Hello,

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

Indeed, if this is the only change, that will be fine.

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

So we can for sure collaborate on this.

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

I see two different questions there. One is to get proper timestamps for 
each slice, the other is to cut the data in smaller chunks. We can work 
on them independently.

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

The first thing I see is adding timestamps to slices and then adding 
support for tf in the reconstruction code. Cutting the full rotation 
into smaller chunks is a matter of trade-offs between latency and 
efficiency, and we can address this later.

I'll be on the move during the next 5 days but later I would like to 
work on this. Would you like to discuss more in private, or on there on 
ros-users as it might interest other people? Would you like me to send 
patches to you? Or use something like gitsvn?

Kind regards,

Stéphane

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