无人机仿真与真机开发基础：从 SITL 到实机，一篇给零基础看的学习笔记
这篇文章不是为了让你一次记住所有名词，而是先建立一张“脑内地图”：谁负责飞、谁负责想、谁负责模拟世界、谁负责看状态、它们之间怎么说话。
如果你刚开始接触 PX4、ROS 2、AirSim、QGroundControl，看见 MAVLink、DDS、uORB、Offboard 就头大，这很正常。下面我尽量用生活化的比喻和具体例子，把这些概念串起来。
1. 为什么先补“无人机系统基础”
很多人第一次搭环境时，会经历一个阶段：命令都能复制，软件也能启动，但一报错就完全不知道从哪一层查。
原因很简单：无人机开发不是一个软件，而是一整套系统。它同时包含飞控、传感器、机器人中间件、网络通信、仿真器、地面站以及真实硬件。原学习笔记的核心目标就是建立“系统层级 + 数据流 + 工具链 + 从仿真到真机的验证路径”，而不是只背安装命令。
小白类比：把无人机想成“一个会飞的机器人公司”
- PX4 像公司的“执行部门 + 小脑”：必须反应快，负责把飞机稳住。
- ROS 2 像“项目经理 + 大脑”：负责规划、识别、决策，但不直接每毫秒控制电机。
- AirSim / Gazebo 像“训练场”：不摔真机，也可以不断试错。
- QGroundControl 像“仪表盘 + 运维后台”：看状态、改参数、上传任务。
- MAVLink / DDS 像不同用途的“通信语言”。
如果先记住这几个角色，后面所有软件的关系就不会乱。
2. 一架自主无人机，从软件到硬件到底有哪些层
可以把现代自主无人机拆成四层：飞行器硬件层、飞控层、伴随计算与算法层、地面站与运维层。原笔记也是按照这个结构梳理各组件职责。
| 层级 | 典型组件 | 主要职责 | 常见工具 / 接口 |
|---|---|---|---|
| 飞行器硬件层 | 机架、电机、ESC、电池、IMU、GPS、相机、雷达 | 产生真实运动和传感器数据 | PWM、CAN、UART、I2C、SPI |
| 飞控层 | Pixhawk 等飞控 + PX4 | 状态估计、姿态/位置控制、Failsafe、任务执行 | uORB、MAVLink、uXRCE-DDS |
| 伴随计算层 | Jetson、NUC、树莓派、x86 主机 | 视觉、SLAM、路径规划、目标识别、自主决策 | ROS 2、OpenCV、PCL、CUDA |
| 地面站与运维层 | 笔记本、遥控器、数传电台 | 参数配置、任务规划、遥测、日志和调试 | QGroundControl、MAVLink、Flight Review |
一个具体例子：让无人机“看到人后飞过去”
假设你做一个目标跟踪任务：
- 相机拍到画面，这是硬件层提供原始数据。
- ROS 2 上的识别节点找到“人”的位置，这是伴随计算层在做复杂算法。
- ROS 2 不直接命令“3 号电机转 52%”，而是告诉 PX4：“目标点在前方 5 米”。
- PX4 根据当前姿态、速度和位置，实时算出四个电机应该怎么转，这是飞控层。
- QGroundControl 可以在旁边看到飞机位置、模式、电量和参数，这是地面站层。
记忆口诀：硬件负责“感受和动作”，PX4 负责“稳稳地飞”，ROS 2 负责“聪明地飞”，QGC 负责“看着它飞”。
3. 飞控、伴随计算机、地面站：三个角色不要混淆
3.1 飞控（Flight Controller）
飞控是无人机实时控制的核心。它直接连接 IMU、磁力计、气压计、GPS，以及电机和舵机等执行器。PX4 需要以很高频率稳定运行控制环，因此更强调实时性、确定性和故障保护。原笔记列出的核心职责包括状态估计、姿态/角速度控制、位置/速度控制、模式管理和 Failsafe。
小白类比：飞控像人的“小脑 + 前庭系统”
你站立时不会每次都认真思考“左腿加 2% 力、右腿减 3% 力”。身体会自动维持平衡。无人机也是一样：PX4 持续读取 IMU 等传感器，快速调整电机，让飞机保持稳定。
所以，飞控最重要的不是“聪明”，而是“快、稳、可靠”。
3.2 伴随计算机（Companion Computer）
伴随计算机不是“更高级的飞控”，而是负责计算量更大的算法，例如视觉识别、SLAM、路径规划和 AI。它常运行 Linux、ROS 2、OpenCV、深度学习模型，再把高层目标发给 PX4。常见硬件包括 Jetson、NUC、树莓派和 x86 工控机。
一个容易理解的例子
- PX4：保证飞机不会翻。
- ROS 2：判断“绕过前面的树，从右边走”。
- PX4 接到 ROS 2 的目标后，再负责把这个目标变成真正的姿态、速度和电机控制。
3.3 地面站（Ground Control Station, GCS）
QGroundControl 是 PX4 生态中常见的地面站工具，可以查看姿态、GPS、电量、飞行模式，配置参数、任务，并通过 MAVLink 与 PX4 通信。
小白类比：QGC 就像汽车仪表盘 + 4S 店电脑
平时你用它看“车速、油量、故障灯”；调试时你还可以进入参数页面修改配置、检查日志、上传任务。
4. 真机最常见的传感器与执行器基础
原笔记列出了 IMU、磁力计、气压计、GPS/RTK、相机、LiDAR、ESC 和电机等典型器件，以及振动、温漂、磁干扰、延迟、标定等常见问题。
| 器件 | 它告诉无人机什么 | 小白类比 | 真机常见坑 |
|---|---|---|---|
| IMU | 加速度、角速度 | 手机转屏时感知你把手机转了 | 振动、温漂、方向装反 |
| 磁力计 | 朝向 / 航向参考 | 指南针 | 电机、电源线产生磁干扰 |
| 气压计 | 相对高度 | 用气压变化猜楼层 | 螺旋桨气流、温度影响 |
| GPS / RTK | 全球位置、速度 | 手机地图定位 | 遮挡、多路径、城市峡谷 |
| 相机 | 图像信息 | 人的眼睛 | 曝光、延迟、标定、算力 |
| LiDAR | 距离 / 点云 | 用激光“摸”环境 | 反射率、雨雾、数据量 |
| ESC + 电机 | 产生推力 | 肌肉 + 神经驱动 | 协议、校准、供电、散热 |
为什么 IMU 和 GPS 经常一起用？
可以把 GPS 想成“隔一会儿告诉你一次绝对位置”，而 IMU 像“每时每刻感知身体怎么动”。GPS 相对慢，但长期位置不容易无限漂；IMU 很快，但只靠积分会逐渐漂移。状态估计器会把它们融合起来，取长补短。
这就是为什么真机里经常会听到 EKF（扩展卡尔曼滤波）：它不是神秘魔法，本质上是在“多种不完美传感器之间做更聪明的综合判断”。
5. 无人机仿真到底有哪些类型：SITL、HITL、SIH 与真机
PX4 官方把仿真作为真实飞行前的安全验证手段。常见方式包括 SITL、HITL、SIH、台架测试以及最终真机飞行。原笔记推荐的总体路线也是从软件仿真逐步走向真实硬件。
5.1 SITL：全部先在电脑里“演”一遍
SITL = Software In The Loop，PX4 本身也运行在电脑上。
类比：学开车前先玩高质量驾驶模拟器。
优点是成本低、出错不摔飞机、可以快速重来，非常适合算法开发和自动化测试。
5.2 HITL：飞控是真的，世界是假的
HITL = Hardware In The Loop。PX4 跑在真实 Pixhawk 上，但传感器和物理世界由仿真器提供。
类比：真的方向盘、真的汽车 ECU，但外面的道路还是模拟器。
它更适合验证真实飞控硬件、接口、时序和固件行为。
5.3 SIH：仿真世界直接塞进飞控里
SIH 可以理解为“飞控硬件内部运行一个轻量的物理模型”，不依赖复杂的外部 3D 仿真器。适合快速硬件回归和控制逻辑验证。
5.4 台架测试与真机
台架测试开始接入真实电源、传感器、通信设备和执行器，但仍处于受控环境；真机飞行则是完整系统进入真实世界。
推荐路线：SITL → HITL / SIH → 台架 → 低风险真机 → 完整任务。
“仿真里能飞”只能说明逻辑大体成立，不能证明真机一定安全。
6. 常见仿真器怎么选：AirSim、Gazebo、SIH
| 工具 | 优势 | 局限 | 更适合什么 |
|---|---|---|---|
| AirSim | Unreal 场景、相机与视觉效果好 | 原项目维护状态变化，版本兼容要固定 | 视觉、目标识别、复杂场景、PX4 SITL |
| Gazebo / Gazebo Sim | ROS / PX4 生态成熟 | 模型、插件、版本需要管理 | SLAM、传感器、多机、机器人联调 |
| PX4 SIH | 依赖少、启动快 | 3D 场景和高保真传感器有限 | 控制逻辑、任务流程、快速回归 |
怎么选最简单？
如果你现在主要学习 ROS 2 + PX4 的控制和消息链路，Gazebo/SIH 往往更轻量；如果你还要做 相机、目标识别、视觉导航，AirSim 的高质量场景会更有吸引力。
不要一开始就追求“最真实”。对于初学者，能稳定复现、能看懂数据流，比画面真实更重要。
7. PX4 基础：理解 uORB、Estimator、Controller 和 Commander
PX4 是模块化的飞控系统，模块之间通过 uORB 消息总线交换数据。传感器驱动把数据写入 uORB，状态估计器（例如 EKF2）进行融合，控制器根据目标生成执行器输出，Commander 管理飞行模式、解锁和安全状态。
可以先记这一条主线：
Sensors
↓
uORB
↓
EKF2 / Estimator
↓
Vehicle State
↓
Position / Attitude Controller
↓
Actuator Output
Commander、Mission、Offboard 等模块会从旁边影响“现在允许做什么”和“目标是什么”。
小白类比：uORB 像公司内部群聊
IMU 模块往群里发“最新角速度”；EKF2 订阅这些消息，算出“飞机现在是什么姿态”；控制器再订阅状态和目标，算出电机输出。
所以 uORB 是 PX4 内部模块说话的地方。
一个非常重要的观念
ROS 2 一般不是绕过 PX4 直接控制电机，而是给 PX4 一个更高层的目标，例如：
“飞到 x=5m, y=2m, z=-3m”
PX4 再自己完成高频控制。这也是为什么 PX4 和 ROS 2 可以各司其职。
8. MAVLink、uXRCE-DDS、ROS 2 DDS：三者分别解决什么问题
这是初学者最容易混淆的一节。原笔记强调：它们处于不同层级，可以同时存在，并不互相替代。
8.1 MAVLink：无人机生态的“通用对讲机”
MAVLink 常用于：
- PX4 ↔ QGroundControl
- PX4 ↔ AirSim / 仿真器
- PX4 ↔ MAVSDK / MAVROS 等工具
它擅长传遥测、命令、任务、参数等无人机生态消息。
8.2 DDS：ROS 2 世界里的“数据分发系统”
ROS 2 节点之间发布和订阅 Topic，底层通常由 DDS 负责把数据送到正确的节点。
8.3 uXRCE-DDS：让资源受限设备也能进入 DDS 世界
PX4 里运行的是轻量的 uXRCE-DDS Client，主机侧运行 Micro-XRCE-DDS-Agent。可以把 Agent 理解成“翻译 + 中转站”。
PX4 uORB
↕
uXRCE-DDS Client
↕
Micro-XRCE-DDS-Agent
↕
DDS
↕
ROS 2
一个类比
- uORB：PX4 公司内部群。
- MAVLink：无人机行业的对讲机协议。
- DDS：ROS 2 团队的大型消息总线。
- Micro-XRCE-DDS-Agent：把“小设备语言”接入 DDS 世界的中转站。
一句话记忆：MAVLink 更偏无人机生态通信；DDS / uXRCE-DDS 更偏 PX4 与 ROS 2 的数据空间连接。
9. 当前学习环境：Windows AirSim + WSL2 Ubuntu PX4 / ROS 2
为了和当前实际搭建环境一致，这里统一采用：
Windows 11
├── AirSim + Unreal Engine 4.27
└── QGroundControl
WSL2 Ubuntu 22.04
├── PX4 SITL
├── ROS 2 Humble
├── Micro-XRCE-DDS-Agent
└── px4_msgs / 自定义 ROS 2 Node
四条链路分别是：
- ROS 2 ↔ PX4：uXRCE-DDS Client + Micro-XRCE-DDS-Agent + DDS / px4_msgs。
- PX4 ↔ AirSim：Simulator / MAVLink 接口，用于仿真传感器与执行器闭环。
- PX4 ↔ QGroundControl：MAVLink，用于遥测、参数、任务和监控。
- ROS 2 ↔ AirSim：只有当你需要直接读取 AirSim 的相机、深度、LiDAR 等数据时，才额外使用 AirSim API / ROS Wrapper。
为什么 Windows 和 WSL2 之间还要特别配置 IP？
因为 WSL2 不是“Windows 里的一个普通文件夹”，而更像一台通过虚拟网络连接到 Windows 的 Linux 电脑。于是 AirSim 在 Windows，PX4 在 WSL2，它们跨的是网络边界。
这就是为什么调试时经常要关注：
Windows 主机 IP
WSL2 IP
TCP / UDP 端口
Windows 防火墙
9.1 一次典型自主飞行的数据流
假设 ROS 2 要求无人机飞到前方某个位置：
ROS 2 规划节点
↓ 目标位置 / 速度
PX4 Offboard 接口
↓
PX4 控制器
↓ 控制输出
AirSim 物理引擎
↓ 模拟 IMU / GPS / 状态
PX4 状态估计
↓ uXRCE-DDS
ROS 2 状态反馈
↓
更新下一轮规划
把它想成“开车导航”
ROS 2 像导航 App，说“前方 200 米右转”；PX4 像车辆底盘控制系统，真正控制方向、油门和稳定性；AirSim 像模拟道路；传感器反馈让系统知道“车现在开到哪里了”。
10. 无人机开发中最常用的软件与工具
原笔记列出了 PX4、QGC、ROS 2、Micro-XRCE-DDS-Agent、AirSim、Gazebo、MAVSDK、MAVROS、Flight Review、PlotJuggler、Foxglove、Wireshark、OpenCV、Git/CMake/colcon 等常用工具。
对于初学者，不建议一次全学。可以按下面顺序：
| 优先级 | 工具 | 先学到什么程度就够了 |
|---|---|---|
| 1 | PX4 | 会启动 SITL、看 uORB、懂飞行模式 |
| 1 | QGroundControl | 会连 PX4、看状态、参数、MAVLink Console |
| 1 | ROS 2 | 会 node / topic / service、会 colcon |
| 1 | Micro-XRCE-DDS-Agent | 知道它为什么存在，会启动和检查连接 |
| 2 | AirSim / Gazebo | 会启动场景、知道和 PX4 的通信链 |
| 2 | PlotJuggler / Foxglove | 会看曲线和消息 |
| 2 | Flight Review | 会看 ULog 的关键状态 |
| 3 | MAVSDK / MAVROS | 当项目需要 MAVLink API 时再学 |
| 3 | Wireshark | 网络排障时再深入 |
工具越多越好吗？
不是。初学阶段“多装一个工具”往往意味着“多一个可能出错的版本”。先建立最小闭环，再逐步增加工具，会轻松很多。
11. 最常用的调试命令与排障思路
原笔记给出了 ROS 2、PX4/QGC 和 Linux 网络侧的常见调试命令，并强调联合仿真要按链路逐段验证。
11.1 ROS 2
ros2 node list
ros2 topic list
ros2 topic info <topic>
ros2 topic echo <topic>
ros2 topic hz <topic>
rqt_graph
小白怎么用这些命令？
可以按“有没有 → 是谁 → 里面是什么 → 跑多快”的顺序：
ros2 topic list # 有没有这个 Topic？
ros2 topic info # 谁在发，谁在收？
ros2 topic echo # 数据长什么样？
ros2 topic hz # 发送频率正常吗？
11.2 PX4 / QGroundControl
常用检查：
QGC → Analyze Tools → MAVLink Console
listener <topic>
top
mavlink status
uxrce_dds_client status
11.3 Linux / 网络
ip addr
ip route
ss -lunp
ss -ltnp
ping <host>
nc -zv <host> <port>
dmesg -w
最重要的排障原则：像查水管一样一段一段查
不要看到“ROS 2 收不到 PX4 数据”就同时重装 AirSim、PX4、ROS 2。
正确思路是：
PX4 能否单独启动？
↓
QGC 能否连接 PX4？
↓
PX4 能否连接 AirSim？
↓
Agent 能否看到 PX4 Client？
↓
ROS 2 能否看到 /fmu/... Topic？
↓
最后再跑自己的算法节点
这样每次只排查一段，问题会简单很多。
12. 从仿真迁移到真机时必须补上的基础
12.1 坐标系：最常见的“方向反了”来源
ROS 常见 ENU / FLU，PX4 常见 NED / FRD。原笔记提醒：不能只看 x、y、z 字段名称，必须明确坐标系和单位。
一个直观例子
某系统把“向上”定义为 +Z，另一个系统可能把“向下”定义为 +Z。如果你直接复制坐标而不转换，本来想让飞机上升 2 米，结果可能变成下降 2 米。
12.2 时间同步与延迟
假设相机画面延迟 300 ms。无人机速度是 5 m/s，那么算法看到的目标位置其实已经“落后”了约 1.5 米。
这就是为什么真机系统不仅要看“有没有数据”，还要看：
时间戳是否一致？
频率是否稳定？
网络延迟多大？
算法处理用了多久？
12.3 电源、接地与 EMI
仿真里没有电源噪声，但真机中电机、ESC、数传、伴随计算机都会产生电流变化和电磁干扰。原笔记把布线、供电裕量、接地、散热列为真机可靠性的基础。
12.4 校准与安装方向
需要重点检查：飞控安装方向、IMU/磁力计校准、GPS 与大电流导线距离、相机外参、电机序号和旋转方向。
仿真最容易让人忽略“物理世界的麻烦”。而真正把项目从仿真搬到真机，恰恰大量时间花在这些细节上。
13. 真机测试的安全边界
真实旋翼和电机具有明显危险性。原笔记建议采用逐级验证：无桨测试、受控台架、成熟模式首飞、Kill Switch / Failsafe、地理围栏和低风险自主任务。
一个推荐的真机调试顺序
不开电机：检查软件、传感器、GPS、ROS 2 / PX4 通信
↓
无桨：检查电机输出、方向、模式切换
↓
受控台架：检查供电、振动、通信
↓
手动 / Position 模式低风险首飞
↓
低速、低高度 Offboard
↓
最后才逐步扩大自主功能
不要为了“早点看到效果”跳过前面的安全步骤。
14. 推荐的学习与验证路线
原笔记给出的路线从 ROS 2 基础开始，逐步打通 PX4 SITL、PX4↔ROS 2、PX4↔AirSim、AirSim↔ROS 2，再进入硬件和真机。
我把它改成更适合初学者的“闯关式”目标：
| 关卡 | 学什么 | 通关标准 |
|---|---|---|
| 1 | ROS 2 基础 | 能让 talker / listener 通信，能读懂 Topic |
| 2 | PX4 SITL | 能启动 PX4 + QGC，知道当前飞行模式 |
| 3 | PX4 ↔ ROS 2 | 能看到 /fmu/out/vehicle_status 等 Topic |
| 4 | PX4 ↔ AirSim | PX4 能驱动 AirSim 中的飞机，传感器能反馈 |
| 5 | Offboard | ROS 2 发 setpoint，PX4 正确执行 |
| 6 | AirSim 视觉 | ROS 2 能读取图像 / 深度等仿真数据 |
| 7 | 完整闭环 | ROS 2 规划 → PX4 控制 → AirSim 反馈 → ROS 2 更新 |
| 8 | 真飞控 / 台架 | 接口、电源、通信、延迟全部过关 |
| 9 | 真机 | 从低风险任务逐步扩展到完整自主功能 |
为什么这样学更轻松？
因为每一关只有一个“新变量”。如果一上来就同时装 PX4、ROS 2、AirSim、视觉算法和多机协同，任何一个组件出错，你都会不知道是谁的问题。
15. 一个完整无人机项目应该会检查什么
原笔记总结了完整项目应记录软件版本、独立验证各组件和通信链路、关注消息频率/QoS/端口/IP/坐标系、保留日志并在真机前检查 Failsafe、GeoFence、RTL、Kill Switch。
可以把它理解成一个“项目健康检查”：
- 版本能不能复现？
- 每个组件能不能单独跑？
- 每条链路能不能单独验证？
- 坐标系和单位有没有写清楚？
- 频率、延迟和 QoS 是否满足需要？
- 出问题后有没有日志可以回放？
- 真机前是否完成安全检查？
如果这些问题都有明确答案，项目通常会比“只要能飞就行”的项目稳定很多。
16. 常见术语速查：用最简单的话记
| 术语 | 最简单的理解 |
|---|---|
| SITL | PX4 和飞机世界都在电脑里 |
| HITL | PX4 跑在真飞控，世界还是模拟的 |
| GCS | 地面站，例如 QGroundControl |
| FCU | 飞控硬件本体 |
| Companion Computer | 跑 ROS 2 / AI / 视觉的伴随计算机 |
| uORB | PX4 内部模块通信总线 |
| DDS | ROS 2 常用的数据分发机制 |
| MAVLink | 无人机生态常用通信协议 |
| Offboard | 外部计算机持续给 PX4 发控制目标 |
| EKF | 用多种传感器共同估计飞机状态 |
| Failsafe | 出异常后自动进入安全处理逻辑 |
| RTL | Return To Launch，返航 |
原笔记对 SITL、HITL、GCS、FCU、Companion Computer、uORB、DDS、MAVLink、Offboard 和 EKF 也给出了术语定义。
17. 最后：初学时真正应该记住的 7 句话
- PX4 的第一任务是把飞机稳住，而不是做复杂 AI。
- ROS 2 负责上层算法，但通常把高层目标交给 PX4 执行。
- uORB 是 PX4 内部消息总线，DDS 是 ROS 2 的数据世界。
- Micro-XRCE-DDS-Agent 是 PX4 与 DDS / ROS 2 之间的重要中转。
- MAVLink 和 DDS 不冲突，它们解决的是不同通信问题。
- SITL 能飞不等于真机能飞，真机还有电源、振动、干扰、延迟和标定。
- 排障永远按链路一段一段验证，不要一出问题就全部重装。
当你能用自己的话解释这 7 句话时，再去看 PX4 + ROS 2 + AirSim 的安装和配置命令，会明显轻松很多。
18. 官方资料与继续阅读
- PX4 Simulation Overview：https://docs.px4.io/main/en/simulation/
- PX4 Hardware-in-the-Loop (HITL)：https://docs.px4.io/main/en/simulation/hitl
- PX4 ROS 2 User Guide：https://docs.px4.io/main/en/ros2/user_guide
- PX4 uXRCE-DDS Middleware：https://docs.px4.io/main/en/middleware/uxrce_dds
- PX4 MAVLink Documentation：https://docs.px4.io/main/en/mavlink/
- QGroundControl User Guide：https://docs.qgroundcontrol.com/
- MAVLink Guide：https://mavlink.io/en/
- Microsoft AirSim / PX4 SITL：https://github.com/microsoft/AirSim/blob/main/docs/px4_sitl.md
注：AirSim 原项目维护状态已经变化，实践中应固定实际验证通过的 AirSim、PX4、ROS 2 和相关依赖版本，避免“今天能跑、以后拉最新版又跑不起来”。
