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

Made driver for LMS151, what should I do next?

asked 2012-03-18 05:26:46 -0500

Dunes gravatar image

updated 2014-01-28 17:11:40 -0500

ngrennan gravatar image

I've written a driver for the SICK lms 151. I did so because when I first looked for a lms 1xx driver there didn't seem to be proper support for lms 151 (Later turns out that the only real difference is that lms 151 has a maximum range of 50m, and a radiator to keep the laser warm in cold conditions).

Initially I wanted to come here and ask for a code review I suppose and to ask what I should do to make the driver more generic so it could be useful to others. However, I then found this library did pretty much exactly what I wanted (I just had to change the maximum range in the config).

But then looking at this question, I found that people talking about bugs in the above driver that my driver almost certainly doesn't have (I can't be fully sure as I haven't properly tested it yet).

My question is: What should I do from here?

  1. Give up on my driver, and just use the other driver.
  2. Attempt to provide fixes to the other driver, and then use it.
  3. Continue developing my driver and make it available for others to use.

If (3), where should I go for advice on how to improve the driver for others to use. Additionally, one of my aims is to make much of the driver configurable from the command line eg. topic, publish rate, frame reference, etc...

General design of driver:

The driver was designed in mind that lms would be publishing lots of data, and that it be imperative that it not let the internal buffer of the socket or the internal buffer of the driver fill up completely. Further, users might wish to alter the publish rate of LaserScan messages to suit their needs.

The driver is threaded. One thread is continuously reading data from the socket, building up a representation of that data as an object and storing it a shared vector. The second thread reads from the shared vector and converts the data into a LaserScan message for publishing.

  • The time of the scan being published is based on when the scanner believes the scan took place, rather than when the driver finally got around to publishing it. Hopefully, this should allow for better interpolations between scans.

  • If the lms is scanning faster than the node is publishing, then the shared vector is periodically purged so that memory isn't lost to the ether or out-of-date scans published.

  • If not enough data is read from the socket to fully construct the intermediary storage object, then a partial object is built and more data is read.

  • If too much data is read, then this data is moved to the front of the buffer and saved for the next pass when the current message has been parsed.

Code can be found here:

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2012-03-18 11:56:27 -0500

Ryan gravatar image

I would support #2. #1 would mean that all of your work would have gone to waste, and #3 leads to fragmentation in drivers (ideally, there is one LMS1xx driver that everyone is using). We too have made improvements to the driver you've listed and intend on releasing them.

Ideally, if our work/your work/others' work can all get folded into the existing driver, fewer and fewer people will run into the same problems that you and us have.

edit flag offensive delete link more

answered 2012-03-19 03:58:15 -0500

Chad Rockey gravatar image

I'm glad people are working with these lasers. The SICK toolbox works well for the older lasers over serial connections, but we need to add another community package into laser_drivers for the 100, 500, and maybe even the TiM 300/500 series.

Since this will be a large effort, shortly after the Fuerte release, I'll post to ROS Users asking for a planning review for a common driver. Please bring your work and experience with these lasers to that review.

One concern I have is that your code is GPL based. It's much easier to work with a BSD base, especially for a driver, since it gives both us and our end users much less obligation if things need modified.

edit flag offensive delete link more

Question Tools



Asked: 2012-03-18 05:26:46 -0500

Seen: 1,008 times

Last updated: Mar 19 '12