Share you Autonomous

[chris.boyle]

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.

[tr6scott]

Originally Posted by 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?

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.

[wt200999]

Originally Posted by 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?

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
LOAD_SHOT

#Drive forward 5 feet
DRIVE 5

#Internal timer waits until 5 second mark if not hot
DELAY_IF_NOT_HOT

#shoot when ready
WAIT_ON_LOAD
SHOOT

#Make sure the shooter is down for start of teleop
LOAD_SHOT

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

[Bpk9p4]

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

[tr6scott]

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.

[adciv]

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.

[wt200999]

Originally Posted by adciv

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.

Another interesting way to do this would be to use port 80 (HTTP) or 443 (HTTPS) which are both not blocked, and write some kind of snazzy web app to create/modify/save your scripts. The current cRio already runs a web server, and setting this up on the robotRIO will be even easier. If you are worried about resource usage you can do something to pause or kill the web server when you are not in a disabled mode.

[SoftwareBug2.0]

Originally Posted by notmattlythgoe

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.

This still seems linear to me. All it's doing is waiting for some condition and deciding to go on to the next step or continue waiting.

What I was trying to ask is if you could do something like:

if goal is hot:
  fire
  drive forward
else:
  turn
  fire

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

This still seems linear to me. All it's doing is waiting for some condition and deciding to go on to the next step or continue waiting.

What I was trying to ask is if you could do something like:

if goal is hot:
  fire
  drive forward
else:
  turn
  fire

This is one of the things I want to investigate during the off season. This is my untested theory so take it with a grain of salt.

TwoBallTwoHotGoalCommand

HotGoalFinder finder = new HotGoalFinder();
addSequential(new DriveStraightCommand(0.85, 240));
addSequential(finder, 0.5);
addSequential(new DecisionCommand (finder, new TurnandShootSeries(), new ShootCommand()));
addSequential(new DeployArmCommand(Arm.DEPLOY, RobotMap.pickupPower));
addSequential(new DriveStraightCommand(-0.85, 240));
addSequential(new WaitCommand(1));
addSequential(new DriveStraightCommand(0.85, 240));
addSequential(finder, 0.5);
addSequential(new HotGoalDecision(finder, new TurnandShootSeries(), new ShootCommand()));

HotGoalDecision

public class DecisionCommand extends Command {

public DecisionCommand (IProvidesDecision decision, Command trueCommand, Command falseCommand) {}

   public void initialize() {
      if (decision.getValue()) {
         trueCommand.initialize();
      } else {
         falseCommand.initialize());
      }
   }

   public void execute() {
      if (decision.getValue()) {
         trueCommand.execute();
      } else {
         falseCommand.execute());
      }

   etc...
}

IProvidesDescision

public interface IProvidesDecision {
   boolean getValue();
}

[pastelpony]

This isn't our main autonomous (our main autonomous uses vision tracking to detect the hot goal and shoot at it; don't have access to the team's programming computer atm and left my flash drive in it) but it's a 2-ball autonomous VI that wasn't used in the final code. It's pretty basic as it was written in a blank VI and so I didn't get to use global variables or subVIs. See if it helps.

[AGPapa]

Originally Posted by SoftwareBug2.0

What I was trying to ask is if you could do something like:

if goal is hot:
  fire
  drive forward
else:
  turn
  fire

I've implemented something like that. I have an "if" command that continues autonomous from two different script files based on the result of some function. The first parameter of "if" is the name of the function to check. The next parameters are the name of the script file to run if true and then the name of the script file to run if false. For example, here is the two ball hot script.

in twoBallHot.script

SHIFT on
WAIT 1000
SET_SHOULDER 49
IF right_hot rightHot leftHot

in rightHot.script

DRIVE_STRAIGHT 75 0
TURN 12
WAIT 100
SHOOT
WAIT 400
SET_SHOULDER -5
TURN -152
INTAKE in
DRIVE_STRAIGHT 75 -152
SET_SHOULDER 49
TURN -7
INTAKE off
DRIVE_STRAIGHT 70 -7
WAIT 200
SHOOT
SHIFT off

in leftHot.script

DRIVE_STRAIGHT 75 0
TURN -12
WAIT 100
SHOOT
WAIT 400
SET_SHOULDER -5
TURN -150
INTAKE in
DRIVE_STRAIGHT 75 -150
SET_SHOULDER 49
TURN 17
INTAKE off
DRIVE_STRAIGHT 80 17
WAIT 200
SHOOT
SHIFT off

[tr6scott]

Our one ball hot check script was this:

#One Ball, with Hot Checking

WAIT 500

CHECK_HOT

ARM_MOVE 1

SET_ROLLER_SPEED 25

DRIVE_STRAIGHT 96 5000

#Was 3500

SHOOT_HOT 3000

STOP_ALL

The "Check_Hot" Command just checked the hot goal, and wrote the status to a global variable. The "Shoot_Hot" command would look at the global variable, and if hot would shoot without delay, and if it was not hot it would delay the argument "3000" milliseconds, then shoot.

[SoftwareBug2.0]

Originally Posted by AGPapa

I've implemented something like that. I have an "if" command that continues autonomous from two different script files based on the result of some function. The first parameter of "if" is the name of the function to check. The next parameters are the name of the script file to run if true and then the name of the script file to run if false.

Excellent. That's exactly what I was wondering about.

[SoftwareBug2.0]

Originally Posted by notmattlythgoe

public class DecisionCommand extends Command {

public DecisionCommand (IProvidesDecision decision, Command trueCommand, Command falseCommand) {}

   public void initialize() {
      if (decision.getValue()) {
         trueCommand.initialize();
      } else {
         falseCommand.initialize());
      }
   }

   public void execute() {
      if (decision.getValue()) {
         trueCommand.execute();
      } else {
         falseCommand.execute());
      }

   etc...
}

That looks like it would work. I was pretty sure it would be possible to do something but I thought it might get really ugly really fast. That's a pretty slick way to do it.

Here's something you could do if you wanted to be avoid duplicating the end of command conditions in the subsequent if:

class Continuable extends Command{
	//I don't remember whether I've set this class up is valid Java...

	//this would return self unless you wnated to run a different command.
	abstract public Continuable next();

	public bool isFinished(){
		return next()==null;
	}
}

class Continues extends Command{
	Continuable current;

	Continues(Continuable cmd){
		current=cmd;
	}

	void initialize(){
		if(current!=null) current.initialize();
	}

	void execute(){
		if(current!=null){
			current.execute();
		}
	}

	bool isFinished(){
		if(current==null) return 1;
		current=current.next();
		return current==null;
	}
}

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

That looks like it would work. I was pretty sure it would be possible to do something but I thought it might get really ugly really fast. That's a pretty slick way to do it.

Here's something you could do if you wanted to be avoid duplicating the end of command conditions in the subsequent if:

class Continuable extends Command{
	//I don't remember whether I've set this class up is valid Java...

	//this would return self unless you wnated to run a different command.
	abstract public Continuable next();

	public bool isFinished(){
		return next()==null;
	}
}

class Continues extends Command{
	Continuable current;

	Continues(Continuable cmd){
		current=cmd;
	}

	void initialize(){
		if(current!=null) current.initialize();
	}

	void execute(){
		if(current!=null){
			current.execute();
		}
	}

	bool isFinished(){
		if(current==null) return 1;
		current=current.next();
		return current==null;
	}
}

Thanks. This is one of the topics I want to tackle this off season. I'm still struggling with the best way to store the decision, in a command or in another object of some sort that gets passed around. It probably depends on the usage.