team254 / frc-2013 Goto Github PK

In the past we have run autonomous modes by building a queue of "Commands" (which we get for free with this version of WPILib), then running each command sequentially. When a command says it is done, we pop it off the queue and handle the next one. The way we typically built these was by hard coding the object creation. This worked well, but required a bunch of time to restart the robot, which was annoying.

This year, we should still have the ability to do what we did in the past, but I would also like to be able to create script files that dictate what an autonomous mode should be. We can stick a bunch of named scripts in a directory, the main robot program can 'ls' in that directory to find them, then we can execute the one we see fit.

Here is an idea for how this could be architected:

There is an abstract class called AutonomousMode. This class contains a queue of Commands (which starts blank, of course). It also extends Command (so it has methods like initialize(), execute(), isFinished(), end(), etc).

We can then create a subclasses of AutonomousMode. For example:

AutonomousMode
--> ScriptedAutonomousMode
--> HardcodedAutonomousMode

ScriptedAutonomousMode:

All of the logic to open, read, and parse a script should be contained here. It's constructor should take a String that specifies the file path, and this class should take care of opening the file and parsing it.

The file should look like this:

# this is a comment, throw me away COMMAND param1 param2 param3 .... param(n) DIFFERENT_CMD param1 param2

So, we parse this file line by line, look at the name of the Command, and try to create a new command that corresponds to the name and shove it in the queue, right?

How do we find the commands though?

Finding commands:

Unfortunately without the Reflection API I don't think it is possible to query the class loader for all available classes. This means we would have to instantiate all Command classes at startup to get their names (stupid) or build a map of Command strings to Classes. I hate both of these, but the second one seems less bad.

So, either in ScriptedAutonomousMode or another class, we should build a way that allows us to give a Command string and set of parameters and get back a Command object.

I can see this going something like this: (excuse the broken syntax and method names)

private class ParamList {
  Queue params = new Queue();
  public void addParam(double p) {
    params.push_back(p);
  }
  public double get(int i) {
    if (i < 0 || i >= params.length())
      return 0.0;
    else
      return params[i];
  }
 }

 public void parse(String line) {
  String name = somehow_get_command_name();
  ParamList p = new ParamList();      
    while (double param = reading_params())
      p.addParam(param);
  Command newCmd = getCmd(name, p);
  cmdQueue.push_back(newCmd);
}

public Command getCmd(String name, ParamList p) {
  if (name == "Drive")
    return new DriveCommand(p.get(1), p.get(2));
  else if (name == "Shoot")
    return new ShootCommand(p.get(1));
  else
    return new NullCommand();
 }

Running autonomous mode:

In another class called AutonomousSelector, on startup we find the name of all the scripts (lets say /auto/Shoot7.txt is a script) and store their path names. Using buttons we can increment what automode we currently care about. We then build a ScriptedAutonomousMode with the name of the file (remember, ScriptedAutoMode builds itself!) and hold on to it. Then, in AutonomousInit, we set the robot to run that AutonomousCommand. The scheduler should automatically take care of making it run.