Conformant planning

Conformant planning is the problem of determining whether a plan (i.e. a series of actions) exists that always leads to the desired goal, regardless of the incompletely known initial state of the agent. Such problems are typically expressed using an action language.

An action language is built from a finite number of fluents f1, ..., fn. A state is a finite

set of fluents. The properties of the initial state s0 are described by formulas of the form

‘initially f’, which are called value propositions, with f a fluent literal, i.e. a fluent or a fluent preceded by ¬. Changes of states are defined using a finite number of actions

a1, ..., ak. Formulas of the form ‘a causes f if f1, ..., fm’ are called effect propositions,

with f, f1, ..., fm fluent literals and a an action. A domain D is a finite set of value and effect propositions. A proper domain, to which we limit ourselves in this thesis, is a domain in which we can determine in polynomial time what the successor state is, given the current state and an action. A plan is a sequence of actions [a1, ..., aj]. The planning

problemis to determine for a given domain D and a fluent literal f whether a plan exists

leading from s0 to a state in which f is true, where we call f the goal fluent. To solve

a planning problem, the domain is translated to ASP. Particularly, such a translation can be written as Pact∪ Premwhere Pactare those rules used to describe the actions, whereas

Premare the remaining rules that among others describe the (incomplete) initial state and

rules to ensure inertia. Then, a plan exists when an answer set contains the goal fluent. However, not all forms of planning problems can be solved in this way. When we say that we have an incomplete domain, this means that the initial values of some fluents are unknown. Conformant planning is the problem of determining whether for an incomplete domain and a fluent f a plan exists leading to a state in which f is true, regardless of the ini- tial values of the unknown fluents. Only some action languages, e.g. K [Eiter et al. 2000], have the expressive power to describe conformant planning problems. For solving such problems, DLVK_{relies on a two-step translation to ASP where a plan is generated (that}

5.3. APPLICATIONS an actual conformant plan is found. However, these methods are not designed to work with uncertainty and cannot, e.g. compute the most reliable plan when no conformant plan can be found.

Example 49

The BT (p) problem is the basic version of the bomb in the toilet problem, which we discuss in more detail in Section 6.5. We know that there are p packages, exactly one of which is a bomb (armed). There is one toilet in which we can dump these packages. If the package with the bomb is not dumped in the toilet, it remains armed. Once the package with the bomb is dumped in the toilet, the bomb deactivates (−armed) and we reach a safe state. The goal is to reach this safe state without knowing which package is the bomb. We assume concurrency, i.e. only a single package can be dumped each time step. An encoding in e.g. DLVK_{of this problem is:}

f l u e n t s : armed ( P ) r e q u i r e s p a c k a g e ( P ) . u n s a f e . a c t i o n s : dump ( P ) r e q u i r e s p a c k a g e ( P ) . a l w a y s : i n e r t i a l −armed ( P ) . c a u s e d −armed ( P ) a f t e r dump ( P ) . c a u s e d u n s a f e i f n o t −armed ( P ) . e x e c u t a b l e dump ( P ) . n o n e x e c u t a b l e dump ( P ) i f dump (Q) , P < > Q . g o a l : n o t u n s a f e ?

The only action that we can undertake is to dump a package in the toilet. In the

alwayssection we describe the inertia of the bomb, the effect of dumping the bomb,

the unsafe state, and when the action dump can or cannot be performed. The above encoding can then be translated to an equivalent ASP program [Eiter et al. 2000] (where we still need to provide the parameters on the number of packages to consider and the desired plan length). A solution to this planning problem for 4 packages and a plan length of 4 is e.g. the plan dump(1), dump(2), dump(3), dump(4), i.e. we sequentially dump the packages. Any permutation of this plan is clearly also a plan. The encoding of this problem in ASP is listed in Appendix 1.

We now show how conformant planning can be expressed in terms of a decision problem of the form N P |=b_{l
≥ λ. Note that the existence of a conformant plan can also be}

written as ∃p ∀iv·P (p, iv, pp) where P (p, iv, pp) describes that for the planning problem pp and for all initially unknown values iv the plan p leads to the goal fluent.

Proposition 38

Let Pconbe the possibilistic normal program defined for a conformant planning prob-

lem with the atom ‘goal’ the desired goal fluent. We express the domain knowledge as a normal ASP program Pact∪ Prem. Then Pcon is:

{0.5 : block i ← | ri∈ Pact} (5.7)

∪ {1 : head(ri) ← body(ri) ∪ {not block i} | ri∈ Pact} (5.8)

∪ {1 : r | r ∈ Prem} (5.9)

∪ {1 : ← not goal} _(5.10)

A conformant plan exists iff Π (Pcon|=cgoal) ≥ 0.5.

An extract of this translation for Example 49 is given in Appendix 2.

Contrary to cautious abductive reasoning, many performant solvers for conformant plan- ning exist, including DLVK_{. Nevertheless, such solvers cannot take certainties into}

account. For practical purposes though, when no “perfect” conformant plan exists, a plan that is conformant with a “high certainty” is preferred over choosing a plan arbitrarily.

Example 50

A firm has a client calling from city C to ask for an appointment the next day. The secretary knows that the sales person is either in city A (inA) or city B (inB). The secretary is almost certain (resp. absolutely certain) that a sales person can get from city A (resp. city B) to city C in one day (toC), assuming there is no road block. There are some rumours of a possible road block on the route from city A to C. Cities A and B also connect to city D, which is definitely reachable in one day from A and B (toD). This problem can be encoded as the following ASP program:

1 : inA ← not inB 0.8 : toC ← inA, gotoC, not blockAC 1 : inB ← not inA 1 : toD ← inA, gotoD, not blockAD 0.2 : blockAC ← 1 : toC ← inB, gotoC, not blockBC