Pr2 Manual r306

PR2 user manual
Willow Garage
November 12, 2010

2
Contents
1 Introduction 7
1.1 Before you start . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Safety 9
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Design Features . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 General Usage Guidelines . . . . . . . . . . . . . . . . . . . . 10
2.4 Safety Program . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 PR2 hardware 17
3.1 What’s in the box . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 PR2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 Accessory kit . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 Large calibration target . . . . . . . . . . . . . . . . . 21
3.1.4 Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.5 Base-station computer . . . . . . . . . . . . . . . . . . 21
3.2 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Links and Joints . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Drivetrains . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4 Motion control . . . . . . . . . . . . . . . . . . . . . . 30
3.2.5 Mechanical specs . . . . . . . . . . . . . . . . . . . . . 32
3.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Base Laser . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Tilting Laser . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.3 Head Cameras . . . . . . . . . . . . . . . . . . . . . . 37
3.3.4 Forearm cameras . . . . . . . . . . . . . . . . . . . . . 37
3.3.5 Gripper Sensors . . . . . . . . . . . . . . . . . . . . . . 38
3.3.6 Inertial measurement unit . . . . . . . . . . . . . . . . 38
3
4 CONTENTS
3.3.7 Speaker . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Power system . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.2 Power Busses . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.3 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.4 Power Board . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.5 Run/Stop controls . . . . . . . . . . . . . . . . . . . . 43
3.4.6 Power for sensors . . . . . . . . . . . . . . . . . . . . . 44
4 PR2 Computers 45
4.1 Computer hardware . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 Computer 1 (c1) . . . . . . . . . . . . . . . . . . . . . 45
4.1.2 Computer 2 (c2) . . . . . . . . . . . . . . . . . . . . . 46
4.1.3 Basestation . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Network segments . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Network Explanation . . . . . . . . . . . . . . . . . . . 48
4.2.3 Service Port . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.4 WAN port . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.5 Wireless access point . . . . . . . . . . . . . . . . . . . 50
4.2.6 Wireless router . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Computer Configuration . . . . . . . . . . . . . . . . . . . . . 50
4.3.1 BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2 Networking . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.3 NFS and Unionfs . . . . . . . . . . . . . . . . . . . . . 52
4.3.4 autofs . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.5 Home directories . . . . . . . . . . . . . . . . . . . . . 53
4.3.6 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.8 Default user account . . . . . . . . . . . . . . . . . . . 55
4.3.9 Creating user accounts . . . . . . . . . . . . . . . . . . 55
4.3.10 User groups . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.11 Backing up and restoring users . . . . . . . . . . . . . 56
4.3.12 Clock synchronization . . . . . . . . . . . . . . . . . . 56
4.3.13 Configuring the System ROS installation . . . . . . . 57
4.3.14 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.15 Udev . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Basestation Setup and Pairing . . . . . . . . . . . . . . . . . 58
4.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.2 Plugging things in . . . . . . . . . . . . . . . . . . . . 60
CONTENTS 5
4.4.3 Configure the Basestation Network . . . . . . . . . . . 60

4.4.4 Configure the Robot Wifi . . . . . . . . . . . . . . . . 62
4.4.5 Initialize the Basestation VPN Server . . . . . . . . . 63
4.4.6 Pairing with the Robot . . . . . . . . . . . . . . . . . 63
4.4.7 Forwarding IPs to the robot . . . . . . . . . . . . . . . 65
4.5 Reinstall the Basestation . . . . . . . . . . . . . . . . . . . . . 66
4.5.1 Booting off the USB installer . . . . . . . . . . . . . . 67
4.5.2 Booting off the DVD installer . . . . . . . . . . . . . . 67
4.6 Reinstall the Robot . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6.1 Forcing netboot . . . . . . . . . . . . . . . . . . . . . . 68
4.7 Software Maintenance . . . . . . . . . . . . . . . . . . . . . . 69
4.7.1 Fixing the nvidia module . . . . . . . . . . . . . . . . 69
4.8 Default Password Reference . . . . . . . . . . . . . . . . . . . 70
5 Setting up PR2 in your lab 71

5.1 Taking PR2 out of the crate . . . . . . . . . . . . . . . . . . . 71
6 Running the PR2 77

6.1 Getting set up . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.1 Out of the box . . . . . . . . . . . . . . . . . . . . . . 77
6.1.2 Batteries and power . . . . . . . . . . . . . . . . . . . 77
6.1.3 Run-stop . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.1.4 Getting an account . . . . . . . . . . . . . . . . . . . . 78
6.2 Turning on PR2 . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2.1 Logging in . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.2 Checking for other users . . . . . . . . . . . . . . . . . 80
6.3 Starting the software . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.1 Starting the software the easier way . . . . . . . . . . 81
6.3.2 Starting the software the manual way . . . . . . . . . 81
6.4 Running the dashboard . . . . . . . . . . . . . . . . . . . . . 82
6.4.1 Understanding pr2 dashboard . . . . . . . . . . . . . . 83
6.5 Calibrating the joints . . . . . . . . . . . . . . . . . . . . . . . 85
6.6 Tucking the robot arms . . . . . . . . . . . . . . . . . . . . . 86
6.7 Driving with the joystick . . . . . . . . . . . . . . . . . . . . . 86
6.8 Visualizing sensor data . . . . . . . . . . . . . . . . . . . . . . 88
6.9 What next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.10 Putting Away the PR2 . . . . . . . . . . . . . . . . . . . . . . 89
6 CONTENTS
7 Writing code on PR2 91

7.1 Installing code in user-space . . . . . . . . . . . . . . . . . . . 91
7.1.1 Installing another repository in user-space . . . . . . . 91
7.1.2 Creating a package . . . . . . . . . . . . . . . . . . . . 92
7.1.3 Using a local version of a stack . . . . . . . . . . . . . 92
7.2 Where to Start . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.1 Documetation and Tutorials . . . . . . . . . . . . . . . 92
7.2.2 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . 93
8 Maintaining PR2 95
8.1 Installing upgraded stacks . . . . . . . . . . . . . . . . . . . . 95
8.2 Installing updated disk images . . . . . . . . . . . . . . . . . 95
8.3 Resetting PR2 . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.4 Diagnostics Logs . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4.1 Setting up automatic transfer . . . . . . . . . . . . . . 96
8.4.2 Manual transfer . . . . . . . . . . . . . . . . . . . . . . 96
8.5 Solving hardware problems . . . . . . . . . . . . . . . . . . . 96
8.5.1 Figuring out what’s wrong . . . . . . . . . . . . . . . . 96
8.5.2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.5.3 Documentation . . . . . . . . . . . . . . . . . . . . . . 97
Chapter 1
Introduction
This manual is intended to give you enough information to successfully in-

stall, use, and develop code on your PR2 robot. The software on the PR2 is
based on ROS. The recommended source of information for learning about
ROS and the higher-level software available for the PR2 is ros.org.
If you want to start running the PR2 as quickly as possible, please start
with safety in Chapter 2 (seriously - the PR2 is a big machine and can cause
serious injuries or death), and then skip to chapter 6 to learn how to start
up and run the PR2. If you are setting up the PR2 for the first time, you
will need to read chapter 5 to set it properly before you can use it.
1.1 Before you start

Before getting started, please read through this section to ensure you have
everything you will need to use the PR2 safely and successfully.
Space To use the PR2 you will need to have enough room for it to drive
around and move its arms. The PR2 is designed to move through ADA-
compliant spaces (Americans with Disabilities Act), so corridors should be
at least 36” wide, doorways should be at least 32” wide, and the ground
should be flat and level. You will need enough space for the PR2 to move
around and perform tasks.
Safe Environment The space where the PR2 operates should be free of
hazards. Specifically, stairways or other fall hazards can pose an extreme
danger and the PR2 should not be operated near any type of dropoff. You
should also avoid hazardous objects, sharp objects such as knives, sources
7
8 CHAPTER 1. INTRODUCTION
of fire, hazardous chemicals, or furniture that could be knocked over. See

chapter 2 for more details on making sure your environment is safe.
Electrical The PR2 charges using a standard 120V American power out-
let. The robot can draw 15A of current when plugged in, so we strongly
recommend recharging the PR2 only on outlets with no other devices on the
circuit breaker.
Development tools You will need at least one laptop or desktop com-
puter to connect to the robot. The PR2 ships with a base-station computer,
which is a desktop, but you will need to provide a screen, mouse, and key-
board. A laptop with wireless access is ideal.
Linux We highly recommend familiarity with the Linux command-line.

The computers in the base of the PR2, as well as the base-station computer,
run Ubuntu Linux, and since the computers in the robot don’t have attached
displays, all tasks on them have to be performed by logging in remotely (e.g.
via ssh).
ROS Since all of the PR2 software is based on ROS, completing the begin-
ning tutorials available at ROS.org will help you understand the structure
of the software on the robot and will give you tools to understand the data
that is moving around in the system.
PR2 Safety Be sure to familiarize yourself with the contents of the fol-
lowing chapter on safety before using the PR2.
Chapter 2
Safety
Safety is a key goal at Willow Garage. Safety is important yet challenging,

and it is a continual process shared by the robot designer, user, and ad-
ministrator. In the following chapter, we provide an overview of the issues,
describe some safety-related design features, enumerate a set of basic usage
guidelines to support safety, and detail the safety program.
2.1 Overview
Safety is a vitally important concern whenever you are around a PR2. Its
a heavy piece of equipment with many moving parts. The robot travels
through the environment and can carry and manipulate a wide variety of
objects. Its movements and actions are not completely predictable. The
PR2 can cause significant damage if it falls on or runs over someone. There
are several ways it can pinch, grab, and twist fingers or other body parts.
The robot can wield dangerous implements and knock heavy objects over.
You must always be cautious and attentive when you are around a PR2.
Managing safety is a challenge when dealing with any complex engi-
neering system. In the case of the PR2, consider also the open, extensible,
programmable, experimental nature of the platform. The PR2’s capabili-
ties and behaviors change over time, with user interactions, and with re-
programming.
With this in mind, Willow Garage has chosen a three-fold approach.
First, we have designed the PR2 to minimize potential risks and maximize
inherent safety, cognizant of its uncertain uses. Second, we communicate to
all users about how to minimize risk. And third, we have implemented an
explicit safety program to ensure that the community continues to identify
9
10 CHAPTER 2. SAFETY
potential hazards, seek design mitigations, and communicate effective usage

guidelines.
2.2 Design Features

We have designed both hardware and software to minimize risks, while re-
taining the power of an open platform. These aspects of the design are
often described as inherent safety features. For example, the PR2’s arms
are back-drivable. This means that when an arm encounters an object, be
it a table or a person, the interaction will drive the motors back and bring
the arm to a stop. The PR2’s arms can’t ”punch through” an object the
way traditional industrial robots can.
We have further designed the PR2’s arms using relatively small motors
with respect to their payload. This is possible due to a spring counterbalance
offsetting the gravity forces acting on the arms. That is, the arms do not
need to hold their own weight against gravity, so the motors need only be
strong enough to hold the payload. The arms simply can’t push very hard.
In software, we have incorporated low-level checking to limit the current
in a motor, the velocity of a motor, and the range through which a joint
should travel. We obviously discourage users and developers from changing
these configurations. High-level applications also avoid obstacles in naviga-
tion and movement using the various on-board sensors.
These design choices also help make the PR2 robust. However, a robot
with the PR2s capabilities can never be absolutely safe. Your safety as
well as the safety of others critically depends on your constant attention.
You must be aware of the potential dangers of using a PR2, and learn to
anticipate and prevent problems.
2.3 General Usage Guidelines

While many guidelines for the safe use of a robot stem from common sense,
we list a basic set here. We stress the importance of following these guide-
lines but emphasize that these guidelines alone do not guarantee safety, only
reduce risk.
Every organization that uses a PR2 must appoint a Safety Officer.
– The Safety Officer’s contact information should be known by ev-

eryone who uses the PR2 (including designers, developers, pro-
grammers, and end-users).
2.3. GENERAL USAGE GUIDELINES 11
– Details of the Safety Officer’s roles and responsibilities are de-

scribed in section 2.4.
Before operating or working with the PR2 you must do the follow-
ing:
– view the safety video,

– read this User Manual, in particular the entirety of Chapter 2 on
Safety,
– read and understand the latest list of potential hazards, which
can be found at safety.willowgarage.com, and
– know how to contact your organization’s Safety Officer
Supervise children, visitors, and anyone who has not followed the
previous guideline. In particular, make sure they
– do not come within range of the PR2 when active,

– are aware the robot could move unexpectedly and is potentially
dangerous,
– are not alone with the PR2, and
– do not operate the PR2.
Maintain a safe environment. Safety is not only affected by how

you operate the robot, but by the environment as well. The PR2 is
designed to operate in a laboratory environment.
– Keep the robot at least 7 meters from the top of a stairway

or any other dropoff.
– Make sure the robot has adequate and level space for any ex-
pected or unexpected operation.
– If the robot travels on a ramp, make sure the spine is lowered and
the arms are tucked in so that the center of gravity is as low as
possible. The slope should not be more than 1:12. Ensure that
the robot cannot fall off the edge under any circumstances.
– Make sure the the environment is free of objects that could pose
a risk if knocked, hit, or otherwise affected by the PR2
– Make sure there are no cables or ropes that could be caught in
the covers, wheels, or arms; these could pull other objects over.
– Make sure no animals are the near the robot.
– Keep fingers, hair, and clothing away from wheels and gears.
– Be aware of the location of emergency exits and make sure the
robot cannot block them.
– Do not operate the robot outdoors.
Keep the PR2 away from open flames and other heat sources. The
PR2 covers are flammable. They may burn if ignited.
– Never use the PR2 around stoves or ovens.

– Always be prepared for a fire and have a fire extinguisher ready
to use. An ignition source could come from anywhere, including
an internal failure of a PR2 system.
Use caution to avoid electrical shock.
– Do not allow the robot to come in contact with liquids (spilled

drinks, rain, etc.). This is particularly important when the robot
is plugged into an AC outlet.
– If a robot does get wet, turn off the DC breaker and contact
Willow Garage. If it is plugged into an AC outlet, don’t touch
the robot. Turn off the circuit breaker that controls the outlet.
– Before removing any covers, the PR2 should be unplugged and
the DC breaker should be turned off.
– Make sure the power cord is in good condition. Cord insulation
must be intact with no cracks or deterioration. Both connectors
should be undamaged. If the power cord is damaged in any way,
it should be discarded and replaced with a new cord from Willow
Garage.
When plugging in the PR2, always attach the power cord to the AC
inlet on the robot before attaching it to the AC outlet on the wall.
Unplug the cord from the wall before unplugging from the robot.
Use extreme caution whenever the robot’s spine is contracting. Ob-

jects or body parts could be crushed between the robot’s body and
base. Also keep people and objects away from the robot’s joints.
Make sure the batteries cannot be overheated or punctured. Do not

run the robot without its covers. They help protect the batteries from
inadvertent collisions.
2.3. GENERAL USAGE GUIDELINES 13
The operator should always have immediate access to the run/stop

box and should stop the robot at the first sign of a problem. The
stop button should always be pressed when examining, inspecting, or
maintaining the robot.
Use common sense when operating the robot.
– Do not allow the robot to grab or hit any person.

– Do not allow the robot to drive into contact with, or over, any
body part.
– Do not allow the robot to interact with any sharp or dangerous
items.
– Do not allow the robot to operate potentially dangerous appli-
ances (like stoves) or power tools.
Pay attention to warning labels on the robot.
Do not remove the covers of a PR2 or disassemble it in any way

without prior and appropriate instruction by Willow Garage.
– There are high voltages inside the robot.

– There are a variety of pinch points and other mechanical dangers
in the interior of the robot.
– Counterbalances and springs store significant potential energy
which could cause damage if unloaded abruptly.
Do not modify or remove any part of the software safety features.
If you are sensitive to 50 Hz flashing lights, the texture projector may

trigger headaches or seizures.
When you are developing software, you should consider that some
people have adverse reactions to the flicker from the texture projector
and only turn it on when necessary.
Regularly inspect and maintain anything the robot interacts with. For
example, regularly inspect the electrical outlets the robot plugs into.
Anticipate potential problems and hazards. Always imagine what

might happen if the robot malfunctions or behaves in a way different
from the desired action. Be vigilant.
Be aware that many things can go wrong even with a seemingly simple
activity. For example, consider what might go wrong while driving the
robot with the joystick:
– The joystick could run out of batteries.

– The Bluetooth connection between the joystick and the robot
could fail.
– The ROS node that talks to the Bluetooth driver could have been
changed or have a bug.
– The operating system in the robot’s computer could hang.
– The motor controller software node could fail.
– The motor controller board could fail.
– The PR2’s electrical system could fail.
– The motor or gear train could have a problem.
– The wheels could have a problem.
– Someone else could command the robot to move without your
knowledge.
– The operator could make a mistake. It’s intuitive to drive a robot
when it’s going away from you, but when it’s coming towards you
everything is reversed.
2.4 Safety Program

The possibility of injury can never be completely eliminated when working
with a PR2. Therefore, Willow Garage has instituted a safety program
to focus continual effort and attention on risk reduction. The program is
managed by a Safety Board and has three main goals:
Anticipation: identifying potential hazards associated with the PR2
Mitigation: taking actions to reduce the likelihood and severity of

hazards
Communication: exchanging information about safety within the com-

munity
The foundation of the safety program is an ongoing effort to identify ways

a PR2 could cause damage. We refer to these as hazards. For example, a
2.4. SAFETY PROGRAM 15
robot could cause damage by running into a person or falling down stairs.
The Safety Board maintains a list of all known hazards in a document called
PR2 Hazards, which can be found on the safety.willowgarage.com web site.
Anyone who works with a PR2 should review this list regularly. If you know
of a potential source of damage that is not covered by one of the hazards
in the list, please let us know, using one of the contact methods described
below.
When a hazard is identified, one or more of the following steps is taken:
A design change is made to mitigate the potential damage. Examples

of these can be found in the document called Design for Risk Reduction
on the safety.willowgarage.com web site.
A guideline is written to let people know how to avoid the potential

damage. The list of guidelines can be found in an earlier section of
this chapter or in a document called PR2 Usage Guidelines on the
safety.willowgarage.com web site.
A warning sticker is attached to the robot.
Communication is key to the safety program. There are several sources

of information available to you:
The web pages at safety.willowgarage.com.
This chapter of the PR2 User Manual
A Safety Officer for each PR2 site assists with two-way communication.
If you have any concerns about safety or if you witness a safety-related

incident, please contact the Willow Garage Safety Board.
By email at safety@willowgarage.com
By phone at 650-475-9794
Chapter 3
PR2 hardware
3.1 What’s in the box
The PR2 ships in 3 packages:

Robot crate Large wooden crate which contains the PR2 itself
Accessory crate Crate which contains accessory kit, tool kit, and
robot base-station
Calibration target Large checkerboard for accurate calibration of stereo
cameras
3.1.1 PR2
See later sections in this chapter for more detail on the PR2 robot itself or
see Chapter 5 for instructions on getting it out of the crate and set up in
your lab.
3.1.2 Accessory kit
Wireless Joystick
The PR2 ships with a bluetooth joystick for teleoperating the robot. The
bluetooth joystick is a Sony DUALSHOCK3 (Figure 3.1) wireless controller.
It can be charged using any standard USB A to mini-B USB cable (one is
included in the accessory kit). For more information, see the ps3joy package
at ros.org.
17
18 CHAPTER 3. PR2 HARDWARE
Figure 3.1: The PR2 bluetooth joystick.
Wireless run-stop
The PR2 comes with an OMNEX T50 wireless run-stop transmitter. When
the red button is pressed, or the unit is out of range, the wireless run-stop
transmitter will halt the motors and put the power system in standby mode.
Note that this does not completely cut power to the robot.
Figure 3.2: The PR2 wireless run-stop.
To start the wireless run-stop, press the green start button (Figure 3.2);
if this works properly, you will see a light flashing on the wireless run-stop
beside the start button. While transmitting, the wireless run-stop has a
range of approximately 800 ft. The wireless run-stop is powered by four AA
batteries; the battery light will flash when the battery charge is low and new
batteries are required.
3.1. WHAT’S IN THE BOX 19
Robot Power Cord and Self Plug-in Robot Power Cord
Figure 3.3: Robot Power Cord
Figure 3.4: Self plug-in power cord
To recharge the PR2’s batteries, it must be plugged into a 120V electrical

outlet. Use only the provided power cords - many power cords and power
strips have thinner conductors and cannot safely supply the current required
by the PR2. Using inappropriate cables is hazardous and may cause fire.
When manually plugging the robot in to re-charge, you may use either cable.
When attepting to have the PR2 plug itself in, you must use the shorter self-
plug-in cord with attached checkerboard. The self-plug-in cord has magnets
on the side opposite the checkerboard which should be used to attach it to
the magnetic pad on the base.
Sensorized fingertips and boots

The PR2 ships with sensorless fingertips attached. Included in the accessory
kit are fingertips which have an integrated 22-element pressure sensor. These
sensorized tips are easy to damage and are not as robust as the rest of the
Figure 3.5: Fingertip sensors and replacement boots
PR2. We provide 5 fingertip sensors (2 for each gripper, plus 1 spare), as

well as 20 rubber protective ”boots” which prevent the sensor from coming
into direct contact with the environment. When using the fingertip sensors,
you should always have an undamaged boot in good condition installed over
the sensor. Continuing to use the fingertip sensors after the rubber boot
is damaged greatly increases the chance that you will damage the sensors
themselves. Replacement sensor tips will be available to purchase from
Willow Garage. See the support site at support.willowgarage.com for more
information.
Small calibration target
Figure 3.6: Small calibration target
This small hand-held calibration target, which looks like a checkerboard,

is used for the PR2 self-calibration. The robot holds the checkerboard in
one gripper and uses it to calibrate the arms, the head, the cameras, and the
tilting laser together. The squares on the board are 25mm in each direction.
3.1. WHAT’S IN THE BOX 21
3.1.3 Large calibration target

The large calibration target which ships with the robot looks like a checker-
board 1” thick and approximately 3 feet square. This is the recommended
calibration target to use for calibrating the intrinsics of the stereo cameras
on the robot. The robot ships with stereo cameras already calibrated, but
you may need to re-calibrate after shipping, and occasionally as vibration
and thermal effects change the parameters over time. The squares on the
board are 108mm in each direction. Since the flatness of the board is critical
to the accuracy of the calibration, please store this where it will not warp.
User Manual
Printed version of this document.
3.1.4 Toolkit
Figure 3.7: PR2 toolkit
A toolkit is provided with the PR2. To avoid damaging the robot or

injuring yourself, you should always use these tools and follow the Repair
and Replacement procedures at support.willowgarage.com when performing
any hardware maintenance on the robot.
3.1.5 Base-station computer

The base-station computer ships without a monitor, keyboard, or mouse.
See chapter 4 on computers for more information on how to configure your
base-station.
Figure 3.8: PR2 Base-station computer
3.2 Mechanism
PR2 is a 32-dof mobile manipulator with a mobile base, two arms, and a
variety of sensors on a pan-tilt head.
3.2.1 Terminology
We talk about the robot kinematics using the concepts of joints, links,
frames, actuators, and transmissions. Each of these is defined and repre-
sented in code, as well as having a unique name. In general, a single joint
will have an actuator and a transmission and will connect two links together.
A link is a rigid body in the kinematic tree, and will have a coordinate frame,
but not all frames are associated with links. We allow ”fixed” joints, so some
rigid bodies that could be considered one link are considered to be two links
rigidly joined together. This is done mostly at locations where there is a
physical interface between components.
Link We consider a link to be a rigid body within the robot. It generally

has geometry to define visual and collision-space representations, has
inertial properties, and has a name. The links for the PR2 are defined
in the ”URDF” description that can be found in the pr2 description
package.
Frame Frames are geometric entities that represent coordinate frames in

3.2. MECHANISM 23
space. Every link has an associated frame, but we also use frames
to represent other things, such as the optical frame of a camera, the
global map, or the location of a detected object. Frames are always
defined relative to one another, and relationships and transformations
between them are tracked using the tf package.
Joint Joints are considered part of the robot, and define the relationship
between links. The joints for the PR2 are defined in the URDF de-
scription that can be found in the pr2 description package. The PR2
has mostly rotational joints, but the torso is translational, and there
are also a number of ”fixed” joints used to represent the notion that
two links are part of the same rigid body. Rotational and translational
joints are generally represented in the same way in the system, and
we refer to joint ”effort” instead of force or torque, as well as using
position, and velocity to represent both linear and angular movement.
Actuator The motor/encoder units in the PR2 are explicitly modelled as

”actuators”. The actuator model treats them as torque sources with
position measurement. The details of the actuator model (e.g. the
motor torque constant or max current), as well as the name of the
actuator, are stored on the motor controller boards.
Transmission We use transmissions, also defined in the URDF robot de-

scription, to represent the mapping between actuators and joints.
They map actuator position into joint position (meters or radians),
and map from commanded joint efforts (torques or forces) to actuator
efforts. In most cases in the robot this is a linear mapping between one
joint and one actuator that just defines a reduction, but in the wrist
we have 2 motors controlling two joints in a cross-coupled manner, and
in the gripper the mapping from motor rotation to gripper position is
non-linear.
In general, the names for a link and the associated frame will be similar
(e.g. r forearm link and r forearm frame), and the names for an actuator, a
transmission, and the associated joint will be similar (e.g. r elbow flex motor,
r elbow flex trans, and r elbow flex joint). For components such as arms
and casters that are included in the robot in multiple locations, we use a
short prefix to indicate which location we are referring to
l left (from the robot’s perspective)

r right
fr front right
fl front left
bl back left
br back right
Figure 3.9: The PR2 URDF Link Naming Scheme.
3.2.2 Links and Joints

By component, below is a list of the links and joints in the PR2:
Base-Body-Spine
The base-body-spine assembly of the PR2 has only one joint - the prismatic
torso lift joint which moves the torso up and down relative to the base.
The base link holds the rear panel with electrical/network connections, the
computers, and the battery system, as well as bolting directly to the casters.
The torso lift link, which moves up and down, contains the speaker, and
the IMU, as well as serving as the attachment point for both arms and for
the head.
3.2. MECHANISM 25
Figure 3.10: The PR2 URDF Joints Naming Scheme.
Head
The pan-tilt head which holds the wide and narrow stereo cameras, the 5
mega-pixel camera, and the texture projector is made up of two links - the
head pan link, connected to the torso by the head pan joint, and the
head tilt link, connected to the pan link by the head tilt joint. The
sensors are all attached to the tilt link.
The upper Hokuyo laser range-finder is mounted to the laser mount link,
which is tilted up and down by the laser tilt mount joint
Casters
Each robot has four steered and driven casters, one at each corner of the
base. The casters are refered to as front right, front left, back right, and
back left. They are named according to the above table of location pre-
fixes (fr , fl , br , and bl ). Each caster consists of a rotation joint loca-
tion caster rotation joint, which rotates or steers the body of the caster,
called the location caster rotation link, around a vertical axis. Attached
to the body of the caster are two parallel driven wheels, whose drive joints
are location caster r wheel joint and location caster l wheel joint.
Arms
The arm has 7 degrees of freedom. Starting from the attachment to the
torso, the first joint is the location shoulder pan joint which rotates the
location shoulder pan link, or shoulder turret, around a vertical axis.
The shoulder turret contains the springs that store energy to counter-
balance the mass of the rest of the arm. Two degrees of freedom, the loca-
tion shoulder lift joint and location upperarm roll joint attach the
location upper arm link to the shoulder.
The upper arm contains the counterbalance bar, which is a large steel
bar that attaches to the counterbalance attachment and transmits the coun-
terbalance forces into the structure of the arm. The upper-arm also contains
motors for the location elbow flex joint and location forearm roll joint,
which connect the forearm to the upper-arm.
The forearm (location forearm link) contains a 640x480 color cam-
era that can always see the gripper, as well as the two motor which drive
the wrist flex joint and the continuous location wrist roll joint that
attaches to the gripper.
Grippers
The gripper consists of a central palm link called the location gripper palm link
which is rigidly fixed to the location wrist roll link and has a single ac-
tuated degree of freedom. The motor in the gripper drives the 4 joints of the
gripper together to result in parallel motion of the fingertips. The parallel
distance between the gripper tips is treated as a translational joint, called
location gripper joint that can be controlled. The four rotational joints
in the hand which are constrained to move together are also modelled as
joints which can be observed but not controlled. The gripper also contains
a 3-dof accelerometer and an LED which can be turned on and off to assist
in calibration or finding the location of the gripper in camera images.
Additional Information
A CAD approximated kinematic and inertial description of the PR2 can be
found in the pr2 description package. This package uses a robot specific
Extensible Markup Language (XML) and Document Object Model (DOM)
representation called Uniform Robot Description Format(URDF), which can
be converted or exported to other formats such as COLLADA.
3.2. MECHANISM 27
3.2.3 Drivetrains
The joints in the PR2 are all actuated with brushed electric motors, and
all position sensing is done with optical incremental quadrature encoders.
Except where noted, each joint has an optical sensor (interrupt or reflective)
which is used at startup to identify a home position. Once the home po-
sition is identified, the incremental encoders are used to track motion. All
drivetrains in the robot have positive-engagement drives (gears or belts),
and the motor controllers monitor for encoder errors, so there should not be
any drift in measured position over time, although the repeatibility of the
calibration sensors may cause minor differences in position sensing between
runs.
Velocity estimates are made by differentiating the position sensors at
1ms, so the quantization of the encoders produces noise in the velocity signal,
which is especially significant at low speeds.
Torque estimates are made by measuring the commanded current of
the motor and using the values of the torque constant from the datasheet
together with the model of the transmission. These transmission models
assume 100% efficiency, and accuracy of torque estimates and commands is
limited by the friction in the drivetrain, so joint torque accuracy should be
characterized where you are relying on it.
Torso Drivetrain The torso is driven up and down on a linear rail by a

combination of a gas spring, which supports most of the weight of the
torso, and a lead-screw which is driven via an RE40 motor with 113:1
gearhead connected to a continuous belt drive with a 5:1 reduction.
As a result of the force from the gas-spring not being constant over the
range of travel, the lead-screw may be loaded up, down, or neutrally
as different points of travel of the torso. Position sensing of torso lift
is done via optical encoder on the back of the motor, so any backlash
in the lead-screw, belt, or gearhead is not sensed. The torso joint is
quite low efficiency, so commanding large forces (in the range of 1000
newtons) will be required to move the torso. The maximum speed of
the torso lift joint is limited by the thermal rating of the lead-screw
nut. Driving the torso lift link faster than the velocity limit will cause
permanent damage to the lead-screw assembly. Similary, driving at
the safety limit but with excessive load Because of the large reduction,
the torso lift link is capable of exerting high forces, so take care
Head Drivetrains The drivetrains for the head pan, head tilt, and laser
tilt are all fairly similar. Since precise pointing of sensors is important,
all three of these joints have 10,000 count encoders mounted in the
drivetrain after the major sources of potential backlash (gears). The
laser tilt axis is driven directly by the motor, through the encoder,
and then via a belt-drive. The head pan and tilt are both driven from
the motor through a gearset (planetary gearhead for the tilt joint and
external spur gears for the pan joint). The encoder is mounted on the
shaft after the gearset, and then a belt drive is used for the final stage
reduction. These drivetrains are all high-efficiency and capable of very
high velocities. The software velocity and position limits on these
joints are important to prevent hard collisions with the joint stops,
which will cause damage to the hardware (espially to the sensors). If
the mass of the head is changes significantly, the pan and tilt link gains
may need to be re-tuned.
Caster Drivetrains The three joints in each caster have basically the same
drivetrain, which is a Maxon amax-32 motor with a gearhead and a
continuous belt output. Position sensing is done via an encoder on
the back of the motor. The drivetrain is efficient enough to be easily
backdriveable. To rotate the caster, all three motors work together
(the rotation motor drives the rotation, and the two wheels drive in
opposite directions to provide additional forces. To drive, the two
wheel motors rotate in the same direction and the rotation motor
helps to keep them aligned in the proper direction.
Arm Drivetrains The first four degree of freedom in the arm (shoulder
pan, shoulder lift, upperarm roll, and elbow flex) are all driven with
RE40 motors that have single-stage planetary gearheads which output
to a toothed pulley that runs on a belt. These belts all have termi-
nations at either end of a capstan on the moving link, which is how
the torque is transmitted. The terminations are also the way that
these belts are tensioned, and propoer belt tensioning is important to
prevent backlash (which can come from extra slack in the belt), fric-
tion (which can come from extra tension in the belt), and excess wear
(which can come from a belt which is too tight, too loose, or just mis-
aligned). The position is measured via an optical encoder on the back
of the motor, so the backlash of the gearhead and the stretch of the
belt both contribute to the error in the sensed position. Velocity limits
are important on these joints to prevent motor damage from running
over speed, as well as to prevent rapid decelleration which can damage
the motor, gearhead, and belt.
3.2. MECHANISM 29
These drivetrains are all fairly high efficiency, which means they can
be backdriven. This is made possible by the low force requirements
on those joints due to the arm counterbalance. The counterbalance
uses a system of springs and linkages to compensate for the effect of
gravity on the upper arm and forearm links. The compensation should
be effective throughout the range of motion of the first four links of
the arm.
Arm Counterbalance Although not an actuated drivetrain the arm counter

balance is one of the more complicated mechanisms on the PR2. Inside
of the shoulder turret there are two springs. These springs are attached
to belts which run over cams and provide a uniform downward force.
In the upper arm there is a four-bar linkage which transmits the torque
through to the shoulder lift joint, upper-arm roll joint, and elbow flex
joint. As the arm moves through its configuration space the link-
age changes the amount of leverage with which the counterbalance is
pulling which compensates for the effect of the mass of the arm in
difference configurations.
Wrist Drivetrains The forearm roll joint is driven by a motor in the up-
perarm with a planetary gearhead and external spur gear. Position is
measured via an optical encoder on the back of the motor. Because of
the higher gear reduction, the efficiency and backdriveability of this
joint is not as good as that of the first four joints of the arm.
The wrist flex and roll use a differential drive between two motors.
If the motors are turned in the same direction the wrist rolls, if they
are turned oposite the wrist flexes. The differential bevel gears are
attached after a standard encoder, motor, gearhead assembly.
Gripper Drivetrain The gripper consists of two fingers with two joints
each. Within each finger, a four-bar linkage constrains the two joints
to move together so that the fingertips remain parallel. The two fingers
are constrained together with a sector gear that meshes between the
first phalanges of the two fingers. The motion of the fingers is driven
by a motor which drives a lead-screw in the palm of the hand. This
lead-screw is embedded in the four-bar linkage so that the rotation of
the motor has a nonlinear relationship to the movement of the joints.
The gripper can be back-driven when significant force is applied. Un-
like all other non-continuous joints in the system, the gripper has no
calibration flag. Initial homing is done by closing the gripper until
it gets blocked and then treating that position as a zero point. This
means that the gripper is unable to detect if it has miscalibrated on
startup.
Home Pose
In order to describe the PR2 robot pose and joint positions in a consistent
manner, a home pose of the robot has been defined. At the home pose,
all joint-angles are considered to be at zero. In the home pose the casters
are facing straight ahead, the arms are straight ahead in front of the body,
the grippers are closed, the tilting laser is level, and the head is centered
and flat. For most joints the calibration reference point is not at the home
pose, or zero position, and the URDF contains the offsets between the flag
positions and the home position.
PR2 Coordinate System
The coordinate frames for all links of the PR2 are defined to be aligned with
a world coordinate frame of positive z-axis up, positive x-axis forward, and
positive y-axis robot-left when the PR2 is in the home pose. All joint angle
conventions are chosen so that at the home position, positive motion of the
joint causes positive motion around one of the positive axes of the world
coordinate system.
3.2.4 Motion control

Motor controller boards
Each motor/encoder on the PR2 has its dedicated Motor Controller Board
(MCB). The MCB detects and counts transitions in the encoder signal,
measures the motor current, and commands the voltage going to the motor.
Each MCB runs a PI-control loop to control the motor current to a desired
value, by commanding the motor voltage. This control loop is closed at
100kHz on an FPGA on the MCB. A shared etherCAT realtime Ethernet
link with the first computer allows all MCBs in the PR2 to communicate
with the main computers with deterministic timing.
Each MCB has the following inputs and outputs:
Encoder input Each MCB can read quadrature incremental encoder in-
put. In proper operation, this should never skip or drift.
3.2. MECHANISM 31
Figure 3.11: Motion control layout.
Power input Each MCB is connected to the raw battery-power bus, and
using the circuit breakers you can switch between ”enabled”, which
provides 44-80VDC to the MCB and allows it to drive the motor,
”standby”, which provides 18VDC to the MCB and allows it to con-
tinue to communicate and read sensors but doesn’t allow driving the
motors, and ”disabled”, which turns off power the the MCB altogether.
Digital input Each MCB has a digital input which is used for detecting
the flags at the calibration positions on power-up. The MCB internally
latches the encoder counts at the time that the digital input transitions
from high to low and from low to high, which accurate detection of
calibration flag positions.
Digital output Each MCB has a digital output. On the gripper, this is
used to control the LED mounted in the hand. Elsewhere in the robot,
this is used to generate synchronization pulses which allow synchro-
nizing the cameras, the projector, and the motion control systems
together precisely.
Motor output Each MCB can drive a single brushed DC motor. The MCB
drives the output with an H-bridge and uses a current-measurement
to do closed-loop current control on the motor.
SPI There are two SPI ports which are only available on the gripper MCBs
and which are used to connect to the fingerip sensors.
Realtime loop
The realtime loop for the PR2 is a single process, which can be found in the
pr2 ethercat package. At runtime, the node is called realtime loop.
This process uses the RT PREEMPT extensions to the Linux kernel to
run as a hard realtime process, with a cycle time of 1ms, and performs
both controller update computations and communication over EtherCAT
with the MCBs. Non-realtime threads within the same process are used
to communicate over ROS to publish diagnostics, configure controllers, and
otherwise control the behavior of the PR2’s motion-control system
Controller manager
. Within the realtime loop, the controller update is dealt with by a ROS com-
ponent which contains both realtime and non-realtime functionality, called
the Controller Manager. Controlle Manager has an update step which is
called by the realtime loop at 1khz which receives measured motor torques
and positions and sends desired motor torques for the next cycle.
The Controller Manager includes the joint-limit safety code that enforces
position, velocity, and torque limits which are necessary to keep the PR2
from damaging its hardware. In addition, it has a dynamic plugin loading
mechanism that allows shared libraries containing realtime controllers to be
loaded and executed inside the 1kHz realtime loop.
3.2.5 Mechanical specs

Before undertaking any new or risky operations with your PR2, please con-
sult these mechanical specifications. Do not operate the PR2 outside of these
specifications. If you have any questions about your PR2’s specifications,
please contact Willow Garage Support.
Environmental specs
The PR2 is an indoor, household robot. Operating outside this type of envi-
ronment could cause damage to the PR2, and injury or death to operators.
3.2. MECHANISM 33
Water The PR2 has not been tested for any type of contact with wa-
ter or any other liquid. Under no circumstances should the PR2 come in
contact with water from rain, mist, ground water (puddles) and any other
liquid. Water contact can cause damage to the electrical circuitry and the
mechanism.
Temperature and Humidity Temperature testing of the PR2 has al-

lowed the unit to run between 15 and 35C. Towards the upper end of this
range, above 30C, you may experience decreased performance of the batter-
ies. Temperatures outside of this range can cause malfunctions in the PR2
power system and instruments. The PR2 has been tested in high humidity,
but under no circumstances should condensation be allowed to form on the
mechanism.
Drive Surface The drive surface of the PR2 must be capable of support-
ing the entire weight of the PR2, about 450 pounds (220 kgs). If the surface
is too soft, the PR2 can get stuck and fail to drive. A commercial carpet or
tile is recommended.
Incline Surface The PR2 is ready for ADA-compliant ramps, which are
at 1/12 slope. Ramps that are steeper than a 1/12 slope are unsafe and may
be a tip over hazard.
Other Environmental Specs
UV exposure should be minimized. UV radiation can damage the

PR2’s skin
Dust and dirt can clog air filters
Forces and torques

Joint position, velocity, and force limits are implemented in the PR2’s URDF
file, in the “/etc/ros/<distro>/urdf/robot.xml” file on your PR2. These
joint limits control the range of travel of the mechanism, the allowable veloc-
ity to prevent overtravel. These limits are enforced by pr2 controller manager,
and are designed to prevent poorly commanded control efforts from damag-
ing the PR2 and harming operators.
The limits below are from the PR2 URDF file. If a velocity or torque
limit is not specified, no value is enforced by pr2 controller manager.
Joint Velocity (rad/s or m/s) Torque (Nm or N)

∗ caster rotation joint - -
∗ caster wheel ∗ joint - -
torso lift joint 0.013 10000
laser tilt joint 10.00 0.65
head pan joint 6.00 2.65
head tilt joint 5.00 15.00
∗ shoulder pan joint 2.10 30.00
∗ shoulder lift joint 2.10 30.00
∗ upper arm roll joint 3.27 30.00
∗ elbow flex joint 3.30 30.00
∗ forearm roll joint 3.60 30.00
∗ wrist flex joint 3.10 10.00
∗ wrist roll joint 3.60 10.00
∗ gripper joint 0.20 1000
The PR2 motor controller boards (MCB’s) will not allow a current com-
mand greater than the maximum continuous current specified for the joint’s
actuator. This means that maximum joint effort may be lower than the max-
imum effort specified above. Below are the actuators for each joint (Maxon
part number), and their maximum allowable commanded current.
Joint Motor Power (W) Max Current

∗ caster rotation joint 236672 20 0.655
∗ caster wheel ∗ joint 236672 20 0.655
torso lift joint 148877 150 3.12
laser tilt joint 310009 60 1.72
head pan joint 310009 60 1.72
head tilt joint 310009 60 1.72
∗ shoulder pan joint 148877 150 3.12
∗ shoulder lift joint 148877 150 3.12
∗ upper arm roll joint 148877 150 3.12
∗ elbow flex joint 148877 150 3.12
∗ forearm roll joint 310009 60 1.72
∗ wrist flex joint 310009 60 1.72
∗ wrist roll joint 310009 60 1.72
∗ gripper joint 222057 11 0.204
More information about each actuator may be found in Maxon datasheets.

3.2. MECHANISM 35
Joint Limits and Types

The position limits for the PR2 are specified below. These “hard limits” are
the maximum travel for the mechanism.
Joint Type Limit (+) Limit (-)
∗ caster rotation joint continuous - -
∗ caster wheel ∗ joint continuous - -
torso lift joint prismatic 310 mm 0 mm
laser tilt joint revolute 85◦ -45◦
head pan joint revolute 168 ◦ -168◦
head tilt joint revolute 60 ◦ -30◦
r shoulder pan joint revolute 40◦ -130◦
l shoulder pan joint revolute 130 ◦ -40◦
∗ shoulder lift joint revolute 80◦ -30◦
r upper arm roll joint revolute 44 ◦ -224◦
l upper arm roll joint revolute 224 ◦ -44◦
∗ elbow flex joint revolute 133◦ 0◦
∗ forearm roll joint continuous - -
∗ wrist flex joint revolute 130◦ 0◦
∗ wrist roll joint continuous - -
∗ gripper joint prismatic 86 mm 0 mm
Modifying Joint Limits

On the PR2, “soft limits” stop the joints from reaching the full range of
motion to prevent damage to the mechanism. These soft limits, similar to
a virtual spring, are specified in the robot’s URDF file. For an explanation of
their implementation, see http://www.ros.org/wiki/pr2 controller manager/safety limits.
The soft limits have been validated by Willow Garage, and are required
for safe operation of the PR2. Under no circumstances should these limits
be increased without prior written authorization by Willow Garage Safety.
Unauthorized and unvalidated modification of these limits could cause mech-
anism damage and increase the risk of injury or death to PR2 operators.
Mechanism damage resulting from changing these limits can include:
Thermal damage to motors from exceeding maximum current specifi-

cations
Damage to drive-trains resulting from collision with end-stops
Premature wear and damage to motor, gear-head, or drive-train re-

sulting from operating over the components’ rated speed
Premature wear of slip-rings or other electrical connections from op-

erating over the componnts’ rated speed
Vibration damage to sensors or other components resulting from ex-

cessive velocities or collisions with joint-stops
3.3 Sensors
The PR2 has a variety of sensors on its body:
3.3.1 Base Laser

The base laser is a Hokuyo Top-URG (UTM-30LX) scanning range finder.
This laser has a 30 m and 270◦ scanning range. For more information, see
the hokuyo node package at ros.org.
3.3.2 Tilting Laser

In addition to the base laser, the PR2 has a Hokuyo Top-URG (UTM-30LX)
mounted on a tilting platform located just below the pan-tilt head. The
3.3. SENSORS 37
tilting platform can sweep the scanning laser through 135◦ (+90◦ and −45◦
from level) and can be controlled using the default laser tilt controller. For
more information, see the hokuyo node and pr2 default controllers packages
at ros.org.
3.3.3 Head Cameras

The PR2 pan-tilt head has three cameras and a textured light projector:
Wide Stereo Camera The wide stereo camera is part of the dual stereo
pair and is a 100Mb color ethernet camera. The wide stereo uses the
Aptina MT9V032C12STC imager chip and has a maximum resolution
of 752 x 480 pixels at 15 fps. The camera has a field of view (FOV) of
approximately 90◦ and a 2.5mm F2.5 Marshall V-4402.5-2.5-HR lens.
For more information, see the wge100 camera package at ros.org.
Narrow Stereo Camera The narrow stereo camera is part of the dual
stereo pair and is a 100Mb monochrome ethernet camera. The narrow
stereo uses the Aptina MT9V032C12STM imager chip and has a max
resolution of 752 x 480 pixels at 15 fps. The camera has a FOV of
approximately 55◦ and a 5.6mm F2.0 Marshall V-4405.6-2.0-HR lens.
For more information, see the wge100 camera package at ros.org.
Gigabit Ethernet Camera The PR2 has a gigabit ethernet camera lo-
cated to the left of the dual stereo pair on the pan-tilt head. The
gigabit ethernet camera is a Prosilica GC2450C, which uses the Sony
ICX-625AQ imager chip and has a maximum resolution of 2448 x 2050
pixels at 15 fps. Additionally, the gigabit ethernet camera has a 8mm
F1.4-F16 Kowa LM8JC lens. For more information, see the prosil-
ica camera package at ros.org.
Textured Light Projector The PR2 has a textured light projector lo-
cated to the (robot’s) left of the dual stereo pair on the pan-tilt head.
The projector has a FOV of approximately 55◦ and a 5.6mm F2.0 Kowa
LM12JC lens. For more information, see the pr2 camera synchronizer
package at ros.org. Note: The projector will only work if the motors
are enabled and runstop is not hit.
3.3.4 Forearm cameras

Each forearm of the PR2 is equipped with a 12V 100Mb color ethernet
camera. The forearm camera uses the Aptina MT9V032C12STC imager chip
and has a maximum resolution of 752 x 480 pixels at 15 fps. Additionally,

the forearm camera has a 2.5mm F2.0 lens. For more information, see the
wge100 camera package at ros.org.
3.3.5 Gripper Sensors

Accelerometer The gripper of the PR2 is equipped with a Bosch BMA150
digital triaxal accelerometer. The measurement range (±2g, ±4g, or
±8g) and bandwidth (25Hz - 1500Hz) of the accelerometer can be
selected in software. For more information, see the wge100 camera
package at ros.org.
Fingertip Pressure Sensors The default fingertips of the PR2 are sturdy
aluminum blocks with non-slip rubber covers for added friction and
compliance in grasping. However, the aluminum tips can be swapped
out for an (included) set of RoboTouch tactile sensing pads made by
Pressure Profile Systems, each with 22 tactile sensing elements: 15
in a 5x3 array on the front surface, 2 on top, 2 on each side, and 1
in back, near the top. Each tactile element has a pressure range of
0-30 psi (0-205 kPa) and sensitivity of 0.1 psi (0.7 kPa). The sensors
connect to the robot via an SPI ribbon cable and two screws, and have
a maximum scan rate of 35 Hz.
The tactile sensors are highly fragile when not protected by the rub-
ber covering, and so care should be taken not to damage the rubber
covering. For more information, see the fingertip pressure package at
ros.org.
Calibration LED
3.3.6 Inertial measurement unit

The PR2 has an inertial measurement unit (IMU) located next to the tilting
laser. The IMU is a MicroStrain Inertial-Link 3DM-GX2 which has an ac-
celerometer range of ±5g and a gyro range of 300◦ /s. For more information,
see the microstrain 3dmgx2 imu package at ros.org.
3.3.7 Speaker
The PR2 has one Logitech V20 notebook speaker located under the pan-tilt
head next to the tilting laser. For more information, see the sound play
package at ros.org.
3.4. POWER SYSTEM 39
3.4 Power system

3.4.1 Overview
The PR2 has a Lithium-ion (Li-ion) battery system that is charged off of a
120V wall current. The batteries power the computers, motors, and sensors
on the robot. Power distribution is controlled by the Power Board, which
communicates over Ethernet to the computers in the base of the PR2.
3.4.2 Power Busses

The robot has four internal power busses:
AC power The robot has a 3-prong IEC320 plug in the back of the base,
which is connected through a circuit breaker to the four AC-DC con-
verters used to charge the battery packs. With a 120V supply, the
system is designed to draw less than 15A, so a standard 15A or 20A
outlet will suffice. The load is capable at times of approaching the
15A limit, make sure there are no other devices which draw significant
power (e.g. computers or heaters) on the same circuit.
Motor Power Bus The motors get power through 3 discrete circuit break-
ers on the power board. These create three independent motor power
busses: left arm, right arm, and base/head. The motor power bus can
be in one of three states.
Enabled , provides a direct connection to the unregulated battery

power. The voltage will ranges from 52V when the batteries are
fully discharged up to 72V when connected to wall power. i
Standby , the power board provides a low-power 18V supply that is
used for communication and maintaing encoder position counts.
Disabled , total shut-down of the circuit (e.g., in the event of a major
power-system problem or if manually disabled through the control
panel).
12V system bus 12V power for sensors supplied by the power board. This
is also the recommended source of power for user supplied accessories.
12V computer power 12V power for the computers supplied by the power
board.
3.4.3 Batteries
The battery system has four battery bays. Each bay is comprised of four
Ocean Server BA95HC-FL 14.4V Li-ion batteries, a V-INFINITY VF-S320-
18A-CF 18V AC-DC Power Supply, and a Ocean Server XP-04SRW four-
channel high current battery controller. This provides the PR2 with approx-
imately two hours of countinous operation after a full recharge. For more
information, see the ocean battery driver package at ros.org.
Battery Temperature Warnings
The PR2 battery system reports a warning in the diagnostics if the tem-
perature goes above 50C, which is the maximum recommended operational
temperature of the batteries.
The batteries are exothermic when discharging, and tend to get hottest
when they are near minimum charge. During a work day, when your PR2
is constantly charging and discharging, the temperature of the batteries can
slowly climb. If your lab or workspace is warm (above 25C) you are much
more likely to see this problem.
After the battery temperature goes above approximately 54C, the bat-
teries will not charge until the battery temperature drops below 46C.
If your batteries are reporting that they are too hot, then you need to
reduce the load on the batteries. Generally, it is best to plug the robot in as
soon as possible. It may take several hours for the batteries too cool down
and charge.
The main power board fan will run at full power whenever the batteries
are above 46C. If the fan is abnormally loud, clean your fan filter.
3.4.4 Power Board

The power board is central to the PR2’s power system. This is where the
power from the batteries passes through to the rest of the system. The
power board monitors total power drawn from the batteries by measuring
the voltage and current at the power board input.
The battery power is used to provide regulated 12V to the computers and
the system bus through DC converters. Three unregulated circuits are also
provided with a unique electronic circuit breaker functionality. All outputs
are ultimately controlled by the processor located on the Power Board.
Figure 3.12 shows the power board, with e-stop receiver, removed from
a robot.
Figure 3.12: PR2 power board
The Power Board contains an ARM processor with an ethernet interface.

The processor is responsible for performing a self test at power-on, monitor-
ing the state of all busses, providing information about the electrical system
and responding to commands. The power board is the first thing to turn on
and can not be turned off without switching off the DC circuit to the whole
robot.
The power board contains many LEDs used to indicate status:
12V Power Bus The LEDs in green indicate the 3 regulated 12V outputs
are enabled and functional, shown in Figure 3.13.
MCB Power Bus The Blue LEDs, Figure 3.14, indicate the motor bus
power is enabled. Blue indicates a voltage higher than the 18V standby.
These LEDs can also be orange if the output state is in the standby
state.
Power Board Status The status LEDs, Figure 3.15, are used by the pro-
cessor for debugging. In the event of a failure a status code will display
on these LEDs in the form of a number of rapid blinks followed by a
slight pause. Status1 indicates the location where the fault occured
and Status2 indicates the cause of the fault.
Figure 3.13: 12V Bus Indicator LEDs
The following table decodes the meaning for the error codes. For further
diagnosis please provide the status codes in bug reports.
count location
1 Self Test
2 Main Loop
3 Breaker 0
4 Breaker 1
5 Breaker 2
6 Calibration Test
Main Loop Message

count message
1 Under Voltage Lockout
2 Over Temperature Lockout
3 Under Current condition
4 Over Current condition
5 Failed Self Test
6 18v Failure
7 Fan tachometer failure
8 calibration CRC failure
9 Battery voltage low
Circuit Message
1 Disable via software command
2 Failed during turn on cycle
3 Shutdown by E-stop
4 Circuit breaker tripped
Figure 3.14: MCB Bus Indicator LEDs
3.4.5 Run/Stop controls
Besides supplying power the power board also interfaces with the wireless
run/stop radio receiver and the run/stop button. The run/stop system is
designed to reduce the power on the motor bus to a level where only the
board communications and their encoder positions are maintained. The red
button and radio system are described as provide physical run/stop control
over the motors in the robot. This mechanism is implemented in hardware
and can not be altered by software.
Please note that the run/stop system only reduces power to the motor
Figure 3.15: Power Board Status LEDs

power bus and nothing else. If there is an electrical problem or power needs
to be shutdown for service, the red DC circuit breaker on the rear lower
panel is the only way to totally shut off the power board.
3.4.6 Power for sensors

The power board provides a 12V system bus, that provides a well regulated
12V supply. The regulated 12V supply is the only supply designed for ad-
ditions and expansion. This 12V supply is essentially always on once the
Power Board completes its self test. It is also monitored for undervoltage
conditions.
THe 12V use supply powers various electronics devices in the robot,
including both Hokuyo scanners, the ethernet switches, the wireless AP,
and the run/stop receiver. There is 5A of additional capacity available for
expansion.
Access to the 12V accessory bus is available in several locations:
Inside the top head assembly.
insert picture
In the upper back.
insert picture
In the lower back, directly connecting to the power board.
insert picture
The robot electrical systems are complex, and it is easy to damage robot
components by hot-plugging. Never plug in or unplug any components inside
the robot unless the power system is shut off completely.
All 12V connectors in the robot use the same connector, a 2x1 Molex
Mini-Fit Jr. The mating connector part number is 39-01-3022 or from
Digikey WM1021-ND. Pin one is negative and pin 2 is positive. Pin 2 is
the pin closest to the latch.
Chapter 4
PR2 Computers
This section covers the configuration of the computers and software that
comes installed on the robot
4.1 Computer hardware

PR2 has two computers, each has 24 Gb of RAM, 2 quad-core Nehalem
processors, and both a 2.5” internal hard-drive and an externally removable
3.5” drive.
Additionally, the PR2 ships with a basestation computer which facil-
itates seamless communication with the PR2 when transitioning between
wired and wireless networks, and additionally helps in a number of mainte-
nance tasks.
4.1.1 Computer 1 (c1)

Computer 1 (c1) is physically located on the right side of the robot. It is
referred to as the master computer because it serves a number of key roles
for the computer infrastructure:
c1 stores the operating system for both computers. c2 cannot boot

unless c1 has booted first.
c1 is connected to the PR2 ethercat network, and is the only computer

that can perform motor control.
c1 provides routing for the rest of the robot when it is plugged in via
the WAN port .
45
46 CHAPTER 4. PR2 COMPUTERS
c1 provides routing for the rest of the robot when connected to another
network via an openVPN tunnel
c1 provides DHCP services for other devices connected to the robot
internal network.
c1’s PCI slot is used for a 4-port ethernet card, giving it a total of 6
ethernet ports. These are:
lan0 - lan3: connection to internal robot network
wan0: connected directly to WAN port on back of robot
ecat0: connected to robot ethercat network
4.1.2 Computer 2 (c2)

Computer 2 (c2) is physically located on the left side of the robot. It is
sometimes referred to as the slave computer because it netboots from c1.
c2 only has 2 ethernet ports, lan0 and lan1, both of which are connected
to the internal robot network.
4.1.3 Basestation
The basestation is a Zareason xPC. It is a dedicated point of contact through
which network traffic to the robot can be routed. It has 2 ethernet ports,
wan0, on the motherboard, is the primary ethernet port. It is intended to
be plugged into your building network. lan0, on the pci card is a dedicated
port for servicing the robot. When necessary, this port should be plugged
directly into the robot service port.
When configured properly, it is important that the basestation is visible
on port 1194 both via your wired building network as well as via your
building wireless network. This will likely require assistance from your local
network administrator.
4.2 Networking
The majority of communication between components onboard the PR2 hap-
pens via an onboard ethernet network, referred to as the “robot internal
network.” This onboard network can be accessed directly via either wired
connection (through the service port), or wireless connection (through the
WAP). Additionally, the robot can be accessed via the basestation through
a VPN tunnel.
4.2. NETWORKING 47
4.2.1 Network segments

There are a couple of different important network segments, outlined here,
and discussed in more detail in the section “Network Explanation” below.
10.68.0.0/24: Primary Robot Internal Network. The 10.68.0.0

subnet is the primary network used internally by the computers on
the robot. Both computers and the basestation have addresses on this
subnet. Additionally, many of the ethernet-based devices, such as the
power board, are given addresses on this subnet. The robot Service
Port, and the cradlepoint ctr350 Wireless Access Point are directly
connected to this network, allowing a user to easily put their laptop on
the robot internal network. c1, if booted, will give out IP addresses via
DHCP in the range 10.68.0.100-10.68.0.199. Important addresses
on this network:
– 10.68.0.1 - c1 (lan0)
– 10.68.0.2 - c2 (lan0)
– 10.68.0.5 - wifi-router
– 10.68.0.6 - basestation (lan0)
– 10.68.0.91 - c1-esms
– 10.68.0.92 - c2-esms
– 10.68.0.250 - wap
10.69.0.0/24: Secondary Robot Internal Network. The 10.69.0.0

network is a second internal subnet. The cameras are given addresses
on this subnet to partition traffic accross the computer’s two network
interfaces of the computers. This way, heavy network utilization by the
cameras is less likely to interfere with more critical computer functions
such as NFS.
– 10.69.0.11 - c1 (lan1)
– 10.69.0.12 - c2 (lan1)
10.68.X.0/24: Robot VPN Network. The primarily role of the bases-

tation is to function as a VPN server for the robot. Each robot can
be given a unique VPN subnet to facilitate the operation of multiple
robots using a single VPN server. The basestation can be configured
to automatically forward relevant traffic from the building network
into the VPN network, hiding this from the end-user. However, if
greater security is desired, the basestation can instead be configured

to require users to be assigned a vpn key to access the robot VPN
network. Important addresses on this network:
– 10.68.X.1 - c1 (tun0)
– 10.68.X.2 - c2 (via c1:tun0)
– 10.68.255.1 - basestation (tun0)
4.2.2 Network Explanation
ROBOT WIFI ROUTER

BUILDING WIFI DESKTOP
LAN0 WLAN0
10.68.0.5 DHCP WAN0
C1 DHCP
FIREWALL
TUN0 Allows Port 1194
10.68.1.1 WAN0
DHCP
VPN LAN0 BUILDING

10.68.0.1
ROBOT NETWORK BASESTATION
TUN0
NETWORK WAN 10.68.255.1
WAN0
PORT STATIC
C2
LAN0 VPN
10.68.0.2
WAP SERVICE LAN0
10.68.0.6
10.68.0.250 PORT
LAPTOP WLAN0 LAN0

DHCP DHCP
The above figure depicts the interaction between the robot and building
networks. The dotted lines show paths which may or may not be connected
at any given point in time. That is, the basestation or a laptop may not
always be plugged into the service port, and the robot WAN port may not
always be plugged into the building network. The colored lines depict path-
ways that different network traffic follows. The main thing of importance
to note is that there are three ways to talk to the robot: direct wire, direct
wireless, or VPN. Additionally, the VPN traffic itself can be routed in one
of two ways, either via a wired or wireless path. the VPN. Note: for clarity,
we have labeled all interfaces connected to the building network as WAN,
and interfaces connected to the robot network as LAN, but this may well not
be the case for laptops or desktops on your actual network, where the usual
default interface name is typically “eth0”
Direct wired connection. One possibility is to connect a laptop,
or the basestation lan0 port to the robot service port. This sim-
4.2. NETWORKING 49
ply puts the laptop, or the basetation directly on the robot internal
network. The basestation is always configured to use the IP address
10.68.0.6, whereas the laptop will likely be configured to use DHCP.
When plugged into the service port, you can talk to the robot LAN
ports directly on the 10.68.0.0/24 subnet. This system will work
even if the VPN system is not functioning. This is typically used for
reinstalling the robot, or debugging other networking problems.
Direct wireless connection. Another possibility is to connect a lap-

top directly to the robot WAP. This is essentially identical to plugging
into the service port. The robot computers can be reached directly on
the 10.68.0.0/24 subnet.
VPN connection. When not plugged into the service port, the bases-
tation and robot communicate over VPN. The basestation acts as the
VPN server, and is always reachable at 10.68.255.1. However, there
are two mechanism through which the VPN traffic may be routed.
– Wired VPN connection. The wired VPN connection is de-

picted in blue. This only occurs when the robot WAN port is
plugged into the building network. Note that wan0 on c1 goes
directly to the robot WAN port. When this is plugged into the
building network, c1 acquires an IP address via DHCP. At that
point c1 initiates a connection to the basestation using a spec-
ified static IP address. Once this connection is established, all
vpn traffic is routed through this pathway.
– Wireless VPN connection. The wireless VPN connection is
depicted in red. If the WAN port is not plugged in, the robot
falls back on its wireless connection. A secondary route instead
sends traffic through the wifi-router, which must be configured
to connect to the building wireless network. In many cases, the
wireless network is located outside the firewall, so it is impor-
tant that the static IP of the basestation resolves properly and is
allowed through the firewall on port 1194.
Regardless of how the robot is connected to the basestation, a desktop

situated on the building network will always talk to the robot in the
same way. Traffic from the desktop, depicted in green, is actually
routed through the basestation and into the VPN tunnel. Once in the
tunnel, which pathway the robot is using is abstracted and the traffic
seamlessly emerges from the other side of the tunnel.
4.2.3 Service Port

The robot service port is the bottom ethernet port on the back panel of
the robot. It connects directly to the robot internel network, allowing you
to connect to the computers directly. DO NOT PLUG THIS PORT INTO
YOUR BUILDING NETWORK. c1 serves DHCP for this network and if
it conflicts with another DHCP server this will most likely cause problems
both on your building network and on the robot network depending on which
DHCP server takes precedence.
4.2.4 WAN port

The robot WAN port is the top ethernet port on the back panel of the
robot. This connects directly to wan0 on c1. This port is intended to be
plugged into your building network. The robot will attempt to acquire an IP
address via DHCP, and then attempt to contact the basestation at a known
IP address.
4.2.5 Wireless access point

The robot comes configured with a cradlepoint ctr350 configured as a Wire-
less Access Point (WAP) . The ESSID of this network defaults to “¡ROBOT-
NAME¿ LAN”, and allows direct access to the Robot Internal Network. You
can configure the WAP by plugging into the robot service port and going to
the IP address: 10.68.0.250. The default login and password are “root”,
“willow.”
4.2.6 Wireless router

The PR2 has a Linksys WRT610N dual-N band wireless router. This router
can be configured to connect to your building wireless network. In the
absence of a WAN connection, the robot will attempt to contact the bases-
tation through this wireless router instead. You can configure the wireless
router by plugging into the robot service port and going to the IP address:
10.68.0.5. The default login and password are “root”, “willow.”
4.3 Computer Configuration

The operating system running on the PR2 computers is an extended version
of Ubuntu 9.04 (Jaunty Jackalope). It depends on a number of additional
packages for system configuration, but should otherwise be familiar to for
4.3. COMPUTER CONFIGURATION 51
Ubuntu users. If you run into a computer problem not covered by the PR2
documentation, the Ubuntu Documentation is the next place to look.
4.3.1 BIOS
The BIOS configuration is slightly different between c1 and c2 to allow them
to boot differently. c1 defaults to booting off of the internal disk, while c2
defaults to netbooting off the lan0 interface. Early in the boot process, c1 is
reconfigured to try netbooting off of the the lan1 interface before booting off
the disk (using lan1 rather than lan0 enables the basestation to distinguish
the 2 computers). On a proper shutdown, c1 is switched back booting off
the disk, but in the event of a hard power failure, the default BIOS state
leaves c1 netbooting. This is convenient for reinstallation or recovery.
4.3.2 Networking
To keep connections behaving sensibly when transitioning the VPN connec-
tion to the basestation between wired and wireless, the robot is configured to
route ALL traffic that is not on the robot internal network out through the
basestation. Any traffic not routed via the basestation is sent to a blackhole
to keep connections from getting broken. This means that if VPN is not
connected your robot will not be able to see the outside world even though
it might appear that the network is configured appropriately.
This is handled using an ip rule configuration. Most of these rules
are added by the init-script: /etc/init.d/iprules.sh. You can view the
current rule configuration using the command ip rule:
pr2admin@c1:$ ip rule
0:from all lookup local
1000:from all to 10.68.0.0/24 lookup main
1001:from all to 10.0.2.239 lookup main
1002:from all to 10.68.1.0/24 lookup main
2000:from all lookup vpn
3000:from all blackhole
32766:from all lookup main
32767:from all lookup default
The two important rules are priority 2000 and 3000. The priority 2000 rule
routes all traffic into the vpn routing table:
pr2admin@c1$ ip route list table vpn
default via 10.68.1.6 dev tun0 metric 1
The priority 3000 rule is what sends things to the blackhole. By disabling the
priority 3000 rule, traffic which cannot be routed through the basestation,
such as when the vpn tunnel is down, will simply go to the main routing
table.
To remove the priority 3000 rule, you can run:
pr2admin@c1$ sudo ip rule del priority 3000
This may be especially helpful when repairing a system in a particularly
bad state since otherwise you may not be able to fetch necessary software
updates or download necessary configuration files.
Additionally, iptables is configured using configuration files in /etc/iptables.d/.
These rules are responsible for providing firewalling on the robot wan0 in-
terface, turning on masquerading, and NATing incoming vpn traffic into the
robot local network.
4.3.3 NFS and Unionfs

The single largest difference between a normal Ubuntu installation and the
PR2 configuration is that c2 mounts nearly its entire filesystem via NFS.
The exceptions to this are the directories /etc, /var, and /pr2bin which
are mounted via unionfs-fuse. In short, unionfs allows one to specify an
additional overlay on top of the underlying filesystem. The contents of this
overlay can be found in the directory /slave on c1. Files added here will
show up in the appropriate location on c2. For more information on how
this is set up, see the man page for unionfs-fuse and look at the init-script
/etc/unionfs-fuse-nfs-root.
New software and configuration changes should only be made on c1.
Since c2 mounts most of its filesystems read-only, this will usually be en-
forced for you. If you are using a non-standard piece of software that at-
tempts to write to the filesystem outside of your home directory you will
likely need to make accommodating changes to either the computer config-
uration or the software you are trying to run.
4.3.4 autofs
Both of the computers have automount configured for mounting the /home
partition of the other computer in a computer-independent way using autofs.
These automounts are located in the directory /pr. To get to the home
partition on c1 you can use the path /pr/1/ and to get to the home partition
on c2 you can use the path /pr/2/. You should rarely need to do this
explicitly, but it is necessary to make sense of home directory locations.
4.3.5 Home directories

The default configuration for user home directories (as given in /etc/passwd)
is /u/username. Instead of a directory, this location is by default a sym-
link to /pr/1/username (locating the home directory on c1). To place a
users home directory at a different location, such as the disk on c2, an ad-
min can simply move (or copy) the home directory and update the symlink
accordingly.
4.3.6 Kernel
Both c1 and c2 run a 2.6 kernel with the RT PREEMPT patch. We compile
the kernel in order to apply the patch and to enable some configuration.
4.3.7 Storage
Each computer has two hard-drives - one internal 2.5” 500Gb Seagate Mo-
mentus drive, and a slot for a removable 3.5” SATA hard-drive that is ex-
posed on the top of the robot base.
By default the only hard-drive used is the internal drive on c1. There
are 3 relevant partitions created during installation:
c1:/dev/sda1 – / – holds the root filesystem for the OS
c1:/dev/sda5 – c1:/home – stores user home directories (linked to

from /u by way of /pr/1)
c1:/dev/sda6 – /hwlog – stores hardware logs generated by the pr2
The internal hard-drive on c2 has a single partition, which is generally

used as extra user storage:
c2:/dev/sda1 – c2:/home – stores user home directories (linked to

from /u by way of /pr/2)
Finally, both computers are configured to conveniently make use of the

additional removable drives. Any drive loaded into the removable bay should
always show up as /dev/removable. The mount point: /removable is set
up to allow users to mount the first partition on this drive.
/dev/removable1 – /removable – stores temporary data users may

want to move off the robot, primarily used for large bag files. This is
NOT mounted by default. To use a driver users must explicitly
user@c1$ mount /dev/removable
to use it, and should
user@c1$ umount /dev/removable
when done. Until the drive is unmounted, you do not have a guarantee
the data has been written to disk, and if the robot runs out of batteries,
your data may be lost.
Formatting Drives
If you want to partion / reformat one of the removable drives, or the the
internal drive on c2, you can use the formatdisk helper utility. Simply pass
it the name of the drive you want to format, for example:
pr2admin@c2$ sudo formatdisk /dev/sda
or
pr2admin@c1$ sudo formatdisk /dev/removable
Drive maintenance
If you suspect a drive of having problems, you can run a selftest using
smartmontools
pr2admin@c1$ sudo smartctl -t short /dev/sda
After a few minutes, you can then check the results:
pr2admin@c1$ sudo smartctl -l selftest /dev/sda
=== START OF READ SMART DATA SECTION ===

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_
# 1 Short offline Completed without error 00% 4195 -
# 2 Short offline Completed without error 00% 3713
In the event that there are reported bad sectors, http://smartmontools.sourceforge.net/ba

provides information on freeing the bad blocks.
4.3.8 Default user account

The default account on the robot is “pr2admin”. When the robot is first
installed, it does not have a password set, however, this password is set as
part of the branding process. When you first receive the PR2 from Willow
Garage the password will most likely be set to “willow”.
4.3.9 Creating user accounts

The expectation is that each person logging into the robot to develop code
will have their own user account. Any robot admin can create a new user
using the adduser command (NOT the useradd command), on c1. User
accounts are automatically mirrored on c2.
Some examples:
pr2admin@c1$ sudo adduser bob

pr2admin@c1$ sudo adduser bill --shell /usr/bin/tcsh --uid 2000
Note: it may be helpful to assign users the same UID used on your
building network so the UIDs are consistent when mounting shares or moving
around the removable drives.
Moving the home directory and creating the symlink is handled for you
by the script: /usr/local/sbin/adduser.local, which gets run automat-
ically as a part of user-creation. You should not need to worry about this
script at all unless you are changing the user-creation process.
4.3.10 User groups

There are a couple of important groups on the pr2:
admin – Members of this group have full root privileges when using
the sudo command
rosadmin – Members of this group have access to change ros-specific

configuration settings in /etc/ros
apt – Members of this group can install new software
To add a user to a group, use the usermod command. The most common
invocation uses the options -a (append) and -G (group). For example:
pr2admin@c1$ sudo usermod -a -G admin bob

4.3.11 Backing up and restoring users

Before reinstalling the robot operating system you will likely want to back up
the user accounts. This can be done with the command: pr2-usermigrate.
To save users:
pr2admin@c1$ sudo pr2-usermigrate save myrobot.users
Move this file off the robot before reinstalling. Then, to restore users:
pr2admin@c1$ sudo pr2-usermigrate load myrobot.users
4.3.12 Clock synchronization

Consistent time-stamping of data from the two computers is important for
interpreting sensor data on a moving system. As a result, keeping the system
time on the two computers synced together requires some attention. The
system that is used for this is chrony, and the general strategy is to have
the two computers tightly coupled to one another, but loosely coupled to
an external time source to prevent the robot time from drifting too far from
the outside world.
Sometimes the clocks on the computers get into an inconsistant state.
This will show up as an error in the pr2dashboard as: “NTP offset from
XXX to YYY: Offset too great”.
If you find your clocks in an inconsistant state, you may want to try
restarting chrony on the basestation, c1, and c2, in that order.
pr2admin@basestation$ sudo /etc/init.d/chrony restart

pr2admin@c1$ sudo /etc/init.d/chrony restart
pr2admin@c2$ sudo /etc/init.d/chrony restart
You should see the message:
Restarting time daemon: chronyd is running and online.
If you see the message:
Restarting time daemon: chronyd is running and offline.
You should restart chrony again.

4.3.13 Configuring the System ROS installation
The system ROS installation is managed by a set of configuration files in

/etc/ros. This configuration determines which distro is used, which ROS
processes are launched by default, and contains the calibrated description of
the robot URDF. The default configuration files are provided by the pack-
age: pr2-core. Additionally, there are packages, pr2-core-boxturtle, and
pr2-core-cturtle, which provide specific configurations and dependencies
for the different ROS distributions.
In order to change which ROS distro is used by default, you simply need
to change the symlink /etc/ros/distro to point to a different distribution.
The two important entry points to /etc/ros that most users need to
know about are /etc/ros/setup.bash and /etc/ros/robot.launch. Note
that each of these is actually just a symlink to the corresponding file in
/etc/ros/distro. To make use of a specific distribution, you can explicitly
use, e.g., /etc/ros/boxturtle/setup.bash.
/etc/ros/setup.bash works by loading a number of environment vari-
ables from files stored in /etc/ros/distro/env/. The contents of each of
these files will be loaded into the environment variable of the corresponding
name.
/etc/ros/robot.launch is responsible for setting up the robot config-
uration and then launching the minimal set of nodes for robot functional-
ity. The robot.launch files for different distros may need to load different
URDFs or analyzer files. It is important that this file should use distro-
relative paths rather than depending on the “distro” symlink. For example,
in boxturtle, it will use “/etc/ros/boxturtle/urdf/robot.xml” rather than
“/etc/ros/distro/urdf/robot.xml.” This allows the launch file to be used
even if the distro symlink points to a different distribution.
Finally, /etc/ros/sensors/ is a directory containing logical symlinks to
sensors. While we have provided udev rules to mount sensors in consistant
locations in /dev/sensors/, this 2nd layer of indirection allows us to create
a symlink such as /etc/ros/base hokuyo, rather than having to modify
robot.launch to use something like /dev/sensors/hokuyo H0902620.
The two hokuyos are the most likely devices to be configured incorrectly.
If the lasers are switched, swap the symlinks for /etc/ros/sensors/base hokuyo
and /etc/ros/sensors/tilt hokuyo. Note that /etc/ros/sensors on c1
and c2 are different. To modify the symlinks on c2, you actually need to
modify /slave/etc/ros/sensors from the c1 machine.
Switching ROS Distributions Example
Example to switch from ROS boxturtle to ROS cturtle:
pr2admin@pr10XX:/etc/ros$ ls -l distro
lrwxrwxrwx 1 root rosadmin 9 2010-11-10 15:27 distro -> boxturtle
pr2admin@pr10XX:/etc/ros$ sudo rm distro
pr2admin@pr10XX:/etc/ros$ sudo ln -s cturtle distro
pr2admin@pr10XX:/etc/ros$ ls -l distro
lrwxrwxrwx 1 root root 7 2010-11-12 10:19 distro -> cturtle
4.3.14 Log files
The PR2 is configured to consolidate all system logs into /var/log/messages.
4.3.15 Udev
We have provided a number of custom udev rules to help give sensors

more meaningful names. These are all stored in /etc/udev/rules.d/.
71-pr2-network-interface.rules is responsible for renaming the network
interfaces as lan0-lan4, wan0, and ecat0 consistantly based on mac-address
ranges. 73-pr-aliases.rules makes convenient aliases for the hokuyos,
imu, batteries, and joystick. All of these aliases end up in /dev/sensors/.
Finally 74-pr-disk.rules is responsible for ensuring that the removable
drive always just shows up as /dev/removable.
It is important to note that the creation of these udev rules depends on
a functioning ROS system. If the ROS configuration from /etc/ros is non-
functional, udev will not be able to talk to the hokuyos to create appropriate
symlinks. In the future there may be more sensors that depend on ROS for
this initial configuration as well.
4.4 Basestation Setup and Pairing

Before you can use the robot and basestation, it needs to be configured.
This configuration can be done by logging into the basestation. The default
account is “pr2admin” with password “willow”. The following instructions
assume that the basestation is plugged into the robot via the service port.
4.4. BASESTATION SETUP AND PAIRING 59
4.4.1 Requirements
Naming
In order for ROS to work properly, it depends on each computer in your
system being able to correctly resolve the hostnames of all other computers
in your ROS system. For an in depth explanation, please familiarize yourself
with http://www.ros.org/wiki/ROS/NetworkSetup. However, in short, you
are probably going to need 3 hostnames, and 3 IP addresses – one for the
basestation, and one for each of the two robot computers. Each of these 3
hostnames MUST either be resolved by your building network DNS server,
or else they will need to be added to the /etc/hosts file of all the relevant
computers.
IP Address configuration
For the robot to be able to find the basestation, it needs to be given a
constant IP address. Unless you have a reason not to, this IP address should
be assigned to the basestation statically. However, if you are certain that
your DHCP server will always assign the same IP, it is ok for this IP to be
assigned via DHCP.
The IP address assigned to your basestation must be visible on both the
wired and wireless segments of your building network on port 1194. This is
the port that VPN uses when the robot makes its connection back to the
basestation (it can be changed by appropriately modifying /etc/openvpn/server.conf
on the basestation, and /etc/openvpn/basestation.conf on the robot).
Depending on how secure your network is, and whether these segments are
separated by a firewall, you may need assistance from your local sysadmin
to allow traffic through on this port.
Finally, for the robot to be able to find the basestation, both the wired
and wireless networks must provide a DHCP server. The operation of the
system is that the robot will acquire an IP address via DHCP and then
contact the basetation at the known IP address that it is paired to. Review
the section on Networking for a more thorough overview.
Examples
In the remainder of the examples in this section we will assume that our
basestation has been given the hostname prbase1, and our computers will
be named prx1 and prx2. We assume that DNS resolves them correctly as
follows:
prbase1 – 192.168.1.100
prx1 – 192.168.1.101
prx2 – 192.168.1.102
4.4.2 Plugging things in
Power keyboard WAN0 LAN0 DVI
When plugging in the basestation, make sure that you plug WAN0 (on
the motherboard) into your building network. LAN0, on the PCI card, is
only intended to be plugged into the robot service port.
Additionally, it is important to plug the DVI port into the installed
graphics card (on the right side of the computer) and not the extra DVI
port on the motherboard.
There is only one place to plug in the power, and your keyboard/mouse
can be plugged into any of the available USB ports.
4.4.3 Configure the Basestation Network

There are two ways to set up the basestation, using a static IP, or DHCP.
It is strongly recommended that you use a Static IP unless you have a very
good reason to use DHCP and understand configuring your DHCP server
to obey client-id-based requests.
1. Configuring IPs
Static IP – To configure the basestation with a static IP, you must
edit the file /etc/network/interfaces and change wan0 to use a
static ip address, for example:
iface wan0 inet static

address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
post-up robot-forward start
pre-down robot-forward stop
You will also need to update /etc/resolv.conf to contain the appro-

priate nameserver, e.g.,
domain school.edu
search school.edu
nameserver 192.168.1.1
DHCP – If you are using DHCP, you must make sure that your DHCP
server respects the client-id specification and is configured to assign
a consistant IP address to the client-id of the basestation. NOTE:
macaddress based assignment of IPs will not work correctly because the
basestation also acquires IPs on behalf of the robot. The default client-
id for the basestation is “basestation.” If you need to change this to a
different client-id, you must edit the file /etc/dhcp3/dhclient.conf,
and change the relevant line, for example
send dhcp-client-identifier "prbase1";
2. Configuring Hostname
You will also likely need to change the hostname of the basestation. Leaving
it as “basestation” is ok, but you need to make sure the DNS server correctly
resolves this name to the IP address you have assigned the basestation. To
change the hostname you will need to edit the files: /etc/hostname, to just
contain the name of the basestation. For example:
prbase1
and edit /etc/hosts to resolve the basestation locally. After modifying,

/etc/hosts it should look something like:
127.0.0.1 localhost
127.0.1.1 prbase1.willowgarage.com prbase1
10.68.255.1 prbase1.willowgarage.com prbase1
10.68.0.1 c1
10.68.0.2 c2
# The following lines are desirable for IPv6 capable hosts

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Finally, you need to actually set the hostname using the hostname command,
for example:
pr2admin@basestation$ sudo hostname prbase1
3. Applying Settings
Once you have reconfigured the network, you should reboot the basestation
to make sure the network comes back up correctly. At this point you should
be connected to your local network and be able to ping any machine that
you may want to access the robot from.
4.4.4 Configure the Robot Wifi

The Linksys wrt610n on the robot is located at the IP address: 10.68.0.5.
To configure it, either plug a laptop or a basestation into the robot ser-
vice port, open a web-browser and go to: http://10.68.0.5. Click on the
“Wireless” tab. The default login should be “root” and “willow,” although
after a factory reset the router may end up with login, “root” and “admin”.
Set either “Wireless Physical Interface wl0” (for 2.5 Ghz) or “Wireless Phys-
ical Interface wl1” (for 5 Ghz) to client mode and enter the SSID for your
network. If you need to change other settings, make sure that under “Setup,”
the WAN connection type is “Automatic Configuration - DHCP”, the local
IP Address is 10.68.0.5, and the DHCP Server is Disabled. When you are
done, make sure you choose to “Apply Settings.”
To test the setup of the wireless, you can temporarily add a specific
route on the basestation which will route a particular IP address through
the wifi router, and then try to access that ip address. If you can reach
that IP address once the routing entry is added, you know the wifi router
is connected properly. For example, to route requests to the willow garage
website through the wifi-router explicitly:
$ sudo ip route add 157.22.19.22 via 10.68.0.5 dev lan0
Then point your web-browser to: http://157.22.19.22. This should take

you to the willowgarage home page via the wireless router.
If your building-infrastructure wireless access point requires accepting
an EULA, this method will typically give you an opportunity to accept it.
Once that is working, you should remember to disable the route so that
it works if the basestation is not plugged into the service port:
$ sudo ip route del 157.22.19.22 via 10.68.0.5 dev lan0
4.4.5 Initialize the Basestation VPN Server

One of the primary functions of the basestation is to host a VPN server that
the robot can connect to. The server needs an appropriate key. To generate
the key for the VPN server run:
pr2admin@basestation$ sudo /etc/openvpn/gen_server_key
It will prompt you for some information. It is good practice to get the
information correct, but will not actually impact the performance of the
robot.
4.4.6 Pairing with the Robot

Robot pairing is performed with the the robot-brand command on the
basestation. It takes 5 arguments:
pr2admin@basestation$ sudo robot-brand <ROBOT_NAME> <C1_NAME> \

<C2_NAME> <VPN_SUBNET> [<BASESTATION_IP>]
ROBOT NAME – This is the name your robot will be given.
C1 NAME – This is the intended hostname of c1. Your DNS server needs
to resolve this to the IP address you intend to use for your robot.
C2 NAME – This is the intended hostname of c2. Your DNS server needs
to resolve this to the IP address you intend to use for your robot.
VPN SUBNET – Unless you are using multiple robots, this should be
10.68.1.0. The 3rd field of the IP, however, can be any value other
than 0 and 255, which are reserved for the robot local network and the
basestation server respectively. No two robots on the same basestation
should be assigned the same VPN subnet.
(OPTIONAL) BASESTATION IP – By default this is taken from the

IP assigned to wan0. It is worth checking that it is correct using the
ifconfig command:
pr2admin@basestation:~$ ifconfig wan0
wan0 Link encap:Ethernet HWaddr 00:30:1b:48:c8:f8
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:1bff:fe48:c8f8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2702 errors:0 dropped:0 overruns:0 frame:0
TX packets:2709 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:129699 (129.6 KB) TX bytes:218528 (218.5 KB)
Interrupt:17
In this case the address is 192.168.1.100.
To actually brand the robot, first plug the basestation into the service
port of the robot, and then use the robot-brand command
For example, if your robot were going to be named “prx”, c1 was going
to named “prx1”, c2 was going to be named “prx2”, and you wanted to use
the default 10.68.1.0 192.168.1.100, you would run:
pr2admin@prbase1$ sudo robot-brand prx prx1 prx2 10.68.1.0
During the branding process, it may prompt you for the password of
“root@c1”. By default this will be “willow”. Additionally, you may be
prompted to choose a password for the pr2admin account.
When the script finishes, you should be able to connect to the robot over
the VPN. Check that it works and then exit.
pr2admin@prbase1$ ssh pr2admin@10.68.1.1

pr2admin@prx1:~$ exit
4.4.7 Forwarding IPs to the robot

To make contacting the robot from your building network more convenient,
the basestation can be configured to forward IP addresses (assigned statically
or via DHCP) to the robot. This is achieved through a combination of ip-
tables rules and additional ip addresses claimed by the basestation.
First we want the basestation We want the robot to claim a couple extra
IP addreseses. These are the IPs that you will use to contact the robot
from your local network. Eventually these IP addresses should show up in
ifconfig, for example:
wan0:prx1 Link encap:Ethernet HWaddr 00:30:1b:48:c8:f8

Interrupt:17
wan0:prx2 Link encap:Ethernet HWaddr 00:30:1b:48:c8:f8

Interrupt:17
Additionally, we want ip-tables to forward each of these IP addresses to

the respective robot computer in the VPN. In our IP tables (viewable with
iptables-save we would expect to see something
-A PREROUTING -d 192.168.1.101/32 -j DNAT --to-destination 10.68.1.1

-A PREROUTING -d 192.168.1.102/32 -j DNAT --to-destination 10.68.1.2
-A POSTROUTING -s 10.68.1.1/32 -j SNAT --to-source 192.168.1.101
-A POSTROUTING -s 10.68.1.2/32 -j SNAT --to-source 192.168.1.2
-A OUTPUT -d 192.168.1.101/32 -j DNAT --to-destination 10.68.1.1
-A OUTPUT -d 192.168.1.2/32 -j DNAT --to-destination 10.68.1.2
Setting this up by hand is tedious and time-consuming. Instead we

provide a utility called robot-forward, which takes care of setting this up
automatically.
To set this up, edit the file: /etc/robot-forward.conf and add the
lines:
<C1_NAME> <VPN_SUBNET>.1 <ROBOT_IP1>

<C2_NAME> <VPN_SUBNET>.2 <ROBOT_IP2>
For example, in our case we would use:

prx1 10.68.1.1 192.168.1.101

prx2 10.68.1.2 192.168.1.102
Note that for this to work properly, we should have named our robot
computers prx1 and prx2, respectively, and furthermore our DNS server
should resolve “prx1” to 192.168.1.101, and “prx2” to 192.168.1.102.
Much like the basestation, you can also have these IPs assigned via
DHCP:
prx1 10.68.1.1 dhcp
prx2 10.68.1.2 dhcp
In which case the basestation will use the client-id’s “prx1” and “prx2”
to acquire 2 IP addresses from the DHCP server. These IPs should be
assigned consistantly given the client-id’s, and should match the IPs that
the DNS server returns for the particular hostnames.
Robot forwarding is enabled whenever the networking starts, but to man-
ually start forwarding, you can run:
pr2admin@prbase1$ sudo robot-forward start
You should now be able to contact the robot at the IP address you have
given it, and, if your DNS server is set up properly, using it’s hostname. For
example:
pr2admin@prbase1$ ssh pr2admin@192.168.1.101
and
pr2admin@prbase1$ ssh pr2admin@prx1
If you need to disable forwarding you can run:
pr2admin@prbase1$ sudo robot-forward stop
At this point you should be done configuring the basestation to work on
your network.
4.5 Reinstall the Basestation

If you have a basestation USB installer, you can reinstall the basestation to
revert it to a completely fresh state. Creating a new USB installer is outside
the scope of this manual, but instructions for downloading and creating one
can be found on the PR2 website.
4.5. REINSTALL THE BASESTATION 67
4.5.1 Booting off the USB installer

To boot off the USB installer:
Insert the USB stick into one of the USB ports in the basestation
Reboot the basestation
Press the <DEL> key to enter setup
Choose “Advanced BIOS Features”
Choose “Hard Disk Boot Priority”
Select the drive listed as “USB-HDD0” and hit “Page Up” to make it
number 1
Hit “F10” to save and exit the setup
The computer should boot off of the USB stick.
If the installer complains about not being able to find the ISO, choos
“Scan Hard Drive for ISO...” and then hit “Enter” to continue.
Once the installer is actually progressing, it will take about half an

hour to complete.
When the installer completes, hit “Enter” to shut down and remove
the USB stick.
When the basestation boots you should have a fresh image – consult
the section on Basestation Setup and Pairing to configure the bases-
tation.
4.5.2 Booting off the DVD installer

To boot off the DVD installer:
Insert the the DVD into the drive on the basestation.
Reboot the basestation
Press the <DEL> key to enter setup
Choose “Advanced BIOS Features”
Choose “Hard Disk Boot Priority”

Select the “CDROM” and hit “Page Up” to make it number 1
Hit “F10” to save and exit the setup
The computer should boot off of the USB stick.
If the installer complains about not being able to find the ISO, choose
“Scan Hard Drive for ISO...” and then hit “Enter” to continue.
Once the installer is actually progressing, it will take about half an

hour to complete.
When the installer completes, hit “Enter” to shut down and remove
the USB stick.
When the basestation boots you should have a fresh image – consult
the section on Basestation Setup and Pairing to configure the bases-
tation.
4.6 Reinstall the Robot

To reinstall the robot, first back up anything you need off of c1. Next,
shutdown the comptuers using pr2-shutdown --netboot.
You must then plug the service port directly into the basestation. You
can then run the robot installer:
pr2admin@basestation$ sudo robot-install
Boot c1 by pushing the power button with a paperclip.

After N minutes, the netconsole on the basestation will show the install
dialog. Hit enter to start the installer and wait for it to complete.
Once the installer has completed and the robot is shut down, you can
boot it up. You will now need to pair it with the basestation before you can
use it.
4.6.1 Forcing netboot

If the robot BIOS is not configured to netboot, you might need to be able
hit f12 on the keyboard. You can do this in one of two ways.
The easier way to to connect up to the KVM. (See section XYZ on
connecting to the KVM.)
4.7. SOFTWARE MAINTENANCE 69
Alternatively, plug a keyboard into the PR2. This can be done using
the aux usb port under the back cover. To remove this cover, follow the
instructions in section XYZ.
When the robot is booting you will hear 2 beeps followed by a short
pause, and then another 2 beeps. After the 4th beep, hit f12 on the keyboard
(either physically or through the KVM) to force c1 to netboot.
4.7 Software Maintenance

When the robots ship, the most recent version of ROS and the PR2 software
stacks is installed in /opt/ros. By default, new users will have a ROS in-
stallation which references the pre-installed code. Users who wish to modify
or replace a part of the system are recommended to install a development
version of the stacks or packages which they wish to modify, but to continue
to use the base installation for most of the robot functionality.
Debian packages exist for all of the custom software and configurations
on the robot. The package which pulls in all the other requirements is called
pr2-environment. pr2-environment depends on pr2-core, which in turn
depends on ros-boxturtle-pr2, the meta-package which contains all of the
ROS software for the PR2.
To upgrade the software on your robot, you can simply use apt:
$ sudo apt-get update

$ sudo apt-get dist-upgrade
Which will update all packages on your system, pulling in security fixes
for the pr2 configuration as well as for the appropriate ros-release.
4.7.1 Fixing the nvidia module

Occasionally upgrading the basestation will cause a new kernel to be in-
stalled. When this happens, the nvidia module which we build for the kernel
will no longer work. If this happens, once you reboot, X will fail to start.
Choose the option to to exit X. The script to re-build and install the mod-
ules is located in /usr/src/NVIDIA-Linux-x86 64-195.36.15-pkg2.run.
Simply run it:
pr2admin@basestation$ $ sudo /usr/src/NVIDIA-Linux-x86_64-195.36.15-pkg2.run

4.8 Default Password Reference

There are many different devices which make up the PR2. Many of these
have passwords which should be changed for security purposes. The default
logins and passwords are:
Basestation (10.68.0.6). Standard unix logins:
– root - willow
– pr2admin - willow
C1 (10.68.0.1). Standard unix logins:
– root - willow
– pr2admin - willow
C1 (10.68.0.1). Web-interface login:
– admin - admin
– guest - guest
C1 ESMS (10.68.0.91)
– root - changeme
C2 ESMS (10.68.0.92)
– root - changeme
Wireless Router (10.68.0.5).
– root - willow
Wireless Access Point (10.68.0.250))
– root - willow
Chapter 5
Setting up PR2 in your lab
5.1 Taking PR2 out of the crate

The PR2 will arrive in a large crate, it is important to place the crate in
an open area with at least 10 feet of space infront of the the panel labeled
FRONT, Figure 5.1, and 5 feet on all other sides (including behind the
crate).
Figure 5.1: The space required to uncrate a PR2.
Now that there is adequate room around the crate, begin opening the
crate by unlatching the metal latches around the panel labeled OPEN
71
72 CHAPTER 5. SETTING UP PR2 IN YOUR LAB
THIS PANEL FIRST, Figure 5.2. Lift the latch up then rotate the latch
handle counter-clockwise until the hook is extended and no longer engaged.
Finally push the hook outwards to disengage the latch.
Figure 5.2: PR2 crate twist latch.
Unlatch the six latches on the front panel and set the panel aside for
use later. Inside the crate is a vaccuum sealed PR2, Figure 5.3, unlatch
and remove the two boards holding the head in place. After the boards are
removed, unlatch all of the latches aroung the bottom of the crate. Make
sure that all of the latch hooks are pushed down and out of the way.
Figure 5.3: Steps for remvoing the crate.
Now the top of the crate is completely unlatched. Verify that the
two boards holding the head in place have been removed, and then
with two people grab opposite sides of the crate and slowly walk the crate
backwards off the crate base. Remove all of the plastic wrapping and tape
5.1. TAKING PR2 OUT OF THE CRATE 73
from around the foil vaccuum wrapping. Once the wrapping is removed cut
the foil wrapping about one foot up from the seam all the way around the
base of the robot, this will leave enough material for repacking the robot
if needed. Pull the foil wrapping off and remove the dessicant bags from
around the PR2, Figure 5.4.
Figure 5.4: Removing the foil wrapping, dessicant bags, and foam coverings.
Slide the foam coverings off of the arms and over the base laser, then
remove the bracing straps on each side of the head, Figure 5.5, using an
4mm allen wrench (this can be found in the robot toolkit). Place the straps
and screws in a bag for later use when repacking the PR2.
Figure 5.5: Removing the head straps and pushing back packaging.
Push back the foil wrapping and other materials to reveal the platform
in the base of the crate. In the crate base beneath the PR2 platform is
a support board that must be removed before unscrewing the bolts and
lowering the platform, Figure 5.6. Push the board from one side so that it
protudes out the other side and pull it free.
Figure 5.6: Removing support board, unscrewing and removing bolts.
Once the support board is free, use the drill to unscrew the bolts around
the crate base making sure that the two bolts in front of the robot come
completely out of the nuts. Unlatch the board in front of the PR2 base
and set it aside. With two people, take the panel labeled OPEN THIS
PANEL FIRST with the label face up, so that the boards act as rails on
the side of the panel, and lay the panel on the edge of the platform aligning
the pegs with the holes in the panel, as shown in Figure 5.7.
Figure 5.7: Using the OPEN THIS PANEL FIRST panel as a ramp.
With the ramp in place, walk to the back of the robot and switch on the
power switch as shown in Figure 5.8. Once the PR2 computers are booted
connect to the PR2 wifi (PRXXXXLAN) using your wifi manager. The
default password is ”willow”. After connecting to the wireless access point on
the robot you can ssh into the robot as pr2admin with the default password
of ”willow”. Once you are logged into the robot follow the directions outlined
5.1. TAKING PR2 OUT OF THE CRATE 75
in Chapter 6 to drive the robot down the ramp.
Figure 5.8: Switching on the PR2.
Please keep all shipping materials, including the crate, in storage. They
are useful for moving the PR2 to another location, and will be required if
you ever have to ship the PR2 back to Willow Garage for service.
Chapter 6
Running the PR2
Running the PR2 requires a basic understanding of ROS (http://www.ros.org),

the BSD-licensed Robot Operating System. A ROS system consists of mul-
tiple processes running on multiple computers. If you are not familiar with
ROS, it is highly recommended that you follow some of the beginner tutori-
als on ros.org. Familiarity with ROS tools will make using the robot much
easier. In particular, you should understand what a launch file is and how
to run it, and how to run ROS with nodes on multiple computers. This
chapter will walk you through starting up and running a PR2, using ROS.
6.1 Getting set up

6.1.1 Out of the box
If you are starting your PR2 for the first time at your institution, please
read the previous chapter, ??. This will give you advice on setting up the
network, setting the administrative password, and picking a safe location
for charging the PR2. This chapter assumes that the PR2 is already set up
for your lab.
6.1.2 Batteries and power

Before running the robot, you need to make sure it has power, which is
easiest to do by making sure the robot is plugged in to a wall outlet. You
can follow the instructions in this chapter to start up the PR2 while it is
plugged into the power outlet, which will keep the batteries charged. The
battery life of the PR2 is approximately two hours, so it is a good idea to
keep the PR2 plugged in when not in use.
77
78 CHAPTER 6. RUNNING THE PR2
6.1.3 Run-stop
Before running the robot, you should also have the wireless run-stop nearby
(Figure 6.1), so that you can shut down the motors if you need to.
The PR2 has two run-stop buttons: the red push-button on the middle
of the PR2’s back, and the yellow wireless run-stop transmitter. If either one
is in the stop position, the motors are disabled so the robot cannot move. In
an emergency, press the stop button on the wireless transmitter,
or hit the push-button in the back. Putting either run-stop button in
the stop position does not damage the robot or turn off the computers, it
simply stops the motors.
Figure 6.1: The PR2 wireless run-stop.
The wireless run-stop is also powered by batteries, which can run down.
Therefore, it is a good idea anyway to turn the wireless run-stop off (by
pressing the ”STOP” button) when not in use. If the wireless run-stop runs
out of battery charge, then the battery light (the light next to the battery
symbol in the lower half of the wireless run-stop face) will flash. To change
the battery, you will need a slotted screwdriver to open the wireless run-stop
case (Figure 6.2).
6.1.4 Getting an account
Before using the PR2, you will also need an account on the robot comput-
ers. Ask the robot administrator to create an account for you, using the
instructions in section ??.
6.2. TURNING ON PR2 79
Figure 6.2: Opening the PR2 wireless run-stop to change the batteries.
6.2 Turning on PR2

If the robot is already running, you can skip this step, but you should still
put the wireless run-stop in the stop position.
To turn the PR2 on, you should first verify that the wireless run-stop
is in the stop position. If it is not yet in the stop position, then press the
wireless run-stop’s red “STOP” button; the lights on the wireless run-stop
should turn off.
Second, switch the red run-stop button on the back panel of the robot
to the “on” position; turn it clockwise and it will pop out.
Third, if the DC breaker switch at the back panel of the robot is switched
off, then flip the DC breaker switch (Figure 6.3) to the “on” position.
Figure 6.3: The PR2 DC breaker switch in the ON position.
You should see the red lights on the computers turn on, hear the fans
spin up, and hear several rising-tone beeps from the computers as they boot.
The process of booting the computers will take about 5 minutes. You will
know that the computers are on when you see a red light illuminate on each
of the computers in the robot base.
6.2.1 Logging in
Once the robot is on, ssh into the main computer using the account created
for you by the administrator, using the steps below.
In the following tutorial, we will use pr<x>1 to refer to the first computer
on robot <x> and <username> to refer to your account username. Ask your
robot administrator what name you should use for the robot you want to
run.
To log in to the robot, open a terminal window and type
$ ssh <username>@pr<x>1
You should already have access to all the ROS tools. For instance, to see
what packages are available to you, type
$ rospack list-names
and you should see a list of the ros packages currently in your path.
6.2.2 Checking for other users

If you logged in to a robot that was already running, you should check to
see if anyone else is using the robot. To find out who else is using the robot,
type
$ ckill list
This will show you what programs are currently running on the robot. If
nothing shows up, then no one else is logged into the robot. If other people
have processes running on the robot, you will need to find out if you can
interrupt their work. You should find out who is on the robot and ask them
to allow you to kill their processes so that you can work on the robot. If
you cannot find the people running processes on the robot, ask the robot
adminstrator for guidance on what the policy is in your lab. If it is fine for
you to kill the other processes running on the robot, you can type
$ sudo robot stop
and all the processes that are being run on the robot will be killed.
6.3. STARTING THE SOFTWARE 81
6.3 Starting the software

The launch file /etc/ros/robot.launch is used to start up the basic function-
ality of the robot. This includes drivers for the sensors, motors, speakers,
projector, power system, and joystick as well as the default set of realtime
controllers, processing and logging of diagnostics information, and monitors
for various types of problems your robot could experience. On a new robot,
this launch file is standard, but if the robot you are working on has been
altered (e.g., has additional sensors, has only one arm), then it is likely that
someone administering the robot has also updated the /etc/ros/robot.launch
file to work with your robot’s configuration.
There are two ways to start the software on the PR2. The first way is
easier than the second way.
6.3.1 Starting the software the easier way

Once you are logged in and ready to start the robot, you can run the robot
by typing
$ sudo robot start
Running robot start will start the roslaunch for you in the background as
a system user. This will allow you to continue to use your current terminal
and the robot will keep running after you log out.
To see what topics are being published in ROS now, you can type
$ rostopic list
This is a good way to check to see if you started up ROS successfully.
6.3.2 Starting the software the manual way

As an alternative to starting the software the easier way, you can also start
the software manually. If you prefer to see everything that is going on, you
can also start the robot software manually, but you will need to keep that
window open until you are done using the robot. Closing that the terminal
in which you roslaunched will terminate the roslaunch.
$ roslaunch /etc/ros/robot.launch
to start up the pr2.

If you used “roslaunch” to start the robot, then you will need to open a
new terminal and type
$ rostopic list
to see what topics are being published by the system in the new terminal
while the roslaunch continues to run in the original terminal. Remember
that <x> is a placeholding variable to be replaced with the ID of the robot
you are using.
Either way, the robot should be running, but since you have the wireless
run-stop in the stop position, the motors will not be moving.
6.4 Running the dashboard

When running the robot, the pr2 dashboard should always be up on your
screen. This is how the robot software will let you know if something is
going wrong, and is also how you turn the motors and power on and off.
On a computer with a built ROS installation (e.g., the base-station desk-
top computer that ships with the robot), not on the robot itself, set your
ROS MASTER URI to point at the master running on the robot and launch
the dashboard by typing
$ export ROS_MASTER_URI=http://pr<x>1:11311
$ rosrun pr2_dashboard pr2_dashboard
You should see the pr2 dashboard control panel (a graphical user interface)
appear and provide you with information about the state of the robot. It is
ok if not all of the icons are green. In fact, the run-stops should be “warning”
you that the wireless runstop is not on.1
Take a moment to review the state of the robot. You can get a sense for
the health of your robot by looking at the diagnostics information; click on
the wrench on the far left. Since you have the run-stop in the stop position,
you see that the motors are giving you a warning because the robot was just
turned on and the encoders on the joints have not been calibrated yet.
If you see warnings or errors in any other sections, you should read the
error messages and try to figure out what the problem is. Ask your robot
administrator for help if there are errors that you do not understand.
1
If you do not see the pr2 dashboard control panel appear, then there is a chance that
you have not yet built the pr2 dashboard. To do this, type rosmake pr2 dashboard to
build pr2 dashboard. Once this is done, you can try launching the dashboard again.
6.4. RUNNING THE DASHBOARD 83
6.4.1 Understanding pr2 dashboard
When running the PR2, the most important piece of software for you to un-
derstand and control the state of the system is the pr2 dashboard. pr2 dashboard,
Figure 6.4, is a GUI for debugging and controlling low-level state of the PR2.
The dashboard displays the diagnostic, circuit breaker, run-stop, and bat-
tery status. The robot will not usually start up with all green lights. In fact,
Figure 6.4: The PR2 dashboard when starting up the robot.
if you bring up the robot properly, then you should see a dashboard display
that looks more like Figure 6.4. This is because the wireless run-stop should
be in the stop position. You can tell that the wireless run-stop is in the stop
position by mousing over the dashboard to see the tooltips, which describe
what each icon means. See Figure 6.5.
Figure 6.5: The PR2 dashboard when starting up the robot, showing
tooltips.
The following sections describe the other information displayed in the

dashboard. Some of the indicators in the dashboard can have a status of
“stale.” This means that some component of the robot has stopped reporting
status information. A stale status is usually caused by a network problem
(e.g., bad wireless connection from the base station to the robot).
Diagnostic Status The state of the robot is shown by the diagnostic in-
dicators in the pr2 dashboard.
Component OK Warn Error Stale
Diagnostics: Clicking pops up the

Robot Monitor
Rosout: Clicking pops up rxconsole
Motors: Clicking allows you to halt

N/A
or reset motors
Circuit Breaker Status The circuit breakers are labeled L/B/R, which
stand for Left Arm, Base/Spine, and Right Arm. Each breaker can be
in one of four states, and clicking on any of the breakers will pop up
a menu (Figure 6.6), allowing you to change the state of one or all of
them:
Figure 6.6: The circuit breaker options menu.
Enabled Standby Disabled Stale

Breaker Status
Run-stop Status The runstop indicators display the status of the PR2
runstops and their states cannot be changed using the dashboard.
There are two run-stops on the robot, a wireless run-stop, see 3.1.2,
and a red push button run-stop on the back of the robot.
Physical Stop Wireless Stop

OK
is Off is Off
Runstop Status
Battery Status The battery will change its color and % filled based on the
6.5. CALIBRATING THE JOINTS 85
amount of battery remaining. It will also show a power-plug symbol

if the robot is charging.
> 50% 30 - 50% < 30% Charging

Battery Status
6.5 Calibrating the joints
If you do not discover any problems in the diagnostics, and you want to
continue with robot bringup, first check the physical area around the robot
to ensure that the robot will not hit anything around it when it calibrates.
The robot’s arms will be fully extended and the spine will move up and
down during calibration. Once the physical area is cleared, press the green
“START” button on the wireless run-stop. This should change the state of
the run-stop indicator on the dashboard to a green circle, and will allow the
robot to turn power on for the motors.
If the robot circuit breakers are not yet enabled, the next step is to enable
the circuit breakers (marked L, B, R). When you click on the circuit-breaker
icon, select “enable all” from the menu to turn on all three breakers.
If the robot motors are not yet reset, then click on the picture of a motor,
and select “reset motors.”
When you have started the wireless run-stop, enabled all the robot circuit
breakers, and have reset thr boto motors, the robot will move its joints to
find the absolute reference positions of each joint so that it can calibrate the
mechanism. When calibration is finished, you should see all the icons in the
dashboard reading OK (Figure 6.7).
Figure 6.7: The PR2 dashboard when the wireless run-stop is in the start
position.
If this calibration step fails, then you can use the pr2 dashboard to diag-
nose the problems with the robot. See your robot administrator if you need
assistance in understanding and addressesing the issues.
6.6 Tucking the robot arms
Before driving a robot around, it is best to tuck the robot arms. If you do
not tuck the robot arms before driving, then the arms are likely to swing
around while the robot is moving.
To run the tuckarm package, type into the robot computer (pr<x>1):
$ rosrun pr2_tuckarm tuckarm.py b
This will tuck both robot arms. The feedback from tuckarm should display
something like this:
[INFO] 1264099125.710039: Waiting for controller manager to start

[INFO] 1264099125.718283: Tucking both left and right arm
For more information about how to drive the robot around, see the
tuckarm instructions at ros.org.
6.7 Driving with the joystick
To move the robot, you can now drive it around with the joystick. To do
this, you will need to open a new terminal window with a new ssh connection
to the robot and run the teleop joystick launch file
$ roslaunch pr2_teleop teleop_joystick.launch
Be sure to check to see if the robot is plugged in (e.g., ethernet cables

or power cables)! If it is plugged in, then be very cautious to avoid pulling
the cables out improperly.
Once the teleop joystick node is running, press the pairing button (Fig-
ure 6.8) in the middle of the joystick to pair it with the robot. Be sure
to unplug the robot from wall outlets if you are going to drive the robot
around.
6.7. DRIVING WITH THE JOYSTICK 87
Figure 6.8: Pairing the joystick with the PR2.
Then to control the robot, use L1 (Figure 6.9) as the “deadman” switch.
L1 should be held down with your left pointer finger (like a trigger) whenever
you wish to control the robot. If you let go of the L1 button, then commands
will no longer be sent from the controller to the robot. While pressing L1,
use the other buttons for the following movements:
Figure 6.9: The PS3 controller mapped to robot movements.
1. L1 (left pointer finger): The “dead man” switch allows the controller
to send commands to the robot. If the “dead man” is disabled, no
commands will work.
2. L2 (right pointer finger): The head switch allows the joysticks to con-
trol the head instead of the base
3. Right joystick (right thumb): Translates the base or head (i.e., front,
back, left, right)
4. Left joystick (left thumb): Rotates the base or head (i.e., spin clockwise
or counter-clockwise)
5. R1 (left pointer finger): The “run” switch commands the base to move
faster
6. Triangle and X (right thumb): Moves the torso up and down
To drive the robot around (i.e., driving the base), hold down L1 and use
the two joysticks to control its direction of movement (right joystick) and
rotation (left joystick). To drive the robot around at faster speeds, also hold
down R1.
To move the robot head, hold down L1 and use the two joysticks to
control the head movements.
To move the robot torso, hold down L1 and press the triangle button
to move the torso up or the X button to move the torso down. The torso
moves slowy.
For more information about how to drive the robot around, see the ps3joy
tutorial at ros.org.
6.8 Visualizing sensor data

To see the sensor data from the robot, you can use rviz on the offboard
computer (e.g., base station). Again, you will need to open a new terminal
window and configure the ROS MASTER URI to point at the robot, so run
$ export ROS_MASTER_URI=http://pr<x>1:11311
$ rosrun rviz rviz
and you should see rviz launch with a visualization of the robot.2
For more information about how to view different types of data coming
from the robot, see the rviz documentation at ros.org. (TODO - WITH
THE CURRENT LAUNCH FILE, YOU WILL NOT BE ABLE TO SEE
CAMERA DATA)
2
If you do not see rviz appear, then there is a chance that you have not yet built rviz
yet. To do this, type rosmake rviz to build rviz. Once this is done, you can try launching
rviz again.
6.9. WHAT NEXT? 89
6.9 What next?

From here, you can do what you want on the robot. (NOTE TO AUTHORS:
Point to instructions for writing code and to a list of other applications and
things to do with the robot.)
6.10 Putting Away the PR2

To properly put away the PR2, you should drive the robot to the appropriate
location in your lab, plug in the robot to recharge the batteries, press STOP
on the wireless run-stop, stop the processes on the robot, and log off of the
robot.
First, put away the robot. Drive the robot to the appropriate location
in your lab and plug it in to recharge.
Second, stop all the processes running on the robot. If you want to stop
all of the processes running on the robot and log off of the robot, but not
turn off the robot computers, then open a new terminal and type:
$ sudo robot stop
This logs you into the robot and stops the robot processes.
As an alternative to simply stopping the proceeses running on the robot,
you can also turn off the robot computers. To do this, open a new terminal
and type:
$ sudo pr2-shutdown
If you turn off the robot, you will hear four sets of descending beeps
from the robot computers. Then the red lights on each of the computers
will turn off. If this does not happen, then the robot computers might not
be completely shut down properly.
Finally, to exit from the robot computer terminal, type
$ exit
If someone was waiting to use the robot after you, be sure to let them
know that you are done with the robot.
Chapter 7
Writing code on PR2
The PR2 comes with the PR2 variant of the latest released distribution of
ROS installed from binary debian packages in /opt/ros . It is recommended
to use this installation where possible to save compile time and disk space.
Start by getting rosinstall There is more documentation on the wiki

package page rosinstall.
wget --no-check-certificate http://ros.org/rosinstall -O ~/rosinstall
chmod 755 ~/rosinstall
7.1 Installing code in user-space

To setup your environment with the installed packages type:
. /opt/ros/boxturtle/setup.sh
7.1.1 Installing another repository in user-space

To add another repository an overlay rosinstall file should be created like
the following:
- VERSION-CONTROL-TYPE:
uri: URI
local-name: WORKING-COPY-NAME
Recreate this as /custom.rosinstall substituting appropriately for the all
caps sections.
Then type:
~/rosinstall -o ~/local_dir ~/custom.rosinstall
91
92 CHAPTER 7. WRITING CODE ON PR2
Setting environment to use local dir

. ~/local_dir/setup.sh
7.1.2 Creating a package

This is documented on the wiki in the roscreate package
7.1.3 Using a local version of a stack

If a different version of a stack is desired instead of an installed one, add it to
your overlay rosinstall file. Stacks in overlays are prepended to the path and
thus will take priority over an existing stack. Note be careful, if changing a
lower level stack, for all things which depend on it’s changes must be rebuilt.
This can be an issue if the dependent stacks are also installed.
7.2 Where to Start

7.2.1 Documetation and Tutorials
Documentation for ROS and the PR2 can be found on ros.org. An overview
of the relevant libraries for filtering, navigation, cooridinate tranforms, etc.,
can be foung at http://www.ros.org/APIs. Below is a listing of several
tutorials for learning and using ROS:
ROS stack tutorials These tutorials cover the basic ROS concepts and
tools for writing and using ROS nodes.
tf tutorials These tutorials cover using the tf library for cooridinate tran-
sofrms using the python and C++ APIs.
navigation tutorials These tutorials cover configuring and using the nav-
igation stack on the PR2 and other robots.
laser pipeline tutorials These tutorials cover processing laser data and
converting laser data into 3D representations.
image common tutorials These tutorials cover working with images in

ROS.
actionlib tutorials These tutorials cover implementing actions, a stan-

dard interface preemptible highlevel tasks, using the python and C++
APIs. More example tutorials can be found at turtle actionlib.
7.2. WHERE TO START 93
7.2.2 Mailing Lists

ros-users This mailing list provides the latest ROS news and is a forum
for posting questions to the ROS community for help.
PR2-users This mailing list provides the latest PR2 news and is a forum
for posting questions to the PR2 community for help.
94 CHAPTER 7. WRITING CODE ON PR2
Chapter 8
Maintaining PR2
8.1 Installing upgraded stacks
Instructions on using the pr2 admin user to install new version of stacks and
apps next to what is already on the system.
Instructions on how users set up their accounts to be either using the
latest code all the time or to be locked to a particular version. Discussion
of the advantages of each.
8.2 Installing updated disk images
Instructions on installing an updated disk image from WG on the PR2 for,

e.g. OS changes or robot configuration updates. We need to figure out what
is maintained during updates (e.g. network configuration?), and what is
over-written. This needs to be crisp and well-documented.
8.3 Resetting PR2
Sometimes, you may want to reset PR2 to factory defaults. This is the
process. This can either be done while preserving user data, or can be done
as a full factory reset.
Essentially, this is a full update to the last-installed disk image.
95
96 CHAPTER 8. MAINTAINING PR2
8.4 Diagnostics Logs

Since the PR2 is currently in beta, it is important for us to learn as much as
we can about robot hardware usage and how problems develop. To address
this, we are requiring all PR2 beta sites to regularly transfer diagnostics logs
to Willow Garage.
These logs are gathered automatically by pr2 core in the /hwlogs parti-
tion. This directory should not be used for anything else, since everything
there will be periodically transfered to Willow Garage.
8.4.1 Setting up automatic transfer

To make this process easier, we have provided a set of scripts to perform
this log transfer automatically. To enable those, just add the line XXX to
the pr2 admin crontab via these instructions:
8.4.2 Manual transfer

If you would prefer to not have the robot transfer logs back to Willow Garage
automatically, you can transfer them manually instead. To do this, either
run the script ”transfer logs”, or look inside it to understand what it’s doing
and perform the transfer yourself.
8.5 Solving hardware problems

8.5.1 Figuring out what’s wrong
The first step if you suspect hardware problems should be to check the
diagnostics display in pr2 dashboard. If that doesn’t help you resolve the
problem, you can run the full robot self test. This is a GUI which allows
you to select the portions of the robot you wish to qualify, and runs them
through a variety of tests to diagnose problems. Instructions on using it and
interpreting the data it outputs go here.
8.5.2 Support
For hardware issues, please submit a ticket at support.willowgarage.com
8.5. SOLVING HARDWARE PROBLEMS 97
8.5.3 Documentation
For more detailed documentation, see support.willowgarage.com. This in-
cludes drawings and step-by-step instructions for replacing all user-servicable
parts. After this list of chapters, we should have a set of other tutorials
which have been referenced from the text. Only tutorials that are on the
critical path should be in-lined in the text. Everything else should be refer-
enced and then collected at the end.

Pr2 Manual r306

Uploaded by

Document Informationclick to expand document information.. 3.1. Accessory kit 3.1. Large calibration target 3.1. Toolkit 3.1. Base-station computer 3.2. Mechanism 3.2. Links and Joints 3.2. Motion control 3.2. Mechanical specs 3.2. 3.3. Gripper Sensors 3.3. Inertial measurement unit 3.3.

Document Informationclick to expand document information

Copyright:

Available Formats

Pr2 Manual r306

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pr2 Manual r306

Uploaded by

Copyright:

Available Formats

PR2 user manual

November 12, 2010

4.4.3 Configure the Basestation Network . . . . . . . . . . . 60

5 Setting up PR2 in your lab 71

6 Running the PR2 77

7 Writing code on PR2 91

This manual is intended to give you enough information to successfully in-

1.1 Before you start

of fire, hazardous chemicals, or furniture that could be knocked over. See

Linux We highly recommend familiarity with the Linux command-line.

Safety is a key goal at Willow Garage. Safety is important yet challenging,

potential hazards, seek design mitigations, and communicate effective usage

2.2 Design Features

2.3 General Usage Guidelines

 Every organization that uses a PR2 must appoint a Safety Officer.

– The Safety Officer’s contact information should be known by ev-

– Details of the Safety Officer’s roles and responsibilities are de-

– view the safety video,

– do not come within range of the PR2 when active,

 Maintain a safe environment. Safety is not only affected by how

– Keep the robot at least 7 meters from the top of a stairway

– Never use the PR2 around stoves or ovens.

 Use caution to avoid electrical shock.

– Do not allow the robot to come in contact with liquids (spilled

 Use extreme caution whenever the robot’s spine is contracting. Ob-

 Make sure the batteries cannot be overheated or punctured. Do not

 The operator should always have immediate access to the run/stop

 Use common sense when operating the robot.

– Do not allow the robot to grab or hit any person.

 Pay attention to warning labels on the robot.

 Do not remove the covers of a PR2 or disassemble it in any way

– There are high voltages inside the robot.

 Do not modify or remove any part of the software safety features.

 If you are sensitive to 50 Hz flashing lights, the texture projector may

 Anticipate potential problems and hazards. Always imagine what

– The joystick could run out of batteries.

2.4 Safety Program

 Anticipation: identifying potential hazards associated with the PR2

 Mitigation: taking actions to reduce the likelihood and severity of

 Communication: exchanging information about safety within the com-

The foundation of the safety program is an ongoing effort to identify ways

 A design change is made to mitigate the potential damage. Examples

 A guideline is written to let people know how to avoid the potential

 A warning sticker is attached to the robot.

Communication is key to the safety program. There are several sources

 The web pages at safety.willowgarage.com.

 This chapter of the PR2 User Manual

If you have any concerns about safety or if you witness a safety-related

3.1 What’s in the box

The PR2 ships in 3 packages:

3.1.2 Accessory kit

Figure 3.1: The PR2 bluetooth joystick.

Figure 3.2: The PR2 wireless run-stop.

Robot Power Cord and Self Plug-in Robot Power Cord

Figure 3.3: Robot Power Cord

Figure 3.4: Self plug-in power cord

To recharge the PR2’s batteries, it must be plugged into a 120V electrical

Sensorized fingertips and boots

Every organization that uses a PR2 must appoint a Safety Officer.

Maintain a safe environment. Safety is not only affected by how

Use caution to avoid electrical shock.

Use extreme caution whenever the robot’s spine is contracting. Ob-

Make sure the batteries cannot be overheated or punctured. Do not

The operator should always have immediate access to the run/stop

Use common sense when operating the robot.

Pay attention to warning labels on the robot.

Do not remove the covers of a PR2 or disassemble it in any way

Do not modify or remove any part of the software safety features.

If you are sensitive to 50 Hz flashing lights, the texture projector may

Anticipate potential problems and hazards. Always imagine what

Anticipation: identifying potential hazards associated with the PR2

Mitigation: taking actions to reduce the likelihood and severity of

Communication: exchanging information about safety within the com-

A design change is made to mitigate the potential damage. Examples

A guideline is written to let people know how to avoid the potential

A warning sticker is attached to the robot.

The web pages at safety.willowgarage.com.

This chapter of the PR2 User Manual

UV exposure should be minimized. UV radiation can damage the

Dust and dirt can clog air filters

Thermal damage to motors from exceeding maximum current specifi-

Damage to drive-trains resulting from collision with end-stops

Premature wear and damage to motor, gear-head, or drive-train re-

Premature wear of slip-rings or other electrical connections from op-

Vibration damage to sensors or other components resulting from ex-

c1 stores the operating system for both computers. c2 cannot boot

c1 is connected to the PR2 ethercat network, and is the only computer

10.68.0.0/24: Primary Robot Internal Network. The 10.68.0.0