A critical issue is how to coordinate and control the activity of an autonomous system's GBs. In our architecture, this breaks down into two issues: controlling the interaction of the software modules (e.g., Guidance and Navigator) and controlling the activity of the GBs within each module. The first issue has been addressed over the last ten years or so, and we believe we have that problem well in hand. The second issue, however, is more problematic, and will require a substantial effort.
This issue has arisen in others' work on behavior-based control, of course.
Some researchers allow behaviors to run in parallel and use an arbiter to
determine which behavior's output is the one passed along to the hardware;
this is the approach taken, for example, in the subsumption architecture
[\protect\citenameBrooks, 1986]. Others object to this approach for the very good reason that
the subsumption mechanism is rather ad hoc and vehicle-specific and
possibly situation-specific. Bellingham's ##1[][]bellingham90
behavior-based AUV controller, for example, has a mechanism for changing the
subsumptive relationships based on the context the vehicle is in. Maes
##1[][]maes90 instead does away with the arbiter entirely, at least on
first glance, by using a spreading activation scheme to control the behaviors
activities.
Part of the difficulty in
controlling behaviors in a generic way is that they are black boxes in most
approaches: in the researchers' desire to get away from complicated control
mechanisms, they removed any vestige of an AI-like controller from their
systems. Unfortunately, this means that they essentially pushed knowledge
about the behaviors and their interactions into the subsumption (or other)
mechanism in an implicit (procedural) rather than explicit (declarative) form.
Ergo the ad hoc result.
In our approach, generic behaviors are software objects that have associated with them enough knowledge about their function, their input-output needs, and their interactions with other behaviors to allow them to be coordinated by the architecture. In a departure from other work on behavior-based control, an AUV using our architecture has only a subset of its potential behavioral repertoire active simultaneously. We wish to make as few assumptions about the underlying computer hardware as possible in order that our approach may remain generic. Other behavior-based approaches that have all behaviors active at once often rely on specialized hardware. To maintain generality, the model for our behaviors is that they will be ``run'' as processes under a real-time operating system on standard hardware. Given this, it would be inefficient to have all behaviors active, since many will be inappropriate for the situation and mission. Instead, behaviors can be started and stopped as needed.
Control of behaviors occurs at the level of the EAVE architecture software modules. In addition to the behaviors themselves, each module (e.g., Guidance) contains the necessary knowledge and procedures to schedule (i.e., activate and deactivate) appropriate behaviors, manage their inputs and outputs, and resolve conflicts between them (i.e., between their outputs). A schematic view of one of the software modules is shown in Figure 4.
