1
A Planner Independent Approach to Human Interactive Planning
Aug 09, 2003
Hyeok-Soo Kim and Jonathan Gratch
University of Southern California and Institute for Creative Technologies
2
Human Interactive Planning System
• Collaborative planning systems– Each provides what it does best
• Human– Specification of the goals– Highly-developed problem-solving strategies– Subjective evaluation of the plans
• Agent (computer)– Systematic management– Bookkeeping – allocating and scheduling resources
3
Applications
Emergency Relief Mission (TRIPS)[J. Allen, G. Ferguson]
Immersive Learning Environment (MRE)[J. Gratch, S. Marsella, J. Rickel, D. Traum]
Force Deployment Plan (JADE) [A. Mulvehill, M. Cox]
4
PROBLEM: Modularity• Difficult to add new capability
– High dependency across each component
• Antiquated planning technologies in HIPS– Reasons
• A number of capabilities are tightly integrated• Lack of modularity
– Limit the generality
• Independent planning module– Rapid evolvement of planning techniques
• The top performing planners are in constant flux– Performance varies widely across domains
• Diff. Planners excel on diff. Domains
5
How to make direct use of AIPS• E.g., Collaborative Planning (Allen and
Ferguson) – Traditional planners are unsuitable for use in incremental, user-
centered collaborative planning • Need incremental plan AIPS not• Need add/drop constraints AIPS: fixed constraints• Need partial development AIPS: complete plan
– Their conclusion • Build their own custom planner with pluggable sub-modules
• Mismatch in APIs– HIPS : dialogue (speech acts)
• Introduce goals, refine an action, modify plan, create/compare/reject options, evaluate plan,
add/drop goals, undo actions, replan, …… – Traditional Planner : domain theory, initial and goal states
Plan Reasoning Capability (HIPS)
SOLUTION: map Traditional PlanningProblem
Traditional PlanningProblem
6
Generic planning servicesCommon problem solving
operations (Allen & Ferguson)
Planning service requests (HIPAS)
Introduce objectives Introduce a set of goals
Refine a goal Select appropriate hierarchical action set for the goals
Modify/correct solution Abstract planUndo operationEvaluate plan Evaluate alternativesModify goal Add/drop goal
Specify solution User-intended ordering or variable binding
Extend solution Refine plan
Compare options/solution Check interaction/evaluate plan/compare options
Select/reject option Select/reject optionCancel plan Cancel plan / replan
7
Planning Service Request
A Planning service request
Planning problem_1
Planning problem_2
Planning problem_n
transform
Planner (Blackbox)Result 1
Result 2
Result n
Summarize the result to user
8
HIPAS Architecture User
Dialogue manager User speech act System speech act
Planning service requests
Find plan
Refine plan
Abstract plan
request state info
Check interaction
API
HIPAS
Domain theory
Initial state
Goal state
Acting Sensing & Monitoring
Environment
Replies about the requests
API
API
Planner
Add/drop goals
A set of abstract planning service requests
9
New representational structures• Hierarchical action set
– A tree-like AND/OR graph • Representing hierarchical decomposition rules
– An abstract action• An unordered set of relative primitive actions • In conventional hierarchical planning system
– A high-level sequence of actions to perform– The speed of modern non-hierarchical planning
algorithms– The control and flexibility of human-interactive
hierarchical planning
• Current plan set– To keep track of development of a plan
10
Generic planning servicesCommon problem solving
operations (Allen & Ferguson)
Planning service requests (HIPAS)
Introduce objectives Introduce a set of goals
Refine a goal Select appropriate hierarchical action set for the goals
Modify/correct solution Abstract planUndo operationEvaluate plan Evaluate alternativesModify goal Add/drop goal
Specify solution User-intended ordering or variable binding
Extend solution Refine Plan
Compare options/solution Check interaction/evaluate plan/compare options
Select/reject option Select/reject optionCancel plan Cancel plan / replan
Refine Plan
Evacuate-injured-boy
Ambulance Medevac
Check-route
Call-Ambulance
Secure-Accident area
Bring-boy-to-hospital-by-AMB
Call-medevac
Secure-Landing zone
Move-MED-to-LZ
Bring-boy-to-hospital-by-MED
Move-boy-to-LZ
Check-route
Call-Ambulance
Secure-Accident area
Bring-boy-to-hospital-by-AMB
Call-medevac
Secure-Landing zone
Move-MED-to-LZ
Bring-boy-to-hospital-by-MED
Move-boy-to-LZ
There are two possible ways to move the boy to
hospital, one is by Amb, and the other is
by Med. Currently, there is only one way
to do that, by ambulance.”
11
Conclusion• Being applied in MRE (Mission Rehearsal Exercise)
– Virtual training environment– Extending the planning capabilities– More modular planning component
• Easier to update with more advanced planning techniques
• Future works– expanding planning service requests
• e.g., post user-specified ordering constraints– Applying more planners to more applications– Various-degreed representation of goal achievability– True failure/cut off computational difficulty
12
Planner as a “blackbox”
Move the boy to
hospital
Dialogue manager
Refine plan:Move-boy-to-hospital Move-boy-
to-hospital
m1a1 a2a3
m2
T
Ambulance Medevac
C, D, F, T
Planner (Blackbox)
Succeed Fail
c1f2
c2 d1 f1a1 a2 a3
c1f2
c2 d1 f1m1 m2
Generate a domain Theory
For each alternative
Current plan set
13
Hierarchical action set (example)
Evacuate-injured-boy
Ambulance Medevac
Check-route
Call-ambulance
secure-Accident area
Wait-for-AMB
Call-medevac
Secure-Landing zone
Move-MED-to-LZ
Bring-boy-to-hospital-by-MED
Move-boy-to-LZ
14
Hierarchical action set (example)
Obtaining a shelter
Rent an APT Buy a house
Searching classified
adsVisiting
APTsPlacingdeposit
Getting areal estate
agent
Getting loan pre-approval
Visitingopen
houses
15
Independent Planning module• Difficulties
– Planning and user-interface module are tightly intertwined
– Mismatch in APIs• HIPS : dialogue (speech acts)
– Introduce goals, refine an action, modify plan, create/compare/reject options, evaluate plan, add/drop goals, undo actions, replan, ……
• Traditional Planner : domain theory, initial and goal states
• What is the right API?• What is the generic planning services?• How to define these services?• How to map b/w these services and the low-level
API of planning system?
16
Current Limitation in HIPS• Difficult to add new capability
– High dependency across each component
• Antiquated planning technologies in HIPS– Reasons
• A number of capabilities are tightly integrated• Lack of modularity
– Limit the generality
• Goals– Leverage advance in planning community– Modulize planning component
• Plug-and-play• Ease replacement
– As improved techniques become available– depending on the characteristics of the application
17
Rapid Evolvement• The top performing planners are in constant flux
– 1998• IPP : ADL and STRIPS domains• HSP : STRIPS (solved most problems)
– 2000• FF replaced IPP
– 2002• MIPS : produced solutions in each track• FF : STRIPS
• None of these techniques have been incorporated into state-of-the-art Human Interactive Planning systems.
18
No Magic Planner
• Performance varies widely across domains
– Diff. Planners excel on diff. Domains• Specific planner for specific task
– AIPS competition 2002• FF : numeric and STRIPS
didn’t compete in temporal domains• TALPlanner : temporal domains
didn’t participate in numeric domains