A Behavior-Based Navigation System U. Esnaola, I. Ra˜ n´ o, T. Smithers Project MiReLa San Sebasti·n Technology Park P. Mikeletegi 53 20009, Donostia,(Spain)
[email protected] Abstract A Behaviour-based mobile robot navigation system is presented. There is no use of a map of the robot’s environment: navigation is achieved by combining a set of filters which process sensory data to generate two values: α (linear speed), and β (rotational speed), to send to the motors. The paper presents how these filters are grouped and organised to make the robot reliably navigate in a real semi-structured building in crowded conditions. The results of two experiments, performed during the San Sebasti´an Technology Park Open Days, in 2002 and 2003, are presented.
1.
Figure 1: Robot MiReLa
Introduction
This article presents a navigation system implemented in MiReLa, a RWI (Real World Interface, now a Division of iRobot Inc) robot, of the B21 family, see figure 1. MiReLa is being developed to help in the reception of visitors to the main building of the San Sebasti´an Technology Park, (PTSS, 1998). The main building is used for many conferences, exhibitions, and other events throughout the year. This means that the environment changes a lot and often, and it also means that we cannot modify it specifically to help the robot navigate: we cannot adapt the environment to the robot; the robot must adapt to and cope with its environment as it finds it. MiReLa’s navigation system uses no map of it’s environment, geometric or topological, and it involves no planning of any navigation actions. Navigation is treated in a purely Behaviour-based way (Akin, 1998), (Brooks, 1999): movement is generated by defining conditions to be satisfied, ”differences” ((Brooks, 1987)), while other (parallel) processes take care of avoiding (dynamic) obstacles and dealing with people. The robot, MiReLa, has no explicit sense or representation of position or place. It is only those who observe the robot (people) that appreciate that it can move from one place to another and back again.
The navigation system architecture consists of a (nonhierarchical) set of filters, and a motor-fusion component. Each filter takes real time data from one or more of the different sensor systems (Infra-red sensors, Sonar sensors, Scanning Laser Range Finder, Electronic Compass, bumpers, microphone) and outputs two (normalised) speed quantities: α and β. The α is used to control the forward speed of the robot; and the β value is used to control the rotational speed of the robot. (The position of the robot, with respect to some frame of reference, is not explicitly controlled.) The α and β values from each filter are then combined to generate a single (total) quantity for the current forward speed and rotational speed of the robot (see section 2.1, below). Navigation tasks are specified in terms of sequences of Transitions (see section 2.). Each Transition specifies some kind of motion, together with one or more termination conditions. The motion may be a “null motion”, which means the robot remains where it is; a rotation motion; or a translation motion defined in terms of a compass heading and a distance. Termination conditions define detectable states that are generated upon successful completion of a Transition, or by some known failure condition. For example, a termination condition may be satisfied when the distance the robot has travelled in the defined compass direction is the same as the
magnitude of the Transition vector. Short linear sequences of Transitions (of between one to five Transitions) form a Transition Group. Each Transition Group defines which other Transition Groups (one or more) can follow the successful termination of the last Transition in the Transition Group. The Transition Groups thus form a directed graph. The navigation behaviour of the robot is specified by telling the robot to be doing one of the Transition Groups. If MiReLa cannot immediately start doing the specified Transition Group because it is not one of the Transition Groups immediately connected to the Transition Group it is currently doing, in the Transition Group graph, then the sequence of Transition Groups that it needs to completed, so as to be doing the specified Transition Group is executed. This sequence is identified using a simple graph traversal algorithm run over the Transition Group graph, (see section 3.). To demonstrate and test the reliability of this navigation system (and other aspects of the robot not covered in this paper), two experiments have been conducted; one during the Technology Park Open Day held in November 2002, and the other during the Technology Park Open Day held in November 2003. During each of these Open Day’s, about 2,000 people visited the stands and exhibitions set up in the Hall of the main building. They thus presented real and difficult conditions for any robot to work in. Section 4. presents the detail of these experiments, together with the main results and conclusions.
2.
Transitions and Transition Groups
In this section, a more detailed description of the implementation of the Transition based navigation system, is presented.
2.1
Transitions
A Transition is implemented using a set of filters and a set of termination conditions, see figure 2.
A filter takes real-time data from one or more of the robot’s sensor systems and out puts two quantities, see figure 3: αf = current linear speed, and
βf = current rotation speed.
βm
INPUT
OUTPUT
αm
Figure 3: A filter.
Each filter is designed, developed, and tested to support a particular kind of Behaviour, such as: Sonarbased obstacle avoidance; Laser-based obstacle avoidance; compass distance integration; door passing; etc. Each Transition is defined in terms of one or more filters and termination conditions. The α and β values from each filter used in a Transition are combined using the harmonic mean expression, see (Sanchez, 2001), for example. In the case of the α values this is straight forward, since they are all positive. In the case of the β values, which range from −1 to 0 (for anticlockwise rotation) and 0 to +1 (for clockwise rotation), they are divided in to two ranges, a rotate left (−ve) range, and a rotate right (+ve) range, then each is combined using the harmonic mean expression, and the larger of the two resulting (total) β values is applied, see (Ra˜ n´o, 2004) for more details.
TRANSITION
2.2
Transition Groups
Filters
Completion Conditions
Figure 2: Composition of a Transition.
To allow MiReLa to use the same Transitions in its navigation to different places in the main building, short sequences of (between one to five) Transitions are collected in to what are called Transition Groups. A Transition Group is defined in terms of a strictly linear set of one or more Transitions. Each Transition Group also defines which other Transition Groups can be executed next, see figure 4. These next allowable Transition Groups are defined in a table; the TANTG table (Table of Allowed Next Transition Groups). The complete set of Transition Groups thus form a directed graph.
TRANSITION GROUP
isfies the following two properties: 1. All the Transitions that are defined as part of it, must produce a zero α value.
Transitions
2. It must include at least one Transition with only one active termination condition, which is set to true only when another Transition Group of type LNTG is selected for doing.
Table of Allowed Next Transition Groups
Transition Group of type CTG: This type includes any kind and number of Transitions, except those which satisfy property 2 of Transition Group of type LNTG. Figure 4: Composition of a Transition Group.
3.
Navigation
MiReLa is always doing a Transition Group, even if appears not to be doing anything: a MiReLa Transition does not necessarily have to cause MiReLa to move; it can be defined by a vector with magnitude zero. The way to make MiReLa find its way to some other place, is to then tell it to be doing a Transition Group that it can only be doing after navigating its way to the particular place. Navigation from place to place, is thus a side effect of telling MiReLa to be doing certain Transition Groups: we see MiReLa find its way to the place we want it to go, but MiReLa has no proper sense of going anywhere; it just tries to successfully complete all the Transitions in each of the Transition Groups it must finish doing so as to be doing the nominated Transition Group. To facilitate this use of the Transition Group graph for navigation, and to support the possibility for users to “tell” MiReLa where to go (by telling it which Transition Group to be doing), a special type of Transition Group is defined. Transition Groups of this type have a particular kind of completion condition which is only satisfied when MiReLa is “told” to be doing another (or the same) Transition Group. The way to make MiReLa be always doing a Transition Group is to restrict the type of Transition Groups it can be “told” to be doing, to this special type. In effect, what this means is that MiReLa will complete a series of Transitions (grouped in several Transition Groups) that take it to some place, and then wait until it is instructed to be doing some other Transition Group, that may result in it going somewhere else.
3.1
Transition Groups of type LNTG and CTG
Two types of Transition Groups are thus defined, a LNTG (Listen for New Transition Group) type, and a CTG (Common Transition Group) type. Any Transition Group must be one of these two types. Transition Group of type LNTG: Is one which sat-
The sequence of Transition Groups that must be completed, in order for MiReLa to go from doing one LNTG type Transition Group to be doing another LNTG type Transition Group must all be of type CTG. Having a Transition Group of type LNTG in this sequence, would make the robot stop and wait for a new order before starting doing the required Transition Group.
3.2
Navigation behaviour
By defining the TANTGs of each Transition Group, it is possible to generate a graph of Transition Groups. A typical Transition Group graph could be as follows: CTG1
CTG3
LNTG1
CTG2
LNTG2
CTG4
Figure 5: A general graph
The sequence of Transition Groups to do in order to bring the robot from doing one Transition Group of type LNTG to another Transition Group of type LNTG, can be found, using a breadth first search algorithm, see (Brna, 1995), for example. The most common thing is that a Transition Group of type CTG implies movement, that’s to say, it results in MiReLa moving from one physical place to another. In this case, MiReLa does not check in any way to see if it has indeed arrived at the right place: it has no means to do this. What it does check is each termination condition of each Transition that form the Transition Group. When the Transition Group is done it starts the next Transition Group in the identified sequence of Transition Groups. It is the designers job to build Transition Groups which make the robot behave in the desired way. Not all the Transition Groups of type CTG involve movement. There are configurations where the robot is
required to do other things. For example a CTG type Transition Group might make MiReLa stop, wait until it detects a person and turn to where it detected the person.
3.3
Generating a graph from the names of the Transition Groups
Transition Group of type LNTG A:A, C:C, E:E, F:F
Transition Group of type CTG A:B, B:A, B:C, C:B, B:C, A:D, D:A, D:E, E:D, D:F, F:D
Table 2: Transition Groups used for the 2003 Open Day
Some rules are defined to name the Transition Groups. This way, the TANTGs of each Transition Group are completed from the names of the Transition Groups. That’s to say, a graph is generated from the names of the Transition Groups. The structure of the names of the two types of Transition Groups is defined as follows:
Suppose the robot is located at Reception (see figure 8), thus, doing Transition Group of type LNTG C:C and it is required to go to Fun Technology Room, thus, to be doing Transition Group of type LNTG E:E. The sequence of Transition Groups found by the algorithm in step 1, is:
• Transition Groups of type CTG: Name1:Name2 C:C- C:B- B:A- A:D- D:E
• Transition Groups of type LNTG: Name:Name
Then the Transition Group of type LNTG, E:E is added to it, thus the resulting sequence to do to bring the robot from Reception to Fun Technology Room is:
The TANTGs are completed as follows: Type of Transition Group CTG
LNTG
Name structure Name1:Name2
Name:Name
Generation of the TANTG Include the Transition Groups of type CTG starting with Name2 Include the Transition Groups of type CTG starting with Name
Table 1: How the TANTGs of the Transition Groups are completed.
C:C- C:B- B:A- A:D- D:E- E:E
4.
The Open Day Experiments
The main building of the San Sebasti´an Technology Park is a public building. It hosts many conferences, workshops, visits, and other events throughout the year. Each year, in November, an Open Day event is held. These are intended to present the work of the San Sebasti´an Technology Park, and the various research centres, companies, and other organisations situated in the Technology Park, to a general public. To date, there have been four such open days, the first in 2000, and on such occasions about 2,000 people visit the main building.
Note that in a graph generated from these rules, it is not possible to start from doing a LNTG type Transition Group and end doing another LNTG type Transition Group in one step. This is because there isn’t any LNTG type Transition Group included in the TANTGs of CTG type Transition Groups. That is to ensure that the sequence of Transition Groups that must be completed, in order for MiReLa to go from doing one LNTG type Transition Group to be doing another LNTG type Transition Group are all of type CTG (see section 3.1). Thus the sequence is found in two steps. This can be illustrated with the following example: The graph shown in figure 8, used for the 2003 Open Day experiment, is formed from the definition of the Transition Groups:
Figure 6: Map of the floor 0 of the Main Building.
Figure 7: Map of the floors 0(left) and 1(right) of the Main Building.
4.1
The 2002 Open Day Experiment
At the 2002 Open Day, MiRela guided a person from “MiReLa Etxea” (it’s home), on the ground floor of the main building, to the Auditorium, on the first floor of the building. And then returned home again. Figures 6 and 7 show the maps of the ground floor and first floor of the main building, and the trajectory followed by MiReLa. The total distance of the whole tour is more than 200m. To complete it, the robot has to go through 10 doors and it needs to go up and then down in the lift. Two runs of this experiment were presented; one at 11:20 and the other at 13:20. The first time there was not so many people wandering around the building, the second time it was much more crowded. On both occasions MiReLa successfully navigated its way from it’s home, through the Hall, round to the lifts, up the lift, and then round to the Auditorium, and back. On the first run, MiReLa bumped into a wall, and, on the second run, it bumped an edge of a door, but neither of these events caused it to get lost, or fail to complete the tour. In this experiment, the complete tour, from home to Auditorium, was defined as one Transition Group containing the complete sequence of Transitions. There was thus no Transition Group graph used on this occasion, and thus no possibility for MiReLa to get from its home to the goal and back in more than one way. However, MiReLa’s navigation behaviour proved to be robust and reliable in these realistic but difficult conditions, involving lots of people: conditions that MiReLa had never been tested in before the 2002 Open Day event!
4.2
Figure 8: Map of the floor 0 of the Main Building, with the representation of the Transition Group graph implemented in MiReLa for the Open Day of 2003.
The robot was placed near to the entrance of the main building (labelled with “Reception” in figure 8), doing Transition Group C:C, and it offered the possibility of a video conference connection with another person using a computer placed at the point labelled with “Secretary Office” in figure 8 (simulating the secretary in another office).
Figure 9: Video-conferencing through MiReLa.
The person at “Reception”, interested in being guided by the robot, could video-conference with the person at “Secretary Office” and say which place he or she would like to be guided to.
The 2003 Open Day Experiment
At the 2003 Open Day, MiReLa operated in the Hall of the Main Building. See (Esnaola et al., 2004) for a more complete description of the experiment, which included not just navigation behaviour.
Figure 10: The computer with the Web Page control interface.
The person at “Secretary Office” then used a Web
page command interface, to instruct MiReLa to guide the person to his or her desired place. In other words, MiReLa was instructed to be doing either Transition Group A:A, Transition Group E:E or Transition Group F:F. In this experiment, MiReLa operated continuously from 10:00 to 14:00. It always reached the places it was asked to go to. At around 12:00, the Hall got so crowded that it was necessary to slow down the general speed of the Transitions, to prevent MiReLa from bumping in to people in front of it, because they did not have enough room to make way for it.
When this happened the robot found a gap toward the direction of the tables of the stands as they couldn’t be detected neither by sonar nor by laser and it couldn’t help but to bump in to them. So it was necessary, to ask people to unblock the path. The navigation system proved to be very robust as the robot always reached the places requested. Even when the path was blocked and it bumped in to the tables of the stands, it continued the navigation when the path was unblocked and it reached it’s target.
5.
Conclusions and future work
One interesting aspect of the navigation system presented here, is that it doesn’t check the probability of being placed at any point in any internal map. It checks the completion conditions of Transitions. If a Transition Group is intended to take the robot from one place to another, it is the designer’s task to design good Transitions to make this happen reliably. The nodes of the graph are Transition Groups, do not correspond to places, as is more typical in topological map based robot navigation approaches, but with kinds of Behaviour. The graph for the ground floor and for the first floor of the building (about 1200m2 of surface) was implemented with: • 32 Transition Groups of type CTG, including 135 Transitions. • 17 Transition Groups of type LNTG including 17 Transitions.
Figure 11: The hall between 12:00 and 13:30
The configuration of the Hall of the Main Building of the San Sebasti´ an Technology Park changes a lot for an Open Day. Sets of stands are mounted all the way around the Hall, to show other project and activities. These stands included tables of about 80 cm of height. Laser and sonar have an important role in the obstacles avoidance behaviour of the robot. The laser sensor is placed at 36 cm from the floor, while the sonars are placed at 72 cm of height. There where occasions when the robot found the path connecting the reception place with the video-conference stand completely blocked by people. Some having a look at the stands mounted to both sides of the path and others just talking in groups.
Thus, there are 152 Transitions implemented. The information required for a Transition is stored in a C structure. This contains information about which filters and completion conditions to activate in each moment. It needs 460 bytes of computer memory, so the memory required to save the whole graph is 69.92 Kbytes. Extending MiReLa’s navigation behaviour, to cover larger areas in bigger building, results in a linear increase in required memory and computation resources, not an exponential growth, as is the case in other map-based approaches found in the literature. An example of the information structure for a Transition is shown at figure 12. MiReLa’s navigation behaviour is currently being extended to the whole building (floors 2 and 3), where the offices are placed. The development of the new filters needed for this is proving to be quite straight forward, since we can reuse a great deal of the existing filters, that have been extensively tested. Also, because the navigation system uses a simple motor fusion rule (the harmonic mean), adding new filters, or defining new filter combinations in new Transitions, is very easy. This also makes it easy to improve the reliability and robustness of
an existing Transition by adding new filters.These public experiments have thus shown that MiReLa can successfully and reliably navigate in a real place under real (and at times difficult) conditions, using a purely Behaviourbased navigation system. We believe this to be the first purely Behaviour-based robot with such real-world navigation capabilities.
//Transition information struct process_atom { char process_name[255]; /* Filters */ struct process_compass_settings compass; struct process_sonar_settings sonars; struct process_irs_settings irs; struct process_wf_settings wf; struct process_drive_settings drive; struct process_hang_settings hang; struct process_laser_settings laser; struct process_sound_settings sound; struct process_web_settings web; struct process_door_settings door; struct process_people_settings people; struct process_stop_settings stop; struct process_nf_settings nf; /* Change Conditions */ int condition_compass; int condition_drive; int condition_door; int condition_sound; int condition_web; int condition_people; int condition_lisplace; int condition_bump; int condition_sonback; int condition_nf; int condition_alpha; float condition_alpha_value; int condition_timeout; float condition_timeout_value; int condition_lasBigerThan; float condition_lasBigerThan_value; }; //Information for compass filter. struct process_compass_settings { int active; float alpha; float target_heading; float heading_min_delta; float heading_max_delta; };
Figure 12: The C structure to store information required for a Transition. It includes structures with information for each filter. The information structure for the Compass filter is shown as example.
Acknowledgements We acknowledge the support (financial and technical) of the San Sebasti´an Technology Park for Project MiReLa, and in particular, we thank Amaia Bernaras, Manuel Cendoya, I˜ nigo Martinez, Mirari Olaizola, Rub´en Leon, and Alvaro Segura, for help in various aspects of the design and development of this experiment.
References Akin, R. (1998). Behavior-Based Robotics. MIT Press. Brna, P. (1995). Introduction to AI Programming. Word Wide Web, http://www.comp.lancs.ac.uk/ computing/research/aai-aied/people/paulb/ old243prolog/243notes96.html. Brooks, R. (1987). Planing is just a way of avoiding figuring out what to do next. (Also published as (Brooks, 1999), chapter 6.). MIT Artifitial Intelligence Laboratory Working Paper 303. Brooks, R. (1999). Cambrian Intelligence. The early history of the new AI. MIT Press. Esnaola, U., Ra˜ n´o, I., and Smithers, T. (2004). Robot MiReLa: Helping the secretary to attend visitors. In 2004 2nd International Workshop on Advances in Service Robots (ASER 2004). PTSS (1998). Parque Tecnol´ ogico de San Sebastian. Word Wide Web, http://www.miramon.es. Ra˜ n´o, I. (2004). Investigaci´ on de una arquitectura basada en el comportamiento para robots aut´ onomos en entornos semi-estructurados. PhD thesis, San Sebasti´an Technology Park. Sanchez, P. (2001). Harmonic Mean. PlanetMath.org, http://planetmath.org/encyclopedia/ HarmonicMean.html.
