Auton selector - through controller

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:

  1. Robot is off. walk it over to the field.
  2. Turn Brain on (select the program to run).
  3. Use controller to cycle to correct autonomous program
  4. plug into field control
  5. 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?
1 Like

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

1 Like

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. GitHub - Sleuth56/Nebula-2019-PROS: Nebula 20610N Pros Code 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.

2 Likes

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

Please see @John_TYler’s post above. It’s not strictly required, but avoiding VEXnet channel renegotiation when you can is probably a good idea.

2 Likes

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.