【群体智能集群控制工程实践】第6章 无人机蜂群系统架构设计

第 6 章 无人机蜂群系统架构设计

所属卷册：第三卷 无人机蜂群控制工程实践

从第二卷的算法进入第三卷的工程实现，读者面对的第一个问题不是"选哪个算法"，而是"整个系统怎么搭"：飞控、机载计算机、通信链路、地面站、指挥软件各司其职，算法只是其中一层。本章给出无人机蜂群系统的顶层架构设计——6.1 节解决"用什么硬件、怎么通信"，6.2 节解决"软件怎么分层、消息怎么流动"。架构设计的判据只有一个：把前两卷的算法约束（收敛速率、延迟阈值、带宽/规模非线性、拓扑结构）落实为可购买、可组装的部件清单与可运行、可测试的软件骨架。因此本章会在每一节回指对应的算法约束：选飞控时回指第 2.2 节的动力学抽象与第 7 章的编队实现，选通信时回指 1.2.2.1 节的延迟阈值与 2.1 节的拓扑，定软件分层时回指第 3 章的事件触发与第 5 章的任务分配。

6.1 硬件平台选型与适配

6.1.1 消费级/工业级无人机平台对比

蜂群平台选型的第一刀切在"无人机本体"：消费级（或准工业级）多旋翼与工业级多旋翼/固定翼平台，在载荷、可靠性、认证与成本上的取舍完全不同。规模试验（第 8 章的室内小规模验证）通常采用 250~450 mm 轴距的消费级平台——成本低、炸机损失小、改机架方便；任务级部署则必须采用工业级平台——冗余传感器、防尘防水、抗电磁干扰与可维护性。除平台本体外，蜂群真正关心的选型维度有三：接口开放性（飞控是否开放二次开发接口）、机载算力（能否跑感知与协同算法）与链路兼容性（能否与集群通信硬件共处）。本节按大纲聚焦开源飞控与机载算力两个子问题。

6.1.1.1 开源飞控（PX4/ArduPilot）的二次开发接口

消费级飞控多采用封闭或半封闭固件，集群研究几乎都落在两大开源飞控栈上：PX4 与 ArduPilot[1]。两者的共同架构是"传感器驱动 → 状态估计（EKF）→ 控制器（姿态内环 + 位置外环）→ 混控输出"的分层流水线，与第 2.2 节的外环/内环分离假设天然吻合；差异在工程哲学：PX4 采用 NuttX 实时系统上的模块化微内核设计，模块间通过 uORB 发布-订阅总线通信，模块可整体替换，适合研究型二次开发；ArduPilot 采用 AP_HAL 硬件抽象层之上的统一架构，支持机型最广（多旋翼/固定翼/船/潜航器/车），代码成熟度高，适合多机型任务。工程选型经验：新研集群算法、深度依赖 ROS2 生态选 PX4；需要覆盖多机型或长期稳定运行选 ArduPilot（两者也常混合——PX4 飞控 + ArduPilot 地面的组合少见，推荐团队统一一种栈以降低维护成本）。

二次开发的接口层次从下到上有五层，理解这五层才能正确回答"改哪里、不改哪里"：

1. 参数层（最常用）：PID 增益、限幅、EKF 开关等通过 MAVLink 参数协议在线读写——第 7.1.1.2 节编队 PID 整定大部分工作在此层完成，不触碰固件；
2. MAVLink 消息层：MAVLink 是飞控与外部（地面站/机载计算机）通信的事实标准协议（串行化、低带宽友好），提供遥控/遥测/任务/参数/扩展自定义消息；机载计算机经 MAVLink 把"位置/速度/姿态指令"注入飞控，对应第 2.2 节的外环指令接口；
3. uORB 主题层（PX4）：飞控内部各模块经 uORB 交换主题（传感器原始数据、状态估计、控制输出），研究者在飞控内新增模块订阅/发布自定义主题，实现"固件内协作算法"——适用于对控制周期要求苛刻（>100 Hz）且不容忍链路往返的算法；
4. 混合器/机架层：修改混控矩阵与机型定义以适配非常规机架（倾转旋翼、共轴双桨等）；
5. 内核/驱动层：新增传感器驱动、时钟与调度调整——一般集群项目不应触碰此层。

工程铁律：凡是能在外环（机载计算机）解决的问题，不要下放到内环（飞控固件）。集群协同算法（一致性、编队、任务分配）工作周期在 10~100 Hz 量级，完全适合机载计算机层；下放固件只增加炸机风险与维护成本。飞控层的任务止步于"高可靠地执行位置/速度指令"，这与第二卷"平台内环只做跟踪、集群算法只发指令"的分层哲学完全一致。

6.1.1.2 机载计算单元的算力评估标准

机载计算单元（companion computer / onboard computer）承担感知、协同算法与通信管理。算力评估的错误做法是"按标称算力拍脑袋"，正确做法是按算法流水线的实时需求反推。评估流程如下：

1. 列举确定性负载：协同算法（编队控制、任务分配、状态广播）的周期与单周期算力需求——编队控制若 50 Hz 运行、单步 2 MFLOP，则占用约 100 MFLOPS；
2. 列举突发负载：感知算法（目标检测、点云聚类、视觉里程计）以帧驱动且随场景内容波动——深度学习推理通常占用 GPU/NPU，且单帧处理时间波动大，必须按最坏帧时间而非平均帧时间预算；
3. 叠加实时性要求：协同算法周期受第 1.2.2.1 节延迟预算约束，其抖动必须可控——计算单元需要"实时核 + 通用核"或明确的任务调度（实时线程钉核），把感知等非实时负载与协同实时负载隔离；
4. 评估外设带宽：机载计算单元与飞控（串行/USB 数百 kbps_{Mbps）、与数传/自组网（以太网/USB，10}100 Mbps）、与传感器（MIPI/USB3 可达 Gbps）的连接带宽必须分别核算，算力再强也补不了外设瓶颈。

算力评估的量化输出是负载余量表：各负载的 CPU/GPU 占用率、内存占用与最坏延迟，合计占用率控制在 60~70% 以内（预留安全余量与扩展空间），任何超出预算的算法需求都应触发"算法降配"而非"硬件加配"——例如感知帧率减半、检测输入降分辨率、协同算法改用事件触发（第 3.2.2.2 节）。最后提醒：机载计算单元的选择必须同时考虑功耗/散热（小机架散热差，算力纸面再高也跑不满）、软件生态（ROS2 支持度、驱动完备性）与抗振与接口冗余，三者对实飞可靠性的影响往往大于峰值算力本身。

6.1.2 集群通信链路配置

蜂群通信是架构中最"物理"的一环，也是第 1.2 节所有延迟/规模结论的发生地。集群通信的分层结构为：机间与机地链路（数据）→ 组网协议（拓扑与路由）→ 消息协议（MAVLink/ROS2 DDS）。本节按大纲讨论自组网选型部署与带宽-规模匹配计算。

6.1.2.1 自组网（Mesh）模块的选型与部署

集群通信的核心需求是"节点移动、链路动态变化下保持组网"，对应第 2.1.1.2 节的动态拓扑模型。工程选项按自组织程度递进：点对点数传（一对多广播、星形拓扑，地面站中继——拓扑最简单，对应第 2.1.1.1 节星形图，地面站即单点故障）→Wi-Fi 自组网（IEEE 802.11s 网状网标准，HWMP 路由，机间多跳，数公里内视距可用，吞吐 10~100 Mbps）→专用 Mesh 模块（基于 802.11/私有协议的组网数传，一体化天线与功放，支持机间多跳自愈，典型吞吐 1~20 Mbps，时延 10~100 ms）→蜂窝/卫星（广域覆盖但时延 100 ms~1 s，第 1.2.2.1 节表 1-3）。无人机蜂群的主力是 802.11s 自组网与专用 Mesh 数传；无人舰队（第 9.1.2 节）则因海面距离与多径需要卫星/微波组合。

Mesh 部署的工程要点（对应第 2 章拓扑设计结论）：其一，拓扑由功率与天线决定，不靠"协议魔法"——802.11s 的 HWMP 在节点高速移动时路由收敛慢，蜂群场景应优先拓扑简单的星形/树形分层或低跳数网格，减少路由震荡（呼应 2.1.1.2 节"频繁切换有害"的结论）；其二，必须预留中继节点角色——由式(2.8)的谱结论，加入 1~2 架空中中继（提高λ2\lambda_2λ2​）对全群连通收益最高，部署时应显式安排中继机与中继高度（中继高度通常高于队形平面以获得更远视距）；其三，链路质量监测是通信层的第一职责——每节点周期性广播心跳/信标，滑动窗口统计丢包率与 RSSI，作为第 2.1.1.2 节建链判据与第 3.1.1.2 节丢包补偿的输入；其四，频谱卫生——机载 WiFi 与图传/遥控的频段冲突会互相压制，部署前必须做频谱占用测量与信道规划（第 8.2 节部署清单的一部分）。

6.1.2.2 通信带宽与集群规模的匹配计算

带宽-规模匹配是最常被低估的工程环节：算法仿真中"理想信道"的假设，在真实链路上表现为时延、丢包与排队。匹配计算自下而上分三步：

第一步：核算单节点数据率需求。把机上每个周期性消息建模为（周期TmT_mTm​，报文大小sms_msm​），单节点总需求为各消息之和乘以协议开销系数βc\beta_cβc​（以太网/UDP/DDS 头、重传冗余）：

Rnode=βc∑m∈MsmTm(6.1)R_{\mathrm{node}} = \beta_c \sum_{m \in \mathcal{M}} \frac{s_m}{T_m} \tag{6.1}Rnode​=βc​m∈M∑​Tm​sm​​(6.1)

典型量级：状态广播（50 Hz × 64 B）+ 编队误差（50 Hz × 32 B）+ 意图消息（10 Hz × 256 B）+ 遥测转发（10 Hz × 200 B）≈ 数十 kbps/节点——注意这只是"协同层"需求，感知回传（点云/视频）一旦接入，sms_msm​增大 3~6 个数量级，必须走独立的高带宽链路或就地处理（前文算力评估的另一半作用）。

第二步：换算全网需求与空口负载。若采用全互联共享信道（每机广播，一跳内全员可见），全网空口负载约等于N⋅RnodeN \cdot R_{\mathrm{node}}N⋅Rnode​（每节点广播一次、全体接收，共享媒介按发送总量计）；若采用多跳单播，负载按路由中继放大（平均跳数hˉ\bar{h}hˉ倍）。无线共享媒介的实际可用吞吐只有标称速率的 40%~60%（CSMA 冲突、重传、协议开销），设信道利用率为ηc\eta_cηc​，全网可承载数据率为ηcB\eta_c Bηc​B，于是规模上限估算为

Nmax⁡≈ηcBhˉ⋅Rnode(6.2)N_{\max} \approx \frac{\eta_c B}{\bar{h} \cdot R_{\mathrm{node}}} \tag{6.2}Nmax​≈hˉ⋅Rnode​ηc​B​(6.2)

式(6.2)直接回答"这套链路能带多少机"：例如B=20B = 20B=20Mbps 专用 Mesh、ηc=0.5\eta_c = 0.5ηc​=0.5、hˉ=1.5\bar{h} = 1.5hˉ=1.5、Rnode=40R_{\mathrm{node}} = 40Rnode​=40kbps，则Nmax⁡≈160N_{\max} \approx 160Nmax​≈160架（纯协同消息）；若加入每机 2 Mbps 的感知回传，Nmax⁡N_{\max}Nmax​骤降至约 3 架——这解释了为什么所有蜂群系统的感知数据都"就地消化"而非回传。

第三步：核对延迟预算。由式(1.19)的设计裕度，编队控制链路端到端时延必须落在τmax⁡\tau_{\max}τmax​预算内；负载率升高 → 排队时延上升 → 有效τ\tauτ逼近阈值。因此带宽配置要与延迟预算联立：先按第 3 章定控制周期，再由式(6.1)(6.2)定规模与链路，最后仿真/实测验证时延（第 8.1 节将给出延迟注入测试方法）。规模增长若越界，正解不是"换更贵的链路"，而是降低RnodeR_{\mathrm{node}}Rnode​（状态广播降频、事件触发、感知就地处理——第 3.2.2 节方法全集）。

6.2 软件架构设计

6.2.1 基于 ROS2 的集群控制框架

机载软件的主干采用 ROS2（Robot Operating System 2）——面向多机多节点、以 DDS（Data Distribution Service）为通信中间件的机器人框架，其发布-订阅模型与"机载计算机 + 地面站 + 多机"的拓扑天然匹配，且 DDS 提供丰富的 QoS（Quality of Service）配置，是蜂群软件的推荐底座[2]。ROS2 之上再叠加机载飞控桥接（MAVLink/微 XRCE-DDS）与集群状态机，构成完整的软件框架。

6.2.1.1 多节点通信的 QoS 策略配置

DDS 的 QoS 是 ROS2 里"最容易出错也最值得细抠"的配置面。蜂群消息按对可靠性与实时性的需求分为四档，对应四套 QoS 模板：

表 6-1 蜂群消息的 QoS 分档配置

消息类别	示例	QoS 配置	理由
实时状态（高频、容旧）	位置/速度广播、编队误差	BEST_EFFORT + KEEP_LAST(1)	只要最新值，旧帧无价值；等可靠重传反而拖慢控制
关键指令（低频、必达）	队形切换指令、返航指令	RELIABLE + KEEP_LAST(1) + 超时重试	命令丢一条后果严重，宁等不丢
大块数据（感知/地图）	目标列表、局部地图	RELIABLE + 大发送队列 + 死线	数据完整性优先，容忍延迟
日志/诊断	调试消息、健康报告	BEST_EFFORT + KEEP_LAST(若干)	丢了不可惜，别占带宽

QoS 配置的三个常见陷阱：其一，发布端 RELIABLE 订阅端 BEST_EFFORT 不匹配会静默降级为 BEST_EFFORT——所有节点必须使用统一的 QoS 约定（编队各机同型软件，建议把 QoS 模板写成共享常量头文件）；其二，KEEP_LAST 队列深度设置过大会让延迟消息积压，实时状态类消息必须 KEEP_LAST(1)；其三，QoS 与丢包策略叠加——BEST_EFFORT + 丢包 = 第 3.1.1.2 节的状态保持策略，RELIABLE + 丢包 = 重传风暴，配置前先想清楚消息在丢包下"应该怎么表现"。

6.2.1.2 集群状态同步的 DDS 优化方法

集群的分布式算法（第 3~5 章）要求各节点对"全局状态"有一致视图，而 DDS 默认的端到端可靠性在小规模（<10 机）下够用，规模上升后必须优化。状态同步的 DDS 优化手段按收益排序：

1. 主题按需分区（partition 与 topic 命名空间）：全集群高频广播会撞车——把"仅编队内需要的消息"与"全局需要的消息"分主题分分区，减小无关节点的接收负担（对应 2.1.1 节拓扑分层在消息层的实现）；
2. 状态合并（multiplexing）：把多个 50 Hz 小消息合并为一条"状态包"（位置+速度+意图一次发布），把每节点消息数从 10+ 降到 2~3 条，显著降低 DDS 的每消息元数据开销（RTPS 头、发现协议流量）——消息瘦身比改 QoS 更立竿见影；
3. 发现协议（discovery）降噪：DDS 默认的参与者发现协议在全网广播，多机大规模下发现流量不可忽视——配置静态发现/对等发现白名单，或把集群分为小域（每个域内默认发现）；
4. 发布降频与事件触发结合：编队收敛后状态广播降频（第 3.2.2.2 节），由事件触发消息在偏差超限时补发——此方案把 DDS 的实时性从"持续供给"转为"按需供给"，需要 6.2.2 节分层架构提供"订阅方也能催发"的回传通道（心跳中携带"请求重发"标志）。

6.2.2 分层控制架构实现

6.2.2.1 任务层/协调层/执行层的接口定义

蜂群软件按控制时间尺度分为三层，每层有明确职责与接口边界——这也是第二卷算法在工程中的落位图：

• 任务层（task layer，秒~分钟级）：运行第 5 章的任务分配与全局规划，输出"任务指令集"（谁去哪执行什么）。接口：任务状态（进行/完成/失败/超时）与任务目标（航路、区域、优先级）；
• 协调层（coordination layer，100 ms~1 s 级）：运行第 3~4 章的一致性/编队/协商算法与第 7 章的协同行为，输入是邻居状态（经 QoS 状态主题），输出是"平台期望指令"（期望位置/速度/加速度、队形角色）。本层是蜂群智能的载体——所有"群体性"算法都在这一层运行；
• 执行层（execution layer，1~100 ms 级）：平台内环（PX4/ArduPilot 姿态与速度控制器）+ 机载安全逻辑（超限保护、失联降级），输入为协调层指令，输出为电机/舵面指令。执行层对上层暴露的标准接口是"期望加速度/速度向量 + 使能标志 + 指令超时戳"。

层间接口的三大纪律：其一，指令必须带超时戳——协调层崩溃或链路中断时，执行层按"超时即悬停/返航"的安全默认执行（第 8.2.2 节自恢复的触发源）；其二，层间只能经消息传递，禁止共享内存式紧耦合——保证任一层可单独在仿真中替换（第 8.1 节的 SITL/HIL 测试结构即由此而来）；其三，状态只能"上报-订阅"，不能"跨层改写"——任务层不直接改执行层参数，否则调试时无法定位"谁改的"。

6.2.2.2 层间数据流转的时序约束设计

分层架构的性能取决于层间数据流转的时序——总延迟是每层延迟与链路延迟之和，而第 1.2.2.1 节的稳定阈值约束的是"感知→决策→执行"全链路的端到端预算。端到端时序链为：

τe2e=τsense+τproc+τcomm+τexec≤τbudget(6.3)\tau_{e2e} = \tau_{\mathrm{sense}} + \tau_{\mathrm{proc}} + \tau_{\mathrm{comm}} + \tau_{\mathrm{exec}} \leq \tau_{\mathrm{budget}} \tag{6.3}τe2e​=τsense​+τproc​+τcomm​+τexec​≤τbudget​(6.3)

各分量预算的分配原则：感知延迟（传感器输出到可用状态，含曝光/缓存）通常占 1~3 个感知周期；处理延迟占 1~2 个协调层周期；通信延迟由链路与负载决定（6.1.2.2 节）；执行层延迟最小且可控。时序设计的三条规范：其一，层间周期必须整数倍对齐（任务层 1 s、协调层 100 ms、执行层 10 ms 的 10:1 对齐），避免非整数倍造成的相位漂移与"数据饥饿"；其二，消息时间戳贯穿全链路——每层在转发状态时携带原始采集时间戳，协调层算法使用"按时间戳对齐"的邻居状态（而非"按到达顺序"），否则不同机不同龄期的状态混算会引入虚假误差（对应第 3 章一致性对信息新鲜度的敏感）；其三，抖动预算必须实测校准——理论时序（式(6.3)）只用于分配预算，实际抖动用第 8.1 节的延迟注入与统计分析验证，任何一层的抖动实测超过其预算的 50% 就要重新分配。

本章小结

本章完成蜂群系统的"骨架"搭建：硬件层（开源飞控选型与接口五层模型、机载算力反推评估）、通信层（Mesh 部署四要点、带宽-规模匹配式(6.1)(6.2)）与软件层（ROS2/QoS 分档、DDS 状态同步优化、任务/协调/执行三层架构与端到端时序预算式(6.3)）。架构层面的工程结论可以浓缩为三条：能在外环解决的问题不放下放内环、感知数据就地消化而不回传、层间按时间戳对齐并留 50% 时序余量。本章选择的每一部件与配置都能在第 7 章的算法实现与第 8 章的测试流程中找到验证环节——软件架构的验收不在代码评审而在仿真与实飞。

思考与练习

1. 用式(6.1)(6.2)核算一个 30 机编队的带宽预算：给出状态广播、编队误差、意图、遥测四类消息的速率设定，判断 20 Mbps Mesh（ηc=0.5\eta_c = 0.5ηc​=0.5）是否够用；若不够，列出三种降低RnodeR_{\mathrm{node}}Rnode​的措施并重新核算。
2. 对比 PX4 与 ArduPilot 的五层二次开发接口，设计一个"飞控内实现编队误差补偿（>200 Hz）"方案应使用哪一层接口？说明为什么不应在 MAVLink 层实现。
3. 为表 6-1 的四类消息各写一段 QoS 配置（C++/Python），并解释为什么"发布端 RELIABLE、订阅端 BEST_EFFORT"会静默降级。
4. 画出任务层→协调层→执行层的完整数据流图（含时间戳标注与超时降级路径），标出式(6.3)各分量在架构中的位置，给出一组分配合法的延迟预算。
5. 设计一个"协调层单机失联"场景，说明执行层、协调层邻居、任务层各自应如何响应（超时→悬停→邻居接管→任务重分配），并指出该响应链对应本书哪些章节的算法。

参考文献

[1] Meier L, Honegger D, Pollefeys M. PX4: a node-based multithreaded open source robotics framework for deeply embedded platforms[C]//Proceedings of the IEEE International Conference on Robotics and Automation (ICRA). Seattle: IEEE, 2015: 6235–6240.
[2] Macenski S, Foote T, Gerkey B, et al. Robot Operating System 2: design, architecture, and uses in the wild[J]. Science Robotics, 2022, 7(66): eabm6074.
[3] IEEE Std 802.11s-2011. IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 10: Mesh Networking[S]. New York: IEEE, 2011.