Go Down

Topic: Arduino Laser Range Finder (Read 70 times) previous topic - next topic


Very interested in this. Let me know how i can get my hands on one of these!


Very interested in this. Let me know how i can get my hands on one of these!

For further information about the Arduino Laser please contact Tracy at: info@lightware.co.za


I'm very interested in using this for my master's thesis - your site says that the AL_01 is in production. How long after ordering would it take to get one of these to the southeast united states?




The optical components have arrived at last!

The lenses are 25mm diameter on both the laser and receiver. In the case of the laser, the purpose of the lens is to collimate the outgoing flash of laser light. This is necessary because, unfortunately, the light that comes from a semiconductor laser doesn't have a nice parallel beam. Instead, it comes out in a distorted cone shape that needs to be made parallel in order for the laser light to travel as far as possible without getting spread out and becoming too faint. This collimation process is often done with very fancy optics in order to get the maximum theoretical range. In this design however, a single lens element should be enough to get the laser beyond the 25m range specified for the design. The diameter of the laser beam will be the same as the laser lens (25mm) as you can see from the picture below.

The laser beam projected onto a Phosphor card

The lens in front of the receiver serves a different purpose. It acts as a light gathering area that focuses the rather weak return signals from the target onto the APD detector. The bigger this light gathering area is, the greater the distance that the range finder will be able to measure. This makes it very easy to increase the range - just use a bigger lens. For the purposes of this design, the 625 mm2 of the receiver lens should give us the desired range.

Optics - front view

From the picture above you can see that the optical arrangement is very sturdy. This is necessary to ensure that the alignment of the lenses stays absolutely fixed. If this alignment changes then the laser will end up pointing in one direction whilst the receiver points in another - and that means no return signal!

To get the laser and the receiver lined up correctly in the first place there is an alignment and focus mechanism for both the laser and the receiver circuit boards (see below). These mechanisms have three degrees of freedom (the ability to be adjusted independently in three orthogonal axes, X, Y and Z). By adjusting the position of the laser and receiver whilst watching the strength of the return signal on an oscilloscope, it is quite easy to achieve almost perfect optical alignment.

Optics - rear view


Oct 24, 2012, 01:52 am Last Edit: Oct 24, 2012, 02:35 am by odalvo Reason: 1
Hi it is good and you should sale a kit!  :)
How accurate it is in  closer range 10 cm to 2M? What is the power consummation?


Oct 30, 2012, 03:10 am Last Edit: Oct 30, 2012, 03:19 am by LoganPark Reason: 1
We've been hacking around with two AL_01 kits for a few weeks now in my research group and have enjoyed them immensely.  I wrote a short post on our early experiences here: research group blog

The rangefinding works quite well enough for our purposes, esp. once we configured averaging = off by default in the EEPROM.  We're using one of the kits to scan for movement at high relative speeds (30-50mph), so we learn more about the passing object from non-averaged data.  Good times are experienced with 20+ Hz sampling rate.

We have, however, hit the memory ceiling for the UNO board (32k) and want to switch to a Mega 2560 for the extra headroom (256k), but the SPI pin mapping is different (Mega = 50-53 vs. UNO = AL_01 = 10-13).  Is there a way to change the pins the laser board is looking for?  This isn't a design problem with the AL_01 kit at all, it is primarily an Arduino programming question, so, OK to punt if you need to.

So far we have found in constants.h from the AL_01 Arduino sketch files:

Code: [Select]
// SPI Hardware
#define SPI_CHIPSELECT_PIN        10
#define DATA_READYN_PIN           9

I should note that our setup is Mega2560 --> Wireless SD shield (for datalogging) --> AL_01 board all snugly stacked on the header pins.  

I also want to note that Tracy has been OUTSTANDING on support over email over the past month.  I thought other folks on the fence about buying these AL_01 kits should know that.  It is rare to get decent support these days but Lightware has really treated us well.  I have no commercial connection to them so I can say that without bias.  :)


You may find a pretty good market for these LRFs in the small UAVs to be used for landing aids some of the smaller UAVs land by a controlled crash method as they do not have a reliable idea of how high above the landing surface they are.  A controlled crash from 5 feet is much preferable to one from 50 feet.


Laser I love your work on this, I agree the $100 bar needs to be met, Im looking working on a >5m system with 1K+ readings /s .
Im using the osram spl pl90 905nm , a very clean avalanche transistor ,solder flux leaks enough to self trigger at well below the 100V normal .
The cost saving is all in the detector and the optics, im trying a few non-avalanche pin diodes with ultra low noise high bandwidth fet op amps, sot23-5. again, they have to be clean. I stripped a UT391LASER DISTANCE METER, the optics have factory adjustments and are good to 50m ,without diodes, in low volume it could be 3D printed at ? $5 would be ok. lenses, plastic $1.  Time to digital, i might go for the acam 65ps uk one off GBP 9.50 I cant believe how cheap the hard bit is. pcb with screened cans $10, Total BOM cost ? $80
Range would be limited but as a cheap part of a larger system it can deliver 1000 ranges / second . At 1m/s thats 1 range / mm.

Micromouse can do 3m/s = 1range /3mm , the maze is 160mm apature square on, 50+ hits if perfectly square but if turning you may only see the longest passage for 1ms.


@Laser_Developer i am totally new to this laser range finder thing and am highly motivated by your post. i wanted to know how did you selected laser and that optical assembly, i mean on what parameters. thank you :)


These laser range finders I can get at home depot and such like,
   50 to 100 dollars,

battery powered, seem to have more than required resolution and range,
    "just" need an arduino interface...

just a thought ,


I'm confused about some things.  I hope I don't sound like a jerk, but I want to dissect some things.  So critical analysis to follow.

Apparently this rangefinder is meant to work using time of flight, and I don't understand how that's possible.  It takes light about 1ns (10^-9) to travel a single foot.  That means in order to have 1-foot accuracy you need to have a counter that is at least 1GHz.  Am I wrong? 

I looked up the data sheet for the DS00VQ100 chip and it's only 12.8MHz.  Also, according to the data sheet, minimum span is 156.25ns or 23.44 meters.  The data sheet is not very well put together though, so it's confusing what this means.  I can't tell whether they mean to say this is the minimum span, meaning it can measure anything over 23m, or whether that's the accuracy period at any distance.

Question: How are you getting centimeter accuracy at less than 1m range?  According to the IC from the manufacturer, unless I'm reading this wrong, their chip isn't even physically capable of this. Moreover, this isn't just a range problem, but an accuracy problem. 

Let's do some easy math.  As I said previously, based on speed of light, you need a 1GHz counter in order to get single-foot accuracy using time of flight.  Am I wrong?  I know there are mathematical methods for figuring out the distance using slower counters, by doing phase shift, etc., but we're talking only about time of flight.

If the counter is 12.8MHz that is 12.8 * 10^6 cycles per second.  1 / (12.8*10^6) = 7.81 x 10^-7, which means approximately 78ns maximum accuracy.  78 nanoseconds is the smallest period of time that the chip is capable of measuring, and that's assuming an increment with each clock cycle. Each cycle of the clock will take 78 nanoseconds.  Now remember what I pointed out previously, according to the data sheet the minimum span is 156.25ns.  Does that number now seem familiar?  It should, 7.81 x 10^-7 x 2 = 1.5625 x 10^-7.  So, the obvious implication is that even though the IC clocks at 12.8MHz, it needs two clock cycles in order to count.  Two cycles equals one counter increment.

So what this means is that if the light takes 2 nanoseconds to travel, the counter will register 156.  Anything less than 156 will register 156.  If the light takes 170 nanoseconds, the counter will register 312.  So in other words, the measurements will always be plus or minus 156 feet.  We can divide that by 2 since we know the light travels the distance twice.  So 78ft accuracy!!!  Doesn't matter if you're measuring something 1 meter away or 1000 meters away, your result will always be + or - 78ft. 

And what does 78.1 feet equal?  It's about 23.44 meters, which was the figure also given in the data sheet.  Suddenly this picture is coming together.

78 foot accuracy seems rather useless to me.  What baffles me though is how you're claiming to be getting centimeter accuracy and at distances far lower than 23m.  The only way I can see for this to be possible is if the IC is performing a mathematical operation, doing a multi-frequency phase shift or something else along these lines.  Does the IC control the laser frequency?  If so then it would be possible to do something like this.  I am under the impression though that the IC simply counts, nothing more, and you manage all the laser circuitry yourself.

Is there something I'm missing? 


A real great piece of investigation there,

well done


I looked up the data sheet for the DS00VQ100 chip and it's only 12.8MHz

I looked at the schematic for my phone - the highest frequency section is probably the 5GHz WiFi, yet the clock for that is derived from a 48MHz crystal.
(If it didn't have the 5GHz band option, then the 2.4GHz band would be clocked from the same 19.2MHz crystal that provides the system clock for the 1.7GHz processor)
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.


I looked at the schematic for my phone - the highest frequency section is probably the 5GHz WiFi, yet the clock for that is derived from a 48MHz crystal.
(If it didn't have the 5GHz band option, then the 2.4GHz band would be clocked from the same 19.2MHz crystal that provides the system clock for the 1.7GHz processor)

This is different, that's just a carrier signal.  Generating a high frequency signal isn't the issue.  Computer processors use clock multipliers to multiply a reference bus frequency, which itself is achieved by multiplying some base reference crystal.  The limitation however is the reset time on all the registers.  It takes a certain amount of time for all the registers to flip to 0 or 1.  If too high a frequency is fed in, registers will start to flip before the previous state had a chance to settle, and then it all goes to heck.  Radio circuitry does the same thing.  Analog circuits can be used to multiply a base frequency.  A 16 MHz crystal is typically used for 2.4 GHz radio applications, with a multiplier of around 150.  And just like with registers on a processor though, there is a bandwidth limitation, and this is the processing speed.  Notice that data transfer is not any faster at 5 GHz wifi than 2.4 GHz wifi?  If it was just about the frequency of the carrier signal you'd expect things to be twice as fast, but they aren't.  The radio signal is just a carrier wave.  That wave then has to be encoded, which can be done with a variety of techniques.  Technically-speaking, a higher frequency should result in higher data throughput for a given encoding technique.  But only if your eyes are fast enough to observe it.  Notice that wifi operates in the millions of bits per second whereas the carrier frequency is in the billions of cycles/sec.  That's because we can't decode things any faster than this, at least not yet.   

In the case of the laser rangefinder the same principle applies.  We're talking about counting time, like a stopwatch.  At the precise moment the laser pulse is transmitted we start the timer.  At the precise moment it comes back we stop the timer.  Subtract the two, we have travel time.  Because light is so fast we have to be able to count sub-nanosecond intervals.  It's physically impossible with a 12.8 MHz clock.

And again, this is assuming things are being done using "time of flight," which means the time is directly measured, and this is what the author said earlier.  Other methods also exist for determining time of flight without actually measuring it, such as phase shift.  If you send a beam of light out and then measure the reflected light that comes back there will be a phase shift between the two.  You compare the beam that's coming in with the beam that's currently going out.  It's a continuous sinusoid.  Think of it like a really long snake.  By comparing the front end with the rear and knowing how long the snake is, you can determine the distance.  The phase shift provides this same data by utilizing multiple frequencies and solving simultaneous equations. 

I'm not saying this range finder doesn't work, I'm just asking questions.  How does it work?  TOF doesn't jive.


This is different, that's just a carrier signal.

What, the bit about the 1.7GHz processor clock?
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Go Up