Command Based Programming
Objective of the Command Based Robot
WPILib supports a method of writing programs called "Command based programming". Command based programming is a design pattern to help you organize your robot programs.
Some of the characteristics of robot programs that might be different from other desktop programs are:
- Activities happen over time, for example a sequence of steps to shoot a Frisbee or raise an elevator and place a tube on a goal.
- These activities occur concurrently, that is it might be desirable for an elevator, wrist and gripper to all be moving into a pickup position at the same time to increase robot performance.
- It is desirable to test the robot mechanisms and activities each individually to help debug your robot.
- Often the program needs to be augmented with additional autonomous programs at the last minute, perhaps at competitions, so easily extendable code is important.
Command based programming supports all these goals easily to make the robot program much simpler than using some less structured technique.
Structure of the Software Layers
The Command Based Robot has the following structure:
The operator input defines the mapping between the operator physical device and the command layer. When a button is pressed, the robot will take an action. The OI layer allows for quick re-configuration of button actions.
Commands are the glue in the robot connecting operator inputs to the robots motors and sensors. A command will read the operator control inputs and subsystem sensors to determine the appropriate robot action. Complex robot actions are performed though grouping of commands
Subsystems are containers for all of the motors, pneumatic actuators and sensors on the robot. The subsystems provide feedback to the command layer, and take inputs from the command layer.
Commands run over a subsystem or set of subsystems to coordinate specific actions.
Each subsystem has a default command, and that command typically takes user inputs from the Joysticks (or OI layer) and translates those actions into motor movements. For instance, a typical DefaultDriveCommand reads Joystick values and sets the left and right motor speeds in a Drive Subsystem.
In general, each command runs until it ends, or until it is interrupted by another command. If no commands are running for a subsystem, the scheduler will re-schedule the default command for that subsystem. That means there could be several concurrently active commands running - one for each subsystem on the robot!
All currently active commands in the robot are called at approx 50Hz, or once every 20ms.