Hi Rod, I was wondering if you could give me a little bit more info about the issue you're having. I'm trying to replicate it so I can help you figure out what is going on.

1. Which model Raspberry Pi are you using?
2. What kernel are you running?
3. You mentioned being able to use a Python script to use the camera successfully. Does the raspistill command work as well?
4. Can you use your Python script successfully, then immediately get an error from Mathematica (ie, no rebooting or anything in between)?
5. Are you using any GPIO devices on your Pi at the same time as your camera?

Thanks, Brett

I've just started and discovered how to run external commands:

<<"!command"

This means I can use fswebcam to capture an image which can then be imported. A work around where there's no webcam driver.

Best regards, Colin

Phew! Thanks very much for posting this, I was on the brink of removing Mathematica from my raspi.

Hopefully this change will be reflected in a future update, the cam is a great toy to play with in Mathematica and such hiccoughs are likely to deter folks from getting into the swing of things.

It would be nice if support were added for external cameras, possibly through PTP, as part of the device connectivty effort.

Example application: I once wanted to control a DSLR using Mathematica to record a time lapse during sunset. (Why Mathematica?  Because it's a high level, easy to use language that I know well.)  Finally I gave up because (at that time) it would have been too much work to connect the device to Mathematica.  The point of controlling the camera through the computer was twofold: it didn't have a built-in intervalometer, and it didn't quite get the metering completely right throughout the changing lighting conditions.  I was planning to continuously vary the settings according to a pre-recorded profile from the previous day, and not use the camera metering at all.  To be fair, this kind of control is not really needed with a newer and higher quality camera that has a built-in intervalometer and more reliable metering.

I am also having the same experience as Bob L - the DeviceRead[ "Raspicam" ] hangs, but the Import from shell works as expected, taking ~0.5 secs.

I am running RPi MMA 10.0 for Linux ARM (32-bit) (Nov 19,2013). I am using latest NOOB with updates.

Thanks for the response, Lambert, but it wasn't a typo. I tried it because that was the name returned by $ImagingDevices and was the $DefaultImagingDevice. Out here in the near perfect  vacuum of documentation space, we have no way to know whether something is "supported" or not except to try it and see whether we can understand the response.

The only sensible way I've found so far to get an RPi camera image is to use Import as Arnoud suggested earlier in this thread and wrap it in a function that exposes the optional parameters of raspistill such as:

In all of this, the most awkward feature is that there are so many ways to fail ugly - if the camera hangs, there's no way to recover except to reset the power on the board, and DeviceRead, as a blocking function, inherently fails ugly - hanging beyond <command .> and sometimes beyond kernel kill. There ought to be a way to first validate the camera state before requesting the image and second, to be able to soft reset it when it does hang. It would seem that the camera validation would be required first, because a hanging DeviceRead would prevent any way to DeviceWrite a reset to the camera (if indeed such a thing exists.) I suppose both of these could be done on the RPi in Python in a more graceful way and avoid the blocking of the Mma front end.

I haven't looked at whether Import or DeviceRead fail more gracefully than the other.

I've encountered two flavors of camera hang. One in which there's some kind of software loop, where the LED blinks on and off with a period of about a second (this one times out after a period of some minutes I haven't actually measured) and another flavor where the LED comes on and stays on, a condition requiring a power off reset.

Any ideas?

BTW, I don't know how or when I became "Updating Name."

Fred Klingener

I'm experimenting with RPi's camera, running the RPi's kernel remotely via a notebook in Mathematica on a Macbook Pro. 

I've found the following oddity:but
works as intended.
Further:produces a camera image in a way indistinguishable from that produced by DeviceRead["RaspiCam"].

And apparently ImageCapture[] isn't related to any of this, producing on the one hand a nonopt message if either "Raspicam" or "RaspiCam" is specified as a parameter, and on the other, in the case of the default ImageCapture[], a hanging camera, cycling its LED on and off endlessly with a period of about a second. I haven't timed it, but the blinking condition will reset after some minutes.

If I run DeviceRead["RaspiCam"] while the camera LED is cycling, the command hangs in Mathematica and the RPi camera LED lights and stays on. Evidently, the only way out is to reset the power on the RPi and kill its kernel in the Mathematica notebook.

The only way out I've found is to cycle the RPi power and restart its kernel once the RPi has rebooted.
Hth,
Fred Klingener

Kay,

Another way is to use ImportString like so:



The exclamation (!) before 'raspistill' tells Import to run the command and read the result from the standard output channel (stdout). In this case it is important to tell raspistill to send its result to stdout with '-o -'.

Are you doing this in a Mathematica notebook on the pi?  What is the CPU Usage Monitor showing during the evaluation?

Did you start Wolfram/Mathematica as sudo?

This is not currently supported, but it is functionality we'll add.  Thanks for your suggestion.