IEEE Robotics & Automation Magazine - September 2010 - 24

The PR2 robot is designed to do
human-scale tasks in environments
where people are present.
A key criterion for the selection was promised open-source
contributions back to ROS, and we expect that the robotics
community will benefit greatly from the work of these groups
over the next two years. The groups will leverage the core
capabilities that have already been put into ROS. In the next
section, we will explore one particularly powerful such capability, the transform library (TF).

Using the ROS TF on PR2
Robots like the PR2 move around in and manipulate the
three-dimensional (3-D) world. They have to reason about
how the sensor reading taken one second can be used to
manipulate an object some time later, while the linkage
between the sensor platform and the robot's hand moves in
arbitrary ways. The ROS TF library (named for either TransForm or for its author Tully Foote) is designed to make this
common problem trivial. TF is part of the ROS base functionality and is useful on a wide variety of robot hardware.
TF is a coordinate frame-tracking system designed to work
with distributed systems such as ROS. Frames are parts of the
robot or the environment that contain a unique coordinate
system. A robot like the PR2 has a large number of frames:
one for each camera, one for the base of the robot, one or
more for the maps the robot keeps of the environment, and
one for each link in each arm. The key idea behind TF is that
individual components can publish their own frames, so that
one program can monitor the joints of the robot and report
frames for them, another program can report the frame for the
map, and yet another can publish frames for objects that are
being tracked.
Let us look at a simple example. Imagine a simple planar
robot moving through a flat world. We can talk about the
robot moving from Point A to B, but even that simple way of
speaking presumes a coordinate frame in which A and B are
defined. A and B could be defined in the map frame, but,
when we program the robot to move from A to B, we need to
think in terms of the robot's frame, and the crux of the program is often transforming the goal B into robot coordinates
instead of map coordinates.
As the robot moves from A to B, it will observe objects at
different times. Its range sensor might detect an object at one
time and another object half a second later. TF lets a programmer easily transform the sensor-centric coordinates of those
readings into map coordinates, compensating for time, so that
the programmer can build an accurate model of the world. In
a much more complicated robot like the PR2, this means that
we can use a camera embedded in the forearm to detect a wall
24

IEEE Robotics & Automation Magazine

outlet and register its coordinates in the frame of the robot's
base, and then move that arm to a position where it can grasp a
plug and robustly insert the plug into the outlet. It also means
that making the robot's parts move in harmony is a trivial
programming task. The code sample below is a simple ROS
Python program for pointing the PR2's head at a point in
space. Lines 1-4 just set up the program's environment by
bringing in the relevant modules. Line 6 creates a new ROS
node called move_the_head. Lines 8-10 use ActionLib
to create a simple controller that will aim the head at a goal.
(ActionLib will be the subject of a future column and is
already the subject of a number of tutorials on ros.org.)
1 import rospy
2 from actionlib import SimpleActionClient
3 from pr2_controllers_msgs.msg import
PointHeadAction, PointHeadGoal
4 from geometry_msgs.msg import Point
5
6 rospy.init_node('move_the_head')
7
8 client = SimpleActionClient(
9 '/head_traj_controller/point_head_
action', PointHeadAction)
10 client.wait_for_server()
11
12 g = PointHeadGoal()
13 g.target.header.frame_id = 'base_link'
14 g.target.point = Point(1.0, 0.0, 1.0)
15 g.min_duration = rospy.Duration(1)
16
17 client.send_goal(g)
18 client.wait_for_result()
For purposes of this article, the interesting lines are 12-15,
and especially line 13. Line 12 creates a PointHeadGoal that
can be passed to the head controller (client). How do we
express that goal? We express it with respect to a frame. In line
13, the frame_id is set to base_link, which is welldefined on the PR2, the base of the robot. So far, this example
is a bit boring. Line 14 sets the goal to (1.0, 0.0, 1.0) relative to
the base of the robot, and if we run the example, the robot
would stare off at a point in space. By adjusting the (x,y,z) of the
goal, we could make the head stare at a different point in space.
What is really cool is that TF allows us to automatically reason about lots of other interesting points that the robot implicitly
knows about. Instead of using base_link, we could ask the
robot to point the head at (0.0, 0.0, 0.0) of r_gripper_r_
finger_tip_link (the right gripper's right finger tip) and
without any more thought we run the program and the robot
looks at its right hand. Furthermore, it is a trivial adaptation to
the program to add a loop so that the head follows the hand
where ever it moves. And that simple 20-line program will
make the head follow the hand, no matter whether the hand is
being commanded to move by another program or moved by a
person touching the robot. Similarly, by using a map frame, the
SEPTEMBER 2010

http://www.ros.org

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2010