GRoot integration

[StefanoSoffiaUTRC]

Goal: Enable the CARVE BT interpreter to read BT specifications generated by the GRoot tool from the Mood2Be ITP.

See the uploaded BT specifications.

The first BT specification should pose no difficulties, it is just a matter of agreeing on the .xml schema:

The last one tries to experiment with tree parameters (with the goal of identifying reusable sub-trees). It first defines two parametric sub-trees GotoRoom and FindAndFetchObject and then instances them. One open point is if-and-how to refer to the parameters of a sub-tree from its nodes. This example uses the syntax ${subtree.PARAM_NAME}$ just to convey the idea. To be discussed with Davide.

[altacch]

Perhaps I never made this clear, but the current implementation of the interpreter (and mkspec also) are already using precisely Faconti's XML schema. Indeed I just verified that our interpreter will happily run the first file (modulo the preliminary execution of readskill).
However, skill parameters and sub-trees are not supported at the moment.

[StefanoSoffiaUTRC]

Good. Afaik to avoid duplication it could be GRoot to perform 1. parameter value propagation and 2. sub-tree expansion, so as to e.g. transform the third BT into the first. I'm currently looking at the Groot internals to get an idea of how it works: We might ask for this and the ability to edit contracts directly in GRoot.

[altacch]

I agree. In fact doing the transformation doesn't look difficult. Especially sub-tree insertion should be straightforward. As regards skill parameters, we can have a discussion about supporting them natively (i.e. modifying our current BT data type) versus supporting them by means of a preprocessing step in GRoot (e.g. the condition "IsRoomKnown" with parameter "Kitchen" becomes the (non-parametric) skill "IsRoomKnown_Kitchen", or similar)

[altacch]

By the way, I noticed that in the output files produced by GRoot there is a "TreeNodesModel" tag which is (basically) a list of the basic skills used in the BT. By making a trivial modification to the readskill utility, I could make readskill read the list of basic skills directly from this tag (i.e. from the BT input file), without needing a separate XML file.
Should I make this change?

[StefanoSoffiaUTRC]

Should I make this change?
It sounds reasonable.

[facontidavide]

Hi,

first of all, if everything isn't clear, just let me know ;)

1. About subtrees. It is important to point out that Groot works differently from the executor you can find here: BehaviorTree
   The former (the executor) will always build/instantiate the expanded tree; in other words, subtrees have by default a value semantic (copy) and not a reference semantic (pointers).
   Groot instead use mostly a reference semantic.

2. About the TreeNodesModel. This is a minimalistic way to define the palette of user defined TreeNodes (the building blocks) which are available in the left side of the editor. I am also working on a system that uses a library of [plugins + manifest] to create this palette.
   In my opinion Skill and TreeNodeModel are completely different concepts. The latter is... the model of a TreeNode (surprise), nothing more, nothing less.

3. Feel free to contact me if you have any doubt.

[altacch]

Hi @facontidavide, thanks for the clarifications. Given your "semantic" description, it seems better for us to stick with our current approach (i.e., to give a list of all the usable skills in a separate XML file).
What about the feasibility of the other two transformations mentioned by Stefano above? Namely, could you provide an option to "export" a BT in a format which has:

• (eventual) subtrees "expanded out", and
• (eventual) parameters incorporated in the skills name (e.g. "IsRoomKnown" with parameter "Kitchen" becomes "IsRoomKnown_Kitchen")?

[facontidavide]

subtrees "expanded out"

Sure, I will work on that.

 parameters incorporated in the skills name

I am not sure I understood... probably because we haven't agreed on the relationship between the word "skill" and a LeafNode. If I guess correctly, you want some syntactic sugar to convert this:

     <Condition ID="IsRoomKnown" room="Kitchen"/>

into

    <IsRoomKnown_Kitchen/>

[altacch]

Actually I would like the target to be

<Condition ID="IsRoomKnown_Kitchen"/>

In any case, we did not decide yet if we are going to handle the parameters in this way...