一家电子厂用边缘AI调度AGV车队：从"撞车堵路"到智能调度

去年底，一家苏州的电子代工厂找到了我们。他们的SMT车间上了8台AGV做物料搬运，结果上了半年后，物流班长都快被搞疯了——AGV三天两头堵在路口，运力分配严重不均，有的车闲得要命，有的车忙不过来。

这种问题说起来简单：不就是调度算法的事吗？但真正深入进去才发现，工厂里的调度比我想象的复杂得多。

这篇文章记录我们是怎么一步步做下来的。不保证看完你就能自己搞定AGV调度，但至少能避开我们踩过的那些坑。

一、现场情况摸底

这家工厂是典型的SMT电子制造车间，面积约8000平方米，布局是两排SMT产线中间夹一条主通道，产线两端各有一个物料暂存区，仓库在车间北侧。

• AGV情况：8台潜拖式AGV（200kg负载），每台负责在不同产线和仓库之间搬运料盘
• 导航方式：磁条导航，地面贴了磁条走固定路线
• 原有调度系统：AGV厂家自带的系统，基于区域锁+先到先服务
• 数据接口：AGV控制器的API只能查询状态和下发任务，不能实时修改路径
• MES对接：MES系统通过WebAPI下发物料需求，原有调度系统自己解析

我们到现场蹲了两天，物流班长给我们看了一组数据：每天平均出现6-7次AGV堵车事件，其中3-4次需要人工介入推车或重新调度。最严重的一次，4台AGV在T字路口形成死锁，物流班长手动处理了将近20分钟。

此外还有两个问题也很要命：一是每次下午换班前，总有一两台AGV电量低于20%还在跑，跑到一半趴窝；二是运力分配极不均衡——靠近仓库的两条产线基本随叫随到，而最远端的产线经常等料等30分钟以上。

二、问题分析

花了两周时间，我们分析了AGV运行日志和MES下发的任务记录。发现了几个根因：

2.1 路径锁死机制太粗

原有系统把车间地图分成了几个大区域，AGV进入一个区域就锁住整个区域。这就导致：一台AGV在主通道中间卸料，其他7台全部停住不能过。实际用过的主通道只有3米宽，AGV如果靠边停，其他车完全能过去。但系统不认——它只管区域锁，不管实际路面占用情况。

2.2 任务分配算法不公平

调度系统的分配逻辑很简单：有任务来了，找离任务起点最近的空闲AGV。听上去合理对吧？但实际结果是：离仓库近的AGV几乎永远在接单，而远端产线附近的AGV经常一整天都没什么任务。近端AGV跑到后段没电了，远端AGV闲着电却没用上。

2.3 没有电量预判

调度系统完全不关心电量。一台AGV可能在离充电站最远的位置接到一个长任务，跑到半路电量告警，被迫原地待机等救援。

2.4 单车决策，无法全局优化

每台AGV自己跑自己的路径，互相之间只知道"前面有车，我停"。没有中央协调机制，所以在路口很容易形成死锁——四台车各占一个方向，谁都不退，谁也过不去。

三、方案设计

我们很清楚：替换这8台AGV的原有控制器不现实。磁条导航已经固定在地面，API接口也有限。能做的只有在外层加一层智能调度系统。

最终架构分三层

采集层（边缘AI网关）：在车间部署一台边缘AI网关，通过Modbus TCP轮询AGV控制器的API，获取每台AGV的实时状态（位置、速度、方向、电量、当前任务ID）。每200毫秒采集一次。

决策层（调度优化引擎）：在边缘网关上运行一套任务分配+路径规划优化系统，包含三个模块：

• 任务分配模块：不再按"最近派车"，而是考虑综合成本——包括AGV当前位置、剩余电量、方向朝向、已有任务队列、任务紧急程度
• 路径规划模块：为每台AGV规划具体路径，精细到"走主通道的左侧还是右侧"，在路口分配通行时间片
• 冲突解决模块：实时检测潜在路径冲突，提前重新规划避开

执行层：通过AGV原有API下发任务指令。我们不改控制器底层的路径执行逻辑，只是更聪明地分配任务和规划路径。

算法选型的思考

一开始我们想上强化学习——听起来很帅，训练好了就能自动优化。但仔细一想，这种产线的AGV调度有几个特点：

• 任务到达是不可预测的（MES随时下发）
• 路径拓扑是固定的（磁条不能改）
• 必须保证100%无死锁（不能有"试一下"的余地）

RL在这三个条件下很难落地——训练周期长、很难保证零死锁、产线变化了还得重新训练。

最后我们选的是混合整数规划（MIP）+ 启发式搜索的组合方案。MIP负责每10秒做一次全局任务分配，启发式搜索负责每台车的路径规划和冲突避免。虽然理论上的全局性不如RL，但胜在可解释、可调试、零死锁有数学保证。

四、实施过程

第一周：数据摸底和接口对接

第一件事不是写代码，是把AGV控制器的API文档翻出来看。结果发现一个问题：厂家API能查询AGV的位置坐标、电量、状态（运行/空闲/充电/故障），也能下发任务。但不能实时修改已下发任务的路径。也就是说，如果一台AGV已经在路上了，我们没法让它"前面右转"——只能等到它完成当前任务后，发下一个任务时才生效。

这个限制让我们重新调整了方案。我们做不了"实时路径修正"，只能做"更聪明的任务分配"。最终的策略是：

• 把车间地图拆成更细的"路段段"（segment），不再是大区域
• 每个任务下发时，附上完整的路段序列（起始段→途经段→目标段）
• 通过时间片分配来避免冲突

教训：对接前一定要搞清楚API的约束。我们一开始的"实时路径修正"方案在第一天就废了，白写了一周的代码。

第二周：地图建模和路径网络构建

我们把整个车间地图数字化——包括所有磁条路径、路口、充电站位置、产线取料点的坐标。磁条路径总长约680米，涉及12个路口、3个T字路口、2个十字路口、1个Y字分叉口。

每个路口我们都记录了"通行方向约束"——比如某个路口只能直行，不能左转（因为磁条没铺左转路径）。这是AGV厂家的物理约束，我们只能接受。

说实话，画地图这个工作看起来简单，实际很花时间。光是校准坐标就来回跑了三趟——AGV反馈的位置有约30厘米的误差，我们得手动修正每个路口的触发点坐标。

第三周：调度算法开发和仿真

我们在边缘网关上用Python写了一套调度引擎。核心代码并不复杂，但细节很多。

任务分配：每10秒跑一次MIP求解器，把等待队列里的任务分配给最优AGV。目标函数是综合成本，包含三项：

• 距离成本：AGV当前位置到任务起点的预估行驶时间
• 电量惩罚：如果完成当前任务后AGV电量低于30%，分到这个任务会加分惩罚
• 均衡度惩罚：任务超过一定数量没被分配到的AGV会降低权重，让运力更均衡

路径规划：每个任务分配后，用A*算法在地图网络上找最优路径。A*的代价函数不只看距离，还包含了经过路口的通行时间片等待成本。

冲突解决：我们维护了一张"路段占用时间表"，每段路在未来30秒内被哪台AGV占用。在为每台新AGV规划路径时，会查这个表。如果发现30秒内某个路段已被占用，就等待一个时间片或者重新规划绕行路线。

算法写完后又花了一周做仿真验证——用历史数据作为输入，模拟调度效果。仿真跑了1000+组数据，确认零死锁后才敢上线。

第四周：现场联调

最折磨人的阶段。第一天上线测试，系统就开始抽风。

第一个问题：AGV位置更新延迟。我们200毫秒采集一次位置，但实际测试发现，AGV控制器返回的位置数据有1-2秒的延迟。在路口这种关键位置，2秒的延迟足以让两辆车同时出现在同一个路段上。解决方案是把轮询间隔从200毫秒降到500毫秒，同时增加一个"安全缓冲路段"——路口前后各留出一段缓冲区间，每台车进入路口前必须先申请通行权。

第二个问题：通信超时。我们的边缘网关通过WiFi和AGV控制器通信，但车间WiFi信号不稳定，偶尔会丢包。结果导致下发任务延迟，AGV到了路口等了10秒都没接到下一步指令，停在路口挡住其他车。解决方案是加了一个本地缓存和心跳机制——每次成功下发的指令，在网关本地存一份。如果通信中断，等连上后立即补发，不重复执行。

第三个问题：某台AGV在运行时磁条传感器故障，偏离了磁条路线。我们的调度系统以为它还在规划路线上，结果两台AGV在路口几乎相撞。还好磁条偏离触发了原厂急停功能，没有真的撞上。事后我们加了一个"位置偏离告警"——如果AGV反馈的位置偏离规划路径超过40厘米，立即暂停该区域的所有任务，由人工介入。

五、实际效果

系统正式上线跑了3周后，我们对比了前后的运营数据：

但也有几个问题没能完美解决：

高峰期偶发延迟。换班前后物料需求最集中的时段，任务队列会比较长，偶尔会有等待超过15分钟的情况。原因是AGV数量就这么多，高峰期需求超了容量，再怎么优化也只能做到排队——不可能无中生有增加运力。

WiFi稳定性影响。车间WiFi不改善，调度系统就不可能100%稳定。我们建议工厂在车间部署全区域覆盖的工业级AP，但这是另外的投入了。

六、遇到的问题和解决办法

除了前面说的通信和位置延迟问题，还有几个值得记一笔的：

1. 仿真数据和真实数据的偏差。仿真用的历史数据里，AGV的行驶速度是恒定的（1m/s）。但实际上，AGV在转弯时会降到0.3m/s，满载和空载的加减速也有明显差异。这些差异导致仿真时算的"预估用时"比实际少了约15%。后来我们在仿真模型里加了速度曲线参数，预估准确度提升到约93%。

2. MES任务下发时机。原来MES是"想到就发"——一个物料需求分批下发，每次只发一个。这导致我们的调度系统在10秒的分配周期内，只能看到很短的需求窗口。后来跟MES团队协调，让他们在排产完成后一次性把未来2小时的任务都推过来。调度系统有了更长的时间窗口，分配质量明显提升。

3. 操作工的信任问题。新系统上线后，物流班长发现AGV不再走"最近的路"了——有时候会绕路，因为我们的算法选择了整体更优但单台不一定最优的路径。班长一开始不理解，说"这车是不是傻了"。我们花了一个下午解释算法的逻辑，又加了一个看板，展示当前每台AGV的任务和预计到达时间。看板上线后，工人们很快接受了——他们不在乎AGV怎么走，只要料能准时到就行。

七、个人的思考

做完这个项目，我几个比较深的感受：

AGV调度看起来是算法问题，实际上是个系统工程。通信延迟、API约束、车间WiFi、MES对接方式、操作工接受度——每个环节都可能成为瓶颈。算法解决的是最后一小步，前面的基础设施和数据链路才是大头。

不要低估"接口兼容"的工作量。原有AGV厂家的API设计时就没考虑过第三方调度系统。我们花了大量时间在"怎么让AGV听懂我们的指令"上，而不是"怎么调得更好"。

增加一层边缘网关做本地调度，比直接改造AGV控制器靠谱得多。不改底层硬件，对工厂来说风险小、成本低。以后AGV升级换代了，调度系统还能继续用。

数据同步比算法精准更重要。AGV位置延迟2秒这件事，对算法精度的拖累远超算法本身的优化。有时候多花时间在数据质量和传输稳定性上，比花时间调算法参数更值。

八、给你的建议

如果你们工厂也在用或计划用AGV，几点实际经验：

1. 先搞清楚AGV控制器的API能力再设计方案——能不能支持第三方调度、能不能修改路径、数据更新频率是多少。这些直接决定方案的可行性和复杂度。
2. 调度算法上线前，至少要跑1-2周的数据采集和仿真验证。千万不要直接在生产环境上试——AGV堵车不是闹着玩的。
3. 引产线远端工人的信任。离仓库最远的产线，原来料总是不及时。新系统出来后，他们是最先支持的——因为效率提升对他们是实打实的好处。
4. 不要一次性上所有AGV的调度切换。先切2台试跑一周，没问题了再逐步扩展。我们是先切了远端产线相关的3台AGV跑了3天确认无问题后，才全量切换的。
5. 留好人工接管的后路。我们保留了原厂调度系统的旁路开关——一旦新系统出问题，5分钟内可以切回原来的调度方式。这是让老板放心的关键点。