[ros-users] scan_to_cloud_filter_chain for high-bandwidth scanners

Stéphane Magnenat stephane.magnenat at mavt.ethz.ch
Thu Oct 28 15:06:05 UTC 2010


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


Dr Stéphane Magnenat

More information about the ros-users mailing list