Chief Delphi - Impressions: Command Based Robot

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Impressions: Command Based Robot (http://www.chiefdelphi.com/forums/showthread.php?t=127232)

Re: Impressions: Command Based Robot

I'm a big fan of the command-based approach, primarily because properly done it reduces coupling and makes it easier for >1 person to work on the code.

One example -- our 2013 robot had a tilting Frisbee intake that was fully automatic. Its control system was a tilt motor combined with one of the AB object detectors to sense the Frisbee, an encoder to sense the tilt angle of the platform, and two limit switches to detect the limits of travel on the platform.

https://github.com/stevep001/RoboEag...sorCommand.cpp

https://github.com/stevep001/RoboEag...nSubsystem.cpp

https://github.com/stevep001/RoboEag...PanCommand.cpp

A couple things to note.

1. Note the state machine implemented inside the command.

2. I've suspected that the state machine could be refactored into a set of commands, but haven't tried it.

3. We always group sensors into their own subsystem.

4. The Mode (the current activity/goal) is stored in the subsystem, not the command. We never store persistent state in a command, even if it executes perpetually.

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

Re: Impressions: Command Based Robot

Quote:

Originally Posted by DjScribbles (Post 1350115)

Code:

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

Code:

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

make a method so that you can say

Code:

collectorLifter->IsForward()

3. Similarly, create methods like

Code:

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.

Re: Impressions: Command Based Robot

Quote:

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.

Quote:

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

Re: Impressions: Command Based Robot

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.