The ARCL Robot Programming System

Peter Corke and Robin Kirkham

CSIRO Division of Manufacturing Technology
Locked Bag 9, Preston 3072 Australia
The wide variety of robot programming languages available and their limitations can reduce the
value of robots in establishing competitive industries. A solution is the use of a standard program-
ming language and a library of robot control functions. ARCL (for Advanced Robot Control Li-
brary) is a powerful, general, and portable software library which provides robot control capability
to C language application programmers. ARCL, developed by the CSIRO Division of Manufac-
turing Technology, supports sensor-based motion control, and has been used in projects related to
force-controlled deburring and high-performance visual servoing. Robot controllers using the ARCL
library have replaced the VAL-I controller on Unimate Puma 560 robots, and controlled a stepper
motor robot attached to a PC. As well as real-time systems, ARCL runs o-line on Unix worksta-
tions and PCs, and can produce graphical simulation of robot motion. This paper introduces the
software and its capabilities.

1 Introduction of the ARCL robot programming system. ARCL

(Advanced Robot Control Library) is a real-time soft-
A robot control language is a textual means of den- ware library that provides robot control facilities for
ing the actions required of a robot manipulator in an existing computer programming language, C[7].
order to complete some task. Robot languages ap-
peared when the increasing complexity of tasks be-
gan to require programmed decision-making ability
and interaction with other manufacturing equipment.
The underlying robot system must interpret this pro-
gram and generate the movement directives for the
axes of the manipulator.
Early languages, such as Unimation's VAL-I[13],
were implemented as interpreters to facilitate on-line
program development and resembled BASIC in style.
Since that time, the languages have evolved and im-
proved, and taken lessons from modern structured
programming languages: KAREL, from GMF, and
LM[8], very roughly resemble Pascal. Yet, the facili-
ties considered standard in a modern computer pro-
gramming language, such as Pascal or C, are rarely
completely oered in these robotic languages. Fre-
ARCL provides robot-specic data types and opera-
tions to the C programmer allowing robot programs
to use C and other application libraries, rather than
a limited and proprietary robot language.
It provides a set of robotic data types and opera-
tors, including vectors, homogeneous transformations
and quaternions. It provides a powerful application
program interface, the functions called by a program
to make the robot move. Finally it provides the real-
time part of the robot system|the trajectory gener-
ator and kinematic solutions, and interfaces for deliv-
ering the computed position set-point stream to the
robot control hardware.
The addition of robot functions to a standard lan-
guage is not a new idea. RCCL, developed at Purdue
and later McGill University, uses C and runs on a
Unix host[5, 9]. Others have described a similar ap-
quently, user-denable types or common control struc-
tures are not available, or there are restrictions on
subroutine argument passing or recursion|and so on.
This makes robot programming more dicult than it
need be.
It would be possible to design a robot language
with all the facilities of a `proper' language, but this
would only create yet another robot language. It has
been suggested that there are already too many such
proach based on Pascal[11, 1]. We believe ARCL is
more modular and portable than these previous sys-
tems.
Portability across computer architectures, operat-
ing systems, manipulator kinematics and robot hard-
ware is achieved through replaceable modules. One
provides kinematic functions and the other provides
real-time operating system services and low-level con-
trol of the robot. ARCL controllers currently replace
languages (a 1986 report[6] identied around 95). VAL-I control on several Puma 560 robots, as well
A dierent approach was used in the development as controlling a Farley/MD gantry robot and a Mi-
crobot educational robot. ARCL programs can also
 Type Meaning cated, and have a `constructor' function which allo-
ROBOT Structure representing a Robot cates and initialises the object from simpler objects
Vector 3D Cartesian coordinate passed as parameters, and return a pointer to the new
Trans Homogeneous Transformation object. The most commonly used object in ARCL
Pos Transformation Position Equation programs is the homogeneous transform, type Trans,
Diff Dierential Displacement Vector which represents a position plus rotation. Another
Force Force/torque Vector important object is the ROBOT type, which is a `han-
Jacob Jacobian Matrix dle' for a robot the programmer wishes to use.
Quat Unit Quaternion
QuatVect Unit Quaternion and Vector The following robot program fragment illustrates
IOD IO Channel Descriptor these types:
Table 1: Common ARCL data types #include <arcl.h>

main(int argc, char *arv[])

run o-line for program development. {
ARCL's robot motion specication model is based ROBOT *rp;
on Paul's general formulation of the robot control Trans *stand, *work, *base, *tool;
problem[11]. This provides standard manipulator tra- Pos *pos;
jectory types as well as permitting functionally de-
ned and real-time sensor-based trajectory modica- rp = arcl_open(
ARCL_ARGCV, argc, argv,
tion. 0);
ARCL has been in
uenced by other robot pro- if (rp == NULL) {
gramming systems as well as some non-robot sys- fprintf(stderr,
tems. For instance, ARCL's frequent use of call- "Can't open manipulator"
back functions as an event passing mechanism is rem- );
iniscent of graphical user interface (GUI) program- exit(1);
ming. Homogeneous transforms are often found in }
computer graphics. ARCL's application program in-
terface (AAI) also makes use of attribute-oriented base = new_trans_tr(
argument lists to conveniently express modiers to "base", 0.0, 0.0, 300.0
functions, a C idiom associated with object-oriented );
programming. tool = new_trans_tr(
ARCL's versatility and capacity for sensor-based "tool", 0.0, 0.0, 170.0
real-time trajectory modication has made it use-
ful for exploratory work in high-bandwidth control.
It has been a key component of research at DMT
projects into force controlled robotic grinding and de-
burring 1985-7[2], and more recently high-performance
robotic visual servoing[4, 3].
In the following sections we will examine some of
the key features of ARCL in more detail.
2 ARCL Robot Programming
This section illustrates some of the key concepts of
an ARCL application through a simple example pro-
gram.
2.1 Robot Data Types
);
stand = new_trans_tr(
"stand", 600.0, 100.0, 500.0
);
work = new_trans_rotvec(
"work", -100.0, 50.0, 345.0,
yunit, 30.0
);
Here, main() declares some objects and proceeds to
construct them. Firstly, arcl open() initialises ARCL
itself and returns a pointer rp to a ROBOT object,
which will be used to identify that robot to sub-
sequent functions (somewhat like a C-library FILE
pointer). arcl open() accepts an attribute-oriented
argument list terminated by a zero value. In this
example we pass in the Unix command line argu-
ments, so that ARCL can parse the command line
switches. In a multi-robot program, several calls to
arcl open() are made, with an attribute indicating
Robot specic data types, listed in Table 1, and ARCL which of the given set of robots to open.
functions are declared with a conventional C header Homogeneous transforms base, tool and stand
le arcl.h. Most data objects are dynamically allo- are purely displacement, and are constructed using
 used to identify this position equation to subsequent
tool functions.
Using position equations seems a roundabout way
of to dene robot targets. The power of this formula-
tion will become apparent when functionally-dened
transforms are examined.
work
T6

2.3 Robot Motion

Robot motion is invoked using the move() function,
stand which accepts a ROBOT pointer, to identify which robot
to move, and a Pos pointer, identifying which posi-
tion equation to use. Our ARCL example might in
base
the simplest case use:
Origin move(rp, pos, 0);

move() is an attribute-oriented function that may

Figure 1: Robot Position Equation take additional arguments: a 0 marks the end of
the list. For instance, we might want a Cartesian-
new trans tr(), which takes the transform's transla-
interpolated move, so we would use:
tional components px , py and pz as parameters. work
has an rotation component of 30 about the y^ direc- move(rp, pos,
tion vector as well as displacement, constructed with MOV_TRAJ, TRAJ_CART,
new trans rotvec(). 0);

or we might want joint-interpolation, and the move

2.2 Position Equations to take 2 seconds:
However, ARCL does not use homogeneous trans- move(rp, pos,
forms directly as target points for the robot. Instead, MOV_TRAJ, TRAJ_JOINT,
destination conditions are dened in terms of the so- MOV_TIME, 2000,
lution of a position equation[11]: 0);

base T6 tool = stand work We can specify the kinematic conguration to switch
to like this:
This establishes a relationship between transforms
in the manipulator's workspace (see Figure 1). The move(rp, pos,
transform T6 represents the pose of the manipulator. MOV_TRAJ, TRAJ_JOINT,
MOV_TIME, 2000,
In ARCL programs, position equations are dened MOV_CONFIG, "lun",
using makeposition(). Our example program would 0);
dene the above equation:
where "lun" means \left-hand elbow-up no-twist".
pos = makeposition( There are some 20 attributes to move(); where an
base, T6, tool, EQ, stand, work, attribute is not specied, it takes a default value, or
TL, tool the value it was last set to be.
);

As in the position equation, T6 is a pre-dened trans-
form representing the robot manipulator, and the EQ
marker indicates the position of the = operator. The
TL marker indicates the frame in the equation which
is the tool tip of the manipulator, required for tool
2.4 Trajectory Generator and
Motion Queue
move() in fact queues a motion request to the trajec-
tory generator, and returns immediately, not when
velocity specication. The returned Pos pointer is the motion is actually complete. Repeated calls to
move() will queue several motion requests.
 User program task If the robot is approaching the end of a motion seg-
move() ment, the trajectory generator's segment path plan-
ner de-queues the next motion request from the mo-
tion queue, and sets up a zero-jerk transition (B1 to
B2) into the new segment (see Figure 3). This may
mean that the end-point of the original segment (B)
Target position is never reached. If the motion queue is empty, the
trajectory generator smoothly decelerates the robot
Trajectory
Generator to the target T6 .
Task
Motion request queue

2.5 Functionally Dened and

Sensor In
uenced Motion
Trajectory
Generator Because the trajectory generator re-evaluates the ho-
mogeneous transform components of a position equa-
tion at each time step, the equation can in eect rep-
resent a `moving target'. Because any of the trans-
joint
setpoint
stream
forms in the position equation chain can change, very
complicated motions can be generated as the `sum' of
Robot simpler ones. This is a big advantage of dening mo-
tion using position equations.
Figure 2: ARCL task structure. Threads of execution In fact four types of transform are supported: con-
are shown by dashed lines stant which may be pre-multiplied, variable, whose
value may change, hold whose value is frozen at the
A instant the motion is requested, and functionally de-
ned whose value can be modied by a function bound
to the transform.
B1 In our example, all the Trans objects were con-
stants. To obtain functionally dened motion, we
B
construct weave using new trans():
weave = new_trans(
B2 "WEAVE", FNDEF, weave_func
);
C
and elsewhere in the program,
Figure 3: Motion Segment Transitions
#define WEAVE_AMP 10.0 /* mm */
#define WEAVE_FREQ 2.0 /* Hz */
The trajectory generator is the heart of any robot
system. ARCL's trajectory generator is a separate, void weave_func(Trans *weave, Motion *m)
concurrent task to the user program task, and runs {
in real-time. Its link from the user program task is double theta;
the motion queue, illustrated in Figure 2.
Each cycle the trajectory generator solves the po- theta = TwoPI * (ami_treal() - m->t0)
sition equation for the target T6 , then interpolates * WEAVE_FREQ/1000.0;
the present value of T6 towards that solution. Ro- weave->t_p.x = WEAVE_AMP * sin(theta);
tational interpolation is performed using quaternion }
arithmetic. Then, the inverse kinematic function (see
Section 3.1) is applied to the interpolated T6 to give After move() is called with a position equation
the corresponding joint angle vector  . This set-point involving weave, the trajectory generator will call
vector is communicated to the robot servo system weave func() every cycle as it evaluates and solves
using the machine interface (Section 3.2) as the sub- the position equation. weave func() sets the px com-
target for the next trajectory generator period. ponent of the weave transform to a sinusoid of time.
The robot's motion thus has a low frequency weave
imposed on it, of the kind sometimes used in robotic 2.7 Synchronisation and
arc welding. Workspace Arbitration
Functionally dened transforms need not be sim-
ply computed functions of time, but can depend on Both the event passing mechanism and the semaphore
sensory data read in real-time. This provides a pow- library are used in the following fragment, for man-
erful means of integrating external trajectory modi- aging two manipulators with a shared work area:
cation with planned robot motion.
ROBOT *rp1, *rp2;
An example of this kind of system is one where a .
robot manipulates objects on a moving conveyor belt. .
The transform function reads an encoder rotated by move(rp1, pWS,
the belt and connected to the robot controller, to MOV_NOTIFY, excl_proc,
compute a transform representing the conveyor posi- NULL);
tion. Provided this transform is included in all the
position equations, the manipulation task can be han- excl_proc(event, rp)
dled as if the belt was still. Event event;
The paper [4] analysed the closed loop response ROBOT *rp;
of a system incorporating ARCL functionally dened {
transforms. Naturally the performance of these sys- static ROBOT *who_is_in;
tems is dependent on the power of the controller com-
puter and the servo hardware update rate. switch (event) {
case EVENT_DEQ:
if (sem_take(sem_excl) == OK) {
2.6 Synchronisation and who_is_in = rp;
Event Handling return OK;
} else
Since the robot program runs `ahead' of the real-time return MOVE_STOP;
trajectory generator task, there needs to be some way case EVENT_DONE:
of synchronising the two when required. ARCL pro- if (rp == who_is_in) {
vides several means of doing this. The simplest in- sem_give(sem_excl);
volves adding the MOV SYNC attribute to the move() who_is_in = NULL;
call, which makes move() not return until the move }
is nearly complete. return OK;
}
Alternatively, the trajectory generator can be made }
to call a user-supplied function when a move segment
is complete; the function pointer is passed with the To simplify the application logic the call-back func-
MOV DONEPROC attribute. The function might signal
completion through some other method, or maybe op-
erate some ancillary equipment. Alternatively,
MOV NOTIFY can be used to have a user-supplied func-
tion called for a wider variety of events.
To aid synchronisation, ARCL provides a binary
semaphore facility, usually based on the underlying
real-time operating system's native synchronisation
primitives. The user program may construct, set,
clear and pend on objects of Semaphore type.
Errors are a kind of event. ARCL has a central er-
ror handler function called when exception conditions
are detected, including joint limits and kinematic sin-
gularities. The error handler can call a user-supplied
function, which may choose to continue operation, or
have the system brought to an orderly halt.
tion excl proc() is specied when either arm at-
tempts to move into the shared area. Before the move
is actually commenced the function is called with the
argument MOVE DEQ which will attempt to take the
semaphore protecting the work area resource. If suc-
cessful the identity of the semaphore holder is saved.
If unsuccessful, the return value of MOVE STOP causes
the trajectory generator to re-execute the last motion
request and try again.
2.8 Interaction with other Equipment
A robot is not useful in isolation, and must sense and
control ancillary equipment. The most common such
device is a robot gripper, and ARCL provides the
gripper() function to control it. gripper() accepts
a ROBOT pointer and at least a gripper command code:
This method of registering call-back `notier' func-
tions and event-passing by function call is commonly gripper(rp, GRIP_OPEN);
used in graphical user interface programming. gripper(rp, GRIP_CLOSE);
Robot grippers vary widely, but all open and close.
More complicated grippers take additional arguments User Application Program
such as:

ARCL Kinematic
Interface Library
gripper(rp, GRIP_CLOSE_BY, 40.0); ARCL
Application Interface
Library
Robot controllers are often equipped with binary AAI
IO systems often operating at 24VDC. ARCL pro-

AKI
vides for this using IO descriptors, type IOD. IODs
represent one or more contiguous IO bits, either input
ARCL Machine Interface
Library
or output. A similar arrangement exist for analogue AMI
input and output.
Operating System

2.9 Interaction with the Operator

Robots also often have `teach pendants' that can be
used by the operator to manually move the robot
to some position. ARCL provides for teaching with
the teach() function. teach() is a special form of
move() which places the robot under the control of
its teach pendant. When the operator presses the
LEARN or ENTER button, a user-supplied call-back
function is called, with the current robot T6 transform Figure 4: Structure of the ARCL Library
as a parameter, which can be stored for later use.
As an adjunct to the teaching function and the ho- ARCL adopts a similar solution, by using a struc-
mogeneous transform library, ARCL provides a trans- ture consisting of a core module, the ARCL Appli-
form symbol table facility. This allows transforms to cation Interface Library (AAI) and two replaceable
be stored and retrieved by the name key. The sym- device-dependent libraries, the ARCL Kinematic In-
bol table can be dumped or loaded from a disk le.
This permits ARCL programs to emulate the teach-
record-replay style of robot controller if desired.
2.10 Finishing Up
terface and the ARCL Machine Interface. See Fig-
ure 4.
The core AAI library consists of the robot program
interface functions examined in the previous section,
and the trajectory generator and motion queue code.
That completes our examination of the ARCL pro-
gram interface. The last thing to be done in an ARCL
robot program is to close all the open manipulators:
arcl_close(rp);
} libraries and run on a Puma, and then re-linked for
The next section will examine the internal structure
of ARCL.
3 The Structure of ARCL
The AKI library contains all functions specic to the
kinematics of the manipulator. The AMI library con-
tains all functions that involve the computer operat-
ing system and the interface to the robot's servos and
sensors. In principle, a robot program can by linked
with a Unimation Puma version of the AKI and AMI
use on, say, an ASEA manipulator.
3.1 The ARCL Kinematic Interface
Every kinematically distinct manipulator must have
an AKI library to be used by ARCL. The AKI has
two major tasks:
A major benet of using most graphics software li-
braries is that a device-independent interface is pre- The Forward Kinematic Solution For an n-link
sented to the applications programmer. Low level manipulator, given the joint angle vector  and
hardware specic details are encoded in particular de- the geometric link parameters, compute the po-
vice `drivers'. There is also considerable benet for a sition and orientation of the end-eector with
robot programmer in being able to express an appli- respect to the reference coordinate frame as a
cation in a manner that is independent of the actual homogeneous transform (T6 ).
computing hardware and manipulator being used.
The Inverse Kinematic Solution Given the geo-
metric link parameters and the desired end-eector
position and orientation expressed as a homo-
geneous transform (T6 ), compute the required
joint angles  .
Additionally the AKI may implement other kinematic
functions required by ARCL for special purposes, such
as the manipulator Jacobian matrix and its inverse.
The AKI is used repeatedly by the trajectory gen-
erator, to convert the T6 transform to the robot joint
angle vector. The inverse solution is therefore exer-
cised heavily, and an ecient implementation is re-
quired; algebraic rather than iterative solutions are
preferred. The ability to store substantial kinematic
state assists the kinematic solutions for manipulators
which are redundant or have no closed-form solu-
 the manipulator teach server function
 the real-time clock
 the ARCL semaphore library
 the ARCL event logging facility
 the ARCL diagnostic data stream
The most critical functions relate to operation of
the trajectory generator and transfer of position set-
points to the servos. The AMI must create an inde-
pendent thread of execution (or an illusion of one) for
the trajectory generator, and arrange for it to be run
periodically. In a circular way, the trajectory gener-
ator will call AMI functions to deliver set-points to
the servos.
The AMI will most probably employ the services
of a real-time operating system to create the neces-
sary threads; shared-memory style systems are pre-
ferred as there is data shared between the AAI, AKI
tion. Multiple solutions are handled by a congu- and AMI. However, ARCL systems have run on `bare
ration word which uses bits or bit-elds to represent hardware' using timer interrupts to call the trajectory
the required solution, for example, the left hand/right generator.
hand conguration of a Puma 560.
The AKI works entirely with manipulator joint an-
gles or displacements in real-world units such as mil-
limetres or radians. It does not deal with the actuator
positions or units, which is in the domain of the AMI.
The AKI routines are provided to be called implic-
This principal dependance of the AMI is gener-
ally on the operating system and secondarily on the
manipulator type. The MS-DOS/CTask AMI (see
below) was designed to support a number of dier-
ent manipulator types simultaneously. AMI libraries
may dier considerably internally, but all conform to
itly by the ARCL library, in particular the real-time
trajectory generator function. However, the routines
are general purpose and make no assumption about
the rest of ARCL being present.
3.2 The ARCL Machine Interface
The role of the AMI is to incorporate all code that
is operating system, computer architecture and robot
a well dened software interface specication.
3.3 Portability
All ARCL code is in ANSI C and portable to any ar-
chitecture providing an ANSI-compatible compiler.
ARCL has run on National 32016, DEC VAX, Mo-
torola 680x0, Intel 80x86 and Sun SPARC machines.
AKI libraries have been written for the Unimation
interface specic. In the same way as the AKI library,
a dierent AMI is required for each distinct operating
system/robot controller combination.
All of ARCL's communicationwith the robot hard-
ware and operating system is routed through the AMI.
In fact an AMI library may be used to operate a robot
quite independently from ARCL, or may serve as a
low-level manipulator interface for some other high-
level robot programming system.
Puma 560, ASEA 3000, Machine Dynamics/Farley
Journeyman and Microbot MIM-5 manipulators.
AMI libraries exist for the following combinations:
vxWorks/Unimate Puma 560 This suits a 68030
processor on a VME card, the real-time operat-
ing system vxWorks[15] and the Unimate Puma
560 servos. The processor controls the servos
using a custom interface.
The specic responsibilities of the AMI include:
 mapping manipulator joint angle vector
to actual motor position
 delivering the mapped motor position com-
mands to the robot servos
 controlling the gripper and ancillary IO
lines
 providing the periodic thread of execution
for the trajectory generator
vxWorks/Journeyman This suits a 68030 proces-
sor on a VME card, the real-time operating sys-
tem vxWorks and Farley/MD axis controllers
on a Journeyman robot. This implementation
uses software position control loops within the
AMI.
ARTS/Unimate Puma 560 The ARCL Real Time
System (ARTS) is a simple monitor that has
 control of the manipulator, which it temporar-
ily cedes to application programs upon request.
ARTS utilises vxWorks and provides an AMI
interface.
MS-DOS/CTask/MIM-5 This is designed for PC-
style machines and uses the CTask[14] library
to provide the real-time multi-tasking environ-
ment. This AMI generates stepper motor mo-
tion pulses in software for the MIM-5 educa-
tional robot.
O-Line While a Unix process and MS-DOS do not
oer multi-tasking, an illusion of it to allow
ARCL applications to be run o-line is provided
by this AMI. Motion information may only be
written to a le or piped to post processors for
analysis and display, described in the next sec-
tion.
Most combinations of AKI and AMI libraries are pos-
sible but many are not practical.
ARCL's very general approach to robot control
placed heavy demands on the computing system, and
in the early days of development (1984) the emerging
32-bit microprocessor technology was pressed to its
limit. More modern platforms have however vindi-
cated the approach and provide powerful and general
robot control systems.
Figure 6: X-windows robot animation
4 Running Programs O-Line the event. Binary format is used to reduce the vol-
By linking ARCL applications with the o-line ume of data. The stream consists of a sequence of
AMI library, programs can be developed without the doubly-linked headers each of which is followed by a
need for a robot. The o-line AMI generates a bi- variable-length data structure. The rst record con-
nary data stream containing all the trajectory, grip- tains a `magic number' to identify the le type, and
per, and IO requests that would normally have been contains the name of the manipulator, its kinematic
sent to the robot servo system, and directs it into a structure, and the name of the application program.
le. This AMI can run in a single-threaded environ-
ment, such as a single Unix process, or on MS-DOS.
Later, the program can be re-compiled or re-linked
with a real-time AMI to run on a real manipulator.
For debugging, command line switches (those for
The utility unstream provides a human readable
version of the stream data, with interpretation of the
common record types. The utility jtraj extracts
joint angle records and displays this data in tabular
form, which is useful for plotting. ctraj performs a
ARCL are prexed by +) can enable the printing of
position equations and transforms as they are con-
structed by the application program (see Figure 5).
To examine the move requests as they are issued
and processed: User program motion requests from
move() or stop() functions are listed as request.
The time given is the time at which the request was
issued.
The binary data stream can be examined by a
similar function for Cartesian set-point records, dis-
played in a variety of formats.
Trajectory data may be piped into a rigid-body
dynamic simulator to compute joint torques, or im-
ported into CACSD software such as MATLAB[10]
to exercise models of robot control algorithms.
A graphical simulator, Figure 6, provides an X-
windows wire-frame animation based on a graphical
model of the manipulator, selected on the basis of
range of tools. Axis set-points, ancillary IO requests, the robot type information in the rst record of the
and other data can be replayed and analyzed after ARCL data stream. Model les currently exist for
the Unimation Puma 560 and the Microbot MIM-5.
 % prog
ami_offl: done at t=272.048

% prog +tr
base : x:0.000 y:0.000 z:862.000 RPY r:0.000 p:-0.000 y:0.000
tool : x:0.000 y:0.000 z:170.000 RPY r:0.000 p:-0.000 y:0.000
p : x:500.000 y:600.000 z:800.000 RPY r:0.000 p:30.000 y:0.000
ami_offl: done at t=272.048

% prog +m
request PARK: t=0, traj=1, Ta=100, Tseg=300, Vt=0, Vr=0
request pos: t=0, traj=1, Ta=100, Tseg=0, Vt=10, Vr=10
request PARK: t=0, traj=1, Ta=100, Tseg=0, Vt=10, Vr=10, conf=run
exec(stdtg) PARK: t=0.00, stat=0, j Ta1=112, Ta2=112, Tseg=280, dT=56
exec(stdtg) pos: t=0.34, stat=0, j Ta1=112, Ta2=112, Tseg=0, dT=56
exec(stdtg) PARK: t= 136.19, stat=0, j Ta1=112, Ta2=112, Tseg=0, dT=56
request STOP: t=272048, traj=1, Ta=100, Tseg=300, Vt=10, Vr=10
ami_offl: done at t=272.048

Figure 5: Examples of o-line diagnostic output

5 Other Languages package has been proven on a range of diverse ar-

chitectures and operating systems as well as dierent
For some applications, a robot programminglanguage manipulator types. Applications can be prototyped
may be preferred to the library approach. Such ap- and de-bugged using the o-line tools developed.
plications might include development and testing of a
large application, or teaching. The transition from li-
brary to language is relatively straightforward. Once References
the syntax and semantics of a robot programming
language are dened, a compiler or interpreter can be
written. This task is considerably eased by the use
of the Unix compiler generation tools lex and yacc.
With the addition of symbol table routines to handle
variables, the rest of the functionality is handled by
the ARCL libraries.
As an exercise, a version of VAL-II[12] was writ-
ten which provided most of the functionality of the
monitor and interpreter. This required 230 lines of
lex code for the lexical analyser, 360 lines of yacc
code for the syntax, and 2700 lines of C code for the
semantics.
6 Conclusion
ARCL is a powerful library for controlling the mo-
tion of robots, and permits the programmer to use C
and other application libraries. It allows the user to
represent the world and the manipulator in terms of
homogeneous transforms, and to solve equations of
transforms at run-time. This general facility allows
sensor-based control and has been used in research
projects into robotic deburring and visual servoing.
A major design aim has been portability. The
[1] C. Blume and W. Jakob. Pasro: Pascal for
Robots. Springer-Verlag, 1985.
[2] P. I. Corke, M. V. Roberts, R. J. Kirkham, and
M. C. Good. Force controlled robotic debur-
ring. In Proc. ISIR. Australian Robot Associ-
ation, November 1988.
[3] P.I. Corke and M.C. Good. Dynamic eects in
high-performance visual servoing. In Proc. IEEE
Int.Conf. Robotics and Automation, pages 1838{
1843, Nice, 1992.
[4] P.I. Corke and R.P. Paul. Video-rate visual ser-
voing for robots. In V. Hayward and O. Khatib,
editors, Experimental Robotics 1, volume 139 of
Lecture Notes in Control and Information Sci-
ences, pages 429{451. Springer-Verlag, 1989.
[5] V. Hayward and R. P. Paul. Robot manipulator
control under unix - RCCL: a Robot Control C
Library. International Journal of Robotics Re-
search, 5 No.4:94{111, 1986.
[6] R. Hocken and G. Morris. An overview of o-
line robot programminglanguages. Annals of the
CIRP, 135:495{503, February 1986.
[7] B. W. Kernighan and D. M. Ritchie. The C
Programming Language. Prentice Hall, 1978.
 [8] J.C. Latombe, C. Laugier, J.M. Lefebvre, and
E. Mazer. The LM robot programming sys-
tem. In International Symposium on Robotics
Research, pages 377{391, 1984.
[9] John Lloyd. Implementation of a robot control
development environment. Master's thesis, Mc
Gill University, December 1985.
[10] The MathWorks, Inc., 24 Prime Park Way, Nat-
ick, MA 01760. Matlab User's Guide, January
1990.
[11] R. P. Paul. Robot Manipulators: Mathematics,
Programming, and Control. MIT Press, Cam-
bridge, Massachusetts, 1981.
[12] B.E. Shimano, C.C. Geschke, and C.H. Spalding.
VAL-II: a new robobt control system for auto-
matic manufacturing. In Proc. IEEE Int.Conf.
Robotics and Automation, 1984.
[13] Unimation Inc. User's Guide to VAL, Version
11, 1979.
[14] T. Wagner. Ctask { a Multitasking Kernel for C,
volume 2.2. Ferrari Electronic GmbH, Beussel-
strasse 27, D-1000 Berlin 21, Germany, October
1990.
[15] Wind River Systems, Inc., 1351 Ocean Avenue,
Emeryville CA 94608. Vxworks 4.00 Volume 1:
User Manual, 1988.