I was sent this image this morning from Gert (not pictured), Naush (right eye and half-moustache) and JamesH (stripy shirt and chin). It’s not a terribly exciting photo – until you realise that it’s the first picture ever taken from the prototype camera add-on board we’re developing for release later in the year, which will plug into those CSI pins we expose in the middle of the Raspberry Pi. I will ask Gert, Naush and JamesH, who have been working on this in their free evenings, to answer questions in the comments below – they are also very active on our forums, so please come over and have a chat.

We may downgrade the super-duperness of the camera to something with fewer than its current 14 megapixels before release; we need to keep things affordable, and a sensor of that size will end up pricey. Before you ask (I know it’ll be the first question most of you have), we don’t have a price for the camera module yet; we’ll need to finalise exactly what hardware is in it first, but we will, of course, be ensuring that it’s very affordable.

More pictures, including some of the camera module itself with the Raspberry Pi:

Gert (bottom left), JamesH (middle) and Naush (top right) are looking very pleased with themselves. Here's another picture from the camera module, which wishes it had something to photograph besides engineers.

The module is pretty small, which makes it ideal for some of the robotics and home automation applications people have been wanting to build.

The mechanical design still isn't complete, but the final version will attach to the Raspberry Pi with ribbon cable, like this prototype.

View from above.

JamesH now holds the record for the most random body parts (fingertip, chin) used as feature photos on this website. Congratulations James! (There is no prize.)

I’ve been thinking about this over dinner, and I’m really keen that you guys shouldn’t get your hopes up about removable filters – the problem is that we will be using cameras which are usually sold as mobile phone or webcam parts, and typically those are pretty much sealed-unit deals where the user doesn’t really get to do even that degree of customisation. We’ve heard what you’re saying, though, and we’ll look into whether it’s possible; but I have a very strong feeling it won’t be.

As Liz said I’m not even sure you can even get sensors with removable IR filters. And these things are pretty tiny so difficult to ‘DIY’. I’m check with one of our experts who has some experience with this if I rememeber (he used to work on the camera used for big telescopes)

Since it will likely be cellphone style camera I am with liz and not holding my breath. But on the off chance that its possible, I would be willing to give up a compact camera for something with a screw on lens. However with price in mind, that would likely rule out auto focus which I am sure others may be hoping for.

Someone correct me if I am wrong, I am mostly basing this on my expirience with FPV model airplanes, though they are analog SDTV style camera’s.

For now, we’re probably just going to do one, which will *probably* be around the 5 megapixel class. We want to concentrate our engineering resources and our buying power – although a more expensive module with higher resolution might be on the cards at a later point, it’s not something we’re actively developing for at the moment.

OK, before I saw this, I just finished posting a comment that a clean 5 MP camera would be far better than what is most likely a more-noisy 14 MP one. I’d hope that a lower-resolution camera would offer better noise levels and low-light sensitivity. 14 MP is way too high for a puny camera like this, and I’d expect that the primary use for a camera on this thing will be video anyway. Why undertake the unnecessary data bloat for all those relatively useless megapixels? How about a clean 5 MP sensor with great performance?

I do see arguments for higher resolution – specifically, it means you can do good digital zoom, where physical zoom is unavailable because of the way the cameras for cellphones are built without moving parts. (But on the whole I totally agree with you.)

when doing computer vision projects, as opposed to mearly video, the higher resolution camera can be a big win because you have more pixels to use to notice changes in. This lets you detect changes much more rapidly (and/or at much larger distances)

a 14Mp camera will be able to detect a change either about half as large, or at about twice the distance as a 5Mp camera.

not all uses require low noise and low light. there are many where the increased resolution (and therefor tighter angular sensitivity) is far more useful.

If you do make the cheaper 5Mp camera, please post the part number of the camera and the board design (along with the software) so we can build our own.

If we can get a higher-resolution camera in the same product line from the same manufacturer as a special group buy, would it be a fairly straightforward matter of updating some constant or variable values (e.g., image width, height, bit depth, etc.) in the driver for the lower-res camera? Or is there no such thing as a product family where the drivers are that similar?

It is very good to hear there is a possibility for the h264 encoding license. The bcm2835 used in raspi only contained a license for h264 decoding. This way, users who wish to use it can purchase it without increasing the price of the bare computer :D

This is great. I really look forward to the video possibilities. And the possibilities of what the hackers will make it do. Exciting times, especially seeing as today I got my golden ticket from RS for my Raspberry Pi.

How about the one when it finally snowed on Christmas Eve and Dad came home with a car full of presents and Mom made those really good cookies and…..
Oh, wait. I have to build my Pi based time machine first.

In the first picture, the Videocore on the Raspi is being run via a JTAG debugger running under Windows. That’s how we bring up cameras, and we can dump images direct to debugger display .
Other pictures are taken of a piece of demo/test software we use for further development, which is why they are photo’s of the display.

The “C:/projects/raspberrypi/…” is a bit of a giveaway ;-)
I suspect it’s simply the http://www.synopsys.com/dw/ipdir.php?ds=arc_metaware_debugger running under Windows – the debug connection between the Raspi and PC could be over any number of interfaces (probably JTAG though). This isn’t “proof” that the Raspi can run Windows :-P

Length – probably not much longer than you see there – the signals are pretty fast, and the longer they are the less chance of working.
Yes, the GPU can encode the camera stream to H264 at 1080p30, but that does require a licence from MPEG_LA.
Display – one thing at a time!

The last thing you want when bringing up a new device, is worry about signal quality. Thus we started with a very short cable. The cable you see is 51mm. We also have cables which are 150mm which we will try soon. The manufacturer says these are 50Ohm cables and they are designed for the 600Mbits/sec we need and can even exceed that speed.

Very nice. Raspbian earlier today built the OpenCV libraries with hard float math so having a camera feed into the capabilities of OpenCV will mean some very cool applications will be possible. I’ve done some OpenCV projects in the past and I’m eager to give it a whirl on the Raspberry Pi.

CSI is just an electrical interface which transports data. It has no effect on the quality of the picture other then it arrives or not.
“I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” :-)

I think you’ll find Shish was referring to the TV series “CSI”. Wherein a grainy 160×160 pixel image grabbed from a black and white CCTV camera can be “enhanced” to a hi-def colour image of the reflection in the subject’s pinky ring, thus revealing that the killer was, in fact…

All by someone saying “enhance” “flip” “zoom in there”, aided by teh majick of the computar-machien.

Actually, if you can take multiple frames (the more, the better), you can actually generate a higher-resolution image than any single frame as noise can be canceled out as image data is mathematically summed for each pixel. This requires registration of objects in the frame to ensure pixel-per-pixel overlap. This is how the Hubble Deep Field images are generated which detect galaxies back to within a few hundred million years of the Big Bang – except that they boresight the telescope/imager on a single point at maximum zoom power for weeks at a time and collect millions of images that then take months to process. Having the GPU will be handy for this.

BTW, if the camera and/or object move within the frame, 3-D data can also be extracted, even within a couple of frames of real time, given a fast enough GPU (ours should be plenty fast enough).

This ->”JamesH now holds the record for the most random body parts (fingertip, chin) used as feature photos on this website. Congratulations James! (There is no prize.)”
really sounds like some quote from Portal. Replace “prize” with “cake” and it would be even nerdy-er.

Heck, even 1 megapixel is overkill if the sensor is of good quality! Remember that the human eye can be seen as a 1~2 megapixel “camera” (though at like 100fps, insanely good low-light sensitivity and 16 steps of light difference)

Also are these really the kind of things put into cellphones? The Camera module in the pictures is absolutely enormous!

These are : VGA, 5MP, 8MP and 12MP sensors from various mobile phones. The 12MP has a focusing lens. The 41MP sensor in the Nokia 808 is considerably bigger than the largest one here. The 808 sensor takes stunning photographs – so this is a case where megapixels are put to very good use.

The module used in this demo was 14MP, and in size if somewhere between the 8 and the 12 in size.

I’ve seen 2MP cams from years back which take far superior photos to some more current 8MP/12MP – please consider using a focusable cam and not a fixed focus – macro would be nice although I don’t think that would be justified in a robotics/automation setting.

Cost cost cost and more cost. Focusing lens cost a lot more. Also because they are infrequently used, we only have tunings for a couple of types (I think – would need to confirm), one which is end of line and one other, which I think is also end of line (that’s 12MP from the Nokia N8). See Gert’s post below for why we need to choose a camera with an existing tuning.

Awesome.
Please consider offering at least a 720p camera. If you decide this would not be cheap enough you can offer two models: a cheaper model, for example 640×480, and another, more expensive HD model too.

High quality camera module please – useful for computer vision / schools etc. etc. It’s not as if most of us are likely to integrate very expensive camera lenses in front of this … AWESOME projects to come :)

Very interesting. I’m wondering if there’ll be some kind of easy to use librarys for it ;)
Also I’m thinkin about a Project with a camera module in my Bachelor exam next year. Something about cameras, lasers and radarstations on streets ;)

Just some background information (These comment have been posted on the forum on several subjects about ‘CSI camera’ but not everybody will have seen those).
Electrically connecting a camera on the CS interface is a challenge but it is only fraction of the job. Most of the effort involved with cameras is getting a good image quality. The GPU has an ISP (which here stands for Image Sensory Pipeline) which does A LOT of post-processing on the raw camera data. Every camera module which is connected to this ISP needs tuning. We have a team of people working about 6 months to get a good quality image out of the camera. (I think some of them have doctorates in computer images maths) Thus ‘adopting’ a new camera is not a trivial task and is not something which can be done ‘just’ in the evening hours like some of the other work done by my colleague Broadcom volunteers. This means that whatever camera module will be chosen, it has to be one where that tuning work has already been done. This also means that I strongly discourage anybody out there to try to do the same. You are welcome to try but are likely to fail utterly. You first do not have the knowledge of how the ISP works and secondly I doubt you have even a fraction of the total experience our teams has build up over the years.

Note to self: Do not use &sm or &gr in text. It seem to have missed a line and made the following text italics:
“I hope this is also reduced the flood of emails from Camera vendors who want ‘their’ camera connected to the Raspberry-Pi”

“We at NASA will have some leftover very high-resolution imaging devices that cost hundreds of millions of dollars to develop, which will be available to the highest bidder at a disposal auction to be held in a few years. Oh, rats, we can’t go retrieve them without a Space Shuttle … well, that was really poor planning, wasn’t it?” ;)

It really surprises me there is so much work put into post-processing of digital camera data. I’ve owned many different cellphones in the past. All of them were very different in each and every perspective, except for one and that is the absolute terrible camera quality. On several windows smartphones there were even applications that were able to post-process predictable noise data out of images because such cameras usually had some noise in predictable locations. It’s only been the last couple of years that mobile phone cameras are finally moving away from their 2000s webcam quality.

I hope that nowadays such joke-cameras are no longer being put in high-end mobile devices. With a team so very qualified, there is hope for the raspberry camera!

This is a nice looking project, and I have a few observations.
We should never forget that this is a £25 computer board. As such it would make no sense for the camera (or other, later add-ons for that matter) to be expensive. If you’re looking to do high-res/high-quality robot vision, you’ll be looking at a much better quality camera and lens than the plastic, mass-produced phone-cam example here.
If you’re not into robot vision, then there’s not much to be gained from having a camera resolution greater than the resolution of the display. So anything better than 1920×1080 would be a waste – both of camera/cost and processor cycles on the Pi itself.

So if the camera was to cost more than £2 or 3 in quantity, I’d reckon that would not be a good match for the Pi and would certainly dampen the spirit of the whole low-cost concept of this device.

Sorry Pete, I disagree with almost all of that. Modern mobile phone sensors are MUCH MUCH better than you seem to this. I challenge you to take a look at images from the Nokia N8 and Nokia 808 (both use the GPU we have here) and then make the same assessment you just made. Even the EDOF sensors (no focusing lens) used by many mobile companies can take very good imagery. Of course there are some real dogs, which is usually down, not to the sensor, but the tuning. And of course, really cheap sensors are exactly that.

As to price, well, if its too expensive for you, don’t buy it. You still have your $25 computer. This is an option for people who want a camera. A £2 camera would I’m afraid be a waste of money.

That is really cool! I had no idea it was so much work to tune in a camera as has been described here. I can certainly see some interesting possibilities resulting from your groundwork. For the record, price is a factor, and I think you’ve made the trade off as practical as possible…

Can we have some more solid details about the sensor? Will we get a decent datasheet, will we get source code for the drivers? Will we just get a lib and headers? How controllable is the camera? Will it do stills? I would really like a stills based camera sensor on the pi, long exposure would be fantastic, any chance? Pretty please? :D

I have an astronomy project that I will be running on the pi, with webcams and astronomy cameras, so a pi based one could be very useful!!

For the folks who want to use a fancy camera with the Pi, can’t that generally be done through a USB interface of some sort? I thought the main point of a “raw” camera module interfaced straight to the GPU was the price (maybe, also size).

The USB link rate always limits the video quality. The effective data rate of USB is far below the 480 Mbits/s. The CSI camera talks to the Raspi using two 600Mbits/sec lanes. Also all the CPU power to receive the data leave little space for any processing data. Having it all in one device just means less data shuffling around and that is generally a good idea.

To me, it just has to be sharp enough so that my new Roomba Pi Robotic Security/Vacuum Cleaner Device can differentiate between an intruder and the cat in the middle of the night. It pains me no end when the thing Tasers the cat…

Awesome! I won’t mind the MP dowgrade at all. 5 MP would be more than enough!
Just one small question: How are you supposed to ‘mount’ the camera? It wouldn’t be very handy to stick a Raspberry Pi on your monitor or have it on your desk with the camera pointing to the ceiling.

Event if it is a prototype board, I did make two holes (2mm diam) in opposite corners. There is a screen shot of the camera adapter board in the CSI thread on the forum. As mentioned elsewhere: the issue is how long can we make the cable and still have it work reliably. Otherwise the holes don’t help much either.

Congrats, guys, very nice work. Not sure if you are using the OV14810 or OV14825 but either way an excellent choice for an image sensor. I looked at using this for the camera project I am (still) working on that I mention here form time to time, but rejected it for my purposes since it is a rolling shutter rather than a global one which limits its abiility to deliver detail on moving objects. This is absolutely a picky point, overall this is an EXCELLENT video sensor and I hope you build it up into a full camera module.

For some details, here’s links to the spec sheets and also a nice YouTube video that shows what I mean about motion blur using this sensor – overall very nice image definition and color, but you can’t read the text on the side of the toy train.

That’s not a rolling shutter issue, that’s simple an exposure time issue. I’m assuming 1080p30, so presumably the camera is exposing for as long a period as possible to reduce required gain, so about 1/30s, and I would expect that sort of blurring at that exposure time.

Not to say global shutter are not a better option for still capture when objects are moving fast.

I see Gert van Loo has mentioned a data pipeline of 100s of mbits per second.

Can anyone give an estimate of how long it would take to send a complete 5 megapixel camera image, uncompressed, and get it pushed to the Pi’s data card?

I’m interested in single images, not video, and I’m wondering what sort of fps rate could be hoped for given a 5 megapixel sensor, for obtaining and storing a continuous stream of uncompressed images.

While I’m asking, I wonder if it will be possible to just request a continuous feed of values from a single row of the image sensor, and whether that would increase the fps that might be received? And would there be a low-res mode that would allow faster retrieval?

I suspect the limiting factor will be the SD card write speed. An uncompressed 5 megapixel image will take up 15MB of space on disk, and ISTR that various forum threads have said the RPi can currently only write to SDcard (even high-speed ones) at about 4mb/sec (may be improved later?), so theoretically you’d be looking at about 4 seconds per image. If I’ve got my sums right, that means you’d be writing a gigabyte of data in less than 5 minutes. There’s a reason people use JPEG / H264 compression ;)
I have absolutely no ideas about your other questions!

Thanks. I wonder if the resources of the r-pi might be able to compress a 5 megapixel image to a more reasonable write size in a less than one second window? I’m hoping to build an inexpensive hand-feedable replacement for a single sided document scanner out of an r-pi, a tripod or frame, and some leds.

Well, the Pi can encode 1080p30 in real time. Stills to JPEG are not real time, but still faster than the SD card can write them I think. Easily faster than the 1 second you ask for. We have some phones using video core which can take at least 5 frames a second at that sort of resolution IIRC.

Please design a camera version with a short ribbon and one with a long ribbon. This will help people who have complex uses for the camera who need it some distance from the Pi board. Also it would be great if you could avoid using a hot filter on the camera units. Make it a bare bones photo sensor and let people add filters as and when they need them. It is really hard to remove them once they become built in.
Keep up the good work!

The ribbon cable is detachable. So you buy your own and swap it. We have to try and see what maximum length still works. (At the moment I know only one supplier in the UK which does the 15-wire version and that is Toby.)
But the Raspberry-Pi computer is so small you can hide both in a small box.

I am interested to hear more about the H264 1080p30 encoding license cost.
1) First, does the cost of the camera module include the the license fee?
2) If not, how much will it cost?
3) Does it need signing any NDA? If yes, can a hobbyist get one?

As mentioned: we are in the very early stages with the camera development and still have to sort out lots of details. But yes the camera module will include an H264 encoder license and no you can not get the module without the license or vice versa. That would be an administrative nightmare. No NDA as that would be an even bigger administrative nightmare. Details are not know yet but I suspect the H264 encoder will only be usable with the camera input.

yes, you are asking the impossible but my guess is probably late Autumn, at least before Christmas. As with the Pi we have to get manufacturing sorted out but in contrast to the Pi, there is only one difficult component and that is the camera itself.

I think you should provide several options for the camera size. I think you will be surprised how many people would be prepared to pay the extra for the 14 Mega pixel module.

I am really happy you are providing a camera module, but I have to ask what is the maximum distance the camera can be mounted away from the motherboard? I have built my own motorcycle camera system that powers on and begins recording within 20 seconds of the ignition being turned on. This utilises an Alix system board, a Mini PCI capture card and remote bullet camera. Ideally, I would like to replicate this setup with the Raspberry Pi, having the camera mounted on the front of the bike and have the Raspberry Pi tucked away from the elements and where it can’t be accessed without a key.

This is incredibly exciting! I am a complete newcomer to the programming world and hacks like this make me so excited!

I was wondering whether Gert, Naush and JamesH would be interested in helping me make the camera hack for the raspberry pi available for legal observers on protest? I realise it is still a prototype but I think it would make our work so much easier! If this interests you then please reply to this message and i’ll send you an email :)

That is totally awesome. Now what we need are CUDA drivers for the obviously quite capable GPU, so we can build an image processing module that can do feature tracking / object recognition / … stand-alone!

Wow! It appears that there is a second 15 pin plug on the left-centre of the RPi (the same as where the camera is plugged in now). What’s that for? Would it be possible to plug 2 camera modules into the RPi at the same time?

Sorry, no camera.That is a DSI (Serial Display Interface) port. It is just like the CSI but just in the opposite direction. In fact you could connect the DSI of one Pi to the CSI of another for a 2Gbits/sec link :-)

And to think I was *this* close to spending £250 on a GoPro Hero 2!
Can’t wait to try this out in the wild – I’m envisioning a Bramble of Raspberry Pi + Camera modules attached all over my Mountain Bike and Helmet all syncing their 1080p streams for some serious playback & telemetry gathering.
Can’t wait!

+1 for the 150mm cables, 51 is just too short to do anything really useful applications such as custom panoramic cameras using 4-5 PIs. Some major potential here, as soon as I see them avail I’ll buy 5!