Saving Camera Exposure and White Balance Holds after Restart?

[TheDominis]

I think you'd have to write a save or something to the camera. Perhaps if you manually connect and save the settings you can accomplish this.

Also what you do mean by "exceptionally well"?

[Tom Line]

Without knowing what language you are working in, I can tell you that in Labview those settings can be set using VI's. I think the initial robot framework comes with them in the Begin VI, though we've moved things around so much I can't remember if that's where they started at.

Remember the CRIO logs into the camera and uses what it sees in the programming code to modify settings, so setting them on the camera will probably not save them.

[Mr. Lim]

We are working in C++.

The API provides two functions:

void AxisCamera::writeExposureControl  ( ExposureT  exposureControl  )   

Parameters:
 valid  values are automatic, hold, flickerfree50, flickerfree60  

void AxisCamera::writeWhiteBalance  ( WhiteBalanceT  whiteBalance  )   

Parameters:
 valid  values automatic, hold, fixed_outdoor1, fixed_outdoor2, fixed_indoor,fixed_flour1, fixed_flour2

When setting both of these to HOLD in code, the camera appears to still stay in AUTOMATIC. Upon immediately logging in to the camera's web interface, it confirms that the camera is still in AUTOMATIC mode.

Furthermore, there doesn't seem to be a way to programmatically "set" an exposure or white balance level, either through the API or web interface.

For those using LabVIEW, can you verify that you can change the exposure and white balance settings to HOLD, and confirm that they actually changed through the camera's web interface?

[TheDominis]

Saving the camera settings via web doesn't work? Try using the first account used to authenticate and saving the settings there. The first account is FRC, FRC.

[Mr. Lim]

Originally Posted by TheDominis

Saving the camera settings via web doesn't work? Try using the first account used to authenticate and saving the settings there. The first account is FRC, FRC.

Saving settings via the web does work temporarily, until you power cycle the robot. The settings revert to AUTOMATIC once you turn the robot off and on again.

[jhersh]

Originally Posted by Mr. Lim

Saving settings via the web does work temporarily, until you power cycle the robot. The settings revert to AUTOMATIC once you turn the robot off and on again.

Is it possible that your robot code is logging in to the camera and changing them to automatic (possibly with the API being buggy and not setting it to what you request)? How about if you just power off the camera and back on... does it retain the settings then?

-Joe

[Greg McKaskle]

The camera capabilities do not allow you to set the exposure to an explicit value in any language. The two choices are the ones you are already using, auto and hold. The calibration routine you are using to dim the image sounds good, and should stick with the camera through power cycles, but not through a reset button.

The LV template sets all fields in Begin.vi. It didn't do that last year, and in fact teams would have odd side effects from logging into the camera and messing with fields. If you do not want the code to change the settings, look for the API call in your team template code, or possibly in the framework. I'm going to speak with the WPI folks later, and I'll ask if they are possibly doing something like this in a constructor.

A second way to get a more dim image is to use the Brightness setting on the camera. What it does is to take the exposure value computed by auto and increase or decrease it. It is particularly useful when the camera's auto selects an overexposed image. Set Brightness low and see if your image has a similar exposure.

As for why the ellipse detection works better with more dim images. It may be that you've set the threshold very high, and bright lights cause blooming in the image. The white bleeds into the black and blurs the edge. I'm just guessing here. Also, you may have set the jpeg compression a bit high, and the jpeg artifacts are more bothersome in the brighter image. Can't say for sure, but if you'll tell me what settings you are using, I may have more input.

Greg McKaskle

[jhersh]

Originally Posted by Mr. Lim

We are working in C++.

The API provides two functions:

void AxisCamera::writeExposureControl  ( ExposureT  exposureControl  )   

Parameters:
 valid  values are automatic, hold, flickerfree50, flickerfree60  

void AxisCamera::writeWhiteBalance  ( WhiteBalanceT  whiteBalance  )   

Parameters:
 valid  values automatic, hold, fixed_outdoor1, fixed_outdoor2, fixed_indoor,fixed_flour1, fixed_flour2

When setting both of these to HOLD in code, the camera appears to still stay in AUTOMATIC. Upon immediately logging in to the camera's web interface, it confirms that the camera is still in AUTOMATIC mode.

Furthermore, there doesn't seem to be a way to programmatically "set" an exposure or white balance level, either through the API or web interface.

For those using LabVIEW, can you verify that you can change the exposure and white balance settings to HOLD, and confirm that they actually changed through the camera's web interface?

I was refactoring the AxisCamera class last night and found 3 bugs that prevent the C++ implementation from successfully setting the rotation, exposure, and white balance. This is likely why it's not working for you.

-Joe

EDIT: Turns out the rotation bug was introduced since Update 1.

[Mr. Lim]

Originally Posted by jhersh

I was refactoring the AxisCamera class last night and found 3 bugs that prevent the C++ implementation from successfully setting the rotation, exposure, and white balance. This is likely why it's not working for you.

-Joe

Thanks for looking in to this Joe! Very much appreciated.

Do you know if a fix for this will be released in an upcoming update? If not, do you think you might be able to post a bit of detail so that teams can try and tackle the fix on their own?

[jhersh]

Originally Posted by Mr. Lim

Thanks for looking in to this Joe! Very much appreciated.

Do you know if a fix for this will be released in an upcoming update? If not, do you think you might be able to post a bit of detail so that teams can try and tackle the fix on their own?

It will be in the next update, but here's a patch for the specific bug that you were experiencing.

-Joe

[Mr. Lim]

Originally Posted by TheDominis

I think you'd have to write a save or something to the camera. Perhaps if you manually connect and save the settings you can accomplish this.

Also what you do mean by "exceptionally well"?

The DS feed updates at a frame rate that we can drive the robot through the halls of the school using only the camera to navigate. No noticeable lag.

The ellipse finding works well enough that our PID control loops can maintain a robot heading directly pointed at the target - even when moving tangentially to it.

By exceptionally well, it really means that we're able to do all the things we want our robot to be able to do - except that we cannot afford the time to reset the exposure and white balance hold values at the beginning of every match.