企业官网建设流程全解析

做仓储自动化这些年，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延迟突然飙升的尴尬情况。

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以内。

第三步，验证多车并发的延迟变化。把现场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开启WMM（Wi-Fi Multimedia）模式，把AGV调度业务的数据包标记为高优先级队列，和仓库里的扫码枪、办公数据区分开，实测在指令高峰期延迟提高了30%以上的稳定性。这个优化零成本，效果却很明显，值得所有做AGV无线改造的人试一下。

6. 现场问题实录与排查经验

6.1 高频故障速查表

整个项目实施下来，我把遇到过的和同行业朋友分享过的典型问题整理成了一张速查表，现场出问题可以直接对着查。

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系统里不起眼的一环，但它就像人的神经系统，平时感觉不到它的存在，一旦出问题，整个系统都会瘫痪。把这层基础打好，后续的智能化升级才能走得稳。