problems with webcams

Hi,

I’m running Ubuntu 11.10 and I’m trying to develop an application using opencv and a webcam. I’m running into problems whenever I try for resolutions higher than 320x240. I tried using the Ps3Eye (driver is gspca_ov534) and the logitech C260 (driver is uvcvideo). At 320x240 it seems to work fine and I get a saved image with the occasional “select timeout” error.

However, when I try to run at 640x480 I get this output (with a black image file):

VIDIOC_QUERYMENU: Invalid argument
VIDIOC_QUERYMENU: Invalid argument
VIDIOC_QUERYMENU: Invalid argument
VIDIOC_QUERYMENU: Invalid argument
Resolution set, entering loop…
select timeout
select timeout
Saving Image

Any ideas on how to fix this error? It would be great to be able to save higher resolution images… are there other ways to grab a still from the webcam?

`
Enter code here…

CvCapture* capture = 0;

capture = cvCaptureFromCAM(-1);

//set camera resolution to low, perform object detection
//then set resolution to high, and capture images

cvSetCaptureProperty( capture, CV_CAP_PROP_FRAME_WIDTH, 640 );
cvSetCaptureProperty( capture, CV_CAP_PROP_FRAME_HEIGHT, 480 );

if (!capture)
printf(“error opening capture”);
else
{
printf(“Resolution set, entering loop… \r\n”);
IplImage* image = cvQueryFrame( capture );
image = cvQueryFrame( capture );

if( !image )
return 0;

printf(“Saving Image\n\r”);
cvSaveImage(“cam.jpg”, image); //save the image
//start=time(NULL); //get current time in seconds

}

`

You can ignore the QUERYMENU error messages. Some cameras don’t support this optional call and OpenCV whines when it doesn’t get a response. When it does get a response it just throws the information away.

It has been several months since I last tried capturing OpenCV images on my dusty Beaglebone (using Ubuntu, not Angstrom). Back then I encountered two problems. One was that the USB machinery in the kernel wasn’t up to snuff and could not deliver images across the USB bus quickly enough. I have no idea if that problem has been fixed since my webcam project is on the back burner.

The second problem was that the OpenCV code was asking video4linux (v4l) to deliver RGB frames. v4l was in turn grabbing JPEG compressed RGB images from the camera and decompressing them using a very slow software-based JPEG decoder. No doubt that decoder uses a lot of floating-point and is fast enough on desktop machines but terribly slow on the Beaglebone and Beagleboard-XM.

I was able to get much better capture frame rates once I wrote my own code to capture uncompressed YUV images and hand-convert them to RGB or grayscale. My C++ classes for doing this are hosted in a Mercurial repository at https://bitbucket.org/beldenfox/cvcapture. They are pretty minimal; I did only as much as I needed to get things working for my specific camera. You can dig up similar sample code on the web to fill in any gaps.

Martin

PS. I tracked down the JPEG performance problem using the ‘perf’ utility which was easy to install and use under Ubuntu. Highly recommended.

Thanks for your insights, Martin.

As an update, I have dug into the OpenCV source code a little bit and believe that I may have found the source of my problem. In /OpenCV/modules/highgui/src/ there are two files named “cap_v4l.cpp” and “cap_lib_v4l.cpp” that seem to be handling the camera through the Video4Linux API. Both of these files querey the camera’s capabilities (including the maximum height/width supported by the camera). It does this by first determining if the device is V4L or V4L2 compatible and then doing something like:

/* Query the newly opened device for its capabilities */

//# if V4L:

ioctl(capture->deviceHandle, VIDIOCGCAP, &capture->capability)

//# if V4L2:

xioctl (capture->deviceHandle, VIDIOC_QUERYCAP, &capture->cap)

And later, the OpenCV code attempts to readjust the resolution to be less than or equal to the maximum supported resolution. (I’m working with version 2.4.2 of OpenCV – available here: OpenCV - Browse Files at SourceForge.net)

if (capture==0) return 0;

if (w>capture->capability.maxwidth) {

w=capture->capability.maxwidth;

}

if (h>capture->capability.maxheight) {

h=capture->capability.maxheight;

}

capture->captureWindow.width=w;

capture->captureWindow.height=h;

//# (other stuff)

}

Again, I know that my camera (PS3 Eye) supports 640x480 resolution (and I have confirmed this by invoking “v4l2-ctl -V” in a terminal window on the beagle bone, which reports 320x240 and 640x480 as supported resolutions. This leads me to believe that OpenCV is not querying the camera’s resolution correctly. I have tried to comment out the lines that resize the height/width and rebuild OpenCV from source on the BeagleBone using the simple cmake/ make/ make install instructions provided here (http://opencv.willowgarage.com/wiki/InstallGuide_Linux), but end up with some kind of “Out of memory” error about 76% of the way through the build. I have started looking into cross-compiling OpenCV for the BeagleBone, but haven’t got a clue what I am doing and have no idea if commenting out these lines would solve my problem anyways.

Can anyone offer any advice on how I should proceed with this? Many thanks to anyone who takes a look at this.

(I’m not sure that v4l2-ctl -V is totally accurate according to this: http://www.mattfischer.com/blog/?p=211 )

The sane way to approach this (for me) was to take one of the files you mentioned (cap_lib_v4l.cpp) and get it to compile outside of OpenCV. For the most part it’s just standard v4l2 capture code adapted from readily available sample code. Then at the very end the image data is packaged with an OpenCV wrapper. Its all based on publicly available v4l and OpenCV headers so it can be isolated.

The code I pointed to earlier (https://bitbucket.org/beldenfox/cvcapture) is basically the v4l2-compatible path of cap_lib_v4l.cpp that’s been cleaned up, pared down, and packaged with its own CMake files so it can be compiled outside of OpenCV. All you need is the development files for libv4l2, which in Ubunutu you can get by installing the libv4l-dev package. Even if the code doesn’t work for you at least it would give you a blob of v4l video-capture code that can be compiled outside of OpenCV itself. You can build up from there by copying and pasting from the OpenCV sources.

You don’t mention if you’re getting the QUERYMENU error messages. If you are you’re using the v4l2-compatible path in the code, in which case the maxwidth and maxheight checks are not being applied (based on my somewhat hasty reading of the code.)

I have managed to compile OpenCV 2.4.2 on a BeagleBoard-XM with an external hard drive. It took almost two hours. I really doubt you can compile it on a BeagleBone. I gave up on trying to cross-compile it; OpenCV relies on a bunch of external libraries (like v4l and jpeg) and I never figured out how to download the necessary libraries and insert them into a cross-compilation environment.

Thanks for your prompt reply,

But as it turns out, I don’t think OpenCV is my problem after all. I tried capturing frames from the command line using “ffmpeg” and still had bad results. As a point of comparison, I tried to capture some frames on my desktop’s Ubuntu partition through OpenCV. I had no problems at all and even the 320x240 frames were much clearer than I was able to get with the BeagleBone.

To see what was going on, I tried calling “dmesg” on my desktop as well as the BealeBone. I noticed that my desktop was interfacing with the webcam with something called ehci_hcd while the BB was using musb-hdrc.

BeagleBoard

[ 5.277099] PHY 0:01 not found

[ 5.289520] ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 76.481750] usb 1-1: new high-speed USB device number 2 using musb-hdrc

[ 76.624176] usb 1-1: New USB device found, idVendor=1415, idProduct=2000

[ 76.624206] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[ 76.624237] usb 1-1: Product: USB Camera-B4.09.24.1

[ 76.624237] usb 1-1: Manufacturer: OmniVision Technologies, Inc.

[ 77.393920] gspca_main: v2.14.0 registered

[ 77.401489] gspca_main: ov534-2.14.0 probing 1415:2000

[ 77.563629] usbcore: registered new interface driver ov534

Desktop:

[ 577.672908] ftdi_sio 1-2.1:1.1: device disconnected

[ 583.768329] usb 1-2: new high-speed USB device number 5 using ehci_hcd

[ 583.903707] usb 1-2: New USB device found, idVendor=1415, idProduct=2000

[ 583.903718] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[ 583.903725] usb 1-2: Product: USB Camera-B4.09.24.1

[ 583.903732] usb 1-2: Manufacturer: OmniVision Technologies, Inc.

[ 583.985507] gspca_main: v2.14.0 registered

[ 583.990621] gspca_main: ov534-2.14.0 probing 1415:2000

[ 585.594388] usbcore: registered new interface driver snd-usb-audio

[ 585.595905] usbcore: registered new interface driver ov534

It looks like these are some kind of Linux USB drivers. A call to “modinfo” confirmed that the ehci_hcd driver was not installed on the BB but was on my desktop. I found an (alleged) solution here: Redirecting to Google Groups that relates to the ehci_hcd driver provided by Krcevina. I have not yet attempted to apply the fix. (I am brand new to Linux, and learning as I go has been quite slow.)

Do you have any knowledge of the Linux USB drivers? If so, do you think this could potentially be the culprit? My only rationale is that the USB is being slowed to USB 1 speeds instead of using USB 2.0. Thoughts?

Thank you once again for taking the time to help me out. I appreciate it very much!
-Mike

Not quite an answer, but I’m experiencing similar problems. I just posted the specifics of the code I’m running to StackOverflow. Really trying to get this to go.

The poor floating-point performance I mentioned in my initial post will probably affect just about any video-capture path that requests JPEG frames from the camera and decompresses them. It is likely that ffmpeg is doing this by default; it’s a reasonable thing to do on a desktop machine since it reduces the USB bandwidth and desktop machine generally have blazing fast floating-point units (compared to the dismal FPU’s on the Beagles). It is worth doing some research to determine if ffmpeg can be manipulated to grab YUV frames from the camera so you can eliminate that bottleneck. For OpenCV work the only solution was to write my own capture code. (By the way, you can track software issues like this down using the “perf” utility.)

Several months ago when I was working on my project there were well-known kernel issues with the USB DMA machinery on the BeagleBone. I have no idea where that stands now. My initial work was on the BeagleBoard-XM which has the floating-point bottleneck but not the USB one and my project was put on hold just as I began working with the Bone.

I did find this solution: OpenCV v4l2 select timeout error SOLVED! High FPS! - Raspberry Pi Forums

I get the following output to my screen:

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QUERYMENU: Invalid argument

VIDIOC_QBUF: Invalid argument

VIDIOC_QBUF: Invalid argument

VIDIOC_QBUF: Invalid argument

VIDIOC_QBUF: Invalid argument

VIDIOC_QBUF: Invalid argument

VIDIOC_QBUF: Invalid argument

and I do get a 640x480 frame. Unfortunately it is completely garbled (attached)

I am switching to a Logitech c270 webcam, by the way, to see if I can get that working first. (It is a supported UVC device.)

Hi Martin,

I hate to ask such an embarrassingly simple question – but I am in completely unfamiliar territory and need to get this working ASAP so I can get back on track with my thesis:

I’m convinced that OpenCV’s handling of the V4L2 API is indeed the issue. (I have found examples of people being able to capture higher-res frames on the BeagleBone without OpenCV). So I would like to try bypassing OpenCV’s buggy camera capture functionality by using your custom code. However, I’m not sure what exactly I need to do to implement your code into my project. Do I need to use Cmake to build a binary of some sort? – because when I try to do this, I get an error (below). I know that all of the OpenCV libraries and includes are indeed installed (by default with the stock Angstrom image I am using).

Instead of using Cmake, can I simply add an #include “OCVcapture.h” line to my main file, modify my code to use an instantiation of your OCVcapture object to capture frames, and compile everything with the g++ compiler as I usually do?
i.e. g++ -Wall MyCode.cpp OCVcapture.cpp -o MyCode.o -I /usr/include -L /usr/lib -lopencv_core -lopencv_highgui -lopencv_imgproc

Also what frame rate can I expect to with your code? Ideally, I would like to get around 10 frames per second.

Thanks a ton for your help! If I cannot get this to work, I may need to move to another board.
-Mike

CMake Error at CMakeLists.txt:15 (find_package):
  Could not find module FindOpenCV.cmake or a configuration file for package
  OpenCV.

  Adjust CMAKE_MODULE_PATH to find FindOpenCV.cmake or set OpenCV_DIR to the
  directory containing a CMake configuration file for OpenCV.  The file will
  have one of the following names:

    OpenCVConfig.cmake
    opencv-config.cmake

Yes, just compile my code into your project as you describe. It needs to link against the v4l2 library, so add -lv4l2 to your command line and it should work. I compiled my sample application on Ubuntu using just this line:

g++ camera.cpp OCVCapture.cpp -lopencv_core -lopencv_highgui -lv4l2

I have no idea what frame rate you can expect. I didn’t take measurements back when I was working on the Bone. At the time the USB drivers were in such poor shape there didn’t seem to be much point so I just worked with a BeagleBoard-XM instead.

Update: I set up a simple OpenCV script to capture frames using the tools developed by Martin Fox. 320x240 frames are captured no problems, but no luck at 640x480 – same select timeout errors. The result was the same for all three cameras I tried:

Capture: capabilities 5000001

Capture: channel 0

Capture: input 0 ov534 0

Capture: format YUYV YUYV

Capture: format RGB3 RGB3

Capture: format BGR3 BGR3

Capture: format YU12 YU12

Capture: format YV12 YV12

Capture: dimensions 640 x 480

Capture: bytes per line 1280

Capture: frame rate 30 fps

Capture: 4 buffers allocated

Capture: buffer length 614400

Capture: buffer length 614400

Capture: buffer length 614400

Capture: buffer length 614400

Capture 640 x 480 pixels at 30 fps

Capture: select timeout

Capture: select timeout

Any other ideas?

Just out of curiosity:

Have you had a look at the “motion” package (http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome)?

I am using this on a beaglebone A3 board running ubuntu. Motion can be installed using “sudo apt-get install motion”. On my board it can capture 640x480 images without problems.

I am not sure if motion uses OpenCV or how it grabs images from the camera.

But maybe worth a look if you can get it to work for your camera and board, and if it works take a look at how it does the capture, I believe there is source code available.

Martin

I haven’t, but I’ll start looking into it. Thanks for the recommendation!

Hi Martin,

Sorry it took me so long to get back. I was having problems getting a stable version of Ubuntu installed on my board. A new version was just released and that solved my problems.

I just installed the motion package. I copied the default motion.conf file to my working directory, renamed it, and changed the width and height values to 320 and 240, respectively – Everything works as expected using the PS3 Eye:

ubuntu@arm:~/Motion$ motion -c loResMotion.conf
[0] Processing thread 0 - config file hiResMotion.conf
[0] Motion 3.2.12 Started
[0] ffmpeg LIBAVCODEC_BUILD 3482368 LIBAVFORMAT_BUILD 3478784
[0] Thread 1 is from hiResMotion.conf
[0] motion-httpd/3.2.12 running, accepting connections
[0] motion-httpd: waiting for data on port TCP 8080
[1] Thread 1 started
[1] cap.driver: “ov534”
[1] cap.card: “USB Camera-B4.09.24.1”
[1] cap.bus_info: “usb-musb-hdrc.1-1”
[1] cap.capabilities=0x05000001
[1] - VIDEO_CAPTURE
[1] - READWRITE
[1] - STREAMING
[1] Config palette index 8 (YU12) doesn’t work.
[1] Supported palettes:
[1] 0: YUYV (YUYV)
[1] Selected palette YUYV
[1] Test palette YUYV (320x240)
[1] Using palette YUYV (320x240) bytesperlines 640 sizeimage 153600 colorspace 00000008
[1] found control 0x00980900, “Brightness”, range 0,255
[1] “Brightness”, default 0, current 0
[1] found control 0x00980901, “Contrast”, range 0,255
[1] “Contrast”, default 32, current 32
[1] found control 0x00980911, “Exposure”, range 0,255
[1] “Exposure”, default 120, current 120
[1] found control 0x00980912, “Auto Gain”, range 0,1
[1] “Auto Gain”, default 1, current 1
[1] found control 0x00980913, “Main Gain”, range 0,63
[1] “Main Gain”, default 20, current 20
[1] mmap information:
[1] frames=4
[1] 0 length=155648
[1] 1 length=155648
[1] 2 length=155648
[1] 3 length=155648
[1] Using V4L2
[1] Resizing pre_capture buffer to 1 items
[1] Started stream webcam server in port 8081
[1] File of type 8 saved to: /tmp/motion/01-20130402201014.swf
[1] File of type 1 saved to: /tmp/motion/01-20130402201014-00.jpg
[1] File of type 1 saved to: /tmp/motion/01-20130402201018-01.jpg
[1] File of type 1 saved to: /tmp/motion/01-20130402201019-01.jpg
[1] File of type 1 saved to: /tmp/motion/01-20130402201021-00.jpg

But if I change the height and width in the conf file to 640 and 480, respectively, I get the following:

ubuntu@arm:~/Motion$ motion -c hiResMotion.conf
[0] Processing thread 0 - config file hiResMotion.conf
[0] Motion 3.2.12 Started
[0] ffmpeg LIBAVCODEC_BUILD 3482368 LIBAVFORMAT_BUILD 3478784
[0] Thread 1 is from hiResMotion.conf
[0] motion-httpd/3.2.12 running, accepting connections
[0] motion-httpd: waiting for data on port TCP 8080
[1] Thread 1 started
[1] cap.driver: “ov534”
[1] cap.card: “USB Camera-B4.09.24.1”
[1] cap.bus_info: “usb-musb-hdrc.1-1”
[1] cap.capabilities=0x05000001
[1] - VIDEO_CAPTURE
[1] - READWRITE
[1] - STREAMING
[1] Config palette index 8 (YU12) doesn’t work.
[1] Supported palettes:
[1] 0: YUYV (YUYV)
[1] Selected palette YUYV
[1] Test palette YUYV (640x480)
[1] Using palette YUYV (640x480) bytesperlines 1280 sizeimage 614400 colorspace 00000008
[1] found control 0x00980900, “Brightness”, range 0,255
[1] “Brightness”, default 0, current 0
[1] found control 0x00980901, “Contrast”, range 0,255
[1] “Contrast”, default 32, current 32
[1] found control 0x00980911, “Exposure”, range 0,255
[1] “Exposure”, default 120, current 120
[1] found control 0x00980912, “Auto Gain”, range 0,1
[1] “Auto Gain”, default 1, current 1
[1] found control 0x00980913, “Main Gain”, range 0,63
[1] “Main Gain”, default 20, current 20
[1] mmap information:
[1] frames=4
[1] 0 length=614400
[1] 1 length=614400
[1] 2 length=614400
[1] 3 length=614400
[1] Using V4L2
[1] Resizing pre_capture buffer to 1 items
[1] v4l2_next: VIDIOC_DQBUF: EIO (s->pframe 0): Input/output error
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] Error capturing first image
[1] Started stream webcam server in port 8081
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] Video device fatal error - Closing video device
[1] Closing video device /dev/video0
[1] Retrying until successful connection with camera
[1] cap.driver: “ov534”
[1] cap.card: “USB Camera-B4.09.24.1”
[1] cap.bus_info: “usb-musb-hdrc.1-1”
[1] cap.capabilities=0x05000001
[1] - VIDEO_CAPTURE
[1] - READWRITE
[1] - STREAMING
[1] Config palette index 8 (YU12) doesn’t work.
[1] Supported palettes:
[1] 0: YUYV (YUYV)
[1] Selected palette YUYV
[1] Test palette YUYV (640x480)
[1] Using palette YUYV (640x480) bytesperlines 1280 sizeimage 614400 colorspace 00000008
[1] found control 0x00980900, “Brightness”, range 0,255
[1] “Brightness”, default 0, current 0
[1] found control 0x00980901, “Contrast”, range 0,255
[1] “Contrast”, default 32, current 32
[1] found control 0x00980911, “Exposure”, range 0,255
[1] “Exposure”, default 120, current 120
[1] found control 0x00980912, “Auto Gain”, range 0,1
[1] “Auto Gain”, default 1, current 1
[1] found control 0x00980913, “Main Gain”, range 0,63
[1] “Main Gain”, default 20, current 20
[1] mmap information:
[1] frames=4
[1] 0 length=614400
[1] 1 length=614400
[1] 2 length=614400
[1] 3 length=614400
[1] Using V4L2
[1] v4l2_next: VIDIOC_DQBUF: EIO (s->pframe 0): Input/output error
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] Video device fatal error - Closing video device
[1] Closing video device /dev/video0
^C[0] httpd - Finishing
[0] httpd Closing
[0] httpd thread exit
[1] Thread exiting
[0] Motion terminating

It looks like the motion package is using Video4Linux, according to the Motion homepage. Besides the fact that I am using a Rev. A6a board, what could possibly be different in my setup compared to yours? I am running the 2013-03-28 Quantal 12.10 version of Ubuntu for BeagleBone.

Thanks!

sorry just to be clear… the conf file i used was actually called hiResMotion.conf both times. i just changed the resolution between the two instances.

Hi Martin,

I’m not sure if you’re still interested in helping me, but I did want to let you know that I have finally been able to grab 640x480 frames on my BeagleBone from the PS3 webcam. I did end up using your custom capture code since the framerate setting in OpenCV doesn’t work. (Thanks!)

I am able to set the camera to 15fps and capture frames without select timeout errors, however I end up with significant motion blur due to the low framerate. (Again, I plan to put this system on an airplane, so that won’t cut it for me.) I blindly made a couple of adjustments to your code, and am able to get frames with the camera set at 30 fps if I open 3 instances of my program, then close two. (This is what I have to do on my Mac with the 3rd party macam driver for the PS3 Eye – thats where I got the idea from.) Unfortunately, even at the 30 fps setting, I really am only getting about 10.

For my application, it is okay if I only grab frames at 10 Hz, but I need to have the camera operating at high enough of a frame rate that I can eliminate motion blur. I’m not very familiar with Video4Linux or the nitty-gritty of capturing frames from a webcam, so I was wondering if you might be able to provide some guidance. Is there any way to be able to eliminate motion blur with a slow embedded processor and just tolerate dropped frames, or am I pretty much hosed?

Michael,

Would you be willing to tell me how you got the PS3Eye running at 640x480? I am running Arch Linux, and the best I can do is 320x240 even when using custom capture code. The call to Select() in V4L2 times out regardless of how long the timeout is. The camera’s capture led comes on when the code executes so I suspect it is an issue with the amount of data the camera tries to bulk transfer over usb.

Thanks for your help and work,
Matthew

Hi Matthew,

I have been able to get 640x480, but not at a very high framerate. I’ve spent a lot of time asking questions in different forums so let me see if I can condense things down to one or two links for you. (I haven’t touched the vision part of my thesis for awhile so its all a bit foggy in my memory. I will be returning to BeagleBone vision work in the next couple of weeks so hopefully I can be of more help soon.):

I have three posts on this page starting at May 11 (way towards the bottom of the page). It links to some sloppy code that I put up on GitHub. You might find it useful. I believe I was running the most recent version of Ubuntu for the BeagleBone at the time.
Max Thrun's Project Blog: PS3 Eye Driver Patch

If I remember right, the biggest problem was that the standard OpenCV capture code does not adjust the camera framerate like it should (i.e. if you try to set the framerate to 30 fps, the camera actually stays at the default 60 fps setting). I haven’t been able to capture 640x480 at 60 fps, (possibly limitations of the board’s hardware?) so you have to settle for a lower framerate. To actually set the framerate you have to use a custom piece of capture code that you can compile along with the rest of your project.

Let me know if you get any farther with any of that. As I said, I will try and get back in touch within a couple of weeks when I am working with this stuff again. Go ahead and shoot me a reminder message just in case I forget.

Best of luck.
-Mike

Matthew,

Well I am back to working with BeagleBone/OpenCV. This time I am using the BeagleBone Black. I had hoped that the faster processor, additional RAM, and on-board eMMC might have somehow made a difference, but I am not able to capture images at 640x480 resolution with the new board. For my first attempts, I have tried to stick with the standard Angstrom image that ships with the BBB. I have tried a few different command-line video4linux capture utilities (fswebcam and v4l2-ctl/v4l2grab), but cannot get images at the higher resolution.

So I know that the problem is not with OpenCV. The problem must either be in the video4linux2 API, or the gspca-ov534 driver that is built-into the kernel version that the standard Angstrom build is using. Or worse, it could be a problem with the hardware itself.

I’m quite new to linux and embedded systems in general, but I will keep trying to track down the problem. I think I will try and install the Ubuntu image for the BBB and see if that improves things, as it might use a newer kernel version. It has been a long time, but I remember that my marginal success came after tweaking some things in the linux kernel for the Ubuntu image and building it myself – what a headache!

Let me know if you make any progress on this. What project are you working on that you need to use the PS3 Eye, anyways? (Just curious) If you have the time to help me track down the issue I have some email correspondence and online forum posts that I can share with you as they might be helpful . If I can get this to work, the rest of my master’s thesis should be smooth sailing from here on out, so I definitely have the motivation to get this figured out.

I’ll keep you updated on my successes and (more likely) failures with you.

• Mike