WPI new Command Based Programming - RobotContainer

Hey there,
I have been reading the new Command Based Programming docs for a while,
there is a new class called “RobotContainer”, this class responsible for a few things:

  • It’s where all the robot’s subsystems will be opened.
  • The actual binding of triggers and commands to buttons.
  • Declares which command runs in autonomous.

A link to this base class:

WPI gives a few examples of how robot projects in the new framework should look, and in those examples, they declare the subsystems as a private instance in the RobotContainer class.
So now when you have to write a command for a subsystem you have to give an instance of the wanted subsystem in the constructor of the command.

Here is an example of a GearsBot in the new format:

I personally can’t see the value of doing this.
Somebody might know what are the reasons behind such a change?
THX!! :slight_smile:

1 Like

The first reason that comes to mind is Unit Testing. If you pass in your external dependencies instead of accessing them directly within the class, it makes dependency injection for unit testing much easier.

Chuck Benedict with Team 997 did a couple of videos on how to do Unit Testing, and Dependency Injection within WPILIB, and the problems the old Command-Based Templates created, about a year back that are well worth the watch.


More than testing, it’s important for code clarity and reusability. Global subsystems work fine for small projects, but they become rapidly untenable as the amount of code grows and it becomes harder to keep track of what is being modified from where; in the new pattern, the information flow is easy to see. Additionally, this pattern allows teams to loosely couple their commands and subsystems, so that subsystem implementations can be easily changed without changing the command code.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.