Multi-Choice Autonomous

Hello! We’ve created seven (and counting!) different autonomous modes to account for the various situations we might end up being in and what we decide to do depending on the other alliance robots as well as the robots on the opposing alliance. We program in Labview, so what I would like to know is if we can put controls on the front panel (the grey page with gridlines) with a separate button for each of the seven autonomous modes so that we wouldn’t have to run a different .lvproj each time we want to use a different version of autonomous. What I plan on doing is just clicking one of the seven buttons on the front panel right before each match to make it light up. The project reads which one of the seven buttons is true, making its corresponding case structure true (for the moment, I think that I’ll be using case structures, but I’m open to any suggestions you may have). Basically, I know how this will be programmed, but my main question is if I am allowed to do this. I know that this may seem like a strange question to some people, but then again, I’ve seen stranger rules than this! Feel free to ask if any details of my questions seem foggy. Thanks enormously for any help or suggestions!

This is legal, just make sure this is before they get to the alliance station. My team uses an on board switch, but I see this as perfectly legal as long it is before the auto starts.

There are no rules prohibiting this. However, I don’t understand how you plan on doing it. Do you want these controls on the front panel of How are you going to edit those controls once the code is compiled? Or do you plan on recompiling your code whenever you want to change the autonomous routine?

A simpler way that doesn’t require you to recompile code is to use the digital inputs on the driver station. The default already has code to read from the driver station’s digital inputs. Just click on a different button before each match to select which auto mode you want to use,



I see … thanks!

I understand … but if I use the digital inputs, what kind of structure do I connect each input to? I would be led to believe I would use a case structure, but I could be wrong.

Yes you would use a case structure. What you can do is create a boolean array and convert it to numeric and wire that to the case structure.

The default code I showed before takes the array of booleans and splits it up into individual booleans. You can treat the outputs of the index array the same way you would treat the 8 individual button on the front panel.

Having separate case structures for each button and each autonomous mode would work, the first image I’ve attached shows how to do this.

This code will work fine if only one button is pressed at a time. If two or more buttons are pressed then each autonomous mode will run together at the same time. This is generally bad.

So for each case structure you should make sure that a certain button is pressed and all others aren’t. There’s a clever way to do this using “boolean array to number”. This will turn the boolean array into an integer by treating the array like a boolean number. For example (four buttons):
(Each button is represented by one digit)
Your cases for each mode will then be 1, 2, 4, 8, 16, etc.
Now if two buttons are pressed (ex: 0011=3) then it will enter the default case and not do anything!

Either approach will work, the second one will just make it impossible to execute two autonomous modes at the same time.

Is this what I can do or what I must do?

You’re going to have to.

If you take a look above, AGPapa shows a way where I don’t have to.

For me it is cleaner to use the boolean array conversion, instead having multiple case structures. AGPapa’s examples are still valid. It’s up to you to what you want to use.

OK, thanks!

You can use the Boolean bits however you like. Note that you can also name the switches on the DS so that the drive team knows what they are selecting. Just click on the field and give them a short name.

In the auto, you may want to account for unusual settings, illegal values, etc. In those cases, be sure to run something.

A few things you may want to consider.

Searching for the first True Boolean in the array gives you eight valid values (0 - 7) with good labels on the DS.

Converting the Boolean array to a number is in the Numeric>>Conversion palette and it gives you 256 valid values (0-255). The encoding will be in binary and the DS will not read as well.

You can use the sliders too, so if some of your programs vary only be a speed or a steering angle, you may want to use a slider instead. They can also be named on the DS.

Greg McKaskle

I see, but where exactly do I edit the names of each digital input? Directly on the driver station?

Yes, each button has a text field to the right of it. It should store and retrieve those when you next launch the DS. They are stored in the ini file. The names are not sent to the robot, only the Boolean values.

Greg McKaskle

About how much text do you think I could put in each text field?

If you have the DS, give it a try. In the first Button, I typed “About this much”. It wrapped on the ‘h’.

Greg McKaskle

No, sorry, I don’t have the DS in front of me, but I get the picture: I only have space for 2 or 3 keywords.

We are using another method based on the SD. We have a record and replay system that stores the driver & manipulator input to a file on the cRIO. Autonomous reads the selected file and populates the variables that control the robot. The drive team chooses the autonomous to run from our custom dashboard app before the start of the match.

In we populate the array of autonomous choices (custom file extension *.auto) and write it to the SD.

In Dashboard we read the array of choices and populate an enum ring’s String Property with the file names.

Autonomous then sends back the values it received so we know it got the correct values.



Here’s yet another method if you don’t like the DS buttons:

Set up a Enum text box on your dashboard and give each number value a corresponding label, showing your driver which program to use.

Write the integer value to a SD variable and then in your autonomous mode, read the value and have a case structure select the correct program to run based simply on the integer value.

When you set up your player station, select the correct program then leave the variable alone. As the match starts, it will read the variable from your dashboard once at the beginning of the Autonomous Period, then execute the correct program.

Our team has used this method for two years and never had an issue. It’s reliable and versatile, allowing for many different modes and configurations, as long as your drivers remember to check and make sure it’s correct before the match starts XD.