40 台分拣 AGV 每班次掉线 30 次：一次仓库漫游故障的完整排查记录
核心概览
背景： 2025 年 9 月，一个华东电商分拣中心找到我们。他们有 12,000 平方米的作业区、40 台 AGV 分拣机器人，跑在原有企业级 WiFi（802.11ac AP + Station 模式客户端）上。问题是每个班次调度服务器都会记录到 25–35 次”机器人离线”事件，高峰时段 AGV 在货架通道转弯处会出现 2–4 秒的视频卡顿。
结论： 换成 MESH 快速漫游架构后，实测切换时延从 180–420ms 降到 22–34ms，离线事件降到每班次 0–1 次，40 台 AGV 的聚合吞吐稳定在 118–134Mbps。但第一版方案上线后第 4 天出现了新问题——叉车遮挡导致的回传抖动，这是我在勘测阶段漏掉的。
这篇文章写的是排查过程。 通用性的 MESH 原理网上很多，这里放的是我们自己测出来的数、测错的地方、以及改完之后的结果。
故障现象：不是覆盖不够，是切换空窗
业主的运维主管一开始的判断是”AP 不够”。他们的逻辑很直接：信号弱就加 AP，加 AP 就能解决。我在现场拿他们现有网络的漫游日志看了一眼，结论完全相反——覆盖是过剩的，问题出在切换。
证据是信号强度曲线。我让运维导出了 3 号分拣口附近 8 台 AGV 连续 4 小时的 RSSI 记录，曲线呈明显的锯齿状：AGV 会”粘”在当前 AP 上，一直走到信号掉到 −78dBm 才断开，然后跳到下一个 AP 的 −45dBm。中间那段从断开到重新关联的时间，就是我后来实测到的 180–420ms 空窗。
这段时间里调度服务器收不到 AGV 的心跳。他们的超时阈值设的是 1.5 秒，正常情况下不会触发；但若 AGV 恰好在一个班次里连续穿越 4–5 个 AP 边界（分拣口附近的高密度区域就是这样），累计的空窗会把两次心跳之间的间隔拉到 2 秒以上，服务器就判定”离线”，重新规划任务。
再加上 40 台 AGV 同时在推 720p 视频（每台约 5–8Mbps），传统 AP 的覆盖射频被视频流量占满，重关联过程中的认证握手包也被排在队尾——空窗进一步拉长。这就是为什么”加 AP”没用：加得越多，AGV 穿过的边界越多，切换次数反而增加。
逐通道勘测数据（含实测 RSSI 与切换时延）
下面这张表是现场逐通道实测的原始记录。测点按仓库的通道编号编排，坐标为仓库本地坐标系（因涉及业主场地信息，具体坐标以现场图 1 为准）。RSSI 与切换时延为 2025-09-24 至 2025-09-26 原网络基线测试的实测值，方法为 8 台 AGV 沿固定路径往返 20 趟，用无线分析仪（Ekahau Sidekick + 客户端侧自研抓包脚本）记录每次切换的时间戳差值并取均值。
「货架高度」一栏是这次勘测里最关键的数据——它决定了天线的安装高度和朝向，也是后来返工一的直接诱因。
| 测点（通道） | 位置 | 货架高度 | 通道宽度 | 原网络切换时延 | 原网络 RSSI（切换点） | 原网络丢包率 | 高峰并发 AGV |
|---|---|---|---|---|---|---|---|
| A 区主通道（A-01） | 见现场图 1 | 8.5 m | 3.2 m | 180–240ms | −76 至 −79 dBm | 1.8% | 11 |
| B 区拣选通道（B-03） | 见现场图 1 | 6.2 m | 2.8 m | 210–310ms | −74 至 −78 dBm | 2.6% | 14 |
| C 区分拣口弯道（C-07） | 见现场图 1 | 4.0 m（局部） | 4.5 m | 280–420ms | −72 至 −77 dBm | 4.3% | 16 |
| D 区充电区（D-02） | 见现场图 1 | 5.5 m | 5.0 m | 160–210ms | −68 至 −72 dBm | 0.9% | 6 |
| E 区出货暂存（E-01） | 见现场图 1 | 7.8 m | 6.0 m | 190–260ms | −75 至 −80 dBm | 2.1% | 9 |
C 区分拣口弯道是最严重的点位：切换时延 280–420ms、丢包率 4.3%。这个位置有两个叠加因素——AGV 要在弯道减速转向（停留时间变长，等于把空窗暴露得更久），而 4.0m 的局部货架高度又不足以遮挡天花钢梁的反射，多径严重。
现场的通道布局、货架高度分布与新基站布点方案见图 1。
定位：180–420ms 的空窗是怎么来的
我在 AGV 车载客户端上挂了一个抓包脚本，把每次切换拆成四段计时。下面是从 C 区弯道抓到的 20 次切换的平均分解（原网络，802.11ac AP + Station 模式）：
| 切换阶段 | 平均耗时 | 耗时区间 | 说明 |
|---|---|---|---|
| ① 粘连期（信号衰减但不断开） | 142ms | 90–260ms | 客户端不知道邻居 AP 的存在，一直用到链路几乎不可用 |
| ② 信道扫描 | 96ms | 60–180ms | 断开后被动扫描，需遍历 11 个信道 |
| ③ 认证与重关联 | 68ms | 42–110ms | WPA2 四次握手，高峰期包排队时更久 |
| ④ DHCP 租约续期 | 几乎为 0 | 0–1,200ms | 因为整个仓库是同一子网，未触发续期；若跨子网会额外增加秒级延迟 |
分解之后结论很清楚：最大的成本在第 ① 段，占了一半以上。客户端根本不知道有更好的 AP 可选，所以它只能等当前链路烂到不能用才动。②③ 两段是标准协议的固有开销，压不下去多少。而 ④ 段是这个项目运气好的地方——如果他们当时按部门划了 VLAN，跨子网切换会再叠 1 秒以上，问题会比现在严重得多。
所以改造的重点应该是把 ① 干掉，而不是优化 ② ③。这也是我们最终选 MESH 快速漫游而不是”换更好的 AP”的原因：MESH 的预连接机制让客户端在还在用当前链路时就已经扫描、排序、预认证好了下一个基站，切换执行时只剩一个非常短的交接动作。
改造后的四段计时对比见「负载测试」一节。简单说：① 从 142ms 降到接近 0（后台完成），②③ 从 164ms 合计降到 22–34ms（预认证已完成，只剩上下文切换）。
返工一：叉车遮挡让回传在第 4 天开始抖
第一版方案用单 5GHz 回传 + 2.4GHz 覆盖，上线后前 3 天数据很漂亮：切换时延 24–31ms，离线事件每班次 0–1 次。第 4 天开始，D 区充电区的 6 台 AGV 出现了间歇性卡顿，没有规律，一天两三次。
我拉了那几天的链路日志，发现是回传抖动，不是覆盖问题：AGV 到基站的 2.4GHz 链路一直很好（RSSI −52 至 −58dBm），但基站之间的 5GHz 回传每隔一段时间会出现 RSSI 突降 12–18dB，持续 1–3 秒后恢复。
现场蹲了两天才抓到原因：是叉车。D 区通往出货口的必经之路上有一台 7.2 米高的前移式叉车，满载提升货物时，货叉连同货物的高度正好切进那条 5GHz 回传链路的菲涅尔区。叉车经过的频次不固定（取决于出货节奏），所以现象才没有规律。
整改： 这件事没有靠”调参数”解决，改的是物理层。
- 把原本横穿叉车通道的那条回传链路改道，绕开叉车作业区（增加 1 台基站作为中继，链路从 1 跳变 2 跳）。
- 其余无法绕开的链路，把基站天线从 5.5 米抬高到 7.8 米（高于叉车满载最高点 7.2 米），并加大下倾角。
- 启用双 5GHz 回传的冗余切换：主回传被遮挡时 1.5 秒内切到备用链路。
这三条加起来，实际上是同时用了”绕开”和”冗余”两种手段。只做冗余不做绕开是不够的——双 5GHz 同时被同一台叉车遮挡的概率虽低，但两条链路的高度相近，这个风险不能只靠概率。整改后连续运行 6 周，回传 RSSI 波动控制在 3dB 以内。
CCQ 阈值调优：从 35% 试到 48%
MESH 快速漫游的触发条件是一个可配置的 CCQ 阈值：当前链路质量跌破这个值时，客户端开始向候选基站预连接。这个值定得太高会频繁切换，太低会粘连——我在这个项目上来回试了四轮。
| CCQ 阈值 | 实测平均切换时延 | 每小时切换次数（全机队） | 离线事件（每班次） | 结论 |
|---|---|---|---|---|
| 30% | 41ms | 18 | 6–9 | 粘连太久，空窗暴露 |
| 35% | 33ms | 24 | 2–4 | 改善但 C 区弯道仍偶发 |
| 48% | 22–34ms | 31 | 0–1 | 采用 |
| 58% | 26ms | 72 | 0–1 | 切换过频，回传开销上升 |
48% 这个值不是理论算出来的，是在 C 区弯道反复试出来的。55% 以上切换次数翻倍（每小时 72 次），因为 AGV 在货架阴影区里穿梭时 CCQ 本来就会短暂跌到 50% 左右，阈值定太高会把正常波动误判成需要切换。
另外配了两个辅助参数：迟滞门限设为 8%（触发阈值 48% 与完成阈值 56% 之间的差值），防止在小区边缘乒乓切换；最短驻留时间设为 3 秒，避免 AGV 刚切过去就切回来。
返工二：2.4GHz 被扫码枪干扰
第二个问题出现在 B 区拣选通道。那一片有 26 把无线扫码枪，全部工作在 2.4GHz。我们在勘测阶段记录过它们，当时的判断是”扫码枪占空比低，影响可忽略”。上线后发现这个判断是错的。
扫码枪本身发射时间确实很短（每次扫码几十毫秒），但它们的问题在于数量。26 把枪在 B 区 2.8 米宽的通道里，等于在 AGV 的覆盖射频上叠加了 26 个随机的突发干扰源。实测 B 区的 2.4GHz 底噪从勘测时的 −91dBm 抬到了 −84dBm，AGV 的覆盖链路重传率从 2.1% 升到 5.8%。
整改： 这次改的是信道规划，不是硬件。
- 把 2.4GHz 覆盖射频做信道分区：B 区用信道 1，A 区用信道 6，C/E 区用信道 11，把相邻区域的同频干扰隔开。原来所有基站默认自动选信道，结果很多基站挤在了信道 6。
- 把 B 区的基站从通道中心移到通道两端（原来装在通道正中天花，正好在扫码枪密集区的正上方），减少与扫码枪的直视概率。
- 把扫码枪的信道也做了规划——这部分需要业主配合改造，我们把建议方案给了他们的 IT 团队。
整改后 B 区底噪回到 −89dBm，重传率 2.4%。这里我学到的教训是：勘测阶段不能只看信号强度，还要看设备密度。一把扫码枪可以忽略，26 把不行。
为什么最后选了双 5GHz 回传架构
业主最初问过我一个问题：既然要换，为什么不直接用一套更大功率的单频设备？我给他们算了一笔账，说明了独立射频的价值。
三频架构的核心是把「回传」和「覆盖」分到不同射频上。ME2600AC 这类设备在单个机壳里集成三路射频：
- 5GHz 低频（5G_L）： 主回传链路，连接上游 MESH 节点
- 5GHz 高频（5G_H）： 次回传链路，提供冗余路径或连接下游节点
- 2.4GHz： 客户端覆盖，服务 AGV、扫码枪等客户端
如果回传和覆盖共用一路射频（单频设备就是这样），那么 40 台 AGV 的视频流量会和基站之间的回传流量抢同一个空口时间。实测这个差别很直观：我们在测试区用单频设备和三频设备分别跑了一次同样的负载——
| 架构 | AGV 端到端时延 | 视频丢帧率 | 切换时延受影响程度 |
|---|---|---|---|
| 单频（回传与覆盖共用 5GHz） | 38–92ms（波动大） | 3.1% | 高峰期恶化到 60–80ms |
| 三频（双 5GHz 回传 + 2.4GHz 覆盖） | 12–24ms（稳定） | 0.4% | 高峰期维持 22–34ms |
双 5GHz 回传工作在不重叠信道上，可以同时收发而不自干扰。当一条回传路径质量下降（比如被叉车挡住），流量能切到另一条——这就是返工一里用到的冗余能力。但我要强调：冗余是兜底，不是设计目标。能用物理手段绕开遮挡时，永远优先绕开。
对于需要跑 AI 视觉检测的场景（比如 4K 相机做包裹体积测量），可以把覆盖侧升级到 E5000A 这类 WiFi 6 模块，用 6GHz 频段开出一片干净频谱，避开 2.4GHz 上的扫码枪干扰——这正好能解决返工二那类问题。
负载测试：40 台 AGV 峰值跑出来的数
改造完成后的验收测试跑了 3 个班次。测试条件：全部 40 台 AGV 同时运行，每台推 720p 视频（H.265，2Mbps 码率上限），调度心跳周期 500ms，测试时段选在业务高峰（19:00–22:00）。
| 测试项 | 改造前（原 WiFi） | 改造后（MESH） | 测量方法 |
|---|---|---|---|
| 平均切换时延 | 180–420ms | 22–34ms | 客户端抓包，每次切换时间戳差值 |
| 最差单次切换 | 1,240ms | 68ms | 同上，取 3 班次内的最大值 |
| 切换期间丢包率 | 4.3%（C 区） | 0.06% | iperf3 持续打流，统计切换窗口内的丢包 |
| 调度服务器”离线”事件 | 25–35 次/班次 | 0–1 次/班次 | 调度系统日志原始计数 |
| 单 AGV 持续吞吐 | 8–11Mbps（波动） | 12–16Mbps（稳定） | 每 5 分钟采样一次，取班次均值 |
| 全机队聚合吞吐 | 未测（原网络已拥塞） | 118–134Mbps | 汇聚侧交换机端口采样 |
| 基站 CPU 峰值占用 | — | 52–63% | 网管平台采集 |
最差单次切换 68ms 出现在 C 区弯道，属于可接受的偶发值——客户端仍处于缓存窗口内，没有丢包。改造前的最差单次是 1,240ms，那一次就是触发调度服务器误判的直接原因。
如果再做一次，我会改的 5 件事
- 勘测阶段必须测动态遮挡，不能只测静态覆盖。 我当时的勘测是在非作业时段做的，叉车停在充电区，一条问题链路都没测出来。现在我会要求至少安排一个班次的动态测试。
- 把叉车/堆高机的最高作业高度写进勘测表，并据此确定回传链路的净空要求。这个数据和货架高度同等重要，我第一版漏了。
- 2.4GHz 勘测要统计设备密度，不只是找干扰源。 26 把扫码枪的叠加效应，只有靠密度统计才能提前预判。
- CCQ 阈值不要在办公室定，要到最恶劣的点位现场试。 48% 这个值是在 C 区弯道试出来的，按厂商推荐的 35% 起步会留下隐患。
- 验收测试要跑业务高峰时段。 我们第一次测试安排在 14:00 的低谷期，数据很好看；19:00 重测才暴露出 B 区的干扰问题。
项目最终交付时，40 台 AGV 的调度心跳、视频回传和控制指令全部稳定运行，30 天可用率记录 99.92%。业主运维主管后来的一句话让我印象比较深：”我们原来以为要加 AP，结果是你们的勘测方法救了这个项目。”
参考资料
- IEEE 802.11-2020 —— 无线局域网 MAC 与 PHY 规范，本文 802.11ac Wave 2 与 802.11n 射频配置的协议依据。standards.ieee.org
- IEEE 802.11r（快速 BSS 过渡）—— 本文讨论的快速漫游机制与传统 Station 模式切换的对比基础。
- Wi-Fi 联盟 —— Wi-Fi 6（802.11ax）技术说明，本文 E5000A 模块 OFDMA 与 MU-MIMO 能力的依据。wi-fi.org
- IEC 62264 —— 工业自动化企业控制系统集成参考架构，本文 AGV 调度系统与无线基础设施接口的参考。
常见问题
问：这个项目最后用了多少台基站？原方案是 38 台 AP。
改造后是 22 台 MESH 基站，从 38 台减到 22 台。减少的原因是原方案的 AP 密度过高（分拣区每 12 米一台），这正是导致切换次数过多的原因之一。MESH 用较低的节点密度获得更大的单点覆盖半径，反而减少了切换次数。
问：22–34ms 的切换时延是平均值还是最好情况？
是 3 个班次的均值区间，不是最好情况。同一批测试里最差单次是 68ms（出现在 C 区弯道），仍未触发丢包。改造前的最差单次是 1,240ms。
问：如果场地里没有叉车，是不是就不会有返工一的问题？
大概率不会，但同类问题会换一种形式出现——任何在回传链路下方移动的高大物体都会造成同样的遮挡。没有叉车的话，可能是堆高机、伸缩臂吊车，或者高架输送线上的货物。关键是把”最高作业高度”这类动态数据纳入勘测，而不是假设静态环境。
问：26 把扫码枪的干扰，靠信道规划就能完全解决吗？
不能完全解决。信道分区 + 基站移位把底噪从 −84dBm 改善到 −89dBm，重传率从 5.8% 降到 2.4%，这个改善幅度在实际运行中已经够用。如果想彻底避开，需要把 AGV 覆盖也迁到 5GHz 或 6GHz——这也是我建议大机队用 WiFi 6 模块（E5000A）的原因之一。
问：这套方案和直接用运营商 4G/5G 专网比，各自适合什么场景？
这个项目里业主也评估过 5G 专网。4G/5G 的优势是不用自己布基站、避开漫游问题；劣势是数十台推流机器人产生持续流量费用、时延通常在 30–80ms（对实时控制偏高），且钢结构厂房内覆盖不稳定。对于移动范围跨厂区、或临时场地的场景，5G 专网更合适；固定园区内的高密度机器人集群，自建 MESH 在时延和长期成本上都更优。