## 3 Materials and Methods
### The Generic Planning Problem (GPP) for the GIS and Its Instances in PDDL
#### 3.2.1. PDDL Domain for the Generic Planning Problem (GPP)
```
1(:durative-actiongrasp
2:parameters(?agent-agent?agentpose-agentpose...)
3:duration(=?duration1)
4:condition(and
5(atstart(at?agent?agentpose))
6(atstart(at?thing?from_thingpose))
7(atstart(at?from_thingpose?agentpose))
8(atstart(at?nothing?to_thingpose))
9(atstart(at?to_thingpose?agent))
10(atstart(thing_moveable?thing))
11(atstart(thing_for_agent?thing?agent))
12(atstart(not_acting?agent)))
13:effect(and
14(atstart(not(not_acting?agent)))
15(atstart(not(at?nothing?to_thingpose)))
16(atstart(not(at?thing?from_thingpose)))
17(atend(not_acting?agent))
18(atend(at?nothing?from_thingpose))
19(atend(at?thing?to_thingpose))
20(atend(native?allowed?agent))))
```  
Listing 5: Excerpt from the PDDL domain file for the GPP with the definition of the _grasp_ action. Unlike the _grasp_ action, the _manipulate_ action of the GPP has a set of restrictions and is part of the processes that can be applied to the items (see its PDDL formulation in Listing 6). These characteristics of the action are encoded in the action's conditions and effects. The first conditions are similar to those of the _grasp_ action and encode the spatial requirements (lines 5-9). The next two conditions from lines 10 and 11 are the special ones. The first checks whether, in the actual state of the world, a specific process step should be executed on the given _item_. The second condition describes under which prerequisite this process step must be carried out. While the former condition contains a predicate whose values can change over a planning period, the latter condition encapsulates constant  
Figure 4: Three states at the beginning of, during, and at the end of the execution of the _navigate_ action and the corresponding values of the grounded predicates describing these states. properties. Finally, the effects also contain two important commands in lines 16 and 17. These commands mark the selected _step_ for the given _item_ as done. ```
1(:durative-action manipulate
2:parameters(?agent-agent?agentpose-agentpose...)
3:duration(=?duration1)
4:condition(and
5(atstart(at?agent?agentpose))
6(atstart(at?item_pose?agentpose))
7(atstart(at?item?item_pose))
8(atstart(at?thing_pose?agent))
9(atstart(at?thing?thing_pose))
10(atstart(process_step_todo?item?step))
11(atstart(process_step_manipulate?item?step?thing?agent?agent?agentpose))
12(atstart(not_acting?agent)))
13:effect(and
14(atstart(not(not_acting?agent)))
15(atend(not_acting?agent))
16(atstart(not(process_step_todo?item?step)))
17(atend(process_step_done?item?step))
18(atend(navigate_allowed?agent)))
```  
Listing 7 presents a durative action that cannot be carried out in the real world but that is used to model the activation rules between the process steps on items. It is a simple action that checks two conditions (lines 5-6). The first condition inquires whether, in the actual state of the world, a specific process step on an item has already been carried out. The second condition encodes the fixed ordering of process steps for that item. If both conditions hold, the activation rule is triggered with the effect described in line 8. The description of the _update_type_* actions concludes the formulation of the PDDL domain for the GPP. ```
1(:durative-actionupdate_type1
2:parameters(?item?item2-item?step1?step2-step)
3:duration(=?duration0.1)
4:condition(and
5(atstart(process_step_done?item1?step1))
6(atstart(process_step_precedence_type1?item1?step1?item2?step2)))
7:effect(and
8(atstart(process_step_todo?item2?step2))))
```  
Listing 8: Excerpt from the PDDL domain file for the GPP with the definition of the _manipulate_step_1 action.