Camera Connection Issues

Camera Connection Issues

Hello, Myzhar! I hope your day or evening is well.

I am working with a small student club competing in multiple robot competition. We have very little funding and are having issues with camera streaming connection. We believe there to be a hardware issue, but are unsure. Our Zed X camera is our only sensor for odemetry at the moment so we would be very grateful for any assistance.

We have noticed during streaming attempt:

• Corrupted frames detected
• NVIDIA Argus timeout
• CAMERA REBOOTING loop
• Socket communication failures (Argus IPC)
This indicated failure during image stream capture.

We are concerned one of these issues are occuring:

  1. Bandwidth or timing mismatch in the video pipeline
  2. One stereo sensor producing unstable frames under load
  3. Unstable or marginal GMSL cable connection
  4. CSI lane instability between deserializer and Jetson

The following debugging steps have been done:

  • followed install instructions with the zed link duo.
  • Checked camera device nodes
  • Verified device tree camera modules properly registered
  • Attempted raw inspection (binary /proc entries)
  • ZED_Explorer hardware verification with /user/local/zed/tools/ZED_Explorer -a
  • Python SDK minimal camera streaming open test
  • Python SDK camera photo
  • Stereolabs’ Diagnostics Tool
  • Explored various system-level and kernel level logs
  • Attempted running after reinstalling camera and capture card multiple times and verifying they’re installed and secured.

Our debugging confirms that:

  • The camera is correctly installed and detected
  • All drivers and hardware initialization steps succeed
  • The failure occurs only during live video streaming

I have provided hardware and software information below:

Hardware

  • Developer Kit Jetson Orin Nano
  • Zed X
  • Duo Capture Card
  • Power Supply to Duo Capture providing 14v
  • Camera Cable 22-pin 0.5mm Pitch to 15-pin 1.0mm Pitch (150-FPC)
  • GMSL2 1-to-4 M-F cable 0.5m (From Duo Capture Card Box)

Software Stack

  • OS: Ubuntu 22.04.5 LTS (GNU/Linux 5.15.185-tegra aarch64)

  • RMW Implementation: rmw_cyclonedds_cpp

  • ZED SDK: v5.2.3

  • L4T: R36.5.0

  • JETPACK: Version: 6.2.2+b24

  • HARDWARE MODE: max

  • Nvidia Driver: Driver Version: 540.5.0

  • CUDA: 12.6

  • ROS: Humble

  • Package: stereolabs-zedlink-duo: 1.4.2-LI-MAX96712-L4T36.5.0

ROS 2 WRAPPER

Install check

VALID OS: Ubuntu 22.04 (Jammy Jellyfish)
SDK: ZED SDK v5.2
ROS: Humble

Installed following correct rosdep instructions (such as symlink install) with ros2-zed-interfaces and prevented zed_debug package

[!NOTE]
Install had one warning from xacro.

Additional Contact

If you wish to privately contact us for whatever reason please contact mechatronicsclub@humber.ca

Hi @TheFujirose
The first thing that I would recommend doing is upgrading the ZED SDK to the latest v5.3.1 and then using the latest version of the ZED ROS2 Wrapper.

On a robotics system, it’s also important to verify that the power supplied to the ZED Link Duo capture card (14V in your case) is stable.
Every single negative power drop (even very short spikes) can cause the capture card to stop communicating, a condition that cannot be recovered even by software using the sudo service zed_x_daemon restart command.

Finally, the NVIDIA Jetson Orin Nano has limited computing power. If you overload it, the ZED X Driver can drop the connection, a condition that you can recover by restarting the daemon with the command above.

Have you applied the DDS tuning illustrated here?

Have you tuned the node frequency as illustrated here?

Hello again,

We tried again with various power supplies and updated to the latest ZED SDK 5.4 and driver, but had no success.

To isolate the issue, we attempted to debug further with a new Jetson Orin Nano, various CSI cable lengths, power supplies, and a different capture card.

Here are our findings:

Using an oscilloscope on our original [Insert Voltage, e.g., 19V] power supply, we verified some power spikes, but they were under 1V, which we assume is normal. We switched to various different supplies of power and tested them individually.

We flashed a new Jetson Orin Nano with Jetpack [6.2.2] and installed the correct driver for a mono capture card; different from our previous duo capture card. On this new setup, it works as expected.

When we use our duo capture card on this exact same new setup–after purging the mono driver and installing the duo driver–it fails exactly as before.

Given that the mono card works on the same hardware where the duo card fails, we have a direct question: Is it safe to conclude our duo capture card is damaged?

(post deleted by author)

Hello,

we have found that using the following script
and occasionally sudo systemctl start driver_zed_loader.service resolves our problem

It’s important to note that the systemctl restart zed_x_daemon or reset for nvargus did not solve our issues. Specifically it was a mixture of more stable CSI connection and cables with driver_zed_loader.service call and IMU_daemon restarts. We aren’t sure why.

script we use

#!/bin/bash
echo "Stopping nvargus"
sudo systemctl stop nvargus-daemon.service
echo "nvargus stopped"
sleep 2
echo "stopping IMU_Daemon"
sudo systemctl stop IMU_Daemon.service
echo "IMU_Daemon stopped"
sleep 1
echo "stopping zed"
sudo service zed_x_daemon stop
echo "zed stopped"
sleep 5
echo "clearing cache"
sudo rm -rf /tmp/argus_socket
echo "cache cleared"
sleep 1
echo "clearing ipc shared memory"
sudo ipcrm -a
echo "done".
sleep 1
echo "starting service nvargus"
sudo systemctl start nvargus-daemon.service
sleep 5

if sudo systemctl is-active --quiet nvargus-daemon.service; then
    echo "nvargus-daemon is active"
else
    echo "ERROR: nvargus-daemon failed to start"
    sudo systemctl status nvargus-daemon.service --no-pager
fi

echo "starting zed"
sudo service zed_x_daemon start
sleep 10

if sudo service zed_x_daemon status | grep -qi 'running'; then
    echo "zed_x_daemon is running"
else
    echo "ERROR: zed_x_daemon failed to start"
    sudo service zed_x_daemon status
fi

echo "starting IMU_Daemon"
sudo systemctl start IMU_Daemon.service
sleep 2

if sudo systemctl is-active --quiet IMU_Daemon.service; then
    echo "IMU_Daemon is active"
else
    echo "ERROR: IMU_Daemon failed to start"
    sudo systemctl status IMU_Daemon.service --no-pager
fi

input=$(ZED_Explorer -a 2>&1)

if echo "$input" | grep -q 'State :  "AVAILABLE"'; then
    echo "Camera is available!"
else
    echo "Camera is not available."
fi