When you program using an FSM, your program
needs to define and handle when control passes from one
part of the program to another. In some ways, this could
be called “cooperative” multitasking which means that the
different parts of the program cooperate to avoid any one
part starving another part of the program for processing
time. We use state machines to handle this. I won’t go into
a discussion about Mealy vs. Moore state machines. We’ll
be using a combination of them, as well as a time
modified version, that Rod Brooks and his MIT team call
the Modified FSM, or MFSM for short.
“Well, that’s nice,” you say, “How does one do this
kind of programming?” I’m glad you asked! The first thing
you need to do is break out your pencil and paper and
start drawing pictures. Let’s say that you have a mini Sumo
robot that needs to do three things to stay alive on the
1. Look for the other guy.
2. Attack the other guy.
3. NOT fall off the edge of the board.
This seems obvious for a mini Sumo, and is a great
place to start drawing pictures of your state machine.
Figure 1 shows the simplest form that this FSM can
One always has a first state (initialize, in this case)
that gets the ball rolling for the state machine and explicitly
defines where the state machine starts. This state passes
off to Search, which then passes to Attack, and then to
Detect Edge which passes back to Search. Each of these
states represent a block of code that is in itself another
state machine. Seems simple, right? Who out there sees
the problem with doing this on a robot? Exactly! The
motors! Who controls the motors? They can’t all do it, or
every state in the main loop will tell the motors to do
something different, and this will happen very, very often
because if you have done your job right, your code will be
switching quickly to avoid starving any of your main states
in Figure 1.
We now must add in the concept of priority. In the
case of our mini Sumo’s motors, we have a single
resource that several processes want to control. Only one
of them can have control at a time. The best way to handle
this is to determine which of the processes is the most
important, which is second, and so on. My choice is the
Detect Edge process for most important. If we run off of
the edge, the game is over and our robot looks dumb. My
vote for second most important is the Attack process since
you want it to react when the Search process finds
Now we know that we need an FSM which keeps
switching between processes that are each also FSMs, and
that those processes need to have a priority attached to
them to gain proper access to a limited resource — the
motors. How? To make everything work well, we need to
break each of these processes up into bite size chunks of
Figure 1. Simple state machine.
code that run fast, do something, and then exit after
setting up their next state to process. Let’s look at how we
would have the Attack process do this. Figure 2 shows a
breakdown of a Search process that I have used.
Seems pretty simple? It is, actually. This FSM simply
looks at a sonar and determines if something is to the right
or left. The Find Enemy state then sets up a motor
direction, sets the next state, and exits. When this process
is again entered, it will be in the Wait for turn state where
it will remain until it has completed its turn. Then, it will set
the state back to Find Enemy and start over again.
“But when do I do the sensors? When does the motor
Figure 2. Search FSM.
SERVO 11.2010 15