What is XABSL?

The Extensible Agent Behavior Specification Language XABSL is a very simple language to describe behaviors for autonomous agents based on hierarchical finite state machines. XABSL was developed to design the behavior of soccer robots. Behaviors specified in XABSL proved to be very successful during RoboCup since 2004. The GermanTeam has won the competitions in the Standard Platform League (using Sony Aibo robots) in 2004, 2005, and 2008. The Darmstadt Dribblers have won the Humanoid Kid Size competition in 2009 and 2010. However, the usage of the language is not restricted to robotic soccer. XABSL is a good choice to describe behaviors for all kinds of autonomous robots or virtual agents like characters in computer games.

Examples

• The sources and documentation of an XABSL example implementation for the ASCII Soccer simulator. These behaviors are also contained in the XABSL release, so you can play around with them.
• The documentation of the GermanTeam's behaviors for their winning entry in the RoboCup 2008 Standard Platform League.

Publications

M. Risler. Behavior Control for Single and Multiple Autonomous Agents Based on Hierarchical Finite State Machines. Fortschritt-Berichte VDI Reihe 10: Informatik/Kommunikation, No. 801, Darmstadt, VDI-Verlag, 2009.    [bibtex]

M. Risler and O. von Stryk. Formal Behavior Specification of Multi-Robot Systems Using Hierarchical State Machines in XABSL. In AAMAS08-Workshop on Formal Models and Methods for Multi-Robot Systems, Estoril, Portugal, 2008.    [bibtex]

M. Lötzsch, M. Risler, and M. Jüngel. XABSL - A Pragmatic Approach to Behavior Engineering. In Proceedings of IEEE/RSJ International Conference of Intelligent Robots and Systems (IROS), pages 5124-5129, Beijing, China, 2006.    [bibtex]

M. Lötzsch. XABSL - A Behavior Engineering System for Autonomous Agents. Diploma thesis. Humboldt-Universität zu Berlin, 2004.    [bibtex]

M. Lötzsch, J. Bach, H.-D. Burkhard, and M. Jüngel. Designing Agent Behavior with the Extensible Agent Behavior Specification Language XABSL. In D. Polani, B. Browning, and A. Bonarini, editors, RoboCup 2003: Robot Soccer World Cup VII, volume 3020 of Lecture Notes in Artificial Intelligence, pages 114-124, Padova, Italy, 2004. Springer.    [bibtex]

What do you need to use XABSL for your agent?

To start using XABSL for your agent you need only three things:

• A text editor of your choice
• The XABSL-Compiler (ruby-based)
• The XabslEngine (C++ or Java library)

The behavior is described by a set of .xabsl files. These have to be compiled to an intermediate code using the XABSL-Compiler. At the start-up of the agent this intermediate code is read by the XabslEngine which executes the behavoirs during run-time.

How to describe behaviors with XABSL?

Agents

Options

States

Decision Trees

How does it work?

Within options, the activation of behaviors on lower levels is done by state machines. Each state has any number of subsequent options basic behaviors. Note that there can be several states that have the same subsequent option or basic behavior.

The chart to the right shows the internal state machine of the option "goalie-playing". Circles denote states, the circle with the two horizontal lines denotes the initial state. An edge between two states indicates that there is at least one transition from one state to the other. The dashed edges show which other option or basic behavior becomes activated when the corresponding state is active.

Each option has an initial state. This state becomes activated when the option was not active during the last execution of the option graph. Additionally, states can be declared as target states. In the options above it can be queried if the subsequent option reached such a target state. This helps to check if a behavior was successful.

Additionally, each state can set special requests (output symbols), that influence the information processing besides the actions that are generated from the basic behaviors.

Each state has a decision tree with transitions to other states at the leaves. For the decisions the agent's world state, other sensory information and messages from other agents can be used. As timing is often important, the time how long the state is already active and the time how long the option is already active can be taken into account.

The chart to the right shows the decision tree of the state "get-to-ball". The leaves of the tree are transitions to other states. The dashed circle denotes a transition to the current state.


The execution of the option graph starts from the root option of the agent. For each option the state machine is carried out once, the decision tree of the active state is executed to determine the next active state. This is continued for the subsequent options of the active state.

During behavior execution, the options and basic behaviors that are activated at a specific time step form a rooted tree which is a subtree of the option graph, the so called option activation tree. The diagram to the right shows an example option graph from a simple two-player robot soccer behavior. It depicts the decomposition of the task of playing soccer into several options and a basic behavior. Boxes represent options, ellipses represent basic behaviors. The edges show which options might get activated from another option. The highlighted options, basic behaviors and edges show an example of a possible option activation tree, showing which behaviors are activated during one specific time step.

Agents following this layered state machine architecture can be completely described in XABSL. There are language elements for options, their states, and their decision trees. Boolean logic (||, &&, !, ==, !=, <, <=, > and >=) and simple arithmetic operators (+, -, *, / and %) can be used for conditional expressions. Custom arithmetic functions (e.g. distance-to(x, y)) that are not part of the language can be easily defined and used in instance documents.

Symbols are defined in XABSL instance documents to formalize the interaction with the software environment. Interaction means access to input functions and variables (e. g. from the world state) and to output functions (e. g. to set requests for other parts of the information processing). For each variable or function that shall be used for conditions a symbol has to be defined. This makes the XABSL architecture and programming language independent from specific software environments and platforms.

As basic behaviors are implemented externally, prototypes and parameter definitions have to be specified in an XABSL document so that states can reference them.