ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Building a 3d pointcloud from rotating 2d lidar with a SICK LMS 291/s14 and high resolution optical encoder

asked 2013-05-06 06:47:54 -0600

jimbo gravatar image

updated 2013-05-30 17:50:13 -0600

Greetings, ROS is fabulous and thanks to all contributors! I was wondering if anyone had experience rotating a 2d laser to produce 3d pointcloud and how to advertise/visualize using ROS? - Secured a SICK LMS 291 S14.
- Built a rotating platform with high resolution optical encoder (Heidenhain ERN420) I have both the SICK laser and the PhidgetEncoder talking with ROS. - I have a 5 pole slipring rated to high rpm - I would like to construct a point cloud from this next, and not reinvent the pointcloud wheel, hopefully re-using as much c/c++ code from ros as possible...

  • I had a look at player/stage LaserPTZCloud driver and I was going to write something similar, but before I dive into this wanted some expertise..

  • I was trying to build something similar to the following, but I cannot post links because of karma points

Any thoughts or suggestions of how to proceed or if someone has done this before and can provide specific code examples would be appreciated...

-05/15/2013 Edit: After running the tutorial for laser_scan_assembler and periodic_snapshotter I have learned a great deal. My question would be how was the tilt_scan topic built? All that is mentioned is

"The tilt_scan topic was recorded from a planar laser mounted on a tilting stage. The /tf topic contains the robot transforms."

Is there a code example of how this was built?

Update 05/30/2013 Finally figured it out, and yes I needed to learn tf very well to do this. If you have questions learn TF! Thanks for pointing me in the right direction!!

Few other stumbling blocks that I had along the way. I had a SIIG SII206M. SIIG Inc. USB to RS-422/485 Converter, but did not get 500kb baud (only got 38K), I even wrote my own driver, and achieved 230kb, then I bought a USB-COMi-M and it works perfectly with the sicktoolbox-wrapper provided.
You may also want to check out, as it is cheaper, I went with one I knew some papers had documentation on.

I had to re-write the encoder phidgets package, as they have updated their library, I used their high-speed encoder but there was some #ifdef's that didn't apply anymore... also the high_speed_encoder had to init() the encoders before using them otherwise didn't work..

I also wrote my own periodic_snapshotter2 based off the original, just modified for pointcloud2 data, figured it may be more useful in the future.

For anyone else that needs help or is trying to do something similar, the nootrix image is an excellent way to get started developing on ubuntu, then I recommend creating your own package to customize/copy/re-use source code for your own robot.

This was a very cool and interesting challenge, I am now able to generate pointclouds that consist of 78398 points every 4 seconds, published into rviz. The unit itself turns 360 ... (more)

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2013-05-06 07:19:07 -0600

This is done for the PR2 tilt laser scan using the laser_assembler. The HowToAssembleLaserScans tutorial should have everything you need to know to get started.

edit flag offensive delete link more

answered 2013-05-06 07:19:23 -0600

Gav gravatar image

Hi Jimbo,

You don't necessarily need to make a pointcloud, although there's nothing stopping you. I made this a while ago: Although I haven't posted the code, sorry, and I'm in Germany at the moment for ICRA.

All the arduino code does is publish a transform between /base_link and /laser that gives the current rotation of the laser. There's also a bit of code to accept requests to start or stop nodding the laser, but that's optoinal. Once the TFs are being published RVIZ can then display the scan immediately with no further configuration.

One snag I noticed is that although AMCL does read the TF between odom and laser, it only does it once on startup, hence it's not suitable for nodding lasers. Transforming to a pointcloud referenced to /base_link would be a good way around that, though.

Cheers, Gavin

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2013-05-06 06:47:54 -0600

Seen: 2,912 times

Last updated: May 30 '13