tree_generator does not handle multiple keyframes with the same label in one tree

[angeltop]

A sequence of keyframes may have multiple "move" keyframes. However, each keyframe id is unique in the sequence. Mapping keyframes to BT subtrees should be done based on the keyframe id; the subtree type depends on the keyframe label. The same behaviour is necessary for setting and getting the generated tree's ros parameters.

[diogoalmeida]

Hi,

Thanks for the report. The problem is fixed from the perspective of the tree generation (will push it soon). However, the solution for passing the idx values to the action servers will be temporary. They way I have it implemented, a subtree would have a constant set of parameters during execution. If we however have two set of parameters, for the same subtree, it becomes tricky to choose the right ones when the subtree is tick'ed.

My solution for now will be to simple accumulate the idx values in the parameter server, under the same label. The actions will cycle through the parameters in the same order as they were received. This can go wrong in many different ways, but should work with the current implementation.

What I believe to be the correct implementation from a Behavior Tree point of view would require a modification of the subtree structure, such that each subtree would have a preliminary "load parameters" action. When generating the full tree, this special action would be assigned the parameters that were received from the keyframe. That way, when the subtree is tick'ed, it will always load the right parameters for that particular execution point.

[diogoalmeida]

You can test the temporary fix in 942bed6 . This is in the branch "temp_idx_fix", and should work for very simple trees.

With this solution, if everytime an action client is tick'ed, it will cycle through the idx list that was received from the keyframes. Thus, if an action fails and it is tick'ed again, you might end up sending the wrong idx.

For simple trees like the ones the project has right now, this should allow you to go forward, while I try to come up with a more elegant and robust solution.

[diogoalmeida]

Ok @angeltop, I think I have a good solution for the problem. You can test by pulling the latest commit in the load_parameters branch. This will also require you to pull changes in my behavior tree engine fork.

The way this works is through the addition of a "loader" node. This will load parameters in the parameter server when it's tick'ed. The parameters are loaded in memory when the node is created. So now, when the tree generator receives a list of keyframes, it will add to each subtree a loader node with the idx to be loaded for that particular subtree. More details can be found in #7.

The cool thing about this is that extending it to pass an arbitrary number of parameters from the keyframes is very simple. Furthermore, the subtrees themselves can be designed with loader nodes, if we want to reconfigure an action statically, through the JSON tree description.

Let me know if this solves the bug, and I'll merge the changes. Besides pulling the changes in both repos, I believe everything should be working as before, minus bug.