A Planner Independent Approach to Human Interactive Planning

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 1

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 2

Applications Immersive Learning Environment (MRE) [J. Gratch, S. Marsella, J. Rickel, D. Traum] Force Deployment Plan (JADE) [A. Mulvehill, M. Cox] Emergency Relief Mission (TRIPS) [J. Allen, G. Ferguson] 3

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 4

How to make direct use of AIPS • E. g. , Collaborative Planning (Allen and Ferguson) – Traditional planners are unsuitable for use in incremental, usercentered 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 SOLUTION: Plan Reasoning Capability (HIPS) map Traditional Planning Problem 5

Generic planning services Common 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 Undo operation Abstract plan Evaluate alternatives Modify 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 Cancel plan / replan 6

Planning Service Request A Planning service request transform Planning problem_2 Planning problem_n Planner (Blackbox) Planning problem_1 Result 2 Result n Summarize the result to user 7

HIPAS Architecture A set of abstract planning service requests 8

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 9

Generic planning services Common problem solving Planning service requests Evacuate-injured-boy operations (Allen & Ferguson) (HIPAS) Introduce objectives Introduce a set of goals Refine a goal Select appropriate hierarchical action set for the goals Modify/correct solution Ambulance Undo operation Medevac Abstract plan Evaluate alternatives possible There are two Modify goal Add/drop goal Check-route Specify solution Call. Ambulance Extend solution Secure. Accident area Compare options/solution Bring-boy-to- Select/reject option hospital-by-AMB Cancel plan Callways to move the boy to medevac hospital, one is by Amb, and User-intended ordering or Med. Secure- the other is by Currently, there is only Landing zone variable binding one way to do that, by Move. Refine Plan ambulance. ” boy-to-LZ Check interaction/evaluate Moveplan/compare options MED-to-LZ Bring-boy-to. Select/reject option hospital-by-MED Cancel plan / replan 10

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 11

Planner as a “blackbox” Dialogue manager T Refine plan: Move-boy-to-hospital Move-boyto-hospital Ambulance Medevac Current plan set a 1 C, D, F, T Generate a domain Theory For each alternative Move the boy to hospital m 1 m 2 a 3 c 1 c 2 d 1 f 2 a 2 f 1 a 2 a 3 c 1 c 2 d 1 f 2 m 1 f 1 m 2 Planner (Blackbox) Succeed Fail 12

Hierarchical action set (example) Evacuate-injured-boy Ambulance Check-route Call-ambulance secure. Accident area Wait-for-AMB Medevac Callmedevac Secure. Landing zone Moveboy-to-LZ Move. MED-to-LZ Bring-boy-tohospital-by-MED 13

Hierarchical action set (example) Obtaining a shelter Rent an APT Searching classified ads Visiting APTs Buy a house Placing deposit Getting a real estate agent Getting loan preapproval Visiting open houses 14

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, goals, undo actions, replan, …… add/drop • 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? 15

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 16

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. 17

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 18