BehaviorTree.CPP

BehaviorTree.CPP is a C++ behavior tree framework used to model robot decision logic as modular trees instead of hard-coded state machines. The project is centered on runtime XML tree definitions, asynchronous actions, plugin-loaded nodes, and logging tools that make robot behaviors easier to inspect and iterate on.

What it does

The library provides the execution engine for behavior trees, plus the dataflow, blackboard, and node abstractions needed to build reactive robot applications. In practice, teams use it to centralize task planning in a coordinator node while keeping lower-level motion, sensing, and service components separate. The project also ships ROS 2 integration wrappers and works with Groot/Groot2 for editing, live monitoring, and log replay.

How teams use it

BehaviorTree.CPP is most visible in ROS 2 robotics stacks, where it is used to express navigation, recovery, and mission logic with reusable XML trees and custom nodes. Nav2 documents a Groot-based workflow for loading BT.CPP palettes and editing navigation trees, which makes the library relevant for AMRs and other mobile robotics projects. Outside robotics, the maintainers also position it as an alternative to finite state machines for game AI and other C++ applications that need reactive control flow.

Deployment and ecosystem

The main library is self-hosted software rather than a hosted service. The maintainers document builds through colcon for ROS 2 users, plus Conan, plain CMake, pixi, and vcpkg for other C++ environments. The surrounding ecosystem includes BehaviorTree.ROS2 wrappers for rclcpp_action and service clients, and the separate Groot2 IDE for visual editing, monitoring, and replay.

Limitations

• BehaviorTree.CPP is a library, not a complete robot application platform, so teams still need their own motion, perception, and hardware integration layers around it.
• The core workflow assumes C++17 tooling and build-system comfort, which raises the entry cost compared with low-code robot orchestration tools.
• ROS 2 integrations are well documented, but non-ROS industrial integration patterns are less turnkey and usually require custom adapter nodes.
• Some of the richer debugging workflow depends on companion tools such as Groot2, and advanced features there are partly commercial rather than fully bundled with the OSS library.