IEEE Robotics & Automation Magazine - June 2011 - 78

Figure 8. The second demonstrator. A robot serves a drink to a
patient in a mock-up hospital room. By using prior knowledge
stored in RoboEarth the robot could improve its navigation,
object perception, and object manipulation capabilities and
could efficiently serve a drink. (Photo courtesy of RoboEarth
Consortium.)

stored them in the Q-matrix. If the robot did not reach the
target field, it updated the value of its previous field with a
small movement cost. Once it did reach the target field, the
robot updated the entire Q-matrix [57] and uploaded it to
the RoboEarth database (see the "Architecture: Database"
section) hosted on a remote server. Subsequent robots
exploring the maze first downloaded the latest version of the
Q-matrix from the RoboEarth server and then used it to
guide their maze exploration. Upon successful arrival at the
target field, they similarly updated the Q-matrix with their
knowledge and reuploaded it to RoboEarth.
Following multiple iterations of downloading the Q-matrix,
navigating through the maze, and sharing of the improved Qmatrix, the values of the matrix converged. At the end of
experiment, the converged matrix allowed all robots to move
through the maze using the shortest path. (Videos of the
demonstrator can be accessed at http://www.roboearth.org.)
Second Demonstrator
In a second demonstrator, a robot was asked to serve a drink
to a patient in a mock-up hospital room (Figure 8). At the
beginning of the experiment, the robot was preprogrammed
with skills for movement, perception, and mapping (described
in detail in the "Architecture: Generic Components-Semantic Mapping" section). However, it did not have any prior
knowledge about its environment, relevant objects, or tasks.
At the start of the experiment, the written command ServeADrink was sent to the robot. The robot's action execution component (described in detail in the "Architecture:
Generic Components-Action Execution" section) received
and used the RoboEarth communication interface (see the
"Architecture: Interfaces" section) to remotely access the
RoboEarth database (see the "Architecture: Database" section). Similar to robot B mentioned in the example scenario in
the "RoboEarth: Example Scenario" section, the robot then
downloaded the relevant details, including the corresponding
ServeADrink action recipe. Further relevant details were
78

IEEE ROBOTICS & AUTOMATION MAGAZINE

JUNE 2011

determined using logical reasoning based on a local knowledge base, a KnowRob installation [40]. As a result, the robot
retrieved a map of the hospital room, approximate object positions gathered from previous trials, as well as perception and
manipulation models for the cupboard, the bed, and the bottle
(cf. Figure 6). The perception models were sent to the robot's
semantic mapping component (see the "Architecture:
Generic Components-Semantic Mapping" section), which
started looking out for the given object. All perception
instances were routed to the world modeling component
(see the "Architecture: Generic Components-Environment Modeling" section), which was responsible for asserting the world state in the local knowledge base. The map
was used by the robot's localization component to safely
navigate the hospital room. The action execution component itself internally built a state machine from the action
recipe and used it to trigger and monitor the execution of
action primitives (see the "Architecture: Skill Abstraction
Layer and Robot-Specific Components" section).
Despite differences between the downloaded information, such as changes in the map and variations in object
locations, RoboEarth's world modeling component
allowed the robot to use the downloaded information as a
prior. For example, the last known location of the bottle
was asserted in the local knowledge base and could be
queried by the action execution framework to parameterize
the moveTo action primitive as part of the MoveBaseToGraspPose subaction (Figure 5). This led to a bias of
the robot's search strategy toward the most promising
areas of the map. Similarly, downloading the known
dimensions of the bed meant that detection of a single side
of the bed was enough to provide occupancy information
even for areas not covered by the prior map and not yet
visited by the robot. The model of the bottle allowed the
robot to reliably recognize and locate the bottle (Figure 6),
use a suitable grasp point to pick it up, and apply a suitable
grasp force. (Videos of the demonstrator can be accessed at
http://www.roboearth.org.)
Third Demonstrator
In a third demonstrator, a compliant robot arm with accurate sensing capabilities was used to learn articulation models [58] for the drawers and doors of a cupboard (Figure 9).
In a first step, a reference trajectory for the robot arm was
generated based on an initial guess for the unknown articulation model. In subsequent steps, measurements of the
compliant arm's deviation from this reference trajectory
were used to continuously refine the model estimate in a
closed-loop control structure. At the end of this learning
stage, the learned articulation model of a specific door
instance was attached to the door's object description and
uploaded to the RoboEarth database.
In a second step, a service robot with less accurate sensing capabilities downloaded the stored articulation model
and its parameters (e.g., door radius and axis of rotation)
from the RoboEarth database. Using this knowledge, this

http://www.roboearth.org http://www.roboearth.org

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