2D Laser Range Finder

Ever since I read Ken Maxon's article: 'A Real-time Laser Range Finding Vision System', I've wanted to experiment with a similar system. This past Sunday afternoon, I finally got around to it. I don't have any CLPD chops, so I used a regular computer. Above you can see my initial rough results. The line laser registers lower in the image field for the block than for the background. The software properly converted that lower registration to a distance of about 26.5 inches.

The idea behind the concept is fairly straight forward. By angling and elevating the camera relative to the laser we can establish a trigonometric relationship between the vertical location of the laser and the distance to the object that the laser is striking. Since the laser is a line on the screen, each pixel column in the image field becomes it's own independent laser range finder.

In the picture above four possible angles are shown to demonstrate that each angle corresponds to a different obstruction distance.

Each possible height in the image field corresponds to a specific angle of light into the camera's roughly conical field of view. The line from the laser's point of impact to the camera, the vertical line from the camera to the laser generator and the horizontal laser line itself form a right triangle that allows us to compute distance. By dividing the angular field of vision by the number of rows in the the camera we come up with a formula to compute the angle of entry for the reflected laser light for each of the rows in the camera. We also know the distance from the camera to the laser generator. (Its fixed). Plugging the angle and the vertical distance in the trigonometry equation: tangent of theta equals the opposite leg length divided by the adjacent leg length, and re-arranging, we compute the opposite leg length and determine how far away the object is.

You can see my software doing just that in the first picture. The software doesn't compensate for the fact that the horizontal pixels are each their own angle as well, but in this first rough pass I felt it wasn't necessary. You'll note the the software makes no attempt to measure the left/right distances.

With a sub 5mW power level and a popular frequency (red), something like is probably restricted to a small indoor bot with somewhat short range needs. Still in complement to other scanning systems like a spinning ultra sonic range finder, I can see this adding mechanism to the reliability of local environment mapping system. If I ever build my home security patrol bot, I'll definitely think about this technique.

Below you can see the rig I used to test this idea out. It's pretty basic but it got the job done. To the left you see the paper back drop and the paper obstruction. To the right you can see the line laser generator sitting at the bottom of the dremel drill press with the webcam perched on top.

Hexamon

So today I discovered two things: I have a transistor in backwards on Uno-version-Dos' drive board and I am out of de-soldering braid. :(

Nevertheless, as the wife was tied up all afternoon today, I was determined to work on robots. I stopped by Trossen Robotics and caught some of the footage of the Mech Warfare event they held at the 2009 RoboGames. Boy, it was really neat. I also caught a note from Alex that indicated they were creating a hexapod league.

It occurred to me that hexapod gaits were simple enough that it might well be a good project for me to get some custom Dynamixel gait code up and running. From there I could branch off and do more complex tasks. Custom gait code is something "I've Been Meaning to Do."(TM).

So, I spent all afternoon assembling the frame below from my Bioloid kits.


Its always shocking to me just how long it takes to do mechanical things. Looking at that pic, I think it should have taken no more than a hour, but it was actually more like four or five hours. Nevertheless, it was a fun afternoon and my head filled with delusions of grandeur as I built it.

I rather like my name too. Its from Eon. I figure I'll wind up letting this bot will ride on a whole line of design flaws, so it seems appropriate.

Uno Sensor Board Update

I worked on my sensor board again tonight. I got the sensor portion, as opposed to the led driver portion, working. I had to do a bit more board repair. Apparently, when I swapped the incorrectly routed op-amp outputs and power lines, I damaged a via and disconnected the forward looking opamp from the MCU. I wound up drilling out a couple vias to fix it.

Once I had it going I tried to run a simple test program to show which of the four sensors saw the greatest amount of light. For the test I just used a loose IR LED wired to be always on at about 20 mA. I have moved the code around a bit since last time I talked about it. I don't use the timer interrupts at all now. I just use the ADC conversion complete interrupt. I discovered you can configure the ADC to automatically begin a conversion based off of a number of other interrupts. So I set the ADC to trigger off of Compare Match A for Timer 1. That interrupt is the one that raises the strobe line to the LEDs to begin emitting light for 10us. However, I don't actually have to service the Compare Match A interrupt, the ADC will begin conversion regardless. Instead I can just service the conversion complete interrupt and do everything there. The timing of the conversion is such that the sample and hold should happen somewhere around 7 us into the pulse. I've yet to verify that's really what's happening on the scope however.

Anyway my test program behaved quite oddly and only the forward channel seemed to ever detect anything. After some digging I discovered that there are restrictions on changing the ADC channel while in auto-trigger mode. Two of the three times they list that its OK to change, I could not puzzle out how to get at in code. I wound up actually disabling the auto-trigger bit, a listed time to change the channel, and then reset the bit right after the channel change. That seemed to work. But, it took about more than an hour to figure out what was going on.

I'll chalk it up to a learning experience. I've explored a corner of the AVR that'd I'd never visited before and found an annoying quirk. I'll know better next time and maybe I can get someone past the quirk in the future without them having to puzzle for an hour or more.

Rapid PCB Etching with a Sponge

hack-a-day picked this up from instructables who picked it up from Pulsar. Its a story about etching VERY rapidly, in about 60 seconds, by using a tiny amount of Ferric Chloride and a sponge. I am pretty excited for this technique and will try it very shortly. I found a second error on my LED emitter board so its over-due for a re-etch. Once I've tried it I'll report back here. If you've already tried it, leave a comment and let me know if the technique lives up to it amazing promises.


Update: Unfortunately I must report failure. Tonight at RBNO I tried this technique and found only moderate reduction in etch time for a whole lot more work than an agitated bath. I think that the copper clad the fellow in the instructable is using must be quite thin indeed. I would expect that an agitated bath would run pretty quick as well. For my standard 1oz copper clad it took me 8 or nine minutes of wiping to clear the board. An agitated bath take 10 to 15 minutes, but I don't have to do anything, I just wait for the board to finish.


So, I don't think I'll be using this technique. Its a shame, I was really salivating over a 60 second etch time.

Uno V Dos Sensor Board Progress

So tonight I finally got back around to working on Uno V. Dos. The part I really wanted to get working was the multiplexer driver. The idea behind the multiplexer circuit is that the 10us pulse that happens 300 times per a second will redirected to a new IR LED bank after each pulse causing the LED banks to fire one at a time in a ring sequence. To effect that, I set my timer up to generate a 10us pulse 300 times a second on the Timer1 Output Compare A pin (OC1A). That was pretty easy and I was able to see the pulse in TomG's old but still quite capable o-scope.

The pulse goes to the enable pin of the high power 3-to-8 multiplexer chip. Each of the eight outputs goes to a different bank of LEDs. So when that pulse comes in one bank and one bank only will light up for 10 us. Exactly which bank lights up is controlled by the 3 address lines of the multiplexer. I needed to swap out those address lines shortly after the strobe pulse ended when the multiplexer would be disabled, the LEDs off and there would be a goodly wait until the next pulse.

Initially I set my Timer to Fast PWM mode with the TOP controlled by ICR1 and set to about 27,000. The compare register was set to 67. OC1A was configured to set on overflow and clear on compare match. This looked great on the scope and I didn't think I'd need touch those values again. Since OC1A was set to clear on a compare match I figured that of the several timer interrupts, the Compare A Interrupt was the right time adjust my address lines that headed to the multiplexer. Wrong.

For some reason that I still not certain of, the Compare A Interrupt does not seem to fire.  I know I had the Timer 1 Interrupt mask set properly to enable both Compare A and Overflow and I had the Global Interrupts Enabled flag set, but still no joy. Overflow Interrupt, however, worked just fine. Odd. Of course, the way the timer was configured, overflow was a terrible time to mess with the address Lines. It could result in two banks lighting up, each for some percentage of the 10 us time.

Maybe its just a quirk of Fast PWM mode, but by the time I determined that Overflow worked and Compare A didn't it was late and I didn't want to change the mode. I wound up setting the Compare Register to 27000 minus 67 and changing OC1A to clear on overflow and set on compare match. This gave me the same over all signal, it just occurred at the other end of the time period. (26933 through 27000 rather than 0 through 67) It also made overflow the correct time to change the address lines.

Above you can see a picture of my success. The top two pairs of lines are two of the three address lines. The last square wave at the bottom is the strobe pulse signal from the Output Compare pin (OC1A). The Address lines appear double because the o-scope is set to trigger on OC1A and the value of the address lines changes with each pulse. The rapid variation makes the high and the low states blur together and appear to be occurring simultaneously on the o-scope. However the code that actually changes the line first sets them all to zero so that a simple bitwise OR operation can be used to write the new line states all at once. This causes a noticeable glitch in the address line wave shape where all the lines are zero for a time. However, as you can see in the photo the glitch occurs a few microseconds after the LED strobe pulse comes down meaning the LEDs are off. So the glitch does not affect them. What the glitch does do is provide me a nice point of reference that allows me to overcome the blurring of states and confirm that the address lines are changing at the right time. It was a happy glitch to end the evening with!

Slow Progress

Not a lot of progress this week. All I managed to do was attach my repair wires to fix the reversed power and output on the TI OPA380A chips. I haven't even had a chance to test it. With any luck I did not smoke the chips.

It took me around two or three hours of futzing to put the wires on. Just a bit faster than I could remake the whole board. Of course, if I smoked the chips, I'll be remaking it any way.

On another note I happened to run across a really neat piece of electronics art. I really dig the air-wire scheme it has going on. I can see using the technique in a trophy design.

Blunderifc

Well it seems I made another blunder quite some time ago and have only now just seen it. I finally got around to firing up Uno's sensor board for testing. The Transimpedance Amplifiers immediately got hot. After poking around a bit I discovered that the library component that I created for DipTrace has the pins in descending order.. on both side of the SOIC chip. Doh. I got lucky, two of the four pins are N/C on the bad side, but the output and the Vcc got swapped.

You can see where I've begun cutting the traces on one of the four amplifiers. I hate to make this board even more ugly than it is, but if I didn't fry the chips its still a good bit less time to cut traces and solder jumpers than to remake the whole board, even with my new solder paster skills.