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