3. PX4架构与仿真原理
要真正用好 Gazebo 仿真，不能只把 PX4 当成一个“黑盒固件”烧进去。PX4 的软件栈、uORB 消息机制、SITL 仿真模式以及 Gazebo 的物理与传感器模型，共同决定了仿真中“飞控在想什么、数据从哪来、又流向哪里”。理解这条链路，才能在传感器联调时快速定位问题：是模型没发布数据，还是 uORB 话题没订阅上，抑或是物理引擎根本没算对。
一、PX4 飞控软件栈：分层与职责
PX4 采用分层架构，从下到上大致可分为四层。最底层是 硬件/驱动层，负责与真实传感器、执行机构通信；其上是 中间件层，核心就是 uORB 发布/订阅总线；再往上是 飞行控制层，包括姿态估计、位置控制、导航与混控；最上层是 应用与任务层，如 commander、navigator、mavlink 等模块。
在 SITL 模式下，硬件层被“替换”为仿真接口：传感器数据不再来自 I2C/SPI，而是由 Gazebo 通过仿真桥接注入；执行机构输出也不再驱动电调，而是变成 Gazebo 中的力与力矩。这种替换让上层控制逻辑几乎无需改动，从而保证仿真与实飞的一致性。
二、uORB 消息机制：仿真的数据总线
uORB 是 PX4 的异步发布/订阅消息中间件。每个消息类型（如 sensor_combined、vehicle_attitude、actuator_controls）都有独立的主题，发布者写入，订阅者读取，彼此不关心对方是谁。这种机制带来两个好处：一是模块可独立启停，二是仿真与实飞的数据接口完全一致。
在传感器联调中，最常用的排查手段就是查看 uORB 话题。例如用 listener 查看某话题是否有数据、频率是否正常：
pxh> listener sensor_combined
pxh> listener vehicle_gps_position
pxh> uorb top
uorb top 会实时显示各话题的发布频率，如果某个传感器话题频率为 0，说明 Gazebo 模型没有发布对应数据，或桥接插件未加载。这是仿真联调中最直接的“第一现场”。
三、SITL 仿真模式与 Gazebo 物理引擎
SITL（Software In The Loop）指飞控软件在主机上编译运行，通过仿真接口与虚拟世界交互。PX4 的 SITL 支持多种仿真后端，Gazebo 是其中最完整的一种。启动流程通常是：先启动 Gazebo 加载世界与机型模型，再启动 PX4 SITL，两者通过 gz_bridge 或 px4-gazebo 插件交换数据。
Gazebo 负责物理引擎计算：刚体动力学、碰撞、重力、空气阻力等。它按固定步长推进世界状态，并把机体位姿、速度、IMU 加速度、磁力计读数等通过仿真接口发送给 PX4。PX4 解算后输出电机转速或力矩，再回传给 Gazebo 施加到模型上，形成闭环。
四、传感器模型与联调要点
Gazebo 中的传感器模型并非“真实硬件”，而是按物理规律生成的理想或带噪声的数据源。常见模型包括 IMU、GPS、磁力计、气压计、激光雷达和相机。每个模型都有可配置参数，如噪声密度、更新频率、量程和安装位置。这些参数直接影响 PX4 的估计与控制效果。
联调时，建议按以下顺序检查：
- 确认 Gazebo 模型已加载对应传感器插件，且
sdf中<sensor>标签配置正确。 - 用
uorb top查看话题频率，确认数据是否发布。 - 用
listener查看具体数值，判断量纲、坐标系和噪声是否合理。 - 检查 PX4 参数中传感器使能与校准设置，如
SENS_IMU_MODE、EKF2_AID_MASK。 - 若数据异常，回到 Gazebo 侧检查插件加载日志与物理步长设置。
| 仿真对象 | 对应 uORB 话题 | 常见联调问题 |
|---|---|---|
| IMU | sensor_combined |
频率为 0、噪声过大、坐标系反向 |
| GPS | vehicle_gps_position |
无定位、经纬度跳变、高度异常 |
| 磁力计 | vehicle_magnetometer |
航向漂移、磁场强度不合理 |
| 气压计 | vehicle_air_data |
高度基准错误、气压值恒定 |
| 执行机构 | actuator_controls |
电机不转、推力方向错误 |
uorb top 做一次全话题扫描。这样能把“模型问题”和“飞控问题”分开定位。
五、常见误区与复盘
第一个误区是“仿真能飞，实飞就能飞”。仿真中的传感器噪声、延迟和模型误差与真实硬件差异很大，尤其是 IMU 振动和磁干扰，Gazebo 很难完全复现。第二个误区是“话题有数据就代表正确”。频率正常但量纲错误、坐标系反向的情况非常常见，必须用 listener 看数值。第三个误区是忽略仿真时钟。Gazebo 的实时因子若远小于 1，物理推进变慢，PX4 会认为传感器频率异常，导致估计器发散。
复盘时，建议把每次联调的问题记录为“现象—排查路径—根因—修复”四段式。例如：现象是“无人机起飞后立即侧翻”，排查发现 actuator_controls 输出正常但电机转向相反，根因是 Gazebo 模型中旋翼旋转方向配置错误，修复方式是调整 sdf 中电机 joint 的轴向或 PX4 混控参数。这样的记录能显著缩短下一次排障时间。
掌握 PX4 软件栈、uORB 机制、SITL 模式与 Gazebo 传感器模型之间的关系，就相当于拿到了仿真联调的“地图”。后续无论是接入新传感器、修改机型，还是调试估计器，都可以沿着这条数据闭环逐段排查，而不是盲目试错。