Encoding Planning Constraints into Partial Order Planning Domains M. Baioletti, S. Marcugini, A. Milani
Dipartimento di Matematica ed Informatica Universita di Perugia Via Vanvitelli 06100 Perugia { Italy E-mail: fmarco,gino,
[email protected]
Abstract This paper presents a technique for encoding the representation of a constrained planning problem through the generation of an equivalent unconstrained planning problem. In many real situations the initial state/goals characterization of a planning problem is not satisfactory, this motivates the notion of a constrained planning problem, i.e. a planning problem for which the user speci es additional constraints on the problem solution in order to: give a limit to the length of the solution plan, use or avoid speci c action instances, use particular strategies in adding steps or precedence constraints to the plan, reach some intermediate states. A common way to implement constrained planning is modifying the existing planner in order to take into account of the user additional constraints. In this paper we present a planner independent approach, which operates on the problem and constraints representation instead of modifying the planning algorithm. A planning constraint description language (PCDL) is therefore introduced. It is shown that a signi cant subset of PCDL can be encoded by modifying (domain preprocessing phase) the planning domain and goals. The original problem can then be solved by submitting the modi ed problem to the planner. The solutions to the modi ed problem de ned by the new domain correspond (solution postprocessing phase) to the solutions of the original constrained problem. A signi cant result is that domain preprocessing phase has a linear time/space cost in the domain and additional constraints dimensions, and the solution postprocessing phase has also linear cost on the solution length. A the-
oretical consequence of the equivalence result is that representation of constraints and strategies does not require a planning model which is more powerful than an ordinary partial order planning.
1 Introduction Planning problems have been widely characterized in terms of end goals or goals of attainment: end goals are speci ed by stating the conditions that should hold in the nal state, after the execution of the plan [9]. Often solution plans that simply achieve end goals are unsatisfactory since real user have more complex goals. Examples of these non end goals or extended goals are: goals of maintaining (or preventing from) some conditions throughout plan execution (e.g. the power must be maintained on); goals of having sequence of activities in the plan (e.g. I want a plan for calling the bank prior to returning home); more complex attainment goals, such as requiring one or more intermediate states to be reached (e.g. a roundtrip goal from Florence to Rome requires the intermediate attainment goal of being in Florence); goal of having temporal precedences among activities or attainment goals (e.g. be in Florence, then go to restaurant); goals of having certain codesignation constraints among activities (e.g. I want to come back from Florence with the same car I used to go there). In addition the user can require that the nal plan veri es some strategies or eciency criteria. The solution should be reached using (or avoiding) certain domain operators (i.e. I want to take a plane but I do not want to build one) or the plan must verify conditions on plan length (e.g. prefer shorter plans), actions duration, plan cost or plan utility (e.g. obtain a solution that verify a minimum/maximum interval of duration/cost/utility). The problem of specifying non end goals and build-
ing solution plans for them has been faced by di erent planning models based on languages able to express properties of sequences of state or events. In hierarchical task planning (HTN) [15], it is possible to specify activities goals (do goals) and decompositions (perform goals), while other models allow complex speci cation of activities (for instance see [19],[13],[10]). UCPOP [20] allows the user to specify some other kinds of planning constraints, like axioms and safety constraints. An axiom is a domain law, i.e. an implication between facts, like \if a block A is on a block B, then B is above A". A safety constraint is a requirement that a given condition must not made true during the whole plan, like \don't close the door", although this condition is allowed to be true from the initial state, i.e. in our example the door can even be closed from the beginning, the important is that none must close it. Unfortunately the implementations are scarce for some models, some other models sacri ce generality for ef ciency (i.e. in the case of HTN) or have a di erent focus (i.e. interaction{coordination versus planning in multiagent models). Our work uses a di erent approach by representing the extended goals inside the classical model, and considering all the non end goals as constraints on the nal plan. This point of view is rather di erent to other uses of constraints in planning, as in Tate [19], where plans are seen as constrained objects, or in Ste k [18], whose planning system, MOLGEN, is mainly based on the activity of constraints posting. The main contribution of our work is showing that planning with constraints described in PCL-1, a language for de ning planning constraints which will be introduced later, is equivalent to ordinary planning through a domain transformation. This result shows that instead of building up a new planning algorithm for solving a constrained problem, we can embed the problem constraints within a classical domain: from the constrained problem domain an equivalent classical problem domain is generated which contains only end goals. The advantage is that the equivalent problem can be solved by a classical planner, making also possible to exploit the eciency of certain recent fast implementations for the classical model (GRAPHPLAN [4], SATPLAN [11] etc.). Moreover since the approach is not bound to a particular planner implementation, new kind of constraints can be added without any modi cation in the planning algorithm.
In order to force the search space to produce plans which veri es the extended constraints, some dummy elements are introduced into the domain (i.e. dummy operators, initial facts and goals) and since the equivalent problem and its solutions will contain these dummy elements, dummy operators are to be removed in order to produce a solution to the original constrained problem through a solution decoding phase. A remarkable result is that constraint coding and equivalent solution decoding are very ecient, being their complexity linear in time and space. In the following section we introduce a planning constraint description language (PCDL) for specifying extended constraints. In section 3 we characterize a signi cant subset of PCDL which can be embedded in classical domain. In section 4 the encoding rules are introduced. Expressivity, implementation issues and a discussion about eciency of encoding/decoding phases conclude the paper.
2 Reference Planning Model and the constraints formalism PCDL We shall refer to a very general planning formalism by which we describe a planning problem and its solutions. A problem P is a triple (I ; A; G ), where I is the description of the initial states, G is the goals set and A is the operators set. An operator is characterized by a name, the lists of parameters, preconditions and e ects. A partial plan for a given problem P = (I ; A; G ), is a triple (S ; T ; B) where S is the set of plan steps, that is instances of operators in A. An instance is de ned by a name of an existing operator a of A and a list of parameters, obtained by renaming the parameters of a with new names. T is partial temporal order relation on the plan steps in S , B is the codesignation/non codesignation relation on the variables present in the plan steps. A solution is a partial plan (S ; T ; B) such that it satis es the goals achievement constraint, that is the goals have to be true in the nal situation, and the executability constraint, that is each step s in S has to be executable (i.e. its preconditions are true) in the situation before its execution. We extend the classical planning model by allowing the user to specify some planning constraints described
with a reference language, called PCDL (for Planning Constraints Description Language). A constrained planning problem P is a quadruple (I ; A; G ; C ), where I , G and A have the same meaning as in the unconstrained case, and C is a PCDL constraint. A solution for a constrained problem P is a partial plan such that solves the unconstrained version of P and satis es C . A constraint in PCDL is formulated by means of a formula, which can be either an atomic formula or a combination of formulas obtained using the following logical connectives and quanti ers: (8s) , (9s) , ^ , _ , , : , #(s : ) n, #(s : ) n. The quanti ers are meant to vary over the plan steps, n is an integer and ; are formulae. #(s : ) n is true if and only if the number of steps s for which holds does not exceed n and the meaning of #(s : ) n is similar. An atomic formula can be one of these predicates: s = s , s s , trueAfter(s; p), t = t , t 2 t where s and s are plan steps, is the precedence relation between steps, o is an operator, p is a proposition and t and t are terms. We will use the usual notation s 6= s for :(s = s ) t 6= t for :(t = t ). The predicate trueAfter(s; p) is true if and only if p is true after the execution of step s. The terms are: name(s), value(s; v), parms(s), precond(s), e ects(s). Given a step s, the function name(s) returns the name of the operator of which s is an instance, and value(s; v) returns the value bound to the variable v of s. parms(s), precond(s) and e ects(s) return respectively the set of parameters, preconditions and e ects of s. PCDL is rich enough to express many useful constraints. For instance a presence constraint, i.e. a given action a is to be used, like \use the action y to, i.e. y at least once", can be expressed as (9s)(name(s) = y to)
A precedence constraint, i.e. some action a is to be executed before some other action b, like \knock the door before opening the door", can be expressed as
A safety constraint, i.e. some condition p must be true through the plan, like \do not close the door", can be expressed as :(9s)(door closed 2 e ects(s))
AT-MOST-TIMES(n; a) (#(s : name(s) = a) n)
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
(8s)(name(s) = open door (9s )(name(s ) = knock door ^ s s)) 0
0
0
3 A Signi cant Subset of PCDL We now restrict our investigations on a signi cant subset of the constraints for each of them we provide a semantics based on PCDL. All these constraints, as we will see later, have the nice feature that they can be compiled within the classical planning model. The whole language formed by the following constraints, possibly combined by conjunction, will be called PCL-1.
3.1 Presence Constraints The simplest forms of presence constraints are AT-MOST-ONCE(a) and AT-LEAST-ONCE(a). They mean that at most (least) one instance of the operator a can be present in S. The latter will be called existence constraint, the former non duplicity constraint. Their formulations in PCDL are AT-MOST-ONCE(a) (8s)(8s )((name(s) = a ^ name(s ) = a) s = s ) 0
0
0
and AT-LEAST-ONCE(a) (9s)(name(s) = a): The conjunction of both the previous constraints is the uniqueness constraint EXACTLY-ONCE(a) which requires the presence of a unique instance of a. The constraints AT-LEAST-ONCE and AT-MOSTONCE can be generalized in many ways. The most immediate are AT-LEAST-TIMES(n; a) and ATMOST-TIMES(n; a), where n is an integer and a is any operator. Their semantics is a straightforward extension of the previous constraints: and AT-LEAST-TIMES(n; a) (#(s : name(s) = a) n)
Another generalization are given by AT-LEASTONCE(A) and AT-MOST-ONCE(A), where A is a subset of the whole operators set. Their semantics is simple: s veri es this constraint if it contains at most (at least) one instance of one operator belonging to A, that is AT-MOST-ONCE(A) (8s)(8s )((name(s) 2 A ^ name(s ) 2 A) s = s ) and AT-LEAST-ONCE(A) (9s)(name(s) 2 A): 0
0
0
There exist many ways to combine both possibilities (n instances and m operators), but only few of them are really interesting. The couple of contraints AT-LEASTAMONG(n; A) and AT-MOST-AMONG(n; A) mean that s has to contain at least (at most) n instances of operators belonging to A, taking into account of multiple instances of the same operator. In PCDL they are AT-MOST-AMONG(n; A) (#(s : name(s) 2 A) n) and AT-LEAST-AMONG(n; A) (#(s : name(s) 2 A) n) A very useful constraints is AT-MOST-AMONG when A coincides with the set of all operators. In this way it is possible to express that any solution must not have more than n steps, that is the user can select an upper bound to the plan length. A particular generalization of these constraints is obtained by allowing to give a di erent integral weigth to each operator. Weigths could be interpreted as actions costs, utility or durations and the upper (lower) bound n would be the maximum/minimum plan cost{utility{duration allowed. Another combination is the constraint ONE-OF(A), where A is always a subset of the operators set. This constraint is satis ed by s if and only if s has only instances of only one operator taken from A. In other word ONE-OF expresses a sort of mutual exclusivity on a set of operators: if one of them is used as a plan step, no other operator can be instanciated any more. In PCDL ONE-OF(A) would be expressed as ONE-OF(A) (9s)(name(s) 2 A) (8s )(name(s ) = name(s) _ :name(s ) 2 A) 0
0
0
If the user wants to express a stronger mutual exclusion, extended also to the instances of the same operator, then he or she must use AT-MOSTAMONG(1; A).
3.2 Absence Constraints An absence constraint EXCLUDE(a) means that a
particular operator a must not be present in the solution. In PCDL it is EXCLUDE(a) :(9s)(name(s) = a)
3.3 Order Constraints The order constraints are BEFORE(a; b) and its opposite AFTER(a; b). They impose that each instance
of a has to be executed before (after) each instance of b. In PCDL, for instance, BEFORE would be described as BEFORE(a; b) (8s)(8s )((name(s) = a ^ name(s ) = b) s s ): 0
0
0
3.4 Achievement Constraints The achievement constraint ACHIEVE(p), where p
is a proposition, states that at some time the condition p must be achieved. In PCDL it would be rendered as ACHIEVE(p) (9s)(p 2 e ects(s)):
Since the simple request for achieving a given condition could be easily satis ed by specifying a nal goal, it makes sense only to use this kind of constraints in conjunction with order constraints. We therefore allow to add a unique label to each ACHIEVE constraint, making possible to express an order relation among the time instants in which the conditions are to be achieved. These order constraints are de ned by using BEFORE (or AFTER) between the labels attached to the corresponding ACHIEVE constraints. For instance \be in Rome, then be in Florence" would be stated by the constraints L1:ACHIEVE(be-in-Rome) L2:ACHIEVE(be-in-Florence) BEFORE(L1,L2) The equivalent constraint in PCDL would be (9s)(9s )(trueAfter(s; be-in-Rome) ^ trueAfter(s ; be-in-Florence) ^ s s ) 0
0
0
In this way it is possible to de ne, by means a planning constraint, a construct equivalent to the achieve tasks present in HTN planning [15]. In a very similar way it would be also possible to provide a construct similar to the do task present in HTN planning [15], leading to the possibility of de ning a complete task network, exactly as in [2].
3.5 Codesignation Constraints A codesignation constraint is CODES(x : a; y : b), where a; b are operators, x is a parameter of a and y is a parameter of b. It means that the parameters x and y must be bound to the same value. In PCDL it would be rendered as (8s)(8s )(name(s) = a ^ name(s ) = b value(s; x) = value(s ; y)) 0
0
0
The opposite is the non codesignation constraint NON-CODES(x : a; y : b), where a; b; x; y are like the previous constraint. It means that the parameters x and y must be bound to the di erent value.
3.6 Conditional Constraints In this class, constraints are active only when a certain condition is true. We have the conditional presence constraints NEED-AFTER(a; b) and its opposite NEEDBEFORE(a; b). They means that if an instance s of operator a is present then there must exist an instance s of operator b such that s precedes (follows) s . In terms of PCDL they are expressed as 0
0
NEED-AFTER(a; b) (8s)(name(s) = a (9s )(name(s ) = b ^ s s )) 0
0
0
and as NEED-BEFORE(a; b) (8s)(name(s) = a (9s )(name(s ) = b ^ s s)) 0
0
0
Another kind of conditional constraint is the triggered action IF(p; a). It states that when p becomes true, then a has to be executed. In PCDL this constraint is IF(p; a) (8s)(trueAfter(s; p) (9s )(name(s ) = a ^ s s )) 0
0
0
4 Compiling constraints in the domain In this section we will show how it is possible to nd an appropriate trasformation to be applied in the domain such that the new planning problem has only solutions which respect the desired constraints. In other words with these transformations we are able to restate a problem inglobing the additional constraints within the domain itself. A precompilation phase producing a new unconstrained planning problem from a given constrained problem is de ned using the methods described above. These techniques add some dummy facts to the initial states and/or the goals and/or the preconditions or e ects of some existing operators. They can sometimes add some new dummy operators to the domain. The presence of dummy items causes the solution plan to be sometimes expressed in a language richer than the original planning language. Hence a postcompilation phase is needed to translate the solution in the old language, i.e. by deleting dummy operators. In the following we expose for each type of constraints de ned in the previous section its own method of compilation. We suppose to be able to generate dummy items by means of a system function like Common Lisp GENSYM, we are therefore guaranteed that these symbols will be new (not already present in the domain) and it will be not used any more for the compilation of other constraints. Each method will be described in terms of what it adds to the domain, which will always be denoted by an initial state I , a set of user goals G and a set of operator A. The presence constraint AT-LEAST-ONCE(a) is translated by inserting a new dummy goal ua into the user goals G and adding it to the e ects of a. Since every solution s must satis es the goal ua , which is asserted only by a, the presence of an instance of a is guaranteed. Dually, the presence constraint AT-MOSTONCE(a) is translated by inserting a new dummy fact ua into the initial state I and adding it to the preconditions of a, while its negated form :ua is added to the e ects of a. It is easy to see that no more than one instance s of a can exist in the plan, since s deletes the precondition of a and there are no other step which can reassert
it. It is worth noting that this constraint does not require that any instance of a will ever exist. The compilation of the constraint EXACTLYONCE(a), as a conjunction of both the previous constraints, can be obtained using the additivity principle, which will be stated later. However this is more concise way to compile it: the same dummy fact ua is added to the initial state and the preconditions of a, while :ua is added to its e ects and to the goals G. The constraint AT-LEAST-TIMES(n; a) is compiled by iterating (in some way) the compilation of the constraint AT-MOST-ONCE, that is by creating a new dummy fact ua , adding the n dummy facts ua (1); : : :; ua(n) to the goals and the generic ua (x) to the e ects of a. Satisfying n di erent goal ua (1); : : :; ua(n) requires at least n instances of a (which is the only operator asserting ua (x)), therefore the constraint is automatically veri ed. The constraint AT-MOST-TIMES(n; a) is translated in a very similar way by creating a new dummy fact ua , adding the n dummy facts ua (1); : : :; ua(n) to I, the generic fact ua (x) to the preconditions of a and :ua(x) to the e ects. The translation of AT-MOST-ONCE(A) and AT-LEAST-ONCE(A) does not present any di erence with respect to the related previous constraints: the same appropriate transformation has to performed to every operator belonging to A.
AT-LEAST-AMONG and AT-MOST-AMONG are translated in a very similar way with respect to AT-LEAST-TIMES and AT-MOST-TIMES. The possibility of adding an integral weight w to an operator a is handled by adding w di erent preconditions and/or e ects ua (x) (or its negation) to a.
The constraint ONE-OF(A), where A = fa1; : : :; am g, is compiled by creating a new dummy fact oA , inserting in I the m dummy facts oA (1); : : :; oA (m), adding to preconditions of each operator ai the new fact ^ oA(j) j 6=i
and nally adding the fact :oA (i) to the e ects of ai. When there is no instance of any operator belonging
to A, then potentially any of them can be added, but as one of these operators ai is selected then the presence of instances of any other operator aj is forbidden, because ai negates a precondition of aj (which cannot be re-asserted), while it is still possible to have other instances of the same operator ai . The translation of a BEFORE constraint is accomplished by creating a new dummy fact pab , by adding it to I and to the preconditions of b, and by adding its negation to the e ects of b. A constraint NEED-BEFORE(a; b) is compiled by adding a dummy fact nab to the preconditions of a and to the e ects of b.
NEED-AFTER(a; b) is compiled by creating a new fact nab, by adding it to I , to G and to the e ects of b, and by adding :nab to the e ects of a. A constraint ACHIEVE(p) is compiled by adding to
the domain a new operator ap , whose preconditions are only p and e ects are empty. This operator is then modi ed as if there was an implicit uniqueness constraint in order to guarantee to execute it once. Its execution would require the achievement of the desired condition p. Possible order relations among other achieve constraints must be handled in the same way as a BEFORE constraint. The constraints CODES(x : a; y : b) and NONCODES(x : a; y : b) are translated in this way: two new predicates ea and eb are created, ea (x) is added to the e ects of a, eb (y) is added to the e ects of b, then a new operator EQ is created with preconditions ea (x) ^ eb (y) ^ x = y (for CODES) or ea (x) ^ eb (y) ^ x 6= y (for NON-CODES) and no e ects. A special conditions must be added in order to execute the EQ (which imposes the required constraint) only when a and b are both present in the plan. This is equivalent to a composite NEED-AFTER(a^ b; OP) and can be accomplished with two other new dummy facts pa and pb , their conjunction is added to I , their disjunction is added to G , a will negate pa and b will negate pb. It is worth noticing that this compilation is possible only when the planner allows for disjunctive goals and preconditions.
The compilation of the constraint IF(p; a) is somehow complex. The simplest case is when p is atomic. The constraint is translated by creating a new dummy fact u, adding it to I and G , and modifying those operators o which have p among their e ects. Each o takes as a new e ect :u. Finally u is added to the e ect of operator a. If some operator adds a fact q which uni es with p, then the new e ect :u must be conditioned to the most general uni cant between p and q. For instance if p is at(Rome) and o has an e ect at(X) then the new conditional e ect WHEN X=Rome THEN :u should be added. When p is a disjunction of several propositions, then the obvious relation IF(p _ p ; a) IF(p; a) ^ IF(p ; a) holds, therefore the additivity principle can be used to compile the constraint. A slightly more dicult situation appears when p is a conjunction of several propositions. For instance if p = p1 ^ p2 then u1 and u2 have to be created, their conjunction added to I and to the e ects of a and their disjunction has to included in G . The modi cation of the operators should change in this way: if an operator o has e ect p1 then add a new e ect :u1, while :u2 concerns to those operators which add p2 . 0
0
Finally the EXCLUDE constraint can be translated by trivially deleting the corresponding operators or by adding to them a non existing precondition.
4.1 Compiling conjunctive constraints When the user expresses a conjunction of constraints, that is constraints which must be achieved at the same time, it is possible to use a technique of compilation that we called additivity principle. It states that if a constraint C is expressable as a conjunction of several constraints C1; : : :; Cn (which must obviously not be in contradiction) then C is compiled by sequentially compiling (in some order) each single constraint Ci . In a more formal way if we denote by compile the function that given a problem P and a constraint C returns the new problem P following the rules described through the previous section, then compile(P; C1 ^ C2 : : : ^ Cn) = compile(compile( : : :compile(P; C1); C2); : : :; Cn) 0
This principle can be justi ed by observing that each method of translation makes no hypothesis on the problem P it has to modify: it just sees which is the kind of the constraint C is to be translated and applies some xed rule to P. Therefore P can be also the result of a previous compilation of another constraint. For what it concerns disjunction, it is fairly clear that it is impossible to compile in a disjunctive way, i.e. there is no simple way to obtain the compilation of a constraint like EXCLUDE(a) _ BEFORE(a; b), starting from the compilations of the single disjuncts. Therefore disjunction, when possible, has to be handled in a separate way, depending on the basic constraints.
5 Expressivity results for PCL-1 The above described procedure COMPILE thus transforms a constrained planning problem P into an unconstrained version P , embedding C in the domain. An obvious translation function ! from the space of plans of P into the space of plans of P is needed in order to express a solution of P in the same language as the solutions of P , because for translating some constraints a dummy operator is added. Therefore ! simply neglects these dummy operators to the domain of P . In the following we will denote by P and P respectively the space of solution for P and P showing that these two set are equivalent. Since each method of compilation produces an unconstrained problem whose solutions are forced to respect the constraints and solve P in the ordinary meaning, it is easy to see that for any solution s of P , !(s) solves the original constrained problem P , that is 8s 2 P !(s) 2 P 0
0
0
0
0
0
0
0
0
On the other hand, for each solution s of P it is possible to construct an equivalent solution s of P , by reverting, in some way, the e ect of !, i.e. by adding the required dummy items to s . Therefore we get that 8s 2 P 9s 2 P !(s) = s 0
0
0
0
0
0
Combining these two properties we obtain that
P is equivalent to P modulo !, i.e. P = f!(s) : s 2 P g: 0
0
This means that any PCL-1 planning problem has an equivalent ordinary planning problem. The converse
is obviously true, because any ordinary planning problem can be seen as a PCL-1 planning problem with an identically true constraint. These features have a strong impact in expressivity in that we are able to state the following result: PCL1 constrained planning model and ordinary planning model have the same expressive power. Our concept of same expressive power is similar to
Baader's [1] expressivity language de nition, used also in [7] for showing that HTN planning is more expressive than ordinary planning. This result is also strongly related to the proof of equivalence between TN and ordinary planning (see [2]); moreover a TN problem planning, as we have seen before, can be stated in terms of PCL-1, therefore TN planning is also equivalent to planning with PCL-1. The expressivity equivalence moreover shows that some particular kind of constraints, like plan length, actions costs, mutual exclusion relations, which are usually thought as strategy rules, can be embedded directly in the domain. The equivalence result does not mean the constraints are useless, because even if it is possible to encode directly them in the domain, the user surely prefers to describe constraints separately from the domain and to use a preprocessor that performs the encoding.
6 Complexity and implementation issues The expressivity equivalence result shows how to design a constrained planner by implementing a preprocessor which translates the constrained problem into an unconstrained version by following the rules of section 4. The unconstrained problem is then submitted to an ordinary planner. The solution produced is nally postprocessed as described in the previous section. From the eciency point of view it should be noted that the amount of dummy items added to the domain is, for each method of compilation, linear in the number and dimension of constraints. Also the times needed to the precompilation and postcompilation phases are linear according the size of their input data. We tried our approach by implementing a preprocessor for the target planner UCPOP [20]. It takes a constrained planning problem expressed in PCL-1 adapted to action/fact description of UCPOP and pro-
duces its equivalent unconstrained version, which can be solved by UCPOP. It is possible to implement a preprocessor for Graphplan [4] which handles a subset of PCL-1, excluding those constraints whose compilation requires conditional e ects or disjunctive preconditions and goals, like CODES, NON{CODES, IF with a conjunctive condition, because the syntax of Graphplan does not allow the use of these constructs. But in order to use the full set of PCL-1 constraints some further preprocessing phases or compilation methods are needed, like those suggested in [8], or a some modi cation to its algorithm and syntax are to be inserted, for instance in [12] IPP, a version of Graphplan with capability of handling conditional e ects, is described. The main feature of the precompilation method is that we are able to solve a constrained problem without the necessity of writing a constrained planner, but by just using an existing ordinary planner.
Acknowledgements This work has been partially supported by Special Project \Strategie di controllo innovative per sistemi di Intelligenza Arti ciale (SCI*SIA)" of Italian National Research Council{C.N.R.
References [1] F. Baader. A Formal De nition for Expressive Power of Knowledge Representation. In Proceedings of European Congress of Arti cial Intelligence, 1990. [2] M. Baioletti, S. Marcugini, A. Milani. Task Planning and Partial Order Planning: A Domain Transformation Approach. In Proceedings of 4th
[3]
[4] [5] [6]
European Congress on Planning, Lecture Notes in Arti cial Intelligence 1348, Springer, 1997. A. Barrett, D. Weld. Schema Parsing: Hierarchical Planning for Expressive Language. In Proceedings of National Conference of Arti cial Intelligence, 1994. A.L. Blum, M.L. Furst. Fast Planning through Planning Graph Analysis. Arti cial Intelligence 90(1-2), 1997 D. Chapman. Planning for conjunctive goals. Arti cial Intelligence 32, 1987 K. Erol, J. Hendler, D.S. Nau. Semantics for Hierarchical Task-Network Planning. Tech. rep. CS-TR-3239, Univ. of Maryland, March 1994
[7] K. Erol, J. Hendler, D.S. Nau. HTN Planning: Complexity and Expressivity. In Proceedings of National Conference of Arti cial Intelligence, 1994. [8] B. C. Gazen, C. Knoblock Combining the Expressiveness of UCPOP with the Eciency of Graphplan. In Proceedings of 4th European Con-
[9] [10] [11]
[12]
[13]
[14] [15]
gress on Planning, Lecture Notes in Arti cial Intelligence 1348, Springer, 1997. M. George Planning. In Annual Review of Computer Science, vol. 2, 1987 M. George A Theory of Action for Multiagent Planning. In Proceedings of National Conference of Arti cial Intelligence, 1984. H. Kautz, B. Selman Pushing the Envelope: Planning, Propositional Logic, and Stochastic Search. In Proceedings of National Conference of Arti cial Intelligence, 1996. J. Koehler, B. Nebel, J.Ho man, Y. Dimopoulos. Extending Planning Graphs to an ADL Subset. In Proceedings of 4th European Congress on Planning, Lecture Notes in Arti cial Intelligence 1348, Springer, 1997. A.L. Lansky A Representation of Parallel Activity Based on Events, Structure, and Causality. In Reasoning about Actions and Plans: Proceedings of the 1986 Workshop, 1986. E.D.P. Pednault. Synthesizing Plans that Contains Actions with Context-Dependent E ects. Computational Intelligence, Vol. 4, 1988. S. Kambhampati. A Comparative Analysis of Partial Order Planning and Task Reduction Planning, SIGART Bull. 1995.
[16] S. Kambhampati, J. Hendler. A Validation Struc-
ture Based Theory of Plan Modi cation and Reuse. Arti cial Intelligence, May 1992.
[17] E.D. Sacerdoti, The Nonlinear Nature of Plans. In Proceedings of International Joint Conference of Arti cial Intelligence, 1975. [18] M. Ste k. Planning with Constraints (MOLGEN: Part 1) in Artif. Intell. 16(2): 111-140, 1981. [19] A. Tate. Representing Plans as a Set of Constraints { the Model. In Proceedings of Conference on Arti cial Intelligence Planning Systems, 1996.
[20] J.S. Penberthy and D. Weld. UCPOP: A Sound, Complete Partial Order Planner for ADL. In Proceedings of Third International Conference of Principles of Knowledge Representation and Reasoning, 1992. [21] Q. Yang. Formalizing Planning Knowledge for Hierarchical Planning, Computational Intelligence, Vol 6, pag. 12-24, 1990
