我接手过的AGV仓储项目不算特别多但每一次都让我对调度系统才是仓库自动化灵魂这句话体会更深。早先做第一个AGV仓储项目的时候我也曾天真地以为买几台AGV小车铺好二维码系统就能自动搬货仓库就无人化了。结果真正跑起来才发现三台车在窄巷道里互相堵住、任务死锁、充电桩排队混乱整个仓库的搬运效率甚至不如人工。后来反复排查核心原因才意识到AGV仓储系统的难点从来不在硬件本身而是在调度算法——尤其是路径规划、任务分配、多车避让这三件事。也正是那次折腾让我把A算法从能跑通Demo彻底吃透到了能扛住真实仓储节拍。这篇文章我就拿一个三条AGV基本A算法的真实项目来复盘把从选型到部署的完整链路和踩坑记录都捋清楚给正在做或者在调研AGV仓储方案的朋友一个参考。1. 项目从0到1为什么仓储里放不进三台车1.1 需求背景什么样的仓库需要AGV这个项目所在的仓库属于一个中型电商仓面积大约4000平米货架区域用标准重型货架巷道宽度只有1.8米。货物搬运主要在两个区域之间流转收货暂存区到上架区拣货区到出库暂存区。之前是用人工地牛手动液压托盘车拉着货物走一个班次要走十几个来回累不说效率还很不稳定——早班精神好走得快夜班疲劳容易出错或者干脆摸鱼歇着。老板决定上AGV目标很直接干同样的活一天两个班次搬运工从6个人降到2个人剩下的主要是做异常处理和系统监控。硬件选型最终定了三台磁导式AGV磁条导航载重500kg直角堆垛。选三台不是拍脑袋是根据节拍算出来的——每小时搬运任务峰值在20趟左右单趟平均行驶距离约120米AGV空载速度1m/s负载速度0.8m/s加上叉取/卸货时间单车小时理论搬运量8趟左右三台车富余率控制在20%上下相对稳妥。这个测算是我后来总结项目时最想强调的一点**AGV仓储项目的起点一定是节拍计算而不是先看车的品牌型号。**很多项目失败败在起点就错了——车买多了成本高买少了节拍跟不上调度系统再牛也无力回天。节拍计算要考虑的不只是行驶速度还有转弯降速、举升时间、充电时间、任务排队时间等等实际节拍往往会比理论值低20%到30%所以余量一定要留够。1.2 磁条导航与地图建模先有个路再谈走路磁导式AGV靠地面上铺设的磁条来感知路径这在当前AGV市场里属于成熟可靠的老方案。相比激光SLAM和视觉导航磁条导航的好处在于成本低、部署快、环境适应性好不依赖复杂的地图特征提取坏处也很明显——路径刚性一旦铺好磁条想改路线就得重新贴条灵活性差。但这个项目的仓库巷道固定、业务区域稳定磁条导航的劣势基本不影响使用。磁条铺好之后接下来最关键的就是地图建模。AGV运行的地图不是给司机看的那种带街景的地图而是抽象出来的节点-边拓扑图交叉点、转弯点、停靠点、充电点都抽象成节点节点之间用线段相连每个节点有唯一的ID和坐标每条边有长度、方向限制、最大行驶速度等属性。A*算法跑的就是这张拓扑图而不是包含全部物理空间信息的栅格图。这个取舍值得说道说道。网上大量A算法教程用的都是栅格地图也就是把仓库划分成一个个网格每个格子要么是空地要么是障碍物算法在网格之间寻路。确实直观但在真实AGV系统里纯栅格地图很少直接用——因为栅格地图需要实时处理障碍物状态计算量大、路径不平滑车辆走起来会频繁急转对电机和机械结构都不友好。实际工程里更常用的是拓扑地图A搜索的目标从找到连续空闲格子变成在节点间找一条最短的边序列搜索空间小了一个数量级路径也更符合车辆运动学约束。1.3 调度系统架构谁在指挥这三台车调度系统的架构简单说是上位调度车载控制器两层结构。上位调度负责出题任务管理、路径规划、车辆调度、交通管理车载控制器负责执行沿路径行驶、到位停车、举升卸载、状态上报。上位调度是一个常驻的Java服务车载控制器是AGV厂商配套的嵌入式程序两者通过WiFi用TCP长连接通信。调度服务维护两个核心队列任务队列待执行的搬运任务和车辆状态表每台车的位置、状态、电量、当前任务。每来一个新任务调度服务先查车辆状态表找一台空闲车再用A*算法在这台车当前位置和目标取货点之间规划一条路径下发到车载控制器执行。执行过程中车辆每隔200ms上报一次位置和状态调度服务据此更新车辆状态表并做交通管理。我做的第一版调度系统就漏了交通管理这一层——只做路径规划和任务分配不处理车辆互相阻挡的情况。结果就是经典的教育场景两辆车在一个十字交叉口相遇谁都不让谁死锁卡住不动等着人工去处理。那段时间调度组的同事最怕听到对讲机里喊车又堵了。所以后来我把大量精力放在研究怎么让三台车心平气和地共享道路A*算法也在那个阶段从基础版本进化到了更接近工程实用形态的版本。2. A*不是跑通就完事路径规划核心算法落地2.1 为什么偏偏选A*启发式搜索的最优性价比路径规划算法可选方案不止A一种。Dijkstra是最典型的无启发式搜索——它从起点出发向四面八方扩展直到找到终点保证能找到最短路径但搜索范围大、耗时长广度优先搜索BFS和深度优先搜索DFS则各有侧重BFS保证最短但对图大时内存开销大DFS则完全不能保证最优动态规划算法比如Floyd-Warshall适合离线算全图任意两点间的最短路径但不适合地图频繁变化的在线场景至于D、LPA*这类动态路径规划算法适合地图障碍物频繁变化的场景但对仓储环境来说有点过度设计——仓库里静态障碍物是绝对主体动态障碍物比如临时堆放的货物、维修中的AGV出现的频率不高只要有一套好的动态避让策略就够了。A在这中间正好处于好用的位置它通过启发式函数引导搜索方向比Dijkstra搜索效率高得多又能保证在启发式函数满足一致性条件h(n) h(m) cost(n, m)时找到最优路径。这个最优性价比正是AGV仓储场景需要的——路径规划频率高、地图规模中等、静态障碍物为主、要求实时性这几条A全都能满足。我记得当年学习数据结构时老师讲过一句话**如果你的系统对实时性要求高数据是图结构不是序列结构那A几乎是不需要犹豫的默认选择。**这个判断在AGV仓储项目里完全得到了验证。三台车同时作业任务下发频率平均10秒一个每个任务路径规划耗时设计要求不超过500毫秒A在几百个节点的拓扑图上做一次规划实测平均耗时在几十毫秒量级完全够用。2.2 代价函数设计走一步不仅要看距离还要看代价A*算法的核心是评估函数f(n) g(n) h(n)。g(n)是从起点到当前节点n实际走过的代价h(n)是从当前节点n到终点的预估代价。算法在每一轮循环中从开放列表中取出f(n)最小的节点进行扩展直到终点被取出。在AGV仓储这个场景里代价g(n)可以直接定义成行驶时间而不只是行驶距离。因为不同类型的路径段AGV的行驶速度不一样直道速度快1m/s、弯道速度慢0.3m/s甚至更低、正对货架准备叉取的区段速度更慢0.1m/s如果用距离当代价算法算出来的是距离最短的路径但未必是时间最短的路径——比如一条距离近但弯道特别多的路径实际跑起来可能比一条距离略长但全是直道的路径耗时更久。所以我把g(n)定义成累计估计行驶时间g(n) g(parent) edge_cost(current, parent)其中edge_cost表示从父节点到当前节点的预估行驶时间计算公式为edge_cost distance / speed_estimate不同路径段的speed_estimate我是根据实际测试标定出来的。标定方法是让AGV在每种类型的路径段上反复跑20次取平均速度。比如直道平均实测速度0.95m/s90度弯道平均实测速度0.3m/s含减速和加速过程取货区段平均实测速度0.12m/s含对位和叉取动作。这种标定工作看起来不起眼但对A的效果影响极大——如果用统一速度算代价A规划出来的路径往往会频繁进出弯道因为纯距离最短嘛实际跑起来反而慢还容易造成车辆频繁加减速对电机寿命也是消耗。h(n)启发式函数我用的是曼哈顿距离Manhattan Distance。如果地图允许直线路径、没有强制走网格理论上也可以用欧几里得距离Euclidean Distance但当A运行在拓扑图上、节点之间通过直角边的连接时曼哈顿距离更符合实际运动约束且计算简单能保证可采纳性即h(n)永远不会高估到终点的真实代价从而保证A找到最优解。有的项目会用对角线距离或者切比雪夫距离那是在操作允许沿对角线移动的场景下用的比如无人机巡检或某些全向AGV麦克纳姆轮沿着任意方向移动。像我们这种普通差速/舵轮AGV只能在矩形网络里横平竖直地走所以曼哈顿距离是最合适的。核心代码逻辑如下我把一个可用版本简化了一下去掉了一些业务判断import heapq from math import inf def a_star(graph, start, goal, time_cost): open_list [] heapq.heappush(open_list, (0, start)) came_from {} g_score {node: inf for node in graph.nodes} g_score[start] 0 f_score {node: inf for node in graph.nodes} f_score[start] heuristic(start, goal) while open_list: current heapq.heappop(open_list)[1] if current goal: return reconstruct_path(came_from, current) for neighbor, edge in graph.neighbors(current): tentative_g g_score[current] time_cost(current, neighbor, edge) if tentative_g g_score[neighbor]: came_from[neighbor] current g_score[neighbor] tentative_g f_score[neighbor] g_score[neighbor] heuristic(neighbor, goal) heapq.heappush(open_list, (f_score[neighbor], neighbor)) return None # 找不到路径 def heuristic(node, goal): return abs(node.x - goal.x) abs(node.y - goal.y)这段代码放到真实项目里变成工程版本时我加了几个比较重要的增强逻辑一是转角惩罚。节点和节点之间的边在空间上可能有夹角两条边在节点处形成转弯这个转弯动作不仅耗时还会影响舒适度和机械寿命。我在代价函数里加了一个转弯惩罚项——当父边和当前边的夹角度数超过45度时额外增加一个250ms的惩罚代价。这个优化做出来之后路径明显变直了车辆跑起来稳定很多也减少了对磁条路径的磨损。二是多目标点的路径规划TSP路径拼接。AGV执行一个复合任务比如去A点取货送到B点再回到充电桩充电这不是单条A路径能搞定的而是需要依次规划多段路径。我的做法是逐段调用A每算完一段就把当前节点更新为下一段的起点继续算。这段逻辑单独提出来一部分原因是后续做多车调度时的避让策略也复用了分段校验的逻辑。三是路径平滑处理。A*算出来的路径是一串节点序列节点之间是折线转弯直接下发的话车辆运行轨迹会非常僵硬在转弯处速度波动大、定位可能丢。我在路径上做了一个后处理把路径中连续的直线段合并成一条长直线只保留必须转弯的转折点。这个优化对行驶稳定性的提升肉眼可见——路径下发到车端之后车跑起来明显顺滑了不再是一顿一顿地走。2.3 从能跑通到能扛活A*实际调参经验A*算法的工程落地调参数是一个看不见却极其重要的环节。我把我在项目里调过的几个关键参数拎出来分享一下这些参数直接影响路径质量和系统性能。启发式权重Weight因子。基础A上h(n)的权重通常是1叫精确A保证最优。但有时为了追求更快的规划速度可以把权重加大到1.2甚至1.5——权重越大搜索越贪婪算得越快但路径会偏离最优丢失一些效率。AGV仓储场景里地图不大几百个节点原本一次规划只要几十毫秒就算权重设成1也是实时响应没必要为了省几十毫秒去牺牲路径质量。但如果你管理的是几千平米、上万个节点的超大仓库规划频率又高那可以试试把权重调到1.3左右作为折中。个人经验是先从1.0开始性能扛不住了再放宽不要一上来就调。开放列表/闭合列表的存储结构。A*性能瓶颈主要在开放列表的插入和弹出操作我用的是二叉堆priority queuePython里就是heapq插入和弹出时间复杂度都是O(log n)足够满足日常需求。如果节点规模特别大可以考虑斐波那契堆摊还时间复杂度更优但工程实现复杂没有必要就别碰。死胡同场景处理。拓扑地图里偶尔会有回头路的边存在比如维修区、待命区在路网末端。A在这些区域容易进去出不来搜索扩展到死胡同底层然后再回溯。我的优化是对末端死胡同节点加一个禁入标志除非目标节点本身就在死胡同里否则A在搜索过程中不扩展这些节点的邻居。这个优化对搜索效率的提升很明显死胡同会让A*白白扩展很多无用节点。多车复用路径时的动态代价叠加。基础A算出来的路径是静态最优但如果三台车同时跑一条静态最优路径上可能有三台车挤在一起反而比绕一条空闲的远路更慢。所以我后来给每条边增加了一个动态拥塞系数——某条边正在被占用的AGV数量越多这条边的代价就越高A在路径规划时就会倾向于避开拥堵区域。这个优化是后面多车调度改进的关键一环单独说一下def time_cost(current, neighbor, edge): base_cost edge.length / edge.speed congestion congestion_factor(edge) # 根据当前占用车辆数返回一个乘数 return base_cost * congestion把拥塞系数乘在代价上A*就能天然地避开车多的路段而不用额外写复杂的交通管制逻辑。这个方法简单有效但要注意系数不能设得太大否则车辆会为了避开拥堵绕很远的路反而整体效率下降。我实测下来系数在1.5到2.5之间比较合适——单台车只在路被占用时才会去绕路不会没事就在仓库里散步。3. 三车协同调度比想象中麻烦的冲突与死锁3.1 为什么会死锁一个两车相遇的简单数学问题三台AGV同时工作死锁问题是我在这个项目里掉坑最惨的地方。死锁的本质用操作系统里的经典定义来说多个进程这里是AGV彼此持有对方需要的资源且都不放弃自己已有的资源于是谁都前进不了。在AGV仓储场景里具体表现就是车A在路径段S1上从北往南车B在路径段S2上从南往北S1和S2在交叉点N处汇聚两条路径段的后续都需要经过NA想通过N向南B想通过N向北但是N周围的空间不够两辆车同时通过结果就是A和B都停在N旁边互相对峙谁也不让谁直到人手动干预。这还不算最头疼的——仓库里有时会形成三辆车围一圈的循环等待死锁解起来更麻烦。死锁检测最常见的方案是资源分配图Resource Allocation Graph把AGV看作进程路径段看作资源有向边表示AGV正在占用或正在等待某段路径。当资源分配图中存在环就说明系统进入了死锁状态。我最早做交通管理时第一版就实现了一个简单的死锁检测器每次路径分配前跑一次循环检测。结果发现能检测出来死锁但不知道怎么预防死锁——检测到死锁时车已经停在那里了解死锁的成本和停车的成本甚至更高。所以后面我把重心放在避免死锁发生上而不是死锁后再解。3.2 动态避让的三种策略逐个分析优劣解决AGV冲突和死锁的策略实际工程里常见的方案大概有三种先到先得FCFS加优先级预留路径段Reservation以及单向路网/交通规则法。我三种都实际验证过简要说说优劣。策略一先到先得FCFS优先级。这是最简单的一种做法。每条路径段同一时刻只允许一台AGV占用AGV在进入某条路径段前先向调度系统申请通行许可系统检查该路径段是否空闲空闲则授权否则排队等待。多车同时申请同一段路径时优先给先到达或先申请的。这个方案的优点是实现简单、容易理解、不易出错。缺点是可能造成优先级反转——后申请但运行更快的车被前车堵住整体效率受限于最慢的那台车。只适用于车少、路径简单的场景比如两台车在两条独立环线上跑基本没问题但三台车共享多个交叉点的时候这个方案的效率就不够看了。策略二预留路径段Reservation / Timed Path Reservation。这是我在这个项目的最终方案。核心思路是每台AGV在执行任务前先向调度系统提交它将要经过的路径段以及预计通过时间窗口例如经过节点N1到N2的段从第25秒到第38秒调度系统检查这些时间窗口是否与其他车的预留相冲突如果冲突则让后来者调整通过时间减速等待或重新规划路径。这个方案的好处是从根上避免了冲突——两辆车永远不会被分配到同一个时空交点。代价是计算复杂度上升特别是路径多、时间窗口重叠多的时候需要有一个高效的时间窗口冲突检测模块。三台车的规模下这个方案表现非常好几乎杜绝了死锁。策略三单向路网交通规则。把整个仓库地图改造成单向行驶类似城市单行道车辆只能按逆时针或顺时针环绕交叉口用红绿灯规则控制或者用主干道优先、支路让行的优先规则。这个方案的成本最低效果最稳定但对仓库布局要求高——如果仓库出入口都在同一边强制单向会导致绕路严重反而降低效率。我们仓库的巷道布局是回字形本身适合单向环线但这个方案没选上的原因在于入库任务频繁要从收货暂存区横穿主通道到货架区域如果搞成纯单行车要绕很大一圈搬运效率掉得厉害。最终我采用的是**策略二为主、策略三为辅助的混合方案**主干巷道执行单向通行末端和取货区执行双向通行双向通行段的占用通过时间窗口预约机制来管理。这样既享受了单向路网的稳定又保留了双向操作区的灵活。3.3 冲突检测的时间窗算法实现时间窗Time Window算法的核心是把每段路径的占用情况抽象为时间区间序列。当一辆车申请使用某条路径段时冲突检测模块把这个申请与已有时间窗做交集判断——只要两个时间窗有重叠就说明该路径段即将发生冲突。具体的数据结构我用的是一个路径段ID - 时间窗列表的Map结构。每个时间窗记录四元组(露台段ID, 占用起始时间, 占用结束时间, 车辆ID)。每次申请路径段时按以下步骤走def check_conflict(edge_id, new_tw, reservations): new_tw: (start_time, end_time, vehicle_id) 返回None表示无冲突否则返回冲突的时间窗 tw_list reservations.get(edge_id, []) for tw in tw_list: # 两个时间窗有交集的条件是新的开始时间不晚于已存在的结束时间 # 且新的结束时间不早于已存在的开始时间 if not (new_tw[1] tw[0] or new_tw[0] tw[1]): return tw return None注意这里的时间窗并集判断是开区间还是闭区间很关键——实际车辆走路径段时两头会有加减速和停靠误差所以我总会在每个真实时间窗两端各放宽2秒的安全余量即预留时间窗的起止时间都比车辆预估的起止时间提前/延后2秒。这个安全余量的设定值得细聊调太大仓库通行效率就低路径段被占用时间更久调太小车辆实际运行误差可能击穿安全窗口造成真实碰撞。我试过1秒、2秒、3秒三档最终在驾驶稳定性和调度密度之间平衡下来2秒最合适。这个余量参数也跟AGV的定位精度有关——定位越准能接受的余量越小效率越高定位差的系统必须把余量加大才能保证安全。调整车辆通过时间窗口来避免冲突时有两种常见操作让车减速慢行滞后到达时间压缩窗口或者让车绕道换一条路径段序列。我规定了一个阈值如果等待时间超过15秒则重新用A*规划一条新路径绕路可能更划算如果等待时间在15秒以内则让车在进入冲突区前的等待点停车等待滞后再进入。这个15秒阈值是基于出货节拍和车辆电量消耗综合算出来的——停车等待本身要消耗电量但绕行多走的距离也要消耗电量15秒正好是两条路径消耗电量的等效平衡点。3.4 死锁恢复机制真撞上死锁了怎么办虽然说预防胜于治疗但完全不做死锁恢复策略还是太理想化了。现实里车辆可能因为地面湿滑、机械故障、通讯延迟等问题没有按计划的时间窗到达指定位置导致其他车的时间窗判断全部错乱最终推演出一场死锁事故。我的死锁恢复策略分三步第一步检测死锁环。调度系统周期性遍历所有车辆的当前状态构建等待依赖图检测图中是否存在环。检测频率是每200ms跑一次图节点就是车辆ID如果一辆车正在等待另一辆车释放某段路径就画一条有向边。用拓扑排序判断有环无环复杂度O(nm)三台车规模下毫秒级完成。第二步选择并执行恢复计划。当检测到环时需要确定牺牲哪一台车——让它向后退回上一个安全的停靠点后退点给其他车让出空间解开死锁环。选择牺牲车的原则优先选电量高但任务紧急度低的车后退距离短的更好尽量别选正在载货执行关键任务的车。这一步用了一个简单的加权评分函数来选车不必搞太复杂的AI模型。第三步恢复后重规划。牺牲车退让之后原路径段可能已经变化其他车可能走过了需要重新用A*规划剩余路径。而且要让路退让的那台车恢复运行必须重新申请时间窗重新加入调度计划。这个恢复过程尽量做到对业务无感——如果周转区内有备班车或者系统里有可重新调度的任务对外表现一致操作端不需要感知到内部死锁恢复的过程。实际运营中死锁恢复机制在三个月内触发了差不多27次平均每周两次左右。其中大部分是偶发电量不足、车辆偏离磁条等异常场景引发的解死锁平均耗时40秒到1分钟。这个频次和耗时在可接受范围内毕竟总比人工搬车强多了。4. 部署上线踩坑清单稳定运行的隐形条件4.1 地图精度磁条铺设与坐标标定的坑AGV仓储项目部署阶段最容易被低估的是地图的精度问题。磁条铺完了但每段磁条的物理位置与理论位置之间一定有误差这个误差如果不校正车辆定位偏差会沿着路径累积最后车辆可能在磁条交汇处完全对不上坐标掉线、走偏都在所难免。我们的方案是磁条RFID标签校正的组合定位。在每一个关键节点交叉口、停靠点、取货位铺设RFID标签车辆行驶时经过RFID标签读取到标签ID后以该标签的物理坐标为基准重新校准自己的当前坐标把累积误差清零。这个做法在AGV领域很常见业内叫绝对定位相对航位推算的组合导航方案。部署时我踩过的坑是RFID标签坐标写错了一个——某条路径上RFID的物理贴在磁条向右偏移了5厘米的地方但坐标系里写的是居中值导致车辆每次经过那里都会把位置修正到偏离5厘米的点上连续几次修正后车载货叉对不准货架中心直接触发叉车定位异常报警。那段时间排查了很久最后逐点核对坐标表才发现问题。所以这里提醒一句地图数据的准确性和一致性是AGV项目上线的生命线标定要第三方目检加第二次独立复核多一道保障不亏。4.2 通讯延迟小车撞墙只差200毫秒AGV调度系统对实时性要求极高通讯链路是重中之重。我们用的WiFi组网仓库里有大量金属货架对无线信号衰减比较严重某些死角位置的信号强度很低车辆车载控制器和调度服务之间的数据包延迟会飙升到1秒以上。有一次任务车已经走到了货架巷道口调度系统下发继续前进的指令因为延迟没有及时到达车载控制器以为和调度断开连接按照安全策略自动停车了。结果调度系统那边没收到停车状态继续按原计划给下一台车分配了同一段路径后面的车觉得前面没车全速前进——就差200毫秒两辆车就在巷道口差点撞上。这次事件之后我们在两个层面补了漏洞一是通讯层面在仓库所有弱信号死角加装了无线AP接入点保证任何一个运行位置的信号强度不低于-65dBm二是调度逻辑层面每台车每次上报状态时携带序号调度系统发现车辆状态超过500毫秒未更新就立刻把该车标记为通讯异常禁止给该车和相邻路径下发新任务。这个心跳超时路径隔离的双保险机制上线后再没发生过类似的近距离惊魂。4.3 电池管理和充电策略没人想半夜换电池AGV的电量管理说出来都是泪。有一次我们预估粗心让一台车连续跑了两小时高负载任务电量见底车辆在下坡路段直接断电停车货叉上还托着一托盘的货造成整段巷道堵塞另一台车被堵在后面全系统瘫痪了十几分钟。事后我们规划了更严格的电池管理策略每台AGV的电量上报到调度系统调度系统设置两级阈值——电量降到30%时标记该车为可执行任务但优先级降低降到20%时强制插入充电任务路径规划优先去充电桩充电桩配置了3个三台车共用充电桩前设置了排队缓冲区。关于充电桩排队的死锁我们也有过一次教训两台车同时到充电桩A在充电桩1充着B在充电桩2充着但B充完了因为路径被A挡住出不去A也充完了但路径被B挡住出不去因为B堵了出口——两辆又死锁了。后来充电区设计成环形动线进出口分开这个问题才彻底解决。AGV项目的隐形工作量实际上这三大块地图精度、通讯稳定性、电池管理占了大概三分之一。算法做得再好这基础三项不过关系统永远都在救火状态。5. 效率验证与压测如何证明调度系统真的可靠5.1 压测设计用真实节拍与极限节拍双重考核上线前我们对调度系统做了一轮完整的压测。压测的目标不是能跑而是在正常节拍下稳定、在极限节拍下不崩溃。我设计了两个梯度正常节拍压测按业务预估的20趟/小时任务量持续运行8小时记录任务完成时间、车辆利用率、路径冲突次数、死锁次数。 极限节拍压测把任务量调高到35趟/小时连续运行2小时看系统在超负荷下是否会出现链路堵塞、消息积压、调度延迟激增等问题。压测中需要重点盯的几个指标任务平均完成周期从任务下发到货物搬运完成的平均时间。正常节拍下目标小于150秒实际实测在130秒左右合格。车辆空驶率AGV行驶中空载的时间占比。空驶率越低说明调度越合理。实测三台车空驶率平均32%比较健康。碰撞/冲突次数统计每百次任务中调度系统触发避让或冲突处理的次数。实测正常节拍下午百次冲突12次基本都通过时间窗错峰解决了没有升级成死锁。调度服务CPU和内存曲线连续运行4小时看内存是否有泄漏趋势CPU峰值是否过高。实测CPU峰值35%左右内存平稳。5.2 边界场景测试如果一台车卡住了怎么办边界场景测试是压测中最有价值的环节。我专门设计了几类异常场景来考验系统单点故障测试让A车在运行途中突然停车报错。期望表现是调度系统在2秒内检测到车辆异常将该车从任务队列中摘除已分配的路径段全部释放剩余两辆车自动重规划绕过该区域继续工作。实测从车辆报错到系统完成重新规划耗时约4.5秒达到了预期。死锁构造测试制造两台车对头相遇的场景观察系统能否通过时间窗机制自动化解。实测系统检测到时间窗冲突后A车等待B车先通过时间窗重新排布冲突解除全程无人工干预车辆平均多等待约20秒。断电恢复测试模拟调度服务进程崩溃后重启。调度服务断线期间所有车辆进入安全停车模式原地等待调度恢复后车辆自动重新上报状态系统把未完成任务重新派发车辆继续执行。实测调度服务重启到系统完全恢复业务耗时约30秒这个数字是可以接受的。5.3 性能调优把调度系统的潜能压榨干净压测过程中暴露出来的性能瓶颈主要集中在三个地方一是路径规划算力浪费。早期版本是每个任务到达都立即调用A*全程规划哪怕任务要排队等待车辆空闲。后来优化成任务先入队等确定分配车辆后再基于该车辆的实时位置做路径规划。这样既节省了CPU也避免了规划出来的路径无效化因为等待时间太长车辆位置可能早就变了。二是时间窗列表的查询效率。随着测试进行同一路径段上积累的历史时间窗越来越多线性查找冲突越来越慢。优化做法是给每个路径段的保留时间窗列表按起始时间排序并做索引查询时用二分查找快速定位冲突区间同时定期清理已经过去的旧时间窗超过当前时间5分钟且无车辆等待引用就删除保持列表足够短。实测优化后冲突检测的耗时从原来的平均3ms降到了1ms以内。三是调度消息的批处理。车载控制器每200ms上报一次状态三台车就是15条消息/秒消息量不大但每一条都触发数据库/内存状态更新的话调度服务的CPU会有不少浪费。优化做法是在内存中暂存消息以500ms为一批统一处理批间只更新一次车辆状态表。这样调度服务负载明显下降并且延迟完全可控500ms的批量延迟在实际现场根本感知不到。压测做完之后我对这套三条AGV基本A算法的组合更有底了。它没有用多高深的技术——A是经典算法时间窗预约也不是我发明的——但它把每一环都做扎实了路径规划考虑了车辆运动学约束多车调度用时间窗避免冲突异常场景有兜底恢复机制。这就够用了仓储AGV调度本质上是一个典型的工程问题难点在于把教科书算法变成能稳定扛生产的系统而不是去追什么新鲜的算法花样。6. 一些想提醒后来者的话项目收尾阶段我把这段时间积累的经验沉淀成了几条团队内部的原则在这里也分享给大家参考。第一**AGV项目的复杂度和车辆数量不是线性关系而是超线性关系。**三台车的调度比两台车复杂不止一倍——三台车可能形成循环等待死锁两辆车永远不会。所以做多车调度千万不要把两台车跑通了当作三台车也应该没问题的证据。第二**A算法本身不会帮你解决所有问题重要的是把业务场景建模成算法能理解的形式。**代价函数里加转弯惩罚、加动态拥塞系数这些才是让算法真正贴合业务的关键。很多项目照着教科书跑通了A就觉得大功告成一上线就暴露各种效率问题本质上是业务建模做得不够细。第三**上线之前一定要有完善的压测和边界场景测试方案。**我们在压测阶段模拟的每一类异常几乎都在后来真实运营中碰到过——通讯异常、车辆卡死、电量不足、路径拥堵没有一个例外。前期测试做得越狠后期运维越省心。如果你不想上线之后天天半夜接电话处理车辆死锁就老老实实把异常场景模拟做足。第四**不要迷信全自动化这三个字。**真正稳定的AGV仓储系统一定保留着合理的人工介入通道人工能手动控制车辆、手动修改任务、手动解死锁。完全依赖算法代替人做所有决策在真实仓库里会让你身心俱疲。技术是为了减少人的重复劳动而不是彻底把仓库变成一个碰不得的黑盒子。最后再分享一个我个人的小经验AGV仓储项目的第一优先级永远不是花哨的算法而是稳定地跑完每一个任务。A*作为路径规划底座配合时间窗机制做多车调度再叠加异常监控和死锁恢复这套组合对于三到五台AGV的中小型仓库来说是性价比最高、最值得复用的方案。如果你也是从小规模AGV仓储项目起步希望这篇复盘能帮你少走一些弯路至少别在三台车的规模上就栽跟头。