time constraints in planning
Download
Skip this Video
Download Presentation
Time Constraints in Planning

Loading in 2 Seconds...

play fullscreen
1 / 55

Time Constraints in Planning - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

Time Constraints in Planning. Sudhan Kanitkar ([email protected]). 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. Agenda.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Time Constraints in Planning' - gili


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
references
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
agenda
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.
tlplan
TLPlan
  • Functions
    • Similar to state variable representation discussed earlier
  • Timestamped States
  • Queues
functions
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))))

)

functions1
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)
functions cont d
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

functions more examples
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)))

)

)

forward chaining planners
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
why make time explicit
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
principle
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.
timestamps
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
queue
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
actions
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
example
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

why two types of effects
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’))
delayed action
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
unqueue event action
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
planning algorithm
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

notes on algorithm
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
tlplan support
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”
slide22
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)

importance of control formula
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

changes in domain file
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)

)

..

..

..

changes in domain file1
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)

)))

changes in domain file2
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))

changes in problem file
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)

))

break
Break
  • After the break we will look at the one theoretical approach
formal representation
Formal Representation
  • Formal representation of a temporal planning domain has following objects
  • Symbols
  • Relations
    • Rigid Relations
    • Flexible Relations
  • Constraints
    • Temporal Constraints
    • Binding Constraints
symbols
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
relations
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)
constraints
Constraints
  • Binding constraints
  • Temporal constraints
    • If t1and t2are two temporal variables and ris a constraint defined on them
    • r = 2P
    • P = {<,>,=}
    • 2P={Φ,{<},{=},{>},{<,=},{>,=},{>,<},P}
temporally qualified expression
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
  • A tqe asserts that for the time range ts≤t
temporal database
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
enabling conditions
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.
definitions
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.
temporal planning operators
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
temporal planning operator
Textbook. Pg: 315Temporal 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
applicability of an action
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.
domain axioms
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
domain axiom cont d
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)

domain axiom support
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)
domain axioms actions
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:
temporal planning domain
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

temporal planning problem
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)
tps procedure
TPS Procedure

Note the similarity with Plan-space Planning approach

tps procedure1
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
flaws open goals
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/Φ)}
flaws axioms and threat
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}
example1
Example
  • move(r,l,l’)@[ts,te]

precond: at(r,l)@[t1,ts)

free(l’)@[t2,te)

effects: at(r,routes)@[ts,te)

at(r,l’)@[te,t3)

free(l)@[t4,t5)

const: ts < t4 < t2

adjacent(l,l’)

Temporal Constraints

Binding Constraints

slide54
Example

Goal: Get cargo at location l0

l1

c0

l0

v0

State:

(at c0 l1)

State:

(at v0 l0)

(at c0 l1)

State:

(at v0 l0)

(in c0 v0)

State:

(at c0 l1)

(at v0 l1)

State:

(at v0 l1)

(in c0 v0)

State:

(in c0 v0)

State:

(at v0 l0)

(at c0 l0)

Queue:

Queue:

(at v0 l1)

Queue:

Queue:

(at v0 l0)

Plan:

move(v0,l0,l1)

load(c0,v0,l1)

move(v0,l1,l0)

unload(c0,v0,l0)

slide55
Example

Goal: Get cargo at location l0

l1

c0

l0

v0

move(v0,l0,l1)

load(c0,v0,l1)

move(v0,l1,l0)

unload(c0,v0,l0)

ad