潜伏顶升车调度到底咋排的，路径规划+任务分配一起搞还是分开？
最近在做一个仓储的项目，大概60台潜伏式顶升车，地图是单层仓库大概200m x 80m那种，货架巷道单向走。现在卡在调度算法这块，厂商给的是一套黑盒子调度系统，看不见里面咋排的。
想问问各位，潜伏顶升车的调度算法一般包含哪几块？任务分配和路径规划是放一起算还是分两层解？我看有些方案是用A*或者D*做单车的局部路径，再在上面套一层任务分配的调度器，这套思路实际跑起来响应延迟大概啥量级？另外车多了之后，比如超过50台，传统的集中式调度是不是就开始拉胯了，要不要上分布式那一套？
有没有做过类似规模项目的兄弟，分享下你们用的啥架构，单台车调度周期大概多少ms，谢谢了。
全部回复 (2)
60台这个量级在潜伏顶升车里面算中等偏上了,先把架构问题说清楚:任务分配和路径规划现在主流就是分两层,但不是完全解耦——上层做任务指派(谁去搬哪个货架),下层做单车的路径规划(A*、D*、或者时间窗那种带冲突检测的),两层之间有个心跳周期同步状态。
你这60台单层200x80,如果不考虑充电调度、不考虑货架热度,集中式扛得住,但延迟会顶到天上去。我这边之前做的一个70多台的项目,单台调度周期当时压在200ms以内,用的就是集中式+分层:上层每1秒做一次任务匹配(匈牙利或者拍卖那类算法),下层单车50ms一帧重规划。但前提是地图栅格化做了简化,巷道单向所以冲突点少。
超过50台集中式不是拉胯,是看你服务器配置和算法复杂度。如果你的A*是跑全量栅格(比如0.5m一格,200x80就是6万+格子)每帧都重算,肯定不行,得做增量+缓存。我们当时是把热点巷道预计算路径表,车只算自己当前位置到下一路口的短段。
分布式那套别急着上,60台真没到那个份上,徒增调试难度。厂商黑盒子这事你反过来想——你不用管他里面咋排的,你只要盯几个指标:单指令响应时延、空驶率、高峰期拥堵频次、充电策略合理性。这些数据能拿到,基本够你判断他调度够不够用。真要换自研,先问自己一个问题:你这项目周期允不允许你从零搭一套调度?
你这个规模必须分层，不然调度服务器直接卡死。我们项目80台潜伏车，调度周期200ms起步，任务分配用改进的匈牙利算法跑全局最优，路径规划每台车独立A*本地算，两层之间靠状态机同步。