Cheap Cheap Cheap Computer Vision

[greywanderer012345]

   I'm looking for a way to put a camera on a robot for extremely little cost. My goal is to find a way to build a robot with a camera for ~$50. This price does not include any equipment that is not on the bot itself. (programmer, voltmeter, PC, etc)

   I've been around the forums, and outside of them, and I understand that this is a huge project. Please don't comment that I should just use one of the expensive cameras.

   I am looking for an option that would allow someone to use many such cameras at once. This is why cmuCam and similar products are not viable, but products that require some initial investment, such as RoboRealm, are fine.

   I think that using a Raspberry Pi ($25) instead of (or in addition to) an MCU, along with a webcam would be a great option. For this option, does anyone have any good ideas or experience with the Raspberry Pi that they could add? Is there a good way to control other sensors/actuators with the Pi, or would it be better to let it communicate with an MCU?

   Also I found this camera. I'm quite sure that more hardware is needed to get it to work with an MCU board, but what would be the cost of additional hardware?
https://www.sparkfun.com/products/8667
   In this case, I'm looking for something as simple as taking a photo and storing that on an sd card, not necessarily video, or full-blown robot vision processing, as either can easily be too much for an MCU.

   I'm also interested in capturing an image, and sending it to a pc wirelessly for further processing.

[mstacho]

Hm...neat project!  One big problem with little, cheaper cameras is that they are very susceptible to noise.  Now, for $10, assuming you can get it going with minimal investment in electronics, the solution to that is easy enough: buy 3 of them and register their images together.  The 3 cameras working together SHOULD cancel the noise a little bit better.  Plus there are some *amazing* filtering algorithms out there if you're willing to do the heavy math lifting.  I think a raspberry pi should be able to handle it at a reasonable (2-3 fps) frame rate.

But ultimately, the reason that cameras for machine vision are so expensive isn't because they're a limited market, but because they are designed to deliver excellent image quality all the time, and with low noise it is SO much easier to get the computer vision algorithms working.  So unless you're willing to toss three or four of the little ones together and then process the hell out of  the data, it might not work :-P

Oh, and a final note about processing: I once had a prof who was always angry with the signal processing people, who would just toss their images through filter after filter, "cleaning up the results".  His response to that:

"If all we had to do was process an image in order to get more data from it, then we wouldn't have to send any probes to Pluto.  We'd just take pictures of sand and process them until they contain information about Pluto!"  The moral of the story is: it might seem like it's easy to just buy cheap stuff and glue it together with math, but don't expect the sun, moon, and Pluto :-p

MIKE

[Soeren]

Hi,

   I'm looking for a way to put a camera on a robot for extremely little cost. My goal is to find a way to build a robot with a camera for ~$50. This price does not include any equipment that is not on the bot itself. (programmer, voltmeter, PC, etc)

Given that the basic $50 robot apparently cost way more than $50 to build, I'll say you have some hills to negotiate

   In this case, I'm looking for something as simple as taking a photo and storing that on an sd card, not necessarily video, or full-blown robot vision processing, as either can easily be too much for an MCU.

   I'm also interested in capturing an image, and sending it to a pc wirelessly for further processing.

If you're planning to produce a million of them, you might be able to get the production cost down to $50.
If this is just for a single 'bot, expect seceral times that.

How many cameras are you planning to use?
Why that many?
Can you supply the power needed for them?

If this is more experimenting than producing, you might wanna try cams from optical mice (with DIY optics/lenses) or even a cam from a WII.mote.
resolution are from around 16x16 to something like 48x48, so they're fast to read and process.

If all you want is a robot with a camera (i.e. nice piccies, but no influence on the 'bot. a cheap (Chinese?) compact camera will give you the most bang for your buck and they're complete with optics and sometimes even a small SD card in the packet.

[greywanderer012345]

Given that the basic $50 robot apparently cost way more than $50 to build, I'll say you have some hills to negotiate

Soeren, Thank you so much for all of the help you always give. I'm not sure where people run into problems with keeping the $50 robot within the suggested price range. I understood the project as a minimalist challenge. Because of that, as well as my very limited budget (Full-time student w/ 3yo son), I never spent much extra money to make things simpler. The most expensive part of my project was the AVRMKII programmer. All of the components on my bot actually total less than $15. My chassis is an outlet blank, my caster is an empty fruit-cup, and my wheels are salsa jar lids wrapped in electric tape.

If you're planning to produce a million of them, you might be able to get the production cost down to $50.
If this is just for a single 'bot, expect seceral times that.

How many cameras are you planning to use?
Why that many?
Can you supply the power needed for them?

I only really want 1-3 cameras on my bot. The reason it would be worth the time and money to me would be the lesser expense in many future bots. Also, if I can get this to work, it's my intention to add a tutorial on it and offering the code I use to SoR. My budget is still quite limited. I like to learn with limited, inexpensive devices.

I should also mention that I am entirely a hobbyist. I'm studying medicine, not engineering, so a few basic concepts occasionally create a barrier for me.
   
   What's holding me back right now is that I do not understand exactly how this camera sends information on the output pins. It has 8 pins, and says that it uses parallel processing to send the bytes of the image. I'm thinking that this means that it sends an entire byte, each bit on one pin, for each byte of the image. does this mean that I would need 8 digital input pins on the MCU being used to capture the image, or would I use another IC to collect the image, and then send that serially to the MCU? I'm having a hard time finding any sort of tutorial for this type of information handling.

[Soeren]

Hi,

   What's holding me back right now is that I do not understand exactly how this camera sends information on the output pins. It has 8 pins, and says that it uses parallel processing to send the bytes of the image. I'm thinking that this means that it sends an entire byte, each bit on one pin, for each byte of the image. does this mean that I would need 8 digital input pins on the MCU being used to capture the image, or would I use another IC to collect the image, and then send that serially to the MCU? I'm having a hard time finding any sort of tutorial for this type of information handling.

The first table on page 12 shows this. For RGB mode, you read two bytes for each pixel - 5 bits for red and blue and 6 bits for green, and this describes a single pixel, so you need to read twice as many bytes as you have pixels (and unpack each primary color in a way that suits your need for processing the data).
YUV mode takes twice that, so stay with RGB, at least for now.

You read the picture data by a parallel bus eg. a single port on your controller. The DCLK tells your controller when a new byte is ready and you need to read it before the next DCLK (seems there's no way to control the speed by handshaking, so your best option is to set it to 15 fps initially)
Further you read (or use interrupts to get) the horizontal and vertical synch pulses

You set the registers via the IIC interface (SDA and SCL) and since your controller will be issuing the clock (SCL), speed demands are more lax.
It's all on page 5.

On the software side, you are in for a bit of work I think, but for some uses, you might be able to just look at one primary color (like if it was a B/W cam), eventually with a color filter in front of it.

Seems to be a nice cam for the price, judged on all the settings available (I have no idea of picture quality of course) and I would be tempted to play around with it, if I could get it locally

An exciting project that will teach you a lot I'm sure