Hi @lincolnxlw
I tried to reproduce with normal OAK-D (so 2x OV9282), but it worked as expected every time (out of 20x) running latest depthai. @jakaskerl , could you perhaps try to repro with FFC-3P and 2x IMX477 cam modules? I'd be surprised that would make a difference though. Perhaps the camera that fails doesn't have perfect connection, and it sometimes doesn't get enumerated, so it doesn't stream?

Hi lincolnxlw
Tried with FFC-3P (r3) and two IMX477 connected to cam_L and cam_R.

lincolnxlw This link contains the code and model to run this python MRE

This link/code works without issues on my machine. Versions: depthai==2.24.0.0. Tried running 20 times, no errors/crashes.

Couldn't setup the ROS version due to USB passthrough issues on M1 macs.

@Luxonis-Adam Can you check with ROS noetic please, so we can pinpoint the issue to a source?
link:

lincolnxlw The link should contain the MRE for this issue.

Thanks,
Jaka

        Hi @jakaskerl and @erik

        Just want to make sure we are on the same page. I don't have issue running the python MRE, like I mentioned earlier

        Also, I created the exact same pipeline in python running with depthai-library docker image, and I will run 10 times without any problem. I attach the python script below.

        The one has blocking issue is the ROS c++ MRE. It is weird because the pipeline is pretty much the same.

        Thanks

        Lincoln

        Hi, regarding ROS Noetic on Mac, I don't it is officially supported, but you could use Docker images to get the latest version running. In general, if it's possible to connect to the camera with basic DepthAI libraries then it should also work for ROS. Could you share your ROS setup?

          Hi Luxonis-Adam

          As I mentioned in the MRE link, the ROS is setup using docker image depthai-ros built by the latest Dockerfile provided in the depthai-ros repo. Anything more specific you want me to provide?

          Thanks

          Lincoln

            18 days later

            Hi Luxonis-Adam

            Just want to follow up on this. Were you able to reproduce the pipeline blocking issue with the provided MRE?

            Thanks

            Lincoln

              Hi @Luxonis-Adam, @jakaskerl, @erik,

              I added another file image_publisher_ros.cpp in the MRE folder for comparison.

              root@0b6870f3b150:/workspaces/depthai_catkin_ws/src/station_depthai/minimum_image_publisher# tree .
.
├── CMakeLists.txt
├── README.md
├── config
│   └── yolov6n.yaml
├── include
│   └── minimum_image_publisher
├── models
│   └── yolov6n_openvino_2022.1_6shave.blob
├── package.xml
└── src
    ├── image_publisher.cpp
    └── image_publisher_ros.cpp

              In image_publisher_ros, it doesn't try to get the image from the queues directly but use dai::rosBridge::BridgePublisher to publish the image data. And the blocking issue is much worse than image_publisher.cpp, almost half of the times are failure. I attached here the screen recording of 10 of my run.

              The depthai library I am using is 2.24.0, which is the latest depthai-ros noetic is using. Let me know what else I can provide to help figure out the issue.

              Library information - version: 2.24.0, commit: 6628488ef8956f73f1c7bf4c8f1da218ad327a6f from 2023-12-13 14:45:09 +0100, build: 2023-12-13 23:26:25 +0000, libusb enabled: true

              Thanks!

              Lincoln

              Hi @lincolnxlw, so far I've been unable to replicate the issue. Could you try setting export DEPTHAI_DEBUG=1 before running the example? Also, is this also happening if you run one or none detection networks?

                Hi Luxonis-Adam

                Thanks for responding. I set up the debug and here are my test videos.

                With image_publisher_ros, it failed 2 times out of 5 runs. Here is the video.

                I created a node with only one color camera with detection network. It worked 10 times out of 10 runs. Here is the video.

                Also, when I run the code without pipeline_graph consuming the terminal output. I noticed some red debug messages. But it shows those messages regardless success or failure. And regardless of two detection network or just one.

                == FSYNC enabled for cam mask 0x0
CAM ID: 1, width: 1920, height: 1080, orientation: 0
CAM ID: 2, width: 1920, height: 1080, orientation: 0
== SW-SYNC: 0, cam mask 0x6
!!! Master Slave config is: single_master_slave !!!
Starting camera 1
[E] app_guzzi_command_callback():173: command->id:1
[E] app_guzzi_command_callback():193: command "1 1" sent

[18443010D1F3F40800] [3.1] [2.609] [system] [warning] PRINT:LeonCss: [E] iq_debug_create():161: iq_debug address 0x88837680
[E] hai_cm_driver_load_dtp():852: Features for camera IMX214R0 (imx214) are received
[E] set_dtp_ids():396: //VIV HAL: Undefined VCM DTP ID 0
[E] set_dtp_ids():405: //VIV HAL: Undefined NVM DTP ID 0
[E] set_dtp_ids():414: //VIV HAL: Undefined lights DTP ID 0
[18443010D1F3F40800] [3.1] [2.619] [system] [warning] PRINT:LeonCss: [E] camera_control_start():347: Camera_id = 1 started.

[E] hai_cm_sensor_select_mode():164: No suitable sensor mode. Selecting default one - 0 for start 1920x1080 at 0x0 fps min 0.000000 max 30.000000
[E] hai_cm_sensor_select_mode():164: No suitable sensor mode. Selecting default one - 0 f
[18443010D1F3F40800] [3.1] [2.581] [DetectionNetwork(2)] [info] Inference thread count: 1, number of shaves allocated per thread: 6, number of Neural Compute Engines (NCE) allocated per thread: 1
[18443010D1F3F40800] [3.1] [2.630] [system] [warning] PRINT:LeonCss: or start 1920x1080 at 0x0 fps min 0.000000 max 30.000000
[18443010D1F3F40800] [3.1] [2.653] [system] [warning] PRINT:LeonCss: [E] vpipe_conv_config():1465: Exit Ok
[E] callback():123: Camera CB START_DONE event.
Starting camera 2
[E] app_guzzi_command_callback():173: command->id:1
[E] app_guzzi_command_callback():193: command "1 2" sent

[18443010D1F3F40800] [3.1] [2.675] [system] [warning] PRINT:LeonCss: [E] iq_debug_create():161: iq_debug address 0x88375cc0
[18443010D1F3F40800] [3.1] [2.686] [system] [warning] PRINT:LeonCss: [E] hai_cm_driver_load_dtp():852: Features for camera IMX214R0 (imx214) are received
[E] set_dtp_ids():396: //VIV HAL: Undefined VCM DTP ID 0
[E] set_dtp_ids():405: //VIV HAL: Undefined NVM DTP ID 0
[E] set_dtp_ids():414: //VIV HAL: Undefined lights DTP ID 0
[E] camera_control_start():347: Camera_id = 2 started.

[18443010D1F3F40800] [3.1] [2.696] [system] [warning] PRINT:LeonCss: [E] hai_cm_sensor_select_mode():164: No suitable sensor mode. Selecting default one - 0 for start 1920x1080 at 0x0 fps min 0.000000 max 30.000000
[E] hai_cm_sensor_select_mode():164: No suitable sensor mode. Selecting default one - 0 for start 1920x1080 at 0x0 fps min 0.000000 max 30.000000
inc_camera_process set exposure and gain
[E] vpipe_conv_config():1465: Exit Ok
[18443010D1F3F40800] [3.1] [2.707] [system] [warning] PRINT:LeonCss: [E] guzzi_event_send():324: Send: Event ID=20003 no registered recipient
[E] guzzi_event_send():324: Send: Event ID=20004 no registered recipient
[E] guzzi_event_send():324: Send: Event ID=20005 no registered recipient
osDrvImx214Control:514: Start stream
[E] callback():123: Camera CB START_DONE event.
inc_camera_process set exposure and gain
osDrvImx214Control:514: Start stream
[18443010D1F3F40800] [3.1] [2.718] [system] [warning] PRINT:LeonCss: AF_TRIGGER on camera 1
[E] app_guzzi_command_callback():173: command->id:5
[E] camera_control_focus_trigger():591: Focus trigger succeeded camera_id = 1.

[E] app_guzzi_command_callback():218: command "5 1" sent

AF_TRIGGER on camera 2
[E] app_guzzi_command_callback():173: command->id:5
[E] camera_control_focus_trigger():591: Focus trigger succeeded camera_id = 2.

[E] app_guzzi_command_callback():218: command "5 2" sent

Starting Guzzi command handling loop...

                Let me know what do you think

                Thanks

                Lincoln

                  5 days later

                  Hi @lincolnxlw, thanks for the information, to narrow it down more, could you try replicating this setup without ROS, using bare depthai-core library?

                    Hi Luxonis-Adam

                    I switched both cameras from IMX477 to IMX214 and ran the same MRE extensively, and I didn't see any blocking issue. I have 10 of the IMX477 modules and no matter how I pair them up (switch cables as well), I can always see the issue. So I don't think it is an individual camera problem. What do you think? Is this something on firmware side or hardware side? If it is on the hardware side, is it from Luxonis side or ArduCam side?

                    @erik, @jakaskerl feel free to let me know what you think as well. This issue has been blocking us from releasing our depthai-powered product.

                    Thanks

                    Lincoln

                      Hi Lincoln,
                      So to confirm, any type of pipeline (just streaming color stream to XLinkOut) with 2x FFC-IMX477 with FFC-3P using latest depthai version there's a chance it will block one camera at the start, and it won't recover? I'm just trying to understand what would be the smallest repro solution, so the engineering team can fix the issue.
                      Thanks, Erik

                        erik

                        Yes one camera will be blocked and won't recover. The tricky part is the issue not appear for all the pipelines with IMX477. But as comparison, with IMX214, NO issue for all the pipelines.

                        In the latest C++ MRE, I have 3 different nodes

                        • image_publisher_node: color camera nodes and detection nodes for CAM_B and CAM_C, no ROS.
                        • image_publisher_ros_node: color camera nodes and detection nodes for CAM_B and CAM_C, also ROS bridges to publish image and detection to ROS.
                        • image_publisher_ros_single_detection_node: color camera nodes for both cameras, only one camera has detection node. ROS publishing image from two cameras and detection from one camera.

                        In term of severity of the issue

                        For image_publisher_node, the blocking issue can be seen directly from the screen, it happens around 1 out of 10

                        For image_publisher_ros_node, we need pipeline_graph to see the FPS. It happens around 2 out of 5

                        For image_publisher_ros_single_detection_node, we need pipeline_graph to see the FPS, I have NOT see the blocking happen yet

                        Also, like I mentioned a while ago, the issue rarely happens with the python MRE even with IMX477 (1 out of 30?). But I did see it happen before.

                        So in summary

                        • The inconsistency of the issue with IMX477 modules in different pipelines, make it looks like it is more on the firmware side.
                        • But absolutely no issue with IMX214 in all pipelines make it looks like IMX477 hardware is the one to blame.

                        Sorry for the mess. Let me know what do you think.

                        Thanks

                        Lincoln

                          Hi @lincolnxlw ,
                          Thank you for all the details, we will try to reproduce this locally and get back to you asap.

                          @lincolnxlw , just to confirm, is the hardware absolutely still when you ran these tests, or do you eg. move it even a tiny bit between runs? It might be an improper connection, which is quite common for FFC cameras, and results in camera not being able to stream.

                            Hi erik

                            The hardware: OAK-FFC-3P with two IMX477 cameras are still during run. The OAK-FFC-3P is powered by the external adapter the came with the product instead of just the USB cable.

                            Let me know if you have any other questions.

                            Thanks

                            Lincoln

                              erik

                              Another information may or may not be relevant. Even though the Luxonis shop is still branding the module as IMX477, but Arducam actually updated the sensor to IMX577, see the description on their own shop for the same module. And the cameras I received and am testing is the updated version with IMX577 sensors. So in order to reproduce the issues, you may need to make sure using the same version.

                              Thanks

                              Lincoln

                                Hi @lincolnxlw ,
                                We just ordered the exact same cameras (from Arducam), hopefully they will arrive in the next 2 weeks and we'll try to repro then. We tried with the IMX477 many times and didn't encounter the issue.
                                Thanks, Erik

                                  Hi erik,

                                  Thanks for trying to repro the issue. I really appreciate it. Just to make sure I did it the right way. What arguments did you provide to launch the container while reproducing the C++ MRE? Here is my command

                                  docker container run --net=host -it --rm \
    --privileged \
    -e DISPLAY=$DISPLAY \
    -e QT_X11_NO_MITSHM=1 \
    -v /dev/bus/usb:/dev/bus/usb \
    -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
    -v $HOME/.Xauthority:/root/.Xauthority:rw \
    -v $HOME/data/:/data:rw \
    --device /dev/i2c-1 \
    depthai-ros \
    bash

                                  Also, I guess there are no issue with all three nodes while using IMX477?

                                  Thanks

                                  Lincoln