Multi-ZED X ROS2 node repeatedly crashes on JetPack 6.0.0 with Isaac ROS 3.1

[andrew.stringfield]

Summary

• We’re running 4× ZED X cameras via GMSL using the zed_multi_camera ROS2 node inside an Isaac ROS Docker container on Jetson Orin NX (Syslogic IPC).
• The node consistently crashes after a period of time — cameras enter CAMERA_REBOOTING, fail to recover, and eventually one camera returns FAILURE, taking down the whole node.
• We’ve tested across two different machines, and with multiple ZED SDK versions — the crash is 100% reproducible.
• We’d like support to understand how we can make a mulit-ZED X ROS2 node run more reliably.

Background

Following on from this issue, we’ve taken the option to run the pre-NITROS ZED wrapper.

Error building ZED ROS2 wrapper on JetPack 6.0.0 with NVIDIA ROS Isaac 3.1

Hi @andrew.stringfield NITROS support was introduced in zed-ros2-wrapper humble-v5.0.0 against the Isaac ROS 3.2 API. The struct was renamed from NitrosStatisticsConfig (v3.1) to NitrosDiagnosticsConfig (v3.2) by NVIDIA, and we built against the new name. The wrapper is currently only compatible with Isaac ROS 3.2.x — this is documented on our Isaac ROS integration page, but I agree it’s not as prominent as it should be on the setup guide itself. I’ll flag it internally. Support for Isaac ROS…

Environment

• Platform: Jetson Orin NX (Syslogic RML A4NX GMSL — two units: “Alpha” and “Beta”)

• JetPack: 6.0 (L4T R36.3)

• Isaac ROS: 3.1

• ZED ROS: humble-v4.2.5

• ZED SDK: 5.0.5 and 5.0.7

• ROS2: Humble

• Cameras: 4× ZED X GMSL

• Launch command:

  ros2 launch zed_multi_camera zed_multi_camera.launch.py \
    cam_names:="[zedx_0,zedx_1,zedx_2,zedx_3]" \
    cam_models:="[zedx,zedx,zedx,zedx]" \
    cam_ids:="[0,1,2,3]" \
  

Crash Behaviour

Every test ends the same way:

1. All cameras simultaneously hit CAMERA_REBOOTING errors
2. Cameras attempt to reboot but fail to recover
3. One camera (usually zedx_3) returns FAILURE, which cascades and takes down all the others
4. Sometimes the node process exits after varying amounts of time after hitting camera failures

Comparison to a Python application

We ran our own Python-based 4-camera object-detection application (which uses the ZED Python SDK directly, not the ROS2 wrapper) on the same Syslogic Alpha machine with the same cameras. It ran continuously for over 3 days (635,000+ grab/inference iterations) without crashing. This suggests that the hardware and environment setup run reliably without using ROS.

Test Results

#	Machine	ZED SDK (Container)	ZED SDK (Host)	ROS2 Wrapper / Examples	NITROS	Runtime Before Crash	Failed Camera	Log Files
1	Syslogic Alpha	5.0.5	5.0.5	humble-v4.2.5	No	~5h 30m	zedx_3	zed_multi.log.2026-05-20, nvargus.log.2026-05-20
2	Syslogic Alpha	5.0.5	5.0.5	humble-v4.2.5	No	~5h 40m	zedx_3	zed_multi.log.2026-05-21, nvargus.log.2026-05-21
3	Syslogic Alpha	5.0.5	5.0.5	humble-v4.2.5	No	~5h 55m	zedx_3	zed_multi.log.2026-05-21.2, nvargus.log.2026-05-21.2
4	Syslogic Beta	5.0.5	5.0.5	humble-v4.2.5	No	~15 min	—	zed_multi.log.2026-05-22.beta, nvargus.log.2026-05-22.beta
5	Syslogic Beta	5.0.5	5.0.5	humble-v4.2.5	No	< 10 min	—	—
6	Syslogic Alpha	5.0.7	5.0.5	humble-v4.2.5	No	~2h	—	zed_multi.log.2026-06-03, nvargus.log.2026-06-03
7	Syslogic Alpha	5.0.7	5.0.7	humble-v4.2.5	No	< 5 min	—	zed_multi.log.2026-06-04, nvargus.log.2026-06-04

Key Observations

1. From the zed_multi.log* logs, the crash occurs in the same way each run
2. Swapping cameras over between GMSL ports had no affect, suggesting the issue is not related to a specific camera
3. The issue is reproducible on both machines
4. Upgrading to the latest ZED SDK 5.0 didn’t resolve the issue

Questions

1. Is there a known issue with the zed_multi_camera ROS2 node and long-running multi-GMSL2 camera setups on Jetson Orin NX?
2. Is there a known issue with the camera rebooting process in the zed_multi_camera ROS2 node?
   • I do notice the following log when running the node. Could the rebooting be failing because the container can’t interact with the zed_x_daemon? If so, how could I fix that?

     [component_container_isolated-1] [ZED-X][Warning] Failed to connect to zed_x_daemon.
     

3. Can you provide any guidance on how we can make this environment configuration run more reliably?

Log files

I’ll email the log files referenced in the table above to Stereolabs support separately, including the standard sudo ZED_Diagnostic --dmesg and ZED_Diagnostic -c files.

Any help would be greatly appreciated — we think moving to a ROS2-based system would be highly valuable, but this is blocking us.