Fleet Brain or Robot Brain: The Link Outage That Decides AMR Mission Planning
When Wi-Fi drops in a rack aisle, a centrally orchestrated AMR drives only as far as its last released node, then stops and waits. An agentic robot with its own mission planner and behavior tree keeps working, but on a world model the fleet can no longer see. Both are legitimate ways to survive a failed link. Which one is right depends on a single measurable boundary: how long your links actually stay down compared with how far ahead the fleet releases the path.
Two different ways to fail safely
In the central option, the fleet manager owns mission decomposition and traffic deconfliction, and it streams VDA 5050 orders in which only the base, the released nodes and edges, may be driven, while the horizon is advisory. The robot runs Nav2 for local navigation and a thin behavior tree that does little more than execute actions and report state. If the link fails, the robot finishes its base and halts. That is a fail-stop design, and its strength is that the server stays the only authority over shared floor space, so traffic state can never diverge. In the edge option, the robot holds the mission goal itself, and a BehaviorTree.CPP tree encodes the recovery logic locally: fallback nodes for replanning around a blocked aisle, retry policies for a failed pick, alternate drop locations. That is a fail-operational design, and it moves the hard problem from the network to the arbitration of shared resources.
Where the decision flips
The parameter that matters is the base horizon expressed in travel time, meaning the number of seconds a robot can keep moving on released nodes with no new order. Many sites tune this to around 20 s. Take the p95 link outage on the real floor and set it against that figure. When outages are shorter, the robot never notices them, and central orchestration wins outright, because it keeps one global source of truth for traffic at no extra cost. When outages are longer, robots begin to stall at node boundaries, the stalled robots block the aisles behind them, and the whole fleet recovers in a wave once the access point comes back, which costs far more throughput than the outage itself. Handover gaps of 5 to 15 s are common in dense steel racking (an estimate, and very site-dependent), so this boundary tends to fall exactly where real warehouses sit. Extending the base horizon does not escape the trade-off, because every released node is floor space reserved for one robot, and long reservations eat the capacity at intersections that central traffic control exists to protect.
What breaks on the edge side
The edge option's typical failure is split-brain at a shared resource. A robot that cannot reach the server replans around an obstruction and moves into a corridor that the server, still connected to everyone else, has already granted to another robot. The safety-rated scanners required by industrial mobile robot safety standards such as ISO 3691-4 keep both robots from colliding, but the two end up face to face in a deadlock with no authority to resolve it, and a human has to walk out and clear it. The fix is a lease mechanism. The server grants zones with an expiry time, the behavior tree checks lease validity as a condition node before any replanned segment, and an expired lease drops the robot back into the same fail-stop behaviour the central design would have shown. The robot's autonomy is bounded by what it was granted before the link went down, and that bound is the part of the design you have to get right.
The rule to freeze
Measure p95 link outage on the real floor during a peak shift. If it exceeds the travel time of your released base, put mission replanning on the robot behind expiring zone leases, and if it does not, keep the planner central and spend the budget on wireless coverage, bearing in mind that the leased design makes every expiry and reconnection path a test case your team now has to own.
Technical FAQ: Can we keep central orchestration and just add an onboard behavior tree as a safety net?
Only if that tree is forbidden from taking floor space the server has not leased to it, and with that restriction in place you have built the edge option. The real cost is keeping two planners consistent, because the onboard fallback logic and the server's traffic model have to agree on what a robot is allowed to do when it goes silent, and that agreement has to be versioned and tested together.