A simpler rangefinder?

So, ages ago, the Seattle robotics people used an analog video camera and some timing with a peak detector to "read" a laser line's distance. People do this with webcams these days. But their system was one of the first and also low power. So, how could we duplicate this?

Modern digital cameraphone cameras are cheap (see Sparkfun). But they're color. You get 1/4 red, 1/4 blue, and 1/2 green pixels in your image. The color filter is definitely not user serviceable. You can get monochrome imagers, but finding the optics and keeping the cost down is difficult.

Step 1: optimize for your design choices! I'd start with a red line generator from my laser level as a test. However, green line generators (doubling your bandwidth requirements) are available now for $40.

http://www.z-bolt.com/green-laser-line-generator.html

Step 2: design your logic. The idea here is that we'd only clock in the sensor data we're interested in (be it red or green). We'd use a threshold function to trigger if this is "the line". For each trip, we'd want to capture the line number, pixel position in that line at the very least. For more accuracy, we'd want to capture the value that tripped the threshold. This would let us process the average in a program and determine if we're seeing a reflection.

This can be done either in separate programmable logic or in a PSOC3/5. Ideally you'd only have 1 or 2 pixels per line, but reality may change this. For a 1300x1040line camera, for instance, reading a 1 pixel tall line would take (2 bytes for line + 2 bytes for position + 1 byte for threshold) x 1040 = 5200 bytes of RAM, updated at 15Hz. Throughput therefore would be 78KBytes/s or 624kbit/s. I would not be surprised if it was 3-4x more, but synchronous averaging by the cpu should knock the data back down to a reasonable size. Depending on how the averaging works out, most data could be converted to a 5-8 byte per line data calculation (16-32 bit range, 2 byte line indicator, 1-2 byte time indicator), and real time streaming to a host processor via SPI, CAN, or another moderately fast bus is completely possible.

We'd want a 2 line state machine. It would control the timing of the logic depending on which scan line we're in (RG or GB). So this would take in the camera's logic. We'd use the VSYNC to reset all counters. HSYNC would toggle the state machine and increment a line counter. A second pixel counter would be run with the system. We'd need an 8x8 threshold variable.

Return to the Laser Rangefinder: PSoC to the rescue?

Of note, I have done my first soldering on the RepRap electronics. I plan to continue on it tomorrow.

Anyway, I was looking at doing a laser rangefinder again, to see if it's more feasible. I think it is. I found some hardware that can do the signal mixing and generate a 1MHz wave and a 0.98MHz wave to allow for a 2KHz signal sensor. Now, to duplicate the low end (still $2400) laser scanners that have a 1024 point scan over 360 degrees at 10hz. So, if I crank up to 10MHz and 9.98MHz I get a 20khz signal. I can digitze that at about 40MHz, so my smallest theoretical step size is 7.5mm. To do better I either need to mix to a lower frequency and sacrifice update rate, or get a faster counter. I could switch processors to 80MHz instead. That would get me 3.75mm steps.

Now, I was hoping to make this whole thing programmable, so I could test different signals (say from 0.1 to 10MHz). This would require either expensive hardware or a lot of digital potentiometer. I looked at the PSoC originally, and it is what got me looking at how feasible this project is again. The example they had was only mixing a 10KHz and a 9KHz signal in a special way, far below my target frequency. It also took half the analog blocks to do one mix, and I'd need to do two. The CPU was also just not fast enough to replace the fast MCUs I've been looking at.

Then Cypress announced the new PSOC5 series. 80MHz ARM Cortex M8 core. 4 analog blocks that can make a 14MHz bandwidth downmixer with ONE block. 4 matched comparators. 24 digital blocks. CAN. Even USB. Integrated GNU C compiler. I think I might be able to make this work without extensive external parts. A laser driver output, a PIN photodiode and amplifier, and maybe a secondary clock source for assistance mixing. I think I might be able to fit everything else inside. We'll see when I get there.

There's several digital motor control blocks, too. I might be able to combine this chip with a low cost DC motor and encoder and a mirror and mirror the capabilities of that $2400 laser model at a fraction of the cost. And only need one chip for everything.