Pi Robot Navigation Endurance Test

Pi Robot Passes First 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

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:

The nav_amcl.launch file also launches the move_base node which in turn requires four configuration files that can be found here.

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 often.)
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.

Results

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, 160x120 (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:

Here are a few shots of RViz running on my PC during the test. As you can see, RViz displays the map as well as the current position of the robot, the path it is following (light green arc in some of the images), as well as the location of danger zones (yellow and blue squares) and laser scan data (small red balls). You can also see the a small color video image (lower left corner) which is the view Pi sees from his Kinect camera. The multicolored "cloud" of points is the color-coded depth image from the Kinect. Red means the point is closer to the camera, while purple is furthest away.

Note that one could easily view this same display on any other computer running ROS on the Internet so that you could turn the endurance test into more of a home surveillance program. You could even have Pi pan and tilt his head as he moves about or at each location to give you a better view.

Click on an image to get a larger and clearer view: