ROS + OpenNI2 + NiTE2

After weeks banging my head with OpenNI version 1.5.4 that comes with my ROS fuerte installation, I finally come to the conclusion that OpenNI 1.5.4 is highly frustrating, difficult to use, and has very low code readability. Or maybe it is just me.

It is time to migrate to OpenNI2, the latest version of the library that has been completely hauled with new architecture, with (much) better code readability. And another good thing about this release is that this will not mess the other version of OpenNI, so we can still work with both version in the same time.

The installation process is pretty straight forward. We can get the installation files after registering on OpenNI website. Then just simply run the install script from each folder.

Then, to use OpenNI2 and NiTE2 with ROS, we need to add some parameters to the CMakeLists.txt of our ROS project/package to link them with the libraries. Here’s mine:

cmake_minimum_required(VERSION 2.4.6)

# Change two lines below according to your installation
set(OPENNI2_DIR /home/ariandy/src/OpenNI-Linux-x64-2.2/)
set(NITE2_DIR /home/ariandy/src/NiTE-Linux-x64-2.2/)

#set the default path for built executables to the "bin" directory
#set the default path for built libraries to the "lib" directory



rosbuild_add_executable(testing src/main.cpp)
target_link_libraries(testing OpenNI2 NiTE2)

Now grab any sample program codes from the OpenNI2 or NiTE2 and put it inside our ROS package for testing. It should compile just fine.

There’s still one issue though. NiTE2 uses machine learning method for the human recognition and also skeleton fitting, which relies heavily on training data. It keeps the training data on NiTE2 folder inside NiTE-Linux-*/Samples/Bin folder. And somehow, when NiTE2 initializes it will look for the training data relative to the path (e.g. your executable is at /home/user, then it will look for /home/user/NiTE2/*). That is a bummer, since we can run ROS executable (node) regardless of the path and this NiTE2 thing defeats the purpose. Workaround is by navigating first to NiTE-Linux-*/Samples/Bin/ or NiTE-Linux-*/Redist/ then do rosrun your_package your_node, otherwise it won’t find the training data.