Little Propeller vision board
Cliff L. Biffle
Posts: 206
As a hobby, I build little robots. I've used a CMUcam for vision in the past, but they're sometimes finicky to work with, and while the newest one is open source and hackable, it's got some serious Second System Syndrome going on (Zigbee? SD slot? $240?!).
So I've set to work building a replacement around the Prop. I'm not the first by any means, but this might be of interest to amateurs -- the board is simple, and the image sensor is readily available (OV6620-based 3088 module, same as the CMUcam).
The driver is integrated into PropellerForth, so you can log into the camera to test code and develop. (The sample images below were generated using PropellerForth words to produce PPM and real-time ASCII art.) With the driver and framebuffer you've got about 7.5KB left (plenty of PropellerForth code space).
If other folks might be interested in this sort of thing, I can post the PCB layouts and sources under a suitable open-source license. I can't provide much in the way of technical support, so I wouldn't think of trying to sell it.
Currently it records 88x72 (QQCIF) images at 25fps, YUV format, using one Cog -- the other seven can do whatever you want. For my applications I need color blob tracking, edge tracking, and motion sensing, for example.
The prototype:
Some PPM exports (sorry about the chroma noise, I only had a dim yellow light available):
A screenshot of minicom displaying real-time ASCII art of my very tolerant girlfriend:
While I don't follow the forums much anymore (not much spare time lately), I'll check back to gauge interest.
So I've set to work building a replacement around the Prop. I'm not the first by any means, but this might be of interest to amateurs -- the board is simple, and the image sensor is readily available (OV6620-based 3088 module, same as the CMUcam).
The driver is integrated into PropellerForth, so you can log into the camera to test code and develop. (The sample images below were generated using PropellerForth words to produce PPM and real-time ASCII art.) With the driver and framebuffer you've got about 7.5KB left (plenty of PropellerForth code space).
If other folks might be interested in this sort of thing, I can post the PCB layouts and sources under a suitable open-source license. I can't provide much in the way of technical support, so I wouldn't think of trying to sell it.
Currently it records 88x72 (QQCIF) images at 25fps, YUV format, using one Cog -- the other seven can do whatever you want. For my applications I need color blob tracking, edge tracking, and motion sensing, for example.
The prototype:
Some PPM exports (sorry about the chroma noise, I only had a dim yellow light available):
A screenshot of minicom displaying real-time ASCII art of my very tolerant girlfriend:
While I don't follow the forums much anymore (not much spare time lately), I'll check back to gauge interest.
Comments
Cliffe, what you've shown here is awesome
Oh - and welcome back
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I especially like the ASCII art, I would be very interested in this.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Very nice work.
Graham
(Getting out my photo lights, with predictable color temp, didn't hurt either.)
I should give some credit to Coley on this one -- I used his marvelous Hybrid board for initial prototyping, using a modified Hydra experimenter card. Without the Hybrid I'd never have tried reworking my algorithms for 96MHz operation (which turned out to be the key!). Everyone should buy one.
Edit: Sorry, simonl, I missed your question the first time around.
The 3088 in the picture is the one off my CMUcam2 (purchased from Seattle Robotics a couple years back).
For experimenters buying them in low quantities, Electronics123 seems to be the easiest outfit. They've got a bunch of Omnivision-based DIP modules like the 3088, most of which are pin-compatible. (If you're on a budget, my code works fine with the 6120, which is the B&W module.)
Caveat: I haven't actually bought from Electronics123, though I'm preparing to put in an order.
Post Edited (Cliff L. Biffle) : 5/17/2008 9:08:43 AM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 5/17/2008 12:03:39 PM GMT
The descriptions and lens are different on these models - can the in stock one be used for this application?
I think the main difference between them is that the first one has a mono composite video output, as well as digital O/Ps.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Basically any OV6620/OV6120-based board will work, as long as either
1. It has the same pinout as the 3088 (E123 has the pinout in their spec sheet), or
2. You're willing to adapt my layout (using gEDA, which is free and will run on basically anything).
I can't promise that I'd have free time to assist anyone trying to adapt the board. :-(
Nice work! The OmniVision chips are certainly more ubiquitous than the (now-discontinued) Kodak chips I purchased in quantity for the PropCAM. And the ability to program the resolution makes it a nice match to the Prop. Their only drawback (and the main reason I went with the Kodak chip) is that their "frame exposure" mode requires a mechanical shutter. But for most hobby robotics apps (as the CMUCam has amply demonstrated), the shutterless "rolling exposure" mode is more than adequate. And for those who need color, there's probably no better choice out there.
Congrats on getting one cog to do the interfacing. That had to require some clever programming!
-Phil
I can't take any credit for this great piece of work but it is really fantastic to see my board put to some good use other than gaming...
And yeah, everyone should buy one!
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
For my applications, exposing line by line is no big deal, and the OV chips have the advantage of being cheap (since they're in virtually every webcam since the Quickcam).
Right now when e.g. exporting a PPM file, I freeze capture by killing the driver cog, to prevent tearing. Needless to say this is not ideal, and the next version (likely the one I release) will have a locking protocol to pause capture for processing. This will at least let you ensure that you're working on a single frame's worth of data, rather than segments of multiple frames.
The timing's not as sensitive as you might think. I cheat a little and program the camera for 25fps and QCIF output. I've got 43.308 cycles per pixel (86.616 per pixel I save), which is a lot of headroom to capture Y:U and V, combine them, and write them to RAM. The only tricky part was leaving enough headroom on the waitpeq calls to deal with the fractional cycle counts -- but once we worked out the details in that other thread, it fell into place.