Suppose you give ARCHO a mission: "Go to shelf number 12." Now, along the way, any of these could happen:
If ARCHO's logic is just a simple linear program:
In a linear program, the first unexpected event stops the entire program. If you write Move → Pick →
Return and the first step fails, the whole chain collapses. But in the real world, an industrial
robot needs to be able to make decisions — not just execute.
ROS 2's solution to this problem is a structure called a Behavior Tree.
A Behavior Tree is a tree-shaped decision-making structure that lets a robot choose the best behavior based on the environment's momentary conditions — instead of blindly executing a fixed chain of commands.
When you leave the house in the morning, this happens in your mind: "Is it raining? If yes, take an umbrella; if not, go without one." This is exactly a Behavior Tree — a condition, and depending on its result, a different action.
Because decisions branch, a tree structure makes sense:
Almost every real Behavior Tree is built from a combination of these three node types:
| Node Type | Function | Example |
|---|---|---|
| Condition | Only asks a question; the output is only Success or Failure | Battery OK? Goal Reached? |
| Action | Performs a real task | Compute Path, Follow Path, Rotate, Clear Costmap |
| Control | Decides which branch executes — the most important part of a BT | Sequence, Fallback, Parallel |
All steps must succeed one after another; if one fails, the rest never execute.
If the first option fails, the next one is tried.
Runs several tasks at once — ARCHO doesn't just move, it simultaneously monitors battery, LiDAR, and the goal.
At any given moment, every node returns one of these three states:
| Status | Meaning |
|---|---|
Success | The task was completed successfully |
Failure | The task was not completed |
Running | Still in progress — for example, ARCHO is still moving |
A Behavior Tree doesn't run just once; it's checked repeatedly and continuously (for example, 20 times per second) from the root. Each check is called a Tick. On every Tick, the same questions are asked again: Has the goal changed? Is there a new obstacle? Is the battery low? Is the path still valid?
If you tried to write all these conditions with if battery, if obstacle, if
planner, if recovery, if localization, if timeout, and
if sensor, the code would very quickly turn into unmaintainable chaos. A Behavior Tree
organizes this same complexity into a visual, extensible structure.
Simplified version:
But the real version that Nav2 executes has a more complete shape:
If the Global Planner can't find a path, the BT tries a recovery chain instead of collapsing:
If the Planner had previously found a path through an aisle, but that aisle is now blocked, the Behavior Tree decides on its own that the Planner should run again and compute a new path — without a single new line of code being written.
If ARCHO's battery drops to 8%, the BT can decide — without the programmer writing hundreds of
if conditions — to cancel the mission and head to the charging station.
The mission "go to shelf 12," in BT form, looks something like this: Battery OK? → Localization OK? → Compute Path → Follow Path → Goal Reached? → Recovery. If a worker crosses the path midway, the Planner recomputes the route and ARCHO continues; if that doesn't work either, Recovery kicks in — it backs up a bit, tries again, or ultimately cancels the mission.
Suppose you turn ARCHO on. Does it make sense for the LiDAR to start working immediately, the Planner to run, the Controller to issue commands, and the motors to move — without any guarantee that everything is healthy? Absolutely not.
A pilot doesn't just hit the power button and take off. First the engine, fuel, hydraulic system, and instruments are checked, and only then is takeoff cleared. ROS 2 implements exactly this same logic for critical nodes.
In ROS 1, nodes usually only had two states: Start and Running. If something went
wrong, it was hard to manage because there was no controlled intermediate state. ROS 2 solved this with the
Lifecycle Node.
A Lifecycle Node is a node with well-defined states that only becomes fully active once all the necessary conditions are met — not the instant it's powered on.
Note: in addition to these four main states (Unconfigured, Inactive, Active, Finalized), each transition between them (like Configure or Activate) actually passes through a temporary Transition State; these transition states are not shown in the simplified diagram above.
| State | Meaning | LiDAR Driver Example |
|---|---|---|
| Unconfigured | The node exists, but isn't ready to work yet | The serial port hasn't been opened yet |
| Inactive | The node is ready but isn't doing anything yet | The LiDAR is ready but isn't publishing data yet |
| Active | The node is actually working — publishing topics, responding to services | LaserScan is published on /scan |
| Finalized | The node has been fully and irreversibly shut down — reachable from all three other states | Complete system shutdown |
Suppose the Planner is ready but Localization isn't ready yet. If the Planner became active right now, it would receive incorrect position data and generate wrong paths. The Inactive state lets the Planner stay "ready but quiet" until it's actually its turn.
If the Controller becomes active before Localization, ARCHO could move based on incorrect position data — which, in a warehouse full of shelves and workers, is dangerous. The Lifecycle mechanism controls exactly this order: LiDAR → TF → Localization → Costmap → Planner → Controller.
In Navigation2, there's a central node called the Lifecycle Manager that acts like a project manager: it coordinates Configure → Activate → Monitor → Shutdown for all the critical nodes.
The night shift starts at a factory. ARCHO powers on; the Lifecycle Manager checks that the LiDAR, IMU, and encoders are healthy. AMCL becomes active and localizes the robot. The Planner and Controller become active and ARCHO starts working. Midway through the shift, the LiDAR temporarily goes offline — the Lifecycle Manager immediately moves the Planner and Controller to Inactive so ARCHO doesn't make a dangerous move. Once the LiDAR is healthy again, the nodes are reactivated in the same logical order. This behavior keeps the system predictable and safe.
The Behavior Tree decides what to do right now. Lifecycle decides which node is even allowed to run. One is the brain of moment-to-moment decision-making; the other is the safety framework for startup and shutdown.
Now the complete architecture of Navigation2 is clear to you: Localization, Map, Costmap, Global Planner, and Local Controller (Chapter 11), together with the Behavior Tree that coordinates all of these, and Lifecycle Nodes that guarantee each component only becomes active when it's truly ready. Together, these six pieces let ARCHO cope in a real environment — with moving obstacles, route changes, sensor errors, and unexpected conditions.
ARCHO Project now has a complete Nav2 architecture: a BT Navigator that coordinates moment-to-moment decision-making, and a Lifecycle Manager that controls the safe startup order and recovery of all critical nodes.
In Chapter Thirteen we move on to MoveIt 2 — if ARCHO also has a robotic arm, this is where we learn how that arm plans its own motion.