Page 21 - Designing Autonomous Mobile Robots : Inside the Mindo f an Intellegent Machine

Chapter 1

keyword here is “virtually,” since the permutations of stimuli and reactions become
too convolved for prediction through even the most enlightened observation.
When we truly begin to grasp this fact, the whole process of programming autono-
mous systems takes on an almost metaphysical dimension. Input data can no longer
be processed at face value, but must be filtered in relation to other data, and accord-
ing to experiences of the recent past. In the process of doing this, we begin to see
our own human behavior in a new light. Fear and caution, for example, begin to
look like excellent control modification mechanisms, and not merely human
emotions.
Given the complexity of the task ahead, we must plan our approach carefully. The
second most frustrating phase of any complex project is determining the architecture
to be used. The first most frustrating phase is realizing after months of trying to
implement a flawed architecture that it has degenerated into a mass of patches and
expedients, that it has lost any semblance of elegance, and that it will have to be
razed to the ground and rebuilt.
While developing our architecture, we try to think of all the various capabilities we
will need and vaguely how they will be performed in hardware and software, and
then envision a structure that can be used to tie them together. We then think of
things that could go wrong, and challenge our ephemeral structure. This often causes
the rickety conceptual framework to crash to the ground, but each time it does so
we build anew with more robust geometries. Often a vicious circle of reasoning will
be encountered which repeatedly flips us from one approach to another, only to be
pushed back again by complex considerations, but with single-minded persistence
our architecture will eventually emerge.

I will warn of as many traps as I can, but others you will have to find yourself. Just
remember that you always need a “Plan B.” That is, you must always keep in mind
how you will adapt your approach if one or more elements prove flawed.

Rule-based systems, state-driven systems, and other potential tar pits

To some extent, rule-based systems and state-driven systems are simply opposite
sides of the same coin. In its simplest form, a state-driven system attempts to provide
a discrete block of instructions (rules) that define the machine’s reaction to its
inputs for a given state or circumstance. It is almost inevitable that any architecture
will have elements of such a structure, but appropriately defining the states is the key.

4