o3d3xx-ros is a wrapper around libo3d3xx enabling the usage of IFM Efector O3D3xx ToF cameras from within ROS software systems.

1. Ubuntu 14.04
2. ROS Indigo
3. libo3d3xx

Additionally, your compiler must support C++11. This package was initially developed and tested using g++ 4.8.2 on Ubuntu 14.04 LTS. This is the stock gcc-based C++ compiler on Ubuntu 14.04.

NOTE: Since we are talking about ROS here, we assume you are on Ubuntu Linux.

You should first ensure that you have installed ROS by following these instructions. The desktop-full installation is highly recommended.

Next, you should be sure to install libo3d3xx. This ROS package assumes you have installed libo3d3xx via the supported debian installer. Step-by-step instructions for that process now follows:

$ git clone https://github.com/lovepark/libo3d3xx.git
$ cd libo3d3xx
$ mkdir build
$ cd build
$ cmake ..
$ make
$ make check
$ make package
$ sudo dpkg -i libo3d3xx_0.1.3_amd64.deb

NOTE: The version string in the deb file may be different based upon the version of libo3d3xx that you are building.

If everything above went successfully, you should have libo3d3xx installed at /opt/libo3d3xx. Per the libo3d3xx README, it is also recommended that you add the following to your ~/.bash_profile:

if [ -f /opt/libo3d3xx/etc/setup.bash ]; then
    source /opt/libo3d3xx/etc/setup.bash
fi

We now move on to building o3d3xx-ros.

Building and installing o3d3xx-ros is accomplished by utilizing the ROS catkin tool. There are many tutorials and other pieces of advice available on-line advising how to most effectively utilize catkin. However, the basic idea is to provide a clean separation between your source code repository and your build and runtime environments. The instructions that now follow represent how we choose to use catkin to build and permanently install a ROS package from source.

First, we need to decide where we want our software to ultimately be installed. For purposes of this document, we will assume that we will install our ROS packages at ~/ros. For convenience, we add the following to our ~/.bash_profile:

if [ -f /opt/ros/indigo/setup.bash ]; then
    source /opt/ros/indigo/setup.bash
fi

cd ${HOME}

export LPR_ROS=${HOME}/ros

if [ -d ${LPR_ROS} ]; then
    for i in $(ls ${LPR_ROS}); do
        if [ -d ${LPR_ROS}/${i} ]; then
            if [ -f ${LPR_ROS}/${i}/setup.bash ]; then
                source ${LPR_ROS}/${i}/setup.bash --extend
            fi
        fi
    done
fi

Next, we need to get the code from github. We assume we keep all of our git repositories in ~/dev.

$ cd ~/dev
$ git clone https://github.com/lovepark/o3d3xx-ros.git

We now have the code in ~/dev/o3d3xx-ros. Next, we want to create a catkin workspace that we can use to build and install that code from. It is the catkin philosophy that we do not do this directly in the source directory.

$ cd ~/dev
$ mkdir o3d3xx-catkin
$ cd o3d3xx-catkin
$ mkdir src
$ cd src
$ catkin_init_workspace
$ ln -s ~/dev/o3d3xx-ros o3d3xx

So, you should have a catkin workspace set up to build the o3d3xx-ros code that looks basically like:

[ ~/dev/o3d3xx-catkin/src ]
tpanzarella@jelly: $ pwd
/home/tpanzarella/dev/o3d3xx-catkin/src

[ ~/dev/o3d3xx-catkin/src ]
tpanzarella@jelly: $ ls -l
total 0
lrwxrwxrwx 1 tpanzarella tpanzarella 49 Dec  2 15:26 CMakeLists.txt -> /opt/ros/indigo/share/catkin/cmake/toplevel.cmake
lrwxrwxrwx 1 tpanzarella tpanzarella 32 Dec  2 15:24 o3d3xx -> /home/tpanzarella/dev/o3d3xx-ros

Now we are ready to build the code.

$ cd ~/dev/o3d3xx-catkin
$ catkin_make
$ cd build
$ make run_tests
$ cd ..
$ catkin_make -DCMAKE_INSTALL_PREFIX=${LPR_ROS}/o3d3xx install

The ROS package should now be installed in ~/ros/o3d3xx. To test everything out you should open a fresh bash shell, and start up a ROS core:

$ roscore

Open another shell and start the primary camera node:

$ roslaunch o3d3xx camera.launch ip:=192.168.10.69

NOTE: The IP address of your camera may differ. If you are using the factory default (192.168.0.69), you do not need to specify it on the above roslaunch line.

Open another shell and start the rviz node to visualize the data coming from the camera:

$ roslaunch o3d3xx rviz.launch

At this point, you should see an rviz window that looks something like:

Congratulations! You can now utilize o3d3xx-ros.

This node provides a real-time feed to the camera data. This node is started from the primary camera.launch file:

$ roslaunch o3d3xx camera.launch

The naming of the camera can be customized via the ns (namespace) and nn (node name) command line arguments passed to the camera.launch file. For example, if you specify your roslaunch command as:

$ roslaunch o3d3xx camera.launch ns:=robot nn:=front_camera

The node will have the name /robot/front_camera in the ROS computation graph.

     <tr>
         <td>/o3d3xx/camera/amplitude</td>
         <td>sensor_msgs/Image</td>
         <td>16-bit gray scale encoding of the sensor Amplitude image
         normalized wrt exposure time. </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/raw_amplitude</td>
         <td>sensor_msgs/Image</td>
         <td>16-bit gray scale encoding of the sensor Amplitude image
         non-normalized.</td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/cloud</td>
         <td>sensor_msgs/PointCloud2</td>
         <td>
         A 3D PCL point cloud of point type `XYZI`. In this encoding the
         intensity channel is represented by the corresponding pixel's
         amplitude data. The units of this point cloud are in meters.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/confidence</td>
         <td>sensor_msgs/Image</td>
         <td>
         An 8-bit mono image encoding of the confidence image. The meaning
         of each bit of each pixel value is discussed in the official IFM
         documentation for the camera.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/depth</td>
         <td>sensor_msgs/Image</td>
         <td>
         A 16-bit mono image encoding of the radial depth map from the
         camera. The depth units are in millimeters.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/depth_viz</td>
         <td>sensor_msgs/Image</td>
         <td>
         A rendering of the depth image utilizing a colormap more
         human-friendly for visualization purposes. For performance
         reasons, messages are only published to this topic when the
         `publish_viz_images` parameter is set to true at launch time.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/good_bad_pixels</td>
         <td>sensor_msgs/Image</td>
         <td>
         A binary image showing good vs. bad pixels on the pixel array. Bad
         pixels can be caused by numerous reasons (e.g., motion blur over
         an integration/exposure timestep). Visualizing this data is useful
         for when you are tuning your imager parameters. For performance
         reasons, messages are only published to this topic when the
         `publish_viz_images` parameter is set to true at launch time.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/xyz_image</td>
         <td>sensor_msgs/Image</td>
         <td>
         An OpenCV image encoding (CV_16SC3) of the same point cloud that
         is published to `/o3d3xx/camera/cloud` where the three image planes
         are 0 = x, 1 = y, 2 = z. Units are in millimeters yet the coord
         frame is consistent with the point cloud.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/unit_vectors</td>
         <td>sensor_msgs/Image</td>
         <td>
         An OpenCV image encoding (CV_32FC3) of the rotated unit vectors
         that can be used together with the translation vector from the
         camera extrinsics and the radial distance image to compute the
         cartesian coordinates for each pixel in the imager array off-board
         the camera. This topic is latched.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/extrinsics</td>
         <td><a href="msg/Extrinsics.msg">Extrinsics.msg</a></td>
         <td>
         Extrinsics as reported by the camera. The translation vector here
         is used together with the unit vectors and the radial distance
         image to compute the Cartesian coordinates for each pixel in the
         imager array. It should be noted that for this message, the
         translational units are in mm and the rotational units are in
         degrees. This is to be consistent with the camera eventhough it is
         not necessarily consistent with ROS conventions. Usage of this
         message is really for very specialized use-cases.
         </td>
     </tr>

This node is of type tf/static_transform_publisher. It establishes a frame_id for the camera in the global tf tree. This node is launched from the primary camera.launch file:

$ roslaunch o3d3xx camera.launch

When run as above, the tf publishing node would be named /o3d3xx/camera_tf and the camera coordinate frame would be o3d3xx/camera_link in the tf tree.

You can customize this naming (to an extent) via the ns (namespace) and nn (node name) command line arguments passed to the camera.launch file. For example, if you specify your roslaunch command as:

$ roslaunch o3d3xx camera.launch ns:=robot nn:=front_camera

The node name will be /robot/front_camera_tf and the camera frame will be robot/front_camera_link in the tf tree.

This node is used as a proxy to simplify calling the /o3d3xx/camera/Config service offered by the /o3d3xx/camera node. It was noted above that there appears to be a limitation in the YAML parser of the ROS rosservice command line tool. Specifically, it seems that it is not capable of assigning a JSON string to a variable. This is the reason for this node. This is not a long-running node but rather works like a typical command-line tool would: you invoke it, it runs, and exits. The following command line will launch this node:

$ roslaunch o3d3xx config.launch

NOTE: This node has been deprecated and will be going away in the next release.

This node provides a way to subscribe to the various point cloud and image topics provided by the /o3d3xx/camera node and write the data to files. Specifically, PCD files for the /o3d3xx/camera/cloud topic, PNG files for the /o3d3xx/camera/depth, /o3d3xx/camera/amplitude, /o3d3xx/camera/raw_amplitude, and /o3d3xx/camera/confidence topics, and OpenCV YAML files for the /o3d3xx/camera/xyz_image topic. This node was created to ease tool interoperability of performing analysis on the data provided by the O3D3xx camera. For example, at Love Park Robotics, our lead quant likes to use MATLAB for algorithm design and using this node to record data from the camera allows us to perform quick data collection tasks from an O3D3xx camera stream and puts us in position to immediately ingest that data into MATLAB without having to fuss with bag files or any other data-interchange issues. This node is started from the file_writer.launch file:

$ roslaunch o3d3xx file_writer.launch

The naming of the node can be customized via the ns (namespace) and nn (node name) command line arguments.

By default, this node will write its output to /tmp/o3d3xx-ros/data but that can be customized with the outdir parameter passed on the command line to file_writer.launch.

Here is a brief writeup on how you can use this node to feed data to MATLAB for off-line analysis.

     <tr>
         <td>/o3d3xx/camera/amplitude</td>
         <td>sensor_msgs/Image</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/amplitude/amplitude_XXX.png` where `XXX` is
         a monotonically increasing integer value.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/raw_amplitude</td>
         <td>sensor_msgs/Image</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/raw_amplitude/raw_amplitude_XXX.png` where
         `XXX` is a monotonically increasing integer value.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/cloud</td>
         <td>sensor_msgs/PointCloud2</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/cloud/cloud_XXX.pcd` where `XXX` is a
         monotonically increasing integer value.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/confidence</td>
         <td>sensor_msgs/Image</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/confidence/confidence_XXX.png` where `XXX` is
         a monotonically increasing integer value.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/depth</td>
         <td>sensor_msgs/Image</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/depth/depth_XXX.png` where `XXX` is
         a monotonically increasing integer value.
         </td>
     </tr>
     <tr>
         <td>/o3d3xx/camera/xyz_image</td>
         <td>sensor_msgs/Image</td>
         <td>
         Data received on this topic is written to
         `/tmp/o3d3xx-ros/data/xyz_image/xyz_XXX.yml` where `XXX` is
         a monotonically increasing integer value. The YAML file is in the
         OpenCV `FileStorage` format (i.e., it is human readable and
         readily ingested by OpenCV C++ or Python bindings. Parsers for
         other languages would be a simple matter of programming
         (SMOP).
         </td>
     </tr>

This package offers a launch script that wraps the execution of rviz so that the display will be conveniently configured for visualizing the /o3d3xx/camera data. To launch this node:

$ roslaunch o3d3xx rviz.launch

Running the command as above will color the point cloud with the data from the normalized amplitude image (i.e., the intensity).

The rviz window should look something like (assuming you are coloring the point cloud with the intensity data):

This package offers a launch script that wraps the topic_tools/throttler node so that it can throttle the core topics from the camera. Specifically, it will throttle /o3d3xx/camera/cloud to /o3d3xx/camera/cloud_throttle, /o3d3xx/camera/amplitude to /o3d3xx/camera/amplitude_throttle, /o3d3xx/camera/raw_amplitude_throttle, /o3d3xx/camera/depth to /o3d3xx/camera/depth_throttle, /o3d3xx/camera/confidence to /o3d3xx/camera/confidence_throttle. To launch this node:

$ roslaunch o3d3xx throttled.launch

By default, it will throttle the above named topics to 1 Hz. You can change the frequency with the hz command line argument. For example, to send data at 2 Hz:

$ roslaunch o3d3xx throttled.launch hz:=2.0

Using this launch file to launch this set of nodes is strictly optional. We have found use for it in two ways. First, to slow down the publishing frequency of the topics when used in conjunction with the /o3d3xx/camera/file_writer node for collecting data (i.e., in those instances when we really do not need all the data but rather some subsampling of it). Second, if we are running the camera on a drone (for example) that has a slower radio link down to a ground control station running rviz where we want to see what the camera sees while the drone is in flight. Clearly there are other uses for this, YMMV.

Configuring the camera is accomplished by passing a JSON string to the /o3d3xx/camera/config_node which will call the /o3d3xx/camera/Config service to mutate the camera settings. Using a JSON string to configure the camera has the following primary benefits:

0. Configuration is declarative. The camera configuration will reflect that which is described by the JSON file.
1. The JSON data is human-consumable and easily edited in a text editor. This makes it very convenient for headless embedded systems.
2. The JSON data is machine parsable, so configuring the camera on the fly via programmable logic is also possible.

There are also a few downfalls to using JSON. Most notably the lack of comments and an enforceable schema. One could argue that the latter keeps things flexible. None-the-less, JSON is the format used by libo3d3xx and, by extension, this ROS package.

An exemplary JSON file is shown here (this is the result of calling the /o3d3xx/camera/Dump service on a development system). When passing a JSON string (like the previously linked to file) to the /o3d3xx/camera/Config service (or to the /o3d3xx/camera/config_node) the following rules are used to configure the camera:

0. The Device section is processed and saved on the camera.
1. The Apps section is processed. For each app:
2. If the Index key is present, a current app at that Index is looked up. If present, it is edited to reflect the data in the JSON file. If an app at that Index is not present, a new app is created with the parameters from the JSON file. It is not guaranteed that the new app will have the specified Index.
3. If the Index key is not present, a new app is created with the parameters as specified in the JSON file.
4. The active application is set by consulting the desired index of the ActiveApplication from the Device section of the JSON. If the specified Index does not exist, the active application is not set.
5. The Net section is processed. A reboot of the camera may be necessary after changing the camera's network parameters. Additionally, you will likely need to restart the /o3d3xx/camera node pointing it to the new IP address (if that is what you changed).

It should also be noted that any portion of the JSON tree can be specfied to configure only that part of the camera. The only rule to follow is that all keys should be fully qualified. For example, to simply set the active application, you can use a JSON snippet like this:

{
    "o3d3xx":
    {
        "Device":
        {
            "ActiveApplication": "2"
        }
    }
}

The above snippet is provided as an example here. To apply this to your camera, you can:

$ roslaunch o3d3xx config.launch infile:=/path/to/ex_set_active.json

It was also noted above that the /o3d3xx/camera/config_node will read stdin by default, so you could also:

$ echo '{"o3d3xx":{"Device":{"ActiveApplication":"2"}}}' | roslaunch o3d3xx config.launch

Here is another example JSON file. This one will add a new application to the camera, using the default values for the high-dynamic range imager. We note that this application is added to the camera because no Index is specified for the application. If an Index were specfied, the application at the specified Index, if present, would be edited to reflect this configuration.

In general, a simple way to configure camera settings without having to memorize the JSON syntax would be to simply dump the current camera settings to a file:

$ rosservice call /o3d3xx/camera/Dump > /tmp/camera.json

Then, open /tmp/camera.json with a text editor to create a declarative JSON configuration for your camera. You should be sure to delete the variable names from the rosservice output if you are following this example word-for-word. Additionally, you can delete any unnecessary keys if you would like, however it is not strictly necessary as the /o3d3xx/camera/Config service will leave unedited values unchanged on the camera. Once you have a configuration that you like, you can:

$ roslaunch o3d3xx config.launch infile:=/tmp/camera.json

You can check that your configuration is active by calling the /o3d3xx/camera/Dump service again.

Please see the Github Issues.

Please see the file called LICENSE.

Tom Panzarella tom@loveparkrobotics.com