Practical Hierarchical Task Network (HTN) Planning Examples of using - - PDF document
Practical Hierarchical Task Network (HTN) Planning Examples of using - - PDF document
Practical HTN Planning Putting HTN Planning into Use Practical Hierarchical Task Network (HTN) Planning Examples of using the core HTN technique along with other essential planning, search and constraint satisfaction technologies to realise
2
Practical HTN Planning 2
Literature
- Human Planning
- Klein, G. (1998) Sources of Power: How People Make Decisions, MIT Press.
- Refinement Search
- Kambhampati, S., Knoblock, C.A. and Yang, Q. (1995) Planning as Refinement Search: A Unified
Framework for Evaluating Design Tradeoffs in Partial-Order Planning, Artificial Intelligence, Vol. 76, No. 1- 2, pp. 167-238, Elsevier.
- Nonlin
- http://www.aiai.ed.ac.uk/project/nonlin/
- Tate, A. (1977) Generating Project Networks, Proceedings of the Fifth International Joint Conference on
Artificial Intelligence (IJCAI-77) pp. 888-893, Boston, Mass. USA, August 1977.
- O-Plan
- http://www.aiai.ed.ac.uk/project/oplan/
- Currie, K and Tate, A. (1991) O-Plan: the Open Planning Architecture, Artificial Intelligence Vol. 52, No. 1,
pp 49-86, Elsevier.
- Other Practical Planners
- Ghallab, M., Nau, D. and Traverso, P., Automated Planning – Theory and Practice, chapters 19, 22 and
- 23. Elsevier/Morgan Kaufmann, 2004.
Literature
Further practical planning systems are described in several chapters of the course textbook… e.g. chapters 19, 22 and 23. Malik Ghallab, Dana Nau, and Paolo Traverso. Automated Planning – Theory and Practice. Elsevier/Morgan Kaufmann, 2004.
3
Practical HTN Planning 3
Overview
Human Approaches to Planning Practical HTN Planning Refinement Planning as a Unifying View Nonlin and O-Plan Features QA (Modal Truth Criterion) Time, Resource and Other Constraint Handling I-X/I-Plan Overview
4
Practical HTN Planning 4
- Expansion of a high level abstract plan into greater detail
where necessary.
- High level ‘chunks’ of procedural knowledge (Standard
Operating Procedures, Best Practice Processes, Tactics Techniques and Procedures, etc.) at a human scale - typically 5-8 actions - can be manipulated within the system.
- Ability to establish that a feasible plan exists, perhaps for a
range of assumptions about the situation, while retaining a high level overview.
- Analysis of potential interactions as plans are expanded or
developed.
- Identification of problems, flaws and issues with the plan.
- Deliberative establishment of a space of alternative options,
perhaps based on different assumptions about the situation involved, of especial use ahead of time, in training and rehearsal, and to those unfamiliar with the situation or utilising novel equipment.
Some Planning Features
5
Practical HTN Planning 5
- Monitoring of the execution of events as they are expected to
happen within the plan, watching for deviations that indicate a necessity to re-plan (often ahead of this becoming a serious problem).
- Represent the dynamic state of the world at points in the plan
and use this for ‘mental simulation’ of the execution of the plan.
- Pruning of choices according to given requirements or
constraints.
- Situation dependent option filtering (sometime reducing the
choices normally open to one ‘obvious’ one.
- Satisficing search to find the first suitable plan that meets the
essential criteria.
- Heuristic evaluation and prioritisation of multiple possible
choices within the constrained search space.
- Uniform use of a common plan representation with
embedded rationale to improve plan quality, shared understanding, etc.
More Planning Features
6
Practical HTN Planning 6
Previous slides describe aspects of problem
solving behaviour observed in expert humans working in unusual or crisis situations.
Gary Klein, “Sources of Power”, MIT Press, 1998. But they also describe the hierarchical and mixed
initiative approach to planning in AI developed
- ver the last 30 years.
Human Approach
7
Practical HTN Planning 7
HTN Planning is a useful paradigm… Compose workflows/processes from
requirements and component/template libraries
Covers simple through to very complex (pre-
planned) components
Allows for execution support, reactive repair,
recovery, etc.
Suited to mixed initiative (people and systems)
planning and execution
Gives an understandable framework within
which specialised constraint solvers, domain- specific planners (e.g. route finders), optimisers, plan analysers and simulators can work
HTN - Planning Approach
8
Practical HTN Planning 8
A1 A2 A3 A5 A4
“Initial” Plan Refine Introduce activities to achieve preconditions Resolve interactions between conditions and effects Handle constraints (e.g. world state, resource, spatial, etc.) “Final” Plan
A2.2 A2.1 A1 A3 A5 A4
Plan Library
A2 Refinement
S2 S1
HTN - Activity Composition
9
Practical HTN Planning 9 Refine Plan Library
Ax Refinement
S2 S1
P
Initial Plan can be any combination of Activities and Constraints
“Refined” Plan
A1.2 A1.1
Q P
“Initial” Plan
P Q
HTN – Initial Plan as “Goals”
10
Practical HTN Planning 10
Hierarchical Task Network Planning Partial Order Planner Plan Space Planner Goal structure-based plan development - considers
alternative “approaches” only based on plan rationale
QA/Modal Truth Criterion Condition Achievement Condition “Types” to limit search “Compute Conditions” for links to external data and
systems (attached procedures)
Time and Resource Constraint checks
Nonlin core is basis for text book descriptions of HTN Planning
Nonlin (1974-1977)
11
Practical HTN Planning 11
Nonlin Domain Language – TF
- pschema makeon
pattern {on $*x $*y} expansion 1 goal {cleartop $*x} 2 goal {cleartop $*y} 3 action {put $*x on top of $*y}
- rderings 1 ---> 3 2 ---> 3
vars x undef y undef; end;
- pschema makeclear
pattern {cleartop $*x} expansion 1 goal {cleartop $*y} 2 action {put $*y on top of $*z}
- rderings 1 ---> 2
conditions usewhen {on $*y $*x} at 2 usewhen {cleartop $*z} at 2 vars x <:non table:> y undef z <:et <:non $*x:> <:non $*y:> :>; end; actschema puton pattern {put $*x on top of $*y} conditions usewhen {cleartop $*x} at self usewhen {cleartop $*y} at self usewhen {on $*x $*z} at self effects + {on $*x $*y}
- {cleartop $*y}
- {on $*x $*z}
+ {cleartop $*z} vars x undef y undef z undef; end; always {cleartop table}; initially {on c a} {on a table} {on b table} {cleartop c} {cleartop b} ; plan goal {on a b} goal {on b c};
$*x is a variable
“typed” condition restricts search space example of search control knowledge
Nonlin Task Formalism (TF) Domain Description language Op schemas are the HTN “Methods”. Act schemas are the primitive operator schemas that are not further decomposable.
12
Practical HTN Planning 12
QA in a partially ordered network of nodes Way to establish value of a condition P=V at some point in the plan Yes/no/maybe responses Alternative Terminology:
- Contributors, deletors (Austin Tate, Nonlin, QA, Edinburgh, 1975-7)
- White nights and clobberers (David Chapman, MIT, MTC, 1987, 1st Formalisation)
- Producers, consumers (Some textbooks)
Initially just allowed imposition of orderings on nodes for a
condition, a b (ordering)
Later also allowed variables within condition to be constrained –
= (codesignation), ≠ (non-codesignation)
Intuitively, a white knight is an activity which re-establishes a
clobbered precondition p
A clobberer in a plan can be "defeated" by imposing ordering or
codesignation/non-codesignation constraints on the plan, or by inserting a white knight between the clobberer and the point where a condition is needed
QA/Modal Truth Criterion
13
Practical HTN Planning 13
QA/Modal Truth Criterion
Before After
P=V
Contributor No Effect Deletor
Need to ensure no deletor appears between a chosen contributor and point of need
Note that this lends itself to parallel implementations of the algorithms in the network of nodes. Note also that least commitment approaches can be used by using multiple disjunctive contributors to be kept unless some deletor needs to be excluded from the ranges.
14
Practical HTN Planning 14
O-Plan (1983-1999) Features
- Hierarchical Task Network Planning
- Nonlin-like goal-structure, QA and Typed/Compute conditions
- Partial-Plan “Refinement “ Approach
- Plan State has “flaws”/issues attached
- Agenda Architecture with Plan Modification Operations
- “Opportunistic Search” (agenda type, branch1/branch N)
- Multiple constraint managers with yes/no [and maybe] results
- Least Commitment Approach (on activity ordering,
- bject/variable bindings and other constraints)
- Constraint “Posting” rather than explicit commitments
(and/or trees with sets of “before” temporal constraints and variable binding (= and ≠) constraints) [as in MOLGEN]
- Goal structure recording and monitoring to preserve plan
rationale
15
Practical HTN Planning 15
O-Plan (1983-1999) Features
16
Practical HTN Planning 16
O-Plan Domain Language – TF
types objects = (a b c table), movable_objects = (a b c); always {cleartop table}; schema puton; vars ?x = ?{type movable_objects}, ?y = ?{type objects}, ?z = ?{type objects}; vars_relations ?x /= ?y, ?y /= ?z, ?x /= ?z; expands {puton ?x ?y};
- nly_use_for_effects
{on ?x ?y} = true, {cleartop ?y} = false, {on ?x ?z} = false, {cleartop ?z} = true; conditions only_use_for_query {on ?x ?z} achieve {cleartop ?x} achieve {cleartop ?y}; end_schema;
“typed” condition restricts search space example of search control knowledge
?x is a variable
O-Plan Task Formalism Domain Description language. Single schema for block stacking domain. Note “only_use_for_effects” is for ALL effects, since this is a general schema that can be used in any way. Generally in large domains you restrict the effects you are willing to allow a scheme to be selected to achieve to be the “main effects” it is meant to be used for. The condition type “only_use_for_query” means the schema would not allow this particular condition to ever be ACHIEVED by inserting new activities. This in turn restricts the search space, but means the planner cannot search the complete space of all possible plans in the domain… which seeks to prevent the generation of plans with redundant activities.
17
Practical HTN Planning 17
O-Plan Agent Architecture
18
Practical HTN Planning 18
O-Plan Agent Architecture
Later became
- Issues
- Nodes
- Constraints
- Annotations
Later became Plan Modification Operators
19
Practical HTN Planning 19
O-Plan Planning Workflow
20
Practical HTN Planning 20
Human relatable and presentable objectives, issues,
sense-making, advice, multiple options, argumentation, discussions and outline plans for higher levels
Detailed planners, search engines, constraint solvers,
analyzers and simulators act in this framework in an understandable way to provide feasibility checks, detailed constraints and guidance
Sharing of processes and information about process
products between humans and systems
Current status, context and environment sensitivity Links between informal/unstructured planning, more
structured planning and methods for optimisation
A More Collaborative Planning Framew ork
21
Practical HTN Planning 21 Shared, intelligible, easily communicated and
extendible conceptual model for objectives, processes, standard operating procedures and plans:
- I
Issues
- N
Nodes/Activities
- C
Constraints
- A
Annotations
Communication of dynamic status and presence for
agents, and reports about their collaborative processes and process products
Context sensitive presentation of options for action Intelligent activity planning, execution, monitoring, re-
planning and plan repair via I-Plan and I-P2 (I-X Process Panels)
I-X/I-Plan (2000- )
22
I – Issues - Plan Agenda - implied constraints on the plan N – Nodes - Plan Entities - Anchoring activities in a plan C – Detailed Constraints - Detailed Plan Constraints A – Annotations A model of a product being created, modified or used within an I-X system or agent is specified by giving a set of constraints on the whole space of legitimate products in the area of application. Nodes are the principal entity in the
- product. The decision to include a node is a very important
step in a system whose aim is to synthesise such a product description or model.
Practical HTN Planning 22
Constraints Issues Nodes
Plan State
Space of Legitimate Behaviours
Issues or Implied Constraints Node Constraints Detailed Constraints I N C A Annotations
<I-N-C-A> Framew ork
23
The I-X processing cycle begins with the selection of one or more of the outstanding issues in a product model. A handler is selected to address the issue(s). The handler is then called. This can lead to alterations to:
- 1. the nodes included in the product model (a key decision
for synthesis systems);
- 2. the introduction of constraints on the way in which the
nodes are related between themselves and to other entities in the application domain which are termed Node-Relatable Objects
- 3. the introduction of further issues or sub-issues to
handle. A constraint propagation loop is then activated which looks at the feasibility of introducing the constraints added by the issue handling loop. This can lead to further constraints being introduced to resolve constraint interactions, and can lead to even further issues which are passed back to the Issue Handler – possibly just to be posted into the Product Model for later handling.
Practical HTN Planning 23
Constraints Issues Nodes
Plan State
Space of Legitimate Behaviours
Issues or Implied Constraints Node Constraints Detailed Constraints I N C A Annotations
<I-N-C-A> & I-X
Do (IH) Choose (IH)
IH=Issue Handler (Agent Functional Capability)
Propagate Constraints
24
Practical HTN Planning 24
Anatomy of an I-X Process Panel
25
Practical HTN Planning 25
I-P2 aim is a Planning, Workflow and Task Messaging “Catch All”
- Can take ANY requirement to:
- Handle an issue
- Perform an activity
- Respect a constraint
- Note an annotation
- Deals with these via:
- Manual activity
- Internal capabilities
- External capabilities
- Reroute or delegate to other panels or agents
- Plan and execute a composite of these capabilities (I-Plan)
- Receives reports and interprets them to:
- Understand current status of issues, activities and constraints
- Understand current world state, especially status of process products
- Help user control the situation
- Copes with partial knowledge of processes and organisations
26
Process Panel
I-X Process Panel and Tools
Domain Editor Messenger I-Plan Map Tool
27
I-X for Emergency Response
Collaboration and Communication
Command Centre
Central Authorities Isolated Personnel
Emergency Responders
28
Planning Research Areas & Techniques Planning Research Areas & Techniques
Problem is to make sense
- f all these techniques
Problem is to make sense
- f all these techniques
Deals with whole life cycle of plans
- Search Methods
Heuristics, A*
- Graph Planning Algthms GraphPlan
- Partial-Order Planning
Nonlin, UCPOP
- Hierarchical Planning
NOAH, Nonlin, O-Plan
- Refinement Planning
Kambhampati
- Opportunistic Search
OPM
- Constraint Satisfaction
CSP, OR, TMMS
- Optimisation Methods
NN, GA, Ant Colony Opt.
- Issue/Flaw Handling
O-Plan
- Plan Analysis
NOAH, Critics
- Plan Simulation
QinetiQ
- Plan Qualitative Mdling
Excalibur
- Plan Repair
O-Plan
- Re-planning
O-Plan
- Plan Monitoring
O-Plan, IPEM
- Plan Generalisation
Macrops, EBL
- Case-Based Planning
CHEF, PRODIGY
- Plan Learning
SOAR, PRODIGY
- Plan Generalisation
Macrops, EBL
- Case-Based Planning
CHEF, PRODIGY
- Plan Learning
SOAR, PRODIGY
- User Interfaces
SIPE, O-Plan
- Plan Advice
SRI/Myers
- Mixed-Initiative PlanS
TRIPS/TRAINS
- Planning Web Services
O-Plan, SHOP2
- Plan Sharing & Comms
I-X, <I-N-C-A>
- NL Generation
…
- Dialogue Management
…
- Domain Modelling
HTN, SIPE
- Domain Description
PDDL, NIST PSL
- Domain Analysis
TIMS
29
Practical HTN Planning 29
Summary
Human Approaches to Planning Practical HTN Planning Refinement Planning as a Unifying View Nonlin and O-Plan Features QA (Modal Truth Criterion) Time, Resource and Other Constraint Handling I-X/I-Plan Overview