AGV小车串口转WiFi无线通讯改造实战：从选型到调度对接

做仓储自动化这些年AGV小车的通讯问题一直是现场开会的高频话题。尤其是那些还在用拖链电缆或者滑触线传输串口信号的AGV跑个几千公里之后断芯、接触不良、干扰误码全来了。我最近接手了一个物流仓储项目需要对在役的一批磁导引AGV做通讯改造核心诉求就一句话把车载控制器上的串口信号搬到无线链路上做到实时、稳定、可运维。我最终选了串口转WiFi模块的方向这文章就把整个项目从选型、组网、配置、调优到对接调度系统的完整过程拆开讲重点记录几个容易踩的坑和现场验证过的参数给正在做类似AGV无线化改造的朋友一个可以直接参考的样板。1. 改造背景AGV车载通讯为什么必须动刀子1.1 有线串口在移动设备上的三大痛点很多AGV出厂时用的还是RS232或RS485串口与上位机通讯通讯线缆的走向无非两种跟随AGV本体走拖链或者通过滑触线、地沟连接。这两种方式在静态设备上没问题但AGV是连续移动的问题会随时间成倍放大。第一个痛点是拖链电缆的疲劳断芯。AGV一天跑八小时拖链每分钟弯折几十次导线的铜芯在反复弯折下会慢慢断裂。这种故障非常隐蔽外层绝缘皮是完好的用万用表量通断也可能正常但到现场一跑就丢数据、报乱码。我们统计过一批运行两年的AGV因为线缆问题导致的通讯故障占了全部故障的四成以上。第二个痛点是滑触线的接触可靠性。滑触线受安装精度、灰尘、氧化层的影响很大AGV转弯、过接缝时碳刷和滑触线之间会产生瞬间接触电阻波动直接表现在串口信号上就是偶发性的帧错误、CRC校验失败。这种故障最讨厌不是一直坏而是“偶尔坏一下”定位非常困难。第三个痛点是运维成本。AGV数量一多几十辆车的线缆状态巡检、插头紧固、备件更换都是实打实的人力和停机成本。尤其是在库房这种环境叉车、人员、货架来回穿梭线缆外露本身就是安全隐患。所以这个项目改动刀子不是拍脑袋而是被现场故障率逼出来的。改造目标很明确去掉车载通讯的物理线缆依赖把串口数据无缝搬到无线链路上让AGV和调度系统之间的数据交互不再受线缆状态制约。1.2 为什么是串口转WiFi而不是其他无线做无线通讯改造可选的方向其实不少蓝牙、ZigBee、LoRa、4G/5G、WiFi我为什么最终选了串口转WiFi模块蓝牙的问题在于连接数和对移动漫游的支持不够稳定蓝牙主从模式下多车并发管理很麻烦而且传输距离和穿透能力都偏弱。ZigBee和LoRa的优点是功耗低、自组网能力强但它们的通信带宽太小了ZigBee的典型吞吐率也就是几十kbps到两百多kbps传一些精简的状态帧勉强够用一旦后续要升级传输更大块的数据比如AGV的日志、传感器波形、视觉辅助信息带宽就成了瓶颈。LoRa更适合低速率、远距离、小数据量的物联网场景放在仓库里给AGV用反而有种“大炮打蚊子”且带宽不够的矛盾感。4G/5G呢作为公网方案会引入SIM卡管理、运营商信号覆盖、流量资费和断网风险等一系列运营问题而且很多仓储场景在地下室或金属货架密集区域公网信号并不好。更重要的是AGV调度系统的通讯要求足够确定性的内网环境走公网链路多了很多不可控因素。串口转WiFi模块恰好落在平衡点上2.4GHz频段的WiFi在仓库里有现成的AP覆盖基础带宽充裕支持TCP/IP协议栈可以直接承载串口数据映射到Socket连接上模块本身成本低单台AGV加一个模块几十到一两百块钱的物料成本就能搞定而802.11协议本身对移动漫游有标准机制配合好AP部署策略可以做到AGV跨AP区域时连接不中断。另外还有一个重要的考虑是通用性。AGV车上的控制器五花八门PLC、单片机、嵌入式工控机但它们基本都保留了串口。串口转WiFi模块在原车控制器看来就是一个“透明的串口设备”不需要动控制器的程序逻辑和硬件接口这让我们能在不停产、不大改线束的情况下完成改造风险是最低的。1.3 改造目标与技术指标在动手之前我把需求量化了一下这个环节很重要没有指标就没办法判断改造效果通讯实时性从AGV控制器串口发出数据到调度服务器收到数据端到端延迟不大于50ms常态最好在20ms以内。通讯可靠性在AGV全路径运动过程中包括跨AP漫游时TCP连接不中断单日丢包率低于0.1%。协议兼容性原车串口协议不做任何改动模块工作在透明传输模式下相当于一根“无线串口线”。并发规模至少支持现场30台AGV同时在线调度指令下发延迟不因车辆数量增加而明显恶化。这几个指标成了后面选型和调试的参照系也帮我在和现场工人、甲方沟通时有了明确的验收标准。2. 硬件选型与组网架构设计2.1 串口转WiFi模块选型怎么看指标市面上的串口转WiFi模块很多从几十块的ESP8266方案到几百块的工业级专用模块都有。这种改造项目我建议选工业级模块而不是自己用ESP8266搭原因后面会讲。选型时我主要看五个关键项第一串口电平要匹配。AGV控制器有的是TTL电平串口有的是RS232有的是RS485。模块必须选对应电平版本的否则要额外加电平转换电路。RS485还牵扯到方向控制很多模块是内置自动换向的买的时候要确认。第二工作温度范围。仓库虽然不像露天环境那么极端但夏天库房顶部温度经常有四十多度AGV电控箱内部温度更高。商业级模块标称0~70℃实际在密封电控箱里很容易到临界值工业级一般标-40~85℃留的余量大得多。第三供电电压和功耗。车载电控通常是24V直流系统模块一般要5V或3.3V供电需要加DC-DC降压模块。功耗方面要关注峰值电流WiFi发射瞬间的电流可以达到两三百毫安供电电路必须留够余量。第四天线接口形式。优先选带外置天线的型号用IPEX接口或者SMA接口这样天线可以从电控箱里引出来贴在车体外侧。内置PCB天线的模块装在金属电控箱里信号会被屏蔽得很惨。第五协议栈和功能完整性。至少需要支持TCP Server、TCP Client、UDP三种工作模式支持心跳包配置支持AT指令和网页配置双通道。高端一些的模块还支持Modbus TCP网关模式如果现场有Modbus RTU设备这个功能会很有用。我在这批项目中选的是USR-WIFI232系列级别的模块作为主力型号参考它的原因是资料全、Socket模式支持完善、透传稳定性经过大量工业场景验证。如果你的现场预算紧张用ESP8266做概念验证POC是可以的但批量上车我不建议无线驱动的稳定性和长时间运行的重连机制都跟不上。2.2 三种典型组网拓扑对比串口转WiFi模块的组网方式不是只有一种根据现场网络条件我梳理了三种典型方案第一种STA模式接入现有仓库WiFi。这是最常用的方案。AGV车载模块作为无线终端连接仓库里原有的AP通过交换机到达调度服务器。优点是复用现有网络不需要新增无线设施缺点是对原有WiFi网络的覆盖质量、漫游策略要求高AP部署不佳的话AGV跑到信号盲区就抓瞎。第二种专用AP模式。针对没有现成无线覆盖或者不想和办公网络混用的现场在调度机房部署一个专用AP车载模块的WiFi配置成STA模式直连这个AP。这个方案的好处是网络干净、干扰可控、安全性好AGV通讯和其他业务完全隔离。缺点是AP覆盖范围有限大库房可能要多布几个AP做漫游。第三种模块AP模式直连服务器。有的小规模场景只有一两台AGV可以把模块配成AP模式服务器侧用无线网卡连接模块的SSID实现点对点通讯。这个方案最简单但扩展性极差AGV一增加就没法玩了而且AP模式下模块自身的IP管理比较别扭。我在这个项目里用的是“专用AP模式双频段覆盖”的变体主AP放在库房中部高位考虑到AGV主要走货架通道又在库房两端补了两个从AP做漫游扩展。这样设计的好处是AGV调度网络和办公网络彻底隔离不会出现办公区有人看视频导致AGV延迟突然飙升的尴尬情况。组网方案适用场景优点缺点STA接入现有WiFi已有成熟无线覆盖的库房部署成本低复用基础设施受原网络干扰影响漫游策略难控专用AP模式无线覆盖差或要求隔离的现场网络干净时延稳定易排查需新增AP设备和布线模块AP模式1~2台AGV的小型验证实现最快无需AP并发能力差扩展性不足2.3 天线安装与现场覆盖天线看起来是小细节实际上决定了大半的通讯质量。AGV的电控箱大多是金属材质如果模块的天线还留在箱体内部WiFi信号会被金属壳体屏蔽掉哪怕AP就在十米外信号也可能只有-80dBm以下。我的做法是在电控箱面板上开一个SMA孔把天线引出来固定在AGV车体顶部或侧面的非金属区域。注意天线要保持垂直朝向尽量远离变频器、电机驱动线和电池主线这些大电流线路的电磁干扰对2.4GHz信号影响非常明显。现场AP的安装位置也要花心思。很多仓库为了美观把AP装在钢梁下方但钢梁本身会遮挡信号而且AGV的行驶路径主要是贴地的AP的覆盖要重点保证车体天线高度那个平面的信号强度。我习惯在部署后用手机或笔记本沿着AGV运行路径实测一遍信号强度确保最差位置不低于-70dBm。这个标准定下来之后后面AGV在库房里跑基本没遇到过因为覆盖盲区导致的通讯中断。3. 模块配置与核心参数实操3.1 串口参数匹配改错一位全盘皆输模块拿回来第一件事不是连WiFi而是先看原车控制器的串口参数。AGV控制器的串口配置在项目资料里一般都能找到但最保险的方式是直接连串口工具抓一下实际输出。串口参数包括四个波特率、数据位、停止位、校验位。绝大多数设备用的是9600或115200波特率、8数据位、1停止位、无校验即“9600 8N1”。但千万不要因为“绝大多数”就默认了我们项目里有一台AGV用的就是19200波特率和偶校验第一次上电时因为参数没配对收到的全是乱码耽误了半天才排查出来。配置模块时进入网页管理界面后把串口设置和控制器保持一致。这里有个容易被忽略的细节串口缓冲区的大小。模块一般在串口侧有一个接收缓冲区常见的是1024字节或2048字节。如果AGV控制器不是用逐字节查询的方式而是一次性发送大块数据帧缓冲区太小会导致数据被截断。我用的模块支持设置“打包时间”和“打包长度”意思是从收到第一个字节开始等待多少毫秒或者攒够多少字节后再通过WiFi发出去。对实时性要求高的场景把打包时间设置在5ms左右比较合适既能保证小帧数据的及时性又能把连续字节合并成有效的网络包。3.2 WiFi接入与地址规划WiFi接入这块要注意SSID不要用特殊字符密码加密方式选择WPA2-PSK AES不要用WEP或者开放网络。AGV调度通讯的数据涉及位置、任务指令虽然没有太高的保密要求但至少要防止无关设备接入捣乱。IP地址规划上我给每台AGV分配固定IP而不是依赖DHCP动态获取。之前吃过亏DHCP租约到期或者服务器重启后地址池顺序变化导致服务器端维护的连接映射表错乱明明连接还在但车和地址对不上号了。固定IP之后服务器可以直接通过IP识别每台AGV排查问题也好定位。具体操作上我先在路由器/交换机上做DHCP静态绑定把模块的MAC地址和规划好的IP绑定起来同时也把IP、网关、子网掩码这几个参数直接在模块网页里写死成静态双保险。实践证明这一步对运行稳定性的提升立竿见影。3.3 工作模式选型TCP Client是首选串口转WiFi模块的工作模式我强烈建议AGV车载端全部用TCP Client模式。原因很直接在调度系统中服务器作为Server端IP地址是固定的所有AGV作为Client主动向服务器发起连接并由服务器端维护连接表。这种架构的好处有三个第一AGV的数量变动不会影响服务器地址配置车多了就多建几条连接车少了就少几条完全动态。第二TCP自带的ACK和重传机制能保证串口数据帧在网络层不丢失。虽然会带来一点延迟开销但AGV控制指令这类数据可靠性远比那几毫秒延迟重要。第三服务器端按Socket句柄区分不同的AGV天然解决了多车并发时的数据归属问题。配置TCP Client的关键点是服务器IP和端口。端口号要避开常用的服务端口避免冲突。我习惯给AGV调度单独开一个端口比如9001这个端口在服务器防火墙里要放行否则AGV侧显示连接失败容易让人误判成模块问题。有些模块在配置TCP Client时还可以设置“连接超时时间”和“重连间隔”。我建议把重连间隔设在3~5秒太短了网络抖动时会频繁发起连接反而加重无线拥塞太长了则AGV掉线后不能及时恢复。这个参数在后期调优时很常用。3.4 透传模式的几个关键坑大部分AGV控制器走的是自定义串口协议不是标准Modbus所以模块配置成“透明传输模式”就够了。但透明传输并不是真的“透明”有几个坑得提前埋好对策。第一个坑是网络安全机制。模块在透明传输模式下默认是允许任意TCP客户端连接的这在调试期方便但上线后容易出问题。建议在模块里启用“允许连接的远程IP列表”功能把调度服务器的IP加进去其他IP一概不响应。第二个坑是模块上电后自动重连的时机。AGV运行中偶尔会因为现场断电重启模块重启后需要几十秒时间去扫描WiFi并建立TCP连接这个空窗期里调度服务器会报“AGV通信超时”。解决方式是在服务器端做断线缓存把AGV重启期间的指令存起来等连接恢复后补发而不是直接判定为故障。第三个坑是网络空闲时的假死。有些无线模块在链路空闲一定时间后会自动进入省电模式导致数据来了不能立刻发送。工业AGV场景一定要在模块配置里关闭省电模式或者设置成“始终唤醒”状态。我遇到过一次AGV停在充电站待命调度下发任务指令结果车过了十几秒才动排查半天发现是模块的休眠策略在作怪。还有一个容易被忽略但很重要的点如果原车走的是RS485总线且总线上挂了多个从站设备比如驱动器、传感器串口转WiFi模块只是把整个RS485总线上的数据打包到无线链路中。这时要特别注意总线上不要让两个主站同时发数据否则RS485的冲突仲裁机制会在无线化的过程中变复杂导致数据错乱。4. 实时性能调优延迟、掉线与漫游4.1 端到端延迟实测方法没有实测数据一切实时性都是纸上谈兵。我在项目现场用的测试方法很简单分三步走。第一步测无线链路延迟。在调度服务器上对每台AGV模块的IP执行ping命令看平均RTT和丢包率。在库房里距离AP二十米左右的理想位置ping值一般在2~5ms隔一堵货架墙会到5~15ms如果超过30ms就要考虑信号遮挡或者干扰了。第二步测串口到网络的整体延迟。这个需要借助模块的调试功能。我的做法是在AGV侧用串口调试工具发送一串带时间戳的测试帧同时在服务器侧用网络调试助手接收对比发送和接收的时间戳差。实测下来9600波特率下发送一个20字节的帧串口侧的发送时间本身就要约20ms再加上WiFi传输的几毫秒端到端延迟大概在25ms左右。如果把波特率提高到115200串口发送时间缩短到2ms左右端到端延迟可以压到10ms以内。测试项目测试方式实测结果无线链路RTT服务器ping模块IP2~15ms串口到网络整体延迟串口打时间戳帧网络接收对比9600波特率约25ms115200约10msTCP连接重连耗时手动断开AP观察恢复时间一般为3~8秒跨AP漫游断流时间AGV跑通道中间跨AP点抓包约100~300ms第三步验证多车并发的延迟变化。把现场30台AGV的模块全部上线连服务器再重复第二步的测试确认延迟没有显著上升。这一步是验收的硬指标如果并发一上来延迟就翻倍说明无线链路规划或服务器处理能力有问题得回头排查。4.2 心跳包、掉线重连与看门狗机制无线链路的“实时”不等于链路永远不断。模块长期运行后WiFi连接可能因为DHCP租约、AP重启、无线干扰等原因悄然断开问题在于TCP连接断开了但车载控制器还不知道继续往串口发数据数据就会在模块的缓冲区里堆积造成“假在线”的现象。解决假在线的标准做法是开启心跳机制分网络层和应用层两道。网络层的心跳是TCP KeepAlive很多模块里可以设置KeepAlive间隔默认可能关着要打开我一般设在30秒。应用层的心跳是模块向服务器定时发送自定义的心跳帧比如每10秒发送一串固定的字节例如0xAA 0x55 0x00 0x01。服务器端只要在超过设定时间比如30秒没有收到某台AGV的任何数据就判定该车离线触发告警并停止下发指令。模块侧的掉线重连也要做硬性配置。我在模块里设置的参数是检测到WiFi断开后立即重连TCP断线后3秒重连重连失败则不断重试同时开启硬件看门狗防止模块内部程序跑飞。这里说一个实操心得模块的硬件看门狗触发后会让模块重启重启再连上服务器一般需要30秒左右这期间AGV通讯是完全中断的。所以不要依赖看门狗去解决频繁掉线问题它只是最后一道保险。真正要做的是把掉线的根因找出来大部分情况下都出在无线覆盖和配置上。4.3 漫游、干扰与信道优化AGV在仓库里跑会从一台AP的信号范围跑到另一台AP的范围这个切换过程叫漫游。家用WiFi的漫游体验差没关系最多是视频卡一下AGV的漫游可能会让一个正在执行中的任务被打断所以漫游策略必须专门调。很多普通WiFi模块不支持快速漫游802.11r在漫游时是“先断开再连接”断流时间在几百毫秒到一秒不等。对于100ms周期的实时指令下发来说这个间隙确实会有影响。我们的应对方案有三个层面一是把模块的漫游触发阈值调低一些让模块“恋家”一点避免在AP边缘频繁切换二是在AGV运行路径规划中尽量避免让AGV长时间停留在两台AP的信号交界处或者在这个区域适当降低AGV的运行速度三是如果模块支持“根据信号强度主动切换”的功能就把切换阈值设置在-75dBm左右低于这个值再切高于这个值就老老实实待在原AP上。干扰问题在2.4GHz频段尤其严重。仓库里的无线扫码枪、工控机无线网卡、甚至是叉车上的蓝牙设备都在抢这个频段。我现场用无线频谱分析仪扫了一遍发现好几个AP的工作通道被附近的蓝牙信标和微波设备压得厉害。解决方式很简单把相邻AP的工作信道错开1、6、11三个非重叠信道尽量分开用同时把AP发射功率调到合适的档位不要把信号开太满造成相邻AP相互干扰。如果仓库不大甚至可以直接改成5GHz频段AGV模块也选支持双频的型号5GHz干扰小、速率高穿墙能力弱一点但AGV都是走视距内的通道问题不大。5. 与AGV调度系统的通讯对接5.1 通信帧结构设计无线链路打通之后调度系统和AGV控制器之间的串口协议就得跑在这条链路上。原车协议是厂商定的我们尽量不动但为了让服务器端能稳定解析我在原有协议外面包了一层通用帧结构专门用来解决“数据从哪来、到哪去、是否完整”的问题。帧结构设计如下帧头用2个字节0xAA 0x55然后跟1个字节的长度域表示负载长度1个字节的帧类型域区分上行状态、下行指令、心跳应答然后是负载数据最后2个字节放CRC16校验。上行状态帧示例AA 55 0A 01 22 00 00 01 2C 01 00 64 58 1E 帧头 长度 类型 负载数据(10字节) CRC16其中负载数据里包含AGV当前坐标X、坐标Y、方向角、速度、电量以及故障码。调度服务器收到这个帧后先做CRC校验再按帧类型分发到对应的解析模块。下行指令帧的结构类似只是类型域不同负载是目标点、速度、动作命令这些。心跳帧则是固定内容如AA 55 00 02 34 12不带负载。帧结构定下来之后还有一个重要决策AGV的状态上报频率。我们用100ms一个周期也就是每秒10帧每帧十来个字节数据量并不大但服务器端解析、存储、画面刷新的压力会成一个台阶。这个频率要根据调度系统的算力来定如果调度服务器性能一般把周期放宽到200ms也行AGV速度不高的话完全够用。5.2 粘包和半包的处理串口数据走TCP传输最经典的问题就是粘包和半包。TCP是面向字节流的它不保证一次recv收到的数据恰好对应一帧串口数据。调度服务器同时管理几十台AGV的连接每路连接都在不停收数据如果不做拆包处理服务器端解析到的一定是乱套的字节流。我在服务器端的接收逻辑是用一个环形缓冲区把收到的字节先全部塞进去然后循环扫描缓冲区按我们定的帧头、长度、CRC规则一帧一帧地拆出来。粘包的情况靠帧头和长度自然切分半包的情况则等下一批数据到达后再拼出来。给一段参考的Python解析框架def parse_stream(buffer): frames [] while True: if len(buffer) 4: break # 查找帧头 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 # 半包等待更多数据 frame_body bytes(buffer[:total_len]) frames.append(frame_body) del buffer[:total_len] return frames这个框架在实际项目里运行很稳定。关键点在于使用缓冲区和循环解析而不是依赖单次recv事件就认为收到完整帧这一点对任何自定义串口协议的无线化改造都适用。5.3 调度系统对接openTCS与自定义双通道谈到AGV调度系统圈子里聊得最多的一个是开源系统openTCS一个是各家自研的调度平台。这个项目里我接触过openTCS做技术验证也对接过自研调度平台两边都说说。openTCS比较适合中小规模、以路径规划和任务分配为核心诉求的场景。它本身有一套相对完整的Kernel和Vehicle Driver框架你可以把你的AGV当作一个“vehicle”接入通过通讯驱动层往AGV发命令、收状态。openTCS底层路径规划用到了A*相关的算法多台AGV并行调度时指令下发频次较高对通讯链路的实时性要求也更严格。把串口转WiFi链路作为openTCS和AGV之间的传输通道需要在openTCS里配置一个自定义通信驱动让它向AGV模块的TCP端口发送协议指令并解析AGV上报的状态帧。自研调度平台的对接方式就更灵活了通常是调度平台提供一个TCP服务端AGV模块的TCP Client连上来平台侧用独立的通讯模块统一管理连接和解析。我的经验是无论用哪套系统都要在调度平台和AGV控制器之间加一个“协议适配层”不要让调度平台直接拼串口协议字节。这样即便以后换了控制器或者换了调度系统改的只是适配层的映射关系不至于推倒重来。5.4 多车并发带宽与调度节奏多台AGV同时在线很多人会担心WiFi带宽不够用。我简单算过一笔账每台AGV以100ms周期上报一个15字节左右的帧每秒就是150字节30台AGV每秒总共也就4.5KB左右的上行数据量下行指令更稀疏偶尔一条任务指令也就是几十字节。这个数据量相对WiFi几Mbps到几十Mbps的实际吞吐率来说是九牛一毛。真正的瓶颈不在于带宽而在于AP的并发连接数。普通企业级AP带几十个终端问题不大但如果是几块钱一个的民用路由器带机量二三十台就可能出现连接不稳定、延迟飙升。所以如果现场AGV数量超过二十台AP一定选企业级的并关注它的推荐带机量参数。调度节奏上也要控制好指令风暴。有的调度算法比如多车路径规划时会在某个节点同时向大量AGV下发指令所有数据包同时涌向AP的下行队列WiFi的竞争机制会让某些包延迟明显增大。我做过一个优化给AP开启WMMWi-Fi Multimedia模式把AGV调度业务的数据包标记为高优先级队列和仓库里的扫码枪、办公数据区分开实测在指令高峰期延迟提高了30%以上的稳定性。这个优化零成本效果却很明显值得所有做AGV无线改造的人试一下。6. 现场问题实录与排查经验6.1 高频故障速查表整个项目实施下来我把遇到过的和同行业朋友分享过的典型问题整理成了一张速查表现场出问题可以直接对着查。故障现象可能原因排查手段与解决串口数据乱码波特率、校验位配置不匹配核对原车控制器串口参数在模块网页重新配置服务器收不到任何数据TCP连接未建立或模块处于AT模式检查模块工作模式是否为透明传输检查服务器IP端口放行模块偶发掉线又自动恢复DHCP租约到期或IP地址冲突改为静态IPDNS静态绑定小车一直在某区域丢包AP覆盖盲区或金属货架遮挡沿路径测试信号调整AP位置或增加补点延迟突然飙升到几百毫秒同频段干扰或某AP带机量过载换信道、开WMM、QoS标记错开非重叠信道重启后长时间连不上服务器模块开机扫描SSID耗时长关闭省电模式缩短TCP重连间隔必要时让模块记忆上次连接两台AGV的数据互相串服务器端按帧头解析逻辑缺陷检查粘包半包处理逻辑按Socket区分数据源6.2 三个典型案例复盘案例一某台AGV一过通道拐弯就掉线。排查了很久最后发现是AGV走到拐弯处时车身正好把天线遮挡在了金属货架和车体之间形成定向屏蔽。解决办法不是在无线参数上动刀而是把天线位置从车体侧面改到了车顶中央信号立马从-78dBm改善到-62dBm。这个案例让我深刻体会到天线位置是无线通讯里最便宜的优化项也是最容易被忽略的优化项。案例二服务器端显示多台AGV状态刷新延迟但ping模块都是正常的。查到最后发现是服务器端程序用单线程在轮询解析所有Socket连接某台AGV的串口日志数据量一上来把整个处理线程阻塞了。优化方式是把每台AGV的连接解析放到独立线程或者使用异步IO问题瞬间消失。这提醒我无线链路没问题的时候要看链路两端的处理程序有没有瓶颈。案例三AGV停在充电桩区域时频繁报“通信超时”。这个位置AP信号其实是满格的但充电桩运行时的电磁干扰非常严重频谱仪上能看到明显的底噪抬升。我把充电区域的AP调到5GHz频段同时把模块也换成双频型号问题解决。如果模块不支持5GHz那么在充电桩区域加装屏蔽措施或者把充电桩和AP的物理距离拉开至少五米也有改善。6.3 改造后的稳定性数据与心得改造上线运行三个月后我拉了一次数据AGV因通讯故障导致的停机次数从改造前平均每周两三次降到了一个月不到一次拖链电缆和滑触线相关的备件费用基本清零。无线链路的平均端到端延迟稳定在15ms左右最差情况跨AP漫游瞬间控制在300ms以内满足最初定下的指标。我个人在实际操作中的体会有三点供大家参考。第一串口转WiFi改造并不是什么高科技它的核心价值在于用最小改动成本把移动设备从物理线缆的束缚里解放出来但前提是无线基础设施必须按工业标准来搭省掉AP部署和信道优化的钱后面会用故障时间加倍还回来。第二模块的选型宁可用工业级也别图便宜用开发板长时间运行的稳定性差异特别大这个钱不能省。第三调试时一定要把原车串口协议吃透一定要设计好服务器端的拆包逻辑这两个环节做好了后面所有问题都好解决做不好无线链路再快也会在数据解析上栽跟头。这批AGV后续计划接入视觉导航和自动充电功能串口转WiFi这条链路从带宽和时延上都是够用的到时候只需要在帧协议里扩展新的帧类型就行。通讯改造虽然只是整个AGV系统里不起眼的一环但它就像人的神经系统平时感觉不到它的存在一旦出问题整个系统都会瘫痪。把这层基础打好后续的智能化升级才能走得稳。