1 A Planner Independent Approach to Human Interactive Planning Aug 09, 2003 Hyeok-Soo Kim and...

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 services

Common problem solving operations (Allen &

Ferguson)

Planning service requests (HIPAS)

Introduce objectives Introduce a set of goals

Refine a goalSelect appropriate hierarchical action set for the goals

Modify/correct solutionAbstract plan

Undo operation

Evaluate plan Evaluate alternatives

Modify goal Add/drop goal

Specify solution User-intended ordering or variable binding

Extend solution Refine plan

Compare options/solutionCheck interaction/evaluate plan/compare options

Select/reject option Select/reject option

Cancel plan Cancel plan / replan

7

Planning Service Request

A Planning service request

Planning problem_1

Planning problem_2

Planning problem_n

transform

Pla

nner (B

lackb

ox)

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 services

Common problem solving operations (Allen &

Ferguson)

Planning service requests (HIPAS)

Introduce objectives Introduce a set of goals

Refine a goalSelect appropriate hierarchical action set for the goals

Modify/correct solutionAbstract plan

Undo operation

Evaluate plan Evaluate alternatives

Modify goal Add/drop goal

Specify solution User-intended ordering or variable binding

Extend solution Refine Plan

Compare options/solutionCheck interaction/evaluate plan/compare options

Select/reject option Select/reject option

Cancel 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

Dialogue manager

Refine plan:Move-boy-to-hospital Move-boy-

to-hospital

m1a1 a2

a3

m2

T

Ambulance Medevac

C, D, F, T

Planner (Blackbox)

Succeed Fail

c1

f2

c2 d1 f1

a1 a2 a3

c1

f2

c2 d1 f1

m1 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

ads

VisitingAPTs

Placingdeposit

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