Finite state machines
States, transitions, triggers, guards, actions. How to describe an interactive system before you build it, with a turnstile, a video game character and a tap-access door.
A finite state machine is a way of describing a system that can only be in one of a fixed number of states, and moves between them when something happens. A turnstile is locked or unlocked. A game character is standing, running or jumping. A vending machine is idle, has a coin in, is dispensing, or is out of service. Before you write a line of Arduino code for something interactive, drawing it as a state machine tells you what the code has to do.
The turnstile
Two states, locked and unlocked. Two inputs, coin and push. The black dot is the start: we begin locked.
- Locked + push → still locked. Nothing happens.
- Locked + coin → unlocked. Action: release the lock.
- Unlocked + coin → still unlocked. Free money.
- Unlocked + push → locked. The customer went through.
The same thing as a table: current state, input, next state, output. Both views are useful. The diagram is easier to talk about; the table is closer to code.
The parts
- State. A situation where the system is waiting for something: time, a sensor, a result, a person. Drawn as a rounded rectangle with a name.
- Transition. An arrow from one state to another. Written on the arrow: the trigger (what happened), an optional guard (what has to be true for the transition to count), and the action (what the system does as it moves).
- Entry and exit actions. Things that happen every single time you enter or leave a state, no matter how you got there. Write those inside the state. If it only happens sometimes, it belongs on a transition instead.
- Self-transition. An arrow that leaves a state and comes back to it. A timer that fires and resets, say.
- Start is the filled dot. A closed-loop system has no end; an open-loop one ends at a dot inside a circle.
- Decision diamonds branch to more than one state on a condition. Concurrent regions, split by a dashed line, let two sub-states run at once: front brakes and rear brakes applying together.
A game character
Stand, run, jump. Inputs: up, A, nothing. From standing, A jumps, up runs. From jumping, A jumps again (a self-transition), and when the jump finishes with nothing pressed you land back in standing. Each state carries its own animations and rules. This is how the same button does different things depending on what the character is already doing.
A tap-access door with an alarm
A fuller example: a door opened with a fob, that alarms if it is left open.
Three states: locked, unlocked, open. Entry to any state writes a log entry, because it is a security system; locked also shows a red LED and unlocked a green one.
From locked: an authenticated tap unlocks (action: unlock). An unauthenticated tap beeps and stays locked. From unlocked: a 10 s timer relocks (action: lock), another tap just beeps, the automatic-door button runs the motor (a self-transition, because the button alone does not prove the door opened), and the door sensor reporting open moves us to the open state. Only the sensor can do that. If the motor jams, we stay unlocked, which is the honest answer.
From open: a 10 s timer sounds the alarm and loops back. Motion detected inside pauses the alarm for 10 s and loops back; someone is carrying something through. The sensor reporting closed locks the door. An authenticated tap while open goes back to unlocked and then, since the door is still open, straight back to open with a fresh timer. That is how you extend the time.
Nothing here handles an unauthenticated tap while the door is open. It does nothing, which is a choice the diagram makes visible.
For the same idea on a breadboard, see Traffic light state machine on Arduino.