AGV落地实战：从工业无线组网到多车协同调度全过程

去年接广汽传祺总装车间这个项目的时候我就知道它不会是一个“买几台AGV装上就能跑”的简单活儿。项目title写得很直白海康AGV小车加斯普莱工业无线组网。但真正落地过程中牵扯出来的东西远不止这两块牌子——三条AGV协同作业要跑A*路径规划车间里成千上万平方米的铁皮结构、电机变频设备给无线组网挖了一个又一个坑再加上与MES对接、线边料架改造、二维码地图铺设……整个项目做完我才敢说自己摸清了工业移动机器人物流系统的底。这篇就把我们团队从方案选型、无线勘测、调度算法落地到上线运维的完整过程捋一遍。如果你正在评估车间上AGV或者已经在为AGV无线断连、三车互堵这些问题头疼这篇应该能帮你少走不少弯路。1. 传祺车间上AGV这钱该不该花花在哪1.1 总装车间物料配送的运行瓶颈传祺这个总装车间一条主线几十个工位零部件从卸货区、缓存区到线边的配送量非常大。原来的模式是传统的电动牵引车加拖车司机人员分三班倒用对讲机喊话调度。表面上看着运转正常实际上问题一大堆。最核心的痛点是“信息黑洞”。车在哪个位置只有司机自己知道组长问起来靠对讲机喊喊不到人就只能干等。急料呼叫过来配送员可能正卡在某条通道上人为响应周期根本不可控。更麻烦的是夜班原本白班还能靠经验老道的班组长压住场面夜班人手一少整个物料配送节奏就乱了。加上总装车间产线节拍一直在往上提靠堆人已经解决不了问题。同时车间里人车混流的现象很严重。牵引车拉着长长的拖车在通道上转弯、倒车行人避让全靠喇叭安全隐患始终存在。厂里之前也评估过磁条导航AGV但磁条方案有个致命问题——产线调整或工位挪动时地面磁条要重新贴工期长、成本高而且磁条容易被叉车压坏后期维护量非常大。1.2 目标拆解效率、柔性、可追溯项目立项的时候业主方给了三个核心诉求效率、柔性、可追溯。翻译成工程语言是这样的效率从呼叫发出到物料到达线边的时间要可量化单趟配送时间要比人工牵引明显缩短白夜班表现一致。柔性后续产线节拍调整、工位变化时AGV的路径和站点可以通过软件改不需要动地面基础设施。这一点直接否掉了磁条方案。可追溯每辆AGV的位置、状态、当前任务、历史记录都要留痕能够对接车间MES系统将来做物料齐套分析、配送准时率统计都有数据支撑。另外还有一条安全底线车间里有大量线边作业人员AGV必须做到人车混流下的安全运行声光报警、避障传感器、急停按钮都是标配。这里要特别提一点AGV“能跑”只是及格线“不出安全事故”才是验收的前提。前期方案评审时我们把安全策略单独列了一个章节来谈包括障碍物检测距离、减速逻辑、急停后的恢复流程这一块一定不能省。2. 从海康选型到场地勘测AGV不是买来就能跑2.1 潜伏式和牵引式之间的选择物流机器人的形式五花八门选型错一步后面全盘被动。在传祺这个项目里我们最开始同时评估过牵引式和潜伏式两个方向。牵引式AGV的优势是改动小直接替代原来的电动牵引车后面拖挂料车就行载重能力大适合长距离大吨位转运。但缺点也很明显——它需要拖车编组转弯半径大在总装车间里灵活性差而且牵引式对接料车时如果料车的挂钩高度、刹车方式不一致还要做一轮料车改造工作量并不小。潜伏式AGV是另一种逻辑它钻到料架底部顶升后把整个料架驮着走。优点是对接精度高、转弯灵活、运行路径短缺点是料架本身要做标准化改造底部要留出AGV进入的净空高度。我们最终选了潜伏式方向因为总装线边的料架本来就要重新规范顺势做一轮标准化改造反而把整个现场的料架规格统一了后续扩展性更好。品牌选型上考察过几家主流AGV厂商。最后选海康机器人因素不是单一的RCS调度系统成熟度海康的机器人控制系统在行业里落地案例多接口文档开放度高对接MES/WMS方便。导航方式匹配海康的潜伏式AGV支持二维码加IMU加里程计融合定位精度和成本平衡得很好。本地化服务海康在广州有成熟的售后和工程团队项目后期驻场、响应都有保障。这一点对生产车间来说非常实际AGV故障停线一小时损失不是设备本身能算回来的。2.2 二维码网格地图与站点规划导航方案确定后真正费时间的是地图和站点设计。我们采用的是二维码网格方案——在AGV运行通道上按一定间距铺设二维码每个二维码有唯一IDAGV底部的相机识别二维码获取绝对坐标再配合IMU和轮式里程计做短距离推算。二维码铺设间距是经过仔细考量的。间距太大AGV在两个码之间的定位误差累积大间距太小铺设成本高、维护量也大。我们最终用的是1.2米乘1.2米的网格间距既能保证定位精度又不至于让施工量失控。地图坐标系以导航原点建立所有站点、路径、避让点都落在这个坐标系里。站点类型包括充电位、缓存区取料位、线边呼叫工位、临时避让点、维修区。这里有个经验值得分享——站点设计一定要和车间工艺流程对齐不能光听AGV厂家的标准模板。比如线边呼叫位要和产线工位的实际配货口一一对应如果站点离得远员工取料要绕路表面上看AGV跑得挺欢实际使用者天天抱怨。还有一个选型阶段容易忽略的地方转弯半径和通道宽度的匹配。我们最初按AGV车体尺寸预留通道宽度现场勘测时发现有几处通道转弯处因为立柱和工装设备遮挡AGV带料架转弯时空间不足。这个问题如果等设备到场再发现返工成本极高。建议任何AGV项目土建勘测阶段就要把“车体加最大料架”的转弯包络图画出来和现场通道逐段核对。3. 斯普莱工业无线在铁皮森林里给AGV铺一条“看不见的路”3.1 为什么普通Wi-Fi扛不住AGV车间AGV项目里无线网络经常是最先被轻视、最后背锅的环节。很多团队的习惯是“车间里装几个AP就够了反正Wi-Fi哪都能用”。但AGV对无线的要求和办公场景完全是两个物种。AGV和调度系统之间的通信是连续实时的。AGV每隔几百毫秒上报一次位置和状态调度系统下发的停止、减速、转向指令同样要求毫秒级到达。一旦通信中断或者丢包严重AGV的控制逻辑会判定“失联”触发安全急停。一台车急停后续路径被堵塞整条物流线就瘫痪了。这个连锁反应我在后面的故障章节会详细讲。总装车间对无线来说是个极其恶劣的电磁环境大量钢结构立柱、货架、工装设备无线信号反射严重多径效应会让信号强度看着挺好实际吞吐一塌糊涂。焊机、变频器、大功率电机启动时产生宽带电磁干扰2.4GHz频段基本是个灾难。AGV始终处于移动状态需要在多个AP覆盖区之间切换漫游时延稍微一大调度就会断连。所以这个项目果断上了斯普莱的工业无线整体方案包括工业级AP、无线控制器AC、PoE交换机和配套天线。专业做工业无线的厂商和办公Wi-Fi品牌的区别在于他们知道“移动设备的连续性”才是核心而不是单纯的覆盖面积。3.2 覆盖规划、信道划分与漫游调优无线网络设计这块我们实际上做了两轮。第一轮是按厂家提供的软件模拟出的AP点位图部署结果AGV实测时在好几个区域出现漫游掉线。后面我们重新做了现场勘测结合实际AGV行走路径调整点位才算稳定下来。覆盖规划的核心逻辑是这样的不追求整个车间都满格而是保证AGV所有行走路线和停靠站点上的信号连续稳定。AP布点沿着AGV主通道来而不是按车间均匀铺。因为AGV只在特定路径上跑把AP集中在通道上方信号效率最高。信道规划同样有讲究。AGV专用SSID只用5GHz频段2.4GHz直接关闭复用。原因很简单2.4GHz干扰源太多蓝牙、微波炉、附近的办公Wi-Fi都在抢信道而且2.4GHz吞吐天花板低对AGV这种高密度小包通信不太友好。5GHz频段里还要把信道错开相邻AP不能同频我们用1、6、115GHz对应36、44、149等错开分配同时关闭不需要的DFS信道避免雷达规避机制带来的周期性信道检测。漫游优化是无线这块的重头戏。办公场景断网几秒顶多卡一下AGV断网几秒就是急停。我们调了三个地方AP间覆盖重叠区相邻AP的信号重叠不能太小否则AGV还没有完成漫游旧AP信号已经弱到不可用。重叠区留出足够的缓冲让AGV有充足时间完成切换。漫游触发阈值AGV网卡默认的漫游触发在-70dBm左右但这个值受驱动策略影响。我们把阈值适当调高让AGV在信号明显变差之前就主动切换到新AP。白名单和AP优选在AGV工控机的无线配置里锁定允许连接的AP列表避免AGV连到信号强劲但信道拥挤的办公SSID上。这套配置做完后AGV在车间里往返跑的漫游切换时延稳定在几十毫秒级符合调度系统的要求。3.3 弱网丢包对AGV安全机制的连锁反应这里想单独说说“弱网”和“丢包”的区别。信号强度弱顶多网速慢但只要链路还在TCP/IP的重传机制能兜住。真正可怕的是丢包——尤其是连续丢包AGV控制端会直接判断通信链路断裂。我们调试期间做过一次测试在某个AP覆盖边缘人为丢包30%AGV的调度系统在几秒内就报了通信超时随后车辆急停。从急停到重新联机、人工确认、恢复任务花了将近两分钟。车间里这两分钟看起来不长但产能节拍都是按分钟算的一天多停几次当天的产量指标就悬了。所以评估AGV无线网络时指标不是覆盖率百分之多少而是端到端丢包率AGV与调度系统之间的ping丢包目标小于0.1%。漫游切换时延目标小于100毫秒且不允许丢包超过2个。并发容量车间里同时有AGV、手持PDA、工位终端在线要保证AGV通信不被挤占。我建议任何AGV项目入场调试前先和业主确认这套无线验收标准白纸黑字写进技术协议。很多人被“无线不好调”这种话糊弄过去最后AGV跑不稳天天跟网络打架。4. 三条AGV共线运行A*只是起点防死锁才是核心4.1 单机导航里的A*怎么落地三条AGV协同作业频率最高的算法关键词其实就是“A*”。网上聊A的大部分文章止步于八数码、五子棋这类玩具场景真实AGV项目里A的落地方式要务实得多。简单回顾一下A*的原理它用f(n) g(n) h(n)来评估每个节点。其中g(n)是从起点到当前节点的实际代价h(n)是当前节点到目标点的启发式估计。AGV场景里最常用的启发式函数是曼哈顿距离路径越长启发值越大搜索不断往目标方向引导比Dijkstra这种无方向盲搜快得多。AGV上的A搜索对象不是自由二维空间而是预先铺好的站点拓扑图。我把车间地面抽象成一张有向图节点是二维码站点、转弯点、停靠点边是AGV允许行驶的路径段边的权重是路径长度加转向惩罚。A在这张有向图上搜索得到从起点到目标点的路径点序列AGV沿着路径点依次行驶。当时的规划核心逻辑可以简化成下面这个Python伪代码方便大家理解import heapq def heuristic(a, b): # 曼哈顿距离作为启发函数 return abs(a.x - b.x) abs(a.y - b.y) def astar(start, goal, graph): open_pq [(0, start)] came_from {start: None} g_score {start: 0} while open_pq: current_f, current heapq.heappop(open_pq) if current goal: path [] while current: path.append(current) current came_from[current] return path[::-1] for neighbor, cost in graph[current].items(): tentative_g g_score[current] cost if tentative_g g_score.get(neighbor, float(inf)): came_from[neighbor] current g_score[neighbor] tentative_g heapq.heappush(open_pq, (tentative_g heuristic(neighbor, goal), neighbor)) return None在传祺项目里海康的RCS调度系统已经把A*封装成了内部模块我们不需要自己从零开发但必须理解它的底层逻辑因为后面调多车协同的时候大量问题出在地图拓扑和路径权重的定义上而不是算法本身。4.2 路段锁、优先级与避让区三条AGV如果各跑各的A*不搞协同那碰撞只是时间问题。因为A*只会给单车找一条不撞墙的最短路径它不知道另一台车也打算走同一段路。三台车共用一个主通道的场景光靠车头激光避障远远不够——避障只能让车停下来不能让车学会怎么高效地让路。我们实际采用的是“集中式调度加路段锁”的机制。RCS把整个地图的路径拆成一段段路段每个路段同一时刻只允许一台AGV占用。AGV要进入某段路之前必须先向RCS申请拿到路段锁才允许进入。这个“锁”的概念特别好理解就像单车道桥梁同一时间只能有一个方向的车通过。但路段锁带来一个直接问题锁的粒度怎么划分。上线初期我们用的是长路段因为路径段少调度逻辑简单。结果发现一台车在交叉口等待时另一台车明明隔着几百米因为路径上某个长路段被锁也只能干等效率极低。后来重新梳理地图把长路段拆成短路段按车长和转弯半径细化锁的粒度精细了并发效率才上来。第二个关键策略是任务优先级。AGV项目里不是所有任务都平等的产线急料呼叫是最高优先级正常配送次之空车返回充电区再次之。高优先级车在申请路段锁时可以抢占低优先级车已申请的路径低优先级车收到抢占通知后就近开到避让区等待。这里的一个前提是地图上要留足避让区否则“让路”会让到角落里出不来。第三个是循环路径设计。我们在主通道上做了一部分单向循环AGV统一逆时针走减少了大量对向行驶的冲突。这个思路一点不高深但效果立竿见影——三台车的对向会车几乎被消灭剩下的冲突集中在交叉口的交汇点通过路段锁和优先级就能解决。4.3 调参实战从频繁等待到稳定节拍系统刚上线那几天三台AGV的整体效率一度被现场人员吐槽“不如人工”。我们从调度日志里看到车辆大量时间处于“等待路段锁”状态部分任务的等待时间甚至超过了实际行驶时间。问题出在哪日志分析显示路段锁的粒度是主因但还有一个隐藏因素调度系统的路径预占策略太保守。RCS默认给每条规划路径一次性预占全链路路段A先规划好路径B再规划时发现整条路线被占哪怕A离这些路段还有好几个站点B也只能等待。优化策略是把“全链路预占”改为“逐步申请”——AGV每经过一个路段再申请下一个路段锁的持有时间大幅缩短并发利用率和调度灵活性比之前好很多。另外我们对任务分配逻辑也做了调整。三台车中原来固定A车服务1号线B车服务2号线C车服务3号线。结果1号线呼叫密集时A车忙不过来其他线空着。改成动态任务池后任何空闲车辆优先响应最高优先级任务充分用足了运力。调完这些参数单车平均配送时间从14分钟降到9分钟三车整体节拍稳定在项目预期之内。这个案例说明一个道理AGV数量不多时瓶颈往往不在A*算法本身而在路段划分粒度、任务分配策略、预占逻辑这些工程细节上。算法再好拓扑和策略设计不合理照样跑不出效率。5. 上线月里我处理过的三个典型故障5.1 AGV运行中随机急停无线漫游丢包的完整排查项目上线半个月后车间反馈一个很棘手的问题AGV运行到B通道和C通道交叉口附近时偶尔会报“通信超时”并急停但几分钟后又自己恢复完全没有规律。这个故障极难排查因为不是必现的可能一两个小时才出一次。我们第一反应是无线有盲区拿着测试电脑到现场测信号强度显示-60dBm以上看起来完全正常。后来在故障区域放了一个持续的ping监控发现端到端丢包率确实偶发飙高而且丢包发生的瞬间正好对应一个漫游切换动作。再深入看AGV工控机的无线日志问题清晰了AGV的网卡驱动并没有在信号变差之前主动触发漫游一直守着旧AP信号到-80dBm以下才开始找新AP切换过程又因为扫描时间太长直接丢了几个包。调度系统连续几次收不到心跳就判定AGV失联触发急停。修复方案分三路并进AC侧把覆盖该区域的AP发射功率略微调高同时调整RSSI均衡策略让AGV在信号衰减初期就被引导切换。AGV工控机上关闭系统自动漫游改用驱动级漫游参数把触发阈值从默认的-75dBm提前到-65dBm保证在新AP信号足够好的时候完成切换。把两个AP的重叠覆盖区在交叉口处特意加大避免AGV在转弯的同时进行无线漫游。修复后连续观察三天漫游切换平均时延50毫秒最大120毫秒再也没有因为无线原因急停过。5.2 二维码脏污与补光角度引起的定位漂移运营一个多月后某条线边停靠点开始出现AGV对不准料架的情况偏差大概三四厘米。AGV顶升时如果位置不正料架会倾斜存在安全隐患。排查时我先看的RCS导航日志发现AGV在到达该停靠点前的最后一个二维码识别成功率明显偏低几次甚至连续丢码。到现场一看那个位置的二维码被牵引车轮胎带起的油污覆盖了薄薄一层加上AGV底部补光灯在金属地面上形成反射眩光相机识别率进一步下降。处理办法是双管齐下把这批二维码更换成耐磨防污的材质贴完后在上面覆盖一层透明保护膜同时纳入车间5S保养清单要求每周清洁一次。调整AGV底部补光灯的亮度和安装倾角减少地面镜面反射干扰。另外我们在停靠逻辑里增加了二次校验机制AGV进入停靠区之前连续确认两个二维码的位姿数据取平均值作为最终停靠位姿而不是只依赖最后一个码。改动之后该区域再没有出现定位漂移问题。这个故障提醒我二维码导航方案便宜可靠但它是有维护成本的。地面上那些小方块看着不起眼一旦脏污破损AGV整个就“瞎”了。工业现场要建立二维码的巡检制度别等出了问题再去擦。5.3 PoE长线供电导致的AP离线第三个故障非常有意思排查过程给我上了一课。上线初期B通道一个AP总是间歇性离线发生在每天早班和下午班开始的时段重启后能恢复但撑不了几个小时又掉线。按常理AP离线一般查网络配置、查IP冲突、查AC连接。我们整天和AC、交换机、网线搏斗都没结果直到有一次现场运维顺手测了一下AP的供电电压才发现异常。那个AP的网线从弱电间接出来走线距离已经接近一百米中间还经过了一个转接端子。PoE供电在长距离线缆上电压降很大AP启动时瞬间电流需求高电压直接被拉低触发了硬件保护AP强制重启。为什么集中在早晚班时段因为那两个时段是AGV集中充电和出入库高峰无线终端数量多、AP负载高功耗上升供电不足的问题就被放大了。解决方法是把那台AP的供电方式改成光纤收发器加本地DC电源网线只跑数据不跑供电彻底绕开PoE距离限制。如果现场不想增加光纤也可以在该位置附近加装一台PoE交换机缩短网线长度同时注意交换机PoE功率预算是否充足。这个故障的教训是工业无线前期勘测不能只测无线信号还要把每个AP的物理链路距离、PoE供电余量一并核清楚。网络八九十米看着能凑合在实际负载下就是定时炸弹。6. 最终验收与运维建议6.1 效率、稳定性和人工变动的实测数据项目验收的时候我们整理了一份对比数据其中几个数字我觉得对想上AGV的车间很有参考价值。人工牵引阶段单趟配送平均耗时12分钟AGV上线稳定后单趟平均8分钟缩短约三分之一。呼叫响应时间从平均15分钟降到5分钟以内急料呼叫响应更是缩短到3分钟。配送准时率从85%左右提升到99%以上产线停线等料的情况基本消除。无线网络的数据是这样的AGV运行期间端到端丢包率小于0.1%AGV与RCS的断连次数为零漫游切换平均时延控制在80毫秒以内。这组数据说明工业无线针对AGV场景的专项设计是有效的不是靠运气。人工方面原来的牵引车司机转岗了一部分到线边配送作业另一部分经过培训转为AGV现场管理员负责日常点检、二维码维护、简单故障处理。AGV不是单纯减少人力而是把人力从低价值的重复驾驶中释放出来去做更有质量的管理工作。6.2 给准备上AGV的车间几条建议做完这个项目我对AGV落地的理解比之前务实了很多。如果有朋友也在筹备类似项目我会给出下面几条建议AGV、无线网络、物流流程必须三位一体规划任何一项单独招标、单独施工后期都会互相扯皮。传祺项目之所以顺利很大程度上因为无线网络从一开始就按AGV场景设计而不是拿来一个通用Wi-Fi方案硬套。多车调度别急着搞高级算法先把地图拓扑做合理。三条AGV这个规模A*加路段锁加优先级已经足够。如果地图上有大量不合理的交叉和长路段再厉害的算法也救不回来。无线验收标准要写进合同丢包率、漫游切换时延、急停次数都是可量化的指标。验收不是看信号满格而是看AGV跑一周下来急停几次。二维码方案的日常维护别忽视。AGV靠地上的小码认路码脏了、破了、磨损了车就瞎了。建立巡检制度把二维码维护落到班组考核里。日志是最好的老师。RCS调度日志里什么都有车辆等待时间、路段占用时长、任务响应周期这些数据比供应商给你画饼实在得多。我在项目里很多优化决定不是拍脑袋而是每天翻日志翻出来的。最后分享一个小技巧吧AGV上线后定期导出调度日志做路径热力图分析看哪些路段是拥堵点、哪些避让区根本用不上。传祺项目运行半年后我们根据热力图调整了两处避让区的位置把交叉口通行效率又提了一截。这种东西供应商不会主动帮你做但做了之后效果是实打实的。AGV项目从来不是交付即结束上线后的持续调优才是真正拉开使用体验差距的地方。