EMPLOYING DOMAIN KNOWLEDGE TO IMPROVE AI PLANNING EFFICIENCY *

Transcription

1 Iranian Journal of Science & Technology, Transaction B, Engineering, Vol. 29, No. B1 Printed in The Islamic Republic of Iran, 2005 Shiraz University EMPLOYING DOMAIN KNOWLEDGE TO IMPROVE AI PLANNING EFFICIENCY * G. GHASSEM-SANI ** AND R. HALAVATI Dept. of Computer Engineering, Sharif University of Technology, Tehran, I. R. of Iran sani@sharif.edu Abstract One of the most important problems of traditional A.I. planning methods such as nonlinear planning is the control of the planning process itself. A non-linear planner confronts many choice points in different steps of the planning process (i.e., selection of the next goal to work on, selection of an action to achieve the goal, and selection of the right order to resolve a conflict), and ideally, it should choose the best option in each case. The partial ordered planner (POP) introduced by Weld in 1994, assumes a magical function called "Choose" to select the best option in each planning step. There have been some previous efforts for the realization of this function; however, most of these efforts ignore the valuable information that can be extracted from the problem s domain. This paper introduces several general heuristics for extracting useful information contained in problem domains by an automatic preprocessing. These heuristics have been incorporated into a planner called H 2 POP, and tested on a number of different domains. Keywords Artificial intelligence, planning, non-linear planning, domain knowledge, heuristic 1. INTRODUCTION Strategic planning has had many advances in recent years by introducing several new efficient methods such as planning by graph analysis [1] or SAT planning [2], etc. However, traditional planning methods such as non-linear planning have the advantage of simplicity. The idea of non-linear planning was first introduced by NOAH [3] and Nonlin [4]. POP [5] uses this idea in the following manner: Using a depth first search, in each iteration, the planner chooses one of the remaining goals, then finds an action satisfying that goal and tries to resolve possible conflicts. These choices are assumed to be made by a magical function called "Choose", which has been addressed by several researchers [6-8]. The main approach of most of these works is to find some general, domain-independent heuristics that can help in making better choices. However, they fail to employ the valuable information that can be automatically elicited from problems domain. This paper presents several heuristics for automatic extraction of domain-dependent knowledge. H 2 POP's operation begins with a single time preprocessing of each new domain prior to working on any problem in that domain. The outcomes of this preprocessing are generating some macro actions, finding sequences of actions that will never be used in any plan, creating a hierarchy of predicates, and discovering hidden conflicts among the predicates of problem domain. The problem solving operation of H 2 POP is almost the same as POP except for the following. The first task at the beginning of solving any problem is to put the goals in a hierarchy that states which goals are more important and should be satisfied sooner. As long as there are still unsatisfied goals in higher levels of this hierarchy, lower level ones are not considered (i.e., hierarchical planning). Instead of choose functions used by POP (i.e. 'choose goal' and 'choose action'), here we employ two functions called 'generate action choices' and 'rate action choices'. The first one produces all possible choices at the current step, and the second one rates them in such a way that the most promising choice is then selected. Received by the editors November 13, 2002 and in final revised form November 9, 2004 Corresponding author

2 108 G. Ghassem-Sani / R. Halavati In the next section, we briefly explain the partial order planning (POP), and then we introduce our automatic, domain-independent heuristic-generator procedures in a section titled 'Domain Preprocessing'. Next, we introduce H 2 POP, and express its differences from POP. Finally, in the last section, we conclude our work and propose some further works. For the sake of simplicity, all examples are given from the Blocks World domain, but the proposed methods can also be applied to other domains. 2. PARTIAL ORDER PLANNING (POP) In a partial order planner, a plan is defined as a triple <S, O, L>, where S is the list of actions in the plan, O is a list of ordering constraints between action pairs, and L is a list of the causal links between the actions preconditions and effects. An ordering constraint <A, B> O means that action A must be executed before action B. A causal link <A, B, Q> L denotes that the precondition Q of action B has been produced by action A and must not be violated between the execution of actions A and B. L is used to detect and resolve possible conflicts among actions. POP begins with a list of goals called agenda. At first, S includes two nodes: Begin and End. The problem main goals are represented by the preconditions of End, and the initial state of the problem is represented by the post conditions of Begin. Initially, there is only one ordering constraint <Begin, End> O, and L is empty. At each planning step, POP chooses a goal from Agenda and tries to achieve it by using either an existing action in the plan or a new action from the list of available actions that are given to the planner. If a new action is added to the plan, the preconditions of the new action are added to the agenda as the new subgoals. The planner also detects and resolves possible threats to the previously achieved goals. There are several choice points in each planning cycle (i.e., choosing the next goal to achieve, choosing an action to support the goal, and choosing a mean to resolve a possible threat) where a proper decision can have a major effect on the efficiency of the planning process and quality of the produced plan. However, in original POP algorithm, there are not any criteria to make a proper decision, and decisions are made by performing a blind search. 3. DOMAIN PREPROCESSING As stated before, the first task of H 2 POP, whenever it encounters a new problem domain, is a pre-analysis of that domain. The aim of this job is extracting the heuristics, besides constructing a number of macro actions. The following sub sections describe different procedures used for this operation. The way that these heuristics are used in the planning process is discussed later. a) Detecting hidden mutual exclusions Every domain may contain predicate pairs that are mutually exclusive, but the point is not stated directly in the domain definition, and therefore remains obscure. For example, Clear(X) and On(Y, X) in the Blocks World Domain are mutually exclusive. This property is not explicitly stated in the domain definition, but can be derived by analyzing appropriate actions. The aim of this procedure is to identify these obscure mutual exclusions in an automatic and domain-independent manner. The outcome of this procedure for a given domain is a table that has one row and one column for each predicate of that domain. This table, for the Blocks World domain, is shown in Table 1. In this table, variables that occur in columns are disjointed from variables in rows. At the end of the execution of this procedure, each cell of the table shows both conditions under which the two related predicates are mutually exclusive, and situations in which they are not. For instance, consider the information given in Table 2 for two cells of Table 1. Iranian Journal of Science & Technology, Volume 29, Number B1 February 2005

3 Employing domain knowledge to improve 109 Table 1. The initial table for hidden mutual exclusion detection On(X,Y) Clear(X) OnTable (X) Hand Empty Holding (X) On (Z, T) Clear (Z) OnTable (Z) Hand Empty Holding (Z) Table 2. Partial mutual exclusion table On(X,Y) Clear(X)... On(Z, T)... (1) Y=Z, X=T : mutually exclusive (2) Y=Z, X T: Ok (3) X=Z, Y T: mutually exclusive. (4) X=Z : Ok (5) X=T : mutually exclusive Table 2's information is interpreted as follows: 1) On(X,Y) and On(Z,T) are mutually exclusive whenever X and Y are equal to T and Z, respectively. 2) On(X,Y) and On(Z,T) are ok whenever X is not equal to T, but Y is equal to Z. 3) On(X,Y) and On(Z,T) are mutually exclusive whenever X is equal to Z, but Y is not equal to T. 4) Clear(X) and On(Z,T) are compatible if X is equal to Z. 5) Clear(X) and On(Z,T) are incompatible if X is equal to T. The mutual exclusion detection algorithm, which is shown in Fig. 1, has two stages. The aim of stage 1 is to initialize the table with predicate pairs that are consistent. This knowledge can be extracted from the definition of domain actions. If an action has two preconditions A and B, we regard these predicates as consistent. (Note, we assume that the domain definition has no errors.) Furthermore, if an action has two add-effects C and D, we again regard C and D as consistent. Based on these assumptions, the first stage of our algorithm iterates for all domain actions, and marks every two predicates that are in the same preconditions list or add-effects of an action as consistent. For example, if we find an action with two preconditions On(X,Y) and Clear(X), we will add the statement "X=Z, Ok" to the cross reference of On(X,Y) and Clear(Z) in Table 1. We must also add the statement "X=Z, Ok" to the cross reference of Clear(X) and On(Z,T). In stage 2, the algorithm performs a recursive search for detecting mutual exclusion relations between predicate pairs. A pair of predicates is regarded as being mutually exclusive if every action that produces the first predicate also has an effect or a (possibly indirect) precondition that is inconsistent with the other predicate (and vise versa). // Stage 1: Initializing the table. 1- For every action A, a. Set M to the set of all preconditions of A. b. For every two predicates P and Q, from set M, i. If P and Q have no common variable and none of them is variable-free, continue from 1-c. ii. Add the relation between variables of P and variables of Q to the cross reference of P and Q as Ok. c. Repeat the above stages for every two predicates P and Q from the set of add-effects of A, too. // Stage 2: Searching for mutual exclusions. 2- Found false 3- For every two predicates A(a 1,a 2,...) and B(b 1,b 2,...), whose compatibility is not yet known, a. x CheckComp( [A(a 1, a 2,...)], B(b 1, b 2,...)) b. y CheckComp( [B(b 1, b 2,...)], A(a 1, a 2,...)) c. if x is false and y is false, then i. Add "A(a 1,a 2,...) and B(b 1,b 2,...) are incompatible" to the table. ii. Found = true. 4- If Found is true, then go to Line 2 Fig. 1. Mutual exclusion detection algorithm February 2005 Iranian Journal of Science & Technology, Volume 29, Number B1

4 110 G. Ghassem-Sani / R. Halavati As it is shown in Fig. 1, each direction of this analysis is performed by one call to a recursive procedure called CheckComp. For instance, in order to prove Clear(Y) and On(X,Y) are mutually exclusive, CheckComp performs the following analysis: Clear(Y) can be achieved by either PutDown(Y), Stack(Y, Z), or Unstack(Z, Y). PutDown(Y) needs Holding(Y), which can be achieved by either Unstack(Y, Z), or PickUp(Y). Both of these actions need Clear(Y) as a precondition. Stack(Y, Z) needs Holding(Y) as well, which in turn needs Clear(Y) again. Finally, Unstack(Y, Z) needs On(Y, Z) which can be achieved by Stack(Y, Z), which in turn needs Clear(Y) again. Thus, all these cases contain a viscous cycle that should be discontinued. Considering the reverse case, On(X, Y) can only be achieved by Stack(X, Y), which produces ~Clear(Y) as an effect. b) Detection of alpha-beta preconditions Let us start this part with an example from Blocks World domain. Suppose our goals are On(A, B) and On(B, C). In this case, it is clear that in the final plan, On(B, C) must be achieved prior to On(A, B). Due to the nonlinear nature of POP, the order of selecting these two goals has no limiting effect on the planning process to find the solution. However, if the planner attacks On(A, B) first, it has to perform a timeconsuming conflict-resolution in order to achieve On(B, C); whereas, if it attacks these goals reversely, the conflict-resolution process will not be necessary. Finding the correct order in which planning goals should be attacked has a major effect on the performance of the planning process. The correct order of achieving these types of goals, which we call alpha-beta pairs, can be determined with a simple rule. Alpha-Beta Pair: If there is a case in which every action producing predicate A produces predicate C as well, where C is mutually exclusive with predicate B, we call A and B an Alpha-Beta pair. A is called the Alpha part and B the Beta one. Whenever we find such a case in a problem, we can conclude that the alpha part should be achieved prior to the beta part, because otherwise, construction of alpha will definitely undo beta. For instance, every action producing On(B, C), also produces Clear(B). We know that Clear(B) is mutually exclusive with On(A, B). Hence On(B, C) and On(A, B) are an Alpha-Beta precondition pair, and therefore On(B, C) should be achieved prior to On(A, B). Figure 2 shows the algorithm that identifies the alpha-beta precondition pairs. 1. For every two predicates A and B, a) For every predicate C incompatible with B, i. If there is an action that can produce A without C, continue from 1-a. ii. Otherwise, add (A, B) as an alpha-beta precondition pair. Continue from 1. c) Checking action parameters Fig. 2. Detection of alpha-beta precondition pairs Many actions with more than one parameter may not work when their parameters are set to equal values (e.g., Stack(X, X)). Identification of these cases can prevent later conflicts. Figure 3 shows the algorithm that can be used to identify these cases. 1. For any action A a. L {} b. M {x x is a precondition of action A} c. N {x x is an effect of action A} d. P {x x is a member of delete list of A} e. Q N ( M P ) f. For every pair of variables of action A such as X and Y, if there are two members of Q that are in conflict, and if X is equal to Y, then add (X,Y) to L. g. L is the list of all variable pairs of action A that cannot be set equal. Fig. 3. Finding action parameter restrictions Iranian Journal of Science & Technology, Volume 29, Number B1 February 2005

5 Employing domain knowledge to improve 111 d) Generation of macro actions Some actions naturally follow each other. For example, in Blocks World, Stack(X, Y) always follows either Pick Up(X) or Unstack(X, Z). If such sequences are considered as macro actions and can be chosen during the action selection phase, the number of choice points and items in the goal agenda is reduced. Figure 4 describes our method for constructing macro actions. Repeat for Max Depth times, o For every two actions or macro actions A and B, For every variable combination of A and B, 1. M {x x is an effect of A } ( {x x is a precondition of A } { x x is in delete list of A } ) 2. N { x x is a precondition of B } 3. If any two members of M and N are mutual exclusive, go to P ( M { x x is in delete list of B } ) { x x is in add list of B } 5. Q P ( { x x is a precondition of A } { x x is a precondition of B and not an effect of A } ) 6. If Q is empty, go to Add AB as a macro action. 8. Continue. Prune generated macro actions. Fig. 4. Macro action generator The algorithm has a max depth parameter in its first line. This parameter limits the maximum size of macros generated by the algorithm. The higher this number is, the longer and more macro actions may be generated. More macro actions can speed up the planning process, but at the same time, it has the side effect of causing a higher branching factor, which in turn results in the slowing down of the planning process. The trade off between these two is in fact domain-dependent. We chose a single iteration for the blocks world domain, which worked quite well. The first three lines of the algorithm ensure that every two actions, with every possible set of common variables among them, are checked. For example, stack and unstack are checked 6 times as follows: 1) stack(x, y), unstack(x, y) 2) stack(x, y), unstack(x, z) 3) stack(x, y), unstack(z, y) 4) stack(x, y), unstack(y, x) 5) stack(x, y), unstack(z, x) 6) stack(x, y), unstack(y, z) Line 1 of the algorithm constructs the set M as all add-effects of action A, plus those preconditions that are not deleted by the A. Line 3 checks to see if there is any mutual exclusion relation between any member of M and a precondition of action B. Line 4 finds all predicates produced after sequential occurrence of the two actions. Line 5 computes the net effects of the AB sequence on the world state. Line 6 checks the usefulness of the AB sequence. The last stage of this algorithm is a pruning procedure that uses some measures as 'number of predicates that are produced by one action of the macro action, and used by 'another', or 'the number of predicates that are produced by more than one action of the macro action', in order to eliminate some of the less promising macro actions. A better method for fulfilling this job is proposed later in the paper. e) Finding opposite actions Some actions like Stack(X, Y) and Unstack(X, Y), are considered as opposite actions, because one of them undoes the effects of the other. In other words, a sequence of these two actions has no effect on the current state of the problem. We can use algorithm 4 to identify theses cases just by replacing line 6 by the statement 'if Q is not empty ' February 2005 Iranian Journal of Science & Technology, Volume 29, Number B1

6 112 G. Ghassem-Sani / R. Halavati 4. HIERARCHICAL/HEURISTIC POP This section describes the differences between POP and H 2 POP. Our planner uses an iterative deepening depth first search on the maximum number of actions needed to solve the given problem. This will help the planner not to be trapped in fruitless branches of the search space. a) Goals hierarchy As stated before, when there is an Alpha-Beta relation between two goals, it is better to achieve the alpha goal prior to trying to achieve the beta goal. For this, the goals are checked for having alpha-beta relations prior to beginning the planning process. After computation of alpha-beta relations, the goals are put in different layers such that in each alpha-beta pair, the alpha goal is put in a higher layer than the beta goal (Here, by being in a higher layer, we mean having a higher priority.) The planning process begins by considering only the highest layer goals. Any precondition of actions of each layer is also assumed to be in that layer. Only when all the goals in one layer have been achieved, the planning proceeds to the next layer. If the planner fails to achieve any of the goals of any layer, it backtracks to the previous layer. b) Priority of action selection to goal selection In POP, goal selection is separated from action selection, and takes place before that. In H 2 POP, however, these two tasks are united. It first determines all actions that are applicable to any remaining goals of the current layer, then rates them with some measurement factors, and finally selects the most promising action. (Note that selecting an action entails the selection of goal(s) that should be achieved; i.e. those goals that are supported by the chosen action. In other words, in H 2 POP, there is not a separate step for choosing goals.) The procedure that performs this task is shown in Fig M {x x is an action currently selected in plan} {x x is a new action from domain space}. 2- L0 {} 3- For all members of M such as A, a. L1 {} b. For all unsatisfied goals belonging to current layer such as G, if A supports G with some variable combination, add the combination to L1. c. If L1 is not empty, then for any combination of variables stored in L1, Rate it. 4- Sort List L0 with the following priorities: a. The highest priority measure is the number of satisfiable goals. b. Then, actions with lower number of requirements are favored. c. At last, macro actions have higher priority than simple ones. Fig. 5. Generate action choices Line1: Set M is constructed as the set of all actions that are already used in the current plan (i.e. old actions), plus all actions that can be added to the plan (i.e., new actions). Line 2: We use list L0 as the list of all actions that are checked and proved to satisfy at least one of the remaining goals in the current layer. Each member of L0 holds some rating measures with itself. What these ratings are is described later. Lines 3-a, 3-b & 3-b-i: This part has to find all possible variable assignments of the selected action that may satisfy at least one goal. For instance, a variable assignment can be in the form of 'x A, y B for Stack(x, y)', in which A and B are two objects of the current problem. A variable assignment may be partial, in that, some of the variables may still have no value. These variable assignments are stored in L1. Line 3-c: It is checked if the current action can satisfy at least one goal. If the check passes, the procedure goes through all possible combinations of variable assignments stored in L1 for the current action and rates these combinations. The rating process takes place by considering the following measures: Iranian Journal of Science & Technology, Volume 29, Number B1 February 2005

7 Employing domain knowledge to improve Whether the variable assignment is valid? 2- How many new sub goals are to be added to the goal agenda if this action is selected? 3- How many goals does it satisfy? 4- Whether or not the current action, if it is a new action, and supports precondition G of action A, is opposite to A? A point worth noting here is that the above procedure generates many choices. Although the procedure sorts theses choices, there may still be too many alternatives to be tried in future backtrackings. Thus, we just check part of the high ranked choices (by using an iterative deepening search), and neglect the rest. c) Checking unrecoverable conflicts Suppose there are two actions A and B in the current plan, such that A has unsatisfied preconditions X and Y, and B has effects X and Z. If ~Z and X form an alpha-beta precondition pair, and Z and Y are mutually exclusive, then B cannot be the supporter of precondition X for A (see Fig. 6a). B A M2 M1 X Z X and ~Z are an alpha-beta pair X Y On(A, B) On(B, C) On(A, B) Clear(C) (a) Mutually Exclusive (b) Mutually Exclusive Fig. 6. The pattern (a) and sample (b) of an unresolvable conflict For instance, suppose there is an action called M1 (either a primitive or a macro action) in our plan which has two unsatisfied preconditions On(A, B) and Clear(C). Suppose there is also another action called M2 which produces On(A, B) and On(B, C). In this case, if the planner chooses M2 as the supplier of On(A, B) for M1, there must be a range between M2 to M1 protecting On(A, B) (see Figure 6-b). On(B, C) and Clear(C) are mutually exclusive, and thus On(B, C) must be undone before we reach M1. However, ~On(B, C) and On(A, B) are an alpha-beta pair, which means undoing On(B, C) cannot be fulfilled without undoing On(A, B). Therefore, any action chosen to undo On(B, C) will definitely be in conflict with the above range, and must be either promoted or demoted; whereas, we need it exactly inside that range. Hence, such cases definitely lead to an unresolvable conflict and need backtracking, and hence should be prevented. The algorithm shown in Fig. 7 finds such cases. X 1- For any new range B A, 2- M {x x is an unsatisfied precondition of A}. 3- N {~x x is an effect of B and x is in conflict with a member of M}. 4- If any member of N is in an alpha-beta precondition pair with X, the link has an unrecoverable conflict. d) Preventing linear conflicts Fig. 7. Finding unrecoverable conflicts The final major difference between POP and H 2 POP is that H 2 POP prevents adding actions that are going to create a linear conflict (i.e. a conflict that cannot be resolved by linearization). However, POP first adds such actions and later detects the conflict and has to backtrack. 5. IMPLEMENTATION RESULTS Some of the theoretical aspects of this paper have been previously introduced elsewhere [11]. However, the implementation results are presented here. Table 3 depicts the comparison between H 2 POP and POP in solving several problems from the Blocks World domain. Both algorithms have been implemented by using Visual C++ and the tests were run on a Pentium III, 600MHz. February 2005 Iranian Journal of Science & Technology, Volume 29, Number B1

8 114 G. Ghassem-Sani / R. Halavati As it is shown, POP performs slightly better than H 2 POP in very simple problems (i.e., cases 1-3), but for larger ones (i.e., cases 4-10), H 2 POP's highly outperforms POP. The lower performance of H 2 POP in easier cases is due to the extra work of H 2 POP in each planning cycle to choose the appropriate goal and action. POP that uses a brute force search often solves small problems faster. However, in tackling larger problems, POP, with its blind search, goes through a lot of unnecessary backtracking, whereas H 2 POP prevents these by making decisions that are more appropriate. Since the planning task (using POP or H 2 POP) is a highly iterative operation, the number of backtrackings has a major effect on the planning efficiency. Although in this paper the comparison between H 2 POP and POP was based on problems from a classical planning domain (i.e., Blocks World), the ideas presented here have also been applied to a number of other domains, too [12]. Table 3. Comparison between POP and H 2 POP Initial State CLEAR(B), ONTABLE(C), ON(B, C), ANDEMPTY CLEAR(C), CLEAR(A), CLEAR(B), CLEAR(D), ONTABLE(C), ONTABLE(A), ONTABLE(B), ONTABLE(D), CLEAR(B), ONTABLE(D), ON(B, C), ON(C, A), ON(A, D), CLEAR(A), CLEAR C, CLEAR(D), ONTABLE(A), ONTABLE(B), ONTABLE(D), ON(C, B), Goal State CLEAR(C) CLEAR(B) ONTABLE(A) CLEAR(C) ON(B, A), LEAR(C) ON(B, A), ON(A, C) ON(B, A), ON(C, B) ON(D, C), ON(C, B), ON(B, A) ON(D, C), ON(C, A), ON(A, B) ON(A, B), ON(B, C), ON(C, D) H 2 POP Time(ms) , ,751 37,934 43,482 POP Time(ms) , , ,960 16,734 >300,000 >300,000 >300, CONCLUSION In this paper, we proposed some changes to partial order planning in order to make it more efficient. POP was claimed to be sound and complete [5], and the following statements show that our modifications do not harm these properties, either. 1) H 2 POP uses an iterative deepening approach, which does not change the soundness or the completeness. 2) We use a hierarchical goal ordering in H 2 POP. The order in which goals are selected has no effect on the completeness of POP; it only affects efficiency. We improve the efficiency by forcing the planner to select the goals in a more rational order. 3) We combined two main steps of POP (i.e. choosing the next goal to work on, and choosing an action to achieve that goal). Since H 2 POP can still select all possible actions, this does not affect the completeness of H 2 POP, either. 4) We use macro actions in addition to primitive actions. As macro actions are just sequences of primitive actions, a selection of a macro action can be assumed to be the same as a sequence of action selections in POP. Besides, H 2 POP is not restricted to select only macro actions. So, whenever it is necessary, primitive actions can be selected, too. Iranian Journal of Science & Technology, Volume 29, Number B1 February 2005

9 Employing domain knowledge to improve 115 5) We prevent the occurrence of 'Unrecoverable Conflicts'. As stated before, an unrecoverable conflict is a case that definitely causes backtracking. If POP selects such a case, it has to backtrack and eliminate it. We prevent such cases in advance. 6) We also prevent linear conflicts beforehand, whereas POP does not recognize such cases until it is too late, and it has to backtrack. We have implemented and tested our heuristics on a number of problem domains. Although there have been some improvements, there are still works to be done. For instance, the procedure that detects "hidden mutual exclusion relations" is not yet complete. Completion of this procedure can have a major effect on the planner's efficiency. We can also make use of statistical information, gathered from previously solved problems, to get rid of useless macros, make a better rating of goals and predicates, and guide selections more properly. The planner also needs a method to identify planning loops. Furthermore, the preprocessing engine can be enhanced so that it derives some meta-rules to control the planning process. Finally, we still have no means to make a wiser choice between promotion and demotion. REFERENCES 1. Blum, A. & Furst, M. (1997). Fast planning through planning graph analysis. Artificial Intelligence, 90, Kautz, H., McAllester, D. & Selman, B. (1996). Encoding plans in propositional logic. Proceedings of the Fifth International Conference on the Principle of Knowledge Representation and Reasoning (KR'96), Sacerdoti, E. (1975). The non-linear nature of plans. Proceedings of the Fourth Joint Conference on Artificial Intelligence (IJCAI-75), Tate, A. (1977). Generating project networks. Proceedings of the Fifth International Joint Conference on Artificial Intelligence (IJCAI-77), Weld, D. (1994). An introduction to least commitment planning. AI Magazine, 15(4), Pollack, M., Joslin, D. & Paolucci, M. (1997). Flaw selection strategies for partial-order planning. Journal of Artificial Intelligence Research, 6, Gerevini, A. & Schubert, L. (1996). Accelerating partial-order planners: Some techniques for effective search control and planning. Journal of Artificial Intelligence Research 5, Koehler, J. & Hoffmann, J. (2000). On reasonable and forced goal orderings and their use in an agenda-driven planning algorithm. Journal of Artificial Intelligence Research, 12, Fikes, R., Hart, P. & Nilsson, N. (1972). Learning and executing generalized robot plans. Artificial Intelligence, 3(4), Sacerdoti, E. (1974). Planning in a hierarchy of abstraction spaces. Artificial Intelligence 5, Ghassem-Sani, G., Halavati, R. & Hashemian, E. (2002). Hierarchical/heuristic partial order planner (H 2 POP). Proceedings of International Conference on Artificial Intelligence (IC-AI 2002), 3, Salari, R., Ghassem-Sani, G. & Halavati, R. (2004). Domain preprocessing in AI planning. Proceedings of 9th Annual Int. CSI Computer Conference (CSICC'2004), I, Sharif University of Technology, Tehran, Iran, February 2005 Iranian Journal of Science & Technology, Volume 29, Number B1