State Machines

A finite state machine (FSM) is a model of computation with a fixed set of states and rules for transitioning between them. At any moment, the robot is in exactly one state.

The Basics

Think of a traffic light:

States: [RED, YELLOW, GREEN]
Transitions:
  RED → GREEN (after 30 seconds)
  GREEN → YELLOW (after 25 seconds)
  YELLOW → RED (after 5 seconds)

At any moment, the light is in exactly one state. When a condition is met (a timer expires), it transitions to a new state.

Anatomy of a State Machine

1. States — discrete modes of operation (e.g., Idle, Navigating, Charging, Error)
2. Transitions — arrows between states that define when to switch
3. Guards — conditions that must be true for a transition to fire (e.g., battery < 20%)
4. Actions — code that runs when entering/exiting a state or during a transition

Example: Delivery Robot

Let's design a simple delivery robot with four states:

Guards and Transitions

A guard is a boolean condition that must be true for a transition to fire. In the example above:

• battery < 20 is a guard on the transition from NAVIGATING → CHARGING
• battery >= 100 and mission_complete is a guard on CHARGING → IDLE

Guards prevent invalid transitions. Without them, you'd need messy nested ifs to check every condition.

Hierarchical State Machines

Real robots need more structure. A hierarchical FSM lets you nest states within states.

OPERATING
  ├─ NAVIGATING
  │   ├─ FOLLOWING_PATH
  │   ├─ AVOIDING_OBSTACLE
  │   └─ REPLANNING
  └─ CHARGING
      ├─ SEEKING_CHARGER
      └─ DOCKED

ERROR
  ├─ RECOVERABLE
  └─ FATAL

When you're in FOLLOWING_PATH, you're also in NAVIGATING and OPERATING. This means:

• You can define a transition from any OPERATING state to ERROR (e.g., on sensor failure)
• You don't need to duplicate "on sensor failure, go to error" in every sub-state

Entry and Exit Actions

You can run code when entering or exiting a state:

Entry actions are perfect for initialization (start a timer, load a map, publish a status message).

Exit actions are perfect for cleanup (stop motors, log telemetry, release resources).

When State Machines Excel

State machines are ideal when:

• Your robot has distinct modes (idle, moving, charging, error)
• Transitions are event-driven (user presses button, sensor detects obstacle)
• You need guaranteed behavior in each state (safety-critical systems)

They're less ideal when:

• You have many small, independent behaviors running in parallel
• Behavior needs to be composed from reusable pieces
• Transitions depend on complex logic rather than simple guards

That's where behavior trees come in (next lesson).

What's Next?

State machines give you clear, testable, structured behavior. But what if you have many small behaviors that need to run in parallel or be composed? That's where behavior trees shine. In the next lesson, we'll explore behavior trees and how they differ from state machines.