1 / 18

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. Human Interactive Planning System. Collaborative planning systems Each provides what it does best Human

naida
Download Presentation

A Planner Independent Approach to Human Interactive Planning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Force Deployment Plan (JADE) [A. Mulvehill, M. Cox] Applications Emergency Relief Mission (TRIPS) [J. Allen, G. Ferguson] Immersive Learning Environment (MRE) [J. Gratch, S. Marsella, J. Rickel, D. Traum]

  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 SOLUTION: Plan Reasoning Capability (HIPS) map Traditional Planning Problem Traditional Planning Problem

  6. Generic planning services

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

  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. Ambulance Medevac Call- medevac Call- medevac Check-route Check-route Secure- Landing zone Secure- Landing zone Call- Ambulance Call- Ambulance Move- boy-to-LZ Move- boy-to-LZ Secure- Accident area Secure- Accident area Move- MED-to-LZ Move- MED-to-LZ Bring-boy-to- hospital-by-AMB Bring-boy-to- hospital-by-AMB Bring-boy-to- hospital-by-MED Bring-boy-to- hospital-by-MED Generic planning services Evacuate-injured-boy 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.” Refine Plan

  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” Dialogue manager T Refine plan: Move-boy-to-hospital Move-boy- to-hospital Ambulance Medevac Current plan set a1 a2 m1 m2 C, D, F, T a3 Generate a domain Theory For each alternative c1 c2 d1 f1 c1 c2 d1 f1 f2 a1 a2 a3 f2 m1 m2 Move the boy to hospital Planner (Blackbox) Succeed Fail

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

  14. Hierarchical action set (example) Obtaining a shelter Rent an APT Buy 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

More Related