Evaluating Temporal Planning Domains

1
Evaluating Temporal Planning Domains
Daniel Weld Mausam

• William Cushing
• Subbarao Kambhampati
• Kartik Talamadupula

2
Competition winners are incomplete

• Epoch
• A time at which an event happens
• Decision Epoch Planning
• Only start actions after epochs

Temporal Planning

• How incomplete?
• What should the IPC measure?

Required Concurrency
3
How deep is the problem?

• Required Concurrency
• Languages
• Incomplete for temporally expressive languages
• Complete for temporally simple languages

4
(Minimal) Temporally Expressive Languages

• Temporal Gap
• Before-condition and effect
• After-condition and effect
• Two effects
• Temporally Simple ?? No Temporal Gap

5
No Temporal Gap ? Classical Scheduling
Essence of Temporal Planning

• Forbidding temporal gap implies
• All effects at one time
• Before-conditions meet effects
• After-conditions meet effects
• Unique transition per action

pre
A d

eff
6
Required Concurrency

• Inherently sequential is easy
• Timestamps (with support for arithmetic)
• Loose integration with a PERT scheduler
• TGP, LPG-td, SGPlan, MIPS,
• Required concurrency is hard
• The plan space is larger
• The scheduling sub-problem is harder
• Sub-problem optimality principle
• State of the art is VHPOP, LPGP, CRIKEY
• TEMPO, reduction to CSP

7
The International Planning Competition

• Benchmarks must not require (much) concurrency
• How much?
• None at all
• How do we show it?
• Use temporal gap?
• Problem every action has temporal gap

8
Solution Decompile temporal gap

• (navigate ?rover ?alpha ?omega)
• Pre (at start (at ?rover ?alpha))
• Eff (and
• (at start (not (at ?rover ?alpha)))
• (at end (at ?rover ?omega)))
• (navigate ?rover ?alpha ?omega)
• (over all (gt (at ?rover) ?alpha ?omega))

9
Causal Structure and Concurrency
light-match
B


C
A

fix-fuse

D
light-match
C
D
A
B
fix-fuse
Inherently Sequential
Inherently Concurrent
10
Navigates sequential structure
navigate
navigate
??
??
communicate
11
Technique Start-time Sequentialization
light-match
A
A
B
B
fix-fuse

• Do not want to enumerate plans!
• Nor every sequentialization!
• Start-time sequentialization
• Fixed attempt
• Suffices for benchmarks (not necessary)
• End-time sequentialization
• Critical-time sequentialization
• Start times of containing actions in same order
  as all dependencies

12
Element Safety

• Y lt X
• S(A(Y)) gt S(A(X))
• Threat-free
• X supports Z,
• Y threatens Z
• Interaction-free
• Z supports Y
• X threatens Y
• Link-free
• Y supports X

A
B
A
B
B
A
13
Benchmarks never require concurrency
(durative-action navigate parameters (?x -
rover ?y - waypoint ?z - waypoint) duration (
?duration 5) condition (and (at start (at
?x ?y)) MV Fluent (at start (gt (energy
?x) 8)) Resource Consumption (over all
(can_traverse ?x ?y ?z)) (at start (available
?x)) (over all (visible ?y ?z)) ) effect (and
(at start (decrease (energy ?x) 8))
Resource Consumption (over all (consume (energy
?x) 8)) Resource Consumption (at start
(not (at ?x ?y))) MV Fluent (at end (at ?x
?z)))) MV Fluent (over all (-gt (at ?x) ?y
?z)) MV Fluent ))

• Durative change on m.v. fluents is safe
• Unbounded resources are safe
• The Perils of Discrete Resource Models
• ICAPS workshop on IPC
• A few special cases
• (at end (calibrated ?c ?r))
• Document
• http//rakaposhi.eas.asu.edu/is-benchmarks.html
• Forthcoming

(at ?x - rover ?y - waypoint) (at ?x - rover )
- waypoint
14
Only RC due to Modeling Bugs

• 1 drop
• 1.1 drop
• 2.05 sample
• (and (full ?s) (empty ?s))
• 1 recharge
• 1.1 recharge
• 1.2 recharge
• (gt (energy ?x) ( k (capacity ?x)))

15
Syntactic Sugar for avoiding Errors

• Action drop (store)
• full(store) true at start
• full(store) false at end
• Should be at start
• empty(store) true at end
• Explicit resources
• amount(store) consume 1
• space(store) produce 1
• Explicit durative change m.v. fluents
• amount(store) full gt empty

16
Temporal Machine Shop

• Benchmarks lack required concurrency
• Real world lacks required concurrency?
• (durative-action fire-kiln
• parameters (?k - kiln)
• duration ( ?duration 20)
• effect (and (over all (lend (firing ?k)))
• (over all (gt (ready ?k) true false))
• (durative-action bake-ceramic
• parameters (?p - piece ?k - kiln)
• duration ( ?duration (bake-time ?p))
• condition (and (over all (firing ?k))
• (over all (shaped ?p)))
• effect (over all (gt (baked ?p) false true)))

17
Real world required concurrency

• (and
• (lifted bowl-left)
• (lifted bowl-right))
• Spray-oil (during milling)
• Heat-beaker (while adding chemicals)
• Ventilate-room (while drying glue)

18
Lessons for the Competition

• Competitors tune for the benchmarks
• Most of the competitors simplify to TGP
• Either required concurrency is important
• Benchmarks should test it
• Or it isnt
• Language should be inherently sequential
• PDDL spec. highlights light-match
• RC occurs in the real world
• Might need processes, continuous effects

19
Conclusion

• Required Concurrency separates easy and hard
  temporal planning
• The easy case allows offloading to a scheduler
• Still an intriguing problem
• Simplify the language push the classical track
• The hard case forces temporal reasoning by the
  planner
• Real world required concurrency is frequent
• PDDL 2.1.3 was designed for required concurrency
• But the benchmarks fell through
• Analysis of domains is hard
• Automatable? Embeddable within a search?
• Domain modeling is very hard
• Durative change
• Resources

When is Temporal Planning Really Temporal? IJCAI
2007
Evaluating Temporal Planning Domains ICAPS 2007
The Perils of Discrete Resource Models ICAPS
2007, IPC workshop
20
Research in Concurrent Planning

• William Cushing, advised by Subbarao Kambhampati

When is Temporal Planning Really Temporal? with
Mausam and Daniel Weld
Existing state-space temporal planners are
incomplete, yet win the competitions.
Evaluating Temporal Planning Domains with Kartik
Talamadupula, Mausam, and Daniel Weld
An epoch is a time at which an event happens
when a condition or effect is asserted. An
attempt at solving the problem of when to
dispatch actions is to make decisions only at
pre-existing epochs. Such decision epoch
planners overlook the possibility that an action
may need to start at a non-epoch. In the figure,
the only solution to fixing a blown fuse is
depicted light the match around the end of the
fixing fuse process (to avoid electrocution
during the critical step of placing the new fuse
in the socket). SGPlan, MIPS, SAPA, etc.,
incorrectly report no solution (or search
forever) when given an encoding of this problem.
The Perils of Discrete Resource Models with David
E. Smith
What is wrong with the competitions?
Can they be fixed?
Why are they incomplete?
Vacuously, they are incomplete because there is
one problem that they cannot solve. How many
more problems? What is common to the class of
problems that cannot be solved? Carrying out
this analysis at the level of temporal action
languages leads to a crisp characterization
decision epoch planners are complete for
inherently sequential languages and incomplete
for languages permitting required concurrency. A
language is inherently sequential when every
solution of every problem can be trivially
sequentialized a key result is that languages
which forbid required concurrency are inherently
sequential. That result does not hold for
planning domains or problems a planning domain
might have both sequential and non-sequentializabl
e solutions.
What is tested?
No, because the dispatch time of an action can
depend upon the future (arbitrarily far).
What should be tested?
Our analysis shows that domains lacking required
concurrency are, by and large, inherently
sequential. Since inherently sequential domains
can be efficiently solved using straightforward
integration of classical planning and PERT
scheduling (see SGPlan and MIPS) it makes more
sense to place such problems into the quality
sub-track of the classical track rather than in
the temporal track. That is, only those domain
features which present great difficulty to
planner or planner engineer should be separated
into separate tracks. In particular, the
temporal track should contain problems requiring
concurrency.
Not only do the benchmark problems never require
concurrency, but the domains themselves are
inherently sequential. More precisely, the
intended domains are inherently sequential,
however, there are a few subtle modeling errors
that allow the expression of problems requiring
concurrency. Proving this property of the
(intended) benchmarks is, however, complicated.
Sequentializable Plans
A plan is inherently sequential when its causal
dependencies permit a sequential scheduling of
its actions. The critical thing to show is that
if one event is causally dependent upon a
concurrent event then the order of the containing
actions start times in a nominal schedule is the
same as that required by the causal dependence.
Is complete state-space temporal planning
possible?
Does required concurrency occur in the real world?
Many compelling real world examples of required
concurrency involve joint effects of the set of
actions being applied (e.g. lifted(table) ).
While such problems are not easily expressed in
the framework of discrete changes, all of the
challenges in solving the discrete case remain in
more general settings. There are also quite a
number of real-world, but toy, examples
(light-match).
Yes, it is possible one must delay all
scheduling decisions until after the plan is
finalized. That is, represent the dispatch times
of actions using temporal variables, and solve
for the values only after all actions have been
selected and ordered.
light-match
A
A
Is required concurrency really harder?
Durative change
B
B
fix-fuse
Under reasonable assumptions, both kinds of
problems are in PSPACE. Nonetheless, any existing
(complete) temporal planner can have the depth of
its search space halved if the problem is known
to be inherently sequential an exponential
improvement in performance.
The benchmarks resort to compilation techniques
to capture the concept of a durative (and
mutually exclusive) change. This introduces
temporal gap, and so needlessly complicates our
analysis. We prove that the compilation is
correct, in that concurrent access to the fluent
is prevented, and employ a syntax to directly
capture the non-compiled concept. The canonical
example is a navigate action we represent the
statement the navigate(rover, alpha, omega)
requires the rover begin at alpha, and causes it
to move to omega using one effect.
This is a state-space search in the sense that
search nodes contain the requisite information
for the application of state-based reachability
heuristics.
Arent inherently sequential problems interesting?
Resources
The duration of a plan is, very, often an
important factor in the quality of the plan. In
turn, plan quality (if not optimality) is often a
critical factor in potential real world
applications. So, just as supporting non-uniform
costs is an important goal, supporting
non-uniform durations in a GraphPlan style of
concurrency (c.f. Temporal GraphPlan) is also an
important goal for the classical track.
Allowing concurrent production and consumption of
a resource easily leads to required concurrency,
for example, avoiding over-flowing. However, due
to the nature of PDDL, changes must be
conservatively discretized. This is quite
challenging, and the benchmarks only attempt the
simpler scenario of discretizing inherently
sequential resource usage scenarios. The key
thing to show is that the discretized production
effects do not threaten any constraints, which we
show by rewriting the models so they lack
capacity constraints.