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加nRF24L01PA的组合。当时没经验把模块焊在开发板上直接就跑测试结果距离稍微拉远一点就丢包严重。后来查了芯片手册才注意到这东西对电源纹波和地平面非常敏感供电不稳直接导致射频性能断崖式下降而且天线距离地面、金属物体太近驻波比会变大通信距离会缩短到原来的三分之一。换用独立的AMS1117稳压模块给射频部分单独供电、把天线引出到车体外侧并保持竖直之后通信才稳定下来。从实用角度看nRF24L01适合做AGV项目的无线通信入门选型成本极低、上手快、自己设计协议的空间大。但说实话它的短板也非常明显它本质上是一颗短距离收发器不是为多用户并发设计的多台AGV同时通信时需要上层协议做十分严格的分时调度抗干扰能力也一般现场如果有其他2.4G设备丢包率会明显上升。所以我的定位很清晰样机验证、功能开发阶段用nRF24L01完全够用正式上线到生产环境则需要考虑更稳定的工业级方案。2.2 工业WiFi与无线APAGV调度系统的标准答案到了量产或正式部署阶段工业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双链路冗余正常工作走WiFiWiFi断了自动切到4G保底虽然4G的延迟偏高但至少任务不会中断车能安全停下来等网络恢复。蓝牙BLE因为传输速率低、实时性差在AGV上很少作为控制通道使用最多用来做近距离参数配置、维护口。LoRa适合传输距离要求特别远、数据量特别小的场景比如户外AGV发送心跳包、位置点信息但要把控制指令塞进LoRa那点吞吐量里非常吃力我基本不建议。选这些方案时要清醒地认识到一点你能接受多大的通信延迟和丢包率直接决定方案的可行性。AGV真正跑起来之后通信问题不是网络工程师一句“信号挺好的”就能解决的现场AGV的每一次急停背后大概率都站着一条看不见的网络故障。2.4 一张表看清AGV无线通信方案选型边界方案典型延迟数据传输量多车并发适用阶段主要局限nRF24L012~10ms低需自研分时调度样机验证、小型自制AGV抗干扰弱、并发能力有限蓝牙BLE5~20ms低较弱参数配置、近距离维护吞吐小、连接不稳定工业WiFi10~50ms中高强正式部署、多车调度需要AP部署与漫游规划4G工业数传50~200ms中取决于网络室外无人区、跨园区延迟抖动、流量成本、信号盲区LoRa100ms级别极低一般户外超远距离小数据速率太低不适合控制指令表格里给的延迟数值是实际项目中的常见量级不是芯片手册上的理论值因为现场环境、天线状态、协议开销都会影响最终表现。看完这个表应该能发现方案之间的差异其实代表了不同的项目定位做课程设计和小样机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车收到指令到了路口1B车却还在原地整个系统僵在那里。解决这个问题的关键是两条第一所有需要车与车协调的逻辑不要依赖单车通信延迟去隐式同步调度系统要有一个集中的任务状态机每台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时价值会超过任何示波器和频谱仪。