Share you Autonomous

I am looking at working with are students this off-season to better off are autonomous skills. I was wondering if any teams would care to share there labview autonomous code so that we could learn from it.

Currently we only know of two ways of doing autonomous
1) Hard code
2) Playback recorded data

are there any other methods people know off?

A scripted system using some type of text files that are read into the cRIO on command and then sequentially executed is fairly common.

I looked at doing this but it seems like it would be hard to do 2 things at once. Is there a way around this

State Machine? Although that may count as “hard code” to you. We’ll be posting this years code at some point. Our two-ball auto involved roughly 25 steps due to a variety of things (it’s being reprogrammed to be simpler). Our one ball was four steps, but also involved communicating with an additional statemachine (which also runs during Tele) for opperation.

We have done state machine in the past and it works well. Are biggest problem right now is that we hard code it so it is not very easy to change on the fly. I am wanting to find a way to rapidly produce autonomous and change it easily

Here’s FRC3548 autonomous and teleop program (w/o Camera) in Labview.

The autonomous program is very brute force using simple timers to actuate motor speed and throwing arm commands but it works, we shot 9 out of 11, 10 pointer’s at MSC!

FRC3548 2014 V45 Robot (2.57 MB)

FRC3548 2014 V45 Robot (2.57 MB)

We’re working on recoding the robot using behaviors (and will hopefully do this from the start next year). This should make it easier for us.Basically, we are coding a VI to control our intake and another to control the catapult. We’ll then use these in a state machine or autonomous to control the robot. Similar things for the drive system. Basically, these are the equivalent of C++ function calls for controlling the subsystems. This would help you in building it faster.

As for changing it easily, what exactly do you mean? I can think of a few things we do, but I don’t know what you have in mind.

Scripted autonomous is fairly… interesting.
4213 ‘used’ it this year, but left it as the same script. We searched the cRIO root directory for the first ‘.auton’ file, and then execute through that via state machines. Our basic structure is a bunch of <subsystem> <state> or <wait> <subsystem>. To wait for multiple subsystems, wait multiple times.

Script looks like this:

drivetrain 0.5 0 0 1 //0.5 Y, 0 X, 0 W, 1 second
catapult winched
sides deploy 3
wait drivetrain
wait catapult
wait sides
catapult fired

So this way, we know the 'bot is trying to achieve certain states. Understandable code that allows for ‘parallelism’ without actually using separate threads. :wink:

I’ll see if I can find the source code. I think it got diked/subverted/buried.

We use state machines… a lot. I highly recommend you learn how to use and implement a state machine if you don’t already. It makes coding so much easier.

What language are you using?

For the command based system, writing reusable commands that take in real world parameters and using them in a command group can give you a quick way to write new autonomous routines in the fly. Below is an example:

addSequential(new DriveStraightCommand(0.85, 60));
addSequential(new TurnToDegreeCommand(0.5, 45));
addSequential(new DriveStraightCommand(0.85, 24));

The above would drive forward at 85% power for 60 inches, then turn 45 degrees at 50% power, then drive forward for another 24 inches at 85% power.

If you have tested these commands out extensively you should know the robot will do exactly that the first time you run it.

To switch between auto modes, we have a dropdown menu on the dashboard. Some specific aspects of it are on other controls, like move forward time, which is on a slider.
The drop down menu selection is sent to a state machine.
For the programming of it, I package all complex functions (like a timer function, shooter sequence, and swerve drive) into sub-vi’s, which makes new auto modes pretty easy to produce, though I guess it still counts as hard coded.

Do either of these methods allow non-linear steps? What happens in case of failure? Surely it’s possible that a robot could fail to drive some distance.

Our autonomous modes were DAGs that would not only do different things but intentionally leave the robot in different states for the driver depending on what happened during autonomous.

With some forethought you can create some pretty interesting command groups. And yes you can account for failures. When you add any of the commands you can add timeouts to them. Of course, depending on what has failed to complete could effect if your auto mode is successful or not. Sometimes you might want the robot to not finish the auto mode if one step has failed.

Here is an example of non linear steps.

addSequential(new DriveStraightCommand(0.85, 60));
addSequential(new TurnToDegreeCommand(0.5, 45));
addSequential(new MoveAndShootCommand());
addSequential(new new TurnToDegreeCommand(0.5, -45));


DriveStraightCommand driveCommand = new DriveStraightCommand(0.85, 120);
addParallel(new WaitForDistanceCommand(40, driveCommand));
addSequential(new ShootCommand());
addParallel(new WaitForDistanceCommand(60, driveCommand));
addSequential(new ShootCommand());
addParallel(new WaitForDistanceCommand(80, driveCommand));
addSequential(new ShootCommand());

The DriveStraightCommand implements an interface called IProvidesCurrentDistance which will return the distance the command has currently moved. Using this interface you can pass the running command in to other commands and have access to the distance moved at a given time. The MoveAdnShootCommand will start the robot moving, then once it has reached 20, 40, and 60 inches will run a shoot command. The final TurnToDegreeCommand will run once the MoveAndShootCommand has finished.

Please check out this paper written by apalrd on beescript.

We implemented this a few years ago, and love the flexibility of beescript.

Our two ball script looks like this:

#Two Ball Autonomous


WAIT 100


WAIT 300


WAIT 300




WAIT 250


WAIT 250


WAIT 1550



Our drive straight command drives at 75% motor power, and has a gyro P loop to adjust motor powers so you actually drive straight. The first argument of the drive strait is the inches of travel by encoder counts. The second argument in the drive straight command is a timer override, so after 6 seconds, it will close and go to the shoot command.

We will be making public our github project in the next few weeks, after they clean up the commits from championship.

I really like this idea. The only problem i see with it is you can only do one command at a time. have you found a way to get around this problem?

We used a record and replay system for autonomous this year. Attached are the complete projects for the custom dashboard and robot.

There is a tab on the dashboard for starting and stopping the recording process. It uses the SmartDashboard to communicate between the dashboard and robot.

2014 Dashboard (495 KB)
2014 Aerial Assist Robot (1.06 MB)

2014 Dashboard (495 KB)
2014 Aerial Assist Robot (1.06 MB)

Yes, and no, you can program a command that does multiple actions, but there is only one command active at a time.

I forgot to mention the best part is that the script file is just a text file that resides on the cRio. The cRio has a built in ftp server, so you can change these sequences, and re-run without connecting to labview, compiling, etc. The whole process to change the script and ftp to the cRio can be done in about a min. We have done this while queuing for a match. It takes less time to change the auto code, and download, than it takes to charge the pneumatic system. We also have a dashboard selection that chooses between 7 automodes.

You just need to be smart in how you lay out your commands, and remember they are very high level. Lets take a choo-choo style shooter which starts with the shooter released and a ball on top of it (for whatever reason). Also it takes ~3 seconds to load. Using something like beescript you could have a routine like this:

#Load the shooting mechanism

#Drive forward 5 feet

#Internal timer waits until 5 second mark if not hot

#shoot when ready

#Make sure the shooter is down for start of teleop

You can write your LOAD_SHOT command such that it can drive the shooter motor and wait on a switch. If you do this, you don’t start driving until ~3 seconds into auto, which is a problem.

Instead you can write your command to tell a different process the same thing, letting the script continue. It then can meet back up with the WAIT_ON_LOAD command to make sure its ready to shoot. In this way, both the driving and the camera code are running in parallel with the code to load the shooter.

Essentially you can write your commands to set off a parallel part of the code and continue. If all of the main robot actions are handled in a separate process, this becomes much easier to do (and it carries over to teleop).

any reason you choose to save it on the crio and not just read it from a laptop?

Yes, I don’t know how to get the cRio to read a file over the FMS to the driver station. Maybe there is something there already, but I have never tried it.

You can implement your own UDP/TCP connection to communicate between the dashboard and the cRIO. We have done this in labview when we needed extra vision processing computing power. Also, the smart dashboard may have similar capabilities.