Pi Robot Passes Navigation Endurance Test

One of the long term goals of the Pi Robot Project has been to build a robot that can run more or less continuously while navigating about the house and interacting with people and pets.  A good real-world test of the stability of a robot’s hardware and software is a navigation endurance test.  The idea is to pick a number of goal locations in your home or office, then run a continuous loop on the robot that randomly picks a location, navigates to that location autonomously, then picks another location and so on.  The test continues until either the battery dies or the robot gets stuck, either physically or due to a software problem.  If the robot can stop to charge its own battery (like the Willow Garage PR2), then the test could continue indefinitely.

Back in May 2009, the PR2 set an impressive milestone running ROS when it autonomously navigated a full marathon (26.2 miles) through the offices and hallways of Willow Garage.
Today Pi ran a similar test though he was limited by his battery life which was just under 2 hours.  The big question was: would the combination of ROS and hobby-level hardware be stable enough to carry out the task without the robot running into things, getting stuck, or suffering a software failure?

Test Preparation

Before picking goal locations around the house, we would need a
map.  Fortunately, ROS includes the gmapping package which
automatically draws a map of an area from laser scans and odometry data
collected from a mobile robot.  So Pi was driven around the
house for about about 7 minutes using a wireless remote control while
recording the data returned from his laser scanner and wheel
odometry.  Gmapping was then run on the data file which resulted
in the following map:

Map with Locations

As you can tell from the lower part of the map, a few rooms were not
included for the test but are partially visible through open doorways.  While a
much cleaner map could be made by collecting more data, it turns out
that this level of detail is all that was necessary.

The green dots indicate the six goal locations that were chosen for
the test.  Each location could be easily described by a person
living in the house such as “middle of the living room” or
“facing the front door near the foyer”.  The coordinates of the
locations were then read off the map using RViz, the ROS visualization
tool, so that they could be entered into the test program described below.

Pi’s Hardware

It is a good idea to remind ourselves of Pi Robot’s new hardware setup.  The drive train includes a pair of Pololu motors (100 rpm, 220 oz-in torque), BaneBot’s wheels (roughly 5″ in diameter), and a prototype of a new ArbotiX microcontroller fitted with a Pololu 30-amp motor driver.   The motors have integrated quadrature encoders that report 4,773 ticks per meter.  In addition to the ArbotiX, Pi has a second microcontroller called the Serializer which is used to monitor the battery voltage and overall current drain.  Finally, there is the laser scanner which is the one component that cannot be classified as “hobbyist hardware”.  The model used on Pi Robot is the Hokuyo URG-04LX-UG01 which is the least expensive scanner available but still costs $1,175.00.   A cheaper option is to buy a Neato robot vacuum cleaner for about $379 and then take out the laser scanner.

The images below show the layout–the image on the left is the second layer of the robot with the ArbotiX, Serializer and power distribution terminals.  The image on the right shows the first layer of the robot including the laser scanner, battery and wheels.  (The
motors are mounted on the underside of the plate and the ArbotiX was
moved to the second layer since this photo was taken.)

Pi Robot's Logic Layer

Base Layer with Battery and Laser

Pi’s brain is a Zotac dual-core
mini-ITX headless computer which means
it has no screen or keyboard.  The Zotac runs off the same battery
as all the rest of the electronics.  Using a laptop (which has its
own battery) instead of the Zotac would significantly increase the time
Pi could run between charges since the Zotac accounts for about half of
the power requirements of Pi’s hardware.  Speaking of the battery,
Pi uses a 10 Ah LiFePO4 battery that weights about 2.5 lbs.  The
rating of 10 Ah means that the battery can support a 1 amp current
drain for 10 hours or 5 amps for 2 hours (like Pi Robot), etc.  In
addition to the drive motors, electronics, and mini-ITX computer, the
battery must also power the Kinect which consumes about 1A at 12V, and
the Dynamixel servos which require approximately another 1A.

While Pi’s arm was not used during the endurance test, power was still
applied to all the Dynamixel servos so that the ArbotiX could be used
to keep Pi’s pan and tilt head servos locked in an upright and
forward-pointing position.

Setting up the ROS Nodes

ROS provides all the tools necessary for Pi to navigate from one location to another.  The main package used was amcl which stands for “Adaptive Monte Carlo Localization”.  The amcl algorithms compare the laser scan data from the moving robot to the map
stored in memory to figure out the robot’s location.  The
map and laser data need to be good enough for amcl to accurately
predict where the robot is in the map without human intervention;
otherwise the robot will get lost and the navigation test will fail.

ROS also provides a powerful package called move_base
for commanding the robot to move to a goal location.  You might be
wondering: if we know the coordinates of all the goal locations, how
hard could it be to program the robot to move from one to
another?  The answer is surprisingly complex and move_base handles many contingencies including:

  • If a person or pet walks in front of the robot as it is moving, move_base will compute a new path on the fly that goes around the obstacle yet still gets the robot to the goal.
  • If a path is blocked completely,  move_base
    must either choose an entirely different route through some other part
    of the map, or abort the goal and notify anyone who needs to know.
  • The path followed from one
    location to another must take into account the size of the robot’s base to avoid
    hitting obstacles along the way.  By configuring move_base
    with the radius of Pi’s base (or length and width for a rectangular
    base) the path planner ensures that the path chosen will not cause the
    edges of the robot to strike nearby obstacles.
  • Obstacles can be detected not only by the laser scanner but also by a 3D camera such as the Kinect.  The move_base package
    can use data from both sources to dynamically plan the path of
    the robot safely around obstacles.  This is particularly useful
    when the environment includes furniture such as a credenza which is
    elevated off the floor on thin legs.  While the laser scanner can
    be fooled because its beam sweeps underneath the credenza’s cabinet,
    the Kinect will easily see the cabinet, even from a distance, and move_base will be able to avoid it.

Once Pi was ready for the endurance test, the following ROS launch file was used to fire up all the required nodes:


 <!-- Start the Serializer controller -->
 <include file="$(find pi_bringup)/launch/serializer.launch" />

 <!-- Start the ArbotiX controller -->
 <include file="$(find pi_bringup)/launch/arbotix.launch" />

 <!-- Start the Hokuyo laser driver --> 
 <include file="$(find pi_bringup)/launch/hokuyo.launch" />

 <!-- Keep the head upright and centered -->
 <node pkg="pi_bringup" type="lock_head.py" name="lock_head" output="screen" />

 <!-- Start the OpenNI node -->
 <include file="$(find pi_navigation)/launch/openni_node.launch" />

 <!-- The move_base and amcl nodes -->
 <include file="$(find pi_navigation)/launch/nav_amcl.launch" />


The Test Program

To automate the endurance test, I wrote a Python script that cycled through the following steps:

  • Randomly select the next location.  (The locations were
    sampled without replacement so that each location was visited equally
  • Send the appropriate move_base goal to Pi’s base controller.
  • Record the success or failure of the navigation to the goal, as well as the elapsed time and distance traveled.
  • Pause for 10 second
    pause at each location so that the robot’s position could occasionally be verified visually.
  • Repeat.

The test script can be found here.


By all measures, Pi passed the endurance test with flying colors.
Most importantly, at no point did Pi touch another object, including
people and cats who wandered across his path.  In numerical terms,
Pi’s battery lasted nearly 2 hours (1:55).  During that time, he
successfully navigated to 174 out of 175 locations, aborting only once
when his path was blocked for a time longer than move_base
was willing to wait (as set in the configuration files).  Total
distance traveled was 611 meters (0.6 km).  Typical current drain
on the battery was between 4 and 5 amps with peaks to 7.5 amps during
tight turns.  CPU load on the Zotac hovered around 3.0 while %CPU
utilization was broken down as follows:

  • 86%: XnSensorServer (the Kinect)
  • 78%: move_base
  • 33%: openni_node
  • 15%: python
  • 14%: amcl

The Kinect was run in its lowest resolution mode, 160×120 (QQVGA) to keep CPU load as low as possible.

Pictures and Video

It’s an interesting experience to have a robot wandering about the
house on its own while you are also doing your own thing, especially
when your paths cross and the robot simply goes around you and
continues on its way.  Here is a short clip of Pi rolling around
during part of the endurance test:

This entry was posted in ROS. Bookmark the permalink.