Command Based Programming

What is Command-Based Programming?

WPILib supports a robot programming methodology called “command-based” programming. In general, “command-based” can refer both the general programming paradigm, and to the set of WPILib library resources included to facilitate it.

“Command-based” programming is an example of what is known as a design pattern. It is a general way of organizing one’s robot code that is well-suited to a particular problem-space. It is not the only way to write a robot program, but it is a very effective one; command-based robot code tends to be clean, extensible, and (with some tricks) easy to re-use from year to year.

The command-based paradigm is also an example of what is known as declarative programming. In declarative programming, the emphasis is placed on what the program ought to do, rather than how the program ought to do it. Thus, the command-based libraries allow users to define desired robot behaviors while minimizing the amount of iteration-by-iteration robot logic that they must write. For example, in a command-based program, a user can specify that “the robot should perform an action when a button is pressed”

Structure of the Software Layers

The Command Based Robot has the following structure:

Operator Input

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

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

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

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.

Google Sites

Report abuse