AGV这行干久了你会发现，真正让项目从“能跑”变成“跑得稳”的，往往不是底盘、不是电机、甚至不是调度算法，而是那条看不见的无线链路。AGV无线通信听起来是个基础话题，实际上牵扯到整车的控制闭环、多车调度、场地上位机交互，任何一个环节出现丢包、延迟、断连，都会直接表现为AGV急停、路径偏差、任务失败，严重的时候还会出现两车在交叉口互相等死的情况。这篇文章围绕AGV无线通信这个核心话题，结合我在实际项目中用过的几种主流方案，包括大家熟悉的nRF24L01无线通信模块、工业WiFi、以及AGV调度系统对通信链路的要求，把选型逻辑、协议设计、部署经验和排查方法一次讲清楚。适合正在做AGV样机、准备上调度系统、或者已经在现场被通信问题折磨得头大的工程师参考。
为什么我一上来就强调无线通信？因为AGV调度系统再厉害，A*算法规划得再好，这些决策都建立在一个前提之上：上位机能及时拿到每一台AGV的位置和状态，并且能可靠地把指令发到车上。通信断了几秒钟，调度系统眼中那台车的位置就是假的，基于假位置做的路径规划、交通管理全是空中楼阁。我见过不少项目，前期调车时速度都挺好，一到多车联调就开始各种诡异现象，最后查来查去，问题全出在无线端。
1. 内容整体设计与思路拆解
1.1 AGV为什么不能像遥控车那样随便通信
很多人第一次接触AGV都会有个直觉疑问：无线通信不是很简单吗？家里WiFi、蓝牙、遥控车都在用，为什么到了AGV这就要专门设计一套方案。这个疑问我一开始也有，直到第一次看到AGV在产线上因为通信延迟而撞到安全围栏才彻底明白。
AGV的控制模式和遥控车有本质区别。遥控车的控制链路是人在回路里，信号断了人还能通过眼睛看到车的位置，手动调整；AGV是闭环自主控制，上位机下达“去3号工位取货”这条任务后，车自己规划路径、自己导航、自己停位，中间如果断连，车要么继续执行旧指令直到撞上障碍物，要么立刻急停。急停本身没有问题，但如果频繁急停，AGV的定位精度会受影响，更重要的是整个产线的节拍会被打乱。
这要求AGV的无线通信链路必须具备几个硬性指标：延迟要低，一般要求控制指令端到端延迟在20到50毫秒以内；可靠性要高，丢包率在正常情况下要低于千分之一，关键指令甚至需要重传保障；并发能力要强，一套系统可能要同时管理几十台车，不能因为一台车占用信道导致其他车全部排队。这三个指标是AGV通信方案选型的底层标尺，后续无论选什么模块、设计什么协议，都是围绕这三条展开。
1.2 核心需求拆解：控制流、状态流和调度流
在动手选硬件之前，我习惯先把AGV需要传输的数据分成三类：控制流、状态流和调度流。这个分类看似简单，实际决定了你要用几路无线链路、每路链路要买多大的带宽。
控制流是上位机发给AGV的指令，包括启动、停止、加速、减速、转向、举升、放货等，这类数据对延迟和可靠性最敏感，一个字节的错乱都可能导致设备误动作。状态流是AGV上报给上位机的数据，包括当前位置、电量、任务状态、传感器数据、故障码等，这类数据量不大但对实时性有一定要求，调度系统要靠它更新地图上每台车的位置。调度流是任务层面的交互，比如任务下发、任务取消、路径变更、交通管制指令，这类数据不频繁但绝对不能丢，丢了会导致AGV按错误的任务执行很久才发现。
在实际项目里，控制流和状态流往往走同一个实时通道，调度流可以跟它共用，也可以单独走一路。用nRF24L01这种低成本模块做样机时，我通常把控制流和关键状态流合并到一个通道，调度流通过轮询机制穿插其中；用工业WiFi时，则可以利用多个Socket端口天然分开，调度流走TCP，控制流和状态流走UDP或专用协议。这种分类思考的方式能让后续的协议设计清晰很多，不会出现所有数据混在一起、优先级无法保证的混乱局面。
1.3 方案选型的基本盘：先定预算和场景，再谈技术
每次有人问AGV无线通信选什么方案，我的第一个问题都是：你的现场有多大、多少台车、预算多少、有没有现成的无线网络环境。这四个条件直接决定了技术路线。
如果只是实验室里的两三台样机，场地十几平方米，手头预算有限，那nRF24L01无线通信模块确实是性价比极高的选择，一个模块几块钱到十几块钱，一对就可以打通通信链路，配合简单的自定义协议就能满足基本需求。如果是一两百米见方的仓库、十几台车同时运行、还需要跟WMS系统对接，那就老老实实上工业WiFi，最好用支持漫游的企业级AP，信道规划、切换策略都要提前设计。如果是跨楼层的工厂、室外厂区、AGV会经过电梯井或者金属货架密集的区域，WiFi覆盖容易出现死角，这时候要考虑多个中继点覆盖或者换用4G方案的数传终端作为补充。
方案没有绝对的好坏，只有适不适合。我自己做项目时有个习惯：先画一个通信架构图，标清楚每台AGV、每个基站、上位机之间的数据流向和带宽预估，再回头选硬件。这种做法看着多花了半小时，实际上避免了后续无数次返工，非常划算。
2. 无线通信方案横向对比：从模块级到系统级
2.1 nRF24L01无线通信模块：低成本样机的救命稻草
先聊聊很多自学AGV的人第一次接触的nRF24L01无线通信模块。这颗芯片工作在2.4GHz频段，支持250Kbps、1Mbps、2Mbps三档速率，最远通信距离在开阔环境下配合PA和LNA增益天线可以做到几百米，带屏蔽盖的模块在室内也有几十米的稳定传输能力。最关键的是它支持Enhanced ShockBurst增强型突发传输模式，自带CRC校验和自动重传，这对没有射频功底的工程师来说非常友好。
我最早给AGV样机搭通信链路时，用的就是STM32加nRF24L01+PA的组合。当时没经验，把模块焊在开发板上直接就跑测试，结果距离稍微拉远一点就丢包严重。后来查了芯片手册才注意到，这东西对电源纹波和地平面非常敏感，供电不稳直接导致射频性能断崖式下降，而且天线距离地面、金属物体太近，驻波比会变大，通信距离会缩短到原来的三分之一。换用独立的AMS1117稳压模块给射频部分单独供电、把天线引出到车体外侧并保持竖直之后，通信才稳定下来。
从实用角度看，nRF24L01适合做AGV项目的无线通信入门选型：成本极低、上手快、自己设计协议的空间大。但说实话它的短板也非常明显：它本质上是一颗短距离收发器，不是为多用户并发设计的，多台AGV同时通信时需要上层协议做十分严格的分时调度；抗干扰能力也一般，现场如果有其他2.4G设备，丢包率会明显上升。所以我的定位很清晰：样机验证、功能开发阶段用nRF24L01完全够用，正式上线到生产环境则需要考虑更稳定的工业级方案。
2.2 工业WiFi与无线AP：AGV调度系统的标准答案
到了量产或正式部署阶段，工业WiFi几乎是AGV无线通信的标准答案，因为它和AGV调度系统的配合最成熟。现在主流的AGV调度系统，无论使用什么导航方式，和单车控制器之间基本都走TCP或UDP通信，调度服务器作为服务端，每台车作为客户端，通过WiFi接入同一个局域网，网络层交互简单直接。
工业WiFi方案中，AP的选型和部署位置是整个链路稳定性的核心。很多人以为只要仓库里有WiFi信号就行，实际上AGV对WiFi的要求远不止“有信号”这么简单。AGV是在移动中通信的，当它从AP1覆盖区移动到AP2覆盖区时，客户端需要完成漫游切换，这个切换过程会导致几十到几百毫秒的通信中断。消费级路由器在这个场景下会明显卡顿甚至掉线，而企业级AP配合支持802.11r快速漫游的终端，切换时间可以压缩到50毫秒以内，对控制流来说基本无感。
我在项目中实测下来，影响AGV场地上WiFi稳定性的因素按破坏力排序大概是：AP间信道互相干扰、地面金属货架反射形成多径衰落、AGV本体金属结构遮挡天线、同频段蓝牙和微波设备干扰。解决起来也没有捷径，只能在现场用频谱分析仪扫一遍电磁环境，跟着AGV跑一遍整条路径，在每个点位记录信号强度和丢包率，找出信号较弱的区域再决定加AP还是调整AP位置。说句实在话，AGV通信调试的功夫大部分都花在这种“陪着车走”的土办法上，但效果比任何标称参数都可靠。
2.3 4G、蓝牙、LoRa等其他方案的存在意义
WiFi之外，AGV无线通信还有一些特殊场景会用到其他方案。
4G数传终端适合室外厂区、跨园区、AGV需要长距离作业但无法铺设WiFi覆盖的场景。现在不少户外AGV直接用4G工业路由器做远程通信，好处是无需自建网络基础设施，坏处是公网通信存在延迟抖动和流量费用，控制类报文走公网需要做足断线重连和指令确认机制，时不时的网络抖动是不可避免的现实。我参与过的室外园区AGV项目就是4G加本地WiFi双链路冗余：正常工作走WiFi，WiFi断了自动切到4G保底，虽然4G的延迟偏高，但至少任务不会中断，车能安全停下来等网络恢复。
蓝牙BLE因为传输速率低、实时性差，在AGV上很少作为控制通道使用，最多用来做近距离参数配置、维护口。LoRa适合传输距离要求特别远、数据量特别小的场景，比如户外AGV发送心跳包、位置点信息，但要把控制指令塞进LoRa那点吞吐量里非常吃力，我基本不建议。选这些方案时要清醒地认识到一点：你能接受多大的通信延迟和丢包率，直接决定方案的可行性。AGV真正跑起来之后，通信问题不是网络工程师一句“信号挺好的”就能解决的，现场AGV的每一次急停背后，大概率都站着一条看不见的网络故障。
2.4 一张表看清AGV无线通信方案选型边界
| 方案 | 典型延迟 | 数据传输量 | 多车并发 | 适用阶段 | 主要局限 |
|---|---|---|---|---|---|
| nRF24L01 | 2~10ms | 低 | 需自研分时调度 | 样机验证、小型自制AGV | 抗干扰弱、并发能力有限 |
| 蓝牙BLE | 5~20ms | 低 | 较弱 | 参数配置、近距离维护 | 吞吐小、连接不稳定 |
| 工业WiFi | 10~50ms | 中高 | 强 | 正式部署、多车调度 | 需要AP部署与漫游规划 |
| 4G工业数传 | 50~200ms | 中 | 取决于网络 | 室外无人区、跨园区 | 延迟抖动、流量成本、信号盲区 |
| LoRa | 100ms级别 | 极低 | 一般 | 户外超远距离小数据 | 速率太低，不适合控制指令 |
表格里给的延迟数值是实际项目中的常见量级，不是芯片手册上的理论值，因为现场环境、天线状态、协议开销都会影响最终表现。看完这个表应该能发现，方案之间的差异其实代表了不同的项目定位：做课程设计和小样机，nRF24L01是最快的路径；做正经调度系统，工业WiFi几乎没有悬念。确定了方案大方向，后面的事情才能逐步展开。
3. 基于nRF24L01的AGV无线通信模块实操
3.1 硬件连接与供电：一条血泪换来的布线规范
这一段主要给正在用nRF24L01做AGV无线通信的读者分享实操细节。AGV小车内部空间紧张，电机驱动器、单片机、传感器、无线模块挤在一起，这种环境对射频模块来说其实非常恶劣。我第一版AGV样机就是吃了这个亏，无线模块直接靠近电机驱动板放，跑起来时电机PWM会产生强烈的电磁干扰，通信距离肉眼可见地缩水，甚至出现模块偶尔不响应的情况。
正确做法是三点：第一，nRF24L01模块远离电机驱动和电源模块，至少保持5厘米以上间距，条件允许时用一块小的接地铜箔隔开；第二，给模块单独提供一路干净的3.3V稳压电源，不能在单片机3.3V引脚上直接并联，电机瞬间启动的电流会把电压拉低，模块的射频前端一旦欠压，发射功率会断崖式下跌；第三，天线不能贴着金属底盘摆放，AGV车体基本都是金属结构，天线紧贴金属等于把辐射方向屏蔽了一半，我用的是IPEX接口外接天线，引出到车体外部并垂直向上固定。
接线方面，nRF24L01是SPI接口，和STM32连接需要用到CSN、CE、SCK、MOSI、MISO这几个引脚，注意nRF24L01的IO电压是5V兼容的，但3.3V逻辑更稳，我建议全部用3.3V逻辑连接，避免电平不匹配导致的奇怪故障。连接好之后先用最简单的send-receive测试程序确认通信正常，再接到AGV主控程序里，分步调试能省去很多混合故障排查的时间。
3.2 通信协议设计：帧结构就是AGV通信的生命线
nRF24L01无线通信模块的好处是硬件帮你处理了无线编码、CRC校验和自动重传，但数据链路层的帧结构必须自己定义。设计帧结构时，我踩过一个印象深刻的坑：最开始为了省事，直接定义了一个结构体就往模块里塞，结构体里有uint8_t、uint16_t、float混合排列，然后直接强转成字节流发送。这个做法在小端模式下没有任何问题，但一旦AGV主控换成别的平台，字节序不一致，解析出来的数据全乱了。
从那以后我养成一个习惯：无论什么平台，通信帧都用固定字节数组来定义，用专门的打包和解包函数在协议层和业务数据结构之间转换。AGV的通信帧建议做成这样：帧头占用两个字节，用固定值如0xAA 0x55，接收方通过它来寻找帧起点；接着是帧类型、帧序号、设备地址各一个字节，帧序号用于丢包检测和重传判断；然后是数据域，按业务需求定义长度；最后是校验字节，我习惯用累加和加CRC16双重校验，虽然nRF24L01硬件里已经有CRC了，但应用层的校验能防止数据在单片机内部搬运时出错。
多台AGV在同一个网络里时，设备地址字段尤其重要。nRF24L01支持6个数据管道，设计协议时可以利用不同管道作为不同AGV的专属地址，但同一时刻一个模块只能绑定一个接收地址，多车场景下还是得靠协议层的设备地址区分。我在协议里预留了3位的AGV编号，最多支持8台车，对样机验证来说够了。
3.3 双通道通信设计：控制指令必须和状态上报分开
用nRF24L01做AGV通信，很多人一开始都是一个通道又发指令又传数据，运行一段时间后发现一个致命问题：AGV的状态上报数据量稍微大一点，比如每隔100毫秒上报一次包括坐标、速度和电池电压的数据包，就会把通道的大部分时间占掉，上位机的控制指令被挤在后面排队，等到指令到达时AGV早就开出老远了。
我后来设计的方案是把无线通信任务拆成两个通道：一条主通道传控制指令和ACK，另一条辅助通道传状态数据。nRF24L01一颗模块同一时刻只能在一个频率上工作，所以这里说的两个通道是用同一个硬件模块、在时分复用的逻辑上实现的两个虚拟链路。具体做法是给每个通道分配不同的数据管道和帧类型，主通道的帧优先级最高，发送间隙优先让主通道的指令帧插队，状态数据帧只在没有指令需要发送时才占用信道。
这样设计之后，哪怕状态上报频率增加到80毫秒一次，上位机也能在下发指令后的20毫秒内收到ACK。实际体验下来，AGV的急停指令基本上能实现“按下就停”，这种及时性是AGV现场安全调试的基本保障。对于准备上手nRF24L01做AGV无线通信的朋友，我建议一开始就把这个双通道思想放进协议设计里，后面加功能时会省很多事。
3.4 多车轮询时序：让每台AGV都有公平的发言机会
多台AGV通过同一个nRF24L01网关通信时，最朴素的思路就是轮询：网关按顺序挨个问每台车“你有没有数据要发”，被问到的车才允许占用信道。这个思路没错，但实现细节上有讲究。
我最早做三台AGV联调时，轮询顺序是固定的1、2、3循环，每台车等待时间固定50毫秒。跑起来发现一个问题：如果某台车因为故障一直不回复，网关会傻等满50毫秒才跳到下一台，三台车下来每一轮要浪费150毫秒，整体响应变慢很多。后来加了超时跳过的逻辑，每台车的等待时间从50毫秒压缩到15毫秒，没有回复就自动询问下一台，同时把故障车标记出来延迟到下一轮再处理，整个轮询周期从150毫秒级别降到了45毫秒级别。
轮询帧本身也要设计合理。网关给AGV发一个轮询请求帧，AGV回复里携带它要上报的数据，如果AGV有紧急消息比如急停状态、碰撞传感器触发，可以突破固定上报周期立刻在回复帧中置位。这种“轮询为主、紧急插队为辅”的机制在AGV通信里很实用，既避免了多车同时抢信道造成的冲突，又保证了紧急事件不会被埋没。我用这个方案实现了三台AGV加一个网关的通信系统，场地二十几米见方，正常情况下延迟稳定在15毫秒以内，实测运行两天没有发生过一次通信死锁。
4. 无线通信可靠性工程：丢包、干扰与多车协调
4.1 丢包不是玄学：从“信号很好”到“指令丢了”之间发生了什么
进入正式场地后，AGV无线通信最头疼的就是丢包。我见过最典型的场景是：用手机在场地里打视频电话，画面流畅，站在AGV旁边测WiFi信号也满格，但AGV就是时不时丢失与调度系统的连接。后来才发现，问题不在信号强度，而在空口延迟和重传机制。
AGV在工厂环境里移动时，车体和货架会不断改变周围射频信号的反射路径，形成多径衰落。信号在某些位置会因多路信号相位相反而相互抵消，导致接收端瞬间丢包。这个问题靠增加信号强度解决不了，因为它是相位叠加问题而不是功率问题。真正有用的办法包括：让AGV天线位置尽量高且开阔，避免陷入货架过道形成的“信号波谷”；部署AP时选在通道侧面而不是通道尽头，减少信号被车身遮挡的概率；必要时降低WiFi协商速率，比如把5GHz频段的协商速率限制在较低档，慢一点但更加稳定。
丢包发生后，上层协议要有兜底策略。我给AGV和调度系统之间的TCP链路设置了心跳机制，每500毫秒一次，连续三次心跳没收到回复就主动断开重连，同时在应用层对关键指令增加序列号和ACK确认。实际运行中，一次控制指令最多重发三次，重发都失败就进入安全停车流程，这比无限重发或者直接死等都要可靠得多。
4.2 死锁与错序：多车协调中的两个隐形杀手
AGV调度系统里，无线通信问题换一种面目出现，就变成死锁和指令错序。死锁的典型场景是：调度系统给A车发了“前进到路口1等待”指令，给B车发了“前进到路口2等待”指令，但这两条指令中有一条因为网络延迟在队列里堵住了，A车收到指令到了路口1，B车却还在原地，整个系统僵在那里。
解决这个问题的关键是两条：第一，所有需要车与车协调的逻辑，不要依赖单车通信延迟去隐式同步，调度系统要有一个集中的任务状态机，每台AGV的位置和状态必须以调度服务器为准，AGV本地只做短时缓存；第二，调度系统的指令队列要做超时检测，一条指令在发送队列里超过设定时间没有确认，就要触发重发或者改发别的路线。
错序问题更隐蔽。TCP能保证一台车和一个调度端之间指令顺序，但如果调度系统是多线程分发，或者车端接收线程和应用线程之间没有做防重入处理，先后发出的两条指令可能在执行时就乱掉了，比如AGV先收到“前进”，后收到“停止”，但执行时停止先被执行，前进后被执行，就会导致车冲过指定位置。我在车端做了一个带序号校验的指令缓冲池，只有序号连续的指令才被提交给执行模块，序号跳跃时触发告警并要求调度系统重发当前批次指令，这个问题就彻底被拦在了控制环之外。
4.3 现场部署中的天线与信道规划：细节里藏着稳定性
无线通信系统在现场的稳定性，很大程度取决于部署阶段有没有花时间去规划。我在AGV项目现场总结了一套部署检查套路。
首先是信道规划。以工业WiFi为例，2.4GHz频段有效不重叠信道只有1、6、11三个，相邻AP之间必须分配互不重叠的信道，否则哪怕信号覆盖没问题，AP之间也会互相干扰，AGV漫游时会出现反复切换、通信时断时续的问题。如果现场有多个业务系统共用同一套无线网络，必须在部署前列出所有业务系统的无线频点，规划出一张信道分配表，避免AGV专用的信道被其他业务挤占。
其次是天线角度。全向天线不是“全向”就真的哪里都能收到，天线的辐射方向图是一个苹果形，顶端和底端都有辐射盲区。部署AP时天线应竖直向下，AGV车载天线同样竖直向上，两者轴线平行时信号最好，如果AGV天线被支架横着装，信号强度会差不少。检测方法很简单：拿笔记本电脑装一个无线信号扫描软件，沿着AGV的路径走一遍，记录每个位置的信号强度和噪声底噪，低于阈值的位置就是需要调整的区域。
最后是备份与冗余。AGV项目运行起来后，无线AP、交换机这些网络设备一旦故障，影响的不只是一台车，而是整个调度系统。所以AGV场地的无线网络至少要做到AP冗余配置，一台AP掉线后相邻AP能覆盖其区域；调度服务器和网关之间最好有热备链路，避免单点故障导致全场瘫痪。这些设计虽然平时看不见用处，但出了故障时能保住整个项目。
4.4 通信问题排查方法：从现象反推根因的一条实用思路
AGV无线通信出问题，现象往往五花八门：车明明停在原地，调度系统却显示它在移动；调度端发了几条指令，车只执行了一条；多台AGV同时跑，其中一台频繁急停；又或者一切正常但偶发连接中断。遇到这些问题，我的排查经验是：不要急着改代码，先按“物理层-数据链路层-应用层”的分层思路逐层定位。
物理层排查在AGV场地里也就是用频谱仪或者WiFi扫描工具看现场的信道占用情况，确认有没有强干扰源，比如其他WiFi热点、蓝牙设备、微波炉、基站的意外信号。数据链路层则是看无线终端和AP的协商速率、重传率、丢包率、漫游记录，这些数据在企业级AP后台都能查到。应用层则是看调度系统日志中指令的发送时间、到达时间和ACK时间，关键指标是端到端延迟。
有一个案例我印象很深：一台AGV每次经过某个特定货架通道时必然掉线，查遍AP覆盖和信道都没发现问题，最后是蹲在现场盯着车走了一遍才发现，通道顶部的金属消防管道在特定位置正好把AP和车载天线之间的视距完全挡住了，射频信号只能靠反射绕行，反射路径又多，形成了严重的深度衰落。后来在那个位置加了一个微型中继节点才彻底解决。类似这种问题，纸上推演很难发现，非得到现场跑一遍才知道。
5. 常见问题与排查技巧实录
5.1 一张服务AGV通信的常见故障速查表
| 故障现象 | 可能原因 | 排查方向 |
|---|---|---|
| AGV频繁出现在线/离线抖动 | AP覆盖存在盲区或漫游切换异常 | 沿AGV路径扫描信号，检查漫游阈值设置 |
| 指令下发后AGV响应慢 | 控制链路与状态流争抢带宽 | 拆分指令通道，降低状态上报频率 |
| 多台AGV同时运行时互相干扰 | 信道规划不合理，或nRF24L01轮询超时过长 | 重新规划信道，优化轮询时序与超时 |
| 车到固定位置就丢通信 | 金属结构遮挡、多径衰落明显 | 调整天线位置，必要时增加中继节点 |
| 通信正常但AGV执行错误指令 | 应用层指令序号错乱或缓冲池未防重入 | 检查指令序号校验和执行队列逻辑 |
| 偶发断连后无法自动恢复 | 没有断线重连机制或ACK等待时间过长 | 增加心跳检测与自动重连功能 |
这张表里的每一行，都是我在实际项目中遇到过、处理过的真实问题。排查故障时我会提醒自己：一条条对着处理，不要觉得问题表现不同就重新发明方法论，绝大多数AGV通信故障都能归到上面这几类原因里。
5.2 排查无线问题的一套动作，一步步照着做
当AGV场地出现无线通信问题，我用的是下面这套标准动作，目前看下来基本能把问题定位到具体环节。
第一步，立刻抓住现场的实时状态：调度系统日志、AP后台的无线接入列表、每台AGV的心跳时间戳，先判断是所有车都掉线还是只有个别车掉线。所有车同时掉线说明网关或AP环节出了大问题，个别车掉线则大概率是车辆位置或者车载天线的问题。
第二步，查看无线终端的历史数据：跟着故障AGV的路径重放一遍现场记录，把信号强度、丢包率、漫游次数这些数据和故障时间点对应起来，找出故障发生时刻有没有异常事件，比如漫游切换、信道繁忙、重传率飙升。
第三步，区分软件问题还是射频问题：把AGV停在固定位置，用一台单独的测试终端持续和它通信，如果不跑了仍然丢包，问题倾向于车载射频或现场电磁环境；如果停下来就正常、跑动才出问题，多半是漫游切换或者运动过程中的信号衰减。
第四步，复现并验证修复：针对定位到的原因做修改，然后让AGV在故障路径上反复跑很多遍，确认问题不再出现才算修好。AGV通信问题最怕“修完就不测了”，因为很多问题是间歇性的，跑三趟没事不代表真的解决了。
5.3 从无线通信到AGV调度系统的联动调优
AGV无线通信调到最后，一定会碰到一个绕不开的问题：通信参数和调度系统参数是相互影响的，动一个就得看另一个。
比如调度系统为了防止通信超时导致任务失败，会设置一个比较保守的AGV响应超时时间，比如5秒没有收到状态上报就判定该车离线并启动保护措施。但如果你把通信链路的延迟调低到20毫秒以内，这个5秒的超时时间就明显太长了，一旦某台车真的故障，调度系统要等5秒才能反应过来，这个时间在产线上足够引发连锁问题。我调这类参数时习惯用实际测量的端到端延迟数据来推算：统计正常运行时通信延迟的均值、P95和P99，把超时时间设为P99的5到10倍，既避免误报，又不会让故障反应太迟钝。
跟AGV调度算法配合时，无线通信质量还会直接影响A路径规划的执行效率。A算法算出的路径是一条理论最优路径，但那是在通信理想的前提下。如果现场某片区域无线信号特别差，调度系统给车规划的路径恰好穿过这片区域，车到那里就会频繁掉线，实际效率反而不如绕一段路。我在调度系统里做了“信号热区地图”，把平时记录的通信质量数据映射到场地坐标上，路径规划时对那些信号弱的区域降低权重，尽量引导AGV走通信质量好的路线，效果非常明显。这个思路是比较进阶的用法，但对正在摸索AGV无线通信的人应该能有启发。
6. 写在最后的经验之谈
AGV无线通信这个题目，表面上是选一个无线模块、连好天线、把指令发过去就完事，实际做下来会发现它是一条覆盖了射频硬件、通信协议、嵌入式软件、网络部署到调度系统联调的长链路，哪一环薄弱都会拖累整个项目。我个人的建议是，做AGV通信不要一上来就追求昂贵复杂的方案，先用nRF24L01或者现有的WiFi模块把手里的AGV跑起来，把控制流、状态流、调度流的数据模型理清楚，再逐步往更稳定的工业方案迁移。因为没有跑起来之前，你对通信的所有想象几乎都是错的。
如果有朋友正在用nRF24L01做AGV样机，我想再提醒一句：这个模块对制造工艺和布线很敏感，买模块时尽量选带屏蔽罩、带PA的版本，布线时多花十分钟规划模块位置和地平面，别急着焊接固定，先用杜邦线插着测试模块方向和距离对通信的影响，找到相对最优的位置再用硅胶固定。这个小小的习惯，能在后面的联调里帮你省下大把时间。
最后再说一个小技巧：不管最终用哪种无线方案，一定要在建项目的第一天就把无线通信的日志记录功能设计好，记录每一帧收发的时间戳、序号、重传次数、信号强度。因为这些数据等你在现场面对一台死活不肯听指令的AGV时，价值会超过任何示波器和频谱仪。
