IEEE Robotics & Automation Magazine - June 2011 - 77

and a request for user input, an operator uses a joystick to
control the arm of the robot to open the door and creates an
action recipe for "open a hospital room door." Sometime
later, robot B may encounter the closed door of the hospital's kitchen area. The recognition and labeling component
can now help this robot to detect that both situations are
similar and, upon successfully opening the kitchen door,
update the action recipe to reflect that knowledge.
Skill Abstraction Layer
and Robot-Specific Components
The skill abstraction layer (Figure 1) provides a generic
interface to a robot's specific, hardware-dependent functionalities. This is achieved by abstracting a robot's underlying hardware to offer a subset of standardized skills (e.g.,
MoveTo, MoveCloseToObject, Grasp, or Detect), sometimes also referred to as movement primitives, perception
primitives, basis behaviors, or macro actions [51]. Skills
accept input parameters, for example, to set the end goal of
a movement or to define a grasp point. By providing a
common interface to higher-level commands, skills play a
key role in allowing the robots to successfully share and
reuse action recipes. The specific subset of skills available
in a specific robot is an important factor when selecting
among different action recipes to perform a task.
For example, robot A may be equipped with an omnidirectional platform, whereas robot B may have a parallel
drive. Using their respective MoveTo skills, both robots
can nevertheless execute the same action recipe.

the RoboEarth database. Each robot also used RoboEarth's
generic components for environment modeling (more
details can be seen in the "Architecture: Generic Components-Environment Modeling" section) and learning (see
the "Architecture: Generic Components-Learning" section for more details) to improve its maze navigation.
Robots navigated the maze in turns. Each robot started
on a predefined starting field and was allowed to continue
moving through the maze until it reached a predefined target field.
To collaboratively learn the optimal path through the
maze, the robots used Q-learning [57], with Q-learning
states represented by the maze cells and Q-learning actions
by the four-motion skills. At the start of the experiment, the
first robot began moving through the maze using a random
walk strategy. After each step of its navigation, the robot
surveyed its four adjacent maze fields for obstacles and

Demonstrators
To provide a proof of concept of the benefits of sharing
information via RoboEarth, we have implemented three
prototypical demonstrators so far. The demonstrators used
a knowledge base with reasoning engine based on KnowRob [40], the robot operating system (ROS) [52] for communication between generic components, and various
robot-specific functionalities.
First Demonstrator
In a first demonstrator, two types of robot with different
hardware and software configurations were tested in a
maze exploration task (Figure 7). Both types of robot were
preprogrammed with a basic set of skills using their respective RoboCup code [53], [54]. The skills were move 1 m
forward, move 1 m back, move 1 m to the right, and move
1 m to the left. Both types of robot could autonomously
detect maze fields blocked by black obstacles (a fifth skill)
and used their respective RoboCup code for navigation
and localization (i.e., the posters and red lines were not
used). However, each robot was controlled by a generic
action execution component (see the "Architecture:
Generic Components-Action Execution" section for
details), which coordinated the interaction of other robotunspecific components, the execution of low-level, hardware-specific skills, and the exchange of information with

(a)

(b)
Figure 7. (a) Setup for the first demonstrator. A 6 3 8 m maze
consisted of 48 square fields outlined using red lines. Robots
tried to find the shortest path from a predetermined starting
field (indicated by the red cross) to a predetermined target field
(indicated by the green cross) while avoiding blocked maze
fields (indicated by black markers on the ground). (b) The two
different robot platforms used [55], [56]. The University of
Stuttgart's and the Technical University of Eindhoven's (USTUTT)
RoboCup robots (first and third from left) use four omniwheels
rather than the three omniwheels used by TU/e's robots. Both
types of robots also use different robot operating software,
preventing a direct transfer and reuse of knowledge. By defining
a common set of hardware-specific skills, both types of robots
could share a simple action recipe and information about their
environment via RoboEarth. (Photo courtesy of RoboEarth
Consortium.)

JUNE 2011

IEEE ROBOTICS & AUTOMATION MAGAZINE

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - June 2011