2010/10/28 Stéphane Magnenat <stephane.magnenat@mavt.ethz.ch>:

>>> 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?)

That was the original format (as best I can remember). Adding an input
class or option specific to the new format should be straightforward.

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

You are quite right about that. We would like to address this problem, too.

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

That should be possible. The driver does not require a full scan to
publish data. I just did that to create a simple interface for our
students to work with. For that it was a success, they have created
many interesting programs to process the data in various ways.

I believe the driver can publish smaller groups of packet without
getting behind. When I wrote it a year ago, I was not sure about that.
We could feed that stream into a different nodelet thread that would
transform the data into /map or /odom coordinates and (optionally)
assemble the packets into complete 360 degree scans, if desired.

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

The PCL interfaces are still changing significantly. The intent is to
get at least the basics stable for Diamondback. Others can explain the
status better than I. I have been following those discussions with
interest. It looks like a wonderful collection of filters for devices
like ours, but I currently plan to wait until next semester (January)
before I start porting our packages to PointCloud2. Maybe I am wrong
about that.

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

Good. There are other ROS users with significant Velodyne experience.
Perhaps they will want to participate as well.

I am certainly open to better ideas. This was the second ROS driver I
ever wrote and has not changed significantly since a year ago. The
package status is marked "experimental". We could start by doing an
API review of what's there and make a list of things to improve.

Regards,
-- 
 joq