SparkFun Forums

[SN96]

Are there any plans to make a breakout board that will make use of

this camera?



I would love to see a wireless video camera that is smaller than the smallest curently out there. I am trying to find a wireless video camera that is small enough to fit in an aluminum head that I designed. I plan to put a camera in the drilled eye socket, but most small wireless cameras are in the 22mm X 22mm rage, to lage for my design. I would love to see a 2 channel version made since I would like to use two cameras for vision navigation.

Look at the below image to see what those cameras would be used for. I designed this using eMachineShop's software. the eye sockets are 16.6mm but I can easily revise the design to house the smaller camera. I originally designd the eye sockets to house the Parallax PING Sonar sensor, but cameras would be so much nicer!



For what it's worth, thanks

[TSPRAP]

I would also love some use for this camera. People still haven't been able to get a image stream from this camera! (remember, these were from phones and supplied with no datasheets and pinouts. they have figured out the pinout and one person got SOMTHING (not evev static) so in a few months someone shoud have figured how to 'take' a picture with this camera)

[SOI_Sentinel]

I'm actually waiting on hardware for my attempts. However, let me give you an idea of what we're facing.

30fps x 640x480x16 (YUV 4:2:2 format) = 147,456,000 bits per second. 18 Megabytes per second is a little high for embedded processing. I've decided to not pursue a full resolution image for the moment. I'm also focusing on just a snapshot.

Analog cameras get by by using lower resolution and transmitting an analog format. Modern digital cameras get through this bottleneck by placing a lot of computing power real close to the camera and/or using a high bandwidth link (802.11B/G).

Now, I'm mostly trying to reinforce the level of complexity you're looking at. You can get small board computers running anything from ARM to full Pentium chips that may fit on your robot. You will most likely have difficulty getting any data analysis done with normal hobbyist microcontrollers.

Now, with all this, I have to say that your decision to wait is probably the best possible. Yes, a breakout board should be coming. In your case, I'd recommend waiting for something with some horsepower already attached to it. You might be able to do a lot of pre-processing that way so that you don't have to worry about moving ALL this data. No promises, I know the programmable logic approach is going for a frame grabber right now.

I also know of a few wired black and white and color NTSC video cams that may work if you could find a small enough dual channel transmitter or digitizer that could be strapped to your robot effectively.

http://www.supercircuits.com

[SN96]

Thanks billions SOI_Sentinel,

I might go black and white wireless to keep things simple. I am in no hurry and can wait for the best solution. My head design is finished but I have yet to figure out what size to make the eye sockets. The eye sockets in the image I posted above are 16.6mm which is for the Parallax PING sensor elements which are 16.3mm O.D.

[NateW]

FWIW, the AVRCam uses 88x144 images at 30fps for color blob tracking, and the CmuCams are in that ballpark as well (CmuCam2 also supports higher resolution or frame rate, but I dunno if it supports both at once).

So, even if the captures are only at about 1/4 of the full resolution (1/16th of the data), a lot of interesting stuff would still be possible. A shrunken (SMT-based) AvrCam using this camera sensor would be super cool.

[SOI_Sentinel]

You'll get something like that probably. I'm actually going to try and do some on the fly data work on the data via a dsPIC33F (just got the shipping confirmation yesterday).

The AVRCam also only watches 4 bits of each channel IIRC. Still quite impressive.

This camera can, in hardware, downsample to 320x240 or 160x120. Input frequency and framerates stay the same, they skip lines and pad the actual data stream. I'm still trying to decide how this can be handled. I'm still digging about looking for a common processor that can handle stuff like this. ARMs are an option, but I keep on hearing that their GPIO parallel ports suffer in the speed department. Some do have an external memory port, which would allow for image buffering. We're heading into non-integrated territory, with larger and more complex board designs. I'm trying to keep away from that.

[phalanx]

So you managed to scrape up a dsPIC33F? Did you go through Microchip directly? They apparently have a number of the 64-pin ones available.

I'm currently waiting to get the 100 pin versions. They are still listed as a future product on the Microchip website.

-Bill

[SOI_Sentinel]

Yeah, I have three dsPIC33FJ128MC706's on the way, 64 pin. I know some of my plans are getting well ahead of my testing with this, but it should be powerful enough to do many interesting things with these camera. It just got updated... I have a month to wait.

It looks like they're sampling 100 pin 16 MIPS PIC24's. I'm a little upset with them, actually. They put a parallel master port (PMP) on the 16 MIPS units, and a DMA controller on the 40 MIPS units. The PMP can behave as a 16 bit interface memory with direct access to 16 bits of address. It they could have put it on the 40 MIPS 24's or dsPICs and provided DMA access, they may have really gotten something. Otherwise, it's mostly ARM7s that exist in that field, and they don't have the IO speed to read from this camera from what I've seen so far.