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 Planning Problem Traditional Planning Problem

6 Generic planning services Common problem solving operations (Allen & Ferguson) Planning service requests (HIPAS) Introduce objectivesIntroduce a set of goals Refine a goal Select appropriate hierarchical action set for the goals Modify/correct solution Abstract plan Undo operation Evaluate planEvaluate alternatives Modify goalAdd/drop goal Specify solution User-intended ordering or variable binding Extend solutionRefine plan Compare options/solution Check interaction/evaluate plan/compare options Select/reject option Cancel planCancel 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 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 services Common problem solving operations (Allen & Ferguson) Planning service requests (HIPAS) Introduce objectivesIntroduce a set of goals Refine a goal Select appropriate hierarchical action set for the goals Modify/correct solution Abstract plan Undo operation Evaluate planEvaluate alternatives Modify goalAdd/drop goal Specify solution User-intended ordering or variable binding Extend solutionRefine Plan Compare options/solution Check interaction/evaluate plan/compare options Select/reject option Cancel planCancel plan / replan Refine Plan Evacuate-injured-boy AmbulanceMedevac 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 m1a1a2 a3 m2 T AmbulanceMedevac C, D, F, T Planner (Blackbox) SucceedFail c1 f2 c2d1f1 a1a2a3 c1 f2 c2d1f1 m1m2 Generate a domain Theory For each alternative Current plan set

13 Hierarchical action set (example) Evacuate-injured-boy AmbulanceMedevac 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 APTBuy a house Searching classified ads Visiting APTs Placing deposit Getting a real estate agent Getting loan pre- approval Visiting open 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