You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using the graphplan algorithm on a self-defined planning problem #1136
Hi!
I am trying to use the Graphplan to solve a self-defined planning problem. As per now, I am creating an object of type "PlanningProblem" with the initial state, goal state and possible actions. Each of the actions consist of "preconditions" and "effects". I've seen that in some of the examples, such as "spare_tire" and "three_block_tower" do have a defined domain as well while "simple_blocks_world" does not. What does the domain actually mean, and how does it impact the solving of the planning problem?
When running the the Graphplan algorithm on my planning problem, it only returns "No Solution" and I am not able to figure out why.
Any suggestions/tips are greatly appreciated :))
in the simplest planning problems such as "simple_blocks_world" or "have_cake_and_eat_cake_too" it is not necessary to specify the domain of the objects because these are all of the same type (blocks A, B, and C in the case of "simple_blocks_world" problem or Cake in "have_cake_and_eat_cake_too" problem).
All the other problems instead manage objects of various types for which it is necessary to specify the domain of each one so that the actions can be performed on the correct objects to prevent actions which does not make sense!
Anyway, this does not affect the GraphPlan algorithm because it does not enumerate all possible actions as does ForwardPlan, BackwardPlan, SATPlan, and CSPlan.
I advise you to check the definition of your problem or try other solvers like the ones mentioned above. :)
The domain question was answered in-thread, and the GraphPlan engine was reworked in #1324 (fixed mutex/interference/level-off handling, added tests/test_graphplan.py). A small self-defined problem now solves correctly on current master (e.g. a one-action toggle problem returns its plan). If you define a custom PlanningProblem with capitalized predicate/constant names (lowercase are variables), GraphPlan(problem).execute() should work — please reopen with a current snippet if you still hit 'No Solution'. Closing.
Activity
dmeoli commentedon Nov 25, 2019
Hi @sarahsa
in the simplest planning problems such as "simple_blocks_world" or "have_cake_and_eat_cake_too" it is not necessary to specify the domain of the objects because these are all of the same type (blocks A, B, and C in the case of "simple_blocks_world" problem or Cake in "have_cake_and_eat_cake_too" problem).
All the other problems instead manage objects of various types for which it is necessary to specify the domain of each one so that the actions can be performed on the correct objects to prevent actions which does not make sense!
Anyway, this does not affect the GraphPlan algorithm because it does not enumerate all possible actions as does ForwardPlan, BackwardPlan, SATPlan, and CSPlan.
I advise you to check the definition of your problem or try other solvers like the ones mentioned above. :)
dmeoli commentedon Jun 27, 2026
The domain question was answered in-thread, and the GraphPlan engine was reworked in #1324 (fixed mutex/interference/level-off handling, added
tests/test_graphplan.py). A small self-defined problem now solves correctly on current master (e.g. a one-action toggle problem returns its plan). If you define a customPlanningProblemwith capitalized predicate/constant names (lowercase are variables),GraphPlan(problem).execute()should work — please reopen with a current snippet if you still hit 'No Solution'. Closing.