旋转矩阵与欧拉角：从物理意义到工程实践
各位同行好，我是做感知融合的老兵了。今天咱们聊聊坐标变换里最基础也最容易踩坑的部分——旋转矩阵、欧拉角和四元数。说实话，我见过太多同事在这上面翻车，包括我自己刚入行那会儿。
旋转矩阵的物理意义
旋转矩阵说白了就是个3x3的矩阵，它描述了一个坐标系相对于另一个坐标系的朝向。你想想看，我们做感知融合时，激光雷达、摄像头、毫米波雷达各自有各自的坐标系，要把它们统一到车体坐标系下，靠的就是旋转矩阵。
我个人习惯把旋转矩阵理解成「基向量的投影」。什么意思呢？假设我有两个坐标系A和B，那么旋转矩阵R_AB的每一列，其实就是B坐标系的基向量在A坐标系下的坐标表示。嗯，这个理解方式对我做标定帮助很大。
核心性质：旋转矩阵是正交矩阵，满足 RTR = I，且 det(R) = 1。这意味着它只改变方向，不改变长度。
我在项目中遇到过一个问题：有人直接用旋转矩阵做插值，结果得到的矩阵不再是正交的，导致物体变形。这就是没理解旋转矩阵的物理意义——它必须保持正交性。
欧拉角的定义与RPY约定
欧拉角是另一种描述旋转的方式，用三个角度来表示。在自动驾驶领域，我们最常用的是RPY（Roll-Pitch-Yaw）约定，也就是横滚-俯仰-偏航。
| 角度 | 绕轴 | 物理含义 |
|---|---|---|
| Roll (φ) | X轴 | 车身侧倾，比如过弯时的倾斜 |
| Pitch (θ) | Y轴 | 车头俯仰，比如上坡下坡 |
| Yaw (ψ) | Z轴 | 车头朝向，也就是航向角 |
这里要注意的是旋转顺序。RPY约定通常采用ZYX顺序：先绕Z轴转Yaw，再绕Y轴转Pitch，最后绕X轴转Roll。顺序搞反了，结果天差地别。
⚠️ 常见坑：不同库对欧拉角的定义可能不同。比如ROS和MATLAB的旋转顺序就不一样。我曾经因为这个问题，联调时花了整整一天排查，最后发现是欧拉角顺序理解错了。
万向锁问题——一个绕不开的坑
万向锁（Gimbal Lock）是欧拉角最让人头疼的问题。为什么会这样？说白了，当Pitch角达到±90°时，Roll和Yaw的旋转轴会重合，导致丢失一个自由度。
我记得有一次做车辆姿态估计，车辆在陡坡上行驶时，Pitch角接近90°，结果欧拉角表示突然变得不稳定，姿态估计直接崩了。这就是万向锁在作怪。
💡 我的建议：如果你需要在全姿态范围内工作，尽量别用欧拉角。用四元数或者旋转矩阵会更安全。
四元数基础
四元数是个好东西，它用四个数来表示旋转，没有万向锁问题，插值也平滑。形式上，四元数 q = w + xi + yj + zk，其中 w 是实部，x、y、z 是虚部。
我个人理解四元数的方式是：它描述了一个绕单位向量 (x, y, z) 旋转 2*arccos(w) 角度的操作。这个理解在做姿态融合时特别有用。
// C++示例：四元数转旋转矩阵
Eigen::Quaterniond q(0.707, 0.0, 0.707, 0.0); // w, x, y, z
Eigen::Matrix3d R = q.toRotationMatrix();
// 注意：Eigen中四元数的存储顺序是 (w, x, y, z)四元数的优势：
- 无万向锁问题
- 插值平滑（球面线性插值SLERP）
- 计算效率高（比旋转矩阵少一个维度）
- 易于组合旋转
嗯，这里要注意四元数的归一化。非单位四元数会导致缩放，这在感知融合中是致命的。我习惯每次使用前都检查一下模长是否接近1。
知识体系总览
下面这张图是我自己总结的，把旋转表示方法之间的关系理清楚了：
避坑指南
最后分享几个我踩过的坑，希望能帮到大家：
- 我曾经因为四元数顺序搞反（Hamilton vs JPL约定），导致整个融合系统姿态反了。现在我用Eigen库，它默认Hamilton约定，但ROS用的是另一种。联调前一定要确认好。
- 我曾经在欧拉角转旋转矩阵时，忘记考虑旋转顺序。结果标定出来的外参全是错的，排查了三天才发现是顺序问题。
- 我建议所有旋转表示法之间转换时，都写单元测试。比如随机生成一个旋转矩阵，转成四元数再转回来，看误差是否在可接受范围内。
💡 实用技巧：调试时可以用欧拉角来理解姿态，但最终存储和传输时，我强烈建议用四元数。它既紧凑又稳定，是感知系统的最佳选择。
好了，这一章就到这里。旋转表示法看似简单，但实际工程中处处是坑。理解了物理意义，掌握了转换关系，你就能在感知联调中游刃有余。