On reverse-engineering the KUKA Robot Language

Henrik Mühe, Andreas Angerer, Alwin Hoffmann, and Wolfgang Reif

Abstract— Most commercial manufacturers of industrial potentially dangerous operations such as direct memory
robots require their robots to be programmed in a proprietary access. However, a major drawback of these languages is the
language tailored to the domain – a typical domain-specific lack of extensibility. They are tailored to the underlying con-
language (DSL). However, these languages oftentimes suffer
from shortcomings such as controller-specific design, limited troller and, as a consequence, only offer a fixed, controller-
expressiveness and a lack of extensibility. For that reason, we specific set of instructions. Due to this design, even robot
developed the extensible Robotics API for programming indus- manufacturers have difficulties extending these languages
arXiv:1009.5004v1 [cs.RO] 25 Sep 2010

trial robots on top of a general-purpose language. Although be- with new instructions or adapting them to novel, challenging
ing a very flexible approach to programming industrial robots, requirements such as the synchronization of cooperating
a fully-fledged language can be too complex for simple tasks.
Additionally, legacy support for code written in the original robots or the tight integration of sensor-guided motions.
DSL has to be maintained. For these reasons, we present a For that reason, we have developed a novel software
lightweight implementation of a typical robotic DSL, the KUKA architecture [2] for programming industrial robots in the
Robot Language (KRL), on top of our Robotics API. This work research project SoftRobot. Its core part is the Robotics API
deals with the challenges in reverse-engineering the language which represents an extensible object-oriented framework
and mapping its specifics to the Robotics API. We introduce
two different approaches of interpreting and executing KRL for robotic applications (available in Java and C#). Similar
programs: tree-based and bytecode-based interpretation. to robotic DSLs, the Robotics API offers an abstraction
from real-time programming facilitating the development
I. I NTRODUCTION of robotic software. With a general-purpose programming
For programming industrial robots, Biggs and MacDonald language and a robotic-specific application programming
distinguish between two major principles: automatic and interface (API), rapid development of domain-specific lan-
manual programming [1]. While automatic programming guages for industrial robots is possible. In contrast to exist-
often uses programming-by-demonstration, manual program- ing robotics programming languages, we intend to develop
ming is by far the most common technique; the developer lightweight DSLs, that is, languages which are implemented
has to explicitly specify the desired behavior of the robot using well-defined interfaces and without other dependencies
in a machine-readable syntax, usually using a formal text- on the underlying robot system. As a proof-of-concept, we
based or graphical language. Hence, a straightforward idea decided to reverse-engineer the KUKA Robot Language
is to program the robot directly using a general-purpose (KRL) and implement it on top of our architecture. We
programming language. This approach has the major dis- have chosen KRL to show that we can achieve a similar
advantage that the developer is responsible for developing expressiveness as classical robot programming languages
code which satisfies all necessary real-time constraints of and simulate their execution semantics. Moreover, we can
the robot controller. Any errors in the code may not only execute legacy code written in KRL this way and thus
lead to a failure of the program itself, but to severe damages maintain a certain degree of compatibility.
of the entire robot. The paper is structured as follows: In Sect. II, the KUKA
To mitigate this shortcoming, most commercial manufac- Robot Language is introduced and its main features are
turers of industrial robots provide domain-specific languages explained using an example. Subsequently, Sect. III describes
for their robot systems. These languages are usually text- the Robotics API and our software architecture which was
based and offer the possibility to declare robotic-specific data used to implement a lightweight interpreter for KRL. The
types, to specify simple motions, and to interact with tools steps required for reverse-engineering KRL are explained in
and sensors via I/O operations. Examples are the KUKA Sect. IV. While static preprocessing of KRL programs is
Robot Language or RAPID from ABB. To run such a described in Sect. V, different approaches for interpreting
program, it is transmitted to the robot controller, where it KRL on top of our software architecture are discussed in
is executed obeying real-time constraints. These languages Sect. VI. Finally, Sect. VII concludes the paper.
focus on a narrow set of required features and prohibit
II. KUKA ROBOT L ANGUAGE
Andreas Angerer, Alwin Hoffmann, Henrik Mühe, and Wolfgang Reif Today, every KUKA industrial robot is programmed using
are with the Institute for Software and Systems Engineering, University of
Augsburg, D-86135 Augsburg, Germany. E-mail of corresponding author: the proprietary KUKA Robot Language which is an imper-
hoffmann@informatik.uni-augsburg.de ative programming language similar to Pascal. In addition
This work presents results of the research project SoftRobot which is to typical programming statements such as variable assign-
funded by the European Union and the Bavarian government within the
High-Tech-Offensive Bayern. The project is carried out together with KUKA ments, conditionals and loops, KRL provides robotic-specific
Roboter GmbH and MRK-Systeme GmbH. statements e.g. for specifying motions and interacting with
DEF example() deceleration phases. To indicate that a target position does
DECL INT i
DECL POS cpos not need to be reached exactly, an additional parameter (e.g.
DECL AXIS jpos C_DIS in the example program) is used in the corresponding
FOR i=1 TO 6 motion statement. However, there are KRL statements like
$VEL_AXIS[i]=60 reading an input which stop the advance run making it
ENDFOR
impossible to blend between two motions [3].
jpos = {AXIS: A1 0,A2 -90,A3 90,A4 0,A5 0,A6 0}
PTP jpos
L1
IF $IN[1] == TRUE THEN
cpos = {POS: X 300,Y -100,Z 1500,A 0,B 90,C 0}

L2
ELSE
cpos = {POS: X 250,Y -200,Z 1300,A 0,B 90,C 0} Smoothing
ENDIF
Fig. 2. Two blended linear motions, L1 and L2 , with n automatically
INTERRUPT DECL 3 WHEN $IN[2]==FALSE DO BRAKE
INTERRUPT ON 3 generated transition.

TRIGGER WHEN DISTANCE=0 DELAY=20 DO $OUT[2]=TRUE

LIN cpos In KRL, the communication with external tools and sen-
LIN {POS: X 250,Y -100,Z 1400, A 0,B 90,C 0} C_DIS sors is usually done by using digital or analog in- and
PTP jpos
outputs. Hence, KRL provides predefined global variables
INTERRUPT OFF 3 (cf. variables $IN and $OUT) and additional statements to
END
handle in- and outputs. These variables and statements can be
Fig. 1. Example program written in KRL. used in a TRIGGER statement to define path-related switching
actions. In the example from Fig. 1, the binary output $OUT[2]
is set to true 20ms after the linear motion to cpos was started.
tools. Moreover, KRLs execution semantics uses two pro- Another feature of KRL are interrupts, where the current
gram counters to implement a feature known as advance run. program is suspended when an event (e.g. an input) occurs
The second counter is usually ahead of the regular program and a subprogram is executed. The event and the subprogram
counter and is used for planning motions in advance. In are defined by an INTERRUPT declaration statement. After
particular, this is used to blend two subsequent motions. An being defined, the interrupted can be switched on and off.
extensive reference to KRL can be found in [3]. In the example program above, an interrupt is declared,
which fires when the binary input $IN[2] becomes true. The
An example program showing the main features of KRL
interrupt-subprogram causes the robot to brake immediately
is given in Fig. 1. Like all KRL programs, it contains a
(BRAKE). Besides the submit interpreter [3], which allows
declaration section followed by a statements section which
running a special second program in parallel with the main
starts with the first statement and comprises the actual
program, triggers and interrupts are the only means to
program. Every variable must be declared in the declaration
express concurrency in KRL – albeit in a limited manner.
section and can later be assigned in the statements sections.
Besides common data types (INT, REAL, BOOL and CHAR), KRL
III. ROBOTICS API
allows the definition of arrays and user-defined structs and
provides predefined structs such as AXIS and POS which are Fig. 3 illustrates the important parts of the software ar-
specific to robotics. There is a large number of predefined chitecture introduced in [2]. The central concept is that real-
global variables, e.g. for setting the max. velocity of the time critical commands can be specified using the object-
robot’s joints ($VEL_AXIS) or for accessing binary inputs ($IN) oriented Robotics API and are then translated into commands
and outputs ($OUT). To control program flow, KRL has several for the Realtime Primitives Interface [4]. The Robot Control
statements such as conditionals (e.g. IF, SWITCH), loops (e.g. Core (RCC) executes these commands, which consist of
FOR, REPEAT ... UNTIL, WHILE) and jumps (GOTO). a combination of pre-defined (yet extendable) calculation
Because KRL is a robotic DSL, it has built-in statements modules and a specification of the data flow among them.
for programming motions such as PTP or LIN. While PTP Implementing only the RCC with real-time aspects in mind
executes a point-to-point motion to its programmed end is sufficient to allow the atomic execution of Robotics
point, the LIN statement executes a linear motion to a API commands while obeying real-time constraints. Here,
specified target in Cartesian space. Besides these two motion only the aspects of the programming model relevant to this
types, KRL currently supports circular motions and splines. work will be introduced. A comprehensive overview of the
Using the advance run feature, motions are pre-calculated programming interface can be found in [5].
and planned before the actual program execution reaches The Robotics API is implemented as a library on top
the corresponding motion statement. This allows blended of a general purpose programming language. In terms of
movements, where the motion does not stop exactly at the concepts, the Robotics API covers the same scope that the
programmed target but blends into the subsequent motion KUKA Robot Language does (see Sec. II), offering robotic
(cf. Fig. 2). Usually, this approach leads to faster execution specific data types, movement and tool commands as well
of multiple motion statements by reducing acceleration and as control flow structures as provided by the host language.
 Domain-specific DSL Interpretation Graphical Programming
Application Engine Environment (see Sec. II). In today’s general purpose programming lan-
guages, which the Robotics API is intended to be used with,
Robotics API such an ahead-of-time interpretation is usually not provided.
Our transaction-like mechanism for specifying real-time
Robotics Base Class Libraries (RBCL)
Robotics Extension critical commands is suitable for covering the requirements
Class Libraries (RECL)
in almost any domain of industrial robotics today [2]. It also
Dynamic Construction of Realtime Primitive Commands allows for blending between subsequent motions, but only
for a finite set of motions and not incrementally. However,
the execution semantics clearly differs from those of the
Realtime Primitive Interface (RPI)
KUKA Robot Language, which constitutes an additional
challenge for interpreting legacy KRL programs on top of
Robot Control Core
the Robotics API.
IV. A PPROACH
Fig. 3. The Robotics API and its context in the software architecture.
The goal of this work was running KRL in an entirely
different execution environment and with a different under-
Additionally, the Robotics API incorporates a comprehen- lying execution paradigm. The first problem is that KRL is
sive robotics domain model that extends beyond the set of only documented in user manuals, i.e. there is no publicly
specific data types that KRL provides. This simplifies the available formal specification or grammar of the language.
development of diverse, complex robotic applications, which Semantics is only documented by informal descriptions.
is also supported by reusable class structures and reusable Additionally, even if it is possible to sufficiently determine
logic. However, runtime environments of common object- the semantic meaning of every construct in the language, a
oriented programming languages do not guarantee real-time successful reimplementation must not only retain the same
constraints during program execution. Thus, reacting to cer- control flow as the original implementation but also ensure
tain sensor events cannot be done in real-time using eventing that robot movements are planned and executed the same
concepts built into the programming language. way. This task is difficult, because of different underlying
concepts of KRL and the Robotics API used to implement
ignitionMovement : ignitionMovementCmd robot : Robot
Motion
: action
: Command
: targets
motion commands. KRL can start a motion and continue
the execution of the program while the motion is performed
motionEnded : Event startGasTrigger :
: triggeredBy
Trigger by the robot. Commands read while continuing the execution
: starts can influence the motion (cf. advance run in Sect. II). Repli-
gasOn : GasOn : action startGasCmd :
Command
: targets weldingTorch :
WeldingTorch cating this in a simple way requires a means of augmenting a
motion which has already been started, which is conceptually
Fig. 4. Robotics API command incompatible with the Robotics API.
Starting with a simple benchmark program written in KRL
To meet real-time requirements, e.g. for motion blending and the programming manual [3], every command found in
or event handling, commands in the Robotics API can be either code or the handbook was added to a list of valid KRL
linked with a special mechanism prior to execution. Com- statements. To find the set of allowed parameters for each
mands that are combined in that way are executed atomically command, the manual proved to be insufficient, even though
on the Robot Control Core. Fig. 4 shows an example of it uses EBNF-like notation to explain some commands. The
such a combined command structure. This example is taken set of parameters specified in the manual is often either in-
from a welding application and specifies the initialization complete or vague. To counter the problems stemming from
of the welding gas flow as soon as a robot motion has a lack of documentation, we extracted about one megabyte
ended. To achieve this, the motion (titled ignitionMove- of valid KRL source code from a KUKA robot control unit.
ment) defines a special event (motionEnded) that is used This in itself is usually not enough to construct a grammar
as a trigger (startGasTrigger) for starting the subsequent for a programming language in a reasonable amount of time.
command (startGasCommand). Such a command structure Combined with a very restrictive preliminary grammar built
is converted into a dataflow specification that is executable manually using the handbook mentioned earlier, the source
by the RCC with real-time guarantees. This, however, is code proved to be a valuable asset. The preliminary grammar
a different concept of handling events occurring during was constructed in a conservative manner: Whenever the
execution than the concept employed by KRL, where it is syntax was not entirely clear in the handbook, the most re-
possible to call arbitrary methods when an event occurs. strictive assumption was made to construct the corresponding
Additionally, the way commands for robots or tools are grammar rule. After having finished the construction, both
processed inside the Robotics API differs from how they lexer and parser were generated and extended to simplify
are handled in the KUKA Robot language. KRL interprets finding missing or insufficient grammar rules. All common
program instructions ahead of their actual execution which constructs not included in the grammar so far were added.
allows for successive blending between subsequent motions If a specific parse error happened only with a single source
 Sourcecode Symboltable
file, the official KRL implementation KUKA.OfficeLite [6] DEFDAT $global GlobalSymbols
INT a
was used to validate the construct before it was added to the ENDDAT - a : int
- m : method
grammar. This way a comprehensive grammar for KRL was DEF m()
INT b b : int
built from scratch in a short amount of time. a = 5
END - mo : method

Having obtained a usable grammar, we next implemented DEF mo()

INT c
c : int

a way of mapping KRL to the Robotics API introduced in END

Sect. III. Although translating KRL to Java with calls to the AST
ROOT
Robotics API is possible, we chose to build an interpreter
for the DSL. The official KUKA implementations of KRL DEFDAT DEF DEF

offer some debugging options and features like backward $global INT m INT = mo INT
execution of movement commands. Trying to mimic these
features in a translation-based approach would complicate a b a 5 c

s1 s2
the translation process. An interpreter, on the other hand, al-
lows a high level of interaction with the interpreted program.
It simulates a CPU but can be accessed and manipulated Fig. 5. KRL sourcecode, AST generated by the parser and associated
symbol table hierarchy.
easier than the physical CPU. Further advantages of the
interpretation approach will be detailed in Sect. VI.
V. P REPROCESSING with the type of the expression on the right. In the context
From the grammar, both lexer and parser were generated of an assignment, two types are considered compatible if
using ANTLR [7] (ANother Tool for Language Recognition). lossless conversion between the type of the expression and
We enriched the grammar with the description of a tree the variable is possible. A set of similar constraints was
structure that the generated parser uses to output an Abstract found for all expressions in KRL and implemented in the
Syntax Tree (AST) instead of a parse tree. A parse tree type checker. The type checker also adds type information
is a representation of which rules were used to parse the to the AST to avoid having to compute this information again
input whereas an AST is less verbose and represents only in the interpreter.
the information necessary for the purpose of interpretation.
VI. I NTERPRETATION
Since KRL is both statically and explicitly typed, compre-
hensive type-checking is possible before actually executing Traversing the AST is a simple way of executing a DSL.
a program. This is advantageous, since having to terminate a We will call this approach tree-based interpretation. It is
program because of an invalid assignment while in the mid- a straightforward implementation of an interpreter, but not
dle of the execution is discouraged, especially in a DSL that the only feasible method. Literature suggests that a different
is used to control heavy machinery. Type checking requires approach, called bytecode interpretation, is also widely used
all symbols and their types to be known. Additionally, it is [9]. Since our implementation using a tree-based approach is
paramount that symbol scoping, that is, different visibility in both more mature and versatile than our implementation of a
different areas of the program, is established. Thus, a symbol bytecode interpreter, we will focus tree-based interpretation
table has to be generated before a type checker can be run. first. Later in this chapter, a bytecode-based prototype will
The program that fills the symbol table works on the AST be introduced and compared to the original approach.
created by the parser – an example is displayed in Fig. 5. Tree-based interpretation relies on the idea that a KRL
A hierarchy of symbol tables is established to allow for program can be effectively executed by walking the AST
easy integration of scoping: only symbols are visible that generated from it and executing each node in it as shown
are in a symbol table which is an ancestor to the current in Fig. 6. For simple statements, like a variable declaration
symbol table. In this context, current symbol table means (see Fig. 5, label s1), execution comes down to reading the
local to the expression for which visibility of a symbol has declaration node, reading the variable name in the child node
to be determined. If a statement in a method m tries to read and allocating a corresponding amount of memory. For more
a variable a, the symbol table used to collect symbols of complex statements like an assignment (see Fig. 5, label
said method is the current symbol table. In the symbol table s2), execution requires executing both child-nodes. The value
hierarchy given at the top of Fig. 5, variable a is thus visible returned by executing the second child-node – and thus the
to method m, since it is in a symbol table that is an ancestor right side of the assignment – needs to be assigned to the
of the current symbol table for statements in method m. position in memory referenced by the first child-node.
After having collected all symbols in a given KRL pro- Control flow constructs like loops are simple to execute:
gram, type checking is trivial: The AST has to be read a for an unconditional loop, its body is executed iteratively
second time and every expression has to be checked for until a statement which causes the loop to exit is encountered.
type compatibility. Type checking can be done by verifying However, a serious problem arises with executing statements
that a set of type constraints is met [8]. Considering the that severely impact control flow (e.g. a return statement,
source code in Fig. 5, we must verify that the type of the a procedure, a function call, or a GOTO). It is sufficient to
variable on the left side of the assignment is compatible focus on the most difficult of these statements, GOTO, since
 test.src AST test.src AST

DEF test() DEF test()

INT c,x ROOT INT c,x ROOT
c = 0 c = 0
x = 1 x = 1
WHILE x<10000 parser WHILE x<10000 parser
c = c + x DEF DECL ... c = c + x DEF DECL ...
x = x + 1 x = x + 1
ENDWHILE TEST INT c x ENDWHILE TEST INT c x
END END

bytecode compiler
Interpreter Textual bytecode
.method TEST Assembled bytecode
stackframesize 2
int_loadConst 0 8, 0, 0, 0, 2, 4, 0, 0, 0,
int_store 0 # C 0, 2, 0, 0, 0, 0, 4, 0, 0,
int_loadConst 1 0, 1, 2, 0, 0, 0, 1, 0, 0,
int_store 1 # X 0, 0, 1, 4, 0, 0, 39, 16,
16, 14, 0, 0, 0, 78, 0, 0,
Fig. 6. Architecture when using a tree-based interpreter. .label 0
int_load 1 # X 0, 0, 0, 0, 0, 0, 0, 1, 11,
int_loadConst 10000 2, 0, 0, 0, 0, 0, 0, 0, 0,
int_lt 1, 4, 0, 0, 0, 1, 11, 2, 0,
jmp_false 1 0, 0, 1, 13, 0, 0, 0, 25
int_load 0 # C
int_load 1 # X bytecode assembler
int_add
int_store 0 # C

the others statements can be simulated with it. In a tree-based int_load 1 # X

int_loadConst 1
int_add
Interpreter

interpreter, two stacks need to be maintained: The call stack int_store 1 # X

jmp 0
.label 1
of the interpreter (interpreter call stack) itself and the call .end

stack of the program being interpreted (program call stack).

When interpreting a LOOP for instance, the interpreter call
Fig. 7. Process used to generate bytecode from a KRL program.
stack changes because a method is invoked that handles the
execution of the loop. The program call stack remains the
same as it only changes with method calls and jumps in KRL representation into an actual byte-array. We designed each
cannot target a label outside the current method. bytecode operation to be as simple as possible. Required
Consider a GOTO statement inside a loop which jumps memory is determined by the compiler and numerical in-
to a statement outside said loop. A jump like that would dexes are used to address variables. This way, memory
require the method executing the LOOP statement to return allocation is dealt with before the program is executed,
execution to its caller and tell it to continue at the target resulting in a leaner interpreter. The translation process and
label of the jump. This requires reversing the call stack, and the results generated in each step are displayed in Fig. 7.
transferring information on where to continue execution to The Robotics API is used to execute movement commands
the caller – in complex cases through a call-hierarchy of in both the tree-based interpretation approach as well as the
arbitrary height. Although this can be achieved by wrapping bytecode interpretation approach. As explained in Sect. II,
every method used for node execution, a more elegant albeit KRL can blend motions together, thus making the transition
unusual approach is using the exception concept provided by between two separate motions smooth, as illustrated in Fig. 2.
most high-level programming languages, as suggested in [9]. To achieve this, KRL executes motions asynchronously and
Exceptions can pass through the call hierarchy and be caught continues interpretation until it finds the next motion to be
in appropriate places with a minimum of additional code. executed. When found, a soft transition between the running
Additionally, since none of the debug information carried and the next motion is calculated and applied. Mapping this
by the exception is required, cost for exception creation is behavior to the Robotics API is non-trivial, because the way
minimal, as suggested by [10, p. 174]. a motion is executed cannot be influenced once execution has
At the beginning of this chapter, a different approach, started. To mimic KRL, we do not start execution of a motion
bytecode interpretation, was mentioned. Compared to a tree- as soon as it is found. Instead interpretation is continued
based interpreter, a bytecode interpreter does not walk a and all motion commands are queued until a motion is
complex data structure like a tree but instead works on encountered that may not be blended. This can either be the
simple code consisting of small atomic operations. Using case when a motion has a parameter indicating that it is not
a less verbose data structure leads to less overhead in the supposed to blend with a subsequent motion, when a special
interpreter. Extracting an operation and its parameters from command prevents blending as mentioned in Sect. II or when
the AST requires accessing different nodes of the tree and the queue is full. If any of the above applies, the motion-
thus accessing different addresses in memory using pointers. queue is executed with blending between each motion. The
Bytecode can be constructed in a way that groups operations rationale behind this is that interpretation of control flow and
and parameters together, making the cost of accessing an computational statements takes only a minor amount of time.
operation and its parameters as cheap as reading a byte- Thus, the delay introduced by deferred execution of motion
sequence from memory. commands is minimal, but allows us to closely mimic the
The bytecode has to be generated out of the KRL program execution semantics of KRL.
before interpretation can start. This is achieved by reusing Interrupts in KRL halt execution of the main program
the annotated AST introduced in Sect. IV. Since bytecode and run a subroutine when an event condition becomes
is usually represented as an array of byte values, a standard true. An interpreter can mimic this behavior by a separate
approach is to first generate human readable bytecode that thread that periodically checks all event conditions. When
is easy to read and debug, and then assemble the textual a condition becomes true, the main thread executing the
KRL program has to block and a new thread executing the both interpreters written in Java, the bytecode interpreter is
interrupt subroutine has to be created. Once the subroutine about six times faster than the tree-based interpreter on all
has finished, the main thread can resume. Apart from this major platforms (Microsoft Windows Vista, Ubuntu Linux,
scenario, more complex interrupt invocations are possible: Mac OS X) tested on the same machine. Furthermore, a
an interrupt can fire while an interrupt subroutine is being bytecode interpreter prototype written in C is up to 300
executed. To handle both scenarios, all threads executing ei- times faster than the tree-based interpreter written in Java.
ther the main program or an interrupt subroutine are managed However, interfacing the bytecode interpreter written in C
on a stack. Only the thread on top of the stack is allowed with the Java-based API is not possible yet.
to execute statements, all other threads need to block. When The Robotics API was interfaced with the interpreters
an interrupt subroutine finishes, the thread executing it is to implement robot commands like motions and to gain
removed from the stack, allowing another interrupt to finish. access to I/Os. We assumed that executing control flow and
This concept can cope with an arbitrary number of interlaced calculation statements takes only a small amount of time
interrupts without explicitly suspending threads and makes compared to the time it takes the robot to complete a motion
resource synchronization unnecessary. Additionally, the same command. Under that assumption, we were able to show that
mechanism can be used to implement triggers: instead of differences in semantics between the API and KRL can be
monitoring a condition, the robots position is considered. bridged by batch-executing motions. Concurrency as offered
When the robot reaches the point specified in the trigger, by KRL can be added to our interpreters by using threads
its subroutine is executed just like an interrupt subroutine. and a stack-based synchronization mechanism.
However, this approach does not guarantee any real-time Future research will focus on extending and modifying
constraints for both interrupts and triggers. Alternatively, KRL to include features like synchronization between robots.
simple triggers (e.g. setting outputs) that meet real-time The interpreters introduced in this paper were designed to
requirements can be established by the transaction-like mech- be extendable and can be used for prototyping additions
anism of the Robotics API (cf. Sect. III). to the original DSL. Furthermore, more specific commands,
The third way of adding concurrency is the submit in- e.g. for welding applications, will be integrated. So far, the
terpreter, which allows executing a different program in Robotics API does not include a way of specifying complex
parallel to the main KRL program. Implementing the submit triggers like it is possible in KRL. Embedding a simple DSL
interpreter is possible by running two separate interpreter to specify triggers in and using a lean bytecode interpreter
instances concurrently on the same memory. Because KRL to execute those triggers could be a way of mitigating this
documentation does not specify how the submit interpreter shortcoming and will be a topic of future research.
is scheduled and whether it receives CPU time, we have ACKNOWLEDGEMENT
decided not to include an implementation in our prototypes.
We would like to thank Prof. Terrence Parr for his impor-
VII. C ONCLUSION tant remarks on interpreting KRL.
In this paper, we have shown that it is possible to run R EFERENCES
KRL using the Java-based Robotics API developed in the [1] G. Biggs and B. MacDonald, “A survey of robot programming sys-
SoftRobot project. Running KRL is necessary in order to tems,” in Proc. Australasian Conference on Robotics and Automation,
J. Roberts and G. Wyeth, Eds., Brisbane, Australia, Dec. 2003.
support legacy applications and additionally serves as proof [2] A. Hoffmann, A. Angerer, F. Ortmeier, M. Vistein, and W. Reif,
that our approach is indeed viable. We have introduced “Hiding real-time: A new approach for the software development of
the Robotics API and shown that it is superior to KRL in industrial robots,” in Proc. 2009 IEEE/RSJ Intl. Conf. on Intelligent
Robots and Systems, St. Louis, MO, USA, Oct. 2009, pp. 2108–2113.
many areas, but also that its semantics differs in other areas. [3] KUKA System Software 5.5 – Operating and Programming Instruc-
Additionally. we have shown that reverse-engineering KRL tions for System Integrators, KUKA Roboter GmbH, Augsburg, Ger-
is possible and that a grammar for the language can be build many, 2009.
[4] M. Vistein, A. Angerer, A. Hoffmann, A. Schierl, and W. Reif,
using only information from the KRL manual and results “Interfacing industrial robots using realtime primitives,” in Proc. 2010
from trying statements in KUKA.OfficeLite. IEEE Intl. Conf. on Automation and Logistics, Hong Kong, China,
To execute KRL, we have introduced two separate ap- Aug. 2010.
[5] A. Angerer, A. Hoffmann, A. Schierl, M. Vistein, and W. Reif, “The
proaches, each with a different set of advantages and thus use Robotics API: An object-oriented framework for modeling industrial
cases. Comparing both approaches, the tree-based interpreter robotics applications,” in Proc. 2010 IEEE/RSJ Intl. Conf. on Intelli-
is flexible because it works on a more verbose data-structure. gent Robots and Systems, Taipei, Taiwan, Oct. 2010.
[6] KUKA.OfficeLite. KUKA Roboter GmbH. [Online]. Avail-
This makes adding features like debugging simple, because able: http://www.kuka-robotics.com/en/products/software/kuka sim/
debug information is directly available to the interpreter. kuka sim detail/
The bytecode interpreter works on a lean data-structure [7] T. Parr and R. Quong, “ANTLR: A predicated-LL(k) parser generator,”
Software-Practice and Experience, vol. 25, no. 7, pp. 789–810, 1995.
including only information vital to executing the program. [8] A. V. Aho, M. S. Lam, R. Sethi, and J. D. Ullman, Compilers:
Furthermore, bytecode can be represented as an array making Principles, Techniques, and Tools, 2nd ed. Addison Wesley, 2006.
dereferencing pointers and thus random memory access [9] T. Parr, Language Implementation Patterns: Create Your Own Domain-
Specific and General Programming Languages. Pragmatic Bookshelf,
unnecessary. Because of this, more instructions fit into the 2009.
CPU cache and execution is faster. We tested performance [10] J. Shirazi, Java Performance Tuning. Sebastopol, CA, USA: O’Reilly
while executing a simple benchmark written in KRL. With & Associates, Inc., 2002.