Saving Camera Exposure and White Balance Holds after Restart?

[Mr. Lim]

A strange one for all of you.

We can get our camera running exceptionally well, with great framerates on the DS feed, and with excellent ellipse detection, but only under a few weird conditions:

1) I first use my laptop to log in directly to the Axis 206 web interface, point the camera at a light in the room so that the field target is dimmed, and then set the Exposure and White Balance to HOLD CURRENT.

2) Log in to the DS as Developer, and use the task manager to log off the Driver account.

My question pertains to #1. I can't get my Axis camera to save its exposure and white balance hold settings when the robot is power cycled. Everytime it starts up, they revert back to AUTOMATIC, and that causes tons of problem.

It's strange that the vision system seems to run best when the image is dim. But when auto exposure and white balance work to brighten it up to a nicer looking image, the ellipse detection starts to become unreliable.

Lastly, as long as exposure and white balance are set to AUTOMATIC, our frame rates on the DS feed are terrible. But once we set them to HOLD via the web interface, it speeds right up.

Attempting to set the exposure and white balance to HOLD via the writeExposure and writeWhiteBalance(?) functions in WPILib don't seem to do anything. When I log in to the web interface, they show up as AUTOMATIC again. Manually setting them via the web interface seems to be the only effective way.

Does anyone know a way to make the Axis permanently hold its exposure and white balance settings?

[Mr. Lim]

Attached are two screen captures of our DS.

Good.jpg shows exposure and white balance hold settings that give excellent ellipse detection and frame rates. Auto exposure and white balance have been disabled, and set to HOLD. We intentionally made sure the ceiling lights were in the frame in order to get a dim image.

Bad.jpg shows automatic exposure and white balance producing a brighter image. The ellipse detection picks up noise ellipses in the background, and doesn't reliably pick up the target. Frame rates using automatic exposure and white balance seem to be very poor.

[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?

[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.

[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