CPSC 322 - Lecture 33 - November 24, 2004

CPSC 322 - Lecture 33

More About Limitations


I.  More about limitations

Last time we at least were able to point out that there
were limitations with our simple STRIPS planner.  The
one we encountered last time was that we couldn't get
three blocks stacked regardless of the desired order.
The problem was due to the fact that the very simple
STRIPS planner from the textbook could compare goals
to the initial state, but it didn't track the 
intermediate states.  That is, once a block was taken
off the table an put on top of another block, our 
planner didn't know that its world had changed.  It
was doing STRIPS-style planning for a world with only
two blocks, but it couldn't deal with the possibilities
posed by three blocks.

That's when we upgraded the simple STRIPS planner to
a more complex STRIPS planner.  That CILOG code looks
like this:

/* 
This is an enhancement of the simple STRIPS planner
shown on page 302 of the Computational Intelligence text.
The domain is a very simple blocks world problem, and 
the representations of state and actions, while described
in chapter 8 of the text, are adapted from a more 
complicated sample program and knowledge base found at
http://www.cs.ubc.ca/spider/poole/ci/code/cilog/cilog_code/cilog_code.html
(click on delrob_strips.pl).

launch it with the query:
cilog: ask goals(G) & achieve_all(G,init,Plan).

Note that the add list is denoted here by "achieves" instead 
of "add", and that the add and delete lists aren't exactly 
lists.
*/

/* stack action */
preconditions(stack(X,Y),[cleartop(Y),X\=Y,holding(X)]).
achieves(stack(X,Y),armempty).
achieves(stack(X,Y),on(X,Y)).
deletes(stack(X,Y),cleartop(Y)).
deletes(stack(X,Y),holding(X)).

/* unstack action */
preconditions(unstack(X,Y),[on(X,Y),cleartop(X),X\=Y],armempty).
achieves(unstack(X,Y),holding(X)).
achieves(unstack(X,Y),cleartop(Y)).
deletes(unstack(X,Y),on(X,Y)).
deletes(unstack(X,Y),armempty).

/* pickup action */
preconditions(pickup(X),[cleartop(X),ontable(X),armempty]).
achieves(pickup(X),holding(X)).
deletes(pickup(X),ontable(X)).
deletes(pickup(X),armempty).

/* putdown action */
preconditions(putdown(X),[holding(X)]).
achieves(putdown(X),ontable(X)).
achieves(putdown(X),armempty).
deletes(putdown(X),holding(X)).


/* initial situation */

holds(ontable(a),init).
holds(ontable(b),init).
holds(ontable(c),init).
holds(cleartop(a),init).
holds(cleartop(b),init).
holds(cleartop(c),init).
holds(armempty,init).

achieves(init,X) <- holds(X,init).

goals([on(b,c),on(a,b)]).

/* the more complex STRIPS planner */

remove(X,[X|Y],Y).

achieve_all([],W0,W0).

achieve_all(Goals,W0,W2) <- 
     remove(G,Goals,Rem_Gs) &
     achieve(G,W0,W1) &
     achieve_all(Rem_Gs,W1,W2).

achieve(G,W,W) <- true_in(G,W).


achieve(A \= B,W,W) <- A \= B.


achieve(G,W0,do(Action,W1)) <-
     achieves(Action,G) &
     preconditions(Action,Pre) &
     achieve_all(Pre,W0,W1).

true_in(G,init) <-
   holds(G,init).
true_in(G,do(A,_)) <-
   achieves(A,G).
true_in(G,do(A,S)) <-
   true_in(G,S) &
   ~ deletes(A,G).

This enhanced STRIPS planner shows off more clearly
what some textbooks call goal-stack planning.  (The
very simple planner did goal-stack planning, but it
wasn't easy to see because of the simplistic two-block
problem it was working on.)  Goals are pushed onto a
stack, and the planner pops the top goal off, finds
an operator whose add list contains the goal that was
just poppped off the stack, and the preconditions of
that operator are pushed onto the goal stack where 
they become new goals to be satisfied.

So now our STRIPS planner is able to solve our tower
problem if we present the goals to be solved in the
right order.  For example, if we tell the planner that
we want block B on block C and block A on block B, all
goes smoothly.  The planner satisfies the first goal
with a plan for putting B on C, and then the planner
satisfies the second goal with a plan for putting A on B.

But what happens if we reverse the order of the goals?
If we say we want A on B and B on C, then the planner
comes back with a plan to put A on B.  But now when
the planner wants to put B on C, it finds that A is
already on B.  To pick up B, the planner has to 
adjust the plan to take A off of B, but now the planner
is right back where it started.  Thus satisfying the
goal of putting A on B conflicts with the goal of
putting B on C.  What to do?

Last revised: December 7, 2004