轨迹控制时，使用的坐标关联是：
odom -> base_link
这是轨迹控制中最核心、最直接的两个坐标系关联。
为什么是 odom -> base_link？
轨迹控制（通常是局部规划器/控制器，如 nav2 中的 DWB 或 MPC 控制器）的核心任务是："在接下来的很短一段时间和距离内，让机器人准确地跟随一条计划好的局部轨迹。"
这个任务的性质决定了它必须依赖 odom -> base_link 的变换，原因如下：
-
高频与实时性 (High Frequency & Real-Time):
- 控制循环需要运行在很高的频率（通常 50Hz - 100Hz+）才能实现平滑、稳定的运动。
odom->base_link的变换由轮式编码器 或IMU 等传感器直接产生，更新频率极高（与控制器同频或更高）且延迟极低，完美匹配控制器的需求。- 相比之下，
map->base_link的变换来自于SLAM算法，其计算复杂，频率较低（通常10-30Hz）且有处理延迟，无法满足高速控制环的要求。
-
局部一致性与平滑性 (Local Consistency & Smoothness):
- 里程计提供的运动估计在短期内非常准确和平滑。它精确地描述了"自从上一个控制周期以来，机器人移动了多少"。
- 控制器关心的是相对运动 （"我下一步应该走多快、转多少"），而不是绝对的全局位置。
odom框架提供了一个局部一致、连续平滑的参考系，非常适合计算这种相对运动。
-
避免全局跳变的影响 (Avoiding Global Corrections):
- 当SLAM算法进行闭环检测或全局优化时，它会修正
map->odom的变换。这个修正会导致机器人的全局位姿发生"跳变"。 - 如果控制器直接使用
map->base_link，那么这次跳变会被控制器视为一个巨大的、瞬间的位姿变化，从而导致机器人产生剧烈、不稳定的纠正行为（例如突然猛转或猛冲）。 - 而使用
odom->base_link，则完全不受这种全局跳变的影响。因为SLAM的修正被隔离在了map->odom这个变换中，odom->base_link的流始终保持连续平滑，保证了控制的稳定性。
- 当SLAM算法进行闭环检测或全局优化时，它会修正
整个导航栈的数据流
为了让你更清晰地理解，我们来看整个导航过程中的数据流：
-
全局规划 (Global Planning):
- 使用
map->base_link。 - 全局规划器（如
nav2的NavFn）需要知道机器人在全局地图map中的绝对位置，来计算出一条从起点到目标点的全局路径。这条路径是粗略的。
- 使用
-
局部规划与轨迹控制 (Local Planning & Trajectory Control):
- 使用
odom->base_link。 - 局部规划器/控制器（如
nav2的DWB）接收全局路径。 - 它在其前方模拟生成多条局部轨迹。
- 为了评估和选择最佳轨迹 ，它需要极高频率的位姿来回答："以我当前的运动状态（
odom->base_link），执行哪条轨迹最可能成功跟踪全局路径，同时避免撞上附近的障碍物？" - 它最终输出的是速度指令 （
cmd_vel：线速度和角速度），这些指令直接控制电机，使odom->base_link的变换按照期望的轨迹变化。
- 使用
-
定位 (Localization):
- 使用
map->base_link。 - 虽然控制不用，但我们需要知道机器人在哪。Amcl 或 SLAM 算法会持续计算
map->odom的变换，从而间接得到map->base_link，用于显示在RVIZ中和供全局规划器使用。
- 使用
总结对比
| 任务 | 使用的坐标关联 | 原因 |
|---|---|---|
| 轨迹控制 (Trajectory Control) | odom -> base_link |
需要高频、连续、平滑的数据流。关心的是相对运动，而非绝对位置。 |
| 全局路径规划 (Global Planning) | map -> base_link |
需要机器人在全局地图中的绝对位置。 |
| 显示机器人位姿 (RVIZ) | map -> base_link |
需要知道机器人在地图中的真实位置。 |
| 传感器数据处理 (e.g., 避障) | odom -> sensor_link |
需要将最近的传感器数据转换到统一的局部参考系中进行处理。 |
所以，记住这个结论：在做高速、实时的轨迹跟踪和运动控制时，你永远应该依赖和使用了 odom -> base_link 这个变换。