一、Autoware整体架构概览：核心模块与接口关系
大家好，我是老张。在自动驾驶集成这个行当摸爬滚打了六七年，经手过好几个基于Autoware的项目。今天咱们聊聊Autoware的整体架构。说实话，很多新手一上来就扎进代码里，结果越看越懵。我的建议是——先看架构图，再读代码。
Autoware的核心模块，说白了就四个：感知、规划、控制、定位。它们之间通过ROS 2的Topic和Service通信。嗯，这里要注意，接口设计的好坏，直接决定了你的系统能不能稳定跑起来。
核心观点：Autoware的架构是典型的“感知-决策-控制”闭环。感知负责“看”，定位负责“我在哪”，规划负责“怎么走”，控制负责“动起来”。
1.1 四大核心模块速览
我习惯把Autoware的模块分成两类：数据输入类（感知、定位）和决策输出类（规划、控制）。这样分，接口关系就清晰了。
| 模块 | 输入接口 | 输出接口 | 典型Topic |
|---|---|---|---|
| 感知 | LiDAR点云、Camera图像 | 障碍物列表、车道线、交通标志 | /perception/object_recognition/objects |
| 定位 | IMU、GPS、点云 | 车辆位姿（x, y, z, yaw） | /localization/kinematic_state |
| 规划 | 目标点、障碍物、位姿 | 轨迹（路径点+速度） | /planning/scenario_planning/trajectory |
| 控制 | 轨迹、当前位姿 | 油门、刹车、转向指令 | /control/command/control_cmd |
你看，每个模块的输入输出都很明确。我在项目中遇到过最头疼的问题，就是接口Topic的名字没对齐。比如感知模块发了/perception/objects，但规划模块订阅的是/perception/object_recognition/objects——结果车就是不动。排查了半天，原来是命名空间写错了。
1.2 接口关系：数据流怎么走？
数据流其实很简单。传感器数据进来，感知和定位模块各自处理，然后把结果发给规划模块。规划模块算出一条轨迹，再丢给控制模块去执行。你想想看，这不就是人的驾驶过程吗？眼睛看路（感知），脑子判断位置（定位），决定怎么走（规划），手脚操作（控制）。
下面这张图是我自己画的，把核心数据流和接口关系都标出来了。
小技巧：调试接口时，用ros2 topic list和ros2 topic echo查看实际发布的Topic。我曾经靠这个命令，半小时就定位了一个接口不匹配的bug。
1.3 接口适配的常见坑
做接口适配，说白了就是让不同模块的数据格式能对上。我总结了几条经验：
- 坐标系要统一：感知模块输出的障碍物坐标，是传感器坐标系还是车辆坐标系？规划模块用的是map坐标系还是odom坐标系？搞混了，车就会往奇怪的方向开。我记得有个项目，定位模块输出的是ENU坐标系，但规划模块默认用的是UTM坐标系——结果轨迹偏了十几米。
- 时间戳要对齐：每个消息都有时间戳。如果感知消息的时间戳比控制消息还晚，那控制模块就是在用“过去的数据”做决策。我曾经遇到过，因为时间戳没对齐，车辆在高速上急刹车——吓出一身冷汗。
- 数据类型要匹配：比如规划模块输出的是
autoware_auto_planning_msgs::msg::Trajectory，控制模块接收的也是这个类型。但如果你自己写了一个节点，把类型改成了nav_msgs::msg::Path——对不起，编译能过，运行就报错。
警告：千万不要在接口适配时随意修改消息定义。如果非改不可，记得同步更新所有相关模块的依赖。我曾经因为改了一个字段名，导致三个模块同时崩溃——那周我加了三天班。
1.4 我的调试习惯
最后分享一个我个人的调试习惯。每次拿到一个新的Autoware版本，我会先做三件事：
- 跑一遍官方Demo：确认基础功能正常。如果Demo都跑不通，那肯定是环境问题。
- 检查Topic列表：用
ros2 topic list对比官方文档，看看有没有缺失的Topic。少了任何一个，都意味着某个模块没启动。 - 手动发一个测试消息：比如用
ros2 topic pub发一个虚拟的障碍物消息，看看规划模块会不会响应。这样能快速验证接口是否通。
嗯，这套流程帮我省了不少时间。你想想看，如果等到实车测试才发现接口问题，那代价就大了。
好了，这一章就聊到这儿。记住，理解架构是第一步，接口适配是基本功。下一章咱们深入聊聊感知模块的接口细节。