Figure 3. Mini Sumo FSM.
get turned on?” Good question! My main level FSM has
states that handle that. The individual processes will handle
the priority arbitration, then the motor controller state looks
at the settings it has been given and acts upon them. I also
have a state whose whole job is to set up and read sensors.
Those values are left where the processes that need sensor
Figure 4. White Stripe.
16 SERVO 11.2010
input can get them and decide what to do. So, let’s look at
a more complete FSM that includes all of those states for a
more complete picture. Figure 3 shows a pretty good FSM
for a simple mini Sumo.
There is a wealth of information not shown here in
these drawings, but this is how it’s done. We draw pictures
to get the main process flow down. Then, we break each
of the higher level states down into their own FSMs and
decide their flow. It is rare that I’ve gone any deeper than
two levels of FSM; at that point, I’d be thinking of interrupt
service routines which is how you should do timers. In
many of these processes, you will be wanting to do
something for a while, then stop and do something else.
For instance, if your Edges process detects the edge of the
board, it will want to back up and turn around. You do
NOT want to sit in a for/next loop to do this! You would
set the motors to reverse, set a timer, and exit. The next
state would monitor the timer and switch states to the turn
state, set the motors, set the timer, and exit, and so on.
Pictures are nice, but eventually you will need to write
code. Listing 1 shows the code that I used in a mini Sumo
as a Search process; I called it “track().”
In this code, I used a simple counter (dur) to determine
when to be done with a state. A timer or a counter are
both viable ways to keep track of time. Note the beginning;
if anything with a higher priority than TRACK was running,
then we do nothing — we’re already busy. The initial if
block is the initialize phase of the state machine that gets
the FSM set up and running. At that point, we use the
switch statement to track each state of the state machine.
The leftSONAR and rightSONAR variables are set in the
sensors state of the main FSM to handle all of the various
sensor inputs. Finally, the movement states set the lS and rS
variables that the Motor Control state will use to set motor
speed and directions.
This method of programming does a lot more than just
allow us to have the appearance of concurrent processes
using cooperative multitasking. It also allows us to break
our processes down and isolate them so that we can add
new ones, and change them without the risk of breaking
some other part of the code. Yes, that is correct, you CS
majors out there. This allows us to nicely compartmentalize
our code to enhance cohesion and reduce coupling. An
older book, Mobile Robots by Jones and Flynn, gives a
great introduction into the concepts of this type of
programming. These authors are alumni from the MIT
robotics program run by Rodney Brooks. In this book, this
type of FSM was called subsumption programming for
behavioral robotics; each of the main level states would be
called a behavior and have a priority attached to it. I
recommend this book for some light reading.
For even more on behavioral programming I really
recommend Vehicles: Experiments in Synthetic Psychology
by Valentino Braitenberg. This simple and fast reading book
will open your eyes to great ways to think of programming
simple robots that make them very life-like.
No discussion about a robot would be complete
