After the Seventh IPC a number of contributors sent additional material. This page is devoted to keep track of this additional contributions.
As a side effect, a number of additional documents might be created to discuss/introduce particular issues related in some way to the International Planning Competition. All of those should go here.
During the Seventh IPC Daniel L. Kovacs contributed with a couple of manuscripts about the BNF notation of PDDL 3.1. These documents are included here as well for the ease of reference:
It might happen that the domain definitions are sometimes inconsistent whereas in other cases there might be better ways to formulate them. This section is intended to keep track of the latest contributions regarding domain definitions of any competition or to provide new domains.
Mikko Ettienne has proposed the domain Hospital Robots. He can be found at mikkobe in the domain gmail dot com.
A level is a grid-based structure with walls, agents, boxes, goal cells and possibly a number of unknown items. Agents represent hospital robots and boxes represent the items that the robots have to move. Unknown items represent objects that are not part of the agents' initial maps of the world, e.g., boxes, trash or beds placed by humans but not scheduled for transportation. Some agents maybe allowed to only move some boxes. A box fits exactly one goal cell, but there may be multiple boxes for each goal cell. The goal is to make all goal cells occupied by a fitting box.
Agents can move around in the environment and push and pull boxes. The domain is much like the well-known sokoban except that agents can pull boxes, so there are no deadlock states, also boxes can be pulled and pushed around corners. Furthermore, there is the multi-agent scenario and the partial observability scenario.
This domain originated from a programming project in the course Artificial Intelligence and Multi-Agent Systems lectured at the Technical University of Denmark by Thomas Bolander.
The project is inspired by the recent developments in mobile robots for hospital use. Hospitals tend to have a very high number of transportation tasks to be carried out: transportation of beds, medicine, blood samples, medical equipment, food, garbage, mail, etc. Letting robots carry out these transportation tasks can save significantly on hospital staff resources. The most successful implementation of hospital robots so far are the TUG robots by the company Aethon. TUG robots were first employed in a hospital in 2004, and is now in use in more than 100 hospitals in the US. An earlier hospital robot was the HelpMate robot developed in the late 1990s. In Denmark, there has been several recent research projects aiming at constructing mobile robots for carrying out transportation tasks at Bispebjerg Hospital near Copenhagen. The ideal is to have a system of multiple mobile robots that can themselves distribute the transportation tasks between them in an efficient way, essentially making it into a multi-agent system. This is more advanced than the TUG robots, where each individual robot is manually assigned its individual tasks. Furthermore, ideally the robots should not only be able to move a single type of container as the TUG robot is, but many different types of physical objects, including hopsital beds. Possibly, the easiest way to achieve this is to have different types of robots with different physical design and different abilities concerning which objects they can move. Some robots might, e.g., be able to move very quickly with small items; others might be bigger and slower but able to move very large and heavy items like hospital beds; yet others might be both small and slow, but able to handle fragile items safely. The goal of this programming project is to implement a much simplified simulation of how a multi-robot system at Bispebjerg Hospital might work.
There is apparently a "bug" in the formulation of the woodworking domain both from the IPC 2008 and IPC 2011. While the formulation used in both competitions is okay, it might be the case that it does not correspond to the original intention of the author. The current formulation of the saw actions look like this:
(:action do-saw-medium :parameters (?b - board ?p - part ?m - saw ?w - awood ?surface - surface ?size_before ?s1 ?size_after - aboardsize) :precondition (and (unused ?p) (goalsize ?p medium) (available ?b) (wood ?b ?w) (surface-condition ?b ?surface) (boardsize ?b ?size_before) (boardsize-successor ?size_after ?s1) (boardsize-successor ?s1 ?size_before)) :effect (and (increase (total-cost) 30) (not (unused ?p)) (available ?p) (wood ?p ?w) (surface-condition ?p ?surface) (colour ?p natural) (treatment ?p untreated) (boardsize ?b ?size_after)))
Emil Keyder noted that the "saw" actions should mark that the corresponding part is available but also to change the size of the board used. While the current formulation adds the new size board, it does not delete its previous size. This results in the same board being reusable for making the different parts.
A "patched" version for your consideration can be downloaded from here.
Ángel García Olaya has noted a bug in the definition of the Floortile domain and therefore a patched version is posted here along with his explanation.
The domain definition states it only needs :typing, but its actions have cost and a (total-cost) fluent is declared. So it should include also the :action-costs requirement.
Vidal Alcázar noted that there is a potential bug in the formulation of the Barman domain.
This change fixes the potential dead end that occurs when a beverage is poured to a shot from a shaker: the action "pour-shaker-to-shot" does not add "(used ?d ?b)", which is a prerrequisite of "clean-shot", so that shot can be emptied but not cleaned and thus it becomes unusable for the rest of the computation. This should be the codification of the action:
(:action pour-shaker-to-shot :parameters (?b - beverage ?d - shot ?h - hand ?s - shaker ?l ?l1 - level) :precondition (and (holding ?h ?s) (shaked ?s) (empty ?d) (clean ?d) (contains ?s ?b) (shaker-level ?s ?l) (next ?l1 ?l)) :effect (and (not (clean ?d)) (not (empty ?d)) (contains ?d ?b) (used ?d ?b) (shaker-level ?s ?l1) (not (shaker-level ?s ?l)) (increase (total-cost) 1))) )