做ROS2小车最难的不是跑通仿真，而是仿真里一切完美，一上车就露馅。这句话我这两年听同行说过无数次，自己也在ROS2+Autoware这套组合上反复踩过坑。ROS2解决了机器人通信的实时性和分布式问题，Autoware则把感知、定位、规划、控制这些自动驾驶核心模块全部开源出来，两者放在一起，理论上可以快速搭出一台能自动驾驶的小车。但“理论上”和“实车上”之间，隔着一整个工程化的距离。
这篇文章是我从零开始做这套ROS2+Autoware小车，从仿真环境一步步走到实车部署的完整记录。内容包括整体技术路线怎么定、仿真环境怎么搭、上车前要准备什么、核心模块怎么适配，以及最后实车调参时那些文档里查不到的坑。适合那些已经有ROS基础、想往自动驾驶方向进阶，或者是准备拿ROS2小车做课题、竞赛、毕设的同学参考。你会看到的不只是命令和配置，更是我踩过一遍之后沉淀下来的判断标准。
1. 一条从仿真到实车的主线：先把框架吃透，再把变量一个一个换成真的
1.1 为什么是ROS2+Autoware，而不是从零手写
很多做机器人的人有个误区，觉得自动驾驶小车嘛，自己写一套感知规划控制也就几个月的事。真上手你会发现，光是一个可靠的激光雷达点云地面分割，就能耗掉你大量时间；再到目标检测、跟踪、轨迹预测、行为决策、路径规划、横纵向控制，每一层都有无数细节。与其从零开始重复造轮子，不如站在成熟框架上做二次开发，把精力花在理解系统和解决实车问题上。
选ROS2的原因很实际。ROS1的单master架构在实车上会很吃力：车上有激光雷达、相机、GNSS、IMU、底盘控制器，可能还有独立的算力平台，数据流一大，ROS1的节点通信在弱网或无中心节点场景下就容易出问题。ROS2基于DDS，天生支持多机分布式部署，节点发现、QoS策略、生命周期管理都是为真实系统设计的，这对一辆车、多个传感器、一个工控机的拓扑来说更合适。另外ROS2在时间同步、参数动态配置、日志回放这些工程能力上也比ROS1扎实。
选Autoware的理由更简单：它是目前开源自动驾驶框架里模块最完整的那个，整个pipeline是闭环的。点云预处理、目标检测、定位、地图管理、行为规划、控制输出，链路上每个节点都能独立跑起来，也都有对应的参数可以调。更重要的是，Autoware的设计思路就是面向实车而不是仿真，很多节点天然就考虑到了传感器噪声、执行延迟这些真实因素。
不过也要泼一盆冷水：Autoware不是拿来即用的玩具，它的复杂度相当高。如果你只是想让小车沿着线走一圈，用它反而是负担，手写一个纯追踪控制加简单避障就够了。我建议把Autoware定位成“学习自动驾驶完整架构的母体”，用它理解模块之间的关系，再按需替换或裁剪自己的模块。
1.2 仿真与实车的差距到底在哪
仿真跑得好好的，上车就翻车，原因基本逃不出这几类：话题和帧率不一致、时间戳对不齐、TF树混乱、传感器特性差异、执行器响应延迟。
先说话题层面的问题。仿真器里的传感器节点是你自己配置的，话题名称、消息类型、发布频率都随你定。实车上的传感器驱动则五花八门，16线雷达和某个相机的驱动都是各厂商风格，话题名可能叫/lidar_points，也可能是/points_raw，频率可能稳定在10Hz也可能上下跳。ROS2虽然可以用remap把话题名映射对齐，但消息里的时间戳、坐标系ID不对齐，下游节点照样会把数据当垃圾丢掉。
再说物理层差异。仿真里的激光雷达点云是理想模型，没有反射率不均匀、没有去玻璃吸收、没有遮挡盲区，目标检测模型在仿真数据上跑得准，不代表在真实点云上也准。相机更是如此，真实环境的光照变化、曝光抖动、运动模糊，仿真里都复现不彻底。
执行层差异往往最容易被忽略。仿真里你发布一个速度指令，车马上就响应；实车有底盘控制器的加速度限制、CAN通信延迟、电机响应滞后，同样的控制参数在仿真里稳定，实车就会来回振荡甚至冲出边界。
所以我的经验是：仿真的价值在于验证逻辑链路，而不是验证参数。参数一定是以实车为准，仿真只能帮你把方向定对。
1.3 一条可行的学习路线
结合我做下来的过程，推荐这样一条路线：
第一步，在纯仿真环境里把整套Autoware跑通，理解每个模块的输入输出，知道一个点云进来之后经过了哪些节点才变成控制指令。第二步，用自己的小车采集真实数据，在离线状态下把感知、定位模块跑在ros2 bag上，复现仿真链路。第三步，做传感器标定和时间同步，这是从仿真跨到实车的关键卡口。第四步，在场地上做限制条件下的闭环测试，先低速、无碰撞物，逐步放开。第五步，反复调参并记录，把仿真参数和实车参数对照，形成自己的参数表。
不推荐直接跳过仿真上车，除非你对所有模块已经熟到闭眼能画出数据流图。更不推荐在仿真里折腾一两个月不碰车，因为很多仿真里的问题在实车上根本不存在，反之亦然。最好的节奏是仿真理解架构，实车验证参数，两者交替迭代。
2. 仿真阶段：先让Autoware在你电脑上完整跑起来
2.1 环境准备：硬件达标是关键
Autoware本身是个吃资源的框架。我最初在一台只有16GB内存的旧笔记本上尝试，编译过程中直接内存溢出，后来加到了24GB，跑仿真时CPU和GPU也是顶着用。如果想顺畅体验，建议至少满足这些条件：32GB内存起步，显卡显存不低于8GB，CPU核心数不低于8核，固态硬盘预留80GB以上空间。别在这个环节省预算，否则会把大量时间浪费在等待和排查环境问题上。
系统方面，推荐Ubuntu 22.04搭配ROS2的对应版本。这里有个经验之谈：除非你很清楚自己在做什么，否则优先用Autoware官方推荐的版本组合。不同ROS2版本对应的DDS实现有差异，Autoware某些模块对特定版本的依赖非常敏感，用非推荐组合会引入一堆编译和运行期奇怪问题。
安装方式上，强烈建议用Docker镜像而不是源码编译。Autoware的依赖项非常多，源码编译对网络和编译环境要求极高，初学者很容易卡在某个依赖上。Docker方式的好处是环境隔离、可复现性强，官方镜像已经把大部分依赖都装好了，你只需要挂载自己的工作空间和配置文件就能跑。
当然，用Docker也有个坑：你无法直接访问宿主机上的GPU显卡直通和共享内存配置。解决方案是启动容器时带上GPU相关的参数，并确保/dev/shm足够大，否则点云处理这种高频数据在容器内会频繁阻塞。
2.2 仿真世界的搭建要点
仿真环境里，地图是绕不开的第一件事。Autoware对地图有一套要求：至少要有高精度的栅格地图或点云地图用来做定位，还要有可用于规划的Lanelet2地图文件。如果你没有现成地图，可以在某个仿真器里自己建一个封闭场地，画好车道线和人行道，导出PCD点云和Lanelet2的OSM文件。这个过程我第一次做的时候觉得很枯燥，但它值得花时间，因为后续所有调试都在这张地图上进行。
车辆模型方面，要给小车挂上激光雷达、相机、IMU、里程计模型，并把它们的坐标系、安装位置配置好。这里有一个很重要的细节：仿真里的传感器模型位置要和后续实车安装位置尽量保持一致，哪怕是几厘米的偏差，都会影响标定参数和坐标变换的一致性。
动态障碍物也不能省。如果仿真里只有一辆车在路上跑，那只能验证规划和控制的基本逻辑，感知模块基本是摆设。加几辆虚拟社会车辆和行人模型之后，才能在仿真里看到目标检测和轨迹预测的完整工作流，这对理解Autoware的感知行为很有帮助。
启动仿真环境后，先不要急着启动整套Autoware，先用ros2 topic list确认传感器话题都出来了，再检查TF树是否完整。TF树这种问题在仿真里就检查清楚，能省掉后面实车排查的大把时间。
2.3 跑通Autoware Demo的启动顺序与验证方法
第一次跑起来的启动顺序建议固定下来，形成肌肉记忆：先启动仿真器，再启动地图加载和定位模块，看到定位点云正常匹配之后，再启动感知和规划控制模块。如果一上来就把所有launch文件都拉起来，一个报错会混着另一个报错，根本无从下手。
启动之后，重点观察几类数据。第一是话题频率，用ros2 topic hz查看关键话题的发布频率，点云、图像、里程计、控制指令这些频率异常基本都能说明问题。第二是可视化工具里的小车状态，看地图点云和实时点云的匹配是否稳定，目标检测框是否合理，规划的轨迹是否平滑。第三是日志，ros2 node list配合rqt_graph确认节点之间的订阅发布关系是否和设计一致。
这时候如果发现规划轨迹抖动、目标框跳变，不用急着改参数，先记录当时的场景和话题数据，用ros2 bag存下来离线分析。仿真阶段养成数据回放的习惯，实车阶段会非常受益。
跑通一次Demo后，我建议你做一个动作：手动控制小车走一圈，同时记录ros2 bag，然后离线把bag重新喂给Autoware的感知和定位链路。这个操作能帮你理解数据驱动的调试方式，也是后面实车验证的关键技能。
3. 上车之前的功课：传感器选型、时间同步、标定一个都不能省
3.1 实车传感器和计算平台怎么搭配
传感器选型直接决定了算法效果的上限。很多初学者喜欢用相机做纯视觉方案，但Autoware对激光雷达的依赖还是比较重的，定位和感知的主干路径都是以点云为主。我的建议是配置一套基本的“雷达+相机+IMU/GNSS”组合。
激光雷达选16线起步，测距能力30米以上，扫描频率10Hz，角分辨率不能太差。16线雷达价格相对友好，正好能支撑起Autoware里定位和感知的绝大多数功能。相机方面，720p@30fps是最低门槛，不要选卷帘快门太差的工业相机，否则运动畸变会让目标检测很痛苦。IMU和GNSS也是必须的，IMU负责短时高频率姿态更新，GNSS负责绝对位置约束。
计算平台选型可以按算力来推：摄像头目标检测、点云目标检测、NDT定位、路径规划这几个任务同时跑，需要至少50到100 TOPS的算力才比较从容。我用的是一款国产工控板卡，算力不到80 TOPS，跑轻量化模型刚好，但一旦把点云分辨率调高就明显掉帧。低算力平台上的解法是降低模型推理分辨率、减少点云裁剪范围，但这是有上限的，加算力永远是最直接的手段。
除了算力，供电和散热也是上车前要解决的事。小车运行中会有瞬时高功耗，电源线径不够、稳压不足，会直接把工控机或者传感器打挂。强烈建议给计算平台配一个车载直流稳压模块，并做负载测试再上车。
3.2 时间同步：很多跑飞问题的根源
我在实车调试中遇到的最诡异的问题就是目标检测框和点云对不上，明明雷达和相机都检测到了障碍物，但融合结果里目标位置乱跳。折腾半天，根源是时间戳没对齐。
时间同步的重要性可以用一个生活场景类比：几个人要合唱一首歌，如果每个人按照自己手机的时间开始唱，节奏必然乱，必须有一个人喊口令对齐起拍。传感器也一样，激光雷达、相机、IMU、GNSS各自有自己的时间源，时间基准不同，融合算法拿到的数据就是“乱唱”的。
实车上常用的方案有两种：一是硬件层的PTP方案，雷达和相机驱动支持PTP协议，由主控板做Grandmaster，传感器做Slave，可以达到微秒级同步；二是软件层的近似时间同步，用message_filters::ApproximateTimeSynchronizer或者Autoware自带的同步节点，把时间戳相近的消息打包后送入融合模块，精度在毫秒级。
我的经验是，如果传感器都支持PTP，优先做硬件同步，省心且可靠。如果不支持，至少保证各传感器话题的时间戳都能正确映射到同一时区，并在驱动层面做时间戳校正，再叠加软件同步，才能稳定工作。每次上车前，用ros2 topic hz --window 100检查一下所有关键话题的频率稳定性，时间同步异常时频率往往也会异常。
3.3 标定实操：相机内参、相机激光雷达外参、雷达车体外参
标定是仿真里完全没有、实车必须做的一件事。许多人跳过标定直接把仿真参数搬到实车，结果感知距离不准、定位漂移、融合错乱，最后百思不得其解。
首先是相机内参标定。用棋盘格加标定板拍摄多组不同姿态的图片，通过标定工具解算相机内参矩阵和畸变系数。这个步骤要注意棋盘格要够大、纹理清晰、光照均匀，拍摄角度要覆盖中心、边缘、近处、远处，样本量至少30组。内参标定不准确，后面的外参也不用谈。
然后是相机和激光雷达的外参标定。需要一个带反射面的标定板，同时被相机看到、被雷达扫描到。通过点云中的角点或反射强度特征与图像中的棋盘格角点建立对应关系，求解出雷达坐标系到相机坐标系的变换。这个步骤的花费时间占比最高，因为要采集多帧数据并且剔除匹配误差较大的帧。
再是雷达和车体外参标定。将小车停在一个平整地面上，手动测量雷达相对于车体中心的位置和安装角度，再结合IMU的姿态估计做一次优化近似的初始对齐。这一步没有想象中那么精确没关系，因为后续定位模块往往会有一个“静态TF校准”环节，可以由NDT匹配结果反向修正外参误差。
标定完成后，一定要做验证，而不是直接信任结果。将标定参数写入系统后，把雷达点云投影到图像上，如果投影的物体边缘能与图像中物体边缘对准，说明标定结果可用；如果对不齐，就要回去检查标定板数据，而不是靠调参数硬凑。
标定的完整流程我建议至少预留一个完整工作日，急不得。赶时间的后果是，上车后每几分钟出一个怪问题，排查时间远超标定时间。
4. 核心模块落地：从感知到控制，仿真参数要换的远不止速度值
4.1 感知模块：点云预处理和目标检测的实车适配
Autoware的感知链路大致是：原始点云经过点云预处理（降采样、地面滤除、兴趣区域裁剪）后，送入目标检测节点，输出障碍物目标列表，再送入跟踪节点做多目标跟踪。
仿真里点云预处理参数可以直接默认，因为仿真数据干净。实车数据则不然，地面上多余的噪点、护栏和墙面反射点、远处稀疏点，都需要通过裁剪范围、高度阈值、距离阈值去过滤。我调试时会把裁剪范围设成车前方30米、左右各15米，高度范围限制在-1米到3米之间，超出这个范围的点云一律滤除。阈值设太大会引入大量无效计算，太小又会丢失关键障碍物，需要反复根据场地情况调整。
目标检测方面，Autoware默认的模型在仿真点云上表现很好，实车上我的经验是必须重新评估检测距离和召回率。真实点云反射率不均会让距离较远的目标点变得稀疏，检测模型经常漏检或者误检。我的做法是先在ros2 bag上做离线评测，统计不同距离段的检测准确率，再针对性地调整模型的点云输入范围和检测置信度阈值。这一阶段的调试重点是建立指标，而不是凭感觉调参。
有一个特别容易踩的坑：Autoware感知模块对输入点云的时间和坐标系要求很严格，如果你没有把TF和时间戳校准好，目标框会在车周围乱跳，表面看起来是检测问题，实际是数据同步问题。所以在调检测参数之前，先确认上下游数据质量没问题。
4.2 定位与地图：仿真地图不能直接用
Autoware里定位的核心是基于NDT的点云配准，结合GNSS/IMU/轮速里程计做融合。仿真里跑得好好的定位，到了实车一定会出问题，因为地图不是一回事。
仿真地图是仿真器直接导出的，干净、精确。实车运行环境里，你需要用自己的雷达点云重建一张点云地图。过程是先驾驶小车在场地里低速跑几圈，同步记录点云和里程计/GNSS数据，再用地图构建工具离线拼接生成点云地图。这个地图质量决定了后续定位上限，建图时要注意避开动态障碍物，尽量选择环境静止、点云特征丰富的时间段，车速控制在1米/秒以下。
拿到点云地图后，还要生成Lanelet2地图，把车道线、停止线、路口等结构化信息标注进去，规划模块才有所依据。这一步如果用工具半自动标注，工作量能接受；完全手动标注，会非常耗时。
实车启动定位时，要给定位模块一个初始位姿，否则NDT在全局地图里匹配会直接失败或者跑到错误位置。你可以在可视化界面里手动给定一个粗略初始位姿，等匹配收敛后再放开。每次车断电重启，这个步骤都要做，除非加了自动重定位模块。初始位姿给错，车会“以为”自己在地图上别的位置，这时候别急着查规划，先查定位。
4.3 规划与控制：给控制加个“护栏”
Autoware的规划链路从行为规划开始，做车道级决策，然后路径规划生成离散路径点，最后控制模块输出速度和转向指令。这三个层次在仿真里都能正常工作，但实车要改的东西非常集中：速度限制、加速度限制、转向角速度限制、控制周期、安全距离。
实车第一课就是降速。仿真里Autoware往往默认跑到10公里每小时甚至更高，实车第一次上车测试，最大速度一定砍到1米/秒左右，加速度限制设在0.5米/秒平方上下。这不是保守，是给控制系统留出足够的响应余量。速度太快时，规划的横纵向控制误差会被迅速放大，底盘哪怕有零点几秒延迟都可能导致冲出边界。
控制模块的参数也不能直接用仿真默认值。我用的是横纵向解耦控制策略，横向用纯跟踪或MPC，纵向用PID。仿真里PID参数表现很好，实车会因为底盘响应延迟、噪声等因素出现明显振荡。我的处理方式是：先在原地让车空载测试控制指令的响应延迟，测出底盘从收到指令到真正执行的平均延迟，然后根据这个延迟把控制周期从仿真里的50Hz调低或者调高，并配合调PID的P项和I项。这个延迟测量，通常比盲目调PID快得多。
安全机制是不容讨论的硬性要求。上车前必须做好急停开关、遥控接管、低速限制、最小安全距离检测这几个基本保障。Autoware有碰撞停止节点，可以设定安全距离，但与它并行的硬件急停优先级更高。我第一次闭环测试前，除了软件层限制，还在小车上加了一个物理限位器，在路径边界外摆好防撞挡板。软件再可靠，硬件冗余永远不能少。
5. 实车部署全流程：一次完整工程验证步骤
5.1 上车前的移植清单：话题、TF树、权限一个都不能漏
我总结了实车部署前一定要走完的清单，照着做能省掉大量现场排查时间。
第一，话题重映射。将实车传感器驱动发布的话题与Autoware订阅的话题对齐，确认消息类型完全一致。不同驱动发布的消息类型即使字段名称一致，类型不匹配也会直接导致订阅失败。第二，频率检查。实车传感器的实际发布频率可能和标称值有偏差，要确认低频话题不低于Autoware节点的最低容忍值。第三，TF树检查。实车的TF树涉及多个坐标系，要确认所有传感器、车体、地图之间的TF变换链路完整且方向正确。第四，权限和实时性。给ROS2节点配置合理的nice级别和实时调度权限，否则在点云处理高负载时会出现节点调度滞后。第五，日志管理。设置好ros2 bag的记录目录和磁盘空间，确定需要记录哪些话题，避免现场数据遗漏。
这些检查每一项都可以用一条命令快速确认，不要偷懒。我见过很多实车翻车，最后查下来就是某个话题没remap，某条TF缺失，或者某个节点权限不够导致发布频率不稳定。
5.2 分模块验证法：从单一模块到全闭环再放开手脚
实车上车测试最忌讳的就是一次性把所有模块全开，车一跑起来出了问题根本不知道是哪个环节导致的。我的习惯是分阶段验证。
第一阶段，只启动底盘的底盘驱动和控制，手动遥控小车走S形，确认里程计方向和位移正确，速度响应平滑。第二阶段，启动定位模块，让车原地转向和缓慢移动，观察定位点云匹配误差是否在可接受范围内。第三阶段，启动感知模块但关闭规划控制，开着车在场地里绕，看目标检测框是否稳定，距离估计是否准确。第四阶段，启动规划控制，但把目标速度设到最低，让车走一小段直线，确认规划轨迹和控制指令能够正常输出。第五阶段，设置一个封闭的小场地，加入静态障碍物，才做第一次全闭环自动驾驶测试。
每一阶段都要找现场问题，确认无误后再进入下一阶段。不要觉得前面阶段手动遥控浪费时间，它能把链路上的每个环节都验证清楚，最终闭环测试会顺利得多。我实际做下来，分模块验证大概占了整个实车调试时间的三分之二，但换来的是闭环测试只失败了一次。
5.3 一场实测中的参数调整记录
以我第二次场地实测为例，起始参数是仿真默认配置，最大速度1.2米/秒，最大加速度0.8米/秒平方，控制频率50Hz，安全距离0.8米。车跑起来后出现几个问题：起步时刹车过猛车头有明显点头；转弯时方向盘响应偏慢，轨迹向外侧偏移；遇到一个小障碍物，刹停距离比我预期多了不少。
处理起步点头，把最大加速度从0.8降到0.4，同时把控制模块里速度变化率的平滑系数调高一点。处理转弯偏移，把横向控制的前视距离从0.8米增加到1.5米，同时把转向角速度限制从每秒20度降到每秒12度，车身姿态稳定很多。刹停距离偏大的问题，除了提高安全距离到1.5米，还把碰撞检测节点的预警距离调大，给控制系统留更多反应时间。
三次调整之后，这辆车在场地里的表现已经比较接近“自动驾驶该有的样子”了。整个过程大约花了一个下午，每次改参数后都重新跑同一段测试路径，用ros2 bag记录数据做对比。这里最重要的原则是：一次只改一个参数，并且用数据说话，否则你永远不知道哪个参数起了作用。
6. 避坑手册：ROS2+Autoware实车最常见的问题与排查
6.1 高频问题速查表
| 现象 | 常见原因 | 排查方向 |
|---|---|---|
| 定位点云匹配发散或错位 | 初始位姿给错、地图质量差、外参不准 | 检查初始位姿；重建地图；重新标定雷达车体外参 |
| 目标检测框乱跳 | 时间戳不同步、TF缺失、检测阈值过低 | 检查话题时间戳；确认TF树完整；调高检测置信度 |
| 规划轨迹抖动 | 控制增益过高、规划拓扑冲突 | 降低控制增益；检查红绿灯状态和相关障碍物是否误报 |
| 控制指令发布但车不动 | 底盘模式没切到自动驾驶、CAN线束问题、使能信号丢失 | 检查底盘驱动上报状态；确认使能线束和遥控切换逻辑 |
| 节点频繁崩溃 | 共享内存不足、内存泄漏、某个子节点超时 | 检查/dev/shm大小；加内存监控；查看崩溃日志 |
| 实时性不足导致频率抖动 | CPU占用过高、非实时调度、DDS配置不佳 | 优化模型推理分辨率；给节点实时权限；调整DDS QoS |
| 点云加载过慢且画面卡顿 | 地图点云太大、滤波参数过宽 | 降采样地图；缩小点云裁剪范围；提升显卡性能 |
| 仿真正常实车全乱 | 参数没按实车重新标定 | 按第3、4、5章流程重新走一遍标定和参数移植 |
每次排查问题的时候，先别急着改代码改参数，把现象描述、当时场景环境、话题日志、TF树截图都夹在排查看板上，信息足够齐全再动手。很多问题往往和信息不全有关，而不是技术难度有多高。
6.2 几个让调试效率翻倍的技巧
第一，ros2 bag回放是实车调试的利器。每次测试前我必做的一步是开一个后台命令，把传感器话题、定位结果、规划控制指令全部记录下来。测试后如果出问题，直接离线回放当时的数据，调到哪一个环节出现问题，比在现场靠肉眼观察靠谱得多。
第二，rqt_graph别只看“像不像蜘蛛网”，重点看每个节点的订阅发布频率差异。现场最节约时间的排查方式，是拿rqt_graph对照模块设计图，看哪条链路上多了一个节点或者少了连接，百分之八十的数据流问题能一眼定位。
第三，Autoware所有节点都支持动态参数配置，不用重启节点就能调整参数。调试时我习惯把需要调的几个参数记到一个文件里，用脚本一次性下发，省去手动敲命令的时间。比如控制相关的最大速度、加速度、前视距离，感知相关的裁剪范围、检测阈值，都成立一个热调参流程。
第四，日志级别切换非常有用。大多数Autoware节点默认日志级别是INFO，出问题时切到DEBUG，会把每个模块内部的处理细节都打出来。虽然日志量大，但在现场排查时信息密度远高于你猜漏洞。
第五，准备一个遥控急停装置。不管软件做了多少层保护，物理上能够一键断开发布指令、切换手动模式的遥控器是最后的防线。第一次闭环测试前，我专门做过一轮“突然插入遥控接管”的演练，确认在自动驾驶模式下随时能切回手动，才敢放开跑。
做ROS2+Autoware小车，从仿真到实车，最花时间的不是算法本身，而是各个模块之间那种“看起来都正常，合起来就不正常”的工程问题。每次踩坑之后，把周期和不安全感记录下来，慢慢就能形成一套自己的排查框架。最后想说的是，这套学习过程的价值不只是让你学会Autoware，更是让你理解了自动驾驶系统里每个决策背后的工程约束。等你把一条完整的感知定位规划控制链路在实车上跑通过一次之后，再看其他自动驾驶技术方案，会觉得通透很多。
