有一类问题几乎每个准备接触自动驾驶的人都会问：这么大一套开源工程，几十个模块堆在那里，到底应该先从哪儿看起？我自己最开始也走过弯路，找了不少资料、看了无数架构图，结果一到实际操作仍然一脸懵。后来我彻底换了个思路——先把整套仿真环境搭起来，把一个Demo从头到尾跑通，再回头面对源码去读各个模块，很多原本悬在空中的概念一下就落地了。这篇学习笔记就是把这条路径拆开来讲：从仿真环境的搭建心得，到感知定位、规划控制的模块笔记，最后再附上我印象很深的一次排障全过程。内容不少，但每一条都是我实际验证过、踩过坑后才沉淀下来的，希望能帮你少绕几个圈子。
1. 我为什么坚持“先跑通仿真，再读源码”
很多人拿到这套开源项目之后的第一反应，是急着翻开目录，从感知模块开始逐行读代码。我能理解这种想法，但说实话，如果不知道整套系统的最终输出长什么样，直接从代码里找线索，效率非常低。
1.1 光看架构图解决不了“消息对不上”的问题
架构图能告诉你模块与模块之间“应该”怎样通信，但实际运行起来，真正要命的问题往往出在数据结构、字段单位、时间戳对齐这些细节上。比如障碍物消息里速度用的是米每秒还是千米每小时？置信度取值范围是0到1还是0到100？这些问题一张架构图永远回答不了。
模块之间的信息传递通常依靠消息机制。对我这种没有太多分布式系统经验的人来说，光看代码想象消息怎么流动，很容易卡在某个抽象层级。但是当你把仿真环境跑起来，直接打开可视化工具，看到当前车辆前方点云、障碍物包围框、规划轨迹同时在屏幕上分层显示，那种“数据流”的感觉一下子就出来了。所以我的建议是：先跑通系统，再读代码；先用工具观察消息，再理解模块实现。
1.2 环境搭建完整流程与代表性难点
我搭建这套实验环境时的流程大致如下，顺序上基本是固定的：
- 准备好Linux环境，有独立显卡会省掉不少麻烦。没有GPU也能跑通，但可视化流畅度和部分加速功能会受限。
- 安装容器运行时。整个平台一般都在容器里运行，好处是依赖隔离、删除方便，坏处是如果你不熟悉容器的网络和磁盘挂载，会遇到一些莫名其妙的问题。
- 下载与当前源码版本匹配的镜像。
- 启动容器，把源码目录挂载进去。
- 在容器内执行编译脚本。新手上路最容易在这里失败，表现通常是内存不足，编译进程被系统杀掉。
我碰到过的版本痛点不止一个。最典型的是装了最新源码，却拉了旧版本的镜像，结果运行时提示某个模块缺失，查了半天发现自己根本没注意版本对应关系。所以严格来说，第一步不是装环境，而是确认你想用哪一个稳定版本，然后让源码、镜像、配置文件三者完全对应。
内存不足可以说是最普遍的坑。如果编译过程中出现编译器进程被杀或者编译报错中有“Killed”字样，九成是内存不够。我当时临时增加了交换空间，勉强编出来了，但后面跑仿真时还是慢。有条件的话，编译时尽量在内存16G以上的机器上做。
1.3 跑通后先看哪三类输出
仿真平台启动之后，屏幕上会出现几个可视化窗口，里面能看到虚拟城市道路、本车模型、感知到的障碍物等。新手容易犯的毛病是只顾着看画面炫不炫，却忽略了真正值得观察的数据输出。我建议暂时忘掉渲染效果，按下面三个线索去追数据：
- 感知模块输出的障碍物消息，看里面包含哪些字段，有没有速度和朝向；
- 规划模块输出的轨迹，看路径点和速度曲线是怎么表达的；
- 底盘状态消息，看车辆的实时速度、方向盘转角反馈。
把这三个输出对应起来看，你就能理解一条最简链路：感知发现障碍物，预测判断它下一步会怎么走，规划产出避让轨迹，控制模块把它变成加速或转向指令。这些数据流一旦在脑子里串起来，后面读代码时就有了“骨架”。
1.4 一个容易被忽略的容器时间问题
容器与宿主机的时间如果不一致，仿真里的时间戳会漂移，进而让多个模块之间出现“老消息、新消息”错配。这个问题在仿真调参时不易察觉，但一旦系统跑久了，各个模块的输出开始对不上，排查起来很痛苦。我的习惯是每次启动容器前先做一次时间同步，并且查看时钟偏差，确保所有进程处在同一个时间基准上。
2. 感知模块学习笔记：点云与视觉的分工
感知部分通常有两类输入：激光雷达点云和摄像头图像。它们各司其职，激光雷达擅长精确测距和三维几何描述，摄像头擅长识别类别、车道线和交通信号。理解了“分工”二字，感知模块的代码就不难读了。
2.1 激光雷达点云的第一道工序
激光雷达一帧产生的点云数量可能达到十几万个，直接从原始点里找障碍物会非常吃力，所以预处理是必不可少的。我读完这部分源码后的整体流程是这样的：
- 坐标变换：把雷达坐标系下的点云转换到车辆坐标系；
- 无效点滤除：去掉超出量程和反射强度异常的点；
- 地面与远距离点滤波：去掉地面反射点和超过ROI范围的点；
- ROI区域过滤：只保留车辆周围一定范围内的点，减少聚类时的工作量。
这里有个容易踩的坑：不同型号激光雷达对坐标系正方向的定义并不一致，如果标定关系搞错，点云会在车辆坐标系里发生翻转，后续所有聚类结果全错。我曾见过一个模拟环境里点云被旋转了180度，障碍物全体跑到车辆屁股后面，感知模块却还在正常工作——就是因为当时没有复核坐标转换关系。
2.2 障碍物聚类与目标跟踪
预处理之后，系统会做障碍物聚类，把“一堆彼此距离很近的点”合并成“一个目标”。常用的聚类思路是欧式聚类，设定一个距离阈值，把空间上相邻的点归到一组。聚类结果经过尺寸过滤、噪声剔除之后，就形成了障碍物的包围框、朝向和几何尺寸。
但单靠聚类还不够稳定。传感器每一帧都有噪声，同一个目标可能在帧间出现抖动甚至短时丢失。所以系统还需要跟踪模块，用卡尔曼滤波这类方法对目标状态做连续估计。这样做出来的速度才平滑可信，目标ID也会稳定不少。
我在学习初期会误解跟踪的价值，觉得不过是“让画面看起来不跳帧”。后来才明白，跟踪的意义在于给预测模块一个稳定的运动模型：如果连目标的加速度都是跳变的，后续预测轨迹根本没法做。
2.3 视觉检测与数据融合的“关联-验证-更新”逻辑
摄像头这条链路主要做目标检测和车道线检测。目标检测会输出2D框和类别，比如轿车、行人、自行车、卡车。由于相机本身不直接提供精确距离，视觉结果大多是“类别坐标+二维位置”，需要与其他传感器做融合才能获得可信的三维位置。
不少人以为融合就是把多个传感器结果折算成一个坐标再取平均，这个理解偏差很大。实际工程里的融合更像“关联—验证—更新”的循环：先判断激光雷达检测到的目标，和相机检测到的目标是不是同一个；再把不同来源的状态合并，输出一个综合结果。中间还要考虑某个传感器这一帧漏检了怎么办、两个传感器的置信度不同时该信谁更多。看懂这段逻辑，再看代码里的数据关联和协方差处理，就会顺很多。
3. 高精地图与定位：最容易被忽略却影响全局的地基
定位和高精地图在入门学习时往往容易被跳过，因为它们不像感知和规划那样能直接在可视化窗口里看到“很炫”的效果。但恰恰是这两个模块，很容易引发整条链路的连锁故障。
3.1 高精地图与普通导航地图的差别
普通导航地图给人看，精度是米级，由道路连线构成；高精地图给车看，精度要求达到厘米级，并且不止有路网，还有车道中心线、车道边界、停止线、信号灯位置、路缘石信息等。车辆需要利用地图“预知”前方几百米的结构：再往前是直行还是右转专用道？下一个路口有哪几个车道可以汇入？
有了这些先验信息，感知模块就不需要在每一帧都从零识别车道结构，规划模块也可以提前规划变道路径。我学到的一条经验是：高精地图与定位共同构成了一种“几何上下文”，没有它，自动驾驶系统就像人类司机在没有路牌、没有车道线的空地上开车，每一步都极度依赖实时推理，可靠性很难保证。
3.2 GNSS、IMU与点云定位是怎么配合的
定位模块通常会把三类输入融合起来：
- GNSS提供全局绝对位置，但容易受高架遮挡、多路径效应影响，在城市环境里不稳定；
- IMU以高频输出加速度和角速度，短时间内推算姿态与位移很准，但长时间积分会产生漂移；
- 点云配准把当前激光雷达的一帧点云，与预先构建的定位地图进行匹配，得到相对精确的位姿修正。
三者优势互补，最终通过融合算法输出一个带协方差的位置估计。我需要提醒自己重视的一点是：定位模块输出的不是一个“确定的位置点”，而是带有不确定性描述的概率分布。规划和控制模块在决策时会考虑这个不确定性，不会把车辆位置当做一个绝对精确的点来处理。这正是代码里协方差字段存在的原因。
3.3 定位异常时的“集体犯病”现象
定位一旦漂移，故障通常是多米诺骨牌式的：地图上的本车位置偏了一大截，点云与地图投影错位；感知模块把障碍物投到错误的地理坐标上；规划模块拿到的参考线也不再是本车真正所在车道。从现象上看，你可能会觉得是感知漏检或者规划抽风，实际上源头却在定位。
所以每次遇到“明明前方有障碍物，规划却视而不见”这类问题，我会先问一个“下三路”问题：本车定位是不是偏了？把定位结果输出出来，和真实位置做对比，往往比直接调感知、调规划参数要快得多。
4. 规划与控制：从驾驶语义到方向盘动作
规划和控制是自动驾驶决策链路的“最后一公里”。这一层把所有上游感知和定位信息汇总，翻译成油门、刹车、方向盘转角。这部分对数学基础有一点要求，但只要抓住几个核心概念，代码读起来并不是天书。
4.1 参考线与Frenet坐标分解
车辆要规划路径，通常不是直接在二维平面上找一条点序列，而是依托一条参考线，用“纵向距离s”和“横向偏差d”来描述位置。
横向偏差决定车离车道中心线远不远，纵向位置决定车沿道路走到哪儿了。这种坐标系的好处是能把“在二维平面里规划路径”拆成两个相对独立的问题：沿着道路走多快，以及相对车道线偏移多少去绕开障碍物。读规划模块源码时，你会看到大量s和d这两个字母，理解它们代表的是什么，比单纯记忆公式重要得多。
4.2 路径规划与速度规划为什么要分开做
路径层负责回答“走哪条线”：避开障碍物、不压车道边界、保持平滑。速度层负责回答“多快地走”：什么时候加速、什么时候刹车、什么时候等一等。
两层分开设计是有道理的。路径问题偏几何，速度问题偏时序和动力学。如果把两者合在一起求解，状态空间会膨胀到没法实时算。常见的实现思路是：先用采样或动态规划方法产生候选几何路径，再从候选里挑出一条代价最低的平滑路径；然后在这条路径上规划速度曲线，考虑限速、前方障碍物的距离和红绿灯时间等约束。最后把横向路径和纵向速度合成一条带时间戳的期望轨迹。
4.3 控制模块的反馈校正逻辑
规划给出的是期望轨迹，控制要输出实际执行量。这个问题听起来像“照着轨迹走就行”，但车辆本身的动力学、转向延迟、轮胎摩擦阻力都会带来误差，模型再准也会偏离。
所以控制器一般不会只算一次，而是采用滚动时域优化的思想：每帧根据当前车辆状态重新计算未来一小段时间的控制序列，但只执行当前这一拍的控制量，下一帧再重新计算。这就是不断反馈校正的过程。学习时最容易误解的地方在于，盯着某一次控制输出会觉得很“不合理”，要看它的跟踪误差是不是随着滚动优化逐步收敛。如果横向偏差周期性震荡，大概率是控制增益或预测模型有问题；如果始终有固定偏差，往往与模型参数或时间延迟补偿有关。
4.4 在仿真里调参数时我关注哪些指标
我通常会观察横向偏差、航向偏差、速度跟踪误差这三条曲线。仿真平台基本都能打印这些量。如果偏差曲线是发散的，先不要改一堆参数，应该先确认规划轨迹本身是否平滑、车辆模型是否与仿真平台一致。有一次我调了一整天控制参数，最后发现是车辆模型里的轴距写错了，所有控制参数再调也没用。这个教训让我养成了“先校核模型参数，再动控制参数”的习惯。
5. 一次印象深刻的排障记录：虚拟车“钉”在原地不动
仿真场景里，我在本车前方放置了一辆缓行的虚拟障碍车。按道理，规划模块应该检测到它并逐渐减速，可我看到的却是：感知可视化窗口里明明有那辆车的轮廓，车辆轨迹却几乎不动，规划系统的速度曲线也没有明显下降。这是一个非常典型的链路排查场景。
5.1 现象与初步判断
第一个念头是感知模块是不是漏检了。但打开感知输出数据，障碍物消息里有这辆车的坐标、宽度和长度，证明感知已经稳定检测到它。那问题可能出在预测模块：预测模块输出的预测轨迹几乎没有变化，且目标置信度持续偏低。我把注意力转向消息链路。
5.2 沿着消息链路一层层往下查
我按下面的链路逐级排查：
- 感知模块输出障碍物消息，有值、有时间戳，正常；
- 预测模块接收多个同主题消息，但只处理了一部分，另一部分被当作“过期消息”丢弃；
- 对比时间才发现，某一路观测消息的主时钟与预测模块使用的系统时钟存在偏移；
- 该路观测因为“时间戳超过允许阈值”被过滤掉，导致目标长期得不到新观测更新；
- 预测模块只能用历史状态做外推，而外推结果的置信度越来越低，最终被系统判为“不可用”。
问题彻底定位后，我将传感器时间同步方式统一为系统时钟，重新播放同一个场景，障碍车的预测轨迹随之恢复正常，规划也给出了合理的减速行为。
5.3 这个案例给我的两个教训
第一，不要在没确认输入链路完整性的情况下贸然修改算法参数。这个问题的根因与感知、预测算法本身没关系，纯粹是时间同步和数据过滤的配置问题。很多所谓的“算法效果差”，底层其实是消息链路或时间戳问题。
第二，要养成“故意制造异常”的测试习惯。比如手动把某一路传感器停掉、给定位结果叠加一段噪声，观察系统会不会表现出对应症状。这种训练能让你很快建立“现象到模块”的直觉。动过参数、改过配置之后，再复跑一遍异常场景，看系统能否正确退化，远比只看正常场景更加靠谱。
6. 从学习笔记到排障手册：我的信息整理方法
学模块学到一定阶段，光靠记忆已经不够了。我个人会维护一份持续更新的“排障小册子”，记录每次实验中出现的现象、原因、复现步骤和解决方式。这种方式比单纯收藏文档有用得多。
6.1 用四要素记录每一个实验
每条记录我会固定写成四段：现象、排查链路、根因、复现步骤。
比如“虚拟障碍车静止不动”这条，我就会记录成：现象是“感知有车，预测轨迹不变”；排查链路是“感知→预测→时间戳比对”；根因是“时间基准不一致导致消息被过滤”；复现步骤是“把传感器时间偏移调大，就能复现同样问题”。这样下次再遇到类似情况，我可以先翻自己的笔记，而不是从头开始查。
6.2 善用回放数据验证假说
仿真系统一般支持场景录制和回放。修复一个问题之后，不要急着做下一个实验，应该把刚才的回放数据再跑一遍，确认修复确实有效。我在排障时发现，有时改完一个参数看起来正常了，但换一个场景又复发，说明根因根本没有被真正解决。回放数据让你能用同一段输入反复测试，是验证“是否真的修复”的底线手段。
6.3 定期复盘哪些模块仍然陌生
我会每隔一两周复盘一次：哪些模块自己能独立讲清楚，哪些还完全陌生。比如高精地图里地图数据格式的细节，我花了好几轮复盘才真正理解。与其追求把每个模块都一次吃透，不如按“感知→预测→规划→控制”的主链路反复循环，每一轮都比上一轮多深入一层。
整理这篇笔记的过程本身，就是我另一次系统化复习。读一段代码、回到仿真里做一个验证、把关键输出记录下来，再继续往下读，这样的循环对我来说非常有效。如果你也在啃这类开源自动驾驶项目，我最后建议你从“跑通Demo”开始，先从消息链路里选一条完整地摸到底，之后再去横向展开每个模块的细节。节奏可以按自己的基础调节，但“动手验证”这个习惯，我认为是所有人共同的捷径。
