04 / Subsystems and Commands

Enums and Finite State Machines

Represent robot mechanism states explicitly instead of scattering booleans.

60 minIntermediateSubsystems and Commands

You will

01Use enums for mechanism targets.
02Replace fragile boolean combinations with named states.
03Write state transitions that drivers can understand.

Why Enums and Finite State Machines 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

Enums make robot intent visible

Names like DOWN, HOVER, DEPOSIT, and SAFE are easier to reason about than raw servo positions. The attached arm subsystem uses enum states to make mechanism targets readable.

FSMs protect sequencing

A finite state machine defines which states exist and how the robot moves between them. This prevents half-updated mechanisms where one servo thinks the robot is scoring and another thinks it is intaking.

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.

ArmState.java · Java

public enum ArmState {
    DOWN(0.12),
    HOVER(0.18),
    DEPOSIT(0.46),
    UP(0.95);

    public final double position;

    ArmState(double position) {
        this.position = position;
    }
}

public void updateState(ArmState nextState) {
    armState = nextState;
    setProfileTarget(nextState.position);
}

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

Every driver action maps to a named state.
Raw positions live in one enum or constants area.
Telemetry prints the current state name.

Check your understanding

Module check

Why prefer enums over several unrelated booleans?

0 of 1 answered

References

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