2. AGV系统组成与站点建模

要理解AGV为什么能“自己跑、自己找路、自己排队干活”，不能只盯着车体本身。一台AGV只是执行末端，真正让它形成生产力的是一套分层协作的系统：车体负责运动与承载，导航负责定位与姿态，站点定义可停靠的作业位置，地图提供可行驶的拓扑与几何约束，任务描述“要做什么”，调度系统决定“谁在什么时候去做”。这六者不是并列关系，而是从物理层到逻辑层逐级抽象、再自上而下逐级约束的关系。

一、六层对象的分工与边界

先明确每一层“管什么、不管什么”，这是后续建模不混乱的前提。

• 车体（Vehicle）：物理执行单元，包含驱动、转向、举升/牵引机构、电池、安全传感器（激光雷达、防撞条、急停）。它只关心“我能不能动、载多重、还剩多少电”。
• 导航（Navigation）：解决“我在哪、朝哪、怎么到下一段”。常见方式有磁条/二维码、激光SLAM、反光板、自然轮廓导航。输出的是位姿（x, y, θ）与路径跟踪指令。
• 站点（Station）：作业的锚点，是任务与地图的交汇处。一个站点通常包含：站点ID、坐标与朝向、允许的动作（取/放/充电/等待）、停靠精度要求、可服务车型。
• 地图（Map）：由站点、路径段、区域（禁行区、减速区、充电区）构成的拓扑图，叠加几何坐标与属性。地图是导航与调度的共同底座。
• 任务（Task/Mission）：一次业务请求，如“从A站取托盘送到B站”。任务包含起点、终点、优先级、时间窗、载具类型要求。
• 调度系统（Dispatcher/RMS）：全局决策者，负责任务分配、路径规划、交通管制（路口互斥、单车道方向）、充电调度与异常处理。

二、从任务到动作：一次搬运的完整链路

假设仓库有一条典型任务：“将托盘从入库站 IN-01 搬运到立库接驳站 ST-07”。这条任务在系统中的流转可以拆成如下过程（示例参数为教学假设，非实测）：

1. WMS/上位系统向调度系统下发任务，字段包括：任务号 T20240521-018、起点 IN-01、终点 ST-07、优先级 5、要求车型 Forklift-A。
2. 调度系统查询地图：IN-01 与 ST-07 之间存在路径 P1→P4→P9→ST-07，总长约 86 m，途经一个双向单车道区段。
3. 调度系统筛选可用车辆：AGV-03 电量 78%、空闲、车型匹配，分配该任务。
4. AGV-03 导航模块加载路径，从当前位姿出发，逐段跟踪；到达 IN-01 后，站点触发“取货”动作，举升到位并确认载货传感器信号。
5. 调度系统对 P4→P9 区段加锁，防止对向车辆进入；AGV-03 通过后释放锁。
6. AGV-03 到达 ST-07，执行放货动作，上报任务完成；调度系统更新站点占用状态与车辆状态为空闲。

可以看到，任务是业务语言，路径与站点是地图语言，位姿与动作是车体语言，而调度系统是翻译官与交通警察。任何一层缺失或定义不清，都会表现为“车到了但停不准”“任务卡住不分配”“路口死锁”等现场问题。

三、站点建模的关键字段与常见坑

站点不是地图上的一个点，而是一个带属性的作业对象。工程上建议至少定义以下字段：

常见坑包括：站点朝向与货架方向不一致导致取货失败；同一站点被两个任务同时占用；站点坐标写在地图但未同步到调度系统数据库。解决思路是让地图与调度共用同一份站点主数据，任何修改走版本化发布，而不是两边各改一份。

四、六层关系总览

下图把车体、导航、站点、地图、任务、调度系统的依赖与数据流放在同一张关系图中：调度系统向下发任务与路径，地图与站点提供约束，导航把路径变成车体动作，车体状态再回传调度形成闭环。

五、建模时的三条工程原则

第一，站点与地图同源。站点坐标、朝向、可服务车型应作为地图数据的一部分统一维护，调度系统只引用ID，不另存一份坐标。否则地图更新后调度仍用旧坐标，会出现“车停在旧位置”的隐性故障。

第二，任务只描述业务意图，不描述具体路径。任务写“从IN-01到ST-07”，路径由调度系统根据实时地图与交通状况计算。如果把路径写死在任务里，一旦某段路被占用或维修，任务就无法自动绕行。

第三，车体状态必须实时回传。调度系统需要知道每台车的位姿、电量、载货状态、当前任务阶段。没有状态回传，调度就是“盲派”，容易出现重复分配或死锁。工程上通常以1～5 Hz的频率上报位姿，任务状态变化时立即上报事件。

理解这六层关系后，后续的路径规划、交通管制、任务调度算法才有稳定的数据基础。站点建模看似只是填几个字段，实际上决定了整个系统能否从“单车演示”走向“多车协同生产”。