SPLAT documentation - chapter 1
Overview

SPLAT provides both a language for defining robot plans and control laws and a runtime capable of executing these plans. The emphasis is on flexibility and simple construction. SPLAT provides a basic core of primitives for describing both continuous and discrete actions. It does not address issues of knowledge representation, planning, etc. (which are the sorts of research issues one might want to use SPLAT as a testbed for) but does provide hooks for these sorts of algorithms to use SPLAT as their back end.

A basic assumption behind SPLAT is that most useful kinds of robot behavior will be guided by some sort of closed-loop feedback control. SPLAT fills the gap between a plan specification, which is generally an open-loop, top-down description of the sub-parts of a robot task, and physical control of the robot apparatus, which is guided by both the plan and the dynamic nature of the environment.

This is accomplished by allowing the basic unit of plan construction to be much more than a set of motor controls. Instead, each plan primitive (or splat) is a rich structure containing multiple methods of execution, handlers for exceptional conditions, restrictions on the context in which the action is appropriate, and so on.

The basic unit of task execution is a single splat. A splat describes a discrete action which has a clearly-defined "begin" and "end" points, as opposed to a continuous behavior that has "start" and "stop" points. A splat might describe how to pick up an object, how to traverse a doorway, or how to call an elevator. Splats can be hierarchically composed to build primitive skills into complex plans. The system was designed so that a programmer could define a library of primitive skills as splats which could be the building blocks for a planning system. Using splats as the intermediate language between automatic planning and plan execution allows the planning system to focus on describing the solution and lets the splat system deal with robustness and exception handling.

An action which is continuous and has no predetermined termination conditions is called a behavior. For example, following a wall is best described as a behavior, but going from one end of a hallway to another is best described as a splat.

The implementation of SPLAT is a library of code and syntax forms which depends heavily on the extended Scheme language implemented by RScheme. RScheme provides a capable object system, support for multiple threads of execution, and a powerful syntactic extension mechanism, and SPLAT is heavily intertwined with all of these facilities.


1.1 Reasons for using SPLAT

Since SPLAT is a tool, and not an end in itself, it has the burden of providing measurable benefit over existing solutions if it is to be used and useful. We wrote SPLAT to be a functional replacement for Firby's RAPS system, which we found to be excessively complex and burdened by the results of several generations of incremental fixes and extensions. As a replacement for RAPS, SPLAT has several virtues.

1.1.1 Small implementation, modest scope

The current source for SPLAT comes to less than 2000 lines of Scheme code. This is a manageable, understandable, modifyable code base. RAPS is about 8000 lines of Common Lisp code, and more importantly, 8000 lines of Common Lisp code that someone else wrote. RAPS includes a planner and knowledge representation system that are not necessarily the ones I want. SPLAT leaves planning and knowledge representation to the researcher, and leaves the action sequencing and closed-loop control as a self-contained entity that can be fit into any planning and control framework.

1.1.2 Integration of continuous and discrete actions

RAPS separates "skills" from RAPS, requiring continuous behaviors to be written in C language and put in a different executable without ready access to the LISP environment. SPLAT uses RScheme's multithreaded runtime, which gives continuous behaviors access to the same environment as discrete actions. If you want to go outside the Scheme environment, you can. Locally, we use SPLAT with an inter-language distributed object system (to be released in future versions of the SPLAT code, or when ARGUS becomes ready for public view, whichever comes first) that lets us have C code running on whatever machine is most capable. But it's easy to keep as much information as you want available for both discrete and continuous control processes.

1.1.3 Memory access control without full knowledge representation

A basic problem in event-driven systems is noticing when an event has occurred without polling. RAPS solves this problem via "RAP Memory", a blackboard-like structure which has access controls that can detect changes to memory locations and take appropriate action. RAPS circumvents the LISP environment and forces all variables in RAPS to go through RAP Memory. This seems excessive, and intertwines knowledge representation with the plan execution model too much. The SPLAT system requires event handlers and other routines that can be fired at any time a predicate becomes true to use a special data type, the splat fluent, and to explicitly list all relevant splat fluents as a tag for the predicate thunk. This dramatically reduces the overhead of locating and calling event handlers and other asynchronous routines, and does not tie the programmer down to a particular knowledge representation strategy.
SPLAT documentation - Copyright 1996-1997 Bill Gribble.
Contents; next.
2 September 1997
Bill Gribble grib@cs.utexas.edu