04 / Subsystems and Commands

Command-Based OpModes

Schedule small commands and compose them into TeleOp and autonomous routines.

75 minAdvancedSubsystems and Commands

You will

01Explain the difference between a subsystem and a command.
02Use instant, sequential, and parallel commands appropriately.
03Run the scheduler every loop.

Why Command-Based OpModes matters

This lesson is about making robot code scale. Architecture should reduce repeated decisions, not bury logic. Students should see why RobotHardware, subsystems, enums, state machines, and commands make the robot easier to test, reuse, and repair at an event.

Starting point

Commands are small promises

A command should do one behavior: set the claw, move the arm, wait, or run an intake sequence. The centerstage code uses short command classes to keep driver controls and autonomous routines readable.

The scheduler is part of the loop

Command-based OpModes only work if the scheduler runs every iteration. Scheduling a command describes what should happen; the scheduler actually advances it over time.

Build path

Introduce structure after students have felt the pain of duplication. Move one mechanism into a subsystem, one repeated behavior into a command, and one set of raw positions into named states. The final code should read more like robot intent and less like a wiring diagram.

For this specific lesson, students should first restate the goal in robot terms, then identify the value or behavior they expect to observe, then run the smallest test that proves the idea. The lesson should feel like a guided lab: predict, run, observe, explain, and only then extend.

CommandTeleOpSnippet.java · Java

@Override
public void run() {
    previousGamepad2.copy(currentGamepad2);
    currentGamepad2.copy(gamepad2);

    CommandScheduler.getInstance().run();

    if (currentGamepad2.left_bumper && !previousGamepad2.left_bumper) {
        CommandScheduler.getInstance().schedule(
            new SequentialCommandGroup(
                new InstantCommand(() -> manualClaw = false),
                new IntakeCommand(),
                new InstantCommand(() -> manualClaw = true)
            )
        );
    }

    robot.periodic();
}

Debugging and failure modes

Architecture fails when responsibilities are unclear. If hardware is written from several places, commands fight. If states are scattered across booleans, impossible combinations appear. If lifecycle methods run out of order, telemetry and behavior disagree. The debugging path should follow ownership: input, command, subsystem state, hardware write.

Checks

The scheduler runs exactly once per loop.
Commands are short and mechanism-focused.
The same command can be reused in TeleOp and autonomous.

Check your understanding

Module check

What must happen every loop in a command-based OpMode?

0 of 1 answered

References

FIRST FTC DocsOfficial FTC SDK and robot programming documentation.Game Manual 0Community FTC programming, control, and robot design reference.