3. 无人机基础
在进入 ROS2 无人机伴随计算机开发之前，必须先建立对多旋翼飞行器本体的基本认识。伴随计算机并不直接“让电机转动”，它通过飞控获取状态、发布控制目标、运行感知与规划算法，因此理解飞行原理、坐标系、姿态表示、传感器和飞控平台，是后续所有代码能够正确落地的前提。
一、多旋翼飞行原理：四个输入，六个自由度
以最常见的四旋翼为例，它通过四个电机转速的组合变化产生升力、俯仰、横滚和偏航运动。四个旋翼中通常有两对反向旋转的桨叶，用来抵消反扭矩。飞控对四个电机施加不同的 PWM 或 DShot 指令，本质是在控制四个推力的大小，从而合成总推力和三轴力矩。
- 升降：四个电机同步加速或减速，总推力大于或小于重力，实现上升、悬停或下降。
- 俯仰：前后电机差速，机体绕横轴倾斜，产生前后方向的分力，实现前进或后退。
- 横滚：左右电机差速，机体绕纵轴倾斜，产生左右方向的分力，实现侧移。
- 偏航：两组对角电机差速，改变反扭矩平衡，使机头绕垂直轴旋转。
多旋翼是欠驱动系统：四个控制输入要控制六个自由度（位置 x、y、z 与姿态 roll、pitch、yaw），因此位置和姿态不能独立任意指定。飞控通常采用串级控制：外环位置/速度环输出期望姿态，内环姿态角速度环输出电机指令。伴随计算机若通过 MAVLink 发送位置或速度设定点，实际执行仍由飞控内环完成。
关键结论：伴随计算机负责“去哪里、看什么、怎么规划”，飞控负责“如何稳定地飞过去”。两者通过 MAVLink 或 ROS2 话题交换设定点与状态。
二、坐标系：从机体系到世界系
无人机开发中最容易出错的地方之一，就是坐标系混用。常见坐标系包括：
| 坐标系 | 符号 | 原点与轴向 | 典型用途 |
|---|---|---|---|
| 机体坐标系 | body / base_link | 原点在机体中心，x 向前，y 向右，z 向下（航空常用） | IMU、机载相机、飞控内部姿态 |
| 世界坐标系 | world / map / odom | 原点在起飞点或地图原点，z 向上（ROS 常用 ENU） | 路径规划、目标点、全局定位 |
| 相机坐标系 | camera_link | 原点在光心，z 向前，x 向右，y 向下 | 视觉 SLAM、目标检测、深度估计 |
| NED 坐标系 | NED | 北-东-地，z 向下，航空与 MAVLink 常用 | 飞控状态、GPS 航向 |
ROS2 中使用 TF2 维护坐标变换树。典型链路为 map → odom → base_link → camera_link。若伴随计算机需要把视觉检测结果转换为世界坐标，必须经过完整的 TF 链，而不是只做一次旋转。注意 ROS 默认使用 ENU（东-北-天），而飞控和 MAVLink 常用 NED（北-东-地），两者之间需要做轴交换和符号翻转。
三、姿态表示：欧拉角、旋转矩阵与四元数
姿态描述的是机体坐标系相对世界坐标系的旋转关系。常见表示方法有三种：
- 欧拉角：roll、pitch、yaw，直观易读，但存在万向节死锁，且旋转顺序不同结果不同。
- 旋转矩阵：3×3 正交矩阵，适合坐标变换计算，但存储冗余、数值误差会累积。
- 四元数：四个数表示旋转，无死锁、插值平滑，是 ROS2 和飞控内部的主流表示。
在 ROS2 中，姿态消息通常使用 geometry_msgs/msg/Quaternion，而人类可读的 roll/pitch/yaw 需要通过转换得到。下面是一段常见的 Python 转换示例：
from tf_transformations import euler_from_quaternion
# 假设从 /mavros/imu/data 或 /tf 中拿到四元数
q = [msg.orientation.x, msg.orientation.y,
msg.orientation.z, msg.orientation.w]
roll, pitch, yaw = euler_from_quaternion(q)
print(f"roll={roll:.3f}, pitch={pitch:.3f}, yaw={yaw:.3f}")常见误区：直接把飞控通过 MAVLink 发来的 roll/pitch/yaw 当作 ROS 的 ENU 姿态使用。MAVLink 的 ATTITUDE 消息通常是 NED 下的弧度值，yaw 方向与 ENU 相反，必须转换后再送入规划或控制模块。
四、传感器与飞控平台：状态从哪来，控制往哪去
飞控依赖传感器完成状态估计。核心传感器包括 IMU（加速度计+陀螺仪）、磁力计、气压计、GPS，以及外接的光流、激光测距、视觉定位等。IMU 提供高频角速度和加速度，但会漂移；GPS 提供低频绝对位置；气压计提供高度但受气流影响；视觉/激光定位可在室内替代 GPS。飞控内部通过扩展卡尔曼滤波或互补滤波融合这些数据，输出姿态、位置和速度估计。
常见飞控平台及其与伴随计算机的配合方式如下：
| 飞控平台 | 固件/生态 | 与伴随计算机接口 | 适用场景 |
|---|---|---|---|
| Pixhawk 系列 | PX4 或 ArduPilot | MAVLink over UART/USB，ROS2 用 micro-ROS 或 mavros | 科研、巡检、集群，生态最成熟 |
| CUAV / Holybro | PX4 / ArduPilot | 同上，常配 Jetson 或树莓派 | 中型多旋翼、行业应用 |
| 大疆 Onboard SDK | DJI 飞控 | OSDK / PSDK，串口或网口 | M300、M350 等机型二次开发 |
| PX4 + ROS2 | PX4 Autopilot | micro-ROS / uXRCE-DDS 直连 | 轻量、低延迟的 ROS2 原生方案 |
在 ROS2 伴随计算机架构中，飞控与计算机通常通过串口或网口连接。若使用 PX4，推荐 uXRCE-DDS 桥接，可直接把飞控内部 uORB 话题映射为 ROS2 话题；若使用 ArduPilot，则常用 mavros 或 MAVSDK。无论哪种方式，伴随计算机拿到的都是位置、姿态、电池、GPS 等状态，以及可发送的设定点、模式切换和任务指令。
五、案例与复盘：一次“起飞后漂移”的排查
某次室内测试中，无人机起飞后持续向一侧漂移，伴随计算机发送的位置设定点没有生效。排查过程如下：
- 检查飞控模式，发现仍处于 Stabilize 而非 Offboard 或 Guided，设定点被忽略。
- 检查 MAVLink 连接，确认伴随计算机能收到 ATTITUDE 和 LOCAL_POSITION_NED，但未发送心跳。
- 检查坐标系，发现视觉定位输出的 yaw 是 ENU 方向，而飞控期望 NED，导致偏航估计反向。
- 修正 TF 链和 yaw 符号后，重新进入 Offboard 模式，漂移消失。
经验总结：无人机开发中，绝大多数“控制不生效”问题都来自三处：模式未切换、坐标系未对齐、心跳或消息频率不满足飞控要求。先确认状态流，再确认控制流，最后才怀疑算法。
掌握多旋翼飞行原理、坐标系、姿态表示、传感器与飞控平台之后，后续在 ROS2 中编写伴随计算机节点时，才能正确理解话题方向、单位、坐标系和模式约束，把感知、规划与控制真正串成一条可运行的链路。