ai-unit3
ai-unit3
^Airport(to)
EFFECT: ┐At(p, from)^At(p,to))
The precondition and the effect are each
conjunctions of literals (positive or negated
atomic sentences). We can choose constants to
instantiate the variables, yielding a ground
(variable-free) action
A ground action a is applicable in state s if s
entails the precondition of a; that is, if every
positive literal in the precondition is in s and
The result of executing applicable action a in
state s is defined as a state s’ which is
represented by the set of fluents formed by
starting with s
Removing the fluents that appear as negative
literals in the action’s effects (DEL(a)), and
adding the
fluents that are positive literals in the action’s
effects (ADD(a)): RESULT(s; a) = (s-DEL(a)) U
ADD(a) :
A set of action schemas serves as a definition of
a planning domain. A specific problem within the
domain is defined with the addition of an initial
state and a goal.
The initial state is a conjunction of ground
fluents (with the keyword Init), The goal is just
Example domain: The blocks world
This domain consists of a set of cube-shaped
blocks placed on an arbitrarily-large table.The
blocks can be stacked, but only one block can fit
directly on top of another.
A robot arm can pick up a block and move it to
another position, either on the table or on top of
another block. The arm can pick up only one
block at a time, so it cannot pick up a block that
has another one on top of it.
A typical goal to get block A on B and block B
on C
We use On(b,x) to indicate that block b is
on x, where x is either another block or the
table
The action for moving block b from the
top of x to the top of y will be Move(b,x,y)
Basic PDDL does not allow quantifiers, so
instead we introduce a predicate Clear(x)
that is true when nothing is on x.
The action Move moves a block b from x
to y if both b and y are clear. After the
move is made, b is still clear but y is not.
Action(Move(b,x,y);
PRECOND:On(b,x)^Clear(b)^Clear(y);
EFFECT:On(b,y)^Clear(x)^ ┐On(b,x)^
This does not maintain Clear properly
when x or y is the table. When x is the
Table, this action has the effect
Clear(Table), but the table should not
become clear;
When y=Table, it has the precondition
Clear(Table), but the table does not have
to be clear for us to move a block onto it.
To fix this, we do two things.
First, we introduce another action to
move a block b from x to the table:
Action(MoveToTable(b,x),
PRECOND:On(b,x)^Clear(b),
Second, we take the interpretation of Clear(x)
to be “there is a clear space on x to hold a
block.” Under this interpretation, Clear(Table)
will always be true.
The only problem is that nothing prevents the
planner from using Move(b,x,Table) instead of
MoveToTable(b,x)
Algorithms for Classical Planning
Planning problem provides an obvious way to
search from the initial state through the space of
states, looking for a goal.
A nice advantage of the declarative
representation of action schemas is that we can
also search backward from the goal, looking for
the initial state
A third possibility is to translate the problem
Forward state-space search for planning