Robot Behavior Engineering using DD-Designer Ansgar Bredenfeld, Giovanni Indiveri GMD - Institute AiS D-53754 Sankt Augustin, Germany +49-2241-14-2841 {bredenfeld,indiveri}@gmd.de

Abstract We present a novel robotic software development framework for rapid simulation and programming of mobile robot teams. The framework uses a specificationcentred generative approach. A robot control program is specified in an intuitive graphical representation of a hyper-graph of typed data processors. This specification is automatically refined to all design artifacts required in a robotic software development environment: simulation models, robot control programs, team communication infrastructure, documentation, and real-time monitoring. Although our framework was originally intended to design behavior-based robot control programs using the Dual Dynamics architecture, we demonstrate the openess of the environment by an example which integrates a “classical” control schema into a Dual Dynamics behavior system. Experimental validation was done on GMD-Robots, our team of mid-size league RoboCup robots. Keywords - Programming and Architecture, Design Automation, behavior-based robotics, robotic software development framework

1. Introduction Autonomous mobile robots present fascinating research perspectives for today, and likewise fascinating prospects for applications in the future. The challenge is to achieve a behavior of autonomous robots that is both complex and fast. We have identified three research areas which are crucial to achieve these objectives: •

Formal models of complex behavior systems.

•

Methods, tools and developement environments for very fast design-redesign cycles.

•

Fast real-time processing for control and inter-robot communication.

With these requirements in mind, designing autonomous, mobile robots is a demanding, interdisciplinary challenge. Developing software for complex robots is

done in many iterated design-redesign cycles, often with substantial modifications in all required design artifacts: specification, simulation models, robot control programs and documentation. Frameworks [1], component software [2] and generative programming are the most promising engineering approaches to speed-up the construction of novel design environments and the construction of robotic software using these environments. In this paper, we present our DD-Designer framework which has been designed and implemented exploiting these leading-edge technologies. Our RoboCup [3] mid-size league robots are the test bed for our ideas, techniques and environment. We use our development environment to program and operate this team of soccer playing robots. We use the control program of the goal keeper as demonstrative example in this presentation. This paper is structured as follows. In section 2 we introduce the main idea behind our reactive, behaviorbased approach called Dual Dynamics. In section 3 to 5 we present the architecture, realization and the environment of our robotic software development framework. In section 6 we take a user perspective and demonstrate the openess of our framework by giving a robot controller example. Section 7 puts our work into perspective to related work, before we conclude the paper with an outlook to future work.

2. Dual Dynamics Our approach to robot programming is based on a mathematical model for robot behaviors which we developed. It integrates central aspects of a reactive, behavior-based approach to robot control [4], methods from continuous-time robust control (like in [5]), and a dynamical systems representation of actions and goals. In our approach robot behaviors are specified through differential equations, forming a global dynamical system made of behavior subsystems which interact through specific coupling and bifurcation-induction

mechanisms. Behaviors are organized in levels where higher levels have a larger time scale than lower levels. Since the activation of behaviors (activation dynamics) is separated from their actuator control laws (target dynamics), we named our approach "Dual Dynamics" [6]. An important feature of DD is that it allows for robust and smooth changes between different behavior modes, which results in very reactive, fast and natural motions of the robots.

3. DD-Designer The successful design of robot software requires means to specify, implement and simulate as well as to run and debug the robot software in real-time on physical robots. In this section we give an overview of DD-Designer the central specification tool of our robotic software development framework. 3.1 Data processor network As abstraction of a robot control architecture we use a hyper-graph of data processors. Figure 1 shows a screen shot of a robot control program as appearing to the user. The interpretation of data processors depends on the robot control architecture. In our Dual Dynamics architecture, data processors are either sensor filters, activation dynamics of higher-level behaviors, activation dynamics of elementary behaviors or target dynamics of elementary behaviors. Data processors are connected by states which are classified. Their interpretation depends on the robot control architecture. In the Dual Dynamics architecture we have sensor variables as outputs of sensor filters, activations as output of elementary or higher-level behaviors, and target variables which are partial actuator values calculated by the target dynamics of elementary behaviors. All target variables are superposed resulting in a final actuator control signal. Seen from an abstract point of view, DD-Designer is a graphical specification editor for data processor hypergraphs where processors are of different type and have to fulfil constraints regarding their connectivity with other types of data processors. As an example, a network of sensor filters is used to pre-process signals which are directly read from sensors or other sensor filters. Since these filters are pre-processing stages, they usually do not access activation states calculated in the hierarchy of behaviors. 3.2 Data processor scheduling All data processors have to be scheduled in order to be executed in a simulator or on the real robot. At present,

Figure 1. DD-Designer: sensors, sensor filters, behaviors, actuators entered as network of typed data processors

we use a static schedule for the execution sequence of data processors which runs in a fixed time main loop with a cycle time of 20 ms on our robots. The schedule of the sensor filters is ruled by data dependencies in the sensor filter network. Unavoidable cycles in the data flow are reported to the user and are subject to be re-scheduled by a suitable user modification of the network. The static schedule of behaviors is ruled by the behavior hierarchy; we first schedule all higher-level behaviors and afterwards the elementary behaviors. Schedule construction takes care of unallowed relationships, for example, activation state cycles from lower-level behaviors to higher level behaviors which are forbidden in the Dual Dynamics architecture. 3.3 Processor equations The functionality of data processors is further detailed using an equation editor. The specification language uses common control flow statements known from C and Java. Data types comprise scalars, vectors and static multi-dimensional arrays. We restrict arrays to be static in order to prepare migration of robot control programs to FPGA hardware in future. Besides common control and data flow, our language supports the formulation of differential equations. They are simply written by specifying an assignment to a derivative term like α ' = – α . Derivative terms are converted to difference equations without any further interaction required by the user. Since equations are parsed and stored as a fine-grained syntax tree, we can offer convenient editing, searching and browsing functionality like known from state-of-theart software IDEs.

3.4 Interface abstraction The data processors of a robot control program have to be connected to the sensoric input and the actuator output. We support abstractions of sensors and actuators as prominent modelling constructs. This explicit interface abstraction has three major benefits. The first is to have a clear cut edge between the robot control program and robot platform resp. simulator specific realizations of sensors and actuators. In our framework, the robot control program can be re-used in the simulation and on the real robot regardless of the implementation language used in the simulator or the real robot. In our case the simulator is written in Java whereas the real robot is programmed in C++. Interface abstraction in combination with a target language independent specification of data processor equations maximizes the re-usability of our robot control programs and avoids all problems related to manual code migration. The second benefit of explicit interface abstraction is a simplification of integration and back-annotation accross different implementation targets, namely the simulation code, the real robot code and our real-time monitoring tool. The central specification of the sensor and actuator interfaces allows us to keep track of all these relations and links in the whole system of design artifacts. As an example we are able to configure the real-time monitoring tool via the specification, we can re-use the monitoring tool for both simulation and real-time observation of our robots. The enabling factor is explicit modelling of sensors, actuators and states (activations, sensor variables, target variables, actuator variables). The third benefit is simplification of extensions. Adding a new sensor to the DD-Designer framework is simply done by adding an entry in a textual sensor configuration file and providing sensor wrapper functions for the simulator and the real robot. The same extension process is used for adding new functions to the framework. This is done by adding the signature of the new function and providing a simple wrapper to the native implementation in the target language. This “plug-and-play” concept makes each extension directly visible in the DD-Designer editor. Model checking, automatic documentation, and code generation for the target languages is directly available for such extensions.

team communication is as simple as tagging a state which connects data processors - to be publically visible in a team. Team communication is realized with a black-board like mechanism, which allows to share public states in a given team of robots. In the simulator, team communication is simulated, on the real robot the communication layer uses TCP/IP. The communication protocol between the robots is automatically synthesized for a given team. If a robot joins or leaves the team, its states are simply not distributed any longer to its team mates. A given robot accesses public states of other robots using a dynamic state vector. If no team mate provides values for a state, this vector simply remains empty. This mechanism turns out to be very flexible for varying team sizes. At present, we use this simple but robust communication mechanism to monitor and check states, i.e. sensor inputs, activations and actuator signals of team mates. 3.6 Data processor refinement The central specification of the robot control program is the hyper-graph of state connected data processors. This representation allows to design Dual Dynamics models on a high level of abstraction and to synthesize all design artifacts required to make the models operative in practice: a documentation, a simulation model, executable control programs for our RoboCup robots and a parameter sets for our real-time monitoring and analysis tools.

4. Realization of DD-Designer DD-Designer was constructed using the model-based rapid software prototyping environment APICES [7]. In previous work [8][9] we concentrated on the construction and evolution of the DD-Designer from the very first prototype to the full-fledged design tool it is now. Here, we summarize very shortly this aspect of DD-Designer. We generate a design tool framework from an UML class diagram with APICES. Figure 2 shows the simplified UML class diagram of DD-Designer without attributes or generated methods. The generated tool framework consists of an efficient C++ implementation of the class diagram embedded in the scripting language Tcl. In addition, it comprises a re-configurable interactive graphical instance editor.

3.5 Team communication support

5. DD-Designer Environment

Communication between robots is a prerequisite for the realization of message-based cooperation in a team of robots. Therefore, we added a team communication feature already on the specification level. Specifying

DD-Designer is the central tool of an integrated design and simulation environment for mobile robot teams. Besides DD-Designer, it consists of the simulator DDSim and the real-time monitoring tool beTee.

"behavior" controller i is the linear u i and angular velocity w i to be assigned to the robot. The higher-level behavior level layer consists of a dynamic system regulating the interactions between behaviors. This kind of architecture was inspired by biological considerations [6] in consideration of which the activation dynamics should generally have more than one locally stable equilibria and bifurcations among them may occur. The output of the activation dynamics relative to each behavior i is a scalar number α i between 0 and 1, such that the total inputs to the actuators of the robot at each time are given by Figure 2. UML class diagram of DD-Designer

•

•

•

DD-Designer allows to specify a Dual Dynamics model in terms of sensors, actuators, sensor preprocessing elements and a hierarchy of coupled behaviors. Each of the processing elements is formulated using a combination of control data flow and differential equations. This specification is the basis for an automatic refinement of all code artifacts required by the tools in our design environment. DDSim allows to simulate a communicating team of robots on a playground. It provides sophisticated simulations of the ball and the sensors of the robots. This includes laser scanner simulation and an emulation of the vision system used by our robots. Since each robot is configured with different behavior systems, we are able to benchmark behavior systems against each other in a team of robots. beTee is a real-time monitoring tool for tracing arbitrary internal states of the simulated or (via wireless LAN and TCP/IP) the physical robot.

6. Controller design using DD-Designer DD-Designer war originally planned as a design tool for robot control programs relying on the Dual Dynamics scheme [6]. In order to illustrate the basic underlying ideas of the Dual Dynamics (DD) control architecture and the use of the DD-Designer for the specification of robot control programs, we describe the design of a control schema of the goal keeper of the GMD RoboCup robot team. In extreme synthesis the name Dual Dynamics refers to a two layer control architecture: the lower one consists of task oriented controllers (or behaviors) as by example "avoid obstacle", "move to a point", "track a target" that are designed independently of each other with standard tools of automatic control theory. Given the purely kinematic model of the robots, the output of the generic

u tot =

∑i = 1 α i u i n

and w tot =

∑i = 1 α i w i . n

For the present purpose it might suffice to notice that the activation dynamics may be thought of (and used) simply as a smoothing mechanism to switch among tasks. In the goal keeper case, by example, the behaviors or tasks were three: "avoid obstacle", "home" and "keep goal". Their activation dynamics were very simply given by γi α' i = – α i + f i ,

being γ i a positive constant, fi in {0,1} for every i and n ∑i = 1 fi = 1 . This condition insures that the rise of an activation variable implies the decrease of the others, i.e., that except for a transient period only one behavior is active at a time. The transitions among the f i variables are governed by a finite state machine that guarantees the satisfaction of the constraint ∑ni = 1 f i = 1 . The "keep goal" behavior should allow the robot to move along the line of the goal and to stop in front of the ball. With reference to figure 3, the steering law is designed such that the candidate Lyapunov function 1 V = ----------------------------------------2 2 2( φ + ( y – yr ) )

has semi-negative definite time derivative. Noticing that y' = u sin φ , and φ ' = w being u and w the linear and angular velocities, V ' = φw + ( y – y r )u sin φ 2

such that imposing V ' = – hφ , h>0 constant gain, implies sin φ w = – hφ – ( y – y r ) u ----------φ

which is well defined on the whole state space. La Salle´s Invariance Principle may be applied to V showing that as long as u is not identically null both φ and ( y – y r ) will be globally asymptotically driven to zero.

φ and ( y – y r ) are estimated by onboard infrared sensors and u is taken to be proportional to θ (see figure 3) which is measured by the vision system of our robots.

The corners of the goal are detected by other infrared sensors: the variable fi relative to the activation dynamics of the "keep goal" behavior is put to zero when a corner is reached while the f i variable within the "avoid obstacle" activation dynamics is put to 1. The angular and linear velocities relative to the "avoid obstacle" behavior are both null. If the robot should be hit by opponent robots thus losing its position in front of the goal, a homing behavior is triggered in order to recover the correct position and the keep goal behavior is thus restarted. The robustness and effectiveness of this approach has been experimentally verified during the 4th RoboCup World Championships in Melbourne where the GMD Robots team reached the quarter finals. Figure 4 shows our self-constructed robot platform.

7. Related Work We identified related work in two domains: languages for mobile robot programming and robotic software development frameworks. Several specific languages for mobile robot programming with different emphasis and focus have been proposed in the past. PDL [11] is a Process Description Language developed by Steels and Vertommen for defining and experimenting with networks of dynamical processes for behavior-based control. Similar to DD-Designer, PDL is targeted to specify process networks for behavior-based

Figure 3. Control law for RoboCup goal keeper

Figure 4. GMD RoboCup mid-size league robot

robot control. In contrast to PDL, DD-Designer offers a visual language to construct contrained networks of typed data processors. COLBERT [12] is a language for writing reactive robot controllers in C++. Unfortunately, it is dedicated to robot controllers having the Saphira [13] architecture. CES [14] is a programming language extension of C++ specifically targeted towards mobile robot control. It adds two ideas to C++: Computing with probability distributions, and built-in mechanisms for learning from examples. DD-Designer follows a different extension approach. The user specifies a robot control program explicitely in our graphical editor. Since the specification is mapped to a implementation language C++ or Java, our approach has two advantages: First it allows to generated robot control programs in C++ and simulation models in Java for DDSim without any manual code migration. This important benefit stems from the rigorous separation of abstract control specification from concrete target implementations. Second, with the advent of powerful embedded real-time Java plattforms, we will simply re-target our robot control programs to Java without any cumbersome and error-prone code migration from C++ to Java. In the domain of robotic software development frameworks integrated design and simulation environments, for example the tool set around COSIMIR [15] exists. This environment is not targeted to reactive behavior-based mobile robots but to manufacturing robotics. Interesting work on a robotic software

development framework for humanoids is PredN [16]. As our environment it starts from a hyper-graph representation of the robot control program on specification level. This representation is mapped to a multi-threaded real-time communication platform. In comparision, the architecture of PredN is very similar to ours. Both systems clearly separate the specification level hyper-graph of processors from a mapping of this hypergraph to specific target implementations. DD-Designer maps the data processor hyper-graph to a static schedule executed in a main loop running at 50 Hz. At present, we did not yet map to a distributed implementation layer. Nevertheless, this is possible, since the mapping mechanism to an implementation target is configurable in DD-Designer.

[3] [4] [5]

[6]

[7]

[8]

8. Conclusions In this paper, we presented the novel robotic software development framework DD-Designer for rapid simulation and behavior-based programming of mobile robot teams. We generate documentation, Java simulation code, C++ robot control programs, TCP/IP based team communication infrastructure and real-time monitoring tools from an abstract hyper-graph of typed data processors. Although we explicitely support the behavior-based robot control architecture Dual Dynamics, our system allows to easily merge arbitrary controllers into this architecture. The environment is in productive use to program the GMD team of mid-size league RoboCup robots.

[9]

[10]

[11] [12]

9. Future work It is worthwhile to investigate an adaption of DDDesigner to other robot control architectures. Since DDDesigner is constructed using the UML-class diagram based rapid-prototyping tool APICES [7], it can be seen as an instance of a design tool family. One aspect of our future work is to look at abstractions of robot control architectures using “architecture templates”. If we factor our these templates, we will be able to tailor DDDesigner to different robot control architectures by changing the meta-model (Fig. 2) in APICES. This would allow for quantitative comparision of alternative architectural approaches within a single, integrated environment for simulation and real robot programming.

10. References [1]

[2]

Fayad, M. E., D. C. Schmidt, Object-Oriented Application Frameworks - Introduction, Communications of the ACM 40(10), 1997, pp. 32-38 C. Szyperski, Component Software – Beyond Object-Oriented Programming, Addison-Wesley, 4th printing, 1999

[13]

[14]

[15]

[16]

RoboCup (http://www.robocup.org/) R. A. Brooks. Intelligence without reason. A.I. Memo 1293, MIT AI Lab, 1991 (http://www.ai.mit.edu/). M. Aicardi, G. Casalino, A. Bicchi, and A. Balestrino. Closed-loop steering of unicyle-like vehicles via Lyapunov techniques. IEEE Robotics and Automation Magazine, March:27-35, 1995. H. Jaeger and T. Christaller. ’Dual dynamics: Designing behavior systems for autonomous robots’, Artificial Life and Robotics, 2:108-112, 1998 A. Bredenfeld. APICES - rapid application development with graph pattern. In Proceedings of the 9th IEEE International Workshop on Rapid System Prototyping (RSP 98), Leuven, Belgium, pages 25-30, 1998. Bredenfeld, A. Co-Design Tool Construction Using APICES., in Proceedings of the 7th ACM/IEEE International Workshop on Hardware/Software Codesign, pp. 126-130, May 1999 A. Bredenfeld, ’Integration and Evolution of ModelBased Prototypes’, 11th IEEE International Workshop on Rapid System Prototyping (RSP 2000), Paris, France, June 21-23, 2000 A. Bredenfeld, T. Christaller, W. Goehring, H. Guenther; H. Jaeger, H.-U. Kobialka, P. Ploeger, P. Schoell, A. Siegberg, A. Streit, C. Verbeek, J. Wilberg, ’Behavior engineering with "dual dynamics'' models and design tools’, in RoboCup-99: Robot Soccer World Cup III (M. Veloso, E. Pagello, H. Kitano, eds.), LNAI 1856, pp. 231-242, 2000 Steels, L. The PDL Reference Manual. VUB AI-Lab AI Memo 92-5, 1992 Konolige, K. "COLBERT: A Language for Reactive Control in Saphira", in German Conference on Artificial Intellgence, Freiburg, 1997. K. Konolige, K. Myers, The Saphira Architecture for autonomous mobile robots, In AI-based Mobile Robots: Case studies of successful robot systems (D. Kortenkamp, R. P. Bonasso, and R. Murphy, eds.), MIT Press, 1996. S. Thrun, Towards Programming Tools for Robots That Integrate Probabilistic Computation and Learning, ICRA 2000 Freund. E. Rossmann, J. Projective virtual reality: Bridging the gap between virtual reality and robotics. IEEE Transaction on Robotics and Automation; 15:3:411-422, June 1999. O. Stasse and Y. Kuniyoshi, PredN : Achieving efficiency and code re-usability in a programming system for complex robotic applications, ICRA 2000