3、仿真环境搭建：MATLAB/Simulink、PX4/ArduPilot SITL、Gazebo等工具链选择与配置
飞控仿真测试的核心在于构建一个高保真、可重复、可观测的虚拟运行环境。本章聚焦于工具链的选型逻辑与配置方法，重点剖析MATLAB/Simulink、PX4/ArduPilot SITL（软件在环）以及Gazebo三者的协同关系。与单纯介绍安装步骤不同，这里更强调“如何根据故障注入目标选择正确的仿真层级”，因为不同的故障类型（如传感器噪声、执行器卡死、通信丢包）对仿真保真度的要求截然不同。我们将从工具链的架构定位出发，逐步深入到配置流程、参数调优与典型故障注入场景的落地。
上图展示了飞控仿真工具链的典型分层架构。核心要点在于：故障注入的层级决定了测试的可信度与成本。MIL阶段适合验证控制律对故障的鲁棒性算法，SITL阶段适合验证飞控软件栈对异常传感器数据的响应逻辑，而HITL阶段则用于验证真实硬件在故障下的电气行为。在课程实践中，我们通常采用“MIL快速迭代 + SITL全场景覆盖 + HITL关键用例抽检”的组合策略。
3.1 工具链选型核心原理与对比
选择仿真工具链并非追求功能最全，而是追求与故障注入目标的匹配度。MATLAB/Simulink在控制律建模与故障逻辑快速原型方面具有无可比拟的优势，其Simulink Fault Inspector工具箱可以系统化地定义故障场景并自动生成测试用例。PX4/ArduPilot SITL则直接编译运行真实的飞控固件，通过MAVLink协议与仿真环境通信，这意味着故障注入的对象是“真实运行中的飞控代码”，而非简化模型。Gazebo作为开源物理引擎，提供了刚体动力学、碰撞检测和传感器噪声模型，是连接“飞控逻辑”与“物理世界”的桥梁。
| 维度 | MATLAB/Simulink | PX4/ArduPilot SITL | Gazebo |
|---|---|---|---|
| 仿真层级 | 模型在环（MIL） | 软件在环（SITL） | 物理环境仿真 |
| 故障注入方式 | Simulink Fault Inspector / 自定义模块 | 修改传感器/执行器驱动代码或通过MAVLink外发指令 | 插件机制（如ModelPlugin）或传感器噪声参数 |
| 时间尺度 | 可加速/减速，适合蒙特卡洛 | 实时或准实时 | 实时或慢于实时（取决于场景复杂度） |
| 适用故障类型 | 控制律参数突变、逻辑错误 | 传感器数据异常、执行器输出限幅 | 物理碰撞、GPS丢星、风力干扰 |
| 配置复杂度 | 中（需熟悉Simulink模型） | 低（编译即用） | 高（需配置模型与传感器） |
在实际选型中，一个常见误区是“用Gazebo模拟一切”。Gazebo的物理引擎虽然强大，但对于飞控内部的故障（如EKF协方差异常、控制分配矩阵错误）无能为力，这些必须通过SITL或MIL层注入。反之，若只关注传感器噪声对姿态解算的影响，SITL配合脚本注入噪声即可，无需引入Gazebo的完整动力学。
3.2 环境配置与操作流程
以PX4 SITL + Gazebo为例，标准配置流程如下。首先，确保系统满足依赖要求（Ubuntu 20.04/22.04，ROS Noetic或Humble）。然后，克隆PX4源码并运行自动化安装脚本。关键步骤在于配置仿真时间同步，否则故障注入的时间戳会错乱，导致分析困难。
# 1. 克隆PX4固件
git clone --recursive https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
# 2. 运行安装脚本（仅需一次）
bash ./Tools/setup/ubuntu.sh
# 3. 构建SITL目标（以Gazebo为例）
make px4_sitl gazebo-classic
# 4. 启动仿真（默认世界）
./Tools/simulation/gazebo-classic/sitl_run.sh
配置完成后，验证环境是否正常：通过QGroundControl地面站连接至udp://:14550，观察姿态数据是否在合理范围内波动。若需注入传感器故障，推荐使用PX4的param set命令动态修改参数，例如模拟GPS丢失：
# 模拟GPS信号丢失（设置GPS故障标志）
param set COM_DISARM_LAND 1
param set GPS_FAULT_ENABLE 1
# 或者通过MAVLink发送自定义故障指令
对于MATLAB/Simulink与PX4的联合仿真，推荐使用官方支持的PX4-PSP（PX4 Support Package）。该工具包允许Simulink模型直接生成代码并部署到SITL环境中，实现MIL到SITL的无缝过渡。配置时需注意模型步长与SITL通信端口的匹配，通常设置为固定步长（如0.01s），并使用UDP或共享内存进行数据交换。
3.3 案例拆解：基于SITL的传感器故障注入与检测
本案例目标是在PX4 SITL环境中注入加速度计偏置故障，并验证飞控的故障检测与隔离（FDI）逻辑。实验环境为Ubuntu 22.04 + PX4 v1.14 + Gazebo Classic。
初始现象与目标：在悬停任务中，飞控姿态估计出现缓慢漂移，但未触发任何警告。目标是通过注入已知偏置，观察EKF（扩展卡尔曼滤波器）的残差变化，并验证故障检测阈值是否合理。
关键输入参数：加速度计偏置注入量设为0.5 m/s²（持续5秒），注入脚本通过修改SensorAccel话题的发布数据实现。EKF残差监控参数为EKF2_REQ_EFTHR（残差阈值）。
操作步骤：
- 启动SITL并进入悬停模式，记录基线数据（姿态、加速度计残差）。
- 运行Python脚本，通过MAVLink的
V2_EXTENSION消息注入偏置。 - 实时监控
ekf2_innovations话题，观察残差变化。 - 当残差超过阈值时，记录飞控是否触发“EKF variance”警告。
结果对比：注入偏置后，残差从0.02 m/s²上升至0.6 m/s²，但飞控未触发警告，因为默认阈值设置为1.0。这说明默认配置对缓慢漂移不敏感，需要根据实际飞行包线调整阈值。复盘发现，故障检测的灵敏度与阈值设置直接相关，且需结合多个传感器（如GPS速度残差）进行交叉验证，避免误报。
风险提示：在SITL中注入故障时，务必确保注入的故障信号不会导致仿真崩溃（如除零错误）。建议在注入前对信号进行范围检查，并设置自动恢复机制（如定时器），以便在测试结束后自动清除故障。
3.4 常见误区与总结复盘
在工具链配置与使用中，以下误区最为常见：
- 误区一：混淆SITL与HITL的故障注入能力。SITL无法模拟电气特性（如电源跌落、信号毛刺），这些必须依赖HITL。反之，HITL中难以模拟“理想化”的传感器噪声，因为真实传感器已包含噪声。
- 误区二：忽视时间同步。在联合仿真中，若Gazebo的仿真时间与SITL的时钟不同步，故障注入的时序会错乱，导致测试结果不可复现。解决方案是使用
use_sim_time参数强制Gazebo使用ROS的仿真时间。 - 误区三：过度依赖默认参数。PX4的默认故障检测参数是针对正常飞行优化的，在故障注入测试中往往过于保守或过于激进。建议根据测试用例动态调整
EKF2_REQ_*系列参数。