Time Constraints in Planning

1. Time Constraints in Planning Sudhan Kanitkar (sgk205@lehigh.edu)

2. References • Fahiem Bacchus, Michael Ady “Planning with Resources and Concurrency A Forward Chaining Approach” • Ch. 13 Time for Planning • Ch. 14 Temporal Planning • http://www.cs.toronto.edu/~fbacchus/tlplan-manual.html

3. Agenda • TLPlan – Practical Approach • Functions, Timestamped States, Queues • Algorithm, Example • Changes needed in the domain • A more theoretical but expressive approach described in the textbook.

4. TLPlan • Functions • Similar to state variable representation discussed earlier • Timestamped States • Queues

5. Functions • In traditional planning States are represented as databases (sets) of predicate instances and operators as making changes to these databases. • It is needed to add/delete all the predicates • (drive ?t ?l ?l’) . . (forall (?o) (int ?o ?t) (and (add (at ?o ?l’)) (del (at ?o ?l)))) )

6. Functions • Instead of having predicates for all facts we use functions. • Functions seem to analogous to variables in programming languages • They represent values • Predicate (at ?x ?l) just describes the location of object x. • Instead model the location of the object using a function (loc ?x)

7. Functions (Cont’d) • (loc ?x) acts just like a variable which describes the location of the object x. • In the drive predicate we make the following changes • (drive ?t ?l ?l’) . . (forall (?o) (in ?o ?t) (add (= (loc ?o) ?l))) ) Recall State-Variable Representation

8. Functions – More Examples • Predicate (refuel ?t) refuels the truck t • (capacity ?t) is the fuel capacity of the truck • (fuel ?t) is the current level of fuel • (fuel-used) is a total fuel used globally • (refuel ?t) (and (add (= (fuel-used) (+ (fuel-used) (- (capacity ?t) (fuel ?t))))) (add (= (fuel ?t) (capacity ?t))) ) )

9. Forward chaining Planners • Forward chaining has proved to be useful for high-performance planners. • Domain independent heuristics for search • Drawback: They explore only totally ordered sequences of action. • Hence, modeling concurrent actions with linear sequences become problematic • e.g. Two trucks in two different locations can travel simultaneously in parallel. • Plans generated by GraphPlan

10. Why make time explicit ? • Model the duration of action • Model the effects and conditions of an action at various points along duration • Handle goals with relative and absolute temporal constraints • To be able to use events happening in the future which are not immediate effects of actions

11. Principle • In classical planners the effects of an action are visible immediately and hence validating the preconditions of further action • This approach suppresses the visibility of effects for the duration of action • Hence the further actions which use these effects as preconditions cannot be used.

12. Timestamps • Associate with each state a timestamp • Timestamp starts with a fixed start time in the initial state • Denotes the actual time the state will occur during the execution of a plan • Timestamp of a successive state changes only when no other action can be applied and it is necessary to wait for an action that takes some time to finish. • The effects which are not delayed still become available instantaneously

13. Queue • State also has an event queue • Queue has updates scheduled to occur at some time in the future • These updates are predicates and time at which they become effective • Each state inherits the pending events of its parent state

14. Actions • s is the current state • a is an action which is applicable to s only if it satisfies all the preconditions of s. • Applying a to s generates a new successor state s+ • An action can have two kinds of effects • Instantaneous effects • Delayed effects

15. Example • (def-adl-operator (drive ?t ?l ?l’) (pre (?t) (truck ?t) (?l) (loc ?l) (?l’) (loc ?l’) (at ?t ?l) ) (del (at ?t ?l)) (delayed-effect (/ (dist ?l ?l’) (speed ?t)) (arrived-driving ?t ?l ?l’) (add (at ?t ?l’)) ) ) Instantaneous Effect Delayed Effect

16. Why two types of effects ?? • Instantaneous effects make sure that objects in question are not reused • Delayed effects ensure that the timing constraints are satisfied Delayed Effect • (add (at ?t ?l’))

17. delayed-action • Parameters • delta: the time further from the current time that the action is time stamped with • Instantaneous effects change the database of s immediately • Delayed effects are added to the queue of the state to be applied later

18. unqueue-event Action • A mechanism is needed which will remove events from the queue when the time is up and update the database • A special action • Advances the world clock • Remove all actions scheduled for current time from the queue and update the database

19. Planning Algorithm State & Queue pair Advance to new state Record Previous State Non-deterministic:Operator or unqueue-event Record Action Two types of Updates New timestamp Apply all updates with current timestamp from the queue

20. Notes on Algorithm • The non-deterministic choice operator is realized by search. • The choice of which action to try is made by heuristic or domain specific control • Temporal Control Formula from previous class • Instead of a plan the final goal state is returned • The sequence of actions leading to the goal can be determined using actionand prev pointers

21. TLPlan support • Following actions can be defined for TLPlan • (delayed-action delta tag formula) • (wait-for-next-event) • TLPlan Manual link • http://www.cs.toronto.edu/~fbacchus/tlplan-manual.html • Look for section titled “Support for Concurrent Planning”

22. Thanks: Joe Souto http://www.cse.lehigh.edu/~munoz/AIPlanning/classes/Graphplan.ppt Example Goal: Get cargo at location l0 (at c0 l0) l1 c0 l0 v0 State: (at c0 l1) State: (at v0 l0) (in c0 v0) State: (in c0 v0) State: (at c0 l1) (at v0 l1) State: (at v0 l0) (at c0 l0) State: (at v0 l0) (at c0 l1) State: (at v0 l1) (in c0 v0) Queue: (at v0 l0) Queue: Queue: (at v0 l1) Queue: Plan: move(v0,l0,l1) load(c0,v0,l1) move(v0,l1,l0) unload(c0,v0,l0)

23. Importance of control Formula • 0 (move v0 l0 l1 f2 f1) • 20 (event (moving-truck • v0 l0 l1 f2 f1)) • 20 (load c0 v0 l1 s1 s0) • 20 (move v0 l1 l0 f1 f0) • 40 (event (moving-truck • v0 l1 l0 f1 f0)) • 40 (unload c0 v0 l0 s0 s1) • 0 (move v0 l0 l1 f1 f0) • 0 (move v1 l1 l0 f2 f1) • 20 (event ... • 20 (move v0 l1 l0 f1 f0) • 20 (load c0 v1 l0 s2 s1) • 20 (load c1 v1 l0 s1 s0) • 20 (unload c0 v1 l0 s0 s1) • 20 (donate l2 l0 f2 f1 f0 f0 f1) • 20 (load c0 v1 l0 s1 s0) Note Redundant actions

24. Changes in Domain File (define (domain mprime-strips) (:types space vehicle cargo) (:predicates (at ?v ?l) (conn ?l1 ?l2) (has-fuel ?l ?f) (fuel-neighbor ?f1 ?f2) (in ?c ?v) (has-space ?v ?s) (space-neighbor ?s1 ?s2) (not-equal ?l1 ?l2) ) .. .. .. (declare-described-symbol (predicate cargo-at 2) (predicate vehicle-at 2) (predicate conn 2) (predicate has-fuel 2) (predicate fuel-neighbor 2) (predicate in 2) (predicate has-space 2) (predicate space-neighbor 2) (predicate not-equal 2) ) .. .. ..

25. Changes in Domain File (:action move :parameters ( ?v - vehicle ?l1 ?l2 - location ?f1 ?f2 – fuel) :precondition (and (at ?v ?l1) .. (fuel-neighbor ?f2 ?f1)) :effect (and (not (at ?v ?l1)) .. (has-fuel ?l1 ?f2))) (def-adl-operator (move ?v ?l1 ?l2 ?f1 ?f2) (pre (?v ?l1) (vehicle-at ?v ?l1) (?l2) (conn ?l1 ?l2) (?f1) (has-fuel ?l1 ?f1) (?f2) (fuel-neighbor ?f2 ?f1)) (del (vehicle-at ?v ?l1) (has-fuel ?l1 ?f1)) (delayed-action 20 (moving-truck ?v ?l1 ?l2 ?f1 ?f2) (add (vehicle-at ?v ?l2) (has-fuel ?l1 ?f2) )))

26. Changes in Domain File • Add operator to unqueue events (def-adl-operator (event) (wait-for-next-event) ) • Add to the top of the domain file (enable concurrent-planning))

27. Changes in Problem File (define (state0) (not-equal l0 l1) (not-equal l0 l2) (not-equal l1 l0) .. ) (define goal0 (cargo-at c0 l0) (cargo-at c1 l2) ) define (problem strips-mprime-. .-c4) (:domain mprime-strips) (:objects f0 f1 f2 - fuel .. c0 c1 - cargo) (:init (not-equal l0 l1) (not-equal l0 l2) . . ) (:goal (and (at c0 l0) .. (at c1 l2) ))

28. Break • After the break we will look at the one theoretical approach

29. Formal Representation • Formal representation of a temporal planning domain has following objects • Symbols • Relations • Rigid Relations • Flexible Relations • Constraints • Temporal Constraints • Binding Constraints

30. Symbols • Constant Symbols • Objects which remain constant over time or state changes • Objects of classes such as robot, crane • Variable Symbols • Objects whose value changes over time or state changes • e.g. temporal variables ranging over R

31. Relations • Rigid Relations • Relations which do not change over time or state transitions • e.g. adjacent(loc1,loc2) • Flexible Relations • Also called Fluents • Relations which invalidate/validate over a period of time • e.g. at(robot1,loc1)

32. Constraints • Binding constraints • Temporal constraints • If t1and t2are two temporal variables and ris a constraint defined on them • r = 2P • P = {<,>,=} • 2P={Φ,{<},{=},{>},{<,=},{>,=},{>,<},P}

33. Temporally Qualified Expression • A temporally qualified expression (tqe) is an expression of the form p(ζ1,…, ζk)@[ts,te] • p is a flexible relation • ζ1,…, ζk are constants or object variables • ts,te are temporal variables such that ts<te • A tqe asserts that for the time range ts≤t<te the relation p(ζ1,…, ζk)holds

34. Temporal Database • A temporal database is a pair Φ = (F,C) • F is a finite set of tqes • C is a finite set of temporal and object constraints

35. Textbook. Pg: 312

36. Enabling Conditions • In the temporal database shown previously there are two instances of tqe free(l)@[t,t’). • This tqe holds w.r.t to database only if one of the following holds: • {l=loc3, τ0 ≤t,t’≤τ5} • {l=loc2, τ6 ≤t,t’≤τ7} • These two sets of constraints are called enabling conditions for the tqe to be supported by F • One of them has to be consistent with C for the database to support the tqe.

37. Definitions • A set F supports a tqe e = p(ζ1,…,ζk)@[t1,t2] iff there is in F a tqe p(ζ1’,…,ζk’)@[τ1,τ2]and a substitution σsuch that σ(p(ζ1,…,ζk)) = σ(p(ζ1’,…,ζk’)) and • An enabling condition for e in F is conjunction of the temporal constraints τ1 ≤t1 andt2 ≤τ2 with binding constraints of σ. • θ(e/F) is set of all the possible enabling conditions for e in F. • θ(ε/F) is set of all the possible enabling conditions for a set of tqes ε in F. In this case F is said to support ε. • A temporal database Φ=(F,C) supports a set of tqes ε if all the enabling conditions c Єθ(ε/F) are consistent with C. • Φ=(F,C) supports another database (F’,C’) when F supports F’ and there is an enabling condition c Єθ(F’/F) such that C’U c is consistent with C.

38. Temporal Planning Operators • It’s a tuple • o = (name(o), precond(o), effects(o), const(o)) • name is an expression of form o(x1,…xk, ts, te) such that o is an operator, x1,…xkare object variables, ts, te are temporal variables • precond(o) and effects(o) are tqes • const(o) is a conjunction of constraints

39. Textbook. Pg: 315 Temporal Planning Operator • Action is a partially instantiated operator • If preconditions and constraints of an action hold then action will run from ts to te. • effectsdescribe the new tqes that result from an action

40. Applicability of an Action • An action a is applicable to a temporal database (F,C) if and only if precond(a) is supported by F and there is an enabling condition c in θ(a/F)for the a such that C U const(a) U c is consistent with the set of constraints • Γ(Φ,a) = {(F U effects(a), C U const(a) U c | c Єθ(a/F)} • Note that actions are applied to database and the result is a set databases since action can be applied differently at different times.

41. Domain Axioms • The operators described till now do not express the negative effects of the actions • The action thus keeps on increasing the size of the database where we might have conflicting statements appearing. • Domain axioms is the mechanism used to overcome this shortcoming. • Domain axiom is a conditional expression of the form p = cond(p)  disj(p) • cond(p) is a set of tqes • disj(p) is a disjunction of temporal and object constraints

42. Domain Axiom (Cont’d) • Consider a scenario which has two robots r and r’ an two locations l and l’ - {at(r,l)@[ts,te),at(r’,l’)@[ts’,te’)}  (r ≠ r’) v (l = l’) v (te ≤ ts’) v (te’≤ ts) - {at(r,l)@[t1,t1’),free(l’)@[t2,t2’)}  (l ≠ l’) v (t1’≤ t2) v (t2’≤ t1)

43. Domain Axiom Support • Let p be an axiom and Φ=(F,C) be a temporal database such that cond(p) is supported by F and θ(p/F) is set of enabling conditions for cond(p) in F. • Φ is consistent with p iff for each enabling condition c1 in θ(p/F) there is atleast one disjunct c2 in disj(p) such that C U c1 U c2 is consistent set of constraints. • This means that for every for every tqe to be supported by F, there is needs to be atleast one disjunct in disj(p) which is consistent with Φor C. • A consistency condition for Φ w.r.t a set of axioms X is: • A set of all such conditions is denoted by θ(X/F)

44. Domain Axioms- Actions • So for a set of axioms to be applicable the consistency condition needs to satisfied • As result we get a new set of databases as • Earlier it was mentioned that effect of applying an action a to Φ is a set of databases. • Many of these databases may not be consistent with X • So we now restrict that definition to only those databases which are consistent with X as follows:

45. Temporal Planning Domain • A temporal Planning domain is the triple D = (ΛΦ , O, X) - ΛΦis set of all temporal databases that can be defined - O is a set of temporal planning operators - X is a set of domain axioms

46. Temporal Planning Problem • Is the triple P = (D, Φ0, Φg) • D is the planning domain • Φ0 = (F,C) is the initial state of the domain • Φg = (G,Cg) is the goal state of the domain • The statement of the problem is given by • P = (O, X, Φ0, Φg)

47. TPS Procedure Note the similarity with Plan-space Planning approach

48. TPS Procedure • It maintains the data structure Ω. • Ω = { Φ,G,K,π } • Φ = { F,C } is the current temporal database • G is a set of tqes corresponding to current open goals • K = { C1,…,C2 } is the set of pending enabling conditions of actions, consistency conditions of axioms • π is a set of actions corresponding to current plan

49. Flaws – Open Goals • A tqe in F can support a tqee ЄG if there is an enabling condition θ(e/F). Updates are • K K U {θ(e/F)} • G G – {e} • Updates owing to action a for this goal • π π U {a} • F F U effects(a) • C C U const(a) • G (G – {e}) U precond(a) • K K U {θ(a/Φ)}

50. Flaws - Axioms and Threat • Unsatisfied Axioms • These flaws are possible inconsistencies of instances of Φ w.r.t to the axioms of X. • A resolver is a set of consistency conditions θ(X/Φ) • K K U {θ(X/Φ)} • Threats • Over the period of time we have kept on adding new constraints which are required to be solved to K. • For every Ci in K, the resolver is a constraint c such that: • C C U c • K K - {Ci}