HIL Swarm Simulation

一个用于硬件在环蜂群仿真的OpenEaagles框架扩展¶

摘要¶

无人机（UAV）蜂群的应用、算法和控制策略在过去15年中稳步发展。然而，直到今天，大多数蜂群开发工作仍未经过测试，因此也未能实现。飞行器系统成本、政府施加的空域限制以及缺乏适当的建模和仿真工具，是成功实现蜂群的主要障碍。本文研究如何扩展OpenEaagles仿真框架以弥补这一缺口。该研究旨在利用硬件在环（HIL）仿真，为开发者提供一种功能性能力，能够在仿真中开发和测试可扩展且模块化的自主无人机蜂群行为，并高度确信这些行为能推广到真实/实飞测试中。演示显示该框架通过封装提升和简化了蜂群开发，具有高度模块化，提供逼真的飞行器建模，并能在HIL仿真期间同时容纳4架由硬件驾驶的蜂群无人机，或在纯仿真中容纳64架蜂群无人机。

https://github.com/derekworth/SwarmSim

March 2016 THESIS

I. 引言¶

无人机蜂群在监视侦察、反蜂群防御、搜救、代理通信中继和快速地理测绘等多种应用中展现出有希望的潜力[43, 48]。尽管理论上蜂群可用于此类应用，但实际实现和成功部署代价高昂且极具挑战性。近年来，建模与仿真已被证明是开发过程中的重要初始阶段，能够降低成本并为成功部署奠定基础。构建一个用于测试和开发无人机蜂群的仿真环境，对于其在现实世界中的实现至关重要。

现有许多多智能体仿真框架，在经过一定修改后，或许能满足建模无人机蜂群行为的需求。然而，许多框架需要大量源代码开发和重构，才能仅模拟蜂群的简单方面或特定蜂群场景。理想的蜂群仿真框架应足够完整，能够模拟无人机蜂群的简单方面——如飞行器类型、位置和控制输入——同时为开发者提供一个工作空间或“游乐场”，以插入其传感器包和蜂群算法。具有内置可复用且适用功能的框架，能够减少开发开销和前期工作量，使开发者专注于蜂群开发而非仿真开发。

不幸的是，无人机蜂群的多样性和复杂性不允许蜂群开发者完全绕过仿真开发。不可能创建一个通用或“一刀切”的解决方案，涵盖蜂群的所有潜在方面。相反，更有价值的是识别、分类并融合常见的模式、配置和结构，以及已经被广泛接受且验证成功的流程、协议、结构和架构。此外，框架必须实现有用且用户（蜂群开发者）不应更改的代码，同时提供可扩展性（即可被扩展/重写）。本文探讨了建立此类无人机蜂群开发框架的方法。

此外，所谓的硬件在环（HIL）技术通过引入控制实际无人机的硬件嵌入式系统，增强了仿真。具体来说，仿真向硬件自动驾驶仪提供传感器信息（如位置、姿态、速度），以换取自动驾驶仪返回的控制信息（即操纵杆、方向舵、油门）。HIL仿真消除了对自动驾驶仪性能假设的需求，迫使仿真考虑通信协议、固件实现、处理器速度限制和集成到自动驾驶仪中的机载应用相关的时序和带宽约束。引入实际用于真实飞行的硬件设备，提高了蜂群在实飞测试中行为与仿真模型一致的信心。因此，本文探讨的蜂群仿真框架构建时即考虑了HIL的适配。

1.1 研究目标¶

本工作的最终目标是演示一个利用HIL的仿真框架，使开发者能够开发和测试可扩展且模块化的自主无人机蜂群行为，并高度确信这些行为能推广到真实/实飞测试中。该研究不旨在发明一个新的框架，而是扩展现有框架以容纳上述蜂群行为。具体而言，目标不是开发蜂群算法，而是定义一个空间，使蜂群开发者可以在其中开发和测试自己的算法。本文借助仿真、蜂群控制理论、可视化（计算机图形学）、飞行动力学、串行及链路层通信和HIL集成等领域的现有技术与研究进展。

1.2 论文结构¶

本文余下内容安排如下：第二章介绍本研究的背景，包括为何要开展蜂群仿真框架的理由、需求分析、相关设计考虑以及OpenEaagles仿真框架简介。第三章阐述如何扩展OpenEaagles以支持蜂群行为开发及HIL仿真。第四章通过蜂群开发场景测试所提出的蜂群仿真框架，展示其能力与局限性。该章揭示在HIL仿真期间，仿真与硬件设备间高频率数据传输成为蜂群可扩展性的瓶颈。最后，第五章对蜂群仿真框架进行总结评估，并提出未来工作建议。

II. 背景¶

任何软件框架的设计与实现，都需深刻理解软件必须满足的需求。本章通过首先探讨为何需要蜂群仿真框架，以及以往蜂群开发工作对蜂群共性元素的启示，来提取这些需求。随后，讨论当前技术与设计考量，这些内容构成了所提框架的基础组件，并介绍OpenEaagles仿真框架。

2.1 为什么需要无人机蜂群？¶

如果你正在阅读本文，可能会问：“无人机蜂群为什么有用或重要？”不幸的是，目前无人机蜂群的广泛应用仅存在于未来的远见者想象中，因此尚无实际效用的衡量标准。随着微型计算机、人工智能、无线网络通信和自主飞行探索的发展，技术才逐渐成熟，令此类愿景成为现实。本节试图通过探讨灾难救援和军事战略等相关领域专家的观点和建议，回答蜂群为何重要。首先，什么是无人机蜂群？如PennWell航空防务媒体集团所述，“无人机蜂群是协同工作的无人机群体，它们彼此通信，并协助其他蜂群成员完成任务”[15]。无人机蜂群的普遍共识是“以少胜多”的能力，即用更少的操作者，以更低的成本、更快的速度、更高的效率和更少的错误完成大型复杂任务。

Kumar [23]指出，搜救是蜂群明显优于单一航空器的一个有前景的领域。蜂群能够自主协调，更快覆盖更广区域，且只需一个操作者。想象数十架无人机梳理区域，不仅向操作者传递信息，还彼此通信，协调避免重复覆盖。配置用于搜救任务的蜂群比单架飞机更可能找到受害者。此外，无人机的自主协调解放操作者，使其能做出更高层次的战略决策，例如基于新获得的外部情报，将蜂群（或部分蜂群）转移到更高优先级区域。这将有助于自然灾害后的救援工作，加快救援响应时间和伤员治疗。

在军事应用中，蜂群可在攻防两端发挥关键作用。Scharre [43]认为，大规模无人机蜂群在战斗中具有多种潜在优势，包括战斗分散、蜂群韧性、优雅退化及敌方防御饱和。这些优势在考虑蜂群攻击当前防空系统时尤为明显，如地对空导弹（SAM）阵地通常设计为一次只能交战少量连续目标。当前SAM阵地无法防御大量空中载具同时攻击，且常依赖装备昂贵弹头、制导系统和传感器的导弹，蜂群通过消耗价值数百万美元的导弹以数千美元的无人机进行经济上的优势对抗。此类因素赋予蜂群战斗优势。武装蜂群无人机将成本低廉且可一次性使用，提供一种经济且更可靠的击败敌方防御系统方式。Chung [23]指出，唯一能阻止蜂群的军队是另一支蜂群。

除了在搜救中拯救生命和摧毁战场敌防外，无人机蜂群在其他领域也展现出促进协调行动和实现以往被认为不可能的效果的良好机会。只有当蜂群行为被开发、测试并投入实践后，我们才能认识并拓展这些机会的真正价值。下一节阐述仿真作为蜂群理念与现实实施之间桥梁的必要性。

2.2 仿真框架的必要性¶

蜂群配置变化极大——从简单有序（如网格阵型）到高度动态且看似混乱（如无人机群形成紧密球体并作为整体移动，避免碰撞）。为开发和测试如此广泛的蜂群配置，建模与仿真必不可少。跳过建模和仿真阶段代价高昂。实飞测试伴随大量资源需求，如地面站、飞行器、燃料和传感器包等物理组件的固有成本。

此外，外部因素如受限空域限制了实飞测试。美国拥有全球最繁忙、最复杂的空域[1]，在此拥挤空域中开发和测试真实无人机蜂群对FAA和航空界均构成挑战，其成本在以下示例中体现：一项18个月的农业用途无人机测试（于2015年6月结束），需要多种小型无人机，价格从9000美元到10万美元不等，取决于传感器包需求，且平均运行成本为每小时30至50美元。此外，冗长且昂贵的政府审批过程导致严格限制：每架无人机必须保持目视范围内，始终低于地面以上400英尺，且重量低于2公斤[14]。该例展示了真实无人机实飞测试的部分挑战，而这些挑战可在仿真中轻松缓解。仿真飞行器及传感器包不仅大幅降低金钱成本，还能探索超越政府限制范围的测试。

系统开发者因而转向建模与仿真。尽管部分现有模拟器对无人机蜂群提供有限支持，但多数依赖过多假设，难以准确映射真实飞行。Corner [11]对众多相关蜂群和网络模拟器及仿真框架进行了调研。虽然这些工具均能孤立模拟无人机蜂群的特定方面，如粒子动画蜂群、无人机/目标交互以及蜂群节点间临时网络的统计仿真，但均未提供准确且全面的飞行仿真环境，无法模拟多种飞行器并配备定制自主行为。因此，蜂群开发仍多停留在理论阶段。

开发者已提出针对多目标检测与定位[3,12,33]、多目标跟踪[27]、持久感知[40]及侦察/监视[42]等任务的蜂群中心解决方案。部分研究甚至展示了无人机蜂群如何追踪环境状况，如有害海洋漂浮物[41]及污染云边界[44]。然而，迄今这些蜂群行为仍未实现。迫切需要一种能够稳健准确建模无人机蜂群的仿真框架，以克服上述假设和挑战。通过提供准确仿真蜂群的手段，蜂群开发者可以以远低于实飞测试的时间和成本，初始化、运行并重复多种测试，且不受实飞限制。唯有如此，开发者才能验证蜂群中心解决方案的可行性。

2.3 当前无人机蜂群仿真现状¶

无人机蜂群在现实应用中的使用是一个相对较新的概念。直到近几十年，我们才开始尝试这一理念并涉足其实现。在此期间，许多先驱者通过推进控制策略、算法和仿真，验证了使无人机蜂群成为现实的理论。这里，我们将审视这些努力中的许多，其中部分构成了所提蜂群仿真框架的基础。

2.3.1 蜂群研究¶

人们研究了蜂群的不同方面，试图回答诸如“我们如何控制蜂群？”以及“在不同蜂群控制策略中，哪种是最优？”等问题。对于后者，答案显然是视情况而定！如图1所示，存在多种控制策略，可能对不同场景表现出不同适用性。使用涌现协调的蜂群在攻击任务中更具韧性——当遭受敌方火力时能够实现优雅退化——而使用集中协调的蜂群则容易被一击致命（敌方只需摧毁领头无人机即能消灭整个蜂群）。但我们如何确定采用涌现协调实现进攻行动的蜂群是否可行？如果可行，这是否比其他方式更有利？

图1. 蜂群控制模型。（最初见于[43]，作为公共领域元素复现）

许多蜂群开发者在仿真中建模其算法和控制策略以回答上述问题。一些使用高保真仿真环境，另一些则使用简单数学模型，并通过如MathWorks®工具Matlab进行结果可视化。表1列出了过去15年间进行的多项蜂群研究。可以看到，研究中采用了多种方法对算法或蜂群控制策略进行建模。比较这些研究的建模方法时，出现了一些显著规律。首先，仿真复杂度与模拟无人机数量呈反比。高复杂度仿真模拟的无人机较少（约3架），而简单仿真则能模拟更多（30架以上）。这符合直觉，高保真建模需更多处理器资源以计算空气动力学、传感和环境效应等细节。另值得注意的是，使用复杂建模的研究依赖成熟飞行模拟器和仿真框架等基础工具，而非为特定目的构建的自定义工具。通过使用社区广泛使用且持续开发的准确工具，蜂群开发者能够获得足够信心，确信这些工具能够充分验证或否定其假设。

这并非意味着所有蜂群开发均需如此精确。虽然表1中的许多研究仅使用简单模型和大量假设来验证假说，但这些研究结果提供了丰富知识。然而，当从仿真过渡到现实飞行测试时，则必须具备全面准确的仿真。例如，Hexmoor [25] 探讨了竞价过程如何促进协调的多目标跟踪。该研究开发者进行了详细仿真实验测试理论，但其仿真环境仅由不同颜色和大小的小形状（代表无人机和目标）构成，这些对象仅在一个小矩形网格中拥有两个自由度（垂直和水平方向移动）。该研究对竞价过程得出了一些有意义的结论，但难以体现该过程在真实无人机蜂群中的表现。

表1. 蜂群研究

蜂群研究	年份	2D/3D仿真	最大无人机数	FDM/机体	通信	传感器	HIL	地面站	定制仿真器	基础工具	可视化界面
Cooperative Control [37]	2002	两者	8	C	是	是	否	否	否	Simulink/MultiUAV	Matlab绘图及AVDS回放
Wide Area Search [8]	2002	2D	8	S	否	是	否	否	是	Matlab和Simulink	Matlab
SEAD and Target ID [20,21]	2003/5	3D	32	S	是	是	否	否	是	定制	命令行反馈
Target Locating and Tracking [25]	2005	2D	U	VS	否	否	否	否	是	定制，Java编程	带GUI控制的矩形网格
General Flocking Algorithms [34]	2006	两者	150	U	U	U	否	否	是	未说明	2D/3D图形绘制
Vehicle Routing Problem [30]	2007	两者	640	S	否	是	否	否	否	SPEEDUS	带数据的地图叠加
Search and Destroy [32]	2007	2D	65	S	是	是	否	否	否	SWARMFARE	脚本可视化
Formation Flight [19]	2010	3D	3	VC	是	否	否	否	否	X-Plane/Matlab/Simulink	带Matlab脚本的3D GUI
Flocking and Comm Range [24]	2011	3D	10	S	是	否	否	否	是	未说明	2D图形绘制
Search and Attack [9]	2012	2D	50	VS	是	是	否	否	否	SWARM Simulation	2D地图GUI
Swarm-vs-Swarm [17]	2013	3D	100	C	是	是	否	否	否	MASON	3D GUI
Point ISR Flocking [28]	2014	3D	10	S	否	是	否	否	是	Matlab	Matlab绘图
Formation Flight [49]	2014	3D	4	VC	是	否	否	否	否	FlightGear/Matlab/Simulink	Matlab绘图及飞行模拟GUI
Flocking for Drag Reduction [29]	2014	2D	15	VS	否	否	否	否	是	Matlab	Matlab绘图

VS（极简）- 仅使用离散/增量二维定位建模；模型通常以线性方式移动  
S（简单）- 使用离散/增量二维或三维定位建模  
C（复杂）- 使用数学方程进行连续三维定位建模，考虑六自由度  
VC（极复杂）- 使用完整功能的飞行动力学模型，考虑空气动力学及诸如重力和天气等环境效应  
U（未说明）- 未指明功能/属性

另一个显著观察是，所有研究中有一半依赖自定义模拟器，且仅有两项研究未使用现有框架或工具集作为建模环境基础。还注意到，近半数仿真完全依赖Matlab/Simulink进行数据生成和/或解释。这表明对准确且易用的通用仿真工具的需求。若无合适工具或工具过于复杂，蜂群开发者较少探究某些蜂群行为。此外，自定义工具往往依赖简单设计和过多假设，难以对被观测的蜂群控制算法/策略得出有效结论。蜂群仿真框架应作为一种通用工具，既足够易于扩展与定制场景实现，又足够准确以提供有用结果。

最后需注意，无研究实现硬件在环（HIL）或蜂群地面控制站（GCS）功能，这反映了无人机蜂群研究的现状。即当前蜂群控制算法与策略尚不成熟，尚不足以支持测试此类先进蜂群组件。

尽管如此，如后文所述，实现这些功能在从理论过渡到实际无人机蜂群飞行测试时具有重要益处。

2.3.2 关键仿真组件¶

表1的研究代表了当前无人机蜂群仿真的方法。每项研究均关注蜂群行为开发的特定方面，但未提供可直接转化为现实行为的综合解决方案。本文目标是提出一个框架设计，支持HIL仿真及准确建模无人机蜂群所需的全部组件，从而提供完整解决方案。本节概述三个所有蜂群仿真共有的关键仿真组件（实体、系统和视图），下一节介绍业余爱好者社区开发的技术，组成实现准确HIL蜂群仿真所需的剩余组件。

实体（Entities）。所有蜂群仿真中明显的首个组件是软件定义的实体。表1中的许多蜂群研究不仅模拟无人机，也包括外部参与者和目标。例如，Gaerther的研究[17]要求区分友军和敌军无人机，以展示两个不同蜂群的交互。在此情况下，需要两种不同实体类型（即友军和敌军无人机）。此外，许多场景需要目标实体。软件定义实体使得仿真中关键的“参与者”得以建模，这对蜂群开发至关重要。

系统与子系统（Systems and Subsystems）。表1所示所有场景均表明，蜂群无人机实体（可能还包括非无人机实体）必须与环境及彼此交互。仿真中对应的传感和通信功能建模需整合实体系统与子系统。图2所示的无人机硬件架构示例支持该论断，展示了真实无人机的系统与子系统，如机载传感器和通信接口，用于采集并与操作员及其他无人机交换信息。传感器如全球定位系统（GPS）接收器、摄像头和惯性测量单元（IMU）捕捉外部输入（如位置、速度、图像、姿态等），这是蜂群行为中自主决策的必要条件。此感知信息经处理后，不仅通过通信链路传递给地面操作员和其他无人机，也传输至无人机机载其他组件。鉴于信息采集与分发是大多数无人机任务的主要目标[13]，这些系统与子系统对真实及仿真无人机操作均至关重要。

图2. 无人机硬件架构示例。无人机由多个子系统组成；仿真中，开发者应具备根据需求建模这些子系统的能力。（最初见于[47]，作为公共领域元素复现）

视图（Views）。所有蜂群场景中的另一个重要仿真组件是视图或仿真可视界面。无可视化与交互手段，仿真数据难以解读。例如，观察飞行器在三维空间的运动，远比分析时间、位置、速度和姿态测量表格更易于直观判断特定机动（如高头失速或滚转）。至少，仿真可视界面必须能接收仿真数据并将其转化为蜂群的有意义视觉表现。蜂群视觉表现的有用方面包括无人机在三维空间的渲染、录制及可控速度回放。三维渲染应支持平移、俯仰、缩放及围绕蜂群或单个无人机旋转视角。一些可视化框架提供“飞越”和“跟随”视角，增强仿真分析。视图还应直观展示个体飞行器状态参数（如高度、速度、滚转/俯仰/偏航角）、飞行路径（即无人机身后显示先前位置的尾迹）及无人机间关系（如相互间距和高度差）。为满足这些需求，蜂群仿真框架应支持多种不同视图。

2.3.3 业余爱好者社区¶

许多无人机爱好者发现无人机在业余时间玩耍非常有趣且令人兴奋。他们在博客和其他公共论坛上分享自己的尝试，互相帮助解决无人机相关问题。DIY Drone 就是这样一个典型的公共论坛，来自世界各地的业余爱好者聚集于此，分享他们的定制无人机设计。这个开源社区汇集了大量知识与经验，通过不断试错测试新思路。正是通过这些努力，出现了许多与蜂群仿真相关的有用工具和技术。

该社区开发了遥控（RC）飞机、地面控制站（GCS）软件、自动驾驶硬件/固件、高吞吐量低开销的通信协议和飞行模拟器，这些工具组合使用时可提供多种功能。表2列出了当前业余爱好者社区中可用的一些工具。

表2. 业余爱好者社区工具

类型	工具
带FDM的RC飞机	HiLStar17F/EasyStar、Zagi飞翼、Sig Rascal 110、Viper X-10、Multiplex TwinJet、Early Bird滑翔机
地面控制站	MAVProxy、QGroundControl、Mission Planner、APM Planner
自动驾驶仪	OpenPilot、FlexiPilot、ArduPilotMega、SLUGS、Pixhawk/PX4、MatrixPilot/UAVDevBoard、SMACCMPilot、Armazila、Aerob
通信协议	MAVLink、UAVCAN
飞行模拟器	XPlane、FlightGear、Microsoft Flight Simulator、GEFS Online、AeroSimRC、JSBSim

机体。 表2展示了用于蜂群开发的一部分飞机样本。然而，业余爱好者社区和美国国防部中存在众多不同尺寸和配置的机体，均有潜力集成至无人机蜂群（见图3）。仿真此类无人机的一大挑战是实现精确的飞行动力学模型（FDM）。本文使用的FDM是开源的JSBSim软件库，该库也是FlightGear的飞行动力学模型，自1996年以来由航天及软件工程专业人士持续开发[5]，依赖飞机构型定义文件提供有效的飞行特性数据。Sig Rascal 110飞机模型在业余爱好者社区广泛使用和开发近4年，是本文用于演示所提蜂群仿真框架的机体。

自动驾驶仪。 美国传统词典定义，“自动驾驶仪是一种导航装置，如飞机上用以自动保持预定航线”[36]。在小型无人机环境下，自动驾驶仪功能更丰富。作为飞行管理系统（FMS）的一部分，自动驾驶仪是无人机的“大脑”，对其他子系统组件提供监督控制。无人机自动驾驶仪将传感器数据转换为驱动节气门和连接控制面的伺服机构的输出信号，最终控制空速、高度和航向[39]。大多数无人机自动驾驶仪至少支持高度、方向和位置（盘旋）保持，有些还支持航点（即点对点）导航。自动驾驶仪是蜂群中无人机的关键部件，提供稳定飞行和导航能力。PX4飞行栈——Pixhawk自动驾驶仪固件的一个实现，带有许多机载应用程序——是业余爱好者社区中广泛使用的自动驾驶仪之一，本文也使用它演示HIL仿真。

图3. 多样机体。小型无人机形状、尺寸和配置多样。本文使用的机体是图中上排左起第二的Sig Rascal 110 ARF。

硬件在环仿真（HIL Simulation）。 硬件在环是一种实时仿真方式，通过在环路中加入真实硬件组件[22]，允许开发者测试真实硬件性能并收集数据，避免损失真实飞行器风险[7]。这在开发资源密集型的蜂群行为时尤为重要，因为模拟组件与实际组件性能可能因对硬件的假设差异而不同。将硬件设备整合进仿真，物理组件将提供最真实的反馈。此外，因硬件嵌入式系统实时运行，使用HIL时仿真也必须实时运行。

业余爱好者社区广泛使用HIL仿真。该方法不仅让爱好者能在无实际坠机风险情况下，使用真实硬件自动驾驶仪练习飞行机动，还允许其在将硬件装机前调整自动驾驶仪参数。业余飞行的一般设置如下：操作者使用无线电遥控器配合地面控制站（GCS）软件，通过如MAVLink的高吞吐低开销通信协议与空中飞行器的自动驾驶仪通信。在手动模式下，操作者可对无人机进行完全手动控制，或切换至其他模式，由自动驾驶仪实现部分或全自动飞行，即稳定飞行和点对点导航。HIL仿真以仿真模型代替实际无人机。利用此技术，GCS通常作为HIL接口，从仿真中拉取建模无人机数据（如高度、姿态、速度等），并以自动驾驶仪可识别格式发送给硬件自动驾驶仪。随后，GCS将自动驾驶仪产生的控制信号回传给仿真（见图4）。本研究的重要目标之一是扩展该HIL系统开发方法，以支持更可能成功过渡至真实飞行测试的蜂群行为仿真开发。

图4. 硬件在环。左图显示了业余社区典型的无人机控制设置——操作者通过无线电提供手动RC输入，同时通过GCS（均经无线电）发送指令和更新参数。右图中，操作者以同样方式控制仿真飞行器，但嵌入式系统（即硬件自动驾驶仪）通过串口/USB连接与仿真器通信，GCS作为两者间的接口。

地面控制站。 地面控制站（GCS）为人工操作者提供控制空中或太空无人载具的界面。传统上，GCS在无人机操作中（尤其是业余社区）负责更新自动驾驶仪参数和航点，同时显示无人机遥测数据[16]。如前所述，业余社区使用的GCS软件，如QGroundControl和Mission Planner，也作为HIL接口使用。FlightGear（飞行模拟器）和QGroundControl均为开源软件，本研究利用它们测试和开发与Pixhawk自动驾驶仪的硬件接口，用于蜂群仿真框架中的HIL仿真。

2.3.4 仿真链（Simulation-Chaining）¶

现有飞行仿真软件架构支持一种可扩展的蜂群仿真方案，称为仿真链。XPlane和FlightGear均为飞行模拟器，已提供多种机型的逼真飞行动力学建模，支持与现有硬件自动驾驶仪飞行栈的HIL集成，并提供仿真输入/输出的网络接口。仿真链在此定义为多个飞行模拟器实例通过网络集成，本文描述此方案以指出另一种支持无人机蜂群HIL仿真的方法及其实现中遇到的挑战，这促使探索扩展OpenEaagles框架。

仿真链设计简单：在两台或多台计算机上安装已有飞行模拟软件，并为每台添加蜂群接口，使其能跨网络通信（见图5）。只要所有飞行模拟器环境和坐标系一致，单个无人机可在接收邻近无人机信息后，将其投射进自身环境中。脚本可初始化蜂群场景，另一工具可截获/存储/解释网络流量（即蜂群数据），以实现无人机共同蜂群的可视化。该设计无需对飞行模拟器做额外开发。XPlane和FlightGear支持自定义飞行器模型，有助于机体模块化。它们也提供交互视图，但仅限单架飞机，这对研究单个蜂群无人机行为仍有帮助。自动驾驶仪HIL实现通过第三方GCS软件完成，可集成进蜂群接口。

为评估此方案可行性，构建了一个简单应用，用于通过网络连接多个FlightGear 3.4.0实例（模拟Sig Rascal 110）和QGroundControl v2.3.0。设计蜂群接口的首要挑战是从仿真中提取遥测数据。FlightGear中有一选项可输出包含用户指定仿真信息的UDP数据包流，使蜂群接口能识别邻近无人机。硬件自动驾驶仪（Pixhawk）通过QGroundControl连接至模拟器，实现HIL。在此设置中，编程至Pixhawk的航点集合为模拟无人机导航提供路径规划信息（代替实际蜂群行为）。成功将两个模拟器串联后，该设置（见图6）使两架无人机能识别彼此，仿佛在同一虚拟环境中飞行。

图5. 仿真链。每台计算机运行一个独立的仿真实例，广播其无人机的仿真遥测数据，同时接收并处理来自其他仿真的遥测数据。

该设计准确建模飞行动力学，支持HIL，允许多无人机交互，并提供蜂群的视觉界面。但存在若干固有设计缺陷。首先，开发者必须管理每个飞行模拟器实例。模拟大量无人机，尤其初始化复杂蜂群配置时，这成为难题，降低了可用性。其次，无人机子系统功能（如通信和传感系统）实现必须放在蜂群接口中，难以顺畅转化至真实飞行器。最后，该设计不支持表1中多蜂群场景所需的目标模拟。尽管仿真链在许多方面潜力巨大，但实验揭示了显著缺陷，促使探索替代设计。

图6. 使用FlightGear的仿真链。两个同时运行的FlightGear实例通过UDP包广播仿真状态。截获这些包后，各实例蜂群接口可将邻近无人机投射进自身环境，仿佛它们共同飞行。

2.4 质量属性¶

与任何软件架构或设计一样，探索相关的软件质量属性非常重要。本节聚焦于提升和促进蜂群开发的四个具体属性：模块化、可复用性、易用性和可扩展性。

在开发过程中，蜂群开发者必须能够轻松添加、修改和删除蜂群组件，而不会对仿真的其他部分产生不良影响。因此，整个框架应具备高度模块化——即系统由各部分组成，这些部分能干净分离且相互契合的特性[35]。模块化设计简化了各种蜂群配置和场景的测试，包括不同目标、飞行器、蜂群算法、自动驾驶仪及其他系统/子系统的组合。

为实现高效开发并配合框架模块化，蜂群仿真组件应具备可复用性。可复用性定义为组件和子系统适合用于其他应用和场景的能力。它减少了组件重复开发和实现时间[45]。此属性重要在于促进开发蜂群行为，而非重复构建已有的蜂群建模工具。如果为模拟蜂群场景必须开发自定义工具、设计或文档，应考虑可复用性以防止未来工作重复。

除可复用性外，作为任何软件框架的基本要求，蜂群仿真框架还应表现出高易用性，即框架满足开发者需求的程度，通过直观设计带来良好的用户体验[45]。如前节仿真链示例所示，若开发者觉得仿真框架难用或难管理，将放弃转向更易用的替代方案。所提框架提供的工具应易于理解和使用，学习成本低于寻求其他框架解决方案的成本。

最后，框架应具备可扩展性，以支持不同规模和复杂度的蜂群。可扩展性指系统在负载增加时无性能下降，或能方便地扩展的能力[45]。无人机蜂群本质（即“数量优势”）要求高可扩展性，低可扩展性限制开发者的测试和实验能力。例如，若仿真只能模拟两架无人机，开发者如何判断200架无人机蜂群的行为？

2.5 OpenEaagles¶

至此，我们了解了先前的方法、蜂群仿真的常见和关键元素、技术、手段及相关考虑。以下介绍OpenEaagles仿真框架，本文在此基础上扩展以满足蜂群仿真需求。以下内容摘自OpenEaagles主页，总结了使OpenEaagles成为理想框架基础的几个关键特点：

OpenEaagles是一个跨平台仿真框架，旨在帮助仿真工程师和软件开发者快速原型设计并构建健壮、可扩展、虚拟、构造式、独立及分布式仿真应用……OpenEaagles全称为开放可扩展联动仿真分析与生成架构。该框架成熟，已开发活跃逾十年。[26]

此外，框架具备模块化架构，支持与成熟且可信的FDM（Flight Dynamics Model）（如JSBSim，FlightGear使用的同一FDM）轻松初始化和配置仿真，并提供内置功能，促进蜂群行为建模配置。

2.5.1 模型-视图-控制器设计模式¶

OpenEaagles是一个面向对象框架，使用C++编写，遵循模型-视图-控制器（MVC）设计模式。每个仿真实例由多种对象组成，形成树状数据结构（见图7）。模型包括玩家（Player）和系统（System）对象，多种可选图形及I/O接口提供定制视图，站点（Station）对象位于树根部，负责与仿真对象（Simulation）接口，承担仿真控制器功能。

图7. OpenEaagles设计模式[26]。OpenEaagles遵循模型-视图-控制器设计模式。右侧的玩家和系统树提供模型，左侧图形和I/O对象提供视图，站点和仿真对象充当控制器。

模型。 每个仿真实例拥有一个Simulation对象。Simulation包含Players，Players包含Systems。Players代表被建模实体（如无人机和目标），Systems代表实体使用的设备、工具（如电台、动力学模型、传感器）。开发者可通过子类化Player和System类实现定制。图8展示了与蜂群相关的无人机系统及其在OpenEaagles中的子类化方式。该简单设计结合继承与多态，支持无限蜂群配置建模。

图8. 无人机系统层级。无人机系统和子系统按功能角色分组（图下方圆圈）。OpenEaagles中这些系统通过继承实现父子关系，带来可扩展性和代码复用优势。

此外，每个System拥有名为getOwnship的方法，返回所属Player指针。Player拥有getSimulation方法，Simulation拥有getStation方法。由于Station对象可访问整个树，且每个对象能回溯至Station，任意对象均可直接访问其他对象。这赋予Player和System之间交互能力。

视图。 为查看仿真数据，OpenEaagles包含基于OpenGL的图形包。开发者可设计并实现自定义视图，展示玩家的姿态、空速、燃油消耗、地图位置或周围地形等信息。框架还包含支持分布式仿真架构网络通信的包，如分布式交互仿真（DIS）、高级体系结构（HLA）和测试与训练使能架构（TENA）。这些包满足多样化的可视化需求，无需开发定制工具的额外开销。

控制器。 如前所述，Station和Simulation对象提供仿真控制。Station管理设备、图形及网络对象，控制刷新率、优先级及线程栈大小。Simulation控制特定仿真参数（如参考点、时间、地球模型等），并管理时间关键及非时间关键任务线程。具体来说，Simulation允许开发者指定时间关键和后台线程数，这些线程以轮询方式分配玩家，每线程处理部分玩家。时间关键线程负责必须与实时同步的任务，非时间关键线程允许后台运行其他任务，且不阻塞时间关键任务。该区分对实时建模尤其重要，如HIL仿真中使用硬件自动驾驶仪。由于硬件自动驾驶仪实时运行，仿真也必须实时执行，提供与自动驾驶仪接收的实时控制信号同步的仿真数据。此外，OpenEaagles多线程在模拟大量玩家时有用，因为线程可分布于多个CPU核并并行处理任务，但对少量玩家建模时，线程管理开销可能不划算。

2.5.2 基类¶

OpenEaagles基于其基类构建（见图9）。所有对象均为Object类型，包含用于内存管理的ref和unref方法。每个Component对象可持有其他组件（子组件），以PairStream列表形式存在。OpenEaagles的树状数据结构利用该组件/子组件关系，实现框架可扩展性。树通过updateTC和updateData方法更新，分别对应前述时间关键和非时间关键线程。这些更新方法从仿真树根调用，再递归调用其子组件的更新方法，直至整棵树更新完成，且更新以指定刷新率循环进行。

图9. OpenEaagles基类[26]。OpenEaagles中所有对象均为Object类型。部分对象为Component，可持有PairStream组件，实现子组件树结构。

仿真同步通过帧实现。OpenEaagles中的帧定义为仿真树中所有updateTC方法被调用的周期。单帧时间关键任务必须在前一帧所有时间关键任务完成后开始。每帧最短持续时间由指定帧率决定（如50Hz刷新率对应20ms）。

1、基类架构

1.1 Object 类

所有对象的基类 在 OpenEaagles 中，无论是玩家（Player）、系统（System）还是其它辅助模块，最终都继承自同一个基类 Object。
内存管理：ref 与 unref
ref()：为对象增加一个引用计数
unref()：减少引用计数，当计数归零时，自动释放对象这种显式的引用计数机制帮助框架在多处持有同一对象指针时，保证不会“野指针”或内存泄漏。

1.2 Component 类

Component：可包含子组件的对象 继承自 Object 的 Component 类，引入了一个 PairStream 容器，用来保存它的“子组件”（subcomponents）。
PairStream 列表
类似于标准库中的链表或向量，保存若干 (key, Component*) 对
key 通常是子组件名称或标识，Component* 指向具体子对象
树状层次结构 通过把组件嵌套在 PairStream 里，实现了多层级的组件——子组件关系。所有组件共同组成一棵“仿真树”（Simulation Tree），这正是框架可扩展、可插拔的基础。

2、仿真树的更新机制

2.1 updateTC 与 updateData

updateTC（Time-Critical）
用于必须严格同步到仿真循环、对延迟敏感的“实时关键”任务
例如：飞行动力学解算、控制律计算、传感器数据输出
updateData（Non-Time-Critical）
用于对实时性要求没那么高的后台任务
例如：日志记录、UI 更新、网络通信、调试信息输出

2.2 从根节点到叶节点的递归更新

从根节点调用 在每一帧开始时，仿真控制器首先在仿真树的根节点（Station 或 Simulation 对象）上依次调用 updateTC()（或者 updateData()）。
递归向下
根节点的 updateTC() 会遍历其 PairStream 中的所有子 Component，依次调用它们的 updateTC()。
每个子组件又会再遍历自己的子组件，继续调用……
直到“叶子” 递归一直进行到没有子组件的最底层对象（叶子节点），完成后逐层返回。
整个树更新完成 无论树多深，所有 updateTC()（或 updateData()）都被调用一次，仿真状态前进一步。

3、帧（Frame）与同步

3.1 帧的定义

Frame：一帧是 “从上一次所有 updateTC() 调用完成，到本次所有 updateTC() 调用完成” 这一段时间。
最小时长 由仿真指定的刷新率决定，比如 50 Hz 刷新率意味着一帧至少 20 ms。

3.2 实时关键任务的调度约束

互不重叠原则 同一帧的所有 updateTC() 必须在开始下一帧的任何 updateTC() 之前完成。
保证实时同步 若一次 updateTC() 调用耗时超过帧时长（如 > 20 ms），下一帧就要“追不上”时钟，仿真开始落后现实时间。
等待/调节 当所有 updateTC() 在帧时长之内完成后，系统可主动“休眠”至帧尾，再进入下一帧更新，以保持与真实时间同步。

4、可扩展性与并行化

可扩展性
任意多层的组件／子组件结构，只需在 EDL（或代码）中插入新的组件，即可自动纳入更新循环。
并行化
OpenEaagles 支持将 updateTC() 分配到多个线程（多核 CPU）并行执行，不同时间关键线程处理不同子树，加速大型仿真。

小结

Object 提供统一的内存管理。
Component + PairStream 构建了可无限扩展的树状仿真结构。
updateTC/ updateData 分别对应实时关键与非关键任务的更新接口，通过根节点递归、帧级同步完成每次仿真迭代。
Frame 机制 确保所有实时关键任务在规定时间内完成，维持仿真与真实时间的同步。

正是这一系列设计，使得 OpenEaagles 在保持高模块化、可扩展性的同时，也能够满足实时仿真的严格需求。

2.5.3 Eaagles定义语言¶

理解OpenEaagles基本构建模块和结构外，使用该框架还需熟悉Eaagles定义语言（EDL），它用于初始化和配置每个仿真，允许用户完全控制仿真树的初始大小、配置、状态及刷新率。EDL文件让开发者动态定制初始仿真状态。用户通过简单的文本文件定义对象及其属性，包括组件与子组件间关系。开发者既可直接在EDL文件定义对象和属性，也可将配置拆解成Eaagles预处理（EPP）子文件——由makeEdl批处理脚本合并为单一EDL文件。此拆分技术强大，支持配置设置复用。

example.epp \
    ( Station
        tcPriority: 0.5
        #include "io/networkSetup.epp"
        // Simulation scenario
        ownship: player1
        simulation: ( Simulation
            latitude: 37.0
            longitude: -116.0
            players: {
                player1: ( Aircraft
                    id: 101
                    type: "F-16A"
                    signature: ( SigSphere radius: 1.0 )
                    initXPos: ( NauticalMiles 0 )
                    initYPos: ( NauticalMiles 0 )
                    initAlt: ( Feet 20000 )
                    initHeading: ( Degrees 0 )
                    initVelocity: 250
                    side: blue
                )
            }
        )
    )

图10. EPP示例文件。该简易文本文件允许开发者指定可复用的蜂群配置。定义中通过"#include"语法引入来自networkSetup.epp的网络设置，定义了包含单个玩家实体的仿真——类型为F-16A的飞机构型。

图10展示的EPP文件说明了仿真树的定义方式。该树经OpenEaagles解析后，将包含三个顶层对象：Station、Simulation和Aircraft。可以看到，定义了多个属性和初始条件，如仿真原点（37.0°N，-116.0°W）、玩家ID（101）、飞机构型（F-16A）、起始偏移等。网络配置定义在单独EPP文件io目录下的networkSetup.epp中。示例中使用#include语法实现复用——“一次编写，多处使用”。有关Eaagles定义语言的完整描述，详见OpenEaagles网站文档区的Basic Package Classes Slides[26]。

2.5.4 主要方法¶

OpenEaagles的优势来自其现有构建模块。除Main类外，OpenEaagles中一个完整运行的多智能体飞行仿真不需额外源码。现有的玩家（Player）、动力学模型和系统类为开发者构建复杂大规模无人机编队模型提供了所有必需。然而，Main类须实现三个特定方法，才能将EDL文件转换为仿真树并以指定刷新率更新。开发者必须在执行仿真前实现createObj、builder和main方法。图11展示了这些方法的解析流程。

createObj方法接受一个字符串参数，若该字符串匹配某定义对象名，则创建该对象实例并返回给解析器。随后，解析器根据EDL文件中通过对象类定义的“槽”应用属性。createObj方法使开发者能精细控制可供解析的对象及解析器如何实例化它们。

接着，开发者通过传入createObj方法及EDL文件名给解析器，实现builder方法。解析器返回仿真树的Station对象指针，builder方法将其传给main方法。最后，开发者实现main方法，按需循环执行仿真更新。对于HIL仿真，该方法必须实时运行，定期同步系统时钟，并以硬件嵌入式系统要求的刷新率更新。main方法中的逻辑应考虑等待或延迟，以将“仿真时间”与“实时”对齐。

图11. Eaagles定义语言解析。1）批处理脚本将Eaagles预处理文件（.epp）合并为单一的EDL文件。2）Main类的builder方法调用lcParser，传入EDL文件名和Factory类的createObj方法。3）解析器利用createObj方法将EDL文件转换为仿真解析树，返回树根指针给main方法执行仿真。

2.5.5 扩展内置功能¶

OpenEaagles包含众多内置功能包，已满足多种蜂群仿真需求（见图12）。开发者可扩展这些包，实现自定义飞行器、传感器、飞行动力学和自动驾驶仪。例如，开发者可将现有的AirVehicle类子类化为UnmannedAirVehicle类，添加特定于自主飞行器的子系统，从而灵活建模不同蜂群配置。

图12. OpenEaagles包层级。白色/透明背景表示使用第三方开源工具。（最初见于[26]，作为公共领域元素复现）

与蜂群开发特别相关的三个类包括AirVehicle、Pilot和AerodynamicsModel。AirVehicle是Player的子类，包含子系统。开发者可进一步将其扩展为UAV子类，实现蜂群无人机专有功能。Pilot是提供对Player控制（如节气门位置）的通用对象。在蜂群建模中，Pilot可扩展为Autopilot子类，实现对建模飞机控制面的具体控制。AerodynamicsModel是赋予飞机构型飞行特性的AirVehicle系统，即定义AirVehicle所模拟的“机型”。开发者通过扩展AerodynamicsModel，能使用内置、第三方或自定义FDM。OpenEaagles已有JSBSim接口（JSBSimModel类扩展AerodynamicsModel），利用JSBSim提供逼真飞行建模，使用该FDM的Players将继承真实飞行行为。

2.6 小结¶

无人机蜂群展现巨大潜力。为实现该潜力，蜂群开发者需要工具，利用硬件在环技术准确建模和测试其蜂群理论、算法及控制策略。尽管先前蜂群仿真方法未能满足此需求，但它们的共性揭示了任一蜂群仿真框架所需的核心组件。此外，业余爱好者社区开发的许多工具和技术对成功蜂群仿真框架设计高度相关。仿真链实现展示了一种利用业余社区工具模拟蜂群的方案，但存在固有设计缺陷，导致可用性和模块化不足。最终，OpenEaagles作为模块化、可扩展解决方案被介绍，并被扩展用于创建具备HIL能力的蜂群仿真框架。

III. 框架设计与分析¶

选择OpenEaagles仿真框架，正是基于其良好满足前章探讨的需求。上述需求继续指导OpenEaagles的扩展，使其支持硬件在环（HIL）蜂群仿真。本章结构如下。首先定义一个蜂群仿真组件，作为蜂群开发的沙箱。接着描述OpenEaagles扩展（即所提蜂群仿真框架）。最后，框架评估部分列出假设、限制及演示的预期衡量方法，随后介绍演示所用场景。

3.1 蜂群算法部署位置¶

在扩展OpenEaagles以实现蜂群行为前，须定义蜂群算法部署空间。蜂群算法应集成于现有无人机系统，还是作为独立组件与系统接口？本节先定义封装蜂群算法的功能隔离单元，随后讨论其部署位置。

机载控制代理。 在传统无人机任务中，地面控制站（GCS）允许操作者向自动驾驶仪传递路径规划信息，指示其飞行路径（见图13）。然而，蜂群无人机特性要求自主路径规划，无需操作者介入——各无人机必须自主行动。当每架无人机配备智能代理，具备独立决策能力（即无外部干预）时，方能实现此目标。若代理具备主动（目标导向行为）、响应（应对变化）及社交能力（与其他代理交互）[46]，则被视为智能且能自主行为。本文以“机载控制代理”（OCA）称呼具备此功能的组件。

图13. 无人机任务概览。图示典型无人机任务中，GCS（此处为Mission Control）向现场无人机传递任务参数及引导信息，反过来接收任务期间采集的传感器数据。（最初见于[10]，作为公共领域元素复现）

为实现蜂群行为于仿真与真实飞机中，OCA须具备可执行线程、访问自主决策所需数据及向自动驾驶仪提供路径规划信息的能力。满足这些需求，OCA位置仅有两个合理选择：集成于带飞行管理系统（FMS）的自动驾驶仪内，或作为独立组件置于自动驾驶仪外。实现硬件在环（HIL）仿真框架时，考虑两种方式差异尤为重要。

集成式OCA。 自动驾驶仪已有传感器数据访问权并能执行代码，自然成为蜂群算法部署首选。此外，集成式OCA与自动驾驶仪使路径规划信息内部生成和通信，带来若干内在优势。

首先，自动驾驶仪和OCA常需相似的外环感知信息以完成各自功能。将二者集成于同一组件（即同一软件类）简化数据管理，避免两个独立组件间信息冗余。集成后，OCA可直接调用自动驾驶仪FMS属性与方法，避免实现组件间接口。且此方法简化了从HIL仿真向实飞测试的过渡，因为OCA已部署于自动驾驶仪硬件，无需另行实现独立硬件设备。

但从软件开发视角看，此优势伴随显著缺点。自动驾驶仪与OCA的同处导致紧耦合，降低模块化——例如更换自动驾驶仪设计或平台须重新针对新自动驾驶仪实现OCA。且集成OCA功能需深入理解自动驾驶仪实现细节。开发者不再仅与自动驾驶仪接口（即传递航点以实现航点飞行），而须修改自动驾驶仪代码库或固件（针对HIL），在不影响FMS功能情况下嵌入OCA。

此外，集成方法面临资源利用瓶颈。自动驾驶仪CPU资源有限，已有特定任务（如稳定飞行及点对点导航）。共享处理器时，自动驾驶仪与OCA竞争执行时间。计算密集型蜂群算法或占用足够CPU周期，导致FMS执行受阻，危及飞行稳定。

独立式OCA。 替代方案是将OCA功能拆分为独立组件。此法缓解集成方案弊端，因自动驾驶仪与OCA分离，不再争抢同一CPU周期。此举需封装二者功能接口，提升模块化。通过简单接口，不同OCA实现可与多种自动驾驶仪配对，无需大改动，开发者能新增蜂群算法而不影响FMS执行或学习复杂自动驾驶仪细节。

虽有一定权衡，但相对较小。以HIL仿真为例，OCA部署于专用硬件设备（如Raspberry Pi）。此时自动驾驶仪与OCA间需实现接口或通信协议。幸运的是，当前已有多种低开销高吞吐协议可满足需求。最终，本文采纳此模块化方案作为提出的实现路径。

3.2 通信流程¶

到目前为止，我们已确定了蜂群开发所需的三个具体模拟无人机系统：定义无人机飞行特性和运动的飞行动力学模型（FDM）、用于稳定飞行和导航的自动驾驶仪，以及封装蜂群算法的机载控制代理（OCA）。此外，仿真的视觉接口必须能够访问FDM生成的飞行器信息，以提供蜂群行为的三维视图。明确这些仿真组件之间的信息流，有助于定义它们如何在框架结构中协同工作。

这四个仿真组件的功能角色决定了它们的交互方式及共享信息。OCA主要负责自主决策和路径规划——基于其反应性、主动性和社交能力——需要传感和通信数据输入。自动驾驶仪的角色是为飞行器提供稳定飞行和导航的飞控信号，需要路径规划信息及飞行器测量数据的反馈循环。FDM负责随着时间推进及飞控信号输入，模拟飞行器测量数据。最后，仿真视觉接口需要飞行器测量数据。将各组件所需输入与对应输出匹配，形成蜂群行为建模所必需的反馈环和信息流。此通信流程如图14所示，并在蜂群仿真框架设计中实现。

图14. 蜂群仿真组件通信图。蜂群行为起源于OCA，并通过蜂群算法处理测量数据后形成路径规划信息。自动驾驶仪将OCA的路径信息和FDM的测量数据转化为飞控信号，构成反馈环。仿真视图通过解释FDM测量数据生成。注意，每个OCA需来自多个FDM的测量数据以支持其社交能力。

3.3 扩展OpenEaagles¶

回顾上一章，OpenEaagles支持可扩展且模块化的多实体仿真。本节描述为实现蜂群行为建模和HIL仿真所需的扩展。

3.3.1 启用蜂群行为¶

如前所述，自动驾驶仪提供稳定飞行及点对点导航，OCA负责自主决策。但它们如何协同实现蜂群行为？在蜂群中，嵌入每架模拟无人机的OCA智能执行动态路径规划。这意味着无人机的目标路径会根据OCA的主动性、反应性和社交能力不断变化。传递此动态路径信息给自动驾驶仪的媒介是指向矢量，该矢量转化为一组航点。换言之，自动驾驶仪能自主导航预设航点，OCA通过动态更新这些航点，掌控自动驾驶仪导航方向。此外，因路径不断变化，自动驾驶仪只需跟踪单个动态航点，如“追逐手中的胡萝卜”。利用此动态航点跟踪（DWF）技术，OCA控制自动驾驶仪，实现蜂群行为。

在OpenEaagles中，自动驾驶仪和OCA均为无人机玩家实体的子系统。为支持DWF，自动驾驶仪类须实现设置和更新动态航点的方法，因此需要一个顶层抽象类包含这些方法。该类强制所有自动驾驶仪子类实现DWF，同时允许在基类层面自定义自动驾驶仪设计，保持模块化。图15展示了支持蜂群行为模拟的无人机三大子系统（FDM、OCA、自动驾驶仪）。FDM模拟飞机，接收飞控输入并产生模拟遥测数据。OCA包含实现智能自主行为的蜂群算法，蜂群开发者主要在此工作。OCA基于来自其他无人机子系统的传感输入（图中未示）及邻近无人机数据，独立决策并路径规划，实现蜂群行为。自动驾驶仪持续接收OCA传来的动态航点路径规划信息，驱动FDM通过飞控信号操纵模拟飞机向该航点飞行。

图15. 无人机系统通信图。在蜂群仿真中，OCA接收对应无人机FDM的测量数据及邻近无人机数据。OCA中的蜂群算法将数据转化为自主路径规划信息，以动态航点形式传递给自动驾驶仪。自动驾驶仪持续引导模拟飞机向动态航点飞行。该交互产生模拟蜂群行为。

3.3.2 支持硬件在环¶

为支持HIL仿真，OpenEaagles必须与硬件设备接口。为保持OpenEaagles的设计模式及系统/子系统关系，硬件设备对应的系统对象作为硬件接口，而非功能组件（图16）。此类接口管理与设备的串口连接，并负责仿真与设备间信号转换和路由。例如，自动驾驶仪硬件接口对象继续与FDM和OCA通信，但不直接将输入（遥测与航点）转为输出（飞控信号），而是以设备能识别格式传给硬件（如Pixhawk）。硬件接收输入信号执行自动驾驶功能，返回飞控命令，自动驾驶仪对象将其转换为FDM可读控制信号。

图16. 无人机系统通信图（含HIL）。实现HIL仿真时，硬件设备通过硬件接口直接向仿真提供系统功能。示例中，Pixhawk与Raspberry Pi分别提供自动驾驶仪与OCA功能，自动驾驶仪和OCA系统对象作为其硬件接口。（图中Raspberry Pi仅作示意，本文未实现OCA硬件接口。）

串口连接管理的挑战包括支持高波特率（HIL仿真所需）及与硬件设备的异步通信。HIL仿真需在特定刷新率实时执行（例如Pixhawk PX4飞行栈要求HIL_SENSOR和HIL_GPS数据包分别以50Hz和10Hz更新）。时间关键线程必须在最高刷新率对应的间隔内更新整个仿真树以提供有效数据。此外，硬件设备的发送和接收流并行且速率不同，需精细管理串口流量。

3.3.3 蜂群仿真框架¶

基于OpenEaagles扩展实现使用HIL的蜂群行为建模，如图17所示。OpenEaagles默认AirVehicle类包含指定飞行员和动力学模型的槽，因此其任意子类可包含这些系统或其子类（如自动驾驶仪和JSBSimModel）。UAV子类用于在仿真运行时唯一标识无人机实体，并实现指定OCA的附加槽。

基于此设计，UAV玩家现含支持蜂群行为的三大系统：SwarmAutopilot（自动驾驶仪）、JSBSimModel（FDM）及OnboardControlAgent（OCA）。每个自动驾驶仪类继承自SwarmAutopilot父类，后者强制实现DWF功能。SwarmAutopilot子类既可直接实现模拟自动驾驶仪功能（完全仿真），也可作为对应硬件设备接口（HIL）。通过继承SwarmAutopilot并实现对应硬件接口，开发者可集成任意硬件自动驾驶仪（如ArduPilotMega、OpenPilot、Armazila等）。同理，蜂群算法开发者可在OnboardControlAgent对象中实现蜂群行为，或提供对应硬件接口（如Raspberry Pi）供开发。本文中，PixhawkAP作为Pixhawk自动驾驶仪的硬件接口。

通过公有方法，OCA直接从FDM拉取遥测，设置自动驾驶仪的动态航点，自动驾驶仪则控制FDM的操纵面（如方向舵、操纵杆、节气门）。最终蜂群仿真框架设计实现了模块化、可扩展且准确的综合蜂群行为建模，同时支持HIL仿真，助力接近真实操作配置。

图17. 蜂群框架类图。OpenEaagles（白色部分）为所提蜂群仿真框架（灰色部分）基础。所有Player子类均有DynamicsModel和Pilot子系统。AirVehicle子类UAV用于容纳OnboardControlAgent子系统，实现蜂群行为。OCA封装蜂群行为开发，并通过推送航点实现DWF控制SwarmAutopilot。SwarmAutopilot子类实现模拟自动驾驶仪或作为HIL仿真时的硬件自动驾驶仪接口。左下角显示JSBSimModel为OpenEaagles内置接口，连接流行开源飞行动力学模型JSBSim。

3.4 框架评估¶

本节通过定性与定量分析，评估框架在HIL仿真中支持真实、模块化及可扩展无人机蜂群的能力。内容包括分析假设与限制、分析重点领域，以及用于演示框架能力的蜂群开发场景。

3.4.1 假设与限制¶

无人机通常分为固定翼与旋翼机两类，二者各有特点，设计自主行为时面临不同挑战[4]。虽理论上本文框架可扩展至两类，实际仅聚焦翼展不足10英尺的小型固定翼无人机。目前，框架不考虑天气影响如降水、风或阵风等飞行条件。框架支持多机型、多自动驾驶仪（仿真或硬件接口）及蜂群算法，但下章节演示中仅实现以下配置的蜂群行为：

飞机构型：非官方（未验证）Sig Rascal 110机型，见github.com [18]
仿真自动驾驶仪：定制软件自动驾驶仪，调试控制Rascal机型——当给定航点或航点集时，操纵杆和方向舵（节气门保持100%）提供航向和高度保持
HIL自动驾驶仪：带PX4固件（px4fmu-v2_default.px4）的Pixhawk，使用QGroundControl设备初始化/设置时提供的默认配置控制Rascal机型
蜂群算法：采用Brundage [6] 详细描述的分离、对齐和凝聚规则实现Reynolds群集行为

框架可扩展性的测量基于上述配置，但限定于本工作使用的平台——HP EliteBook 8560w，配2.20 GHz Intel® Core™ i7-2670QM CPU，16.0 GB内存，64位操作系统（Windows 7 Professional SP1）。此外，本文不涵盖通过虚拟或物理集群扩展单平台能力的方案。仿真采用多线程，7个时间关键线程和1个后台线程分布在8个CPU核上。时间关键线程处理FDM和自动驾驶仪任务，后台线程处理OCA任务。

如前所述，部分无人机配置含复杂通信系统和机载传感器套件需仿真。尽管框架可容纳这些复杂性，本文实现的概念验证未应用此类通信和传感处理，而是假设仿真实体可直接访问其他实体实例（通过句柄/指针），直接调用其公共属性。

3.4.2 定性指标¶

开发过程中能轻松增删蜂群组件对高效蜂群开发至关重要。随着蜂群组件在仿真树中被添加、修改和删除，框架将在集成便捷性、仿真组件间互操作性及蜂群行为封装性方面进行评估。

为提供高可信度的蜂群行为真实仿真，所用飞行动力学模型（如JSBSim）应准确模拟飞行器飞行特性。对飞行器性能的观察——包括巡航空速、失速速度、响应性及机动完成度——应强烈指示飞行器行为建模的准确性，最终提升对蜂群行为准确性的信心。例如，实际飞机以最大60节的平直巡航速度飞行，则模拟中同款飞机应表现类似空速。对单架飞机行为的定性分析将通过特定控制输入（如向右操纵杆）及其导致行为与预期（如向右滚转）对比完成。

3.4.3 定量指标¶

展示框架如何实现可扩展后，现可评估HIL仿真期间的质量属性。因外部硬件设备实时执行，仿真也必须实时执行，否则仿真失效。随着蜂群规模增长，仿真树规模随之扩大，实时更新和推进仿真所需操作量增加。评估HIL仿真中框架可扩展性将采用两项性能指标：1）仿真树更新时长（毫秒）以指示是否实现实时，2）最大蜂群规模（无人机数量）以指示框架总体扩展极限。

图18. 仿真运行时长示意图。三个进程均需50Hz刷新率和20ms帧。箭头表示每次仿真树更新时长。绿色更新在当前帧结束前完成，进入短暂等待至下一帧开始；红色更新未完成，导致帧延迟。

更新时长。仿真刷新率（帧率）决定了每次仿真树更新开始间隔的最短时长。若更新时长 $dt$ 小于帧时长，仿真将在当前帧结束前等待，保持与实时同步。若 $dt$ 大于帧时长，则下次更新必须等待当前更新完成，导致仿真逐渐脱离实时。

图18展示三种进程示例。进程A每帧内均完成仿真树更新，故每次更新后进入等待。进程B第二次更新超时，但随后更新足够快，仿真恢复实时执行。进程C所有更新均超时，累积影响使仿真远离实时。

图19. 性能示例图。该频率分布图显示了50Hz、约1秒仿真中各更新的等待时间。大部分更新时长为14~16ms，表明仿真实时执行，但处理器利用率较高（时长接近20ms表示高利用率，接近0ms表示低利用率，预留更多蜂群无人机仿真空间）。

本文演示的仿真通过记录前10分钟每次仿真树更新时长评估实时执行能力。更新时长取毫秒向上取整（例如2.0324ms向上为3ms），并绘制为频率分布图。仿真更新时长的形状和位置能强烈反映仿真性能。图19为示例，显示50Hz帧率、约1秒总时长仿真中50次更新时长分布，大部分时长集中于14至16ms。一次更新持续完整刷新周期（20ms），另有4次超时，表明这些更新期间未达实时。

50 Hz 的帧率（即 20 ms 的帧时长）用于满足本文所用硬件设备的需求——Pixhawk 自动驾驶仪要求在 HIL 仿真期间至少以 50 Hz 频率接收测量数据流。因此，更新时长小于或等于 20 ms 的情况下，视为实现了实时执行。此外，由于部分超过 20 ms 的更新仍可恢复（如图18中进程B的第二次更新），将对实时更新比例进行监控。具体地，实时执行百分比 $P_{\mathrm{rt}}$ 计算公式为： $$ P_{\mathrm{rt}} = \frac{n_{rt}}{n_{\text{total}}} \tag{1} $$

其中，$n_{rt}$ 表示持续时间不超过 20 ms 的更新次数，$n_{\text{total}}$ 为被评估的更新总次数。以图19为例，$P_{\mathrm{rt}} = \frac{46}{50} = 92.0%$。本研究中，$P_{\mathrm{rt}} \geq 90%$ 视为最佳，$90% > P_{\mathrm{rt}} \geq 70%$ 视为可接受，$P_{\mathrm{rt}} < 70%$ 视为不可接受。

最大蜂群规模。 框架的可扩展性最终通过确定在满足上述 $P_{\mathrm{rt}}$ 标准下的最大蜂群规模来评估。同时，比较纯仿真蜂群（仅用仿真自动驾驶仪）与完全配置为 HIL 的蜂群（仅用 Pixhawk 自动驾驶仪）的可扩展性差异，揭示仿真自动驾驶仪与硬件接口数据流处理的资源需求差异。

3.4.4 蜂群开发场景¶

下述场景用于演示蜂群仿真框架的能力与限制：假设你是一名蜂群开发者，想了解基于 Reynolds 群集规则编程的无人机蜂群的行为。具体来说，你想知道该蜂群会如何与三架有人驾驶飞机交互——它们会合并为紧密编队并随机漂移吗？会分裂为较小编队，分别跟随三架有人机吗？还是会相互碰撞坠落？

下一章将详细演示开发者如何应用本框架回答上述问题。共展示四个演示，逐步扩展以展示框架能力与限制。第一演示介绍群集算法，并展示如何在单架无人机的 OCA 中实现。第二演示基于第一演示，将群集算法应用于多架无人机，增加蜂群规模直至达到上限（即处理器无法在 20 ms 刷新周期内完成仿真树更新，假设实时刷新率为 50 Hz）。第三演示引入单个 Pixhawk 自动驾驶仪，实现 HIL 仿真。最后第四演示将 HIL 扩展至多设备，增加设备数量至上限。

本场景构成下一章实验域。三架导航（非蜂群）无人机作为“有人机”，在10个共同航点间连续飞行三条不同航线。航点分布于 4.5 × 3.4 海里矩形区域，不同航点高程在 MSL 13700 至 14300 英尺（图20）。三架导航无人机分别标为 N1、N2 和 N3，飞行轨迹见图21。基于 Reynolds 规则的蜂群无人机被添加进环境并监控。

框架演示利用上述场景验证 OCA 蜂群开发沙箱，使开发者可在高度自定义配置中应用和测试蜂群算法，高可信度保证结果蜂群行为能转化为真实飞行，从而在无风险真实飞机的情况下验证或否定蜂群控制策略。相关代码见：https://github.com/derekworth/SwarmSim 。

图20. 场景共同航点域。每次仿真包含 10 个共同航点，分布于约 20 平方海里区域，原点位于 WP10 之下，约为 $39.0084648^{\circ} \mathrm{N},-104.8887177^{\circ} \mathrm{W}$，海拔 0 英尺 MSL。

图21. 无人机路径。导航模式下的无人机重复飞行各自预编程路径，途经 10 个共同航点；蜂群无人机则依据 Reynolds 群集规则及邻近无人机信息决定路径。

飞行动力学模型。前述概念验证所用 FDM 为 JSBSim，采用 XML 定义的 Sig Rascal 110 ARF 机型（图22）——“基于 FlightGear 中的 Rascal110，调整用于 ArduPilot 测试系统”[18]。虽然 JSBSim 几乎支持任意机型，Sig Rascal 选为示范机型因其为典型机型，广泛应用于业余和无人机社区。该机属于小型固定翼无人机类别，单螺旋桨，传统控制面（副翼、方向舵、电梯），翼展 9.17 英尺。

图22. Sig Rascal 110 ARF 模型。

SIMDIS。 为查看开发中蜂群行为的动态交互，使用分布式交互仿真（DIS），通过 OpenEaagles 网络类 DisNetIO 配置，广播 DIS 包至本地主机环回网络接口。SIMDIS™ 软件工具截获并解析此类包，提供仿真数据的三维交互图形和视频显示。图23展示与上述场景相关的主要工具。SIMDIS 是本文所有演示的视觉接口。为可视化起见，SIMDIS 中无人机显示为 MQ-1 Predator，因图标模型有限，但不影响飞行特性，飞行由 Sig Rascal 110 FDM 定义（即飞行如 Sig Rascal，但外观如 Predator）。

图23. SIMDIS 概览。SIMDIS 截获并解释仿真广播的 DIS 包。左侧“测距工具”提供多实体间距离信息（如高度差、斜距等）；右侧“超级表单”支持视图定制（添加/移除标签、数据表、本地网格等）及聚焦特定实体。主窗口支持点选交互，仿真运行时可自由平移、俯仰和缩放视图。

3.5 小结¶

本章展示了如何扩展 OpenEaagles 以使用硬件在环技术模拟无人机蜂群，并介绍了下章用于评估所提框架能力与限制的蜂群开发场景。

IV. 设计演示与结果¶

本章呈现四个演示，以突出所提蜂群仿真框架的能力与局限。每个演示包含设置与实现期间及之后的观察。针对每个演示，均进行定性分析（框架的重用性、可用性与模块化观察）与定量分析（评估扩展性的性能测量）。

4.1 应用 Reynolds 群集规则¶

本演示介绍并在机载控制代理（OCA）中实现 Brundage [6] 详述的简单 Reynolds 群集规则（分离、对齐与凝聚），以提供基础蜂群行为，并展示蜂群开发在 OCA 中的封装。实现一个可见 Reynolds 向量的单蜂群无人机及三架非蜂群无人机。

4.1.1 设置¶

自动驾驶仪。 本演示仅用仿真自动驾驶仪测试基于 Reynolds 规则的蜂群行为。仿真自动驾驶仪类（SimAP）继承 SwarmAutopilot 以支持动态航点跟踪（DWF），采用比例-积分-微分（PID）增益控制逻辑生成带恒定最大节气门的滚转、俯仰和偏航命令。具体地，仿真自动驾驶仪利用滚转和偏航控制引导飞机朝下一个航点航向飞行，利用俯仰控制实现航点高度。PID 增益可调并在 Eaagles 定义语言（EDL）文件中指定，针对 Sig Rascal 110 机型调优以确保稳定飞行与导航。默认 OpenEaagles Navigation 类提供航向信息及航线修正。三架“有人驾驶”（非蜂群）无人机编程使用10个共同航点，按顺序循环飞行。

Reynolds 向量计算。 蜂群算法（即 Reynolds 规则）驻留在 OCA。对齐和凝聚向量驱使蜂群无人机聚拢，分离向量防止碰撞（见图24）。OCA 通过对周围无人机速度向量和位置向量分别取平均，计算对齐向量（$vect_A$）和凝聚向量（$vect_C$）；通过对预定义分离距离内周围无人机位置向量取反后取平均，计算分离向量（$vect_S$）。设 $\vec{p}$ 为位置向量，$\overrightarrow{p_{i}}$ 为原点无人机指向邻近无人机的向量，$n$ 为预定义范围内邻近无人机数量，$DS$ 为设定分离距离，本文均设为 1000 米，计算如下：

\[ \vec{p}_i = \vec{p}_{\text{uav}} - \vec{p}_{\text{neighbor}_i} \tag{2} \]

\[ vect_S = \frac{\sum_{i=1}^n \vec{p}_i \times \left(\frac{DS}{\|\vec{p}_i\|}\right)^2}{n} \tag{3} \]

动态航点向量（$vect_X$）通过将三向量乘以相应缩放因子后求和计算。本文使用的缩放因子分别为：分离 0.5，对齐 10.0，凝聚 1.0。最终将动态航点向量直接转换为航点（即相对于蜂群无人机当前位置的纬度、经度和高度偏移），传递给自动驾驶仪实现自主导航。为向量可视化，向仿真树中添加四个“虚拟”玩家实体，其位置由 OCA 更新，对应四个向量。OCA 每次仿真树更新时重新计算向量，实现 Reynolds 群集规则的平滑连续可视化。

图24. Reynolds 群集规则。分离使局部群体成员间保持距离，避免拥挤；对齐使成员朝向局部群体的平均航向；凝聚使成员向局部群体的平均位置移动。（最初见于[38]，作为公共领域元素复现）

4.1.2 观察¶

仿真准确性。自动驾驶仪设计与调试过程中，定性分析表明飞控输入对 Sig Rascal FDM 反应准确且灵敏。预设飞控输入诱发特定机动，模拟无人机表现符合预期，增强了对 FDM 准确性的信心。图25展示部分机动效果。

图25. 飞行机动。多种机动用于测试 Sig Rascal 110 FDM 的偏航、俯仰、滚转和节气门控制的准确性和响应性。

质量属性。确立 UAV、OnboardControlAgent 和 SwarmAutopilot 类后，框架表现出良好可用性。SimAP（继承自 SwarmAutopilot）包含三方法对应飞机的滚转、俯仰和偏航控制（节气门恒定 100%）。OCA 通过调用继承自 SwarmAutopilot 的 setWaypoint 方法与 SimAP 交互，且自身包含三个方法对应 Reynolds 三向量，轻松封装蜂群算法的开发与实现。单一自动驾驶仪类（SimAP）能无修改整合于导航和蜂群无人机，证明了代码重用性。

蜂群行为。仿真显示 Reynolds 向量及对应动态航点。图26标注各向量（黑箭头）。分离向量指向唯一处于分离距离内的无人机 N2 反方向。对齐向量指向三架导航无人机的平均飞行方向。凝聚向量指向三架导航无人机的平均位置。动态航点向量为三缩放 Reynolds 向量之和。向量随仿真刷新周期更新，呈现平滑连续轨迹，残迹如图所示。为演示效果，OCA 刷新率设为较高值，后续演示中将使用更低刷新率。正如预期，蜂群无人机持续“追逐”动态航点 vect_X，展示 OCA 对自动驾驶仪的控制能力。

图26. 模拟 Reynolds 向量。分离向量（左上）表示分离范围内周围无人机的排斥“力”（仅无人机 N2）。对齐向量（右上）表示周围无人机的平均速度向量。凝聚向量（左下）指向周围无人机的平均位置。动态航点向量（右下）由三者相加得出。

性能分析。单架蜂群无人机与三架导航无人机的 10 分钟仿真中，记录了 30,000 次更新（即每 20 ms 一次）。图27显示仿真更新时长的频率分布，$P_{\mathrm{rt}}$ 达 100%，大多数更新时长约为 4 ms，表明资源利用率低，具备容纳更多蜂群无人机的能力。

图27. 性能图——单架蜂群无人机。展示了单蜂群无人机与三导航无人机（仅仿真自动驾驶仪）10分钟仿真中每次仿真树更新后的时长记录。

4.2 使用仿真自动驾驶仪的无人机蜂群¶

本演示基于前一演示，增加蜂群无人机数量，以确定支持实时执行的最大蜂群规模（仅使用仿真自动驾驶仪）。

4.2.1 设置¶

保留前演示中无人机子系统（OnboardControlAgent 和 SimAP）及三架“有人机”配置（10个共同航点导航）。移除四个表示动态航点和 Reynolds 向量的“虚拟”玩家实体。蜂群无人机随机分布于场景原点两海里范围内。逐步增加蜂群无人机数量，直至达到实时执行的最大规模。鉴于动态航点计算中点对点速度与位置向量查询预计呈多项式增长 $O(n^2)$，OCA 刷新率从先前不必要的 50 Hz 降至 0.2 Hz，以更准确测量增加无人机数的影响。

4.2.2 观察¶

蜂群规模增加导致更新时长逐步增长，最终出现落后于实时执行。表3列出了不同蜂群规模的 10 分钟仿真中实时执行百分比 $P_{\mathrm{rt}}$，图28显示对应性能（通过记录的更新时长）。可接受的最大蜂群规模为 64 架蜂群无人机（图29）。尽管实时执行限制了规模，超大蜂群仍可在非实时下准确模拟。图30展示了一个运行速度约为实时五分之一的大规模蜂群行为。

表3. 实时执行百分比

蜂群规模	$P_{\mathrm{rt}}$
1	$100.0%$
10	$100.0%$
20	$100.0%$
30	$100.0%$
40	$100.0%$
50	$99.9%$
60	$97.3%$
61	$91.5%$
62	$78.5%$
63	$74.1%$
64	$74.4%$
65	$67.3%$
66	$52.0%$
67	$30.4%$
70	$21.8%$

图28. 蜂群规模性能比较。各仿真均持续 10 分钟。更新时长记录中蓝色条代表在 20 ms 帧内完成（即实时执行），红色条表示超时（更新延迟）。

图29. 实时蜂群。蜂群规模逐步增加，最终达到最大实时执行规模 64 架（右下图所示）。

图30. 大规模蜂群。随机布置于两海里半径内的 240 架蜂群无人机先合并（左上），最终形成紧凑球形编队（右下），在无碰撞情况下徘徊于三架“有人机”附近。

4.3 应用硬件在环仿真¶

本演示将前述纯仿真自动驾驶仪的蜂群切换为硬件自动驾驶仪集成仿真（即硬件在环，HIL）。具体实现了 Pixhawk 自动驾驶仪平台的硬件接口 PixhawkAP，使其将来自飞行动力学模型（FDM）的模拟无人机遥测信息传递给 Pixhawk，并接收返回的飞控指令反馈给 FDM。同时，PixhawkAP 也将机载控制代理（OCA）生成的动态航点更新发送给 Pixhawk。蜂群无人机的 SimAP 被 PixhawkAP 替换，导航无人机配置保持不变。蜂群无人机启用动态航点和 Reynolds 向量的可视化。

4.3.1 设置¶

Pixhawk 硬件在环准备。 在集成 Pixhawk 进行 HIL 仿真前，使用 QGroundControl v2.3.0 安装了 px4fmu-v2_default.px4 飞控软件包。QGroundControl 还作为 FlightGear v3.4.0（同一 Sig Rascal 110 FDM）与 Pixhawk 自动驾驶仪之间的 HIL 接口用于参数调试。为提高蜂群飞行稳定性，将正俯仰角限制参数 FW_P_LIM_MAX 从默认 45.0 调整为 15.0，最大正负俯仰速率参数 FW_P_RMAX_POS 和 FW_P_RMAX_NEG 从默认 60.0 调整为 10.0，其他参数保持默认。Pixhawk 在模拟飞行前通过 QGroundControl 解锁并设置为自动模式，基模式设置为 189（启用 HIL、稳定、引导、自动及自定义模式；安全开关解锁；测试和手动输入禁用）。Pixhawk 的安全开关必须安装并切换至常亮红灯状态。最终硬件设置见图31。

图31. Pixhawk 硬件设置。单个 Pixhawk 自动驾驶仪通过 USB（COM5端口）连接到仿真系统。安全开关（伸缩线末端按钮）在安全解除时常亮红灯。多色 LED 飞行状态指示灯（图中覆盖黄色胶带）常亮绿灯表示系统已解锁、获得 GPS 定位且准备就绪。接收航点时绿灯闪烁，其他灯光模式表示错误状态。

为测试 Pixhawk 支持动态航点跟踪（DWF），在飞行中途向 Pixhawk 程序化单个航点并定期更新（图32）。Pixhawk 能如预期动态追踪更新的航点，验证了其在蜂群场景中的实用性。本演示及后续演示中，所有 Pixhawk HIL 模式初始化均通过 QGroundControl 与 FlightGear 实例完成。建立 DWF HIL 仿真后，Pixhawk 从 QGroundControl 断开，接入基于 PixhawkAP 的蜂群仿真框架硬件接口。

硬件需求。Pixhawk HIL 集成需通过 USB 串口连接，使用 MAVLink 协议双向通讯，完成 Pixhawk 与仿真（FDM 和 OCA）之间的遥测与航点数据传输。Pixhawk 串口连接使用 CSerial API [2] 实现。MAVLink 通用消息库 C++ 版本 [31] 支持消息编解码。Pixhawk MAVLink 消息需求详见 https://pixhawk.ethz.ch/mavlink/ 指导PixhawkAP 类的数据转换逻辑开发。

图32. 利用 QGroundControl 实现动态航点跟踪。QGroundControl 作为仿真（左侧 FlightGear）与 Pixhawk 硬件自动驾驶仪之间的接口。黄色圆圈表示动态航点更新，黄色箭头（右上起）显示更新顺序。红色高亮线为无人机实际飞行路径。

时间同步。表4 汇总了 HIL 仿真期间 MAVLink 消息流（从仿真角度）及其消息率与大小。Pixhawk 需要稳定的 HIL_SENSOR 和 HIL_GPS MAVLink 消息分别以 50 Hz 和 10 Hz 频率发送有效测量数据流，同时需要 1 Hz 的 HEARTBEAT 消息。为实时满足各消息频率，PixhawkAP 将其与计算机系统时钟同步。

表4. HIL MAVLink 消息流

消息 ID	消息类型	方向	大小（字节）	频率
0	HEARTBEAT	双向	17	1 Hz
39	MISSION_ITEM	发送	45	按需
40	MISSION_REQUEST	接收	12	按需
44	MISSION_COUNT	发送	12	按需
46	MISSION_ITEM_REACHED	接收	10	按需
47	MISSION_ACK	接收	11	按需
91	HIL_CONTROLS	接收	50	37 Hz
107	HIL_SENSOR	发送	72	50 Hz
113	HIL_GPS	发送	44	10 Hz
253	STATUSTEXT	接收	59	按需

数据缓冲。 由于 CSerial API 不支持中断，采用轮询方式以 128 字节块读取串口缓冲区数据。具体而言，每个仿真帧周期内，PixhawkAP 接口查询串口缓冲区中等待字节数；若超过 128 字节，进入循环持续读取，单次拉取 128 字节，直至缓冲区剩余不足 128 字节时退出循环，继续处理当前帧剩余的时序关键任务。只要 PixhawkAP 读取速度快于 Pixhawk 写入速率，即不会丢失字节。航点使用航点协议编程，详见 http://qgroundcontrol.org/mavlink/waypoint_protocol。

4.3.2 观察结果¶

质量属性。使用 Pixhawk 自动驾驶仪进行动态航点跟踪（DWF）不需要开发者熟悉其代码实现，而只需理解其行为方式。换言之，开发者只需了解 Pixhawk “做什么”，而非“如何做”。这种实现细节的封装极大简化了其在硬件在环仿真中的集成，同时提升了可用性和模块化。在此过程中，DWF 依赖于航点（由 OCA 生成，蜂群开发在此进行）和测量数据（由 FDM 生成）与控制信号（由 Pixhawk 生成）之间的交换。例如，Pixhawk 在收到包含加速度、陀螺仪、磁力计、气压、温度、位置、速度及地面航向测量的 HIL_SENSOR 和 HIL_GPS 消息（HIL 模式下）后，才会发送包含滚转、俯仰、偏航及油门控制的 HIL_CONTROLS 消息，进而自主驱动模拟飞行器朝向由 MISSION_ITEM 消息指定的航点（经纬度及高度）。

然而，与 Pixhawk 的交互需要深入了解其通讯协议。PixhawkAP 接口必须准确读取并转换来自 FDM 的测量数据和 OCA 的航点信息为 Pixhawk 能理解的 MAVLink 消息，否则 Pixhawk 会发出异常或无效的控制信号。实现仿真与 Pixhawk 之间准确数据转换，详尽的 API 文档至关重要，文档不足会影响开发效率。幸运的是，MAVLink 通用消息集提供了必要的消息格式细节，保证仿真状态信息准确传输至 Pixhawk 并接收其控制信号。

性能分析。更新时长分析显示 HIL 仿真保持了实时执行（图33）。然而，单个由 Pixhawk 自动驾驶仪驱动的蜂群无人机仿真，其更新时长平均值与由模拟自动驾驶仪驱动的 38 架蜂群无人机相当，表明切换至 HIL 仿真时可扩展性大幅降低，主要原因是生成和发送 HIL_SENSOR 与 HIL_GPS 消息时，仿真到 MAVLink 数据转换的高频率开销。

图33. 性能图 - 单架蜂群无人机（HIL）。该图展示了一次 10 分钟仿真中，包含一架集成 Pixhawk 自动驾驶仪（HIL 仿真）和三架使用模拟自动驾驶仪的导航无人机的更新时长。两个局部峰值中较小的峰值（约 17 ms）显示了在主刷新周期外资源利用率的周期性升高，即 10 Hz 频率的 HIL_GPS MAVLink 消息生成与传输。

为了给仿真提供控制信号（即 HIL_CONTROLS），Pixhawk 需要以较高频率接收准确的测量数据流（HIL_SENSOR 50 Hz，HIL_GPS 10 Hz）。每条 HIL_SENSOR 消息生成包含大量磁力计计算及气压和温度转换的乘法运算。sendHilSensor 方法调用前后时间戳测得该过程（包括从 FDM 拉取数据、转换为 MAVLink 消息并通过串口发送给 Pixhawk）约需 11 ms。同理，HIL_GPS 消息生成涉及多个乘法运算及外部方法调用，sendHilGps 方法调用前后时间戳表明生成并发送每条 HIL_GPS 消息约需 7 ms。

图33 中显示两个峰值——11 ms 处的大峰和约 17 ms 处的小峰。平均等待时间从使用模拟自动驾驶仪到集成 Pixhawk 的 HIL 仿真显著增加（由大峰体现），这是因为每刷新周期都会生成并发送一条 HIL_SENSOR 消息；而小峰源于每 50 Hz 帧率外的周期性（10 Hz）资源使用峰值，即每隔五帧生成并发送一条 HIL_GPS 消息（约耗时 7 ms）叠加在 HIL_SENSOR 消息上。

图34. HIL 仿真中的 Reynolds 向量。Pixhawk 自动驾驶仪为蜂群无人机 P1 的 FDM 提供飞控信号，驱动其持续追踪动态航点（由 OCA 每五秒更新一次）。红线表示 P1 的瞬时航向。

行为表现。由于 PixhawkAP 继承自 SwarmAutopilot，故其可无缝替代蜂群无人机（重新命名为 P1）中的 SimAP。当 OCA 通过 setWaypoint 方法设置动态航点时，PixhawkAP 通过航点协议将该航点经 USB 转发至 Pixhawk。测量数据与控制信号的交互如前述。图34 展示了采用该蜂群仿真框架集成 Pixhawk 自动驾驶仪的仿真结果——P1 类似于首次演示中的 S1，无间断追踪 vect_X，验证了由机载控制代理主导的硬件在环仿真成功实现。

图35. 多 Pixhawk 硬件设置。图中笔记本电脑（右侧）为本论文全部实验的平台。多个 Pixhawk（左侧）通过 USB 2.0 集线器（中央上方）连接到笔记本电脑的 USB 2.0 端口。

4.4 配备硬件自动驾驶仪的无人机蜂群¶

本次最终演示将 HIL 仿真扩展至多个集成 Pixhawk 自动驾驶仪的蜂群无人机。逐步增加蜂群无人机数量，直至达到最大蜂群规模（即满足可接受 $P_{\mathrm{rt}}$ 指标的最大规模）。

4.4.1 设置¶

沿用单机 HIL 演示的设置，移除动态航点及 Reynolds 向量可视化。将前演示参数复制到新增 Pixhawk 自动驾驶仪中。各 Pixhawk 通过 QGroundControl 分别初始化 HIL 模式。所有 Pixhawk 通过 USB 2.0（图35）连接，自动分配虚拟 COM 端口。PixhawkAP 接口与对应 Pixhawk 自动驾驶仪的 COM 端口映射通过 EDL 文件定义。蜂群无人机随机布置于场景原点半径两海里范围内。

图36. 蜂群规模性能比较（HIL）。随着 Pixhawk 自动驾驶仪数量增加，仿真性能线性下降。

4.4.2 观察结果¶

性能分析。图36 显示最多六架蜂群无人机参与 HIL 仿真时的更新时长分布，表5 列出相应的 $P_{\mathrm{rt}}$ 值。最多四架蜂群无人机同时与 Pixhawk 自动驾驶仪接口时，实时执行率处于可接受区间。

表5. 实时执行率（HIL）

蜂群规模	$P_{\mathrm{rt}}$
1	$94.3 %$
2	$86.7 %$
3	$80.5 %$
4	$74.9 %$
5	$54.8 %$
6	$46.1 %$

行为表现。不同规模的蜂群行为与仅使用模拟自动驾驶仪时相似。无人机合并形成紧凑编队，在共同航点区内于三架导航无人机附近盘旋。图37 展示了不同蜂群规模下的协调行为。尽管最大可接受实时率的蜂群规模仅为四架，五架和六架蜂群亦表现出稳定的 Reynolds 编队行为。

图37. HIL 仿真中的蜂群行为。红色高亮的蜂群无人机由 Pixhawk 自动驾驶仪驱动，其行为与第二次演示中由模拟自动驾驶仪驱动的蜂群无人机相似。

4.5 总结¶

本章通过四个演示阶段逐步展示了利用所提蜂群仿真框架进行蜂群行为开发和建模的全过程。以简单的 Reynolds 编队规则作为蜂群算法，其在机载控制代理（OCA）中的实现展示了 OCA 封装配合动态航点跟踪（DWF）如何促进蜂群行为开发。能够在不影响框架内其他组件或交互的前提下，自由添加、删除或替换不同组件（如将 SimAP 替换为 PixhawkAP）体现了框架的高模块化。此外，该框架成功支持了 61 架使用纯模拟自动驾驶仪的蜂群无人机以及 4 架集成 Pixhawk 硬件自动驾驶仪的蜂群无人机的实时同步仿真。

V. 结论与未来工作¶

本文提出了对 OpenEaagles 仿真框架的扩展，使其能够在仿真中通过硬件在环（HIL）技术实现可扩展、模块化且逼真的无人机蜂群的测试与开发。OpenEaagles 的仿真树结构促进了蜂群组件集成的高模块化与可扩展性。如第四章所示，机载控制代理（OCA）配合动态航点跟踪（DWF）促进了蜂群开发的封装，实现了一个“沙箱”，使开发者能够先在此环境中实现和测试蜂群算法及控制策略，随后将其应用于真实飞行。此外，JSBSim 这一已经集成于 OpenEaagles 的可信飞行动力学模型（FDM）为蜂群或无人机行为的真实过渡提供了高度信心。

然而，当引入硬件设备以实现 HIL 仿真时，由于生成和发送 HIL_SENSOR 与 HIL_GPS MAVLink 消息所需的处理开销，最大蜂群规模仅为四架无人机。相比之下，纯模拟自动驾驶仪时的最大蜂群规模要大得多，表明框架本身具备高可扩展性。且当不受实时约束时，框架理论上支持无限蜂群规模。为实现 HIL 仿真的高可扩展性，存在多种潜在优化手段。例如，可在仿真之外实现一个高速专用的中间转换器，该转换器输入仿真产生的原始数据流，输出 Pixhawk 所需的 MAVLink 消息（如 HIL_SENSOR 与 HIL_GPS）。此转换器仅需接收仿真中的原始 FDM 数据报文流，生成耗时极低，从而避免了在仿真内执行昂贵数据转换的需求。

此外，通过合理的线程优化和任务管理，可将这些转换任务高效分配至多个 CPU 核心并行执行，提升性能。尽管 OpenEaagles 默认的线程管理方案简单易用且在多数情况下有效，但针对该特定场景，定制化线程管理可能带来性能提升。

OpenEaagles 架构内置对分布式仿真架构（如 DIS、HLA 和 TENA）的支持，允许跨网络共享仿真视图，亦可将多个仿真实例桥接成更大的分布式系统，具备将蜂群仿真框架扩展为分布式系统的潜力。设想多个本论文实现的仿真实例网络联通，形成更大规模的 HIL 仿真集群节点。五个节点即可形成至少 20 架由 Pixhawk 自动驾驶仪驱动的蜂群。

未来研究方向之一是为 OCA 实现硬件接口，使得每个硬件 OCA 可通过无线连接等方式在仿真外部与其他 UAV 的 OCA 交互，模拟真实 UAV 点对点通信。将此类交互迁移出仿真环境，不仅提升实际飞行测试的信心，也减轻仿真计算负担，从而释放资源以提升蜂群规模。

所提框架的高度模块化结构还支持实现蜂群控制站（SCS），允许开发者在任务中途向仿真蜂群中的 OCA 注入参数和控制算法，从而超越传统地对单架 UAV 进行个别控制，转而作为一个整体有机实体操控整个蜂群。具备无限可配置的玩家、系统与子系统，以及可定制的 I/O 接口和图形库，框架拓展空间广阔。

5.1 最后致辞¶

随着技术的不断进步，无人机蜂群正日益成为现实并与实际应用紧密相关。过去十五年间，蜂群应用、理论与控制策略取得了重大进展。但因高昂的实现成本和受限的空域管制，多数蜂群行为仍未得到实现。本文表明，一个优秀的蜂群仿真框架能够突破这些限制，实现蜂群行为的开发与验证。总结而言，蜂群开发既困难又昂贵，若无高效且经济的仿真框架验证蜂群行为，无人机蜂群的应用将仅停留于理论层面。

Bibliography¶

F. A. Administration. Unmanned aircraft systems. Retrieved Online at URL: https://www.faa.gov/uas/, August 2015.
T. Archer and R. Leinecker. Cserial - a c++ class for serial communications. Retrieved Online at URL http://www.codeguru. com/cpp/i-n/network/serialcommunications/article.php/c2503/ CSerial--A-C-Class-for-Serial-Communications.htm, August 1999.
P. Barooaha, G. E. Collinsb, and J. P. Hespanha. Geotrack: Bio-inspired global video tracking by networks of unmanned aircraft systems. In N. F. F. Jr. and V. S. Swaminathan, editors, Bio-Inspired/Biomimetic Sensor Technologies and Applications, volume 7321, 2009.
R. W. Beard and T. W. McLain. Small Unmanned Aircraft: Theory and Practice. Princeton University Press, 41 William Street, Princeton, New Jersey 08540, 2012.
J. S. Berndt et al. JSBSim: An Open Source, Platform-Independent, Flight Dynamics Model in C++, 2008.
H. Brundage. Neat algorithms - flocking. Retrieved Online at URL http:// harry.me/blog/2011/02/17/neat-algorithms-flocking/, July 2015.
V. Chandhrasekaran and E. Choi. Fault tolerance system for uav using hardware in the loop simulation. In New Trends in Information Science and Service Science (NISS), 2010 4th International Conference on, pages 293-300, May 2010.
P. R. Chandler, M. Pachter, D. Swaroop, J. Fowler, J. Howlett, S. Rasmussen, C. Schumacher, and K. Nygard. Complexity in uav cooperative control. In American Control Conference, 2002. Proceedings of the 2002, volume 3, pages 1831-1836 vol.3, 2002.
H. Cheng, J. Page, and J. Olsen. Dynamic mission control for uav swarm via task stimulus approach. American Journal of Intelligent Systems, 2(7):177-183, 2012.
T. O. Computing. Uav architecture. Retrieved Online at URL http://www. twinoakscomputing.com/coredx/uv, October 2015.
J. J. Corner. Swarming reconnaissance using unmanned aerial vehicles in a parallel discrete event simulation. Master's thesis, Air Force Institute of Technology, Wright Patterson AFB, OH, March 2004.
R. W. Deming and L. I. Perlovsky. Concurrent multi-target localization, data association, and navigation for a swarm of flying sensors. Information Fusion, 8(3):316-330, 2007. Special Issue on Concurrent Learning and Fusion.
L. Evers, T. Dollevoet, A. Barros, and H. Monsuur. Robust uav mission planning. Annals of Operations Research, 222(1):293-315, 2014.
A. Felton-Taylor. Trial tests cost effectiveness of drone use in agriculture. Retrieved Online at URL: http://www.abc.net.au/news/2015-06-10/ drone-technology-on-australian-farms-cost-effectiveness-trial/ 6535546, June 2015.
S. Frink. Uav swarm technology emerges to perform varied applications, August 2012.
C. Fuchs, C. Borst, G. C. H. E. de Croon, M. M. R. van Paassen, and M. Mulder. An ecological approach to the supervisory control of uav swarms. International Journal of Micro Air Vehicles, 6(4):211-229, December 2014.
U. Gaerther. Uav swarm tactics: an agent-based simulation and markov process analysis. Master's thesis, Naval Postgraduate School, Monterey, CA, June 2013.
D. Gagne. Mavlink/qgroundcontrol. Retrieved Online at URL https://github. com/mavlink/qgroundcontrol/tree/master/flightgear/Aircraft, September 2015.
R. D. Garcia, L. Barnes, and M. Fields. Unmanned aircraft systems as wingmen. Journal of Defense Modeling and Simulation: Applications, Methodology, Technology, 9(1):5-15, January 2012.
P. Gaudiano, E. Bonabeau, and B. Shargel. Evolving behaviors for a swarm of unmanned air vehicles. In Swarm Intelligence Symposium, 2005. SIS 2005. Proceedings 2005 IEEE, pages 317-324, June 2005.
P. Gaudiano, B. Shargel, E. Bonabeau, and B. Clough. Control of uav swarms: What the bugs can teach us. In 2nd AIAA "Unmanned Unlimited" Conf. and Workshop & Exhibit, 2003.
H.-P. Halvorsen. Introduction to hardware-in-the-loop simulation. Technical report, Telemark University College, Postboks 203, Kjlnes ring 56, N-3901 Porsgrunn, Norway., 2011.
D. Hambling. The future of flight: Swarms will dominate the sky, July 2013.
S. Hauert, S. Leven, M. Varga, F. Ruini, A. Cangelosi, J.-C. Zufferey, and D. Floreano. Reynolds flocking in reality with fixed-wing robots: Communication range vs. maximum turning rate. In Intelligent Robots and Systems (IROS), 2011 IEEE/RSJ International Conference on, pages 5015-5020, Sept 2011.
H. Hexmoor, B. McLaughlan, and M. Baker. Swarm control in unmanned aerial vehicles. In IC-AI, pages 911-917, 2005.
D. Hodson, C. Buell, R. Suhr, D. Gehl, and L. Sines. Openeaagles simulation framework. Retrieved Online at URL http://www.openeaagles.org/, April 2015.
I. Kadar, editor. Collaborative distributed sensor management and information exchange flow control for multitarget tracking using Markov decision processes, volume 6968, 2008.
J. N. Kaiser. Effects of dynamically weighting autonomous rules in an unmanned aircraft system (uas) flocking model. Master's thesis, Air Force Institute of Technology, Wright Patterson AFB, OH, September 2014.
J. L. Lambach. Integrating uas flocking operations with formation drag reduction. Master's thesis, Air Force Institute of Technology, Wright Patterson AFB, OH, March 2014.
G. Lamont, J. Slear, and K. Melendez. Uav swarm mission planning and routing using multi-objective evolutionary algorithms. In Computational Intelligence in Multicriteria Decision Making, IEEE Symposium on, pages 10-20, April 2007.
L. Meier, D. Gagne, et al. Mavlink micro air vehicle communication protocol. Retrieved Online at URL http://qgroundcontrol.org/mavlink/start, September 2015.
D. Nowak, I. Price, and G. Lamont. Self organized uav swarm planning optimization for search and destroy using swarmfare simulation. In Simulation Conference, 2007 Winter, pages 1315-1323, Dec 2007.
S. O'Hara, M. Simon, and Q. Zhu. Towards distributed atr using subjective logic combination rules with a swarm of uavs. Proc. SPIE, 6561:65611G1-65611G10, 2007.
R. Olfati-Saber. Flocking for multi-agent dynamic systems: algorithms and theory. Automatic Control, IEEE Transactions on, 51(3):401-420, March 2006.
I. Ozkaya, R. Kazman, and M. Klein. Quality-attribute-based economic valuation of architectural patterns. Technical report, Software Engineering Institute, Carnegie Mellon, 2007.
S. Pinker et al. The American Heritage Dictionary of the English Language. Houghton Mifflin Harcourt Publishing Company, 5th edition edition, 2013.
S. Rasmussen and P. Chandler. Multiuav: a multiple uav simulation for investigation of cooperative control. In Simulation Conference, 2002. Proceedings of the Winter, volume 1, pages 869-877 vol.1, Dec 2002.
C. Reynolds. Boids. Retrieved Online at URL http://www.red3d.com/cwr/ boids/, March 2015.
T. C. Rivers. Design and integration of a flight management system for the unmanned air vehicle frog. Master's thesis, Naval Postgraduate School, Monterey, CA, December 1998.
R. S. Roberts, C. A. Kent, C. T. Cunningham, and E. D. Jones. Uav cooperation architectures for persistent sensing. Sensors, and Command, Control, Communications, and Intelligence (C3I) Technologies for Homeland Defense and Law Enforcement II, 5071:306-314, 2003.
J. C. Rubio, J. Vagners, and R. Rysdyk. Adaptive path planning for autonomous uav oceanic search missions. In AIAA 1st Intelligent Systems Technical Conferenc, 2004.
J. A. Sauter, R. S. Mathews, A. Yinger, J. S. Robinson, J. Moody, and S. Riddle. Distributed pheromone-based swarming control of unmanned air and ground vehicles for rsta. In G. R. Gerhart, D. W. Gage, and C. M. Shoemaker, editors, Proc. of SPIE, volume 6962, pages 69620C-69620C-12, 2008.
P. Scharre. Robotics on the battlefield part ii: The coming swarm. Technical report, Center for a New American Security, October 2014.
A. Sinha, A. Tsourdos, and B. White. Multi uav coordination for tracking the dispersion of a contaminant cloud in an urban region. European Journal of Control, 3(4):441-448, 2009.
M. P. . P. Team. Microsoft®Application Architecture Guide (Patterns 83 Practices). Microsoft Press, second edition edition, November 2009.
R. Vaculin and R. Neruda. Autonomous behavior of computational agents. Springer, 2005.
T. Wang. Hardware architecture. Retrieved Online at URL http:// ai.stanford.edu/~twangcat/figures/hardware_architecture.png, October 2015.
G. Warwick. Onr: Swarming uavs could overwhelm defenses cost-effectively. Aviation Week & Space Technology, April 2015.
S. Yili, Z. Ziyang, O. Chaojie, and P. Huangzhong. 3d scene simulation of uavs formation flight based on flightgear simulator. In Guidance, Navigation and Control Conference (CGNCC), 2014 IEEE Chinese, pages 1978-1982, Aug 2014.

蜂群规模	\(P_{\mathrm{rt}}\)
1	\(100.0%\)
10	\(100.0%\)
20	\(100.0%\)
30	\(100.0%\)
40	\(100.0%\)
50	\(99.9%\)
60	\(97.3%\)
61	\(91.5%\)
62	\(78.5%\)
63	\(74.1%\)
64	\(74.4%\)
65	\(67.3%\)
66	\(52.0%\)
67	\(30.4%\)
70	\(21.8%\)

蜂群规模	\(P_{\mathrm{rt}}\)
1	\(94.3 %\)
2	\(86.7 %\)
3	\(80.5 %\)
4	\(74.9 %\)
5	\(54.8 %\)
6	\(46.1 %\)