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.

Tuesday, September 15, 2009

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.

Friday, May 22, 2009

Reprap electronics order arrives

My order of the Gen3 Reprap electronics arrived. Now I'll have to find the time to build the electronics, but I have to organize and reassemble my work area in the basement first...

Note: Cat not included

Thursday, May 07, 2009

The UAVs are coming!

So, I was poking around and ran across DIY drones again. When I first saw the site a year ago, I wasn't too impressed. My opinions have changed drastically. About $200 gets you an add-on autopilot for most small R/C aircraft (Ardupilot). Others have a direct cosine matrix that fuses IMU and GPS signals into a very stable position and attitude estimation of an airframe. More expensive hardware, of course ($400?). I keep seeing daughterboards for these, and this makes me wonder. While it's not ideal, what would happen if you used an IDG 2 axis gyro (x,y) and a more traditional gyro (z) to make a "flat" board? This would greatly reduce any mechanical misalignment or damage, and cut down on the board profile, too.

They're looking for suggestions for an Ardupilot PRO. They want to run dual Arduino CPUs on this. One CPU should be running a fail-safe program, and also an XBEE signal. The second can be running the current Ardupilot software. This would let the user create an XBEE based radio and completely ditch the need for an external standard receiver. I personally would figure out how to put TWO Xbee sockets onboard. One would be running 900MHz (40kbps) and carry critical data and the controller information, while the other would be a 2.4GHz data uplink (250kbps) for anything the Ardupilot or other add-on cards needed to send to a PC. This would allow either a dedicated 900Mhz signal for longer ranged manual control and emergency signalling, or a double failsafe for manual control with extra bandwidth to ride on for the standard 2.4GHz modules. Duplicate this down at the radio and you'd be set.

Technically, using something like Ardupilot shields, you could have one shield providing IMU, GPS, and servo support, and another shield providing transmitter buttons, analog sticks, a display, and an FTDI or other chip based USB uplink to the computer.

IO Type______Aircraft_______Transceiver
Digital______Servos (PWM)___Buttons
UART_________GPS____________FTDI USB

Thursday, April 23, 2009

Finally a powerful camera module!

I've been looking at the CMUCam3 for a while, but I've never been very happy with the limited processing power of prior modules. Now the Surveyor comes out with almost exactly what I was looking for. Fast, enough space, can do video compression, or more importantly video analysis to run many image codes onboard. It might take more power than the CMUCam, but not much, nor much larger. And it costs less.

Tuesday, April 21, 2009


Was reading notes on Sparkfun's web site, ran across notes and work on the Ardupilot. Looks like a complete, but basic UAV is around $500 if you have nothing to start with.

Wednesday, January 21, 2009

Mass Memory?

Just ran across Microchip's latest toy, a serial SRAM. I haven't looked at this class much as many didn't have a lot of memory, or were slow. This can do 20MHz SPI, not too bad, but still FAR short of the internal RAM speeds. What could we do, though?

Each memory chip can use a Chip Select, Hold, and standard 3 wire SPI. We can gang the chip select, hold, and serial clock together from each chip. It doesn't look like there's a problem twinning the serial in and out lines together for each chip. what we can do then is get a somewhat inefficient parallel RAM module then, starting at 256Kbytes. Might be useful if you have large blocks of data to transfer and can take some lag at the start and stops. You could talk to this array via a parallel port interface on an MCU, but instead of sending a single 24 bit numeric array for a read, you'd have to multiplex this out to all the IO lines. A little more processing, but probably still much faster than anything else. It's this command addressing that will slow it down the most, but it will work very well for sequential read/writes with, perhaps, less cost than a SRAM of similar price and without worrying about FLASH wearout.