Introduction to the Labs
the entire page
before you start working on the individual labs!
The page contains important information that is common to all labs and exercises.
- Lab 1: Modeling classical planning domains, part 1
- Lab 2: Modeling classical planning domains, part 2
- Lab 3: Planning with Concurrency
- Lab 4: Hierarchical Task Networks
- Lab 5: Planning with Control Formulas
- Lab 6: Motion Planning
Working in Groups / Working at Home
You may work alone or (if you prefer and you can find a lab partner) in pairs.
If you work in pairs, we expect you to work together with each lab and each task, continuously discussing the solutions you develop with each other. You should not tackle problems indididually. Both participants must be able to answer questions about all of the domain variations you define.
As most tasks use purely text-based tools, it should be quite possible to do them on your own computer, at the university or at home (but still make sure you're working together!). Unless indicated otherwise in a specific lab, you can simply use ssh to log into remote-und.ida.liu.se, and from there, ssh into the Linux machine crabbofix.ida.liu.se where the planners are installed just like you will do from the SunRay machines. Putty is a free SSH client for Windows. Further instructions are available on the planner page.
Registration for the labs should be done using the WebReg on-line registration system.
If you cannot register for the labs, the most likely reason is that you are not registered for the course. Talk to the people responsible for course registration – we do not handle registration ourselves and cannot add you to the course! Without registration, you cannot receive credits.
The following resources are available for the planning labs.
A large number of planners, both from the latest international planning competition and from other sources. These include sequential satisficing (non-optimizing) planners, sequential optimizing planners and temporal satisficing planners as well as other types of planners.
- Some of these planners will be used by all participants in specific parts of the labs, and have been tested and verified to run on our current systems.
- The remainder of the planners are included for those of you who want to experiment with alternatives.
An introduction to PDDL, complementing the information provided during the lectures.
A PDDL parser that can be used to test your planning domains and problem instances for syntactic correctness. This parser is likely to be more correct and at the same time more informative than most planners' built-in parsers. Run the parser as follows:
/home/TDDD48/bin/parser domainFile [problemFile]
See also VAL's web page. Note that the FF planner also tends to provide comprehensible error messages!
A PDDL mode for Emacs, to help you edit domain and problem instance files. You can also use the plain text mode in Emacs, or any other editor, but we suggest that you use Emacs with this mode file in order to get syntax highlighting. The instructions on that page are not entirely correct! To install this:
- Download the file pddl-mode.el to some directory, let's say "~/TDDD48/".
- Rename the file to "PDDL-mode.el" with capital letters in PDDL, since Unix file systems are case-sensitive.
Add the following to ~/.emacs (where "~/TDDD48/" is replaced
with the directory where you placed the file):
(add-to-list 'load-path "~/TDDD48/") (require 'PDDL-mode) (add-to-list 'auto-mode-alist '("\\.pddl" . PDDL-mode))
A set of PDDL examples using the STRIPS subset of PDDL. Use these to learn more about how domains are usually modelled!
A set of PDDL examples using types and some non-STRIPS features. Use these to learn more about how domains are usually modelled!
Several variants of the Satellite domain, which illustrate the use of durative (temporal) actions in PDDL 2.1. Use these to learn more about modeling temporal domains!
Keeping All Versions
In these labs you will be incrementally creating quite a few planning domains and problem instances. Don't overwrite old domains or problem instances when they are extended in a subsequent exercise. Make sure you have a suitable directory structure for your labs where you keep the result of each exercise (not necessarily all intermediate versions, of course, but the end result of lab 1.1, the end result of lab 1.2, and so on). For example, something as simple as this:
lab1.1/ lab1.2/ lab1.3/ ...
Reporting your results
In all labs and exercises, you will be handing in a set of domain specifications and problem specifications, possibly together with a report. All domains and problems must be easily readable and sufficiently commented, explaining the way you represent the domain and motivating your choice of predicates, objects and operators unless these choices seem so obvious that explaining them would be silly. Naturally, names of predicates, operators and constants should be chosen with some care.
Note that if you try out one design and find out that you have to make changes to make it work, then this is an excellent opportunity for explaining why you made the change and why your new design is better. This is one way of demonstrating your understanding of how planning domains are modeled.
Results should always be reported to your lab assistant.
Policy for handing in computer lab assignments at IDA
General policy: For all IDA courses having computer lab assignments there will be one deadline during or at the end of the course. If you fail to make the deadline, you must retake the, possibly new, lab course the next time the course is given.
Deviation in this course: There will be some additional opportunities to hand in your assignments. See the lecture notes for further information.
General rules for examination of computer lab assignments at IDA
You are expected to do lab assignments in group or individually, as instructed for a course. However, examination is always based on individual performance.
It is not allowed to hand in solutions copied from other students, or from elsewhere, even if you make changes to the solutions. If there is suspicion of such, or any other form of cheating, teachers are obliged to report it to the University Disciplinary Board.
Be prepared to answer questions about details in specific code and its connection to theory. You may also be asked to explain why you have chosen a specific solution. This applies to all group members.
If you foresee problems meeting a deadline, contact your teacher. You can then get some help and maybe the deadline can be set to a later date. It is always better to discuss problems, instead of, e.g., to cheat.
Any kind of academic dishonesty, such as cheating, plagiarism or use of unauthorized assistance, and failure to comply with university examination rules, may result in the filing of a complaint to the University Disciplinary Board. The potential penalties include warnings and suspension from further studies.
Page responsible: Jonas Kvarnström
Last updated: 2014-03-19