Our team is trying to figure out the best way to manage multiple autonomous programs (at a minimum, 2 versions - 15 sec and 60 sec). We tried to keep them all in one program (different routines in like auto1(), auto2(), etc.)
Another team posted their approach. They coded these different versions of autonomous routines (functions) and has some case-switching code (depending for some controller values) in initialize() function. They will use controller to select which one to run and here is their steps:
Robot is off. walk it over to the field.
Turn Brain on (select the program to run).
Use controller to cycle to correct autonomous program
plug into field control
Robot runs autonomous that was selected
Their steps depends on the fact that V5 brain doesn’t need to be power cycled before/after plug into field controller.
However, according to this guide - https://help.vex.com/article/186-connecting-the-v5-competition-robot-to-the-competition-field
The V5 brain and controller needs to be off before controller can be plugged into field controller. So how does this work?
When you plug into competition control, your connection will drop as the robot and controller move over to a competition channel. They probably advise the order that they do so that there’s no mishaps if refs start matches right after plugging in the competition control, which would leave a robot unresponsive for the duration of the channel renegotiation. If you have enough time for the channel to switch and the radio lights to blink green, there shouldn’t be a problem.
This is my understanding of how it works unless there’s something about the firmware that I’m getting wrong, in which case I would have to defer to @jpearman
Separate suggestion: the reason why that approach requires doing things in the order you described is that the controller inputs won’t work when the robot is in disabled (which is the default once it is connected to the competition switch). To avoid this, you can use an on-screen selection. If you only have a couple of autons, then the buttons in LLEMU might be a good enough approach - simply use one button for each auton that you have. There are of course more complex selection systems that can be built on top of that if you so desire.
I am currently working on a library that would ideally do exactly what you are talking about. It’s not quite done yet though so if you would like to help out check out autolib.
Who ever told you that isn’t correct. Here is my teams code from last year. We had an on screen auton selector. https://github.com/lerker100/Nebula-2019-PROS It’s a little bit messy but you should get the jist of it. As far as using controller buttons to control the screen. Just call the function that you mapped to the on screen button. To a button on the controller.
From What I have found turning on the program before connecting it to the field controller can actually stop driver and autonomous working when plugged in and even not let driver work however plunging in a controller to compaction port then turning a program on works as it should. So doing this might stop driver and auto working
That’s why you’re support to get to matches early. I used the field control software and hardware to program autons for last years challenge. I’ve never had a problem. I have had problems with the cortex system but never with v5 and I’m very aware of why and how tournament manager does this.