Automatic Discovery and Exploitation of Domain Knowledge in Planning as Constraint Satisfaction

1
Automatic Discovery and Exploitation of Domain
Knowledge in Planning as Constraint Satisfaction

• Steve Wolfman

2
Current Domain Specialization in Planning as
Constraint Satisfaction

• Simple heuristics in constraint solvers
• unit propagation, pure literal elimination,
  k-clause resolution,
• not directed at planning
• Hand encoded systems
• experts define heuristics for problems
• encodings restrict search according to heuristics

3
CPlanvan Beek and Chen, 1999

• Hand encoded CSP Planner
• Uses expressive CSP variant
• variables have arbitrary (finite) domains
• constraints are user-defined functions over
  variables
• Suggests goals for domain specialization
• efficient encodings
• heuristic information

4
PGH
AIRPORT
DC
STOP
STOP
1
3
1
4
2
AIRPORT
BOS
STOP
2
3
AIRPORT
5
Goals

• Identify targets for automation of domain
  specialization
• Synthesize analysis and reformulation techniques
  with CPlan/CSP Planning systems
• Augment analysis and reformulation techniques

6
Outline

• Motivation
• Planning as Constraint Satisfaction
• TIM Plan Level
• PABLO Compilation Level
• Symmetry Breaking CSP Level
• Conclusions and Future Directions

7
CSP Planning
8
Weaknesses of CSP Planning

• All plans are equal
• uninformed search
• combinatorially large search space
• Each compilation step is an island
• no knowledge passed between steps
• Encodings are huge
• variable domains drastically restricted
• only one simple type of constraint used

9
Domain Specialization Desiderata

• Heuristic information
• lower bounds on subplan lengths
• symmetries over objects
• Connected compilation steps
• meaningful progression of compilation steps
• carryover of effort between steps
• Efficient CSP encodings
• compact predicate representations
• effective use of varied constraints

10
Opportunities for Specialization

• Plan level (TIM)
• all information available
• old analyses still applicable
• Compilation level (PABLO)
• high level search control
• currently very little specialization
• CSP level (Symmetry breaking)
• independent of plan or compilation level
• most heavily used

plan level
Planning
problem
compilation
Compiler
level
CSP level
Solver
11
Outline

• Motivation
• Planning as Constraint Satisfaction
• TIM Plan Level
• PABLO Compilation Level
• Symmetry Breaking CSP Level
• Conclusions and Future Directions

12
TIM Fox and Long, 1998

• Operates at plan level
• Analyzes simplified problems
• unary predicates and actions
• no preconditions
• Infers types for objects
• Derives invariants over types

13
Domain Specialization with TIM

• Efficient encodings
• select variable identities
• define domain values
• Lower bounds on subplan lengths
• remove object interactions
• derive plan length
• Enhanced type information
• reduce number of instantiated actions

14
Simplification

• Ignore preconditions/unchanged properties
• Trace each object separately through actions

Load(pack, veh, site) pre at(veh,
site), at(pack, site) add in(pack,
veh) del at(pack, site)
Load1 add in1 del at1
Load2 add in2 del
Load3 add del at2
15
Type Construction

• Each property defines a type
• Group types based on actions
• Form type spaces

at1
Load1 add in1 del at1
Load1
Unload1
in1
16
Identity Invariants

• Examine each type space, T, for invariants
• If a property P1 appears at most once, P1
  participates in an identity invariant
• if two P predicates are true of one object of
  type T, all other arguments of P must be equal

Load1
at1
in1
at(truck1,x) ? at(truck1,y) ? x y
Unload1
17
Applying TIM in CPlanEfficient Encodings

• Subject of identity invariant becomes variable
• Domain is other objects in predicate

at(package1,pgh-stop)
true, false

18
Applying TIM in CPlanTuning Encoding

• Other invariants lead to more compact encoding
• merge multiple variables (e.g., in1 and at1
  variables)
• remove dummy values

19
Outline

• Motivation
• Planning as Constraint Satisfaction
• TIM Plan Level
• PABLO Compilation Level
• Symmetry Breaking CSP Level
• Conclusions and Future Directions

20
PABLOChristensen, 1990

• Operates at the compilation level
• Relaxes predicates
• constructs miniature plans for predicates
• relaxed predicates true when mini-plan
  preconditions are true
• Builds abstraction hierarchy
• plans with relaxed predicates
• removes detail at higher abstraction levels
• failure at higher level guarantees failure at
  ground

21
Domain Specialization with PABLO

• Connected compilation steps
• success at high level suggests possible concrete
  solution
• abstract solution is starting point for next
  level
• Lower bounds on subplan lengths
• shortest mini-plan for a predicate yields lower
  bound

22
Relaxed Predicates

• One level predicate itself or regression of
  predicate through any action
• Regression conjunction of action preconditions

Regression
Predicate
Relaxed predicate
Unload(pck,truck, site)
in(pck,truck), at(truck,site)
OR
at(pck,site)
at(pck,site)
OR
Unload(pck,plane, site)
in(pck,plane), at(plane,site)
23
Relaxed Predicates (cont.)

• Predicate P relaxed to level n

24
Abstraction Hierarchy

• Level 0 is original problem (ground)
• Level k replaces action preconditions Pi with
  relaxed versions Pik
• Top level is last one before all relaxed goals
  are true in initial conditions
• Planning proceeds from top level down

25
Abstraction in CSP Planning
26
Applying PABLO in CplanAbstraction without
Failure

• CSP Planners cannot report failure
• no guarantee that a longer plan does not exist
• PABLO is incomplete with semi-decidable planner
• Solution do not commit to abstract plan
• local search constraint solver
• use abstract plan to seed initial variable
  assignment
• systematic search constraint solver
• use abstract solution at the top of the tree
• use dynamic backtracking to gradually correct
  solution if necessary

27
Applying PABLO in CplanPlan Refinement in CSPs

• Standard encodings do not support refinement
• fixed order, contiguous steps
• interleaving new steps is infeasible
• Solution use causal encoding MK1999
• step order initially unconstrained
• add abstract solution and minimal necessary
  constraints

28
Outline

• Motivation
• Planning as Constraint Satisfaction
• TIM Plan Level
• PABLO Compilation Level
• Symmetry Breaking CSP Level
• Conclusions and Future Directions

29
Symmetry Breaking Crawford et al., 1996

• Operates at the CSP Level
• Compilation process totally irrelevant
• Plan level mostly irrelevant
• Searches for interchangeable variables
• Eliminates interchangeability with arbitrary
  variable preference

30
Domain Specialization with Symmetry Breaking

• Symmetric object detection
• detects resources (interchangeable objects)
• detects more complex symmetries
• forces investigation of only one symmetric choice

31
Symmetry Detection by Automorphisms

• automorphism a color-preserving relabelling of a
  graph which creates an identical graph
• Rewrite SAT problem as graph
• automorphisms in graph represent symmetries in
  SAT problem
• Find automorphisms in graph
• use existing, high-performance automorphism
  package (nauty)

32
Example Transformation
(a ? ?c) ? (b ? ?c) ? (a ? b ? c) ? (?a ? ?b)
a
?a
b
?b
3
c
?c
33
Graph Form

• Variable
• Red node for variable
• Blue node for negation
• Edge connecting the pair
• Clause
• Yellow node for clause
• Edge to each variable and negation in clause
• Binary clauses replaced by edge between variables

34
Breaking Symmetries

• Insert clause disallowing all but one arrangement
• Various improvements to efficiency

35
Finding Symmetries in CPlanExample Augmented
Transformation
(a ? ?c) ? (b ? ?c) ? (a ? b ? c) ? (?a ? ?b)
T
F
T
F
3
T
F
36
Finding Symmetries in CPlanAugmented Graph Form

• Variable
• Black node for each variable
• Colored node for each domain value
• Edge connecting variable to each domain value
• Clause
• Unique color for each type of constraint
• Otherwise unchanged

37
Applying Symmetries in CPlan CSPs with
Augmented Form

• Many values from one variable node
• reverse of binary clause optimization
• ensures variable and values move together
• New types of constraints with new colors
• colors guarantee separate treatment for each type
• types are completely incomparable
• constraints must be symmetrical

38
Outline

• Motivation
• Planning as Constraint Satisfaction
• TIM Plan Level
• PABLO Compilation Level
• Symmetry Breaking CSP Level
• Conclusions and Future Directions

39
Conclusions

• Identified target structure and information for
  automation of domain specialization
• Categorized analysis and reformulation techniques
  in terms of CSP Planning
• Described methods for integrating analysis and
  reformulation techniques with CPlan

40
Conclusions (paper)

• Identified important properties for reformulation
  engines used with CSP Planners
• Proposed extensions to reformulation systems
• Explained assumptions implicit in TIM

41
Future Directions

• Automate CPlan system
• integrate analyses into CPlan framework
• compare alternative abstraction systems
• prune excess heuristic information
• add new analyses (e.g., reachability)
• Extend analyses
• refine TIM type system
• allow object symmetries in Joslin and Roy system
• Mixed-initiative domain specialization

42
Related Work

• ILPPlan KW1999 CSP Planning systems suggest
  target heuristics
• DISCOPLAN GS1998 performs complementary plan
  level analysis to TIM
• ALPINE K1990 abstraction system does not
  require interleaving steps
• JoslinRoy 1997 describe planning-directed
  improvements to symmetry detection

43
Questions?
Why am I driving on both sides?
44
Planning as Constraint Satisfaction (CSP Planning)

• Input a planning domain and problem
• Pick a plan length k
• Construct a Boolean satisfiability (SAT) problem
  encoding every plan of length k
• If SAT problem is solveable, decode into plan
• Otherwise, increment k and recompile

45
Example Actions

• Load(package, vehicle, site)
• pre small(package), vehicle(vehicle),
• location(site), at(package, site),
• at(vehicle, site)
• add in(package, vehicle)
• del at(package, site)

Drive(vehicle, from, to, city) pre vehicle(vehic
le), location(from), location(to),
city(city), in-city(from, city), in-city(to,
city), at(vehicle, from), add at(vehicle,
to) del at(vehicle, from)
46
Example Problem

• Initial conditions
• at(truck1,pgh-stop),
• at(truck2,pgh-stop),
• at(truck3,bos-stop),
• at(truck4,dc-stop),
• at(plane1,pgh-airport),
• at(package1,pgh-stop),
• at(package2,bos-stop),
• at(package3,dc-stop),
• in-city(pgh-stop,pgh), in-city(pgh-airport,pgh),
• in-city(bos-stop,bos), in-city(bos-airport,bos),
• in-city(dc-stop,dc), in-city(dc-airport,dc)

Goal at(package1,pgh-airport),
at(package2,dc-stop), at(package3,bos-stop)
47
Example Compiled Action

• Load(package1,truck2,pgh-airport,step-1) ?
• at(package1,pgh-airport,step-1) ?
• at(truck2,pgh-airport,step-1) ?
• in(package1,truck2,step-2) ?
• at(package1,pgh-airport,step-2)

Each time-stepped predicate and action (e.g.,
at(package1,pgh-stop,step-1)) is represented by a
Boolean variable.
48
Type Inference

• Find properties of each object in initial state
• Object type is subtype of all properties types

at1
at(truck,site1) in(dog,truck) fuelled(truck)
in2
fuelled1
at1,in1
fuelled1
in2
49
Abstraction planning

• Input a planning domain and problem
• Start at highest abstraction level k
• Plan with goals and actions relaxed to k
• If no solution exists, increment k
• If a solution exists and k gt 0, decrement k,
  continue planning from abstract solution
• If a ground solution exists, return it