A Planner Independent Approach to Human Interactive Planning

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
Immersive Learning Environment (MRE) J. Gratch,
S. Marsella, J. Rickel, D. Traum

• Emergency Relief Mission (TRIPS)
• J. Allen, G. Ferguson

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
 
7
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
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
m1
a1
a2
m2
C, D, F, T
a3
c1
c2
d1
f1
c1
c2
d1
f1
Generate a domain Theory For each alternative
f2
a1
a2
a3
f2
m1
m2
Move the boy to hospital
Planner (Blackbox)
Succeed
Fail
13
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
• didnt compete in temporal domains
• TALPlanner temporal domains
• didnt participate in numeric
  domains