Hide menu

Troubleshooting

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

This page may be incrementally updated during the course, when participants ask new questions.

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, or
does not find the solution you want?

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. Or maybe you can quickly find a plan without carriers, but the planner keeps searching for hours without finding one that does use carriers – or terminates saying that the plan without carriers is the best one that it can find?

What is the problem? Is the planner simply slow? Is it getting stuck for no good reason? Is something wrong in the domain file, or problem file, and if so, what? Are the plans with carriers too expensive? 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. You had 50 crates to move, so 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 the depot 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 delivering a crate, even just a single crate. Change the goal to the UAV holding a medicine crate and having the UAV at some specific location.

  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 UAV at location 3, without having to move any crates? Using minimal test cases like this is very valuable in any type of modeling or programming – in a sense, you should be unit testing your actions!

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...

General Pitfalls

Spaces are significant – hyphens are not special!

The PDDL syntax is built on general LISP syntax. This syntax has some slightly unusual properties, including the use of parentheses and prefix notation.

Probably the most common pitfall in relation to PDDL comes from the fact that LISP operators can be part of identifiers. In most languages, a-b means "a minus b". In LISP, this is a single identifier consisting of three characters: a, hyphen, b.

In PDDL, "crate1 crate2 - crate" states that the two objects crate1 and crate2 are of type crate. On the other hand, "crate1 crate2 -crate" declares three objects, the third of which has the name "-crate". Since the hyphen is not separated from the rest by a space, it is considered to be part of an identifier.

These three objects might be of the general object type, or may end up having some other type:

  crate1 crate2 -crate
  uav1 uav2 - uav

The above declares five objects of type uav, as there are five identifiers before the first standalone hyphen. This may of course be even more confusing and lead to strange issues such as problem instances having no solutions. To make things worse, planners may interpret this specification differently: Some do use the standard LISP interpretation of hyphens and spaces as discussed above, while others do parse -crate as a separate hyphen and a separate identifier "crate".

Therefore, please be careful with your spaces. Always use spaces to separate hyphens in type declarations from identifiers.

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

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 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)). 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 do not 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.

Troubleshooting and Debugging Tools

Finding syntax errors

You can configure vscode-pddl to run a PDDL parser in the background, automatically highlighting many (but not all) errors.

Visualizing initial states

In vscode-pddl, you can visualize initial states, using tables and directed graphs.

Parsing a file, verifying it is syntactically correct

A domain file with errors:

jonkv82@ssh-vw3:domains/pddl$ /courses/TDDD48/bin/Parser assembly.pddl
File: assembly.pddl

Errors: 3, warnings: 0
assembly.pddl: line: 58: Error: Syntax error in action declaration.
assembly.pddl: line: 58: Error: Unreadable structure
assembly.pddl: line: 59: Error: Syntax error in domain

A domain and problem file that are apparently syntactically correct (but there might still be something wrong):

jonkv82@ssh-vw3:domains/pddl$ /courses/TDDD48/bin/Parser miconic.pddl miconic01.pddl 
...
constraints: (NULL)
metric: (NULL)
length: (NULL)
Errors: 0, warnings: 0

Analysing properties of propositions

"Analyse a domain and problem file to give you information about type structure, relationship between arguments, overloading of predictates and functions."

See which predicates exist and where they are used (preconditions, positive effects/adds, negative effects/dels). See propositions that are static (never modified) or that only decay (can be made false but cannot be made true by effects).

  jonkv82@ssh-vw3:domains/pddl$ /courses/TDDD48/bin/Analyse wumpus-adl.pddl wumpus-adl-1.pddl 
File: wumpus-adl.pddl
File: wumpus-adl-1.pddl

Errors: 0, warnings: 0

Report for: at
---------
Initial: 3 Goal: 1
Preconditions:
	move
	move
	take
	take
	shoot
	shoot
Adds:
	move
Dels:
	move
	take
	shoot

Report for: adj
---------
Initial: 14 Goal: 0
Preconditions:
	move
	shoot
Proposition is static

Report for: pit
---------
Initial: 1 Goal: 0
Preconditions:
	move
Proposition is static

Report for: have
---------
Initial: 1 Goal: 1
Preconditions:
	shoot
Adds:
	take
Dels:
	shoot

Report for: alive
---------
Initial: 2 Goal: 1
Preconditions:
	move
	move
	take
	shoot
	shoot
Proposition decays only
Dels:
	move
	move
	shoot

Instantiate a domain and problem

Instantiating a domain + problem allows you to see exactly which instances exist of actions and predicates. This can be helpful if you are trying to find problems that might be caused by faulty types.

jonkv82@ssh-vw3:domains/strips$ /courses/TDDD48/bin/Instantiate wumpus-a.pddl wumpus-a-1.pddl |& less
  
move
110 so far
take
1110 so far
shoot
2510 so far
1380
(move agent s-2-1 s-1-1)
(move arrow-1 s-2-1 s-1-1)
(move gold-1 s-2-1 s-1-1)
(move s-1-1 s-2-1 s-1-1)
(move s-1-2 s-2-1 s-1-1)
(move s-1-3 s-2-1 s-1-1)
(move s-2-1 s-2-1 s-1-1)
(move s-2-2 s-2-1 s-1-1)
(move s-2-3 s-2-1 s-1-1)
(move wumpus s-2-1 s-1-1)
...
...

List of all literals:
(adj s-1-1 s-1-2)
(adj s-1-2 s-1-1)
(adj s-1-2 s-1-3)
...
...

Page responsible: Jonas Kvarnstr�m
Last updated: 2023-04-10