Appeared in ECAI-96 workshop: Cross-fertilisation in Planning
Recovering from Failure in Temporal Planning Ho-Jin Choi, Vassilis Liatsos, Amin El-Kholy, and Barry Richards y 3 June 1996
Abstract
resource allocation presents a formidable computational problem. In this paper we describe some of the dicult problems faced in plan generation. We shall focus, in particular, on the area of recovering from collapsing failures [1, 2, 4, 6]. For example, Allen and Koomen's planner [1] has no strategy for introducing new actions when the set of temporal constraints becomes inconsistent. When this happens, there is no clue as to which subgoals have led to the temporal contradiction. Here the planner has to resort to blind search. Plainly this is an intractable process. There seems to be no domain-independent strategy to solve this problem. The aim of this paper is to clarify this problem with a view to seeking a strategy. We rst present in section 2 the representation and plan generation framework used in parcPLAN; in section 3 we describe the problem of recovering from collapsing failure. Section 4 summarises the progress we have made so far towards solving this problem.
This paper describes an open problem in temporal planning, namely the problem of recovering from failure in collapsing time intervals. We illustrate this problem in the context of the parcPLAN planning system and show its full complexity by combining the problem with resource reasoning. We also summarise some of the progress made to tackle this problem.
1 Introduction
A practical planning system should concern two levels of optimality in its output plans: (1) obtaining an optimal plan in the number of actions generated; and (2) obtaining an optimal schedule in the usage of time and resources. These issues of optimality have been central to the design of parcPLAN [8], a temporal planning system which is currently under development at ICParc. parcPLAN follows an interval-based planning parc paradigm [1].1 Both actions and properties are indexed explicitly to intervals. Moreover, the traditional \one action at a time" assumption disappears. parcPLAN aims to produce plans 2.1 Representation which maximise concurrency in action execution subject to available resources (e.g., number of In parcPLAN both properties and actions are robot arms) and speci c temporal constraints. represented by terms indexed to time intervals. The task of integrating action scheduling and We use the notation p@[start,end) to say that property (or action) p holds (or occurs) over the This work was supported in part by a grant from time interval [start,end). The end-points of an interval are represented by a domain variable on EPSRC No. GR/J38772. y IC-Parc, William Penney Laboratory, Im- which we impose temporal constraints. perial College, London SW7 2AZ, email: Figure 1 shows an example planning problem in fhjc,vl,aoe,
[email protected] 1 Unlike [1], however, parcPLAN adopts point-based the blocks world. This is a \temporal version" representation of intervals. of a state-based style problem in that all facts
2 The ture
1
PLAN Architec-
The constraints in lines 6-8 are used to designate the type of object variables involved in the action speci cation. For instance, the constraint in line 6 states that the object which is moving has to be a block and not a table position. The constraints in line 9 are non-codesignation constraints. They state that a block cannot be moved from itself, nor it can be moved on top of itself. Constraints in line 10 are temporal constraints which state that the moving block has to be clear throughout the action. All these constraints are asserted when the action is introduced. Note that there is no non-codesignation constraint From 6= To, which is typically found in traditional approaches. This constraint prevents an action of moving a block from X to X. When actions are assumed to occur in a linear sequence, lifting up a block and putting it down in the same place does not make sense. When parallel execution of actions are considered as in the case of parcPLAN, however, this action can be e ective in obtaining an optimal solution. Domain rules are application-speci c and state certain relations between pairs of properties and/or actions which cannot occur in a valid plan. In the blocks world, for example, a domain rule is used to state that a block cannot be clear and have something on top of it at the same time.
a c b
a
t1
t2
b c t3
t1
Initial State
t2
t3
Goal State
(a) A planning problem Facts:
on(a,t2)@[0,T1), on(b,t1)@[0,T2), on(c,a)@[0,T3), clear(b)@[0,T4), clear(c)@[0,T5), clear(t3)@[0,T6)
Goals:
on(a,b)@[T7,20), on(b,c)@[T8,20), on(c,t1)@[T9,20)
Temporal Constraints: 0
< T
10 ;
< T
2
;:::;T
9 20
