[ros-users] scan_to_cloud_filter_chain for high-bandwidth scanners

[Vijay Pradeep]

Hi Stephane,

If I understand correctly, you have a higher bandwidth, higher precision
version of the PR2's ability to drive around while taking laser scans with
its tilting laser
scanner<http://www.willowgarage.com/sites/default/files/images/overview02.jpg>
.

For the PR2, we sometimes aggregate point clouds using
http://www.ros.org/wiki/laser_assembler.  This lets us aggregate data in a
fixed frame, like the *map* frame or *odom* frame.

Based on this thread, it sounds like you might be fragmenting the velodyne
scans into chunks that might not necessarily fit into the *
sensor_msgs/LaserScan* type, and it's quite possible that the service call
interface that we're using in the *laser_assembler* is not ideal for your
high bandwidth case.  But, nonetheless, I just thought I'd point you at the
code that performs the analogous aggregation operation for the PR2.

Vijay

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

> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Vijay Pradeep
Systems Engineer
Willow Garage, Inc.
 <tfoote at willowgarage.com>vpradeep at willowgarage.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101028/1115bd9f/attachment-0003.html>