Joe Grand's Laser Range Finder: A Development Diary

[Joe Grand]

Hi all-

I originally mentioned that I was designing a low-cost Laser Range Finder (LRF) for Parallax back in their 2009 catalog. The project has been moving along sporadically in a vacuum since then and I thought it would be fun (and hopefully informative) to use this Forum thread as a way to keep folks updated with my progress and to solicit any comments along the way.

There’s a danger of publicly documenting an in-progress design, since lack of consistent updates will cause people to think the project has been abandoned. Not true in this case - I’m working on this design in parallel with some other projects. Sometimes I’ll have more time to focus and, hence, make strides quickly, and other times I’ll be working on other things or waiting for parts/materials to arrive. I’ll try and post when I have something useful to share or run into some development problem.


Initial attempts

Most of the past year has been spent researching and evaluating various range-finding methods and trying to settle on a design direction that is suitable for a low-cost/hobbyist environment.

My original plan way back at the beginning was to use the time-of-flight method (http://en.wikipedia.org/wiki/Time-of-flight and http://www.repairfaq.org/sam/laserlia.htm#liarfbl) to measure the travel time from laser light leaving the laser and being received by the detector. I built a high-speed time-to-digital converter using the ACAM GP2 (http://www.acam-usa.com/GP2.html) and a Parallax SX, and had a Data Delay Devices 3D3608 programmable pulse generator (http://www.datadelay.com/asp/oscpg.asp) generating pulses in a range of 14ns to 1.3uS that was to be used to trigger the laser driver circuitry.

Here’s a short video I made for Ken Gracey/Parallax in mid-2009 just to demonstrate the subsystems: http://www.youtube.com/watch?v=BlQhr8Jtl_A

I had also considered phase-shift measurements, which compares the phase shift between the outgoing modulated laser and its reflected light.

The high speed circuitry required for both systems is non-trivial and too much in the analog domain for me (I’m primarily a embedded/digital engineer), so I scrapped this approach. Both designs would also need specialized optics and the circuitry would be too finely tuned and precise for any user-based modifications/hacks.


Optical triangulation

I decided to go with the method of optical triangulation whereas the distance to a targeted object is calculated using triangulation with simple trigonometry between the centroid of laser light, camera, and object. The most compelling example is the Webcam Based DIY Laser Rangefinder (http://sites.google.com/site/todddan...m_laser_ranger) and my design is based, in theory, on this implementation.

Optical triangulation for range finding has been discussed previously elsewhere on the Parallax forums, but nothing’s out there as far as a fully developed, compact, easy-to-use module:

• Phil Pilgrim using a TSL1401-DB linescan imaging sensor (June 2009)
• Discussion of time-of-flight and explanation of triangulation (~November 2006)

My first foray using this technique was using a Position Sensitive Detector as described by Roger Johnson and Chris Lentz's 2-D Optical Position Sensor article (Circuit Cellar #152, March 2003). A PSD gives excellent resolution and accuracy (0.0001” and 0.001”, respectively), but only for a limited detection range as the sensor is designed for sensing light shined directly onto its face, not capturing reflected light.

This approach ultimately turned into the Laser Position Sensor module (Parallax part #NFS001) that we recently released as open-source with no plans to manufacture due to cost of the PSD sensor (~$30 in volume) and expected low-volume sales.

My finalized design direction is to use a Propeller as the core, an Omnivision OVM7690 640x480 CMOS camera module (http://www.ovt.com/products/sensor.php?id=45), and a laser diode. The OVM7690 is a really nice, compact device with fixed focus, integrated lens. The LRF module will be open source to the extent possible. Omnivision requires an NDA in order to obtain data sheets and communication information, so we'll need to work with them further to figure out what we can publicly release.

I particularly like this approach, as the design combines a few separate subsystems that could ultimately end up being used as separate pieces - the CMOS camera system and laser driver system. I also hope that by using a Propeller, folks will take advantage of hacking/modifying the module for more vision/camera/imaging applications above and beyond the basic laser range finding functionality.

To me, simplicity for the user is key. Like previous modules I’ve designed for Parallax (Emic Text-to-Speech, RFID Reader and Read/Write, GPS Receiver), the LRF will have a simple serial communications interface for sending and receiving commands. Most likely it will be a 4-pin device: VCC (5V), SIN, SOUT, and GND.

In May 2009, early in my experimentation with optical triangulation, I made a video for Ken/Parallax to demonstrate a prototype using a CMUcam2 and a Freescale QG8. It worked surprisingly well given the low CMUcam2 resolution (176x255) and I could get 1/4 inch accuracy and distance range from 7 inches to 40 inches: http://www.youtube.com/watch?v=-h5ctq7dE9k



I think range and accuracy will dramatically improve using 640x480 resolution and further experimentation will be necessary to determine the ideal width of the module (distance between the laser diode and the camera), which will be an engineering trade-off of size v. measurement range. Possibly the camera and laser diode subsystems could be on a single module, but scored to make it easy for hackers/customers who want a different configuration or larger width to do so by snapping the board in half and re-calibrating.


Work to date

Since the video of the CMUcam2 and Freescale QG8 was made, I’ve successfully put together a version using the CMUcam2 and Propeller:



I’ve ported the triangulation math from the QG8 to the Propeller, so I can calculate the range to an object given pixel count from the center of the laser dot to the center of the camera module (which the CMUcam2 returns from its color tracking function call). For what it’s worth, I’ll be releasing the code and hastily-drawn schematic for this version once I make some more progress and have some time to go back and clean things up.

The prototypes using the CMUcam2 proved that I’m on the right path with optical triangulation, but I needed to continue development using the actual OVM7690 camera. Instead of relying on the high-level image processing that the CMUcam2 provides, I’ll need to create the color tracking routines directly on the Propeller. So, I built a hardware development “platform” using a Propeller Proto Board, OVM7690, and custom PCB holding the associated control/interface circuitry:



Last week, I finished up the camera communications interface, so I can now send commands to and configure the OVM7690.


Next steps

I feel like I've made some very good progress so far.

Up next is to finish the start-up/initialization routines for the camera, complete my evaluation of suitable laser diode/driver circuitry, and try to capture some data.

I also plan on diving into Hanno Sander’s DanceBot vision tracking code (http://www.circuitcellar.com/archive...der/index.html and in Chapter 7 of the Programming and Customizing the Multicore Propeller Microcontroller book, Parallax part #32316).

Hanno’s ViewPort application (http://hannoware.com/viewport/) supports the OpenCV library for computer vision, which should give me a nice head-start on dealing with the actual color tracking of the laser dot (once I can successfully capture a video frame from the OVM7690).

Whew - that was a really long post! If you’ve read this far, let me know if you have any initial thoughts and if you enjoy the idea of my posting of development progress to the Forums!

Take care,

Joe

[John R.]

Joe;

It's great to see the post on the laser rangefinder. I think you'll find folks here love hearing about stuff like this, and for the most part understand the on/off, slow/fast cycles of development, and are usually pretty patient. If someone is really curious and there have been no updates for a while, you might see a Bugs Bunny post (What's up Doc?).

The explanation of what you've looked at, and what works/doesn't work and why was great! We look forward to hearing more from you.

John R.

[Joe Grand]

The explanation of what you've looked at, and what works/doesn't work and why was great! We look forward to hearing more from you.

John R.

Great! I'm looking forward to sharing more as I make progress!

Joe

[Joe Grand]

I’ve completed the OVM7690 camera initialization and configuration routines and the camera is now set up for maximum 640x480 resolution with a YUV422 output, among other things.

Though time consuming and somewhat tedious, it wasn’t particularly difficult. I ported the recommended start-up settings from a file provided with Omnivision’s PC-based evaluation tool (that communicates to an Omnivision camera module over a USB interface) and reverse engineered a few additional settings (for example, reduced frame rate and disabling automatic white balance, which will come in handy for my initial attempts at capturing data and red laser spot detection, respectively) by watching the bus between the camera and host while selecting specific settings from within the PC tool. I then commented as many of the register settings as possible within my code to let me easily scroll through and identify what values do what.

All told, there were ninety-eight (98!) 8-bit registers that needed to be configured to get the OVM7690 module up and running, including, but not limited to, general settings, output format selection, resolution, video output speed/frames per second, lens correction values, color matrix values, edge and de-noise settings, Automatic Error Control (AEC), Automatic Gain Control (AGC), Automatic White Balance (AWB), gamma values, and flicker control.

I can monitor the digital video lines (8 bits), HREF (Horizontal reference), VSYNC (Vertical sync), and PCLK (Pixel clock) outputs from the OVM7690 on my scope, so the next step is to capture a video frame with the Propeller!

Joe

[Bill Chennault]

Joe--

Well, this is way cool! I will watch you progress.

--Bill

[Tubular]

Awesome, Joe.

I use some industrial sensors based on the triangulation technique. Ideally I would like them to be faster (they quote 2ms to 10ms), and to better understand the small error that occurs as the beam lands on different colours

[Joe Grand]

I use some industrial sensors based on the triangulation technique. Ideally I would like them to be faster (they quote 2ms to 10ms), and to better understand the small error that occurs as the beam lands on different colours

It's very likely that my system will be slower, as the CMOS camera frame rate is 30fps (at maximum) and I'll need to do some basic vision processing once the image (or portion thereof) is in hand. So, it will probably be ~30Hz/33ms per measurement. This may preclude use of the module for high-speed applications - I think the sensor will find the most usefulness in indoor robotics navigation/object detection, but also hope the module will be used/hacked/modified for other scenarios that I haven't thought of.

As for small errors with different colors/objects, that will be interesting to experiment once the basic system is completed. Since I'll be looking for the brightest/most saturated red spot within a portion of the frame (some distance above and below the horizontal center), even against different colors, a red laser should still appear more red than other things in the field-of-view. I think I'll run into some limitations, however, like being in an outdoor environment, bright ambient light/sunshine, or if there's a reflection from another light source on an object that my system accidentally thinks is the laser spot. There are tricks we can do to help limit erroneous data, but the challenge will be doing so with the memory constraints within the Propeller.

Joe

[Phil Pilgrim (PhiPi)]

The positional resolution of the spot detection can be improved by finding the brightest red spot, then performing an average of it's X-coordinate and the X-coordinates of the pixels surrounding it, weighted by their intensity. Using this technique, you should be able to obtain sub-pixel resolution. As a simple example, suppose two adjacent red pixels have nearly the same intensity. The averaging technique would yield a final position between the two, rather than picking one position over the other just because it was a little brighter.

Also, if you scan twice -- once with the laser on, and once with it off -- you'll be able to subtract the ambient light for an even more accurate reading.

-Phil

[Joe Grand]

The positional resolution of the spot detection can be improved by finding the brightest red spot, then performing an average of it's X-coordinate and the X-coordinates of the pixels surrounding it, weighted by their intensity. Using this technique, you should be able to obtain sub-pixel resolution. As a simple example, suppose two adjacent red pixels have nearly the same intensity. The averaging technique would yield a final position between the two, rather than picking one position over the other just because it was a little brighter.

Agreed. That will help to give me the true centroid of the laser spot.

Also, if you scan twice -- once with the laser on, and once with it off -- you'll be able to subtract the ambient light for an even more accurate reading.

Good idea, but not sure if I'll have the memory to do so? I'm thinking of reducing the camera resolution to 320x240 (which will give me an increased 60fps as a bonus) and, if I limit the "window" of the video frame to the section I'm only interested in (some amount of pixels above and below the horizontal center), that might work. I'm trying to fit the frame buffer into the Propeller's main RAM (32KB) while still retaining a full 8-bits per pixel. I'm working on the calculations now to see what I can pull off. Maybe I could calculate things on-the-fly instead of storing into a large buffer, but having support for a buffer will be helpful to people who want to use the module for non-range-finding functionality and take more advantage of the camera's capabilities.

Joe

[Phil Pilgrim (PhiPi)]

Joe,

Since you're only interested in the X-position of the spot, you might be able to get by with summing intensities along the Y-axis, either over the entire image, or in broad, overlapping horizontal stripes. This will necessitate the ambient subtraction, though, since a cluster of semi-bright ambient pixels will sum to as much as one bright laser pixel.

Another tactic would be, for each X-position, just keep track of the value of the brightest red pixel, or n brightest red pixels, over all the Y's.

-Phil

[vanmunch]

Sounds exciting. I'll be especially interested in seeing the code for interfacing with the camera (as well as the rest of the project). Good luck!

[Don M]

Joe,

Was curious as to the make and model of your scope in the background?

[Joe Grand]

Was curious as to the make and model of your scope in the background?

That is the love of my life - an Agilent DSO7054A 500MHz DSO.

Joe

[Roy Eltham]

Joe,

You could do the two pass difference "in place" so that it only requires one frame sized buffer.

[Joe Grand]

You could do the two pass difference "in place" so that it only requires one frame sized buffer.

Great idea

I'm struggling with frame buffer size v. available RAM right now and am writing up a piece for my next "diary" post. With 640 pixels across @ 16-bits per pixel (YUV422 format. which I'm assuming is better than RGB format for the laser detection over a wider variety of lighting conditions) and assuming I want to use hub RAM (maximum 32K, but really only about 24KB available right now), that means:

640 * 16 = 10240 bits/line = 320 words/line
24KB = 6144 words
6144 words / 320 = 19.2 lines

So, I'd basically have a thin band around the X axis, +/- 10 lines. This might be OK for the red spot/blob detection, since I'm only really concerned with the X axis since that's where my camera and laser diode are located. Any red spot far away from Y = 0 probably isn't the laser, anyway.

Joe

[Possum79]

Definitely keeping an eye on this thread. Its great to see updates. I love everything you do Joe! I miss prototype this!

[cwhittenburg]

Hi Joe,

Are you getting images from your ov7690 yet? I noticed from your photo that you may have been having problems with IR light leaking into the back of the sensor and tried to mask it off the pcb with tape or something? We had a problem like that. Anyway, we built a project with the 7690 recently and haven't gotten very good images-- the edges seem out of focus, and there is a lot of blooming around any sort of light source.

Hopefully it is just settings, because as you said, there are many of them.

regards,
chris

[Joe Grand]

Hi Chris-

I'm still working on getting images with the OVM7690 and Propeller, but I've been using the camera evaluation board and Omnivision's OVTATool for quite some time. The images look good enough to me - I'm not a video/image processing person by any means, but the image will certainly serve my purpose.

The electrical tape wrapped around the module was to block all light (not just IR) from entering the back of the sensor. Typically, these modules are meant to exist in a closed (e.g., dark) housing where light will only enter from the front. However, since I'm operating the module in a free (not closed) environment, light is entering from behind and illuminating some of the BGA pads and traces. I can see them on my sample pictures taken with the OVTATool and the electrical tape significantly reduces the problem, though I certainly won't be wrapping any production design in electrical tape!

Omnivision suggested that a PCB with black soldermask might also help. To me, this is a minor problem, as even having such "interference" on the image won't prevent me from proper red spot detection and range calculations. I'll have more details once I move away from Omnivision's evaluation and onto my first revision of prototype circuitry.

Take care,

Joe

[Phil Pilgrim (PhiPi)]

Joe,

I usually put a copper pour behind image sensor chips to completely block light from the backside. It can be a bit inconvenient, though, if it messes with the signal routing.

-Phil

[Joe Grand]

Great idea. I'll do that for sure!

Joe