AGV 项目真正难的不是单车跑起来，而是多车调度：路口互锁、任务分派、和产线 PLC 的叫料握手。车体厂家一般自带调度系统（WCS / RCS），工厂要做的是通过接口把它和上位机、MES、产线对接起来。堵死、死锁、任务丢失、装卸不同步，几乎都出在对接这一层。
一、先分清AGV和AMR，选型直接决定对接方式
这俩经常被混着叫，但对调度对接来说差别挺大：
- AGV（磁条 / 二维码导航）：路径固定，靠地标点位行走，调度偏集中式，路径要提前规划死；
- AMR（激光 SLAM 自然导航）：自主避障、路径动态规划，柔性高，但多车协调依然离不开统一调度。
| 导航方式 | 改线成本 | 对接重点 |
|---|---|---|
| 磁条导航 | 要重新铺条，成本高 | 地标点位与分支控制 |
| 二维码导航 | 贴码即可，较灵活 | 码点定位、偏航纠正 |
| 激光 SLAM | 改地图即可 | 地图同步、动态避障协同 |
不管选哪种，系统层级都差不多：现场设备层（AGV）→ 调度系统 RCS/WCS → 上位机 / WMS / MES。咱们要对接的，就是后两层之间那道缝。
二、系统怎么对接？三种常见通道各有分工
- REST API：MES 调调度系统下发任务、查状态，通用好做，实时性一般；
- WebSocket：AGV 位置和状态变化主动推给上位机，做实时监控大屏用；
- OPC UA / Modbus：和产线 PLC 在同一协议体系里，方便直接做硬件级联锁。
// 上位机向调度系统下发搬运任务（典型 JSON 结构） POST /api/tasks { "taskId" : "T20260919-0001", // 由上位机生成，全局唯一 "type" : "carry", "from" : { "point": "P01" }, "to" : { "point": "P02" }, "priority" : 5 } // 调度系统只回执状态，断线重连靠 taskId 查询，绝不重复下发
任务走的是一条明确的状态链：已创建 → 已接单 → 去取货 → 等取货确认 → 搬运中 → 等放货确认 → 完成；出异常就进取消或失败分支。这个状态机两边必须对齐，否则一个说"还在搬"、一个说"早完成了"，对账时能崩溃。
三、交通管制：多车为什么会活活堵死
集中式调度里，路径统一规划，路口靠加锁来管。常见做法是这么几条：
- 把路口、窄巷道设成"资源点"，同一时刻只放一辆车进入，本质就是互斥锁；
- 走申请 — 占用 — 释放三段式，进门前申请、通过后立刻释放，别占着不动；
- 防死锁：提前预约路径上的几段，或者干脆规定单向环路，从根上消除对向抢道；
- 充电区、待命区设避车位，低电量自动去充，别让车在主干道上趴窝。
说实话，很多现场堵死不是算法不行，是地图点位设计不合理——双向窄道太多、交汇点没留缓冲区。这种情况改地图往往比改算法管用得多，而且立竿见影。
四、和产线PLC握手：叫料、到位、装卸完成
这是最容易扯皮的边界。车到了，产线知不知道？货装完了，车知不知道？标准的五拍是这样：
- 产线缺料 → PLC / 上位机发叫料请求；
- 调度派车 → 车辆上报"去接货"；
- AGV 到上料点 → 上报到位，PLC 确认对接；
- 自动或人工装卸完成 → PLC 发装卸完成信号；
- AGV 离开 → 上报任务完成，产线恢复。
信号必须双向回执加超时：到位后 30 秒还没收到装卸信号，就报警转人工，绝不能无限等。我之前做过一个仓库项目，就是装卸完成只发不收——AGV 以为还在装、产线以为车早走了，结果物料在半空扔下。后来加了双向确认和超时升级，才算根治。
握手信号建议走 OPC UA 或调度系统的 IO 接口，少用硬接线。后期加个点位、改个节拍，软件点一下就行，不用拆柜子重新放线。
五、异常处理和上线步骤，别跳步
现场要面对的异常无非几种：车离线、堵路、低电量、货物丢失、急停。
- 堵路：AMR 自动绕行，或调度安排拖离，超时人工介入；
- 离线任务：先挂起，车恢复后逐条对账状态，防止出现"幽灵任务"；
- 急停：安全回路优先级最高，调度系统只负责记录，不参与判断。
上线顺序一定不能乱：单车跑通点位 → 双车单路口会车 → 多车多任务压测 → 最后再接 MES。压测时务必人为制造拥堵和离线，平时跑得顺不代表真的能用——异常场景才是这套系统的考场。
如果你正要对接 AGV，先去现场拿到两样东西：调度系统的接口文档和车间地图点位表。重点确认路口有没有被当成互斥资源、装卸信号是不是双向回执。这两个问题现在不问清楚，上线之后你就得天天泡在车间里，处理那些堵成一串的车。