Subtrees are not able to share blackboard resources

[naiveHobo]

Steps to reproduce issue

Spin up a robot in the simulation with the following tree:

<root main_tree_to_execute="MainTree">
  <BehaviorTree ID="ReplanningTree">
    <RateController hz="1.0">
      <ComputePathToPose goal="{goal}" path="{path}" planner_id="GridBased"/>
    </RateController>
  </BehaviorTree>
  <BehaviorTree ID="MainTree">
    <PipelineSequence name="NavigateWithReplanning">
      <SubTree ID="ReplanningTree"/>
      <FollowPath path="{path}"  controller_id="FollowPath"/>
    </PipelineSequence>
  </BehaviorTree>
</root>

Expected behavior

ReplanningTree is able to get blackboard resources and executions continues as expected.

Actual behavior

Throws a missing key error for resources on the blackboard and aborts bt_navigator configuration.

Error Log

[lifecycle_manager-13] [INFO] [1588963214.003140012] [lifecycle_manager_navigation]: Configuring bt_navigator
[bt_navigator-11] [INFO] [1588963214.003796274] [bt_navigator]: Configuring
[bt_navigator-11] [ERROR] [1588963214.033044873] []: Caught exception in callback for transition 10
[bt_navigator-11] [ERROR] [1588963214.033069811] []: Original error: Blackboard::get() error. Missing key [node]
[bt_navigator-11] [WARN] [1588963214.033102801] []: Error occurred while doing error handling.
[bt_navigator-11] [FATAL] [1588963214.033121137] [bt_navigator]: Lifecycle node entered error state
[lifecycle_manager-13] [ERROR] [1588963214.034978660] [lifecycle_manager_navigation]: Failed to change state for node: bt_navigator
[lifecycle_manager-13] [ERROR] [1588963214.035045085] [lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.

[SteveMacenski]

I would remove “navigation2” context here. The issue is just around sharing the blackboard between sub trees.

[naiveHobo]

@SteveMacenski ongoing discussion on #168, I'll close this issue.

[facontidavide]

As clearly explained in the documentation, one of the MAIN purpose of subtree is isolating the blackboards. That is not a bug, it is the desired behaviour.

https://www.behaviortree.dev/tutorial_06_subtree_ports/

If you want to share blackboard entries, you must use port remapping.

UPDATE:

I just made a change for those people that want to live dangerously

<SubTree ID="ReplanningTree" __shared_blackboard="true"/>

Default of course is false

[SteveMacenski]

@facontidavide to me, the main reason of subtrees is to have some chunk of capability you may want to have in multiple places in the tree be portable (e.g. reduce duplication) as well as having different scopes to analyze behavior with.

The idea of sharing or not-sharing the blackboard seems like it should be a parameterization when you add a particular subtree to a BT. In some cases having them talk could be bad, but for sharing general resources, I think that's potentially good behavior. I could see abuses to it for sure, though.

[facontidavide]

To really make people understand the reasons why isolation is important, I should write an essay about it ;)

I was going to write an answer, but I really need to take my time and explain this thoughtfully in the documentation, because it is hard to understand how important this isolation is to achieve composability.

Extra short version: blackboard entries are glorified global variables. As in any programming language, name collision is very hard without namespaces and scope.

[SteveMacenski]

This is true - I definitely don't disagree with you. But there are also some things that are global that really should be accessible to all the nodes if they want it. For example imagine a time entry into the blackboard for the current tick time and that was important for a cascading control system. Or in a ROS2 context a node to get parameters or spin futures with. Or metadata about the version of the tree it is 3.2.5 which might matter for some reason.

I think there are legitimate reasons to have it shared across all subtrees, but I agree that be default it makes sense to have it off. But I think for those cases having something in the include tag for composing trees to enable it would be good. Or even take in a file of specific keys to allow through.

[SteveMacenski]

My use of the blackboard is in only sending around parameters that need global use (nodes, times, etc) or in parameters that change in run-time who's direct children or parents do not require it (eg a path / goal). In my opinion the blackboard is to be used with sparing use and rely primarily on the behavior tree nodes and structure. However when you need the blackboard, you really need the blackboard to keep things generalized and not baking in tree structural knowledge to each node.