基于5G網絡的云化移動機器人部署方式研究

張 慧

(南京中興新軟件有限責任公司，江蘇 南京 210012)

0 引言

工業自主移動機器人(Autonomous Mobile Robot, AMR)是廣泛用于倉儲、產線物流中完成貨物搬運的工業移動機器人，能夠自動根據任務進行路徑規劃和自動行駛，并具備安全保護功能。AGV有傳統的磁條、磁釘、有軌、二維碼等的導航方式，也有基于激光雷達、視覺的自然導航方式。自然導航有著部署及運行靈活的優勢，能更好地適應柔性化生產需要，是AGV發展的方向。本文以基于激光雷達的自然導航為例，不再贅述其他類似的導航方式。

AGV系統為了完成自動的物流搬運功能，需要進行復雜的計算，故云化AGV的概念被提出。將復雜的計算進行云化，降低本地部署部分的成本。同時，云化部分具備資源共享、動態互備、資源彈性升縮的優勢。因為AGV是移動的，無法通過有線方式直接接入云，所以本文討論的是基于5G網絡的云化AGV的部署方式。

1 云化AGV的部署問題

解決本地端和云端的通信問題是云化的基礎。通常工廠或倉儲中的無線網絡以WiFi為主，其具有部署便利的優點。但WiFi容易受到干擾，經常會出現由于信號不好或被干擾導致AGV停運的事故；另外，在較大空間部署時，AGV無法完成在多個AP之間的平滑無縫切換；AP之間的組網、網絡優化和維護也是個困難。一方面，基于5G的網絡連接方案可以解決干擾和信號覆蓋問題；另一方面，網絡的規劃、優化和維護由運營商來解決，使用方只需按需購買服務即可，這提高了效率。故用5G替換WiFi是一個較好的無線網絡的選擇。

常見的百度云、電信云等都屬于集中部署方式的公有云。隨著AR/VR、工業互聯網、車聯網等新技術的發展，一方面是移動性的需求，一方面對時延、帶寬提出了更高的要求。5G NFV、SDN、云計算的發展催生了多接入邊緣計算技術(Multi-Access Edge Computing，MEC)[1]。

MEC是一種技術架構的創新，可以讓業務更加靈活地選擇部署的位置，除了中心云以外，還可以部署在不同的網絡邊緣云上。

網絡邊緣既可以承擔中心云部分下沉的業務，使業務更靠近現場，減少業務時延；也可以承擔現場側邊緣部分上移的業務，以減輕現場邊緣算力不足的壓力。網絡邊緣計算可以部署在多個節點上，包括接入、普通匯聚、重要匯聚、地市核心四級；相應地，物理上存在于基站站點、區縣一級機房、地市甚至省或大區的核心機房內[2]。

AGV系統由相應的硬件和軟件構成，只要是軟件功能，原則上都是可以云化的，但是每個功能模塊對實時性要求、與其他模塊消息交互的帶寬需求不同，故并不是每個模塊都適合云化。本文討論的重點是，分析AGV系統不同模塊的特點以及云化對云網的時延、帶寬等需求，確定可以進行云化部署的模塊；同時，分析確定云及邊緣云節點的位置的選擇原則。

2 云化AGV業務對云網的需求

AGV系統由AGV小車本體和多機調度系統組成。多機調度系統接收來自MES或WMS的調度指令進行任務分配、路徑規劃和交通管制。AGV小車執行兩點或多點間的搬運任務，實時進行定位導航、安全避障和接受調度臺的管制和任務下發、任務變更。AGV本體和多機調度系統(以下簡稱“調度臺”)的功能模塊細分，如圖1所示。

圖1 AGV系統功能模塊

2.1 多機調度

多機調度功能主要完成：

(1)任務分配。收到MES或WMS的指令后，選擇合適的AGV接收任務，這個時延和帶寬要求都不高。和任務的節拍數相關，但實際的項目中一般不會超過每秒1個任務。

(2)路徑規劃。對于收到任務的起始點選擇一條合適的路徑，既需要考慮到最高效，也需要考慮到多機之間交通沖突和死鎖風險。這個也是和任務數相關。事實上，任務分配并路徑規劃后才會和AGV本體進行交互。時延小于500 ms，帶寬大于100 kBps就可以滿足要求。

(3)交通管制。為了防止多車之間發生交通沖突，小車會按一定周期上報位置，調度臺不斷在計算沖突風險，并給出交通管制指令。各廠家實現機制有點不同，小車上報周期100～500 ms不等。上報和控制指令帶寬需求都很小，與小車數量相關，不應大于1 M[3]。

2.2 AGV單機控制

2.2.1 感知采集與控制

這部分包括從攝像頭、雷達、IMU、里程計、安全開關等采集實時數據，也包括向電機控制器發送執行控制信息。這部分功能與硬件強關聯。一般都駐留在AGV本體，不適合云化部署。

2.2.2 實時分析決策

這部分包括對感知數據的分析、避障、導航定位、運動規劃控制。因為感知數據分析是為各項業務功能服務的，提供視覺、雷達、IMU、里程計等數據的智能分析。如果要云化，需要分解到以下主要功能模塊的需求分析。

(1)定位建圖。以激光SLAM定位建圖為例，建圖過程可以是在線的，也可以是離線的，對實時性沒有強制要求，只需考慮上行帶寬。上行數據包括激光點云、IMU、光電編碼器等數據。AGV當前以單線為主，一般上行預留10 M帶寬即可。

(2)定位導航。AGV在行進過程中，需要不斷地對自身為主進行定位計算。定位精度的要求至少3 cm。AGV小車的運行速度為1.0～3.0 m/s不等，以3 m/s計算，這3 cm的誤差將會發生在10 ms內。定位導航如果上移到云端，則需要時延高一個數量級，控制在1 ms為佳。帶寬需要定位建圖，預留10 M帶寬。

(3)安全避障。安全避障包括碰觸急停和檢測到障礙物后停車。涉及安全，故越及時越好。如果需要云化，那么這部分功能所能容忍的時延不能低于定位導航，需要控制在1 ms。

(4)決策控制。運動規劃、運動控制，需要在定位、避障感知的基礎上，實時地決策和發送控制指令，使得車身前進、后退、轉向。故不能低于安全避障功能的要求，姑且定位1 ms。

帶寬一般都不是問題，主要需要考慮時延和抖動。

3 基于5G云網的測試數據

網絡中的MEC存在多個節點，不同節點的部署會帶來不同影響。本研究通過1個試點項目進行了測試。測試通過中國南方某市的1個測試基站到4個MEC層次上的節點的用戶面UPF的時延，看不同部署節點帶來的時延影響。測試組網如圖2所示。

圖2 測試組網

分別測試從基站gNB到不同MEC節點的時延，測試數據如圖3所示，從中可以看出：用戶距離邊緣節點上UPF(用戶面功能)越遠，時延越大；地市MEC/邊緣云，基本可控制在20 ms以內。

圖3 測試點gNB到各層邊緣節點的距離與時延示意

另外，上述內容只考慮了基站到MEC上的UPF的時延，但對于業務來說，還需要考慮MEC上UPF到業務服務器的時延的端到端的過程。測試對走不同MEC節點到業務服務器的不同路徑做了對比。應用服務器部署在B機房。一條路徑是基站到B機房，另一條路徑是基站到A機房后到B機房的應用服務器。測試結果，第二條路徑多了7 ms。所以，時延要求越低，就要求UPF下沉到最接近業務應用服務器的MEC節點。

同時，也對上下行帶寬進行了測試，測試結果顯示，在測試點環境下，單用戶單線程下行160 Mbps，上行110 Mbps。上下行帶寬能滿足AGV業務需求。

4 結語

從以上數據和對AGV功能模塊的分析看，可以得出3個結論：

(1)多機調度系統、AGV的定位建圖功能可以部署在地市一級(不超過50 km)的各級MEC上，都可以滿足時延帶寬的要求；節點越遠，時延越大，受影響因素更多，因條件限制，沒有測試。

(2)在條件允許的情況下，將業務部署在越低的節點，越靠近業務發生的園區，時延越低，越有利于業務的可靠開展。

(3)AGV本體的業務功能，如智能感知、導航定位、避障等，因為對實時性要求更苛刻，在當前5G的eMBB網絡下，無法滿足要求。

5G作為新一代的移動通信技術，契合了工業數字化轉型對無線網絡的應用需求。5G在工業領域的應用研究處于探索階段。尤其在超低時延(ms級以下)、高可靠性上，工業場景對網絡的要求是非常苛刻的。為此，除了在R16中發布的URLLC、5G TSN，還針對工業場景啟動了5G LAN、工業協議感知和增強、高可用方案等5G增強技術的研究[4]。隨著這些技術的成熟，包括AGV在內的多種應用，都可以更加靈活地部署計算節點，如進一步云化AGV本體中的智能感知、導航定位等算法，這可以降低本體的成本，共享云端計算資源。