and to hierarchically plan a solution to reduce the search space. .... goal state, a description of the domain and the operators available in such domain.
A System for Hierarchical Planning in Service Mobile Robotics Fulvio Mastrogiovanni, Antonio Sgorbissa, Renato Zaccaria Laboratorium DIST – University of Genova, Italy Abstract. We discuss a planning system which has been especially designed for Service Mobile Robotics applications; the system is able to classify problems (i.e., determining the domain to which a problem belongs and –if possibe– dividing it into subproblems) and to hierarchically plan a solution to reduce the search space. The paper shows that the approach is able to deal efficiently with a significative subset of the tasks that are usually requested from Service Mobile Robots acting in a civilian environment.
1
Introduction
In this paper we discuss a planning system which has been especially designed for Service Mobile Robots, e.g. robots which operate within human populated environments to carry out different tasks such as surveillance of banks and warehouses, transportation of things, escorting people in exhibitions and museums, etc; the main purpose of this research is to enable autonomous mobile robots to plan and execute complex sequences of actions to deal with realistic problems in a realistic civilian environment. Currently, very few existing systems prove to be effective, if we ask robots to autonomously solve complex navigation problems (i.e. problems which require to plan and execute complex activities, such as “use an elevator to move to another floor”, “move boxes from one room to another one”, etc.) rather than just simple ones (such as “move to the goal” and “avoid obstacles”). Moreover, if we require the system to work continuously over long periods of time without performance degradation, we need to consider activities which are required for self-maintenance (e.g. battery recharging) and multiple tasks scheduling, thus complicating even more the set of possible actions that the robot has to consider for successfully carrying out its tasks. Hybrid approaches to mobile robotics were introduced for this purpose: on one side, they provide a solution to deal with the limitations of purely behavior-based approaches, which traditionally do not manage to produce much more than basic “move and grip” behaviors [1]; on the other side, they provide a way to deal with the predicate grounding problem of symbolic planning architectures, for example by defining perceptual and motor schemata [2] which can be efficiently adopted, respectively, to generate predicates from sensorial inputs and motor commands from predicates. Unfortunately, hybrid architectures have the drawbacks of their symbolic component: in particular, it is well known that the computational time required by planning activities dramatically increases with the dimensions of the search space. Several approaches have been proposed in literature to deal with this problem. Casebased planning (together with skeletal planning) [3][4] tries to adapt the current problem to a previously solved one, in order to minimize the computational time required for planning; however, this sometimes leads to sub-optimal plans that have not been specifically designed for the current state of the world. Hierarchical task networks (HTN) can effectively deal with complex plans [5][6], but they are not very robust in the case of re-planning (which is often required in highly dynamic environments); in fact, planning is carried out only at the higher
level, whilst high level operators are mapped onto pre-determined sequences of low-level operators. Planning based upon temporal logics [7] tries to avoid large search spaces by reducing the planning horizon, assuming that -in dynamic environments- a long plan would hardly be executed from the beginning to the end; once again, this can lead to sub-optimal plans. Finally, heuristics (if supported with adequate knowledge of the domain) can dramatically increase the efficiency of a planner [8], e.g. by subdividing a complex task into simpler ones (as a human expert would do): the approach fails in those situations which have not been foreseen by the designer of the heuristics. All these approaches aim at dealing with the planning problem in its general formulation. On the opposite, in the specific scenario of an autonomous mobile robot performing Service Tasks (e.g. navigation, transportation, etc.), we propose a simpler (yet very efficient) system, which allows to classify problems (i.e. determine the domain to which a problem belongs and –if possible- divide it into subproblems) and to hierarchically plan a solution to reduce the search space. Section 2 describes the system architecture; Section 3 describes the Knowledge Representation subsystem which is part of the architecture; Section 4 gives details about the planner; Section 5 shows experimental results. 2
System Architecture
The system is composed of two interacting subsystems: • A Knowledge Representation subsystem based on NeoClassic [9], which stores information and makes inferences about the domain in which the robot operates. • A BlackBox planner [10], which is given problems described in the PDDL formalism and plans sequences of operators in order to solve them. Both the classification subsystem handled by NeoClassic and the BlackBox planner could be easily substituted with different ones performing analogous operations (for example the BlackBox planner could be substituted with another, possibly more efficient planner adopting the same PDDL formalism): our research is more focused on improving the performance of the whole system through the interaction between the two component, rather then on each single component by itself. To achieve this, the two subsystems are handled by a couple of agents A 1 and A 2 within the ETHNOS Multiagent framework (details about ETHNOS and the overall navigation architecture that we implemented on real robots can be found in [11, 12]): • A 1 handles the NeoClassic Knowledge Base: it adds and removes concepts, individuals, descriptions which are required to represent the domain in which the robot operates. When a new problem is inserted in the KB, A 1 publishes a message containing all the information required by A 2 in the PDDL formalism: a description of the the initial and goal state, a description of the domain and the operators available in such domain. • A 2 handles the BlackBox planner: whenever A 2 reads a message published by A 1, it searches for a plan to solve the particular problem it has been given. Finally, the results of this search are written in a new message which is made available to A 1: A 1 will use this information to update the KB. 3
The Knowledge Base
It has been demonstrated that Knowledge Representation systems based on Description Logics guarantee that subsumption and classification procedures are solved in polynomial time with respect to the dimension of the problem space [13]. In particular, NeoClassic [9]
allows to store objects like “concepts”, “individuals” (i.e. concept instances), “roles” (i.e. relations between objects of the domain) etc., and it is able to derive consequences from the stored knowledge; finally, it allows to add and remove information in run-time. However, what makes NeoClassic particularly appealing for real world robotics applications are the so-called “hook functions”: an hook function is a procedural, non symbolic user-defined function which can be activated asynchronously as a consequence of an event (i.e. when a given state has been reached within the knowledge base). Hook functions are particularly useful to interface the KB with standard C programs, such as algorithms for perception and actuation. In our system, NeoClassic handles a KB which can be ideally divided into separate areas representing three kinds of concepts: 1. Objects, 2. Operators and Plan Predicates, 3. Problems and Plans. 3.1 Objects All the objects in the KB - from more general concepts down to individuals - are subsumed by the concept OBJECT. However, the objects to be considered vary depending on the domain that we want to represent. For example, in the scenario of an autonomous mobile robot carrying out navigation tasks within a civilian building, we would consider concepts like PLACE, FLOOR, DOOR, ELEVATOR, OBSTACLE, etc. PLACE would be probably further detailed through the subsumed concepts OFFICE, LAB, CORRIDOR; moving down along the hierarchical tree, we would finally reach leaf concepts, which correspond to physical objects. In the scenario of a robotic manipulator moving blocks in a block-world, we would consider objects such as BLOCK, TABLE, HAND, etc. Consider now the joint scenario in which the mobile robot is equipped with a manipulator: the resulting KB is composed of both navigation and block-world objects, thus increasing the search space for planning. As we consider within the same KB more scenarios (e.g. outdoor navigation), the search space increases even more, by making planning more and more complicate. In order to make easier the access to the KB, we introduce intermediate base concepts (e.g. BW-OBJECT, NAV-OBJECT, etc.): all the objects in a given domain are subsumed by the corresponding base concept. Next, we introduce a particular concept which we call DOMAIN, which on its turn subsumes more specific domains, such as BWDOMAIN and NAV-DOMAIN. In Fig. 1a notice that, among the roles of BW-DOMAIN, is the role bwob, which is filled by instances of the concept BW-OBJECT. By means of this taxonomy, when we consider the concept BW-DOMAIN we can immediately infer all the objects (i.e. all the individual subsumed by BW-OBJECT) which must be considered in that particular domain (obviously, an analogous representation exists for the other domains represented in the KB). Finally notice in Fig. 1b that a similar representation is adopted for the concepts OPERATOR and PLAN-PREDICATE; they subsume the concepts BWOPERATOR, NAV-OPERATOR, BW-PLAN-PRED, NAV-PLAN-PRED, etc., thus allowing to define the operators and the predicates that are available for planning in a specific domain. In the following, we will show in details how the use of the DOMAIN concept can reduce the time required to solve a planning problem. 3.2 Operators and Plan Predicates Operators are concept in the KB defined through the roles pl (precondition list), dl (delete list), and al (add-list). The prototype for the generic concept OPERATOR is shown in Fig.
1b: notice that specific operators (e.g. STACK) are subsumed by OPERATOR through an intermediate concept (BW-OPERATOR) which restrict the set of the actions that can be performed in the BW-DOMAIN. The concept PLAN-PREDICATE is introduced to model predicates which are required to describe the initial and goal state of the system, and the precondition, add, and delete list of each operator. Again, through the intermediate base concept BW-PLANPRED, we have specific predicates for the domain considered, such as ON, HOLDING, CLEAR, ON-TABLE for the BW-DOMAIN. The predicate arguments are modeled through the concept’s roles, i.e. grounding an argument is equivalent to fill a role with an individual. For example, the roles X and Y of the STACK operator in Fig. 1b specify the blocks which are affected by the operator (i.e. corresponds to the argument X and Y of the predicate Stack(X,Y) in a STRIPS-like formalism). pl
NAVDOMAIN
PLANPREDICATE
OPERAT OR dl
DOMAIN
al
BWDOMAIN
NAVOPERAT OR
NAVOPERAT OR
op
NAVPLANPRED
pl BWPLANPRED
dl BWOPERAT OR
bwop
al
OPERAT OR holding
pl
pp BWOPERAT OR
ob
ST ACK
bwpp
dl
clear
bwob al
NAVOBJECT
hand empty
Y
OBJECT
b BWOBJECT
X
BLOCK
on
is
PROBLEM
PLANPREDICAT E
gs
BWPLANPRED
PLANPREDICAT E
DOMAIN
d
ON NAVPROBLEM
BWPLANPRED
is
CLEAR
BWDOMAIN
gs NAVPLANPRED
a
BWPROBLEM
c
d
Fig. 1 a) OBJECTs & DOMAINs b) OPERATORs & PLAN-PREDICATEs c) PROBLEMs & PLANs.
3.3. Problems and Plans In order to formalize a particular problem, the system uses the PROBLEM concept. As usual, a problem is defined by an initial and a goal state, each defined as a conjunction of predicates: this is done in our KB through the roles is (initial-state) and gs (goal-state), which relate the concept PROBLEM with the concept PLAN-PREDICATE (Fig. 1c). Finally, the role d (domain) puts the problem in relation to the corresponding domain, thus allowing to consider problems which are meaningful only in a specific domain. In Fig. 2, an instance of BW-PROBLEM is created and inserted in the KB. initial state
goal state C B
A
A B C
(createIndividual a-typical-block-world-problem (and BW-PROBLEM (fills initial-state clear-b clear-c c-on-a hand-empty ontable-a ontable-b) (fills goal-state b-on-c a-on-b) (fills domain block-world)))
Fig. 2 A BW-PROBLEM is inserted in the KB.
Notice that clear-b, clear-c, etc. are instances of the concept BW-PLAN-PRED, subsumed by PLAN-PREDICATE. Once a solution (or no solution) has been found, a PLAN individual is stored in the KB; a PLAN is defined through the initial and goal state of the corresponding PROBLEM and the OPERATORs which solve it (possibly an empty list). This avoids re-planning if the execution of the same plan should be necessary in future. 4
Plan Generation
As anticipated in Section 2, two ETHNOS agents A 1 and A 2 cooperate in order to find a solution to given problems. I.e., when a new PROBLEM individual is inserted in the KB: 1. A 1 builds relevant PLAN-PREDICATE individuals to describe the initial and goal state. These predicates can obviously belong to different DOMAINs. 2. A 1 understands whether the problem requires to consider concepts belonging to different domains (go to step 3) or it can be solved within a specific domain (go to step 6). Notice that the problem in Fig. 2 can be solved within the BW-DOMAIN. 3. A 1 automatically generates a domain-independent problem in the PDDL formalism (using high level concepts such as OBJECT, OPERATOR, etc.). 4. A 2 searches a high level solution; when a solution (or no solution) is found, it is returned to A 1 which inserts a PLAN individual in the KB. 5. For each OPERATOR that solves the generic problem, A 1 generates a domaindependent problem (i.e. a NAV-PROBLEM in the NAV-DOMAIN, a BW-PROBLEM in the BW-DOMAIN, etc.). 6. For each domain-dependent problem A 2 searches a solution by using the concepts available in the domain (i.e. NAV-OPERATORs, NAV-OBJECTs, NAV-PLANPREDICATEs in the NAV-DOMAIN, etc.). When a solution (or no solution) is found, it is returned to A 1 , which updates the KB by adding instances of the concept PLAN. The motivation for hierarchical decomposing a problem is straightforward: it helps to reduce the time required to solve it. However, it is not always a trivial task for A 1 to automatically generate a high-level, domain-independent problem starting from the original one: in our case, the BW-DOMAIN and the NAV-DOMAIN are not really disjointed, in the sense that a BW-PROBLEM often requires BW-OBJECTs to be moved to one place to another, thus requiring to automatically instantiate and solve a NAV-PROBLEM. (e.g. when BW-BLOCKs – i.e. BW-OBJECTs- are located in different NAV-PLACEs – i.e. NAVOBJECTSs). That is, we have to face a problem which is typical of hierarchical planning system: when the planner is given an initial and a final configuration, we want a domainindependent PROBLEM to be instantiated and a domain-independent PLAN to be found which contains only the right sequence of high level, domain-independent OPERATORs (e.g., navigate place1 place2, load block a, navigate place2 place3, arrange blocks), postponing domain-dependent planning to a subsequent phase. To achieve this, the domain-independent PLAN-PREDICATE IS-IN is introduced, with the purpose of creating a link between the BW and the NAV-DOMAIN: in fact, the two arguments of IS-IN belong to different DOMAINs, and allow to specify the NAV-PLACE in which each BW-BLOCK is located. Moreover, the following high-level OPERATORs are available for planning: NAVIGATE, LOAD, UNLOAD, ARRANGE BLOCKS. In particular, LOAD and UNLOAD are responsible for deleting and adding IS-IN predicates in order to reflect variations in the state of the involved
BW-OBJECT. Details about these high level OPERATORs are given in Fig. 3 (in the PDDL formalism used by the planner): in their precondition, add and delete lists the IS-IN predicate can be noticed. The automatic generation of the domain-independent problem is shown in Fig. 4a: domain-independent PLAN-PREDICATEs (bold font) are left unaltered, while domaindependent ones are combined into a new domain-independent PLAN-PREDICATE individual. (:action navigate (:action arrange-blocks-0 :parameters :parameters (?r - MOBILE-ROBOT (?r - MOBILE-ROBOT ?p1 - PLACE ?p - PLACE) ?p2 - PLACE) :precondition :precondition (and (gripper-free ?r) (and (is-in ?r ?p1)) (is-in ?r ?p) :effect (is-in block-a ?p) (and (not (is-in ?r ?p1)) (is-in block-b ?p) (is-in ?r ?p2))) (not (problem-solved ?p block-conf-h-tv-hall))) :effect (problem-solved ?p block-conf-h-tv-hall)))
(:action load :parameters (?r - MOBILE-ROBOT ?b - BLOCK ?p - PLACE) :precondition (and (is-in ?r ?p) (is-in ?b ?p) (gripper-free ?r)) :effect (and (not (gripper-free ?r)) (gripper-holding ?r ?b) (not (is-in ?b ?p))))
(:action unload :parameters (?r - MOBILE-ROBOT ?b - BLOCK ?p - PLACE) :precondition (and (is-in ?r ?p) (gripper-holding ?r ?b)) :effect (and (not (gripper-holding ?r ?b)) (is-in ?b ?p) (gripper-free ?r)))
Fig. 3 High level ACTIONs definition in the PDDL formalism. b
a Given Problem
Goal state
Start State is-in staffetta entrance gripper-free staffetta is-in block-a carpet-room is-in block-b tv-hall
Goal State is-in staffetta tv-hall gripper-free staffetta is-in block-a tv-hall is-in block-b tv-hall on-table block-a on block-a block-b clear block-b
Goal State is-in staffetta tv-hall gripper-free staffetta is-in block-a tv-hall is-in block-b tv-hall
not problem-solved tv-hall block-conf-tv-hall
Little-room
C D
Domain Independent Problem (Automatically Generated)
Start State is-in staffetta entrance gripper-free staffetta is-in block-a carpet-room is-in block-b tv-hall on-table block-a on-table block-b clear block-a clear block-b
Casalino-office
A
C
2nd Zaccaria-office Braccini-office
Initial state
Elevator
Goal state
A B
problem-solved tv-hall block-conf-tv-hall
D
B
3rd Initial state
Vernazza-office
Elevator
Fig. 4 a) Generation of a domain-independent PROBLEM; b) A problem at DIST, University of Genova.
Finally notice that, in the case of a mobile robotic system, similar considerations still hold when new DOMAINs (and the corresponding OBJECTs, OPERATORs and PLANPREDICATEs) are added to the KB. 5
Experimental Results
We performed many experiments in simulation: the robot is asked to carry out various navigation/manipulation tasks within our Department building (DIST), composed of three floors connected by an elevator. The map of the building (i.e. the topological connections between PLACEs, CORRIDORs, FLOORs, etc.) is inserted into the KB during the initialization phase (i.e., it is not part of a specific problem). After initialization, the robot is ready to receive missions with multiple goals, as shown in Fig. 4b: • Move from the little room to Prof. Zaccaria Office. • Change the arrangement of the boxes from their initial configuration to the final one (indicated with a circle in the figure). Notice that, in the start configuration, the boxes are distributed in different areas of the building; thus the robot has to perform both navigation and manipulation actions in order to solve the problem. To achieve this, the system first looks for a domain independent
solution, thus producing a sequence of high-level, domain-independent OPERATORs; next, each of them originates a sub-problem to be solved within a specific domain. In this particular case, our simulator returns the PLANs shown in Fig. 5; Experiments with a real robot within a oversimplified scenario have been carried out as well. Fig. 6 shows the maze in which the robot operates: walls are built with scotchtape stripes on the floor, box marked with A,B,C,D are manipulated by the robot only virtually (i.e., when the robot wants to rearrange boxes it asks for human intervention). However, plan generation and execution, even if carried out in a toy world, allow to evaluate the behavior of the ETHNOS multiagent system when agents A 1 and A 2 are integrated in the navigation architecture. A more realistic implementation on-board of our mobile robot Staffetta1 [12, 14] is currently work-in-progress.
3
hl
4 1 5 2
Fig. 5 Domain independent plan (hl); Domain-dependent plans generated from OPERATORs 1 to 5. put down box D
pickup box D
Fig. 6 Experiments in a toy world.
Finally, we compared the time required by BlackBox to find a solution when the problem is hierarchically decomposed (as in our system) versus the time required with no hierarchic decomposition. As we expected (Fig. 7), as the complexity of the environment (i.e. the number of OBJECTs, OPERATORs and PLAN-PREDICATEs available) and the number of steps required to solve the problem increases, the benefits of the hierarchical approach become more and more evident, being able to find a solution in reasonable time even when the problem becomes intractable for the non-hierarchical BlackBox planner. 1
Staffetta is commercialized by the spin-off company Genova Robot (www.genovarobot.com)
6
Conclusions
In this paper we describe a system which solves complex planning problems within the Service Mobile Robotics scenario. In particular, we focused on a couple of cooperating agents dedicated, respectively, to problem classification and hierarchical planning. Currently, the system has been tested in simulation and with a real robot in an oversimplified environment: however, these agents are currently being integrated in the overall navigation architecture of the Service Mobile Robot Staffetta (which is widely described in [12, 14]). Move two BLOCKs from PLACE_1 to PLACE_2 and arrange them
Move two BLOCKs from PLACE_1 to PLACE_2 16000 12000 10000
Non-hierarchical Hierarchical
8000 6000 4000
Times (ms)
Times (ms)
14000
2000 0 12
20
4500 4000 3500 3000 2500 2000 1500 1000 500 0
Non-hierarchical Hierarchical
12
28
20
28
N. of Actions
N. of Actions
Move a BLOCK from PLACE_1 to PLACE_3 Move a BLOCK from PLACE_2 to PLACE_3
Move a BLOCK from PLACE_1 to PLACE_4 Move a BLOCK from PLACE_2 to PLACE_4 Move a BLOCK from PLACE_3 to PLACE_4
1000 6000
600
Non-hierarchical
400
Hierarchical
200
Times (ms)
Times (ms)
800
5000 4000
Non-hierarchical
3000
Hierarchical
2000 1000
0
0
12
20 N. of Actions
14
36 N. of Actions
Fig. 7 Hierarchical Vs Non-hierarchical planning.
References [1] Brooks, R. A Robust Layered Control System for a mobile robot, IEEE J. of Robotics and Automation, RA-2 l, 1986. [2] R.C. Arkin, Motor Schema-Based Mobile Robot Navigation, International Journal of Robotics Research, Vol. 8, No. 4, 1989, pp. 92-112. [3] Kristian J. Hammond, Case-based Planning: An Integrated Theory of Planning, Learning and Memory, PhD thesis, Yale University, 1986 [4] Manuela M.Veloso, Merge Strategies for Multiple Case Plan Replay, in Proceedings on ICCBR97, 1997 [5] K. Erol, J. Hendler, and D. S. Nau, UMCP: a sound and complete procedure for hierarchical task-network planning, in Proceedings of the International Conference on AI Planning Systems (AIPS), June 1994 [6] A. Tate, Generating project networks, IJCAI-1977. Reprinted in “Readings in Planning”, James Allen, James Hendler and Austin Tate, eds., Morgan Kaufmann, 1990 [7] Bacchus and Kabanza, Planning for Temporally Extended Goals, in Proceedings of the Thirteenth National Conference on Artificial Intelligence (AAAI-96), 1996 [8] B. Bonet and H.Geffner, Planning As Heuristic Search, in Artificial Intelligence 129, 2001 [9] A. Borgida, R.J. Branchman, D. L. McGuinness, L. A. Resnick, CLASSIC: a structural data model for objects. Proc. 1989 ACM SIGMOD International Conference on Management of Data, 59-67, 1989. [10] Henry Kautz and Bart Selman, Unifying SAT-based and Graph-based Planning. Proc. IJCAI-99, Stockholm. [11] Piaggio, M., Sgorbissa, A., Zaccaria, R., A Programming Environment for Real Time Control of Distributed Multiple Robotic Systems, Advanced Robotics, Vol. 14, N.1, VSP Publisher, 2000. [12] Piaggio, M., Sgorbissa, A., Real-Time Motion Planning in Autonomous Vehicles: A Hybrid Approach, Lecture Notes in Artificial Intelligence, Vol. 1792, Pag. 368-379, Springer-Verlag, 1999. [13] H. J. Levesque and R. J. Branchman. Expressiveness and tractability in Knowledge Representation and Reasonong. Computational Intelligence, 3(2): 78 -- 93, 1987. [14] Miozzo, M., Scalzo, A., Sgorbissa, A., Zaccaria, R. Autonomous Robots and Intelligent Devices as an Ecosystem, International Symposium on Robotics and Automation, September 2002, Toluca, Mexico.
