Configuration and Control of KMR iiwa Mobile

Robots using ROS2

Charlotte Heggem∗ , Nina Marie Wahl∗ and Lars Tingelstad
Department of Mechanical and Industrial Engineering
NTNU, Norwegian University of Science and Technology
Trondheim, Norway

Abstract—In this paper, we present a novel system for con-

trolling a KMR iiwa mobile robot using ROS2. The KMR iiwa
is a mobile robot with a manipulator mounted on the base that
is developed by the robot manufacturer KUKA. The developed
system integrates with the Sunrise.OS operating system of the
mobile robot and exposes sensor and control interfaces over
UDP and TCP sockets. The controllability of the mobile robot
from ROS2 is verified using the Cartographer and Navigation2
projects.
Index Terms—KMR iiwa, ROS2, KUKA, Mobile Robot, In-
dustry 4.0

I. I NTRODUCTION
Industry 4.0 is about digitalization, automation, machine
learning, and real-time data. A company that works extensively
with industry 4.0 is the German company KUKA, Keller und Fig. 1. The KMR iiwa is composed of a mobile platform and a lightweight
manipulator [2]. Image courtesy of KUKA Nordic AB.
Knappich Augsburg. The company produces robot systems for
the industry and automated production solutions, and focus
on networked, intelligent production. Such a production robot ROS2, Robot Operating System 2, is the second generation
is the KMR iiwa, KUKA Mobile Robot Intelligent Industrial of the open source framework ROS for developing robot appli-
Work Assistant, shown in Figure 1. cations with support for several programming languages and
The KMR iiwa is composed of a robot arm, the LBR iiwa 14 platforms [3]. Integration between Sunrise.OS and ROS2 is
R820, and a mobile platform, the KMP 200 omniMove [1]. desirable as it would limit the required preknowledge required
LBR is a German abbreviation for lightweight robot, while to operate the robot and make it more available for users. The
KMP is short for KUKA Mobile Platform. The intended use ROS2 packages Cartographer and Navigation2 perform real-
of the mobile robot is to handle automated manufacturing tasks time localization, mapping and navigation of mobile vehicles
and transport components, and it is characterized by its high and are highly relevant to use with the KMR iiwa.
degree of mobility and flexibility. Two projects with focus on interaction between the LBR
The operating system for the KMR iiwa mobile robots iiwa and ROS have been inspirational for the work presented in
is KUKA Sunrise.OS. Programming the software requires this paper. The LBR iiwa and the KMP is operated by the same
knowledge of the Java programming language and the Sunrise controller, and hence a similar approach for programming the
software, including robot specific functions. This could be robot can be applied to the KMP.
a blockade for many developers. Another drawback is that Virga and Esposito [4], propose an architecture with native
data and information from the robot are only available locally ROSJava nodes launched on the robot controller. Hence, the
in the Sunrise system during executions of applications. In two operating systems can exchange data and commands in
a decade when everything should be online, compatibility the form of ROS messages over the ROS framework. The
between networked devices is desired, and information should proposed solution requires installation of third-party libraries
be available. Tools that support system integration based on on the robot controller to run ROS nodes.
common platforms are essential for the continuous evolution The work by Mokaram et al. [5] provides a simple stan-
of Industry 4.0. dalone application that requires minimal installation on the
This work was supported by the Norwegian Research Council project robot controller. The architecture of the API consists of two
MANULAB: Norwegian Manufacturing Research Laboratory under grant main components, a single Sunrise.OS application on the robot
269898. controller and a ROS node launched on the external computer.
∗Author names in alphabetical order. Charlotte Heggem and Nina M. Wahl
contributed equally to this work. The ROS node establishes a connection to the controller
over TCP, Transmission Control Protocol. Data and command

978-1-7281-6419-9/20/$31.00 ©2020 IEEE

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.
 messages are transmitted between the two components as B. Software
strings. KUKA Sunrise.OS is the system software for robots that are
The two APIs of [4] and [5] are developed for different operated by the Sunrise Cabinet. It offers functionality for pro-
purposes, but the implementations contain the same funda- gramming and configuration of robot applications. Commands,
mental functionality. The main difference between the two sensor data, and information related to the ongoing operation
architectures is whether to publish ROS messages directly are only available locally on the robot control system, or the
from the robot controller or to utilize a middle-layer to handle supplied teach pendant, the SmartPAD.
the communication. The API of [5] includes simple methods
for directly controlling the robot, while [4] present a more C. Operation
advanced system, including functionality for simulation in There are three different approaches for controlling the
Gazebo and using the robot with ROS packages as Moveit!. KMP: manually, autonomously, or by an application.
Work related to integration of KUKA mobile platforms and The most interesting option in this context is to control
ROS has previously been explored to a small extent. Dömel the KMP by a Java-based Sunrise application on the Sunrise
et. al. present a concept toward fully autonomous mobile Cabinet. The application can be implemented in the program-
manipulation using ROS and KUKA omniRob, built on a ming environment Sunrise.Workbench. The software packages
different control system than the KMR iiwa [6]. However, the KUKA RoboticsAPI and KUKA Sunrise.Mobility contain
project is not open source. methods for obtaining information from the robot system
In this paper, we present a communication interface between and executing motions, which are the basis for developing a
the KMR iiwa and ROS2 to control the mobile platform. The program for controlling the KMP.
developed system integrates with the Sunrise.OS operating KUKA.NavigationSolution is an optional software pack-
system of the mobile robot and exposes sensor and control age with functionality for autonomous navigation of mobile
interfaces over UDP, User Datagram Protocol, and TCP sock- platforms. The navigation software is based on sensor data
ets. The interface is available online [7], and is the first free from the S300 laser scanners and the odometry of the mobile
and open approach to controlling a KMR iiwa using ROS2. platform.
The main functionality is autonomous navigation in an The KMP can be moved manually by jogging the robot
unknown, dynamic environment without collision. The goal from the SmartPAD or the Radio Control Unit, an optional
is that a user should easily be able to connect to the robot device with joysticks for controlling the platform.
and control it without any preknowledge about KUKA robotic The robot system has three different operation modes. T1
systems. and T2 are manual operation modes used for testing and
The paper is structured as follows. A description of the verification of programs. AUT is autonomous mode, which
KMR iiwa is presented in Section II. Further, in Section III, is the operating mode for program execution.
an introduction to ROS2 and the packages Cartographer and
D. Safety
Navigation2 is given. A challenge with the implementation
was to find the correct methods to command and retrieve The primary function of the S300 sensors is to operate as
data from the robot. The approach for obtaining the correct the safety equipment of the system by monitoring predefined
methods is described in Section IV. Next, in Section V, follows areas around the vehicle. By default, the S300 sensors are
a system description with the implemented functionality of the configured with a protective field and a warning field. The size
interface. Section VI presents a verification of the functionality of the monitored fields depends on the velocity of the vehicle.
of developed system. Finally, Section VII concludes the paper. The consequence of a violation of the two fields varies with
the operation mode. Generally, a breach of a field causes a
reduction of maximum travel speed or triggers a safety stop
II. KMR IIWA
of the vehicle. The laser scanners are not active for velocities
A. Hardware below 0.13 m/s in the manual operation modes.

The KMP mobile platform has four mecanum wheels, which III. ROS2
allow the mobile platform to move omnidirectionally. It is ROS [3] is a robot operating system that can be used
equipped with two SICK S300 safety laser scanners mounted with multiple programming languages and has implemented
diagonally opposite of each other. open source functionality. It includes tools and libraries to
The S300 is a compact laser measurement system that scans handle the programming of robots without having to deal with
the environment in two dimensions in the height of 150 mm hardware. The main goal of ROS is to provide a standard
above the ground in means of infrared laser beams. Each laser that can be used by any robot. ROS2, the second generation
has a scanning range of 270°, covering one long side and one of ROS, is state-of-the-art software and is currently under
short side of the vehicle, and a resolution of 0.5°. massive deployment.
The controller of the robot system, Sunrise Cabinet, is In general, ROS2 is cleaner and faster than the prior version,
contained inside the KMP. The Sunrise Cabinet contains two in addition to more flexible and universal. One of the main
PCs: one control PC and one navigation PC. differences between the two versions is that ROS2 is built

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.
 on top of DDS, Data Distribution Service, which provides a relies on the odometry data from the KMP for navigation, this
distributed discovery feature. data can also be subscribed to through the FDI connection.
Two ROS2 packages that are relevant for controlling the As for the motion commands, the predefined methods
KMP is Cartographer [8] and Navigation2 [9]. available from KUKA RoboticsAPI provide functionality for
Cartographer is a package for real-time SLAM, simultane- moving the KMP to an absolute or relative pose. This is not
ous localization and mapping, and is part of Google’s open applicable for the intended use, as Navigation2 sends velocity
source projects [10]. commands.
A map can be created based on the robot’s odometry, trans- The approach leading to the proposed solution was to
formation information, and sensor information when the robot investigate the underlying code of the devices used to jog
moves. The map can further be provided to Navigation2 and be the KMP manually. When a jogging button is held on the
used for navigation in the environment. The requirement for smartPAD or the joysticks are used to move the robot with
the cartographer node is sensor data measuring the distance the Radio Control Unit, the robot is continuously jogged. In
to obstacles in the environment. Data from IMU sensors and a similar manner, a jog method can be executed continuously
odometry sensors can be included to improve the result. from a Java program to make the robot move with the specified
Navigation2 is a package that can be used to control mobile velocity. The method found to jog the robot enabled access to
robots and is based on a velocity controller. The main goal of the internal functionality of the robot, which is mainly marked
applying the package is to navigate the robot from a start as private and not intended to use for programming by external
pose to a goal pose. This task can be broken down into users.
subtasks like handling maps, localization of the robot, obstacle By investigation of the source code, it was found that
avoidance, and path following. When an obstacle-free path is for each time the jog method is executed, a new thread is
calculated, velocity commands are produced to describe how established. As the method is intended for internal use, the
the robot should move to follow the path. The navigation threads are marked as private, and there is no way to handle all
package requires information about the environment and how the threads established when continuously calling the method.
the robot moves, which can be provided in the form of a map, Over time this lead to an accumulation of threads, which
sensor data, and odometry data. is a problem when the number of threads get too high. A
solution to this problem was found in the code of the Radio
IV. A PPROACH Control Unit, which revealed that a support class had to be
The information required by Cartographer and Navigation2 implemented to handle the threads. The support class creates
defines the functional requirements of the system: It must be a thread pool for each new jogging execution, which can be
possible to retrieve odometry from the wheel encoders and shut down when the velocity motion is finished, and hence,
laser data from the SICK scanners on the KMP, and the vehicle kill all the threads established.
must be able to be controlled by velocity messages. With the jogging motion it is possible to execute motion
The motion commands and sensor retrieval methods from based on velocity commands, which further makes it possible
KUKA RoboticsAPI are limited and are chosen based on to move the KMP by the commands from Navigation2.
KUKA’s definition of what is the intended use for pro-
V. S YSTEM D ESCRIPTION
gramming the robot. A challenge that was faced during the
development was to find the appropriate methods to retrieve The implemented interface has the following main function-
data and move the KMP for the desired outcome. alities:
As mentioned in Section II-D, the main functionality of • Retrieve laser data from the KMP
the laser scanners is to monitor predefined areas around the • Retrieve odometry data from the KMP
vehicle. Boolean signals from the lasers indicate whether • Retrieve status information from the KMP
the monitored fields are violated, and can be extracted • Move the KMP by giving velocity commands in the
through defined methods from the KUKA RoboticsAPI. Range terminal
data from the laser scanners are only available through • Move the KMP by setting a goal pose in the terminal
KUKA.NavigationSolution, and there are no direct methods • Use Cartographer to create a map of the environment
to retrieve sensor data through KUKA RoboticsAPI. • Use Navigation2 to move the KMP
The correct method for retrieving the sensor data was The interface consists of multiple ROS2 nodes running on
found by investigating the underlying functionality of a remote PC communicating with a Java program over TCP.
KUKA.NavigationSolution. This software package introduces The remote PC does not need to be in the immediate vicinity
several views that can be opened in Sunrise Workbench, of the KMR, but must be connected to the same network.
among them are the LaserView that visualizes range readings The Java program, KMRiiwaSunriseApplication, is installed on
in real-time. By exploring the source code of the view, it the Control PC in the Sunrise Cabinet, which handles further
was found that a FDI, Fast Data Interface, connection is communication with other internal devices on the robot. The
established to the Navigation PC. The FDI connection utilizes physical architecture is shown in Figure 2.
a UDP socket to transmit data and enables functionality Figure 3 shows the architecture of the implemented com-
for subscribing to sensor data. As KUKA.NavigationSolution munication interface between the Java application and the

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.
 the protocol options TCP and UDP for handling the socket
objects and transmitting data. Each of the Java communication
classes establishes a socket class to transmit the data to the
corresponding ROS2 node.
The kmp sensor reader class is handling both the data
from the S300 laser sensors and the odometry data. An FDI
connection, which is used to transmit odometry and laser
data, is established between an instance of the class and the
Navigation PC. The FDI connection is based on subscriptions,
meaning a data type is only sent if a subscription to the data
type is created. This makes it possible to subscribe to only
laser or odometry data. A data listener class is implemented
that, by subscribing to the data of interest, retrieves odometry
Fig. 2. Graphical representation of the physical system. Component images data and laser data through the FDI connection. Further, the
courtesy of KUKA Global.
data is transmitted to the two corresponding ROS2 nodes.
The kmp status reader use functionality from KUKA
ROS2 nodes. Each node is responsible for one area and is RoboticsAPI to retrieve information from the robot. Examples
communicating with a corresponding Java class on the Sunrise of information that can be retrieved are whether an emergency
Cabinet over UDP or TCP. Both protocols are implemented, stop has been triggered and if there are any obstacles in the
and the desired communication type can be set in the system monitored fields.
parameters. By creating separate nodes and connections for The kmp commander receives velocity or pose commands
all tasks, it is possible to launch only the nodes needed for a from the corresponding ROS2 node. Pose commands are
specific use case. This limits the transferred data and enables executed by the motion type MobilePlatformRelativeMotion
a faster system. from KUKA RoboticsAPI, while velocity commands are being
The information is transmitted with the selected protocol as carried out by jogging the robot. More specific this is done
strings on the following format: by a KMPJogger object, which is implemented to handle the
execution of motion and the accumulation of threads.
Length > T ype (LaserID) T imestamp Data
| {z } | {z }
Additional Message B. Remote PC
Information
On the remote PC, there are four different nodes available
The additional information, Length, is only included if the for communication with the KMP: kmp odometry, kmp laser,
message is sent over TCP. As TCP is a buffer protocol, this kmp command and kmp status.
is necessary to ensure that the whole message is read. All the nodes have data process methods and ROS publish-
The Type field describes what kind of data this message ers and subscribers to correctly handle the data to and from the
includes, and is necessary to know how the data should KMP. All the publishers and subscribers, and the associated
be processed. If the message is coming from the robot, an ROS topic are listed in Table I and II.
example of a type could be Odometry. An odometry message The kmp odometry and kmp laser nodes handle the sensor
contains data describing the pose and velocity of the robot. information retrieved from the KMP, while the kmp command
The pose of the robot is represented by a position vector subscribes to multiple ROS topics and forwards the commands
x ∈ R3 and a unit quaternion q ∈ S 3 , while the velocity is from each topic. The currently supported commands are: move
represented by a twist V = (ω, v) ∈ R6 where ω ∈ R3 and with a certain velocity, move to a given pose, and shutdown.
v ∈ R3 are the angular and linear velocities, respectively. The shutdown command is essential to be able to shut down
The LaserID only applies for laser scan messages to denote all connections and threads in the program correctly.
from which sensor the data is read. The data, in this case, The kmp status retrieves information data from the KMP
consist of 540 range readings from the specified laser. and saves the information to a ROS message, KmpStatusdata.
Similarly, a message of type setTwist can be sent, command- This message type is custom made for the interface and
ing a change in the velocity of the robot. includes information that is useful when operating the robot.
A. Sunrise Application The message could be extended with more information if
necessary. The KmpStatusdata includes the information shown
The KMRiiwaSunriseApplication is the main application
in Table III.
running on the Sunrise Cabinet. The Java classes communi-
cating with ROS2 are initiated from the application as threads
VI. S YSTEM V ERIFICATION USING C ARTOGRAPHER AND
and executed in parallel. The Java classes are responsible for
NAVIGATION 2
sending sensor data and other relevant information, and for
carrying out the pose or velocity commands received from The ROS packages Cartographer and Navigation2 are used
the ROS2 nodes. Support classes are implemented for both to verify if the communication and control work as expected.

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.
 Fig. 3. Architecture of the implemented solution.

TABLE I
P UBLISHERS FOR PUBLISHING DATA FROM KMP TO ROS

Name Message type Topic Description

pub odometry Odometry /odom Odometry information.
pub laserscan1 LaserScan /scan 1 Data from B1 S300 laser (front).
pub laserscan2 LaserScan /scan 2 Data from B4 S300 laser (back).
pub kmp statusdata KmpStatusdata /kmp statusdata Statusdata retrieved in the kmp status node.

TABLE II
S UBSCRIBERS FOR SUBSCRIBING TO DATA FROM ROS TO KMP

Name Message type Topic Description

sub twist Twist /cmd vel Make KMR move at a certain velocity.
sub pose Pose /pose Make KMR move to a certain pose.
sub shutdown String /shutdown Make the application on the Sunrise controller shut-
down. Any string sent to this topic do the same
purpose.

TABLE III
F IELDS INCLUDED IN A KmpStatusdata MESSAGE

Name Message type Description

header std msgs/Header Regular header for all ROS messages.
operation mode String The KMR iiwa has three different operation modes. This field states the current mode.
ready to move Boolean True if the robot is ready to move, and no safety rules is violated.
warning field clear Boolean False if either of the warning fields of the S300 sensors are violated.
protection field clear Boolean False if either of the protection fields of the S300 sensors are violated.
is kmp moving Boolean True if the KMP is moving.
kmp safetystop Boolean True if the KMP performs a safety stop. This happens if any of the internal safety
monitoring functions of Sunrise software are violated.

Both packages include parameter files with multiple parame- which includes sensor data from both S300 sensors as well as
ters that can be tuned to improve the algorithms used. These odometry data.
parameters are minimally tuned for this experiment, and only By driving the robot around in the laboratory and using
the parameters necessary for the packages to work with our Cartographer, the map in Figure 4 was created. Tuning the
data have been changed. All available data sources are used, parameters to a more significant extent would likely improve
the result, but was not relevant for testing the communication

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.
 protective field. The velocity should be reduced when an
obstacle is detected in the warning field to reduce the size of
the protective field. If necessary, a second warning field can be
configured by the use of SICK software, to be notified about
obstacles earlier. This could solve the problem, but would lead
to a less generic system.
VII. C ONCLUSION
This paper describes a control interface for operating the
mobile robot KMR iiwa with ROS2. The proposed architecture
is verified by a proof-of-concept implementation that enables
control of the robot from an external computer. The architec-
ture is based on multiple ROS2 nodes with corresponding Java
classes that handle separate tasks. The architecture is created
in a scaleable manner, where more nodes can be added for
additional functionality.
Fig. 4. Map created by Cartographer
It was desired to navigate the robot by utilizing the ROS2
packages Cartographer and Navigation2. For this purpose,
interface. As mentioned in section II, the SICK scanners functionality was implemented to retrieve odometry and laser
perform a planar scan 150 mm above the ground. This affects data from the sensors, and for the ability to control the model
the map, as overhanging obstacles are not detected. Hence, by velocity commands. The specified ROS2 packages were
additional sensors should be included in the system to be able used to verify the controllability of the mobile vehicle. The
to perform autonomous navigation safely. Cartographer package was able to create a fully recognizable
The compatibility with Navigation2 was verified by entering map of the environment, and simple navigation in the environ-
a goal pose in Rviz to which the KMP was to navigate. ment was performed. The verification revealed issues related
The goal pose is sent to Navigation2 which returns velocity to navigation closer to obstacles, and a possible solution for
commands. The use of Navigation2 works as expected for this was proposed.
more straightforward scenarios. When commanded to navigate Further work include manipulation of the LBR iiwa, im-
to poses in open areas, the robot moves with holonomic proved navigation, and the addition of camera sensors to
movement and follows the planned path until the requested handle issues related to 2D laser scans.
goal pose. When the goal pose is set too close to obstacles, The work is open source and available online at https://
the navigation is not completed. github.com/ninamwa/kmriiwa ws.
The maximum velocity specified in the parameter file of R EFERENCES
Navigation2 are above 0.13 m/s, which is the velocity where
[1] KUKA. KMR iiwa omniMove, 2019. https://xpert.kuka.com/app/portal.
the sensors are activated for T1 mode. If the sensors detect [2] Direct Industry. KMR IIWA. https://www.directindustry.com/prod/
an object inside the protective field when driving at a speed kuka-ag/product-17587-1714901.html, 2016. The image is used with
higher than this, the safety restriction of the robot turns in and permission from KUKA Nordic AB. Accessed: 2020-03-13.
[3] Morgan Quigley, Brian Gerkey, Ken Conley, Josh Faust, Tully Foote,
stops the movement. This causes the navigation to fail, as the Jeremy Leibs, Eric Berger, Rob Wheeler, and Andrew Ng. ROS: an
vehicle is not following the given commands and not showing open-source Robot Operating System. In Proc. of the IEEE Intl. Conf. on
enough progress within a time limit. The vehicle is not able to Robotics and Automation (ICRA) Workshop on Open Source Robotics,
Kobe, Japan, May 2009.
drive out of this area as all the commands from Navigation2 [4] Salvatore Virga and Marco Esposito. IFL-CAMP/Iiwa Stack. https:
are at a higher speed than allowed by the robot. //github.com/IFL-CAMP/iiwa\ stack, 2019. Accessed: 2019-11-07.
When the KUKA Navigation Solution controls the vehicle, [5] Saeid Mokaram, Jonathan M. Aitken, Uriel Martinez-Hernandez, Iveta
Eimontaite, David Cameron, Joe Rolph, Ian Gwilt, Owen McAree,
the velocity is automatically reduced when objects are inside and James Law. A ROS-integrated API for the KUKA LBR iiwa
the protective field. Navigation2 does not implement this collaborative robot. IFAC-PapersOnLine, 50(1):15859 – 15864, 2017.
behavior, and this causes a conflict between the built-in safety 20th IFAC World Congress.
[6] Michael Kaßecker Manuel Brucker Tim Bodenmüller Andreas Dömel,
restrictions and the navigation controller. To make Navigation2 Simon Kriegel and Michael Suppa. Toward fully autonomous mobile
work optimally, this must be taken into account. Newly manipulation for industrial environments. International Journal of
implemented behavior in Navigation2 makes it possible to Advanced Robotic Systems, 2017.
[7] Charlotte Heggem and Nina Marie Wahl. Project repository: kuka ws.
update the parameters which specify the maximum velocities https://github.com/ninamwa/kmriiwa ws, 2019.
dynamically. [8] W. Hess, D. Kohler, H. Rapp, and D. Andor. Real-time loop closure in
Our suggested solution to the navigation problem is to 2D LIDAR SLAM. In 2016 IEEE International Conference on Robotics
and Automation (ICRA), pages 1271–1278, 2016.
monitor the status of the warning fields and protective fields, [9] ROS2 Navigation. https://ros-planning.github.io/navigation2/. Accessed:
which both are included in the KmpStatusdata message, and 2020-03-27.
use this information to control the velocity. For both operation [10] Cartographer. https://opensource.google/projects/cartographer. Ac-
cessed: 2020-03-27.
modes, the robot stops if an obstacle is detected in the

Authorized licensed use limited to: The Chinese University of Hong Kong CUHK(Shenzhen). Downloaded on September 09,2024 at 13:38:59 UTC from IEEE Xplore. Restrictions apply.