See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/286490138

Controlling Kuka Industrial Robots: Flexible Communication Interface

JOpenShowVar

Article  in  IEEE Robotics & Automation Magazine · December 2015

DOI: 10.1109/MRA.2015.2482839

CITATIONS READS
28 8,462

5 authors, including:

Filippo Sanfilippo Lars Ivar Hatledal

Universitetet i Agder Norwegian University of Science and Technology
71 PUBLICATIONS   452 CITATIONS    25 PUBLICATIONS   208 CITATIONS   

SEE PROFILE SEE PROFILE

Houxiang Zhang Massimiliano Fago

Norwegian University of Science and Technology 2 PUBLICATIONS   50 CITATIONS   
210 PUBLICATIONS   1,970 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

EEG Brain Control and Communication View project

A Novel Integrated Anti-sway System for Rolls-Royce Marine Shipboard Cranes (2012-2013) View project

All content following this page was uploaded by Filippo Sanfilippo on 16 December 2015.

The user has requested enhancement of the downloaded file.

 Controlling Kuka Industrial Robots:
Flexible Communication Interface JOpenShowVar
F. Sanfilippo, L. I. Hatledal and H. Zhang M. Fago K. Y. Pettersen
Department of Maritime Technology and IMTS S.r.L. Company Department of Engineering
Operations, Aalesund University College Taranto, Italy Cybernetics, Norwegian University of
Postboks 1517, 6025 Aalesund, Norway [email protected] Science and Technology
{fisa, laht, hozh}@hials.no 7491 Trondheim, Norway
[email protected]

Abstract— JOpenShowVar is a Java open-source cross- User Program

JOpenShowVar KRL (Kuka Robots)
platform communication interface to Kuka industrial robots. (Middleware)

This novel interface allows for read-write use of the controlled

manipulator variables and data structures. JOpenShowVar,
Fig. 1: The idea of realising a communication interface for
which is compatible with all Kuka industrial robots that use Kuka industrial robots that works as a middleware between
Kuka Robot Controller version 4 (KR C4) and Kuka Robot the user program and the Kuka Robot Language (KRL).
Controller version 2 (KR C2), runs as a client on a remote
computer connected with the Kuka controller via Transmission is to try to gain as much control over the robot as possible,
Control Protocol/Internet Protocol (TCP/IP). Even though only whereas industries seek safe and easy operational interfaces.
soft real-time applications can be implemented, JOpenShowVar
opens up to a variety of possible applications, making both In particular, although software interfaces that are appropriate
the use of various input devices and sensors as well as the for industrial use are available, it is difficult to find interfaces
development of alternative control methods possible. that are applicable for research purposes. The disclosure of
Four case studies are presented to demonstrate the poten- the internal control architecture is also very hard to come
tial of JOpenShowVar. The first two case studies are open- by. Many manufacturers are unwilling to publish internal
loop applications, while the last two case studies describe the
possibility of implementing closed-loop applications. In the first
details regarding system architecture due to the high levels
case study, the proposed interface is used to make it possible for of competition in the robot market. Consequently, it is not
an Android mobile device to control a Kuka KR 6 R900 SIXX possible to fully exploit many robotic platforms in a scientific
(KR AGILUS) manipulator. In the second case study, the same context.
Kuka robot is used to perform a two-dimensional line-following Only a small number of industrial manipulators with an
task that can be used for applications like advanced welding
operations and similar. In the third case study, a closed-loop open control interface has been released as far as robotics
application is developed to control the same manipulator with a is concerned. Focusing exclusively on Kuka industrial robots
Leap Motion Controller that supports hand and finger motions as [3], the Kuka Robot Language (KRL) is the standard pro-
input without requiring contact or touching. In the fourth case gramming language [4]. It is a text based language that
study, a bidirectional closed-loop coupling is established between offers data type declaration, specification of simple motions,
a Force Dimension omega.7 haptic device and the same Kuka
manipulator. Related experiments are carried out to validate and interaction with tools and sensors via Input/Output (I/O)
the efficiency and flexibility of the proposed communication operations. It is only possible to run KRL programs on the
interface. Kuka Robot Controller (KRC), where program execution is
done in accordance with real-time constraints. While the
Index Terms— Robot interface, Kuka industrial robots, input KRL offers an interface that is easy to use in industrial
device.
applications, it is quite limited for research purposes. In
particular, the KRL is tailored to the underlying controller
I. I NTRODUCTION
and consequently, only a fixed, controller-specific set of
Industries that employ robots in a wide variety of ap- instructions is offered [5]. Advanced mathematical tools such
plications are the main customers for robot manufacturers. as matrix operations, optimisation or filtering methods are
The manipulator market for research applications, on the not supported, thus making the implementation of novel
other hand, is simply too small for the robot manufacturing control approaches very difficult. There is no native way to
industry to develop models specifically for such use. While include third party libraries and as such, extending the KRL
the hardware and mechanical requirements of developed to include new instructions and functionalities is an arduous
robots are often similar for both industry and research, task. Moreover, it is not possible to directly use external input
scientific software requirements are quite different and even devices. The standard workaround for partially expanding the
contradictory in many aspects [1], [2]. The goal of scientists robot’s capabilities is to use supplementary software packages
provided by Kuka. Some examples of such packages are the TABLE I: Currently available interfaces for Kuka robots
Kuka.RobotSensorInterface [6], which allows the manipulator External
Support to Support to Kuka
motion or program execution to be influenced by sensor Interface packages
Kuka LBR industrial robots
required
data, and the Kuka.Ethernet KRL XML [6], a module that OpenKC Yes No Yes
allows the connection of the robot controller with up to nine FRI Yes No No
external systems (e.g. sensors). However, several drawbacks KCT No
Yes (only small
Yes
and low-payload)
accompany these supplementary software packages: I/O is
Robotics Yes (safety
limited, a narrow set of functions is present and major capital Yes No
APIs limitations)
investments are often required to actually purchase these ROS Yes No No
packages from Kuka. KUKASunrise.Connec-
Yes No Yes
tivity
To overcome these problems, JOpenShowVar was pre-
sented by our research group in [7]. JOpenShowVar is a Java
open-source cross-platform communication interface that al- case study, a bidirectional closed-loop coupling between a
lows for reading and writing all the controlled manipulator Force Dimension omega.7 haptic device and the same Kuka
variables. Even though only soft real-time applications can robot is established. A force feedback proportional to the
be implemented, this interface allows researchers to use force that the robot’s end-effector is supporting is returned
different input devices, sensors and to develop alternative by the haptic interface. Related experiments and results are
control methods. JOpenShowVar library is compatible with shown in Section V. In Section VI, conclusions and future
all Kuka industrial robots that use KR C4 or KR C2. The works are outlined.
basic concept is shown in Fig. 1: JOpenShowVar works as a
middleware between the user program and the KRL. In this II. R ELATED R ESEARCH W ORK
work, more details about JOpenShowVar architecture are pro- The possibility of creating a software interface to Kuka
vided. Several new, more flexible and efficient, procedures are robots has been investigated by several research groups.
introduced in the latest release of the library to replace the old An open-source real-time control software for the Kuka
fundamental reading and writing method that is now marked lightweight robot, OpenKC, was presented in [1]. This soft-
as deprecated. In addition to these new methods, some other ware makes it possible to externally trigger and control all
high-level functions are also provided to enable angles and of the features of the Kuka lightweight (LBR) manipulator.
torques readings of the controlled manipulator. This feedback This is done by using a simple set of routines that can
signal is very important to improve the manipulator dexter- easily be integrated into existing software. As a result,
ity and to achieve crucial functions like sensitive collision developers of robot applications have an edge in finding
detection and compliant control actions. Some guidelines for solutions for a variety of different software scenarios. In
allowing the user implementing new high-level procedures particular, force and torque readings as well as different
are discussed. JOpenShowVar is an open-source project and modes of operation can be remotely read and parametrised.
it is available on the Internet at https://github.com/ However, this software interface is restricted to a specific
aauc-mechlab/jopenshowvar, along with several de- model of Kuka robots, the Kuka lightweight manipulator, and
tailed class diagrams, documentation and demo videos. use of the Kuka.RobotSensorInterface package is required.
The paper is organised as follows. A review of the related Another interface that is currently available for the Kuka
research work is given in Section II. In Section III, we focus lightweight robots is the Fast Research Interface (FRI) [2].
on the description of JOpenShowVar architecture, analysing The FRI provides direct low-level real-time access to the
the communication protocol, possible control approaches KRC at high rates of up to 1 kHz. On the other hand,
and some high-level methods. In Section IV, four case all features, like teaching, motion script features, fieldbus
studies are presented. The first two case studies are open- I/O and safety are provided. The FRI is based on the KR
loop applications, while the last two case study describe the C2. Without much installation efforts, access to different
possibility of implementing closed-loop applications. In the controller interfaces of the Kuka system is provided including
first case study, JOpenShowVar is used to control a Kuka KR joint position control, cartesian impedance control, and joint
6 R900 SIXX (KR AGILUS) robot with an Android [8] mobile position control. However, also this software interface is
application. In the second case study, the same Kuka robot is restricted to a specific model of Kuka robots, the Kuka
used to perform a two-dimensional line-following task that lightweight manipulator. No support for the standard Kuka
can be used for applications like advanced welding operations industrial robots is provided.
and similar. In the third case study, the same manipulator Later on, the Kuka Control Toolbox (KCT), a collection
is controlled in a closed-loop mode with a Leap Motion of MATLAB functions for motion control of Kuka industrial
Controller [9] that supports hand and finger motions as input robots, was introduced in [10] to offer an intuitive and
without requiring contact or touching. Finally, in the fourth high-level programming interface for the user. This toolbox
is compatible with all small and low-payload Kuka robots Remote Computer
TCP/IP
KRC
that have six degrees of freedom (DOFs). The KCT runs User Program KUKAVARPROXY

on a remote computer connected to the KRC via TCP/IP.

A multi-thread server runs on the KRC and communicates
via Kuka.Ethernet KRL XML with a client whose job is JopenShowVar

to manage the information exchange with the manipulator.

High transmission rates are guaranteed by this communi- Fig. 2: The proposed architecture for JOpenShowVar: a
cation set-up, thus enabling real-time control applications. client-server model is adopted.
Nonetheless, as in the previous work, this approach is still
is also possible to access the robot controller from external
tailored to the underlying controller and requires the use of
computers in hard real-time mode. However, even in this last
the Kuka.Ethernet KRL XML package.
case, the main limitation is that this software is restricted to
A different approach has been tried by other researchers, the Kuka lightweight manipulators.
aimed at the disclosure of the Kuka industrial manipulator To provide a more clear overview of the currently available
internal control architecture. For instance, the reverse en- interfaces for Kuka robots, a table of comparison of all the
gineering of the KRL was investigated in [5] and a set of reviewed related works is shown in Table I.
Java-based Robotics APIs was presented for programming To the best of our knowledge, a cross-platform commu-
industrial robots on top of a general-purpose language. The nication interface that works with all Kuka industrial robots
Robotics APIs implement robot commands like motions and without requiring any external packages has not been released
access to I/O calls. It was shown that KRL can be bridged yet.
by batch-executing motions, under the assumption that ex-
ecuting control flow and calculation statements takes only III. JOpenShowVar ARCHITECTURE
a small amount of time compared to the time it takes the In this section, the authors initially describe the design
robot to complete a motion command. However, some safety choices that characterise the proposed architecture. Succes-
limitations are inherently present in the Robotics APIs set sively, the architectural concept is presented, analysing the
because it is the result of a reverse engineering approach communication protocol, possible control approaches and
and therefore does not include a way of specifying complex some high-level methods.
triggers in contrast to the KRL. The design of JOpenShowVar is based on the following
In the last few years, the Robot Operating System (ROS) design choices:
[11], an open-source software toolbox for robotic devel- • Low-cost: the developed architecture does not re-
opment, has become more and more popular among the quires any supplementary software packages provided
research community. The primary goal of ROS is to provide a by Kuka such as the Kuka.RobotSensorInterface [6] or
common platform to make the construction of capable robotic the Kuka.Ethernet KRL XML [6]. Therefore, no major
applications quicker and easier. Some of the features it pro- capital investments are required to actually purchase
vides include hardware abstraction, device drivers, message- these packages from Kuka. This fact makes the proposed
passing and package management. ROS provides support solution very inexpensive;
for different industrial robots including vendors like ABB, • Flexibility: the system offers a virtually unlimited I/O
Adept, Fanuc, Motoman and Universal Robots. Extensive and the possibility of including third party libraries. This
research work has also gone into creating ROS packages allows for adding support for advanced mathematical
for communicating with the Kuka lightweight robots but no tools such as matrix operations, optimisation or filtering
support is provided for the Kuka standard industrial robots methods, thus making it very simple to implement novel
yet. One of the main reasons for this lack is the non- control approaches;
disclosure of the KUKA Robot Controller (KRC) internal • Reliability: the system is easy to maintain, modify and
architecture which currently makes it impossible to directly expand by adding new components and features. In
interact with the robot to be controlled. addition the proposed interface is also open-source and
Recently, Kuka has shown more interest in the re- cross-platform;
search and education market. In particular, the KUKA Sun- • Integrability: the proposed system interface presents a
rise.Connectivity has been recently developed for Kuka modular structure that can facilitate the integration with
lightweight robots. This software provides a collection of ROS. Even though this integration is outside the scope
interfaces for influencing robot motion at various process of this journal paper, it is considered as an important
control levels. Third-party software can be easily integrated future work which will surely improve the usefulness
into the user-specific application using the popular standard of the proposed interface. The community of developers
programming language Java. Along with the quick update at ROS is looking forward to the integration of JOpen-
of the target position directly from the robot application, it ShowVar. The developers have confirmed the usefulness
 of the proposed interface especially because there are Application Code Terminal GUI
currently no other alternative offering similar features. Application
High Level
High-level
Functions
Hereafter, several specific functions, variables and config- functions
urations related to the KRL and the KRC are referred to Control Custom
in order to introduce the architectural concept. For a more Methods Kinematics
detailed introduction to the KRL, the reader can refer to [4].
The proposed control system architecture is shown in Fig. 2. JOpenShowVar readVariable sendRequest
CrossComClient writeVariable @Deprecated
It is a client-server architecture with JOpenShowVar running
as a client on a remote computer and KUKAVARPROXY act- Network
ing as a server on the KRC. JOpenShowVar locally interacts
with the user program and remotely communicates with the Kuka-
Dependent KUKAVARPROXY
KUKAVARPROXY server via TCP/IP. Functions
In particular, KUKAVARPROXY is a multi-client server
Kuka Robot
that is written in Visual Basic 6.0 and can serve up to Controller
KRL Actuator Program
10 clients simultaneously. KUKAVARPROXY implements the
Kuka CrossComm interface. This interface allows for the
interaction with the real-time control process of the robot KRC KRC
Kinematics
and makes it possible to perform several operations such as
selection or cancellation of a specific program, errors and Fig. 3: The architectural levels of JOpenShowVar.
faults detection, renaming program files, saving programs,
resetting I/O drivers, reading variables and writing variables. simultaneously access several variables, thereby minimising
KUKAVARPROXY implements the reading and writing meth- the access time. The only limitation to this approach is on
ods. All the variables that need to be accessed by these meth- the length of the logical structures that cannot exceed 255
ods have to be declared as global variables in the predefined bytes.
global system data list $CONFIG.DAT. All kinds of variables JOpenShowVar provides a client, CrossComClient, which
can be declared in this file from basic types such as INT, is written in Java, thus making cross-platform support possi-
BOOL and REAL to more complex structures like E6POS ble. The architectural details of the JOpenShowVar library
and E6AXIS that allow for storing the robot configuration. are shown in Fig. 3. As presented in our previous work
Moreover, several system variables can be accessed provided [7], the client initially provided only one low level method,
there are no restrictions due to the type of data such as sendRequest. This method allows for both reading and writ-
for $PRO IP, $POS ACT, $AXIS ACT or $AXIS INC. For ing variables. The sendRequest method returns a Callback
example, the current robot position, $POS ACT, cannot be instance containing the updated value. However, in the latest
written but only read. Restrictions of this nature are checked release of JOpenShowVar, starting from version v0.2, the
by the controller. sendRequest is marked as a deprecated method, since two
As already mentioned, the interface of the Kuka Cross- new more flexible and efficient methods are introduced:
Comm class allows for the interaction with the real-time readVariable and writeVariable.
control process of the robot to be controlled. However, On top of the JOpenShowVar’s methods that implement the
it should be noted that the Kuka CrossComm class can low level communication protocol, another logic layer can be
only be remotely accessed via TCP/IP. Unfortunately, the added by the user developer allowing for the possibility of
TCP/IP communication introduces inevitable delays, there- implementing alternative control methods (custom kinemat-
fore JOpenShowVar cannot provide a real-time access to ics) as well as some higher level functions. The application
the robot’s data. Only soft real-time applications can be code can run on top of this hierarchical architecture. In
realised. In fact, it takes a non-deterministic time to access addition a graphical user interface (GUI) and a terminal are
a specific variable. Since Kuka does not offer any kind provided with JOpenShowVar to allow the user for monitor-
of documentation on this topic, several experimental tests ing the robot’s state, visualising and manually setting all the
were performed at our laboratory to asses this time interval. desired variables. It should be noted that the GUI still uses the
According to our experiments, reported in Section V, the sendRequest method of JOpenShowVar for a practical reason,
average access time is about 5 ms. Moreover, this time since this old method does not require any knowledge on the
interval is not affected by the kind of access to be performed internal structure of the variables to be accessed compared to
(whether it is a reading or a writing operation) or by the the new methods. The low-level communication protocol, a
length of the message. For these reasons, it is advantageous to detailed reference explanation of the newly released methods,
aggregate several variables in logical structures when reading the possibility of implementing custom control functions, as
or writing data. By using data structures it is possible to well as some guidelines to develop high-level procedures will
 TABLE II: Reading variables a value of 50 (50% override speed), the message that the
Field Description client has to send to the server will have the format shown
00 message ID in Table III.
09 length of the next segment
0 type of desired function B. Variables, structures and methods
07 length of the next segment
$OV PRO Variable to be read From the release version v0.2 of JOpenShowVar, several
new classes have been added to the library to improve the
TABLE III: Writing variables usability. In particular, two abstract classes, KRLVariable and
Field Description
KRLStruct (which extends KRLVariable), are provided to
00 message ID allow the user to implement any KRL variable or structure,
0b length of the next segment respectively. In this way, it is possible to create and maintain
1 type of desired function a local instance of all the desired variables and structures
09 length of the next segment
$OV PRO Variable to be written on the client side. Based on these two abstract classes, the
50 value to be written most commonly used KRL variables and structures have
been implemented. Any other KRL variable or structure that
is not included in JOpenShowVar library yet can be easily
be discussed later in this section. implemented by the user.
Since the release version v0.2 of JOpenShowVar, the
A. Communication protocol sendRequest is marked as a deprecated method. To replace
The communication protocol relies on the TCP/IP pro- this old method, two new, more reliable methods, are added
tocol. In particular, on top of the TCP/IP layer, specially to the CrossComClient:
formatted text strings are used for message exchanges. • the readVariable method allows for reading any desired
KUKAVARPROXY actively listens on TCP port 7000. Once remote variable or structure from the controlled robot
the connection is established, the server is ready to receive and store it locally. An exception is thrown if an error
any reading or writing request from the client. in the communication protocol occurs;
Reading variables: To access a variable, the client must • the writeVariable method allows for updating any de-
specify two parameters in the message: the desired type of sired remote variable or structure of the controlled robot
function and the variable name. To read a specific variable, with the value of the corresponding local variable or
the type of function must be identified by the character “0”. structure, respectively. An exception is thrown if an error
For instance, if the variable to be read is the system variable in the communication protocol occurs.
$OV PRO, which is used to override the speed of the robot, The deprecated sendRequest method is being kept as part
the message that the client has to send to the server will of the JOpenShowVar library simply because the GUI still
have the format shown in Table II. In detail, the first two uses it for a practical reason. In fact, this old method does
characters of this string specify the message identifier (ID) not require any knowledge on the internal structure of the
with a progressive integer number between 00 and 99. The variables to be accessed compared to the newly introduced
answer from the server will contain the same ID so that methods. Moreover, it should be noted that the new method
it is always possible to associate the corresponding answer writeVariable cannot handle arrays; this can only be done
to each request even if the feedback from the server is by using the old sendRequest method. In the Algorithm 1
delayed. The next two characters in the string specify the sketch box, a possible use-case example is shown to highlight
length of the next segment in hexadecimal units. In this the differences between the new methods and the deprecated
specific case, 09 accounts for one character specifying the sendRequest method.
function type, two characters indicating the length of the next
segment and seven characters for the variable length. The fifth C. Control methods
character 0 in the message represents the type of the desired JOpenShowVar opens up to a variety of possible appli-
function, which in this case is reading. Subsequently, there cations making it possible to use different input devices
are two more characters indicating the variable length (in and to develop alternative control methods. In particular, the
hexadecimal units) and finally the variable itself is contained proposed interface provides the possibility of implementing
in the last section of the message. either a position or a velocity control approach. The user
Writing variables: To write a specific variable, three pa- experience is substantially different in each case. When using
rameters must be specified: the type of function, the name of the position control mode, the operator simply controls the
the desired variable and the value to be assigned. The writing position of the robot’s end-effector with constant velocity;
function is specified by the character “1”. For instance, if the when operating in velocity control mode, the operator also
variable to be written is the system variable $OV PRO with sets the velocity of the robot tool. In the first case, when the
 Remote Computer KRC
TCP/IP
User Program JOpenShowVar
θt
KRL KRC
s xt
Input Device Input Driver CrossComClient Actuator kinem
Program atics
xt xt
writeVariable KUKAVARPROXY

(a)

Remote Computer KRC

TCP/IP
User Program JOpenShowVar
θt
s xt
Control Algorithm KRL Actuator
Input Device CrossComClient
(kinematics) Program
θt θt
writeVariable KUKAVARPROXY
θa
θa θa
readVariable

(b)

Fig. 4: (a) The user program utilises JOpenShowVar to set the desired end-effector position and then the robot joints are
calculated by the KRC using the standard kinematic model, (b) a custom control algorithm can be implemented by the user
to calculate the joint values for the robot and then send these angles to the KRC to be actuated.

try (CrossComClient client = new CrossComClient(" if operating in position control mode, or by:
robotIPaddress", 7000)) {
//JOpenShowVar v0.1 reading xt = xa + ẋd Dt, (2)
Callback readRequest = client.sendRequest(new
Request(0, "$OV_JOG")); if operating in velocity control mode, where Dt is the esti-
System.out.println(readRequest);
//JOpenShowVar v0.1 writing mated time interval between two successive iterations. As al-
Callback writeRequest = client.sendRequest(new ready mentioned, JOpenShowVar cannot provide a real-time
Request(1, "$OV_JOG", "100")); access to the robot’s data. Only soft real-time applications
System.out.println(writeRequest);
//JOpenShowVar v0.2 reading can be realised. It takes a non-deterministic time to access a
KRLReal jog = KRLVariable.OV_JOG(); specific variable. According to our experiments, reported in
client.readVariable(jog); Section V, the average access time is about 5 ms. Therefore
System.out.println(jog);
//JOpenShowVar v0.2 writing Dt can be approximated to a slightly bigger factor of the
jog.setValue(10); the average access time. To achieve better performance, the
client.writeVariable(jog); average access time should be continuously monitored and
System.out.println(jog);}
updated. Perhaps, this may be a price to high to pay for some
Algorithm 1: A use-case example that highlights the applications with real-time requirements but JOpenShowVar
differences between the new methods and the deprecated still provides great advantages in terms of flexibility.
sendRequest method. Alternatively, when a custom control algorithm is needed,
the target joint configuration is given by:

operator releases the input device, the end-effector moves qt = qd , (3)

back to its starting point, while in the second scenario, the if operating in position control mode, or by:
arm just stops moving but it keeps the last given position.
qt = qa + q̇d Dt, (4)
To control the robot motion according to the desired op-
erational scenario, JOpenShowVar allows researchers to use if operating in velocity control mode.
the standard kinematics provided with the KRC. However, it When the operator manoeuvres the manipulator, a vector
is also possible to implement alternative control algorithms signal with no semantic, s, is sent from the input device
according to current needs. This is illustrated in Fig. 4-a and to the user program. Here, according to the operational
in Fig. 4-b, respectively. It should be noted that the KRL does scenario, the vector signal is interpreted as the target position
not provide a native way to obtain velocity control. When xt . If the intent is to use the standard kinematics provided
using the KRC kinematics, this limitation can be overcome with the KRC, the user program simply works as a driver
by expressing the target position as: for the input device and uses the writeVariable method of
JOpenShowVar to forward xt to a KRL program where
the standard KRC kinematics is used to calculate the joint
xt = xd , (1) angles qd . Alternatively, a custom control algorithm can be
implemented within the user program to calculate the joint try (CrossComClient client = new CrossComClient("
robotIPaddress", 7000)) {
values for the robot according to xt . Essentially, the custom System.out.println(client.simpleRead("$OV_JOG"));
control method has to implement classic inverse kinematic System.out.println(client.simpleWrite("$OV_JOG",
functions that can be generalised as follows: "90"));}

qd = f p 1 (xd ), (5) Algorithm 2: Use-case for the new simpleRead and

simpleWrite methods.
concerning position control, and try (CrossComClient client = new CrossComClient("
robotIPaddress", 7000)) {
q̇d = fv 1 (qa , ẋd ), (6) double[] torques = client.readJointTorques();}

for velocity control, where qa is the the actual joint angles Algorithm 3: Reading the actual torque for each axis, Java
vector that can be retrieved by using the readVariable method side.
of JOpenShowVar. These values are then forwarded to a
KRL program where the standard KRC functions are used E. Terminal and Graphical user interface
to actuate the robot. Another useful tool that comes with JOpenShowVar is a
Note that the possibility of implementing certain control console terminal that provides read-write text-based access
features does not influence the design for the presented to the robot’s data. It is particularly useful for system
interface. Instead, JOpenShowVar extends the functionalities administration and debugging purposes. To read a variable,
of the KRL language. it is sufficient to type the name of the desired variable and
press enter. From an implementation point of view, it uses the
D. Additional functions new simpleRead and simpleWrite methods. Fig. 5-a shows a
To simplify the low level communication protocol and simple use-case.
improve reliability, some additional methods are provided Besides, JOpenShowVar also offers a useful GUI that can
with the CrossComClient class: be used to monitor the robot’s state, visualise and manually
set variables. A screen shot of this convenient tool is shown
• the simpleRead and the simpleWrite methods are simpler
in Fig. 5-b. This interface is very intuitive for the user.
versions of the sendRequest function. In particular, these
methods do not execute any data parsing as opposed to IV. C ASE STUDIES
the sendRequest method. They allow for an easier and In this section, four case studies are presented to demon-
faster access, as shown in the Algorithm 2 sketch box. strate the potential of JOpenShowVar. The first two case
The two new methods return a raw string without parsing studies are open-loop applications, while the last two case
the information. The aim of these two new methods is studies describe the possibility of implementing closed-loop
to provide an easy way to monitor the status of the robot applications.
making it possible to print the raw information returned
from the KRC; A. Case study 1: controlling the Kuka KR 6 R900 SIXX
• the readJointAngles method uses the readVariable manipulator with an Android mobile device
method retrieve the actual joint angles vector, qa , of the To show the potential of the presented interface in control-
controlled robot, all at once; ling a Kuka industrial robot from an alternative input device,
• the readJointTorques method allows for monitoring the as a first case study, JOpenShowVar is used to control a
load of each joint actuator by retrieving the current Kuka KR 6 R900 SIXX manipulator with an Android mobile
torque of each axis of the arm, all at once. In particular, device. In this case, an open-loop application is implemented
readJointTorques retrieves the global KRL array variable by using the standard kinematics provided with the KRC. The
$TORQUE AXIS ACT and returns the current torque of Kuka KR 6 R900 SIXX, shown in Fig. 6-a, is a 6 DOFs robotic
each axis. This feedback signal is very important in order arm with a slim design and a small footprint.
to improve manipulator dexterity and to achieve crucial According to the operational scenario, an Android mobile
functions like sensitive collision detection and compliant application whose Graphic User Interface (GUI) is shown
control actions. In the Algorithm 3 sketch box, a possible in Fig. 6-b, is used to set the target position xt . By using
use-case is shown. the writeVariable method of JOpenShowVar this vector is
In addition to these methods, some other high-level func- forwarded to the KUKAVARPROXY and stored as a global
tions can be implemented by the user on top of the JOpen- value in a data structure. Finally, a KRL actuator program
ShowVar communication protocol. The implementation of iteratively retrieves the new global data and uses the KRC
some other possible high-level applications is included as a kinematics to actuate the robot. The code of the KRL
technical document in the public repository of JOpenShow- actuator program is shown in the Algorithm 4 sketch box.
Var. For Kuka industrial robots, the idle time between motions
 (a) (b)
(a)

Fig. 6: Case study 1: (a) the Kuka KR 6 R900 SIXX manip-

ulator, (b) the GUI of the Android mobile application used
to control the arm.

system simultaneously ensures that the permissible gear and

motor torques for each axis are not exceeded. Furthermore,
the higher motion profile, set by default, ensures motion that
is optimised in terms of velocity and acceleration.
(b) B. Case study 2: a two-dimensional line-following task with
the Kuka KR 6 R900 SIXX manipulator
Fig. 5: (a) JOpenShowVar terminal can be used for debugging
purposes, (b) JOpenShowVar GUI can be used for monitoring In this case study, JOpenShowVar is adopted to perform
the robot’s state, visualise and manually set variables and a two-dimensional line-following task with the same Kuka
structures. robot used in the previous example. In this case, an open-
loop off-line application is implemented by using the standard
DEF ACTUATOR() kinematics provided with the KRC. The considered task can
INI be used for applications like advanced welding operations
PTP HOME Vel = 100 % DEFAULT
$ADVANCE=1 and similar. In this experiment, a camera is mounted on the
LOOP robot’s end-effector and can capture a photo of the desired
PTP_REL MYPOS C_PTP line to be followed on a plane. This vision feedback is
ENDLOOP
PTP HOME Vel = 100 % DEFAULT used for the off-line detection of the path before starting
END the movement. In particular, once a photo of the line to be
followed is taken, the operator manually selects the desired
Algorithm 4: KRL actuator program for the case study 1.
initial and final points. Then, the A* search algorithm [12]
is used to efficiently find a traversable path between these
can be shortened by executing the time-consuming arithmetic two points within the region covered by the desired line.
and logic instructions between motion commands while the The detected traversable path is sampled with a predefined
robot is moving, i.e. processing them during the advance run resolution and the resulting samples are stored in an array
(the instructions “run” in “advance” of the motion). Using variable. The same array is used as an off-line input for
the system variable $ADVANCE, it is possible to define the robot’s end-effector to be actuated point by point. The
the maximum number of motion blocks that the advance experiment setup is shown in Fig. 7.
run can process ahead of the main run (the motion block
currently being executed). Since the main loop of the Server C. Case study 3: controlling the Kuka KR 6 R900 SIXX
program consists of only one instruction, the system variable manipulator with a Leap Motion Controller
$ADVANCE is initially set to 1 to avoid the unwanted In this case study, JOpenShowVar is used to control the
execution of the same line of code. Inside the main loop, a same robot (from the previous case studies) in a closed-
relative movement is iteratively executed to the global vari- loop and with a custom control algorithm. This is done
able MYPOS, which is the one that stores the target position. to highlight the potential of the presented interface in de-
The key word C PTP is used to approximate the movement. veloping alternative control methods that do not use the
The approximate positioning instruction is executed in a time- standard kinematic model provided by Kuka. Moreover, a
optimised manner: there is always at least one axis moving Leap Motion Controller [9], shown in Fig. 8, is used as
with the programmed acceleration or velocity limits. The alternative input device to control the robot. The Leap Motion
 Camera

Fig. 8: Case study 3: the Leap Motion Controller used to

Arbitrary line to be followed operate the Kuka KR 6 R900 SIXX manipulator.

mode, a movement of the wrist in a particular direction will

produce a translational motion in the same direction at a
velocity proportional to the wrist displacement. In order for
small vibrations not to affect the motion of the robot’s end-
effector, a small spherical imaginary volume with a diameter
of about 8 cm is defined in the centre of the controller
monitoring space. As long as the operator’s wrist is located
Reference points within this volume, the robot’s end-effector does not move.
The operator’s hand has to be moved more than 4cm from
the center of the monitoring space in order to generate a
motion. Thanks to the modularity of the architecture, any
other joystick or input device can be used without influencing
the effectiveness of the proposed interface.
The user program runs on a remote computer and uses the
Fig. 7: Case study 2: the experiment setup for a two- Leap Motion APIs to retrieve the target position xt according
dimensional line-following task with the Kuka KR 6 R900 to the operational scenario. By using the readVariable method
SIXX manipulator. of JOpenShowVar, the actual joint angles qa are received.
This data is used as input for the custom control algorithm.
Controller is a small USB input device that supports hand In this specific case study, the classical kinematic functions
and finger motions as input without requiring contact or and the Jacobian method [13] are used to implement (5)
touching. This controller is designed to be placed on a and (6). Then, by using the writeVariable method of JOpen-
physical desktop, facing upwards. Using two monochromatic ShowVar the target joint configuration qt is forwarded to the
infra-red (IR) cameras and three IR light-emitting diodes KUKAVARPROXY and stored as a global value in a structure.
(LEDs), the device observes a roughly hemispherical area, Finally, a KRL actuator program iteratively retrieves the new
to a distance of about 1 meter. The LEDs generate a 3D global data and actuates the robot.
pattern of dots of IR light and the cameras generate almost The code of the KRL actuator program is shown in the
300 frames per second of reflected data, which is then sent Algorithm 5 sketch box. It should be noted that the variable
through a USB cable to the host computer, where it is MYAXIS is initialised to default values inside the initialisa-
analysed by the Leap Motion Controller software and can tion (INI) fold. The system variable $ADVANCE is initially
be retrieved using the Leap Motion APIs. While the Leap set to 1. Then the current joint values are assigned to a local
Motion Controller makes it possible to control all the joints structure variable named LOCAL. Inside the main loop, the
of human hands, in this specific case study, only the DOFs of desired joint angles are iteratively assigned to LOCAL, axis
the wrist are used as an input signal to control the robot’s end- by axis. Finally, a PTP movement with C PTP approximation
effector. Each DOF of the wrist corresponds to a translational is executed.
axis in the workspace of the robot to be controlled. When
operating in position control mode, the input device works D. Case study 4: controlling the Kuka KR 6 R900 SIXX ma-
as a position proportional replica so that the wrist motion nipulator with a omega.7 haptic device from Force Dimension
maps exactly to the motion of the robot’s end-effector with The aim of this fourth case study is to show the pos-
constant speed, while, when operating in velocity control sibility of operating the robot and transferring the corre-
DEF EXT_MOVE_AXIS()
DECL AXIS LOCAL
INI
PTP HOME Vel = 100 % DEFAULT
$ADVANCE=1
LOCAL.A1 = $AXIS_ACT.A1
...
LOCAL.A6 = $AXIS_ACT.A6
LOOP
LOCAL.A1 = LOCAL.A1 + MYAXIS.A1
...
LOCAL.A6 = LOCAL.A6 + MYAXIS.A6
PTP LOCAL C_PTP
ENDLOOP
PTP HOME Vel = 100 % DEFAULT
END

Algorithm 5: KRL actuator program for the case study 3.

sponding force feedback to the operator. For this purpose, a

bidirectional coupling between a Force Dimension omega.7
[14] haptic device and the same Kuka robot used in the
previous sections is established. In this case, an closed-loop Fig. 9: Case study 4: controlling the Kuka KR 6 R900
application is implemented by using the standard kinematics SIXX manipulator with a omega.7 haptic device from Force
provided with the KRC. The omega.7 is a 7 DOF haptic Dimension.
interface with high precision active grasping capabilities and
orientation sensing. Finely tuned to display perfect gravity
compensation, the force-feedback gripper offers extraordi-
nary haptic capabilities, enabling instinctive interaction with
complex haptic applications. In this case study, the principle
of virtual works [13] is applied. According to this principle,
the following equation is valid:
J T F = t, (7)
where J is the Jacobian matrix of the arm, F is the vector of
forces exerted from the robot’s end-effector to the environ-
ment and t is the vector of torques at the joints that can be
retrieved by using the readJointTorques method. By applying
this principle it is possible to simulate on the haptic device Fig. 10: Case study 2: the detected line and the actual path
a force feedback proportional to the force that the robot’s followed by the robot’s end-effector respectively.
end-effector is supporting. The experiment setup is shown in
Fig. 9. and tablets in research and development is also found in
V. E XPERIMENTAL R ESULTS other areas, as they represent a significant business oppor-
Experiments related to the proposed case studies are car- tunity for manufacturers, who need to consistently develop
ried out to test the proposed communication interface in terms better hardware and operating systems. For these reasons,
of accuracy, performances and effectiveness. these applications are very interesting and appealing in the
Concerning the first and the third case studies, a demo forthcoming industrial applications.
video is available on-line at:
A. Accuracy
https://youtu.be/fC8jb9MKgGw.
The first case study highlights the potential of JOpenShow- Accuracy refers to the possibility of positioning the robot’s
Var in remotely controlling a Kuka industrial robot from an end-effector at a desired target point within the workspace.
Android mobile device. This possibility opens up to a variety Concerning the second case study, the line-following exper-
of useful purposes including human interface applications iment is performed on a randomly generated line, drawn on
and teleoperations. Nowadays, smartphones and tablets are a table. Fig. 10 shows the detected line and the actual path
becoming computationally more and more powerful. In this followed by the robot’s end-effector respectively. Once the
perspective, they are a perfect match with robots for devel- line is detected, the robot executes the movement off-line in
oping alternative control systems. The use of smartphones about 10s with a maximum position error less than 5 mm.
 End−effector tracking, X axis
0.65 16
Actual
Desired 14

0.6 12

10

Delay [ms]
Position [m]

0.55 8

4
0.5
2

0
0.45 0 2 4 6 8 10 12 14 16 18 20
0 2 4 6 8 10 12 14 16 18 20 Time [s]
Time [s]

(a) Fig. 12: Case study 3: time-delay analysis for the correspond-
ing Cartesian paths shown in Fig. 11.
End−effector tracking, Y axis
0.6
Actual Moreover, to assess the communication delay of JOpen-
0.4
Desired
ShowVar, a time-delay analysis is carried out.
0.2
The considered time-delay represents the time for each
message to be received, performed and notified to the client
Position [m]

0
by the KRC. Particularly, this time-delay is obtained by
−0.2 considering the exact instant in which the request is dis-
−0.4
patched from the client and the exact instant in which
the information is received back from the client. It is not
−0.6
possible to exactly determine the time-delay mainly because
−0.8
0 2 4 6 8 10 12 14 16 18 20 Kuka has not released any information about it. During our
Time [s]
experiments, a deterioration of the time-delay has usually
(b) been noticed when making the selection of a program and
End−effector tracking, Z axis
when the robot is engaged in some movements or there are
1
Actual several active interrupts. When considering the causes of the
0.9 Desired
delay, it is possible to distinguish two main components that
0.8
affect the access time for a variable to be either read or
0.7
written from the client side:
Position [m]

0.6
• the time interval that is required for the TCP/IP protocol
0.5
to transfer the information from the client to the server
0.4

0.3
and then back to the client. This time component is non-
0.2
deterministic;
0.1
• the time interval that is required for the Kuka controller
0 2 4 6 8 10
Time [s]
12 14 16 18 20
to acquire the information from the robot. Also this time
component is non-deterministic.
(c)
As already mentioned in Section III, the time-delay is not
Fig. 11: Case study 3: path tracking for (a) the X coordinate, affected by the kind of access to be performed (whether
(b) the Y coordinate and (c) the Z coordinate. it is a reading or a writing operation) or by the length of
the message. Therefore, it is beneficial to aggregate several
variables in logical structures when reading or writing data.
This position error could be reduced even more by increasing By using data structures it is possible to simultaneously
the sampling resolution of the detected traversable path. access several variables, thereby minimising the access time.
Considering the third case study, a time-delay analysis
is carried out for the same Cartesian paths as shown in
B. Performances
Fig. 12. Even though there are a few spikes with a larger
Within the particular case study of the Leap Motion time interval, an average access time of 4.27 ms is obtained
Controller (case study 3), a real-time path tracking analysis of in this case. It should be noted that all the considered case
the Cartesian paths for X, Y and Z coordinates is performed, studies are equally affected by similar communication delays
measuring the difference between the desired and actual except for the second case study which is performed off-line
position of the robot’s end-effector. The results are shown and therefore not presenting any run-time delays.
in Fig. 11. To further assess the performances of the proposed inter-
 C. Effectiveness
Concerning the fourth case study, the aim is to show
the possibility of operating the robot and transferring the
corresponding force feedback to the operator. The plots in
Fig. 14-a and Fig. 14-b show the actual position for the X, Y
and Z axes as a result of the haptic input device’s movements,
operated by the user, and the corresponding joint angles,
respectively. In this particular case, the operator manoeuvres
the robot to lift the end effector up at first, then down again
with a displacement also in the X and Y axes. In this case
study, the input signal is not scaled to the robot’s workspace
since the haptic device is only used to set the direction of
movement for the robot and to transfer the corresponding
force feedback to the operator. Even though there is a delay
between the input signal and the actual position, the results
show that the system is quite responsive to the user’s inputs.
Fig. 14-c and Fig. 14-d show the torques applied to the
robot’s joints and the corresponding forces applied to the
robot’s end-effector, respectively. The operator also perceives
Fig. 13: Target and response of the adopted PID controller
a force feedback that is proportional to forces applied to the
for all the joints of the robot.
robot’s end-effector.

VI. C ONCLUSIONS AND F UTURE W ORK

This paper highlights the features of JOpenShowVar as

face with regard to the communication delay, an additional a cross-platform communication interface to Kuka industrial
experiment is performed. In particular, the possibility of robots. Even though JOpenShowVar only provides a soft real-
developing alternative control methods is considered (as time access to the manipulator to be controlled, this middle-
presented in case study 3). Any custom control algorithm ware package opens up to a variety of possible applications
that does not use the standard KRC kinematics must calcu- making it feasible to use different input devices, sensors and
late the corresponding sampling point configurations for the to develop alternative control methods. Special care has been
desired end-effectors positions. In other words, each control devoted to keep JOpenShowVar methods intuitive and easy
algorithm works as a motion planner. To ensure smooth to use. The versatility and effectiveness of the interface have
movements for the manipulators it is necessary to generate been demonstrated through four case studies. The first two
trajectories out of these given sampling points. A well-suited case studies are open-loop applications, while the last two
trajectory is the basic prerequisite for the design of a high- case studies describe the possibility of implementing closed-
performance tracking controller and ensures that no kinematic loop applications. Recently, our research group employed
nor dynamic limits are exceeded. Such a controller guarantees JOpenShowVar to realise a framework that makes it possible
that the controlled robot will follow its specified path without to reproduce the challenging operational scenario of control-
drifting away. Therefore, feedback control has to be applied ling offshore cranes via a safe laboratory setup [16].
to be able to compensate external disturbances as well as In the future, different control algorithms such as the
disturbances from communication time delays. Note that time ones implemented in [17], [18] and [19] may be tested as
data is a free parameter because, as already mentioned, the alternatives to the standard KRC. Finally, some effort should
sampling time of the mapping algorithm is not constant. be put in the standardisation process of JOpenShowVar to
A possible solution for generating well-suited trajectories make it even more reliable for both the industrial and the
consists of using a Proportional Integral Derivative (PID) academic practice. It is the opinion of the authors that the
controller for each joint. To tune the PID parameters, different key to maximising the long-term, macroeconomic benefits for
methods can be used, such as the one proposed in [15]. The the robotics industry and for academic robotics research relies
response of the adopted PID controller is shown in Fig. 13 on the closely integrated development of open content, open
for all the joints of the robot. The interface provided by standards and open source. In this perspective, the integration
JOpenShowVar demonstrates a relatively fast reaction to the of the proposed interface with ROS is of crucial importance
inputs and reasonable output error for research purposes, as a necessary future work. The community of developers at
considering the dimension of the controlled model. ROS is looking forward to the integration of JOpenShowVar.
 VII. ACKNOWLEDGMENTS
This work is partly supported by the Research Council of
Norway through the Centres of Excellence funding scheme,
project number 223254 and the Innovation Programme for
Maritime Activities and Offshore Operations, project number
217768. R EFERENCES (a)
[1] M. Schopfer, F. Schmidt, M. Pardowitz, and H. Ritter, “Open source
real-time control software for the kuka light weight robot,” in Proc. of
the 8th IEEE World Congress on Intelligent Control and Automation
(WCICA), Jinan, China, 2010, pp. 444–449.
[2] G. Schreiber, A. Stemmer, and R. Bischoff, “The fast research interface
for the kuka lightweight robot,” in Proc. of the IEEE ICRA Workshop
on Innovative Robot Control Architectures for Demanding (Research)
Applications How to Modify and Enhance Commercial Controllers,
2010, pp. 15–21.
[3] KUKA Robotics Corporation. (2014, March) “KUKA”. [Online].
Available: http://www.kuka-robotics.com/
[4] KUKA, Expert Programming. KUKA Robotics Corporation, 2003.
[5] H. Mühe, A. Angerer, A. Hoffmann, and W. Reif, “On reverse-
(b)
engineering the kuka robot language,” in 1st IEEE/RSJ International
Workshop on Domain-Specific Languages and models for Robotic
systems DSLRob’10, International Conference on Intelligent Robots
and Systems (IROS), 2010, pp. 16, 217, 223, 224.
[6] KUKA Robotics Corporation. (2014, March) “KUKA, Hub
technologies”. [Online]. Available: http://www.kuka-robotics.com/
en/products/software/hub technologies/print/start.htm
[7] F. Sanfilippo, L. I. Hatledal, H. Zhang, M. Fago, and K. Y. Pettersen,
“JOpenShowVar: an open-source cross-platform communication inter-
face to kuka robots,” in Proc. of the IEEE International Conference on
Information and Automation (ICIA), Hailar, China, 2014, pp. 1154–
1159.
[8] Google Inc. (2014, March) “Android”. [Online]. Available: http: (c)
//www.android.com/
[9] Leap Motion Inc. (2014, March) “The Leap Motion Controller”.
[Online]. Available: http://www.leapmotion.com/
[10] F. Chinello, S. Scheggi, F. Morbidi, and D. Prattichizzo, “Kuka control
toolbox,” IEEE Robotics & Automation Magazine, vol. 18, no. 4, pp.
69–79, 2011.
[11] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs,
R. Wheeler, and A. Y. Ng, “ROS: an open-source robot operating
system,” in ICRA workshop on open source software, vol. 3, no. 3.2, (d)
2009, p. 5.
[12] D. Delling, P. Sanders, D. Schultes, and D. Wagner, “Engineering route Fig. 14: Case study 4: (a) actual position as a result of the
planning algorithms,” in Algorithmics of large and complex networks.
Springer, 2009, pp. 117–139.
haptic input device’s movements (in this case, the input signal
[13] B. Siciliano and O. Khatib, Springer handbook of robotics. Springer, is not scaled to the robot’s workspace since the haptic device
2008. is only used to set the direction of movement for the robot
[14] Force dimension. (2014, March) “omega.7”. [Online]. Available:
http://www.forcedimension.com/
and to transfer the force feedback to the operator), (b) joint
[15] I. Pan, S. Das, and A. Gupta, “Tuning of an optimal fuzzy PID angles, (c) joint torques and (d) forces applied to the robot’s
controller with stochastic algorithms for networked control systems end-effector.
with random time delay,” ISA transactions, vol. 50, no. 1, pp. 28–36,
2011.
[16] F. Sanfilippo, L. I. Hatledal, H. Zhang, W. Rekdalsbakken, and [19] L. I. Hatledal, F. Sanfilippo, and H. Zhang, “JIOP: a java intelligent
K. Y. Pettersen, “A wave simulator and active heave compensation optimisation and machine learning framework,” in Proc. of the 28th
framework for demanding offshore crane operations,” in Proc. of the European Conference on Modelling and Simulation (ECMS), Brescia,
IEEE Canadian Conference on Electrical and Computer Engineering Italy, 2014, pp. 101–107.
(CCECE), Halifax, Nova Scotia, Canada, 2015, pp. 1588–1593.
[17] F. Sanfilippo, L. I. Hatledal, H. G. Schaathun, K. Y. Pettersen, and
H. Zhang, “A universal control architecture for maritime cranes and
robots using genetic algorithms as a possible mapping approach,”
in Proc. of the IEEE International Conference on Robotics and
Biomimetics (ROBIO), Shenzhen, China, 2013, pp. 322–327.
[18] F. Sanfilippo, L. I. Hatledal, H. Zhang, and K. Y. Pettersen, “A
mapping approach for controlling different maritime cranes and robots
using ANN,” in Proc. of the 2014 IEEE International Conference on
Mechatronics and Automation (ICMA), Tianjin, China, 2014, pp. 594–
599.

View publication stats