[ros-users] scan_to_cloud_filter_chain for high-bandwidth scanners

Stéphane Magnenat stephane.magnenat at mavt.ethz.ch
Fri Oct 29 13:06:12 UTC 2010


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

I guess that it might be possible on a fast PC, but it would probably be 
a waste of computational power given the amount of context switch. It 
might be better to use a single ROS message for several Velodyne 
packets, but with one timestamp per packet. This seems a minor change to 
the API and would retain the exact information of when a packet arrived, 
while still ensuring a low number of context switches.

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

Ok, so if I understand correctly there are not the same amount of data 
from the upper and the lower laser banks? Do you think that this might 
be different between your model of Velodyne and ours? At some point, I 
should probably have a look at the documentation of your model to 
understand better the differences.

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

Sorry I was not clear. By slices I meant a Velodyne UDP packet (slice 
was a bad naming). By chunk I meant data corresponding to a certain 
number of UDP packets, more than one but less than a full rotation.

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

Yes, I think that doing this per packet is fine, we just need not to 
loose this information afterwards.

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

Ok, so we continue the discussion there and then I can summarize the 
conclusions on the ROS wiki.

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

Ok.

Kind regards,

Stéphane

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



More information about the ros-users mailing list