Finite State Machines (FSM) are often an excellent design pattern for robot control software. As I was developing my first robotic vehicle, I started with just modifying and expanding upon some sample code I found online. This worked for a robot moving around at random, avoiding obstacles. But once I wanted to add positioning and navigation, it became difficult to keep track of where the logic should be at each step and each time the main control loop executed. I realized that a state machine approach was the solution, and it’s worked out beautifully.
The formal, mathematical definition of an FSM is such brain numbing, eye popping mumbo jumbo I feel certain that 9 out of 10 electronic engineering and IT students switch off in the first 5 minutes of the FSM lecture series, never to ever benefit from the power of FSMs in their work. This is not difficult stuff, it’s just made to look difficult by the academics!
The basic concept of an FSM is that the system is, at any time, in a specific, pre-defined state. Multiple states are defined, along with the internal or external events that cause the system to transition from one state to another. The functions that need to be performed for each transition from one state to another are then determined, and, of course, you have functions to be performed when in a given state. Not all events trigger a state transition, some are processed and handled with the system staying in the same state. It’s easiest to explain by example. A good, short tutorial with examples can be found in the online article Application Design Patterns: State Machines, along with some useful design hints. Below, I use the state-machine model I developed for my MARV-1 autonomous dead-reckoning vehicle as an example.
State Machines can be represented in several ways. One approach is a state transition matrix. Below is the matrix for the code for my MARV-1 autonomous vehicle:
The topmost row shows the seven states that the robot can be in. The leftmost column shows the internal and external events that can cause a change from one state to another. For example, “Button 1 pressed” is an external event. If MARV-1 is currently in the Off state, it transitions to the Orienting state. If it’s in any other state, it transitions to Off. “Completed calculating next heading” would be an internal event that causes a transition from the Orienting state to the Turning state. If, instead, the last waypoint in the list had already been processed, then there would be a transition from the Orienting to the Off state.
In C/C++/Arduino code, states are typically coded using the Switch command. Each Case ends with a break;, since the system can only be in one state at a time. There can be code to run each time a state is entered for the first time and code to run when you exit a particular state. This code can be dependent on the specific transition, e.g., the exit code from Orienting to Off is different than from Orienting to Turning. I found it easier to use exit code rather than entrance code wherever possible, because then I didn’t have to set a flag and check each time through the main loop to determined if I was entering a state for the first time or not.
In fact, 95 percent of the code in the main Loop for my MARV-1 vehicle is inside a single Switch statement. The exceptions are checking for the Button 1 press, since that must be done in every state, and updating position and orientation, since, with the exception of the Off state, that must always be done.
You’ll notice that most of the cells in the state transition matrix are empty. That’s because most events only affect one or two states. That means that you don’t need to check for those events when in any of the other states. The state machine design pattern makes coding simpler and much, much easier to follow. It also allows you to change out the details within a state (inside a specific case in your code) without affecting the rest of your code. The exception to this is the transition triggers themselves and the exit processing code.
Another way of designing or documenting your Finite State Machine is with a state machine diagram. Here’s the same information for MARV-1, presented in pictorial form:
In the case of MARV-1, I started my planning figuring on an Off state and an On state. Of course, the On state quickly was subdivided into more. Since MARV-1 uses tank-style turns and always either moves in a straight line or turns in place, it was logical to have a Turning state and a Traveling state. As I worked on the code, I found it made sense to break out the Orienting from the Turning, even though the Orienting is just some calculations that complete in a single pass through the main Loop. Similarly, it became easier to code to break the obstacle avoidance maneuvering into 3 states, one for each step in the 3 step obstacle avoidance approach I decided on: Back up, turn right, go forward a ways, hopefully clearing the original obstacle. As you can see from the table or picture, if MARV-1 is still pointing towards an obstacle after turning, it goes back to the Avoid:Backing state, as it does if it detects an obstacle while moving forward.
Finite State Machines are a simple and effective concept for robot software, and I encourage you to plan out your next project using this approach.