Edmund, POSH and Behavior-Oriented Design

When I first started developing the POSH system of action selection, I was also building an architecture, which I called Edmund.  (The name came in a moment of desperation while submitting a paper.  It sort of stands for "The Edinburgh Mind"; I was at Edinburgh at the time in the lab of Brendan McGonigle, who always referred to his robots as "the Edinburgh Nomad" or "The Edinburgh R2".)  Many people mistook POSH action selection for Edmund, neglecting the Behavior-based element of the architecture, so I eventually abandoned the term Edmund (as well as the over- & mis-used term architecture) and created Behavior-Oriented Design instead.  I do sometimes still use Edmund to refer to the older version of POSH which is in C++. 

The rest of this page is an old description of Edmund (and to some extent POSH plans), dating mostly to December 2000.  The bottom of the page has code.

Here is a brief description of Edmund's control architecture, taken from Hierarchy and Sequence vs. Full Parallelism in Reactive Action Selection Architectures (see my publications page.) My methodology for developing these structures is called Behavior Oriented Design, which is also described in Section 2 of Making Modularity Work: Combining Memory Systems and Intelligent Processes in a Dialog Agent. Many of the references mentioned below are also on my related web sites page. The code for edmund is available down there.

Edmund is intended to extend behavior-based approaches to artificial intelligence, such as subsumption architecture (Brooks-91-AIJ) to allow for behavior of greater complexity. Subsumption architecture stipulates that intelligence should be decomposed into individual behaviors, each of which controls its own sensing and activation. All behaviors run continuously in parallel. Whether a behavior is expressed in the control of the robot is determined partly by the behavior itself, which can recognize situations in which it should be active, and partly by intricate interactions with other behaviors. Behaviors are allowed to inhibit and change each other's input, and also to suppress each other's output. Behaviors are organized in carefully crafted networks that specify these interactions. Groups of behaviors for pursuing the same goal are implemented as a unit called a level. Levels of additional, higher goals are added in a linear hierarchy. The behaviors in higher levels may inhibit or suppress lower levels' behaviors, but lower levels are intended to remain ``unaware'' of higher. The lower levels' behaviors should be unchanged from their internal perspective.

Subsumption architecture works well in situations where there is a small number of non-conflicting goals that require behaviors that are fairly homogeneous across the entire of the robot's intended niche (Horswill-93-THESIS,Bryson95). However, it is difficult to specify the performance of different behaviors in the same physical environment, such as when a sequence of behaviors needs to be conducted, or when the robot is selectively pursuing one of multiple possible goals (Connell-90-BOOK). This problem is addressed in Edmund by creating a more complex hierarchical control system for triggering the expression of behaviors. This structure is based on two elements: the competence and the action pattern . An action pattern is a sequence of behaviors that will execute in turn unless interrupted by a radical failure or a higher priority goal. A competence is a grouping of action patterns and other competences which express a behavior consistent with a particular goal. The elements of a competence are prioritized so that if multiple elements are able to run, the element closest to achieving the goal is selected. Competences are similar to reactive plans (Agre & Chapman 88), or triangle tables (Nilsson 85, 94). The idea of using hierarchies and sequences to improve behavior-based control is also widespread (Firby 87,McGonigle 90, Gat-91-PHD, Tyrrell-93-PHD, Correia & Steiger-Garcao 95, Levison-96-PHD), though still controversial (Hendriks-Jansen 96, Maes-90-SAB). Edmund differs from other behavior-based architectures in two ways. First, it completely separates the issue of flow-of-control from flow-of-information. The only information available in the control hierarchies is recent control and decision state. All perception and sensory-based memory is present in the behaviors themselves. The flow of information between behaviors is not restricted by the control architecture, but rather specified within a behavior library . Adaptation, both in terms of short term perceptual processes and long term ``lifetime learning,'' occur in the behavior library. The variable state needed for learning is stored in the behaviors that use it. The second difference distinguishes Edmund from other behavior-based architectures that exploit plan-like structures for organizing complexity, such as RAPs (Firby87) and the other hierarchy-based architectures mentioned above. Although hierarchical, the control architecture supports both reactivity and arbitrary chains and loops of behavior. This is achieved through several methods:

Each element of a competence is prompted to perform by its own perceptual requirements. There is no error passing or assumption of success for an operation. An action sequence will complete regardless of the success of its elements, the result is checked at the competence level. Infinite loops are prevented and alternative strategies enabled by a system of habituation.

The top level of the hierarchy consists of special competences called drives. Drives execute all their elements in course-grained pseudo-parallel with best-attempt scheduling for the frequency of attention to the varying elements. This allows for the constant monitoring of important sense modalities or internal states and the possibility of interruption for urgent or opportunistic conditions.

No stack is maintained as control traverses the hierarchy of competences. When a competence prompts the activation of one of its constituent competences, the new competence takes its place in receiving the attention of the parent drive. This enables infinite loops in behavior, such as oscillating between active exploration and grooming/memorizing phases of behavior in rats exploring new enclosures (Wilson-94-Science). Drives maintain a record of there initial elements, so that if a competence chain completes, the chain may be started again from the beginning. If nothing has changed in the world, control will return to the parent of the competence that just completed which allows the parent in turn to proceed. If something relevant has changed, control may switch to a more appropriate competence or action pattern.

Edmund thus has the potential for expressing fairly dynamic behavior, but it does not have the complete opportunism or full democracy of Maes' and Tyrrell's architectures. Modularity between control abstractions may be violated in the behavior library: there is no restriction on being influenced by the state of other behaviors. As Tyrrell and Blumberg describe, such violations are ubiquitous in animal behavior. On the other hand, Edmund allows for the expression of both sequences and prioritization. It allows for the utilization of selective attention to ensure particular tasks are completed fluently.

Here is the code for edmund (C++ version, circa 1998) in a compressed tar file. This was last updated for the December 1999 gnu compiler, so may be a bit out of date. For current code versions (in Lisp & python), see my POSH page.

For people interested in the comparison work I did with Toby Tyrrell's simulated environment, first get his architecture from here . (The graphics version of that code is unfortunately in sunview, if anyone gets around to converting it to X please mail me! Meanwhile, you should be able to compile and run the no_graphics version on any platform -- I've tested it on solaris and linux.) Then my extensions are in this. Sorry about the lack of documentation, but you should be able to see how to integrate this after you are familiar with Tyrrell's set up. Notice that I have done a fair amount of work on the make files!  My experience building this simulation and all the experiments I ran with it are documented in my MPhil dissertation.  See also the SAB 2000 paper also on my publications page.

New: In late 2003 the World-Wide-Mind project reimplemented both Tyrrell's simulation & my Edmund mouse.  I haven't checked their implementation myself, but it doesn't get as good of results as I did so there must be something wrong ;-).