Steps in Designing a Reactive Behavioral System

Fig. 5.3 shows the steps in designing a reactive behavioral system, which
are taken from Behavior-Based Robotics10 and a case study by Murphy.98 This
section will first give a broad discussion of the design process, then work
through each step using the winning approach taken in the 1994 Unmanned
Ground Vehicle Competition.
The methodology in Fig. 5.3 assumes that a designer is given a task for the
robot to do, and a robot platform (or some constraints, if only budgetary).
The goal is to design a robot as a situated agent. Therefore, the first three
steps serve to remind the designer to specify the ecological niche of the robot.
The fourth step begins the iterative process of identifying and refining the
set of behaviors for the task. It asks the question: what does the robot do? Defining
the ecological niche defines constraints and opportunities but doesn’t
necessarily introduce major insights into the situatedness of the robot: how it
acts and reacts to the range of variability in its ecological niche. This step is where
a novice begins to recognize that designing behaviors is an art. Sometimes,

ifying its motor and perceptual schemas. This is where the designer has to
write the algorithm for finding red blobs in a camera image for the random
search until find red and move to red behaviors. The designer usually programs
each schema independently, then integrates them into a behavior and
tests the behavior thoroughly in isolation before integrating all behaviors.
This style of testing is consistent with good software engineering principles,
and emphasizes the practical advantages of the Reactive Paradigm.
The list of steps in implementing a reactive system can be misleading. Despite
the feedback arrows, the overall process in Fig. 5.3 appears to be linear.
In practice, it is iterative. For example, a supposed affordance may be impossible
to detect reliably with the robot’s sensors, or an affordance which
was missed in the first analysis of the ecological niche suddenly surfaces.
The single source of iteration may be testing all the behaviors together in the
“real world.” Software that worked perfectly in simulation often fails in the
real world.