I am using a ZED 2 camera with the ZED ROS 2 wrapper on ROS 2 Jazzy.
Description
When viewing the camera directly in ZED Explorer, the image stream appears stable and correct. I monitored it for several minutes and did not observe any flickering or visual corruption.
However, when using the ROS 2 image topics published by the ZED ROS 2 wrapper, I occasionally observe image artifacts.
The artifacts appear as:
Image flickering
Partial mixing of two consecutive frames
Regions of the image appearing to belong to different frames
The issue is intermittent and does not occur continuously.
Additional testing
I initially observed the issue using:
rqt
subscribed to:
/zed/zed_node/rgb/color/rect/image
To rule out an RQt-specific issue, I also tested using:
ros2 run image_tools showimage --ros-args -r image:=/zed/zed_node/rgb/color/rect/image
and observed similar flickering/artifacts there as well.
Therefore, the issue does not appear to be limited to RQt Image View.
The ZED Diagnostic tool reports multiple CUDA installations:
CUDA 13.2
CUDA 12.6
and recommends keeping only CUDA 13.
Rosbag
I recorded a rosbag while reproducing the issue:
Bag details:
Topic: /zed/zed_node/rgb/color/rect/image
Duration: ~3 seconds
Messages: 85
Approximate frame rate: ~29 FPS
Question
Since the image stream is stable in ZED Explorer but shows artifacts when viewed through ROS 2 topics, what additional diagnostics would you recommend to determine whether the issue originates from:
The ROS 2 wrapper
ROS 2 image transport
DDS/QoS configuration
GPU/OpenGL rendering
Another component in the ROS visualization pipeline
Hi, I investigated this further and I can now reproduce the corrupted/mixed frame below ROS 2.
I updated to ZED SDK 5.5.0 and zed-ros2-wrapper v5.5.0, and the issue still occurs.
I then captured the ZED stream directly through Linux V4L2 using MMAP at 3840x1080 YUYV @ 30 FPS, without ROS 2, DDS, rqt, or the ZED ROS wrapper.
I captured a bad buffer with an expected frame size of 8294400 bytes, but bytesused was only 3668672 bytes. The buffer also had flags 0x12041. The bad frame had sequence 1097, and the next normal frame had sequence 1099 with the full 8294400 bytes.
Visually, this produces the same mixed/shifted frame sections I reported before.
So the corruption is already present at the V4L2 level as an incomplete/error frame, which strongly suggests that ROS 2 is not the root cause.
Hi @Sohaib-Snouber,
thank you for the detailed investigation, this is very useful information.
This confirms the hypothesis of my previous reply. The flags value 0x12041 includes V4L2_BUF_FLAG_ERROR (0x40), which the uvcvideo kernel driver sets when it does not receive the full payload of a frame from the USB link. The sequence jump from 1097 to 1099 also shows that a frame was lost. The data is lost between the camera and the host USB3 controller, before the ZED SDK, the ZED ROS 2 Wrapper, or ROS 2 can access it.
Correct, the root cause is the USB3 connection. The most common causes are:
USB3 ports on the front panel or on case extensions, which are connected to the motherboard by internal wires; use a port on the rear I/O panel soldered directly to the motherboard
USB3 hubs, cable extenders, or non-original cables; use the original StereoLabs USB3 cable and check that the connector screws are fully tightened
The USB3 controller shared with other high-bandwidth devices
An outdated BIOS; some AMD Ryzen platforms had known USB data loss issues that were fixed by BIOS (AGESA) updates
USB autosuspend; you can disable it by adding usbcore.autosuspend=-1 to the kernel boot parameters
You can check sudo dmesg -w | grep -i -E "xhci|uvc|usb" while the issue occurs to see if the kernel reports errors on the USB bus.
If no free port on the motherboard solves the problem, a dedicated PCIe USB3 expansion card normally provides a reliable connection.
Finally, keep general.enable_image_validity_check set to 1 in the common_stereo.yaml file, so the ZED SDK checks each frame for corruption before processing it.