Restart Robot Code at competition

[engbrech]

We are having trouble initiating our camera setting when we deploy the code (labview for us) such that it starts on power on. Instead of applying the manual setting we want it default to auto exposure.

This doesn't happen when we simply deploy the code from our laptop in interactive mode.

We are baffled to find the reason it works in one instance and not the other and of course this makes us nervous going to competition this weekend.

A work around we have found is simply to "restart robot code" from the dashboard. Takes about 10 seconds and fixes the problem and then we are off and running just fine.

My question is, will I be able to do that at the competition? There should be time but I don't know if the difference in the communication system between competition and our practice scenario will make this impossible.

Obviously I would rather figure out the problem causing the camera to initial correctly at some times an incorrectly at other. But we've been working on that for a while with no joy and if we don't get that sorted out I'd like to know if the work around will work.

[Mark McLeod]

Sounds like it might be that the code is trying to send settings before the camera itself has finished booting and is ready to receive the modified settings.
Restarting the code later may insure that the camera is already running and is ready to communicate.

A solution might be to delay your camera code for the length of time it takes the camera to boot.

Depending on the camera you may be able to fix the startup settings on the camera itself, which would be far and away my preference.

[euhlmann]

Restarting works fine over FMS. The only issue is that driver station's restart button is right next to the reboot roborio button - be careful!

Why would you want to set your camera to auto exposure though?

Originally Posted by Mark McLeod

Sounds like it might be that the code is trying to send settings before the camera itself has finished booting and is ready to receive the modified settings.
Restarting the code later insures that the camera is already running and is ready to communicate.

A solution might be to delay your camera code for the length of time it takes the camera to boot.

What we do (in C++, but you should be able to do this in labview) is constantly set the exposure setting on every tick. We do this because we use manual exposure with a setting on smartdashboard, but you can repeatedly set exposure to auto as well.

[rich2202]

As long as everything is working, you should be fine. However ...

If you forget to turn on the robot, and they turn it on for you ...

Similarly, if your robot is not connecting, and they power cycle your robot ...

Once your robot is connected, especially if there has been a long delay, they are eager to start the match. They may see the green light, and start the match. You should be able to give them a thumbs down, but if they forget to look ...

[engbrech]

Thanks for the suggestion. The delay seems like an obvious thing to try tonight at practice and it is good to know we can reset the code if we need to.

To clarify, we want the camera to accept a manual mode but are seeing it irreversibly switch to auto exposure at start up.

I'll update our status later.

[Greg McKaskle]

What type of camera?

Are we talking about a camera for processing on the roboRIO or sent to the dashboard, or both?

The vision processing VI runs a parallel loop to keep up with the camera and make the latest image available. It will continue to open the camera connection in case it reboots or was not up when the code started.

For USB cameras, Get image will watch for errors and similarly try to close and reopen sessions for camera disconnects. I have, however seen odd things happen at the UVC layer. I would like to reproduce this if given more details.

How does it behave with camera disconnect and reconnects?

Greg McKaskle

[engbrech]

Tonight at practice the programmers added a delay (20 seconds to be plenty long) and we still had the camera default to auto exposure about half the time. We eliminated the delay then since all it seemed to accomplish was adding time to restart the code.

We also noticed our navx not starting on boot at power on. Restarting the code also addressed that issue.

So may the issue is a more general peripheral issue at power on?

We are using the microsoft lifecam. Use for both sending to the dashboard and for processing on the roborio. We'll likely change cameras next year after these connection and exposure hassles, but it is too integrated mechanically to change now.

Greg, I'm not sure what you mean by disconnect and reconnect. I don't see that happening on its own. Do you mean to plug and unplug it? We haven't tried but could tomorrow.

[Greg McKaskle]

I was talking about pulling the USB cable and reinserting it. I'm not suggesting this is happening on the robot when you aren't looking or anything. I'm suggesting it as a debugging tool. Anytime the USB camera code errors out, it closes, opens, and sets the properties such as exposure to the requested values. If this works, it means that the LV session saw the property be set, but the camera either rejected it or perhaps another property interfered.

I agree that the different ways of running your code should work the same, and except for some uninitialized shift registers in our code, our robot generally does that. At least I think it does.

What about the navX is different?

Greg McKaskle

[sraque]

We have this situation happening repeatedly. I also expect a race condition between code settings and camera boot.

We were restarting robot code before every match towards the end of SMT. We could easily see on the dashboard if the camera settings were bad and then do a restart.

It would be good for Beta Testing this fall to start with a ticket to redo the camera VIs/classes to make them more robust and address this race condition (if it is the problem) along with the scaling of the custom settings and support for multiple cameras.

[engbrech]

Things became too busy this past week while we were at the 10,000 Lakes competition to communicate on the forum. So I thought now that it was done I would follow up.

The good news is that the camera never had an issue on the FMS. Why the FMS, starting from boot via direct computer wifi, and running in interactive mode all seem to behave differently is both baffling and of course frustrating. It is completely nerve-racking being a position of having code that you are unable to test and know that it will work in game conditions. But we finished the qualification matched ranked 3 with a 55 OPR so it seemed to work out.

We tried restarting code during practice matches from the DS so that we would know how it would respond. That took nearly a minute on the FMS compared to the 10 seconds it took with a direct wifi connection. So it was much less desirable.

Hopefully we can sort this out for the future but for I was just glad things worked at competition.