AMR 僵局發生在機器人形成迴圈等待時：每個機器人持有共享資源，等待下一個機器人持有的另一個資源。兩輛停車的車輛不會自動陷入僵局，緩慢的交通也不是同一情況。診斷從所有權和依賴開始，而不僅僅是速度。
透過建模受限車道、交叉口、門、電梯、充電樁及安全等待點作為資源，防止僵局。預留足夠路線保證釋放，檢測目前等待週期，並在現場事件發生前確定恢復時需要讓路的機器人、撤退目標和預約清理。
本指南應與 多機器人分配指南 及 規劃與控制指南一起使用。驗證真實車輛尺寸、制動和設施規則的交通邏輯。
區分死鎖、阻塞和擁堵
擁堵會延長工作進展的延遲。堵塞可能只有一個物理原因，當該原因移動時就明確了。僵局是一種依賴迴圈，根據現行規則，參與者無法釋放其持有的資源。每種情況的恢復和證據都不同。
根據可觀察事件定義狀態標籤：資源持有、請求資源、機器人移動、進度超時和外部障礙。避免僅憑停止計時器推斷死鎖，因為機器人可能正確讓路或等待門反應。
將樓層建模為共享資源和安全等待
將單車道走廊、交叉口、門檻、升降艙、充電通道和工作單元入口作為具容量的命名資源表示。設定等待點，使整台機器人和貨物能夠停靠，而無需佔用其他路線、門口或保護區。
幾何節點不一定是安全的等待地點。驗證佔地面積、轉彎包絡、感應和停止距離。將資源身份儲存在地圖版本中，以確保交通預留不涉及設施更新後發生變化的幾何形狀。
| 資源 | 容量問題 | 進入條件 | 釋出驗證資料 |
|---|---|---|---|
| 狹窄巷道 | 機器人能透過嗎？ | 出口通道預留 | 尾巴越過邊界 |
| 交匯點 | 有多少樂章共存？ | 相容機芯套裝 | 足跡離開衝突區 |
| 門 | 它能安全承受嗎？ | 門會話與清閾 | 機器人和貨物清空 |
| 電梯 | 這間小屋是誰的？ | 會議、場地及容量 | 出口確認 |
| 充電器方法 | 排隊是在車道上嗎？ | 可靠泊並接近 | 機器人離開接近 |
利用等待關係來揭示迴圈
當 A 等待 B 目前擁有的資源時，建立一個從機器人 A 到機器人 B 的定向關係。迴圈表示迴圈等待，但圖表必須反映目前的物理所有權、預留和到期情況。舊的車隊訊息可能製造虛假週期或隱藏真實週期。
記錄每條邊的資源和等待時間戳。操作員需要檢視是哪個預訂產生了該週期。 Open-RMF 視覺化庫 可以為計劃視覺化提供資訊，但部署的系統仍需顯式的資源和故障遙測。
保留透過可釋放出口的狹窄通道
在進入機器人無法透過的通道前，預留走廊及可用的出口或下游等待空間。僅保留目前段允許機器人進入後發現釋放點已被佔用，使普通排隊變成迴圈依賴。
從幾何和吞吐量中選擇保留粒度。鎖定整個長走廊很簡單，但會減少容量；分段可以提升併發性，但會擴充狀態空間。驗證每個允許的段序列都保留安全的停止和釋放路徑。
將充電槽與進近通道和排隊區分開
免費充電樁並不意味著其接近點可達，成功停靠的機器人仍可能阻塞通道。分別模擬充電位置、進場車道和等待佇列。按不會因過路交通而形成迴圈的順序預訂。
整合 自動對接接受指南，使空間站佔用包括重試、計費確認和脫離時間。只有在實際佔用對帳後才取消預訂，而不是因為某個操作資訊超時。
| 控制機制 | 防止 | 新風險 | 必需測試 |
|---|---|---|---|
| 全資源鎖 | 對方參賽隊 | 低通量 | 突發流量 |
| 路段預留 | 地方衝突 | 預訂週期 | 所有線路組合 |
| 優先佇列 | 無界競速 | 飢餓 | 持續緊急負荷 |
| 單向策略 | 正面衝突 | 長途繞行 | 路段封閉與疏散 |
| 租約超時 | 鬼魂所有權 | 過早重複使用 | 通訊中斷 |
在不破壞安全的情況下，將老化納入優先考慮
先到順序易於解釋，但當必須透過高優先順序任務或清除操作時，表現可能不佳。增加服務等級和老化，使等待時間較長的工作逐漸獲得優先順序。將碰撞和存取約束排除在任何優先順序評分之外。
記錄有效優先順序、年齡和平局規則。重放持續的緊急需求，以證明正常工作不會被餓死。優先順序變更不應剝奪無法安全停止或撤退的機器人的資源。
透過方向和容量結構性地減少迴圈
單向通道、轉彎限制和限制區容量可以消除拓撲中的依賴迴圈。這些控制通常能防止比複雜的線上檢測器更多的事故發生。它們也可能增加行駛距離，或在合併點製造新的瓶頸。
在規則實施前後評估設施圖。測試關閉和禁用機器人，因為替代路線可能重新引入雙向壓力。記錄臨時方向變化，使每個車隊控制器共享相同的拓撲版本。
不要讓本地障礙物避讓來解決預訂
本地管制員可以避開其機動空間內意外的托盤或人員。它不知道哪個機器人擁有感測器範圍之外的走廊，也不知道哪個等待位置會觸發機器人車隊級迴圈。本地繞行可能違反預訂，加劇交通堵塞。
定義本地避讓與交通時刻表的界限。當本地偏離越過預留邊界時，需更新行程或停靠。在事故審查時，在同一時間線上比較機器人姿勢、規劃路徑和活躍預訂。
選擇康復受害者和已驗證的避難所
當預防失敗時，選擇一台機器人，使用可控條件讓路：後退能力、有效負載、電池、任務優先順序、避難距離及對其他交通的影響。數學上最便宜的受害者可能無法從目前姿勢倒車。
預先定義避難點，並驗證後方感應、足跡間隙和指令限制。機器人實際清理後，按順序釋放預訂。切勿先確認軟體所有權，然後指望實際移動。
將租賃合約與實際居住證據結合
租賃條款防止斷開的機器人永久擁有資源，但到期不能證明車輛消失。通訊中斷後，保持感測器、最後姿勢和站點程式的物理佔有狀態。資源僅在宣告的保守規則下重複使用。
測試訊息延遲、重複狀態、車隊伺服器重啟和機器人重啟。對帳必須是冪等的，這樣同一所有權事件不能建立兩個活躍租約或重複移除有效預訂。
在驗收測試中注入迴圈等待
建立正面走廊入口、四路交叉迴圈、封堵充電器通道、電梯時段丟失以及殘疾機器人佔用車道。測量預防率、檢測延遲、恢復時間、不必要的受害者移動和預留清理。
在流量突發和部分通訊失敗情況下執行。儲存資源所有權、等待圖、機器人姿態、命令和任務狀態。當罕見週期能停止整個區域時，平均吞吐量不足。
讓所有權比地圖動畫更顯眼
操作介面應顯示目前資源所有者、排隊請求者、租賃年齡、等待環路成員和選定的讓路機器人和預計釋放。僅靠移動圖示無法解釋為何靜止機器人必須等待，或停車機器人是否仍擁有該路口。
釋出包含拓撲版本、策略版本和迴歸套件的變更。
評估“AMR 交通死鎖預防與恢復”時，還應儲存模型版本、機器人設定、校正檔案、測試日期和全部試驗記錄。
只有把這些持續投入與單位成功任務的價值比較，才能判斷方案是否適合擴大。
上線後仍要持續檢查分佈變化、感測器漂移、機械磨損和人工接管原因。
實際專案還應指定資料、模型、控制器和安全流程的負責人，並預先定義回復條件。責任邊界、審批記錄與變更紀錄越清楚，故障發生後越容易停止擴散、定位原因並安全恢復。
- 說出所有受限資源和安全等待點。
- 進入非超車區前，預留一個可用的出口。
- 從目前所有權證據中檢測迴圈等待。
- 透過驗證撤退和命令釋放恢復。
- 將租約到期與實際居住時間進行對帳。
常見問題
兩個 AMR 面對面是否總是死鎖？
不是。如果根據現行策略可以讓出或釋放資源，那是衝突或延遲，而不是永久迴圈等待。
狹窄的走廊是否應該總是作為一個資源被鎖定？
並非總是如此。整走廊鎖定很簡單；安全的分段可以提高吞吐量，但需要更強的預留驗證。
為什麼本地策劃者不能解決機器人車隊僵局？
它缺乏全機器人車隊的所有權和未來資源承諾，可能導致無序的偏差。
如果預訂伺服器故障會發生什麼？
使用明確的降級狀態、租賃合約和實際佔用權的對帳；不要把伺服器靜音當作免費的途徑。
死鎖檢測必須有多快？
速度足夠快，符合操作延遲限制，但預防和安全停止比任意的最短計時器更重要。
交通協調與物理安全邊界
車隊交通協調並非安全級的碰撞預防系統。機器人保護、限速、隔離和人工恢復流程仍是應用職責。