Autoware 是一个面向自动驾驶汽车的开源软件框架，建立在 ROS 2 机器人操作系统之上。它并不是某一种单独的目标检测算法、路径规划算法或车辆控制程序，而是一套覆盖“传感器输入—定位—环境感知—行为决策—轨迹规划—车辆控制”的完整自动驾驶软件栈。
它的目标，是让高校、科研机构、汽车企业、自动驾驶公司和车辆集成商不必从零开发整套自动驾驶系统，而是在统一接口和软件架构下，更换传感器、车辆底盘或算法模块。Autoware 官方将其定位为可支持机器人出租车、自动配送、自动驾驶巴士、接驳车和私人乘用车等应用的平台。项目采用 Apache 2.0 许可证，允许研究、修改和商业使用。(Autoware Foundation)
截至 2026年7月18日，Autoware 元仓库最新正式版本为 1.9.0，发布于2026年7月16日；项目按照语义化版本管理，通常约每月发布一次。需要注意的是，官方部分安装文档中的命令示例仍以1.8.0为例，因此实际部署时应以仓库的正式发布标签和对应 .repos 文件为准。(GitHub)
一、项目发展过程
Autoware 项目由加藤真平于2015年在日本名古屋大学发起。最早的版本称为 Autoware.AI，基于 ROS 1，是较早提供定位、感知、规划和控制完整链路的开源自动驾驶软件之一。
2018年，Autoware Foundation 成立，负责项目治理、技术路线、社区协作和产业推广。2019年前后，项目开始开发基于 ROS 2、更加重视软件工程质量的 Autoware.Auto。Autoware.Auto 并不是对 ROS 1 版本的简单移植，而是围绕自动泊车、货物配送等明确的运行设计域重新设计架构、接口、测试和文档。(Autoware)
但 Autoware.Auto 的严格准入和质量要求，也提高了科研人员贡献新算法的门槛。为同时兼顾稳定性和前沿算法试验，项目后来转向目前的 Autoware Core/Universe 模式：
- Core 提供稳定、经过较严格测试的基础功能；
- Universe 容纳更新、更丰富、迭代速度更快的算法和功能；
- 成熟的 Universe 模块可以经过评审后进入 Core。
Autoware.AI 已停止作为主线发展，Autoware.Auto 也不再是最新代码入口，当前用户应使用 GitHub 上的 Autoware Core/Universe 体系。(Autoware)
二、Autoware 的总体工作原理
其典型数据链路可以概括为：
摄像头、激光雷达、毫米波雷达、GNSS、IMU、车轮速度
↓
Sensing 传感器处理
↓
Map 地图 ── Localization 定位
↘ ↓
Perception 感知
↓
Planning 规划
↓
Control 控制
↓
Vehicle Interface 车辆接口
↓
转向、制动、驱动、挡位、灯光等执行机构
Autoware 当前的架构文档把主要驾驶功能划分为七个部分：Sensing、Map、Localization、Perception、Planning、Control 和 Vehicle Interface。系统监控、诊断、API、仿真和开发工具则作为支撑层存在。(Autoware Foundation)
Autoware 将这种设计称为 Microautonomy Architecture，微自治架构。它把自动驾驶拆成许多输入输出明确的小模块。例如，可以将默认的激光雷达目标检测器换成自研神经网络，而下游跟踪、预测和规划模块不必全部重写。
这种结构的优点是模块可替换、方便科研验证和多团队协作；缺点是 ROS 话题传输、数据复制、节点调度和模块间延迟会增加系统开销，因此真实车辆部署不能只关注平均计算速度，还要关注各节点截止时间、时延抖动和最坏情况执行时间。(Autoware Foundation)
三、Sensing：传感器与数据预处理
Sensing 层的任务不是理解环境，而是把来自不同厂商、不同通信接口的原始传感器数据，转换为下游模块可以稳定使用的 ROS 2 消息。
典型输入包括：
- 激光雷达点云；
- 摄像头图像；
- 毫米波雷达目标或点云；
- GNSS/INS 数据；
- IMU 加速度和角速度；
- 轮速、转角、车速和车辆 CAN 信息；
- 部分场景下的超声波雷达。
这一层通常完成坐标转换、时间戳处理、畸变校正、点云拼接、降采样、地面与噪声过滤、雷达数据适配、图像解压和传感器状态诊断。Autoware Universe 中已经包含点云时间同步、运动畸变校正、体素降采样、离群点过滤、雷达静态点过滤以及 CUDA 加速点云预处理等模块。(Autoware Foundation)
真实车辆上，Sensing 层往往是集成工作量最大的部分之一。传感器时间同步、外参误差、网络丢包、点云延迟或错误的 TF 坐标关系，都会继续传递到定位和感知模块。因此，“驱动已经能够发布数据”并不等于传感器已经满足自动驾驶要求。
四、Map：点云地图和语义地图
Autoware 的经典方案具有较明显的高精地图依赖，通常使用两类地图。
点云地图一般以 PCD 等形式保存道路周边建筑、路灯杆、护栏和其他静态结构，用于激光雷达定位。车辆实时点云与地图点云匹配，可以估计车辆在地图中的位置。
矢量地图主要采用 Lanelet2 格式，描述车道中心线、车道边界、行驶方向、限速、交叉口、停止线、人行横道、交通信号灯、减速带和禁停区域等语义信息。规划器依据这些信息理解“哪里可以行驶”“哪里必须停车”“当前车道连接到哪条车道”。(Autoware Foundation)
可以简单理解为：
- 点云地图主要回答“车辆现在在哪里”；
- Lanelet2 矢量地图主要回答“道路规则和拓扑结构是什么”。
Autoware 并非所有配置都必须同时使用两类地图。例如，官方定位设计允许 GNSS 主导或部分无地图定位方案；但对于城市道路上的参考全栈配置，点云地图与 Lanelet2 地图仍然非常重要。
五、Localization：车辆定位
定位模块要持续输出车辆的：
- 位置和姿态 Pose；
- 线速度和角速度 Twist；
- 加速度 Accel；
- 协方差和定位可信度；
map → base_link坐标变换；- 定位异常诊断信息。
Autoware 常见的定位链路是：
GNSS 提供全局初始位置
↓
激光雷达点云与点云地图进行 NDT 匹配
↓
IMU、轮速和车辆里程计提供高频短期运动信息
↓
滤波器融合多个定位结果
↓
输出车辆在地图中的连续位姿
官方能力说明中将 NDT 点云匹配与 GNSS、IMU 里程计融合作为典型高精度定位方案。其定位设计允许使用不同传感器组合，包括 LiDAR、摄像头视觉定位、GNSS、轮速、IMU、地磁传感器和磁钉定位等。(Autoware Foundation)
Autoware Universe 还包括定位误差监控、姿态不稳定检测、不同定位器结果仲裁、地标定位以及 YabLoc 视觉定位等模块。这说明 Autoware 的定位层不是固定为单一 NDT 算法，而是预留了多定位源融合和替换能力。(Autoware Foundation)
定位质量直接决定自动驾驶系统的上限。即使目标检测完全正确，只要车辆在地图中横向偏移几十厘米，规划器就可能误认为车辆压线或进入相邻车道。
六、Perception：环境感知
感知层接收传感器、定位和地图数据，为环境添加语义信息，主要包括四类输出：
目标识别、跟踪和预测。
识别汽车、卡车、公交车、行人、自行车、摩托车、交通锥等对象，给每个目标分配持续 ID，估计其速度、朝向，并预测未来运动轨迹。
障碍物分割。
从点云中提取墙体、护栏、路缘、树木、静止车辆等需要绕行或停车的障碍物。
占用栅格。
把周围空间划分为可通行、已占用或未知区域，帮助规划器处理盲区和非结构化环境。
交通信号灯识别。
结合 Lanelet2 地图中交通灯位置，从摄像头图像裁剪候选区域，再完成灯色和箭头方向分类。
当前 Universe 中可以看到 BEVFusion、CenterPoint、TransFusion、摄像头 StreamPETR、YOLOX、欧氏聚类、地面分割、多目标跟踪、地图约束预测以及多摄像头交通灯融合等模块。它既保留传统的几何聚类和规则处理，也集成了大量深度学习感知算法。(Autoware Foundation)
这种组合很有实际意义：神经网络检测能力强，但可能存在漏检和误检；几何点云方法不需要训练数据，但不容易准确分类。Autoware 可以将多种检测结果融合，再进行验证、跟踪和预测。
七、Planning：决策与轨迹规划
Autoware 的规划不是一个单独算法，而是分层完成。
1. Mission Planning
任务规划根据起点、终点和 Lanelet2 道路拓扑生成全局路线。例如确定应依次经过哪些车道、路口和道路。
2. Behavior Path Planning
行为路径规划决定空间上的驾驶动作，例如：
- 保持当前车道；
- 向左或向右变道；
- 绕过静态障碍物；
- 从路边或停车位起步；
- 靠边停车；
- 侧向偏移；
- 进入停车区域。
3. Behavior Velocity Planning
行为速度规划处理道路规则和交通场景，例如：
- 停止线停车；
- 红灯停车；
- 通过交叉口；
- 礼让人行横道；
- 盲区减速；
- 检测区域停车；
- 减速带限速；
- 禁停区处理；
- 虚拟交通信号灯。
4. Motion Planning
运动规划把行为层给出的路径进一步平滑、优化和赋予速度，使轨迹满足车辆运动学约束、舒适性限制、曲率限制以及障碍物安全距离。
停车或无明确车道的区域还可以使用 freespace planner，官方模块中包括 RRT* 等自由空间搜索算法。(Autoware Foundation)
Autoware 目前仍以模块化、规则式规划为主体，但 Universe 已包含 Diffusion Planner、轨迹排序器、安全过滤器、QP 轨迹平滑器和交通规则过滤器等学习式或混合式规划组件。这表明项目正在从纯规则流水线，逐步扩展到规则规划、学习式规划和端到端模型并存的结构。(Autoware Foundation)
八、Control：车辆控制
规划模块输出期望轨迹，控制模块负责让车辆实际跟随这条轨迹。
横向控制解决方向盘怎么转，常见模块包括：
- MPC 模型预测控制；
- Pure Pursuit 纯跟踪；
- 智能 MPC 轨迹跟踪。
纵向控制解决油门和制动怎么控制，Autoware 提供 PID 纵向控制器等实现。
此外，控制层还包括：
- 自动紧急制动；
- 碰撞检测；
- 车道偏离检查；
- 轨迹有效性验证；
- 控制命令选择和门控；
- 自动驾驶、遥控驾驶、手动驾驶之间的模式切换；
- 停止模式和紧急模式处理。(Autoware Foundation)
控制输出通常不是直接操作某个特定品牌车辆的 CAN 报文，而是输出标准化的转向、速度、加速度、制动和挡位指令，再交给 Vehicle Interface 转换。
九、Vehicle Interface：车辆底盘适配
Vehicle Interface 是 Autoware 与真实车辆之间的边界。
向下，它需要连接车辆线控系统，包括：
- 线控转向；
- 线控制动；
- 驱动电机或发动机控制；
- 挡位；
- 驻车制动；
- 转向灯和危险警示灯；
- 车门等附属设备。
向上，它把车辆实际车速、方向盘角度、挡位、制动状态和驾驶模式转换为 Autoware 标准消息。
因此，同一套 Autoware 感知和规划代码可以运行在不同车辆上，但每种车辆通常都需要开发或适配自己的 Vehicle Interface。官方集成教程分别提供车辆模型、传感器模型、Ackermann 转向车辆以及差速驱动车辆的适配说明。(Autoware Foundation)
普通量产汽车即使具备 ACC 或车道保持功能，也不一定开放完整的转向、制动和驱动控制接口。要运行 Autoware，车辆通常需要经过线控改装，或者本身就是开放线控接口的开发平台。
十、系统监控、故障处理和外部接口
Autoware 不只有驾驶算法，还包含系统级支撑模块，例如：
- CPU、GPU、内存、硬盘和网络监控；
- NTP 时间同步监控；
- 节点重复检查；
- 处理时间和流水线延迟监控；
- 组件状态聚合；
- 诊断关系图；
- 定位、感知、规划和控制评估器；
-故障注入工具； - 最小风险策略 MRM；
- 舒适停车和紧急停车处理。(Autoware Foundation)
Autoware 还定义了 AD API，用于把内部大量 ROS 话题封装为相对稳定的外部接口。HMI、远程驾驶系统、车队管理平台、调度系统或其他应用可以通过这些接口获取车辆状态、设置路线、切换运行模式和查询诊断信息。
相应的消息定义分布在：
autoware_msgs：主要模块之间通信；autoware_internal_msgs：模块内部通信；autoware_adapi_msgs：Autoware 与 HMI、远程操作、车队管理和仿真系统之间通信。(Autoware Foundation)
十一、代码仓库结构
Autoware 并不是只有一个包含全部源代码的仓库。顶层 autoware 仓库更像一个发行版和工作区管理仓库，保存依赖版本、Docker、Ansible、开发环境和 .repos 文件。
主要代码仓库包括：
autoware_core
保存自动驾驶所必需、质量要求较高、经过较严格测试的包，包括感知、定位、规划和控制基础模块。
autoware_universe
保存更丰富、更前沿或具有试验性质的模块，由基金会和社区共同维护。
autoware_launch
保存不同运行配置的启动文件，可以启动完整仿真、规划仿真、真实车辆配置或 rosbag 回放配置。
autoware_tools
保存调试、可视化、分析和开发工具，通常不参与车辆实际自动驾驶运行。
autoware_utils
保存数学、几何、系统和其他公共工具库。(Autoware Foundation)
Autoware Universe 的代码以 C++ 为主。2026年7月的 GitHub 统计约为 C++ 90.9%、Python 4.1%、CUDA 3.2%，说明核心实时节点主要采用 C++，Python 更多用于工具、模型和辅助脚本，GPU 算法则通过 CUDA、TensorRT 等执行。(GitHub)
十二、开发环境和安装方式
官方支持 amd64 和 arm64 架构。给出的通用最低建议配置为：
- 8核 CPU；
- 16GB 内存；
- 可选 NVIDIA GPU，显存至少约4GB。
基础定位、规划和控制可以不使用 GPU，但激光雷达神经网络目标检测、摄像头目标检测和交通灯识别等功能通常需要 GPU。实际运行完整多传感器系统时，4GB显存往往只适合最低限度测试，工程车辆通常需要更强的计算平台。(Autoware Foundation)
常用安装方式有三种：
- Docker 镜像；
- 从源代码编译；
- Debian 软件包。
Docker 同时提供 amd64、arm64、普通版和 CUDA 版，并提供 ROS 2 Humble 与 Jazzy 镜像。源码安装文档目前主要以 Ubuntu 22.04 和 ROS 2 Humble 为例。构建过程使用 vcs/vcs2l 获取多仓库代码，使用 rosdep 安装依赖，使用 colcon 和 CMake 编译；官方还提供 Ansible 自动配置开发环境。(Autoware Foundation)
十三、仿真与测试
Autoware 支持多种测试层级。
规划仿真只运行地图、规划和控制相关模块，用虚拟车辆和虚拟障碍物验证变道、避障、停车、交叉口和人行横道逻辑。
Rosbag 回放使用真实车辆曾经记录的传感器数据，重复运行定位或感知算法，适合算法调试和版本对比。
场景仿真通过预设交通参与者、道路条件和事件，自动验证车辆行为。
数字孪生仿真可以使用 AWSIM，也提供 CARLA、MORAI 和 PanoSim 等集成路径。官方快速演示包括 AWSIM 完整自动驾驶演示、Lane Driving、Parking、Lane Change、Avoidance 和交通灯识别等场景。(Autoware Foundation)
仿真能够验证算法功能，却不能完全替代真实道路测试。真实车辆还会面临传感器振动、时间同步漂移、轮胎侧偏、制动延迟、执行器死区、阳光反射、雨雪、遮挡和车辆网络异常等问题。
十四、将 Autoware 部署到一辆真实车辆需要做什么
从“成功运行官方仿真”到“车辆能够自动驾驶”，通常需要完成以下工程：
- 明确运行设计域 ODD，例如封闭园区、固定公交线路或城市道路；
- 选择并安装摄像头、激光雷达、雷达、GNSS/INS 和计算平台；
- 编写或集成各传感器 ROS 2 驱动；
- 完成相机内参、传感器外参和时间同步标定；
- 建立点云地图和 Lanelet2 矢量地图；
- 建立车辆尺寸、轴距、转向限制和动力学参数；
- 开发线控底盘 Vehicle Interface；
- 调整定位、感知、规划和控制参数；
- 在仿真、台架和封闭场地逐级测试；
- 增加独立安全控制器、紧急停车、冗余电源和通信监控；
- 根据所在国家或地区完成道路测试许可、安全论证和监管要求。
官方教程本身就是按照“创建车辆与传感器模型—传感器标定—车辆接口—创建地图—启动各模块—参数调优—性能评估”的路径组织的。这也说明 Autoware 是一个工程平台，而不是安装后即可直接接管任意汽车的应用程序。(Autoware Foundation)
十五、Autoware 的主要优势
Autoware 最显著的价值是完整性。许多开源项目只解决检测、SLAM 或规划中的一个问题，而 Autoware 提供完整车辆闭环。
第二个优势是模块化。研究人员可以只替换一个定位器、感知器或规划器，而不必重新开发整套系统。
第三个优势是ROS 2 生态兼容性。大量机器人传感器驱动、可视化工具、录包工具和通信机制都可以复用。
第四个优势是同时服务科研与工程应用。Universe 允许快速引入新算法，Core 则强调接口稳定、测试和发布管理。
第五个优势是配套工具比较完整。地图、标定、RViz 可视化、诊断、仿真、故障注入、性能评估和容器化环境基本都有相应入口。
十六、局限和实际使用难点
Autoware 的最大难点不是下载或编译，而是系统集成。多传感器时间同步、标定、地图制作、底盘控制和参数调优需要自动驾驶、机器人、车辆工程、网络和嵌入式等多方面知识。
其次，完整 Universe 的节点和依赖数量较多，启动文件、参数文件、TF 树和 ROS 话题关系复杂。版本升级时，消息接口、参数名称、模型文件和仓库组合也可能发生变化，因此实际项目通常会锁定一个正式版本，而不是长期跟随 main 分支。
再次，Autoware 的参考方案总体上仍然偏向预先定义 ODD、固定传感器方案和地图驱动型 L4 自动驾驶。它可以扩展到端到端模型或弱地图方案，但这些能力并不意味着现有默认配置可以在所有道路和天气条件下自动工作。
最重要的是，开源和“具备完整软件栈”不等于已经获得功能安全认证。真实商业车辆还需要针对硬件故障、软件失效、网络中断、传感器遮挡和超出 ODD 等情况设计独立安全机制。Autoware 的早期架构文档也明确指出，最初的驾驶架构没有完整覆盖冗余、实时性、HMI 和故障安全等全部问题；虽然现在 Universe 已加入诊断、MRM、系统监控和紧急停车模块，但整车安全仍然是车辆集成方的系统工程责任。(Autoware Foundation)
总体评价
Autoware 可以理解为自动驾驶领域类似于“ROS 2发行版加参考自动驾驶产品架构”的项目。它既包含可直接运行的算法，又定义了接口、消息、启动方式、测试方法和车辆集成流程。
对于高校和科研团队，它适合研究多传感器融合、定位、感知、规划和控制算法；对于企业，它适合作为园区接驳车、低速物流车、自动驾驶巴士和机器人出租车的基础软件平台；对于个人开发者，它最适合从 AWSIM 或规划仿真入门，而不适合在缺少线控车辆、地图、传感器和安全测试条件时直接尝试公开道路自动驾驶。
它的核心价值并不是提供某个“最强算法”，而是提供一套开放、可组合、能够把大量算法连接成完整车辆闭环的工程基础。