Microsoft Cam Exposure Reseting To Automatic on Robot Reboot?

[Classified*]

Hello,

I am currently working on vision tracking to find the tape around the peg using the Microsoft Life Cam 3000, and I have been having a lingering problem. I am using LabVIEW. My vision processing code works great, but when I reboot the robot (Turn it off and back on, not just reboot the roboRIO), all of the camera settings (white balance and exposure) are returned to automatic. As we all know, vision doesn't work very well like this . Here is a screen shot of my Vision Processing.vi.

As soon as I restart robot code from the drivers station, however, the camera settings return to what I set them to in my code, but the target is extremely dim. Picture. When I redeploy the code, though, keeping the robot on, the target becomes very bright (how I want it to be). Picture. Both of these shots were taken with THE SAME CODE WITH THE SAME SETTINGS. The only difference was that the first was taken after turning the robot on and restarting robot code, while the second was taken after the robot had been on and new code had just been deployed.

Last offseason was our first time using vision tracking, and we had the same problem. At our offseason events, we got around it by quickly restarting robot code as soon as we got communication, but I have a feeling this would be frowned upon at a Regional. Also, this didn't solve the problem of it being dim, but we were okay after we recalibrated the thresholds to detect it like this.

I did a thorough search on CD and Google, but I found no mention of this issue. Any suggestions on how to fix this problem are much appreciated! Do I need to initialize the camera in Begin.vi instead of just in Vision Processing.vi? Is this a problem with the Life Cam? Has anyone else ever run into this issue?

Thanks!

-Julia Cecchetti

[microbuns]

Our team had a lot of similar issues when we tried the Microsoft Lifecam - as well as issues with its autofocus. We ended up switching to a fixed focus Axis camera, and it persisted its white balance and exposure settings as we wanted it to.

However, there is totally a chance that another team got it to work with the Microsoft camera.

[wt200999]

Originally Posted by Classified*

As soon as I restart robot code from the drivers station, however, the camera settings return to what I set them to in my code, but the target is extremely dim. Picture. When I redeploy the code, though, keeping the robot on, the target becomes very bright (how I want it to be). Picture. Both of these shots were taken with THE SAME CODE WITH THE SAME SETTINGS. The only difference was that the first was taken after turning the robot on and restarting robot code, while the second was taken after the robot had been on and new code had just been deployed.

To me the 1st image you showed seems like it would be easier to process, as I see much less green reflections and the green color is more consistent, it looks like it would be much kinder to the threshold step. Is there any particular reason you prefer the 2nd one?

For the camera it looks like the vision settings are only applied once when the vision start. The only difference between the two you describe above is whether or not the robot has been running for some time. Maybe the camera isn't 'ready' to start receiving commands when you first turn the robot on? I would start there, maybe you can monitor the error wire or send the error wire back to the dashboard to see if that has any hints. Maybe you need a delay before running the settings, or check if the camera is available first?

[Classified*]

Originally Posted by wt200999

To me the 1st image you showed seems like it would be easier to process, as I see much less green reflections and the green color is more consistent, it looks like it would be much kinder to the threshold step. Is there any particular reason you prefer the 2nd one?

For the camera it looks like the vision settings are only applied once when the vision start. The only difference between the two you describe above is whether or not the robot has been running for some time. Maybe the camera isn't 'ready' to start receiving commands when you first turn the robot on? I would start there, maybe you can monitor the error wire or send the error wire back to the dashboard to see if that has any hints. Maybe you need a delay before running the settings, or check if the camera is available first?

Thanks for these suggestions. I will try this and see if I can see what is happening. Another thing I just thought of is setting the exposure inside the loop just like the example code does with image size. This way it would be sure to set it correctly (I think). I know it's not the most efficient way to do it, but if all else fails it is better than nothing. This would also allow us to change the exposure back to auto during teleop for driver vision.

The reason the second one was preferred last year was because the goal was so much farther away that it was really, really dim. I had to set the threshold to see everything except pure black, which resulted in lots of noise. Luckily my algorithm for ranking the targets was robust, because at our competition we were seeing 10-20 particles because of the tower LEDs and ceiling lights. This year I have the code able to detect both the dim and bright versions with the same threshold and similar robust filtering/ranking algorithm, although this year there is less of a problem with noise because the camera is not looking toward the ceiling and there are no LEDs around the peg (except on the steam tank, but that's not much of a problem).

Our team had a lot of similar issues when we tried the Microsoft Lifecam - as well as issues with its autofocus. We ended up switching to a fixed focus Axis camera, and it persisted its white balance and exposure settings as we wanted it to.

I think we have a few Axis cameras laying around. I will try this also!

[Nebster]

This was a problem for us last year as well, we ended up switching to an axis camera. This year we are using a Logitech C270 webcam, which doesn't have the issue the Microsoft HD-3000 did.

[Classified*]

So,

Problem:

I tracked the errors, and the problem was indeed that the camera was not initializing before the code tried to apply settings to it.

Solution:

I solved this by setting the exposure inside of the while loop. This also allowed me to set the camera to have a low exposure for autonomous, and automatic exposure for teleop so the drivers can use it to see. Here is a screenshot for when auto is enabled (or disabled), and here is another for when teleop is enabled.

I hope this helps anyone with this problem in the future!