Can you have controller input before a match without the motors moving?

[UvuvwevweOnyetenye]

During a match, does controller input still get read if the code is in pre auton? Wondering so I can have an auton picker using controller input.

[Ryan_4253B]

No, controller input will not be read in pre auton. I’ve seen people select auton using a controller by hopping into driver control before a match, and saving the results in a sd card however

[Foster]

No controller input on pre-auton. In past teams have used the orange jumpers in the 3 wire ports to tell what routine to run.

One of my favorites is the use of the three wire potentiometer. As the potentiometer moves it selects a routine. To make it discrete steps teams use a sprocket with a screw as a pointer. Teeth move past a screw, the teeth act as detents. (use of the rubber bushing helps with this). This allows for about 10 different auto settings.

Long article on how to do this. https://renegaderobotics.org/vex-sensors-potentiometer/

There are also 5 or so posts about this, search is your friend.

[VexTeamZ]

The other option is to use a limit/bumper switch picker, like mentioned in here:

Macro and automation explanation

[Mentor_355U]

The Brain, however, is able to receive Screen press events during the “Disabled” state, and many teams will use either the PROS LCD-emulator or other UI elements (such as the Button example from James, that was extended by WalshBots, and, I suspect, others)

WalshBots Autonomous Feature Selector

James Pearman posted an example of autonomous selection using the V5 Robot Brain. It allows up to eight different routines to be selected before start of a match. We have extended this to allow the buttons to select features to be enabled or not, for example shoot preload or not. It also allows to select the starting tile and alliance. Attached is an example program and brief description. Thanks James for being an awesome teacher to all! If there are bugs, please let me know. Be sure to cr…

[xTigr]

An alternative solution to what has been mentioned so far is to have your auton selector with the controller during pre-auton, but don’t plug into field control until after you have finished the selection. This way you can still do the selection with the controller without needing to add any extra sensors or take the screen protector off.

[Mentor_355U]

@UvuvwevweOnyetenye

During a match, does controller input still get read if the code is in pre auton? Wondering so I can have an auton picker using controller input.

See also this detailed explanation from James in Competition code and user created tasks . The important section is:

VEXcode provides a competition class, it’s used to start one of two user provided tasks (threads and tasks are the same as far as this discussion is concerned). The default names for these are “autonomous” and “usercontrol” but any valid function can be registered with the competition class if you want to call them something else. The competition class will only allow one of these two tasks to run at any one time, it disables both when the robot is disabled. However, any tasks that your code creates in main, pre_auton or at the beginning of these tasks are not under control of the competition class and will continue to run as the competition control status changes. This may be desired behavior, I often use a separate task in my code that constantly displays the status of motors and sensors on the brain screen. I would want this task to run during the entire match, there’s no need to stop it. However, tasks running PID loops or other code that directly controls motors should only be running when needed.

One important thing to understand is that there is a good chance that your driver control code will have been called even before the autonomous phase of the match. Whether this happens will depend on when the user program is started and when the controller is connected to field control or the live remote system. If you run the program first and subsequently connect to field control, the driver code will have been started and the robot disabled only when field control is connected. Reversing the order, connect to the field first and then start the user program, will generally avoid this from happening. It’s also important to understand that event handlers (for example, the function that gets called when you register using pressed and release calls on buttons) should only ever be registered once, if you register them at the beginning of driver control additional events will be added if driver control is started more than once.