USB MS Lifecam HD 3000 Exposure Issues

After several weeks of adjusting and playing with calibrations, I have found that the lifecam’s exposure seems to be binary. What we are using is a USB MS Lifecam HD 3000 on Labview with NI Vision example code, and we are using a green LED to try to track the target. In the code I am setting the exposure by making it custom.
When I set the exposure to zero, the camera sees a green target and recognizes it properly. However, even when I change the value to one, the camera sees a white target and cannot find the target. I will change the values to go from one to one-hundred, and I cannot see any change. So, is the exposure acting binary, or am I doing something wrong?

We had this problem (although the exposure change was going from 5-6). Our solution? Tape a polarized sunglass lens over the camera. Works like a dream.

I have found this behavior to be typical for this camera.
Time to get creative!

I agree: this is a common issue with this camera and the tinted or polarized lens does help.

I’ve been setting the exposure using the Lifecam software. It’s been working well so far.

I haven’t tried using any of the FRC software to set the exposure, but I noticed that OpenCV has issues setting it as well. I’ve found that you can install v4l-utils (via opkg), and execute the following command:

v4l2-ctl -c exposure_auto=1 -c exposure_absolute=10

Works every time.

I’ve been having the same problem with some vision I’ve been running with open cv. Is it possible to integrate that command into the camera capture object? If I could do this in the initiation of my code that would be great. If possible how so?

Depends on your language, there are multiple ways to run external processes in each language. In python it would be something like:

import os
os.system('v4l2-ctl ... ')

And in C++ it’ll probably be something like:

#include <stdlib.h>

system("v4l2-ctl ...");

And in java it’ll be something like this:

Runtime.getRuntime().exec("v4l2-ctl ...");

Obviously, you will want to do error checking, and some languages provide better ways of doing this as well.

hey i know you




Anyone find a USB camera you can adjust exposure on?

A few years ago, when Patrick was a student on FRC11, and doing hard core collection of frames from Video4Linux directly into his own Java code on my Dell Mini 9’s with Microsoft USB cameras we discovered an annoying issue that basically abstracts away your ability to control the exposure (auto white balance) via the exposed registers on Linux (Ubuntu 9 Karmic at the time) with the Microsoft USB cameras we had and the newer models are not much different. Keeping in mind you have Linux on the RoboRIO but it is not Ubuntu.

We contacted the package maintainer who was part of the V4L project, which OpenCV draws from and GRIP depends on, but between us we weren’t able to expose whatever Microsoft had done with the OmniVision CMOS sensor in the core of their camera. I’ve been a long time user of OmniVision products which are at the core of some of the best webcams (more than 10 years) and it’s clearly something particular with the way this was used or the sensor was configured. I tried to pull in some friends from Microsoft but was not successful. A little transparency would have long ago solved this issue.

We were able get this to work from V4L directly into Java and OpenCV with Logitech cameras. Logitech has been pretty forthcoming with the Linux community for a long time (considering how many Logitech 3 button mice I used to buy for X-terminals where the middle button was a tricky matter).

This issue, by the way, is the reason I provided FRC11 the Logitech C920 USB cameras and why I recommended to several people on ChiefDelphi the Logitech cameras.

Take those same Microsoft branded cameras and put them on a Windows laptop and you’ll see the issue is much less a problem. The Windows drivers do something to the camera configuration that expands the response. I did consider, at one time, reversing the camera communications with my logic analyzer but, to be honest, the camera is too cheap to waste that kind of energy.

Normally I don’t expose this kind of interaction but this topic has been respectful so please continue to be polite so I don’t regret pointing out the likely problem.

Please see the thread here: (or other posts by robert1356).

Basically, you are not doing anything wrong, there’s a problem in the USBCamera class that prevents it from working correctly. You might be able to copy and modify the existing class, but it sends a value between 0-100 when it should be something much greater.

I don’t know if this works on a RoboRIO, but this does work on other Linux distributions:

This is a way to get V4L to tell you the range it thinks it can set for a value to the camera.
If V4L gives you the wrong range - then I am not at all surprised everything else would as well.

One way to test, if this can’t be built or compiled on the RoboRIO, is to put the camera on a similar enough Linux distribution on a PC or more open embedded system and try it. I may try this, this weekend, on my Intel Edison or ODroid XU4 or Raspberry Pi 2 with Yocto. I just want to see what range V4L thinks is available at the bottom of the stack. The RoboRIO might not be identical.

Because of this thread, and because I had some time to kill, I pulled out my RPi 2 and tried a few tests to see what I could figure out for the LifeCam HD-3000 and adjusting exposure.

The first step was to see if

V4l2-ctl -L

would list out a setting for exposure. Sure enough it does. You can set it to manual or Aperture Priority mode (auto).
When in manual mode, you need to set the exposure value with exposure_absolute. The range of values it reports as acceptable are: min=5, max=20000.

In testing I found that it still had what amounted to a binary response to inputs while in manual. Any value above 5 resulted in over exposure. 5 resulted in under exposure. It didn’t matter if I used anything from 6 to 20000, it was over exposed. 5 resulted in under exposure.

So now the next test is, can we set it to an exposure_absolute=5 and have a bright enough light shine on the target to get acceptable tracking of the target? (Enter the 3 X 3w LED ring).:cool:

It’s interesting the newer camera at least announces the range as higher. The older Microsoft camera, still with the OmniVision sensor, did not even manage that at the V4L stack layer. Still basically the same issue. Will try to grab one of my mothballed older Microsoft cameras and the dig up the contact information for the V4L project maintainer. I can also put mine on a Raspberry Pi 2 which I assume Bilbo has Raspbian on: or did you go the Arch route?

Latest Raspbian and OpenCV 2.4.9.

I think there’s something more going on. Using the Microsoft lifecam software you can get varying exposure with out it appearing so binary.

But I don’t have more to contribute than that. One option we’ve considered is running a monitor/keyboard with the Kangaroo and having settings for the lifecam set on that. As long as the lifecam doesn’t get power cycled, it maintains its exposure and brightness settings.

Correct - the Windows drivers for the Microsoft USB cameras know how to configure the Microsoft hardware correctly. So on a Kangaroo running Windows it is likely no issue.

Much like this custom driver for the PS3 Eye:

However most of the video capture related software in use on the Linux RoboRIO depend on V4L’s ability to configure said cameras (GRIP uses OpenCV which uses V4L). As Billbo911 has demonstrated above - on a bunch of models of the Microsoft cameras it doesn’t work like you would expect. The V4L project is the core common solution to USB webcam support for Linux systems. If that doesn’t work for a particular camera it either needs to be addressed there or a lot of development work would need to happen to create another framework unique to a camera. Course a brighter light or tinted lens as a hack works as well.

Interesting that you should mention this specific camera. I was playing around with mine just today as well. I wanted to see if it was recognized natively by Raspbian, and it was. It has more configuration options accessible via V4L than the MS LifeCam does. That said, the image is much noisier than I would ever want to use. I will try to do some additional testing with it and see if the noise is an issue or not. Currently it is just another option for us, but it is somewhat on hold until we compete next weekend. Depending on the outcome of that tournament, I may spend a bit more time on it.