Example: A primitive move-to-goal behavior

Example: A primitive move-to-goal behavior

This example shows how a primitive behavior can be designed using OOP
principles. In 1994, the annual AAAI Mobile Robot Competitions had a “Pick
Up the Trash” event, which was repeated in 1995 at the joint AAAI-IJCAI
Mobile Robot Competition. 129;66 The basic idea was for a robot to be placed
in an empty arena about the size of an office. The arena would have Coca-
Cola cans and white Styrofoam cups placed at random locations. In two
of the four corners, there would be a blue recycling bin; in the other two,
a different colored trash bin. The robot who picked up the most trash and
placed them in the correct bin in the allotted time was the winner. In most
years, the strategy was to find and recycle the Coca-Cola cans first, because
it was easier for the robot’s vision processing algorithms to perceive red and
blue.
One of the most basic behaviors needed for picking up a red soda can and
moving to a blue bin is move_to_goal. When the robot sees a red can, it
must move to it. When it has a can, it must find and then move to a blue bin.

It is better software engineering to write a general move to goal behavior,
where only what is the goal—a red region or a blue region—varies. The goal
for the current instance can be passed in at instantiation through the object
constructor.
Writing a single generic behavior for move_to_goal(color) is more
desirable than writing a move_to_red and a move_to_blue behaviors.
From a software engineering perspective, writing two behaviors which do
the same thing is an opportunity to introduce a programming bug in one
of them and not notice because they are supposed to be the same. Generic
behaviors also share the same philosophy as factoring in mathematics. Consider
simplifying the equation 45x2 + 90x + 45. The first step is to factor out
any common term to simplify the equation. In this case, 45 can be factored
and the equation rewritten as 45(x + 1)2. The color of the goal, red or blue,
was like the common coefficient of 45; it is important, but tends to hide that
the key to the solution was the move-to-goal part, or x.
Modular, generic code can be handled nicely by schemas as shown in
Fig. 5.2. The behavior move_to_goal would consist of a perceptual schema,
which will be called extract-goal, and a motor schema, which uses an
attractive field called pfields.attraction. extract-goal uses the affordance
of color to extract where the goal is in the image, and then computes
the angle to the center of the colored region and the size of the region. This
information forms the percept of the AFFORDANCE goal; the affordance of the Coke can is
the color, while the information extracted from the perception is the angle
and size. The attraction motor schema takes that percept and is responsible
for using it to turn the robot to center on the region and move forward. It
can do this easily by using an attractive field, where the larger the region, the
stronger the attraction and the faster the robot moves.
The move_to_goal behavior can be implemented as a primitive behavior,
where goal_color is a numerical means of representing different colors
such as red and blue:

 The behavior is the “glue” between the perceptual and motor schemas.
The schemas don’t communicate in the sense that both are independent
entities; the perceptual schema doesn’t know that the motor schema exists.
Instead, the behavior puts the percept created by the perceptual schema in a
local place where the motor schema can get it.
 Behaviors can (and should) use libraries of schemas. The pfields suffix on
the pfields.attraction()meant that attraction was a method within
another object identified as pfields. The five primitive potential fields
could be encapsulated into one class called PFields, which any motor
schema could use. PFields would serve as a library. Once the potential
fields in PFields were written and debugged, the designer doesn’t ever
have to code them again.
 Behaviors can be reused if written properly. In this example, the move to
goal behavior was written to accept a structure (or object) defining a color
and then moving to a region of that color. This means the behavior can be
used with both red Coke cans and blue trash cans.