A Scripting-based Approach to Robot Behavior Engineering Using Hierarchical Generators Thijs Jeffry de Haas, Tim Laue and Thomas Rofer¨ Abstract— When developing software for autonomous robots, The contribution of this paper is a domain-specific langua- the aspect of behavior engineering is, among tasks such as sen- ge called b-script to describe hierarchical agent behaviors sing, state estimation, and motion control, of major importance. using the programming concept of generators. We show that Current solutions range from basic behavior-based approaches to sophisticated reasoning systems, in each case depending on it is a convenient way to use hierarchical continuation-based the complexity of the robot’s task as well as the available routines to realize complex robot behaviors in an intuitive amount of computing time. In this paper, we present a behavior and clean way and that it can be used in large-scale appli- specification language, which is called b-script, to describe cations. This is achieved by using a specialized generator hierarchical agent behaviors using the programming concept implementation, similar to Python’s generators, including of generators. We show that this is a convenient approach to realize complex robot behaviors in an intuitive and clean implicit context maintenance. The language is in particular way that can be used in large-scale. Furthermore, the actual suited to be used on resource restricted embedded systems, implementation of this language is in particular suited to be such as the Nao robot [5], and was already successfully used on resource-restricted embedded systems. This is shown applied in actual competitions of the RoboCup [6] Standard in different examples of a Nao robot in a robot soccer scenario. Platform League [7]. Furthermore, b-script has a strong type system and a scripting-like look and feel that can be compiled I. INTRODUCTION to C++. Each robot that operates (at least partially) autonomously The development was guided by different domain-specific needs an action selection (aka behavior) component to map requirements, in particular: sensor input or world models to actions. For some trivi- • light-weight due to resource restricted hardware al tasks, this can already be achieved by sensor actuator • allow execution in realtime coupling, but in general, more sophisticated mechanisms • easily embeddable into existing robot architectures are necessary. These range from behavior-based approaches (usually written in C/C++) [1] over pragmatically hand-coded finite state machines [2] • consider long and costly edit-compile-deploy-test cycle to complex planning systems such as [3] or [4]. Amongst • “runtime safe” (no runtime exceptions) others, the applied approach might depend on the complexity In theory, the basic functionality of this approach could of the task, the number of different sub-tasks, as well as of also be realized by using several established high-level the necessary amount of computing time that is available languages, such as Python, Lua, Ruby, or C#. But in practice, on the used robot platform. The actual task of defining a these languages have different drawbacks, as they are either robot’s action selection, which is often named as behavior dynamic languages (conflicts with “runtime safe” and the engineering, is, in general, supported by various description long edit-compile-deploy-test cycle) or need extensive runti- languages or logics. me libraries such as Microsoft’s Common Language Runtime In this work, we focus on the development of behaviors (conflicts with light-weight). In addition, for modeling robot for robots with limited computational resources in dynamic behavior, the full expressiveness of general-purpose langua- scenarios that require acting in realtime and that cannot be ges is not needed. In contrast, it can even be a drawback handled by behavior-based approaches due to their comple- when developing in large teams, because there is always xity or a strictly specified workflow that might conflict with the risk of the introduction of hacks, i. e. constructs that emergent behaviors. Typical examples for such scenarios are seriously impede the maintainability of the whole system. office delivery, (semi-)autonomous transportation of humans, Therefore, with b-script we specifically designed a language or industrial pick and place tasks. In such domains, it is a for modeling robot behavior. As such, it excludes concepts common practice to preprogram decisions explicitly and to that are not needed for its purpose and bear the risk of avoid any computationally expensive inference. This is often resulting in confusing code (e. g. global variables) and it realized by implementing state machines, either by using introduces new ones that are very beneficial in its domain special description languages or by directly using some kind (e. g. tasks). of common programming language. This paper is organized as follows: SectionII provides an Thijs Jeffry de Haas is with Department of Mathematics overview of related work in general and the basic concept of and Computer Science, Universitat¨ Bremen, Bremen, Germany. generators in particular. Their use in this work is explained in [email protected] Tim Laue and Thomas Rofer¨ are with Cyber-Physical Systems, DFKI, Sect. III, followed by a description of their actual application Germany. fTim.Laue, Thomas. [email protected] for specifying complex behaviors Sect.IV. The b-script language details are presented in Sect.V. Finally, recent from the saved context. Certain programming problems can applications of b-script are shown along with an evaluation be modeled very elegantly with generators. In particular, in Sect.VI. problems that are typical use cases for finite state machines, such as parsers or communication protocols, can be described II. RELATED WORK efficiently, as demonstrated by [14]. A basic example that As aforementioned, finite-state machines are a common computes a Fibonacci sequence using the b-script generator choice for describing a robot’s behavior. Although a di- implementation is shown in Fig.1a. rect implementation is possible in almost any programming Jouvin introduced an approach to use continuations – language, it is a common practice to use domain specific the functionality underlying generators [15] – to specify languages. Some recent examples include XABSL [2], XRo- behaviors of conversational agents [16]. It is shown that bots [8], and the use of UML state charts [9], [10]. These continuations can be used to describe agent behaviors in an implementations have in common that they are not limited to elegant and intuitive way, however, no applications to robot the specification of single, possibly very huge state machines behaviors are considered. Interestingly, it seems that this but that they also allow structuring complex behaviors by approach was not further investigated. Furthermore, Bruce splitting them into a hierarchy (such as the example in Fig. and McMillen discussed the possibility of implementing a 1b) of smaller state machines. robot soccer goalkeeper using Python generators [17]. They Other behavior description systems are COLBERT [11], showed a rudimentary example but apparently did not apply which includes finite state machines as one major concept, as the approach to real robots. well as TDL (Task Description Language) [12], an extension III. TASKS –GENERATORS FOR ROBOT BEHAVIORS to C++. Also the known URBI framework [13] includes its own, event-based behavior scripting language called The core of our approach are so-called tasks. These are UrbiScript. All three approaches are based on concurrent specialized generators that provide a handy way to describe code blocks to realize the decomposition of problems, a hierarchical robot behaviors. In this section, the characteri- concept that makes the detailed interplay of different tasks stics compared to generators are described. less comprehensible and – in case of bugs or necessary A. Context Maintenance fine-tuning – harder to debug. In addition, COLBERT as well as URBIScript are both embedded in specific control When using common generator implementations, there is frameworks – Sapphira and URBI respectively – and cannot the need to handle the context of a generator explicitly. be considered as light-weight regarding a usage inside other One can create multiple instances of the same generator. For frameworks or control concepts. specifying robot behaviors, this is not necessary since each Most behavior engineering approaches use programming component of the hierarchy represents a skill and could be paradigms that differ from the one that is, in general, used treated as some kind of singleton (like a function). Therefore, for most other software components inside a robot system: each task is associated with a single context instance, which imperative programming1. Huge problems are decomposed is stored in the b-script runtime environment and is retrieved into small bits and assembled in a hierarchical structure. when the task gets called (cf. Fig.1a). Each component in the hierarchy is usually a function that B. Task Parameters solves a sub-problem (e. g. finding the brightest pixel in an image). This allows creating complex programs that are Regular generators evaluate their parameters only once well structured and relatively easy to understand. Almost all when the context is created. When used in a hierarchical programmers are familiar with this programming concept. orchestra controlling a robot, this usually is not very helpful. Considering