GRAPHPLAN-BASED TEMPORAL PLANNING WITH THE CRITICAL PATH Tien Ba Dinh University of Huddersfield t.b.dinh@hud.ac.uk 1 INTRODUCTION Up to now, there are several planning systems which are quite successful in dealing with temporal planning domains, such as TGP[3], TPSYS[2], TP4[6], parcPLAN[4], LPGP[5]. Among them, TGP, TPSYS, LPGP are developed based on Graphplan[1]. However, they have some assumptions on conditions and effects of actions which limit the temporal planning domains, such as effects can only appear at the end of their executions [3], or at the beginning and at the end [2, 5]. In this paper, I would like to propose a different approach based on Graphplan to find optimal solution in terms of time (makespan) for richer temporal planning domains. First, we extend the temporal increment idea in the graph expansion phase to deal with planning domains in which effects can take place anywhere during the execution. Second, the solution extraction will rely on the critical path which lead to the examining timepoint to prune more branches in the search tree. 2 PROPOSAL Like TGP, the planning graph is the bilevel compact graph which has 2 groups of nodes, the proposition nodes and the action nodes. Each action or proposition appears only once, and is attached with its earliest time in the graph. As in TGP and TPSYS, the graph expansion applies the temporal increment by choosing the action which has its ending time earliest among possible ones [2, 3]. In this paper, it is extended to deal with richer temporal planning domains. The solution extraction phase relies on the critical path for the timepoint which is hoped to obtain a solution. Unlike other approaches in which they dequeue every goal from the list of goals and look for supporting actions, we are looking for supporting actions from the whole list of goals and the ending time of the previous chosen action. 2.1 Action presentation To deal with richer temporal planning domains where an action can have effects at anywhere during its execution, we propose an action presentation as follows: An action A is presented as {Dur A , Cond A , Eff A } in which: Dur A > 0: the duration of the action A. This value is defined for a domain or calculated before executing the action (e.g. the action fly has duration depending on the distance between 2 places). + + + + + + Cond A = {<Cond A1 , d CondA1 >, …,<Cond Ak , d CondAk >} with ∀i∈[1, k]: d CondAi ≤ Dur A . It is a list of 2-tuples <condition, its duration> for the action A. It means that in order to perform action A, the condition Cond Ai must be true in [Start A , Start A + d CondAi ] (where Start A is the time action A starts). Eff A = {<Eff A1 , d EffA1 >, …,<Eff Ah , d EffAh >} with ∀i∈[1, h]: d d EffAi ≤ Dur A . It is a list of 2-tuples <effect, time> for the action A. It means that action A has effect Eff Ai from the time Start A + d EffAi . 2.2 Mutex relation Like TGP and TPSYS, we also have proposition-proposition, action-proposition, and action-action mutex relations. However, we have some changes in the description to be appropriate with the action presentation above. Proposition – proposition: propositions p and q are mutex if (1) they are negations or (2) all actions supporting q are mutex with p and vice versa. Action – proposition: action A and proposition p are mutex if one of these holds o ¬p∈Cond A ∪ Eff A o (p and q are mutex) ∧ (q ∈Cond A ) ∧ (p is true in [Start A , Start A + d Aq ]) Action – action: action A, B are mutex if one of these holds o ∃p: (p∈Cond A ) ∧ (¬p∈Eff B ) ∧ (d Ap > d B¬p ) o (p and q are mutex) ∧ (p∈Cond A ) ∧ (q∈Cond B ) ∧ (Start A + d Ap ≥ Start B ) We store the mutex relation as constraints between nodes in the graph. There are two types of mutex. One is the static mutex which we can know after reading the planning domain. It is always mutex regardless of the time, e.g. negations of propositions. The other is the dynamic one which depends on the time of propositions or actions. Therefore, when checking whether this proposition or action is mutex with another one, we will know immediately if it is static mutex. Otherwise, we have to check the mutex constraint between them at the examining time. 2.3 Graph expansion Like TGP and TPSYS, the graph expansion applies the idea of temporal increment. We extend the algorithm to deal with actions having effects during their executions. The planning graph is a bilevel compact graph in which there is a level of proposition nodes and a level of action nodes. Each node appears only once and is attached with the earliest time it appears. In addition to the directed arcs which show the relations of condition-action-effect of nodes, we also have mutex constraints between nodes. Besides, we also maintain a list called Props which is used to store instances of propositions and their timestamps. Starting from the list of propositions for the initial state, the system will expand the graph by choosing an action among possible actions which has the ending time earliest. 1