Programming Support

This area contains resources related to programming. In some cases topics are programming language dependant.

This page is to support both our team, as well as others, with programming guides and resources. A lot of knowledge is available across the web and we hope to collect what we find useful here. If you have a reference we should add, please feel free to contact us!

java codeIn this guide we give a brief overview of the Command Based Robot Project found in the Java WPILib.

The following is an excerpt from a post made on chief delphi briefly explaining the way the command based robot project works. For more information please see the related links at the end of the article.


Overview of the concept

There are two major classes which are provided that can be extended to contain the majority of the robot specific code, the Subsystem class and the Command class.

Subsystems characterize mechanisms on your robot. So each subsystem (drivetrain, shooter, lift, etc) should extend the Subsystem class and implement any methods for the functionality that subsystem can perform. It abstracts hardware specific funcitons from the rest of the program. The subsystem is where physical wiring meets the code. Variables for input and output devices live inside the subsystem. Methods to get or set these variables are created within the subsystem to abstract the hardware from the rest of the program. The shooter may have a method setSpeed which takes a parameter in RPMs, but this alone wouldn't be enough to shoot a ball. You will likely need to interact with multiple subsystems to do that.

This is where the Command class comes in. The purpose of the command class is to build more complex sets of functions, a procedure to follow to complete a task. For many commands this requires using methods across a number of subsystems. Groups of commands can be created to complete a number of steps in series or parallel (or a mix of both).

Commands are then linked into operator interfaces (e.g. joystick buttons) or even executed from autonomous modes.

You need to conform somewhat rigidly to the framework for everything to work, but this can have the advantage of helping you organize your thoughts.


How it works

New instances of Commands are created from events (e.g. button press from operator). These instances are passed to a scheduler which maintains a list of all the active commands. Commands have a number of methods which allow the scheduler to step through their execution (initialize(), execute(), isFinished(), end()).

Part of a command definition provides information as to which Subsystems are required for the particular command. This allows the scheduler to identify conflicting commands, and handle which ones get to execute. Basically whichever command was issued last will execute (if there was a subsystem dependency conflict).

The command based robot project builds on top or the iterative robot project. Methods for each game mode (teleopPeriodic(), autonomousPeriodic()) are called repeatedly (every 20ms - with each driver station update). Calls to the scheduler's run() method are required within the teleop and auto periodic mode methods to allow the scheduler to process outstanding commands.

Once you understand the model it makes building up a fairly complex system quite painless. Throwing together autonomous mode actions become quite easy, as it simply becomes a new command which calls other existing commands that in many cases have already been tested and proven to work in teleop.


Related Links

Overview commands and subsystems. Skip to slide 18.

WPILib Cookbook




Valid XHTML 1.0 Transitional  

See your web site through colorblind eyes with the colorblind web page filter.