Where do releasers go in OOP?

Where do releasers go in OOP?

The previous examples showed how behaviors can be implemented using
OOP constructs, such as classes. Another important part of a behavior is how
it is activated. TWO PURPOSES OF As was discussed in Ch. 3, perception serves two purposes:
PERCEPTION to release a behavior and to guide it. Perceptual schemas are clearly used for
guiding the behavior, either moving toward a distinctively colored goal or
following a wall. But what object or construct contains the releaser and how
is it “attached” to the behavior?
The answer to the first part of the question is that the releaser is itself a perceptual
schema. It can execute independently of whatever else is happening
with the robot; it is a perceptual schema not bound to a motor schema. For
example, the robot is looking for red Coke cans with the extract_color
perceptual schema. One way to implement this is when the schema sees
red, it can signal the main program that there is red. The main program can
determine that that is the releaser for the move to goal behavior has been
satisfied, and instantiate move_to_goal with goal=red. move_to_goal
can instantiate a new instance of extract_color or the main program
can pass a pointer to the currently active extract_color. Regardless,
move_to_goal has to instantiate pfield.attraction, since the attraction
motor schema wouldn’t be running. In this approach, the main program
is responsible for calling the right objects at the right time; the releaser is attached
to the behavior by the designerwith little formalmechanisms tomake
sure it is correct. This is awkward to program.
Another, more common programming approach is to have the releaser be
part of the behavior: the single perceptual schema does double duty. This
programming style requires a coordinated control program. The behavior
is always active, but if the releaser isn’t satisfied, the coordinated control
programshort-circuits processing. The behavior returns an identity function,

in the case of potential fields, a vector of (0.0,0.0), which is the same as if the
behavior wasn’t active at all. This style of programming can tie up some
resources, but is generally a simple, effectiveway to program. Fig. 5.2 shows
the two approaches.
Either way, once the robot saw red, the observable aspect of move to goal
(e.g., moving directly toward the goal) would commence. The extract goal
schema would update the percept data (relative angle of the goal and size of
red region) every time it was called. This percept would then be available to
the motor schema, which would in turn produce a vector.
As will be covered in Sec. 5.5, the releasermust be designed to support the
correct sequence. Depending where the robot was in the sequence of activities,
the robot usesmove to goal tomove to a red Coke can or a blue recycling
bin. Otherwise, the robot could pursue a red Coke can and a blue recycling
bin simultaneously. There is nothing in the OOP design to prevent that from
happening—in fact, OOP makes it easy. In this situation, there would be two
move to goal objects, one instantiated with goal of “red” and the other with
goal of “blue.” Notice that the move to goal behavior can use any perceptual
schema that can produce a goal angle and goal strength. If the robot needed
to move to a bright light (phototropism), only the perceptual schema would
need to be changed. This is an example of software reusability.