Let's Make Robots!

I just received my OSLRF laser Range Finder!

So I received this awesome package in the mail yesterday from LightWare Optoelectronics in South Africa.

I had posted a link here on LMR last week to highlight this new product that had been developed for the Hobbyist / Open Source Community.     Open source laser rangefinder sensor. up to 9m $100USD

Open source laser rangefinder sensor. Including optics, laser, detector, amplifiers and sequential-equivalent-time-sampling (SETS) circuits, it is a 'bare-metal' front end component for a laser rangefinder system. Now available.

  • Range :: 0.5 ... 9 m
  • Resolution :: Adjustable
  • Update rate :: Adjustable: 3 ... 50 readings per second
  • Accuracy :: Adjustable
  • Power supply voltage :: 12 V (10 … 16 V)
  • Power supply current :: 50 mA
  • Outputs & interfaces :: Timing & laser signal outputs
  • Dimensions :: 27 x 56 x 65 mm
  • Weight :: 57 g
  • Mounting :: 4 x M3 (3.2 mm diameter)
  • Connections :: 0.1 in. pitch header
  • Optical aperture :: 53 mm
  • Laser power :: 14 W (peak), 6 mW (average), Class 1M
  • Operating temperature :: - 20°C ... + 60°C


The next morning after posting it, I was greeted by an email from the manufacturer, thanking me for the posting and offering me a trial.  I quickly accepted, on the promise that I would completely document my process/progress, and would share back anything I developed for it. 

I was quite pleasantly surprised to see a package from DHL within just a few business days (Coming from South Africa to Canada!) and here begins my journey into un-packaging, marvelling, reading... more reading,  whiteboarding, and developing a useful and cheap interface between this Laser Range Finder module, and our hobbyist Robots.


As the documentation describes, this is a bare bones Range finder, requiring a microcontroller to set up and process the ranging data.  Nothing we are not all familiar with on our various IR and UltraSound Range Finders.  There's just a little bit more to this one. 

LightWare Optoelectronics  employs Sequential Equivalent Time Sampling (a process developed by Tektronix to allow their oscilloscopes to work at higher frequencies) to represent a more manageable time scale for the Laser time of flight measurement. This allows us hobby roboticists to use our existing processors (Arduino or Atmel, PIC, Propeller, etc...) to interface and take measurements from it.

Directly from the manual:

The OSLRF-01 is a time-of-flight, “bare-metal” sensor that forms the front end of a laser rangefinder system. It runs autonomously
when power is applied and produces electrical signals that can be analysed to determine the time it takes for a laser pulse to travel
from the unit, to a surface and back again.

The OSLRF-01 solves the most critical engineering problems that designers face when making a time-of-flight laser rangefinder. These
1. The laser needs to be “fired” using a very short current pulse of tens of amps. The high speed driver components must be
shielded to prevent optical and electronic leakage which would otherwise interfere with the detector and mask the return signal.
2. The detector needs to pick up the very weak return signal and amplify it to a level well above any background noise. This
amplification is done using high speed amplifiers that are expensive and consume a lot of power.
3. The time between the outgoing laser pulse and the return signal needs to be measured with very high precision in order to
calculate the distance. Clocking speeds of 15GHz would be needed in a timer capable of 1cm resolution and this is impractical.
4. Collimating optics for the outgoing laser beam and collection optics for the return signal are needed to make the system work
over a reasonable range. These can be expensive components.

The OSLRF-01 consists of a laser, photodiode, optics, amplifiers and sequential-equivalent-timebase-sampling (SETS) circuits. These
components work together to create signals that are easy to analyse, having been amplified and slowed down to a manageable
speed. The output signals from the OSLRF-01 include the outgoing laser pulse, the return signal and various timing references.



I am currently laying out a daughter card based on my exisiting I2C Atmel ATtiny84 Ultrasound Scanner.  This daughter card will mount over the existing screw holes on the OSLRF01, will manage a pan servo, and provide 180 degrees of ranging data to your Robot or Autonomous Rover via I2C.

Future updates to this blog will document that process....

(Here is where you ask for features!)











Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Niiice.  This sort of sensor sure would make mapping and localization a lot easier especially since you can use ultrasonic sensors simultaneously for closer in.  I look forward to seeing your test results. 



The Setup as it sits now (photos later tonight) has the OSLRF for long range scanning for mapping purposes, the MaxSonars cover the infield for Proximity and Obstacle Avoidance. 

I've also changed up the inexpensive Pan/tilt brackets I had, for some heavier guage, to give me the warm and fuzzies that I'm not going to spin the Range Finder off into a wall somewhere.

I'm also making the deliberate compromise for the short term at least to only scan in 2 degree increments.  I feel this is enough resolution to pick up anything but a broom handle (or chair leg at 2 meters) but mapping should not be a stationary process anyway...

This compromise gives me the ability to scan my range of view in roughly a second.   When I'm comfortable with my software and mechanical build, the vendor has assured me that a few resistor changes will give me a faster scan rate.   Baby Steps.


AWESOME! Look forward to seeing  what you develop.  I am researching getting this device or the LIDAR Lite,  that I posted to forums last week,  as a future upgrade for Vader. 

Only two caveats to date:  From the documentation, it can only take 50 samples / second, where I was *hoping* to do a full 180 degree scan per second.  I'll be discussing options or limitations with the vendor on this.

The second caveat is that to work efficiently and accurately with this device, you need four to five pins from your microcontroller,  Two digital, two Analog, and a PWM, as well as associated cycle time to setup/capture/filter/map each ranging.  

This is why I am opting to build a separate daughterboard where I can allocate 100% of the MCU resources to panning/scanning/filtering amd exporting via I2C.