度:從路口資源管理到穩(wěn)定通行)
機器人移動導(dǎo)航發(fā)展到今天直線行走、避障、原地旋轉(zhuǎn)這些基本功已經(jīng)比較成熟。真正讓項目調(diào)試時間拉升一個量級的往往是廠區(qū)里的交叉口兩輛 AGV 同時靠近轉(zhuǎn)彎車輛擋住直行機器人互相停在路口后方任務(wù)全部連鎖延誤。標(biāo)題里“機器人過交叉口穩(wěn)如老手”指的并不是靠單個機器人感知逆行檢測繞過所有障礙而是整套調(diào)度系統(tǒng)能讓機器人在進(jìn)入路口前做有序讓行、平穩(wěn)減速、安全通過。這篇文章直接用一套可落地的交叉口資源管理模型把一張工廠地圖里的路線、區(qū)域、資源占用、通行權(quán)限和機器人狀態(tài)機串起來方便做無人叉車、倉儲 AMR、車間配送機器人應(yīng)用的開發(fā)者對照實現(xiàn)。倉庫和工廠里的機器人路線一旦出現(xiàn)交匯故障就不再是“哪臺機器人撞了墻”而是變成兩臺車在同一個空間里搶時間。只靠車載激光雷達(dá)做局部避障無法解決全局交通秩序只靠中央調(diào)度排任務(wù)又沒法處理緊貼車身的物理遮擋和環(huán)境噪聲。工程上需要從地圖建模、路口資源分配、通行協(xié)議、異常釋放、速度規(guī)劃幾個層面共同處理。1. 為什么交叉口會成為移動機器人天然的瓶頸地帶1.1 交叉口在導(dǎo)航問題里的本質(zhì)是空間資源競爭如果把工廠地面看成一張拓?fù)鋱D直線巷道是邊交叉口就是節(jié)點。單臺機器人從一個工位走到另一個工位本質(zhì)是沿著有向邊執(zhí)行路徑規(guī)劃。多臺機器人同時在線后交叉口就不是一臺車的路徑點而是多臺車都想在某一時間段內(nèi)使用的公共空間資源。公共空間資源有兩個明顯特征。第一空間面積通常不大但多條運動方向在這里重疊車體旋轉(zhuǎn)、轉(zhuǎn)彎、避讓都需要占用額外包絡(luò)。第二機器人從不同巷道接近交叉口時彼此的傳感器視野往往被貨架、立柱、卷簾門和其他設(shè)備遮擋等看到對方車身時剩余制動距離可能已經(jīng)不夠。所以交叉口不能只靠“感知-避障”閉環(huán)處理必須把“誰先通過”的時間窗在進(jìn)入路口前就確定下來。1.2 局部避障解決不了交叉口遮擋問題很多開發(fā)者的第一反應(yīng)是給機器人加更多雷達(dá)和攝像頭。硬件增加確實能提高檢測率但解決不了兩個工程問題。一是檢測范圍存在連續(xù)盲區(qū)。交叉口兩側(cè)通常是貨架或墻體機器人只有前進(jìn)到接近路口邊緣時側(cè)向傳感器才能看到另一條巷道里的車。如果對方車速較快從“發(fā)現(xiàn)”到“剎?!钡木嚯x可能不足急停又會造成貨物移位和定位丟失。二是單臺車的“禮讓”行為不具備全局一致性。A 車讓了 B 車B 車可能又讓 C 車最終形成死鎖。要讓多車在復(fù)雜巷道里穩(wěn)定流動必須有一個不依賴單臺車局部判斷的通行決策層。1.3 全局交通規(guī)則需要和車輛執(zhí)行能力匹配中央調(diào)度系統(tǒng)負(fù)責(zé)決策但實際踩剎車、打方向盤、降低速度的還是機器人底盤。好的路口通行策略應(yīng)該讓機器人很早就收到信息而不是等到了路口邊緣才收到緊急停車指令。要做到“穩(wěn)”時間維度上必須提前觸發(fā)減速空間維度上必須保留安全包絡(luò)權(quán)限維度上必須明確誰擁有當(dāng)前路口的通行權(quán)??梢园堰@套機制理解成路口預(yù)約機器人還沒到交叉口前先向調(diào)度中心申請一段時空窗口調(diào)度中心根據(jù)當(dāng)前占用情況回復(fù)“允許進(jìn)入”“等待”或“改道”。機器人只在拿到允許信號后才進(jìn)入路口并且按固定速度完成穿越。這樣就把多車競爭轉(zhuǎn)化為一串帶時間順序的資源授權(quán)記錄。2. 先把“交叉口”變成調(diào)度系統(tǒng)可管理的資源區(qū)2.1 地圖拆分路徑、節(jié)點、區(qū)域和資源區(qū)實現(xiàn)交叉口調(diào)度前需要重新組織地圖模型。絕大多數(shù)移動機器人項目會把地圖用于定位室內(nèi)地圖往往由柵格或者點云表示。而交通調(diào)度更適合使用語義地圖也就是把物理空間拆成以下四類對象對象含義調(diào)度作用路徑點機器人路徑上的具體坐標(biāo)用于導(dǎo)航和定位路段兩個路徑點之間的巷道作為機器人正常行駛區(qū)域交叉口區(qū)域多條路段交匯的多邊形或圓形區(qū)域作為需要統(tǒng)一管理的關(guān)鍵空間資源區(qū)一臺機器人占用后其他車不可進(jìn)入的區(qū)域是通行權(quán)控制的最小單元在真實地圖里交叉口區(qū)域通常不是單獨一個坐標(biāo)點而是一個覆蓋路口中心、入口、出口的集合。資源區(qū)可以設(shè)計成“入口緩沖段 路口核心區(qū) 出口清空段”三段結(jié)構(gòu)。機器人未獲授權(quán)時不能進(jìn)入入口緩沖段獲得授權(quán)后允許進(jìn)入核心區(qū)駛出出口清空段后資源區(qū)才釋放給下一臺車。2.2 用 YAML 描述交叉口資源模型工程中可以用 YAML 描述資源區(qū)域和放行規(guī)則。下面這段配置屬于示例結(jié)構(gòu)用于說明思路。實際項目落地前要根據(jù)自己的地圖服務(wù)、調(diào)度系統(tǒng) API 和機器人路徑格式做對應(yīng)擴展。junction: id: J-07 type: four_way core_zone: shape: circle center: [12.5, 30.0] radius: 0.6 entry_zone: west: { yaw_range: [-10, 10], length: 2.0 } east: { yaw_range: [170, 190], length: 2.0 } south: { yaw_range: [80, 100], length: 2.0 } north: { yaw_range: [-100, -80], length: 2.0 } safe_speed: 0.4 max_cross_time: 6.0 release_fence_distance: 0.5 priority_rule: main_route_first allowed_turns: - from: W to: E priority: 2 - from: W to: N priority: 1 - from: E to: W priority: 2 - from: S to: N priority: 0 wait_at: entry_south這里有幾個關(guān)鍵參數(shù)需要解釋。safe_speed是進(jìn)入路口核心區(qū)后的限速值通常遠(yuǎn)低于巷道巡航速度目的是給可能的誤差留出反應(yīng)空間。max_cross_time是機器人從申請通過到釋放資源的最大時間上限超過后調(diào)度系統(tǒng)會判定異常占用。priority_rule是路口通行策略main_route_first表示主干道直行車優(yōu)先。wait_at表示低優(yōu)先級方向需要在哪個入口等待。2.3 通行權(quán)控制的接口設(shè)計有了資源模型之后需要定義一套機器人端和調(diào)度端的通信接口。實際項目中常見實現(xiàn)是調(diào)度中心暴露 HTTP、gRPC 或內(nèi)部消息服務(wù)。下面用一種便于理解的 JSON 接口示意{ request_id: REQ-20250115-001, robot_id: AMR-103, junction_id: J-07, enter_point: entry_west, exit_point: exit_east, estimated_cross_time: 5.2, priority: 2 }機器人進(jìn)入交叉口前會發(fā)送這個申請。調(diào)度中心進(jìn)行時空占用檢查后返回授權(quán){ grant_id: G-3312, junction_id: J-07, allow_enter: true, authorized_window: 2025-01-15 10:30:00.000, expired_time: 2025-01-15 10:30:07.000, advised_speed: 0.4 }機器人拿到allow_enter: true后才繼續(xù)前進(jìn)。拿到false時需要在入口停車等待重新申請還是等待由調(diào)度中心的排隊隊列決定。駛離路口后機器人還需要上報釋放信息才能讓調(diào)度中心把資源分配給下一臺車。2.4 沒有地圖語義時容易踩的坑很多項目的第一版調(diào)度系統(tǒng)只保存了路徑坐標(biāo)點沒有定義交叉口資源區(qū)。系統(tǒng)只知道機器人當(dāng)前在哪個點卻不知道它是否占用了路口。結(jié)果一旦通信中斷或任務(wù)取消路口資源會長時間懸掛其他車輛全部阻塞在路口外圍。這個問題要在設(shè)計地圖文件時避免。給每個交叉口定義獨立的資源 ID并且把路段坐標(biāo)和資源 ID 關(guān)聯(lián)起來是讓交通調(diào)度具備可維護(hù)性的第一步。3. 機器人通過交叉口的狀態(tài)機與執(zhí)行流程3.1 一套路口過車狀態(tài)機申請、等待、進(jìn)入、穿越、釋放機器人通過交叉口不能只靠一次授權(quán)還需要一套完整的執(zhí)行狀態(tài)機。用狀態(tài)分離的好處是每一個狀態(tài)節(jié)點都能輸出日志方便排錯時確認(rèn)機器人到底卡在哪一步。狀態(tài)觸發(fā)條件動作離開條件APPROACH任務(wù)目標(biāo)包含前方路口開始減速進(jìn)入入口緩沖段收到 allow_enterWAIT_ENTRY未獲授權(quán)或授權(quán)被拒絕在指定等待位停車隊列中輪到本車且收到授權(quán)CROSSING收到有效授權(quán)按 safe_speed 進(jìn)入并穿越核心區(qū)車尾越過出口清空線RELEASING車體已離開核心區(qū)上報 release釋放資源調(diào)度中心確認(rèn)釋放完成FAULT授權(quán)超時、通信異常、碰撞包絡(luò)沖突停車并進(jìn)入安全狀態(tài)現(xiàn)場確認(rèn)后手動或自動恢復(fù)狀態(tài)轉(zhuǎn)移要放進(jìn)機器人任務(wù)調(diào)度模塊里而不是放在導(dǎo)航模塊。原因是導(dǎo)航模塊負(fù)責(zé)局部路徑規(guī)劃沒有能力去做排隊語義任務(wù)調(diào)度模塊才知道當(dāng)前任務(wù)去向、路口順序和后續(xù)工位。3.2 中央調(diào)度器的最小實現(xiàn)思路下面這段代碼用于講解核心邏輯不是完整生產(chǎn)代碼。它的語義是調(diào)度器維護(hù)一張“路口授權(quán)表”每個交叉口同一時間只允許一個 grant_id 持有通行權(quán)。class JunctionScheduler: def __init__(self): self.holders {} self.request_queue {} def request(self, robot_id, junction_id, priority): if junction_id not in self.holders: grant_id fG-{len(self.holders):05d} self.holders[junction_id] grant_id return {robot_id: robot_id, allow_enter: True, grant_id: grant_id} queue self.request_queue.setdefault(junction_id, []) ordered sorted(queue [robot_id], reverseTrue) return {robot_id: robot_id, allow_enter: False, position: ordered.index(robot_id) 1} def release(self, robot_id, junction_id, grant_id): if self.holders.get(junction_id) grant_id: del self.holders[junction_id] queue self.request_queue.get(junction_id, []) if queue: next_robot queue.pop(0) # 通知下一臺車進(jìn)入 return {robot_id: next_robot, notify: True} return {error: grant mismatch}這段實現(xiàn)展示了一個單路口授權(quán)控制器。生產(chǎn)版本不能只判斷“有沒有占用者”還要考慮車輛預(yù)計進(jìn)入時間、預(yù)計離開時間以及故障后的超時強制釋放。多機器人同時申請時排序邏輯應(yīng)根據(jù)priority、estimated_cross_time、queued_time做加權(quán)計算避免某一臺低優(yōu)先級車永遠(yuǎn)排不上。3.3 執(zhí)行端速度規(guī)劃提前減速比關(guān)鍵時刻急剎更穩(wěn)機器人獲得授權(quán)后并不是全速沖進(jìn)路口而是按照任務(wù)規(guī)劃的速度曲線運行。為了減少執(zhí)行機構(gòu)的載荷沖擊和貨物晃動速度規(guī)劃可以在進(jìn)入入口緩沖段時就執(zhí)行減速。計算切入口前剩余距離的公式可以用一段偽代碼說明。def plan_approach_speed(current_speed, distance_to_enter, target_speed, decel_limit): # 根據(jù)距離計算出允許的最大速度 allowed_speed math.sqrt(target_speed * target_speed 2 * decel_limit * max(distance_to_enter, 0.0)) return min(current_speed, allowed_speed, max_path_speed)其中distance_to_enter是車頭到入口點的距離target_speed是交叉口核心區(qū)限速decel_limit是底盤允許的安全減速度。這樣算出來的指令會讓機器人提前收油而不是到了入口檢測到位置偏差后才急剎。把剎車過程拉長車身橫向擺動會明顯減小這就是所謂“像老手過路口”的控制層來源。3.4 完整流程里的運行時日志實際運行時機器人日志里應(yīng)當(dāng)能看到這樣的時間線10:29:58.210 AMR-103 APPROACH_J07 dist4.8m speed1.2m/s 10:29:58.320 AMR-103 REQUEST_J07 grantnull waittrue reasonJ_07_busy_by_AMR-107 10:30:01.400 RCS_J07 NOTIFY AMR-103 grantG-3312 window7s 10:30:02.050 AMR-103 ENTER_J07 speed0.4m/s 10:30:07.310 AMR-103 LEAVE_J07 cleartrue release_idG-3312如果機器人 10:30:01 收到通知卻過了 3 秒才進(jìn)入路口說明通知下發(fā)的時序或機器人任務(wù)隊列阻塞存在問題。如果 10:30:08 還沒離開說明進(jìn)入速度高于設(shè)定值或路徑規(guī)劃在路口內(nèi)部出現(xiàn)了繞行。4. 過路口時的安全邊界、通信異常和降級策略4.1 傳感器檢測層不能取消只能降為安全兜底交叉口交通調(diào)度解決的是“秩序”問題但物理安全性仍然需要車載傳感器確認(rèn)。最好這樣理解調(diào)度中心給通行權(quán)雷達(dá)和急停按鈕負(fù)責(zé)處理調(diào)度之外的異常物體包括臨時出現(xiàn)的人、掉落的紙箱、托盤破損和未接入調(diào)度的外來車輛。所以底盤安全邏輯應(yīng)該保留雙層結(jié)構(gòu)。第一層是調(diào)度層的“位置與權(quán)限判斷”第二層是安全 PLC 直接接入急停、激光掃描儀和碰撞傳感器。第二層不依賴中央調(diào)度只要檢測到安全包絡(luò)內(nèi)出現(xiàn)障礙物就立即停車。調(diào)度中心的授權(quán)并不能覆蓋物理安全檢測。4.2 通信超時和“資源懸掛”處理工廠無線網(wǎng)絡(luò)并不總是穩(wěn)定。機器人進(jìn)入路口前斷網(wǎng)、調(diào)度中心重啟、消息隊列延遲都可能導(dǎo)致一個交叉口資源被長期占用。為了避免一臺失聯(lián)車堵死整個工廠調(diào)度器必須支持資源超時強制回收。可參照如下設(shè)計授權(quán)時寫入max_cross_time機器人超過該時間仍未上報離開消息調(diào)度中心先查詢機器人最新位置。如果位置系統(tǒng)確認(rèn)它已離開路口直接回收資源如果位置系統(tǒng)顯示它仍停留在核心區(qū)則要向現(xiàn)場監(jiān)控發(fā)送告警等待人工處理。強制回收不能永遠(yuǎn)自動執(zhí)行因為存在底盤故障、貨物散落等需要人工介入的情況。4.3 調(diào)度器單點故障和主備切換中央調(diào)度器本身可能成為系統(tǒng)瓶頸。實際項目至少要考慮兩種故障調(diào)度進(jìn)程崩潰和調(diào)度服務(wù)器宕機。推薦做法是把授權(quán)狀態(tài)持久化到數(shù)據(jù)庫或消息系統(tǒng)的高可用存儲里而不是只保存在內(nèi)存。調(diào)度器重啟后可以從持久化記錄恢復(fù)當(dāng)前哪些路口被占用、授權(quán) ID 是什么、剩余超時時間是多少。機器人在通信恢復(fù)后應(yīng)主動重發(fā)一次狀態(tài)同步上報。這個機制能避免一次重啟造成全廠機器人交管狀態(tài)清空。5. 常見交叉口交通問題排查先看日志再改參數(shù)5.1 一張現(xiàn)場問題對照表把實際項目中出現(xiàn)頻率較高的路口問題整理成表后面逐條分析。問題現(xiàn)象可能原因檢查點初步處理多臺車堵在路口附近互相等待優(yōu)先級規(guī)則導(dǎo)致低優(yōu)先級車永久讓行查看排隊時間、授權(quán)歷史為等待超過閾值的高優(yōu)先級任務(wù)開放搶占或改道車輛收到允許信號但遲滯 3 秒以上才啟動任務(wù)調(diào)度線程被阻塞授權(quán)消息沒有及時進(jìn)入控制環(huán)查看消息隊列積壓、任務(wù)線程負(fù)載拆分導(dǎo)航線程和任務(wù)線程授權(quán)消息走獨立訂閱車輛尚未完全駛離資源已被下一臺車獲取釋放判定點設(shè)置過近對比輪速里程計和激光定位坐標(biāo)釋放點應(yīng)設(shè)置為車尾越過出口清空線之后授權(quán)正常但車輛在路口內(nèi)頻繁修正方向地圖語義點與實際路沿有偏差使用點云或反光板標(biāo)定路口中心校正地圖并重新采集交叉口地圖數(shù)據(jù)交叉口車輛低速但總發(fā)生安全急停安全傳感器包絡(luò)設(shè)置過大或入口遮擋觸發(fā)誤報查看急停源、安全 IO 日志按車型重調(diào)安全包絡(luò)區(qū)分靜態(tài)貨架和動態(tài)入侵5.2 排查順序車輛、通信、調(diào)度、地圖遇到交叉口通行異常按順序排查能大幅縮短時間。先確認(rèn)單臺車的本體行為是否正常再看通信是否丟包然后檢查調(diào)度器的授權(quán)狀態(tài)最后檢查地圖語義配置。顛倒順序很容易浪費時間改動根本沒錯的調(diào)度參數(shù)。第一步確認(rèn)車輛位置。通過調(diào)度系統(tǒng)看車輛實時坐標(biāo)、當(dāng)前速度、目標(biāo)路徑點。如果車輛位置一直震蕩地圖定位可能有問題。第二步檢查通信鏈路。用 ping 和消息訂閱延遲查看調(diào)度中心與車輛網(wǎng)關(guān)之間是否丟包。低速工廠環(huán)境里機器人經(jīng)過金屬貨架區(qū)域時 Wi-Fi 信號衰減是常見原因。第三步檢查調(diào)度狀態(tài)。看交叉口授權(quán)表里grant_id是否還被某臺車持有是否有超時未釋放記錄。一次典型的“路面死鎖”經(jīng)常能從授權(quán)日志里直接看出來。第四步檢查地圖配置。重點看入口點、核心區(qū)半徑、出口清空線是否設(shè)置過大或過小。設(shè)置過大會降低通行效率設(shè)置過小則會增加碰撞風(fēng)險。5.3 交叉口排錯清單當(dāng)現(xiàn)場報告交叉口卡住時可以按這份清單逐項核對。確認(rèn)卡住的具體交叉口 ID 和涉及的機器人 ID。拉取最近 10 分鐘授權(quán)日志列出每個交口的授權(quán)-釋放時間線。檢查是否有機器人長時間保有一個資源的異常記錄。檢查當(dāng)時兩輛車的實時車速確認(rèn)不是超速進(jìn)入。確認(rèn)中央調(diào)度器和機器人控制器的系統(tǒng)時鐘是否一致。檢查車輛停車點是否位于入口緩沖段內(nèi)避免車體前半段占用核心區(qū)。用錄像回放確認(rèn)機器人在路口是否存在反復(fù)前進(jìn)后退。6. 從單路口順利到全廠通行效率的優(yōu)化方向6.1 衡量交叉口的關(guān)鍵指標(biāo)不只是“通過時長”看一個交叉口是否穩(wěn)定常用三個指標(biāo)。第一個是平均通過時間從機器人到達(dá)入口緩沖段到完全離開出口清空線的時間。第二個是等待率接近路口的機器人中發(fā)生停車的比例。第三個是異常事件數(shù)包括授權(quán)超時、安全急停和人工介入次數(shù)。這三個指標(biāo)往往互相拉扯。把安全包絡(luò)放大異常事件數(shù)會下降但每臺車通過需要的空間范圍變大平均通過時間和等待率會上升。方案取舍要放在具體場景里評估不建議盲目追求某一個指標(biāo)。6.2 放行方向的分組優(yōu)化四向交叉口如果允許四個方向任意轉(zhuǎn)彎調(diào)度沖突會非常多。工程上可以把路口放行策略簡化為時間相位分組。把互不沖突的方向放進(jìn)同一相位例如“東向西直行”和“西向東直行”可以同時放行“南向北直行”和“北向南直行”也可以同時放行。轉(zhuǎn)彎車流量大的方向可以單獨設(shè)置一個相位窗口避免轉(zhuǎn)彎車長期等待。這種思路很像路口信號的相位設(shè)計但它不是定時紅綠燈而是由調(diào)度中心根據(jù)當(dāng)前排隊車輛動態(tài)分配時間窗。低峰期只放行當(dāng)前有申請的方向不需要空等固定周期。高峰期則聚合同方向車輛允許車隊連續(xù)通過減少反復(fù)啟停。6.3 全局路徑規(guī)劃與交叉口通行聯(lián)動單路口優(yōu)化到一定程度后限制全廠效率的反而是最高層的任務(wù)調(diào)度如果多臺車目的地相同任務(wù)分發(fā)時就應(yīng)該做批次聚合讓它們走同一路徑而不是在交叉口附近反復(fù)交匯。另一個常用策略是在任務(wù)下發(fā)時預(yù)計算每個路口的預(yù)計到達(dá)時間讓交叉口調(diào)度在車輛到達(dá)前提前預(yù)排時間窗而不是等車到入口后才申請。更進(jìn)一步的方案是把“路口擁堵”反饋給路徑規(guī)劃器。當(dāng)某些路口在當(dāng)前時間片排隊過長時路徑規(guī)劃模塊可以主動選擇繞行路線即使繞行路徑更長一點也比堵在路口強。7. 工廠應(yīng)用中的落地前提與擴展前景7.1 哪些工廠場景會優(yōu)先受益具備相對固定路徑、長距離搬送路線和多車協(xié)作需求的業(yè)務(wù)場景均適合優(yōu)先落地基于交叉口資源調(diào)度的技術(shù)方案。電子元件車間、汽車零部件配送線、原材料倉到產(chǎn)線邊的往返運輸以及中央倉庫到多個緩存區(qū)的跨區(qū)配送都是典型場景。這些場景有兩個共同點路徑相對規(guī)范適合提前做語義地圖搬運頻率高交叉口擁堵會直接導(dǎo)致產(chǎn)線停線。如果現(xiàn)場環(huán)境大量依賴人工叉車與機器人混行單靠機器人端調(diào)度并不能保證全廠安全。這時應(yīng)把安全策略覆蓋到更完整的交通管理機制限制人工車輛進(jìn)入機器人調(diào)度區(qū)域或為人工車輛安裝可被機器人穩(wěn)定識別的標(biāo)識。7.2 進(jìn)一步擴展的技術(shù)方向在穩(wěn)定的路口通行規(guī)則之上研發(fā)方向可以繼續(xù)延展。一是基于歷史數(shù)據(jù)預(yù)測交叉口流量在任務(wù)排程階段就避開高峰。二是將交叉口調(diào)度從單一路口擴展到路口群讓幾條關(guān)聯(lián)路口的信號協(xié)同工作。三是增加地圖語義自動生成能力從激光點云或 CAD 圖紙中自動識別交叉口區(qū)域和車道方向減少人工配置地圖的工作量。對開發(fā)者個人而言最有價值的練習(xí)不是讀一堆復(fù)雜論文而是先實現(xiàn)一個物理機或仿真環(huán)境下的兩路口三車交叉測試。能讓三臺車在無人工干預(yù)的情況下平穩(wěn)互不阻塞地完成任務(wù)說明已經(jīng)掌握了這套系統(tǒng)的關(guān)鍵鏈路地圖語義、狀態(tài)機、授權(quán)協(xié)議、超時恢復(fù)和日志排錯。7.3 落地前務(wù)實驗收機器人過交叉口的“穩(wěn)”不是靠把速度調(diào)低實現(xiàn)的也不只是雷達(dá)多一點的問題。它需要調(diào)度、控制、執(zhí)行、安全多個模塊寫在同一套嚴(yán)謹(jǐn)協(xié)議里并通過大量現(xiàn)場測試確認(rèn)。一款可以交付工廠使用的方案至少應(yīng)通過如下測試連續(xù)多車無沖突放行測試、單臺車失聯(lián)后的資源釋放測試、調(diào)度器重啟恢復(fù)測試、急停后恢復(fù)測試、低電量車輛優(yōu)先級測試。把這些場景跑完交叉口才真正具備進(jìn)入實際產(chǎn)線運轉(zhuǎn)的條件。