Random autonomous

[ekapalka]

Hello! I am programming in C++, and I came up with an interesting idea. What I would like to do is write multiple autonomous programs/routines, and have one of them randomly selected at the beginning of the match. I'm pretty sure we would first generate a random number between 1 and ___, and then have a series of case statements with each autonomous code assigned to a different case. Does this sound like something that can/should be done? I suppose I'll ask how on the C++ forum if it seems okay with everyone.... Thanks!

[pfreivald]

Hello! I am programming in C++, and I came up with an interesting idea. What I would like to do is write multiple autonomous programs/routines, and have one of them randomly selected at the beginning of the match. I'm pretty sure we would first generate a random number between 1 and ___, and then have a series of case statements with each autonomous code assigned to a different case. Does this sound like something that can/should be done? I suppose I'll ask how on the C++ forum if it seems okay with everyone.... Thanks!

I'm sure it can be done, but why would you do it? You can't interfere with your opponents, and you can't be interfered with, so why do something random when you can instead do the best thing you're capable of?

[yelk11]

you could have the choices not random but controlled, the options would be available on the dash board and according to your surroundings you could change what happens in autonomous.

[ekapalka]

It's mostly the concept I'm interested in. I've seen it implemented on robots that were unanimously successful, with separate programs for defense, offense, and whatnot.... This year, we'll only be focusing on one aspect, so it wont really be of much concern. I'm just interested. Thanks!

[DjScribbles]

You can do this. But you should not make it random, I used C++ last year, and programmed it so that by holding a single button on the joystick during disabled mode, the robot would select different routines to run in autonomous. The driver station had a text output describing the mode.

It was indeed very useful/effective. We could switch between shooting 2 balls from the key, shooting 2 and tipping the bridge, driving up to the fender and shooting 2 balls, shooting 4 balls, or feeding balls to an alliance member.

It made life easier to be able to switch modes without a reprogram, the only thing to watch out for is if your robot gets reset, or the field is reset, you have to re-select the mode (it's a good idea to use your preferred mode as the default).

Here is a link to my main source code file: https://github.com/TeamExcel/Project2012/blob/master/Robot2012.cpp
Line 489 shows the switching logic.
Line 420 resets the mode when the robot gets disabled.
Line 665 shows the switching between autonomous cases during running.

[dk5sm5luigi]

For Lunacy we had several auto modes. One of them would randomly pick an existing auto mode. To make it more fun we also had an auto mode to drive straight for a random amount of time, then turn for a random amount of time, then drive straight for a random amount of time. This random auto mode could have been one of the randomly selected auto modes.

Granted in that year, as long as you kept moving in auto you were good.

[ekapalka]

I used C++ last year, and programmed it so that by holding a single button on the joystick during disabled mode, the robot would select different routines to run in autonomous. The driver station had a text output describing the mode.
This method sounds perfect. I was not aware that you were allowed to influence the robot in any way during disabled/autonomous mode. Thanks for the example! Thanks everyone else, as well :D I'm glad I'm not the only person who thinks something similar to this is a good idea.

[DonRotolo]

Many years ago, we selected our auto mode using switches on the robot. On off off meant one thing, on off on another, and so on.

Of course we knew which one we wanted to choose before the match started

[AndyBare]

This method sounds perfect. I was not aware that you were allowed to influence the robot in any way during disabled/autonomous mode. Thanks for the example! Thanks everyone else, as well :D I'm glad I'm not the only person who thinks something similar to this is a good idea.

ULTIMATE ASCENT is played by two competing alliances on a flat, 27 x 54 ft field. Each alliance consists of three robots. They compete to score as many discs into their goals as they can during a two (2)-minute and fifteen (15)-second match. The higher the goal in which the disc is scored, the more points the alliance receives.

The match begins with a fifteen (15)-second Autonomous Period in which robots operate independently of driver inputs. Hitting a button on the joystick is an input, so this is an illegal tactic.

[slijin]

What we've done traditionally is include a rotary binary switch (a more compact version of what Don mentioned) somewhere on our OI or robot, and tie a specific auton routine to each setting using a switch block. By changing the switch's state, we can choose between auton routines on the fly when we need to switch roles for a certain match.

[PVCpirate]

This method sounds perfect. I was not aware that you were allowed to influence the robot in any way during disabled/autonomous mode. Thanks for the example! Thanks everyone else, as well :D I'm glad I'm not the only person who thinks something similar to this is a good idea.

I believe he meant before the match starts. The drivers can't touch the controls during autonomous.

[Greg McKaskle]

Moreover, the joystick data sent to the robot during autonomous ignores never changes during auto. The values it uses are the last read during disable. To select an auto, you have many choices ...

Joystick values (like on the third axis),
FIRST Touch switches,
I/O tab switches without a I/O board,
Robot jumpers or switches,
Dashboard settings sent over SmartDashboard,
The cRIO DIP on the 8 slot,
and of course similar mechanisms with a pot compared to various ranges.

Greg McKaskle

[BradAMiller]

There are some examples in Java and C++ of choosing a (not random) autonomous program from the SmartDashboard with Command based programs on this page:

http://wpilib.screenstepslive.com/s/3120/m/7932/l/81109-choosing-an-autonomous-program-from-smartdashboard

The idea is that after caucusing with your alliance partners, you decide which of several strategies you might want to use and run the agreed one.

Brad

[flamer075]

This seems to be a cool idea, how would you do this if you were programming the robot in Java?

[dubiousSwain]

Normally, the Lunatecs select an autonomous mode by using the analog inputs on the dashboard. As soon as the robot is enabled, the code reads the analog input, and uses the appropriate autonomous mode.

[Jared Russell]

You can't interfere with your opponents, and you can't be interfered with, so why do something random when you can instead do the best thing you're capable of?

This isn't strictly speaking true. Yes, there is a center line. But there are still ways to interfere or be interfered with.

[3132MentorMike]

What we've done traditionally is include a rotary binary switch (a more compact version of what Don mentioned) somewhere on our OI or robot, and tie a specific auton routine to each setting using a switch block. By changing the switch's state, we can choose between auton routines on the fly when we need to switch roles for a certain match.

Yeah, this works. We've used a binary-coded decimal switch on the front of the robot so that you can pre-set your autonomous mode AFTER consulting with your alliance partners on the desired strategy.

"Random" doesn't work so well if you are going to interfer with what your alliance partners are going to do.

[pfreivald]

This isn't strictly speaking true. Yes, there is a center line. But there are still ways to interfere or be interfered with.

Point conceded.

...but it still doesn't justify random actions!