# Applying Domain Analysis Techniques for DomainDependent Control in TALplanner Jonas Kvarnstr om Dept PDF document - DocSlides

2014-12-14 186K 186 0 0

##### Description

of Computer and Information Science Link oping University SE581 83 Sweden jonkvidaliuse Abstract A number of current planners make use of automatic domain analysis techniques to extract information such as state in variants or necessary goal orderin ID: 23881

DownloadNote - The PPT/PDF document "Applying Domain Analysis Techniques for ..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.

### Presentations text content in Applying Domain Analysis Techniques for DomainDependent Control in TALplanner Jonas Kvarnstr om Dept

Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
To permit this type of optimization, the optimizer is ex- tended to return a tuple ψ, necNeg necPos , where is equivalent to in the given context, necNeg (corresponding to in the example) is a set of bindings necessary for to hold in the given context, and necPos is a set of bindings necessary for to hold in the given context. Generating Necessary Variable Bindings Variable bind- ings can be generated by equality expressions: var gen- erates the binding var to be added to necPos , and var generates the binding var to be added to necNeg . Similarly, a xed uent formula var gen- erates a positive binding var value τ,f , and the opti- mization of with a known formula var generates a positive binding var When optimizing a conjunction =0 , each conjunct is recursively optimized. Denote the return values by necNeg necPos for . For the conjunc- tion to hold, the conjunction of all necPos must hold; for the conjunction to be false, the disjunction of all necNeg must hold. A dual optimization is applied to disjunctions. For necPos and necNeg are swapped; for a quanti ed formula x. or x. , the bindings generated for the inner formula are returned after removing the bindings for It may be the case that no binding at all is possible (for example, because two conjuncts require bindings that cannot belong to the same value domain). In this case, a formula may be immediately optimized to true or false This concludes the description of the formula optimizer, which will be used as a basis for the domain analysis tech- niques that will be discussed below. Using Existing Domain Analysis Techniques As mentioned in the introduction, there are two interesting questions to be answered regarding the use of domain anal- ysis techniques for planners that utilize domain-dependent control: Which existing techniques for domain-independent planners can be reused, and what new opportunities are opened by the addition of control formulas? This section will focus on the rst question, while the next section will concentrate on the second one. There are several potential dif culties associated with reusing existing domain analysis techniques in TALplanner. The control rules used by TALplanner are essentially tem- porally extended goals. These rules constrain the possible ways a goal state can be reached, but several analysis tech- niques depend on the fact that only the nal state is con- strained and that the way this state is reached is unimportant. Also, one of TALplanner s design goals is the ability to plan for domains with large numbers of objects and operator instances. Even if an operator could have billions of oper- ator instances or more, this should not be a major problem as long as suf ciently strong control rules can be written to guide the planner towards choosing good instances to be applied. For this reason, techniques that rely on generating all ground instances of operators or predicates are less likely to be useful in conjunction with TALplanner. This includes techniques such as RIFO (Nebel, Dimopoulos, & Koehler 1997) and (Haslum & Jonsson 2000). Finally, another important design goal is permitting the use of more complex types of operators, including operators with extended duration and (eventually) non-deterministic effects, as well as the use of resources and concurrency (Kvarnstr om, Doherty, & Haslum 2000). Any techniques depending on the use of single-step operators would require extensions in order to be used in TALplanner. Using State Invariants Given these restrictions, the most promising type of do- main analysis technique to be integrated into TALplanner has been the automatic extraction of state constraints or state invariants. This involves analyzing the operator de nitions in a domain, possibly together with the initial state of a spe- ci c planning instance, and nding a set of invariants that are guaranteed to hold in any state generated by a valid opera- tor sequence (Fox & Long 1998; Gerevini & Schubert 1998; 2000; Scholz 2000; Rintanen 2000). For the logistics domain, one such invariant would be in obj vehicle at obj loc : An object in a vehi- cle is not at any location. (While this may appear counter- intuitive, it does follow from the way the logistics domain is usually modeled.) There are two steps involved in integrating such a tech- nique into the planner: The technique must be adapted to work with TALplanner s operator de nitions (and possibly extended to handle operators with extended duration), and the planner must be altered to actually use the state invari- ants once they have been generated. We have chosen to be- gin with the second step, extending TALplanner to make use of manually speci ed state invariants. This will provide the opportunity to test carefully whether the use of the invari- ants has a suf cient impact on the planner s performance to warrant following through with the implementation of the automatic domain analysis. State invariants are provided to the formula optimizer us- ing an extended form of the optimization context introduced in the previous section. The extended context consists of a tuple , where (like before) is a set of formulas known to hold and is a set of state invariants. Whenever new facts are added to , as is done (for exam- ple) in conjunctions where each conjunct is optimized given the assumption that all other conjuncts hold, the facts are combined with the state invariants with limited use of a res- olution algorithm. This may yield further facts to be added to , signi cantly strengthening the information available to the optimizer. Below, the inference procedure will be denoted by infer ( Ψ) , where is a set of known formulas, is a set of state invariants, and the return value is a set of formulas con- taining and possibly additional formulas that are entailed by Trans ( Ψ) As can be seen in the benchmark tests later in this paper, the use of state invariants can indeed have a signi cant im- pact on the performance of the planner, decreasing the time required for some blocks world problems by a factor of 3. Consequently, a future version of TALplanner will be inte- grated with one of the existing automatic analysis methods.
Page 7
New Domain Analysis Techniques for Domain-Dependent Control For most planning domains, TALplanner spends a signi cant amount of time testing incremental pruning constraints in fact, this often accounts for more than 99% of the time used by the planner. Clearly, any technique that allows the incremental constraints to be tested more quickly will have a considerable impact on performance. The incremental pruning constraints mainly depend on the state or states generated by the latest operator invoca- tion, and although the preprocessor cannot know in advance which operator instance was invoked, it can know which op- erator type was invoked (such as drive or ﬂy there is a sep- arate set of constraints incr for each operator type . This leads to the idea of attempting to extract some information from the operator de nitions regarding the states in which the constraints will be evaluated, and then using this context information in the formula optimizer. Current versions of TALplanner make use of two different kinds of context information automatically extracted from operator de nitions. First, the preconditions must hold (otherwise the opera- tor would not have been invoked) and the effects must hold (since if they were inconsistent the planner would already have backtracked). This can be used to augment the set of known formulas provided to the optimizer in the optimiza- tion context. Second, many control rules are only triggered by certain speci c state transitions, and the only state transitions that are possible during the execution of an operator are those that are explicitly speci ed in the effects. Analyzing these transitions makes further optimizations possible. Before the operator analysis is described in detail, Fig- ure 3 provides an overview of the complete formula opti- mization process. The planner analyzes each operator de nition to extract a set of facts that must hold at various points during the execution of any instance of the operator. These facts are combined with the state invariants (provided by the user or an automatic domain analyzer) to generate a set of context facts which is given to the formula optimizer as part of the optimization context. The optimizer also makes use of state transition information automatically extracted from the operator de nitions. Operator Analysis: Extracting Facts Let be an operator type (for example, drive ). When an instance of this operator type is invoked (for example, [0 1] drive tru1 pos1 pos2 ), the formal invocation time- point is bound to the actual invocation timepoint, and the formal arguments are bound to their actual values ( is bound to truck to tru1 , and so on). If the precondition is not satis ed, the operator is never applied. If it is satis ed, the effects are applied, and if they are inconsistent, the planner backtracks. In other words, the incremental pruning constraints in incr are only tested if both the precondition and the effects hold. Consequently, a set of known facts can be extracted from the operator quite easily. Let be the precondition of be a conjunction definition Optimized Operator Incremental constraint Planning problem State Fact State constraint generator optimizer Formula resolution extraction + Context constraints facts constraint Transition information analyzer transition State Figure 3: Control Analysis and Optimization of xed uent formulas extracted from the unconditional ef- fects of the action (for example, the effect +3] at o,l ):= false generates the formula +3] at o,l ) false ), and be the set of state invariants speci ed in the domain def- inition. Then, the initial set of known formulas is Φ= infer Ψ) For example, the drive operator yields the formulas =[ at truck loc1 city of loc1 ) city of loc2 loc1 loc2 and =[ +1] at truck loc1 ) false +1] at truck loc2 ) true . Additional facts may be in- ferred from this using state invariants and resolution, and these facts can then be used in the optimizer in order to de- termine that a certain formula must or cannot hold. Note that both the formal invocation timepoint of the op- erator and its formal arguments can occur as free variables in or . When the constraints in incr are tested, the for- mal arguments will be bound to the values used during the latest operator invocation, as stated in the de nition of incr In this way, an incremental pruning constraint can refer di- rectly to the arguments of the corresponding operator invo- cation. (Since all variables in pruning constraints and state invariants have been renamed and replaced with fresh vari- ables, there is no risk of mistaking one instance of a variable for another.) Generating Bindings using State Transition Analysis Many control rules can only be violated if certain state tran- sitions take place. This is a natural consequence of the fact that many control rules follow a certain pattern, where a property true in one state should either be preserved to the next state or violated in a very speci c way. For example, the incremental pruning constraints gener- ated from only-load-when-necessary state that a package should only be loaded into a plane if a plane is needed to move it. This can also be stated in another way: If a pack- age is not in a plane in a certain state, then it should remain not in that plane in the next state, unless a plane is needed in order to move it. As long as the property in obj plane is preserved from to +1 , the constraint cannot be violated. As another example, the incremental pruning constraints generated by objects-remain-at-destinations state that if a package is at a certain location at , it must be at that lo-
Page 8