Introduction to the Labs

Lab Assignments

• 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: Motion Planning

Working alone or in pairs

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.

This does not necessarily mean that you must sit together physically. There are plenty of ways of working together electronically if you prefer. For example, for sharing code "live" there are tools such as Visual Studio Code that allow you to add plugins such as Visual Studio Live Share... or simply a Google Docs document, though that involves a bit more cutting and pasting. Similarly you can use tools like Zoom to have live discussions.

Lab Registration

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:

• We haven't opened the registration yet. In every course there are participants who sign up for labs, but then drop the course before the labs actually start. We want to avoid this.
• You are not registered for the course. Please 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.

Gitlab Projects

All development should occur in Gitlab projects and repositories that we create for you. This happens automatically some time after you register in Webreg.

Resources

The following resources are available for the planning labs.

• A large number of planners, both from international planning competitions 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 to allow all of you 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:

  /courses/TDDD48/bin/parser domainFile [problemFile]

  See also VAL's web page. Note that the FF planner also tends to provide comprehensible error messages!

• 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!

• You can edit PDDL in Visual Studio Code using vscode-pddl. This tool seems quite capable and has been used by students before. To use this on the lab computers, do "module add prog/vscode" and execute the command "code".

  

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.