isaac_ros_common icon indicating copy to clipboard operation
isaac_ros_common copied to clipboard

Zed camera suppport

Open jmblixt3 opened this issue 2 years ago • 4 comments

When testing the isaac_ros_common with zed I am able to get the container up and running and test the zed's functionality using /usr/local/zed/tools/ZED_Explorer on both x86_64 and aarch64. However, when I attempt to build the zed_wrapper on Jetson-AGX-Orin I get the following error while building. For reference I am using a zed2i, so I don't have zedx sdk installed.

--- stderr: zed_wrapper                              
/usr/bin/ld: /usr/local/zed/lib/libsl_zed.so: undefined reference to `NvBufSurfaceGetMapParams'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/zed_wrapper.dir/build.make:447: zed_wrapper] Error 1
make[1]: *** [CMakeFiles/Makefile2:164: CMakeFiles/zed_wrapper.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
---
Failed   <<< zed_wrapper [1.26s, exited with code 2]

I am able to temporarily fix it using the cmake args found with this issue here. Example command:

colcon build --symlink-install --packages-select-regex zed* --cmake-args -DCMAKE_LIBRARY_PATH=/usr/local/cuda/lib64/stubs -DCMAKE_CXX_FLAGS="-Wl,--allow-shlib-undefined"

This behavior is quite annoying and I hope there is a way to modify the aarch64 zed docker layer to fix this.

jmblixt3 avatar Oct 23 '23 18:10 jmblixt3

That is surprising and we have not run into this ourselves yet but we had been testing with some pre-release build of Zed SDK from Stereolabs perhaps. When you say you're building the zed_wrapper, this is within a Docker build phase step or within the running Docker container?

It looks like the former, in which case the BuildKit environment does not respect the default runtime of "nvidia." Our workaround for this is that we actually launch the container, run our build steps for all Isaac ROS packages as well as zed_wrapper in an entrypoint shell script, and then use docker to take a snapshot of the running container to get the final built packages into a Docker image. This is not ideal but it has worked for us since the change in build environment engine went in for Docker.

You can also set BUILDKIT=0 and run docker build commands safely which will then pick up the default nvidia runtime specified in your /etc/docker/daemon.json if configured.

hemalshahNV avatar Oct 23 '23 22:10 hemalshahNV

I encountered it while in a running container with the zed_wrapper in my ros workspace, not built during build phase step. I will have to test the BUILDKIT=0 workaround when I am with the Jetson again.

jmblixt3 avatar Oct 23 '23 22:10 jmblixt3

I was able to test the buildkit=0 and that worked. Looking at buildkit documentation I was also able to change buildkits runtime to nvidia's so that seems more optimal for my solution. It was by adding the following to /etc/buildkit/buildkitd.toml:

# configure the containerd runtime
[worker.containerd.runtime]
  name = "nvidia"

Ideally this could be added to documentation until docker buildkit respects default runtime. Buildkit Documentation

jmblixt3 avatar Oct 24 '23 17:10 jmblixt3

Interesting! Yes, turning off BuildKit would then allow the "default" runtime flag in /etc/docker/daemon.json take effect in the "legacy" builder environment. At last check with Docker, though, shortly after they enabled BuildKit by default, there was no way to use any other builder in BuildKit other than runc which was a known issue (see here). However, if you can configure BuildKit itself to use the nvidia runtime now, then we're all set! Let me try it out locally and we can add to the documentation + update run_dev.sh. Thanks!

hemalshahNV avatar Oct 30 '23 22:10 hemalshahNV