EusLisp of [Matsui and Inaba, 1999] is an object-based extension of Common Lisp with support for solid 3D modeling, concurrences, and robot manipulators. It can be conveniently used also for programming mobile robots.
Task Definition Language (TDL) of [Simmons and Apfelbaum, 1998] is an extension of C++ that allows task specification and manipulation. It has been used in numerous CMU and NASA robotics projects. A compiler translates TDL code directly to C++ code. TDL features very rich set of synchronization commands, which are expressed in straight-forward manner. This makes TDL unique compared to other task-control languages. TDL is working with task trees, where nodes are associated with actions that can succeed or fail. These are either goals or commands (leaf nodes). In addition, TDL utilizes constructs for exception handling, and task monitoring (actions performed repeatedly). The programs themselves manipulate the task trees, thus the same program can generate various task trees in different runs.
Microsoft Robotics Studio is a recent addition to the family of robotics languages and formalisms. It is based on Microsoft Visual Programming Language (VPL) and supports most of the currently used research architectures as well as a physics-based simulation.
2.12
Behavior-Based Robotics
A modern approach of the Nouvelle AI relies on building robots incrementally. The most trivial reactive behaviors, such as obstacle avoidance, are fully implemented, tested, and debugged first, before carefully appending higher-level behaviors. These ideas are applied in the Subsumption Architecture [Brooks, 1986]. Individual behaviors that formed the controller communicated using a fixed network, wires of which conducted simple signals. Fixed mechanisms of inhibition and suppression, and behavior priorities were used to resolve conflicts between the behaviors. Its disadvantage of hard-wiring the behaviors was addressed later in [Maes and Brooks, 1990], where individual behaviors compete for robot control and the robot can learn the conditions of applicability of each behavior in different situations. The precondition lists were learned by random trial-and-error method, and updated using relevance and reliability measures that were computed from correlation of positive (resp. negative) feedback and activity of the behavior.
The research challenge that has not been studied satisfyingly well yet is whether the robot controller can be designed automatically so that it would perform some nontrivial useful task, and whether the automatic method can provide some advan- tages over a human-engineered solution.
According to Miriam Webster dictionary, behavior is “anything that an organism does involving action and response to stimulation”. It is important that this anything, a series of interactions of the individual with its environment, is viewed from the point of view of an external observer. He or she would ask the question What will the agent achieve by doing this? This is in a sharp contrast with a point of view of an engineer who would ask the questions as: What functionality is provided by the bottom light sensor? Which components of the robot form the navigational
pickup_a_cup
navigate_to_cup search_cup
coordinate_behaviors [
search_cup(analyzed_scene),
navigate_to_cup(cup_location) ] = gripper and engines action pickup_a_cup(cup_graspable), cup_graspable analyzed_scene cup location engines engines gripper action
Figure 2.7: Stimulus-response diagram (top) and functional notation (bottom) of behaviors.
unit? What are the different menu-options of the user interface? It is also important to see that this behavioral different point of view does not apply only at the very high conceptual level. Rather contrary, it is found all the way down to the signal layer of the robot controller. One can truly appreciate this when considering the automatic design of robot controllers, where the target behavior is a product of an emergent and possibly learning process instead of a result obtained by following rigid engineering standard methodologies.
2.12.1
Representing Behaviors in a Controller
A behavior-based robot controller consists of behaviors. The behaviors can be rep- resented in different ways [Arkin, 1998]. Very common are graphical representations called stimulus-response diagrams, while functional notation is their textual counter- part. See Figure 2.7 for an example. In other formalisms, behaviors can correspond to states of a finite-state automaton (FSA), which describes sequencing of behaviors based on environmental percepts. Examples of FSA representations can be found in [Arkin and MacKenzie, 1994]. Brooks’ Subsumption Architecture also supports behaviors that are represented as augmented FSA.
2.12.2
Arbitration Mechanisms
Simultaneously performing behavioral modules all access the robot sensors and actuators. Their internal logic assumes the immediate access to the sensors and actu- ators. Mutual coexistence of the modules in a single robot controller must eventually lead to conflicting output values, or, perhaps, competition for bandwidth-limited inputs, or inputs that require calibration, focusing, positioning, etc. Regardless the good efforts of the designer of each individual behavioral module, combination
2.12 Behavior-Based Robotics 37 Behavior SELECT IN OUT Behavior SELECT IN OUT Behavior SELECT IN OUT Behavior SELECT IN OUT Behavior SELECT IN OUT Behavior Arbitration
Group of behaviors (higher−level behavior) SELECT
SENSOR1 SENSOR2 . . . SENSORN ACTUATOR1 ACTUATOR2 . . . ACTUATORM
Figure 2.8: Behavior arbitration general framework. The coordination module synchronizes and prioritizes access of the behavioral modules to the robot sensors and actuators. In addition, it can send control messages to the behavioral modules (for example to turn them on and off, or to select a particular mode. Even though the diagram suggests that behavior arbitration is a centralized component, it is not necessarily so. For instance, each sensor and actuator can have its own module that synchronizes access. Similarly, each behavior can have its own arbitrator that pays attention to the overall context of the robot’s behavior and makes sure its own behavior is performing as required, receives the required inputs and delivers its output to proper destinations. That is also the approach we adopt as described in the later chapters.
of several separately functional modules in one whole will very likely result in a non-functional controller. Naturally, such a combination must be equipped with a coordination mechanism, which will enable, disable, suppress, or prioritize the input and output signals of the individual modules. The problem of action-selection or behavior arbitration must be solved in each functional behavior-based robotic controller. Figure 2.8 shows a general framework for behavior arbitration.
The first proponents of the Behavior-Based Robotics suggested a fixed topology coordination with three basic coordination primitives that allow either to stop (inhibition) or replace (suppression) output signal from a behavior module on the same or lower layer in order to take priority and override the actuator output. The last primitive allows to reset the behavior to initial state. An example on Figure 2.9 shows a famous Brooks’s controller designed using Subsumption Architecture [Brooks, 1986].
Brooks’s behaviors are implemented as augmented finite-state automata (gen- erating output, reset, inhibition, and suppression signals). As mentioned earlier, two important works on coordination mechanisms are those of [Brooks, 1986] and follow-up by [Maes and Brooks, 1990]. The combination of several behaviors can take different forms, such as independent sum, combination, suppression and sequence as studied in [Colombetti and Dorigo, 1993]. Substantial work and an overview have been done by [Pirjanian, 1999].
Figure 2.9: An example of a controller built using the Subsumption Architecture of Brooks, [Brooks, 1987].
2.12.3
Team Robotics with Behavior-Based Architectures
Certain tasks can be completed much faster and more efficiently when a single robot is replaced by a team of multiple cooperating robots. For instance, multiple robots might observe or spot the target from different directions, they can explore environment in parallel, and they can even cooperate on transporting or capturing a large or heavy object, which would be impossible for a single robot.
Unless the robots are working in a rare and precious cases of emergence, where they do not need to cooperate and when the target behavior emerges unintentionally from their simple usually random interactions, in most cases, the robots must communicate. For the same reasons as in the case of single robot system, behavior- based architectures are suitable also for multiple robot systems. In addition, situations can occur when some behaviors run or are active simultaneously in several of the performing robots, whereas some of the robots would be taking different roles and have different behaviors active at the same time. This role distribution can take place either automatically, for example derived from the angle the robot is approaching an object to be transported, or it can be communicated and negotiated. In the latter case, the behaviors within multiple robots might use the same mechanisms for coordination across multiple robots with taking into account possible communication delays and errors.
For example, in [Stroupe and Balch, 2003], a team of behavior-based robots is mapping and tracking target objects in their environment. Each robot independently determines in which direction to travel based on the current situation. Locations and observations by other robots may be communicated, but could also be inferred if teammates are detectable and their sensor models are known. When communication is absent, the full advantage of team cannot be taken until information is later