Porting potential cross-domain applicable Control and Decorator from Nav2 into BehaviorTree.CPP

[Mechazo11]

Hi @facontidavide

I am a robotics researcher from USA and in a recent internship, we have been extensively using BehaviorTree.CPP v3.8 for orchestrate a variety of autonomy and robot navigation related tasks. This backdrop leads to the following feature request

Feature Proposal

Nav2, a popular open-source project from OpenNavigation is known for adding a number of useful Control, Action and Decorator nodes. Some of the most useful ones are PipelineSequence, RecoveryNode and RateController

Some autonomy related projects may have constraints of not using ROS 2 ecosystem. Without ROS 2 and by extension Nav2, these useful nodes become inaccessible natively from BehaviorTree.CPP.

Proposed Solution

I propose to open a PR for v3.8 branch that backports a number Nav2 nodes as native BehaviorTree.CPP nodes.

From what I have found out so far, the implementation of these nodes may have minimal dependency on the actual Nav2 stack. An example: pipeline_sequence.hpp

In my opinion, the following nodes may be most suitable for application across various domains

Control nodes

• PipelineSequence: reticks preceding child nodes that return SUCCESS.
• RecoveryNode: Two child node that only returns SUCCESS if and only if left child is successful.
• NoneblockingSequence: NonblockingSequence ticks all children until one fails, re-ticking running/successful ones, and returns SUCCESS only if all succeed.

Decorator nodes

• Rate Controller: "Controls the ticking of its child node at a constant frequency. The tick rate is an exposed port"

Additional Context

Why v3.8? I have recently worked with a number of robots from notable robotics companies who are still using ROS 2 Humble and the humble branch of Nav2. As far as I know, BehaviorTree.CPP v3.8 is the version supported by Nav2 Humble.

[SteveMacenski]

I don’t mind one way or another, but I also think these are a bit non-generic to the types of behaviors we have in autonomy stacks. I’m not sure architecturally I’d place them in BT.CPP. Maybe if there was a ‘zoo’ library of additional BT nodes that could be a good addition there, but that essentially is what the Nav2 BT package is. I think the nodes should probably just stay in Nav2. We’re always cooking up new nodes

[Mechazo11]

Hi @SteveMacenski thank you for your insight. From my current internship experience, the approach I have seen is that autonomy and navigation are regarded as two separate modules. All autonomous robot behaviors (re-planning, collision avoidance, point-to-point navigation etc.) are regarded as methods/skills within navigation module whilst autonomy is regarded more as an Agentic AI that acquires navigation along with other modules to perform various tasks defined in human language.

However, a number of Nav2's BT nodes appears to be quite useful to orchestrate the autonomy's stack itself but sometimes these trees needs to be Nav2 independent (in one case it was even ROS 2 agnostic). This is what lead me to this proposal.

[facontidavide]

if you want to submit a new node type, please submit a PR, keeping into account:

• good Doxygen comments to explain the logic and use case
• code that carefully consider all the STATES, including SKIPPED
• unit tests