Copyright © IFAC Intelligent Manufacturing Systems,

Vienna, Austria, 1994

THE REALISTIC ROBOT SIMULATION (RRS) INTERFACE

ROLF BERNHARDT, GERHARD SCHRECK, CORNELIUS WILLNOW
Fraunhofer-Institute for Production Systems and Design Technology (IPK Berlin)
PascaistrajJe 8-9. D-J0587 Berlin. Germany
Tel. +493039006-0
Fax +49303911037

Abstrac:t. Tools for simulation and off-line programming became an important means for economic application of
industrial robots . Until now the accuracy of the simulations was not sufficiently precise for reliable down-load and
execution of the off-line generated programs. A main cause for this was the controller specific motion behaviour of the
robots that could not be simulated with sufficent accuracy. The RRS-project was created to overcome this deficite. By
defining a suitable interface, it was made possible to integrate original controller software for motion behaviour into
off-line programming systems .

Keywords. industrial robots, off-line programming. simulation. controller model. kinematic modelling

1. INTRODUcnON 3. REALIZATION OF THE PROJECf

Several industrial products are available on the The RRS-Project was started in January '92 by
market for off-line programming of industrial defining the requirements for the interface: The
robots . They provide visualizations of robotized participants agreed to concentrate on the
production cells, based on geometrical and controller software for motion behaviour and
kinematic modelling, as well as models for the kinematics. Deviations of simulations from
behaviour of the controllers involved. Until reality of less than 0.001 radians for planned
recently the modelling of robot controllers was joint values and less than 3% for cycle time have
based on default models or on models based on been desired. It was required to have several
extensive measurement of robot behaviour by the controllers of the same or different controller
vendors of the off-line programming systems. type and manufacturer running in parallel in the
Nevertheless, these efforts did not lead to same simulation. Finaly the interface had to
sufficient simulation accuracy for down-loading support data consistency of simulated and real
programs and executing them without re- controllers.
teaching.
From March '92 on, the first sketch of the
interface has been elaborated. The sketch has
2. RRS-PROJECf APPROACH been continuously enriched and improved by
feasability studies and by cross checking with the
In order to improve the situationn a consortium functionalities of the involved controllers. After
of automotive companies (Audi, BMW, Ford, more than 32 project meetings version 0.0 of the
Mercedes, Opel, P.S.A., Volvo) started the RRS-Interface Specification was available in
project Realistic Robot Simulation (RRS). The December '92.
goal of the project was to overcome the
inconvenience by defining an interface for the Implementation work on first Robot Contol
integration of original controller software into Simulation (RCS-) Modules began in January '93.
simulation systems. As technical experts they Until May '93 RCS-Modules with a dummy
involved manufacturers of robots and robot functionality have been implemented .
controllers (ABB, Comau, Fanuc, Kuka, Renault implementations including original controller
Automation, Siemens, VW), and manufacturers software have been distributed to the
of off-line programming systems (Dassault manufacturers of off-line programming systems
Systeme, Deneb, Silma, Tecnomatix). For neutral in July '93 . Complete RCS-Modules have been
project management they selected an independant available in September '93 . After alltogehter
research institute (IPK-Berlin). more than 43 projcet meetings tested integrations
of five RCS-Modules in four simulation systems
and the now verified version 1.0 of the RRS-
Interface Specification (N ,N. 1994) have been
presented in December '93.

321
 4. COMPRIZED FUNCfIONALITY requests for new targets. As long as the status
indicates 'The service is successful'.
Caused by the tight time frame of the project, the GET_NEXT_STEP returns robot positions. If
interface had to concentrate on the motion and the status indicates 'Need more data' further
kinematics software of controllers. But in order target positIons may be passed with
to be able to reasonably operate these controller SET_NEXT_TARGET. In the case of circular
parts further functionalities had to be included. motion or fly-by motion GET _NEXT_STEP
This concerns e .g. machine data, tracking, may return 'Need more data' several times. If no
condition handling and message reporting. further target positions are supplied .
GET_NEXT _STEP may continue to return
Furthermore the interface had to be uniform for interpolated positions. If the last supplied target
all controllers, but had to cover the wide range is reached GET_NEXT_STEP returns in the
of different concepts for motion handling , status 'Final step'.
parameterization and performance, while beeing
handable and easy to survey. In the result, the
interface provides a set of principal services. 4 2 Further Services
Without these services no reasonable operation of
an RCS-Module is possible. In addition, several
groups of further services are defined, from Machine Data. for machine data handling
which services relevant for a specific controller services for reading and modifying single
can be selected. Currently the RRS-Interface machine data are provided. The service for
provides all together 57 services. reading machine data may also be used for
generating a list of all accessible machine data.

4 I The Principal Services In order to maintain data consistency of real and

simulated controllers after modification of
The RRS-Interface supports the simulation of any machine data, services for loading and saving of
number of robot controllers by one RCS-Module. machine data are provided.
An instance of a robot controller is generated by
the service INITIALIZE (fig.l). INITIALIZE
returns a unique identifier for this instance. The Kinematics and Conversion . As a base
identifier has to be passed to each further call of functionality, services for inverse and forward
a service for this instance . The service tranformations are provided. Some controllers
TERMINATE ends the beeing of an instance, the contain extensive internal kinematic cell models
identifier is then unvalid. that may be read and modifyed by services.
Strongly related to the cell modelling is a servce
for selecting object and tool coordinate systems.
INITIALIZE
In order to support the simulation systems in
SET_INITIAL_POSITION displaying controller specific string
r------, •
representations of robot positions to the user,
SET_NEXT_TARGET services for conversion of positions to strings and

G-N':ufp 1 TERMINATE
vice versa are provided.

Motion Modification, For modification of the

default motion, services are provided for
specification of motion type (e.g. ptp, lin), target
type (absolute, serveral kinds of relative motion),
Fig. I : The Principal Services
interpolator look-ahead, position override and
several further purposes.
After INITIALIZE the position of the robot is
still undefined. The service
SET INITIAL POSITION sets the robot
Motion Parameterization With this group of
position, thereby defining the first starting
services speeds, accelerations, time and several
position for interpolation. From now on target
positions for motion can be passed to the instance overrides may be specified.
by the service SET_NEXT_TARGET .
Subsequently the interpolated intermediate
Fly-By and Point Accuracy. The large number of
positions may be sampled by the service
concepts for fly-by required a general, open
GET_NEXT_STEP.
system of services. As a general operation, fly-by
GET NEXT STEP also returns control may be switched on and off. Furthermore several
info~ation to the simulation system. This criteria may be selected or canceled and a
concerns error and informational messages, controller specific number of parameters may be
occured events and a status that controls e.g. set.

322
The concept for point accuracy required selection (MVS. Unix. VM. VMS. special developments)
and parameterization of several accuracy types . and on a variety of different harware platforms
(DEC. Hewlet Packard. IBM. Intel. Motorola.
Siclicon Graphics. SUN). Beyond these
Trackjn2 . For the treatment of tracking one ponability requirements the interface had to cope
service is provided for selecting tracking on up with the problem of partial implementation (not
to 32 joints . The actual values of the joints are all controllers require all services ) and the
passed to the RCS-Module by a second service. interface had to be expandable . Both. the
ponability and the compatibility requirements led
to the development of the RRS-Calling
Condjtion Handlin2. Two kinds of conditions are Conventions.
distinguished in the RRS-Interface : Events.
generated by the motion system of the controller The basic concept of the RRS-Calling
and conditions that come from outside of the Conventions is to supply only one address per
motion system. but influence its behaviour. RCS-Module as a main entry point. This entry
point is an ANSI-C function with two pointers as
Events may be defined dependent on motion parameters. Such a function can be called and
time. motion progress and robot position. The provided by most programming languages. The
conditions for the events are evaluated during first parameter points to a data block for input
GET _NEXT _STEP . Afterwards further parameters and the second one points to a data
information about the events may be querried. block for output parameters. Each of the blocks
starts with a header containing information for
In order to influence running motions. services data security. The header of the input block
are defined for stopping. continuing and additionally contains an opcode that selects the
canceling motions. called service.

The header of the input and output blocks are

Messa2es Messages generated by the original followed by the input and ouput parameters of
controller software included in an RCS-Module the selected service. For the parameters the
should be reported to the off-line progammer. format of elementary data types and rules for
The occurance of messages is reported by all data compositon are specified . The first
services that may lead to messages. The message parameter in the output block is - by convention -
text as displayed on the controller may be allways an integer called 'Status ' (see
obtained by the message service. GET _NEXT_STEP). Status is returned by all
services in order to report information about the
success of a service. In the case of partial
Weavin2 . The weaving concept is organized implementation of the RRS -Inteface or older
similar to the concept for fly-by . Weaving may versions, RCS-Modules may report 'Service not
be switched on or off. groups of weaving supported'.
parameters may be selected or canceled and each
of the parameters may be set. The RRS-Calling Conventions have been
developed and thoroughly tested during the first
year of the project and proved to be robust and
Special Services. For debugging of RCS-Modules stable during the second year. They form the
during putting into operation. a special service is heart of the RRS-Interface and allow to couple
provided. It allows to select information and any RCS-Module with any off-line programming
services for debugging. system (fig. 2).
A special service is defined for temporarily
providing actually non specified services . CAR-Tool CAR-Tool
Knowing that this 'back-door' may lead to by- inC in Fortran
passing the standardized parts of the RRS-
Interface. the participants of the project agreed to
indruce this service for temporarily solve
interface problems currently not covered by the
I Adaption I r Adaption I
RR5-lnterface
standard.

5. INTEGRA nON CONCEPT

r Adaption I r Adaption l'
The integration concept of RRS had to address Original Controller Original Controller
the fact that the different programming systems Code Code
as well as the controller software are wrinen in in Pascal in C
several programming languages (C. Fortran.
Pascal). run on different operating systems Fig.2: The Integration Concept

323
 6. RESULTS 9. REFERENCES

After two years of intensive specificaton and N.N. (1994) RRS-Interface Specification,
implementation the concept of RRS proves to be (Version 1.0), distributed via IPK-Berlin
extremely successful\. It was possible to easily
integrate the five developed RCS-Modules into
the four off-line programming systems of the
participants. Up to nine different robots of four
different manufacturers have operated in parallel
with satisfying response time. The desired
simulation accuracy of 0.001 radians for joint
values and 3% for cycle time was achieved in all
cases and surpassed to up to 0.00005 radians and
I % cycle time. Today RCS-Modules are in
industrial application.

7. THE FUTURE

For the future the obtained success has to be

maintained and extended. The RRS-Interface
Specification has to grow with future extensions
of the controllers in order to follow the state of
the art. The defered requirement for inclusion of
the language/interpreter system into RCS-
Modules remains an important issue. For this
purpose the project team will be in the future
responsible for the maintenance of the RRS-
Interface Specification and maintenance meetings
including further companies will be held. The
IPK-Berlin will stay available for contacts and
for distribution of the RRS-Interface
Specification.

8. CONCLUSION

The RRS project leads to a dramatic

improvement in simulation accuracy in off-line
programming systems for industrial robots. The
project approach is based on a cooperation of
robot manufacturers and off-line programming
system suppliers. It was initiated and driven by
the users of robotic systems in the automotive
industry.

By a commonly defined interface, the RRS-

Interface, simulation modules provided by robot
manufacturers (so called RCS-Modules) can be
integrated in simulation systems. The technical
goals defined by the users were reached in the
given time frame of two years. The RRS-
Interface has been implemented in off-line
programming systems available on the market
and first RCS-modules are integrated and in
industrial application.

The RRS-Interface Specification is maintained by

the RRS-Consortium and distributed via the IPK
Berlin.

324