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 4.x (JetPack 7 / Jetson Thor) is planned for a future release.

The note you quoted about adjusting l4t36.4l4t36.3 only refers to the ZED SDK installer URL, not to the Isaac ROS version. It’s there because the ZED SDK ships separate L4T-specific binaries. The supported path for the wrapper with NITROS is JetPack 6.1+ with Isaac ROS 3.2.x — JetPack 6.0 is below the floor NVIDIA set for Isaac ROS 3.2.

I’ll make sure this prerequisite is called out more clearly in the setup guide.

About your workaround

Renaming the symbol back to NitrosStatisticsConfig builds, but I’d be cautious about relying on it in production. The wrapper currently default-constructs the config (NitrosDiagnosticsConfig()) without setting fields, so you’ll likely get a working build — but the two structs are not field-compatible across the rename, and the diagnostics behavior may silently differ. Given that you’ve been chasing the 5 Hz / 30 Hz instability on this same platform, I’d rather you weren’t also debugging on a patched diagnostics path.

Recommended options, in order

  1. Upgrade to JetPack 6.1+ and use Isaac ROS 3.2.x. This is the configuration we test against. Worth checking with Syslogic first whether their BSP for the RML A4NX supports JP 6.1 or 6.2.
  2. If JP 6.1 is blocked by the BSP, fall back to a pre-NITROS wrapper tag (anything before humble-v5.0.0). You lose NITROS acceleration but you get a tested build on your current stack. With 4× ZED X at 30 Hz this is a measurable performance hit, so option 1 is preferable when feasible.
  3. Keep your local patch only as a short-term unblock while you work toward option 1.

Let me know which path makes sense for your setup, and if you do go the BSP-upgrade route, I’m happy to help debug if anything breaks on the wrapper side.