An AUV or other autonomous system can usefully be thought of as having a behavioral repertoire composed of primitive behaviors that combine to produce its overall behavior. The behaviors can be viewed as the AUV's operator set. This provides a potential user with a concise view of what the vehicle can do. It allows the user to easily design and specify a mission by using the behaviors as a vocabulary with which to describe desired goals and actions. We can imagine a user, for example, describing a mission to an AUV in terms of the behaviors TRANSIT (to a location), RASTER-SEARCH (an area), TRANSIT (home).
We take the approach that all of a system's activities, not just its sensorimotor control, can be thought of as the product of a set of interacting behaviors. Thus path planning, obstacle avoidance, communication, homeostatic functions, and controlling an effector or sensor can all be thought of as behaviors of the vehicle. We call this expanded view of what constitutes a behavior a generic behavior.
Generic behaviors (GBs) provide a common form in which to represent and implement functionality. In many ways, the concept of a generic behavior is like the concept of an ``object'' in object-oriented programming: a black box with well-defined inputs, outputs, and behavioral characteristics. This provides both data and control abstraction to free system designers and users from worrying about the implementation details of how a generic behavior is achieved; instead, they can concentrate on using the generic behavior. As long as the generic behavior does what it is supposed to and respects its input/output conventions, only the implementor of that generic behavior needs to be concerned with the implementation details. The generic behaviors then become building blocks from which system designers can create a capable autonomous control system.
A generic behavior-based software architecture could be flat: that is, no hierarchy or other partitioning of the behaviors, and with each generic behavior interacting directly with any other. However, this has several disadvantages. It would be difficult to add a new behavior and ensure that it works well with the existing ones. It would also be difficult for a potential user to understand and use the architecture. Worse yet, a flat architecture does not adequately reflect the fact that the control task is inherently composed of subtasks that operate in different time domains: e.g., obstacle avoidance is in some sense a more time-critical behavior than path or mission planning.
We layer our behaviors, letting those that are closer to the actual hardware (and hence, faster) take over control of the vehicle when there is insufficient time for higher-level behaviors to respond. This is also the approach taken in the subsumption architecture [\protect\citenameBrooks, 1986] and related approaches. A problem with these approaches, however, is that the layering is often ad hoc: behaviors are layered based on what works, with no explicit attention to inherent time domains in the task. This tends to frustrate modification and user understanding. To address this, we incorporate behaviors into an existing hierarchical architecture, specifically the EAVE software architecture. This architecture provides a rough partitioning of behavior into abstraction and time domains that have both theoretical proven practical validity. It also splits behaviors between perception and action, as others (e.g., [\protect\citenameKaelbling, 1987]) have suggested as an improvement to the ``standard'' subsumption architecture. Figure 1 shows the EAVE architecture.
A layered architecture has many advantages. It partitions the overwhelming task of developing a software system for AUV control into reasonably-sized modules, each with a well-defined set of tasks, abilities, and information needs. By closing the control loop at each level, lower-level, faster modules are able to respond quickly to the needs of a changing environment when the higher levels cannot, while the higher levels, though slower, have a longer planning horizon and can both sensibly guide the overall long-term behavior of the vehicle as well as ``condition'' the lower levels so that their responses are appropriate for the AUV's long-term goals. An advantage that cannot be over-stressed is that a layered architecture allows developers to implement bottom-up, from simple control tasks to progressively more difficult ones. Development and implementation at each level can thus depend on a fully-functional level beneath it; during testing, the functional lower level can rescue the vehicle if necessary. This proved to be very important during our portion of the work on the MAUV (Multiple Autonomous Underwater Vehicles) program [\protect\citenameAlbus, 1988].
Though we have considerable experience developing and using our generic hierarchical architecture, the internals of the modules themselves have been anything but generic. The overall behavioral repertoire of the vehicle has also not been viewed with an eye toward a generic, behavior-based approach. Consequently, we are building on the overall architecture, but developing the modules so that they are composed of interacting generic behaviors. This means that both low-level perceptual-motor actions as well as high-level ``cognitive'' actions (and everything in between) are treated identically as behaviors. By taking this approach, techniques for creating and coordinating behaviors found useful at one level apply equally well to all other behaviors.
To the user, an AUV using the behavior architecture is a black box with an advertised repertoire of behaviors it can perform. These are the top-level, or mission-level, generic behaviors. The user does not need to know how these work, only what they do. The mission-level behaviors constitute all the user needs to know about the vehicle in order to use it.
Internally, however, the picture is more complex. The mission-level GBs are software objects with their own well-defined inputs, outputs, and behavior. The mission level of the architecture is responsible for activating or deactivating these behaviors as the users' mission unfolds. However, the behaviors at this level do not interact directly with the vehicle hardware, nor do they perform particularly low-level tasks. Instead, these are high-level behaviors, encoding (possibly abstract) knowledge about how to carry out some behaviors. Some mission-level behaviors, such as COMMUNICATE-WITH-USER, may themselves perform all the work necessary at the mission level. Others-perhaps most of them-will instead carry out their tasks by activating, deactivating, and coordinating the activities of generic behaviors at the next lowest level. Thus a cooperative photography generic behavior might perform the work necessary to communicate with a peer AUV at the mission level, but distribute the rest of the work by activating TRANSIT, PHOTOGRAPH, and other behaviors in the next-lower level (the ``environment level'') of the architecture.
A behavior at one level may cause the invocation of the same generic behavior at another level (see Figure 2). For example, AVOIDANCE, a behavior for avoiding obstacles, at the mission level may have little to do, perhaps only assuring that goal locations are not within known objects. It would, however, cause the Mission Planner module to activate the behavior AVOIDANCE in the Navigator module, which would ensure that path planning was done when motion is considered at that level. Activation of this behavior would, in turn, activate AVOIDANCE at the next lower level, in the Guidance module. At this level, the behavior is responsible for obstacle avoidance. Thus a single conceptual behavior, avoiding obstacles, is different for different levels of the architecture. The user, however, needs see none of this; to him or her, when the vehicle is told ``avoid obstacles'' it correctly avoids scheduling goals within objects, plans paths to avoid known obstacles, and uses its obstacle avoidance sonar (OAS) to go around unknown obstacles as they are encountered. The various instantiations of AVOIDANCE effectively partition the user-level behavior across the architecture so that all levels of the architecture produce the right behavior.
Generic behaviors in a module can also cause the activation of GBs in their peers. For example, when the Guidance module's AVOIDANCE behavior is activated, Guidance causes immediate activation of the OAS behavior in its peer, Data Assessment, to watch for obstacles. When AVOIDANCE becomes inactive (e.g., during docking), then it notifies Data Assessment that it no longer requires the activity of OAS; if there is no other reason for this GB to be active (e.g., some GB in Situation Assessment has requested it), then OAS becomes inactive.
In the GB approach, the software modules of the EAVE AUV control architecture have become coordinators of behaviors. They are responsible for establishing connections between behaviors for communication, for activating/deactivating them, and for monitoring and maintaining constraints between their activities and outputs. In the role of scheduler, consider a module such as the Mission Planner during a search mission. The mission would be specified to it in terms of generic behaviors (either directly by the user or as the output of the user interface) as shown in Figure 2. Mission Planner would be responsible for assuring that TRANSIT, RASTER-SEARCH, etc., are activated and deactivated at appropriate times.
In the role of coordinator, consider a module such as Guidance. When it activates AVOIDANCE, it must assure a connection between the inputs to the behavior and data that the behavior needs, including the output of Data Assessment's OAS (possibly available via an intermediary working memory). It must also iron out conflicts between behaviors. Some conflicts exist due to competition. The AVOIDANCE behavior, for example, will compete with TRANSIT for control of the AUV's thrusters. Conflict resolution can be done in many ways, including subsumption [\protect\citenameBrooks, 1986]. Other conflicts have to do with more fundamental incompatibilities between behaviors. For example, AVOIDANCE conflicts with DOCKING. The task of the controlling software module is to recognize such conflicts and decide which behavior should be active and which should be suppressed. In doing this, it makes use of explicit knowledge about behaviors and their interactions. This knowledge is declaratively represented as part of the behavior definitions, as discussed below.