HDDL – A Language to Describe Hierarchical Planning Problems

HDDL – A Language to Describe Hierarchical Planning Problems

D. Höller, G. Behnke, P. Bercher, S. Biundo, H. Fiorino, D. Pellier and R. Alford
Institute of Artificial Intelligence, Ulm University, 89081 Ulm, Germany
{daniel.hoeller, gregor.behnke, pascal.bercher, susanne.biundo}@uni-ulm.de
University Grenoble Alpes, LIG, F-38000 Grenoble, France
{humbert.fiorino, damien.pellier}@imag.fr
The MITRE Corporation, McLean, Virginia, USA

The research in hierarchical planning has made considerable progress in the last few years. Many recent systems do not rely on hand-tailored advice anymore to find solutions, but are supposed to be domain-independent systems that come with sophisticated solving techniques. In principle, this development would make the comparison between systems easier (because the domains are not tailored to a single system anymore) and – much more important – also the integration into other systems, because the modeling process is less tedious (due to the lack of advice) and there is no (or less) commitment to a certain planning system the model is created for. However, these advantages are destroyed by the lack of a common input language and feature set supported by the different systems. In this paper, we propose an extension to PDDL, the description language used in non-hierarchical planning, to the needs of hierarchical planning systems. We restrict our language to a basic feature set shared by many recent systems, give an extension of PDDL’s EBNF syntax definition, and discuss our extensions with respect to several planner-specific input languages from related work.

1 Introduction

During the past years, much progress has been made in the field of hierarchical planning. Novel systems based on the traditional, search-based techniques have been introduced [Bit-Monnot, Smith, and Do2016, Shivashankar, Alford, and Aha2017, Bercher et al.2017, Höller et al.2018], but also new techniques like the translation to STRIPS/ADL [Alford, Kuter, and Nau2009, Alford et al.2016a], or revisited approaches like the translation to propositional logic [Behnke, Höller, and Biundo2018a, Behnke, Höller, and Biundo2018b, Behnke, Höller, and Biundo2019, Schreiber et al.2019]. In contrast to earlier systems, all given systems can be considered to be domain-independent, i.e., they do not rely on hand-tailored advice to solve planning problems, but on their solving techniques.

Even though the systems share the basic idea of being hierarchical planning approaches, the feature set supported by the different systems is wide-spread: \citeauthorBitMonnotSD16 \shortciteBitMonnotSD16 focuses, e.g., on advanced support for temporal planning, but lack the support for recursion; several systems are restricted to models that do not include partial ordering [Alford, Kuter, and Nau2009, Behnke, Höller, and Biundo2018a, Schreiber et al.2019]; and some, like the one by \citeauthorShivashankarAA17 \shortciteShivashankarAA17 even define an entirely new type of hierarchical planning problems.

Even systems restricted to the maybe best-known and most basic hierarchical formalism, called hierarchical task network (HTN) planning, do not share a common input language, though the differences between the input languages are sometimes rather subtle, e.g. between the formalisms of \citeauthorAlford2016Bound \shortciteAlford2016Bound and \citeauthorBercher17AdmissibleHTNHeuristic \shortciteBercher17AdmissibleHTNHeuristic. To the best of our knowledge, the hierarchical language introduced for the first International Planning Competition (IPC) by \citeauthorMcDermott98PDDL \shortciteMcDermott98PDDL is not supported by any recent system.

The lack of a common language has several consequences for the field. First, it makes the comparison between the systems tedious due to the translation process. Second – and even more important – it makes the use of hierarchical planning from a practical perspective laborious, because it is not possible to model a problem at hand and try which system performs best on the final model. Selecting the best-fitting system in beforehand (if possible) requires much insights into the systems.

A common description language would make the comparison of the systems easier, it could foster a common set of supported features and result in a common benchmark set the systems are evaluated on.

In this paper, we propose the hierarchical domain definition language (HDDL) as common input language for hierarchical planning problems. It is widely based on and fully compatible to the input language of the planners by \citeauthorBercher17AdmissibleHTNHeuristic \shortciteBercher17AdmissibleHTNHeuristic, \citeauthorpandapro18 \shortcitepandapro18, \citeauthorBehnke2018totSAT \shortciteBehnke2018totSAT, and \citeauthorBehnke2019orderchaos \shortciteBehnke2019orderchaos. We define it as an extension of the STRIPS fragment (language level 1) of the PDDL2.1 definition [Fox and Long2003]. To concentrate on a set of features shared by many systems, we restricted the language to basic HTN planning. However, we hope that the given definition is just the starting point for further language extensions like the first PDDL in classical planning.

We start by introducing a lifted HTN planning formalism from the literate, before we introduce our language by example. We go through the new language elements, introduce their syntax and meaning, discuss our design choices and the differences to several approaches from the literature, namely PDDL1.2 [McDermott et al.1998], SHOP(2) [Nau et al.2003], ANML [Smith, Frank, and Cushing2008], HPDDL [Alford et al.2016a], GTOHP [Ramoul et al.2017], and HTN-PDDL [González-Ferrer, Fernández-Olivares, and Castillo2009]. We then give a full EBNF syntax definition111When the paper gets accepted, we will provide syntax definitions of our language for the ANTLR and Bison parser generators to support the integration into planning systems. based on the definition of PDDL2.1 and discuss every extension and change. We conclude with a short outlook.

2 Lifted HTN Planning

In this section we formally define the problem class HDDL can describe. It is standard hierarchical task network (HTN) planning in line with the text book description by \citeauthorGhallab04AutomatedPlanning \shortciteGhallab04AutomatedPlanning. To define the formal framework we extend the formalization of \citeauthorAlford15TightHTNBounds \shortciteAlford15TightHTNBounds,Alford15TightTIHTNBounds.

Our lifted formalism is based upon a quantifier-free first-order predicate logic with the following elements. is a finite set of predicate symbols, each having a finite arity. The arity defines its number of parameter variables (taken from ), each having a certain type (defined in ). Thus, is a finite set of type symbols as is also known from PDDL. is a finite set of typed variable symbols to be used by the parameters of the predicates in . is a finite set of typed constants. They are the syntactic representation of the objects in the real world. Please be aware that a single constant can have several types, e.g. truck and vehicle to support a type hierarchy.

The most basic data structure in HTN planning is a task network. Task networks are partially ordered sets of tasks.

In contrast to classical (non-hierarchical) planning, there are two kinds of tasks in HTN planning: primitive and compound ones. Task networks can contain both primitive tasks (also called actions) and compound tasks (also called to be abstract). Each task (primitive or compound) is given by its name, followed by a parameter sequence. For instance, a (primitive) task for driving from a source location to a destination location is given by the first-order atom . We do not differentiate between the expressions task and task names – both are used synonymously.

Definition 1 (Task Network).

A task network over a set of task names (first-order atoms) is a tuple with the following elements:

  1. is a finite (possibly empty) set of task identifiers.

  2. is a strict partial order over .

  3. maps task identifiers to task names.

  4. is a set of variable constraints. Each constraint can bind two task parameters to be (non-)equal and it can constrain a task parameter to be (non-)equal to a constant, or to (not) be of a certain type.

The task identifiers are arbitrary symbols which serve as place holders (or labels) for the actual tasks they represent. We need these identifiers because any task can occur multiple times within the same task network, but the partial order needs to be able to differentiate between them. We call a task network ground if all task parameters are bound to (or replaced by) constants from .

Task networks can contain primitive and/or compound tasks. Primitive tasks are identical to actions known from classical planning. An action is a tuple with the following elements: name is its task name, i.e., a first-order atom like consisting of the (actual) name followed by a list of typed parameter variables. pre is its precondition, a first-order formula over literals over ’s predicates. eff is its effects, a conjunction of literals over ’s predicates. All variables used in pre and eff are demanded to be parameters of name. We also write name(a), pre(a), and eff(a) to refer to these elements. We also require that for each task name name(a) there exists only a single action using it as its name (this way, names can be used as unique identifiers).

A compound task is simply a task name, i.e., an atom. In contrast to primitive tasks its purpose is not to induce a state transition, but to reference a pre-defined mapping to one or more task networks by which that compound task can then be refined. They do thus not use preconditions or effects. However, there are many hierarchical planning formalisms that do also feature preconditions and/or effects for compound tasks [Bercher et al.2016], but they are not within the scope of this paper. The before-mentioned mapping from compound tasks to pre-defined task networks is given by a set of decomposition methods . A decomposition method is a tuple consisting of a compound task name , a task network , and a set of variable constraints . The variable constraints allow to specify (co)designations between the parameters of and those of the task network .

Definition 2 (Planning Domain).

A planning domain is a tuple defined as follows.

  • is the underlying predicate logic.

  • and are finite sets of primitive and compound tasks, respectively.

  • is a finite set of decomposition methods with compound tasks from and task networks over the names .

The domain implicitly defines the set of all states , being defined over all subsets of all ground predicates.

Definition 3 (Planning Problem).

A planning problem is a tuple , where:

  • is the initial state, a ground conjunction of positive literals over the predicates assuming the closed world assumption.

  • is the initial task network that may not necessarily be ground.

  • is the goal description, being a first-order formula over the predicates (not necessarily ground).

HTN planning is not about finding courses of action achieving a certain state-based goal definition, so it makes perfect sense to specify no goal formula at all. In fact, goal formulas can trivially be simulated by the task hierarchy [Geier and Bercher2011]. We added them anyway to be closer to the HDDL specification given later on. Having such a goal formula in the input specification is more convenient in case one actually wants to specify one in the addition to the task hierarchy.

We still need to define the set of possible solutions for a given problem. Informally, solutions are executable, ground, primitive task networks that can be obtained from the problem’s initial task network via applying decomposition methods, adding ordering constraints, and grounding.

Lifted problems are a compact representation of their ground instantiations that are, as in classical planning, up to exponentially smaller [Alford, Bercher, and Aha2015a, Alford, Bercher, and Aha2015b]. However, we define solutions based on their grounding. The semantics of such a lifted problem is thus defined in terms of the standard semantics of its ground instantiation. We assume that the reader is familiar with the grounding process and refer to the paper by \citeauthorAlford15TightHTNBounds \shortciteAlford15TightHTNBounds for details about it. To the best of our knowledge there is currently only one publication devoted to grounding in more detail [Ramoul et al.2017]222Please be aware that the procedure described there allows to delete effectless actions [Ramoul et al.2017], which is not allowed in HTN planning. This would, for example, invalidate the compilation process for goal descriptions. We now give the required definitions based on a ground problem and domain. Note that we do not need to represent variable constraints anymore since their constraints are already represented within the groundings.

Given ground problems/models we can now define executability of task networks. Let be the set of ground actions obtained from . An action is called executable in a state if and only if . The state transition function is defined as usual: If is executable in , then , otherwise is undefined. The extension of to action sequences, is defined straightforwardly.

Definition 4 (Executability).

A task network is called executable if and only if there is a linearization of its task identifiers , , such that is executable in .

The essential means of transforming one task network into another – to obtain executable task networks – is decomposition.

Definition 5 (Decomposition).

Let be a decomposition method, a task network, and (the latter can be achieved by renaming). Then, decomposes a task identifier into a task network if and only if and

We have now defined all prerequisites required to define the criteria under which a task network can be considered a solution.

Definition 6 (Solutions).

Let be a planning problem with and . is a solution to an HTN planning problem if and only if

  • There is a sequence of decompositions from to , such that , , and

  • is primitive and has an executable action linearization leading to a state .

3 HDDL by Example

In this section we explain our extensions to the PDDL definition based on a transport domain. To keep the example simple, the domain includes only a single transporter that has to deliver one or more packages. For each new language element we introduce its syntax and meaning and discuss the way it is modeled in other input languages.

The predicate and type definition is the same as in PDDL:

1(define (domain transport)
2  (:types location package - object)
3  (:predicates
4     (road ?l1 ?l2 - location)
5     ...)
Figure 1: The method set of a simple transport domain. Actions are given as boxed nodes, abstract tasks are unboxed. All methods are totally ordered.

The full method set of the domain is illustrated in Figure 1. Each method will be discussed in this section.

The domain contains two abstract tasks and . We propose to include an explicit definition of abstract tasks as it is the case for actions. HPDDL [Alford et al.2016a] also defines abstract tasks explicitly, albeit with a slightly different syntax. Both ANML [Smith, Frank, and Cushing2008] and HTN-PDDL [González-Ferrer, Fernández-Olivares, and Castillo2009] require an explicit declaration of abstract tasks and their parameter types as well, but here the declaration is not separated from other elements of the domain as both declare methods together with their abstract tasks.

Some description languages for HTN problems define abstract tasks only in an implicit way by their use in methods. This includes the language used by SHOP and SHOP2 [Nau et al.2003], PDDL1.2 [McDermott et al.1998], as well as GTOHP [Ramoul et al.2017]. SHOP and GTOHP assume that any task that is used in a method, but is not declared to be an action is an abstract task. In contrast, PDDL1.2 assumes that every task that has no methods is primitive. This way of implicitly defining the set of compound tasks has also been chosen in some formal definitions of hierarchical problem classes [Alford, Bercher, and Aha2015a, Alford, Bercher, and Aha2015b]. However, this can be very cumbersome when debugging domains. If the modeler forgot to define a specific primitive task, the domain will still be valid, as it would be interpreted as an abstract task.

Another problem with such a definition is that the argument types are defined implicitly, namely as those with which the task can be instantiated via any method. Note that the language of GTOHP [Ramoul et al.2017] further does not allow for using different types (that share a common ancestor in the type hierarchy) to be used for the same task. For example, there might be different methods for the task, depending on the type of transported package. might have two methods, one where the first argument is of type and one where it is of type , the latter requiring an armoured transporter. We assume that and are disjunct types, but have a common super-type , which would be the correct parameter type for ’s first argument. If its type is not declared explicitly, the planner can either reject the domain, as GTOHP does, or would have to infer the possible types of the arguments of an abstract task.

Declaring abstract tasks and their parameter types explicitly is also in line with the design choices of PDDL. Similar to abstract tasks, PDDL could omit the explicit definition of predicates as their types could be inferred from their usages. This is however discouraged from a modeling point-of-view.

Omitting the distinct definition of tasks and methods would also mean a significant deviation from the contemporary theoretical work on HTN planning. It could also hinder further language extensions like annotating abstract tasks with constraints, e.g. preconditions and effects of abstract tasks as used by a couple of systems (see e.g. the survey by \citeauthorBercherHBB16, \citeyearBercherHBB16).

Here is the abstract task definition for the example:

1  (:task deliver :parameters (?p - package  ?l - location))
2  (:task get-to :parameters (?l - location))

There is only a single method in the model to decompose deliver tasks (given at the top of Figure 1). It decomposes the task into four ordered sub-tasks: getting to the package, picking it up, getting to its final position, and dropping the package. The definition in HDDL could look like this:

5  (:method m-deliver
6    :parameters (?p - package ?lp ?ld - location)
7    :task (deliver ?p ?ld)
8    :ordered-subtasks (and
9      (get-to ?lp)
10      (pick-up ?ld ?p)
11      (get-to ?ld)
12      (drop ?ld ?p)))

The method definition starts with the name of the method that can e.g. be used to describe the decompositions needed to find a solution. We decided to give the method’s parameters explicitly (line 3). This allows e.g. to restrict the types used in the subtasks to subtypes of the original task parameters. To be correctly defined, we assume this parameters to be a superset of all parameters used in the entire method definition. The parameter definition is followed by the specification of the abstract task decomposed by the method as well as its parameters (line 3).

The same syntactical structure is used by HPDDL [Alford et al.2016a]. ANML [Smith, Frank, and Cushing2008], PDDL1.2 [McDermott et al.1998], and HTN-PDDL [González-Ferrer, Fernández-Olivares, and Castillo2009] aggregate all decomposition methods belonging to a single abstract task, which have to be declared as part of the definition of an abstract task. As such, the variables that are declared as the arguments of an abstract task are automatically variables in a method’s task network.

In GTOHP’s language, methods don’t have names, but are identified via the abstract task they refine.

In SHOP, all variables inside a method are only defined implicitly by their usage as parameters of tasks and predicates inside the method. For example, the definition of a SHOP method starts with :method followed by an abstract task and its parameters – which if they are variables are automatically declared as new (untyped) variables. The same holds for variables that only occur as parameters of a method’s subtasks. GTOHP and HTN-PDDL follow this pattern, but enforce that the parameters of the abstract task are typed, i.e. declared explicitly. Their languages however do not allow to specify the types of variables that occur in the method that are not parameters of the abstract task. Declaring the variables is, again, in line with the PDDL standard and e.g. done the same way in actions. We think it less error-prone. When the modeler explicitly defines the variables and their types, the system can check the compatibility of types and warn the modeler when undeclared variables are used (e.g. due to a spelling error).

The subtasks of the method are given afterwards (starting in line 3). We decided to have two keywords to start the definition :ordered-subtasks (as given here) and :subtasks (which we will show in the next method). When the :ordered-subtasks keyword is used, the given list of subtasks is supposed to be totally ordered. HPDDL [Alford et al.2016a] uses the keyword :tasks, which might cause errors if mixed up with the :task keyword. Since GTOHP [Ramoul et al.2017] does only support totally-ordered HTN planning problems, their language only allows for specifying sequences of actions with the keyword :expansion.

In the subtask section, all abstract tasks and actions defined in the domain may be used as subtasks, all variables defined in the method’s parameter section may be used as parameters of the subtasks.

The task form our example domain is again abstract and may be decomposed by using one of the three methods given at the bottom of Figure 1. We start with the left one that is used when there is no direct road connection. Then the transporter needs to go to the final location via some intermediate location . Therefore the method decomposes the task into another abstract task, followed by a action with the destination location .

2  (:method m-drive-to-via
3    :parameters (?li ?ld - location)
4    :task (get-to  ?ld)
5    :subtasks (and
6      (t1 (get-to ?li))
7      (t2 (drive ?li ?ld)))
8    :ordering (and
9      (t1 < t2)))

Line 3 shows the aforementioned :subtask definition that allows for partially ordered tasks. The task definition contains IDs that can be used to define ordering constraints (line 3). They consist of a list of individual ordering constraints between subtasks, identified by their IDs. However, in the given example the resulting ordering is, again, a total order (and is just defined that way to demonstrate this kind of definition).

HPDDL [Alford et al.2016a] uses the same keyword, but a slightly different syntax so specify ordering constraints. \citeauthorAlford2016Bound’s format omits the and and the < signs. We would argue that our notation is better readable to humans. As stated above, GTOHP [Ramoul et al.2017] cannot specify partial orders. ANML – as it is primarily designed for temporal domains – uses a temporal syntax, e.g. end(t1) < start(t2). Lastly, SHOP2 and HTN-PDDL use a different approach to represent the task ordering. Instead of specifying individual ordering constraints, they require to specify the order as a single expression. This expression is a nested definition of the ordering, which can only contain two constructors: ordered and unordered. In SHOP2, e.g. ((:unordered (t1 t2) t3) t4) corresponds to the ordering constraints t1 < t2, t2 < t4, and t3 < t4. Note that this construction cannot express all possible partially-ordered sets of tasks. Consider an ordering over five task identifiers t1, , t5, where t1 < t4, t2 < t4, t2 < t5, and t3 < t5. This ordering cannot be expressed with SHOP’s nested ordered/unordered constructs. PDDL1.2 [McDermott et al.1998] also uses this mode as a default, but does with an additional requirement also allow for an order specification as we and HPDDL do. Notably PDDL1.2 intertwines the definition of a method’s subtasks and the definition of their order. The syntax of PDDL1.2 to specify the contents of methods and the order of tasks in them is somewhat convoluted and not easily readable. Thus, we have not adapted their syntax.

A common feature of many HTN planning systems is the possibility of specifying state-based preconditions for methods as supported by the SHOP2 system [Nau et al.2003]. The feature is somehow problematic. First, because it is (at least from our experience) usually used to guide the search and thus often breaks with the philosophy of PDDL to specify a model that does not include advice. The second problem is the way it is usually realized in the HTN planning systems: The systems introduce a new primitive task that holds the method’s preconditions. It is added to the method and placed before all other tasks in the method’s subtask network. Consider a totally ordered domain: here, the action is executed directly before the other subtasks of the method and the position where the preconditions are checked is fine. Now consider a partially ordered domain: here, the newly introduced action is not necessarily placed directly before the other subtasks, but we just know that it is placed somewhere before, i.e., the condition did hold at some point before the other tasks are executed, but may have changed meanwhile. However, though we are aware of these problems, the feature is often used and thus we integrated it and assume the standard semantics as given above.

The preconditions are defined as follows:

12  (:method m-already-there
13    :parameters (?l - location)
14    :task (get-to ?l)
15    :precondition (tAt ?l)
16    :subtasks ())

Here the method may be applied in a state where the transporter is already located at its destination. The given method has therefore no subtasks, but still has to assure that the transporter is at its destination.

Method preconditions are typically featured in languages expressing HTNs. HPDDL [Alford et al.2016a] uses the same syntax we are proposing, while GTOHP [González-Ferrer, Fernández-Olivares, and Castillo2009] uses, as noted above, a separate :constraints section, where the method precondition has to be specified as a before constraint. This is (presumably) to allow for other state constraints later on. PDDL1.2 [McDermott et al.1998] also features method preconditions, but here they are specified as part of the task network. In ANML [Smith, Frank, and Cushing2008], there is no explicit means for writing down method preconditions, but they can be encoded into the state constraints allowed by ANML.

There is a strong contrast between what can be expressed in SHOP333This potentially also applied to HTN-PDDL, as they use a similar syntax. Their description is unfortunately not explicit of the critical point in semantics [González-Ferrer, Fernández-Olivares, and Castillo2009]. and all other HTN formats. In SHOP, several methods for the same abstract task can be arranged in a single method declaration, each featuring its own method precondition. For the th method to be usable, it is not sufficient that its precondition is satisfied. In addition, the preconditions of all previous methods have to be not satisfied as well. Thus SHOP’s method preconditions are in essence a chain of if-else constructs. This structure can be compiled into several individual methods with preconditions. In case one of the preconditions contains an existential quantifier (or in SHOP’s case a free variable) this leads to universally quantified preconditions in the methods after it. We never-the-less propose to drop the ability to use such if-else chains, most notably, since none of the newer languages supports it. Further, this kind of if-else is essentially a means to guide a depth-first search planner in an efficient way. Thus it does not constitute physics of the domain, but advice to the planner, which should not be part of the domain description language for a domain independent planner.

In addition to method preconditions, HPDDL [Alford et al.2016a] also features method effects, which are modeled after SHOP2’s [Nau et al.2003] assert and retract functionality. Method effects are executed in the state in which the method preconditions are evaluated. As far as we know, their formal semantics is not defined in any publication. We propose to drop this feature (at least for the given definition that is intended to be the core language), as we argue that it is not commonly used and might be difficult to use for newcomers to HTN planning. Note that even without method effects in the description language, we can still simulate them with additional actions in the methods’ definitions.

Sometimes it might be useful to define constraints in a method, e.g. on its variables or sorts. This is demonstrated in the following example where the transporter’s source position must be different from its destination.

9  (:method m-direct
10    :parameters (?ls ?ld - location)
11    :task (get-to ?ld)
12    :constraints
13      (not (= ?li ?ld))
14    :subtasks (drive ?ls ?ld))

We are aware that PDDL allows for variable constraints in the preconditions of actions. Due to consistency we also argue to allow this when method preconditions as given above are specified. However, many HTN models are defined without methods that have preconditions and we think it not intuitive to specify a precondition section solely to define variable constraints. Furthermore, we think that other constraints apart from simple variable constraints might be added to the standard. Therefore we integrated a constraint section to the method definition (line 3f) though our current definition only allows for equality and inequality constraints.

HPDDL [Alford et al.2016a] places the variable constraints of a method into the method’s preconditions. In addition to equality and inequality it features type constraints, where e.g. (valuablePackage ?p) is the constraint that ?p belongs to the type valuablePackage. GTOHP [Ramoul et al.2017] allows for equality and inequality constraints that are also within the :constraints section, but are located in a separate before block. In SHOP’s syntax, variable constraints have to be compiled into method preconditions referring to predicates for the individual types and an explicitly declared equals predicate. ANML also allows for variable constraints that can be declared freely anywhere inside a method.

We left the action definition unchanged compared to the PDDL standard we build on. Therefore we included only the following action into our example.

16  (:action drive
17    :parameters (?l1 ?l2 - location)
18    :precondition (and
19      (tAt ?l1)
20      (road ?l1 ?l2))
21    :effect (and
22      (not (tAt ?l1))
23      (tAt ?l2)))
24  ...)

The problem file is slightly adapted to represent the additional elements necessary for HTN panning.

1(define (problem p)
2 (:domain transport)
3 (:objects
4  city-loc-0 city-loc-1 city-loc-2 - location
5  package-0 package-1 - package)
6 (:htn
7  :tasks (and
8   (deliver package-0 city-loc-0)
9   (deliver package-1 city-loc-2))
10  :ordering ()
11  :constraints ())
12 (:init
13  (road city-loc-0 city-loc-1)
14  (road city-loc-1 city-loc-0)
15  (road city-loc-1 city-loc-2)
16  (road city-loc-2 city-loc-1)
17  (at package-0 city-loc-1)
18  (at package-1 city-loc-1)))

We consider the term the section starts with as specification of the problem class. In this example, it starts with :htn to define a standard HTN planning problem. However, extensions to the language might add new classes. An example for such another class may be HTN planning with task insertion, where the planner is allowed to insert tasks apart from the hierarchy. These problems are syntactically equivalent to standard HTN planning problems, so we need the given flag to specify the problem class.

The definition of the initial task network is nested in this section. It has the same form as the methods’ subtask networks. The other description languages for HTN planning also allow for a similar definition of the initial plan. Again, all of them use a slightly different syntax to describe them.

In the given example, the planning process is started with two tasks, one for each package. These initial tasks are not ordered with respect to each other, i.e. their subtasks may be executed interleaved.

In the original PDDL standard, the domain designer has to specify a state-based goal. HTN planning problems do not require such a goal and thus often do not specify one. Therefore we made its definition optional.

4 Full Syntax Definition

We wanted to define our syntax as close as possible to the STRIPS part (i.e. language level 1) of the PDDL 2.1 language definition of \citeauthorFoxL03 \shortciteFoxL03. Wide parts of the following definition are identical to their definition. Changes and extensions are discussed in the following.

The domain definition has been extended by definitions for compound tasks (line 4) and methods (line 4).

1<domain> ::= (define (domain <name>)
2    [<require-def>]
3    [<types-def>]
4    [<constants-def>]
5    [<predicates-def>]
6    <comp-task-def>*
7    <method-def>*
8    <action-def>*)

The definition of the basic domain elements is nearly unchanged.

18<require-def> ::= (:requirements <require-key>+)
19<require-key> ::= 
20<types-def> ::= (:types <types>+)
21<types> ::= <typed list (name)> | <base-type>
22<base-type> ::= <name>
23<constants-def> ::= (:constants <typed list (name)>)
24<predicates-def> ::= (:predicates <atomic-formula-skeleton>+)
25<atomic-formula-skeleton> ::= (<predicate> <typed list (variable)>)
26<predicate> ::= <name>
27<variable> ::= ?<name>
28<typed list (x)> ::= x+ - <type> [<typed list (x)>]
29<primitive-type> ::= <name>
30<type> ::= (either <primitive-type>+)
31<type> ::= <primitive-type>

The only change concerns the definition of <types-def> (lines 4 and 4) in combination with the definition of <typed list (name)> (line 4). In the PDDL2.1 standard, this can be realized by a list of names, e.g. in an untyped way. Our intention was to enforce a typed model and therefore allow for untyped elements only in the type definition. There, it is necessary to define the base type(s). In every other definition that includes <typed list (name)> (e.g. parameter and constant definitions), we wanted to enforce a typed list.

Abstract tasks are defined similar to actions.

8<comp-task-def> ::= (:task <task-def>)
9<task-def> ::= <task-symbol> :parameters (<typed list (variable)>)
10<task-symbol> ::= <name>

In a standard HTN setting, methods consist of a parameter list (line 4), the abstract task they decompose (line 4), and the resulting task network (line 4). The parameters of a method are supposed to include all parameters of the abstract task that it decomposes and those of the tasks in its network of subtasks. The separate definition of method parameters enables e.g. the restriction of the abstract task’s parameters to subtypes of their original definition.

By setting the :htn-method-prec requirement, one might use method preconditions as discussed above (line 4).

31<method-def> ::= (:method <name>
32    :parameters (<typed list (variable)>)
33    :task (<task-symbol> <term>*)
34    [:precondition <gd>]
35    <tasknetwork-def>)

The definition of task networks is used in method definitions as well as in the problem definition to define the initial task network. It contains the definition of sub-tasks (line 4), ordering constraints (line 4), and variable constraints (line 4) between any method parameters.

When the key :ordered-subtasks is used, the network is regarded to be totally ordered. In the other cases, ordering relations may be defined explicitly. This is done by including ids into the task definition that can then be referenced in the ordering definition.

10<tasknetwork-def> ::=
11    [:[ordered-][sub]tasks <subtask-defs>]
12    [:order[ing] <ordering-defs>]
13    [:constraints <constraint-defs>]

We use the same syntax definition for method subnetworks and the initial task network. Here, the keyword subtasks would seem odd. Therefore the syntax also allows for the keys tasks and ordered-tasks (line 4) that are supported to be used in the initial task network.

The subtask definition may contain one or more subtasks. A single task consists of a task symbol and a list of parameters. In case of a method’s subnetwork, these parameters have to be included in the method’s parameters, in case of the initial task network, they have to be defined as constants in or in a dedicated parameter list (see definition of the initial task network, line 4). The tasks may start with an id that can be used to define ordering constraints.

35<subtask-defs> ::= () | <subtask-def> | (and <subtask-def>+)
36<subtask-def> ::= (<task-symbol> <term>*) | (<subtask-id> (<task-symbol> <term>*))
37<subtask-id> ::= <name>

The ordering constraints are defined via the task ids. They have to induce a partial order.

13<ordering-defs> ::= () | <ordering-def> | (and <ordering-def>+)
14<ordering-def> ::= (<subtask-id> "<" <subtask-id>)

So far we only included variable constraints into the constant section, but the definition might be extended in further language levels, of course.

37<constraint-defs> ::= () | <constraint-def> | (and <constraint-def>+)
38<constraint-def> ::= () | (not (= <term> <term>)) | (= <term> <term>)

The original action definition of PDDL has been split to reuse its body in the task definition.

14<action-def> ::= (:action <task-def>
15    [:precondition <gd>]
16    [:effects <effect>])

We restricted the definition of preconditions and effects to level 1, i.e. the STRIPS part of the overall language.

38<gd> ::= ()
39<gd> ::= <atomic formula (term)>
40<gd> ::= <literal (term)>
41<gd> ::= (and <gd>*)
42<gd> ::= (or <gd>*)
43<gd> ::= (not <gd>)
44<gd> ::= (imply <gd> <gd>)
45<gd> ::= (exists (<typed list (variable)>*) <gd>)
46<gd> ::= (forall (<typed list (variable)>*) <gd>)
47<gd> ::= (= <term> <term>)
16<literal (t)> ::= <atomic formula(t)>
17<literal (t)> ::= (not <atomic formula(t)>)
18<atomic formula(t)> ::= (<predicate> t*)
47<term> ::= <name>
48<term> ::= <variable>
18<effect> ::= ()
19<effect> ::= (and <c-effect>*)
20<effect> ::= <c-effect>
21<c-effect> ::= (forall (<variable>*) <effect>)
22<c-effect> ::= (when <gd> <cond-effect>)
23<c-effect> ::= <p-effect>
24<p-effect> ::= (not <atomic formula(term)>)
25<p-effect> ::= <atomic formula(term)>
26<cond-effect> ::= (and <p-effect>*)
27<cond-effect> ::= <p-effect>

The problem definition includes as additional element the initial task network (line 4). Since a state-based goal definition is often not included in HTN planning, we made the goal definition optional (line 4).

48<problem> ::= (define (problem <name>)
49    (:domain <name>)
50    [<require-def>]
51    [<p-object-declaration>]
52    [<p-htn>]
53    <p-init>
54    [<p-goal>])
27<p-object-declaration> ::= (:objects <typed list (name)>)
28<p-init> ::= (:init <init-el>*)
29<init-el> ::= <literal (name)>
30<p-goal> ::= (:goal <gd>)

The initial task network contains the definition of the problem class (line 4). In this first definition we only included standard HTN planning, but we integrated this definition to allow for other classes, such as, e.g. HTN planning with task insertion.

54<p-htn> ::= (<p-class>
55    [:parameters (<typed list (variable)>)] 
56    <tasknetwork-def>)
57<p-class> ::= :htn

Our overall definition includes two new requirement flags:

  • :htn requires the applied system needs to support HTN planning at all, so this can be seen as the basic requirement for the language defined here.

  • :htn-method-prec requires the applied system needs to support method preconditions

5 Discussion

We consider the language proposed in this paper as a first step towards a standardized language for hierarchical planning problems and hope that it helps to find a minimal set of features supported by the diverse systems. However, this basic feature set as well as many design options are still open and have to be discussed in the research community.

First of all, we think it is important to remain as close as possible to the PDDL and to reuse its features to allow domain modelers to create both hierarchical and non-hierarchical problems with minimal learning effort. Language compactness is another important feature to facilitate the adoption of this language. Then, we must decide which features have to be at the core of the language, and which ones are secondary and possibly could be ignored.

A feature that was present in the early HTN formalisms (see e.g. the formalism used by \citeauthorErol96HTNPlanning, \citeyearErol96HTNPlanning) is the possibility to define more elaborated constraints in task networks. Recent work in hierarchical planning was not based on such a rich definition language, but on rather minimalistic formalisms like the one introduced by \citeauthorGeier11HybridDecidability, \shortciteGeier11HybridDecidability. In this first definition we only included the very basic constraints: ordering constraints, variable constraints, and method preconditions. However, we think that a constraint set as given in PDDL3 might be a nice extension beneficial for domain designers.

When the community wants to foster application in real world domains, it may be necessary to integrate support for numbers and time into the planning systems. Since our definition builds upon the PDDL2.1, at least the extension of the syntax in that direction could easily be made.

Other extensions that might be integrated are e.g. preconditions and effects of abstract tasks (see \citeauthorBercherHBB16 \shortciteBercherHBB16 for an overview of that feature) or the ability to decompose not only tasks, but also goals (as e.g. done by \citeauthorShivashankarKNA12, \citeyearShivashankarKNA12) that even has been combined with task decomposition [Alford et al.2016b].

6 Conclusion

In this paper we propose a common description language for hierarchical planning problems. We argue that the core feature set underlying many hierarchical planning systems from the past years is that of HTN planning and introduced its elements as an extension of PDDL, the description language commonly used in non-hierarchical planning. We defined the language in a way that can easily extended by further features as has been done in PDDL. We introduced our novel language elements “by example” and discussed our design choices, the syntax used in related work, and the proposed meaning. We gave a full syntax definition afterwards and discussed the extensions and changes to the PDDL standard. We hope that a common input language may foster the cooperation between groups working in hierarchical planning, the comparison of different hierarchical planning systems and the application on real problems, because it enables an easy exchange of the planning system used for a given problem.


  • [Alford, Bercher, and Aha2015a] Alford, R.; Bercher, P.; and Aha, D. 2015a. Tight bounds for HTN planning. In Proceedings of the 25th International Conference on Automated Planning and Scheduling (ICAPS), 7–15. AAAI Press.
  • [Alford, Bercher, and Aha2015b] Alford, R.; Bercher, P.; and Aha, D. 2015b. Tight bounds for HTN planning with task insertion. In Proceedings of the 25th International Joint Conference on Artificial Intelligence (IJCAI), 1502–1508. AAAI Press.
  • [Alford et al.2016a] Alford, R.; Behnke, G.; Höller, D.; Bercher, P.; Biundo, S.; and Aha, D. W. 2016a. Bound to plan: Exploiting classical heuristics via automatic translations of tail-recursive HTN problems. In Proceedings of the 26th International Conference on Automated Planning and Scheduling (ICAPS), 20–28. AAAI Press.
  • [Alford et al.2016b] Alford, R.; Shivashankar, V.; Roberts, M.; Frank, J.; and Aha, D. W. 2016b. Hierarchical planning: Relating task and goal decomposition with task sharing. In Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence (IJCAI), 3022–3029.
  • [Alford, Kuter, and Nau2009] Alford, R.; Kuter, U.; and Nau, D. S. 2009. Translating HTNs to PDDL: A small amount of domain knowledge can go a long way. In Proceedings of the 21st International Joint Conference on Artificial Intelligence (IJCAI), 1629–1634.
  • [Behnke, Höller, and Biundo2018a] Behnke, G.; Höller, D.; and Biundo, S. 2018a. totSAT – Totally-ordered hierarchical planning through SAT. In Proceedings of the 32nd AAAI Conference on Artificial Intelligence (AAAI), 6110–6118. AAAI Press.
  • [Behnke, Höller, and Biundo2018b] Behnke, G.; Höller, D.; and Biundo, S. 2018b. Tracking branches in trees – A propositional encoding for solving partially-ordered HTN planning problems. In Proceedings of the 30th International Conference on Tools with Artificial Intelligence. (ICTAI), 73–80. IEEE Computer Society.
  • [Behnke, Höller, and Biundo2019] Behnke, G.; Höller, D.; and Biundo, S. 2019. Bringing order to chaos – A compact representation of partial order in SAT-based HTN planning. In Proceedings of the 33rd AAAI Conference on Artificial Intelligence (AAAI), 40–47. AAAI Press.
  • [Bercher et al.2016] Bercher, P.; Höller, D.; Behnke, G.; and Biundo, S. 2016. More than a name? On implications of preconditions and effects of compound HTN planning tasks. In Proceedings of the 22nd European Conference on Artificial Intelligence (ECAI), 225–233. IOS Press.
  • [Bercher et al.2017] Bercher, P.; Behnke, G.; Höller, D.; and Biundo, S. 2017. An admissible HTN planning heuristic. In Proceedings of the 26th International Joint Conference on Artificial Intelligence (IJCAI), 480–488. AAAI Press.
  • [Bit-Monnot, Smith, and Do2016] Bit-Monnot, A.; Smith, D. E.; and Do, M. 2016. Delete-free reachability analysis for temporal and hierarchical planning. In Proceedings of the 22nd European Conference on Artificial Intelligence (ECAI), 1698–1699. IOS Press.
  • [Erol1996] Erol, K. 1996. Hierarchical Task Network Planning: Formalization, Analysis, and Implementation. Ph.D. Dissertation, University of Maryland.
  • [Fox and Long2003] Fox, M., and Long, D. 2003. PDDL2.1: An extension to PDDL for expressing temporal planning domains. Journal of Artificial Intelligence Research 20:61–124.
  • [Geier and Bercher2011] Geier, T., and Bercher, P. 2011. On the decidability of HTN planning with task insertion. In Proceedings of the 22nd International Joint Conference on Artificial Intelligence (IJCAI), 1955–1961. AAAI Press.
  • [Ghallab, Nau, and Traverso2004] Ghallab, M.; Nau, D. S.; and Traverso, P. 2004. Automated Planning: Theory and Practice. Morgan Kaufmann.
  • [González-Ferrer, Fernández-Olivares, and Castillo2009] González-Ferrer, A.; Fernández-Olivares, J.; and Castillo, L. 2009. JABBAH: A java application framework for the translation between business process models and HTN. In Proceedings of the International Competition on Knowledge Engineering for Planning and Scheduling (ICKEPS), 28–37.
  • [Höller et al.2018] Höller, D.; Bercher, P.; Behnke, G.; and Biundo, S. 2018. A generic method to guide HTN progression search with classical heuristics. In Proceedings of the 28th International Conference on Automated Planning and Scheduling (ICAPS), 114–122. AAAI Press.
  • [McDermott et al.1998] McDermott, D.; Ghallab, M.; Howe, A.; Knoblock, C.; Ram, A.; Veloso, M.; Weld, D.; and Wilkins, D. 1998. PDDL – the planning domain definition language. Technical Report CVC TR-98-003/DCS TR-1165, Yale Center for Computational Vision and Control. Available at: www.cs.yale.edu/homes/dvm.
  • [Nau et al.2003] Nau, D. S.; Au, T.; Ilghami, O.; Kuter, U.; Murdock, J. W.; Wu, D.; and Yaman, F. 2003. SHOP2: An HTN planning system. Journal of Artificial Intelligence Research 20:379–404.
  • [Ramoul et al.2017] Ramoul, A.; Pellier, D.; Fiorino, H.; and Pesty, S. 2017. Grounding of HTN planning domain. International Journal on Artificial Intelligence Tools 26(5):1–24.
  • [Schreiber et al.2019] Schreiber, D.; Balyo, T.; Pellier, D.; and Fiorino, H. 2019. Tree-REX: SAT-based tree exploration for efficient and high-quality HTN planning. In Proceedings of the 29th International Conference on Automated Planning and Scheduling (ICAPS), 20–28. AAAI Press.
  • [Shivashankar, Alford, and Aha2017] Shivashankar, V.; Alford, R.; and Aha, D. W. 2017. Incorporating domain-independent planning heuristics in hierarchical planning. In Proceedings of the 31st AAAI Conference on Artificial Intelligence (AAAI), 3658–3664. AAAI Press.
  • [Shivashankar et al.2012] Shivashankar, V.; Kuter, U.; Nau, D. S.; and Alford, R. 2012. A hierarchical goal-based formalism and algorithm for single-agent planning. In International Conference on Autonomous Agents and Multiagent Systems, AAMAS 2012, Valencia, Spain, June 4-8, 2012 (3 Volumes), 981–988.
  • [Smith, Frank, and Cushing2008] Smith, D.; Frank, J.; and Cushing, W. 2008. The ANML language. In Proceedings of the Workshop on Knowledge Engineering for Planning and Scheduling (KEPS).
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description