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 . 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 > 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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Vijay Pradeep Systems Engineer Willow Garage, Inc. vpradeep@willowgarage.com