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?
