Classical Planning 2 History: STRIPS Planner
Classical Planning 2 History: STRIPS Planner
CS 440/ECE 448
Fall 2020 Classical Planning 2
Margaret Fleck
History
Classical planning is called that because it goes back to the early days of AI. A simple version
popularized by the STRIPS planner, created by Richard Fikes and Nils Nilsson 1971 at SRI.
(STRIPS is short for Stanford Research Institute Problem Solver.)
These days, a planner would most likely be used to manage the high-level goals and
constraints of a complex planning problem. For example, it might set the main way points
for a mobile robot or a robot doing assembly/disassembly tasks. A neural net or specialized
robotics code would then be used to fill in the details.
Stories
A planner can also be used to generate stories. These may be freestanding stories (e.g. like a
novel). More often, these systems also include human interaction.
Neural nets can do a good job of filling in details, e.g. generating sentences given a sketch of
what they should say. But they aren't (at least so far) good at keeping the high-level plot
under control. E.g. see this article on automatically-generated Harry Potter stories.
In news reports, common events can be summarized in terms of standard features. E.g.
an earthquake has a location, a date, death toll, major aid agencies assisting.
Everyday actions often follow "scripts" that have only a few variations, e.g. the main
events of having a meal in a restaurant.
Understanding a story often requires filling in missing details that are obvious to humans.
E.g. two people leave a store and the cashier runs out after them. Why? Well maybe to
1 of 3 5/10/21, 01:47
CS440 Lectures https://courses.grainger.illinois.edu/cs440/fa2020/lectures/pla...
return a forgotten credit card. A human knows the payment script well enough to realize
that it involves returning the card.
If we handle such constraints explicitly, our action descriptions end up needing a lot of
frame axioms. This is a waste of memory. But, much more important, it is an invitation to
bugs: writing out long lists of frame axioms means that some will inevitably be left out. This
nuisance is called the "frame problem." It's usually solved by incorporating a default
assumption that properties don't change unless actions explicitly change them. (We've been
tacitly assuming that.)
First, we need ways to represent type hierarchies for objects, e.g. pie is a type of desert and
deserts are a type of food. For example, washing a tablecloth should use the same action as
washing a napkin. Eating an apple is similar to, but not identical to, eating rice. So perhaps
they should inherit some of their representation from a shared ancestor. Then we might
define actions that can be used on any object from a broad range of types.
A closely-related problem is making it possible to have multiple objects of the same type
(e.g. two napkins).
Some object properties should be called out as predicates. In a kitchen scenario, many types
of object are movable (e.g. eggs, kettle) but some are not (e.g. the counters) and some (e.g.
the stove) should be considered non-movable for most routine planning. However, it's not
immediately obvious when we should create an explicit predicate (e.g. movable) vs. having
rules that target only certain types of objects.
We might want to specify relationships among predicates. For example, how are cold and
2 of 3 5/10/21, 01:47
CS440 Lectures https://courses.grainger.illinois.edu/cs440/fa2020/lectures/pla...
hot related? Also might want a "Truth Maintenance System" to spell out the consequences of
each proposition. For example, automatically account for the fact that the teabag cannot be
in two places at once. Such knowledge and inference would allow more succinct (and likely
more correct) state and action definitions.
Harder environments
A final issue is that planning may need to work in less tightly managed environments. These
might include:
3 of 3 5/10/21, 01:47