Roboacs & Computer-Integrated Manu[acturmg, Vol 5, No 1, pp 11-19, 1989 0736-5845/8953 00 + 0 00

Pnnted m Great Britain Pergamon Press plc

• Paper

VML: AN INTERMEDIATE LANGUAGE FOR ROBOT PROGRAMMING

PAOLO BISON,* ENRICO PAGELLO*t and G A E T A N O T R A I N I T O *

*LADSEB, Institute of CNR (National Research Council of Italy), Corso Stati Uniti 4, Padova 35020, Italy
and tlnstitute of Electrical and Electronic Engineering, University of Padua, Via Gradenlgo 6/a,
35100 Padova, Italy

VML (Virtual Machine Language) is an intermediate level programming language for manipulators which
allows structured programming, concurrency, built-in robot-specific data types and a certain degree of robot
independence. VML can be used both as an interactive command language and as a target language for advanced
high-level robotics software systems. Its definition involves a number of design choices which portray an abstract
view of the robot as one of several components in the automated factory.

1. I N T R O D U C T I O N paper. I4 According to these principles, a software

Flexible programmability gives industrial robots
their main advantage over traditional automation.
The d e v e l o p m e n t of good quality software systems is
therefore the key factor for robot system integration
into CIM. At L A D S E B , an Institute of C N R in
Padua, we have i m p l e m e n t e d V M L (Virtual Machine
Language), a structured intermediate level language
for manipulators, to act both as a c o m m a n d language
for mechanical assembly and as a target language for
advanced high level software systems for a u t o m a t e d
assembly.
V M L is a real-time concurrent p r o g r a m m i n g lan-
guage for actuator and m o t o r control; it allows I/O
communication between the manipulator and the
h u m a n o p e r a t o r and also offers primitives for defin-
ing and handling vectors, rotations and frame data
types.
A portable interpreter for V M L has been written
in Pascal; 1 it has been tested in controlling both the
Supersigma R o b o t at Milan Polytechnic and the
P u m a manipulators at Milan Polytechnic and the
L A D S E B Institute of CNR. This p a p e r describes the
full definition of V M L and gives some imple-
mentation details.
We based our first experimental implementation 1
on the design principles outlined in a previous
system for a u t o m a t e d mechanical assembly should
consist of a multilevel software structure distributed
over a multiprocessor architecture. V M L has been
used as a software c o m p o n e n t in a strictly hier-
archical hardware structure to control the Super-
sigma R o b o t at Milan Polytechnic s (see Fig. 1),
where it has been used as an alternative to the
previous M A L language. 13 V M L has also been used
as the core interpreter controlling a Puma; 2 in this
application V M L is able to communicate with V A L ,
the P u m a p r o g r a m m i n g language (see Fig. 2).
The Italian partners in the Esprit Research Pro-
ject No. 623 (Operational Control of R o b o t System
Integration into CIM: System Planning, Implicit and
Explicit Programming 2s) are considering the possi-
bility of using VML, or a revised version of it, as the
Italian national tool for interfacing with the Explicit
Programming System (which will be developed by
this project).
At present we look at V M L as a tool belonging to
a more general distributed software system for
automatic mechanical assembly. Such a system,
based on a message-passing p r o g r a m m i n g environ-
ment, is under development at L A D S E B on a distri-
buted hardware structure. 2° It uses V M L as a target
robot c o m m a n d language.

Acknowledgements--This project has been supported
by CNR and by the MPI (Ministry of Public Education)
through the "Progetto dl Ricerca sulle Metodologle
Elettronlche, Informatlche e Sistemistiche in Robotica".
The following people have also contributed to the design
and implementation of VML: R. Casslnis and G. Glni of
Milan Polytechnic, M. Glnl of the University of Minnesota
and several students of the E.E. Dept. of Padua Univer-
sity, among whom we particularly remember G. Chemello,
F. Ropelato, F. Rodlghiero and A. Tosetto.

11
12 Robotics & Computer-Integrated Manufacturing • Volume 5, Number 1, 1989
i[nter'face
I In addition, the robot is progressively viewed as
Fig. 1. Control system for the Ohvettl Superslgma robot.
[~ Sensors
Puma5 6 0 f ~ Macintosh
D -~ VME
VAX11/750
WarRstat ion
Fig. 2. Configuration of the LADSEB Robotics Laboratory
In both the first case (master-slave architecture)
and the second (distributed architecture), VML
must be integrated into a more general structure
with which it communicates. It is possible however
to utilize VML as a stand-alone software system. We
have proposed a small graphic operating environ-
ment with a real-time single-step interpretation
mode for executing VML programs interactively.
2. DESIGN ISSUES FOR VML
In the following, we will review the design criteria
which led to VML as an intermediate level portable
and modular language.
2.1. Robot programming logical levels
Robot programming has evolved considerably
since the early programming languages for robotics.
First of all, many existing robot programming lan-
guages are not accepted by the average user as the
only means of interaction with the robot. Unless a
programming environment already provides the
programming language, the user tends to restrict
himself to teach-by-showing techniques, thereby
reducing the role the robot language to just that of
one of several powerful interactive tools.
just one component of an integrated set of machines
cooperating towards a common task within the
automated factory. Therefore, the robot control lan-
guage is expected to interact with several other
software modules with several levels of abstraction
through which the whole manufacturing cell (or
combination of cells) is modelled.
Both observations imply a strong demand for:
• machine independence, i.e. high flexibility and
configurability of the control language with
respect to the computing environment
• robot independence, i.e. adaptability to a variety
of different robots.
These criteria entail a clear identification and
separation of logical levels. As an initial approxi-
mation for the purposes of this paper, we distinguish
the following three levels of abstraction:
1. a lower level, which includes the hardware of the
robot(s), low level sensors and associated compu-
ter(s) plus general purpose software
2. an intermediate level consisting of a minimal set
of robotic functions
3. a higher level which views the robot system only
through its abstract representation in level 2, and
which deals with high level sensory processing
and assembly planning.
In our view the intermediate level language is a
key component of the overall system. Careful design
of its structure can play an important role in achiev-
ing the goals mentioned above.
2.2. Intermediate level language definition crtterla
Choosing the appropriate level of abstraction for
the intermediate language (IL) involves making
compromises on several conflicting needs:
• generality vs. specificity
• efficiency vs. expressiveness
• conciseness vs. accuracy of representation.
Previous experiences suggested the formulation of
the following criteria for IL:
• the virtual machine should have a simple stack-
oriented structure
• IL should support a restricted set of general pur-
pose and robotics-oriented data types
• IL should provide facilities for concurrent prog-
ramming
• IL should allow structured programming through
appropriate control structures, procedure defini-
tions and recursion
 V M L in robot p r o g r a m m i n g • P. BISON et al. 13

• IL should allow interfacing with external proce-

dures

///<JOINT
• IL should be interpreted and provide on-line I.i

interaction, simple debugging and an " u n d o " fea-

ture
• IL should be implemented in Pascal or a similar
high-level language. 1.1 )
• N,1 ~

2.3. Consideration of portability and modularity \

Portability for a robot programming language

involves two factors: computer independence and
JOINT n.m )
robot independence.
Computer independence has long been investi- Fig. 3. T h e multl-arm robot.
gated and many approaches have been proposed.
Our solution limits itself to adopting a fairly stan-
dardized high-level language like Pascal for imple-
( M A R ) - - a mechanical structure with several arms,
mentation and to encapsulating machine-specific
each consisting of several joints (see Fig. 3).
features into well-defined interchangeable modules.
Because joint behavior can be described by rota-
Robot independence is a more controversial sub-
tion and transformation parameters, we easily derive
ject. 26 We believe that a decisive contribution will
motion instructions for M A R .
come from the integration of several intelligent tools
within the programming environments (i.e. a robot move_joint (joint i), (position)
description module, a robot simulator, a knowledge move_joint rel (joint n), (position)
base on existing robot, on-line design assistance,
represents the low-level absolute or relative single-
etc.4.2°). Considering this framework, a careful
joint motion statement, which causes the ith joint to
design of the intermediate level language should
move to the position indicated.
prove advantageous.
The language depends on the individual robot in move_arm (arm k), (position)
many ways. Let us consider three limiting cases: move_ arm_ rel (arm k), (position)
1. two robots of the same model in two different
represents the higher-level instructions for absolute
operating contexts: due to calibration and
or relative motions of one arm, by which the end
environmental differences, the same language
effector of the indicated arm is moved to the position
statement can produce different effects
(frame).
2. two different robots performing similar actions:
low-level hardware differences cause the same m o v e robot
statement to produce different pieces of machine
is the motion of the M A R as a whole, which causes a
code for the two robots
concurrent synchronized motion of the individual
3. two different robots, each performing actions
arms.
physically impossible for the other: functional
and structural differences require different ling- tool((arm k), (status i))
uistic features.
is the tool activation instruction, where the status is
For example, the statement "move to frame A " is
represented by values like (ON, OFF, OPEN,
meaningful for both a Cartesian and a joint robot,
CLOSED, etc.).
although it probably translates into different
In addition, for each motion instruction one can
machine code blocks.
specify whether (a) program control should return
We have isolated a "robot kernel" including a
immediately after the motion starts, or (b) the sys-
minimal set of functionalities which we believe
tem should wait for motion completion.
applies to a wide variety of existing robots. The
Status information requests regarding the various
kernel itself should contain mechanisms to interface
components of the M A R can be issued in the follow-
with the robot-specific modules necessary to pro-
ing form:
gram a real manipulator. For example, in order to
establish a model for motion instructions, we can inquire_joint ((arm k), (joint i))
simply refer to the concept of a multi-arm robot inquire_ arm ((arm k)).
14 Robotics & Computer-Integrated Manufacturing • Volume 5, Number 1, 1989
3. OVERVIEW OF VML SOFTWARE
ARCHITECTURE
The first implementation of VML was based on
the hardware framework developed at Milan Poly-
technic for the control of the Supersigma robot.S In
this framework three levels of abstraction may be
distinguished according to the description in section
2.1:
• low level: the microarchitecture is driven by a
software system which directly handles motors,
actuators and sensors; it also implements a crash
protection facility which prevents collisions bet-
ween the arms.
• intermediate level: the target software core con-
sisting of a permanently resident real-time lan-
guage interpreter, the VML written in Pascal,
which has replaced the M A L compiler.13
• high level: an interactive programming environ-
ment for mechanical assembly.
In this way, a strictly hierarchical control struc-
ture 9 was achieved where communications between
levels were defined by suitable protocols; each phys-
ical level, both of hardware and software, corre-
sponds to a different level of abstraction of robot
functional activity. Each level has full and exclusive
control over the next lower level. The software,
which communicates with the lowest level, is
responsible for the direct control of manipulator
motors, actuators and sensors. Commands are then
sent from the higher levels to the lower levels, while
sensor information is collected from low levels to
high. In this way, asynchronous communication
occurs between the robot and the virtual machine,
and between the virtual machine and the operator.
In the trade-off of complexity and power on one
hand, versus simplicity and efficiency on the other,
the first implementation of VML was developed
with reference to this fundamental hardware control
model. Other models realize a richer functional
structure capable of more flexible behavior m sen-
sory interaction. However, we believe that this
model is still adequate for many industrial manu-
facturing applications.
The intermediate level corresponds to the real-
time command language we call the Virtual Machine
Language. VML's design is based on the following
guidelines:
• it manages both single and complex activities,
each corresponding to either a physical or an
abstract process.
• it allows I/O communication between the
operator, sensors and motors, and provides for
the exchange of error conditions.
• it offers the basic primitives for coordinating con-
current processes and for mutually exclusive
resource access.
• it is designed according to Finkel's guidelines for
abstract machine modelling ~2 to increase the
portability of the language, and realizes a type of
machine language for manipulator programming
(like the assembler for a Von Neumann compu-
ter).
• it is structured compactly and elegantly, in order
to obtain readable programs; in addition, the
interpreter allows step-by-step execution of single
processes for interactive testing and debugging.
The design of V M L sought to exploit the concurrent
programming capabilities offered by the distributed
architecture of the system. Concurrent processes can
involve the following actions:
(i) computation of expressions involving either
logic-arithmetic objects or physical values;
(ii) sequences of commands for sensors and
motors;
(iii) interruption of service routines and I/O mes-
sages.
The modular and structured architecture of the
V M L interpreter allows the user to easily add his
own coded modules to extend the original set of
robot control functions: V M L is particularly suitable
as a target for structured robot languages.6
A simple but efficient way of interrupting the
scheduler, both from the upper and from the lower
level, was implemented. Automatic crash protection
interrupts move from the low level to the interpreter
and automatic queries to the micros at the low level
are answered by VML; interrupts may come from
the high level as well, in order to break the running
process at the operator's request.
4. COMPARING VML WITH OTHER ROBOT
LANGUAGES
The task of developing reliable, structured and
portable programming languages for robot manipu-
lation of mechamcal assemblies 7 has been tackled
both by academic institutions and industrial com-
panies whose researchers have tried either to
improve existing languages at the "manipulator
level" or to develop new advanced software systems
at the "task level".
While the task level systems are still under inves-
tigation, 18 the industrial scenario at the manipulator
level is more settled. 5"15 We designed V M L to
significantly improve first generation industrial
robot languages (like Olivettl'S S I G L A 24 and
D E A ' s Help,~l later adopted by General Electric)
by offering an advanced portable tool for interfacing
a manipulator with second generation industrial
 V M L m robot p r o g r a m m i n g • P. B i s o n et al.
robot languages (like the IBM's A M L 27 and Unima-
tion's VAL-II). 25
Inspired by Stanford's A L project, 19 V M L has
been designed as the target for a wider class of robot
languages. Its design therefore represents an effort
to produce an intermediate structured target lan-
guage, not only for robot industrial languages, but
also for more advanced software systems capable of
integrating several interactive tools and a word des-
cription based on frame coordinate abstraction. 17
If we attempt to compare V M L with VAL, 25
however, we may find some similarities. First, we
have a set of equivalent instructions in both lan-
guages (i.e. some monitor instructions, some I/O
instructions and some low level program flow con-
trol). Second, some V M L instructions may find a
direct translation into a suitable set of V A L instruc-
tions and vice versa (such as relative and absolute
motion commands; robot, arm and joint position
queries; tooling operations; parking robot cali-
bration; and speed setting).
The differences between VML and V A L include
the synchronization primitives present in VML but
not in VAL, and the high level program flow control
in V A L which V M L lacks. In addition VML also
lacks certain V A L instructions useful for inter-
actively defining and storing locations, for cali-
brating and resetting various system devices, for
choosing arm configuration and making some parti-
cular movements. However, none of these specific
instructions have been considered primitive opera-
tions for the virtual machine. Moreover, VML was
designed as a stack oriented language for the pur-
poses of efficiency.
The comparison with A M L 27 is much less mean-
ingful. A M L is a new general-purpose language,
extended with the functions needed to operate
robots; its design allows subroutines to be written
and used like built-in commands, while VML acts
mainly as an intermediate language. We have
developed a macroprocessor for VML which may be
used to predefine an instruction subset to be used
later, but this facility is extraneous to the language
definition and belongs rather to the programming
environment tool set.
From the point of extendibility, it is interesting to
compare V M L with the language I R D A T A 23 which
has been designed by a committee of G e r m a n insti-
tutes as the G e r m a n target language of the Explicit
Programming System, which will be developed by
the Esprit Research Project on Operational Control
for Robot System Integration into CIM (VML
indeed is a suitable candidate as the Italian target
language in the same Esprit project). An
15
I R D A T A program is a sequence of records which
contains a certain number of arguments and which
may be classified by distinguishing descriptive ele-
ments from action elements according to the special
requirements of robot programming. V M L has quite
the same set of capabilities with regard to the des-
cription of robot features, motion specifications,
program flow control, I/O operations and data type
manipulation. VML, however, is a more structured
and readable language; it is likely that in the near
future both I R D A T A and V M L will be enhanced
and extended to include features of the next-
generation robot control language.
5. MAIN LANGUAGE FEATURES
In the following, we shall describe the main
instruction subsets of VML. The formal description
of the language can be found in the V M L User
Manual. 3 A V M L statement is composed of an
optional label, a command keyword which may be
followed by a type keyword, and a list of arguments:
(statement) ::= [(label)] : (op code) [(tag field)]
[ (operands)].
A VML program comprises two main parts: a
global data declaration and a concurrent process
declaration. The former allows the declaration of
constants, arrays of constants, global variables,
global arrays, semaphores, mailboxes and global
procedures. In contrast, each individually declared
process may have its own declaration part formed by
a label declaration, local variable and array defini-
tion and local procedure declaration.
Constants and variables can belong to the follow-
ing data types: integer, scalar (real), Boolean, geo-
metric vector, rotation, frame and character string.
Arrays may be composed of scalars, vectors, rota-
tions and frames.
Two primary tools for process synchronization are
available to the programmer: binary semaphores
and messages. Binary semaphores are accessed by
three instructions: WAIT, S I G N A L and TEST-
WAIT. The first two primitives have the usual mean-
ing, while the third tests the semaphore's state and
issues a " W A I T sem" if the semaphore is free. In
any case it returns a Boolean value which corre-
sponds to the state before the operation. Messages
are sent or received through a mailbox by two
instructions: SEND and R E C E I V E .
The control flow may be altered in two ways: by
local or external procedure calls or by conditional or
unconditional branches.
I/O instructions allow communication between
the V M L interpreter and a human operator. A set of
16 Robotics & Computer-Integrated Manufacturing • Volume 5, Number 1, 1989

primitives permits the operator to ask the interpreter CONSTANT VECTOR

to display the top of the stack, the value of a variable edge = 0,0,24 {cube size}, inc = 0 , 0 , - 1 5 1 ,
or a constant, to input a data from the console, etc. up = 0,0,198,
Most V M L commands find their arguments on the down = 0 , 0 , - 1 9 8 ;
process stack. With this in mind we have introduced CONSTANT ROTATION
stack operations to allow parameter passing both by defrot = 0,1,0/0,0,-1/-1,0,0;
reference and by value; this makes it possible to C O N S T A N T F R A M E {left and right stack
push and pop variables, constants or array addresses positions}
onto the stack, both in direct and referenced mode. lpos = 0 , 0 , 1 / 0 , 1 , 0 / - 1 , 0 , 0 / / - 2 5 0 , 6 0 0 , - 3 5 0 ,
VML also provides basic mechamsms (such as rpos = 0 , 0 , 1 / 0 , 1 , 0 / - 1 , 0 , 0 / / 2 5 0 , 6 0 0 , - 3 5 0 ;
PLUS, MINUS, INC, TIMES, DIV, NEG, INC, C O N S T A R R A Y V E C T O R {positions where the
DEC, M O D U L E , INVERSE, AND, OR, NOT, cubes are to be put}
etc.), for evaluating expressions involving the van- pos, 6 = 0 , 7 0 0 , - 3 5 0 / 0 , 6 5 0 , - 3 5 0 / 0 , 6 0 0 , - 3 5 0 /
ous data types mentioned above. 0,550,-350/0,500,-350/0,450,-350;
Moreover, a set of instructions allows the operator V A R I A B L E INT arrind {next free position in pos
to move the robot: M O V E propels a device vector};
( R O B O T , A R M or JOINT) with a given motion S E M A P H O R E mutua {mutual exclusion
type ( R E L or ABS) according to the M A R abstrac- semaphore};
tion described in section 2.3. P A R K parks the device M A I L B O X init;
whose number hes at the top of the stack, on the
absolute reference position of the working space.
The speed of the motion can be given directly as PROCESS; {left-arm process}
distance over time or, alternatwely, as motion dura-
tion.
A small set of sensory control instructions allows V A R I A B L E INT count;
the input to sensor status information and provides V A R I A B L E V E C T O R linc {displacement to reach
for the control of robot movement. the cube stack};
L A B E L loop,endpr;
5.1. Example
In the following example (see Fig. 4), a two-arm
robot moves cubes from two stacks to a line on the BEGIN;
floor. The program consists of two processes (one {initialize global and local variables}
for each arm) cooperating to perform the task. P U S H V A L U E inc; P O P V A L U E linc;
P U S H V A L U E one; P O P V A L U E arrind;
P R O G R A M concproc; P O P V A L U E count;
CONSTANT SCALAR {wake up the other process)
zero = 0, one = 1, two = 2, leftarm = 1, S E N D init;
nghtarm = 2, {set the speed and park the left arm)
close = 0, open = 1, actspd = 20 {speed value}; P U S H V A L U E actspd; P U S H V A L U E
C O N S T A N T INT leftarm;
ncubes = 6 {total cubes}, SET S P E E D ; P A R K A R M ;
lcubes = 3 {cubes in the left stack}, {move left arm over its stack with the hand
rcubes = 3 {cubes in the right stack}; open)
P U S H V A L U E open; P U S H V A L U E leftarm;
TOOL;
P U S H V A L U E lpos; P U S H V A L U E leftarm;
M O V E A R M ABS;
loop: F L U S H ;
{move the arm and take a cube)
P U S H V A L U E linc; P U S H V A L U E leftarm;
MOVE ARM REL;
P U S H V A L U E close; P U S H V A L U E leftarm;
TOOL;
Fig. 4 Two-robot system for the VML example program. {move up}
 VML in robot programming• P. BISONet al. 17

PUSH VALUE up; PUSH VALUE leftarm; guages which may allow for better
MOVE ARM REL; operator-machine interaction.
{update the displacement subtracting the cube Among the criteria which guide a reasonable
size} approach to the design of a software environment
PUSH VALUE linc; PUSH VALUE edge; for robotics, we may select the following:
MINUS; POP VALUE linc; • the coexistence and interaction of different
"loosely connected" software modules, possibly
written in different languages
WAIT mutua; {beginning of critical and region}
• these modules must provide a simulator of robot
{compute where to put the cube and move
kinematics driven by robot language motion
there}
statements
PUSH VALUE arrind; PUSHARRAY
• the programmer needs a set of primitives for
VALUE pos;
manipulating robot programs, accessmg a robot
PUSH VALUE defrot; PACK FRAME;
assembly library and storing coded utilities.
PUSH VALUE leftarm; MOVE ARM ABS;
We believe that software environments for robot
{release the cube}
programming will continue to grow in the future.
PUSH VALUE down; PUSH VALUE
Task level robot programming will be achieved by
leftarm; MOVE ARM REL;
integrating different components within a sophisti-
PUSH VALUE open; PUSH VALUE
cated distributed system rather than by defining a
leftarm; TOOL;
single complex language satisfying all possible
PUSH VALUE up; PUSH VALUE leftarm;
requirements. Previous considerations lead us to
MOVE ARM REL;
consider the manipulator-operator interfacing soft-
{move over the left cube stack}
ware system as an open system 16 in which the robot
PUSH VALUE lpos; PUSH VALUE
language mterpreter acts as one of the modules.
leftarm; MOVE ARM ABS;
Therefore, as a first step, we developed a friendly
{test if all positions in the line have a cube}
interactive environment around the present version
PUSH VALUE arrind; INC; POP VALUE
of VML interpreter. The original VML interpreter
arrind;
was written in Pascal except for a small part written
PUSH VALUE ncubes; COMPARE GT;
in Assembly which interfaces to the particular hard-
SIGNAL mutua; {end of critical region}
ware. Our scheduler implements a round-robin algo-
rithm, while dynamic memory management is based
{jump to the end if the previous test was true}
on the allocation of fixed memory areas to avoid
BRANCH COND endpr;
garbage collection.
{if there's some cube in the stack, take it}
The system layout (see Fig. 5) is composed of a
PUSH VALUE count; INC; POP VALUE
small kernel, called monitor, which provides system
count;
facilities such as clock management, scheduling and
PUSH VALUE lcubes; BRANCH LE loop;
memory allocation, plus several virtual processors
endpr:
PUSH VALUE leftarm; PARK ARM;
FLUSH;
{park the arm and clear the stack}
END;
The code for the right-arm process is exactly
symmetric to this: it contains a RECEIVE statement
corresponding to the SEND in the above code, and
all "lefthand" variables (like linc, lpos, etc.) are
changed to rightarm variables (rinc, rpos etc.).

6. THE OPERATING ENVIRONMENT J PROCESSOR j#n

While the next generation of robot programming

systems will provide for increasing integration of
sensing and motion with task planning capabilities, it
proves convenient to develop an advanced pro-
gramming environment for the existing robot lan- Fig 5. Structure of tile VML exampleprogram.
18 Robotics & Computer-Integrated Manufacturing • Volume 5, Number 1, 1989
5rBDhlc ~eoresentation in
/
/,
/
A
i /
/
/
VML I n t e r p r e t e r 2 . 0
~VML> PARK ROBOT.
Fig 6 A screen snapshot of the VML graphics envzronment under development at LADSEB
with their own private memories which communi-
cate through a c o m m o n data area.
V M L was first implemented on an earlier multi-
microprocessor structure controlling a two-arm
Olivetti manipulator at Milan Polytechnic. Simple
synchronization primitives, like W A I T / S I G N A L
and S E N D / R E C E I V E , allowed concurrent pro-
gramming over a star-structured network formed by
some Intel 8748 8-bit micros and an LSI-11.
A t L A D S E B , V M L presently runs on a distri-
buted hardware structure based on the V M E bus,
which is accessible through the graphic interactive
environment of the Macintosh.
As a second step towards the realization of an
open system, we undertook to develop a high-level
graphic environment. 10 Thus, at L A D S E B we began
by designing a kinematic simulator for P U M A , cap-
able of accepting V M L statements previously trans-
lated into V A L instructions. O u r simulator (see
Fig. 6), based on Paul's kinematic equations, 21 has
/
//
/
iF_rJ
MONITOR
TEACH BOX
WM
READY
OPEN/CLOSE
LEFTY/RIGHTY
BELOW/ABOVE
SPEED
EXIT
been implemented on a ICL-Perq graphics work-
station 4 where it can execute V M L programs.
We also plan to implement a more advanced
interactive environment for r o b o t - p r o g r a m m i n g
based on message-passing semantics 2° in the context
of the Accent Operating System, z2 where the V M L
interpreter runs as an independent module and
communicates with other tools via message
exchange. The University of Padua, in cooperation
with an Italian industrial firm, has rewritten the
V M L into source codes C language to obtain a more
efficient system and transport it into an industrial
environment.
REFERENCES
1. Bison, P., Lorenzln, G., Pagello, E.: The formal defin-
Ition of VML and a proposed portable imple-
mentation. Proceedings of the llth 1S1R, Tokyo,
October 1981. pp. 585-594.
2. Bison, P, Pagello, E., Rodighiero, F., Tramlto, G..
The development of a portable programming lan-
 VML in robot programming• P. BISONet al.
guage for manipulator control. Proceedmgs the Con-
ference on the Automatton of Industrial Processes,
Kempe, V., Menga, G. (Eds.). Tormo, Designers
Riuniti Editon 1983. pp. 221-227.
3. Bison, P., Tosetto, A.: VML-Versione 2.0: Manuale
d'uso e gulda all'implementazione. Techmcal Report
LADSEB-CNR 85-01 Padova, January 1985.
4. Bison, P., Pagello, E., Priolo, L., Zivlam, S.: Simu-
lation tools as a programming aid for robot pro-
grammmg. In Languages for Sensor-Based Control in
Robottcs, Rembold, U., Hormann, K. (Eds.). NATO
ASI Series: Computer and System Sciences, Berlin,
Springer, 1987.
5. Blume, C., Jakob, W.: Programmmg Languages for
Industrial Robots. Berlin, Springer, 1986.
6 Blume, C., Jakob, W.: Design of the structured robot
language (SRL). In Advanced Software m Robotics,
Dauthine, A., Gerardln, N. (Eds), Amsterdam,
North Holland, 1984. pp. 127-143.
7 Bonner, S. Shin, K.G.: A comparative study of robot
languages. Computer 15: 82-96, 1982.
8. Cassmls, R : An example of a distributed intelligence
discrete process controller. Dtgttal Syst. Ind. Automat.
1: 45-77, 1981
9 Cassinis, R.: Hierarchical control of integrated man-
ufacturing systems. Proceedmgs of the 13th IS1R.
Chicago, April 1983, pp 12/9-12/20.
10. Dlllmann, R.: A graphical emulation system for robot
design and program testing. Proceedmgs of the 13th
IS1R. Chicago, April 1983, pp. 7/1-7/15.
11 Donato, G., Camera, A : A high level programming
language for a new multiarm robot. Proceedings of the
1st lnternattonal Conference on Automated Assembly.
Brighton, 1980. Kempston, Bedford, IFS, 1980,
pp. 67-76
12. Fmkel, R A.: Constructing and debugging manipu-
lator programs. SAIL Memo AIM-284, Stanford
University, Stanford, 1976.
13. Gini, R., Gmse, D.: MAL: hnguaggio di program-
mazlone per robot; Descrizione generale. Technical
Report No 78-20. Department of Electronics, Milan
Polytechnic, Milan, January 1979
14. Gmi, G., Gini, M., Pagelio, E., Trainlto, G.: Distri-
buted robot programming. Proceedmgs of the l Oth
IS1R. Milan, March 1980, pp. 61-71.
15. Gruver, W A., Soroka, B I., Craig, J.J., Turner, T.L.:
19
Evaluation of commercially available robot pro-
grammlng languages, Proceedings of 13th ISIR.
Chicago, April 1983, pp. 12/58-12/68.
16. Hewltt, C.: The challenge of open systems. Byte 10:
223-242, 1985.
17. Laugier, C.: Robot programming using a high level
language and CAD facilities. In Robot Technology
Apphcattons, Rathmlll, K., MacConail, P.,
O'Leary, S., Browne, J. (Eds.). Berlin, Springer,
1985, pp. 187-199.
18. Lozano-Perez, T.: Robot programming. Proc. 1EEE
71: 821-841, 1983
19. Multaba , S., Goldman, R.: AI User's Manual. Report
No. STAN-CS-81-889, Stanford University, Stanford,
December 1981.
20. Pagello, E., Bison, P., Mlrolo, C, Penm, G., Tramlto,
G.: A message passing approach to robot pro-
grammlng. Comput. Ind. 7: 237-247, 1986.
21. Paul, R.L.: Robot Manipulators Mathematics, Prog-
ramming and Control. Cambridge, MIT Press, 1981.
22. Rashld, R.F.: Experiences in the design, implementa-
tion and use of network operating systems. Pro-
ceedmgs o f the AICA-84 Conference. Roma, October
1984, pp. 137-156.
23 Rembold, U., Blume, C., Frommherz, B.J.: The pro-
posed robot software Interfaces SRL and IRDATA.
Robotics Comput-lntegr. Mfg 2: 219-225, 1985.
24. Salmon, M.: SIGLA: the Olivetti Sigma robot pro-
gramming language. Proceedings of the 8th ISIR.
Stuttgart, May 1978, pp. 358-363.
25. Shlmano, B.E., Gesche, C.C., Spalding, C.H. III:
VAL-II: a robot programming language and control
system. In Robotics Research The First International
Symposium. Brady, M., Paul, R. (Eds.). Cambridge,
MIT Press, 1984, pp. 917-940.
26. Soroka, B.I.: What can't robot languages do? Pro-
ceedings of the 13th ISIR, Chicago, April 1983,
pp. 12/1-12/8.
27. Taylor, R.H., Summers, P.D., Meyer, J.M.: AML: a
manufacturing language. Int. J. Robottcs Res. 1:
19-41, 1982.
28. Operattonal Control for Robot System Integration mto
CIM: System Plannmg, Exphctt and Implicit Pro-
gramming. ESPRIT-CIM-5.4.2 Robot Systems Pro-
ject No. 623. Techmcal Annex. Spur, G. (Ed.). IPK,
Berlin, January 1985.