5/5 - (1 vote)

PDDL+ Planning: Processes and Events

So far we have seen actions with linear continuous numeric effects:
(increase (battery) (* #t 1))
Now we are going to look at the more advanced features of PDDL+:
Continuous non-linear effects;
Processes and events.

Continuous Non-Linear Effects
In PDDL we can actually write expressions of the form:
dv/dt = P(t)/Q(t) where P and Q are polynomials over the variables defined in the planning problem.
This allows us to write, amongst other things:
Polynomials;
Exponential functions;
Logarithmic functions.

PDDL2.1: Ball Drop Example
PDDL2.1 adds durative actions to PDDL
But as we now know actions can include continuous numeric effects and variable durations
(:durative-action drop-ball
:parameters (?b ball)
:duration (> ?duration 0)
:condition (and (at start (holding ?b)) (at start (= (velocity ?b) 0)))
:effect (and (at start (not (holding ?b)))
(decrease (height ?b) (* #t (velocity ?b)))
(increase (velocity ?b) (* #t (gravity)))))
Notice how the two continuous effects interact
h = -vt = -gt2

PDDL2.1: Dropping the ball
What happens if there is a floor?

Duration of the drop-ball action is limited by the distance to the floor
(:durative-action drop-ball
:parameters (?b ball)
:duration (> ?duration 0)
:condition (and (at start (holding ?b)) (at start (= (velocity ?b) 0))
(over all (>= (height ?b) 0)))
:effect (and (at start (not (holding ?b)))
(decrease (height ?b) (* #t (velocity ?b)))
(increase (velocity ?b) (* #t (gravity)))))
But what happens if we leave the ball to fall?

PDDL+: Lets see it bounce
A better model is to see releasing the ball as separated from the fate of the ball after it falls
Release initiates a process of falling

The falling process can be terminated by various possible actions (catching, hitting, ) or events (bouncing)

PDDL+: Processes and Events
Executive agents perform actions that change the world state in some way

Processes execute continuously under the direction of the world
The world decides whether a process is active or not

Events are the worlds version of actions: the world performs them when conditions are met

Planning is about deciding which actions the executive agents should perform by anticipating the effects of actions before they are executed
Requires a way to predict what will happen when actions are performed (and also when they are not)

What makes it hybrid?
When actions or events are performed they cause instantaneous changes in the world
These are discrete changes to the world state
When an action or an event has happened it is over

Processes are continuous changes
Once they start they generate continuous updates in the world state
A process will run over time, changing the world at every instant
Holding ball
Action: drop ball
Not holding ball
Ball falling
Height over time

Problem Features
We might care about how much of the effect of a process is generated, so we want to choose how long to let it run
Running a bath
Mixing chemicals or running reactions
Heating or cooling metals in a foundry

Duration-dependent effects

We might need to interact with a process while it runs, exploiting or managing conditions during execution

Required concurrency with process effects

PDDL+: Lets see it bounce
A better model is to see releasing the ball as separated from the fate of the ball after it falls
Release initiates a process of falling

The falling process can be terminated by various possible actions (catching, hitting, ) or events (bouncing)

How does this look in PDDL+

PDDL+: Let it go
First drop it

Then watch it fall

(:action release
:parameters (?b ball)
:precondition (and (holding ?b) (= (velocity ?b) 0))
:effect (and (not (holding ?b))))
(:process fall
:parameters (?b ball)
:precondition (and (not (holding ?b)) (>= (height ?b) 0)))
:effect (and (increase (velocity ?b) (* #t (gravity)))
(decrease (height ?b) (* #t (velocity ?b)))))
Process has a precondition
Happens when this is satisfied
No matter what, we dont
have a choice
Continuous numeric effects,
No discrete effects.

PDDL+: See it bounce
Bouncing

Now lets plan to catch it
(:event bounce
:parameters (?b ball)
:precondition (and(>= (velocity ?b) 0)
(<= (height ?b) 0)) :effect (and (assign (height ?b) (* -1 (height ?b))) (assign (velocity ?b) (* -1 (velocity ?b)))))(:action catch :parameters (?b – ball) :precondition (and (>= (height ?b) 5) (<= (height ?b) 5.01)) :effect (and (holding ?b) (assign (velocity ?b) 0)))Event has a precondition,happens when this is satisfiedNo matter what, we dont have a choiceDiscrete numeric effects,can also have propositional No continuous effects.A Valid PlanLet it bounce, then catch it…What does the validator say?Use-l to get a nice latex report showing triggering of processes and events and the values of numeric variables during the plan. 0.1: (release b1)4.757: (catch b1)0.1: (release b1)4.757: (catch b1)VAL ReportHeight of the Ball is Quadratic0.1: (release b1)4.757: (catch b1)Velocity is Linear but Discontinuous0.1: (release b1)4.757: (catch b1)What happens if the ball is not perfectly elastic?Modify the bounce event slightly…Notice that the coefficient of restitution is given a ve sign to make it easier to use!Notice further that the precondition on height is slightly relaxed to allow bouncing to happen until the ball is too close to bounce any more…(:event bounce :parameters (?b – ball) :precondition (and(>= (velocity ?b) 0)
(<= (height ?b) 0.00001)) :effect (and (assign (velocity ?b) (* (coeffRest ?b) (velocity ?b)))))What happens if the ball is not perfectly elastic?(:event bounce :parameters (?b – ball) :precondition (and(>= (velocity ?b) 0)
(<= (height ?b) 0.00001)) :effect (and (assign (velocity ?b) (* (coeffRest ?b) (velocity ?b)))))14 bounces!Zeno behaviourIf we look closely at the bouncing ball, we see that eventually the events are so close (in an idealised view, at least) that infinitely many bounces happen in a finite timeThis is Zeno behaviour and it is A Bad ThingCannot reason about infinite events in finite time in planner, validator or pretty much anywhere else…Check the VAL reportThis is where we see events getting too closeCascading eventsEvents (and processes) can be problematic in lots of interesting waysIt is easy to set up events that trigger each other:Imagine a light connected to a light-sensitive switch, so that when the light is on it triggers an event which turns the light off…But, when the light is off an event is triggered that turns it on!Other Semantic IssuesEvents with strict inequality preconditions can create an interesting problemWhen does E occur? At time 10, (x) = 10, so the precondition of E is not satisfiedAt time 10+, for any >0, the precondition is satisfied, but it was satisfied at 10+/2 and so E should trigger before 10+
:precondition (> 10 (x))
:effect (and (not (active)) (explode)))

(:process P
:precondition (active)
:effect (increase (x) (* #t 1)))

:init (= (x) 0) (active)

PDDL+ Planning: Example 2 Planetary Lander

Durative Action

Prepare Obs 1
Prepare Obs 2
Fullprepare
PlanetaryDDL+ model [Fox&Long, JAIR 2006]
generating()
charging()
discharging()

As a case study, we considered the Planetary Lander Domain.
We have a Solar-powered lander.
Basically, it must perform two observation actions, called Observe1 and Observe2. (animazione)
However, before making each observation, it must perform the corresponding preparation task, called prepareObs1 and prepareObs2, respectively. (animazione)
Alternatively, the probe may choose to perform a cumulative preparation task for both observations by executing the single long action fullPrepare. The shorter actions have higher power requirements than the single preparation action.
(animazione)

During the plan execution, Beagle can use the energy generated by the sunlight (process generating) toperform actions immediately or use it to charge the battery(process charge). If no energy is available Beagle uses the battery ones.

In the general theory of universal planning, the concept of start state is not present. However, the concept of reachable state implies such a start state. In particolar, this is very important for model checking algorithms. In other words, we need to start-up the universal planning with a set of start states, that we call start state cloud.
In this experiment, we generated the start state cloud by varying the initial battery charge and the daytime. In fact, these variables define the environmental conditions.