Classical planning deals with finding a sequence of actions transforming the envi- ronment from some initial state to a desired goal state, where the environment is
§6.2 Background 95
described by propositions. In Chapter 2, we described the set-theoretic representa- tion of a planning problem, which is defined by a tupleΠ = hM,A,C,I,Gi, where
M is a set of propositions, called atoms,Ais a set of actions,C is a cost function on actions, I ⊆ Mis the initial state, andG⊆ Mis the goal.
A planning problem can also be represented in a classical style, where we gener- alize the set-theoretic representation scheme using notations derived from first-order logic. In this representation, atoms are predicates (unlike propositions in set-theoretic representation) that are true or false within some interpretation, and actions are rep- resented by planning operators that change the truth values of these atoms. A plan- ning operator o = (name(o), pre(o), add(o), del(o)) is a generalized action (i.e. the action is a grounded instance of the operator), where name(o) = n(x1, ...,xk) (n is
an unique operator name, andx1, ...,xk are variable symbols as arguments appearing
in the operator) and pre(o), add(o), and del(o), are sets of (unground) predicates (i.e., atoms and negations of atoms), representing the preconditions, add, and delete effects of o respectively. The set-theoretic representation can be obtained from the classical representation by grounding. A planning domain represented in one of these representations can also be represented using the other representation.
Given the above preliminaries on planning operators in classical representation of planning problems, the rest of this section describes a theoretical background on macro-operators and entanglements necessary to explain our macro generation procedure.
6.2.1 Macro-operators
A macro-operator (or macro, for short) is a sequence of operators that are aggregated and added to a domain definition as a new individual operator. In the well known BlocksWorld domain [Slaney and Thiébaux, 2001], for example, we can observe that the operator pickup(?x) is often followed by the operator stack(?x, ?y). Hence, it might be reasonable to add a macro pickup-stack(?x,?y) in the domain definition which moves a block?xfrom a table directly to the top of the block?y, bypassing the situation where the block?xis held by the robotic hand.
A macro is constructed by assembling a sequence of planning operators. A gen- eral procedure to do that could be as follows: First, the procedure starts with an empty macro (i.e., empty sets of operators, variables, preconditions, and effects). At each step it appends one operator from the sequence to the current macro, and fixes the variable mapping (described later in this subsection) between the new operator and the macro. Adding a new operator o to a macro m modifies the precondition, add, and delete effects ofmaccording to the following rule.
Rule 1. The precondition, add, and delete effects of a macro oi,j = (name(oi,j), pre(oi,j),
(add(oi,j), del(oi,j)), formed by assembling two operators hoi,oji, according to their se- quence, wherepre(oj)∩del(oi) =∅, are as follows:
• pre(oi,j) =pre(oi)∪ {pre(oj)\add(oi)}
(:action pickup
:parameters (?x1 - block)
:precondition (and (clear ?x1) (ontable ?x1) (handempty)) :effect
(and
(holding ?x1))
(not (ontable ?x1)) (not (clear ?x1)) (not (handempty)) )) (:action stack
:parameters (?x2 - block ?y - block)
:precondition (and (holding ?x2) (clear ?y)) :effect
(and
(clear ?x2) (handempty) (on ?x2 ?y)) (not (holding ?x2)) (not (clear ?y)) )) (:action pickup_stack
:parameters (?x - block ?y - block)
:precondition (and (clear ?x) (ontable ?x) (handempty) (clear ?y)) :effect
(and (clear ?x) (on ?x ?y)
(not (ontable ?x) (not (clear ?y)) (not (holding ?x)) ))
Figure 6.1: Formation of pickup_stack macro. • del(oi,j) ={del(oi)\add(oj)} ∪del(oj)
An example of a macro is shown in Figure 6.1, where the macro pickup_stack is formulated by assembling the operatorshpickup, stackiin the order of their sequence according to Rule 1. Longer macros that encapsulate longer sequences of original planning operators can be constructed by this approach iteratively. However, for a macro oi,j to be sound, oi must not delete any predicate required by oj, otherwise
corresponding instances ofoi andoj cannot be applied consecutively.
A variable mapping is used to check the identity between operator’s predicates and macro’s predicates. Two predicates are considered identical if they have the same name and the same set of parameters. The variable mapping basically tells what variables (parameters) are common in both the macro and the new operator. In our macro generation process, a macro is constructed from a linearisation of some blocks extracted from a block deordered training plan based on some rules (described in Section 6.3.1). Since we construct a parameterised macro from a grounded sub- sequence (i.e., subplan) of a linearised plan, from a sequence of grounded actions which are, in fact, a plan segment (i.e., subplan), the variable mapping is established by analysing which objects the operators (i.e., actions) in the subplan share. For ex- ample, aggregating the actions of a subplan πsubi=hpickup(A),stack(A, B)i, where
the blockA we picked up is stacked on the other blockB, will form a macro action pickup-stack(A,B). Transforming these grounded actions into parameterised opera- tors will construct the macro pickup-stack(?x,?y) with the preconditions and effects as shown in Figure 6.1.
§6.2 Background 97
Figure 6.2: An illustrative example of outer entanglement [Chrpa et al., 2014].
tors, can be used in a planner independent way. Macros speed up planners since they can act as shortcuts to deeper states in the search tree [Botea et al., 2005; Coles et al., 2007; Newton et al., 2007]. Thus, by exploiting them it is possible to reach the goals in fewer steps, or to escape local heuristic minima. However, adding macros increase the size of grounded problem representation, and thus can be memory demanding by increasing the branching factor in the search tree. Therefore, it is important that benefits of macros’ exploitation outweigh their computational cost. This problem is known as theutility problem[Minton, 1990].
6.2.2 Outer Entanglements
Chrpa and McCluskey [2012] introduced outer entanglements that define the rela- tions between planning operators and initial or goal predicates. These relations are useful for eliminating potentially unnecessary instances of operators, as well as macros [Chrpa et al., 2014].
There are two types of outer entanglements, namely entanglement by initanden- tanglement by goal. An operator is entangled by init (resp. entangled by goal) with a predicate, if there exists a plan where all the operator’s instances require (resp., produce) instances of the predicate that correspond to initial (resp., goal) states. In the BlocksWorld domain [Slaney and Thiébaux, 2001], for example, we might ob- serve that unstacking blocks only occurs from their initial positions. Therefore, an entanglement by init will capture that if a predicate, say on(A,B), is to be achieved for a corresponding instance of the operator unstack(?x,?y), i.e., unstack(A,B), then
the predicate is present in the initial state. Similarly, we might observe that stacking blocks only occurs to their goal position. Then, an entanglement by goal will cap- ture that a predicate on(B,A) achieved by a corresponding instance of the operator stack(?x,?y),stack(B,A), is present in the goal state. In other words, we can say that the operatorunstackis entangled by init with the predicateon, and the operatorstack is entangled by goal with the predicateon. This is illustrated in Figure 6.2, where we can see that if theunstackoperator is entangled by init with theonpredicate only the instancesunstack(B,A) andunstack(C,B)follow the entanglement conditions. Thus, we can prune the rest of unstack’s instances because they are not necessary to find a solution plan. Similarly, we can prune all the stack’s instances except stack(A,B) andstack(B,C)if thestackoperator is entangled by goal with theonpredicate. Thus, outer entanglements can be used to prune potentially unnecessary instances of oper- ators that do not follow the entanglement conditions (i.e., they are not necessary to find a solution plan). Chrpa and McCluskey [2012] showed that while in the original setting the number of operator instances grows quadratically with the number of blocks, considering outer entanglements reduces the growth to linear.
Outer entanglements have been used as a reformulation technique, as they can be directly encoded into a domain and problem model. The way outer entanglements are encoded is inspired by one of their properties: given a static predicate ps (i.e., ps is not present in the effects of any operator), an operator o is entangled by init
with ps if and only if ps ∈ pre(o)[Chrpa and Barták, 2009]. Operators involved in
the outer entanglement relation with a non-static predicate are modified by putting a “static twin” of the predicate into the precondition. Instances of the “static twin” corresponding with initial or goal instances of the predicate are added into the initial state. Formally, let P be a planning problem, I be its initial state and Gbe its set of goal predicates. Let an operator o be entangled by init (resp. goal) with a predicate
p. Then the problem Pis reformulated as follows [Chrpa and McCluskey, 2012]: 1. Add a new static predicate p0 having the same arguments as p to the domain
model ofP.
2. Add p0 intoo’s precondition such that p0 has the same arguments as pwhich is in precondition (resp. positive effects) ofo.
3. Add instances of p0 which correspond to instances of pin I (resp. inG) into I.