最近在做一个多无人机协同项目任务内容其实不复杂让一组无人机在一个区域内做并行数据采集把事先布设的地面目标点全部遍历到再把数据带回起点。听起来跟单机巡检差不多但真正动手才发现单机那套“起飞、沿航点飞、返航”的思路根本撑不住多机场景。分工怎么划、轨迹怎么生成、飞一半遇到偏差怎么修正、多机之间怎么保证不互相干扰每一环都得重新设计。这个项目最后落地成一套“粗粒度闭环轨迹设计”方案配合无人机检测模块做反馈修正整体用Matlab完成了仿真验证。这篇文章把任务拆解、设计思路、代码结构和调试过程里踩过的坑一并整理出来给正在做多无人机协同采集、覆盖路径规划或者闭环航迹控制的朋友做个参考。1. 并行数据采集到底难在哪为什么单机巡检的思路用不了1.1 任务场景还原从“一架飞机扫一圈”到“多架飞机分区扫”项目最初的原始需求很简单在一个约200米乘300米的园区内地面随机分布了25个数据采集目标点每个点需要无人机飞临上空完成采集动作之后无人机返回起始位置上传数据。单机方案很好算如果航线总长约1200米巡航速度设为5米每秒加上每个目标点悬停采集的5秒总耗时大约280秒。这还没算起飞降落和转弯损耗。等任务区域再扩大一倍单机耗时直接超过500秒接近一块电池的续航上限。所以很自然地想到用多机并行。但“并行”两个字带来的复杂度远不是把飞机数量乘上去那么简单。4架飞机同时起飞如果各自随便飞很容易出现两架飞机同一时刻抢占同一个目标点或者在狭窄通道里形成冲突。任务分配、路径生成、飞行中偏差修正三个问题交织在一起才是并行数据采集真正的难点。这个项目里的核心诉求有三条一是覆盖率要达标25个目标点尽量一个不落二是总任务时长要压缩让4架飞机并行工作的收益真正体现出来三是飞行过程要安全机间距离不能被突破。三条诉求对应到技术层面就引出了轨迹设计的全部问题。1.2 多机协同的三条硬约束碰撞、通信、能量先说碰撞约束。多机并行不等于各飞各的必须设定最小安全距离。项目中我把它设为5米这个值既考虑了旋翼无人机的物理尺寸和安全余量也考虑了GPS定位误差在2米到3米之间的现实情况。如果安全距离设得太小比如3米看起来更激进但一旦定位发生跳变两机之间就非常容易触发碰撞告警。安全距离本质上不是给“正常情况”留的而是给“误差情况”留的。再看通信约束。并行采集时飞机和地面站之间的通信带宽有限尤其当多架飞机同时回传位置、状态和采集数据时信道竞争很激烈。项目里采用的方式是让每架飞机只上报“关键检查点”的状态而不是每个仿真步都全量回传这也反过来影响了飞行控制架构的设计。如果轨迹设计完全不考虑通信约束让所有飞机高频率上报数据地面站很容易过载控制指令下发也会出现延迟抖动。最后是能量约束。多机协同表面上是时间优化问题底层其实是能量分配问题。路径规划时要避免绕路、避免频繁急转弯因为每一次大角度转向都会带来显著的能量损耗。粗粒度轨迹设计在其中起到的作用是先保证“方向正确”再让底层控制器去做局部修正这样整条航迹在宏观上平滑微观上有纠偏能力能耗自然可控。这三条约束单独看都不难满足难的是同时满足。碰撞约束要求轨迹之间有足够间距通信约束要求状态上报有节律能量约束要求航迹平滑。三者叠加就会发现单机巡检那种“拿一串固定航点飞完拉倒”的做法完全没有适应性必须设计一套能够在飞行过程中感知偏差并动态调整的闭环框架。1.3 为什么“粗粒度”是正确的切入角度第一次设计这个系统时我本能地想要追求“最优”每架飞机每一个时刻都知道所有其他飞机的位置动态求出全局最优轨迹。这听起来很完美但实际一算就发现不现实。把25个目标点分配给4架飞机每一架飞机的路径本质上是TSP变体联合起来又是一个多旅行商问题加上多机避碰问题状态空间膨胀得极其吓人。用Matlab直接跑全局优化中等规模场景下决策延迟就达到了几十毫秒级别放到工程里根本无法支撑实时控制。于是换了一个思路不在每个控制周期里追求全局最优而是把问题拆成两个尺度。大尺度上做任务分区和航点序列规划这个层面不需要太高频率任务开始前算一次就行小尺度上做跟踪控制和局部修正这个层面需要实时响应但只处理“局部偏差”不做全局重规划。这就是粗粒度闭环轨迹设计的基本思想也是这个项目最终选择的路线。可以用一个生活化的类比来理解粗粒度闭环就像长途自驾时先定好“从A城市到B城市”的高速路线上了高速再根据GPS实时调整车道和出入口。你不会每秒钟都重新规划整个行程但你会每几秒看一眼导航确认没跑偏。粗粒度解决的是“大方向不犯错”闭环解决的是“小偏差不积累”两者配合才是工程上性价比最高的方案。2. 粗粒度闭环轨迹设计的核心逻辑先分区、再规划、飞中修正2.1 三个层次的任务分解分配、路径、修正整个轨迹设计被我拆成了三个层次对应三条执行链路。第一层是任务分配层负责把25个目标点按空间位置和任务量均衡原则划分给4架无人机。实现方式用的是K-means聚类加区域边界修正先把目标点聚成4簇然后根据每簇的重心做区域划分。这一步是粗粒度里面“最粗”的一层频率最低只在任务开始时跑一次就够了。第二层是航点序列规划层。每一架无人机拿到自己负责的目标点集合之后需要生成一条经过所有这些点的顺序路线。我在项目里用了简化版的最近邻算法加2-opt局部优化没有上精确求解器。25个点拆到单机上大约6到7个点最近邻加2-opt在这个规模下已经能跑出相当好的路径而且计算耗时只有几十毫秒。这里不需要“理论上最优”只需要“工程上够好”因为后面还有闭环修正层兜底。第三层是闭环修正层也是整个设计和单机固定航迹最大的区别所在。飞行过程中无人机不可能完全贴着预设航迹走GPS漂移、阵风干扰、动力学响应延迟都会让实际位置偏离参考轨迹。修正层的工作就是持续评估这个偏差当偏差超过阈值时在局部重新生成一小段修正航点接回原轨迹而不是推翻整条路线。2.2 闭环反馈链参考轨迹、状态估计、跟踪控制、在线修正闭环框架中最核心的概念是反馈链。规划器生成参考轨迹后无人机底层的姿态和速度控制器负责跟踪它但跟踪过程一定会有误差所以需要状态估计模块持续给出当前“最可信”的位置和速度值。状态估计和参考轨迹之间的差值就是修正层的输入。项目里状态估计先用的是简单的GPS加惯性数据融合在Matlab仿真中用带噪声的模型模拟。控制层是经典的PID位置控制器输出期望速度内环再用一个简化的姿态响应模型模拟。仿真步长设成0.1秒也就是每100毫秒执行一次控制计算。真正决定闭环压力的是修正层的触发频率如果每次控制周期都触发全局修正计算那就退化成了细粒度规划如果不触发又变成了纯粹开环飞行。对比一下就清楚了。开环飞行时即使每个控制周期都在做PID跟踪实际轨迹仍然会有缓慢漂移因为PID只能消除“已经发生的偏差”不能预判“将要发生的偏差”。飞行时间一长航迹可能偏离预设路线好几米到目标点附近时可能根本飞不到采集半径之内覆盖率直接下降。闭环修正做的正是这一点在偏差尚未累积到不可接受之前及时干预把飞行拉回正确轨道上。2.3 粗粒度与闭环的结合点检查点触发机制最初的实现里我让状态估计模块每100毫秒更新一次但轨迹修正并不是每100毫秒都做。原因很直接如果修正频率过高整个系统就变得跟细粒度在线规划一样计算负担大幅上升但如果修正频率过低偏差又会累积过头。最后的做法是引入了“检查点”机制在规划阶段预先设定好一系列检查点分布在整个航迹上无人机飞抵某个检查点附近时才执行一次完整的偏差评估和轨迹修正。检查点间距是跟巡航速度挂钩的。巡航速度5米每秒时检查点间距如果设成50米相当于每10秒检查一次。这个频率在实验场景里效果不错既能及时纠偏又不会让规划器频繁空转。如果任务区域更大或者飞行速度更高检查点间距要相应拉大否则闭环压力会随距离线性增长。修正逻辑具体是这样实现的无人机抵达第k个检查点后把实际位置与参考轨迹上该检查点的理论位置做差得到偏差向量。如果偏差模长小于阈值项目里用2米不做任何处理继续沿原轨迹前进如果超过阈值则在当前位置与原轨迹的下一个检查点之间重新插值生成一段圆弧过渡航点替换掉两检查点之间的原始轨迹段。这种做法的好处是修正范围极其局部不会影响后续全局航迹结构计算复杂度非常低。3. 无人机检测模块闭环反馈的信号从哪里来3.1 把“无人机检测”拆清楚目标检测与机间检测“无人机检测研究”这个表述在不同项目里含义差别很大很多人会第一时间想到“用无人机去检测地面目标”或者“检测空中的其他无人机”。在这个项目里这两个方向其实都有涉及而且它们服务于不同的闭环需求。第一个方向是目标检测用于判断无人机是否已经飞临数据采集点以及当前采集动作是否顺利完成第二个方向是机间相对位置检测用于多机协同时的冲突预警和避碰决策。很多做轨迹规划的同行容易忽略一点检测模块不仅仅是“感知传感器”它实际上是闭环轨迹修正的重要触发源。如果没有检测结果修正层就只有一个时间驱动的触发逻辑也就是按检查点周期执行。但真实任务中很多事件是空间驱动的比如“飞到目标点上方了”“前方出现另一架无人机”这些事件必须靠检测模块及时上报才能真正构成一个有效的闭环。3.2 目标识别从像素坐标到全局坐标再到航点修正目标检测的工程实现我没有一上来就用深度学习模型因为仿真验证阶段需要先跑通整个闭环链路模型推理会引入额外的延迟和不确定性。我选择了一个更稳妥的方案假定目标点带有明显的视觉标识比如红色反光板用颜色阈值分割加形态学滤波来识别目标中心。Matlab里做这件事非常顺手。先用rgb2hsv把图像转到HSV空间利用色调通道做阈值分割把满足红色范围的像素提取出来然后通过regionprops获取连通区域的质心坐标。得到的质心是像素坐标需要经过相机内参矩阵转换为相机坐标系下的位置再通过无人机当前姿态角和GPS位置转换到全局坐标系。只有到了全局坐标系这个检测结果才能跟规划器的航点数据放在同一个坐标框架里使用。检测结果到手之后闭环触发逻辑不复杂。无人机按参考轨迹飞行时如果检测模块在预定搜索半径内识别到了目标标识任务状态机就从“飞行中”切换为“数据采集中”并向轨迹规划器发送一条指令请求在当前目标点上方生成一个悬停航点。悬停5秒完成采集后再恢复原参考轨迹继续前进。整个过程本质上是“检测结果变更任务状态任务状态影响轨迹生成”这也是检测模块在整个闭环框架里的核心接入方式。3.3 机间相对位置估计与冲突检测机间检测的实现思路要小心因为多机同时飞行时单纯靠视觉识别另一架无人机的难度远大于识别地面目标。无人机体积小、姿态多变、背景复杂视觉算法很容易漏检或误检。我没有把机间冲突检测完全押在视觉上而是设计了两条并行路径。第一条路径是基于广播位置信息的几何冲突检测。每架无人机在通信链路里周期广播自己的GPS位置每架飞机同时接收其他飞机的位置计算相对距离和相对速度方向。如果相对距离小于安全距离且相对接近速度大于零就判定存在冲突风险。这个判定放在一个独立线程里执行不依赖视觉检测而是作为一种“数字感知”手段。第二条路径才是视觉检测作为前者的冗余验证。在Matlab仿真里我用一个统一的时钟推进所有无人机的状态更新所以不存在真实系统中时间不同步的问题。但在调试中仍然发现一个很隐蔽的坑当两架无人机在同一时刻上报位置时模拟器里看起来它们在一条直线上交错而过可加入通信延迟后位置数据会有0.2到0.3秒的滞后。这时候几何冲突检测就会产生“假碰撞”告警。解决办法是在相对距离计算中引入一个速度预测项用对方上报的位置加上速度乘以通信延迟的补偿量作为预估位置参与判定。4. Matlab仿真系统的搭建与代码结构4.1 为什么用Matlab做原型验证这个项目的规模决定了它需要一个能快速迭代的仿真平台。Matlab的优势在于数值计算和可视化的紧耦合无人机动力学模型、PID控制器、轨迹规划算法、检测算法可以全部在同一个环境里跑通调试效率非常高。相比用仿真器加外部控制框架的组合Matlab省去了大量模块通信和配置环节尤其适合在项目早期验证算法逻辑是否成立。代价也有。Matlab运行速度慢于C做大规模仿真时循环效率不高。但对我这个项目而言4架无人机、25个目标点、0.1秒仿真步长总仿真时长也就两三分钟Matlab完全吃得消。我的建议是项目早期用Matlab把算法验证清楚后期要提升仿真规模时再把核心规划模块迁移到C或者Python的重型框架中。不要一开始就在环境搭建上投入过多精力先把逻辑跑通是更重要的事。4.2 代码文件组织与模块划分整个项目被我分成四个模块场景生成、轨迹规划、飞行控制和感知检测。每个模块对应一个目录目录下放若干功能函数。这样划分的目的很明确后续替换其中任何一个模块的算法实现时不需要改动其他模块的接口。coarse_loop_sim/ ├── main_simulation.m # 主仿真循环 ├── scenario/ │ ├── gen_targets.m # 生成随机目标点 │ └── load_scene.m # 加载场景配置 ├── planning/ │ ├── assign_regions.m # 任务分配K-means聚类 │ ├── gen_trajectory.m # 航点序列生成 │ └── refine_waypoint.m # 检查点触发修正 ├── control/ │ └── tracking_controller.m # PID位置控制器 └── sensing/ ├── detect_target.m # 目标标识检测 └── detect_conflict.m # 机间冲突预警主程序负责把所有模块串起来。初始化阶段场景模块生成目标点和无人机起点规划模块跑任务分配和初始轨迹生成之后进入以固定仿真步长推进的主循环。循环体内先更新每架无人机的动力学状态然后调用控制器算出跟踪指令再检查检测模块的输出是否触发修正事件。4.3 主仿真循环的骨架代码这里贴一段精简过的主循环核心代码把闭环逻辑的关键节点展示出来。完整代码比这个长但主干就这几步状态更新、控制跟踪、检查点修正、检测触发、数据记录。% 主仿真循环骨架 dt 0.1; % 仿真步长 0.1s sim_time 0; for uav_idx 1:N_uav % 初始路径生成 traj(uav_idx).wp gen_trajectory(region(uav_idx), uav_idx); % 设置初始检查点 traj(uav_idx).checkpoint_idx 2; end while sim_time sim_duration for uav_idx 1:N_uav % 1. 状态估计更新模拟GPS噪声 state(uav_idx).pos state(uav_idx).pos ... state(uav_idx).vel * dt noise_gps * randn(3,1); % 2. 跟踪控制器计算期望速度指令 cmd_vel(uav_idx,:) tracking_controller(state(uav_idx), ... traj(uav_idx).wp(traj(uav_idx).checkpoint_idx,:)); % 3. 检查点偏差评估与修正 dist2cp norm(state(uav_idx).pos - ... traj(uav_idx).wp(traj(uav_idx).checkpoint_idx,:)); if dist2cp 3.0 % 飞到检查点附近评估累计偏差 delta state(uav_idx).pos - ... traj(uav_idx).wp(traj(uav_idx).checkpoint_idx,:); if norm(delta) 2.0 traj(uav_idx).wp refine_waypoint( ... traj(uav_idx).wp, traj(uav_idx).checkpoint_idx, delta); end traj(uav_idx).checkpoint_idx min(... traj(uav_idx).checkpoint_idx 1, size(traj(uav_idx).wp,1)); end % 4. 检测模块触发 detected detect_target(state(uav_idx), targets); if detected % 生成悬停采集航点 traj(uav_idx).wp insert_hover_waypoint(... traj(uav_idx).wp, state(uav_idx).pos, 5.0); end % 5. 机间冲突检测 conflict detect_conflict(state, uav_idx, safety_dist); if conflict % 局部减速避让 cmd_vel(uav_idx,:) cmd_vel(uav_idx,:) * 0.5; end % 6. 动力学更新 state(uav_idx).vel state(uav_idx).vel ... (cmd_vel(uav_idx,:) - state(uav_idx).vel) * 0.3; state(uav_idx).pos state(uav_idx).pos ... state(uav_idx).vel * dt; end sim_time sim_time dt; % 数据记录与动画绘制略 end这段代码能跑通关键在几个参数要合理设定。dt决定仿真分辨率和计算量之间的平衡检查点判定距离3米这个值决定了修正触发的提前量偏差阈值2米决定了修正动作的灵敏程度速度环系数0.3模拟了无人机内环的响应滞后。这些参数相互关联调整时不能只动其中一个这是后面调参章节要展开讲的内容。4.4 关键参数一览与初值设定项目里最重要的几个参数我整理成了一张表。初次跑仿真时可以直接抄这组初值之后根据场景规模和无人机数量再逐步调整。参数初值说明仿真步长 dt0.1 s控制频率10Hz够用且计算压力小巡航速度5 m/s兼顾覆盖效率和能量消耗最小安全距离5 m含GPS噪声余量检查点判定半径3 m到达检查点附近即触发偏差评估偏差修正阈值2 m超过该值才做局部重规划悬停采集时间5 s模拟数据采集动作耗时目标点检测半径8 m视觉识别有效范围通信延迟补偿0.25 s用于机间冲突检测的位置预估这些参数的初值不是拍脑袋定的它们之间有明确的逻辑关系。比如检查点判定半径3米要小于检查点间距50米否则多个检查点会同时满足判定条件偏差修正阈值2米要小于目标点检测半径8米否则无人机可能还没纠偏就错过目标。理解参数之间的约束关系比记住某一组具体数值重要得多。5. 仿真实验设计、指标与结论5.1 实验场景与三组对比方案为了验证粗粒度闭环轨迹设计的实际效果我设计了三组对比实验。实验场景固定如下200米乘300米的矩形区域25个随机目标点4架无人机从同一起点起飞。三组方案分别对应三种轨迹设计思路。方案A是开环轨迹设计也就是任务分配和航点规划做完之后全程只做底层PID跟踪不执行检查点修正。这组实验用来展示没有闭环反馈时的性能底线。方案B是本文设计的多无人机粗粒度闭环轨迹检查点间距50米偏差阈值2米。方案C是细粒度在线重规划也就是每个控制周期都把当前状态纳入规划器重新求解全局轨迹。三组方案使用相同的动力学模型和噪声模型保证对比公平。5.2 评价指标覆盖率、任务时长、决策开销评价一个轨迹设计方案的优劣不能只看单一指标。我选了三个维度覆盖率衡量任务完成质量任务时长衡量并行采集效率决策开销衡量算法实时性。覆盖率定义为成功采集目标点数除以总目标点数采集成功判定条件是无人机在目标点8米半径内完成5秒悬停任务时长是最晚完成任务的无人机返航时刻决策开销是平均每次触发规划或修正计算所耗费的时间。方案覆盖率任务时长(s)平均决策开销(ms)A开环轨迹78.6%96.80.2B粗粒度闭环100%88.40.8C细粒度重规划100%85.132.5注以上为项目仿真中的示例数据具体数值会随场景和参数变化但相对趋势有参考价值。方案A的覆盖率只有78.6%原因正是误差累积。开环飞行时即使PID跟踪正常GPS噪声和动力学滞后也会让无人机在飞行后期偏离预设航迹5到8米部分目标点飞出8米检测半径之外。任务时长方面因为漏检目标点会导致无人机继续飞行更长距离耗时反而高于有修正的方案B。方案C在任务时长上确实最短只比方案B快了约3秒但代价是平均决策开销增加了整整40倍。这个结果印证了一个工程上的判断对这类中规模并行采集任务在线全局重规划带来的收益边际递减但计算负担却急剧上升。5.3 从仿真结果提炼出的设计结论三组实验对比下来粗粒度闭环方案的定位就很清晰了。它在覆盖率上和细粒度方案持平100%目标点全部采集完成任务时长相较开环方案缩短了约8.4秒接近细粒度方案水平的97%关键是决策开销只有0.8毫秒比细粒度方案低了两个数量级。这个结论不是要否定细粒度规划的价值。如果场景变成高动态环境比如有移动障碍物或者风速剧烈变化细粒度规划的实时感知优势就会更加突出。但在静态区域、目标点位置固定的并行数据采集场景下粗粒度闭环是明显更务实的选择。它把规划压力释放到低频层把高频层留给控制和检测系统整体的实时性和稳定性都更可控。6. 调参踩坑记录闭环频率、检测漏检与假碰撞6.1 闭环修正频率的边界探索调参过程中踩的第一个坑就是检查点间距。我开始图省事把检查点间距设成20米想着修正频率高一点总没坏处。实际跑下来发现无人机频繁触发偏置修正每次修正都会打断原始轨迹的平滑性导致实际航迹变成一段段折线能量消耗增大任务时长不降反升。仿真数据显示在这个参数下任务时长反而比开环方案还多了6秒。反过来把检查点间距拉到120米修正频率太低偏差逐渐累积覆盖率掉到了92%。后来才意识到检查点间距必须跟巡航速度和偏差发展趋势匹配。以5米每秒速度和2米的偏差阈值来算无人机大约需要10到15秒才能累积出超阈值的偏差所以检查点间距在50到75米之间最为合适。我的经验是先估算偏差增长率再反推检查点间距比凭感觉试错高效得多。6.2 检测漏检对闭环系统的“隐性攻击”目标检测模块在仿真里加入噪声模拟后出现了一个很隐蔽的问题。某个目标点如果被漏检无人机不会触发悬停采集航点的插入会直接越过目标点继续飞行。单看一次漏检影响不大但漏检累积后无人机会在后续飞行中逐渐偏离那些含有未采集目标点的区域导致覆盖率下降。解决方案不复杂。检测模块的触发逻辑不能只是“检测到就采集”还要有“到达目标点附近却没有检测到”的超时兜底。我在轨迹里为每个目标点设置了一个“潜在采集窗口”无人机飞过这个窗口时如果检测模块没输出结果就自动执行一次悬停用空间位置信息兜底不依赖视觉确认。这套双确认机制加上之后覆盖率重新回到100%而且应对漏检时依然稳定。6.3 多机仿真里的“假碰撞”与时间同步问题最初跑4机并行仿真时我经常在数据显示窗口看到莫名的冲突告警但回看轨迹又发现两架飞机明明没有真正接近。排查了半天定位到是通信延迟和时间同步问题。仿真里的状态上报采用了异步方式不同无人机的数据到达地面站的时间不同几何冲突检测如果拿到的是一架飞机5秒前的位置和另一架飞机当前的位置做比较距离计算自然会出错。我最后的做法是两处修正。一是给所有无人机的状态都打上统一的时间戳地面站在做冲突判定时先根据时间戳对位置做线性插值把各机状态对齐到同一时刻二是在相对距离计算中把通信延迟估计值纳入相对速度预测。这两步做完假碰撞告警基本消失剩下的少数告警都能对应到真实的接近事件上。6.4 从Matlab仿真到实机部署还需要补哪些课Matlab仿真跑通之后我一度以为问题已经全部解决了但实际上仿真和实机之间还有不小的距离。第一是动力学模型的精度仿真里用的是简化的速度响应模型真实无人机还要考虑姿态角速率限制、电机响应时延和陀螺仪漂移。第二是感知模型的复杂度仿真里的目标检测是理想化的概率触发真实环境里要处理光照变化、遮挡和背景杂波。第三是通信环境的差异真机场景下信号延迟和丢包波动更大冲突检测的时间同步机制需要更鲁棒的实现。如果要把这套系统搬到实机我的建议是分三步走。第一步先在Matlab里把目标检测模块替换成更接近真实输出特性的随机模型加入误检和漏检概率观察闭环系统的容错能力。第二步用硬件在环仿真把控制器和检测模块接到真实飞控上跑一遍验证通信链路和时间同步机制。第三步才是整机小规模试飞比如先用2架飞机验证协同逻辑再逐步扩展到4架。结语这套方案适合谁以及下一步的扩展方向整个项目从拿到需求到Matlab仿真全部跑通前后大约花了两周多。最深的体会是在工程任务里“足够好的方案”往往比“理论最优的方案”更有价值。粗粒度闭环不是精度妥协的产物而是把问题按时间尺度拆解之后自然得出的结构——低频层解决全局任务分配高频层解决局部跟踪和感知反馈各司其职整体稳定。这套框架对静态区域的多机并行数据采集场景非常适用如果任务区域大、目标点数量多、无人机数量多它的优势会更加明显。下一步我准备把目标检测模块从颜色阈值方案换成轻量级卷积网络看看在保持检测频率的前提下闭环系统的修正触发质量能提升多少。同时轨迹跟踪控制器也打算从PID升级成MPC重点测试在强风扰动下检查点修正和局部重规划的配合效果。如果你也正在做多无人机协同采集或覆盖路径规划相关项目欢迎在评论区交流你遇到的坑和处理思路。