AMR deadlock occurs when robots form a circular wait: each holds a shared resource while waiting for another held by the next robot. Two stopped vehicles are not automatically deadlocked, and slow traffic is not the same condition. Diagnosis begins with ownership and dependency, not speed alone.
Prevent deadlock by modeling constrained lanes, intersections, doors, lifts, chargers and safe waiting points as resources. Reserve enough of a route to guarantee release, detect cycles in current waits and define a recovery victim, retreat target and reservation cleanup before a live incident.
Use this guide with the multi-robot allocation guide and planning and control guide. Validate traffic logic with real vehicle dimensions, braking and facility rules.
Distinguish deadlock, blockage and congestion
Congestion increases delay while work can still progress. A blockage may have one physical cause and clear when that cause moves. Deadlock is a dependency cycle with no participant able to release its held resource under current rules. The recovery and evidence differ for each condition.
Define state labels from observable events: resource held, resource requested, robot moving, progress timeout and external obstruction. Avoid inferring deadlock from a stopped timer alone because a robot may be yielding correctly or waiting for a door response.
Model the floor as shared resources and safe waits
Represent single-lane corridors, intersections, door thresholds, lift cabins, charger approaches and workcell entries as named resources with capacity. Place waiting points where the full robot and load can stop without occupying another route, doorway or protective zone.
A geometric node is not necessarily a safe waiting location. Verify footprint, turning envelope, sensing and stopping distance. Store resource identity with the map version so traffic reservations do not refer to geometry that changed after a facility update.
| Resource | Capacity question | Entry condition | Release evidence |
|---|---|---|---|
| Narrow lane | Can robots pass? | Exit path reserved | Tail clears boundary |
| Intersection | How many movements coexist? | Compatible movement set | Footprint exits conflict zone |
| Door | Can it hold safely? | Door session and clear threshold | Robot and load clear |
| Lift | Who owns the cabin? | Session, floor and capacity | Exit confirmed |
| Charger approach | Is queue off the lane? | Dock and approach available | Robot leaves approach |
Use wait-for relationships to expose cycles
Create a directed relationship from robot A to robot B when A waits for a resource currently owned by B. A cycle identifies circular waiting, but the graph must reflect current physical ownership, reservations and expirations. Old fleet messages can create a false cycle or hide a real one.
Record the resource on every edge and the timestamp of the wait. Operators need to see which reservation produced the cycle. The Open-RMF visualization repository can inform schedule visualization, but the deployed system still needs explicit resource and fault telemetry.
Reserve narrow passages through a releasable exit
Before entering a passage where robots cannot pass, reserve the corridor and a usable exit or downstream waiting space. Reserving only the current segment allows a robot to enter and then discover that the release point is occupied, turning ordinary queuing into a circular dependency.
Choose reservation granularity from geometry and throughput. Locking an entire long corridor is simple but reduces capacity; segmenting it improves concurrency but expands the state space. Validate that every permitted segment sequence retains a safe stopping and release path.
Separate charger slots from approaches and queues
A free charger does not imply that its approach is reachable, and a robot docked successfully may still block the aisle. Model the charging position, approach lane and waiting queue separately. Reserve them in an order that cannot create a cycle with passing traffic.
Integrate the auto-docking acceptance guide so station occupancy includes retries, charging confirmation and undocking time. Expire a reservation only after physical occupancy is reconciled, not because one action message timed out.
| Control mechanism | Prevents | New risk | Required test |
|---|---|---|---|
| Whole-resource lock | Opposing entry | Low throughput | Burst traffic |
| Segment reservation | Local conflict | Reservation cycle | All route combinations |
| Priority queue | Unbounded race | Starvation | Sustained urgent load |
| One-way policy | Head-on conflict | Long detour | Closure and evacuation |
| Lease timeout | Ghost ownership | Premature reuse | Communication loss |
Add aging to priorities without breaking safety
First-come order is easy to explain but can perform poorly when a high-priority task or clearing maneuver must pass. Add service class and aging so long-waiting work gradually gains priority. Keep collision and access constraints outside any priority score.
Log the effective priority, age and tie-break rule. Replay sustained urgent demand to prove that normal work does not starve. A priority change should not revoke a resource from a robot that cannot safely stop or retreat.
Reduce cycles structurally with direction and capacity
One-way aisles, turn restrictions and bounded zone capacity can remove dependency cycles from the topology. These controls often prevent more incidents than a complex online detector. They may also increase travel or create a new bottleneck at merge points.
Evaluate the facility graph before and after the rule. Test closures and disabled robots because an alternative route can reintroduce two-way pressure. Document temporary direction changes so every fleet controller shares the same topology version.
Do not ask local obstacle avoidance to solve reservations
A local controller can avoid an unexpected pallet or person within its maneuvering space. It does not know which robot owns a corridor beyond sensor range or which waiting position releases a fleet-level cycle. Local detours can violate reservations and worsen gridlock.
Define the boundary between local avoidance and traffic schedule. When a local deviation crosses a reserved boundary, require an itinerary update or stop. Compare robot pose, planned path and active reservation on one timeline during incident review.
Choose a recovery victim and verified refuge
When prevention fails, select one robot to yield using controllable criteria: ability to retreat, payload, battery, task priority, distance to refuge and impact on other traffic. The mathematically cheapest victim may be physically unable to reverse from its current pose.
Predefine refuge points and verify rear sensing, footprint clearance and command limits. Release reservations in an ordered sequence after the robot actually clears them. Never clear software ownership first and hope physical movement follows.
Combine leases with physical occupancy evidence
A lease prevents a disconnected robot from owning a resource forever, but expiry cannot prove the vehicle disappeared. After communication loss, retain a physical occupancy state from sensors, last pose and site procedures. Reuse the resource only under the declared conservative rule.
Test message delay, duplicate state, fleet-server restart and robot reboot. Reconciliation must be idempotent so the same ownership event cannot create two active leases or remove a valid reservation twice.
Inject circular waits in acceptance tests
Create head-on corridor entry, four-way intersection cycles, blocked charger approaches, lift-session loss and a disabled robot holding a lane. Measure prevention rate, detection delay, recovery time, unnecessary victim motions and reservation cleanup.
Run under traffic bursts and partial communication failure. Save resource ownership, wait graph, robot poses, commands and task state. Average throughput is insufficient when rare cycles can stop an entire area.
Make ownership more visible than map animation
An operations screen should show current resource owner, queued requesters, lease age, cycle membership, selected victim and expected release. A moving icon alone cannot explain why a stationary robot must keep waiting or whether a stopped robot still owns the intersection.
Release changes with a topology version, policy version and regression suite.
- Name every constrained resource and safe waiting point.
- Reserve a usable exit before entering non-passing space.
- Detect circular waits from current ownership evidence.
- Recover with a verified retreat and ordered release.
- Reconcile lease expiry with physical occupancy.
Frequently asked questions
Are two AMRs facing each other always deadlocked?
No. If one can yield or release a resource under the current policy, it is a conflict or delay rather than a permanent circular wait.
Should a narrow corridor always be locked as one resource?
Not always. Whole-corridor locking is simple; safe segmentation can improve throughput but requires stronger reservation validation.
Why cannot the local planner solve fleet deadlock?
It lacks fleet-wide ownership and future resource commitments and may create uncoordinated deviations.
What happens if the reservation server fails?
Use a defined degraded state, leases and physical occupancy reconciliation; do not treat server silence as a free route.
How fast must deadlock detection be?
Fast enough for the operational delay limit, but prevention and safe stopping matter more than an arbitrary shortest timer.
Traffic Coordination and Physical Safety Boundary
Fleet traffic coordination is not a safety-rated collision-prevention system. Robot safeguarding, speed limits, separation and manual recovery procedures remain application responsibilities.