Detailed Behavior Tree Walkthrough¶
This document serves as a reference guide to the main behavior tree (BT) used in Nav2.
There are many example behavior trees provided in
but these sometimes have to be re-configured based on the application of the robot.
The following document will walk through the current main default BT
in great detail.
Become familiar with the concept of a behavior tree before continuing with this walkthrough
Read the short explanation in navigation concepts
Read the general tutorial and guide (not Nav2 specific) on the BehaviorTree CPP V3 website. Specifically, the “Learn the Basics” section on the BehaviorTree CPP V3 website explains the basic generic nodes that will be used that this guide will build upon.
Become familiar with the custom Nav2 specific BT nodes
Recovery subtree is the second big “half” of the Nav2 default
In short, this subtree is triggered when the
Navigation subtree returns
FAILURE and controls the recoveries at the system level (in the case the contextual recoveries in the
Navigation subtree were not sufficient).
And the XML snippet:
<ReactiveFallback name="RecoveryFallback"> <GoalUpdated/> <RoundRobin name="RecoveryActions"> <Sequence name="ClearingActions"> <ClearEntireCostmap name="ClearLocalCostmap-Subtree" service_name="local_costmap/clear_entirely_local_costmap"/> <ClearEntireCostmap name="ClearGlobalCostmap-Subtree" service_name="global_costmap/clear_entirely_global_costmap"/> </Sequence> <Spin spin_dist="1.57"/> <Wait wait_duration="5"/> <BackUp backup_dist="0.15" backup_speed="0.025"/> </RoundRobin> </ReactiveFallback>
The top most parent,
ReactiveFallback controls the flow between the rest of the system wide recoveries, and asynchronously checks if a new goal has been received.
If at any point the goal gets updated, this subtree will halt all children and return
SUCCESS. This allows for quick reactions to new goals and preempt currently executing recoveries.
This should look familiar to the contextual recovery portions of the
Navigation subtree. This is a common BT pattern to handle the situation “Unless ‘this condition’ happens, Do action A”.
These condition nodes can be extremely powerful and are typically paired with
ReactiveFallback. It can be easy to imagine wrapping this whole
ReactiveFallback with a
isBatteryLow condition – meaning the
navigate_to_pose_w_replanning_and_recovery tree will execute unless the battery becomes low (and then entire a different subtree for docking to recharge).
If the goal is never updated, the behavior tree will go on to the
RoundRobin node. These are the default four system-level recoveries in the BT are:
A sequence that clears both costmaps (local, and global)
SUCCESS of any of the four children of the parent
RoundRobin, the robot will attempt to renavigate in the
If this renavigation was not successful, the next child of the
RoundRobin will be ticked.
For example, let’s say the robot is stuck and the
Navigation subtree returns
(for the sake of this example, let’s assume that the goal is never updated).
The Costmap clearing sequence in the
Recoverysubtree is attempted, and returns
SUCCESS. The robot now moves to
Let’s assume that clearing both costmaps was not sufficient, and the
FAILUREonce again. The robot now ticks the
Spinaction will be ticked. If this returns
SUCCESS, then the robot will return to the main
Navigationsubtree BUT let’s assume that the
FAILURE. In this case, the tree will remain in the
Let’s say the next action,
SUCCESS. The robot will then move on to the
FAILURE(clearing the costmaps, attempting a spin, and waiting were still not sufficient to recover the system. The robot will move onto the
Recoverysubtree and attempt the
BackUpaction. Let’s say that the robot attempts the
BackUpaction and was able to successfully complete the action. The
BackUpaction node returns
SUCCESSand so now we move on to the Navigation subtree again.
In this hypothetical scenario, let’s assume that the
BackUpaction allowed the robot to successfully navigate in the
Navigationsubtree, and the robot reaches the goal. In this case, the overall BT will still return
BackUp action was not sufficient enough to allow the robot to become un-stuck, the above logic will go on indefinitely until the
number_of_retries in the parent of the
Navigate subtree and
Recovery subtree is exceeded, or if all the system-wide recoveries in the
Recovery subtree return
FAILURE (this is unlikely, and likely points to some other system failure).