Troubleshooting

This page contains some general troubleshooting information as well as information about known bugs in certain planners.

General Tools and Techniques

Validating your PDDL files and plans

The plan validation system VAL is available on the university computers (including Thinlinc), and can also be downloaded and compiled on your own system. It contains a number of different applications that can be useful in various ways.

The following are the two most useful tools, but there are plenty of others available. See the application page for brief descriptions.

• /courses/TDDD48/bin/Parser filename |& less is used to parse a file and verify that it follows the PDDL standard. At the end, it shows you the number of errors and warnings.

  Note that this does NOT find certain errors such as missing spaces between dash and type: crate7 - crate correctly specifies an object of type crate, while crate7 -crate specifies two objects, where the second one has a name beginning with a dash.

  There are additional options; run Parser to see a list and see the description.

• /courses/TDDD48/bin/Validate domainFile problemFile planFile... is used to validate that one or more generated plans are actually valid. This is primarily useful if you are writing your own planner. It can also be used if one planner provides a solution while others don't, to verify if the solution is actually correct.

What should you do if a planner can't find a solution?

Suppose you have generated a planning problem where 50 crates of different types need to be delivered, and a particular planner is running for a long time without finding any solutions. What is the problem? Is the planner simply slow? Is something wrong in the domain file, or problem file, and if so, what? How do we pinpoint the problem?

In general, a good technique is to minimize your goals. We will describe this as if you incrementally simplified the goals, but sometimes it may be better to do it the other way around: First remove all your goals, then incrementally make the goals harder and harder.

1. Maybe there is a problem with moving to multiple locations. Remove (comment out) all goals except those that require a few crates to be delivered to a single location. Does this work? If so, there might be a problem with going back to pick up more crates.

2. If that didn't work, maybe there's a problem with moving multiple crates even if they go to the same destination. Simplify the goal so that you only need to deliver a single crate to a single person.

3. If that didn't work, maybe there's a problem with actually delivering a crate. Change the goal to holding a medicine crate and having the UAV at location 7.

4. If that didn't work, maybe there's a problem with flying. Change the goal to simply holding a medicine crate, which (depending on your domain formulation) might only require a single action.

You could also find other ways of constructing very simple goals to see whether even the simplest plans can be constructed. Can you solve the problem of having the helicopter at location 3, without even having to move any crates?

Keep in mind that problems can occur in many parts of the PDDL definitions. Maybe a precondition is wrong, or maybe an effect updates a state in the wrong way. Maybe an action parameter has the wrong type. Maybe the type hierarchy is wrong, or an object is declared to have the wrong type, or is missing altogether. Maybe some required facts are missing from the initial state. And so on...

Error messages and crashes

No such file or directory: 'output'

Often caused by calling an output file "output" with a planner that also wants to use "output" as a temporary file name. For example:

args: ['/courses/TDDD48/planners/ipc2011/seq-opt/seq-opt-fdss-2/src/search/downward-1', '--search', 'astar(blind())', '--plan-file', 'output']
Traceback (most recent call last):
  File "/courses/TDDD48/planners/ipc2011/seq-opt/seq-opt-fdss-2/src/search/downward-seq-opt-fdss-2.py", line 19, in <module>
    seq_opt_portfolio.run(CONFIGS)
  File "/courses/TDDD48/planners/ipc2011/seq-opt/seq-opt-fdss-2/src/search/seq_opt_portfolio.py", line 60, in run
    os.open("output", os.O_RDONLY)
    OSError: [Errno 2] No such file or directory: 'output'

ImportError: No module named __future__

Do you get the following or similar output when you try to run a planner?

1. Running translator
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "/courses/TDDD48/planners/ipc2011/seq-sat/seq-sat-lama-2011/src/
        translate/translate.py", line 4, in <module>
    from __future__ import with_statement
ImportError: No module named __future__

In this case you must do "unset PYTHONHOME" in the shell before you run the planner. (The problem is caused by an environment variable that may be transferred from a remote system when using Thinlinc or ssh. It causes Python to look for libraries in the wrong location.)

Could not find instantiation for PNE!

A PNE is a PrimitiveNumericExpression. This error most likely means that you are writing a cost-based domain with costs defined by a function, and that the function does not specify the costs for all combinations of arguments. Maybe you missed the case where a UAV flies from a location to the same location -- such as fly-cost(depot,depot)?

Start or End has been removed...

YAHSP3 can give you the message "Start or End has been removed...". This means that the planner has tried to remove actions that are "irrelevant" for various reasons -- they cannot be executed, have no effect, and so on. Then it found out that Start (its name for the POCL "initaction") or End (its name for "goalaction") was removed, which implies that the problem is unsolvable and that this could be detected even before the POCL search process was started.

In some cases, this means that you have specified an incorrect domain or problem instance that simply does not have any solutions. You may be able to verify this by testing with another planner.

For temporal planning, YAHSP3 also has a bug where it cannot handle the case where a fact is made true at the start of an action, (at start X) and then made false at the end of the action, (at end (not X)). This can cause the planner to falsely believe the problem has no solution. The opposite case works, though: (at start (not X)) and (at end X).

ERROR: Goals Deleted

If ITSAT says "ERROR: Goals Deleted" , this means that the planners can immediately detect that the problem is unsolvable, without doing search (similar to "Start or End has been removed" for YAHSP3). Most likely there is a problem in your domain definition or problem definition.

Undefined type object

This does not mean that a 'type object' is undefined, but that the 'object' type is undefined.

Some planners understand that there should be an automatically defined 'object' type that is the root of the type hierarchy, and some (such as ITSAT and YAHSP3) do not. In those planners you need to declare the 'object' type explicitly, if you actually need to use it. Often there is no need to explicitly refer to "objects of any type", and then the "object" type is not required.

Proposition not found

As stated above, some planners do not understand that there should be an automatically defined 'object' type. ITSAT does not, so if you actually use the 'object' type, you need to declare it explicitly.

ITSAT can also say "Proposition not found", if your type specification is incorrect in other ways.

One such issue could be that you have defined "object" as a type without specifying that the other types are subtypes of "object", but there are other possible type-related issues as well.

Another issue can be that you give a predicate a parameter of the wrong type, such as (empty ?crate) when empty is declared to take objects of type carrier.

If you do not actually use an object as a type (for example a parameter type in a predicate or action), ITSAT may need you to remove it from the :types specification. Type names not followed by "-" are then top-level types directly under object, and type names do not need to be declared before they are used as supertypes:

fruit vegetable - object 
apple pear - fruit

;; is equivalent to 
apple pear - fruit ;; no need to declare "fruit" before!  
fruit vegetable ;; implicitly under object

Subtypes and the 'object' type

YAHSP3 crashing for larger problem instances

YAHSP3 may crash for larger problem instances due to stack overflow errors. If so, try using ulimit -s unlimited in the shell where you are going to run YAHSP3, to allow the planner to use more stack space.

Jasper crashes

Jasper sometimes crashes after finding a first plan.

ITSAT: "Input files parsed successfully. Segmentation fault."

This can be a very misleading error message. The segmentation fault is typically in the parser, and can be caused by having negative preconditions or goals so that the files are not parsed successfully.

Planner limitations and bugs (possibly without error messages)

Using the same name for predicates and types

Some planners, including Symba, do not allow using the same name for predicates and types. Avoid this.

Characters in names (identifiers)

Some planners are unable to handle "." in names, or names starting with numbers. Do not name your problem or domain in this way, even if some planners allow it.

YAHSP: Making a fact true, then false

For temporal planning, YAHSP3 has a bug where it can't handle the case where a fact is made true at the start of an action, (at start X) and then made false at the end of the action, (at end (not X)). The opposite case works well: (at start (not X)) and (at end X).

This may lead to messages such as "Start or End has been removed...".

To work around this, you may need to invert the meaning of some of your predicates. For example, instead of making happy true at the start and false at the end, you make sad false at the start and true at the end.

Modeling pitfalls

Inconsistent temporal effects: (at start) and (over all)

If you use an effect such as (at start (not X)) together with a condition such as (over all X), then the action becomes self-contradictory and inapplicable: The fact X becomes false at the start but must then be true during the execution of the action, which is clearly impossible. The same applies if you use an effect such as (at start X) together with a condition such as (over all (not X)).

Specifying such effects for an operator is always wrong. Unfortunately, a bug in YAHSP allows it to generate invalid solutions containing such non-executable actions. This can lead to confusion when other planners such as Temporal Fast Downward and ITSAT don't find any solutions, leading you to believe that those planners are at fault – after all, YAHSP did find a solution!

Declaring a number type

Do not declare a type called "number". This type is supposed to be built-in.