Our resident expert on all things
robotic is merely an email away.
roboto@servomagazine.com
Tap into the sum of allhumanknowledge and get your questions answered here!
From software algorithms to material selection, Mr. Roboto strives to meet you
where you are — and what more would you expect from a complex service droid?
by
Dennis Clark
Background
On Code Reliability:
Between last month and this
month, I have discovered many
interesting things. Most obvious is
that there is more than one kind of
Roomba controller! Some are faster or
more tolerant of the way you send it
SCI commands; others, not so much.
My old Roomba 410 is either
faster or more tolerant of lots of SCI
commands coming in. My much
newer Roomba 440 is not so tolerant.
Code that ran great on the Roomba
“Red” ran very badly with resets,
ignored commands, and “went into
the weeds.” on my Roomba 440. I
found that if I delayed for about 5 ms
after each command, that everything
was happy! Okay. So be it. That delay
isn’t too bad if everything runs well
when we use it.
Remember from last month I said
that my Roomba Red would not run
straight? I took the wheel assemblies
apart and cleaned the wheel
encoders, and that straightened
everything right up (pun intended)!
This month's column can be called either "No good deed goes unpunished" or "Curiosity killed the cat." Last month, we looked at controlling an iRobot Roomba platform with an Arduino UNO. Questions came in about problems with my Roomba program, and I was asked if I
could make the code more robust and useful. I never shy away from a
challenge, so here you go! This month, we'll look at ways of programming that
will allow multiple tasks to run (apparently) at the same time.
On More Useful Code:
Last month’s code was little more
than a giant “if/then” statement that
did a little bit of robot-ish stuff. This
month, I’m going to talk about finite
state machines in embedded
processors like we use for many of our
robots. I’m not going to go into CS-
101 programming course language
about state machines, so suffice it to
say that a state machine allows a
program to move from one known
condition — or state — to another one
in a predictable manner.
“Huh!” you say. “So what?”
Indeed, that sounds like any program
you write, doesn’t it? The beauty of a
state machine, however, is that your
code will hold that state while you tell
your microcontroller to go off and do
something else. (I’ll bet that got your
attention.)
A long time ago (you know, like
back in the 1990s), the robotics
pioneer Rodney Brooks wrote about
something called robot subsumption
architectures to create what looked
like intelligent behavior in robots. Each
element in a subsumption architecture
is a behavior that may or may not use
sensors for input, and which does use
motors (or similar actuators) for
output. Higher-level behaviors take
control of (subsume) output
actuators, even if lower priority
behaviors are active. Each behavior is
implemented in what Brooks called
modified finite state machines.
