一、坐标变换入门：从零开始理解这个核心概念
说实话，我刚开始接触坐标变换时，也觉得这玩意儿不就是个数学公式吗？直到我在机器人项目里栽了个大跟头——机械臂抓取精度死活达不到要求，折腾了三天才发现是坐标变换参数写反了。从那以后，我对这个看似简单的概念再也不敢掉以轻心。
1.1 什么是坐标变换？
坐标变换，说白了就是回答一个问题：同一个点，在不同坐标系下，坐标值分别是多少？
举个例子。你站在教室门口，说「讲台在我前方3米处」。但如果我站在讲台上，我会说「教室门在我后方3米处」。同一个讲台，同一个门，只是观察位置不同，描述就完全不一样了。
坐标变换干的就是这件事——把「从A坐标系看到的坐标」转换成「从B坐标系看到的坐标」。
核心公式（二维情况）：
// 点P在坐标系A中的坐标是 (x_a, y_a)
// 坐标系B相对于A的平移是 (tx, ty)，旋转角度是 θ
// 那么P在B中的坐标 (x_b, y_b) 为：
x_b = (x_a - tx) * cos(θ) + (y_a - ty) * sin(θ)
y_b = -(x_a - tx) * sin(θ) + (y_a - ty) * cos(θ)嗯，公式看着有点吓人。但你想想看，其实就是「先平移，再旋转」两个步骤。我在项目里习惯把它拆成两步写，不容易出错。
1.2 为什么需要坐标变换？
这个问题我问过不少新人。有人回答「因为要算位置」，有人回答「因为要画图」。都对，但不够本质。
根本原因只有一个：每个物体都有自己的「小世界」。
你想想看：
- 机器人的摄像头看到的是「摄像头坐标系」下的图像
- 机器人的机械臂运动是在「基座坐标系」下规划的
- 机器人的导航是在「世界坐标系」下进行的
这三个坐标系都不一样。没有坐标变换，摄像头看到杯子在左边，机械臂却往右边抓——这不就乱套了吗？
我的经验： 做系统设计时，我建议先画清楚所有坐标系的关系图。别急着写代码。坐标系关系理清了，代码就是套公式的事。我曾经因为偷懒跳过这一步，结果调试花了三倍时间。
1.3 坐标变换的应用领域
坐标变换不是纸上谈兵。我接触过的项目里，几乎每个跟「位置」打交道的系统都离不开它。
🤖 机器人领域
这是坐标变换用得最狠的地方。我做过一个AGV（自动导引车）项目，车上装了激光雷达、IMU、轮式编码器，每个传感器都有自己的坐标系。
- 手眼标定： 让机械臂知道「摄像头看到的物体，在我坐标系下在哪」
- 多传感器融合： 把激光雷达的点云、IMU的姿态、编码器的里程计统一到同一个坐标系下
- 运动学正解/逆解： 每个关节都有自己的坐标系，要算出末端执行器的位置，就得一级一级变换下去
我记得有一次调试AGV的定位模块，激光雷达说「前方2米有障碍」，但车就是撞上去了。查了半天，原来是激光雷达的安装角度没补偿——坐标变换里差了3度旋转。3度啊，在2米外就是10厘米的偏差，刚好够撞上货架腿。
避坑指南： 我曾经在ROS里用tf库做坐标变换，有个坑特别容易踩——时间戳同步。不同传感器的数据到达时间不一样，直接用最新数据做变换，位置可能差出去老远。一定要做时间戳对齐。
🎮 游戏开发
做游戏的朋友应该很熟悉了。每个3D游戏都在疯狂做坐标变换。
- 模型坐标系 → 世界坐标系： 把角色模型放到游戏场景中
- 世界坐标系 → 观察坐标系： 把场景转换到玩家视角
- 观察坐标系 → 屏幕坐标系： 把3D场景投影到2D屏幕上
这一整套流程，在图形学里叫「渲染管线」。我虽然不是专业做游戏的，但做过一些仿真可视化工具，原理一模一样。说白了，就是让玩家感觉「我就在那个世界里」。
🗺️ GIS（地理信息系统）
GIS里的坐标变换更复杂，因为地球是圆的，地图是平的。
- 投影变换： 把经纬度（WGS84坐标系）映射到平面坐标（比如高斯-克吕格投影）
- 基准面转换： 不同国家用不同的地球模型，坐标值差几十米很正常
- 地图配准： 把卫星图、航拍图、矢量地图对齐到同一个坐标系
我有个朋友做智慧城市项目，把GPS轨迹叠加到地图上，结果轨迹跑到河对岸去了。查到最后，是GPS用的是WGS84坐标系，地图用的是GCJ02（火星坐标系），差了大概500米。嗯，这个坑踩过的人应该不少。
1.4 本章知识体系
下面这张图是我自己梳理的坐标变换知识框架，你可以把它当作学习路线图：
1.5 小结
这一章我们聊了坐标变换是什么、为什么需要它、以及它在三个主要领域的应用。说白了，坐标变换就是不同坐标系之间的「翻译官」。没有它，机器人抓不到东西，游戏画面是乱的，地图也对不上。
我个人觉得，学坐标变换最重要的是建立「坐标系思维」——看到任何位置数据，第一反应就是「这个数据是在哪个坐标系下的？」。养成这个习惯，后面学矩阵、学四元数、学各种变换，都会轻松很多。
嗯，这一章就到这里。下一章我们开始动手——用代码实现一个最简单的二维坐标变换。
可可精品资料库