Laser Range Finder for Arduino Robot or similar

Projects Discussion and Showcase Robotics
#1

Hi everyone,
Some time back I posted information about a laser range finder (LRF) designed specifically for the Arduino http://forum.arduino.cc/index.php?topic=110549 and more recently I added a sketch to communicate with another LRF http://forum.arduino.cc/index.php?topic=197835. This got me thinking about a new design for an Arduino LRF specifically to assist with robot navigation. With the recent release of the Arduino Robot, maybe a navigation LRF could be made compatible with this platform, but seeing how many other great Arduino based robots there are, a more universal design might be preferable.

The sort of LRF that might be useful for navigation would be one that could map an area the size of a large room from any point within the room. This would be a 2D map that identifies the principle walls and other significant objects. Navigation decisions could then be made within these defined boundaries like this: http://www.societyofrobots.com/images/sensors_IRSLAM.gif

Creating a 2D map would require that the LRF scan, preferably 360 degrees. I’m concerned that a motor/servo driven laser scanner would become quite expensive so it might be better to fix the LRF to the robot and “spin” the robot whenever the map has to be updated. Absolute angular orientation would be needed to complete the map so data from either wheel encoders or a magnetic compass could be used.

The LRF itself could be a stripped down version of the SF02 with a form factor that matches an Arduino shield. If the robot is for indoor use then the optical filter could be ommitted, further reducing the cost.

If you have any ideas or perhaps have been looking for this kind of laser range finder for your robotics project then please leave a note on this forum. If there’s enough interest then maybe I can get some sample units made. Perhaps I could press the company http://www.lightware.co.za/ into sponsoring a project or two but no promises just yet ;).

#2

I know that you and your company are kind-of "wedded" to your sensor package; from what I understand, it uses a time-of-flight (TOF) system of measurement (with all the attendant high-speed parts) to ultimately measure the distance.

This ends up meaning the sensor costs a fair amount of money - well in excess of most Arduino user's budgets. It likely is the lowest-cost 1D TOF sensor out there (though I don't know of any other similar sensor - most TOF and/or phase-modulation laser distance sensors seem to be of the 2D scanning variety - with extra complexity and a much greater cost - ie, a SICK sensor, for example).

If you could make your system small enough, such that it could be mounted on a hobby servo (even a larger one), it could be very useful and fairly quick to scan a 2D (or even 3D, with a pan/tilt system) area, without a great increase in cost (as the sensor currently stands, it is likely only suitable for a fairly large and somewhat expensive servo - though I don't know what the sensor's total mass is).

Low-cost 1D and 2D laser range finding sensors have always seem to be made using a triangulation parallax approach; that is - the laser forms a dot on the "object", and a linear array of some sort, focused properly, and a certain distance from the laser (forming the base of a triangle) - throw an ATAN in there and bam you have your distance measurement, more or less.

There's even a low-cost 2D version of such a sensor - found in every Neato robot vacuum cleaner; in fact, it's the cheapest way to get such a sensor (and you get a bunch of other robot parts with it, too!). Unfortunately, it works indoors only, and has a limited sensing distance, but for many indoor research purposes, neither of those are real obstacles. The company wrote a paper on the sensor (you can find it on the internet with a bit of digging), and stated that such sensors should only cost $25.00, and that they would offer them to hobbyists - but they never did.

For a while now, I've had an idea on how to build a limited FOV 2D distance sensor with no moving parts (again, parallax-based - the no-moving-part aspect would be the novelty); after taking the SBU class on laser cutting at my local TechShop, I've been thinking about making a prototype. In theory, the total cost should come under $25.00 in quantity (totally pulled out of my rear - I've haven't done the study on that part, simply because I haven't done a prototype or anything to even know if the idea would work - so it's not worth the bother yet - but I know that the retail costs of the parts is fairly low).

It would likely also be indoor only, and not have a lot of range - but again, still a useful sensor, and something that hobbyists might purchase. If or when I get a prototype made, I'll let you know...

#3

Thanks for the comments cr0sh, you've covered a lot of important ground.

The TOF element of the design is, surprisingly, not the primary cause of the high cost (we make the other types as well). In the hobby markets, it's the relatively low sales volumes that preclude the use of high volume manufacturing techniques and the associated price reductions. This is why LRF manufacturers tend to concentrate on different markets where they have either higher volumes or higher margins. But even though we're not yet at a price level that might interest the average Arduino user, you might be surprised at how many units we do sell to hobbyists and students who are doing serious research into robotic navigation.

With the recent release of the Arduino Robot, I feel that the Arduino community has made a significant step into an arena traditionally ruled by players who claim to have some magical "robot technology" edge, something that I don't agree with. I would go as far as to say that the disruptive innovation that comes out of the Arduino community is likely to lead to a major advance in robot technology, simply because the opportunity has suddenly arisen to experiment with a robot that talks the Arduino language.

Designing an LRF that can be used in support of this new robotics mission is going to be a tricky project. Taking your view of offering 2D or 3D scanning capability or alternatively limiting the design to a basic 1D measurement is a critical issue that affects the affordability and usefulness of the final system. The SF02 unit weighs 75g (2.7oz) and I would expect this new LRF (let's call it the AL02 - Arduino Laser Rev2) to weigh even less, so there is definitely an opportunity to create something that can be scanned easily using little additional hardware. Which leads to the next questions - what is the "best" scanning hardware for the job? Should the driver hardware and software for the scanning action be included as part of the LRF kit or sourced separately?

Thanks again for the feedback and good luck with your new laser design!

#4

That looks like a nice unit. Personally, for someone who really wanted an LRF, I don't think $250 is out of the question. The robot carrying it would likely cost in the same ball park price, or more, so I think the LRF is in the general price range for "that" market, although as imagined, I doubt that "that" market is very big either. However, 40m is a very nice range, and I doubt the Neato vac device comes anywhere close to that.

Despite the claims, I also can't imagine it really weighs only 75g. A ckt board that size already weighs in at about 50g, and those optical tubes don't look all that lightweight, so ??? However, if really that light in weight, almost any standard-sized servo panning device could handle it, so I don't think that's much of an issue.

#5

Thanks for the comments oric_dan. I agree that the robot market seems to be less price sensitive and I was hoping to get the price of a basic Arduino compatible LRF down to $200. The light weight of the unit comes about because we've tooled up for acrylic lenses (PMMA) and use glass fibre/pvc composites for the other optical components. Most of the optical section is empty space that allows the outgoing and return laser beams to be collimated and focussed.

In order to scan the unit we would need to design some kind of bracket that fits onto a servo. We could offer the design of this bracket as open source so that people could perhaps 3D print it themselves (if have they access to such equipment.) Alternatively, we could get laser cut aluminum brackets made but we would need to know what type of servo was going to be used.

#6

For just panning, I don't think you would need a fancy bracket. Most std servos have a circular horn and/or an X-shaped horn, so you just need a convenient way to catch 4 screws in a square-formation about 15-20 mm on a side, and you'd have a stable mount. Eg, 4 such holes for #4 screws placed at the central balance point of the LRF would probably suffice.

I'm not sure how standardized the hole patterns in servo horns are, but one possibility would be to include a plastic spacer board, drilled to match the LRF holes, and which could be drilled by the users to attach to their particular servo horns.

I also think if you try mounting your LRF on a std (44 oz-in) servo, you'll find it pans OK.

#7

I tried your idea oric_dan, and I gotta say it works better than I ever imagined. The test system is based on an Arduino Uno with the cheapest servo (analog) that I could find. I used a standard prototype shield to carry the connectors for the servo and the SF02. To display the results I used a 2.8" TFT shield plugged on top of the prototyping shield.

The TFT display uses most of the available pins on the Arduino so the distance reading from the SF02 was taken from the analog output which can be scaled in the menu system of the SF02 to equate to any desired range. This analog signal was read by A2 on the Arduino and software converted the servo position and range measurement into x and y coords (Cartesian) on the display.

The servo was set to give a reciprocating scan of ±45 degrees. In the image below these limits are shown as diagonal lines pointing to the origin of the display. The origin is on the right of the display so that the image is in the same orientation as the physical laser scan.

The picture shown is a scan taken at floor level through a doorway about 3m away and you can see right to the back of the room beyond. Of course these kinds of laser scans are standard on high end robots and they are used to develop navigation strategies. The interesting thing about this particular image is that the important navigation question (is there a clear pathway ahead?) can be easily answered even though the door is beyond the range of the typical sensors currently available on small robots.

The conclusion from this experiment is that it is not only possible, but relatively easy, to scan a laser like the SF02 using nothing but a cheap servo to produce images that are identical to those made by much more expensive equipment.

#8

Laser_Developer:
The conclusion from this experiment is that it is not only possible, but relatively easy, to scan a laser like the SF02 using nothing but a cheap servo to produce images that are identical to those made by much more expensive equipment.

Looks great...how long did it take to make a complete scan?

The thing about the 2D systems (especially the "big dollar" ones) are that they can pretty much output a continuous scan at a very high rate (10 Hz or more); even the Neato sensor can output a scan fairly quickly (though as mentioned, it is limited to indoor environments and has a limited range).

The need for the high speed scanning is mainly for when your robot platform is moving at fairly high rates of speed - mainly for things like autonomous vehicles (especially full-size automobiles pushing 60 mph or greater), where in between each scan you might move a considerable distance. Even with the expensive scanners, the rate might not be quick enough for an automobile.

Lower rates are ok for slower moving robots of course - floor and hall "crawler" research robots, along with other low-speed autonomous robots - but if you can speed up the scan, all the better.

One way (not sure how well this would work with your system) would be to mount a mirror onto the vertical shaft of the servo (or maybe a stepper or DC motor with an optical-slot feedback), and aim the sensor at that, so that the mirror does the scanning.

If you had a "free running" DC (or stepper) motor spinning the mirror, and a simple slot detector (zero-position detection - like old floppy drives used; potentially, their might be a way to use the sensor itself as the zero-position detector), you could govern the motor's speed (speed it up or slow it down) - so that it had a stable reference, plus you would also know (by timing) where the mirror was relative to your pinging.

Regardless - moving the mass of the mirror would have to be faster than moving the whole sensor (at the expense of greater complexity, thus higher implementation costs).

#9

Yeah, the whole thing looks very nice. With such as that geometry, the weight of the sensor is supported by the mechanical components of the servo, not held by the motor torque. The motor rotation torque required is quite low. Panning is easy, you get into lots more trouble with tilt, and off-center weight distribution.

SICK laser scanners do rapid “3D” [or whatever they call them] scans , but they’re also made for vehicles moving 50-60 Km/hr. Little robots hardly need that - most people just use Ping and Max sonars, and have to wait a long 20-40 msec for the echos to return. I’m sure the SF02 would be fine for 95% of robots in existence. For room-mapping, the robot doesn’t need to move very quickly, so there’s plenty of time for a wide-angle scan. For collision-detection while on the move, you mainly need a narrow-angle scan to detect objects in front. This should appeal to people doing robots for inside use who are otherwise considering SICK scanners or possibly a Kinect.

#10

Thanks for the comments cr0sh and oric_dan.

The issue of update rate is very interesting, especially in the context of small robots with limited processing power. It is technically feasible to provide range data at more than 20,000 points per second, but it would be impossible to digest that much data using a host processor like the Arduino. As you have both pointed out, there are probably two different sets of requirements, high speed for fast robots like self driving cars, and low speed for search or inspection type robots.

For the high speed applications, it doesn't make business sense to compete directly with companies like Sick in a specialized market where price is not the primary consideration. But these same companies are not servicing the lower price markets, perhaps because of their high manufacturing costs. In order to design a product that is suitable for this price sensitive market, it is absolutely critical to make sure that the performance of the product is directly aligned with the needs of that market and not to let "engineering ego" run away with really cool features and ever more extreme specifications that add cost but don't make the product any more effective.

The idea of using a spinning mirror in order to get faster scan rates may be an example of such specification creep because it makes the geometry of the system more complicated, reduces the accuracy and range of the laser and increases the cost of the system (tooling cost). At the same time, any benefit gained from the higher scan rate may be completely lost because of the additional time and processing power needed to analyze the results.

I noticed that in the test system the time it took to display the results on the TFT was enough to slow down the scan rate. It was taking about 3 seconds to do a complete refresh of the data. Theoretically, new navigation decisions could be made every time a new point was added so obstacle avoidance could probably be interleaved with the mapping process. This could be done whilst the robot was moving if there was a compass and wheel encoders providing absolute movement and bearing information to keep the data points correctly superimposed.

Once the data range data is available, the fun really begins...

#11