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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dan michaels wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 http://www.cs.uml.edu/blackfin / Ton of flash(256MB), plantly of ram (64MB), fpga for motor/sensor control http://www.cs.uml.edu/blackfin/index.php/Main/Specifications http://www.cs.uml.edu/blackfin/index.php/Main/BlockDiagram Also works with the omnivision camera modules
Alex
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 http://www.cs.uml.edu/blackfin/index.php/Main/Specifications High-Performance 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, I read all those numbers, which is why I wondered what the ACTUAL current draw is.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 www.jrobot.net/Download.html 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 www.jrobot.net
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Great, John, thanks. I'm still hoping to hear from someone who's used both cams, for some comparative background info :).
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.