Tuesday, September 22, 2009

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.


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.

No comments: