Page 129 - Introduction to AI Robotics

112
4 The Reactive Paradigm
where it is relative to the robot. Sensor data, with the exception of GPS, is
inherently ego-centric (e.g., a range finder returns a distance to the nearest
object from the transducer), so this eliminates unnecessary processing to
create a world model, then extract the position of obstacles relative to the
robot.

4. These systems inherently follow good software design principles. The modular-
ity of these behaviors supports the decomposition of a task into compo-
nent behaviors. The behaviors are tested independently, and behaviors
may be assembled from primitive behaviors.

5. Animal models of behavior are often cited as a basis for these systems or a par-
ticular behavior. Unlike in the early days of AI robotics, where there was a
conscious effort to not mimic biological intelligence, it is very acceptable
under the reactive paradigm to use animals as a motivation for a collection
of behaviors.

4.2.2 Advantages of programming by behavior
Constructing a robotic system under the Reactive Paradigm is often referred
to as programming by behavior, since the fundamental component of any
implementation is a behavior. Programming by behavior has a number of
advantages, most of them consistent with good software engineering princi-
ples. Behaviors are inherently modular and easy to test in isolation from the
system (i.e., they support unit testing). Behaviors also support incremental
expansion of the capabilities of a robot. A robot becomes more intelligent by
having more behaviors. The behavioral decomposition results in an imple-
mentation that works in real-time and is usually computationally inexpen-
sive. Although we’ll see that sometimes duplicating specialized detectors
(like optic flow) is slow. If the behaviors are implemented poorly, then a re-
active implementation can be slow. But generally, the reaction speeds of a
reactive robot are equivalent to stimulus-response times in animals.
Behaviors support good software engineering principles through decom-
position, modularity and incremental testing. If programmed with as high
LOW COUPLING a degree of independence (also called low coupling) as possible, and high co-
HIGH COHESION hesion, the designer can build up libraries of easy to understand, maintain,
and reuse modules that minimize side effects. Low coupling means that the
modules can function independently of each other with minimal connections
or interfaces, promoting easy reuse. Cohesion means that the data and op-
erations contained by a module relate only to the purpose of that module.