Encoding HTN Planning as a Dynamic CSP

1. Encoding HTN Planning as a Dynamic CSP A First Step to Application of CP in Planning Domain Pavel Surynek Charles University, Prague pavel.surynek@seznam.cz CP 2005, Doctoral Programme

2. Location A Location B Location A Location B Initial state Goal state Actions Why HTN planning ? • Traditional planning (STRIPS) • Initial world state • Set of actions changing the world state (+ conditions under what they can be used) • Goal state of the world • Plan = Sequence of actions transforming the initial world state into a goal state of the world NOT easy to incorporate any kind of domain knowledge Pavel Surynek CP 2005, Doctoral Programme

3. Task reduction schema Task Task network HTN Planning • Augments the traditional action based model with: • Grammar of legal solutions • Reduction schemas • Initial state same as in STRIPS • Goal state again same as in STRIPS • But actions are more expressive • HTN Planning uses tasks and task networks • e.g.:transportPeople:-transportPeopleByBusor transportPeopleByTrain Pavel Surynek CP 2005, Doctoral Programme

4. Location A Location A Location B Location B Location A Location B Initial state Goal state Goal state transportPeopleByBus transportPeopleByTrain and and and and getIntoTrain getIntoBus travel travel getOff getOff Plan #1 Plan #2 Details of HTN Planning • Plan = Again sequence of actions (tasks without reduction schemas) transforming initial state into goal state • Only the sequences accepted by the grammar are legal plans  reduction of the search space transportPeople:-transportPeopleByBus or transportPeopleByTrain transportPeople or transportPeopleByBus :- getIntoBus, travel, getOff | getIntoBus<travel<getOff Pavel Surynek CP 2005, Doctoral Programme

5. Always bound with its superior task k-moments of execution Location A Location B The CSP model: static properties • For a given HTN planning problem a k-step(hierarchical)CSP model is constructed • Variables are used to encode: • Tasks • e.g.: transportPeople{ , } • Actions • e.g.: getIntoBus{ , , … , } • World states • e.g.: busAt(time){ , } Pavel Surynek CP 2005, Doctoral Programme

6. e.g.: e.g.: if getIntoBus = 1 then busAt(1)=Location A and peopleAt(1)=Location A and peopleAt(2)=Bus busAt(1)=Location B and trainAt(1)=Location Band peopleAt(1)=Location A The CSP model: constraints • Preconditions and effects of the actions • Initial state • Task constraints are more difficult • Constructed hierarchically Pavel Surynek CP 2005, Doctoral Programme

7. transportPeopleByBus :- getIntoBus, travel, getOff | getIntoBus<travel<getOff transportPeopleByTrain :- getIntoTrain, travel, getOff | getIntoTrain<travel<getOff Subproblem B Subproblem A The CSP model: task constraints • Each task constraint is associated with reduction subproblems example: transportPeople task is modelled as transportPeople (Subproblem A) or (Subproblem B) ((Subproblem A) or (Subproblem B)) and (if transportPeople=Bus then Subproblem A) (if transportPeople=Bus then Subproblem A) and (if transportPeople=Train then Subproblem B) Pavel Surynek CP 2005, Doctoral Programme

8. Dynamic properties of the model • Described model is constructed dynamically as the search proceeds • Depth of the hierarchical model is always limited • When the task variable is instantiated the model is extended with the corresponding subproblems Newconstraintmodel transportPeople  Bus Constraint model Propagation Pavel Surynek CP 2005, Doctoral Programme

9. Conclusions: issues to solve • Amount of model extension after variable instantiation or domain narrowing • deeper/larger extension  more constrained model, but larger memory consumption • How to combine constraints via logical conjunctions • reification is easy to implement, but provides weak propagation • the model uses lot of disjunctive constraints (construct if then), constructive disjunction is more suitable • Experimental evaluation of the proposed encoding ! Pavel Surynek CP 2005, Doctoral Programme