Give user input to be used in autonomous function

So this is more of a theoretical question than anything.

My team attended a competition this Saturday and will be attending one more a week from this Saturday. In thinking about how I could improve our autonomous function for the next competition (which previously was just mounting the platform), I’ve come up with about 4 different scenarios for how to score points in the autonomous that I would like to program. Two are on the side of the platform close the the flags (hit a flag, change the cap, get on the platform; the other without the platform component in case our teammate wants to do that) and the other two on the far side (flip the cap, mount the platform; and again, one without the platform aspect).

But because the red and blue sides mirror each other in the direction the robot must turn in order to get on the platform, I feel like I have to write 8 separate programs for each specific situation on where the robot can start. While this is doable, it seems way to spread out to be practical. What if there is a small change that needs to be applied to all the others, like if the robot goes too far on a straightaway?

I’d love the ability to just flip a negative sign on a number depending on if the robot starts on the red or blue side without having to make a whole new program. For this, I’d like to be able to, after I start the program and my robot is disabled due to the competition settings, give some kind of input to let the program know whether I am on blue side or red side.

Right now the best thing I can think of would be to have a bumper switch in a separate task that checks if it is pushed, if so it changes a global variable that represents whether the robot is on blue side or not (true or false respectively), but I haven’t been able to test this theory yet and don’t even know if it works.

Is there an easier way to do this? Does anyone know if something like what I’ve planned even works? Have any of y’all had a similar function in your program?

Thanks, Y’all!

V5 or Cortex?

This is exactly what our teams do for V5 - one program with a list of factors to configure how the robot behaves in autonomous.

take a look, this was derived from James Pearman button selector code to provide a more general situation - not eight routines, but eight conditions - red/blue, near/far flags, shoot/no shoot preload, park/no park, de-score… oh never mind :slight_smile:

WalshBots autonomous feature selector

I’d take a look at using jumper clips, I taped extensions to the ends of my robot, one side indicates if you are on the red or blue alliance, and the other indicates distance from the flags. Then you can just use a switch in your program to run the desired auton as chosen by if the jumper clips are in each of the ports.

Only if Cortex, but V5 why???

great question!

My team is on V5 backorder so correct me if I’m wrong, but aren’t there supposed to be legacy ports on the V5 brain?

EDIT: or so Vex says here…

Using jumpers for autonomous selection in V5 really is a waste of 3 wire ports when you have a touch screen that you can select essential parameters for your autonomous. It begs the question “why?” You might as well code with punch cards in Fortran…

Load VCS or RMS or Pros and look at the opportunities offered with V5.

That said, if the OP only has a legacy Cortex, then go jumpers, potentiometers,…

[edit: was a little harsh with the Fortran and punch card statement. The legacy ports are a scarce resource on the V5 Robot Brain, and best to use with sensors you might need. The V5 touch screen provides a great way to tie together programming logic with visual feedback. Sure you can accomplish it with a potentiometer, but then you need to design a user interface around the mechanism - colored tape, sharpie, etc.

I am a fan of the new V5 control system since it offers up a lot of great opportunity to code more effectively.

My sincerest apologies to @Deicer for my earlier unhelpful remark.]

We are running cortex, and the girls have 4 base programs, one for each colored tile. They use the LCD for menuing and for each tile program, in addition to setting a variable for establishing which program to run, they also set a flag variable 'Park" to either 0 or 1. Then, in the actual tile program, there is an if statement that, if park = 1, runs some extra code to rotate the robot around and drive on the platform. If park = 0, the program simply stops.

So, on the menu, they have 8 selections for the tiles (a park and no park for each of for tiles), two for programming skills programs (near and far tile, depending on what they are working on) and a NO AUTON program (doesn’t move), as a plan z in case something dies and we simply don’t have time to fix it and don’t want to take out our partner.