Command Based Programming

As our robot programs become more complex, a framework is needed to help keep related functionality together (cohesion) while preventing unrelated functions from becoming entangled (coupling). Improving cohesion and reducing coupling are key concepts in software engineering. WPILib provides a framework called Command Based Programming that helps with this. You can read about it in ​ScreenStepsLive.

In command-based programming, we define

• subsystems representing physical parts of our robot: intakes, shooters, turrets, drivetrains, etc.
• commands representing activities that can be done by one or more subsystem (e.g. throwing a frisbee)
• command groups represent behaviors: a set of activities that must be performed in a particular sequence (such as pointing a turret at a target, adjusting the elevation angle, and then throwing a frisbee into it).

A given activity may require more than one subsystem (e.g. throwing a frisbee might require both the turret and the shooter). More than one activity can be running at the same time (e.g. the robot might be driving while throwing frisbees). The Command-Based framework helps organize all of this activity so that multiple things can be happening at the same time without interfering with each other (e.g. preventing two commands from trying to control of the same subsystem at the same time).

Creating a Command-Based Program

Create a new project in VSCode (WPILib Icon->Create a new project->Template->Java->Command Robot). Notice that in the project src folder, addition to the Main.java and Robot.java we're used to seeing, the project also has:

• OI.java - where the Operator Interface is defined
• RobotMap.java - where global constants are defined (e.g. motor controller addresses)
• commands folder - where your Commands will be stored
• subsystems folder - where your Subsystems will be stored

Robot.java still extends TimedRobot (the framework we've been using until now) and the methods robotInit(), robotPeriodic(), autonomousInit(), autonomousPeriodic(), teleopInit(), teleopPeriodic(). However, it now includes an example subsystem and an instance of the OI (Operator Interface) that represents the driver station; the OI helps bind the controls on the driver station (e.g. joystick, xbox controller) to the activities (commands, command groups) that your robot will be performing. For example, the OI allows you to connect a button on your controller to an activity like launching a frisbee.

How it works

Command-based programming is built on top of the IterativeRobot template. In each of the template's periodic() methods, Scheduler.getInstance().run() is called. This takes all currently running Commands -- which behave like threads, but can't include waits like typical threads because it's a type of threading known as "cooperative" multitasking -- and runs them, first initializing any new ones and checking whether each one has completed yet. It's useful because these Commands can be easily joined together in CommandGroups? to make autonomous modes, or can be mapped to buttons to easily allow complex teleop actions, etc.

• ​Intro to Command Based Programming