【AutowareAuto】AVP 2020 Demo Localization Design

总览

根据 REP-105[1] 并在定位模块设计中规定的设计原则的指导下，以下本地化架构将用于 AVP 2020 演示，并将构成 Autoware.Auto 定位模块架构未来改进的基础。

坐标系

定义了以下坐标系：

• /earth
• /map
• /semantic_map
• /odom
• /base_link
• /nav_base（可选）
• 附加坐标系应附加到 /base_link 坐标系以表示传感器坐标系
• 可选的坐标系可以附加到 /base_link 框架以方便传感器校准

除了 /base_link 坐标系和新添加的 /nav_base 坐标系之外，REP-105[1] 为大多数坐标系提供了足够的特异性以用于具体实现。 出于本演示的目的，/base_link 坐标系的位置应定义为：

• 在以下条件下测量的与车辆后轴中心重合的刚性连接到车架的位置：
  1. 除车辆制造商在交付时提供的设备和部件外，车辆没有任何额外负载
  2. 所有四个轮胎的胎压均符合制造商规格
  3. 车辆放置在平坦、水平的地面上

出于本演示的目的，可选的 /nav_base 坐标系的位置应定义为：

• 刚性连接到车辆框架的位置，在 X 和 Y 坐标中与车辆的重心重合。

前提假设

为提供的定位架构做出以下假设：

• 一个静态的、全球固定的传感器数据地图可用于定位（传感器地图）
• 一个静态的、全局固定的语义数据地图可用于交通规则和一些静止物体（语义地图）
• 本地参考的里程计传感器数据可从一个或多个来源获得
• 可从一个或多个来源获得本地参考的环境传感器数据
• 全球参考位置数据可从一个或多个来源获得

组成部分/组件

AVP 2020 演示的最终定位模块应包含以下组件：

• 全局状态估计器
  • 输入：全球参考的传感器数据（例如 GPS）
  • 输出：在 /earth坐标系下的 sensor_msgs/PoseWithCovarianceStamped
• 坐标变换器
  • 输入：在源坐标系下的sensor_msgs/PoseWithCovarianceStamped
  • 输入：sensor_msgs/PoseWithCovarianceStamped 中使用的坐标系的变换
  • 输入：转换的目标坐标系
  • 输出：在目标坐标系中的sensor_msgs/PoseWithCovarianceStamped
• 环境传感器定位器
  • 示例：NDT 匹配
  • 输入：具有固定外部定位环境的本地参考的传感器数据（例如激光雷达、雷达）
  • 输入：全局参考传感器数据地图（例如点云）
  • 输入：来自全局状态估计器中在 /map 坐标系下的sensor_msgs/PoseWithCovarianceStamped，通过坐标变换器从/earth->/map转换获得
  • 输出：/map 坐标系下的 sensor_msgs/PoseWithCovarianceStamped
• 里程计状态估计器
  • 输入：没有固定外部定位环境的本地参考传感器数据（例如车轮编码器、视觉里程计、加速度计、陀螺仪）
  • 输出：/odom->/base_link 变换
• 地图状态估计器
  • 输入：/odom->/base_link 变换
  • 输入：来自环境传感器定位器在 /map 坐标系下的sensor_msgs/PoseWithCovarianceStamped
  • 输入：来自全局状态估计器中在 /map 坐标系下的sensor_msgs/PoseWithCovarianceStamped，通过坐标变换器从/earth->/map转换获得
  • 输出：/map->/odom 变换

坐标变换

AVP 2020 演示的最终定位模块具有以下可用转换：

• /base_link-><sensor_frame>：静态。使用 URDF 文件时由 tf2::static_transform_publisher 或 robots_description 发布。
  • 说明： 假设所有附着在移动机器人身体上的传感器都是刚性的，不能自由移动。由于 /base_link 是一个坐标系，它被定义为绑定到移动机器人身体上的一个固定点，传感器和 /base_link 之间的任何转换都是静态的。
• /base_link->/nav_base：静态。使用 URDF 文件时由 tf2::static_transform_publisher 或 robots_description 发布。
  • 说明：虽然 /base_link 坐标系的位置对于某些车辆模型和长期路径规划很有用，但车辆的质心在短期路径规划和估计车辆动力学方面更有用。然而，在某些操作设计领域，以足够的特异性来测量车辆的质心是不值得的，这就是为什么这个坐标系是可选的。
• /odom->/base_link：动态。由 Odometry State Estimator 发布。
  • 说明：虽然本地地图的定位提供了全局固定的位置估计，但没有任何传感器或算法可以将本地地图定位为可靠的，并且不能相信始终提供连续、无错误的位置。此外，当尚未计算本地地图中的初始位置时，不能期望环境传感器定位器提供准确的定位估计。由于导航基于完整的 /map->/base_link 转换，因此即使在全局相对或地图相对位置尚不可用时，此估计也可用于导航。
• /map->/odom：动态。由地图状态估计器发布。
  • 说明：Map State Estimator 取Environment Sensor Localizer 提供的位置估计（一个/map->/base_link 关系）以及Global State Estimator 提供的位置估计（通过姿势变换器使用 /earth->/map 变换后传入的一个/map->/base_link 关系）并将它们融合成一个 /map->/base_link 估计。然后，它将此估计与 odom 框架的原点联系起来，作为它发布的 /map->/odom 变换。这允许将里程计定位数据和环境传感器定位数据集成到 /map->/odom->/base_link 的转换树中，导航和规划组件应将其视为单个转换（即临时 /map->/base_link）。
• /map->/semantic_map：静态。由 tf2::static_transform_publisher 或 Map Loader 发布。
  • 说明：由于语义地图的原点和传感器地图的原点之间经常存在偏移，因此每个地图的不同框架坐标系是必要的。此外，由于定位通常比使用语义地图的功能对时间更敏感，典型的 /map 坐标系与传感器地图相关联，这避免了定位中的变换查找，但在使用语义地图的功能（例如路径规划）中需要这一变换，使这种转换成为必需的而不是可选的，避免了传感器和语义图之间不必要的依赖。此外，省略此转换将需要假设语义地图和传感器地图都具有重合的原点，这将需要另一个不必要的相互依赖性或此假设的运行时验证，这会导致操作顺序依赖性。
• /earth->/map：如果使用地图服务器，这一变换是动态但不连续的，由地图服务器发布。如果没有使用地图服务器，这一变换是静态的，并由 tf2::static_transform_publisher 发布。
  • 说明：由于传感器地图（发布在 /map 框架坐标系中）被定义为全局固定，此转换将传感器地图的原点与引用为 ECEF 的 /earth 框架的原点相关联。此变换的发布对于环境传感器定位器使用全局状态估计器的输出创建初始位置估计是必要的。对于 Map State Estimator 能够利用 Global State Estimator 的输出作为融合输入，这种变换也是必要的。

框架图

参考

• [1] REP105 - Coordinate Frames for Mobile Platforms