Replies: 1 comment
-
I've run into this as well. We "solved" this in a similar manner to you. Our BTs all have comment "headers" that document their expected input, output, and bidirectional ports. We trust developers to review this header and to keep it up to date, but it isn't perfect, and has led to some bugs. An example derived from a real tree we have: <!--
Input ports:
- x (std::string)
- y (int)
Bidirectional ports:
- queue (std::shared_ptr<std::deque<geometry_msgs::msg::PoseStamped>>): poses to navigate
Output ports:
- count (int): number of poses navigated so far
-->
<BehaviorTree ID="NavigatePoses">
<Sequence>
<!-- ... -->
</Sequence>
</BehaviorTree> What would be ideal is to have static analysis on ports so that we can know at compile time if our trees are remapping ports correctly with the correct types. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been working heavily with the behaviortree_cpp library for the last couple months, and have found myself frequently using a design pattern where I create a subtree that functions as a "method" with certain inputs and outputs that are required to be remapped from the parent tree to the sub-tree. This seems to be a useful design pattern because it means that I can build up re-usable subtrees that I can then "call" where necessary in larger trees. An example would be a tree called "plan_and_execute_arm_motion", which takes in a "goal" and "arm_prefix" and outputs a "final_tcp_position" and "failure_details". This tree then calls the subtrees "plan_arm_goal" and "execute_arm_goal" which do what their names imply with some handling of different failure cases. I expect, but don't know, that this is a common design pattern.
The part where this feels messier than I would like, is that as far as I can tell, there's no way to specify a list of "inputs" and "outputs" to a subtree that need to be populated, like you do with Actions/Decorators/etc. To get around this, I've been keeping a separate document with the required inputs and outputs of a function and what they do and referencing that when I need to use one of my "method" subtrees.
Is this a limitation that others have been running into? Any thoughts on if there might be a better way for me to handle this? Or maybe this just isn't a recommended design pattern?
Beta Was this translation helpful? Give feedback.
All reactions