riccardodebenedictis
commented
3 years ago Thank you very much for the questions, which give me the opportunity to clarify some aspects!
Version 2.9 aims to clean up some aspects of the code, fix bugs and make the graphical interface "more modern". In particular, the old version used prefuse as a library for viewing graphs, a library which has not been maintained for decades and which creates problems with the most recent versions of java. This version also aims to have more organized benchmark problems so that it is easier to demonstrate the qualities/properties of the solver.
All of these changes aim at developing a more effective heuristic. The current heuristic, in particular, is inspired by the classical planning heuristic h_max, which is a heuristic from about twenty years ago. Adapting that heuristic to this form of reasoning was not very trivial, but now that it has been done it is possible to adapt other classical planning heuristics so as to make the solution process much more efficient (hence the need to have better organized benchmarks and a graphical interface that allows to understand how heuristics behaves).
Regarding uncertainty, I did not investigate it deeply. It is definitely possible to introduce an additional variable to each atom for representing its observability, etc. and it would also be possible to implement a STNU as a SMT theory. This STNU, however, should be disjunctive (to manage possible alternative plans). I don't know any algorithm that handle this problem and creating a new one could be an interesting research problem. What I would do, however, is to extend the linear arithmetic theory so as to handle optimization. Most of that code basically comes from the simplex method, so it should be easy to extend it to manage optimization. Specifically, since constraints are linear, I would assume that minimizing/maximizing a temporal variable in a (partial) solution would give you the variable's bounds and, if they are strictly contained in the original ones (i.e., those in the problem) then the events associated to the variable are no more free to happen "whenever they want" (so, the uncertainty is not guaranteed and the solver has to find for another plan). But I have to think more deeply on that. Introducing optimization might be useful also for other reasons.
More in general, however, the causal graph contains a representation of different plans that represent solutions for the given planning problem. In case of an unexpected event (any kind of event, not necessarily a delay!), it would be possible to switch from one plan to another.
It is certainly possible to update the domain at runtime adding new fields, new methods, new predicates etc.. Currently, in order to do that, you have to inherit from ratio::type (I will add some simple documentation for that, but the methods' names should be kinda self explanatory). You have some example of that in the reusable resource. The question is: why would you do that? Types such as state-variables and reusable-resources implement the get_current_incs() procedure which allows to make the corresponding timelines consistent. Types that do not implement this method can probably be defined much more easily in riddle. Most of the code, additionally, is the one defined within the rules (when, in riddle, predicates are defined) and, writing it in cpp, could be a hard work. Yet it is probably me who does not see the usefulness! So, if you need it, I would ask you to please explain better what you have in mind :wink:.
The biggest problem, however, comes in case of unifications. If you dynamically introduce new fields, specifically, you might have different instances of the same type having different fields, and I would not know how to force them to be equal..
From instances of ratio::type, however, you can already retrieve fields, methods, predicates, etc., all of them in bulk, or singularly by their names. It is also possible to retrieve instances of objects which are created, for example, in riddle. You can, for example, create ratio::solver instance. Through the read you can read some riddle script (e.g., a script for creating a real variable: real x0;) and then retrieve it from the solver's get method (e.g., get("x0)";). The returned arithmetic expression can be evaluated (e.g., solver.arith_value(expr)) or constrained with other arithmetic expressions.
solver slv;
slv.read("real a, b;");
auto a = slv.get("a");
auto b = slv.get("b");
auto c = slv.geq(slv.add({a, b}), slv.new_real(1));
slv.assert_facts({c->l});
slv.solve();
auto a_val = slv.arith_value(a);
auto b_val = slv.arith_value(b);Notice that a and b are real variables, while c is a bool variable. When the c fact is asserted (i.e., the c variable is forced to assume the true value), the constraint a + b >= 1 is enforced. If you retrieve the variables' values you will get that their sum is greater or equal than 1 (in my case, a_val is 1/1 and b_val is 0/1). Perhaps the API can be cleaned up (e.g. by overriding the arithmetic operators on the arithmetic expressions), but I hope the above code gives an idea of what is possible to do.
As regards execution, as you correctly guessed, the hard part is related with plan repair. All the references should be available for adapting a plan from a solution. If the repair regards some delay, it should be possible to introduce the delay as a constraint and call again the solve() method. The causal graph, additionally, maintains causal relations among atoms! So, in principle, it should be possible to introduce dynamically new atoms or to remove (actually, hide them) the existing ones. By calling the solve() method, the causal graph should adapt, exploiting information that previously led to the generation of the solution (hence, the adaptation should be efficient). Unfortunately, nothing of that has ever been tested.. so if you have some practical (possibly simple :D) example, I am more than happy to test it and make it work!
I hope that I answered most of your questions! If not, feel free to ask again! There is, for sure, plenty of room for improvement.. Discussions like this are also very valuable to me! :grinning: I am the only one working on this, so changes might require some time, yet if they reflect some real need or some specific research issues, I am more than happy to introduce them :wink:
nrealus
Hello,
I am a master-level student who discovered and got very interested in the field of AI planning during this summer. I have read your thesis on oRatio and timeline-based planning, as well as a fair amount of other papers on AI planning and temporal networks published in the past 20 years. However, the subject isn't really related to my studies, and I am not really interested to pursue academic work in it - for now at least ! As such, I am no specialist at all, but as an engineer, I do find the subject to be extremely interesting, important and promising for real-world applications.
First of, I'd like to say that your work on oRatio appealed to me the most out of all recent planners I've encountered in academic literature. I think it is great in its design and architecture : it is rich, modular, extensible, elegant but also robust, compact and non-restrictive for the user. Finally, I feel like it can be truly used to approach a very wide range of problems, possibly by extending and "specialising" it if necessary (with more advanced heuristics, types, smt theories...).
The reason why I am writing is because I would like to have some clarifications and input on a few issues and questions that came to my mind. Indeed despite all the reading, I'm not a specialist, and there are things I am not really sure I'm figuring out or getting correctly.
First of all, I saw you were working on a 2.9 version and that you put a lot of work on GUI and new theories for the SMT-reasoning module. But apart from that I couldn't really figure out what planned features / changes / additions you were aiming for in this version. Could you give a few details ?
My second question is about uncertainty and partial observability of events. You touched on that subject in your thesis but mostly when talking about the state of the art. I am failing to see how oRatio could support that. I think that PLATINUm uses a STNU of tokens, which are labeled observable, hidden etc, but I may have gotten it wrong. Is that something that could be approached simply with a enum type field for atoms (indicating whether the token is controllable, hidden, or not), or maybe in the solver module (causal graph), or perhaps in the SMT-reasoning module ? If so, how easy or how annoying would that be ?
The third question is about domain and problem adaptation on runtime. If I understand correctly, the compilation units that are given to oRatio are parsed from RIDDLe and then "translated" into "new_method", "new_predicate" etc. methods in core.cpp. Does it mean that domain and problem definition could be possible directly through code in a practical and efficient way (for example, with a method chaining approach) ? Also could there be a way to use "normal cpp variables" as parameters or arguments for the domain ? (maybe "binding" them with RIDDLe expressions / propositional agents / variables ?) But I can't really figure out if all of that would "break" the solver or not. If so, could you give me the cause of it ?
The final question I have is about "acting". I am not sure whether it would be possible (and if so, how hard/reasonable/effective that would be) to incorporate oRatio with an "acting" component with a sort of "closed-loop" / "plan-repair" approach. My guess is that "true online planning" (with reactions during the search process itself, parallel to the causal graph construction) would be out of the scope of oRatio and an unsuitable task for the architecture. But I hope I am wrong, because that would be really great. Maybe there could also be a simpler, more "naive" (but less efficient) approach that would allow for something similar.
There it is, sorry for the very long post. Thank you in advance, and best of luck with this very promising project !