如何调试PDDL规划器超时问题？含planning.domains code124报错排查

Hey there, let’s work through how to debug that timeout error (exit code 124) you’re hitting with your ADL-based PDDL domain. First, let’s unpack what that error means, then dive into actionable steps, tools that support ADL, and a quick review of your domain/problem definitions.

What Exit Code 124 Means #

The error code 124 directly comes from the timeout 5 command in your solver call—it means the planning process took longer than 5 seconds to complete. This could happen for a few reasons:

• The search space is too large for the planner to explore in the given time.
• There’s a logical flaw in your domain/problem that’s causing the planner to get stuck (e.g., unfulfillable preconditions, circular dependencies).
• ADL features (like forall, when, exists) are more computationally intensive for the planner to process than basic STRIPS.

Actionable Debugging Steps #

1. Simplify Your Problem First #

Start with a minimal version of your problem to rule out search space bloat:

• Remove one part from your assembly (e.g., just use base-plate and sub-assembly) and adjust the goal to completing that simplified assembly.
• Temporarily remove ADL constructs (like the forall precondition) to see if the planner can find a solution quickly—if it can, the issue is likely with how your ADL logic is structured.

2. Manually Simulate the Planning Process #

Walk through the initial state, actions, and goal step-by-step to confirm a valid solution exists:

1. Initial state: Robot isn’t carrying anything, base-plate and motor-plate are available, sub-assembly has both as parts, and base-plate must be assembled before motor-plate.
2. First action: Robot picks up base-plate (preconditions are met).
3. Second action: Robot assembles base-plate into sub-assembly (check the forall precondition—since no previous parts are required before base-plate, this should pass).
4. Third action: Robot picks up motor-plate (now available again, since it dropped base-plate).
5. Fourth action: Robot assembles motor-plate into sub-assembly (the forall precondition passes because base-plate is already incorporated).
6. Goal check: sub-assembly should be marked complete.

If this manual path works, your logic is sound—but the planner might be struggling to explore it efficiently. If not, you’ve found a logical flaw to fix.

3. Validate Your PDDL with ADL-Supporting Tools #

Since Torchlight doesn’t support ADL, use these tools to catch syntax or logical errors:

• VAL (Validation & Verification Tool): This is a must-have for PDDL debugging. It checks for syntax errors, validates action preconditions/effects, and can even verify if your problem has a valid solution (or why it doesn’t). Run it locally on your domain and problem files to get detailed feedback.
• FastDownward: A popular planner that fully supports ADL. Run it locally with verbose logging to see what the planner is searching for, and adjust timeout limits to give it more time. You can also tweak search heuristics to speed up exploration.
• Metric-FF: Another ADL-compatible planner that’s fast for simple problems—great for quick sanity checks.
• PDDL4J: A Java library that lets you parse, validate, and test ADL domains programmatically if you want to dig deeper.

4. Check for Hidden Logical Issues in Your ADL #

ADL constructs are powerful but easy to misconfigure:

• In your assemble action’s precondition: (forall (?prev - assembly) (imply (assemble-order ?prev ?part ?whole) (incorporated ?prev ?whole)))—make sure ?prev is correctly scoped. For motor-plate, this checks that base-plate is incorporated, which is correct.
• In the assemble action’s effect: The when clause checks if all parts of whole are incorporated. Double-check that ?p is correctly referencing parts of whole—your logic here looks right, but ensure there’s no typo in predicate names (e.g., part-of vs incorporated).
• Potential optimization: Your initial state includes (available sub-assembly), but sub-assembly is the assembly you’re trying to build, not a part to pick up. Removing this might reduce unnecessary search paths, since the planner won’t waste time considering picking up the uncompleted assembly.

Adjust Timeout Settings #

If you’re using planning.domains, see if you can increase the timeout limit (some platforms let you adjust this). If not, run the planner locally—you’ll have full control over how long it can run, plus access to detailed logs that can show where it’s getting stuck.

内容的提问来源于stack exchange，提问作者FvD