The Command Framework

None of the three does anything on its own. robotPeriodic() is called for you for as long as the robot has power. The gap between calls is 20 milliseconds, so it runs 50 times a second.

1public class Robot extends OpModeRobot {
2  @Override
3  public void robotPeriodic() {
4    Scheduler.getDefault().run();
5  }
6}

One call does the whole job. It checks every trigger, starts and cancels commands from what it finds, and runs any background code you register.

A command declares which mechanisms it needs. The command from arm.runFast() needs the arm, and while it runs, it owns the arm. No other command touches that motor at the same time.

Priorities are new in Commands v3. A second command takes a mechanism only if its priority is the same or higher than the command already holding it. Every command in this workshop carries the same priority, so a new one always gets to run.

1public class Robot extends OpModeRobot {
2  // The robot's mechanisms. Public so OpModes can use them.
3  public final Arm arm = new Arm();
4  public final Flywheel flywheel = new Flywheel();
5 
6  @Override
7  public void robotPeriodic() {
8    Scheduler.getDefault().run();
9  }
10}

Each mode is a separate class marked @Teleop, @Autonomous or @Utility. That marking is how it shows up in the list on the driver station. Every mode is handed the Robot, so it can reach the arm and the flywheel.

1@Teleop(name = "Teleop")
2public class MyTeleop extends PeriodicOpMode {
3  private final CommandNiDsXboxController driver = new CommandNiDsXboxController(0);
4 
5  public MyTeleop(Robot robot) {
6    // Left trigger: push the arm up while held, stop when released.
7    driver.leftTrigger().whileTrue(robot.arm.runFast()).whileFalse(robot.arm.stop());
8  }
9}

The bindings live in the constructor. The framework builds this class when someone picks Teleop, and throws it away on a mode switch. The bindings go with it, so no binding from auto ever fires during teleop.

Almost every command in this workshop is built with runRepeatedly(...). The body runs every loop. If you have seen a while loop before, this is one. Each pass runs the body, then waits for the next loop, 20 milliseconds later.

Nothing inside it decides when to stop, so ending it is somebody else's job. Releasing the trigger is what does it above: whileTrue cancels the command on the way down, and whileFalse schedules arm.stop() in its place.

The reason to write commands this way is visibility. A command that keeps running stays the command on its mechanism, so a log always names what has the arm right now.

Here is a real one, from the arm you build two lessons from now.

1/** Push the arm with a stronger voltage and keep pushing. Never finishes. */
2public Command runFast() {
3  return runRepeatedly(() -> setVoltage(6.0)).named("runFast (hold)");
4}

runRepeatedly re-runs setVoltage every loop, so the six-volt request never goes stale. Every command on this site built that way carries the (hold) suffix, which is a promise from whoever wrote it: this command has no ending.

Six volts is a push, not a position. The arm ends up wherever gravity and friction let it.