Basic Info

Description of contribution in a few bullet points

• BtActionNodes do not crash BT engine nor ros2 nodes holding them, as when there is a problem when calling an action server a BT::NodeStatus::FAILURE is returned instead of throwing an exception.
• When a BtActionNode fails, it is able to run a recovery mechanism, integral in BT framework.
• ros2 daemon is no longer corrupted being unable to discover bt_navigator ros2 node after relaunch
• Logs are more clear and the logging system is able to display logs from action servers

Description of documentation updates required from your changes

• No documentation necessary

Future work that may be required in bullet points

• Use return BT::NodeStatus::FAILURE + log error instead of throwing an exception for BT nodes

BT Nodes can fail, and are meant to allow this, using recovery actions as mechanism resolve these situations. For that, the BT Engine does need the BT Node to return a BT::NodeStatus::FAILURE. Throwing exceptions, will break all the recovery mechanisms the BT provide as the ros2 node and bt engine will be compromised. See also next point below for details.

• Initialize BT Nodes inputs on tick()

I have seen BT Nodes that when compulsory inputs are not provided, the node crashes in the constructor at runtime. This will not only crash the whole BT engine and ros2 node, but there is actually nothing wrong at all by a BT Node not having values for compulsory inputs during class constructor. These inputs can be published on the blackboard by other bt nodes ( for instance the SetBlackboard node). This will take place after the node construction.

It is therefore not meaningful to get values of inputs in the constructor as it's in the tick() method when they shall be loaded. BT Nodes do not necessarily have static inputs, they are dynamic by design by means of using the blackboard.

Whether a BT Node has compulsory inputs is a check that needs to be done in the tick() method. And then there is the question as to what to do when these are not provided. From my POV a nice error log together with returning a BT::NodeStatus::FAILURE is the right way to do it (not crashing the whole bt_navigator using exceptions).

For Maintainers:

• Check that any new parameters added are updated in navigation.ros.org
• Check that any significant change is added to the migration guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists