[ros-users] scan_to_cloud_filter_chain for high-bandwidth scanners

[Jack O'Quin]

2010/10/27 Stéphane Magnenat <stephane.magnenat at mavt.ethz.ch>:
> Dear list,
>
> At ASL we are beginning to write a ROS driver for the Velodyne HDL-64E
> S2. There exists already a Velodyne driver in ROS but for a different model.

I maintain the existing velodyne ROS stack. As you mention, our device
is the older model HDL-64E.

> The Velodyne HDL-64E S2 is a rotating lidar sensor that consists of 64
> lasers mounted on a rotating platform. The sensor head rotates up to 15
> rps and at that speed it acquires ~1400 points per laser per turn.

I don't know exactly what changes have been made in the S2 device
interface, but I would be surprised if they were very big. Our
intention has been to share code as much as possible.

Would you be interested in developing a modified velodyne_read driver
with support for the S2?

  http://www.ros.org/wiki/velodyne_common#velodyne_read

> We can thus consider this scanner as being a source of LaserScan (64
> points) and tf_data (the rotation matrix of the head) at the rate of 21
> kHz. Ideally, one would use a scan_to_cloud_filter_chain to fuse these
> into a point cloud. However with a sensor of such a high bandwidth the
> amount of context switches seems prohibitively large for implementing
> such a scheme. While maybe with current hardware this sensor produces
> too much data for complex real-time processing, the conceptual problem
> remains.

We did it rather differently. The device produces data at such a high
rate, that I did not want to risk dropping packets due to processing
overhead in the driver thread. Hence our velodyne_read driver
publishes raw scan data for each revolution of the device in Velodyne
packet format.

There are other programs in the stack that convert the raw data into
various useful formats, mainly PointCloud. We intend to add
PointCloud2, but are waiting for those interfaces to stabilize before
committing much time to it.

> Is there any discussion on this question or any work toward a solution,
> for instance implementing laser_filters using nodelets?

We plan to provide nodelet support for this device, because it seems
to offer significant performance advantages for such a high-bandwidth
device.

If you have specific requirements or other ideas for how best to
support these devices, I would like you hear about them. We are
definitely open to doing cooperative work with you and other groups.
-- 
 joq