Behavior tree

Behavior tree – definition

A behavior tree (BT) is a hierarchical control model used to select, sequence, monitor, and recover robot behaviors at runtime. In mobile robotics, it is commonly used as the decision-making layer above low-level motion control, localization, perception, and sensor drivers.

A behavior tree represents a mission as a tree of nodes. Internal nodes define control flow. Leaf nodes execute an action or evaluate a condition. The tree is evaluated repeatedly through a process called ticking. Each node commonly returns one of three standard states: SUCCESS, FAILURE, or RUNNING.

For an unmanned ground vehicle (UGV), a behavior tree can express tasks such as navigating to a waypoint, waiting for a sensor condition, checking localization quality, clearing a navigation costmap, returning to a charging point, or stopping when communication is lost. It does not replace SLAM, path planning, obstacle avoidance, or motor control. Instead, it coordinates these subsystems and defines what happens when one of them fails.

Behavior trees are widely used in ROS 2 navigation systems, particularly in the Navigation 2 (Nav2) framework. Nav2 uses the BehaviorTree.CPP library to execute navigation logic represented in XML files. The standard Nav2 navigation workflow combines planning, control, recovery actions, and condition checks in a configurable tree.

Core node types

A behavior tree is composed of control nodes, decorator nodes, condition nodes, and action nodes. The exact node set depends on the framework, but the execution model remains consistent: parent nodes tick child nodes and use their returned state to decide what to execute next.

Node type	Function	Typical UGV example
Sequence	Ticks children in order. It succeeds only when all children succeed.	Check localization, compute a path, then follow the path.
Fallback / Selector	Tries children in order until one succeeds or remains running.	Use GNSS navigation if RTK is valid; otherwise use local SLAM localization.
Parallel	Ticks multiple children according to a configured success and failure policy.	Navigate while monitoring battery voltage and an emergency-stop topic.
Decorator	Modifies the behavior or returned status of one child node.	Retry path planning a defined number of times before starting recovery.
Condition	Evaluates a Boolean state without performing a long-running operation.	Check whether a map is available or a waypoint has been reached.
Action	Starts or monitors an operation that can return `RUNNING`.	Send a ROS 2 navigation goal, rotate in place, or clear a costmap.

Behavior trees in ROS 2 and Nav2

ROS 2 does not define behavior trees through a ROS Enhancement Proposal (REP). Behavior trees are an application-level architecture. In ROS 2 mobile robotics, their most common implementation is Nav2 with BehaviorTree.CPP. Nav2 provides BT navigator servers that accept navigation goals through ROS 2 actions and execute an XML-defined tree.

The standard ROS 2 action interface for point-to-point navigation in Nav2 is nav2_msgs/action/NavigateToPose. Its goal contains a target pose, typically expressed as geometry_msgs/msg/PoseStamped. A behavior tree can invoke planning and control nodes that use this goal, monitor their progress, and switch to recovery behavior when an operation returns FAILURE.

Typical Nav2-related ROS 2 interfaces include:

/navigate_to_pose – action server using nav2_msgs/action/NavigateToPose.
/cmd_vel – velocity command topic, commonly using geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped, depending on the configured stack.
/tf and /tf_static – coordinate transforms used to relate map, odom, base_link, and sensor frames.
/plan or planner-specific interfaces – paths commonly represented by nav_msgs/msg/Path.
Costmap services – interfaces used by recovery nodes to clear local or global obstacle data.

Nav2 trees are normally stored as XML. The following example shows the control structure of a simple navigation behavior. It is schematic and requires matching Nav2 plugins, blackboard ports, frames, and costmap configuration before deployment.

<root main_tree_to_execute="MainTree">
  <BehaviorTree ID="MainTree">
    <RecoveryNode number_of_retries="2" name="NavigateWithRecovery">
      <PipelineSequence>
        <ComputePathToPose goal="{goal}" path="{path}"/>
        <FollowPath path="{path}"/>
      </PipelineSequence>
      <Sequence>
        <ClearEntireCostmap service_name="global_costmap/clear_entirely_global_costmap"/>
        <ClearEntireCostmap service_name="local_costmap/clear_entirely_local_costmap"/>
      </Sequence>
    </RecoveryNode>
  </BehaviorTree>
</root>

In this structure, a planning or path-following failure triggers costmap clearing. The recovery node then retries the navigation subtree. More advanced trees can add spin recovery, backup maneuvers, operator approval, localization checks, or mission abort logic.

Tick rate, latency, and execution semantics

A behavior tree must be ticked frequently enough to react to changes in robot state, but it should not block sensor processing, control loops, or ROS 2 executor threads. A BT tick is not equivalent to a motor-control update. Low-level velocity control may run at a higher rate than the decision layer.

The important engineering parameters are determined by the configured ROS 2 nodes and the platform workload:

Tick period: the interval between tree evaluations. It defines how quickly the decision layer can observe changed conditions.
Action timeout: where configured, the maximum allowed duration for planning, control, recovery, or external service calls.
Retry count: the permitted number of recovery attempts before a mission is reported as failed.
Feedback latency: delay between a navigation controller, localization source, sensor pipeline, and the BT condition that consumes the result.
Blackboard data validity: whether values such as goals, paths, battery status, or localization state are current and frame-consistent.

Long-running actions should return RUNNING while they are active. Blocking an action node until a navigation goal completes can prevent the rest of the tree from checking safety conditions, cancellation requests, or new mission commands.

Use on Leo Rover and Raph Rover

On Leo Rover, behavior trees are useful when integrating autonomous navigation on top of its ROS 2 software environment. Leo Rover has a four-wheel differential-drive chassis, so the navigation stack normally produces linear and angular velocity commands that are converted to the rover drivetrain interface. Autonomous operation requires integration of localization, mapping or an existing map, obstacle sensing, transforms, and a navigation stack. It is not provided as an out-of-the-box capability.

A Leo Rover behavior tree can coordinate a LiDAR-based navigation stack with wheel odometry, IMU data, and optional depth-camera or GNSS inputs. For example, the tree can reject a navigation attempt when the map → odom transform is unavailable, request replanning when an obstacle blocks the current path, and stop the mission when battery or communication conditions fail.

Raph Rover can use the same ROS 2 and Nav2 behavior-tree architecture when a project requires a larger payload capacity. This is relevant for field sensor packages such as multi-camera rigs, LiDAR units, RTK GNSS receivers, or onboard compute hardware. The BT should remain platform-aware: recovery actions such as reversing, rotating, or traversing narrow areas must be constrained by the rover dimensions, payload, terrain, and local safety requirements.

Limitations and integration requirements

A behavior tree improves mission structure and failure handling, but it cannot compensate for unreliable state estimation, incomplete transforms, poor costmap configuration, or insufficient compute resources. A condition node that checks localization quality is only as reliable as the localization metric it receives.

For ROS 2 UGV deployments, validate the following before relying on a behavior tree in autonomous operation:

All required TF transforms are available and use consistent timestamps.
Navigation actions can be cancelled safely and the mobile base is brought to a safe stop.
Recovery actions are appropriate for the terrain, wheel slip conditions, and obstacle-clearance limits.
Sensor failures, stale messages, and localization loss are represented as explicit conditions.
The tree XML, Nav2 parameters, and custom BT plugins are version-controlled and tested in simulation before field deployment.

Technical references

Behavior-tree semantics are implemented differently by individual libraries, so the exact node behavior must be verified against the selected software version. For ROS 2 mobile navigation, the primary technical references are the Nav2 documentation, the BehaviorTree.CPP documentation, and ROS 2 interface definitions.

Nav2 Documentation – behavior tree navigator, navigation actions, recovery behavior, and configuration.
BehaviorTree.CPP Documentation – node statuses, ticking model, XML format, ports, and blackboards.
ROS 2 Documentation – ROS 2 actions, topics, services, parameters, TF2, and lifecycle nodes.
Leo Rover Technical Documentation – platform-specific ROS 2 integration and hardware documentation.