ArticlePDF Available

L -- A Common Lisp for Embedded Systems

Authors:

Abstract

A commercially available system has been developed which allows for the use of Common Lisp in real time embedded control systems. The backbone of this system is a language called L. L is a subset of Common Lisp with multi-processing extensions. It is ideal for use in embedded systems with small computers. The system has a minimal memory footprint and can run on small processors. L contains both a runtime environment and an interpreter which runs on the target system and a cross compiler which runs on the host system. Making use of Common Lisp's macro facilities, a special purpose language has been constructed on top of L, called MARS for Multiple Agency Reactivity System. This language is uniquely tailored for real time control applications. It allows for the spawning of many small processes which communicate with one another via a message passing approach. A graphical user interface debugging tool was also developed which allows real time monitoring and modification of values of variables on the target system by the host system. Underlying this system is an e#cient real time operating system, called VENUS. The operating system is written in C for portability. The interface between L code and the hardware takes place via operating system calls. L accesses the C operating system calls via its foreign function interface. The first application for this system has been the programming and control of autonomous mobile robots. These robotic systems must process and react to their sensor systems in real time.
L A Common Lisp for Embedded Systems
Rodney A. Brooks
and Charles Rosenberg
IS Robotics
Twin City Office Center, Suite 6
22 McGrath Highway
Somerville, MA 02143, USA
Abstract
A commercially available system has been developed
which allows for the use of Common Lisp in real time
embedded control systems. The backbone of this sys-
tem is a language called L. L is a subset of Comm on
Lisp with multi-processing extensions. It is ideal for
use in embedded systems with small computers. The
system has a minimal memory footprint and can run
on small processors. L contains both a runtime envi-
ronment and an interpreter which runs on the target
system and a cross compiler which runs on the host sys-
tem. Making use of Common Lisp’s macro facilities, a
special purpose language has been constructed on top
of L, called MARS for Multiple Agency Reactiv-
ity System. This language is uniquely tailored for real
time control applications. It allows for the spawning of
many small processes which communicate with one an-
other via a message passing approach. A graphical user
interface debugging tool was also developed which al-
lows real time monitoring and modification of values of
variables on the target system by the host system. Un-
derlying this system is an efficient real time operating
system, called VENUS. The operating system is writ-
ten in C for portability. The interface between L code
and the hardware takes place via operating system calls.
L accesses the C ope rating system calls via its foreign
function interface. The first application for this system
has been the programming and control of autonomous
mobile robots. These robotic systems must process and
react to their sensor systems in real time.
1 Introduction
This development effort was motivated by IS Robotics
main business, the manufacture and programming of
small autonomous robots for real world tasks. These
robots have relatively small processors, a 16 MHz Mo-
torola 68332 with 1 megabyte of RAM. Development for
Also a member of the faculty at the MIT Artificial Intelligence
Laboratory.
these systems is performed on a host computer and code
is then installed on the target system. IS Robotics uses
the behavior control approach (Brooks 1986) to program
its robots. In this approach the control of the robot is
broken up into many small parallel processes each of
which operates on some sensor data and can control
actuators on the robot. In earlier work we used what
we called the Behavior Language (Brooks 1990). It
is written in Common Lisp and produces a complete
ROM image for a particular instance of a users program
which is then installed (or downloaded to non-volatile
RAM) on the robot. We decided we needed more flexi-
bility and dynamic debugging however, so we decided to
implement Common Lisp (Steele Jr. 1990) directly on
the robots. We wanted a system which allows us to dy-
namically redefine functions, test new code interactively,
start and kill processes, and easily create extensions to
the language, and tools which would reduce develop-
ment time. To realize these goals we created a new
system composed of a dialect of Common Lisp (which
we call L), a set of language extensions specific to real
time control, and a special operating system.
2 VENUS
VENUS is a compact, efficient real time operating
system. VENUS provides the low level interface to
the target system hardware nec ess ary to support L.
VENUS is written primarily in C for p ortability.
Only a small portion, the processor dependent part, of
the operating system is written in assembly language.
The low level target system supp ort includes basic in-
put/output and timing functions. The input/output
functionality implements a protocol which utilizes a sin-
gle bi-directional serial line to support five virtual bi-
directional serial lines. A front end processor on the host
decodes this protocol and exchanges packets with the
embedded system. Currently these virtual serial lines
are used to allow the embedded system to: access files
on the host, provide a TTY interface for communica-
tion with the embedded system, and provide a means for
data exchange with graphic debugging tools. The tim-
ing functions implemented by VENUS provide access
to the processor periodic interrupt timer for multithread
scheduling.
VENUS is designed to be compact and modular;
only those pieces of the ope rating system required for
a specific application need be included in the run time
kernel. For our typical Motorola 68332 implementation,
the entire operating system occupies less than 32K bytes
of memory. VENUS is also a dynamically linkable and
modifiable system. The C functions which make up the
most basic parts of the operating system can be changed
dynamically, without rebuilding the entire system, as is
the case with many other operating systems.
The VENUS system includes a low level monitor pro-
gram which provides low level debugging support and
the ability to modify the VENUS run time kernel. This
monitor includes s upport for examining and modifying
memory, linking in new OS kernel code, and debugging
support for ‘hard’ crashes.
3 L
L is a completely new implementation of a subset of
Common Lisp. It is carefully designed so that very
small kernel subsets can be used to build Lisp images,
e.g., ones without eval, read, etc., for small dedicated
applications. We have successfully run L programs in
load images as small as 10K bytes. More typically our
full implementation of L now has a load image of almost
200K bytes, including robot specific libraries.
The main design goal in L has been simplicity. For
this reason we have left out a number of aspects of Com-
mon Lisp, including its bulk.
Specifically we have excluded all the sequence func-
tions, overloaded aritmetic, supplied-p arguments, ex-
tendable data structures (we do include automatically
growing hash tables), the EQ/EQL distinction, flet and
labels, parts of format, large parts of packages, pre-
serving whitespace aspects of read, CLOS, the type sys-
tem, the error condition system, and rationals, bignums,
and trigonometry.
On the other hand L does include multiple values,
strings, characters, arrays, a simplified but compatible
package system, all the “ordinary” aspects of format,
backquote and comma, setf etc., almost full Common
Lisp lambda lists including optionals and keyword argu-
ments, macros, an inspector, a debugger, defstruct (in-
tegrated with the inspector), block, catch, and throw,
etc., full dynamic closures, a full lexical interpreter,
floating point, fast garbage collection, and so on. T he
compiler runs in time linear in the size of an input ex-
pression, except in the presence of lexical closures. It
nevertheless produces highly optimized c ode in most
cases.
The L system is designed to be retargetable. So far we
have run it on Macintoshes and on single chip Motorola
68332’s. To retarget it is necessary to write a back-
end for the assembler, provide code templates for about
100 primitive operations, code sequences for about 20
relatively large but primtive operations (such as cons),
code sequences for about 10 operations such as spread-
ing multiple values on the stack and search the stack for
a throw tag, and LAP macros for about 25 things such
as procedure call, building catch frames, etc.
3.1 The Compiler
The compiler is an intellectual descendant of the S-1
compiler (Brooks, Gabriel & Steele Jr. 1982), and more
recently the Lucid compiler (Brooks, Posner, McDonald,
White, Benson & Gabriel 1986). It shares no code with
either of these previous compilers however.
The design goals for the L compiler were
it should produce reasonably efficient code
compilation s peed should be fast
it should be target independent
it should be easy to maintain
The compiler is written in Common Lisp, of course,
and will probably run in L itself although that has not
been tried at this point.
The compiler is rather simple and does not do reg-
ister allocation for variables. It does open code many
Common Lisp primitive operations however, and when
compiling a tree of primitive operations will use registers
to store multiple intermediate results.
The compiler has three phases: alphatization, analy-
sis, and generation.
During alphatization everything is syntactically
checked and a number of source to source transforma-
tions are made. These include quotation of self eval-
uating literals, macro expansions, and compiler macro
expansions. Most of the Common Lisp control forms
are implemented as compiler macros which take precen-
dence over macros defined in the host Lisp—in this way
the user c an use the host Lisp macro system and the
compiler can still use its own definitions of macro expan-
sions for such things as dotimes. During alphatization
the code tree is walked exactly once.
During the analysis phase a number of further source
to source transformations are made that are target
specific—for instance simple vector references and struc-
ture references might all get mapped to a common un-
derlying reference mechanism at this point, or not, de-
pending on the particular memory model being used for
the target. Other transformations carried out here in-
clude constant folding in arithmetic expressions, and
even reordering of arithmetic operations. All these
transforms take alphatized source and return alphatized
source. At the same time as the code tree is being
walked, in a single pass, for these transformations an
analysis tree is formed. It notes side effects, read/write
status of lexical variables, register usage requirements,
stack height, pointers up the tree to lexical variable,
block, and tag owners, etc. Also during this phase, anal-
ysis of closures is carried out, and source to source trans-
forms are made so that shared lexical variables refer to
the right data structures, with optimizations for read
only lexical variables, etc. If closures are present it is
sometimes necessary to re-invoke analysis on a subtree
for a second time.
As analysis proceeds, the compiler looks at the re-
quirements for open coding primitive procedures di-
rectly in machine code. The following are the descrip-
tions of fixnum + and - for the Motorola 68332.
(defun code-68k-adder (x y ops)
(cond ((and (consp y)
(eq (first y) ’quote))
(if (<= 1 (second y) 2)
‘((,(third ops)
,(ash (second y) 2) ,x))
‘((,(second ops) ,y ,x))))
(t ‘((,(first ops) ,y ,x)))))
(deflprim +
:args ((x dreg) (y any))
:code (code-68k-adder x y ’(add addi addq))
:loc x)
(deflprim -
:args ((x dreg) (y any))
:code (code-68k-adder x y ’(sub subi subq))
:loc x)
Note that these descriptions include requirements on
where the arguments should be (the first argument
should be in a data register), and the actual code gen-
erator does some optimizations when possible. If the
compiler has a tree of primitive operations that require
more than the available number of registers, it may in-
troduce a lexical variable to save an intermediate value
and rebuild the analysis tree and source appropriately.
The descriptions above assume that earlier phases of the
compiler have guaranteed that all calls to these two pro-
cedures are dyadic, and that constants have been pushed
rightward wherever possible.
The following are additional primitive operations, out
of a total of about 100 altogether.
(deflprim eq
:args ((x areg) (y any))
:code ‘((cmpa ,y ,x))
:rep :flag
:loc ’eq)
(deflprim car
:args ((x areg))
:loc ‘(ref-cons ,x 0))
(deflprim cdr
:args ((x areg))
:loc ‘(ref-cons ,x 4))
(deflprim set-car
:args ((x areg) (y any))
:code ‘((move ,y (ref-cons ,x 0)))
:effects (make-rplac-effects)
:loc y)
(deflprim second
:args ((x areg))
:code ‘((move (ref-cons ,x 4) ,x))
:loc ‘(ref-cons ,x 0))
Note that some operations produce a value, while oth-
ers, like eq produce a condition code. A coercion process
in generation must convert such representations if they
are not appropriate for the particular place in which the
operation is used. Note also that set-car has its side
effects noted—this means that generation can not op-
timize it away if its value is not used. Also car and
cdr produce no code at all. They describe how given
a cons cell in an address register, the car and cdr can
be accessed by an addressing mode—expressed with the
LAP (Lisp assembler program) macro ref-cons shown
below:
(deflapoperand ref-cons (reg offset)
‘(areg-indirect-disp
,reg
,(+ offset
(ltarget (- 8 *lptr-cons*)))))
The last phase of the compiler is code generation. For
special forms, procedure calls, etc., it produces a series
of calls to LAP macros which essentially describe an ab-
stract machine. For primitive operations it uses the code
templates as described above to generate specific ma-
chine instructions to implem ent them. Some primitive
operations, such as floating point arithmetic, or storage
allocation are too long to generate each time they are
invoked. So there is a library of fastops, handcoded ma-
chine code s ubroutines to implement these, and the com-
piler generates simple subroutine c alls to these where
appropriate.
Except in the case of closure analysis, all three phases
of the compiler are single pass, and thus rather efficient.
The compiler has a simple form and is not weighed down
by special purpose optimizations. The code it produces
for standard sorts of non-arithmetic things when run
on a Macintosh is much more efficient than the code
produced by the Macintosh Common Lisp compiler
(it would be unfair to compare arithmetic operations as
L does not handle generic arithmetic).
3.2 Arithmetic
There are two types of arithmetic supported in L.
Fixnum arithmetic and small floating point.
The arithmetic operators +, *, etc., only support
fixnums. The Motorola 68332 implementation of
fixnums is 30 bits signed. The fixnum operators act just
like Common Lisp arithmetic operators given fixnums,
except that in L there can never be an overflow into
bignums. Any overflows are ignored and arithmetic is es-
sentially mo d2
30
. Thus fixnum arithmetic never causes
any consing in L.
Besides normal arithmetic, the usual logical operators
are also supported on fixnums.
To use floating point, other operators +$, *$, etc.,
must be used. This is similar to the situation in
Maclisp except that L does not include any additional
generic operators. The Motorola 68332 implementa-
tion of floating point numbers is 28 bits long, including
8 bits of signed exponent in excess 128 format, 19 bits
of mantissa (plus a hidden bit), and 1 bit for the sign of
the number. This floating point format is designed to
fit in an immediate data pointer, so there is never any
consing caused by floating point arithmetic. The draw-
back is that floating point arithmetic is implemented in
software (as fastops), so they are slow, but there is no
floating point hardware on the Motorola 68332 in any
case.
Floating point underflow causes an error, but a macro
without-floating-underflow-traps is provided to
suppress these if desired
1
.
3.3 Packages
The package system in L is simplicity itself, but never-
theless it provides the standard functionality of provid-
ing provate namespaces and it appears compatible with
Common Lisp packages as long as one does not poke
too hard.
In L every symbol in every package is e xternal and ev-
ery symbol is in precisely one package. Packages can use
other packages. When it comes time to resolve the name
of a symbol in a package (e.g., in the package bound by
*package* during read), that package is checked first.
If the name is found there then that is the result. Oth-
erwise all the packages used by the first package, and
1
Note that this was proposed to X3J13 in June 1989 to be
added to Common Lisp but the proposal was rejected.
so on in a depth first s earch are checked until a sym-
bol with the same name is found. If none are found,
then a new symbol is interned in the original package.
This system is very easy to implement. By restricting
the total numbe r of packages to be no more than 16,384
the total storage requirement per symbol is 14 bits, plus
one 32 bit entry in a special package hash table which
simply records the presence or absence of a symbol.
When L starts up there are five packages present:
"SYSTEM", "KEYWORD", "LIB", "L", and "USER". The
"SYSTEM" package contains all the system code. The
"USER" package is empty—both these packages use both
the "L", and "LIB" packages. The "L" package is where
all the Common Lisp symbols reside. The "LIB" pack-
age includes all entry points to robot specific libraries
that have been built on top of L and C for the particu-
lar robot.
3.4 Garbage Collection and Storage
Management
The garbage collection system used in L is a very simple
and elegant stop and copy collector. This interferes with
real time requirements placed on L, so the rest of L is
designed so that for real time programming there is no
need to invoke cons. This includes the design of the
arithmetic s ystem and the design of MARS. The idea
is that the user loads everything (or has it autoloaded)
during which time consing takes place, but thereafter,
unless in debugging mode, there is no need for further
consing.
The storage arrangement in L consists of six spaces:
pure code ROM
pure data ROM
static data RAM GC scans
user code RAM
from space RAM
to space RAM GC scans
The system code is all in the pure code space. String
names of system symbols, keyword symbols themselves
used by system code, the closure objects (including
pointers to all literals) for all system procedures, and
minor other constant data structures are kept in pure
data. It has no pointers to from or to spaces, but may
have pointers within itself and to the static space. The
static space provides pre-allocated data structures which
are guaranteed to remain in place. These include all
other structures that are present when L starts up, such
as symbols, packages, etc. The multithreading system
allocates all stacks in this space so that the garbage col-
lector does not have to deal with relocating an active
stack. Users can also request that data be allocated
here by using the macro with-static-consing. The
trade off in using this space is that the garbage collector
never has to copy things from here, but it does have to
scan them even if they do become garbage, and they are
never collected.
User loaded machine code goes into the user code
space. This space is not garbage collected and can po-
tentially fill up just from repeatedly reloading the same
compiled file.
The from and to spaces are the two half spaces for
user data. Their roles are swapped at each garbage col-
lection.
3.5 Multithreading
The multithreading system in L is unique—it is not a
subset or superset of anything in Common Lisp. It
is a p olling pre-emptive scheduler with the abiltity for
processes to put themselves to sleep for a given duration.
Since the pre-emptive scheduler uses polling, it
only pre-empts if code was specifically compiled for
multithreading—this is the default and only about 20
critical procedures in the whole L system are not com-
piled for polling.
A thread only polls, and thus is only ever suspended,
on procedure entry right after all argument parsing has
been done. This includes catching cases of self tail re-
cursive calls. Many threads have their own stack, so on
entry to a multithreading compiled procedure, a check
is done to see if it lo oks like there is enough stack left,
and if not an error is signalled.
When L starts up it is not in multithreaded
mode. But it is possible to evaluate a procedure
called start-multi-processing, which spawns a new
read-eval-print loop, and schedules it to be run re-
peatedly. The scheduler runs in the normal Lisp stack.
The scheduler is based on an internal clock, gotten
with get-internal-real-time. It uses an efficient data
structure to reschedule when to next run each thread as
it requests as it is suspended.
A procedure called spawn can be used to start up
additional threads. There are two sorts of threads.
3.5.1 Light weight threads
Lightweight threads do not have their own stack and
are run from the normal Lisp stack. Whenever such a
thread is invoked, some specific procedure is called and
it runs until it returns—never polling. Its return value
is how many internal time units before it wants to be
run again.
3.5.2 Heavy weight threads
Heavy weight threads have their own stack. They are
spawned as a procedure to be called, but it is expected
that that procedure will never return—the thread is
killed if it does . During e very procedure entry within
the thread the system polls a register maintained by
VENUS saying how much time is left in the slice of
the current thread. When it is zero or less the thread
relinquuishes control to the scheduler which reschedules
it some small time interval later. Threads can also vol-
untarily reschedule themselves by calling sleep, or vari-
ants thereon.
Context switching of heavy weight processes can be
expensive if they are suspended with special variables
rebound—their stack needs to be traversed to undo
these binds before switching to another thread, and then
be traversed again to put them back when restarting this
thread.
3.6 Debugging
The standard debugging tools provided in L are a text
based inspector and a text based stack walker.
The inspector lets the user examine the full internals
of any data structure. It is integrated with defstruct
so that slot names are displayed for structures whose
defstruct has been loaded into the current environ-
ment.
The stackwalker lets the user move up and down any
suspended stack (including those of other threads that
have signalled errors), examing the stack frames and in-
voking the inspector on any slots. There are also facili-
ties for looking at raw machine memory which is some-
times useful in debugging sensors and actuators.
Machine traps are caught in the VENUS operating
system and handed back to L so that they can be dis-
played within the context of the Lisp computation which
caused the problem.
Other useful tools are apropos and who-refers?.
The first is standard Common Lisp and uses
do-all-symbols to find symbols whose name matches
a partial string. The second is an L construct which
searchs all the procedure objects in the system to find
all literal references to an argument symbol.
3.7 The Motorola 68332 Implementa-
tion
For 68000 based architectures we have used a lowtag
scheme to represent lisp objects. Here the bottom three
bits determine the gross type of a pointer according to
the following scheme:
Bits Pointer
000 even fixnum
001 cons cell
010 gc forwarding pointer
011 object with header
100 odd fixnum
101 symbol
110 reserved
111 immediate data item
All of the even data types can also be pointers to
objects created by C, and there only needs to be a little
extra checking in the garbage collector to disambiguate
forwarding pointers.
Besides fixnums, immediate data objects include char-
acters, floating point numbe rs, unbound markers, vari-
ous stack markers for special binds, etc., and headers for
objects in the heap.
All objects in the heap are aligned at eight byte
boundaries, and pointers to them point to within the
previous eight bytes. Symbols and cons cells have no
headers—all their elements are simply scanned by the
garbage collector. Other objects such as strings, arrays,
procedure objects, etc., have headers which say what
their size is and how the garbage collector should treat
them as it scans through the heap.
4 MARS
The Multiple Agency Reactivity System, or
MARS, is a language for programming multiple con-
current agents. It is embeded in L, and as such, all of
that subset of Common Lisp is available for use any-
where within programs.
MARS is a method for defining many asynchronous
parallel processes which run in a single L heap. Groups
of these processe s are called assemblages which share a
lexical environment and some number of ports which are
message passing interfaces between assemblages. Ports
are bi-directional, but a port from one assemblage can
only be connected uni-directionally to a port of an-
other assemblage. Connections of ports involve one deep
buffers and message arrival flags. New instances of as-
semblages can be spawned dynamically at runtime. As-
semblages also can be dynamically killed. Connections
can be dynamically made and broken.
There is also a graphical user interface which allows
for dynamic monitoring and altering of all port values.
These monitors can be added dynamically at run time to
any port. The graphics run on a host machine, such as
a Macintosh—there is a standard interface envionment
that runs in Macintosh Common Lisp.
MARS is somewhat like the earlier Behavior Lan-
guage, a method for layering behavior producing pro-
grams, one after the other, in a system connecting sen-
sors to actuators. In fact there is a fairly straightfor-
ward translation from Behavior Language programs
to MARS programs. But MARS programs can be
much richer as they have access to all of Common Lisp.
In addition, all linking is completely dynamic, and all
housekeeping is invisibly taken care of so that assem-
blages (roughly corresponding to behaviors in Behavior
Language) can be redefined at run time, new assem-
blages can be created, and old ones killed.
The graphical user interface is supported via one
of the extra virtual serial lines implemented in L and
VENUS. A packet protocol is built on top of this se-
rial line (which itself is built on top of a packet protocol
which is built on top of an actual serial line). Besides
handling graphics traffic this system is also used to im-
plement other interactions be tween the front end (host
machine), and L.
Great care has been taken in the implementation of
both MARS itself and the graphical user interface to
make debugging e asy. Everything is dynamically linked
so that new versions of subsystems can be recompiled
and reloaded onto an existing working system, without
any interruptions. All the graphic windows resize them-
selves should it be necessary when this happens, and
things that have had monitors attached to them stay
monitored even when they are completely redefined by
overloading a new version of the code–even to the point
of handling changes in underlying representations in the
middle of display option choice back on the host com-
puter. All this is a marked improvement over the earlier
Behavior Language.
5 Conclusion
Our goal was to create a development system which
would allow us to have all of the advantages of Common
Lisp on a small embedded computer system. The L lan-
guage was developed to se rve this purpose. It is a highly
efficient subset of Common Lisp with multithreading
extensions and a cross compiler. It can run on the rela-
tively small processors often used in embedded systems.
To improve programming efficiency, a language, named
MARS, was built on top of L. This package greatly
simplifies the creation and debugging of large numbers
of inter-communicating processes. IS Robotics is com-
mitted to the continuing development and improvement
of the L system and its commercial viability. We firmly
believe L to be a superior solution for creating complex
real time embedded control systems.
References
Brooks, R. A. (1986), ‘A Robust Layered Control Sys-
tem for a Mobile Robot’, IEEE Journal of Robotics
and Automation RA-2, 14–23.
Brooks, R. A. (1990), The Behavior Language User’s
Guide, Memo 1227, Massachusetts Institute of
TechnologyArtificial Intelligence Lab, Cambridge,
Massachusetts.
Brooks, R. A., Gabriel, R. P. & Steele Jr., G. L. (1982),
An Optimizing Compiler for Lexically Scoped Lisp,
in ‘Proceedings of the 1982 Symposium on Com-
piler Construction, ACM SIGPLAN’, Boston, Mas-
sachusetts, pp. 261–275. Published as ACM SIG-
PLAN Notices 17, 6 (June 1982).
Brooks, R. A., Posner, D. B., McDonald, J. L., White,
J. L., Benson, E. & Gabriel, R. P. (1986), Design
of An Optimizing Dynamically Retargetable Com-
piler for Common Lisp, in ‘Proceedings of the 1986
ACM Symposium on Lisp and Functional Program-
ming’, Cambridge, Massachusetts, pp. 67–85.
Steele Jr., G. L. (1990), Common Lisp, The Language,
second edn, Digital Press.
... Programmers often test a language's mettle by how successfully it has fared in commercial settings, where big money is often on the line. To this end, Lisp has been successfully adopted by commercial vendors such as the Roomba vacuuming robot [24,25], Viaweb (acquired by Yahoo! Store) [26], ITA Software (acquired by Google Inc. and in use at Orbitz, Bing Travel, United Airlines, US Airways, etc.) [27], Mirai (used to model the Gollum character for the Lord of the Rings movies) [28], Boeing [29], AutoCAD [30], among others. ...
Article
Full-text available
We present a rationale for expanding the presence of the Lisp family of programming languages in bioinformatics and computational biology research. Put simply, Lisp-family languages enable programmers to more quickly write programs that run faster than in other languages. Languages such as Common Lisp, Scheme and Clojure facilitate the creation of powerful and flexible software that is required for complex and rapidly evolving domains like biology. We will point out several important key features that distinguish languages of the Lisp family from other programming languages, and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSLs): languages that are specialized to a particular area, and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the 'programmable programming language'. We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and artificial intelligence research in bioinformatics and computational biology.
... Programmers often test a language's mettle by how successfully it has fared in commercial settings, where big money is often on the line. To this end, Lisp has been successfully adopted by commerical vendors such as the Roomba vacuuming robot [32, 33], Viaweb (acquired by Yahoo! Store) [34], ITA Software (acquired by Google Inc. and in use at Orbitz, Bing Travel, United Airlines, US Airways, etc) [35], Boeing [36], AutoCAD [37], among others. ...
Article
We address the need for expanding the presence of the Lisp family of programming languages in bioinformatics and computational biology research. Common Lisp, the most comprehensive of the Lisp dialects, offers programmers unprecedented flexibility in treating code and data equivalently, and the ability to extend the core language into any domain-specific territory. These features of Common Lisp, commonly referred to as a "programmable programming language," give bioinformaticians and computational biologists the power to create self-modifying code and build domain-specific languages (DSLs) customized to a specific application directly atop of the core language set. DSLs not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. These standards may then be shared as libraries with the bioinformatics community. Likewise, self-modifying code (i.e., code that writes its own code on the fly and executes it at run-time), grants programmers unprecedented power to build increasingly sophisticated artificial intelligence (AI) systems, which may ultimately transform machine learning and AI research in bioinformatics and computational biology.
... The robots use wide angle (60-degree) non-actuated cameras. We develop our systems with MARS/L from IS Robotics [12], an on-board Motorola 68332 microcontroller programmed in a Common LISP extended for behavior-based control, and often port them to ActivMedia's C-based PAI (Pioneer Application Interface) environment when we borrow robots not equipped with the MARS/L system. The Pioneer has a low level controller that runs the Pioneer Server Operating System from ROM. PSOS provides sensor readings periodically, and accepts commands which set rotational velocity, translational velocity, and individual wheel speeds, as well as other motor-and sensor-control functions. ...
Article
Full-text available
While terminology and some concepts of behavior-based robotics have become widespread, the central ideas are often lost as researchers try to scale behavior to higher levels of complexity. "Hybrid systems" with model-based strategies that plan in terms of behaviors rather than simple actions have become common for higherlevel behavior. We claim that a strict behavior-based approach can scale to higher levels of complexity than many robotics researchers assume, and that the resulting systems are in many cases more efficient and robust than those that rely on "classical AI" deliberative approaches. Our focus is on systems of cooperative autonomous robots in dynamic environments. We will discuss both claims that deliberation and explicit communication are necessary to cooperation and systems that cooperate only through environmental interaction. In this context we introduce three design principles for complex cooperative behavior - minimalism, statelessness and tolerance - and present a ...
Article
Full-text available
We report on a dynamically balancing robot with a dexterous arm designed to operate in built-for-human environments. Our initial target task has been for the robot to navigate, identify doors, open them, and proceed through them.
Article
Full-text available
We report on a dynamically balancing robot with a dexterous arm designed to operate in built-for-human environments. Our initial target task has been for the robot to navigate, identify doors, open them, and proceed through them.
Article
This thesis presents an integrated framework and implementation for Mertz, an expressive robotic creature for exploring the task of face recognition through natural interaction in an incremental and unsupervised fashion. The goal of this thesis is to advance toward a framework which would allow robots to incrementally "get to know" a set of familiar individuals in a natural and extendable way. This thesis is motivated by the increasingly popular goal of integrating robots in the home. In order to be effective in human-centric tasks, the robots must be able to not only recognize each family member, but also to learn about the roles of various people in the household. In this thesis, we focus on two particular limitations of the current technology. Firstly, most of face recognition research concentrate on the supervised classification problem. Currently, one of the biggest problems in face recognition is how to generalize the system to be able to recognize new test data that vary from the training data. Thus, until this problem is solved completely, the existing supervised approaches may require multiple manual introduction and labelling sessions to include training data with enough variations. Secondly, there is typically a large gap between research prototypes and commercial products, largely due to lack of robustness and scalability to different environmental settings.
Conference Paper
We present the design and construction of Mertz, an active-vision humanoid head robot, with the immediate goal of having the robot runs continuously for many hours a day without supervision at various locations. We address how the lack of robustness and reliability lead to limitations and scalability issues in research robotic platforms. We propose to attend to these issues in parallel with the course of robot development. Drawing from lessons learned from our previous robots, we incorporated various fault prevention strategies into the electromechanical design. We have implemented a preliminary system, integrating sensorimotor, vision, and audio in order to test the full range of all degrees of freedom and enable the robot to engage in simple visual and verbal interaction with people. We conducted a series of experiment where the robot ran for 82 hours within 9 days at different public spaces. The robot interacted with a large number of passersby and collected at least 100,000 face images of at least 600 individuals within 4 days. We learned various lessons involving the robustness of current design and identified a set of failure modes. Lastly, we present the long term research direction for the robot.
Conference Paper
Full-text available
We outline the components of a retargetable cross-compiler for the Common Lisp language. A de- scription is given of a method for modeling the various hardware features in the compiler's database, and a breakdown is shown of the compiler itself into various machine-independent and machine-dependent mod- ules. A novel feature of this development is the dynamic nature of the retargeting: Databases for multiple hardware architectures are a standard part of the compiler, and the internal interfaces used by the compiler are such that the machine-dependent modules may be instantly switched from one to another. Examples of generated code in several environments will be given to demonstrate the high quality of the output available, even under this very modular approach.
Conference Paper
Full-text available
The authors are developing an optimizing compiler for a dialect of the LISP language. The current target architecture is the s-1, a multiprocessing supercomputer designed at Lawrence Livermore National Laboratory. While LISP is usually thought of as a language primarily for symbolic processing and list manipulation, this compiler is also intended to compete with the S-1 pascal and FORTRAN compilers for quality of compiled numerical code. The S-1 is designed for extremely high-speed signal processing as well as for symbolic computation; it provides primitive operations on vectors of floating-point and complex numbers. The LISP compiler is designed to exploit the architecture heavily. The compiler is structurally and conceptually similar to the BLISS-11 compiler and the compilers produced by PQCC. In particular, the tnbind technique has been borrowed and extended. The compiler is stable-driven to a great extent, more so than BLISS-11 but less so than a PQCC compiler. 58 references.
Article
Full-text available
The Behavior Language is a rule-based real-time parallel robot programming language originally based on ideas from [Brooks 86], [Connell 89], and [Maes 89]. It compiles into a modified and extended version of the subsumption architecture [Brooks 86] and thus has backends for a number of processors including the Motorola 68000 and 68HC11, the Hitachi 6301, and Common Lisp. Behaviors are groups of rules which are activatable by a number of different schemes. There are no shared data structures across behaviors, but instead all communication is by explicit message passing. All rules are assumed to run in parallel and asynchronously. It includes the earlier notions of inhibition and suppression, along with a number of mechanisms for spreading of activation. Support for this research was provided in part by the University Research Initative under Office of Naval Research contract N00014--86--K--0685, in part by the Advanced Research Projects Agency under Office of Naval Research contract...
Article
We are developing an optimizing compiler for a dialect of the LISP language. The current target architecture is the S-I, a multiprocessing supercomputer designed at Lawrence Livermore National Laboratory. While LISP is usually thought of as a language primarily for symbolic processing and list manipulation, this compiler is also intended to compete with the S-1 PASCAL and FORTRAN compilers for quality of compiled numerical code. The S-1 is designed for extremely high-speed signal processing as well as for symbolic computation; it provides primitive operations on vectors of floating-point and complex numbers. The LISP compiler is designed to exploit the architecture heavily. The compiler is structurally and conceptually similar to the BLISS-11 compiler and the compilers produced by PQCC. In particular, the TNBIND technique has been borrowed and extended.
Article
A new architecture for controlling mobile robots is described. Layers of control system are built to let the robot operate at increasing levels of competence. Layers are made up of asynchronous modules that communicate over low-bandwidth channels. Each module is an instance of a fairly simple computational machine. Higher-level layers can subsume the roles of lower levels by suppressing their outputs. However, lower levels continue to function as higher levels are added. The result is a robust and flexible robot control system. The system has been used to control a mobile robot wandering around unconstrained laboratory areas and computer machine rooms. Eventually it is intended to control a robot that wanders the office areas of our laboratory, building maps of its surroundings using an onboard arm to perform simple tasks.