ROS2 Wrapper Build Issues on Jetson Nano

Goal: ZED SDK, Python API, and ROS2 (Foxy) wrapper working in Docker container

Background:
We purchased a robot that has a Jetson Nano board running Ubuntu 18.04 (L4T 32.6.1, Cuda 10.2). The Jetson board comes with a ROS2 Foxy Docker image (Ubuntu 20.04) that has company-provided packages to run the robot. We are trying to integrate a ZED 2 camera into this robot’s eco-system. To do this, we are starting with a fresh docker image and first integrating Zed’s components and then the company-provided ROS2 packages.

Current Status:
We have successfully integrated ZED SDK and Python API through the following steps:

  • Pull Nvidia/dustynv’s ros-foxy image (did not use his Zed docker image since that did not have ROS2 and was missing tools like Zed_Explorer)
  • Install Zed SDK (4.0 L4T 32.7) inside the container through the following commands:
    • sudo apt update && sudo apt install zstd
    • ./jetsons – silent skip_od_module skip_hub
  • docker commit this container to a new image

We tested that SDK works using ZED_Explorer and that the Python API works by running one of the sample programs

Issues:
We followed the installation and Github Dockerfile to integrate ROS2 wrapper into our container. Steps in the docs worked unto the rosdep command, but ran into issues at colcon build.

We did manually install missing dependencies as suggested by the linked Dockerfile (lines 60-78) and even tried following lines 83-89 to source ROS Foxy and then colcon build. We only skipped line 80 (upgrading cython) since I believe cython==0.29.36 is necessary for pyzed. However, the xacro package keeps failing to build which prevents the rest of the packages from building. I can provide a log of commands I ran with associated output (unable to attach for some reason). But here’s the error and colcon build summary:

CMake Error at /opt/ros/foxy/install/share/ament_cmake_python/cmake/ament_python_install_package.cmake:34 (message):                         
-- Configuring incomplete, errors occurred!
  ament_python_install_package() called with unused arguments:                                                                                
  SCRIPTS_DESTINATION;lib/xacro
Summary: 6 packages finished [5min 16s]
  1 package failed: xacro
  3 packages aborted: ament_pep257 geographic_msgs nmea_msgs
  10 packages had stderr output: ament_cppcheck ament_flake8 ament_lint ament_lint_auto ament_pep257 ament_pycodestyle angles geographic_msgs nmea_msgs xacro
  33 packages not processed

How can we resolve this issue? Since the linked Dockerfile downloads specific versions of those missing dependencies for ROS Humble L4T35.1.0, we’re wondering if there are specific versions necessary for ROS Foxy L4T 32.7.1. So a Dockerfile / container for Foxy would help.

Hello,

The dependency on Cython version 0.29.36 is needed only for the installation of the pyzed wrapper, once it is installed you can bump the cython version. We are currently working on fixing this issue this problem during the installation of the pyzed module.

It is possible that building the other ROS 2 packages needs an upgraded version of cython, so you can upgrade cython after the installation of pyzed.

Walter

Walter Lucetti
Senior Developer
SDK / Robotics / HW
Stereolabs Support

Hello Walter,

Thanks for the reply. We tried upgrading the cython version too by using line 80 but the same errors/issues persist.

Is there anything else to try or some other package/dependency missing? Perhaps there are specific versions of those missing dependencies for Foxy - are you able to replicate this issue?

Hello,

No I have not replicated the issue for Foxy as we do not provide support for this version since it reached its end of life. You can try to get it to build in a running container, then apply the fixes to your Dockerfile.

Walter

Walter Lucetti
Senior Developer
SDK / Robotics / HW
Stereolabs Support

I see. Since the GitHub home page mentions both Foxy and Humble, we assumed there’s support for both, so this is disappointing to hear.

But yes, we haven’t even tried doing this in a Dockerfile - we have just been trying to get the wrapper to build in a running container. That’s where we’re having the issues mentioned above.