Which aspect of BT.CPP was harder to understand?

Questions
#1

As maintainer of the documentation, I think that it is not too bad, but it can be greatly improved.

It is always hard to put oneself in the user’s shoes, therefore I wonder if anyone wants to share their frustrations: which topic took you a lot of time to understand “well”?

Or in other words, what would you like to be added / improved in the official tutorials?

1 Like
#2

First, thank you @davide for the BehaviorTree.CPP library. I found the library very helpful when integrating it into the Navigation2 project and using it to “open up” the Nav2 behavior and allow for custom scripts.

I recall these being some of the main issues I found hard to understand and/or struggled with (this may be a bit vague, as it was a few years ago):

  • Parallel Nodes - I was confused about parallel nodes and whether I should use them. Also, the model of parallel node was not intuitive (the success and failure thresholds). Finally, the BT ticking model and its interaction with parallel nodes was also a concern.
  • Halting the tree - I remember being confused about how to halt a node and its children and how to ensure that a node and its children were in the correct state.
  • Debugging - Getting an understanding of the whole tree was a challenge. This is where sub-trees can be helpful. I also recall wanting to have an include capability so that I could use a defined sub-tree in another behavior tree as a unit. The hierarchy would help address the complexity. As one scales up to larger trees, managing the complexity is important. I tried groot at one point, but wasn’t able to effectively use my custom nodes.
  • Interface to ROS Actions - It took me a bit to understand how to integrate a ROS action client into a BT node.

Hope that helps.

#3

First of all, it i great having you @mjeronimo in the forum :smiley:

About halting the tree, I added a new article 3 days ago to the website discussing this topic:

About includes, I made recently some interesting progress that you can check here:

#4

Great, thanks. Glad to see the additional docs.

By the way, something I really liked about using Behavior Trees was the ease of introducing “scoped recoveries”. That is, having a tailored response to a localized failure (such as failing to plan a path) versus just one overall recovery strategy in response to “something went wrong” where one might run through a bunch of recovery behaviors.

1 Like