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