Restart Robot Code at competition

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