Support for Fluents and Metrics in the Package Expert

[rossj13]

The support to dynamically added and remove fluents and goal metrics with the problem expert the same way predicates, instances and goals are would be very helpful

[fmrico]

Hi @rossj13

Thanks for your interest. I also think that fluents and metrics are an excellent feature to have. Popf supports it, but it should be managed from domain/problem experts, mainly.
PRs are also welcomed ;)

Best

[teyssieuman]

@rossj13 : The fluents are now available : it is possible to assigne a function value from the problem expert client.
What do you mean by "goal metrics" ?

[fmrico]

I agree with @rossj13 , it is necessary to address the goal metrics.

@teyssieuman by goal metrics (@rossj13 correct me if I am wrong) I understand that the planner tries to optimize the minimization o maximization of a function when calculating a plan. From here:

To specify action costs, it is necessary to add a "fluent" that keeps track of the cost. A fluent is like a state variable/predicate, but its value is a number instead of true or false. Again, note that PDDLs fluent syntax is very expressive, and most planners will only accept a limited use.
To declare fluents, add the following section to the domain specification:

(:functions
(total-cost)
)
Specifying that the cost of an action is C is done by stating that the action has the effect of increasing the total-cost fluent.

:effect (and ... (increase (total-cost) C))
The fluent must be initialised. In the :init section of the problem definition, add

(= (total-cost) 0)
Finally, to specify that minimising the sum of action costs is the objective, a :metric section is added to the problem definition:

(define (problem ..)
.
.
.
(:metric minimize (total-cost))
)

[fmrico]

Hi @rossj13

Since #62 , this should be fixed. Can you test it so we can close this issue?

Thanks!!

[rossj13]

@fmrico sorry for the delay. Ill try the new changes

So just to be clear support for fluents and metrics should now be included within the problem and domain experts? I don't see anyway to add them. Is that what assignments are? I dont see anything for metrics. What am I missing?

[rossj13]

Looks like the fluents work. Still needs support for metrics to maximize the fluents usefulness.

[sethhoward]

Metrics would be a huge win for some of our use cases as well as actor selection.

But I think the bigger issue is none of the plugins (POPF, Fast Downward, Mips, LPG) support metrics from my testing.

[fmrico]

Hi @sethhoward

My students analyzed in one exercise a lot of planner, and they found some interesting planners that supported metrics. Let me check the results because they also created plugins for most of them.

Best

[kogut]

Metrics would be a huge win for some of our use cases as well as actor selection.

But I think the bigger issue is none of the plugins (POPF, Fast Downward, Mips, LPG) support metrics from my testing.

I can corroborate popf, TFD, and MIPS-XXL (the versions indicated by PlanSys2 plugins).

I've had a bit of luck with metrics in LPG-TD. (in fact I can't seem to successfully plan without one which makes it hard to run baseline tests). I created a simple "energy-used" metric with a function keeps track of energy subtracted from the battery. When running with the metric, the LPG-TD planner results indicate that the metric is being used both in the "C" field of each action as well as the total "Execution cost" reported to stdout on the console. What I haven't been able to demonstrate is that LPG-TD is using the metric in any meaningful way. I see little difference when switching between "minimize" and "maximize." And it doesn't help that LPG-TD has a surprising amount of variation in plan results in repeated trials (unlike popf which is super deterministic).

I'll report new findings here since I share this interest.

[kogut]

But I think the bigger issue is none of the plugins (POPF, Fast Downward, Mips, LPG) support metrics from my testing.

So far I've found that KCL's Optic planner (a derivative of popf) provides really good support for metrics that use numeric fluents.

There, unfortunately, is no really good git repo with a version that's conveniently build-able using a modern build system (like @fmrico did for popf). But it only took me a few hours from the 2012 optic tarball from KCL. I may work on a PlanSys2 plugin for optic as well as a ROS 2-build-friendly version of optic, but no promises yet.

[fmrico]

@kogut, Maybe using the binary is not so bad...

[roveri-marco]

I've successfully compiled latest version of optic on Ubuntu 20.04 LTS.
You can find it here: https://github.com/roveri-marco/optic

[fmrico]

@roveri-marco @kogut

Excellent!! The next step is having a planner plugin similar to the ones for popf or lpgtd. These plugins only call to the binary and parse the output. You could add in this plugin a reference to https://github.com/roveri-marco/optic in the building instructions.

We should be thinking about supporting metrics at runtime in PlanSys2. @jjzapf, I think that this is not covered in #118, isn't it?

Thanks!

[kogut]

I will create the planner plugin, and work with @jjzapf on proper metric support throughout PlanSys2 (not covered by #118).

[kogut]

I have completed both an optic ROS 2 package (similar to popf's ROS package) and a PlanSys2 plugin for that package. I'll post the github URLs here once I get approval for making the code public.

[gregtkogut]

I apologize for the delay here. There is now a version of Optic on github that builds directly in a ROS 2 workspace similarly to popf . https://github.com/sscpac/optic-planner. Thank you @roveri-marco for much of the work, and attribution is given, but I went the route of creating a new repo largely because of employer-related issues. Next I'll add the PlanSys2 plugin to this new planner, which should follow this very quickly, then tackle actual support for things like fluents/metrics.

[roveri-marco]

@gregtkogut No problem! It is fine and I'll be willing to experiment with it and use it within plansys2!

[gregtkogut]

The OPTIC plugin is now operational in the same repo as above. However it's only useful for simple plans at the moment because of a strict service call timeout within the PlanSys2. I'm working on that in another issue, as a pull request to this repo.

[fmrico]

@gregtkogut Maybe we could parametrize this parameter, and adding it to the config file.

[gregtkogut]

Yes, that's my intention. I have a branch that does that, that I'm testing.

[fmrico]

Closing... reopen if you want to continue with this

[oyssolbo]

@gregtkogut Is there any progress on the support for metrics or OPTIC?

[gregtkogut]

The above GitHub link has a version of OPTIC that with modern compilation and PlanSys2 integration. I know it's building (part of a nightly build), but I haven't actually used the plugin in quite some time.

OPTIC metrics: As a standalone planner, I found OPTIC to have some support for metrics, but it seems fragile, narrow, and inconsistent in important ways. I believe some "refactoring" would be necessary for most metric use. The original developers have done this, I believe, but have made that proprietary code.

PlanSys2 metrics: I haven't checked recently, but I don't believe PlanSys2 yet has native support for metrics. It would require a lot of work to do right, outside the scope of my personal time.

[fmrico]

Metrics depend on popf, as far as I remember. popf accepts metrics, but it doesn't really use it.