Multi-Choice Autonomous

[alexander.h]

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!

[Kevin Phan]

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.

[AGPapa]

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 autonomous.vi? 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 autonomous.vi 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,

[alexander.h]

Originally Posted by Kevin Phan

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.

I see ... thanks!

[alexander.h]

Originally Posted by AGPapa

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 autonomous.vi? 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 autonomous.vi 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 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.

[Kevin Phan]

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.

[AGPapa]

Originally Posted by alexander.h

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.

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):
0000=0
0001=1
0010=2
0100=4
1000=8
(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.

[alexander.h]

Originally Posted by Kevin Phan

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.

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

[Kevin Phan]

You're going to have to.

[alexander.h]

Originally Posted by Kevin Phan

You're going to have to.

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

[Kevin Phan]

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.

[alexander.h]

Originally Posted by Kevin Phan

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!

[Greg McKaskle]

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

[alexander.h]

Originally Posted by Greg McKaskle

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?

[Greg McKaskle]

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