skip to content
Tang's Blog

Setup Kinect V2 in ROS for Jetson Nano

/ 2 min read

Updated:
Table of Contents

Hardware modification

Safety warning: This modification involves a mains-powered adapter and a 12 V supply. Verify the connector pinout, voltage, polarity, grounding, and current capacity before connecting the camera. A wiring error can damage the Kinect, Jetson, or power supply.

Kinect V2 was designed for the Xbox One and uses a proprietary connector that carries USB 3.0 and external power. The developer adapter breaks this out to a standard USB connection and supplies power. For this robot, I added a 12 V power lead with an XT30 connector and used a USB 3.0 Type-B to Type-C cable. This paragraph describes one tested unit; confirm the pinout independently before reproducing the modification.

libfreenect2

Libfreenect2 is an open-source, cross-platform Kinect V2 driver. This setup uses legacy Jetson Nano software, so pin the tested source revision and dependencies rather than assuming the current default branch behaves identically.

  • Make sure that cmake .. can find the CUDA dependency.
  • Disable the OpenCL backend if OpenCL is unavailable. Test the CUDA backend with Protonect before adding ROS.
  • Build with cmake .. -DENABLE_CXX11=ON -DCUDA_PROPAGATE_HOST_FLAGS=off -DCMAKE_INSTALL_PREFIX=$HOME/freenect2
  • Run make install; the command above installs the library in $HOME/freenect2.
  • Install USB driver for Kinect V2 sudo cp ../platform/linux/udev/90-kinect2.rules /etc/udev/rules.d/
  • Note that Kinect V2 only supports USB 3, and some USB-C to USB-A is sensitive for flipping.
  • If tegraxusb reports an error when launching Protonect, record the exact error and test another SuperSpeed cable or port before changing the build configuration.

iai_Kinect2

This bridge connects libfreenect2 to ROS. The linked fork contains OpenCV 4 compatibility changes for the legacy ROS 1 environment. Test libfreenect2 independently before debugging kinect2_bridge, and record the exact OpenCV, CUDA, and source revisions used by a reproducible build.

Others

  • In this setup, depth processing used CUDA while other image processing still consumed substantial CPU. Streaming multiple image topics also caused packet loss.
  • Compressed image transport reduced network bandwidth and end-to-end latency in the remote-viewing setup.