这不是我第一次给汽车车间的 AGV 项目做无线组网了但这台广汽传祺的项目的确有点典型性。车间里跑的是海康的 AGV 小车调度要求是不允许无线网络出现毫秒级闪断而现场又是金属货架、叉车穿梭、变频设备杂七杂八的电磁环境。配合斯普莱的工业无线设备把整张网搭起来的时候我确实踩了不少坑也积累了很多一手经验。如果你正在做 AGV 落地项目或者要给厂区做工业无线覆盖这篇文章从需求拆解、组网实施、AGV 视觉系统调试到现场排障基本都能找到能直接抄作业的细节。尤其是 AGV 小车无线通信和相机取流这一块很多雷区文档里不会写但项目里一定绕不开。1. 项目背景与需求拆解1.1 车间物流场景为什么这条线非上 AGV 不可广汽传祺这个车间主要是总装线边物料配送零部件种类多、配送频次高人工开牵引车来回跑效率其实并不低但最大的问题是节奏不可控。配送员的行走路径、停靠时间都带随机性线边一旦缺料整条产线就得停。上了 AGV 之后最关键的变化是把“人找料”变成了“料找人”系统按节拍自动配送车间里少了很多人为干预也更好管。项目规模大概是十几台海康的潜伏顶升式 AGV负载 500kg 到 1吨 不等负责几个重点工位到缓存区的循环配送。AGV 属于无人搬运设备但它并不是全自主的整个车队的协同、任务分配、交通管制全靠中控调度系统而中控调度和 AGV 本体之间的通信通道就是工业无线网络。可以说AGV 跑得顺不顺一半看本体一半看网络。1.2 无线组网的边界条件有线敷设为什么不行有人可能会问车间里为什么不用有线AGV 一直移动通信线缆不可能跟着车走所以无线是唯一选择。但这个无线的要求比办公 WiFi 高得多具体来说有这么几个硬指标。第一是漫游切换不能断AGV 在车间里不断移动无线终端会在多个 AP 之间切换切换过程如果超过几百毫秒调度消息就会重发或者超时AGV 可能会急停。第二是抗干扰必须强车间里有电机、变频器、行车、无线扫码枪2.4GHz 频段几乎全是干扰源。第三是覆盖要完全无死角哪怕一个角落信号差AGV 走到那里就可能掉线掉线后安全机制会触发停车后面一排车全堵上。我们这次选的是斯普莱的工业无线纯工业级方案在设计时就能满足快速漫游和抗干扰这两条核心要求。后面施工作业的时候很多细节也是在为这两个目标服务。1.3 整体方案与角色分工整个项目可以拆成几个层次来看最底层是 AGV 小车本体包括底盘、顶升机构、安全雷达、导航传感器中间层是通信层包含车载无线终端、车间 AP、AC 控制器以及相关的工业以太网交换设备上层是调度系统负责任务下发、路径规划、交通管理。海康在这个项目里不只是提供 AGV 本体调度系统也是海康的我们厂商负责把斯普莱无线网络和它们对接起来并且在调试阶段帮 AGV 系统解决通信层面的问题。这种分层的思路很重要。很多项目出问题最后都是各层之间互相甩锅AGV 厂家说网络不行网络厂家说 AGV 终端有问题。但其实大家都在同一个物理环境里每一层都要把对应的参数调扎实了整体系统才能稳定跑起来。2. 海康 AGV 系统核心解析与视觉方案2.1 AGV 本体的导航方式与传感器配置海康 AGV 的导航方式有很多种二维码导航、色带导航、激光 SLAM、反光板导航都有。这次项目用的是二维码导航为主激光 SLAM 做辅助避障和精确定位的方式。二维码导航的原理其实并不复杂就是在地面按照规定间距贴二维码地标小车底部有一个向下拍摄的相机每经过一个地标就读一次码通过码内的坐标信息以及相对偏移量来确定当前位置。这里有一个容易被忽略的细节导航相机读取二维码的精度直接决定了 AGV 停位精度。海康 AGV 的停位精度一般在 ±10mm 以内但这是在二维码完好、相机曝光正常的前提下。车间里叉车经常压地面二维码很容易磨损所以现场要准备备用码贴并且定期检查地标耗损情况。激光 SLAM 这块更多是用于动态避障和环境感知。车前后布置了激光雷达可以实时扫描周围环境检测到行人或者障碍物会自动降速或者停车。车间环境是动态变化的所以 SLAM 的定位更新频率要求很高这也是小车对通信丢包比较敏感的另一个原因——调度系统需要实时读取每台车的位置状态来做交通管制。2.2 海康相机与 VM 视觉软件在 AGV 里的角色热词里有很多人在搜海康 vm 软件、海康 visionmaster其实在这个项目里VM 视觉软件也有用到但不是用在 AGV 本体的导航相机上而是用在线边工位的视觉对接环节。我们在几个关键工位布置了海康工业相机用来做物料到位检测和工件类型识别。相机采集到图像后通过海康 VisionMaster 视觉软件做模板匹配和特征识别然后将结果以 IO 信号或者 TCP 数据的方式发送给 AGV 调度系统。比如某一个工位送来的托盘底部有两个不同形状的定位销AGV 顶升之前需要先确认托盘型号是否匹配这时候视觉系统就会拍照识别匹配好才允许顶升。海康工业相机这块项目里用的主要是千兆网接口的型号。配套的 MVSMachine Vision Software软件是海康相机的官方工具用来改相机 IP、调曝光、测触发。调试时我们经常会用到 RTSP 取流来看实时画面海康工业相机的 RTSP 地址格式大概是rtsp://用户名:密码相机IP:554/Streaming/Channels/101用 VLC 或者海康播放器都能拉流这个方法在调机时特别方便不用打开完整客户端就能快速检查画面是否正常。2.3 相机 IO 触发与外部设备联动AGV 对接的时候相机拍照的触发方式很关键。车间里速度要求高不能靠软件触发慢慢来我们用的基本都是硬件触发。海康工业相机尾部有 GPIO 接口通过 IO 线连接到光电传感器或者近接开关上。当托盘到位、光电信号发出后会直接触发相机拍照不需要经过上位机中转这样延迟能做到几毫秒级别。IO 接线这块我得单独提醒一下海康工业相机的 IO 接口有输入和输出输入一般用来接外部触发信号输出可以用来给光源或者 PLC 发信号。接线时要注意共地问题相机的 GND 必须和传感器的 GND 接在一起否则信号永远不会触发甚至可能烧掉相机 IO 口。我们现场就吃过这个亏之前有个工位触发不稳定排查了半天发现是传感器供电和相机供电不是同一个开关电源地电位不一致导致的。后来把供电统一到一个电源下问题立刻消失。另外视觉控制这块现在海康也有专门的视觉控制器比如热词里提到的 MV-VB2100-120G 这类设备。本质上是一台带 GPU 的工业控制主机预装了海康的视觉软件环境可以同时接多路相机跑深度学习模型。如果后续要做的小件错漏装检测、瑕疵识别这类更复杂的应用直接上视觉控制器会比用普通工控机省心很多因为驱动、运行库、授权这些都是预装好的不用自己去折腾。2.4 调度系统与通信接口设计海康的 AGV 调度系统一般跑在一台服务器上通过无线网络与每台 AGV 保持心跳连接。心跳间隔一般 100ms 到 500ms 不等这次项目里我们设定的是 300ms。如果连续几个心跳周期没有收到小车的响应调度系统就会把小车的状态标记为异常触发急停或者重新下发任务。这里对无线网络的挑战就来了——网络延时抖动和丢包会直接导致心跳超时。斯普莱的无线方案里有专门针对工业实时通信做的 QoS 策略我们给 AGV 的通信数据设置了最高优先级队列确保在无线空口资源争抢时AGV 的控制数据优先发送。这一点在办公 WiFi 里基本看不到但在工业项目里是保命的设计。调度系统和车间 MES 的对接也是这个项目的重头戏。AGV 不是孤立工作的它需要知道什么时候哪个工位要料这就需要从 MES 拿到生产计划。对接方式一般是中间数据库或者 API 接口。我们现场用的是中间库加 WebAPI 双重方式MES 把任务写入中间库表调度系统轮询读取同时关键状态变更通过 API 实时推送。整体运行下来MES 到调度再到 AGV 的链路延迟控制在 1 到 2 秒内对线边配送来说完全够用。3. 斯普莱工业无线组网设计与实施3.1 无线架构选型ACAP 与 Mesh 的取舍斯普莱的工业无线组网方式其实有两种常见的思路一种是 ACAP 的集中式组网另一种是 Mesh 自组网。两种各有适用场景但我们这次直接选了 ACAP。原因很简单AGV 运动轨迹是固定的场景也是固定的完全不需要 Mesh 那种动态自愈的网络拓扑。ACAP 模式下AP 通过有线连接到交换机AC 控制器负责统一管理所有 AP做漫游决策、频段引导、负载均衡。这种方案每个 AP 都有独立的网线回传带宽稳定不需要像 Mesh 那样通过无线链路级联无线空口资源浪费少时延也低得多。Mesh 组网适合什么场景呢比如老厂房改造不方便布线或者临时性的巡检机器人项目AP 点位不固定。但大规模、长期运行的 AGV 项目我建议都老老实实上 ACAP。Mesh 一旦出现多跳时延会成倍增加AGV 调度对时延很敏感多跳网络的风险不值得冒。3.2 AP 点位规划与覆盖验证斯普莱的 AP 点位规划是整个项目里投入精力最多的部分之一。工业环境不比办公室AP 装在哪里、天线朝哪个方向直接影响覆盖质量。第一步是拿 AGV 的行驶路径图把每一条线路标出来优先保证路径上的覆盖而不是整个车间所有区域都无死角覆盖。比如 AGV 不会去的地方信号差点没关系。第二步是考虑 AP 之间的间距一般室内工业环境下单个 AP 的覆盖半径可以做到 30 到 50 米但实际部署时我们通常会加密布置把覆盖半径控制在 20 到 30 米左右。因为车间里金属货架密集信号衰减快靠理论覆盖半径来布点一定会翻车。天线选型上现场用了全向天线和定向天线混合的方式。通道宽敞、AGV 直线行驶的区域用全向天线覆盖走廊拐角、货架深处这些位置用定向天线加强特定方向的信号。AP 的安装高度我们也做了严格规定一般是 3 到 4 米左右天线朝下倾斜 15 到 30 度这样做是为了让信号主瓣覆盖地面区域的 AGV。天线水平安装或者朝上覆盖效果都会大打折扣。布点完成后必须做覆盖验证不能只看 AP 上线就完事。我们用平板电脑配合测试软件沿着 AGV 行驶路径走一遍记录每个位置的信号强度、信噪比和漫游切换行为。指标一般要求信号强度不低于 -65dBm信噪比不低于 25dB。因为 AGV 车载无线终端的发射功率是有限的如果 AP 端信号可以但车载终端发射功率不够实际数据还是会丢包。双向信号质量都要确认好单看一头没用。3.3 信道规划与抗干扰处理工业现场的信道规划比写字楼难太多了。我们做现场频谱调研时2.4GHz 频段扫出来全是变频器、伺服驱动器、流水线上其他无线设备的底噪。最后我们把 AGV 的无线网络全部布在 5GHz 频段2.4GHz 完全放弃。5GHz 频段也不是随便用需要做信道隔离。斯普莱的 AP 支持多个 5GHz 信道我们选取了几个互相不重叠的信道相邻 AP 之间错开使用避免同频干扰。同时关闭了 AP 的自动信道选择功能改为手动指定。很多人会图省事开自动但在动态干扰源较多的车间里自动信道可能会频繁跳变跳变瞬间无线终端会掉线重连AGV 就停了。手动固定信道虽然前期规划麻烦一点但运行稳定度完全不在一个量级。另外一个很重要的优化是关闭低速率协议。无线设备都有一个速率集从几 Mbps 到几百 Mbps 不等。低速率的帧传输距离远、抗干扰强但也更容易占用空口资源。在 AGV 场景里我们建议把低于 24Mbps 的低速率全部禁用。这样既减少了慢速终端的拖累也让漫游切换更快。车载终端一旦检测到当前链路质量下降会快速扫描并切换而不是死撑着低速连接AGV 通信的稳定性会明显改善。3.4 漫游优化参数RSSI 阈值与快速漫游漫游优化是 AGV 项目里最核心的无线调参工作。斯普莱的 AC 控制器里有一套快速漫游机制核心是让车载终端更快地评估当前 AP 的信号质量并在合适时机切换。我们要调整的参数主要有两个一个是漫游触发阈值也就是 AP 信号低到什么程度就开始寻找新 AP另一个是切换延迟也就是目标 AP 信号好到什么程度就立刻执行切换。AGV 场景里我倾向于把切换阈值设置得激进一些比如 -70dBm 就开始搜找-65dBm 就完成切换。这样切换发生的时机早AGV 正在移动时已经连上了新的 AP不会出现走到两个 AP 交界处信号断了才切换的情况。同时要开启 802.11k/v 这些漫游增强协议。802.11k 让终端可以预取邻居 AP 信息不用自己一个个信道去扫802.11v 让网络侧可以主动引导终端漫游到更合适的 AP。这两个协议在地面机器人场景的改善效果非常明显漫游切换时间可以从企业级 WiFi 的 500ms 到 1 秒级别降到几十毫秒级别。对 AGV 的 300ms 心跳来说这个速度足够应对。4. 现场遇到的问题与排查经验4.1 掉线问题漫游切换时间超标项目调试初期遇到的最典型问题是 AGV 在经过两个 AP 交界区域时会偶发心跳超时。从调度系统日志上看通信中断在 600 到 900ms 之间看起来不严重但已经超过了心跳允许的窗口。排查思路是从物理层看起先确认 AP 的 RSSI 覆盖曲线然后看斯普莱 AC 上的漫游日志。最后定位到问题是漫游阈值设得太保守终端已经离开当前 AP 的覆盖范围才触发扫描切换时旧链路已经断了新链路还没建立。把漫游阈值调高同时启用快速漫游协议之后实测切换时间稳定在 30 到 50ms这个问题再没出现过。这里有一个心得调试漫游不能只看平均延时要关注最差情况。AGV 无线通信最怕的不是平均 20ms而是偶发性的 500ms 尖峰。任何一次尖峰都可能导致 AGV 停车。所以我们在验收标准里明确要求测试 100 次漫游单次切换时长不得超过 100ms平均不得超过 50ms否则不通过。效果很好逼着网络侧把端到端的每个环节都做到位了。4.2 视觉漏检问题从光源、曝光到 IO 触发排查AGV 对接工位的视觉系统在初期也有过漏检的情况具体表现是托盘已经到位但相机拍照后识别结果迟迟没有返回偶尔还有误判。排查路径非常标准先看图像质量再看识别流程最后看通讯环节。图像质量方面的问题主要是曝光参数没调好。车间里光照变化大有时候阳光从窗户射进来有时候顶灯被叉车碰歪了位置图像时亮时暗。相机的自动曝光模式在这个场景里不太可靠因为识别对象移动时自动曝光会滞后。我们改成固定曝光并加装了遮光罩和补光灯保证成像亮度基本恒定。这样一来识别率上升得很快。IO 触发这块也排查出一个问题光电传感器位置离相机 IO 端口太远线路走线时和高频信号线绑在一起偶尔会被干扰误触发。后来重新规划了走线IO 信号线单独走线并做好屏蔽误触发频率就归零了。在工业现场信号线走线布线不是小事尤其在控制柜和机架内部动力线、信号线、网线要分开敷设哪怕多绕几米也比一路狂奔来得靠谱。4.3 软件调试环节的经验MVS 驱动、VM 自启动与许可问题软件层面也有几个值得写下来的坑。海康工业相机在调试机上要装 MVS 软件才能被发现很多新手插上网线后找不到相机以为是硬件坏了其实大概率是没装驱动或者电脑的有线网卡 IP 与相机 IP 不在同一网段。哈苏相机初始化默认 IP 一般是静态 IP如果电脑没改成同一网段SDK 是枚举不到设备的。这个坑在 ubuntu 系统下尤其明显Linux 下装完 MVS 还得手动配置网络管理工具否则网卡还是会用 DHCP 模式抓不到相机。VM 软件VisionMaster的使用上也有一点心得。做视觉识别流程时要把相机参数配置、图像预处理、模板匹配、结果输出这四段流程分开测试。不要一上来就整个流程跑那样出了错很难定位是哪一步的问题。分模块测模块间用保存图片的形式把中间结果留下来后面做问题回溯时特别方便。另外 VM 软件在工控机上需要设置开机自启动。很多项目重启后软件不弹出来AGV 对接工位就瘫掉了。设置自启动时建议把启动用户做成当前管理员账户并且要把延迟启动加进去等系统网络和服务完全初始化后再启动 VM。我们尝到过一次教训VM 启动早于网络初始化完成导致相机连接全部失败之后只能靠人工重启软件恢复。授权这块也提醒一句海康的视觉平台和调度平台都有授权管理的项目扩容、新加工位的时候要提前申请授权。有次车间临时决定新增加一个识别工位结果现场发现授权数量不够整个调试进度卡了一下午。建议在项目阶段就把授权余量买足并且把授权信息、配置文件备份到专门的位置别放在工控机 C 盘了事。4.4 典型问题速查表现象可能原因排查与解决AGV 在某区域偶发掉线漫游切换阈值过保守调高漫游触发阈值开启 802.11k/v心跳一直超时车载终端衰耗较大检查车载天线安装位置确认信号强度和信噪比相机搜不到电脑与相机 IP 网段不一致检查网卡 IP接入同一网段视觉识别时好时坏曝光参数不稳定固定曝光加装补光灯和遮光罩拍照触发不灵IO 线没共地或走线被干扰统一电源地信号线屏蔽并单独走线VM 重启后不工作自启动失败或启动过早设为延迟自启动并手动验证开机流程AP 之间反复切换存在同频干扰手动指定信道错开相邻 AP4.5 项目交付与验收的注意事项项目交付阶段除了跑通功能外一定还要做稳定性验证。我们的做法是让 AGV 车队连跑 72 小时期间模拟正常生产节拍、正反转操作、跨区域调度。重点观察无线链路的丢包率、漫游耗时、通信中断次数这几个指标。验收的时候文档是少不了的。无线网络设计图纸、AP 点位表、信道规划表、漫游测试报告、系统拓扑图这些都要整理归档。AGV 项目的维护通常不是原班人马做过两年设备出问题新接手的工程师如果没有完善的文档光是定位问题就要花掉很多时间。我一般还会把日常维护的检查项指导书写好比如 AP 指示灯状态、车间电磁环境变化提醒、二维码耗损检查周期等写细一点后面运维才会省心。海康 AM 的调度后台平时要关注任务完成率和平均任务执行时长这两个指标。如果任务完成率往下掉、平均执行时间拉长大概率是某个环节出现了隐性问题比如某个工位视觉对接偶发超时或者某条路径上的无线信号衰减。早点发现早点处理别等产线停线了再急得像热锅上的蚂蚁。最后的几句心得这个项目做完我自己最深的感受是AGV 方案落地真正拼的不是单机功能有多炫而是整个系统的链路稳不稳定。AGV 本体、视觉系统、调度平台、无线网络、MES 接口任何一环出问题整个物流系统都会停摆。尤其是通信这一层看起来是个“基建活”但在工业现场的复杂环境下要把延时、漫游、抗干扰这些指标做好非常需要耐心和细致的调参。最后再分享一个小建议。如果在做类似项目设备进场之前一定先把现场的电磁环境扫一遍把 AGV 行驶路径上的覆盖情况摸清楚。很多人把 AP 装完就以为完事了其实后面漫游调参、信道资源分配才是真正让网络“能用”的关键。至于相机调试这块我的习惯是先把光源和曝光搞定再谈算法图像本身质量差再聪明的算法也白搭。项目已经交付几个月了现在 AGV 每天在车间里跑偶尔我也会远程看一眼调度后台的数据。看到任务完成率稳定在 99% 以上心里还是比较踏实的。做工程的成就感很多时候不在上线那一刻而在上线之后它安安稳稳地一直跑下去。