Unit 5 · Lesson 7

Introduction to State Machines

Every mechanism on your robot is always in exactly one condition: an intake is idle, or running, or holding a game piece. A shooter is spinning up, or ready, or cooling down. A state machine makes those conditions explicit and enforces that only defined transitions are possible. It is the single pattern that separates reliable FRC code from code that works until it doesn't.

By the end of this lesson, you will:

Explain what a state machine is and why it handles complex mechanism behavior better than if/else chains
Implement a state machine using an enum and switch statement for an intake subsystem
Add entry actions (run once on state entry), during actions (run every cycle), and exit actions (run once on leave)
Define transition conditions that move the machine between states based on sensor input and controller events
Identify the state machine pattern in Team 2910's competition code

Why if/else Chains Break Down

Consider an intake with three behaviors: idle (stopped), running (collecting), and holding a game piece (stopped, confirmed). With if/else, you write something like: "if A button, run. If beam break, stop. If B button, eject." This works until the robot is already holding a game piece and the driver presses A again — do you restart the intake? What if the beam break triggers while ejecting? Each new edge case requires another conditional branch, and the interactions between branches become impossible to reason about.

A state machine replaces this combinatorial explosion with a simple rule: the current state determines the behavior. Transitions determine when states change. There are no hidden interactions — the behavior at any moment is completely described by one variable.

The Entry / During / Exit Pattern

Every state can have three types of actions:

Entry action — runs exactly once when the machine transitions into this state. Starts a timer, logs a message, fires a solenoid.
During action — runs every 20ms cycle while the machine is in this state. Commands motors, reads sensors, updates displays.
Exit action — runs exactly once when the machine transitions out of this state. Cleans up — stops motors, resets a flag.

The during action is the only one that runs every cycle. Entry and exit run once per transition. Together they give you precise control over what happens at state boundaries — which is exactly where intake jams, scoring failures, and unexpected behaviors tend to live.

State Machine Simulator

The simulator below models a four-state intake pipeline: IDLE → INTAKING → HOLDING → SCORING. Click the event buttons to fire transitions and watch the active state, code case, and output values update. The log panel describes what just happened.

Intake State Machine Simulator

⭕ IDLE

🔄 INTAKING

🟢 HOLDING

🚀 SCORING

Active switch case (during action)

case IDLE: intakeMotor.set(0.0);

case INTAKING: intakeMotor.set(INTAKE_SPEED);

case HOLDING: intakeMotor.set(HOLD_SPEED);

case SCORING: shooterMotor.set(SHOOT_SPEED);

Current values

stateIDLE

intakeMotor0.0

shooterMotor0.0

gamePieceHeldfalse

Ready. Press A to begin intaking a game piece.

The Full Implementation

The simulator above models this code. Read through it carefully — notice how each case handles its during action, how transitions are written as if checks inside the case, and how entry actions use a separate boolean flag.

// The minimal state machine pattern — enum + switch in periodic public enum IntakeState { IDLE, INTAKING, HOLDING, SCORING } private IntakeState state = IntakeState.IDLE; @Override public void teleopPeriodic() { // ── TRANSITIONS ── check events, update state ───────────────── switch (state) { case IDLE: if (controller.getAButton()) state = IntakeState.INTAKING; break; case INTAKING: if (!controller.getAButton()) state = IntakeState.IDLE; if (!beamBreak.get()) state = IntakeState.HOLDING; // beam blocked break; case HOLDING: if (controller.getBButtonPressed()) state = IntakeState.SCORING; break; case SCORING: if (shotConfirmed()) state = IntakeState.IDLE; break; } // ── OUTPUTS ── apply motor commands for current state ───────── switch (state) { case IDLE: intakeMotor.set(0.0); break; case INTAKING: intakeMotor.set(INTAKE_SPEED); break; case HOLDING: intakeMotor.set(HOLD_SPEED); break; case SCORING: shooterMotor.set(SHOOT_SPEED); break; } SmartDashboard.putString("Intake State", state.name()); }

An entry action runs once when the machine enters a state. The most reliable pattern: track previousState and compare each cycle to detect a transition.

private IntakeState state = IntakeState.IDLE; private IntakeState previousState = IntakeState.IDLE; @Override public void teleopPeriodic() { IntakeState newState = computeTransition(); // same switch logic as before // ── ENTRY ACTIONS ── run once on state change ────────────────── if (newState != previousState) { switch (newState) { case INTAKING: intakeMotor.setNeutralMode(NeutralModeValue.Coast); // entry: soften for game piece System.out.println("Intake started"); break; case HOLDING: intakeMotor.setNeutralMode(NeutralModeValue.Brake); // entry: grip the game piece rumble(0.3, 0.2); // entry: haptic feedback break; case SCORING: scoringTimer.restart(); // entry: start shot timer break; case IDLE: intakeMotor.set(0.0); // exit cleanup in entry of IDLE break; } } state = newState; previousState = newState; applyOutputs(); // during actions (same switch as before) }

A robot-level state machine coordinates multiple subsystems. Rather than every subsystem having its own scattered if/else chains, a single RobotState enum drives the behavior of all mechanisms simultaneously.

public enum RobotState { IDLE, INTAKING, GAME_PIECE_HELD, AIM_AND_SHOOT, CLIMBING } private RobotState robotState = RobotState.IDLE; @Override public void teleopPeriodic() { // One switch drives all subsystems coherently switch (robotState) { case IDLE: intake.stop(); shooter.idle(); if (driver.getAButton()) robotState = RobotState.INTAKING; if (operator.getStartButton()) robotState = RobotState.CLIMBING; break; case INTAKING: intake.run(); shooter.idle(); if (intake.hasGamePiece()) robotState = RobotState.GAME_PIECE_HELD; if (!driver.getAButton()) robotState = RobotState.IDLE; break; case GAME_PIECE_HELD: intake.hold(); shooter.spinUp(); if (driver.getRightBumper()) robotState = RobotState.AIM_AND_SHOOT; break; case AIM_AND_SHOOT: intake.feed(); shooter.shoot(); if (!intake.hasGamePiece()) robotState = RobotState.IDLE; break; case CLIMBING: intake.stop(); shooter.stop(); climber.run(operator.getLeftY()); break; } }

State Transition Diagram

Before writing code, draw the diagram. Every state is a circle; every transition is an arrow with its condition. If you can't draw it, you can't code it reliably.

Intake State Transition Diagram

🔍 LRI Observation

When I look at a team's code during inspection I search for two things: state machines and their absence. A team with a robot-level RobotState enum can tell me at any moment exactly what the robot is doing and why — because the answer is one variable read. A team with a dozen boolean flags and nested if/else chains can't. I've seen robots stop scoring mid-match because two boolean flags got out of sync in a way nobody anticipated. The state machine exists precisely to make that class of bug impossible: the current state is truth, and truth has exactly one value.

⚙️ 🔌 System Check

Every mechanism that has more than two behaviors needs a state machine. Two behaviors (run/stop) can be an if/else. Three or more — intake, hold, eject, jam-recovery — need states.
The state enum is the single source of truth. Do not maintain a parallel boolean flag (isIntaking, isHolding) alongside the state enum. Derive any needed booleans from the state: isHolding() { return state == IntakeState.HOLDING; }.
Separate transition logic from output logic. One switch determines what state to be in, another determines what to do in that state. Mixing them creates cases where the motor command changes mid-transition in unexpected ways.
Publish the state name to SmartDashboard. SmartDashboard.putString("State", state.name()) gives the drive team and pit crew a live status readout. State labels are the first thing to check when a mechanism stops working.
Draw the diagram before writing the code. If you cannot draw every state and every transition arrow, you don't understand the mechanism well enough to code it. The diagram is also the fastest way to explain the code to a teammate.

Knowledge Check

An intake code uses isIntaking = true/false and hasGamePiece = true/false as separate boolean flags. A bug causes isIntaking to be true and hasGamePiece to be true simultaneously. What would a state machine with an IntakeState enum do differently?

1A state machine can also get into this illegal combination
2A state machine makes the combination structurally impossible — there is one variable with one value; the state is either INTAKING or HOLDING, never both simultaneously; invalid combinations cannot be represented
3A state machine would throw an exception in this case
4No difference — state machines and boolean flags are equally expressive

In the entry/during/exit pattern, which action type should spin up the shooter flywheel to its target RPM when the robot transitions into the GAME_PIECE_HELD state?

1During — the flywheel speed should be applied every cycle
2Entry — the spin-up command should be sent once when the state is entered; the flywheel control loop then maintains the speed autonomously; re-issuing the spin-up setpoint every cycle is redundant and potentially disruptive to the PID loop
3Exit — spin up the flywheel before leaving GAME_PIECE_HELD
4It doesn't matter — entry and during produce the same result

A programmer puts both the transition logic and the motor output logic in the same switch statement case: case INTAKING: if (beamBreak.get()) { state = HOLDING; intakeMotor.set(0); } else { intakeMotor.set(0.65); }. What is the architectural problem?

1Nothing — combined transition and output is the standard pattern
3The transition check changes the state mid-cycle and also manually sets the motor — on the transition cycle, the motor gets 0 from the inline command rather than the HOLDING case's logic; separating transitions from outputs ensures the output switch always runs for the current (post-transition) state, not a manually-specified value
3The case cannot contain an if statement
4The beamBreak.get() call is too slow to be in a switch case

💪 Practice Prompt

Build a Complete Subsystem State Machine

Draw the state diagram for your intake subsystem before writing any code. Include at minimum: IDLE, INTAKING, HOLDING, EJECTING. Draw every transition arrow and label each with its condition.
Implement the enum and the basic switch pattern (transitions in one switch, outputs in another). Wire the transitions to controller button inputs and the beam break sensor from Lesson 4.
Add entry actions: when entering HOLDING, switch the intake motor to Brake mode and trigger a brief controller rumble. When entering IDLE from HOLDING, switch back to Coast.
Publish the state name to SmartDashboard in robotPeriodic(). Watch it update in real time during practice. Does it always show what you expect?
Add a fifth state: FAULT (triggered if the intake motor draws over 40A for more than 0.5 seconds — use a timer). In FAULT, stop the motor and display a dashboard alert. Add a manual reset to return to IDLE.
Bonus: Implement a robot-level RobotState enum that controls both the drive and intake simultaneously. In INTAKING state, limit drive speed to 60%. In SCORING state, limit to 40% and prevent reversing. Confirm the drive behavior changes correctly when the intake state changes.