STRIPS: "STanford Research Institute Problem Solver"

The Stanford Research Institute Problem Solver (STRIPS) is a classical problem solving system (now called a PDDL: Planning Domain Definition Language) which develops a list of actions which will reach a goal state from an initial state given a list of possible actions. STRIPS was developed for Shakey

It is an automated planning technique that works by executing a domain and problem to find a goal. With STRIPS, you first describe the world. You do this by providing objects, actions, preconditions, and effects. These are all the types of things you can do in the game world.

Once the world is described, you then provide a problem set. A problem consists of an initial state and a goal condition. STRIPS can then search (often using A*) all possible states, starting from the initial one, executing various actions, until it reaches the goal.

STRIPS Terms:

States: A list of knowns without variables or functions; in other words, they are limited to literals. Unlisted states are assumed to be false. May be:
- propositions e.g. "Big ^ Tall"
- first-order e.g. "At(Billy, Desk)"
Goal: The final desired state.
Actions: In three parts,
1. Name and parameter list
2. Preconditions: The states which must be true before the action can be used. Variables are allowed.
3. Effects: A list of function-free literals. Variables are allowed if they appear in the actions parameter list.

Example:

Action: PushBox(x, y)
Precond: BoxAt(x)
Effect: BoxAt(y), ¬ BoxAt(x)

Note: ¬ indicates that the state is deleted.

Note that your must describe the world at a very high symatic level (e.g. "block A is on block B" rather than "block A is at 2,7,5, block B is at 2,7,0 and is 4.9 high"). This very high level description enables efficient solution planning, and simple actions.

STRIPS and PDDL planning in general has both good and bad features:

The world is black and white; everything that is known is true, and everything else is false. "Billy" must be "At" somewhere and is therefore NOT at every other place. Billy can not be both at his desk and at work. Billy can be at his desk and doing work.

The search for a set of actions to a goal state can become very very costly to find, when the initial and goal states are very far apart (not incremental), and there are many possible actions which are incremental rather than major updates. To avoid this, it is critical to remember prior action sets as new single actions, and to train the system with incremental goals. Search optimization can also help; e.g. throwing out paths that seem to be increasing the goal distance, or prioritizing paths that most close the gap. A* or other path planning systems can help.
Without typing (which is available in many more modern PDDLs), it's possible for the system to confuse e.g. locations and objects. e.g. At(Billy, Banana) vs Buy(Billy, Banana).
Raising detailed sensor data to accurate high level semantic representations is often difficult. In the same way, translating high level action descriptions into low level commands can be error prone.