第二章：Autoware架构解析

好，咱们直接进入正题。Autoware这套系统，说白了就是自动驾驶界的“乐高积木”。你拿到手是一堆模块，怎么拼、怎么调，全看你对架构的理解有多深。我刚开始接触Autoware时，也被它的节点数量吓了一跳——光核心节点就有几十个。但摸清楚分层逻辑后，一切都清晰了。

2.1 软件架构分层

Autoware的架构，我个人习惯把它分成四层。你想想看，就像盖房子，地基、框架、装修、家具，缺一不可。

层级	名称	核心职责	典型模块
L1	感知层	看懂世界	LiDAR检测、摄像头识别、融合
L2	规划层	决定怎么走	路径规划、行为决策、速度规划
L3	控制层	执行指令	MPC控制器、PID、车辆接口
L4	系统层	调度与监控	诊断、日志、参数管理

嗯，这里要注意：分层不是绝对的。比如感知层输出的障碍物信息，规划层要用，控制层有时也要用。但分层的好处是——你调参数时，知道该去哪个文件夹里找。

2.2 核心节点通信机制

Autoware基于ROS 2，节点间通信靠的是话题（Topic）和服务（Service）。我见过不少新手，上来就问“为什么我的节点收不到数据？”——八成是话题名拼错了。

核心通信模式就三种：

• 发布-订阅：最常用。比如激光雷达节点发布/points_raw，感知节点订阅它。
• 服务-客户端：一问一答。比如“请给我一个全局路径”，规划节点响应。
• 动作（Action）：带反馈的长时间任务。比如“请泊车”，过程中不断汇报进度。

2.3 模块间数据流图

下面这张图，是我自己总结的核心数据流。你看一遍，基本就知道Autoware的“血液”是怎么流的了。

你看，数据从传感器进来，经过感知和定位“翻译”成环境信息，然后规划层“思考”出轨迹，控制层“动手”执行，最后车辆接口“喊”给底盘听。这个链条上任何一个环节出问题，车就跑偏。

2.4 配置文件体系介绍

Autoware的配置文件，说白了就是一堆YAML文件。你想想看，每个模块都有自己的“小本本”，记录着各种参数。我刚开始调参时，最头疼的就是“这个参数到底在哪个文件里？”

配置文件主要分布在三个地方：

• launch目录：启动参数，比如用哪个传感器、开哪些节点。
• param目录：算法参数，比如PID的Kp值、MPC的预测时域。
• config目录：车辆参数，比如轴距、最大转向角、车速限制。

举个例子，控制层的参数文件长这样：

# control_params.yaml
vehicle:
  wheel_base: 2.8        # 轴距，单位米
  max_steer_angle: 0.6   # 最大转向角，单位弧度
  max_accel: 3.0         # 最大加速度，m/s²

mpc:
  prediction_horizon: 50 # 预测步数
  weight_lat_error: 1.0  # 横向误差权重
  weight_heading_error: 0.8  # 航向误差权重

配置文件还有个特点：支持嵌套和继承。比如你有一个base_params.yaml定义通用参数，然后每个场景（高速、城区、泊车）可以继承它并覆盖部分参数。这样你就不用重复写几百行配置了。

嗯，说到这，我想起一个实用技巧：用ros2 param dump可以把当前运行的所有参数导出到一个文件。我每次调完车，都会导出一份，标注上“2024-03-15_晴天_高速测试_参数备份”。这样万一改坏了，还能回滚。

最后，记住一句话：Autoware的配置体系，就是你的“调参地图”。你越熟悉它，调起参数来就越得心应手。别怕改错，大不了重来——反正我当年就是这么过来的。