多无人机并行数据采集这几年在测绘、巡检、应急搜救、农业普查里都开始变成刚需但真正下场做过项目的朋友应该都有体会地面站把几条离线航线一摆无人机放飞之后按图飞行遇到突发障碍、禁飞区临时调整、机间位置偏移整场任务基本就废了一半。我们这次做的项目核心就是给“并行采集”这套玩法补上闭环而且刻意把闭环做成了“粗粒度”加上一个无人机检测模块兜底最后整个链路在Matlab里做了仿真验证附了一套可直接复用的代码。做下来我的结论是粗粒度闭环在工程上远比想象中实用它不是精度妥协而是对算力、通信、稳定性的综合妥协很多场景下这才是真正能落地的方案。这篇文章我会把项目的需求拆解、系统架构、轨迹设计思路、检测模块的实现逻辑以及Matlab仿真的关键代码和调参经验全部过一遍。适合正在做多无人机协同规划、集群数据采集、机间避碰检测相关课题的研究生也适合行业里想给现有无人机系统加“在线重规划”能力的工程师参考。1. 三个硬约束多无人机并行数据采集为什么只有“闭环”才能解1.1 场景画像并行采集在哪些场合真正值钱并行数据采集并不是让几架无人机飞同一块区域而是把大范围任务区域做网格切分每架无人机负责一个子区域尽可能同时起飞、同时采集用时间换覆盖面积。典型的例子是大范围农作物长势普查固定翼或旋翼机带着多光谱相机一天内要完成几个平方公里地块的拍摄又比如电力线路巡视一条走廊上百公里单机单趟跑完时间太长必须多机分段同时巡检再比如灾后快速测绘黄金救援时间就那几小时无人机并行起飞去拍不同片区地面端才能快速拼接出全景图。这些场景有一个共同特征任务范围大、环境不完全已知、执行过程中随时可能出现新情况。线路巡检会碰到新建塔吊或者临时施工设备农业生产中可能会有临时搭建的灌溉棚灾后环境就更不用说地面条理完全不可预测。如果全部依赖起飞前规划好的静态轨迹一架无人机撞了新的物体、绕飞或者悬停耽误了时间整个任务的并行节奏就被打乱区域覆盖率、时间窗口都会受到影响。所以并行采集的价值建立在“多机协同效率”上而这种效率恰恰对不确定性极其敏感。这也是为什么项目一开始我们就确定必须把闭环规划放进去而不是仅仅做离线的任务分配和航点生成。1.2 环境不确定性离线规划最大的敌人离线轨迹规划在多机并行里的问题可以归结为两点一是静态假设失效二是机间偏差累积。静态假设失效好理解规划的时候地图里没有障碍飞行的时候出现了就必须重新决策。机间偏差则更微妙一些多机并行要求各机保持一定的时间拍和空间间距但每架飞机的定位精度、风速影响都不同实际飞行中机间距离会持续漂移。尤其使用GPS单点定位时10米级别的偏差是常态这意味着本应相距30米的两架飞机真实间距可能只有20米甚至更小。在这种偏差下如果机间检测只是“起飞后各飞各的”没有基于实时状态做修正机间碰撞风险会逐步上升。我们可以完全不提“撞机”这种极端事件单说采集质量机间间距缩短导致重叠率上升后期拼接效率下降间距拉大则中间出现空洞一块地没拍到任务就得重飞。闭环规划解决的就是这个问题——系统不把离线轨迹当作不可变约束而是在飞行过程中持续对比“我应该在的位置”和“我当前的状态”发现偏差超限就触发新一轮规划让轨迹始终贴近实际环境。1.3 闭环价值与代价算力、通信与稳定性的三角关系闭环不是免费的。一旦引入闭环就需要回答三个问题多久重算一次轨迹谁来做这个计算计算结果怎么分发如果采用完全在线的细粒度闭环每一秒都在跑一遍完整的轨迹优化对机载计算单元的要求会非常高。市面上常见的机载电脑做一次基于非线性优化的多机协同轨迹求解毫秒级很难通常是秒级甚至更久。而且多机并行场景下所有无人机要把状态发给处理中心处理中心求解完再把新轨迹发给每架飞机通信链路的带宽和时延就成了瓶颈。更麻烦的是高频求解会让轨迹指令经常变化飞机执行不稳定实际飞行效果反而变差。这就是“稳定性”维度的含义闭环更新越快理论上对环境响应越及时但代价是生成的轨迹可能忽左忽右飞机不断调整航向、速度整个系统的鲁棒性下降。1.4 粗粒度的定位用“宏观重算”换“实时可飞”粗粒度闭环的“粗”指的是不对每一个航点做连续高频修正而是把重规划触发条件设定在较宽的阈值上比如只有当检测模块发现新障碍进入安全缓冲距离、或者机间偏差超过设定值的时候才会停下来做一次全局性的轨迹重规划。重规划后输出的也不是逐帧微调而是一组新的路径段无人机继续沿新路径飞行。这么做的好处非常直接计算频率从“每秒一次”降到“每几十秒一次甚至几分钟一次”机载计算压力大幅下降通信上只需要在触发时传输新的航点序列平时保持最低限度的状态广播即可轨迹稳定性也上来了无人机在两次规划之间始终沿平滑路径飞行不会频繁改变动作。粗粒度并不代表“响应慢”。比如检测模块发现障碍物距离还剩50米触发重规划之后优化器在2秒内算出一组新的绕飞路径以无人机常用巡航速度折算足够在到达障碍物前完成规避。关键就是不要把“粒度”当成精度指标它在工程上的意义是计算效率与任务可靠性的折中方案。2. 粗粒度闭环轨迹设计的整体方案与选型2.1 总体架构感知-决策-执行-检测的四环节闭环我们设计的系统分为四个模块感知模块、决策模块、执行模块和检测模块。感知模块负责获取无人机当前状态和任务区域内的环境信息在仿真里由人为给定障碍物位置和运动模型来模拟。决策模块是核心里面跑着任务分配器、离线轨迹生成器和在线重规划器。执行模块负责把轨迹转换成飞行控制指令。检测模块比较特殊它不是独立于闭环之外的附加件而是闭环的触发源之一。检测模块持续监控两类对象的相对位置一类是任务区域内的静态/动态障碍另一类是机间相对位置。一旦检测到相对位置突破安全阈值就发出重规划请求。决策模块收到请求后基于当前全局状态重新计算未来一段时间的轨迹。这四个环节组成一个循环感知获取信息决策做出轨迹选择执行让飞机动起来检测反馈偏差再触发感知和决策。粗粒度体现在决策环节的触发频率上其他环节都是持续运行的。2.2 轨迹优化目标函数拆解轨迹重规划在项目里被建模成一个带约束的最优控制问题。目标函数包含采集覆盖率、能耗和时间窗三个部分。覆盖率项是所有子区域中被轨迹扫过的网格细胞占比直观理解就是“我有没有把该拍的都拍到”。能耗项与路径长度和转弯次数相关路径越长能耗越高转弯越频繁能耗也会因为加减速而增加。时间窗项则用来惩罚超出预定采集时间的轨迹。约束方面主要有运动学约束、避障约束和机间间距约束。运动学约束保证轨迹是无人机物理上能飞的比如最大速度、最大加速度、最小转弯半径避障约束保证轨迹与障碍物保持最小安全距离机间间距约束则保证任意两架平行作业的无人机距离始终大于最小安全值。在Matlab里我们用内置优化器做求解目标函数和约束条件都写成函数句柄传入。相比从零写优化求解器用内置优化器可以节约至少一周的调试时间这也是这套代码比较容易上手的核心原因。2.3 为什么用粗粒度而不是细粒度计算复杂度对比细粒度闭环的典型做法是“模型预测控制”MPC类型的滚动时域优化每个控制周期都在线求解最优化问题。假设并行无人机数量为N轨迹段长度为T那么一次优化的决策变量维度约为 N × 2T 到 N × 3T 之间。当N等于5、T等于20个航点的时候就是200到300维的非线性优化求解一次需要秒级时间。而控制频率通常是10赫兹甚至更高也就是100毫秒一个周期算力完全跟不上。粗粒度的做法将同样的优化问题延后到有需要时才触发。正常巡航阶段无人机只执行上一轮的轨迹决策模块处于“监听”状态只有触发条件达到才做一次同样的高维优化求解一次2秒左右完全可接受。对比一下同样运行10分钟的任务细粒度闭环要在线求解约6000次粗粒度闭环只需求解几次到十几次计算负担差了三个数量级。通信链路上的差别更明显。细粒度闭环需要持续广播状态数据供优化器使用通信频率要求高粗粒度闭环平时只广播低频率的心跳包和位置包只有触发重规划的时候才传输一次稍大的航点数据包。对实际使用中通信带宽不宽裕的多机组网环境来说粗粒度是几乎必然的选择。2.4 与常见方法的横向对照表下表总结了粗粒度闭环轨迹设计与几种常见方法的对比方便在方案选型时做判断。维度离线静态规划细粒度在线闭环粗粒度在线闭环本方案环境适应性差遇变化即失效好高频修正中上关键变化可响应机载计算压力几乎为零高需高性能计算单元低普通飞控即可通信带宽需求低高中低轨迹平滑度高低易频繁抖动高两次规划间平滑实现复杂度低高中任务可靠性与安全性低高中高适用场景环境固定的小规模任务动态复杂环境的少数机巡航多机并行、环境多半可控从这个表格可以看出粗粒度并不是“精度换效率”的无奈选择而是针对多机并行场景的特性做的针对性设计。多机并行的任务区域虽然大但大部分区域是静态已知的真正不可控的部分占比并不高用低频重规划去覆盖这些不可控点比处处都高带宽闭环更匹配实际。3. 无人机检测模块闭环中不可或缺的安全件3.1 检测的任务边界检测模块在项目中的作用是给闭环规划提供触发信号。任务边界很明确检测模块不负责修改轨迹不负责预测未来的障碍轨迹它的职责只是持续计算“当前状态下是否存在需要重规划的风险”。具体检测内容分两类。第一类是外部障碍检测针对任务区域内的电线塔、高层建筑、临时搭建物等。第二类是机间相对位置检测判断并行飞行的多架飞机之间的距离是否仍满足安全阈值。内部检测和外部的不同在于机间位置信息可以通过编队通信获得属于可以精准计算的“自检测”而外部障碍往往需要传感器感知带有测量噪声。3.2 粗粒度检测的工程实现思路检测模块的触发阈值设计是需要仔细斟酌的。阈值太松比如等到机间距离已经小于安全距离才触发重规划留给决策的时间很少轨迹优化出来的时候可能已经晚了阈值太紧系统又会被频繁触发退化成细粒度闭环失去粗粒度的优势。我们在项目里采用的策略是设置两级缓冲第一级是“提醒距离”此时系统将目标机的位置和速度记录进缓存标记潜在冲突但不触发重规划第二级是“重规划距离”这个距离值等于安全距离加上一段冗余量冗余量的计算公式为当前速度的平方除以两倍最大减速度这实际上就是“刹车距离”的概念加上一个固定余量。碰到这个阈值后检测模块发出重规划请求并把冲突飞机的状态打包发送给决策模块。由于冲突信息提前约两秒被检测到决策模块有充裕时间把新的轨迹解出来。实测下来这套两级缓冲既保证了安全又把不必要的重规划触发降到了很低水平。3.3 检测结果如何回注轨迹优化器检测模块送出的不只是“要不要重规划”的布尔信号还包括冲突对象的预测位置。预测位置用当前速度和航向做外推预测时长与决策计算时长相当。决策模块在优化器里将这部分预测位置作为动态约束加入避障约束条件从而在重规划时就考虑了冲突的移动趋势。这种做法的好处是即使冲突对象是另一架运动的无人机重规划出的轨迹也有前瞻性不会出现“刚躲过A机迎面又撞上B机路线”的情况。因为优化器把多架飞机的预测信息同时加入做的是协同式的重规划而非单机自私式的规避。3.4 仿真中模拟检测的方式在Matlab仿真里我们没有接入真实视觉或雷达传感器而是用真值数据加高斯噪声来模拟检测输出。检测模块看到的是噪声污染后的位置而不是真值这样仿真结果更接近真实传感器水平。噪声方差参考GPS单点定位的典型水平横向纵向各取2到3米。这种模拟方式虽然简单但能够有效检验闭环轨迹设计对位置噪声的鲁棒性。如果优化器完全信任测量值噪声会导致重规划轨迹微飘通过加大检测阈值并在优化器中加入对位置不确定性的鲁棒项可以把这种飘动控制在一个可接受范围内。4. Matlab仿真平台搭建与核心代码实现4.1 仿真环境与运行流程总览仿真平台建在Matlab R2022b以上环境使用了优化工具箱。整体流程分五步设置任务区域与无人机初始状态生成覆盖任务的离线轨迹并开始执行进入飞行循环每个时间步更新各机状态、调用检测模块判断是否触发重规划触发后调用重规划器求解新的轨迹段并将轨迹追加到当前执行列表所有无人机完成采集任务后停止最后输出轨迹图、机间距离曲线和覆盖率等指标。代码结构以脚本加函数形式组织主脚本负责流程控制函数模块包括轨迹生成、轨迹优化、检测模块、状态更新和可视化。每个模块都是独立文件调试时不用牵一发动全身。4.2 参数设置从物理约束到优化参数下面给出关键参数表这些参数在代码中集中在配置区。参数数值说明任务区域1000m × 800m网格分割为8个子区域无人机数量4每机分配两个相邻子区域巡航速度12 m/s匀速巡航最大加速度3 m/s²轨迹规划中的运动学约束最小转弯半径25 m固定翼类约束机间安全距离30 m两级缓冲的触发基础重合缓冲距离15 m第二级触发阈值基于此计算重规划触发间隔最短15秒防止频繁触发检测更新频率1 Hz与GPS数据输出频率对齐位置高斯噪声σ 2.5 m模拟GPS误差最小安全距离障碍10 m外部障碍避让约束最大飞行时间600 s任务时间窗这些参数都不是拍脑袋定的。机间安全距离30米综合考虑了定位误差2.5米量级、飞行速度12m/s、通信延迟约200ms以及无人机本身的物理尺寸最小转弯半径25米则参考了中小型固定翼无人机的典型机动能力重规划最短间隔15秒是为了防止系统在检测噪声影响下陷入“触发-重规划-再触发-再重规划”的振荡循环。4.3 核心代码轨迹重规划与检测联动先看检测模块的核心函数这段代码实现了两级缓冲触发逻辑。function shouldReplan checkReplanCondition(posNow, posOther, velNow, velOther, params) % 机间距离计算 deltaPos posNow - posOther; dist norm(deltaPos); % 相对速度计算用于预测冲突时间 deltaVel velNow - velOther; closingSpeed -dot(deltaVel, deltaPos / max(dist, 1e-6)); % 一级缓冲提醒距离只记录不触发 warnDist params.safeDist params.warnBuffer; % 二级缓冲重规划距离基于减速距离计算冗余 stopDist closingSpeed^2 / (2 * params.maxAccel); replanDist params.safeDist params.replanBuffer stopDist; % 判断是否触发 if dist replanDist closingSpeed 0 shouldReplan true; elseif dist warnDist shouldReplan false; % 这里只记录告警不触发规划 else shouldReplan false; end end这里最关键的细节是closingSpeed的计算它只统计两机靠近时的情况。如果两架飞机正在远离即使距离很近也不需要重规划因为冲突正在自然解除。如果对靠近和远离两种情况都触发重规划就会出现毫无意义的绕飞整个闭环就会变得不稳定。再看重规划器中目标函数和约束的核心写法function trajNew replanTrajectory(stateNow, waypointsOld, obstacles, params) % 决策变量新的航点序列这里用 N*2 个变量表示 N 个航点 N params.replanHorizon; x0 reshape(waypointsOld(1:N, :), [], 1); % 目标函数覆盖率惩罚 路径长度 平滑性惩罚 costFunc (x) trajectoryCost(x, stateNow, params); % 非线性约束避障 机间间距 运动学 [A, b, Aeq, beq] buildLinearConstraints(params); nonlcon (x) nonlinearConstraints(x, obstacles, params); options optimoptions(fmincon, Algorithm, sqp, ... MaxIterations, 300, Display, off); [xOpt, ~] fmincon(costFunc, x0, A, b, Aeq, beq, ... [], [], nonlcon, options); trajNew reshape(xOpt, N, 2); endcostFunc包含三个部分一是指定采样点在任务区域网格上的覆盖率权重二是相邻航点间距平方和可以理解为路径长度三是航点转角惩罚防止轨迹出现尖锐拐角。nonlcon则把每个航点到每个障碍物的距离约束写成dist minSafeDist的形式同时把相邻航点间的速度约束也放在里面。有一个使用fmincon的细节值得提一下初始值对求解结果影响很大。我们直接用原航点作为初值这样求解器倾向于输出与原始轨迹偏离较小的结果不会出现每次重规划都生成一条完全陌生路径的情况。实践证明这种“最小改动”约束对多机协同的稳定性非常关键。4.4 指标统计与结果可视化仿真结束后我们会统计三个核心指标区域覆盖率、总飞行时间、最小机间距离以及重规划次数。覆盖率通过将任务区域离散化成5m × 5m的网格细胞判断哪些细胞被任何一架无人机的轨迹覆盖。function coverage computeCoverage(trajAll, gridX, gridY) % trajAll 是所有无人机的轨迹序列 % gridX, gridY 是网格坐标 covered false(size(gridX)); for i 1:numel(trajAll) tx trajAll(i).x; ty trajAll(i).y; idx find(tx gridX(1) tx gridX(end) ... ty gridY(1) ty gridY(end)); covered covered | ... (gridX min(tx(idx)) gridX max(tx(idx)) ... gridY min(ty(idx)) gridY max(ty(idx))); end coverage sum(covered(:)) / numel(gridX); end可视化方面仿真完成会输出三张图第一张是全部无人机的飞行轨迹与障碍物分布第二张是机间最小距离随时间变化的曲线第三张是覆盖率随任务时间增长的曲线。样本任务中4架无人机在约480秒内完成覆盖覆盖率98.6%最小机间距离从未低于28米重规划次数共7次。整体效果符合粗粒度闭环的设计预期。5. 我实测踩过的坑问题排查与避坑技巧5.1 位置漂移导致检测误报最开始的版本里检测模块直接用各机广播的原始位置做距离判断结果频繁出现误报。问题出在GPS噪声上——两架飞机本无冲突但噪声把测量距离压到了阈值以下触发了一次本来不必要的重规划。重规划之后噪声消失距离又高于阈值整个系统处于一种轻微的“神经质”状态。解决的办法有两步。第一步对检测模块输入的位置做滑动窗口滤波窗口长度3秒有效抑制了单点噪声尖峰。第二步给触发条件增加一个“持续时间”判断连续3次检测都满足触发条件才真正发出重规划请求。这两步加完误报率从约15%下降到接近于零。5.2 闭环触发过于频繁导致轨迹震荡“持续时间”判断解决的是噪声误报但还有一个问题来自真实场景就是障碍物出现在无人机必经之路上时重规划轨迹绕过障碍后又接近下一个障碍导致连续触发。每次重规划都会改变轨迹方向无人机在空中走出锯齿形航线不仅难看能耗也高。对此必须引入最短重规划间隔约束。我在检测模块和重规划器之间加了一个计时器上次重规划后15秒内不允许再次触发。这个15秒是和飞行速度直接挂钩的12m/s的速度下15秒无人机已经飞了180米足以确定是否需要进一步调整。加入这个限制后锯齿形轨迹彻底消失重规划次数也控制在了个位数。5.3 通信延迟与并行不同步的处理因为仿真里机间信息是“即时可得的”这是真实系统里不成立的假设。我在后期某个版本中给状态广播人为加了200毫秒的传输延迟结果发现两架飞机的并行数据采集出现了明显的时间错位A机已经飞过重叠区域了B机才收到位置信息检测模块的判断和实际情况脱节。补偿方案是基于预测位置替代延迟位置检查A机收到的B机状态时用B机速度外推200毫秒得到预测位置再参与检测判断。这样处理之后延迟影响基本被消化机间距离计算的误差恢复到正常范围。这个细节在真实系统中极其重要建议做工程落地的朋友优先考虑。5.4 参数调试经验速查表现象可能原因排查方法解决方案检测模块频繁误报位置噪声未滤波对比原始位置与滤波后曲线加滑动窗口滤波 持续时间判断轨迹锯齿形震荡重规划触发过密统计触发时间间隔设置最短触发间隔建议15秒以上覆盖率偏低重规划后轨迹偏离原区域检查重规划轨迹与任务网格重叠度在目标函数中增大覆盖率项的权重求解器收敛慢或失败初值离可行域太远查看fmincon退出标志和迭代过程用上一步轨迹做初值限制决策变量改动幅度机间距离始终偏紧触发的阈值太紧绘制距离曲线对比安全线增大缓冲距离或降低检测频率关于参数调整我的习惯是先调安全距离和缓冲再调覆盖率权重最后才动优化器的迭代参数。因为安全距离的错误会直接表现为系统不稳定而覆盖率权重偏差通常只影响效率不影响可靠性。先保证系统“能飞”再去追求“飞得值”这个顺序能省很多排查时间。这个项目后续还能扩展的方向我觉得至少有两个一是把粗粒度闭环的轨迹输出直接和无人机底层飞行控制协议对接替代目前仿真中的理想执行模型这一步能验证轨迹在真实飞行中的可跟踪性二是把检测模块升级为多传感器融合视觉和毫米波数据同时输入进一步提升对动态障碍的感知鲁棒性。粗粒度闭环这个思路并不是多无人机轨迹规划方向的终点但作为兼顾工程可落地性与系统鲁棒性的中间路线值得在这样的系统设计中占据一席之地。