Functional Programming of Behavior-Based Systems Ian Douglas Horswill Computer Science Department and The Institute for the Learning Sciences Northwestern University Evanston, IL 60201 [email protected] Abstract dozen robot configurations ranging from a sonar-based In this paper, I describe a simple functional programming system with an 8-bit microcontroller to a vision-based language, GRL, in which most of the characteristic quadruped. It has also been used to teach an features of the popular behavior-based robot architectures undergraduate seminar. can be concisely written as reusable software abstractions. This makes it easier to write clear, modular Although evaluation of programming languages is code, to “mix and match” arbitration mechanisms, and to always difficult, students who have used both raw LISP experiment with variations on existing mechanisms. I and GRL report that GRL code is much easier to write describe the compilation process for the language, our and debug. As an anecdotal example, the NWU entry in experiences with it, and issues of efficiency, the 1998 AAAI robotics exhibition was a program that expressiveness, and code size relative to other stalked people in the crowd and followed them around languages.1 while spinning paranoid fantasies about the government turning people into robots. It was constructed in three Introduction weeks by one of our undergraduates. It was his first robot program. In this paper I describe a simple language, GRL (Generic Robot Language, formerly “GiRL”, and still pronounced “girl”), that extends traditional functional programming Programming languages and behavior-based techniques to behavior-based systems.2 GRL is an systems architecture-neutral language embedded within Scheme. It provides a wide range of constructs for defining data In spite of its name, GRL is really only intended for flow within communicating parallel control loops and implementing behavior-based systems (it’s called GRL manipulating them at compile time using functional because “GBBL” would be hard to pronounce). programming techniques. A simple compiler (about 3000 Although many different behavior-based architectures lines of code) then distills the code into a single while- exist (see Arkin 98 for a survey), all consist of a set of loop containing straight-line code, and emits it as independent control loops running in parallel, usually Scheme, C, C++, BASIC, or Unrealscript3 code. The with some sort of arbitration mechanism to combine language allows programmers to write in a much more their outputs. Many of the distinctions between modular and compositional manner, but generates C behavior-based architectures amount to disagreements code that is typically faster than hand-written C code.4 about what a behavior is and how a system should We have implemented the language and used it as the arbitrate between behaviors. In subsumption (Brooks basis for our behavior-based systems at NWU for 86), a behavior is a finite-state machine and arbitration is approximately two years. We have run it on a half- performed with suppression. In the motor-schema architecture (Arkin 98), behaviors are mappings from sensor vectors to motor vectors, and arbitration is a 1 Support for this work was provided in part by the National Science Foundation under award #IRI-9625041 and in part by the Defense performed using linear combination. In behavior Advanced Research Projects Agency Mobile Autonomous Robot Software networks (Maes 90), behaviors (competence modules) Program under award N66001-99-1-8919 and by the DARPA Distributed are unrestricted black boxes, but are arbitrated using a Robotics Program and the U.S. Army Soldier Systems Command under spreading activation mechanism that forms an award #DAAN02-98-C-4023/MOD P3. approximation to STRIPS planning (Fikes, Hart, Nilsson 72). 2 The name is, of course, a gross exaggeration. It was contrived to allow the name. Many behavior-based architectures are implemented as 3 Unrealscript is the extension language for a popular computer game. application-specific programming languages and 4 This is achieved in part because the GRL compiler is maniacal about inlining, so its object code, while very fast, is typically somewhat bloated. compilers. For example, the MIT mobot lab has This could be changed, but so far, it hasn’t been a problem. developed a series of languages for writting subsumption code (Brooks 86, Brooks 90, Brooks and Rosenberg 95). • An application of a finite-state transducer to a set of Maes’ paper describes her architecture, in part, in terms signals. Again, the programmer must provide of a macrology and interpreter embedded in LISP. Scheme source code for computing the value of the Thrun (98) describes a C-like language that supports transducer from the instantaneous values of the input probability distributions and gradient descent function signals. Transducers are finite state in that they may approximators as primitive data types. Several not dynamically allocate storage. researchers have also written architectures as C++ class libraries (Velsquez 98, Schaad 98). Unfortunately, since most robotics researchers don’t have time to be Primitive procedures are mappings from instantaneous professional compiler writers, these systems are often signal values to values. Values may be scalars (integers, quite primitive as programming languages. In particular, floats, Booleans, …) or vectors. Transducers, since they their abstraction capabilities, if any, are typically limited contain history information, are mappings from signal to macro expansion. They also tend to make it painful or time histories to time histories. However, they are impossible to implement the other architectures as user restricted to be finite state. Sources and transducers are code. Thus one can’t easily compare the subsumption the only constructs in which programmers are allowed to architecture with behavior-networks because they have escape to Scheme and write Scheme code that will be completely separate languages. It is possible of course, executed at run time. This Scheme code is restricted, but it typically involves hand-compiling one architecture however, to be statically typeable and to be non-consing, into the primitives of another. at least if the compiler is to generate C or BASIC code for the final output. Assuming the code provided for The goal of GRL is to have a language with the sources and transducers runs in O(1) time, then the abstraction facilities of LISP and the run-time efficiency network as a whole runs in O(1) space and can compute of the subsumption compiler. Although it is limited to updates in O(1) time. the kinds of real-time finite state computations used in behavior-based systems (and therefore cannot implement Primitive signals make up a straightforward language for full symbolic programming systems like theorem writing real-time control loops. Although most of the provers), it does provide the programmer with an advantages of GRL come from more sophisticated architecture-neutral language for experimenting with constructs, the primitive signal sub-language does have different kinds of arbitration mechanisms. the advantage that allows functions over time histories (transducers) to be composed more naturally than is possible in most programming languages. For example, GRL primitives consider the problem of detecting a doorway using a directional proximity sensor, such as a sonar or IR, while GRL supports circuit semantics (Nilsson 1994). driving down a hallway. A simple approach is to look Ultimately, GRL programs consist of networks of signals for a long reading from one of the sideways-facing which are thought of as being computed in parallel and sensors: updated continuously. In reality, of course, GRL code runs on serial uniprocessors or loosely coupled networks (define-signal door? of uniprocessors, so the parallelism and continous update (> (max left-reading right-reading) are only approximate. Any signal that exists at run time thresh)) must be a primitive signal, meaning more or less that it must be easily computed in C. A primitive signal may be: However, this might generate spurious readings because of sensor errors. Programmers often post-process the sensor output by requiring that the long reading be seen • A constant for at least a certain amount of time: • A signal source, for which raw Scheme code has been provided by the programmer. They are used for (define-signal door? sensor and effector interface code. (> (true-time • (> (max left-reading An application of a primitve procedure (+, -, log, …) right-reading) to a set of signals. Note that if, and, and or, are dist-thresh)) normal procedures in GRL, not special forms.1 time-thresh)) 1 This is for technical reasons. Conditionals are usually special-forms in languages with applicative-order evaluation because programmers unintentional range errors do not occur, such as in the expression (if typically don’t want conditionals to pre-evaluate all their subexpressions. (zero? a) 0 (/ 1 a)). Since GRL signals have quasi-parallel semantics, conditionals always evaluate all their arguments. Care must be taken, therefore to ensure that where true-time is a finite-state transducer that returns (define-group-type xy-vector the number of milliseconds for which its input has been (xy-vector x y) true. It is a standard part of the GRL library and is (x x-of) defined by the code: (y y-of)) (define-transducer (true-time input) This example declares that the xy-vector data type1 (state-variables (onset 0)) consists of x and y elements, which are accessed with (when (not input) the x-of and y-of procedures, respectively. New xy- (set! onset ms-clock)) (- ms-clock onset)) vectors are created with the xy-vector procedure, which takes the x and y components as arguments. Unfortunately, you can’t write true-time conveniently in LISP or C because it doesn’t behave like a normal Groups are explicitly represented at compile-time so that function – it requires an internal state variable, onset. they can be manipulated and simplified.