PDA

View Full Version : Little Propeller vision board



Cliff L. Biffle
05-17-2008, 02:41 PM
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. http://forums.parallax.com/images/smilies/smile.gif

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:
http://www.cliff.biffle.org/images/pfcam-front.jpg
http://www.cliff.biffle.org/images/pfcam-back.jpg

Some PPM exports (sorry about the chroma noise, I only had a dim yellow light available):
http://www.cliff.biffle.org/images/pfcam-chroma-test.png
http://www.cliff.biffle.org/images/pfcam-chroma-test2.png

A screenshot of minicom displaying real-time ASCII art of my very tolerant girlfriend:
http://www.cliff.biffle.org/images/pfcam-ascii-nntt.jpg

While I don't follow the forums much anymore (not much spare time lately), I'll check back to gauge interest.

simonl
05-17-2008, 03:03 PM
Well, anyone who's been following the PropCAM thread won't be surprised to see me post back first!

Cliffe, what you've shown here is awesome http://forums.parallax.com/images/smilies/smile.gif I'm definitely interested, especially if you can tell me where you sourced the OV6620.

Oh - and welcome back http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://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 http://forums.parallax.com/images/smilies/smile.gif

Coley
05-17-2008, 03:10 PM
Nice work Cliff,

I especially like the ASCII art, I would be very interested in this.

Regards,

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums (http://www.propgfx.co.uk/forum) - The home of the Hybrid Development System and PropGFX Lite

Graham Stabler
05-17-2008, 03:16 PM
Gives a new meaning to "texting" your girlfriend.

Very nice work.

Graham

Cliff L. Biffle
05-17-2008, 04:01 PM
Found a bug in my matrix code. Better chroma makes for a happier engineer, as shown below.

http://www.cliff.biffle.org/images/pfcam-chroma-test3.png

(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. http://forums.parallax.com/images/smilies/smile.gif

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
05-17-2008, 06:56 PM
The C3088 seems to be a bit difficult to get hold of, Electronics123 doesn't have any in stock. I've just ordered one from Singapore Robotic ($77.61 SGD including shipping). That's quite a bit more expensive than Electronics123. 8-( They've got two left.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 5/17/2008 12:03:39 PM GMT

Forrest
05-17-2008, 09:27 PM
Looks like Electronics123 has one C3088 model in stock and one model out of stock www.electronics123.com/s.nl?sc=14&category=&search=3088 (http://www.electronics123.com/s.nl?sc=14&category=&search=3088)

The descriptions and lens are different on these models - can the in stock one be used for this application?

Leon
05-17-2008, 11:53 PM
I should have scrolled down a bit, I only noticed the first (out of stock) model.

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

Cliff L. Biffle
05-18-2008, 01:09 AM
Forrest, if I'm reading that right, the only difference is the lens. (The one in-stock has a wider-angle lens.)

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. :-(

Phil Pilgrim (PhiPi)
05-18-2008, 01:41 AM
Cliff,

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

Coley
05-18-2008, 01:52 AM
Cliff L. Biffle said...
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. http://forums.parallax.com/images/smilies/smile.gif



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! http://forums.parallax.com/images/smilies/tongue.gif

Regards,

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums (http://www.propgfx.co.uk/forum) - The home of the Hybrid Development System and PropGFX Lite

Cliff L. Biffle
05-18-2008, 07:07 AM
Thanks Phil! I appreciate it.

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.