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

Chapter 3

Flashback…
I vividly remember an occasion on which there was a loud disturbance coming from a
cubicle in the test area of the production floor. As I approached I saw the sensor head of
an SR-2 Security robot moving erratically back and forth above the wall of the cubicle.
I recognized the curses coming from the cubicle as those of the company artist who was
in a greatly agitated state. As he attempted to escape the small space, the robot repeat-
edly blocked his exit and threatened him like rabid animal.

After we subdued the robot by pushing one of its emergency stop buttons, we deter-
mined the cause of the event. Wanting to take some photos, the artist had turned on a
robot that was undergoing a software upgrade and did not yet have a matching set of
program chips installed. When the interrupts occurred, the robot’s program “went off
into the woodwork” and the robot tried to do the same!

This event caused us to build in a hardware latch that would detect illegal sequences and
lock the computer. Most modern processors have special interrupts that occur if illegal
instructions are encountered, but these won’t do any good if they are not properly pro-
grammed.
Similarly, after years of entertaining Windows users with the “blue screen of death” and
random acts of data vandalism, Microsoft finally incorporated good error trapping in its
XP operating system. We like to think Bill was copying us.

Context

Interrupt routines can be state driven or they can maintain context. State-driven in-
terrupt routines keep state data, like arrays and their pointers, to remember what
they were doing, but the routine always starts at the top and ends at the bottom. If
the program that uses the interrupt is to look like a normal program, and have exits
when it needs to wait for something, it may switch stacks during the interrupt to do
this. This is called context switching, and an interrupt routine that does this begins to
look like a real-time kernel. The two programs on either side of this slight of hand
appear to be completely independent of each other! I call this “going through the
looking glass.”

Consider the simple message decoder shown in Figure 3.2. This decoder expects a
serial message that always starts with a “#” character, followed by a low and high
character. The left side of Figure 3.2 shows how this might be accomplished with a
state-driven interrupt. Note that even with this oversimplified example, the program

26