AGV小车控制系统到底咋设计？上位调度和车体控制分开做还是一锅炖？
最近接了个仓储AGV的项目，30台左右，主要是潜伏式顶升的，场景是电商分拣中心，巷道窄、转弯多，调度系统是WMS那边给的接口，我这边负责从车体底层到上位调度这一整套。
现在卡在架构上：是把调度和车体控制全做在一个工控机上（每台车一个主控），还是调度走嵌入式板（比如ARM跑Linux），车体单独再挂个STM32做运动控制？我担心一锅炖的话后期调度算法一改就要重刷车，但分层做的话两边通信又怕实时性不够，丢包了车直接撞货架。
另外路径规划这边，是上传统的磁条/二维码+区域调度，还是要直接搞SLAM自然导航？预算倒是够，但项目方对上线时间压得死，6个月必须跑起来。有做过的兄弟给点实在的方案，最好说下你们当时怎么权衡的，踩过啥坑。
全部回复 (4)
我之前做过一个48台潜伏式的项目，最后选的方案是：每台车NUC+i7跑Ubuntu，上位调度（任务分配、交通管制、路径规划）全在这台机器上，用ROS做中间件；车体运动控制单独挂一个STM32F4，通过CAN总线和上位联，走的是周期性下发+心跳包机制，周期20ms。实时性实测够用，最大延迟没超过15ms，丢了包上位直接急停，不会撞。
导航别上SLAM，你这个时间节点扛不住。电商分拣中心环境变化大，SLAM建图和长期维护能把你搞死，老老实实用二维码+惯性导航，定位精度±10mm，巷道窄的工况下比SLAM稳定得多，调试周期至少省两个月。30台车的规模，二维码贴下来人工成本大概8-10万，能接受。
调度算法自己写还是用现成的？如果WMS那边接口是标准RESTful，建议直接上开源的OpenTCS二次开发，省事。我们当时是自己写的交通管制算法，踩了最大的坑是死锁——三台车在十字路口互让谁都不动，最后加了基于优先级的抢占机制才搞定，你一开始就把这个考虑进去。
分层做是必须的，30台车一锅炖后期维护能把你搞疯。但你担心的实时性问题根本不是问题，上位和下位之间走CANopen或者EtherCAT都行，你别用TCP/IP那个才叫坑。我们那个项目用的EtherCAT，1ms周期，通信抖动控制在50us以内，根本不会丢包。
还有一点你可能没考虑到：30台车要预留扩展接口，后期加车你不可能重新改协议。提前把车体抽象成统一的ROS节点或者类似中间件的标准接口，加车就是加节点的事，不用动调度核心逻辑。
SLAM在这个时间点完全不现实，6个月连现场建图加调试根本来不及，而且电商仓库货架经常挪动，SLAM地图维护成本太高了，老老实实用二维码+IMU。
另外你这个项目方的需求里有几个关键参数你没提：最大运行速度多少？加速度要求？载重多少？巷道最小宽度多少？这几个直接决定你车体选型和控制周期，运动控制周期如果要做到1kHz，那STM32F4都不够用，得上F7或者直接用DSP。30台车的项目别省控制器的钱，车撞了货架赔起来比控制器贵多了。
问一个关键的：WMS给你的接口是事件驱动还是轮询？任务下达频率大概多少Hz？这个直接决定你上位调度架构怎么设计。如果是轮询且频率低于5Hz，那一锅炖也无所谓，反正实时性要求不高。