PointCloud Relay Setup

Overview

Like image data, pointcloud data is something of a special case in ROS. However, pointcloud compression is still an unsolved and active research area, and there isn't any pointcloud compression in ROS. To make up for this gap, our relay software provides special-purpose nodes that combine the network behavior of the generic topic relay with compression provided by either ZLIB, PC30, PC60, or PCL.

Compression

• ZLIB compression applies the same basic compression that's used in PNG compression and gzip - lossless compression on the binary data field of the sensor_msgs/PointCloud2 message type. Compression ratios near 4x are usual; to reduce this further, pre-filtering the cloud with PCL's voxel filter can increase the ratio to 5-6x without causing meaningful degradation of the pointcloud.

• PCL compression applies PCL's octree compression algorithm. This offers significantly better compression ratios (7-8x); however, in our experience, PCL compression can be very unreliable and exhibit corruption.

• PC30 compression is a lossy approach that takes advantage of sensor limitations (range and precision) to reduce data rates (the name comes from using 10 bits each for x, y, and z position). Like PCL, it offers I-frame/P-frame compression, so largely static pointclouds will require significantly less data to transmit. Note - PC30 is limited to points within 5m of the sensor, and does not transfer RGB, HSV, or intensity data. Currently, PC30 offers 3-4x better compression than ZLIB.

• PC60 compression is identical to PC30 in design and features, but doubles the bits used per point (the name comes from using 20 bits each for x, y, and z position). This results in significantly greater range and increased precision. Note - PC60 is limited to points within 500m of the sensor, and does not transfer RGB, HSV, or intensity data. Currently, PC60 offers 1-2x worse compression than PC30.

In our experience, ZLIB, PC30, and PC60 have been significantly more reliable than PCL. We used PC30 at the 2013 DRC Trials.

Service-based relays

Setting up a pointcloud relay "startpoint"

The pointcloud relay startpoint node is request_pointcloud_link_startpoint in the opportunistic_link package. This node requires 3 parameters to be set:

• pointcloud_topic - the name of the original pointcloud topic you want to relay, such as /camera/depth/points_xyz

• data_service - the name of the service used to forward pointclouds between the startpoint and endpoint, such as /camera/depth/points_xyz/data

• compression_type - sets the compression type to use between NONE, ZLIB, PC30, PC60, or PCL

Setting up a pointcloud relay "endpoint"

The pointcloud relay endpoint node is pointcloud_link_endpoint in the opportunistic_link package. This node requires 8 parameters to be set:

• relay_topic - the name of the pointcloud relay topic, such as /relay/camera/depth/points_xyz

• data_service - the name of the service used to forward pointclouds between the startpoint and endpoint, such as /camera/depth/points_xyz/data

• rate_ctrl - the name of the service used by other nodes to control the rate at which data is republished over the link, such as /camera/depth/points_xyz/rate

• default_rate - the default rate, in hz, to republish data. The default value, infinity, means immediate republishing of new data, while the value zero means that republishing is paused

• link_topic - the name of the topic used to republish data between startpoint and endpoint, such as /link/camera/depth/compressed

• filter_ctrl - the name of the service used by other nodes to control the pre-compression voxel filter size, such as /camera/depth/points_xyz/quality

• default_filter_size - sets the filter size (in meters) to pre-filter the pointcloud before compression. A value of 0.0 results in no filtering. In our experience, a value of 0.02 provides a good balance between pointcloud quality and compressed size.

• latched - selects if the publisher should latch the last message published, which means that the last message will be available to all future subscribers

• override_timestamps - selects if the publisher should reset message timestamps to the time of receipt. This is particularly useful for pointclouds, as their size means that they are often received with a considerable time delay. Resetting timestamps ensures that TF queries will succeed - however this is only valid if the robot is largely static during the time delay.

Other relay types

A similar pointcloud relay is provided which uses topics internally for data transfer. Some of the basic parameters are similar, but a number of them are different to handle the setup of the internal topic-based link.