By relying on the sat_core module, as described in Section 4.1, on the linear real arithmetic theory, as described in Section 4.2, and on the object variables theory, as described in Section 4.3, it is possible to create new propositional, numeric and object variables and enforcing constraints on them. Moreover, in case of inconsistencies, it is possible to generate explanations which can be used to allow no-good learning, avoiding the reemergence of similar, inconsistent, situations, and non-chronological backtracking.
Thanks to the linear real arithmetic theory, which abandons arc-consistency prop- agation in favor of the Simplex method, the introduced constraint network is able to manage numeric variables with an initial infinite domain. Nonetheless, inconsistent situations are quickly detected and exploited, in concert with other theories and with the sat_core module, to allow no-good learning and non-chronological backtracking. Numeric variables can be used to represent, uniformly, different numeric aspects of the planning problem including time, resource consumption amounts, resource capacities, etc. The link between temporal variables and other dimensions becomes, therefore, easy, allowing to relate, for example, resource consumption amounts to temporal spans. As mentioned earlier, the sat_core module does not implement any search al- gorithm. Unless it is an explicit consequence of constraints propagation, non of the variables will be assigned. Search is, in other words, demanded to the sat_core’s user applications that can choose which literal to assume and, consequently, what variables consider as relevant in generating solutions. The resulting constraint network will be exploited, in the following chapter, both for generating a new heuristic and for propa- gating constraints during the resolution process.
5
The Critical-Path Heuristics and the
OR
ATIOSolver
By relying on the data structures presented in Chapter 4, this chapter introduces two new heuristics and a new solver architecture for solving timeline-based planning prob- lems. The overall proposed idea consists in applying, in a coarse way, all possible resolvers for all possible flaws until some termination criteria, i.e., unifications and re- solvers which do not add further flaws, is met. Specifically, since flaws and resolvers are causally related (i.e., resolvers might introduce flaws which are solved by other re- solvers) it is possible to build an AND/OR graph for representing such causal relations. By exploiting the topology of such a graph it is possible to generate an estimation of “how far” a flaw is from being solved and exploit this estimation for guiding the res- olution process. Specifically, taking inspiration from the hadd and the hmax heuristics
introduced in Section 2.1.1, the cost of a resolver, which can be seen as an AND node, can be estimated as the sum (or the maximum, in case of hmax) of the estimated costs
of the flaws introduced by the resolver itself plus an intrinsic resolver’s cost, while the estimated cost of a flaw, which can be seen as an OR node, can be estimated as the minimumof the estimated costs of its possible resolvers. It is worth noting that gener- ating such a cost estimation is equivalent to identifying a critical path within the causal graph that can be used for choosing resolvers at resolution time, hence, the name of the heuristic.
Conversely from the hadd and the hmax heuristics for classical planning, the pro-
posed heuristic does not rely simply on propositions. The state is, indeed, described, also, by numerical variables representing, for example, time, precluding, in the most general case, the possibility of generating ground expressions. This enhancement re- sults into the need to manage the atomic formulas while keeping the variables lifted and, hence, similarly to what has been done in [46] in the case of functional STRIPS [52], strongly relying on constraint propagation capabilities already in the heuristic generation phase. Furthermore, continuing in the wake of [29] and somehow inspired by [111], the concept of reification is applied, in addition to resolvers, to flaws as well. As a consequence, rather than maintaining the flaws into an agenda data structure, as proposed in Section 2.3 and implemented in common timeline-based planners, flaws
Figure 5.1: The topology of the causal graph is exploited for recognizing a critical path.
arise as a consequence of the sat_core module’s propagation. Additionally, the atom network should be adapted so as to maintain, besides the sole atoms in the solver’s current state, also all the possible atoms that may exist in all possible states that can be reached by the planner. As we shall see, this can be achieved by introducing a state variable σ to be assigned to each atom of the atom network and including, among the constraints, also the causal ones. This paradigm shift, however, requires a complete architecture refactoring which has lead to the development of a new planner, called
ORATIO, and to the introduction of a new language, calledRIDDLE(from oRatIo Do- main Definition LanguagE), for expressing timeline-based planning problems.
Figure 5.1 shows a synthetic example of such a generated graph. In the picture, flaws are represented through boxes and, since any of their resolvers should be applied to resolve a flaw, are OR nodes. As an example, f law0can be solved either by apply-
ing the res0resolver or by applying the res1resolver. Resolvers, on the other hand, are
represented through ovals and, since all the flaws introduced by them must be solved, are AND nodes. As an example, resolving f law0 through res0introduces both the
f law1and f law2flaws. The critical path for solving the problem is highlighted in the
figure. In particular, once built the graph, a possible solution for the planning prob- lem might consist in applying, at first, resolver res0. This results in the “activation” of
flaws f law1and f law2which might be solved by applying, respectively, the res3and
res4resolvers. It is worth noting that resolvers res1, res2, res5and res6, as well as the
flaws f law3, f law4, f law5 and f law6, although not included into the final solution,
are nonetheless considered into the graph. Furthermore, their associated atoms and constraints, included the causal ones, must be introduced into the atom network and, hence, into the underlying constraint network. Building such a graph allows to con- sider, in a relaxed way, all the possible plans which can be generated starting from a given planning problem. Relaxation, in particular, comes from neglecting the possible interactions among resolvers/subgoals. It might be the case, for example, that resolvers res3and res4, both in the identified critical path, although individually applicable, are
not applicable simultaneously.
Before going into further details in explaining the heuristic, however, it is worth to introduce some of the main concepts underlying the solver. In particular, as a conse- quence of flaws and resolvers reification, it is worth to explain in detail how such data
Figure 5.2: The overallORATIOarchitecture.
structures are made. This would allow to have a better idea of how the graph is built and how the solving process works.
5.1
The
ORATIOarchitecture
Figure 5.2 broadly describes theORATIOarchitecture. While the lower part refers to the data structures introduced in Chapter 4 (i.e., the sat_core presented in Section 4.1, the LRA theory presented in Section 4.2 and the OV theory presented in Section 4.3), the upper part refers to the main data structures introduced in this chapter. To begin, the external interface of theORATIOsolver, through which a user can specify problems and solve them, is the following.
c l a s s s o l v e r : t h e o r y { v o i d r e a d ( s t r i n g s c r i p t ) v o i d r e a d ( v e c t o r < s t r i n g > f i l e s ) v o i d s o l v e ( ) s a t _ c o r e s a t l a _ t h e o r y l a o v _ t h e o r y s e t }
Intuitively, the solver is feed through the two read() methods which, respectively, parse aRIDDLEscript and a collection of files containingRIDDLEcode (for a complete description of theRIDDLElanguage refer to Chapter 6). The problem is subsequently solved through the solve() method which either finds a solution or returns with an unsolvable exception. Finally, the solver maintains a reference to the sat_core, to the linear real arithmetic theory and to the object variables theory presented in Chapter 4.
It is worth to notice that the solver is, itself, a theory and is bounded to the sat_core. Specifically, as a theory, the solver is notified for the assignment of the bound variables by the sat_core which, additionally, calls the solver’s push() and pop() methods for allowing it to store the context before creating a branch. As will be shown soon, this will allow the solver to receive updates about flaws activation and resolvers’ state.
Figure 5.3 describes, in further details, some of the most important data structures required by the solver for maintaining information. Specifically, env and scope rep- resent abstract data structures for retrieving instances, types and predicates. The item structure is used for representing instances of a specific type. It contains, indeed, a ref- erence to the type data structure which is used for representing such types. It is worth to notice the two depicted operations for the item type (i.e., equates and eq). Specif- ically, equates compares efficiently, yet incompletely, two items returning a boolean indicating whether the comparison was successful. This method makes it possible to make the unification checking process more efficient by discarding, without the need to create new variables, those unifications which are trivially unfeasible. Two arithmetic variables whose domains are, respectively, [0, 10] and [20, 30], for example, regardless of the involved constraints, can never be made equal. On the other hand, the eq method deeply compares two items returning a propositional variable which, like the reified constraints described in Section 4.1.3, represents whether the unification constraint is satisfied or not. Both the methods are applied iteratively to all the member fields of the items (i.e., those contained in the items field of the env data structure). It is worth to no- tice that although knowing two items equate does not imply their unifiability, knowing two items do not equate ensures that the two objects are not unifiable.
Bool items, arithmetic items and var items are specific data structures for managing instances of primitive types which, in addition to keeping references to literals, linear expressions and object variables, as defined in Chapter 4, redefine the equates and eq operators. Finally, while atoms are a special kind of items, predicates are modeled as a special kind of types. This allows to efficiently recover all atoms having a given pred- icate and, thus, useful for computing unifications, and, at the same time, to associate a predicate to each atom.
It is worth to notice that while the parameters associated to the atoms are retriev- able through the items field of the env abstract data structure, to which the equates and eqmethods also refer, each atom has its own state variable σ ∈ {INACTIVE, ACTIVE, UNIFIED}. Such a variable indicates the state of the atom and allows for all the possible
atoms, including those which are not in the current partial solution, to stay, together, in the same atom network. By exploiting the features of the SMT-based constraint net- work presented in Section 4, these variables can be represented through propositional variables with the assumption that UNASSIGNEDvariables indicate INACTIVEatoms, TRUEassignments indicate ACTIVEatoms and FALSEassignments indicate UNIFIED
atoms.
The last aspect to consider regards timelines. As already said in Chapter 3, and as it will be further detailed in Section 5.6, timelines are specific types whose role consists in generating further flaws which are peculiar to the specific timeline type (e.g., different states overlapping on a state-variable, resource overusages, etc.).