Desired Functionality

In practice, the design of a behavior-based reactive control system is very te- dious and time-consuming for any non-trivial task. Due to the emergent nature of the overall system behavior, designing a set of behaviors producing a par- ticular desired system behavior often proves to be very tricky. In addition, the behavior engineer must consider numerous issues related to system inte- gration and interaction with the other system components. As a result, the design and implementation of behavior-based systems often appears to have little structure and seems to lack methodology, at least to outside observers. Programming complex behavior-based robot applications could be significantly improved by developing methods that allow for more systematic development, support prevalent software engineering desirabilities like modularity, functional abstraction, reuse, and reduce development time and effort by providing li- braries, and appropriate tools for design, implementation, and evaluation of partial or complete behavior-based systems. A few particular issues are ad- dressed in the next few paragraphs.

Reactivity by supporting concurrent behavior execution. A basic no- tion of all original behavior-based approaches is their intrinsic concurrency [13, 5]. This allows the programmer to factor out detection and handling of potential failure situations in separate behaviors and to retain a concise for- mulation of the actual task. The concurrent execution of all behaviors ensures automatic surveillance of potential failure situations. However, some more re- cent behavior-based approaches have traded concurrent behavior execution in favor of easier behavior sequencing. This puts the burden to ensure timely eval- uation of failure conditions back on the programmer. Therefore, we consider concurrent behavior execution for a generalized reactive control framework as indispensable.

Taskability by supporting behavior sequencing. A common weakness of the early behavior-based approaches is the difficulty to implement a wide set of different tasks. Murphy uses the notion of taskability for describing how easy it is to switch between different tasks [87]. Indeed, a wide spectrum of different tasks requires a large number of behaviors not all of which are relevant in all situations. If all behaviors are concurrently executed all the time, some behaviors may get in your way in undesirable situations. A much more concise approach is to only execute the minimal set of behaviors necessary to produce the desired system functionality. Upon arisal of certain situations, the system switches to another behavior set. Thus, temporal sequencing of behavior sets is a highly desirable mechanism to provide easy taskability of the robot. Fewer

6.2. BAP FRAMEWORK 73 concurrent behaviors also make it simpler for the programmer to understand the emergent properties of the active behavior set.

Modularity by hierarchical policy specification. Simple temporal se- quencing of behavior sets is often insufficient, if the application domain and the task set gets more complex. For example, in robot soccer (and many sim- ilar scenarios) there are numerous situations where the robot is supposed to select and execute a contingent plan out of several options, e.g. when executing one out of maybe 5 or 10 different special plays after a foul call. Each play – a contingent plan – can usually be represented by sequencing behavior sets (using e.g. a finite state machine). However, representing all such plays in a single large finite state machine of behavior sets gets soon very unwieldy and degrades maintainability. Therefore, concepts for hierarchically building poli- cies, which implement such contingent plans and have proper entry and exit semantics, would greatly simplify the overall structure of the behavior system and increase modularity.

Functional abstraction by providing behavior parameterization. In practice, there are many situations where behaviors in different behavior sets are quite similar and differ only in a few parameter settings, like settings for maximum translational and rotational velocities and accelerations, or safety distances to be observed. This holds even for behaviors on different mobile platforms, which may have different low-level sensing and actuating capabilities and different sets of parameters like maximum speed, accuracy of odometry, and so on. Thus, there is considerable potential for code reuse, if the behavior architecture supports functional abstraction and concepts for parameterization. As an example, consider a generic obstacle-avoidance behavior. The safety distance upon which it needs to react and influence the robot’s movements depends both on the scenario and inherent capabilities of the robot platform. A tour guide robot should avoid crashing into exhibits and visitors at all cost, while a rescue robot may have to account only for its own stability when pushing its way through obstacles in the disaster area on its way to a victim. In robot soccer, tackling (physical contact) is okay for a soccer playing robot as long as the referee does not object, but such a behavior would need dynamic adaptation after the robot has been shown a yellow card. So the parameterization of behaviors can not solely be derived from the service-provided metainformation for sensors and actuators.

Flexibility by allowing different arbitration mechanisms If more than one behavior is active and producing inputs for motor control, then the be- havior outputs are potentially in conflict and must be arbitrated. The various different behavior-based approaches, like subsumption, potential field methods, and fuzzy behaviors, mainly differ in what type of output the behaviors produce and what methods are used to arbitrate these outputs [93]. As the different

74 CHAPTER 6. EXTENSIBLE FRAMEWORKS approaches often have complementary benefits and pitfalls, it is desirable to use the most adequate approach in any particular situation. A general-purpose behavior architecture should therefore support the use of multiple arbitration mechanisms.

In order to professionalize software development for autonomous mobile robots, a state-of-the-art system development environment should provide program- ming concepts and tool support for implementing behavior-based reactive con- trol systems, and its design should observe the above design criteria. The next section presents the formal organization of behavior with the BAP framework, which was developed specifically with these design criteria in mind.