[ros-users] scan_to_cloud_filter_chain for high-bandwidth scanners

Jack O'Quin jack.oquin at gmail.com
Fri Oct 29 00:32:06 UTC 2010


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

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

Yes.

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

The simple-minded RawScan message we are using is not required to
contain all the data for a single revolution. It just contains a
header (with time stamp) and a vector of data.

  http://www.ros.org/doc/api/velodyne_common/html/msg/RawScan.html

About the smallest granularity possible for this device is a single
packet, containing 384 scans. There are 260 packets in a full
revolution at the default rate of 600 RPM. It would be fairly easy to
experiment with the device and see if we can keep up while publishing
a separate ROS message for each packet.

Each packet contains blocks of scans for either the upper or lower
laser bank. There are three times as many upper bank blocks. The data
are permuted in some strange order of lasers that presumably makes
sense to the device but seems quite arbitrary to consumers of the
data.

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

Not sure exactly what you mean by chunks and slices. Are these packets
and blocks at the device level?

As far as I know, the device does not provide any timing information.
Our driver estimates system time as the average of the time before the
read and after it returns (IIRC). Doing that on a per-packet basis is
probably the best we can do.

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

There are other velodyne users around, so continuing on the list for a
while seems OK to me. If we get into too much detail, we should take
it off-list. Doing an API review via the ROS wiki is a useful way of
collecting input from all those who are interested in a particular
topic.

For now, just send me patches. Depending on how much joint work we
want to do, we can create a more formal approach as work progresses.

Regards,
-- 
 joq



More information about the ros-users mailing list