AVRcam vs CMUcam

 comp.robotics.misc    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
AVRcam vs CMUcam dan michaels 03-05-2007
Posted by dan michaels on March 5, 2007, 9:52 am
Please log in for more thread options

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.


Posted by Gordon McComb on March 5, 2007, 12:36 pm
Please log in for more thread options
dan michaels wrote:
>
> 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 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

Posted by dan michaels on March 5, 2007, 2:53 pm
Please log in for more thread options
wrote:
> dan michaels wrote:
>
> > 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 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


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.





Similar ThreadsPosted
Vision system comparison: AVRcam vs. CMUcam2 October 22, 2005, 3:20 pm
Re: Vendors for CMUcam February 27, 2006, 12:38 am
Vendors for CMUcam February 21, 2006, 1:15 am
CMUcam opinions? February 25, 2008, 6:50 pm
anyone used the CMUCAM with the Intel OpenCV library ? December 18, 2005, 4:29 am

The site map in XML format XML site map
other useful resources:
Official Robosapien Website
Lego Mindstorms Website

Contact Us | Privacy Policy