6.2 LOLLIPOP
6.2.1 Operator Graph
Operator graphs, are a depedancy graph of all the operators in the domain with edges annotated with the fluent that can become a potential causal link.
Co nt ext -Sesitive Langu age s H ier arc hical T asks Ne two rk
N o P rec ondition & Eff ect s
o C
n te xt
F re e L ang uages = T ota lly
O rd
er ed
eg R
la u
r L an gu age s = Con dit io n a
lE ffe
cts T as k Insertio n
ST RIPS Acyclic
Legend
Languages HTN
STRIPS
Languages + STRIPS
Languages + HTN
Figure 6.6:Venn diagram of the expressivity classes of HTN paradigms.
Definition 6.2.1: Operator Graph
An operator graph 𝑔𝑂 of a set of operators 𝑂 is a labeled directed graph that binds two operators with the causal link 𝑜1 𝑓
−→ 𝑜2 if and only if there exists at least one fluent so that(𝑓 ∈eff(𝑜1)) ∧ 𝑓 ⊧pre(𝑜2).
This definition was inspired by the notion of domain causal graph as explained in (Gö-belbecker et al. 2010) and originally used as a heuristic in (Helmert et al. 2011).
Causal graphs have fluents as their nodes and operators as their edges. Operator graphs are the opposite: they are anoperator dependency graph for a set of actions.
A similar structure was used in (Peot and Smith1994) that builds the operator depen-dency graph of goals and uses precondition nodes instead of labels.
6.2.1.1 Building the graph
While building the operator graph, we need a providing map that indicates, for each fluent, the list of operators that can provide it. This is a simpler version of the causal graph that is reduced to an associative table easier to maintain. The list of providers can be sorted to drive resolver selection (as detailed in section6.2.3). We note𝑔𝒟the operator graph built with the set of operators in the domain𝒟.
Corridor Living-room Kitchen
Robot Keys
go(?movable, ?room)
?movable is Movable, ?room is Room pre ?movable room != ?room,
?room locked false eff ?movable room ?room
grab(?graber, ?pickable)
?graber is Graber, ?pickable is Pickable pre ?graber holds nothing,
?graber room = ?pickable room eff ?graber holds ?pickable
unlock(?graber, ?room)
?graber is Graber, ?room is Room pre ?room locked, ?graber holds keys eff ?graber holds nothing,
?room locked false
robot holds lollipop
Lollipop
a *
Figure 6.7:Example domain and problem featuring a robot that aims to fetch a lollipop in a locked kitchen. The operatorgois used for movable objects (such as the robot) to move to another room. The graboperator is used by grabbers to hold objects and theunlockoperator is used to open a door when the robot holds the key.
corridor locked false livingroom locked false
robot room corridor m room r
r locked false
Figure 6.8:Diagram of the operator graph of example domain. Full arrows represent the domain operator graph and dotted arrows the dependencies added to inject the initial and goal steps.
Example
In the figure 6.8, we illustrate the application of this mechanism on our exam-ple from figure 6.7. Continuous lines correspond to the domain operator graph computed during domain compilation time.
The generation of the operator graph is detailed in algorithm6. It explores the opera-tor space and builds a providing and a needing map that gives the provided and needed fluents for each operator. Once done it iterates on every precondition and searches for a satisfying cause to add the causal links to the operator graph.
Algorithm 6Operator graph generation and update algorithm
1: functionaddVertex(Action𝑎)
2: cache(𝑎) ▷Update of the providing and needing map
3: ifbindingthen ▷boolean that indicates if the binding was requested 4: bind(𝑎)
5: functioncache(Action𝑎)
6: for all𝑓 ∈eff(𝑎)do ▷Adds𝑎to the list of providers of𝑓
7: add(𝐴𝑝, 𝑓, 𝑎)
8: ... ▷Same operation with needing actions and preconditions
9: functionbind(Action𝑎) 10: for all𝑓 ∈pre(𝑎)do 11: if𝑓 ∈ 𝐴𝑝then
12: for allℼ ∈get(𝐴𝑝,𝑓)do
13: Link𝑙 ←getEdge(ℼ,𝑎) ▷Create the link if needed
14: addCause(𝑙,𝑓) ▷Add the fluent as a cause
15: ... ▷Same operation with needing and effects
6.2.1.2 Plan extraction from heuristic indexes
Using heuristics or pre-computed indexes is common in classical planning. A good por-tion of the research into PSP has been intended toward making the paradigm as ef-ficient than classical planning when using the new generation of heuristics from FD
Fast Downward
and LAMA (Richter and Westphal 2010). An example of this research is called VHPOP (Younes and Simmons 2003) that uses a kind of meta-heuristic by combining several heuristic approaches to allow for efficient flaw selection inPOCL.
In our case, the approach is completely different. We propose the use of data struc-tures usually used for heuristics as input data of a plan repair algorithm. The idea is to extract a partial plan that acts as scafolding for the planning algorithm to build a valid plan.
To apply the notion of operator graphs to planning problems, we just need to add the initial and goal steps to the operator graph. In figure 6.8, we depict this insertion with our previous example using dotted lines. However, since operator graphs may have cycles, they can’t be used directly as input toPOCLalgorithms to ease the initial back chaining. Moreover, the process of refining an operator graph into a usable one could be more computationally expensive thanPOCLitself.
In order to give a head start to theLOLLIPOPalgorithm, we propose to build operator graphs differently with the algorithm detailed in algorithm7. A similar notion was al-ready presented as “basic plans” in (Sebastiaet al. 2000). These “basic” partial plans
use a more complete but slower solution for the generation that ensures that each se-lected steps arenecessary for the solution. In our case, we built a simpler solution that can solve some basic planning problems but that also makes early assumptions (since our algorithm can handle them). It does a simple and fast backward construc-tion of a partial plan driven by the providing map. Therefore, it can be tweaked with the powerful heuristics of state search planning.
Algorithm 7Safe operator graph generation algorithm
1: functionsafe(Action𝜔) 2: Stack<Action>𝑜𝑝𝑒𝑛 ← [𝑎∗] 3: Stack<Action>𝑐𝑙𝑜𝑠𝑒𝑑 ← ∅ 4: while𝑜𝑝𝑒𝑛 ≠ ∅do
5: Action𝑎 ←pocl(𝑜𝑝𝑒𝑛) ▷Remove𝑎from𝑜𝑝𝑒𝑛
6: push(𝑐𝑙𝑜𝑠𝑒𝑑,𝑎) 7: for all𝑓 ∈pre(𝑎)do
8: Actions𝐴𝑝←getProviding(ℼ,𝑓) ▷Sorted by usefulness
9: if𝐴𝑝= ∅then 10: 𝐴𝑠← 𝐴𝑠⧵ {ℼ}
11: continue
12: Action𝑎′←getFirst(ℼ) 13: if𝑎′∈ 𝑐𝑙𝑜𝑠𝑒𝑑then
14: continue
15: if𝑎′∉ 𝐴𝑠then 16: push(𝑜𝑝𝑒𝑛,𝑎′) 17: 𝑆 ← 𝐴𝑠∪ {𝑎′}
18: Link𝑙 ←getEdge(𝑎′,𝑎) ▷Create the link if needed
19: addCause(𝑙,𝑓) ▷Add the fluent as a cause
This algorithm is useful since it is specifically used on goals. The result is a valid partial plan that can be used as input toPOCLalgorithms.