1. 为什么是车无人机还要分两层规划1.1 单车不够快单机不够远2023年ESWA上的这篇工作标题看起来挺直白地面车辆UGV和无人机UAV协同做多区域覆盖并且采用双层路径规划。但我刚扫到双层两个字的时候第一反应是这是不是把两个路径规划问题强行叠在一起搞个复杂模型换点性能提升把全文的建模和实验读完之后我得说这个双层的设计是有真实物理背景支撑的不是学术包装。先把问题还原一下。你要对一大片区域做覆盖比如园区巡检、应急勘察、物流配送这类任务的特点是目标点分散在多个子区域里而且子区域之间的道路条件完全不一样。地面车能跑的时间很长、载荷大但它只能在路网或可通行地形上跑遇到一段围墙、一条河、一片绿化带就得绕很远无人机速度快、能直线飞行看起来是完美的补充但多旋翼无人机的航时大家心里都有数20到40分钟级别的续航稍微飞几个点就要返航充电或换电池根本扛不住一整片大区域的连续覆盖。所以很自然的思路就是让车和无人机组队地面车充当移动母港充电宝拖着无人机跑到某个区域附近停下来释放无人机无人机把那一片的离散目标点快速覆盖完再飞回车旁边降落车再赶往下一个区域。这个想法本身不新鲜室内物流、农业植保、搜索救援里都有类似车机协同的影子。但这篇工作切入的角度更细它把问题做了完整的形式化车辆在宏观层面决定先去哪个区域、在哪个位置释放和回收无人机无人机在微观层面决定某个区域内部的哪些点用什么样的顺序覆盖。这两层决策相互依赖又各自成体系所以才叫双层路径规划。如果只用一辆车在路网上绕纯车辆方案的问题很明显大量时间耗在路上而且对车辆到不了的目标点无能为力。如果只用一群无人机去覆盖理论上能全覆盖但每架无人机飞一会儿就要换电池保障体系极其复杂实际用起来成本高、风险也大。车机协同恰好把两者的优势拼起来了车解决长途运输和能源补给无人机解决最后一公里到点覆盖。这也是整个研究成立的物理前提理解了这一层后面所有的建模和算法才有代入感。1.2 双层规划的上下到底拆了什么这篇工作把路径规划拆成两层我个人的理解是上层是战略调度层下层是战术覆盖层。两者不在一个尺度上聊天。上层规划解决的是全局问题给定若干子区域每片区域里有一堆待覆盖的目标点地面车辆要决定自己沿哪条路走、在哪些位置设置起降点、在每个起降点投放多少架无人机、以及什么时候到达、什么时候离开。这一层本质上是带起降点选择的车辆路径问题Vehicle Routing Problem with Release and Recovery Points它的解空间很大因为起降点的候选位置既可以放在路网节点上也可以放在车辆可停靠的任意位置。下层规划解决的是局部问题当车辆到达某一片区域、选定一个或几个起降点之后无人机怎么在这片区域内部执行覆盖。这一层可以理解为带续航约束的覆盖路径规划每架无人机从起降点起飞访问若干目标点再回到起降点所有航迹拼接起来要覆盖完这一片区域的所有点同时单架无人机的总航程不能超过续航上限。两层之间的耦合点就在于时间。车辆到达起降点的时间窗口决定了无人机什么时候能起飞无人机在区域内飞完所有点并返回的时间又决定了车辆必须在起降点等多久。如果车辆提前走了无人机就回不到母港如果车辆等得太久整个系统的总耗时又被拖长。所以双层规划真正的难度不是把两条路线分别画出来而是把两层的时序咬合在一起。这个痛点做过实际带队测试的人应该都有感触仿真里画一条漂亮轨迹很容易真把车停下来等无人机返航时间一错位整个计划就卡住了。2. 问题建模先把边界条件和约束理清楚2.1 区域与任务假设读论文里的建模部分之前先要把场景假设搞明白。这类工作通常会做这样几个设定任务区域被划分为多个互不重叠的子区域每个子区域内有一组已知坐标的目标点需要覆盖地面车辆沿路网在子区域之间移动无人机从车上的起降平台起飞对各子区域的目标点执行覆盖无人机续航有限地面车辆可以携带多架无人机也可以携带备用电源在行驶过程中为无人机充电。这些假设不是随便拍的。多区域划分对应真实场景里厂区多个罐区城市多个小区干线道路连接的多个田块这类结构目标点坐标已知对应巡检点位、配送点、灾情勘察点这些点在实际项目中早就通过地图或勘察确定过了无人机续航有限更是硬约束所有规划必须在这个前提下做。区域划分的方式也值得提一嘴。常见的做法有两种一种是根据地理属性人工划分比如道路、河流、围墙天然形成的边界另一种是算法自动划分比如用泰森多边形或聚类方法把目标点聚成若干簇每一簇对应一个子区域。人工划分的好处是贴合实际地形坏处是区域大小不均匀可能出现某个区域目标点特别多而其他区域很空的情况后面对整体调度会造成明显瓶颈。算法自动划分则能把负载尽量抹平但不一定能尊重地形障碍。这篇工作采用的是预处理好的区域划分把焦点放在区域分配和覆盖路径上我认为这个选择是合理的——如果连区域划分都一起优化问题规模会快速失去控制文章的核心贡献反而被冲淡了。2.2 上层模型车辆去哪在哪里放机上层模型本质上是一个增强版的车辆路径问题。要决策的变量有三类车辆访问子区域的顺序每个子区域内起降点的具体位置车辆在每个起降点的停留时长。目标函数一般是系统总耗时最短。这里的总耗时要做细致的定义它不是纯车辆行驶时间因为车辆可能提前到达某个起降点等待无人机完成任务也可能无人机的任务早做完了但车辆还没赶到。更合理的做法是把总耗时定义为车辆从出发到完成所有区域任务并返回/或到达终点的总时间同时要求所有无人机任务都在这个时间窗口内完成。也就是说最终完成时刻由车辆路线和无人机任务两者中较晚的那个决定。约束条件在论文里也列得很清楚车辆按路网行驶速度固定起降点必须设置在车辆可停靠的位置并且不能和禁飞区域重叠无人机每次起飞后必须在航时上限内回到起降点车辆在起降点停留的时间长度必须覆盖该起降点释放的无人机完成整段任务的往返时间。我在看很多同类论文时经常发现一个问题模型里对无人机可以在多个起降点反复起飞降落这一行为处理得比较模糊。但这篇工作把无人机的角色定义得更贴近实际——无人机是可以反复使用的每次车辆在一个起降点停下无人机起飞完成一批点回到车辆充电车辆移动到下一个起降点无人机再次起飞覆盖下一批点。这样一来无人机的航次变成了一种可由上层调度的资源而不是一次性使用的消耗品。2.3 下层模型无人机怎么覆盖一个区域下层模型是一个经典的覆盖路径规划给定一个子区域内的目标点集合给定一架或多架无人机从起降点出发求一组满足续航约束的环形航迹使得所有目标点都被访问到。如果有多架无人机可用还要做任务分配每个目标点分给哪一架无人机用什么样的顺序访问。这个问题的难点主要在两个地方。第一个难点是续航约束的剪枝。如果只求一条覆盖所有点的最短回路那就是标准的旅行商问题但无人机航时有限一条回路往往飞不完必须拆成多条航段每一段分配给一架无人机。拆分的颗粒度又受到目标点数量的影响目标点稀疏时一段航迹可以覆盖很多点目标点密集时可能飞几个点就得返航。所以下层模型的核心是续航约束下的多航段覆盖它比普通TSP多了一层硬性资源限制。第二个难点是多架无人机的协同。如果车里带了两架甚至更多无人机各架无人机可以在同一区域内同时起飞、并行覆盖但也要去重——不能让两架无人机重复飞同一个目标点否则覆盖效率会打折扣。这个问题的规模一下子又上去了从单航段TSP变成了带容量限制的多旅行商问题。我自己做这类规划时会习惯把下层模型再拆一层目标点先按空间邻近关系聚类成若干分组每一组交给一架无人机。分组的依据不仅是距离还要考虑无人机的航时上限如果一个簇的总访问距离超过了单架无人机的续航就得再细分。这种聚类-簇内路径规划-路径微调的流程和论文里的下层求解思路是一脉相承的工程上也比较容易落地。3. 求解策略为什么分层解而不是一口气硬解3.1 单层模型的复杂度压力理论上讲车辆路线、起降点位置、无人机航迹、时间同步这些变量完全可以揉进一个统一的混合整数规划模型里求解。但真这么干问题规模会迅速爆炸。假设有10个子区域每个区域20个目标点车辆可选起降点50个无人机2架初步算一下决策变量的量级就是1e4以上的离散变量加上时间同步约束商业求解器也未必能在可接受时间内给出可行解更不用说大规模场景。所以这篇工作采用先宏观、后微观的分层思路本质上是把一个大规模组合优化问题降维成两个中等规模的子问题交替迭代逼近。这样做有个好处每一层的模型相对干净可以为各自选择更合适的求解算法坏处也明显分层的方案不保证全局最优两层交替迭代可能陷入局部最优。但从工程角度看能快速给出一个高质量可行解往往比追求理论最优但计算不动更实用这也是为什么这一类方案在应用型期刊上能得到认可。3.2 上层算法与下层算法的搭配上层问题可以看作带起降点选择的VRP这类问题用遗传算法GA、蚁群算法ACO或自适应大邻域搜索ALNS处理非常常见。论文里采用的是进化算法框架每一代对车辆访问顺序和起降点候选位置做交叉、变异适应度函数把下层回传的覆盖成本吃进来。下层问题更精确一点可以用动态规划求小规模的TSP回路也可以对每个区域先做聚类、再按簇求解覆盖回路。如果区域的目标点数量不多用贪心算法初始化加上2-opt局部搜索效果就不错目标点一多就得考虑把区域再分割或者引入启发式。这里要补充一个容易被忽略的细节上层算法在评估一个个体的适应度时需要对所有子区域都跑一遍下层求解。也就是说下层算法要被反复调用很多次如果下层每次求解都很慢整个两层迭代的速度会非常感人。所以实际实现里下层算法必须在最优性和速度之间做取舍。论文里对下层用了快速启发式而不是精确算法从计算时间的角度来说这确实是更聪明的选择——精确解很好看但在迭代里跑不动就是白搭。下面是我在复现这类框架时常用的求解骨架结构大致如下def two_level_plan(regions, vehicle, uavs): best_solution None for gen in range(max_generations): # 上层进化算法生成车辆路线与起降点方案 veh_route ga_evolve(regions, candidate_landing_points) # 由车辆路线计算每个起降点的时间窗口 time_windows compute_time_windows(veh_route) # 下层对每个区域内部求解无人机覆盖计划 task_plans {} for region in regions: task_plans[region] solve_uav_coverage( region.points, time_windows[region], uavs, max_flight_timeflight_limit ) # 汇总上下两层耗时作为上层适应度 total_cost evaluate_total(veh_route, task_plans) if best_solution is None or total_cost best_solution.cost: best_solution (veh_route, task_plans) return best_solution这段代码只是示意性的求解流程但足够说明上下层如何交互上层给下层限定了时间和起降点下层把每片区域的覆盖方案和耗时返回给上层做评估两层之间的信息是双向流动的。3.3 上下层迭代时的关键机制两层迭代看起来简单实际跑起来会有几个坑。我踩过之后总结了几条写出来供大家参考。第一上层方案变化太剧烈会导致下层评估结果不稳定。比如上一代车辆的访问顺序变化不大但起降点位置做了一次大变异下层重新规划出来的覆盖路径可能完全不同适应度值上蹿下跳进化过程很难收敛。解决思路是给起降点位置的变异加一个最大偏移限制让每次迭代的搜索步长保持温和。第二下层求解要保留一点随机性。如果下层每次都返回确定性的贪心解上层会看见一个非常锯齿状的适应度曲面很难判断哪个方案是真的好。我在实现时会给下层贪心加一点扰动或者对相似方案缓存并复用下层结果用来减少重复计算。第三时间窗口的传递必须在上下层之间显式建模。下层求解时无人机起飞和返航时间不能超过车辆在起降点的停留窗口而上层适应度评估时又要计算车辆在某起降点需要停留多久必须取该起降点全部无人机航段的最大返航时间。这个双向依赖如果有一边处理得含糊最终生成的方案在仿真里能跑一到实物联调就出现车走早了无人机悬停在半空的故障。4. 实验设置与效果复盘4.1 三类对比方案怎么设计看实验设计是最能判断一篇工作含金量的地方。这篇论文的实验没有只做自己方案的自我展示而是拉了多个强对比典型的有下面这几类纯车辆方案只用地面车辆执行所有目标点覆盖车辆必须绕路到每个目标点附近如果需要覆盖的点在不可达区域内则该方案直接表现很差。这类对比的意义在于证明无人机参与的必要性。纯无人机方案不考虑地面车辆运输把所有无人机集中在一个中心起降点让它们飞到所有区域执行覆盖。这个方案的软肋在于无人机飞行的距离非常长续航约束把任务的可行范围限制得很小为了覆盖远端区域必须设置很多中间换电池站点现实中根本不经济。单层协同方案把车辆和无人机放在同一个模型里统一求解不做分层。这种方案的对比意义在于证明分层规划在性能和求解时间上的平衡点是可接受的。双层协同方案就是论文提出的方法。实验里通常会在不同规模的任务区域、不同数量的目标点、不同数量无人机配置下做横向对比看总耗时、覆盖率、能耗、求解时间四个维度上的表现。4.2 关键指标怎么选这里有个地方值得强调覆盖率不是唯一的指标。很多论文把覆盖率刷到99%就收工了但在实际应用中超出的那1%覆盖代价可能非常大——无人机多绕一圈、车辆多等半小时、能耗翻倍这些都是隐性成本。这篇工作采用的评价体系更完整总完成时间反映整体调度效率覆盖率反映任务被执行的程度总能耗反映经济性求解时间反映算法的实用性。这四个指标之间其实存在复杂的权衡。比如让无人机以更高的飞行速度执行任务能缩短总完成时间但能耗会快速上升让车辆在起降点多等一会儿无人机可以飞更大的覆盖回路覆盖率会更高但总耗时被拉长。论文里对这些权衡做了分析结果也符合我对这类系统的认知双层规划在总完成时间上明显优于纯车辆和纯无人机方案覆盖率接近单层协同方案而求解时间比单层优化降低了不止一个数量级。4.3 典型结果说明什么我根据实验部分展示的信息把典型结论整理成下面这张表方便直观对比方案总完成时间覆盖率能耗求解时间纯车辆高低受地形限制低短纯无人机高受限续航中远端难以覆盖高中单层协同低高中高很长双层协同本文低高中短表格里的低/高是相对趋势具体数值在不同配置下会有差别但方向是一致的。最值得注意的一行是求解时间单层模型在很多实验配置下已经无法在合理时间内收敛而双层协同由于把问题拆成两个子问题分别求解求解时间被压缩到了可控范围这才使得该方法有实际工程使用的可能性。从这些结果里我能读出这篇工作的核心论点双层规划不是简单的启发式妥协而是一种针对大规模多区域覆盖问题的有效降维策略。牺牲一小部分理论最优性换取计算可行性和方案可落地性这对实际应用场景来说完全是划算的买卖。5. 落地适配点与我的实操经验5.1 哪些真实场景能直接套读懂论文的价值在于能把它迁移到实际项目里。这套车机协同双层覆盖的工作流可以直接适配的场景比我预想的多。末端物流配送地面车停在小区或园区外围的临时停靠点无人机把包裹送到各个楼栋门口。无人机不需要飞到很远的仓库只需要在车辆周围几百米到一两公里内做点对点运输续航不再是瓶颈。农业植保大片农田被道路分隔成很多地块地面车辆携带药箱和无人机在每个地块边沿停一下无人机起飞喷洒喷洒完回到车辆上换药换电池再赶往下一地块。这个模式能显著减少转场时间提高作业效率。电力与管道巡检巡检点往往沿线路延伸几公里甚至几十公里车辆沿检修道路移动无人机负责对塔基、管道上方等人工难以到达的位置做精细检查车机协同能大幅压缩巡检周期。应急勘察灾害发生后地面车辆在安全区域移动无人机进入危险区域采集影像。双层规划的优势在于可以快速加入禁飞区、通信盲区等临时约束生成可执行的任务方案。这些场景共同的特点是覆盖目标分散、区域之间存在不可达地形、任务时间窗口敏感。论文中的模型不一定能直接零改动套用但框架结构非常值得借鉴。5.2 调参与实现中的细节在实际复现类似框架时有几个参数和细节我觉得需要花时间调写出来供参考。车辆速度与无人机速度的比例关系非常关键。如果车辆速度太慢无人机任务做完了但车还没到下一个起降点系统瓶颈就变成车辆如果车辆速度太快车辆等无人机完成任务的空闲时间过长系统瓶颈又变成无人机。上层优化会在两者之间找平衡但对初始参数的敏感度很高。我的经验是先按实际底盘和机型的速度标定好再跑上层进化算法不要让模型在虚设参数上瞎搜。起降点的候选位置要给足数量。很多复现者图省事直接把子区域的几何中心作为唯一的起降点这会严重限制上层搜索空间。正确做法是把道路交叉口、车辆可合法停靠的临时点、信号覆盖良好的位置都列进候选集让上层有充分的自由度去选择。下层算法的续航余量要留一点安全系数。仿真里设定的最大航时往往和真实工况差很多风速、电池老化、载荷重量都会影响实际续航。我通常在规划时把无人机最大航时乘一个0.8左右的折扣系数宁可让规划结果保守一点也不要在实际执行时出现返航电量不足的险情。还有一个细节是关于时间缓冲的。车辆到达起降点后无人机从起飞到完成全部任务、再降落回车辆整个过程不一定正好落在车辆停留窗口内。规划时如果卡得太死实际执行中无人机晚到几秒、车辆就得到处找地方重新规划。我在联调时习惯给每个起降点加30秒到1分钟的安全缓冲区虽然总耗时稍微增加但系统的鲁棒性会显著提升。提示对新手来说最容易出问题的地方是下层规划返回的覆盖时长没有回传到上层做时序约束——检查你的两层接口是否完整传递了时间信息这比优化算法本身更影响最终效果。5.3 局限性与后续可扩展的方向论文的方法当然不是银弹。双层结构的一个固有问题在于如果上下层之间的目标冲突很强比如车辆路线和无人机航迹强耦合分层迭代很容易陷入局部最优。论文对此的处理是依赖进化算法的全局搜索能力和迭代次数但理论上不保证接近全局最优。如果想要更好的解质量可以在上层迭代中加入对候选车辆路线做局部邻域搜索的策略见效明显。另外论文的模型在动态环境下的扩展还不充分。真实场景里风速会变、目标点可能临时增加、车辆可能因为交通堵塞而延误这些动态扰动要求系统具备滚动重规划能力。也就是说当前方案是一条静态的计划但实际任务执行时通常还需要一个执行-监控-局部重规划的闭环这也是我从这篇工作往外延伸时特别想补的一环。我个人的体会是这套双层规划框架最大的价值不在于一次规划出完美方案而在于它把宏观调度和微观覆盖两个层面彻底解耦了让工程团队可以分别优化、分别验证、分别调参这对复杂系统落地来说非常友好。如果你正在做类似的车机协同项目先把上下层的数据接口定义清楚再把车辆等待和无人机等待这两端的时间账算明白你的系统就已经跑赢大半的规划算法了。