Dunes's profile - activity

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: https://github.com/jxh576/tracked-robot