Hello,

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

Nice to hear from you! Thank you for your detailed mail.

>> 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.

Indeed. The device-specific configuration file is now in XML (from your 
code (data.cc) it seems that yours is a simple space-separated file, was 
this the vendor format or did you implement a translator?)

> 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

In any case I will reuse part of it, such as the input abstraction. For 
the rest, see the discussion later in this email. Whenever possible, I 
would like to share the code as well.

>> 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.

As far as I have seen, the raw scan data do not contain a timestamp for 
each raw scan. The problem is thus that for a whole revolution, if the 
Velodyne is mounted on a car going at 72 km/h, and the Velodyne is 
rotating at 10 Hz, there will be 2 m of errors in the point cloud. This 
is by far larger than the intrinsic Velodyne error.

We could keep your architecture but add one timestamp per scan slice and 
use these in conjunction with a tf transform tree to correct the 
position of the scans. What do you think?

> 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.

Isn't PointCloud2 stable yet? It is in sensor_msgs in C turtle, no?

>> 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.

Yes, I fully agree.

> 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.

That's great, it would be nice to cooperate indeed.

Kind regards,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net