AVRcam vs CMUcam

I imagine there are people around here who have used both of these devices.

I picked up an AVRcam this week, and started playing with it. The thing sends out a "torrent" of data in ET = color-blob tracking mode, at 115.2K. Pretty cool to follow using AVRcamView, but difficult I think for a PIC/etc to interpret.

I bought the AVRcam since it's open-source, and it'll give me a chance to learn about the OV6620 chip and also learn AVR programming [I've been programming PICs for years]. I do plan to develop some of my own algorithms. I want something to use on my small mini-sumo sized bots, and not a full-blown vision system [for PC, etc].

Just for reference, I wonder how the AVRcam tracking output matches that of CMUcam #1, especially. The AVRcam outputs a huge amount of seemingly noisy data. 8 datapoints flying around the screen at 30 frames/sec.

Reply to
dan michaels
Loading thread data ...

I don't have much experience with either, but I do dabble in some other video-enhanced technologies (mostly on the PC side), and what we often do there is simply grab what we can, and ignore the frames inbetween if there is a bottleneck. Even though the camera may be supplying 30 fps, there is no steadfast rule that you have to process all 30 frames each second. Your application may only need two frames a second, and that may be all that your hardware can support. Take whatever time you need to process the data, and forget the other 28 frames.

Anyway, you'd think the newer DSP-based PICs would have the speed to process the data. No?

-- Gordon

Reply to
Gordon McComb

Hi Gordo. Actually, the AVR cam [like the CMU cam, as I understand it] doesn't send complete frames to the PC. That takes 4-sec each at

115.2. These cams are basically just blob-trackers.

What the cam does is process the frames in real-time and extracts 8 colored areas [blobs], as determined by a preset color map, and just sends over the x-y coordinates of upper left and lower right corners of the blob areas, so maybe just 20 or 30 bytes at 30 times/sec or so. Then the PIC/cpu converts this coordinate data as it sees fit.

In the PC viewer software that comes with the cam you can watch the blob detection in real-time. You see a torrent of 8 squares representing the blobs flashing on the screen at 30/sec.

Reply to
dan michaels

OK, so I am certainly biased, since I developed the AVRcam, but I know a bunch of people (including myself) who have taken the output of the AVRcam and processed it with another AVR (or a PIC) with no problem. We're talking about a 115.2 kbps bitstream, and any uP with a hardware serial port should have no problem processing this.

If you are looking for example code, keep your eyes peeled on

formatting link
over the next few days. I'm going to be uploading some code that I developed for an AVR that is capable of receiving the tracking packets from the AVRcam, building them into a usable "tracked object" data structure, and making this structure available for application-specific processing (in my original case, it was for line-tracking purposes).

Stay tuned, John Orlando

formatting link

Reply to
john.orlando

onwww.jrobot.net/Download.htmlover the next few days. I'm going to be

Great, John, thanks. I'm still hoping to hear from someone who's used both cams, for some comparative background info :).

Reply to
dan michaels

cmucam uses an sx (scenix pic clone) running at 75MHz. Chip doesn't have aby hardware peripherals - have to do everything bitbanging.

The newer 24f or 30F pics should have more than enough power to process the video data using c (no need for asm) and microchip gives a free student edition of the compiler.

But for full video processing at 30fps still need something a little more powerfull.

One board that looks very interesting is the new blackfin handy board. gcc compiler and also labview

formatting link
of flash(256MB), plantly of ram (64MB), fpga for motor/sensor control
formatting link
works with the omnivision camera modules

Alex

Reply to
Alex Gibson

labview

formatting link
Ton of flash(256MB), plantly of ram (64MB), fpga for motor/sensor control
formatting link
Also works with the omnivision camera modules

Thanks for the info, Alex. Looks interesting.

The two most important pieces of info I couldn't find .... cost of the board, and how much current the board actually draws.

Reply to
dan michaels

control

formatting link
> Also works with the omnivision camera modules

Its not available for general use yet. Apparently being used / debuged in a uni course but sale for general use is supposed to be soon.

Can get an idea of power use from

formatting link
Switching Power Circuit * 5A, +5v to power external devices, including servo motors and sensors * 3.3v and 1.8v supplies for Blackfin and FPGA Integral Battery Power * 12v, 2000 mAh battery pack (10 AA NiMH cells) mounted in case underneath board * built-in rapid-charger with timed, voltage-slope, and thermal cutoff modes

430 No such article 222 11583 body

control

formatting link
> Also works with the omnivision camera modules

Its not available for general use yet. Apparently being used / debuged in a uni course but sale for general use is supposed to be soon.

Can get an idea of power use from

formatting link
Switching Power Circuit * 5A, +5v to power external devices, including servo motors and sensors * 3.3v and 1.8v supplies for Blackfin and FPGA Integral Battery Power * 12v, 2000 mAh battery pack (10 AA NiMH cells) mounted in case underneath board * built-in rapid-charger with timed, voltage-slope, and thermal cutoff modes * 5.5/2.5mm coax power connector with bridge rectifier allows use of AC or DC adapters

I would be interested to know how long the 12v 2000mA battery lasts for.

Alex

Reply to
Alex Gibson

control

formatting link
>> Also works with the omnivision camera modules

from

formatting link
High-Performance Switching Power Circuit

Yes, I read all those numbers, which is why I wondered what the ACTUAL current draw is.

Reply to
dan michaels

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.