If you want to use this project for your own class, please by all means feel free to. All I ask is that you drop me a line so that I know you are using it. Additionally, if you have ideas on improving this, you're welcome to write me too.
Please read through the entire project specification before emailing us with questions.
In this project, you are required to come up with a simple planning domain for a given scenario. The most widely used representation language for planning domains is PDDL, which follows a Lisp-like syntax. A typical test-suite for a planning scenario consists of one domain file which encapsulates all the domain theory, and one (but usually more) problem files that model various instances. The object is to learn to model and represent problems so that you can use existing planners to automate the solution process. For this project, you do not have to write the planner itself - we will provide an executable jar file for a planner that you can run.
Project 2 Tutorial (16:04) 43 MB
You should also look at the Project FAQs and PDDL Resources sections below.
Here are some sample files for other domains that you should look at before attempting to encode your own domain file and problem files. These will give you an idea of the information that goes into each of those files, and the syntax. You can also use these samples to test out the running of the planner, and to see what the output should look like.
As part of this project, we will expect the following from you:
DOMAIN FILE: A PDDL domain file named 'domain.pddl' that models the scenario below (given as text).
PROBLEM FILES: You must provide problem files for the three problems given as images below. These will run with the domain file you write and produce plans as output. You must model all the given problem instances at the very least for full credit; for extra credit, you may try to model more complex problem instances of your own making if you feel able to. Please name your files as 'pfile1.pddl' and so on.
PLANNER TRACES: Download the jar file to run the Sapa Replan planner here. You can run this jar file on any machine that has Java installed (regardless of operating system) by invoking it in the following manner:
java -jar
sapareplan_planner.jar domfile.pddl probfile.pddl
where domfile.pddl is the full path to your domain file (from task 1) and probfile.pddl is the full path to one of your problem files (from task 2). If you store and run the jar file in the same directory as the domain and problem files, you can call them directly as above (thus using a relative path instead of an absolute one). You can try running the planner with some of the sample files from above to get a feel for what the output looks like.
Note: Sometimes the planner may return multiple plans. If it does that, use only the last plan (since that will be the best).
You can also use the planner to debug the domain and problem files that you write. The planner will throw an error if it is unable to parse your files, and will indicate the line in your file where the error was found. Make sure you also check the plans the planner returns, since these are relatively small problems and you can run through the returned solution. We strongly recommend including any information about debugging your domain or problem encodings, or other errors, along with the resolution you devised in your report.
PROJECT REPORT: We will grade you based on your domain and problem files working with the planner provided, as well as the report that you submit. Your final report must include (but is not restricted to):
Please include all of these in a zipped folder which you can name proj2_lastname_firstname.zip
Robby is a search and report robot. Robby's job is to navigate the mundane world of office hallways and rooms in the event of some unforeseen disaster, and look out for resources to rescue.
For this project, we will model a simple model of the world that Robby has to work in. This is essentially a long office hallway that is split into various segments or hallway-locations. These hallway-locations may or may not be connected to various rooms.
You will need to model two different types of locations, hallways and rooms. Robby can be 'at' a particular location at a given point, and only at that location. Two locations can be 'connected' to each other, enabling Robby to navigate between them (regardless of whether they are rooms or hallways). Note that connections are symmetric, so you need to model the fact that if Robby can go from A to B, then going from B to A is also possible. You can also assume that a hallway-location is a whole object - if Robby is anywhere in a given hallway-location, then Robby can enter any of the rooms connected to that hallway-location, and move from/to any of the other hallway-locations connected to it.
Navigating between hallway-locations and rooms is achieved via 'enter' and 'exit' actions. The enter action enables moving from a hallway-location to a room, while the exit action enables the opposite - moving from a room to a hallway-location. Remember that the two need to be connected in order to perform an enter or an exit - and you need to model those connections.
To navigate between two connected hallway-locations, Robby uses a special 'move' action that only works on locations of type hallway. In the domain and problems that you are to model, Robby should not move within rooms or from one room to another directly, and only enters and exits from hallway-locations.
To ensure that Robby doesn't cheat and visits all locations of interest, there are special beacons 'in' those locations. The beacons can be in either hallway-locations or rooms (since they both are subtypes of 'location'). Robby needs to necessarily be at a given location in order to spot the beacon at that location. Once Robby spots and 'reports' that beacon, he can move on to the next task at hand (so you may want to model the reporting of beacons as goals). Finally, there is a destination that Robby must end up at - this is another goal that you must model.
Your assignment is to develop a domain file from the specification above, and then model the situations depicted in the images below as individual problem files. The following hints may be useful, but you are welcome to use your creativity as long as you adhere to the specification mentioned above:
Below are images of the problem instances that you need to model in PDDL, once you are done making your domain file. The legend that accompanies each image should be fairly self-explanatory; remember, you must model connections between hallway-locations for Robby to move from one to the other, and you can only enter and exit between a hallway-location and a room that are connected. In the below instances, any locations that share an edge can be considered connected (you do not need to explicitly model doors). Locations that share only corners and no edges are not connected.
Notice that the above pictures give you an idea of the initial state of the world (which you must encode in your PDDL problem file). They also tell you what the goals are - Robby's final location (in green), and the various beacons that must be reported on the way. If you look at the syntax of example PDDL problem files, you will see that these are the three main parts of a problem file - (1) the objects, (2) the initial state, and (3) the goals.
To recap, remember that there are 4 DELIVERABLES: The domain file, the (three) problem files, planner output traces from running the planner with the combination of the domain and each of the three problem files, and the project report. Please include all of these in a zipped folder which you can name proj2_lastname_firstname.zip
We have had a few questions on PDDL and the way it is parsed by Sapa Replan. The PDDL specs (link below) are extremely general, and very few planners implement all of the features. Given the scope of this project, you do not need to go into depth for all these features. Below are a few useful clarifications / hints:
As a first step, you should at least look at the sample domain and problem files given at the beginning of this specification. Additionally, here is a link to PDDL domain and problem files (for scenarios different from the one you need to model in this project), from past iterations of the International Planning Competition (IPC). The best way to figure out how to model a domain and associated problems is to look at these examples. If you feel the need for documentation, here is a paper that talks about the complete PDDL specification, with BNF specification at the end (Appendix A): PDDL 2.1 Specification
Note: If you download the entire suite of domains and problems, only look at the domain versions that say 'Strips'. The others are more complex versions that we will not be looking at in this project.
If you feel the above document is too unwieldy for a project as simple as this one, you are strongly encouraged to go through the domains and problem files provided as samples. This should be enough to give you a hang of what is required to write a domain and some problem files.
You can also visit the main page of IPC 3 for other resources related to PDDL (look at the tabs on the left).