做倉儲自動化這些年AGV小車的通訊問題一直是現(xiàn)場開會的高頻話題。尤其是那些還在用拖鏈電纜或者滑觸線傳輸串口信號的AGV跑個幾千公里之后斷芯、接觸不良、干擾誤碼全來了。我最近接手了一個物流倉儲項目需要對在役的一批磁導引AGV做通訊改造核心訴求就一句話把車載控制器上的串口信號搬到無線鏈路上做到實時、穩(wěn)定、可運維。我最終選了串口轉WiFi模塊的方向這文章就把整個項目從選型、組網(wǎng)、配置、調優(yōu)到對接調度系統(tǒng)的完整過程拆開講重點記錄幾個容易踩的坑和現(xiàn)場驗證過的參數(shù)給正在做類似AGV無線化改造的朋友一個可以直接參考的樣板。1. 改造背景AGV車載通訊為什么必須動刀子1.1 有線串口在移動設備上的三大痛點很多AGV出廠時用的還是RS232或RS485串口與上位機通訊通訊線纜的走向無非兩種跟隨AGV本體走拖鏈或者通過滑觸線、地溝連接。這兩種方式在靜態(tài)設備上沒問題但AGV是連續(xù)移動的問題會隨時間成倍放大。第一個痛點是拖鏈電纜的疲勞斷芯。AGV一天跑八小時拖鏈每分鐘彎折幾十次導線的銅芯在反復彎折下會慢慢斷裂。這種故障非常隱蔽外層絕緣皮是完好的用萬用表量通斷也可能正常但到現(xiàn)場一跑就丟數(shù)據(jù)、報亂碼。我們統(tǒng)計過一批運行兩年的AGV因為線纜問題導致的通訊故障占了全部故障的四成以上。第二個痛點是滑觸線的接觸可靠性。滑觸線受安裝精度、灰塵、氧化層的影響很大AGV轉彎、過接縫時碳刷和滑觸線之間會產(chǎn)生瞬間接觸電阻波動直接表現(xiàn)在串口信號上就是偶發(fā)性的幀錯誤、CRC校驗失敗。這種故障最討厭不是一直壞而是“偶爾壞一下”定位非常困難。第三個痛點是運維成本。AGV數(shù)量一多幾十輛車的線纜狀態(tài)巡檢、插頭緊固、備件更換都是實打實的人力和停機成本。尤其是在庫房這種環(huán)境叉車、人員、貨架來回穿梭線纜外露本身就是安全隱患。所以這個項目改動刀子不是拍腦袋而是被現(xiàn)場故障率逼出來的。改造目標很明確去掉車載通訊的物理線纜依賴把串口數(shù)據(jù)無縫搬到無線鏈路上讓AGV和調度系統(tǒng)之間的數(shù)據(jù)交互不再受線纜狀態(tài)制約。1.2 為什么是串口轉WiFi而不是其他無線做無線通訊改造可選的方向其實不少藍牙、ZigBee、LoRa、4G/5G、WiFi我為什么最終選了串口轉WiFi模塊藍牙的問題在于連接數(shù)和對移動漫游的支持不夠穩(wěn)定藍牙主從模式下多車并發(fā)管理很麻煩而且傳輸距離和穿透能力都偏弱。ZigBee和LoRa的優(yōu)點是功耗低、自組網(wǎng)能力強但它們的通信帶寬太小了ZigBee的典型吞吐率也就是幾十kbps到兩百多kbps傳一些精簡的狀態(tài)幀勉強夠用一旦后續(xù)要升級傳輸更大塊的數(shù)據(jù)比如AGV的日志、傳感器波形、視覺輔助信息帶寬就成了瓶頸。LoRa更適合低速率、遠距離、小數(shù)據(jù)量的物聯(lián)網(wǎng)場景放在倉庫里給AGV用反而有種“大炮打蚊子”且?guī)挷粔虻拿芨小?G/5G呢作為公網(wǎng)方案會引入SIM卡管理、運營商信號覆蓋、流量資費和斷網(wǎng)風險等一系列運營問題而且很多倉儲場景在地下室或金屬貨架密集區(qū)域公網(wǎng)信號并不好。更重要的是AGV調度系統(tǒng)的通訊要求足夠確定性的內(nèi)網(wǎng)環(huán)境走公網(wǎng)鏈路多了很多不可控因素。串口轉WiFi模塊恰好落在平衡點上2.4GHz頻段的WiFi在倉庫里有現(xiàn)成的AP覆蓋基礎帶寬充裕支持TCP/IP協(xié)議?？梢灾苯映休d串口數(shù)據(jù)映射到Socket連接上模塊本身成本低單臺AGV加一個模塊幾十到一兩百塊錢的物料成本就能搞定而802.11協(xié)議本身對移動漫游有標準機制配合好AP部署策略可以做到AGV跨AP區(qū)域時連接不中斷。另外還有一個重要的考慮是通用性。AGV車上的控制器五花八門PLC、單片機、嵌入式工控機但它們基本都保留了串口。串口轉WiFi模塊在原車控制器看來就是一個“透明的串口設備”不需要動控制器的程序邏輯和硬件接口這讓我們能在不停產(chǎn)、不大改線束的情況下完成改造風險是最低的。1.3 改造目標與技術指標在動手之前我把需求量化了一下這個環(huán)節(jié)很重要沒有指標就沒辦法判斷改造效果通訊實時性從AGV控制器串口發(fā)出數(shù)據(jù)到調度服務器收到數(shù)據(jù)端到端延遲不大于50ms常態(tài)最好在20ms以內(nèi)。通訊可靠性在AGV全路徑運動過程中包括跨AP漫游時TCP連接不中斷單日丟包率低于0.1%。協(xié)議兼容性原車串口協(xié)議不做任何改動模塊工作在透明傳輸模式下相當于一根“無線串口線”。并發(fā)規(guī)模至少支持現(xiàn)場30臺AGV同時在線調度指令下發(fā)延遲不因車輛數(shù)量增加而明顯惡化。這幾個指標成了后面選型和調試的參照系也幫我在和現(xiàn)場工人、甲方溝通時有了明確的驗收標準。2. 硬件選型與組網(wǎng)架構設計2.1 串口轉WiFi模塊選型怎么看指標市面上的串口轉WiFi模塊很多從幾十塊的ESP8266方案到幾百塊的工業(yè)級專用模塊都有。這種改造項目我建議選工業(yè)級模塊而不是自己用ESP8266搭原因后面會講。選型時我主要看五個關鍵項第一串口電平要匹配。AGV控制器有的是TTL電平串口有的是RS232有的是RS485。模塊必須選對應電平版本的否則要額外加電平轉換電路。RS485還牽扯到方向控制很多模塊是內(nèi)置自動換向的買的時候要確認。第二工作溫度范圍。倉庫雖然不像露天環(huán)境那么極端但夏天庫房頂部溫度經(jīng)常有四十多度AGV電控箱內(nèi)部溫度更高。商業(yè)級模塊標稱0~70℃實際在密封電控箱里很容易到臨界值工業(yè)級一般標-40~85℃留的余量大得多。第三供電電壓和功耗。車載電控通常是24V直流系統(tǒng)模塊一般要5V或3.3V供電需要加DC-DC降壓模塊。功耗方面要關注峰值電流WiFi發(fā)射瞬間的電流可以達到兩三百毫安供電電路必須留夠余量。第四天線接口形式。優(yōu)先選帶外置天線的型號用IPEX接口或者SMA接口這樣天線可以從電控箱里引出來貼在車體外側。內(nèi)置PCB天線的模塊裝在金屬電控箱里信號會被屏蔽得很慘。第五協(xié)議棧和功能完整性。至少需要支持TCP Server、TCP Client、UDP三種工作模式支持心跳包配置支持AT指令和網(wǎng)頁配置雙通道。高端一些的模塊還支持Modbus TCP網(wǎng)關模式如果現(xiàn)場有Modbus RTU設備這個功能會很有用。我在這批項目中選的是USR-WIFI232系列級別的模塊作為主力型號參考它的原因是資料全、Socket模式支持完善、透傳穩(wěn)定性經(jīng)過大量工業(yè)場景驗證。如果你的現(xiàn)場預算緊張用ESP8266做概念驗證POC是可以的但批量上車我不建議無線驅動的穩(wěn)定性和長時間運行的重連機制都跟不上。2.2 三種典型組網(wǎng)拓撲對比串口轉WiFi模塊的組網(wǎng)方式不是只有一種根據(jù)現(xiàn)場網(wǎng)絡條件我梳理了三種典型方案第一種STA模式接入現(xiàn)有倉庫WiFi。這是最常用的方案。AGV車載模塊作為無線終端連接倉庫里原有的AP通過交換機到達調度服務器。優(yōu)點是復用現(xiàn)有網(wǎng)絡不需要新增無線設施缺點是對原有WiFi網(wǎng)絡的覆蓋質量、漫游策略要求高AP部署不佳的話AGV跑到信號盲區(qū)就抓瞎。第二種專用AP模式。針對沒有現(xiàn)成無線覆蓋或者不想和辦公網(wǎng)絡混用的現(xiàn)場在調度機房部署一個專用AP車載模塊的WiFi配置成STA模式直連這個AP。這個方案的好處是網(wǎng)絡干凈、干擾可控、安全性好AGV通訊和其他業(yè)務完全隔離。缺點是AP覆蓋范圍有限大庫房可能要多布幾個AP做漫游。第三種模塊AP模式直連服務器。有的小規(guī)模場景只有一兩臺AGV可以把模塊配成AP模式服務器側用無線網(wǎng)卡連接模塊的SSID實現(xiàn)點對點通訊。這個方案最簡單但擴展性極差AGV一增加就沒法玩了而且AP模式下模塊自身的IP管理比較別扭。我在這個項目里用的是“專用AP模式雙頻段覆蓋”的變體主AP放在庫房中部高位考慮到AGV主要走貨架通道又在庫房兩端補了兩個從AP做漫游擴展。這樣設計的好處是AGV調度網(wǎng)絡和辦公網(wǎng)絡徹底隔離不會出現(xiàn)辦公區(qū)有人看視頻導致AGV延遲突然飆升的尷尬情況。組網(wǎng)方案適用場景優(yōu)點缺點STA接入現(xiàn)有WiFi已有成熟無線覆蓋的庫房部署成本低復用基礎設施受原網(wǎng)絡干擾影響漫游策略難控專用AP模式無線覆蓋差或要求隔離的現(xiàn)場網(wǎng)絡干凈時延穩(wěn)定易排查需新增AP設備和布線模塊AP模式1~2臺AGV的小型驗證實現(xiàn)最快無需AP并發(fā)能力差擴展性不足2.3 天線安裝與現(xiàn)場覆蓋天線看起來是小細節(jié)實際上決定了大半的通訊質量。AGV的電控箱大多是金屬材質如果模塊的天線還留在箱體內(nèi)部WiFi信號會被金屬殼體屏蔽掉哪怕AP就在十米外信號也可能只有-80dBm以下。我的做法是在電控箱面板上開一個SMA孔把天線引出來固定在AGV車體頂部或側面的非金屬區(qū)域。注意天線要保持垂直朝向盡量遠離變頻器、電機驅動線和電池主線這些大電流線路的電磁干擾對2.4GHz信號影響非常明顯?，F(xiàn)場AP的安裝位置也要花心思。很多倉庫為了美觀把AP裝在鋼梁下方但鋼梁本身會遮擋信號而且AGV的行駛路徑主要是貼地的AP的覆蓋要重點保證車體天線高度那個平面的信號強度。我習慣在部署后用手機或筆記本沿著AGV運行路徑實測一遍信號強度確保最差位置不低于-70dBm。這個標準定下來之后后面AGV在庫房里跑基本沒遇到過因為覆蓋盲區(qū)導致的通訊中斷。3. 模塊配置與核心參數(shù)實操3.1 串口參數(shù)匹配改錯一位全盤皆輸模塊拿回來第一件事不是連WiFi而是先看原車控制器的串口參數(shù)。AGV控制器的串口配置在項目資料里一般都能找到但最保險的方式是直接連串口工具抓一下實際輸出。串口參數(shù)包括四個波特率、數(shù)據(jù)位、停止位、校驗位。絕大多數(shù)設備用的是9600或115200波特率、8數(shù)據(jù)位、1停止位、無校驗即“9600 8N1”。但千萬不要因為“絕大多數(shù)”就默認了我們項目里有一臺AGV用的就是19200波特率和偶校驗第一次上電時因為參數(shù)沒配對收到的全是亂碼耽誤了半天才排查出來。配置模塊時進入網(wǎng)頁管理界面后把串口設置和控制器保持一致。這里有個容易被忽略的細節(jié)串口緩沖區(qū)的大小。模塊一般在串口側有一個接收緩沖區(qū)常見的是1024字節(jié)或2048字節(jié)。如果AGV控制器不是用逐字節(jié)查詢的方式而是一次性發(fā)送大塊數(shù)據(jù)幀緩沖區(qū)太小會導致數(shù)據(jù)被截斷。我用的模塊支持設置“打包時間”和“打包長度”意思是從收到第一個字節(jié)開始等待多少毫秒或者攢夠多少字節(jié)后再通過WiFi發(fā)出去。對實時性要求高的場景把打包時間設置在5ms左右比較合適既能保證小幀數(shù)據(jù)的及時性又能把連續(xù)字節(jié)合并成有效的網(wǎng)絡包。3.2 WiFi接入與地址規(guī)劃WiFi接入這塊要注意SSID不要用特殊字符密碼加密方式選擇WPA2-PSK AES不要用WEP或者開放網(wǎng)絡。AGV調度通訊的數(shù)據(jù)涉及位置、任務指令雖然沒有太高的保密要求但至少要防止無關設備接入搗亂。IP地址規(guī)劃上我給每臺AGV分配固定IP而不是依賴DHCP動態(tài)獲取。之前吃過虧DHCP租約到期或者服務器重啟后地址池順序變化導致服務器端維護的連接映射表錯亂明明連接還在但車和地址對不上號了。固定IP之后服務器可以直接通過IP識別每臺AGV排查問題也好定位。具體操作上我先在路由器/交換機上做DHCP靜態(tài)綁定把模塊的MAC地址和規(guī)劃好的IP綁定起來同時也把IP、網(wǎng)關、子網(wǎng)掩碼這幾個參數(shù)直接在模塊網(wǎng)頁里寫死成靜態(tài)雙保險。實踐證明這一步對運行穩(wěn)定性的提升立竿見影。3.3 工作模式選型TCP Client是首選串口轉WiFi模塊的工作模式我強烈建議AGV車載端全部用TCP Client模式。原因很直接在調度系統(tǒng)中服務器作為Server端IP地址是固定的所有AGV作為Client主動向服務器發(fā)起連接并由服務器端維護連接表。這種架構的好處有三個第一AGV的數(shù)量變動不會影響服務器地址配置車多了就多建幾條連接車少了就少幾條完全動態(tài)。第二TCP自帶的ACK和重傳機制能保證串口數(shù)據(jù)幀在網(wǎng)絡層不丟失。雖然會帶來一點延遲開銷但AGV控制指令這類數(shù)據(jù)可靠性遠比那幾毫秒延遲重要。第三服務器端按Socket句柄區(qū)分不同的AGV天然解決了多車并發(fā)時的數(shù)據(jù)歸屬問題。配置TCP Client的關鍵點是服務器IP和端口。端口號要避開常用的服務端口避免沖突。我習慣給AGV調度單獨開一個端口比如9001這個端口在服務器防火墻里要放行否則AGV側顯示連接失敗容易讓人誤判成模塊問題。有些模塊在配置TCP Client時還可以設置“連接超時時間”和“重連間隔”。我建議把重連間隔設在3~5秒太短了網(wǎng)絡抖動時會頻繁發(fā)起連接反而加重無線擁塞太長了則AGV掉線后不能及時恢復。這個參數(shù)在后期調優(yōu)時很常用。3.4 透傳模式的幾個關鍵坑大部分AGV控制器走的是自定義串口協(xié)議不是標準Modbus所以模塊配置成“透明傳輸模式”就夠了。但透明傳輸并不是真的“透明”有幾個坑得提前埋好對策。第一個坑是網(wǎng)絡安全機制。模塊在透明傳輸模式下默認是允許任意TCP客戶端連接的這在調試期方便但上線后容易出問題。建議在模塊里啟用“允許連接的遠程IP列表”功能把調度服務器的IP加進去其他IP一概不響應。第二個坑是模塊上電后自動重連的時機。AGV運行中偶爾會因為現(xiàn)場斷電重啟模塊重啟后需要幾十秒時間去掃描WiFi并建立TCP連接這個空窗期里調度服務器會報“AGV通信超時”。解決方式是在服務器端做斷線緩存把AGV重啟期間的指令存起來等連接恢復后補發(fā)而不是直接判定為故障。第三個坑是網(wǎng)絡空閑時的假死。有些無線模塊在鏈路空閑一定時間后會自動進入省電模式導致數(shù)據(jù)來了不能立刻發(fā)送。工業(yè)AGV場景一定要在模塊配置里關閉省電模式或者設置成“始終喚醒”狀態(tài)。我遇到過一次AGV停在充電站待命調度下發(fā)任務指令結果車過了十幾秒才動排查半天發(fā)現(xiàn)是模塊的休眠策略在作怪。還有一個容易被忽略但很重要的點如果原車走的是RS485總線且總線上掛了多個從站設備比如驅動器、傳感器串口轉WiFi模塊只是把整個RS485總線上的數(shù)據(jù)打包到無線鏈路中。這時要特別注意總線上不要讓兩個主站同時發(fā)數(shù)據(jù)否則RS485的沖突仲裁機制會在無線化的過程中變復雜導致數(shù)據(jù)錯亂。4. 實時性能調優(yōu)延遲、掉線與漫游4.1 端到端延遲實測方法沒有實測數(shù)據(jù)一切實時性都是紙上談兵。我在項目現(xiàn)場用的測試方法很簡單分三步走。第一步測無線鏈路延遲。在調度服務器上對每臺AGV模塊的IP執(zhí)行ping命令看平均RTT和丟包率。在庫房里距離AP二十米左右的理想位置ping值一般在2~5ms隔一堵貨架墻會到5~15ms如果超過30ms就要考慮信號遮擋或者干擾了。第二步測串口到網(wǎng)絡的整體延遲。這個需要借助模塊的調試功能。我的做法是在AGV側用串口調試工具發(fā)送一串帶時間戳的測試幀同時在服務器側用網(wǎng)絡調試助手接收對比發(fā)送和接收的時間戳差。實測下來9600波特率下發(fā)送一個20字節(jié)的幀串口側的發(fā)送時間本身就要約20ms再加上WiFi傳輸?shù)膸缀撩攵说蕉搜舆t大概在25ms左右。如果把波特率提高到115200串口發(fā)送時間縮短到2ms左右端到端延遲可以壓到10ms以內(nèi)。測試項目測試方式實測結果無線鏈路RTT服務器ping模塊IP2~15ms串口到網(wǎng)絡整體延遲串口打時間戳幀網(wǎng)絡接收對比9600波特率約25ms115200約10msTCP連接重連耗時手動斷開AP觀察恢復時間一般為3~8秒跨AP漫游斷流時間AGV跑通道中間跨AP點抓包約100~300ms第三步驗證多車并發(fā)的延遲變化。把現(xiàn)場30臺AGV的模塊全部上線連服務器再重復第二步的測試確認延遲沒有顯著上升。這一步是驗收的硬指標如果并發(fā)一上來延遲就翻倍說明無線鏈路規(guī)劃或服務器處理能力有問題得回頭排查。4.2 心跳包、掉線重連與看門狗機制無線鏈路的“實時”不等于鏈路永遠不斷。模塊長期運行后WiFi連接可能因為DHCP租約、AP重啟、無線干擾等原因悄然斷開問題在于TCP連接斷開了但車載控制器還不知道繼續(xù)往串口發(fā)數(shù)據(jù)數(shù)據(jù)就會在模塊的緩沖區(qū)里堆積造成“假在線”的現(xiàn)象。解決假在線的標準做法是開啟心跳機制分網(wǎng)絡層和應用層兩道。網(wǎng)絡層的心跳是TCP KeepAlive很多模塊里可以設置KeepAlive間隔默認可能關著要打開我一般設在30秒。應用層的心跳是模塊向服務器定時發(fā)送自定義的心跳幀比如每10秒發(fā)送一串固定的字節(jié)例如0xAA 0x55 0x00 0x01。服務器端只要在超過設定時間比如30秒沒有收到某臺AGV的任何數(shù)據(jù)就判定該車離線觸發(fā)告警并停止下發(fā)指令。模塊側的掉線重連也要做硬性配置。我在模塊里設置的參數(shù)是檢測到WiFi斷開后立即重連TCP斷線后3秒重連重連失敗則不斷重試同時開啟硬件看門狗防止模塊內(nèi)部程序跑飛。這里說一個實操心得模塊的硬件看門狗觸發(fā)后會讓模塊重啟重啟再連上服務器一般需要30秒左右這期間AGV通訊是完全中斷的。所以不要依賴看門狗去解決頻繁掉線問題它只是最后一道保險。真正要做的是把掉線的根因找出來大部分情況下都出在無線覆蓋和配置上。4.3 漫游、干擾與信道優(yōu)化AGV在倉庫里跑會從一臺AP的信號范圍跑到另一臺AP的范圍這個切換過程叫漫游。家用WiFi的漫游體驗差沒關系最多是視頻卡一下AGV的漫游可能會讓一個正在執(zhí)行中的任務被打斷所以漫游策略必須專門調。很多普通WiFi模塊不支持快速漫游802.11r在漫游時是“先斷開再連接”斷流時間在幾百毫秒到一秒不等。對于100ms周期的實時指令下發(fā)來說這個間隙確實會有影響。我們的應對方案有三個層面一是把模塊的漫游觸發(fā)閾值調低一些讓模塊“戀家”一點避免在AP邊緣頻繁切換二是在AGV運行路徑規(guī)劃中盡量避免讓AGV長時間停留在兩臺AP的信號交界處或者在這個區(qū)域適當降低AGV的運行速度三是如果模塊支持“根據(jù)信號強度主動切換”的功能就把切換閾值設置在-75dBm左右低于這個值再切高于這個值就老老實實待在原AP上。干擾問題在2.4GHz頻段尤其嚴重。倉庫里的無線掃碼槍、工控機無線網(wǎng)卡、甚至是叉車上的藍牙設備都在搶這個頻段。我現(xiàn)場用無線頻譜分析儀掃了一遍發(fā)現(xiàn)好幾個AP的工作通道被附近的藍牙信標和微波設備壓得厲害。解決方式很簡單把相鄰AP的工作信道錯開1、6、11三個非重疊信道盡量分開用同時把AP發(fā)射功率調到合適的檔位不要把信號開太滿造成相鄰AP相互干擾。如果倉庫不大甚至可以直接改成5GHz頻段AGV模塊也選支持雙頻的型號5GHz干擾小、速率高穿墻能力弱一點但AGV都是走視距內(nèi)的通道問題不大。5. 與AGV調度系統(tǒng)的通訊對接5.1 通信幀結構設計無線鏈路打通之后調度系統(tǒng)和AGV控制器之間的串口協(xié)議就得跑在這條鏈路上。原車協(xié)議是廠商定的我們盡量不動但為了讓服務器端能穩(wěn)定解析我在原有協(xié)議外面包了一層通用幀結構專門用來解決“數(shù)據(jù)從哪來、到哪去、是否完整”的問題。幀結構設計如下幀頭用2個字節(jié)0xAA 0x55然后跟1個字節(jié)的長度域表示負載長度1個字節(jié)的幀類型域區(qū)分上行狀態(tài)、下行指令、心跳應答然后是負載數(shù)據(jù)最后2個字節(jié)放CRC16校驗。上行狀態(tài)幀示例AA 55 0A 01 22 00 00 01 2C 01 00 64 58 1E 幀頭 長度 類型 負載數(shù)據(jù)(10字節(jié)) CRC16其中負載數(shù)據(jù)里包含AGV當前坐標X、坐標Y、方向角、速度、電量以及故障碼。調度服務器收到這個幀后先做CRC校驗再按幀類型分發(fā)到對應的解析模塊。下行指令幀的結構類似只是類型域不同負載是目標點、速度、動作命令這些。心跳幀則是固定內(nèi)容如AA 55 00 02 34 12不帶負載。幀結構定下來之后還有一個重要決策AGV的狀態(tài)上報頻率。我們用100ms一個周期也就是每秒10幀每幀十來個字節(jié)數(shù)據(jù)量并不大但服務器端解析、存儲、畫面刷新的壓力會成一個臺階。這個頻率要根據(jù)調度系統(tǒng)的算力來定如果調度服務器性能一般把周期放寬到200ms也行AGV速度不高的話完全夠用。5.2 粘包和半包的處理串口數(shù)據(jù)走TCP傳輸最經(jīng)典的問題就是粘包和半包。TCP是面向字節(jié)流的它不保證一次recv收到的數(shù)據(jù)恰好對應一幀串口數(shù)據(jù)。調度服務器同時管理幾十臺AGV的連接每路連接都在不停收數(shù)據(jù)如果不做拆包處理服務器端解析到的一定是亂套的字節(jié)流。我在服務器端的接收邏輯是用一個環(huán)形緩沖區(qū)把收到的字節(jié)先全部塞進去然后循環(huán)掃描緩沖區(qū)按我們定的幀頭、長度、CRC規(guī)則一幀一幀地拆出來。粘包的情況靠幀頭和長度自然切分半包的情況則等下一批數(shù)據(jù)到達后再拼出來。給一段參考的Python解析框架def parse_stream(buffer): frames [] while True: if len(buffer) 4: break # 查找?guī)^ if buffer[0] ! 0xAA or buffer[1] ! 0x55: buffer.pop(0) continue # 解析長度 payload_len buffer[2] total_len 4 payload_len 2 if len(buffer) total_len: break # 半包等待更多數(shù)據(jù) frame_body bytes(buffer[:total_len]) frames.append(frame_body) del buffer[:total_len] return frames這個框架在實際項目里運行很穩(wěn)定。關鍵點在于使用緩沖區(qū)和循環(huán)解析而不是依賴單次recv事件就認為收到完整幀這一點對任何自定義串口協(xié)議的無線化改造都適用。5.3 調度系統(tǒng)對接openTCS與自定義雙通道談到AGV調度系統(tǒng)圈子里聊得最多的一個是開源系統(tǒng)openTCS一個是各家自研的調度平臺。這個項目里我接觸過openTCS做技術驗證也對接過自研調度平臺兩邊都說說。openTCS比較適合中小規(guī)模、以路徑規(guī)劃和任務分配為核心訴求的場景。它本身有一套相對完整的Kernel和Vehicle Driver框架你可以把你的AGV當作一個“vehicle”接入通過通訊驅動層往AGV發(fā)命令、收狀態(tài)。openTCS底層路徑規(guī)劃用到了A*相關的算法多臺AGV并行調度時指令下發(fā)頻次較高對通訊鏈路的實時性要求也更嚴格。把串口轉WiFi鏈路作為openTCS和AGV之間的傳輸通道需要在openTCS里配置一個自定義通信驅動讓它向AGV模塊的TCP端口發(fā)送協(xié)議指令并解析AGV上報的狀態(tài)幀。自研調度平臺的對接方式就更靈活了通常是調度平臺提供一個TCP服務端AGV模塊的TCP Client連上來平臺側用獨立的通訊模塊統(tǒng)一管理連接和解析。我的經(jīng)驗是無論用哪套系統(tǒng)都要在調度平臺和AGV控制器之間加一個“協(xié)議適配層”不要讓調度平臺直接拼串口協(xié)議字節(jié)。這樣即便以后換了控制器或者換了調度系統(tǒng)改的只是適配層的映射關系不至于推倒重來。5.4 多車并發(fā)帶寬與調度節(jié)奏多臺AGV同時在線很多人會擔心WiFi帶寬不夠用。我簡單算過一筆賬每臺AGV以100ms周期上報一個15字節(jié)左右的幀每秒就是150字節(jié)30臺AGV每秒總共也就4.5KB左右的上行數(shù)據(jù)量下行指令更稀疏偶爾一條任務指令也就是幾十字節(jié)。這個數(shù)據(jù)量相對WiFi幾Mbps到幾十Mbps的實際吞吐率來說是九牛一毛。真正的瓶頸不在于帶寬而在于AP的并發(fā)連接數(shù)。普通企業(yè)級AP帶幾十個終端問題不大但如果是幾塊錢一個的民用路由器帶機量二三十臺就可能出現(xiàn)連接不穩(wěn)定、延遲飆升。所以如果現(xiàn)場AGV數(shù)量超過二十臺AP一定選企業(yè)級的并關注它的推薦帶機量參數(shù)。調度節(jié)奏上也要控制好指令風暴。有的調度算法比如多車路徑規(guī)劃時會在某個節(jié)點同時向大量AGV下發(fā)指令所有數(shù)據(jù)包同時涌向AP的下行隊列WiFi的競爭機制會讓某些包延遲明顯增大。我做過一個優(yōu)化給AP開啟WMMWi-Fi Multimedia模式把AGV調度業(yè)務的數(shù)據(jù)包標記為高優(yōu)先級隊列和倉庫里的掃碼槍、辦公數(shù)據(jù)區(qū)分開實測在指令高峰期延遲提高了30%以上的穩(wěn)定性。這個優(yōu)化零成本效果卻很明顯值得所有做AGV無線改造的人試一下。6. 現(xiàn)場問題實錄與排查經(jīng)驗6.1 高頻故障速查表整個項目實施下來我把遇到過的和同行業(yè)朋友分享過的典型問題整理成了一張速查表現(xiàn)場出問題可以直接對著查。故障現(xiàn)象可能原因排查手段與解決串口數(shù)據(jù)亂碼波特率、校驗位配置不匹配核對原車控制器串口參數(shù)在模塊網(wǎng)頁重新配置服務器收不到任何數(shù)據(jù)TCP連接未建立或模塊處于AT模式檢查模塊工作模式是否為透明傳輸檢查服務器IP端口放行模塊偶發(fā)掉線又自動恢復DHCP租約到期或IP地址沖突改為靜態(tài)IPDNS靜態(tài)綁定小車一直在某區(qū)域丟包AP覆蓋盲區(qū)或金屬貨架遮擋沿路徑測試信號調整AP位置或增加補點延遲突然飆升到幾百毫秒同頻段干擾或某AP帶機量過載換信道、開WMM、QoS標記錯開非重疊信道重啟后長時間連不上服務器模塊開機掃描SSID耗時長關閉省電模式縮短TCP重連間隔必要時讓模塊記憶上次連接兩臺AGV的數(shù)據(jù)互相串服務器端按幀頭解析邏輯缺陷檢查粘包半包處理邏輯按Socket區(qū)分數(shù)據(jù)源6.2 三個典型案例復盤案例一某臺AGV一過通道拐彎就掉線。排查了很久最后發(fā)現(xiàn)是AGV走到拐彎處時車身正好把天線遮擋在了金屬貨架和車體之間形成定向屏蔽。解決辦法不是在無線參數(shù)上動刀而是把天線位置從車體側面改到了車頂中央信號立馬從-78dBm改善到-62dBm。這個案例讓我深刻體會到天線位置是無線通訊里最便宜的優(yōu)化項也是最容易被忽略的優(yōu)化項。案例二服務器端顯示多臺AGV狀態(tài)刷新延遲但ping模塊都是正常的。查到最后發(fā)現(xiàn)是服務器端程序用單線程在輪詢解析所有Socket連接某臺AGV的串口日志數(shù)據(jù)量一上來把整個處理線程阻塞了。優(yōu)化方式是把每臺AGV的連接解析放到獨立線程或者使用異步IO問題瞬間消失。這提醒我無線鏈路沒問題的時候要看鏈路兩端的處理程序有沒有瓶頸。案例三AGV停在充電樁區(qū)域時頻繁報“通信超時”。這個位置AP信號其實是滿格的但充電樁運行時的電磁干擾非常嚴重頻譜儀上能看到明顯的底噪抬升。我把充電區(qū)域的AP調到5GHz頻段同時把模塊也換成雙頻型號問題解決。如果模塊不支持5GHz那么在充電樁區(qū)域加裝屏蔽措施或者把充電樁和AP的物理距離拉開至少五米也有改善。6.3 改造后的穩(wěn)定性數(shù)據(jù)與心得改造上線運行三個月后我拉了一次數(shù)據(jù)AGV因通訊故障導致的停機次數(shù)從改造前平均每周兩三次降到了一個月不到一次拖鏈電纜和滑觸線相關的備件費用基本清零。無線鏈路的平均端到端延遲穩(wěn)定在15ms左右最差情況跨AP漫游瞬間控制在300ms以內(nèi)滿足最初定下的指標。我個人在實際操作中的體會有三點供大家參考。第一串口轉WiFi改造并不是什么高科技它的核心價值在于用最小改動成本把移動設備從物理線纜的束縛里解放出來但前提是無線基礎設施必須按工業(yè)標準來搭省掉AP部署和信道優(yōu)化的錢后面會用故障時間加倍還回來。第二模塊的選型寧可用工業(yè)級也別圖便宜用開發(fā)板長時間運行的穩(wěn)定性差異特別大這個錢不能省。第三調試時一定要把原車串口協(xié)議吃透一定要設計好服務器端的拆包邏輯這兩個環(huán)節(jié)做好了后面所有問題都好解決做不好無線鏈路再快也會在數(shù)據(jù)解析上栽跟頭。這批AGV后續(xù)計劃接入視覺導航和自動充電功能串口轉WiFi這條鏈路從帶寬和時延上都是夠用的到時候只需要在幀協(xié)議里擴展新的幀類型就行。通訊改造雖然只是整個AGV系統(tǒng)里不起眼的一環(huán)但它就像人的神經(jīng)系統(tǒng)平時感覺不到它的存在一旦出問題整個系統(tǒng)都會癱瘓。把這層基礎打好后續(xù)的智能化升級才能走得穩(wěn)。