Goal Person Location Relativelocation. Condition Side Direction Truthvalue. Figure 8: The syntax of a LISTEN operation

Transcription

1 <listen-label> ::= LISTEN <label> <label> ::= <label> Or <label> Seq <label-list> List <label> Goal Person Location Relativelocation Condition Side Direction Truthvalue Figure 8: The syntax of a LISTEN operation 35

2 function exec-nav-plan suspend-nav-plan restart-nav-plan kill-nav-plan exec-monitor-node exec-monitor-distance exec-monitor-time signal-robot-presence perceive-fixed-obstacle perceive-crowding query-position query-state query-failure-description query-navigation-history navigation command translates the navigation plan in a sequence of landmarks, sends the sequence to the modules controlling the sensors and actuators of the mobile robot and receives information about the navigation execution. stops the navigation in the current state; restarts a suspended navigation; terminates the navigation; given a tactic representing a path as input, executes the tactic by monitoring information each time the robot navigates through a new node in the map. executes a tactic and monitors the position of the robot every time the robot has navigated for a given distance. executes a tactic and monitors the position of the robot at each given time interval. activates one or more devices (e.g. a beeper, a hazard light) to signal the presence of the robot; activates the navigation level to recognize the presence of xed obstacles; activates the navigation level to recognize the presence of crowding. returns the node in the map representing the current position of the mobile robot; returns the current state of navigation (e.g. navigating, suspended, success, failure); returning a description of the failure; returns a path describing the navigation so far. Figure 6: Navigation commands <say-phrase> ::= SAY <phrase> <phrase> ::= <utterance> <question> <question> ::= <y/n-question> <wh-question> <wh-question> ::= <who-question> <where-question> <what-question> Figure 7: The syntax of a SAY operation 34

3 map access primitive node-get-objects arc-get-type arc-get-geocost arc-get-navcost arc-get-crowding set-arc-inaccessible computed result list of objects associated to the node given in input. type of the arc given in input (i.e. door or open-space). geometrical cost associated to the arc given in input (i.e. the distance between the barycenters of the connected areas). navigation cost associated to the arc given in input (i.e. the \diculty" in navigating through the arc). crowding cost associated to the arc given in input (i.e. the statistical probability to nd the arc crowded). sets the geometrical, navigation and crowding costs to INFINITE. Figure 4: Function accessing to the map -planner shortest-path least-crowded-path easiest-path least-cost-path all-paths ord-constrained-paths unord-constrained-paths shortest-ord-constrained-path computed path geometrically shortest path; best path according to the crowding cost; best path according to the navigation cost; best path according to the cost function provided as input, (it can be a combination of other costs contained in the map); list of the possible paths from starting to target position; list of all the paths from starting to target position, constrained to pass through a list of specied locations, according to a supplied ordering relation; list of all the paths from starting to target position, constrained to pass through a list of specied locations, in the most convenient order. geometrically shortest path between the ones satisfying the set of ordered constraints specied. Figure 5: Most signicant -planners 33

4 ? 3 6? 6 9 8? 6 3 6?? ? 20 69? 21 11? ? 6 6? ? 3? ? ? ?? ? 11? ? 8? ? 9? 13 -? ? N 1 N6 N 8 N 18 N 24 N 32 N 37 N 13 N 19 N 20 N 23 N 25 N 38 N 2 N 9 N 14 N 26 N 33 N 35 N 39 N 3 N 7 N 10 N 12 N 15 N 21 N 27 N 30 N 34 N 4 N 16 N 28 N 5 N 11 N 17 N 22 N 29 N 31 N 36 Figure 3: The map

5 MRG CENTRAL REASONER INTERACTION SYSTEM NAVIGATION SYSTEM I/O MANAGER KB NAVIGATION PLANNER MAP GRAPHICS INTERFACE SPEECH INTERFACE NAVIGATION INTERFACE GRAPHICS SPEECH VISION NAVIGATION MOBILE ROBOT USER Figure 2: The multilevel architecture of MRG. 31

6 Figure 1: The mobile robot MAIA Average Minimum Maximum Table 1: Navigation Planning Times (in seconds) 30

7 List of Figures 1 The mobile robot MAIA : : : : : : : : : : : : : : : : : : : : : : : : : : 30 2 The multilevel architecture of MRG. : : : : : : : : : : : : : : : : : : : 31 3 The map : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 32 4 Function accessing to the map : : : : : : : : : : : : : : : : : : : : : : : 33 5 Most signicant -planners : : : : : : : : : : : : : : : : : : : : : : : : : 33 6 Navigation commands : : : : : : : : : : : : : : : : : : : : : : : : : : : 34 7 The syntax of a SAY operation : : : : : : : : : : : : : : : : : : : : : : 34 8 The syntax of a LISTEN operation : : : : : : : : : : : : : : : : : : : : 35 29

8 Reasoning Group at IRST, Istituto per la Ricerca Scientica e Tecnologica, Trento, Italy. His present research interests include the integration of deductive and reactive planning, the design and implementation of architectures for complex real world largescale applications, and meta level reasoning techniques. 28

9 AUTHOR'S BIOGRAPHIES Alessandro Armando received the M.S. in electronic engineering from the University of Genoa, Italy in He is currently attending a Ph.D. program within the Mechanized Reasoning Group at the Dipartimento di Informatica Sistemistica e Telematica dell'universita di Genova. His present research interests include planning, problem solving and automated deduction. Alessandro Cimatti received the M.S. in electronic engineering from the University of Genoa, Italy in Since 1989 he has a researcher position within the Mechanized Reasoning Group at Istituto per la Ricerca Scientica e Tecnologica in Trento, Italy. Currently he is interested in introspective systems for planning and automated deduction. Enrico Giunchiglia received the M.S. in electronic engineering and the Ph.D. in electronic and computer science from the University of Genoa, Italy in 1989 and 1992 respectively. He is currently working in the Mechanized Reasoning Group at the Dipartimento di Informatica Sistemistica e Telematica dell'universita di Genova. His present research interests include planning and knowledge based architectures. Paolo Pecchiari received the M.S. in Mathematics from the University of Trento, Italy in He is currently working in the Mechanized Reasoning Group at the Dipartimento di Informatica Sistemistica e Telematica dell'universita di Genova where he attends a Ph.D. program in electronic and computer science. His main research interests are the development and theoretical study of knowledge based systems in robotics, CAD systems and theorem proving applications. Luca Spalazzi received the M.S. in electronic engineering at the University of Ancona, Italy in He is currently attending a Ph.D. program within the Mechanized Reasoning Group at the Istituto di Informatica dell'universita di Ancona. His present research interests include the integration of deductive and reactive planning. Paolo Traverso ( ) studied electronic engineering at the University of Genoa, where he graduated in He is currently a senior researcher within the Mechanised 27

10 [27] B. Caprile, R. Cattoni, A. Cimatti, F. Giunchiglia, and P. Traverso. Proposta di interfaccia ragionamento meccanizzato-visione nell'ambito del progetto maia - versione 2, IRST Internal Report no [28] S. Dalbosco and F. Giunchiglia. La mappa dell'irst - Versione 1. Technical Report , IRST, Trento, Italy, Internal Report. [29] S. Dalbosco and F. Giunchiglia. Software per la gestione di un sistema di navigazione - Versione 1. Technical Report , IRST, Trento, Italy, [30] R. Cattoni, A. Cimatti, and S. Dalbosco. Proposta di interfaccia Ragionamento Meccanizzato-Visione nell'ambito del progetto MAIA - Versione 1, IRST Internal Report no [31] F. Giunchiglia, P. Traverso, A. Cimatti, and L. Serani. Documento di interfaccia tra il ragionatore-pianicatore centrale ed il modulo di voce - (versione 2), IRST Internal Report no

11 [17] R. E. Fikes and N. J. Nilsson. STRIPS: A new approach to the application of Theorem Proving to Probl em Solving. Articial Intelligence, 2(3-4):189{208, [18] E.H. Durfee and V.R. Lesser. Incremental Planning to Control a Blackboard-based Problem Solver. In Proc. of the 5th National Conference on Articial Intelligence, Philadelphia, PA, [19] M. P. George. Situated Reasoning and Rational Behaviour. Technical Report 21, Australian AI Institute, Carlton, Victoria, Australia, [20] R. Simmons. Concurrent planning and execution for a walking robot. In Proc. IEEE International Conference on Robotics and Automation, pages 2086{2091, Sacramento, CA, [21] M. George and A. L. Lansky. Reactive reasoning and planning. In Proc. of the 6th National Conference on Articial Intelligence, pages 677{682, Seattle, WA, USA, [22] M. George. An embedded reasoning and planning system. In J. Tenenberg, J. Weber, and J. Allen, editors, Proc. from the Rochester Planning Workshop: from Formal Systems to Practical Systems, pages 105{128, Rochester, [23] D.H.D. Warren. WARPLAN: A System for Generating Plans. Dept. of Computational Logic Memo 76. Articial Intelligence, University of Edinburgh, [24] A. Tate. Generating Project Networks. In Proc. of the 5th International Joint Conference on Articial Intelligence, pages 888{893, [25] E.D. Sacerdoti. A Structure for Plans and Behaviour. Elsevier-North Holland, [26] P.R. Davis and R.T. Chien. Using and Reusing partial plans. In Proc. of the 5th International Joint Conference on Articial Intelligence, Cambridge, Massachussets,

12 [9] P. Traverso, A. Cimatti, L. Spalazzi, and E. Giunchiglia. Building planners with explicit control mechanisms. In Proceedings 5th International Symposium on Articial Intelligence, Cancun, Mexico, AAAI Press. Revised version of IRST- Technica Report , IRST, Trento, Italy. [10] R. Cattoni and B. Caprile. Navigation Shell: Planning and Supervising Reexive Indoor Navigation. Forthcoming IRST Technical Report, [11] B. Angelini, G. Antoniol, M. Dal Zotto, R. De Mori, D. Giuliani, R. Gretter, and G. Lazzari. Use of procedural networks for task oriented dialogue modelling in mobile robot-operator voice communication. In EUSIPCO, pages 1279{1282, Barcelona, Spain, September [12] S. Dalbosco, F. Giunchiglia, and Jon Slack. Funzionalita dell'interfaccia graca M/M nel progetto MAIA. Forthcoming IRST Technical Report, [13] S. Dalbosco and F. Giunchiglia. Il pianicatore di navigazione. Technical Report , IRST, Trento, Italy, [14] A. Cimatti, P. Traverso, S. Dalbosco, and A. Armando. Navigation by Combining Reactivity and Planning. In Proc. Intelligent Vehicles '92, Detroit, IRST- Technical Report , IRST, Trento, Italy. [15] L. Spalazzi, A. Cimatti, and P. Traverso. Implementing planning as tactical reasoning. In Proc. AIS'92, AI Simulation and Planning in High Autonomy Systems Conference, pages 80{85, Perth Australia, IEEE Computer Society Press. Revised version of Technical Report , IRST, Trento, Italy. [16] P. Traverso, A. Cimatti, and L. Spalazzi. Beyond the single planning paradigm: introspective planning. In Proceedings ECAI-92, pages 643{647, Vienna, Austria, IRST-Technical Report , IRST, Trento, Italy. 24

13 References References [1] L. Stringa. An Integrated Approach to Articial Intelligence: the MAIA Project at IRST. Technical Report , IRST, Trento, Italy, [2] R. Fikes, P. Hard, and N. Nilsson. Learning and executing generalized robot plans. In Readings in Articial Intelligence, pages 231{249, Palo Alto, Columbia, [3] D. E. Wilkins. Practical Planning: extending the classical AI planning paradigm. Morgan Kaufmann, San Mateo, [4] R. A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, RA-2(1):14{23, [5] L.P. Kaelbling. An architecture for intelligent reactive systems. In Reasoning about actions and plans: Procedings of the 1986 Workshop. Morgan-Kaufmann Publishers, [6] M. George, A. Lansky, and M. Schoppers. Reasoning and planning in dynamic domains: An experiment with a mobile robot. Technical Report 380, A.I. Center, SRI International, [7] R. Simmons. Coordinating planning, perception and action for mobile robots. In AAAI Spring Symposium on Integrated Intelligent Architectures, pages 156{159, SIGART Bulletin vol. 2 no. 4. [8] M.J. Gordon, A.J. Milner, and C.P. Wadsworth. Edinburgh LCF - A mechanized logic of computation, volume 78 of Lecture Notes in Computer Science. Springer Verlag,

14 Acknowledgements This work has been conducted as part of MAIA, an integrated AI project under development at IRST and has been done with the partial support of the Italian National Research Council (CNR), Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo (Special Project on Information Systems and Parallel Computing). Fausto Giunchiglia has supervised the development of MRG and provided many of the underlying intuitions. Roberto Giuri and Marco Marinucci have participated to design and implementation of MRG. 22

15 A further technical problem that we have faced is the fact that even if UNIX provides ecient remote comunication supports, not all the programming languages (e.g. Lisp w.r.t. sockets) can used them. For this reason we have implemented in C-language a library of fuctions that work on sockets. The comunication primitives get thus implemented in C-language and imported as compiled code. Finally, MRG is also being used in FIRST (Friendly Interactive Robot for Service Tasks), an EUREKA project that aims at building an automatic system for transportation in hospital environments. The system is organized around a central station that controls a group of robots. The main task of the robots is the transportation of materials (like food, sheets and medicines) from the central store of the hospital to the departments. For this tasks, MRG needs to be extended to control and coordinate more than one robot navigating and interacting in the environment. This project is currently in the design phase. 7 Conclusions The successful application of a general purpose planning system on real world complex application domains depends on which extent the activities of plan formation, plan execution, monitoring and failure handling can be exibly interleaved. In this paper we presented a multilevel reasoning system (called MRG) where low level functionalities (e.g. navigation, vision and speech understanding) are exibly combined with higher level reasoning capabilities through a set of specialized subreasoners. In most of the existing planning systems the planning activities and the control mechanism are xed in the implementation code. The basic feature of MRG is that there is no commitment to a xed planning paradigm. Rather, it is possible to choose the most appropriate planning technique according to the current application. This is achieved by representing the dierent reasoning steps, control strategies and error recovery mechanisms explicitly in the language of tactics. 21

16 taken into account. MAIA is realized as a distribuited architecture, comprising the mobile robot depicted in gure 1 and several other machines each dedicated to a particular task. More in detail, on board of the mobile platform resides sensors, computers and motors. Actually, sensorial devices comprise sonars, odometers and cameras. Other sensorial devices under consideration (but not yet installed) are: gyros, micro-switches and laser scanners. The robot has two hours maximum autonomy and one hour average autonomy. In future developments, the robot will be able to change batteries autonomously. MRG itself is installed as a distribuited system. A supervision station whose functions are centralized supervision, monitoring and control is installed on a SUN-SPARCstation 10 workstation. Transportation tasks can be requested potentially from several dierent machines and terminals. In the current MAIA implementation requests can be entered from four workstations SUN-SPARCstation 1. MRG is mainly implemented in Lucid Common Lisp in UNIX. The pheripheral systems (e.g. reactive navigation, vision processing and speech recognition), that usually require very time-consuming processes, are installed on dedicated machines (either on board or not of the robot). They are implemented in programming languages dierent from Lisp, for instance, most of the reactive navigation and visiom modules are implemented in C-language. The comunication between modules, either within MRG or between MRG modules and peripheral modules, has been implemented using dierent supports, mainly sockets and les, depending on the kind of processes that have to be connected. For instance, sockets are used to exchange quickly not high amounts of data between MRG and the navigation shell. An interface service implemented in MRG provides a communication modality independent of the type of channel that is used. This improves modularity and maintenance, which are very critical features in large-scale, heterogeneous complex applications like MAIA. 20

17 (retrieved by the knowledge base), the state of the robot (e.g. position and orientation), the paths of navigation and the navigation planner activity (obtained by the central reasoner). The graphics module, by drawing onto the screen the information stored in the views, provides a set of functionalities (e.g. generation and composition of views, zoom, simple animation of the robot's movements for monitoring and simulation, visualization and selection of the navigation path(s) for the robot, communication capabilities to exchange goals with the I/O manager). 6 Application in MAIA MRG at the moment is being used in MAIA (Advanced Model of Articial Intelligence), a mobile robot that has to deliver mail, faxes and packs around in the IRST laboratory. Mail can be delivered on a routinary basis from a centralized position to target places and users. Faxes and packs can be transported on request. Due to the real-time application tasks, MRG must be very ecient. Most of the implemented classical planners are very slow and cannot be used in real-time systems. On the other hand, MRG tactics can be customized to achieved desired performances. So far, we have mainly worked on designing ecient tactics for the navigation planning task, which is the most fundamental task. Table 1 reports data with the planning time to build a navigation path in a map of 113 nodes (each node containing an average of 10 objects), that is the current map representing the IRST building in the MAIA application. Given the maximum robot speed (1 meter/second), the average speed of 0.5 m/sec, MAIA is thus able to reach a 100 meter far destination in less than 4 minutes. Of course, such a result considers normal situations i.e. that the planned route is eectively viable (not obstructed). In cases in which the route is not viable, then the re-planning time and the time needed to go from the actual to the desired position must be also 19

18 A more complex interaction task consists of asking the user (for instance through the graphic interface) whether a given route for the mobile platform is satisfactory, allowing the user to modify or specify the route by means of a combined use of speech and graphic capabilities. The interaction between the central reasoner and the I/O manager may occur either because the central reasoner wants some information to be transferred to the user or because the I/O manager communicates a navigation goal (on request by the user) to be achieved. The main interaction primitives provided by the interaction system are: user-interaction-inform communicates to the user the result of the execution of the planning and of the navigation activities; user-interaction-confirm communicates to the user the path given in input and returns the conrmation or the rejection by the user. user-goal-ask ask the user for a goal. The peripheral modules provide the I/O manager with the following functionalities: Speech Module. The interaction between the I/O manager and the speech module takes place by means of the two primitive operations, SAY and LISTEN. SAY activates the synthesis of the sentence given in input, and LISTEN activates the recognition process on the sentence uttered by the person, returning the `understood' sentence. The syntax 2 of these operations is specied in gure 7 and 8. Graphic Module. The graphical information is organized in views. A view is a data structure encoding the graphical information about the navigation domain 2 A description of the semantical and pragmatical import of the language is out of the goals of the paper (more information can be found in [31]). However an intuitive understanding of the meaning of the phrases can be inferred by the mnemonic names of the syntactical categories involved in the BNF grammar. 18

19 4.4 Reasoning about navigation strategies The map, the -planners and the interface provide the basic steps of the navigation activity. However, these steps have to be combined and integrated with dierent modalities according to the goal of the navigation and to the success or failure of navigation. Choosing a particular sequence of steps (e.g. plan for a path with a particular -planner, execute it, and if a failure occurs replan and reexecute) is not satisfactory at all: dierent navigation modalities and dierent failure recovery strategies may be more suitable for dierent (high level) goals. For this reason the navigation strategies are expressed and combined as tactics, where the modalities of navigation and reaction to failure are explicitly represented. As an example, consider that the vision navigation module is able to avoid mobile obstacles like human users, but in case of failure it does not verify whether an obstacle is permanent, it only communicates the failure. Possible reactions may be to try to execute the rest of the plan, assuming that obstacle is xed, or modify the map by cutting the suitable arcs with the primitive set-arc-inaccessible and then replan for a dierent path. 5 The interaction system The interaction system is activated by the central reasoner in order to have an interaction goal executed. The main module of the interaction system is the I/O manager. Task of the I/O manager is to plan the dialogue with people and to coordinate the peripheral modules (namely the speech module and the graphic module). Given an interaction goal to achieve, the I/O manager can directly invoke the peripheral modules or perform some planning to decide the peripheral modules to activate and the order of activation. Simpler tasks are achieved by executing a single action: for instance the task to synthesize a phrase has the simple solution of activating the speech module. 17

20 4.2 The navigation planner The navigation planner [13, 14] plans for a trajectory (i.e. a sequence of adjacent nodes in the map) which can be executed by invoking the vision navigation module. Since the planning phase needs to be fast, but also to devise trajectories with dierent features, it is actually performed by a set of special purpose algorithms, called -planners. - planners search through the graph of nodes minimizing one (or a given combination) of costs. In this way, for instance, if navigation time is important, a navigation plan through (usually) less crowded areas (as returned by least-crowded-path) can be better than a plan devised taking into account only geometrical information (e.g. by shortest-path). There are also more complex functionalities, which are used when the navigation goal is more complex than reaching a single location: the search can be performed to reach a node belonging to a given set of nal nodes, and constraints can be put on the admissible paths, like avoiding certain nodes, or passing through a list of nodes with (or without) a given order. The most signicant -planners are listed in gure The navigation interface The navigation interface [30] hides the functionalities of the vision navigation module by providing for a set of queries and navigation commands, the most important being reported in gure 6. Navigation commands control the navigation of the robot along a plan of the form produced by the -planners. For instance, the navigation command exec-nav-plan activates the navigation of the robot along the path specied as input. Queries return information about the status of the navigation. For instance, the query query-position returns the node in the map representing the current position of the mobile robot. Since the navigation planner handles symbolic information (e.g. nodes of the map) and the vision navigation module performs numerical computations the interface also performs the data conversion between the two formats. 16

21 The map is organized as a graph, whose nodes represent areas of the building and whose arcs represent the connections between them. In gure 3 is depicted a map currently used by MRG. The nodes are dened and classied depending on the navigation capabilities of the reactive system. Currently the following four types of nodes are provided: corridor, open-space, room and cross. This classication is important since MAIA has dierent navigation capabilities depending on the type of area. For instance, in a corridor the mobile platform is able to navigate following the walls while in an open space it may try to follow the route suggested by the navigation planner. Arcs are classied as open and door. An arc of type open represents - for instance - a virtual connection between two pieces of the same physical corridor or between a corridor and a cross. An arc of type door can represent a door connecting areas of any type. Associated to each arc and node is a complex data structure storing signicant information about the navigation and a set of dierent costs representing the diculty of navigation between the nodes connected by the arc. Namely, (i) a geometrical cost (function of the distance between the nodes), (ii) a navigation cost (curves are more \expensive" than aligned nodes) and (iii) a crowding cost (crowded areas are more dicult to navigate). Such costs may assume as value a positive integer or INFINITE. The latter case represents the impossibility to navigate through the arc. Besides information useful for the navigation, to each node it is also associated the set of contained objects, each one described by the coordinates of its own center of gravity, dimensions and so on. Figure 4 is a list of the most signicant primitives providing access to the information stored in the map. Most of the information is stored in the map at the moment of the denition of the navigation domain, but part of it (e.g. descriptions of navigation sessions, success or failure, obstacle descriptions) can be also updated by MRG at run time, and be exploited during the planning phase. For instance, if many navigation failures occur due to crowding in the same area, the corresponding crowding cost can be updated. 15

22 programming language. Within MRG, libraries of reusable tactics are provided (see [15] for more details) so that the application does not have to be developed from scratch. 4 The navigation system Task of the navigation system is (i) to devise a plan that (if successfully executed) should make the mobile platform reach the desired location (ii) to interact with the vision navigation module to have the plan executed, (iii) to monitor execution and (iv) to recover from failure. This approach allows to achieve simultaneously both the capability of immediately responding to most of the arising unpredictable situations (e.g. the mobile platform stops if a person abruptly appears in front of it) and the ability of providing high level navigation functionalities to the central reasoner. The main component of the navigation system is the navigation planner which plans with dierent modalities the route of the mobile platform by exploiting an internal map of the building (see section 4.1). The execution of plans is carried out by exploiting the functionalities provided by the vision navigation module [10] which executes real word actions and acquires information from the environment by using several types of sensors. A bidirectional interface (the navigation interface [27]) manages the interaction between the navigation planner and the vision navigation module. An example of information sent to the navigation planner is the success or failure during execution. 4.1 The map The map [28, 29] is the data base encoding the knowledge about the navigation domain. Such information is exploited by the navigation system during the plan formation activity. The main problem is to determine the relevant information needed by the navigation system about the domain. 14

23 This information can be acquired from the world during the problem solving activity by deferring the plan formation phase [26, 18, 21]. It is thus possible to perform deferred planning, interleaving plan formation and execution in order to acquire information at execution time, as shown by the following example. (DEFTAC t-deferred-goto (desk-loc) (THEN (t-exec-nav-plan (t-plan-shortest-route (t-door-loc-of (t-office-of desk-loc)))) (IF (t-door-open?) (t-exec-nav-plan (t-plan-shortest-route desk-loc)) (THEN (t-open-door) (t-exec-nav-plan (t-plan-shortest-route desk-loc)))))) The tactic t-deferred-goto is a strategy to make the mobile platform to reach a desk location in an oce desk-loc. Rather than planning to go to the desk location, the tactic plans to move the mobile platform to the door of the oce where the desk is located ((t-door-loc-of (t-office-of desk-loc))). The generation of the plan to reach the desk location (t-exec-nav-plan (t-plan-shortest-path)) is then deferred until MRG knows whether the door of the oce is open t-door-open? or not. Notice that the apparent similarity of MRG tactics with conventional programming languages (e.g. LISP) is only syntactical. First of all, the building blocks of the MRG language, primitive tactics, represent basic planning activities. Second, we have circumscribed the constructs of a programming language that are needed for controlling planner activities. For instance ORELSE allows us to handle failure. Furthermore, MRG provides an architecture to manage tactics, to relate tactics to goals and facts and to activate tactics to respond to goals and facts. These mechanisms are not provided by general purpose programming languages. Finally, and perhaps most importantly for the practical use of MRG, the level of abstraction is much higher than in a general purpose 13

24 tactic can also be very complex: for instance it could call a full blown classical planner. The tactic t-plan-shortest-route, shown in section 3, is a plan-for tactic. A dened plan-for tactic is built from primitive ones. Its denition is accessible by the user and is modiable according to the application domain. The tactic t-goto-ask-user, shown in section 3, is a dened plan-for tactic. Plan execution. Plan execution activities are represented by exec tactics whose argument has type tactic. When interpreted by the MRG interpreter an exec tactic executes the argument tactic. In case of success it returns the result of the execution, otherwise it fails. The tactic t-exec-nav-plan, shown in section 3, is an exec tactic. Plan formation + execution. The global task of MRG is to carry out the functionalities of subreasoners and interfaces in order to achieve some dened purpose. This task is represented in MRG by the solve tactics, whose argument is of the type goal. Simple solve tactics are compositions of plan-for and exec tactics, where plan formation is followed by plan execution. This is what usually happens in classical planners (as for instance in [17, 23, 24, 25, 3]). For instance: (DEFTAC t-classic-goto (position) (t-exec-nav-plan (t-plan-shortest-route position))) where t-exec-nav-plan and t-plan-shortest-route are an execution and a plan formation tactic respectively. Note that the two fundamental planning steps, plan formation and plan execution, are represented explicitly and kept separated by the t-plan-shortest-route and the t-exec-nav-plan tactics. Given the ability of performing exible planning, MRG can express the capability of exploring not only the information contained in the model of the world described in the map and in the knowledge base but also the information provided by the real world. 12

25 (LET ((plan (t-plan-shortest-route location))) (IF (t-user-interface-confirm plan) (t-exec-nav-plan plan) (t-user-interface-inform "the plan has not been executed")))) The tactic t-goto-ask-user, dened by the DEFTAC construct, plans for a route where the mobile platform has to be sent (t-plan-shortest-route) by invoking the navigation planner, records the route in the variable plan, asks the user whether the path plan is satisfactory (t-user-interface-confirm) for instance by calling the speech module to interact by voice. Only if the answer is positive, MRG actually executes the plan to move the mobile platform along the path (t-exec-nav-plan) calling the vision navigation module; otherwise the failure is notied by the graphic interface module (t-user-interface-inform). 3.2 Flexible planning This section presents how plan formation and execution can be exibly represented, combined and interleaved within MRG. As the MRG language is typed (an example of type being goal), tactics performing plan formation and execution phases can be classied as follows according to their type. Plan formation. In MRG, plan formation activities are represented by tactics whose argument is of type goal and whose return value is of type tactic. We call these kinds of tactics plan-for tactics. There are several plan-for tactics in the MRG library. They can be either primitive or dened tactics. A primitive plan-for tactic represents a xed process searching over tactics to nd a solution to the given goal. The simplest plan-for tactic we can think of is a function that, given a goal, returns the corresponding tactic in a goal-tactic table (this idea resembles in some way the reactive planning approach [21, 22, 4, 5]). Of course, a plan-for 11

26 ORELSE (ORELSE t 1 t 2 ) tries t 1 and in case of failure then tries t 2. Hence ORELSE is the control construct for the management of failure. ORELSE is, in a certain sense, the most important tactical. Tactics built without ORELSE fail any time the execution of a primitive tactic fails. This is completely in disagreement with the intuition that after the failure of an action, some alternatives should be tried, and the overall process might succeed anyway. Accordingly, (ORELSE t 1 t 2 ) may be thought of as a retrial point: if t 1 fails, then t 2 is tried. Since t 1 and t 2 can represent the internal activities of the planner (e.g. plan formation and plan execution, see section 3.2), then ORELSE can specify dierent kinds of failure recoveries. The following tactic plans a route of the mobile platform (t-plan-shortest- -route) and, in case of planning failure, updates the map (t-set-arc-inaccessible) and looks for a new plan: (ORELSE (t-plan-shortest-route location) (THEN (t-set-arc-inaccessible) (t-plan-shortest-route location))) The t 1 t 2 tactical means functional composition. The tactical is necessary in order to use tactics as arguments of other tactics, as in (t-exec-nav-plan (t-plan-shortest-route location)). The language to describe strategies as it has been dened so far always forces us to refer to combinations of primitive tactics; the system also features a denition mechanism (through the construct DEFTAC) to introduce new tactic identiers. These tactics are then expanded, according to their denition, at execution time. Consider the problem of sending a mobile platform to a given place in a building (location) only if the operator agrees on the path generated by the planner. A dened tactic which can perform this function is the following: (DEFTAC t-goto-ask-user (location) 10

27 THEN The (THEN t 1 : : : tn) tactical builds sequential tactics. The argument tactics are intended to be executed in the given sequential order. If one of ti fails, none of the following tactics will be executed and the overall tactic fails. The following tactic makes the mobile platform to move along the path ((t-exec-nav-plan plan)) and then tell the user that the navigation has phase is terminated (t- -user-interface-inform): (THEN (t-exec-nav-plan plan) (t-user-interface-inform "the navigation is finished")) LET The (LET ((var t 1 )) t 2 ) tactical is used to evaluate t 1 and to store its return value in var which can be subsequently used by t 2. A LET tactic fails if and only if either t 1 or t 2 fails. The following tactic makes the system to plan a route, (t- -plan-shortest-route), to store the route in the variable plan, to communicate the user the plan (t-user-interface-inform), and nally to execute the plan (t-exec-nav-plan): (LET ((plan (t-plan-shortest-route location))) (THEN (t-user-interface-inform plan) (t-exec-nav-plan plan))) IF The IF tactical builds conditional tactics. In (IF t 1 t 2 t 3 ) t 1 is executed rst. If it succeeds, t 2 or t 3 are executed according to the result. A conditional tactic fails if and only if one of the executed tactics fails. Via the IF tactical it is possible, for example, to ask the user whether a given plan is right before executing: (IF (t-user-interface-confirm plan) (t-exec-nav-plan plan) (t-user-interface-inform "the plan has not been executed")) 9

28 integrate various planning techniques, makes it easy to add new modules, and widens the range of applicability of MRG to domains where dierent strategies are better suited. 3.1 The tactical language Tactics are classied in primitive tactics and compound tactics. Primitive tactics represent atomic actions executable by the lower level modules. The association among a primitive tactic and the corresponding action is stored in a data structure called tactic-action pair. For instance the primitive tactics t-set- -arc-inaccessible, t-plan-shortest-route and t-exec-nav-plan are associated to the functionalities of the navigation planner set-arc-inaccessible, plan-shortest- -route and the navigation interface exec-nav-plan respectively. Other primitive tactics are t-user-interface-confirm and t-user-interface-inform. Such primitive tactics are associated to the functionalities user-interface-confirm and user- -interface-inform of the I/O manager. When a primitive tactic is interpreted, the corresponding actions is executed: according to their success or failure the primitive tactic is said to succeed or to fail. Compound tactics are built starting from the primitive ones by means of a set of special control constructs called tacticals. A compound tactic represents a complex plan which may be also a planning strategy controlling the execution of dierent activities. By composing tactics various planning phenomena can be reproduced. For instance, interleaving plan formation and plan execution, global or local replanning, ad hoc strategies execution and reaction to environmental changes. The tacticals implemented in MRG are THEN, LET, IF, ORELSE and (i.e. composition). We describe briey the interpretation of the tacticals (in the following t 1, t 2, t 3 are tactics, var a variable): 8

29 information, informs the robot about an unexpected and dangerous event (e.g. a re), and the goal of the robot is to execute some (simple) safety task. In this case, we do not want the reasoner to activate a complex plan formation task to nd a plan. There is not actually enough time for this. We would like the reasoner to skip the plan formation phase and switch directly to the execution of a precompiled plan as quickly as possible. This control mechanism (i.e. no plan formation phase, but quick response to environmental events) resembles in some way most of the embedded planners control mechanisms (see for instance [19, 20]). The exibility needed to combine plan formation and execution in the most suitable way is also required for failure handling. Classical planners (see for instance [3]), when failure occurs at execution time, always replan, that is switch the control to the plan formation phase. However, in the applications we want MRG to support, failures may occur with dierent features, e.g. may be very dicult to predict and prevent, may not allow to spend time in replanning, or may require a reasoning phase about the causes of failure in order to devise the most suitable reaction. The development of MRG was driven by the requirement of exibility. We did not focus on the classical problems of planning, e.g. how to represent actions by means of preconditions and postconditions over their applicability, which particular algorithms can be used to perform the plan formation search, on whether to use a state space search or a partial plan search. On the contrary we focused on how the dierent basic plan formation mechanisms provided by the sub-reasoners could be combined with the execution phase and how to deal with failures that require dierent kinds of recoveries. This was achieved by providing MRG with a programming language where actions, solution strategies, plan formation and execution are uniformly represented as expressions called tactics. The tactic language is provided with a variety of control mechanisms which: (i) allow to compose simpler plans yielding complex ones, (ii) make natural the capturing and reaction to failures and (iii) simplify the interchange between plan formation and plan execution phase. This gives MRG the ability to combine and 7

30 of each module is independent of the way other modules have been realized, provided that the interface is the same. 3 The central reasoner Task of the central reasoner is to plan, coordinate and activate the functionalities of the navigation planner and of the I/O manager in order to achieve high level objectives. Given a goal, the central reasoner, by exploiting the knowledge it has about the capabilities of the subreasoners, decides a combination of actions (i.e. a plan) that when executed activate and control the sub-reasoners to achieve the goal. It is crucial for the reasoner to perform exibly these tasks, mixing the phases of plan formation and execution in suitable ways. Consider for instance the following examples. The MAIA robot needs to look for a person in IRST that is known to work usually at his oce. In this case a good strategy could be to plan everything ahead (i.e. to generate a plan combining navigation and interaction activities) and execute the plan. In case of failure, the reasoner can replan for a new course of actions. This sequence of plan formation followed by plan execution and, in case of failure, by replanning, is very similar to the usual classical planning control mechanism (see for instance [17, 3]). Let us suppose now that the person to look for is known to work either in the IRST lab or at his oce. In this case a good strategy could be to plan to acquire additional information (e.g. plan the path to a close secretary oce, execute the navigation and interact to actually get information), plan for moving to the place suggested by the secretary, and nally execute this plan to actually nd the person. In this case the central reasoner cannot generate the whole plan in advance, as it depends on the information acquired after execution is activated. This is an example of the well known technique of deferred planning (see for instance [18]). Notice how, given a goal, the same plan formation and execution phases are combined in a dierent way with respect to the previous example. Consider nally the case in which the secretary, rather than providing the expected 6

31 The I/O manager is devoted to the management of the interaction modules (i.e. the speech module and the graphic module). It coordinates the interaction with people by choosing the best communication modality with respect to the current situation and invoking the most appropriated peripheral module. The navigation planner, exploiting the functionalities provided by the navigation module and the information stored in the map, provides a wide spectrum of navigation capabilities being able both to react to external events and to deal with navigation failures. This organization reects the classication of the activities in: (i) interaction activities processing the requests coming from the user and yielding (the representation of) corresponding goals to be solved by the system, and (ii) navigation activities generating a navigation plan that, if successfully executed by the vision navigation module, leads the robot in the desired place. The obvious advantage of such a structure, is that \low level" activities/decisions (e.g. how to communicate to the user where is a person, which is the best route according to dierent input parameters) are directly solved by the appropriate sub-reasoner. Moreover, according to such a schema, it is possible to have each reasoner running for a dierent goal simultaneously, e.g. the I/O manager reasoning about the interaction with the user while MAIA is navigating. The central reasoner [15, 16], which is on the top of the architecture, carries on strategical activities such as the activation, coordination and control of the subreasoners. Given a goal, the central reasoner chooses a plan and executes it. The execution of the plan may require the activation of one (or both) of the subreasoners, but direct access to the peripheral modules (via the interfaces) is retained to keep the hierarchical organization. Notice that the proposed architecture, besides the already quoted advantages, has the fundamental and practical advantage of forcing the enucleation of the set of (primitives) functionalities each module has to guarantee to the upper ones, i.e. of the interfaces between modules. In fact, once this has been done, the development and maintainment 5

32 2 The multilevel architecture Task of MRG is to manage and coordinate the functionalities provided by a set of peripheral modules which are external to MRG and carry out the interaction with the outside world. They are: the vision navigation module [10]: it controls the navigation of the mobile platform according to the plan generated by the navigation planner. It is able to process data from a set of cameras and sonars in order to drive the mobile platform avoiding local obstacles; the speech module [11]: it is responsible of the interaction with people by performing speech recognition and synshesis; the graphic module [12]: it allows the operator to interact with the system by means of a graphical interface displaying the map and the movements of the mobile platform. The internal organization of MRG is given by the multilevel architecture depicted in gure 2. At the bottom of the architecture there is a set of interface modules. Their role is to control and synchronize the ow of information exchanged between the upper modules and the peripheral modules performing data conversion when needed. From a structural point of view they play the fundamental role of abstracting upper modules from the way the lower modules have been realized. Immediately on top of the interface modules two subreasoners, the I/O manager and the navigation planner [13, 14] group and coordinate the activities carried out by the peripheral modules providing a higher level set of functionalities to the central reasoner. Each subreasoner is a special purpose planner dedicated to solve a particular class of problems by controlling the activities of the peripheral modules. More in detail: 4

33 framework where the two approaches can be exibly integrated. Given the functionalities of MRG, and high unpredictability of its application environment, both the reactive and the planning ahead paradigms turn out to be insucient if not exibly integrated. In order to achieve the required level of exibility, therefore, the solution strategies synthesized by each reasoner are expressed in a programming language based on the notion of tactic 1. Within such a language the domain of application is described in terms of goals and actions and both the control mechanisms and the solution strategies can be easily programmed [9]. This gives the capability to dene plans according to the reactive or to the look ahead paradigms, and to dene plans where dierent control strategies (belonging to dierent paradigms) can be exibly intermixed. Finally, MRG allows to control and recover from failures in a exible way. This is achieved by having explicit control constructs for failure handling in MRG plans. This fact provides the capability to recover from failure depending on several factors, such as the particular situation where failure occurs, the kind of failure, the application requirements and the time constraints. In MRG, when failure occurs, it is possible alternatively to replan for a new course of actions (e.g. when there is enough time and reasoning about failure is required), to execute previously generated alternative plans (e.g. when how to recover from failure is known a priori), and to execute ecient and pre-compiled exception handling routines (e.g. when time is critical). The paper is organized as follows. The architecture of MRG is presented in section 2. In section 3 the central reasoner is presented together with the main features of the implementation language. Sections 4 and 5 are a brief description of the navigation system and the interaction system respectively. Some conclusions are given in section 7. 1 The terms tactic and tactical are borrowed from ML [8], a procedural metalanguage for the specication of theorem proving strategies. There actually exist some similarities between the two languages, but there are rather strong conceptual and technical dierences, mainly due to the dierent domains of application. 3