.he'STRIPS''Page %'
.fo'Aaron Sloman'%'January 1978'

.lv 2
.mh
The STRIPS problem-solver
=========================
.hm
The Stanford Research Institute Problem Solving system is a descendant of
GPS and theorem-provers.
The main ideas are as follows.

.in+5
.ti-5
(1)\ \ An actual or hypothetical situation can be represented by a set
of assertions, using the notation of Predicate Logic, i.e. a database.

.ti-5
(2)  A goal state, or subgoal state, can also be represented by a set of such
assertions.

.ti-5
(3)  The methods of Predicate Logic theorem-provers can be used to
discover that a goal or subgoal G has already been achieved
in a situation S (actual or hypothetical) - by proving the goal assertions to be true, given the
assertions describing S i.e. by proving "If S then G".

.ti-5
(4)  Besides having the ability to perfom an action (e.g. a program) one
must also have knowledge
.ul
about
the action, which can be used in deciding
which actions to perform.
The knowledge about a type of action (called an operator) can
be expressed as

 	(a) A set of preconditions for performing it.

 	(b) A set of alterations to the situation, achieved
 	    by performing it, represented by a set of
 	    assertions to be deleted and set to be added to
 	    the database: the "delete list" and the "add list".
.ti-5

(5)  When G is not true in S, the unsuccessful search for
a proof of G will reveal possible alterations to S which might
be achieved by known operators, and which would make G true.
The achievement of the operators` pre-conditions will define one or more new
sub-goals.
.in+4
E.g. The goal G might be [IN SELF ROOM3]
which could be achieved by an operator called GOTHRUDOOR, whose
add list includes
.sp
 		[IN SELF !ROOM]
.sp
but which can only be applied if the assertion
.sp
 		[OPEN DOOR]
.sp
is true. So when this precondition is false, STRIPS has
to set up the new sub goal of making it true. This may generate further
subgoals, like [GRASPING SELF HANDLE]
.in-4

.ti-5
(6)  STRIPS can be applied recursively to the problem
of achieving subgoals.

.ti-5
(7)  Alternative plans can be explored by constructing hypothetical data-bases,
or "contexts" (an AND-OR graph).
.sp
For examples see Bundy et al pp RK48-RK68,
and Margaret Boden`s book pp278-286.
(Also look up "STRIPS" in index.) Bundy`s
examples are all cases where testing the truth of a goal or
subgoal is a simple data-base look-up (e.g. PRESENT (G)) so
theorem-proving is not required.
Hence finding a suitable operator for achieving a goal is simply a matter
of finding an operator whose add list includes something which matches a goal
description.
.sp
For more details see Fikes & Nilsson
in IJCAI-2 p608ff.
.in-10
.sp
.sh
Problems with the approach
--------------------------
.hs
.in+5
.ti-5
(a)  Difficulities arise when there are complex
goals or subgoals with interactions between them.
E.g. if your goal is to get onto a table whilst the table
is under a bunch of bananas, you could climb on the table
to achieve the first part, then get off to
move the table to achieve the second part. 
(look up "Hacker" in Boden).

.ti-5
(b)  It is arguable that a general purpose problem solver defines a
somewhat restricted programming language, in which it
is hard to formulate the special purpose 
heuristics and representational techniques appropriate to different
sort of problem domains.

.ti-5
(c)  A minor difficulty is that STRIPS does not permit a distinction between
preconditions which must already be true and preconditions which one can
try to make true. E.g. if a pre-condition for making an omelette is that
the eggs are fresh, then when the eggs aren`t fresh there`s
no point setting up the sub-goal of making them fresh.
This led Julian Davies to distinguish INFER and ACHIEVE in his POPLER
system (a POP2 version of PLANNER).
.sp
.ti-5
(d)  Strips assumes that each action is a sort of instantaneous change
in the world. Real actions are often ongoing processes which
need to be monitored and related to other processes during
execution.
.sp
.ti-5
Later developments included:
.sp
.ti-5
(a)  The introduction of "macro-operators" i.e. chains of primitive
operators combined into a single new operator - a form of learning.
.sp
.ti-5
(b)  The ABSTRIPS system, which makes plans at different levels of
abstraction, worrying about detailed actions only when a rough
overall plan has been achieved.
.sp
.ti-5
(c)  The PLANEX system to monitor execution of a plan and generate new
planning if things don`t work out as expected.
.sp2
.sh
Programming STRIPS in POP11
---------------------------
.hs

.ti-5
We need to take the following decisions:
.ti-5

(1)  How should situations and goals be represented? The obvious method is
to use the database system, with ADD and REMOVE for altering situations
and PRESENT to test whether a subgoal pattern is already true or not.
Problem: what should be done about negative goals, e.g.

 	[NOT [ON B1 B2]]


.ti-5
(2)  How should operators be represented? We
could use a list of lists, e.g. the following list might
represent an operator GRASP
for grasping a block, with 3 preconditions, a one-element delete list, and one
ADD pattern.
.sp
.ne8
 	[GRASP !BLOCK
 	[PRE	[AT !BLOCK !P]
 		[AT !SELF !P]
 		[CLEARTOP !BLOCK]
 		[EMPTY HAND]]
 	[DEL [EMPTY HAND]]
 	[ADD [GRASPING SELF !BLOCK]]
 	]
.sp
The exclamation-mark indicates variables which must all have
the same value when the operator is executed.
.br
Similarly an operator named GOTHRUDOOR
.ne8

 	[GOTHRUDOOR	!DOOR
 	[PRE	[JOINS !ROOM1 !ROOM2 !DOOR]
 		[NEXTTO ROBOT !DOOR]
 		[IN ROBOT !ROOM1]
 		[OPEN !DOOR]]
 	[DEL	[IN ROBOT !ROOM1]]
 	[ADD	[IN ROBOT !ROOM2]]
 	]

This has a name, 4 pre-conditions, one thing to be deleted and one to be
added.
.in-5
.sp
Implementing a complete STRIPS would raise many problems; including:
.in+5
Building a theorem-prover (we could simplify things  by using
PRESENT instead of a theorem-prover).

Managing alternative contexts while exploring possible plans (we cold avoid this difficulty by doing only a depth-first search, so that only one
context is considered at a time - see the SEARCH2 demos and remarks about
search in Boden)

Indexing operators so that operators relevant to the current goal or subgoal
are found quickly. This is not too different from the problem
of indexing assertions so that PRESENT can find them quickly.

Choosing between operators when several are relevant. One can either
choose by exploring all their consequences at once (a breadth first
search requiring different contexts) or by trying them one at a time
(depth first). This requires some way of selecting the most promising (compare
the "difference table" in GPS). E.g. we could choose the one
with fewest unsatisfied pre-conditions, or use a measure of how
difficult it is to achieve various sorts of pre-conditions (a case
of heuristic search).

Handling variable-bindings. E.g. the GRASP operator is
meant to be general enough to be applicable to grasping any block,
at any location, so there are variables
for the block and the location. However the goal of grasping this
block B1 may be a subgoal of some other goal involving a different block
e.g. B2 which has to be pushed somewhere after B1 has been taken
off it. So STRIPS needs to remember that in the PUSH operator the variable
!BLOCK is bound to B2 while for
now, in the GRASP operation !BLOCK is bound to B1. This is analogous to 
the management of local variables in POP11. How do you think the human mind
handles the problem of general operators?
(Talking about "assimilation" as Piaget does, doesn`t seem to solve
the problem.)
.in-5
.sp2
.mh
Exercises
=========
.hm
.sp
.in+5
.ti-5
1.\ \ \ Think about some actions you can perform and describe them in
terms of pre-conditions, delete lists and add-lists. (E.g. [Travelto
!x] [PUSH !OBJ !LOCATION] [EAT SELF !EGGS])
.sp
.ti-5
2.\ \ \ Discuss the consequences of simply using
PRESENT, instead of a theorem-prover to check preconditions. E.g. think
of negative preconditions, or alternative preconditions (disjunctive preconditions), e.g.
.sp
 	[[METAL !X] or [PLASTIC !X]]
.sp
or preconditions that use a defined term, e.g.
.sp
 	[BACHELOR !X]
.sp
Where "BACHELOR" is defined in terms of a set of other predicates.
.br
What about "quantified" preconditions e.g.
.sp
 	[NOT EXISTS !X [ON !X BLOCK]]
.sp
Compare the way HACKER deals with this. (Sussman).
.sp
.ti-5
3.\ \ \ Discuss the effects of limiting STRIPS to a depth-first
search (for each subgoal choose a relevant operator and don`t consider
any alternative until you`ve explored all possible ways of using this one and found
they all fail).
.sp
.ti-5
4.\ \ \ Discuss the problem of loops. What mechanism could detect that
you are going round in circles in your planning? Describe situations where this
could arise.
.sp
.ti-5
5.\ \ \ Discuss the problem of interacting subgoals. Give examples
of situations where achieving one subgoal might undo the effects of a
previous one, or might make a subsequent one impossible. Show how a
side-effect of achieving one sub-goal might be to make another unnecessary.
How could a problem-solver notice and make use of this?
.sp
.ti-5
6.\ \ \ Discuss the problem of incomplete knowledge. Besides the predictable
consequences of an action, there may be side-effects which you cannot know
about at the time of planning. Give examples. What implications does this have
for the design of an intelligent system?
.sp
.ti-5
7.\ \ \ How can a system learn to perform actions? How can it acquire knowledge of the effects of its actions?
.sp
.ti-5
8.\ \ \ Compare STRIPS and PLANNER as programming languages.
.in-5
.sp2
.mh
Reading
-------
(* = introductory)
.hm
.in+5
.ti-5
*Bundy et.al. TO ARTIFICIAL INTELLIGENCE, pp RK48 to RK68

.ti-5
*Margaret Boden's book
pp278-287, and Chapter 12.

.ti-5
Fikes & Nilsson in IJCAI-2, p608,ff.

.ti-5
Fikes et. al. in MI-7

.ti-5
Nillson, N.J, A hierarchical Robot Planning and Execution System,
SRI technical note 76, 1973 (in Cog. Studs Library).

And the following demos:

 	SEARCH1, SEARCH2, TP, MANDC,
