一、Autoware是什么?
Autoware与Apollo类似，是2015年发布的开源自动驾驶项目，它基于机器人操作系统 ( ROS 2 ) ，包含Map Server、Sensor Drivers、Perception、Prediction、Localization、Planning、Control、Vehicle Interface、User Interface等完备的自动驾驶模块，对自动驾驶汽车在各种平台和应用程序上的商业部署起到了积极的推动作用。
二、Autoware的版本区别
1. Autoware.AI
第一个基于ROS 1发布的发行版，涵盖自动驾驶技术的不同方面 – 传感、驱动、定位、映射、感知和规划。虽然成功吸引了众多开发人员和贡献，但由于以下几点原因，Autoware.AI 的功能很难得到提升：
- 缺乏具体的架构设计，导致积累大量技术债务，如模块之间耦合紧密、模块职责不明确等。
- 每个包的编码标准不同，测试覆盖率很低。
此外，没有明确定义支持 Autoware 的自动驾驶汽车可以在什么条件下运行，也没有明确定义支持的用例或情况（例如超越静止车辆的能力）。
2 Autoware.Auto
基于ROS 2发布的第二个 Autoware 发行版。作为向ROS 2过渡的一部分，采用适当的工程实践从头开始重写了代码库，包括定义目标用例和 ODD（例如：自动代客泊车 [ AVP ]、货物运送等）、设计适当的架构、编写设计文档和测试代码。
Autoware.Auto 开发最初似乎进展顺利，但在完成AVP和 Cargo Delivery ODD项目后，开始看到以下问题：
- 新工程师的门槛太高了。
- 将新功能合并到 Autoware.Auto 需要做大量工作，因此研究人员和学生很难为开发做出贡献。
- 因此，大多数 Autoware.Auto 开发人员都来自 Autoware 基金会的公司，因此很少有人能够从研究论文中添加最先进的功能。
- 进行大规模的架构变革太困难了。
- 为了尝试实验性架构，需要花费很大的开销来保持主分支稳定，同时还要确保每个更改都满足持续集成要求。
3 Autoware Core/Universal
为了解决 Autoware.Auto 开发的问题，Autoware 基金会决定创建一个名为 Autoware Core/Universe 的新架构。
Autoware Core 继承了 Autoware.Auto 的原始策略，即成为一个稳定且经过充分测试的代码库。除了 Autoware Core 之外，还有一个名为 Autoware Universe 的新概念，它是 Autoware Core 的扩展，具有以下优势：
- 用户可以轻松地用 Universe 等效组件替换核心组件，以便使用更高级的功能，例如新的定位或感知算法。
- Universe 的代码质量要求更加宽松，以便新开发人员、学生和研究人员更容易做出贡献，但仍然比 Autoware.AI 的要求更严格。
- 任何添加到 Universe 且对更广泛的 Autoware 社区有用的高级功能都将被审查并考虑纳入主要的 Autoware Core 代码库。
这样，就可以实现拥有稳定安全的自动驾驶系统的主要要求，同时还可以访问第三方贡献者创建的最先进的功能。
三、Autoware的设计方案
1. 传感 Sensing
主要对原始传感器数据进行预处理。
传感器输入数据类型：
| 传感器数据 | 消息类型 |
|---|---|
| PointCloud 点云（激光雷达、深度相机等） | sensor_msgs/msg/PointCloud2.msg |
| Image 图像（RGB、单色、深度等相机） | sensor_msgs/msg/Image.msg |
| Radar Scan 雷达扫描 | radar_msgs/msg/RadarScan.msg |
| Radar Tracks 雷达跟踪 | radar_msgs/msg/RadarTracks.msg |
| GNSS-INS Position 位置 | sensor_msgs/msg/NavSatFix.msg |
| GNSS-INS Orientation 定位 | autoware_sensing_msgs/GnssInsOrientationStamped.msg |
| GNSS-INS Velocity 速度 | geometry_msgs/msg/TwistWithCovarianceStamped.msg |
| GNSS-INS Acceleration 加速度 | geometry_msgs/msg/AccelWithCovarianceStamped.msg |
| IMU 惯性测量单元 | sensor_msgs/msg/Imu.msg |
| Ultrasonics 超声波 | sensor_msgs/msg/Range.msg |
2. 地图 Map
Autoware依靠驾驶环境的高清点云地图和矢量地图来执行各种任务，例如定位、路线规划、交通灯检测以及预测行人和其他车辆的轨迹。地图主要提供以下类型的信息：
- 矢量地图：呈现道路语义信息
- 包含有关道路网络、车道几何形状和交通信号灯的高精度信息。它是路线规划、交通信号灯检测以及预测其他车辆和行人的轨迹所必需的。
- 3D点云图：用于点云匹配定位（可选）
- 主要用于基于 LiDAR 的定位和 Autoware 中的部分感知。为了确定车辆的当前位置和方向，将从一个或多个 LiDAR 单元捕获的实时扫描与预先生成的 3D 点云地图进行匹配。因此，准确的点云地图对于良好的定位结果至关重要。但是，如果车辆具有足够精确的替代定位方法，例如使用基于摄像头的定位，则可能不需要点云地图来使用 Autoware。
- 地图的大地坐标系统
Map 组件由以下子组件组成：
- 点云地图加载：加载并发布点云地图
- 矢量地图加载：加载并发布矢量地图
- 投影加载：加载并发布投影信息，用于本地坐标（x，y，z）与大地坐标系（纬度，经度，海拔）之间的转换
3. 定位 Localization
定位旨在估计车辆的姿势、速度和加速度。目标：
- 尽可能长时间估计车辆姿态、速度和加速度的系统。
- 检测诊断估计的稳定性，如果估计结果不可靠，则向错误监控系统发送警告信息。
- 可以与各种传感器配置配合使用的车辆定位能力。
TF树：
| frame | 含义 |
|---|---|
| earch | ECEF（地心地球固定） |
| map | 地图坐标原点（例如 MGRS 原点） |
| viewer | rviz 的用户定义框架 |
| base_link | 自车的参考姿态（后轴中心在地面上的投影） |
| sensors | 每个传感器的参考姿态 |
只要保持上述 tf 结构，开发人员也可以选择添加其他frame，例如 odom 或 base_footprint。
精准定位的前提条件：
- 传感器：
- 输入数据没有缺陷。
- IMU等内部传感器观察持续保持适当的频率。
- 输入数据具有正确且准确的时间戳。
- 如果时间戳不准确，估计的姿势可能不准确或不稳定。
- 传感器安装正确，定位精确，可从 TF 访问。
- 如果传感器位置不准确，估计结果可能不正确或不稳定。
- 需要一个传感器校准框架来正确获取传感器位置。
- 输入数据没有缺陷。
- 地图：
- 地图中包含了足够的信息。
- 如果地图中的信息不足，姿势估计可能会不稳定。
- 需要一个测试框架来检查地图是否具有足够的信息进行姿势估计。
- 地图与实际环境差别不大。
- 如果实际环境中的物体与地图上的物体不同，则姿势估计可能会不稳定。
- 地图需要根据新物体和季节变化进行更新。
- 地图必须与统一的坐标对齐，或者要有对齐框架。
- 如果使用具有不同坐标系的多张地图，它们之间的不对齐会影响定位性能。
- 地图中包含了足够的信息。
- 计算资源：
- 应提供足够的计算资源以保持准确性和计算速度。
每个传感器都有自己的优点和缺点，但通过融合多个传感器可以提高整体性能。常见传感器融合定位示例如下：
3.1 3D-LiDAR + 点云地图
- 预期情况
- 车辆位于结构丰富的环境中，例如城市地区
- 可能导致系统不稳定的情况
- 车辆被放置在无结构环境中，例如乡村景观、高速公路或隧道
- 自地图创建以来，环境发生了变化，例如积雪或建筑物的建造/毁坏。
- 周围物体被遮挡
- 汽车周围是 LiDAR 无法探测到的物体，例如玻璃窗、反射或吸收（暗色物体）
- 环境包含与汽车的 LiDAR 传感器相同频率的激光束
- 功能
- 该系统可以在点云地图上估算车辆位置，误差约为10cm。
- 该系统可在夜间运行。
3.2 3D-LiDAR 或 摄像头 + 矢量地图
- 预期情况
- 具有清晰白线且曲率平缓的道路，例如高速公路或普通地方道路。
- 可能导致系统不稳定的情况
- 白线粗糙或被雨雪覆盖
- 急转弯，例如交叉路口
- 雨水或油漆导致路面反射变化大
- 功能
- 沿横向修正车辆位置。
- 沿经度方向的姿态校正可能不准确，但可以通过与GNSS融合来解决。
3.3 GNSS全球导航卫星系统
- 预期情况
- 将车辆放置在开放环境中，周围几乎没有物体遮挡，例如乡村景观、空旷地域。
- 可能导致系统不稳定的情况
- GNSS信号被周围物体（例如隧道或建筑物）阻挡。
- 功能
- 该系统可以估算世界坐标中的车辆位置，误差在~10米以内。
- 通过连接 RKT– GNSS（实时动态全球导航卫星系统），精度可以提高到~10 厘米。
- 具有此配置的系统无需环境地图（点云和矢量地图类型）即可工作。
3.4 摄像头（视觉里程计、视觉SLAM）
- 预期情况
- 将车辆放置在具有丰富视觉特征的环境中，例如城市区域。
- 可能导致系统不稳定的情况
- 车辆被放置在无纹理的环境中（笔直的平面，无任何特征点）。
- 车辆周围有其他物体。
- 摄像头可以观察到显著的照明变化，例如由阳光、其他车辆前灯或接近隧道出口时引起的变化。
- 车辆放置在黑暗的环境中。
- 功能
- 该系统可以通过跟踪视觉特征来估算里程。
3.5 轮速传感器
- 预期情况
- 车辆行驶在平坦、顺畅的道路上。
- 可能导致系统不稳定的情况
- 车辆在湿滑或颠簸的路面上行驶，可能会造成对车轮速度的错误观测。
- 功能
- 该系统可以获取车辆速度并估算行驶距离。
3.6 IMU惯性测量单元
- 预期环境
- 平坦、顺畅的道路
- 可能导致系统不稳定的情况
- IMU 具有依赖于周围温度的偏差
- 功能
- 该系统可以观测加速度和角速度。
- 通过整合这些观测数据，系统可以估计局部姿态变化并实现航位推算
3.7 地磁传感器
- 预期情况
- 车辆置于磁噪声较低的环境中
- 可能导致系统不稳定的情况
- 将车辆放置在具有高磁噪声的环境中，例如含有钢筋或其他产生电磁波的材料的建筑物或结构的环境中。
- 功能
- 该系统可以估算车辆在世界坐标系中的方向。
3.8 磁性标记
- 预期情况
- 将汽车放置在安装了磁性标记的环境中。
- 系统变得不稳定的情况
- 标记未得到维护。
- 功能
- 通过检测磁标记可以在世界坐标上获得车辆位置。
- 即使道路被雪覆盖，该系统仍能正常工作。
4. 感知 Perception
感知接收来自传感、定位和地图的输入，并添加语义信息（例如，对象识别、障碍物分割、交通信号灯识别、占用网格地图），然后传递给规划模块。
感知组件由以下子组件组成：
-
物体识别：识别当前帧中车辆周围的动态物体、地图创建期间不存在的物体，并预测其未来轨迹。包括：
- 行人
- 汽车
- 卡车/客车
- 自行车
- 摩托车
- 动物
- 交通锥
- 道路垃圾：纸板、油桶、垃圾桶、木头等物品，掉落在道路上或漂浮在空中
-
障碍物分割：识别源自障碍物的点云，包括动态物体和静态障碍物，需要本车避开它们或在障碍物前停下。
- 其中包括：
- 所有动态对象（如上所列）
- 路缘/护柱
- 障碍
- 树木
- 墙壁/建筑物
- 不包括：
- 草
- 水溅
- 烟雾/蒸气
- 报纸
- 塑料袋
- 其中包括：
- 占用网格地图：检测盲点（没有信息且动态物体可能跳出的区域）。
- 交通信号灯识别：识别交通信号灯的颜色和箭头信号的方向。
支持的功能：
| 特征 | 描述 | 要求 |
|---|---|---|
| 基于 LiDAR DNN 的 3D 探测器 | 该模块以点云作为输入，并检测车辆、卡车、公共汽车、行人和自行车等物体。 | – 点云 |
| 基于相机 DNN 的 2D 检测器 | 该模块以摄像头图像作为输入，在二维图像空间中检测车辆、卡车、公共汽车、行人和自行车等物体。它检测图像坐标内的物体，无需提供 3D 坐标信息。 | – 相机图像 |
| LiDAR 聚类 | 该模块执行点云聚类和形状估计，以实现无标签的物体检测。 | – 点云 |
| 半规则检测器 | 该模块使用来自图像和点云的信息来检测物体，它由两个组件组成：LiDAR 聚类和基于相机 DNN 的 2D 检测器。 | – 基于相机 DNN 的 2D 检测器和 LiDAR 聚类的输出 |
| 基于Radar的 3D 探测器 | 该模块以Radar数据作为输入，检测动态3D物体。详细内容请参见此文档。 | – 雷达数据 |
| 对象合并 | 该模块整合了来自各种探测器的结果。 | – 检测到的物体 |
| 插值器 | 该模块通过使用跟踪结果维持长期检测结果来稳定对象检测结果。 |
– 检测到的物体 – 跟踪的物体 |
| 追踪 | 该模块为检测结果提供ID并估计速度。 | – 检测到的物体 |
| 预言 | 该模块根据地图形状和周围环境预测动态物体的未来路径（及其概率）。 |
– 跟踪物体 – 矢量地图 |
| 障碍物分割 | 该模块识别来自本车辆应避开的障碍物的点云。 |
– 点云 – 点云图 |
| 占用网格图 | 该模块检测盲点（没有可用信息且动态物体可能跳出的区域）。 |
– 点云 – 点云图 |
| 交通信号灯识别 | 该模块检测交通信号灯的位置和状态。 |
– 相机图像 – 矢量地图 |
具体方案：
5. 规划 Planning
规划模块主要为自动驾驶汽车生成目标轨迹，包括行驶路径、行驶速度等。由几个子部分组成：
- 任务规划：该模块利用地图数据计算从当前位置到目的地的路线。其功能类似于车队管理系统 ( FMS ) 或汽车导航路线规划。
-
规划模块：这些模块规划车辆执行指定任务的行为，包括目标轨迹、闪光信号等。它们分为行为和运动类别：
- 行为：专注于计算安全且符合规则的路线，管理车道变换、交叉路口入口和停车线停车的决策。
- 运动：与行为模块协同工作，确定车辆的轨迹，同时考虑车辆的运动和乘坐舒适度。它包括用于路线和速度计算的横纵向规划。
- 验证：确保计划轨迹的安全性和适当性，并具有应急响应能力。如果计划轨迹不合适，它会触发紧急协议或生成替代路径。
支持的功能：
6. 控制 Control
控制模块根据规划模块的参考轨迹，计算生成车辆订阅的控制信号。
控制组件由两个模块组成。
- trajectory_follower：生成车辆控制命令，以遵循从规划模块收到的参考轨迹。该命令包括例如所需的转向角和目标速度。
- vehicle_command_gate：负责过滤控制命令以防止异常值，然后将其发送给车辆。除了轨迹跟随器之外，此处还允许在多个源之间切换，例如 MRM（最小风险机动）模块或某些远程控制模块。
Autoware控制系统被设计为一个自动驾驶系统平台，可以兼容多种车辆。控制过程使用一般信息（例如目标加速度和减速度），而不使用车辆特定信息（例如制动压力）。因此，它可以独立于车辆的驱动接口进行调整，从而轻松实现集成或性能调整。通过切换控制车辆模型，可以解决两轮转向或四轮转向等影响车辆运动约束的显著差异，实现针对每个特性的专门控制。
车辆接口适配器：
7. 车辆 Vehicle
车辆接口组件提供 Autoware 和车辆之间的接口，将控制信号传递至车辆的线控驱动系统并接收传回 Autoware 的车辆信息。
Vehicle Interface与上下游的接口：
- 来自Control：
- 执行命令
- 目标加速度、制动和转向角
- 执行命令
- 来自Planning：
- 车辆特定命令（可选，每种类型有单独的消息）
- 转移
- 门
- 雨刮器
- ETC
- 车辆特定命令（可选，每种类型有单独的消息）
- 来自Vehicle：
- 车辆状态信息
- 车辆特定格式消息，用于转换为 Autoware 特定格式消息
- 速度状态
- 转向状态（可选）
- 班次状态（可选）
- 转向信号状态（可选）
- 驱动状态（可选）
- 车辆特定格式消息，用于转换为 Autoware 特定格式消息
- 车辆状态信息
Vehicle Interface组件的输出：
- 向车辆发送车辆控制信息
- 控制信号来驱动车辆
- 取决于车辆类型/协议，但至少应包括转向和速度命令
- 车辆状态信息发送至 Autoware
- 驱动状态
- 加速、制动、转向状态
- 车辆里程计（输出至定位）
- 车辆扭转信息
- 控制方式
- 有关车辆是否处于自动控制或手动控制的信息
- 班次状态（可选）
- 车辆换挡状态
- 转向信号状态（可选）
- 车辆转向信号状态
8. 节点图 Node
查看整体的节点关系图：
rqt_graph
四、总结
好了，今天就先到这里，Autoware看起来五脏俱全、便于扩展，还是挺有吸引力的，下一次就带大家一起实践一下看看实际效果怎么样。
参考：
