The Interactive Museum Tour-Guide Robot

Wolfram Burgard, Armin B. Cremers, Dieter Fox, Dirk H ahnel,Gerhard Lakemeyery, Dirk Schulz, Walter Steiner, and Sebastian Thrunz

Computer Science Department III yComputer Science Department zSchool of Computer ScienceUniversity of Bonn Aachen University of Technology Carnegie Mellon University

Bonn, Germany Aachen, Germany Pittsburgh, PA

Abstract

This paper describes the software architecture of an au-tonomous tour-guide/tutor robot. This robot was recentlydeployed in the “Deutsches Museum Bonn,” were it guidedhundreds of visitors through the museum during a six-daydeployment period. The robot’s control software integrateslow-level probabilistic reasoning with high-level problemsolving embedded in first order logic. A collection of soft-ware innovations, described in this paper, enabled the robotto navigate at high speeds through dense crowds, while re-liably avoiding collisions with obstacles—some of whichcould not even be perceived. Also described in this paperis a user interface tailored towards non-expert users, whichwas essential for the robot’s success in the museum. Basedon these experiences, this paper argues that time is ripe forthe development of AI-based commercial service robots thatassist people in everyday life.

IntroductionBuilding autonomous robots that assist people in every-

day life has been a long-standing goal of research in ar-tificial intelligence and robotics. This paper describes anautonomous mobile robot, called RHINO, which has re-cently been deployed at the “Deutsches Museum” in Bonn,Germany. The robot’s primary task was to provide interac-tive tours to visitors of the museum. In addition, the robotenabled people all around the world to establish a “virtualpresence” in the museum, using a Web interface throughwhich they could watch the robot operate and send it tospecific target locations.

The application domain posed a variety of challenges,which we did not face in our previous research, carried outmostly in office-like buildings. The two primary challengeswere (1) navigating safely and reliably through crowds, and(2) interacting with people in an intuitive and appealingway.

1. Safe and reliable navigation.It was of ultimate impor-tance that the robot navigated at approximate walking

Copyright 1998, American Association for Artificial Intelli-gence (www.aaai.org). All rights reserved.

speed, while not colliding with any of the various ob-stacles (exhibits, people). Three aspects made this prob-lem difficult. First, RHINO often had to navigate throughdense crowds of people (c.f. Figures 1 and 2). People of-ten blocked virtually all sensors of the robot for extendeddurations of time. Second, various exhibits were “invis-ible” to the robot, that is, the robot could not perceivethem with its sensors. This problem existed despite thefact that our robot possessed four state-of-the-art sensorsystems (laser, sonar, infrared, and tactile). Invisible ob-stacles included glass cages put up to protect exhibits,metal bars at various heights, and metal plates on whichexhibits were placed (c.f., the glass cage labeled “o1”and the control panel labeled “o2” in Figure 3). Navigat-ing safely was particularly important since many of theexhibits in the museum were rather expensive and easilydamaged by the 300 pound machine. Third, the configu-ration of the environment changed frequently. For exam-ple, the museum possessed a large number of stools, andpeople tended to leave them behind at random places,sometimes blocking entire passages. Museum visitorsoften tried to “trick” the robot into an area beyond itsintended operational range, where unmodeled and invis-ible hazards existed, such as staircases. For the robot tobe successful, it had to have the ability to quickly detectsuch situations and to find new paths to exhibits if possi-ble.

2. Intuitive and appealing user interaction. Tutoringrobots, by definition, interact with people. Visitors ofthe museum were between 2 and 80 years old. The av-erage visitor had no prior exposure to robotics or AI andspent less than 15 minutes with the robot, in which he/shewas unable to gain any technical understanding whatso-ever. Thus, a key challenge was to design a robot that was“intuitive” and user friendly. This challenge included thedesign of easy-to-use interfaces (both for real visitors andfor the Web), as well as finding mechanisms to commu-nicate intent to people. RHINO’s user interfaces were animportant component in its practical success.

The specific application domain was chosen for two pri-

From: AAAI-98 Proceedings. Copyright © 1998, AAAI (www.aaai.org). All rights reserved.

RHINO o1

o2

Laser rangefinder

Tactiles

Infrared

Sonars

Stereo camera

Fig. 1: RHINO gives a tour Fig. 2: Interaction with people Fig. 3: The Robot and its sensors.

mary reasons. First, we believe that these two challenges,safe navigation and easy-to-use interfaces, are prototypicalfor a large range of upcoming service robot applications.Second, installinga robot in a museum gave us a unique andexciting opportunity to bridge the gap betweenacademicresearch and the public.

This paper describes the key components of RHINO’ssoftware architecture. The software performs, in real-time,tasks such as collision avoidance, mapping, localization,path planning, mission planning, and user interface control.The overall software architecture consists of approximately25 independent modules (processes), which were executedin parallel on three on-board PCs and three off-board SUNworkstations, connected via a tetherless Ethernet bridge(Thrunet al. 1998a). The software modules communicateusing TCX (Fedor 1993), a decentralized communicationprotocol for point-to-point socket communication.

RHINO’s control software applies several design princi-ples, the most important of which are:

1. Probabilistic representations, reasoning, and learn-ing. Since perception is inherently inaccurate and incom-plete, and since environments such as museums changefrequently in rather unpredictable ways, RHINO per-vasively employs probabilistic mechanisms to representstate and reason about change of state.

2. Resource adaptability.Several resource-intensive soft-ware components, such as the motion planner or the lo-calization module, can adapt themselves to the availablecomputational resources. The more processing time isavailable, the better and more accurate are the results.

3. Distributed, asynchronous processing with decentral-ized decision making.RHINO’s software is highly dis-tributed. There is no centralized clock to synchronize thedifferent models, and the robot can function even if ma-jor parts of its software fail or are temporarily unavailable(e.g., due to radio link failure).

The remainder of this paper will describe those softwaremodules that were most essential to RHINO’s success. In

particular, it will present the major navigation componentsand the interactive components of the robots.

NavigationRHINO’s navigation modules performed two basic func-tions: perception and control. The primary perceptual mod-ules were concerned with localization (estimating a robot’slocation) and mapping (estimating the locations of the sur-rounding obstacles). The primary control components per-formed real-time collision avoidance, path planning, andmission planning.

Localization

Localization is the problem of estimating a robot’s coordi-nates (also called:poseor location) in x-y-� space, wherex andy are the coordinates of the robot in a 2D Cartesiancoordinate system, and� is its orientation. The problem oflocalization is generally regarded to be difficult (Cox 1991;Borenstein, Everett, & Feng 1996). It is specifically hardin densely populated domains where people may block therobot’s sensors for extended periods of time.

RHINO employs a version ofMarkov localization, amethod that has been employed successfully by severalteams (Nourbakhsh, Powers, & Birchfield 1995; Simmons& Koenig 1995; Kaelbling, Cassandra, & Kurien 1996).RHINO utilizes ametricversion of this approach (Burgardet al.1996), in which poses are estimated inx-y-� space.

Markov localization maintains a probabilistic belief asto where the robot currently is. LetP (l) denote this be-lief, where l is a pose inx-y-� space. Initially, when thepose of the robot is unknown,P (l) is initialized by a uni-form distribution. To updateP (l), Markov location em-ploys two probabilistic models, a perceptual model and amotion model. The perceptual model, denotedP (s j l),denotes the probability that the robot observess when itspose isl. The motion model, denotedP (l0 j l; a), denotesthe probability that the robot’s pose isl0 if it previously ex-ecuted actiona at locationl.

Both models are used to update the robot’s beliefP (l)

Fig. 4: Global localization. Obstacles areshown in black; probabilitiesP (l) in gray.

Fig. 5: Typical laser scan in the presenceof people. The gray-shaded sensor beamscorrespond to people and are filtered out.

Fig. 6: RHINO’s path planner: Thegrey-scale indicates the proximity ofthe goal.

when the robot senses, and when it moves, respectively.Suppose the robot just senseds. Markov localization thenupdatesP (l) according to Bayes rule:

P (l j s) = � P (s j l) P (l) (1)

where� is a normalizer that ensures that the resulting prob-abilities sum up to one. When the robot moves, Markovlocalization updatesP (l) using the Theorem of total prob-ability:

P (l0) =

ZP (l0 j a; l) P (l) dl (2)

Here a denotes an action command. These two updateequations form the basis of Markov localization. Strictlyspeaking, they are only applicable if the environment meetsa conditional independence assumption(Markov assump-tion), which specifies that the robot’s pose is theonly statetherein. Put differently, Markov localization applies only tostatic environments.

Unfortunately, the standard Markov localization ap-proach is prone to fail in densely populated environments,since those violate the underlying Markov assumption. Inthe museum, people frequently blocked the robot’s sensors,as illustrated in Figure 1. Figuratively speaking, if peopleline up as a “wall” in front of the robot—which they oftendid—, the basic Markov localization paradigm makes therobot eventually believe that it is indeed in front of a wall.

To remedy this problem, RHINO employs an “entropyfilter” (Fox et al. 1998b). This filter, which is applied to allproximity measurements individually, sorts measurementsinto two buckets: one that is assumed to contain all cor-rupted sensor readings, and one that is assumed to containonly authentic (non-corrupted) ones. To determine whichsensor reading is corrupted and which one is not, the en-tropy filter measures the relative entropy of the belief statebeforeandafter incorporating a proximity measurement:

�H(l; s) := (3)

�

Zl

P (l) logP (l) dl +

Zl

P (l j s) logP (l j s) dl

Sensor readings that increase the robot’s certainty(�H(l; s) > 0) are assumed to be authentic. All other sen-sor readings are assumed to be corrupted and are thereforenot incorporated into the robot’s belief. In the museum,certainty filters reliably identified sensor readings that werecorrupted by the presence of people, as long as the robotknew its approximate pose. Unfortunately, the entropy fil-ter can prevent recovery once the robot looses its positionentirely. To prevent this problem, our approach also incor-porates a small number of randomly chosen sensor readingsin addition to those selected by the entropy filter. See (Foxet al.1998b) for an alternative solution to this problem.

In practice, our approach proved to be robust in the mu-seum. RHINO’s localization module was able (1) to glob-ally localize the robot in the morning when the robot wasswitched on (see Figure 4 for a typical belief state duringthis procedure), and (2) to keep track of the robot’s positionreliably and accurately (see Figure 5). RHINO’s localiza-tion error, measured over a set of 118 randomly selectedreference locations, was consistently below 15 cm. Thisaccuracy was essential for safe navigation. In the entire six-day deployment period, we are only aware of a single occa-sion in which the robot suffered a localization error largerthan its 30cm safety margin, and this incident was precededby partial loss of sensing. A comparison between our ap-proach and plain Markov localization (i.e., our approachwithout the entropy filter) showed that the standard Markovalgorithm would have lost track of the robot’s position fre-quently, whenever large crowds surrounded the robot (Foxet al.1998b).

MappingMapping addresses the problem of determining the loca-tions of the obstacles in global world-coordinates. In themuseum domain, the problem of mapping was simplifiedsignificantly, since an accurate metric map of the mu-

seum was provided to the robot beforehand. However, theconfiguration of the museum changed frequently—peoplemoved stools around and sometimes people blocked entirepassages—, making necessary the revision of the map inreal-time.

RHINO employed a probabilisticoccupancy grid al-gorithm for modifying the initial map, a technique thatwas originally developed in the mid-eighties and sincehas been used successfully in many mobile robot applica-tions (Moravec 1988; Elfes 1989). Occupancy grid tech-niques approximate the environment by a 2D grid, whereeach grid cell is annotated by a numerical “occupancyvalue” that represents the probability that this cell containsan obstacle.

In our approach (Thrun 1998), occupancy maps are gen-erated using a Backpropagation-style network, which mapssensor measurements to local occupancy maps. The net-work is trained off-line, using labeled data obtained in en-vironments where the exact locations of all obstacles areknown. After training, the network generates conditionalprobability estimates for occupancy, denotedP (ox;y j s),for grid cells hx; yi that lie in the sensors’ perceptualrange. Figure 7a shows an example sonar scan, taken ina hallway, along with the local map. The shading en-codes the likelihood of occupancy: The darker a loca-tion, the more likely it is to be occupied. As is easy tobe seen, the two walls are detected with high certainty,as is the free space in between. Behind the walls, how-ever, the network outputs0:5, to indicate maximum uncer-tainty. Local maps are integrated over time using Bayesrule and likelihood ratios, as described in (Moravec 1988;Thrun 1998):

P (ox;y j s1; s2; : : : ; sT ) =

1�

1+

P (o)

1�P (o)

Y�

P (ox;y j s� )

1�P (ox;yjs� )

1�P (o)

P (o)

!�1

(4)

Heres� denotes the sensor reading at time� , andP (o) de-notes theprior probability for occupancy.

Figure 7 shows an example map, in which a narrow pas-sage (upper left) has been blocked, forcing the robot to takea detour. When RHINO reaches a tour item, it reset its mapto the original, pre-supplied one. This strategy ensures thatpassages, once blocked, will not be avoided indefinitely.The ability to modify the map on-the-fly was essential forRHINO’s success. In some occasions, lack thereof wouldhave caused the robot to be “stuck” for extended periods oftime. RHINO frequently surprised people by successfullycarrying out its mission even in the presence of major, per-manent obstacles.

Collision Avoidance with “Invisible” ObstaclesRHINO’s collision avoidance protects the robot from col-liding with obstacles—exhibits and humans alike. It does

(a) (b)

Fig. 7: (a) Sonar scan and local map, generated by the neural net-work. (b) This map is partially pre-supplied, partially learned.Here the motion planner chooses to take a detour to avoid ablocked passage on the top of this figure.

this by controlling the actual motion direction and the speedof the robot, based on sensor input and based on a “targetlocation” prescribed by the motion planner.

RHINO employed an extension of the dynamic win-dow algorithm (DWA) (Fox, Burgard, & Thrun 1997;Foxet al. 1998a). In a nutshell, DWA controls—four timesa second—thetranslationaland rotational velocity of therobot. It does this inaccordance with several hard and softconstraints. Hard constraints restrict the space of veloci-ties. They are imposed to avoid velocities that, if chosen,would inevitably lead to a collision, taking intoaccountthe robot’s inertia and torque limits. Soft constraints, onthe other hand, express preferences in the space of control.DWA employs essentially two soft constraints, one whichencourages the robot to make progress towards its target lo-cation, and one which seeks to maximize the robot’s veloc-ity (thereby favoring motion directions towards unclutteredspace). Together, these soft constraints lead to a behaviorthat makes the robot navigate smoothly around obstacleswhile making progress towards its target whenever possi-ble. In particular, the second constraint ensures that therobot moves at high speeds whenever the situation permits.

The complicating factor in the museum was the pres-ence of the various “invisible” obstacles, as described inthe introduction to this article. The basic DWA, just likeany other sensor-based collision avoidance approach, doesnot allow for preventing collisions with such obstacles. Toavoid collisions with those, the robot had to consult itsmap. Of course, obstacles in the map are specified in worldcoordinates, whereas DWA requires the location of thoseobstacles in robo-centric coordinates. Thus, we extendedthe DWA approach to use the maximum likelihood posi-tion estimatel� = argmaxl P (l) produced by RHINO’s lo-calization module. Given the robot’s location in the map,the �DWA algorithm (Foxet al. 1998a) generates “vir-tual” proximity measurements and integrates them with the“real” proximity measurements, obtained from the robot’s

various sensors (tactile, infrared, sonar, laser). This exten-sion of the dynamic window approach proved to be highlyeffective in the museum. Figure 10 shows a trajectory ofthe robot travelled during the opening hours of the museum.The length of this trajectory is 1.6km. Apparently, the robotsafely avoids “invisible” objects which are marked by thegrey-shaded areas. The same mechanism was used to limitthe operational range of the robot. With it, the robot suc-cessfully withstood all attacks by visitors to force it intounmapped terrain. The collision avoidance routine was alsoinstrumental in quickly finding ways around unanticipatedobstacles, such as humans that stepped in the robot’s path,or stools left behind by visitors.

In order to deal with situations in which RHINO’s local-ization module assigns high probability to multiple poses,we recently developed a more conservative strategy, whichwas not ready at the time of the museum installation, butwhich is now part of�DWA (Fox et al. 1998a). Thisapproach generates “virtual” sensor readings that are with99% probabilityshorter than the actual distances to thenearest invisible obstacles. Lets be a proximity measure-ment that one would expect if all invisible obstacles wereactually detectable. Then

P (s) =

ZP (s j l) P (l) dl: (5)

is the probability distribution over alls that is induced bythe map and the uncertainty in the locationl. Suppose therobot’s virtual sensor were set to one such value, says�.With probability

�(s�) :=

Zs>s�

P (s) ds (6)

this values� will be smallerthan the real value, that is, withprobability�s� , the proximity returned by the virtual sen-sor will be underestimating the true distance to an invisibleobstacle, and the robot will be safe. In our implementationof �DWA, s� is chosen so that�(s�) � :99, that is, the vir-tual sensor measurements prevent collisions with invisibleobstacles with 99% probability. Empirical results presentedelsewhere demonstrate that this extension yields safer con-trol in situations with high uncertainty.

Path PlanningRHINO’s path planner generates paths from one exhibitto another. In the museum, such paths could not be pre-determined in advance, since the environment was highlydynamic and the map changed continuously. This made itimperative that the robot adapted its path to the situationon-the-fly.

RHINO’s path planner is based onvalue iteration, apopular dynamic programming/reinforcement learning al-gorithm (Bellman 1957; Howard 1960). Value iteration

computes valuesVx;y for each grid cellhx; yi. Initially, thegrid cell containing the goal is set to0, and all others are setto1. Value iteration then updates the values of all unoccu-pied grid cells by the value of their best unoccupied neigh-bor plus by the costs of moving there. After convergence,each valueVx;y corresponds to the distance betweenhx; yiand the goal location. Figure 6 shows a value function afterconvergence. Here the goal is located at the bottom right(white), the robot’s location is shown on the top left, andthe shading of the space indicates the valuesVx;y. Noticehow the values “spread” through the free-space. After con-vergence, steepest decent in the value function leads to theshortest path to the goal.

As described in more detail in (Thrun 1998), RHINO’spath planner employs two additional mechanisms, aimed toincrease its run-time efficiency:

1. It uses a bounding box technique to focus computationon regions where it matters.

2. It uses an algorithm similar to value iteration, to iden-tify areas that require re-planning when the map changes.Such changes are often local, leading to a high degree ofre-use when planning in dynamic environments.

Paths generated by the path planner are not executed di-rectly; instead, they are passed on to the collision avoidanceroutine, using visibility considerations to generate interme-diate “target locations.” When computing these target loca-tions, paths are also post-processed to maximize the robot’sside-clearance.

RHINO’s path planner is anany-timealgorithm, i.e., itreturns an answer at any time, whenever needed (Dean &Boddy 1988). As a pleasing consequence, the robot neverhalts to wait for its planner to generate a plan; instead, itmoves continuously—unless, of course, it explains an ex-hibit.

In the museum, running value iteration to completion andfinding theoptimalpath usually took less than one second.The path planner proved to be highly effective in adaptingto new situations. Figure 7 shows an example, in whicha passage is blocked by stools, forcing the robot and thepeople following it to take a detour. All these decisionsare made in real-time, and people usually do not notice thechange in venue.

Task PlanningThe task planner coordinates the various robot activities re-lated to motion and interaction. It transforms abstract, user-level commands (such as: “give tour number three”) intoa sequence of actions, which correspond to motion com-mands (e.g. “move to exhibit number five”) or controls forthe robot’s interface (e.g. “display image four” and “playpre-recorded message number seventeen”). The task plan-ner also monitors the execution of the plan and modifies itif necessary.

o3

Fig. 8: RHINO’s on-board user in-terface: A screen and four buttons.

Fig. 9: On-line image page for the Web. Fig. 10: Path of the robot during a single 4.5hour run (1.6 km).

RHINO’s task planner uses GOLOG (Levesqueet al.1997), which is an extension of the situation calculus (Mc-Carthy 1968). GOLOG is a language for specifying com-plex actions using structures like if-then-else or recursiveprocedures. Based on these specifications, GOLOG gener-ates, in response to a user request, a sequence of elementary(symbolic) actions which provably fulfil this request. Toachieve robust and coherent behavior, and to allow the cor-rection of possible errors of the underlying components, wehave developed GOLEX. GOLEX complements GOLOGby supplying a run-time component that turns linear plansconstructed by GOLOG into (1) hierarchical and (2) con-ditional plans, and (3) that also monitors their execution.None of these extensions are universal (they are in fact quitelimited), but they are all necessary in the context of mobilerobot control.

1. Hierarchical plans. GOLEX converts each GOLOG ac-tion into a pre-specified sequence of elementary com-mands for RHINO’s lower level software. For exam-ple, the GOLOG action “move to exhibit number five”is translated into a sequence of robot motion commands(“move to a position next to exhibit number five,” “turntowards exhibit number five”), pan/tilt control commands(“track exhibit number five”), and graphical and acousti-cal display commands (“announce exhibit number five”).The advantage of the hierarchical decomposition is anenormous reduction in the complexity of the task plan-ning problem.

2. Conditional plans. Some of GOLOG’s actions aretranslated into pre-specified conditional plans, i.e., plansthat are conditioned on the outcome of sensing actions.In GOLEX, conditional plans must always succeed; how-ever, the specific sequence of sub-actions may vary. Forexample, the action “explain exhibit number five” istranslated into a conditional plan that incorporates userfeedback (e.g. the user chooses the level of detail in therobot’s explanation).

3. Execution monitor. GOLEX monitors the execution of

its plans. Using time-out mechanisms, it is able to invokenew actions and to plan pro-actively. For example, in themuseum, people often pushed no button when they wereasked to make a decision. In such situations, GOLEX’sexecution monitor made a default decision (e.g. it madethe robot move to the next tour item) after waiting for acertain amount of time.

GOLEX provided the necessary “glue” between the high-level and the rest of the robot software, thereby bridging thegap between AI-style symbolic reasoning and numerical,sub-symbolic navigation software.

User InteractionAn important aspect of the tour-guide robot is its interac-tive component. User interfaces are generally of great im-portance for robots that interact with people. In applicationdomains such as museums, the user interfaces must be in-tuitive, so that untrained, non-technical users can operatethe system without instruction. It must also be appealing,so that people feel attracted to the robot and participate in atour. While navigation has been studied extensively in themobile robotics literature, the similarly important issue ofhuman robot interaction has received considerablylittle at-tention. RHINO possesses two primary user interfaces, oneon-board interface for interacting with people directly, andone on the Web.

On-board Interface

The on-board interface is a mixed-media interface that in-tegrates text, graphics, pre-recorded speech, and sound.When visitors approach the robot, they can choose a touror, alternatively, listen to a brief, pre-recorded explanation(the “help text”). They indicate their choice by pressing oneof four colored buttons shown in Figure 8. When RHINOmoves towards an exhibit, it displays an announcement onits screen. It also indicates the direction of its intended des-tination by continually pointing the camera in the directionof the next exhibit. At each exhibit, the robot plays a brief

hours of operation 47number of visitors >2,000number of Web visitors 2,060total distance 18.6 kmmaximum speed >80 cm/secaverage speed during motion 36.6 cm/secnumber of collisions 6number of requests 2,400success rate 99.75%

Table 1: Survey of key results.

pre-recorded verbal explanation. Users can then requestfurther information about the specific exhibit or, alterna-tively, make the robot proceed. When a tour is finished,the robot returns to a pre-defined starting position in the en-trance area where it awaits new visitors.

An important aspect of RHINO’s interactive componentis the robot’s physical reaction to people. RHINO uses bodyand head motion and sound to expressintent and dissat-isfaction. As mentioned above, RHINO’s camera head isused to communicate the intended motion direction. In ad-dition, RHINO uses a modified version of the entropy fil-ter (a probabilisticnovelty filter(Fox et al. 1998b)) to de-tect people or other unexpected obstacles. If such obstaclesblock the robot’s path, it uses its horn to indicate its “dis-satisfaction.” In the museum, people usually cleared therobot’s path once they heard the horn. Some even blockedthe robot’s path intentionally in expectation of an acoustic“reward.”

Web Interface

RHINO’s Web interface consists of a collection of Webpages, some of which are interactive, others provide back-ground information. In addition to previous Web inter-faces (see e.g., (Simmonset al. 1997)), which basicallyrely on client-pull/server-push mechanisms, RHINO’s in-terface also offers Java applets for instant update of infor-mation (both state and intent) as the robot moves. One ofthe main pages of the Web interface is shown in Figure 9.This page enables Web users to observe the robot’s opera-tion on-line. The camera image on the left is obtained withone of RHINO’s cameras. The right image is taken withone of two fixed, wall-mounted cameras. The center dis-play shows a map of the robot’s environment from a bird’seye perspective, along with the actual location of the robot.The bottom portion of this page contains information aboutRHINO’s current actions. When RHINO is explaining anexhibit, this area displays information about the exhibit, in-cluding hyperlinks to more detailed background informa-tion. Information may be updated synchronously in user-specified time intervals. Alternatively, certain information(such as the robot’s position in its map) can be visualizedsmoothly, using a Java applet that “simulates” the robot.

StatisticsRHINO was deployed for a period of six days, in which itoperated for approximately 47 hours without any significantdowntime (see Table 1). Over this period of time, the robottravelled approximately 18.6km. More than 2,000 real visi-tors and over 600 “virtual” Web-based visitors were guidedby RHINO. The robot fulfilled 2,400 tour requests by realand virtual visitors of the museum. Only six requests werenot fulfilled, mostly due to scheduled battery changes atthe time of the request. Thus, RHINO’s overall success-rate was99:75%. Whenever possible, RHINO chose itsmaximum speed (80 cm/sec when guiding real people, 50cm/sec when controlled through the Web). The discrepancybetween the top and the average speed (36.6cm/sec), how-ever, was due to the fact that in the presence of obstacles,the collision avoidance module was forced to slow the robotdown.

During its 47 hours of operation, RHINO suffered a to-tal of six collisions with obstacles, all of which occurredat low speed and did not cause any damage. Only one ofthese collisions was caused by a software failure. Here thelocalization module failed to compute the robot’s pose withthe necessary accuracy. All other collisions were results ofvarious hardware failures (which were usually caused byneglect on our side to exchange the batteries in time) andby omissions in the manually generated map (which werefixed after the problem was observed).

Overall, RHINO was received with enthusiasm in all agegroups. We estimate that more than 90% of the museum’svisitors followed the robot for at least a fraction of a tour.Kids often followed the robot for more than an hour. Ac-cording to the director of the museum, RHINO raised theoverall attendance by at least 50%.

DiscussionThis paper described the major components of a softwarearchitecture of a successfully deployed mobile robot. Therobot’s task was to provide interactive tours to visitors of amuseum. In a six-day deployment period in the DeutschesMuseum Bonn, the robot gave tours to a large numberof visitors, safely finding its way through dense crowds.RHINO’s software integrates a distributed navigation pack-age and modules dedicated to human robot interaction.While the approach is mostly based on existing AI meth-ods of various flavors, it contains several innovations thatwere specifically developed to cope with environments ascomplex and as dynamic as the museum. These include amethod for localization in dense crowds, an approach forcollision avoidance with “invisible” obstacles, a method(GOLEX) that glues together first order logic and numer-ical robot control, and a new, task-specific user interface.Among the various design principles that came to bear,three stick out as the most important ones. We strongly be-

lieve that the use of probabilistic representations for on-linestate estimation and learning, the use of resource-adaptivealgorithms for state estimation and planning, and the decen-tralized and distributed nature of the control scheme wereall essential to produce the level of robustness and reliabil-ity demonstrated here.

What lessons did we learn? From hours of watchingthe robot operate, we concluded that interaction with peo-ple is an essential element in the success of future robotsof this and similar kinds. We believe that there is a realneed for research in the area of human robot interaction.We are also interested in methodsaccelerating the instal-lation procedure. For example, one of us spent a weekconstructing a map of the museum by hand. Based onwork by (Lu & Milios 1997; Gutmann & Schlegel 1996;Thrun, Fox, & Burgard 1998), we now have clear evidencethat this task can be automated (Thrunet al.1998b), and thetime for acquiring such a map from scratch can be reducedto a few hours.

We see a significant potential to leapfrog much ofthe technology developed in this and similar projects(e.g., (King & Weiman 1990)) into other service robot ap-plications, such as applications in the areas of health care,cleaning, inspection, surveillance, recreation etc. We con-jecture that time is ripe for developing AI-based commer-cial service robots that assist people in everyday life.

ReferencesBellman, R. E. 1957.Dynamic Programming. Princeton, NJ:Princeton University Press.

Borenstein, J.; Everett, B.; and Feng, L. 1996.Navigating Mo-bile Robots: Systems and Techniques. Wellesley, MA: A. K.Peters, Ltd.

Burgard, W.; Fox, D.; Hennig, D.; and Schmidt, T. 1996. Es-timating the absolute position of a mobile robot using positionprobability grids. InProc. of the Fourteenth National Confer-ence on Artificial Intelligence, 896–901.

Cox, I. 1991. Blanche—an experiment in guidance and navi-gation of an autonomous robot vehicle.IEEE Transactions onRobotics and Automation7(2):193–204.

Dean, T. L., and Boddy, M. 1988. An analysis of time-dependentplanning. InProceeding of Seventh National Conference on Ar-tificial IntelligenceAAAI-92, 49–54. Menlo Park, CA: AAAI.

Elfes, A. 1989.Occupancy Grids: A Probabilistic Frameworkfor Robot Perception and Navigation. Ph.D. Dissertation, ECE,CMU.

Fedor, C. 1993.TCX. An interprocess communication system forbuilding robotic architectures. Programmer’s guide to version10.xx.CMU.

Fox, D.; Burgard, W.; Thrun, S.; and Cremers, A. 1998a. Ahybrid collision avoidance method for mobile robots. InPro-ceedings of the IEEE International Conference on Robotics andAutomation.

Fox, D.; Burgard, W.; Thrun, S.; and Cremers, A. 1998b. Po-sition estimation for mobile robots in dynamic environments. InProceedings of AAAI-98. AAAI Press/The MIT Press.

Fox, D.; Burgard, W.; and Thrun, S. 1997. The dynamic windowapproach to collision avoidance.IEEE Robotics and Automation4(1).Gutmann, J.-S., and Schlegel, C. 1996. Amos: Comparisonof scan matching approaches for self-localization in indoor en-vironments. InProceedings of the 1st Euromicro Workshop onAdvanced Mobile Robots. IEEE Computer Society Press.

Horswill, I. 1994. Specialization of perceptual processes. Tech-nical Report AI TR-1511, MIT, AI Lab, Cambridge, MA.

Howard, R. A. 1960.Dynamic Programming and Markov Pro-cesses. MIT Press and Wiley.Kaelbling, L.; Cassandra, A.; and Kurien, J. 1996. Acting un-der uncertainty: Discrete bayesian models for mobile-robot nav-igation. InProc. of the IEEE/RSJ International Conference onIntelligent Robots and Systems.

King, S., and Weiman, C. 1990. Helpmate autonomous mobilerobot navigation system. InProceedings of the SPIE Conferenceon Mobile Robots, 190–198. Volume 2352.

Levesque, H.; Reiter, R.; Lesp´erance, Y.; Lin, F.; and Scherl,R. 1997. GOLOG: A logic programming language for dynamicdomains.Journal of Logic Programming31:59–84.Lu, F., and Milios, E. 1997. Globally consistent range scanalignment for environmentmapping.Autonomous Robots4:333–349.

McCarthy, J. 1968. Situations, actions and causal laws. InSe-mantic Information Processing. MIT Press. 410–417.

Moravec, H. P. 1988. Sensor fusion in certainty grids for mobilerobots.AI Magazine61–74.

Nourbakhsh, I.; Powers, R.; and Birchfield, S. 1995. DERVISHan office-navigating robot.AI Magazine16(2):53–60.

Simmons, R., and Koenig, S. 1995. Probabilistic robot naviga-tion in partially observable environments. InProc. InternationalJoint Conference on Artificial Intelligence.

Simmons, R.; Goodwin, R.; Haigh, K.; Koenig, S.; andO’Sullivan, J. 1997. A layered architecture for office deliveryrobots. InProceedings of the First International Conference onAutonomous Agents.Thrun, S.; Bucken, A.; Burgard, W.; Fox, D.; Fr¨ohlinghaus, T.;Hennig, D.; Hofmann, T.; Krell, M.; and Schimdt, T. 1998a.Map learning and high-speed navigation in RHINO. In Ko-rtenkamp, D.; Bonasso, R.; and Murphy, R., eds.,AI-basedMobile Robots: Case studies of successful robot systems. Cam-bridge, MA: MIT Press.

Thrun, S.; Gutmann, S.; Fox, D.; Burgard, W.; and Kuipers, B.1998b. Integrating topological and metric maps for mobile robotnavigation: A statistical approach. InProceedings of AAAI-98.AAAI Press/The MIT Press.

Thrun, S.; Fox, D.; and Burgard, W. 1998. A probabilistic ap-proach to concurrent mapping and localization for mobile robots.Machine Learning and Autonomous Robots (joint issue). to ap-pear.Thrun, S. 1998. Learning maps for indoor mobile robot naviga-tion. Artificial Intelligence. to appear.