Introduction

To talk about classical planning we first have to introduce some terminologies:

  • deterministic → for each action there is only one outcome
  • stochastic → the effects of the actions can be uncertain or probabilistic
  • single-agent → just one agent plans his actions
  • multi-agent → multiple agents interact with the environment

And classical planning is deterministic, stochastic, fully-observable (you can acknowledge at every moment in which state it is), static (the changes can only by applied by us) and discrete (usually finite. It is indeed the simplest form of sequential decision making and the plan is the path from the unique initial state to a goal state.

Furthermore we can consider this kind of problems “relatively” simple (their general formulation is PSPACE-complete) but relevant. In further pages there will be stochastic multi-agent settings, which require (much) more complex plans prescribing how to act in every possible state (i.e. how to reach to every possible event/opponent move).

The search in this case consists of exploring the state space, even if there are many other search paradigms (encoding into constrains satisfaction, BDD representation) that we won’t consider.


Some example of classical planning problems

Finding a route in a map

  • starting from an initial state → departure city
  • apply actions → using a road segment
  • reach a goal state → destination city
  • performance measure → shortest time, shortest path, etc.

The “15-puzzle”

TODO: foto slide 6

  • starting from an initial state → left
  • apply actions → moving a tile
  • reach a goal state → right
  • performance measure: minimize summed-up action costs → each move has cost , so we minimize the number of moves

FreeCell

  • starting from an initial state → cards on table
  • apply actions → moving a card
  • reach a goal state → all cards “home”
  • performance measure: minimize summed-up action costs → each move has cost , so we minimize the number of moves

Finding bugs (in automata network)

TODO: foto slide 8

  • starting from an initial state → both idle
  • apply actions → automaton transitions
  • reach a goal state → error (both in critical section )
  • performance measure: minimize summed-up action costs → each move has cost , so we minimize the length of the error path

Classical planning terminology

We need to distinguish between satisficing planning and optimcal planning:

  • satisficing planning
    • input → a planning task
    • output → a plan for , or unsolvable if no plans for exists
  • optimal planning
    • input → a planning task
    • output → a cost-optimal plan for , or unsolvable if no plan for exists

State spaces

Every problem specifies a state space .

Def. state spaces

A state space is a tuple :

  • → finite set of states
  • → finite set of actions
  • → cost function
  • → transition relation. We require that is deterministic (i.e. there is at most one state such that ). If such exists, then is applicable to and results in state . We denote by the set of actions applicable to
  • → initial state
  • → set of goal states

We say that has the transition if . We also write , or when not interested in .

We say that has unit cost if, . We will often give each action a name, and identify with that name.

Terminology

  • successor of if , predecessor of if

  • reachable from if there exists a sequence of transition

  • → is the path from to

  • → is also called path from to

  • the cost of that path

  • reachable (without reference state) means reachable from

  • is solvable if some is reachable from , else is a dead end

Def. plans

Let be a state space, and let . A plan for is a path from to some . The plan is optimal if its cost is minimal among all plans for . A plan for is called plan for . If a plan exists then is solvable

Directed graph

Directed graph + mark-up for initial state and goal states
TODO: foto slide 16

Question

  • Does this have unit cost? No
  • Which actions are applicable to the initial state? actA, actB, actC
  • Is deterministic? No, on and , actG induces more than one outgoing transition
  • What for do we allow -cost actions? Negligible cost (e.g. switch light on)
  • Are all states in reachable? No, is not reachable
  • Are all states in solvable? No, is not solvable
  • What are the optimal plans for ? Any path that starts with actB, applies actE times, then applies actC then actE and then no actions other than actG

Find a route to Bucharest (formalization)

  • maps each to the length of the road segment

Koalas and gorillas

TODO: foto slide 22

Starting with everybody on the right bank we need to use the boat which carries animals to get everybody to the left bank. If koalas are outnumbered by gorillas on either bank is game over.

We consider only the states at the end of each boat ride, not the situation during the boat ride. At the end of each move, everybody leaves the boat (in other words, the animals in the boat count as being on the target river bank); and the game is over in case that results in more gorillas than koalas on either bank. Moves after which the game would be over are disallowed (i.e. these action are not applicable).

Formalization

  • where respectively represent the number of koalas, gorillas and boats currently in the bank
  • if , subtract or from and set , if , add or to and set . Both subject to having, after the move, as well as if , and if
  • accordingly

However in some problems state spaces may be huge. In particular, the state spaces is typically exponentially large in the size of its specification via the problem ; indeed huge space are (almost always) specified by small and so we wouldn’t be able to easily represent them. For this reason we need some specifications.


Specifications

Specifications are formal descriptions of what a system must do or the properties it must satisfy, necessary in order to solve a problem.

Let’s present the three possible ones.

Simulator specification

A simulator for a problem implements the procedures necessary to generate paths in the state space (we don’t need to represent the whole state space in advance, we generate successor states on demand by applying actions to the current state using the simulator).

Problem simulator API

  • InitialState() → returns the initial state of the problem
  • GoalTest(s) → returns a Boolean, true iff state is a goal state
  • Cost(a) → returns the cost of action
  • Actions(s) → returns the set of actions that are applicable to state
  • ChildState(s,a) → requires that action is applicable to state (i.e., there is a transition ). Returns the outcome state

In this case “specifying the problem” means programming the simulator.

A problem simulator provides procedures allowing to explore the state space incrementally and to determine goal states and plan cost. For this reason it’s required to respect the minimal functionality (i.e., only implement essential operations), but often is much easier to obtain than symbolic specification.

Symbolic (aka declarative) specification

A symbolic specification of comes from a declarative language.

Symbolic specification of a problem

There are many ways to do this. Here’s one:

  • → set of Boolean variables (prepositions)
  • → indicating which propositions are true in the initial state
  • → where is a goal state iff (all prepositions are satisfied)
  • → set of actions , each with precondition , add list , and delete list ; applicable to iff , outcome state is
  • → maps each to its cost

This language is called “STRIPS”. In this case “specifying the problem” means writing STRIPS

This specification is strictly more powerful than simulator, as it allows to implement the simulator and allows to analyze the problem however often is more difficult to obtain than a simulator.

Furthermore symbolic specification enable general planning, but is not used for search algorithms.
TODO: foto slide 29

Example

AzionePREADDDEL

obs

I don’t actually need , and then neither .

Starting from , I apply :

Closed-world assumption

We assume that what is inside is true, what is outside is false

The plan is : is applicable because .

Enumerative specification

The enumerative specification describes simply in terms of its state space.

Enumerative specification of a problem

We simply input the state space graph (in some implementation).

In this case “specifying the problem” means writing down the state space, but it’s impossible for large state spaces. However it can be solved easily in the size of the state space (Dijkstra’s algorithm).

Enumerative specifications do not, in difference to simulator and symbolic specification, compactly describe large state spaces. They are used if the state spaces are “small” (only 100.000s of states) and the runtime is very limited. This is typically the case in route planning.