Every AMR path planner makes this decision thousands of times per shift: when something blocks the planned route, does the robot try a new path or does it stop and wait? The question sounds simple. The answer, in practice, depends on a set of variables that most path planners either don't model at all or handle with a single configurable timeout threshold.
We've spent a lot of time on this decision boundary. Here's how we think about it, what tradeoffs matter, and where the naive approaches fail.
The False Dichotomy of "Reroute vs. Wait"
The framing of "dynamic rerouting versus static path fallback" implies two discrete strategies. In reality, there's a spectrum, and most real environments need at least three distinct behaviors rather than two:
- Immediate reroute: Abandon the current path, invoke the global planner, execute a new route. High computational cost, high latency (global replanning in Nav2 with a 20×20m costmap typically takes 80–350ms), but gets the robot moving again quickly if an alternative exists.
- Short hold and re-evaluate: Stop in place, wait a configurable interval (2–8 seconds), re-check whether the obstacle has moved, then either proceed on the original path or escalate to reroute. Works well for transient obstacles — a person who stepped into the aisle, a cart being pushed through.
- Static fallback / request assistance: Stop, mark the task as blocked, notify the fleet coordinator. No local replanning attempt. Appropriate when the robot has determined the path is durably blocked and no known alternative exists within acceptable cost.
The problem with having only behaviors 1 and 3 — which is what a lot of off-the-shelf configurations provide — is that behavior 2 handles a large proportion of real warehouse blocking events cheaply. Jumping straight to global replanning for every transient obstacle wastes planning cycles and, in a dense fleet, can cause cascading reroutes when multiple robots simultaneously attempt to re-plan around the same moving obstacle.
When Dynamic Rerouting Helps vs. Hurts
Dynamic rerouting is worth its cost when:
- An alternative path exists with acceptable additional distance (typically ≤30% longer than nominal)
- The blocking obstacle is durable — a parked forklift, a staging pallet that isn't moving
- The robot's pick-slot timing window has enough margin to absorb the reroute latency
- Aisle density is low enough that the alternative path isn't itself congested
Dynamic rerouting hurts — and this is the case teams underestimate — when the facility layout creates a reroute funnel. A reroute funnel is a geometry where most alternative paths from any given blocked position converge through a small number of chokepoints: a cross-aisle intersection, a dock door corridor, a charging station approach zone. When one robot reroutes through the funnel, it often creates a secondary block that triggers reroutes from other robots, which then also converge on the funnel. We've observed this pattern in facilities with deep narrow pick aisles and limited cross-aisle connectivity — think a traditional selective rack layout with aisles 50+ meters deep and only two or three cross-aisle cut-throughs per zone.
In those geometries, aggressive rerouting can actually reduce fleet throughput compared to more conservative hold-and-wait behavior, because the reroute cost is distributed across the whole fleet, not just the robot that encountered the original block.
Modeling the Decision as a Cost Function
The cleaner engineering approach is to frame the reroute-vs-wait decision as a cost comparison rather than a rule lookup. The robot should reroute if and only if:
cost(reroute) < cost(wait_for_clearance)Where each cost term includes:
- cost(reroute): planning latency + additional travel distance + probability of secondary blockage on the alternative path + impact on pick-slot timing window
- cost(wait_for_clearance): expected wait duration × time-value-of-hold + probability that the obstacle doesn't clear within the wait budget
The tricky term is expected wait duration. You can estimate this using obstacle classification: a LiDAR-detected person who is stationary has a very different expected clearance time distribution than a LiDAR-detected forklift that has been stationary for 45 seconds. Our classification pipeline publishes an obstacle persistence score alongside the standard classification label — a value in [0,1] representing the probability that the obstacle will remain present for longer than 30 seconds. High-persistence obstacles (score > 0.7) trigger the cost comparison immediately; low-persistence obstacles (score < 0.35) default to the short-hold behavior first.
This isn't a complete dynamic programming solution — the cost terms involve estimates with substantial uncertainty. But even rough cost comparison outperforms hard-coded timeout thresholds because it incorporates the timing window state, which changes throughout the shift.
Fleet-Level Rerouting Coordination
One failure mode that's hard to detect from a single-robot perspective: reroute storms. When multiple robots in a zone simultaneously detect the same obstacle and simultaneously invoke global replanning, several problems emerge in sequence:
- All rerouted paths attempt to use the same alternative corridors, creating secondary congestion
- The planning load on the central costmap server (if using a shared costmap) spikes, increasing planning latency for all robots
- Robots that had already committed to the alternative corridor get blocked by robots that arrived there via reroute
The fix requires coordination at the fleet level, not just local decision-making. In our event-sharing model (described in an earlier post on fleet coordination), robots broadcast their current reroute intent before executing replanning. A robot that receives a reroute-intent event for the same obstacle from a peer robot within 3 seconds of its own detection will typically hold instead of also rerouting, letting the first robot's replanned path execute and observing whether it succeeds.
This simple coordination rule — one robot reroutes, others hold and observe — cuts reroute storm frequency by a significant margin in our test environments. It's implemented as a short-lived ROS 2 topic event: /mvnt/fleet/reroute_intent with a message schema carrying obstacle_id, originating_robot_id, and intent_timestamp. Robots subscribe to this topic through the same lightweight event bus used for fleet coordination, with no centralized coordinator required.
Static Fallback Isn't Failure
One thing we want to be clear about: static path fallback — stopping and requesting assistance — is not a failure mode to be minimized at all costs. It's the right behavior when the robot genuinely cannot determine a safe alternative path, when the aisle is durably blocked by something that won't move without human intervention (a broken-down vehicle, a pallet jack blocking an entire cross-aisle), or when the pick-slot window has already closed and proceeding would cause downstream sequencing problems.
We're not saying aggressive rerouting is always wrong — in open-format facility layouts with multiple route alternatives and generous pick windows, it's often the right call. We're saying that over-relying on dynamic rerouting as the primary obstacle response strategy, without modeling the fleet-level cost and the timing-window context, produces deployments that look fast on individual robot metrics but underperform on actual shift throughput.
The useful question isn't "did the robot reroute or stop?" It's "did that robot's response to the obstacle minimize total fleet throughput cost?" That framing leads to different tuning decisions, and usually to more nuanced hold policies — not faster rerouting.
