Share you Autonomous

[Bpk9p4]

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?

[Tom Line]

Originally Posted by Bpk9p4

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.

[Bpk9p4]

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

[adciv]

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.

[Bpk9p4]

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

[marccenter]

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!

[adciv]

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.

[Toa Circuit]

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.

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.

[notmattlythgoe]

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.

[cjl2625]

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.

[baumgartensam]

One other method for doing autonomous is using machine learning-ish concepts. One thing we have thought about doing is having scouts in the stands recording if our robot makes shots and then using that information to find positions on the field that are viable to shoot from (using accelerometer and gyro). We then could import that information after each match and the robot could recalculate an autonomous path. I have written some code to do this and it worked quite nicely; however, we didn't get a chance to use it at comps.

[SoftwareBug2.0]

Originally Posted by Toa Circuit

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

Originally Posted by notmattlythgoe

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.

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.

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

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));

MoveAndShootCommand:

DriveStraightCommand driveCommand = new DriveStraightCommand(0.85, 120);
addSequential(driveCommand);
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.

[tr6scott]

Please check out this paper written by apalrd on beescript.

http://www.chiefdelphi.com/media/papers/2497

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

Our two ball script looks like this:

#Two Ball Autonomous

SET_ROLLER_SPEED 75

WAIT 100

ARM_MOVE 1

WAIT 300

SET_ROLLER_SPEED 25

WAIT 300

SET_ROLLER_SPEED 52

DRIVE_STRAIGHT 84 6000

SET_ROLLER_SPEED 0

WAIT 250

SHOOT

WAIT 250

SET_ROLLER_SPEED 90

WAIT 1550

SHOOT

STOP_ALL

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.

[Bpk9p4]

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?