Impressions: Command Based Robot

[DjScribbles]

So, this year I decided to climb out of my familiar cave and try something new with our robot coding by switching to the (C++) Command Based pattern (this decision was helped by the great presentation from Brad Miller at CMP last year), rather than using my usual home-brewed iterative robot (still C++).

Overall, I am glad I made the switch, because our robot this year is much more complex than past years, and I know I would have struggled with tuning various systems using the 5 analog inputs on the Driver Station dash board; but I've also caught myself longing to just ditch the commands and just code a bunch of GetRawButtons in TeleopPeriodic and an Iterative switch case in AutonomousPeriodic (which I know I can do without wholly ditching the command based pattern). A lot of the problems I've had can be attributed to unfamiliarity with the pattern, but there are a lot of cases where the pattern simply feels to restrictive or requires a lot of added complexity to implement something fairly simple.

To the point, I thought it might be helpful/interesting to share what I perceived to be the pros and cons of the command based pattern:


Pros:

• If you build your commands correctly, simple to moderately complex Autonomous routines (and other chained actions) are very easy to build.

• If written correctly, commands can serve as unit tests.

• Commands are very, very useful for building test methods (along with SmartDashboard) that can be enabled without downloading special code.

• The pattern encourage the use of tools, such as RobotBuilder, SmartDashboard, and Test mode, which has been a life saver this season.

• The code is implemented in small chunks, often the patterns are pretty repeatable, and the commands are generally fairly simple.

Cons:

• Concurrent commands that have complex interactions between each other get complicated fast, to the point that it seems easier to 'cheat'

• When a command finishes, if you assign a default command, it takes over immediately, which can get tricky when you build a sequence of commands (where each must finish for the next to execute)

• For us, in order to spin the shooter wheels and fire, you need them both to be different subsystems (without cheating in your commands, or making a goofy "KeepSpinningAndShoot" command), even though they are functionally tightly coupled; because a command that requires a subsystem will interupt the current command that is executing on that subsystem when it runs.

• The syntax is much more complicated than iterative robots tend to be, I typically try to avoid pointers and static members in our robot code because they are syntactically and conceptually complex for beginners, however they are pretty much mandatory in commands. Switching to Command Based was intended to help the students become more independent in the development of the robot, however the huge jump in syntax complexity became a stumbling block.

• If not properly written, a command can work well in isolation, but hang an autonomous routine because it never ends, or never execute because it ends immediately.

• To do commands right, you end up having a ton of them, all the added files tend to create very long compile times in C++ (I've heard Java is better about this); also, either Windriver tends to be overzealous about recompiling, or there are some weird circular dependencies, but generally if a header file changes, most of the code gets recompiled.

• Tons of commands leads to a lot of small, similar files. Sometimes updating the boiler plate in all instances can be quite cumbersome.

• Figuring out the right way to do things when a necessary feature isn't supported by robot builder can be interesting. For example adding a Camera subsytem as an empty subsystem in RobotBuilder, then manually adding the camera outside the auto-generated regions; or to create a Counter class, adding digital inputs to robot builder, then using those to initialize the counter class rather than using the channels directly.

I think next season (assuming I am still with my team), I am certainly going to use RobotBuilder, SmartDashboard, and LiveWindow, however I don't know if I'm a fan of the Command system as a universal pattern, it certainly works great for special modes and cases, but for general robot operation it seems like it overcomplicates things; and in autonomous, simple sequences are very easy to build, however the command structure starts to feel burdensome when we begin trying to coordinate multiple actions to be time efficient.

[notmattlythgoe]

One thing that will help with having a ton of similar commands is to try to make your commands as reusable as possible.

We have a DeployArmCommand this year that pretty much covers all of the uses we need. We pass in a boolean if the arm should be deployed or not and a speed at which the rollers should spin. This command can then be used for any situation we need it for.

One of the biggest cons so far IMHO with the command based structure is the lack of conditionals for command groups. What we did to get around this was save the state that we need from a previous command in that command and pass the command in to the next command through the constructor. That way we can access the state of the first command after it has finished executing.

Overall we have very much enjoyed using the command based structure as I believe it is a great tool to teach OOD.

[BigJ]

One of the things we have realized that help cut down on the "weird and goofy commands" or commands that rely on each other is that a command only needs to "require" Subsystems that it intends to write to or change. If you're using a Subsystem in a read-only capacity you should be able to use it anywhere you want anytime you want.

[DjScribbles]

Originally Posted by notmattlythgoe

One thing that will help with having a ton of similar commands is to try to make your commands as reusable as possible.

We have a DeployArmCommand this year that pretty much covers all of the uses we need. We pass in a boolean if the arm should be deployed or not and a speed at which the rollers should spin. This command can then be used for any situation we need it for.

To me, what you've described sounds more like the role of a subsystem than a command; and I feel like that is one of the hangups I've got with the system, I believe the subsystem as a model makes is a more proper place to put business logic (such as a state machine that determines when to activate the roller while lowering the arm), but doing so reduces commands to such a trivial role that they just get in the way.

If you build this functionality into your command, then does that simply leave your subsystem as container classes for actuators and sensors?

[notmattlythgoe]

Originally Posted by DjScribbles

To me, what you've described sounds more like the role of a subsystem than a command; and I feel like that is one of the hangups I've got with the system, I believe the subsystem as a model makes is a more proper place to put business logic (such as a state machine that determines when to activate the roller while lowering the arm), but doing so reduces commands to such a trivial role that they just get in the way.

If you build this functionality into your command, then does that simply leave your subsystem as container classes for actuators and sensors?

I've always treated Subsystems as systems that describe the very basic functionality of the robot and the Commands are where the logic goes to control those subsystems. This allows you to have extremely basic commands that you can group together into command groups, or write more complex commands. I think it gives you a little more flexibility this way.

If you'd like I can send you a presentation that our team did for Command Based programming, it's for Java, but a lot of the concepts should be the same. It is very basic though, so most of it is probably going to be at a lower level than you'd like.

[Andrew Schreiber]

Originally Posted by DjScribbles

To me, what you've described sounds more like the role of a subsystem than a command; and I feel like that is one of the hangups I've got with the system, I believe the subsystem as a model makes is a more proper place to put business logic (such as a state machine that determines when to activate the roller while lowering the arm), but doing so reduces commands to such a trivial role that they just get in the way.

If you build this functionality into your command, then does that simply leave your subsystem as container classes for actuators and sensors?

Nearly all of our logic for a given subsystem is in the commands. When logic incorporates multiple subsystems we utilize CommandGroups. For example, our intake must be in a certain position to fire. Thus we have a CommandGroup that does:

addSequential(new DropIntakeCmd());
addSequential(new FireShooterCmd());

Because DropIntakeCmd isn't marked as finished until the sensor reads that the intake is in the proper position the logic works out.

This sort of construction allowed us to write our sequences and autons via flowcharting on a chalkboard.

However, after attempting CommandBase last year with C++ I can say that it was a bit more of a pain. Java is much much cleaner in my opinion.

Codebase for reference: https://github.com/FRC125/NU14

[Joe Ross]

Originally Posted by notmattlythgoe

We have a DeployArmCommand this year that pretty much covers all of the uses we need. We pass in a boolean if the arm should be deployed or not and a speed at which the rollers should spin. This command can then be used for any situation we need it for.

We find it nice to have simple commands that don't need any outside input (so they can be run from SmartDashboard for debugging. Because of this, we make a complicated command (like your DeployArmCommand) and then make a bunch of commands that extend the complicated command and pass the appropriate data.

We've ended up putting Safety logic in the subsystem, so that everyone is guaranteed to use it, but put Business logic in the command.

[notmattlythgoe]

Originally Posted by Joe Ross

We find it nice to have simple commands that don't need any outside input (so they can be run from SmartDashboard for debugging. Because of this, we make a complicated command (like your DeployArmCommand) and then make a bunch of commands that extend the complicated command and pass the appropriate data.

We've ended up putting Safety logic in the subsystem, so that everyone is guaranteed to use it, but put Business logic in the command.

I like this strategy also. But couldn't you just send the command to the smart dashboard with the parameters included? We decided to use Network Tables this year instead of the SmartDashboard, so I could be mistaken.

Also, I cannot wait until next year when we can use ENUMs to send in different states to subsystems and commands.

[DjScribbles]

As an example of what I mean by business logic, here is the bulk of code from our collector:

We need to know the state of the collector when we control our arm (the two can collide while the collector is up). So having the collector subsystem know it's state seems like the appropriate way to manage this.

void Collector::MoveCollector(bool extend)
{
	if (extend == true)
	{
		if (collectorLifter->Get() != DoubleSolenoid::kForward)
		{
			timeTravel.Reset();
			timeTravel.Start();
		}
		collectorLifter->Set(DoubleSolenoid::kForward);
	}
	else
	{
		if (collectorLifter->Get() != DoubleSolenoid::kReverse)
		{
			timeTravel.Reset();
			timeTravel.Start();
		}
		collectorLifter->Set(DoubleSolenoid::kReverse);
	}
}

Collector::CollectorState Collector::GetState()
{
	if ((timeTravel.Get() >= TIME_TRAVELING_UP) && (collectorLifter->Get() == DoubleSolenoid::kReverse))
	{
		return UP;
	}
	if ((timeTravel.Get() < TIME_TRAVELING_UP) && (collectorLifter->Get() == DoubleSolenoid::kReverse))
	{
		return TRAVELING_UP;
	}
	if ((timeTravel.Get() >= TIME_TRAVELING_DOWN) && (collectorLifter->Get() == DoubleSolenoid::kForward))
	{
		return DOWN;
	}
	if ((timeTravel.Get() < TIME_TRAVELING_DOWN) && (collectorLifter->Get() == DoubleSolenoid::kForward))
	{
		return TRAVELING_DOWN;
	}
	return IDLE;
}

It doesn't seem appropriate to tuck the state into a command somewhere. I could see setting the currentState on the End of command though; however the logic of how long it takes to actuate still seems more appropriate in the subsystem, because it is an attribute of that subsystem, not of the command that triggered the action.

[MrRoboSteve]

Originally Posted by DjScribbles

void Collector::MoveCollector(bool extend)
{
	if (extend == true)
	{
		if (collectorLifter->Get() != DoubleSolenoid::kForward)
		{
			timeTravel.Reset();
			timeTravel.Start();
		}
		collectorLifter->Set(DoubleSolenoid::kForward);
	}
...

A couple things we do to make code like this easier to read:

1. Don't test Booleans against true, just say "if (extend)"
2. Up your abstraction in your subsystem a bit -- for example, instead of saying

collectorLifter->Get() != DoubleSolenoid::kForward

make a method so that you can say

collectorLifter->IsForward()

3. Similarly, create methods like

collectorLifter->MoveForward()

4. Once you do this, some of the logic that is in your subsystem becomes easier to move into a command.

We agree that state is best maintained in the subsystem, not a command. I think it's easier to treat commands as transients.

A final note -- we would use some sort of sensor (limit switches, encoders, or magnetic reed switches on the air cylinder) to detect the position of the actuator, rather than using timing, particularly in cases where the actuator's position can interfere with another part of the robot.

If you look at my other post in this thread, there's an example of the supervisor command pattern that I really like for subsystems that require regular observation to work -- your subsystem qualifies in that you have the transient states where it is moving from one goal state to another.

[notmattlythgoe]

Originally Posted by DjScribbles View Post
• For us, in order to spin the shooter wheels and fire, you need them both to be different subsystems (without cheating in your commands, or making a goofy "KeepSpinningAndShoot" command), even though they are functionally tightly coupled; because a command that requires a subsystem will interupt the current command that is executing on that subsystem when it runs.

Another way around this is to not have the shoot command actually require the shooter. As long as you know the command is going to finish, which with actuators is pretty simple, you shouldn't run into any issues. This allows you to keep the wheel and trigger in the same subsystem, but run them with two different commands.

The supervisor command is set as the default command on the subsystem, and is never interrupted. Other commands (e.g., the deploy example) inject changes in desired state into the subsystem, and the supervisor command reacts accordingly.

We also did this for our robot last year. It works well, but we decided we'd try it a different way this year. We're actually cancelling out the default command and running new commands on the subsystems when something different needs done. So back to my arm example, the default command is DeployArm(Arm.RETRACT, 0) which retracts the arm and runs the roller at 0%. We set up two buttons PickUp and Pass that run DeployArm(Arm.DEPLOY, RobotMap.pickupPower) and DeployArm(Arm.RETRACT, RobotMap.passPower) respectively whileHeld().

[adciv]

We use LabView but try to do the same thing. We categorize the behaviors we want the robots to perform. One advantage of this is we typically have some pretty complex autonomous & teleop routines and this makes it easier to develop both.

2012 Rebound Rumble Routines (for example)
1) Ball Management - Statemachine manages the inventory and location of balls in the robot, ensuring we never went over the limit and that all balls were under positive control at all times. Balls were automatically routed through the system to provide a ball as soon as possible to the shooter.

2) Shooter Management - Managed Shooter RPM and inhibited firing if RPM was not within tollerance

3) Shooter Targeting - Recieved location of target and automatically moved the turret to target

4) Ball Detection (implemented after season) - Could find balls automatically and provide the location to the drive system for pickup

5) Driver System - Could take the location of balls and drive towards them until they were picked up to be handled bythe Ball Mangement System

This could be considered a "System of Systems" (groan all you want). Each subsystem handles it's task and is connected (as loosely as possible) to others. It's discrete portions of code instead of monolithic items. We're working on re-implementing this years code in a similar manner. It also makes it easier to maintain/troubleshoot.

[Joe Ross]

Originally Posted by DjScribbles

• When a command finishes, if you assign a default command, it takes over immediately, which can get tricky when you build a sequence of commands (where each must finish for the next to execute)

If you use CommandGroups, the default command won't run until the CommandGroup finishes. However, you do have to think about your end and interrupted methods to make sure they don't do something you don't want when run in a sequence.

[DjScribbles]

Originally Posted by Joe Ross

We find it nice to have simple commands that don't need any outside input (so they can be run from SmartDashboard for debugging. Because of this, we make a complicated command (like your DeployArmCommand) and then make a bunch of commands that extend the complicated command and pass the appropriate data.

This would definitely help with our boiler-plate problem, we have a command for each of our arm positions, each is identical save for a single parameter; this would be a huge improvement there.

Originally Posted by Joe Ross

If you use CommandGroups, the default command won't run until the CommandGroup finishes. However, you do have to think about your end and interrupted methods to make sure they don't do something you don't want when run in a sequence.

This is really one of the biggest annoyances I've had with adopting the pattern. For our shooter (wheel driven with a piston to fire), we have a spin-up command that sets the target RPM while the command is running, and stops the wheels when the command completes. In order to make this work, the shooter subsystem needed to be broken into two subsystem, one for the wheel motors and one for the piston, so that the Fire command did not interrupt the Spin-Up command. (Alternatives would have been having the spin up command interrupt/end without stopping the wheels, but then the default command or an on release command would have to pick up the slop)

This became a problem in autonomous as well, since the spin-up routine didn't end, a seperate command needed to be created to do the same thing, but with a different life-span. (I've since realized that adding this in parallel would have been the better solution, however the nuances of the parallel/sequential weren't clear at the time)

[Ginto8]

Originally Posted by DjScribbles

• Concurrent commands that have complex interactions between each other get complicated fast, to the point that it seems easier to 'cheat'

I think this is an issue of Command design, not of the overall model. If there are two Commands that interact in weird ways if used improperly, I try to contain their use cases in CommandGroups that can guarantee that they will interact as desired. This isn't always feasible, but it can be much more readable than a complex redesign to handle the weirdness.

Originally Posted by DjScribbles

• When a command finishes, if you assign a default command, it takes over immediately, which can get tricky when you build a sequence of commands (where each must finish for the next to execute)

If you're using a CommandGroup, this isn't a problem. CommandGroups implicitly require() all subsystems that the Commands in them require. This year our launcher requires some pretty complex sequences, but by using CommandGroups and setting one as the default command, we were able to automate all but a very small part of it.

Originally Posted by DjScribbles

• For us, in order to spin the shooter wheels and fire, you need them both to be different subsystems (without cheating in your commands, or making a goofy "KeepSpinningAndShoot" command), even though they are functionally tightly coupled; because a command that requires a subsystem will interupt the current command that is executing on that subsystem when it runs.

This is a situation where running the wheel control in a different thread (eg. through a PIDController/PIDSubsystem) would be helpful. Last year, our Shoot command looked like this:

addSequential(new SpinUp(speed));
addSequential(new DeployDisk());

While this ran, even after SpinUp ended, the wheel kept spinning. Using a PIDSubsystem also let us add a safety feature: the default command waited 5 seconds, then spun the wheel down, in case it hadn't been done manually.

Originally Posted by DjScribbles

• Tons of commands leads to a lot of small, similar files. Sometimes updating the boiler plate in all instances can be quite cumbersome.

If you are suffering from a lot of boiler-plate, make some classes to inherit from! For example, our code-base includes this class:

// Does nothing, and keeps doing it forever
public class DoNothing extends Command {
    public DoNothing() {}
    protected void initialize() {}
    protected void execute() {}
    protected boolean isFinished() {
        return false;
    }
    protected void end() {}
    protected void interrupted() {}
}

Originally Posted by DjScribbles

• Figuring out the right way to do things when a necessary feature isn't supported by robot builder can be interesting. For example adding a Camera subsytem as an empty subsystem in RobotBuilder, then manually adding the camera outside the auto-generated regions; or to create a Counter class, adding digital inputs to robot builder, then using those to initialize the counter class rather than using the channels directly.

This is one of the reasons my team does not use RobotBuilder. It's very good for getting some example code or a base to start from, but as soon as you try to modify anything in a way that the template's writer didn't think of, you're somewhat screwed. Creating the subsystems and declaring all the hardware by hand is not an arduous task, and reduces barriers to any necessary changes.