Improving HTN Domains

On one hand, the decomposition methods in HTN domains simplify the domain design by avoiding the need for the complete causal models which require the com-plete precondition and postcondition. On the other hand, the way to decompose high-level actions extremely depends on the expertise of the domain designer on the scenario, where the domain designer stipulates that certain actions will be performed “just because he says so.” However, in most real-world domains, the designer may have the expertise for only some parts of the domains. For instance,

Chapter 7. Conclusion and Future Work 145 it is possible that the non-achievement of a compound task results from the lack of some subtasks. This is probably caused by an omission: the designer forgot to consider the subtask in the decomposition method. Taking the example of Figure 1.1 in the introduction, the action of buying the flight ticket is a prerequisite of taking the plane to Melbourne and it is missed, as a subtask of the action of flying to Melbourne. Nevertheless, there is no HTN solution because the missing subtask is not in the task network and will never be produced, in consequence the initial logistics task cannot be accomplished. The approach of TIHTN planning indeed fills up the plans by adding the missing actions to accomplish the initial tasks.

Actually, we have already implement a TIHTN planner via ASP, shown in Ap-pendix B. One benefit of implementing the TIHTN planner via ASP lies in the computation of all solutions, which include all possible insertion of basic actions.

It enables to provides clues to complete decomposition methods by adding the inserted actions into the decomposition methods, and further to improve HTN do-mains. Preliminary experimental results show that if there exists at least a plan, the improvement obtained from the TIHTN planner speeds up problem solving.

As mentioned above, the human expertise, in many real-world scenarios, is only partial. It is necessary to help the HTN domain designer to improve the domain via finding potential refinement relation among actions. Consider refinement from the entailment perspective, in which the belief-intention database does, contributes to the discovery of the hidden refinement relation.

Appendix A

Publications

The following is a list of the published papers during my PhD study.

ˆ Andreas Herzig, Laurent Perrussel, Zhanhao Xiao, and Dongmo Zhang. Re-finement of intentions. In Proceedings the 15th European Conference on Logics in Artificial Intelligence (JELIA-16), 2016. The results of this paper are contained in Chapter 3.

ˆ Andreas Herzig, Laurent Perrussel, and Zhanhao Xiao. On hierarchical task networks. In Proceedings the 15th European Conference on Logics in Arti-ficial Intelligence (JELIA-16), 2016. The results of this paper are contained in Chapter 5.

ˆ Andreas Herzig, Laurent Perrussel, Emiliano Lorini, and Zhanhao Xiao. BDI logics for BDI architectures: old problems, new perspectives. K¨ustliche In-telligenz (KI) Journal, 2016. The part of results are contained Chapter 1.

ˆ Zhanhao Xiao, Andreas Herzig, Laurent Perrussel, Hai Wan, and Xiaoheng Su. Hierarchical Task Network Planning with Task Insertion and State Con-straints. In Proceedings of the 26th International Joint Conference on Arti-ficial Intelligence (IJCAI-17), 2017. The results of this paper are contained in Chapter 6.

146

Appendix A.Publications 147

ˆ Zhanhao Xiao, Andreas Herzig, Laurent Perrussel, and Dongmo Zhang. De-ciding Refinement via Propositional Linear Temporal Logic. In Proceedings of the 16th International Conference of the Italian Association for Artificial Intelligence, 2017. The results of this paper are contained in Section3.5 and Section 4.1.

Appendix B

A TIHTN Planner Based on ASP

In this appendix, we give a decomposition-first algorithm for TIHTN planning and encode it into ASP programs, implementing a TIHTN planner. In TIHTN planning, only ordering constraints are considered. Here we adjust the presentation way of TIHTNS planning in Chapter 6by using a pair of an action and an integer to denote a task.

A task networktn = (T,≺) is a tuple:

ˆ T ⊆(C∪O)×N

ˆ ≺⊆T ×T is a set of ordering constraints over T

In a task network, every task is a pair of an action a and an integer identifier i. With the same action, different identifiers indicate different tasks. For a task t = (a, i), we define α(t)=a. A task t is called primitive if α(t) is a basic action, otherwise it is called compound. A task network is called primitive iff it contains only primitive tasks.

High-level actions cannot be directly executed by the agent and each high-level action is decomposed into a task network according to decomposition methods.

Each decomposition methodm=(c,tn⁰) consists of a high level action cand a task network tn⁰ whose inner tasks are called subtasks.

148

Appendix B. A TIHTN Planner Based on ASP 149 The decomposition procedure for TIHTN planning are similar with that of TI-HTNS planning. Every step of decomposition removes the decomposed task and adds the subtask network into the task network. The problem description and solution criterion for TIHTN planning are identical as those of TIHTNS planning.

B.1 Encoding HTN Problems and Operators

First we show how to translate a TIHTN problem into a set of ASP facts. As each step of applying decomposition generates a task network, we use the number D of the decompositions that were applied to identify the task network. More formally, we use an ASP atom tn(A,I,D) to denote a task (A,I) is in the task network D.

Without loss of generality, we only give the encoding for the propositional HTN problems. For a propositional HTN problem P = (D, s_I,(T_I,≺_I)), we define a set ΠP of ASP facts as follows:

ˆ for every o∈O, primitive(o).

ˆ for every c∈C, compound(c).

ˆ for every m_k = (c,(T_k,≺_k))∈M,method(c,k).

- for every (a, j)∈T_k,sub(c,k,a,j).

- for every (a1, j1)≺_k(a2, j2), mSucc(c,k,a1,j1,a2,j2).

ˆ for every p∈s_I, holds(p,0).

ˆ for every (a, i)∈T_I, tn(a,i,0).

ˆ for every (a1, i1)≺_I(a2, i2), succ(a1,i1,a2,i2,0).

Next we encode the state transition system and planning operators in ASP. To be simple, we suppose the precondition of each operator is in CNF and NNF. That is, every precondition can be rewritten as a conjunction of literals. In each state S, there is one and only one applicable basic action Operformed. Due to negation

Appendix B. A TIHTN Planner Based on ASP 150 as failure, each variable P is false inS+1 by default unless either it is added in S or it already holds and is not deleted in S. We use Π_O to denote the set of facts and formulas as follows:

For every o∈O and (pre(o),eff⁺(o),eff⁻(o))∈ D,

ˆ for every p∈eff⁺(o), add(p,o).

ˆ for every p∈eff⁻(o), del(p,o).

ˆ for pre(o) =p₁∧...∧p_n∧ ¬q₁ ∧...∧ ¬q_m,

pre(o,S):- holds(p₁,S), ...,holds(p_n,S),not holds(q₁,S),...,not holds(q_m,S).

and

1 {do(O,S) :operator(O)} 1 :- state(S). (B.1)

:- not pre(O,S),do(O,S). (B.2)

holds(P,S+1):- add(P,O),do(O,S). (B.3) holds(P,S+1):- not del(P,O),do(O,S),holds(P,S). (B.4)