Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returned plans should be parsed and returned in a well structured way; plan cost including #36

Open
jan-dolejsi opened this issue Jun 1, 2022 · 3 comments

Comments

@jan-dolejsi
Copy link

Some planners return their entire diarrheas output into the result.output.plan field. Some return a properly formatted plan as text. The original /solve interface returned the plan in a rich Json structure. The planutils should be able to parse and standardize the plan structure between temporal and strips planners.

The plan cost is also included in different formats in the planner output. With bit of luck, one can get the plan from result.output.plan field and find the cost from the result.stdout. But as soon as you have multiple plans, you cannot figure out what belongs to what.

Ideally, result.output.plan should be a structured element with steps or actions if you want as well as cost and/or makespan and possibly the search stats such as statesEvaluated.

@haz
Copy link
Contributor

haz commented Jun 1, 2022

As mentioned elsewhere, this comes down to package-specific setup. We could insist that packages adhere to a particular format (their plans go to a file and not stdout, etc) before they are officially included as part of the main PaaS deploy, but in general, a package is free to define the manifest (and thus endpoints) however they'd like.

Would this be an issue to perhaps have the manifest flag if they follow the "planner output standard X", in which case we could/should parse & package up things?

@jan-dolejsi
Copy link
Author

jan-dolejsi commented Jun 2, 2022

The planners should have the flexibility to output to stdout or to files. I agree.

But either way, they should standardize to one of the supported plan formats. The plan parser may be rather flexible, but it needs to be able to unambiguously discover, where plan starts and where it ends.

The VS Code PDDL extension is already doing fair bit of that.

https://github.com/jan-dolejsi/pddl-workspace/blob/master/src/parser/PddlPlannerOutputParser.ts
https://github.com/jan-dolejsi/pddl-workspace/blob/master/src/parser/PddlPlanParser.ts

  • tests ...

https://github.com/jan-dolejsi/pddl-workspace/blob/master/test/parser/PddlPlannerOutputParserTest.ts

@haz
Copy link
Contributor

haz commented Jun 3, 2022

Well single+multiple plans is standard enough to enforce for inclusion in PaaS. The planner/package manifest can point to the file location, and perhaps indicate the style of plan output (just action sequence with ; comments, temporal plans, something different), and then have dedicated code in PaaS to attempt a parse. We followed this strategy with the legacy solver:

https://github.com/AI-Planning/cloud-solver/blob/master/process_solution.py

For those packages that are just dumping plans to stdout, we can lean back on the authors and give them the ultimatum to fix it, or be removed from the remote service ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants