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.