AI seems to be everywhere right now: driving cars, generating images, counting the number of r's in the word "strawberries". It can be great for finding patterns in large datasets, but in robotics we're usually reading a bunch of sensor readings and waiting for different thresholds to be met. That's where Finite State MachineS (FSM's) come in.
Don't worry, we'll get to AI in a few lessons. That B2B SaaS idea can wait.
A lot of the "thinking" robots need to complete tasks doesn't require machine learning or neural networks. Like most things in your life, it just needs ✨structure✨.
Recall the Think-Sense-Act loop from Lesson 2.
An FSM doesn't learn or adapt; it just follows a set of clear rules. You break a robot's behavior into states (like "moving forward," "turning," or "charging") and then define inputs that trigger switches between them. And depending on the state, there may be one or two outputs occurring before moving around to more states. FSMs don't make the robot "smart," but they give structure to its decisions, and that's often exactly what you need to build reliable, predictable behavior.
FSM's can be used for things other than robots too - let's use an example of how life used to be like for a software engineer before COVID.
This example is pretty self explanatory - the states are WORK, HOME, and BED, and the triggers are the arrows in between the states. However this example is missing inputs and outputs.
Now let's do a slightly more complex FSM with something I'm calling the "Illusion of Free Will Vending Machine". The IoFWVM is a basic vending machine with two options: Coke or Pepsi. When it's waiting for the user to make their choice, both the Coke and Pepsi buttons are lit up, signaling that it's ready. The moment you press one - say, Coke - the machine will only have the Coke button lit up as it dispenses the beverage. The same would work in reverse if you selected Pepsi. After the drink has been dispensed, the vending machine resets itself. It also doesn't accept cash; it'll only accept a card so that there isn't any need to return change to the user.
Let's define the initial states before handling inputs and outputs.
States of the IoFW Vending Machine
| State | Description |
|---|---|
| S0 - Idle | The IoFW vending machine is patiently awaiting someone to use it. We'd call this state S0, the initial or default state. |
| S1 - Money Inserted + Waiting for Selection | Someone has inserted money into the vending machine, and it's now awaiting the choice of Pepsi or Coke with both buttons lit up. |
| S2 - Dispensing Coke | Coke was chosen, so it is in the process of dispensing a can of Coke as the Coke button stays lit. |
| S3 - Dispensing Pepsi | Pepsi was chosen, so it is in the process of dispensing a can of Pepsi as the Pepsi button stays lit. |
Now let's define our inputs. I'm gonna use something called Gray Code, which is a technique of representing a value with a series of bits. Every input is given a bit which can have 1 of 3 values: 0, which means it's off, 1, which means it's on, and X which means it doesn't matter whether it's on or off in the current situation. So if I have 5 inputs and want to say that input #1 is on, input #5 is off, and the rest don't matter, the corresponding Gray Code would be: 1XXX0.
The vending machine has 4 inputs:
Inputs of the IoFW Vending Machine
| Input | Description | Gray Code |
|---|---|---|
| Money Paid | When this is on, it means that the user has paid for a drink. When off, it means it has not been paid. | 1XXX |
| Coke Selected | When this is on, it means the user has selected Coke. | X1XX |
| Pepsi Selected | When this is on, it means the user has selected Pepsi. | XX1X |
| Dispenser Sensor | Let's pretend we have a simple IR sensor at the bottom of the machine checking to see when a snack has dropped. When it's on, it means it's detected a snack that's fallen, and when it's off it means that no snack has fallen and isn't detected. | XXX1 |
Now that we have our states and inputs, we can define the outputs. Outputs are the actions that the vending machine will take when it's in a certain state.
Outputs of the IoFW Vending Machine
| Output | Description | Gray Code |
|---|---|---|
| Coke LED | When on, the LED for the Coke button is on. | 1XXX |
| Pepsi LED | When on, the LED for the Pepsi button is on. | X1XX |
| Coke Dispenser | When this is on, a can of coke is being dispensed. | XX1X |
| Pepsi Dispenser | When this is on, a can of pepsi is being dispensed. | XXX1 |
Alright, that was a lot of information about a hypothetical vending machine in a short amount of time. Try out this interactive tool below to see how the vending machine works and how the state, inputs, and outputs work together as you get a drink (also there's a reset button in case my JavaScript skills break your webpage, but it's not actually real in the example).
Interactive Vending Machine
Current State: S0 - Idle
Current Inputs
Current Outputs
Now that you've played around with the IoFWVM, I'm gonna build it out step by step in the diagram below.
Building the Finite State Machine
Step 1: Let's begin by laying out all our states. Don't worry about the inputs and outputs for now.
Inputs Reference
| Input | Gray Code |
|---|---|
| Money Paid | 1XXX |
| Coke Selected | X1XX |
| Pepsi Selected | XX1X |
| Dispenser Sensor | XXX1 |
Outputs Reference
| Output | Gray Code |
|---|---|
| Coke LED | 1XXX |
| Pepsi LED | X1XX |
| Coke Dispenser | XX1X |
| Pepsi Dispenser | XXX1 |
Alright, so hopefully you now have some idea of how FSM's work. This article might be a bit contrived but I'm hoping that it's a good introduction to the concept with an interesting example. FSM's are a great way to structure a robot's behavior and to track what all your actuators and sensors are doing in any given moment.