企业官网建设流程全解析

第一次把 AutoWareAuto 这套自动驾框架完整跑通的时候，我的第一反应不是兴奋，而是“这东西居然真的能把车开起来”。感知、定位、决策规划、控制、预测五个模块，每一个单独拎出来都是一门课，而框架要做的是把它们全部揉进一套实时软件栈里，消息满天飞，节点十几个，正是这种复杂度让很多刚开始接触的人看了一眼就关了仓库页面。

这篇文章我打算换个讲法，不按官方文档的目录顺序平铺，而是从“这套框架到底在解决什么问题”切入，把五个核心模块的代码组织方式、数据流关系、关键算法选型逻辑，以及我实际集成联调时踩过的坑全部梳理一遍。如果你正准备拿它做毕设、做项目验证平台，或者想理解一套量产级自动驾驶软件栈的整体骨架，这篇文章能帮你少走很长的弯路。

1. 先把整车软件栈拆成一张数据流图：每个模块到底管什么

1.1 五大模块的职责边界：感知不是“看见”，定位不是“知道在哪”

很多人第一次看 AutoWareAuto 的源码目录，会被 modules 下的十几个包搞晕。其实它核心就只有五件事：感知、定位、决策规划、控制、预测。搞清楚这五件事的边界，整个框架就懂了一半。

感知模块负责把传感器原始数据变成“有语义的对象”。摄像头出的是图像，激光雷达出的是点云，毫米波雷达出的是目标列表，感知模块要做的就是从这些原始数据里提取出车道线、障碍物、红绿灯、可行驶区域。它输出的是“前方 20 米有一个行人，速度约 1.2 m/s，朝向东北”，而不是一张漂亮的可视化图片。

定位模块的输入是 IMU、GNSS、轮速计、激光点云这些信息，输出是车体在一个全局坐标系下的位姿（位置加姿态）。注意这里有个关键区别：感知告诉系统“那个行人在哪”，定位告诉系统“我在哪”。没有定位，感知输出的障碍物坐标就是一堆没挂靠的浮点数，规划也没法算路径。

决策规划模块分成决策和规划两层。决策层负责“下一步做什么”，比如当前应该跟车、变道还是停车让行；规划层负责“怎么做”，生成一条满足动力学约束、避障、平滑的轨迹。它输出的是未来若干秒内一串带时间戳的路径点，每个点包含位置、速度、加速度、朝向。

控制模块是执行层。它接收规划轨迹，输出方向盘转角、油门/刹车指令给底层车辆接口。控制不需要知道为什么要变道，它只需要回答一个问题：给定这条轨迹，我当前该打多少方向盘、踩多少踏板才能跟上它。

预测模块比较特殊，它服务于决策和规划。预测模块感知周围动态目标的历史轨迹，推测它们未来几秒的可能行为。比如前面那辆车是减速准备靠边停车，还是临时变道？预测模块给出多条带概率的假设轨迹，决策层再根据这些假设做判断。

1.2 数据流是怎么串起来的：从一帧点云到方向盘转角

我用一个实际场景来描述这条链路：车辆以 60 km/h 行驶在双向两车道，前方 40 米有一辆慢车。

第一帧激光雷达点云进入感知模块，经过地面分割、聚类、目标跟踪，输出一个动态目标：类型为车辆，位置在车体坐标系下（x=40m，y=0.5m），速度 8 m/s，航向与自车一致。定位模块同时输出自车当前位姿（全局坐标 x=1000，y=500，航向角 1.57 rad），以及这个位姿的不确定性协方差。预测模块拿到感知目标列表后，结合车道线信息和历史轨迹，推断该目标大概率继续直行，但也给出 10% 概率的减速意图假设。

决策规划模块的输入是定位位姿、预测结果、路由信息（从哪里到哪里）。决策层当前处于“Follow”状态，规划层在 Frenet 坐标系下做横向和纵向解耦采样，生成一条 8 秒时域、包含 80 个轨迹点的平滑曲线。控制模块接收这条轨迹，取第一个轨迹点作为参考，用纯跟踪或 LQR 算方向盘转角，用 PID 算油门开度。整条链路从传感器数据进入感知到控制指令下发，端到端延迟控制在 100 毫秒以内才算合格。

1.3 为什么很多人觉得这套框架“复杂到劝退”

我的经验是，复杂度主要来自三处：一是依赖库太多，PCL、OpenCV、Eigen、Boost、g2o 这些没装对版本，编译就能卡你一整天；二是消息接口层数太多，同一个障碍物可能既有感知原始输出，又有融合后的跟踪结果，还有预测模块加工后的预测轨迹，新手经常搞混该订阅哪个话题；三是参数配置散落各处，激光雷达装的高度、IMU 安装角、车体后轴位置这些标定参数任何一个不对，整个系统表现都会非常差。

这也是我写这篇文章的初衷：模块功能相对容易看懂，难的是模块之间怎么协作，以及代码里哪些参数是系统能跑的“命门”。

2. 感知模块的代码组织：从点云滤波到目标跟踪

2.1 点云预处理：降采样、地面分割、ROI 裁剪一个都不能少

在 AutoWareAuto 的感知模块里，点云预处理不是可有可无的优化，而是决定后续算法能否工作的前提。原始 64 线激光雷达一帧点云大概有 13 万个点，直接丢给聚类算法，时间和内存都扛不住，所以第一步必须是降采样，通常用 VoxelGrid，叶节点大小设在 0.1m 到 0.2m 之间，既保留障碍物轮廓，又把点数压到两三万。

地面分割我习惯用 RANSAC 拟合平面。原因很简单，室外场景地面并不平整，但绝大多数点是落在同一个大平面附近的，RANSAC 对这种带噪声的模型拟合非常稳。分割掉地面之后再对非地面点做欧几里得聚类，相邻点距离阈值一般设置在 0.5m 左右。这里有个值得注意的细节：阈值太小会把同一个行人身上的点拆成好几个簇，阈值太大又会把紧挨着的电动车和行人合并成一个目标，实际调参时需要在召回率和精确率之间反复权衡。

ROI 裁剪也是必须的。车体后方 10 米之外、左右 3 米之外的点，对当前驾驶决策没有意义，直接裁剪掉，减少后续计算量。但千万不要把 ROI 做得太极限，否则变道场景下旁车道快速靠近的车辆可能因为延迟一帧进入 ROI 而漏检。

2.2 目标检测与跟踪的多帧关联：为什么不能用单帧检测直接输出

感知模块如果只做单帧检测，不做帧间跟踪，系统会发现同一辆车在不同帧里的检测框位置剧烈跳动，目标 ID 也不稳定。比如第 100 帧检测到前方车辆 ID=3，第 101 帧同一个车变成了 ID=7，规划模块就会认为突然多了一辆车，造成急刹车。

AutoWareAuto 的跟踪逻辑可以概括为“检测器加滤波器”的组合：每一帧对点云做检测得到目标假设，然后跟上一帧已确认的跟踪目标做匈牙利匹配，匹配上之后用卡尔曼滤波器更新目标的运动状态。匹配的代价矩阵通常用位置距离、形状相似度、速度方向三个指标加权求和。让我具体解释一下加权逻辑：位置距离权重最高，因为同一目标不会在相邻帧间瞬移；形状相似度主要用来区分大货车和小轿车，宽度 2.5m 的目标不太可能下一帧就变成 1.8m；速度方向则用于防止两条相向而行的轨迹被错误匹配。

跟踪模块内部维护一个目标状态机，包含“新建”“确认”“丢失”三种状态。连续 3 帧匹配上的目标才从“新建”转为“确认”，避免单帧误检被当成真实目标；连续 5 帧匹配不上的目标标记为“丢失”，等它再次出现时重新走新建流程。这套状态机控制的是“系统对目标存在的置信度”，而不是直接删除丢失目标，因为目标本身可能只是被遮挡了。

2.3 我踩过的一个坑：坐标系对齐错误导致检测框漂移

有次路测，感知检测出来的目标框在车辆转弯时整体往外偏了半米，直行时又恢复正常。排查到最后发现是感知模块输入的点云已经是在车体坐标系下，但预处理模块里一个点云变换参数还额外做了一次从激光雷达到车体的变换，导致转弯时外点被错误投影到了错误的位置。

这类问题在自动驾驶框架里极具迷惑性，因为直行时误差被车辆前进方向的对称性掩盖，只有转弯大角度时才会暴露。排查方法是做“单帧点云回放”：把车停在原地，用方向盘让前轮转向，观察静止障碍物的点云在车体坐标系下是否保持不动。凡是转弯时点云坐标也跟着动的，一定是坐标系变换链上出了问题。

3. 定位模块的融合策略：IMU、GNSS、点云匹配怎么博弈

3.1 为什么单靠 GNSS 不可靠

很多初学的人会问：有 GPS 不就能定位了吗？答案是，消费级甚至部分工业级 GNSS 在城市环境下根本达不到自动驾驶要求的厘米级精度。城市峡谷里卫星信号被高楼遮挡反射，多路径效应让定位结果能瞬间跳出去几十米。隧道和地下车库干脆直接没有信号。

所以 AutoWareAuto 的定位模块必须做多源融合。它的设计思路是：GNSS 提供低频但有界的绝对位置参考，IMU 提供高频但会漂移的相对增量，点云匹配提供高精度的局部修正。三者通过滤波框架融合，输出一个既平滑又不会长期漂移的位姿。

3.2 帧间匹配与全局匹配的配合

点云匹配是定位精度的关键。AutowareAuto 式的定位方案里，有两种匹配模式：第一种是帧间匹配，用当前帧点云和上一帧点云做配准（比如 NDT 或 ICP），得到相对位姿增量，然后叠加上去，这种模式短时间精度很高，但误差会累积；第二种是全局匹配，当前帧点云和高精地图点云做配准，直接修正累积误差，得到绝对位姿。

实际框架里是先用 IMU 积分做位姿初值，然后以初值附近的搜索空间做当前帧点云与地图点云匹配，匹配结果作为观测更新卡尔曼滤波器。IMU 在这里不是最终输出，而是提供“期望位姿”，把点云匹配限制在一个合理的局部搜索范围内，既提高匹配成功率，也避免局部极小值问题。

3.3 给规划模块的定位输出：位姿必须带不确定性

新手容易忽略：定位模块输出的绝对不应只是一个坐标点，而应该是一个位姿分布。同一套定位数据，可能是“置信度很高”的，也可能是“基于最后一次可信修正外推了 2 秒”的，两者对规划模块的意义完全不同。

AutoWareAuto 的做法是维护一个 6 自由度的协方差矩阵，通过消息的一部分传递给规划模块。规划模块在计算碰撞风险时会结合这个协方差膨胀自车的包围盒，协方差越大，决策越保守。如果定位长时间不可信，规划层甚至会触发安全停车。所以如果只发位姿不带协方差，就相当于告诉规划模块“我的定位绝对准确”，这在工程上是很危险的做法。

4. 决策规划模块：有限状态机驱动的行车逻辑与轨迹生成

4.1 场景状态机：Follow、Stop、LaneChange 是怎么切换的

决策规划模块的代码核心是两个东西：场景状态机和轨迹优化器。状态机把这个连续世界离散化成若干驾驶状态，每个状态对应一套行为逻辑。比如我常用的状态集就包含：INITIAL（初始化）、FOLLOW（跟车）、STOP（停车等待）、LANE_CHANGE（变道）、INTERSECTION（路口通行）、PULL_OVER（靠边停车）。

状态转换不是随便转移的。拿 FOLLOW 转 LANE_CHANGE 来举例：需要满足三个条件同时成立——当前车道前方车辆速度低于设定阈值且持续时间超过 3 秒，目标车道前方和侧后方安全距离内没有障碍物，变道标志位使能。还有一个容易被忽略的条件：自车当前时刻不能处于路口内部或人行横道上，否则需要等过了这段再变道。这些条件在代码里就是一层层的 if-else 判断，但它们的组合逻辑直接决定车辆行为是否拟人化。

4.2 轨迹生成：Frenet 坐标系下的横向纵向解耦采样

决策定了做什么，规划负责怎么做。AutoWareAuto 的轨迹规划是在 Frenet 坐标系下完成的，这个坐标系的优势在于把“沿着道路方向”和“垂直于道路方向”解耦成两个独立维度，这对变道、超车这类行为非常友好，纵向只需要考虑速度规划，横向只需要考虑车道偏移。

规划器的核心流程分四步：参考线提取、横向采样、纵向采样、代价合并。参考线是车道中心线的平滑后的分段多项式；横向方向，在当前车道中心线左右各采样若干条候选轨迹；纵向方向，在保持安全跟车间距的前提下采样可选的加速度曲线。每条候选轨迹都会做碰撞检查，通过检查的轨迹再计算代价。

代价函数的设计最能体现工程经验。我常用的代价项包含：舒适性代价（加速度及加加速度平方积分，太大乘客会晕车）、偏移代价（偏离参考线越远代价越高）、效率代价（平均速度低要扣分）。三个代价加权求和，权重系数需要实车标定，不同车型、不同用户偏好差异很大。

4.3 规划器输出给控制器的到底是什么

规划器最终输出是一组带时间戳的轨迹点，这些点放到消息里的格式大致是：路径点在全局坐标下的 x/y/z，该点的朝向角，期望的线速度和加速度，以及该点对应的曲率。控制模块拿到这条轨迹后，不是直接跟踪所有点，而是只关注最靠近自车当前位置的附近的若干点，根据当前车速选择预瞄距离，然后计算控制指令。

有一点很多人会理解错：规划轨迹并不保证控制器能完全跟踪，它只是一个“期望参考”。控制模块的任务是最小化轨迹跟踪误差，而不是保证绝对等于。所以规划输出要做平滑处理，尤其是速度和加速度曲线必须连续，否则控制器输出会因为目标值的跳变产生冲击。

5. 控制模块的横纵向解耦：方向盘和油门如何分别跟轨迹

5.1 纵向控制：从目标速度到踏板开度

纵向控制的核心问题是：如何根据当前速度与目标速度的偏差，以及前车距离，决定油门和刹车。

AutoWareAuto 常用的纵向控制器是 PID 加前馈的组合。首先要解释为什么必须有前馈：纯 PID 是“见错才纠”，上坡时为了维持目标速度需要额外扭矩，但 PID 得先看到速度误差才行动，反应就慢了。前馈项可以根据道路坡度或期望加速度直接给一个基础踏板量，PID 只需负责修正扰动，整个系统响应会快很多。

实际标定时我会先把 PID 三项分开调：先只加 P，让系统在平路上能跟住匀速目标，响应有一点超调没关系；再加 I，消除稳态误差，但 I 项要设限幅，否则积分饱和会让起步时猛窜；最后加 D 抑制超调，但 D 对传感器噪声极其敏感，轮速信号没有滤波前千万不要加 D。

5.2 横向控制：预瞄距离、航向角、曲率的三角关系

横向控制我用得最多的方案是纯跟踪算法，原因是它简单、鲁棒、参数少，特别适合作为第一版控制器跑通全链路。

纯跟踪的核心思想是：从自车当前位置出发，在规划轨迹上往前找一个预瞄点，然后计算一条连接自车与预瞄点的圆弧，用这个圆弧的曲率决定方向盘转角。关键参数只有一个：预瞄距离。它跟车速直接相关，通常写成前馈关系“预瞄距离 = 车辆速度 × 预瞄时间”，预瞄时间在 0.5 到 1.5 秒之间。预瞄距离太短，车辆会在车道内左右摆动；太长，车辆会切弯内道，过路口时转向不足。

在实际工程里，我还会叠加一个航向角反馈项：计算自车当前航向与轨迹目标航向的偏差，乘以一个较小的增益，加到纯跟踪输出的转角上。这个航向角反馈的作用是抑制弯道中的横摆，效果好比给纯跟踪加了一个阻尼项，弯道跟踪精度提升非常明显。

5.3 参数整定：从仿真到实车都要做一遍

控制参数整定这件事，我强烈建议遵循“仿真初选、场地微调、道路验证”三步走。仿真里因为车辆模型理想化，参数可以直接给一个比较激进的初值；到了封闭测试场，先低速 10 km/h 跑直线和圆弧，记录跟踪误差，逐步把速度提到 30 km/h；最后才到真实道路验证，这时参数要在舒适性和跟随性之间找一个平衡点。

我有个印象很深的经验：同样是纵向 PID，不同油门踏板响应特性的车，Kp 能差出一倍。换车型后如果还沿用旧参数，起步蹿车和跟车迟滞会同时出现，只能说每个车都得重新标一遍，不存在“一套参数打天下”的美事。

6. 预测模块：不是“预测一条轨迹”那么简单

6.1 目标级预测与意图识别

预测模块要做的事情，很多人以为是“未来 5 秒走过去的那条曲线长什么样”。这话对，但不够完整。预测模块真正的难点是识别目标“想干什么”，然后再对他可能的动作做轨迹预测。

同样是前方 30 米的一辆车，直行意图和右转意图对应的未来位置分布完全不同，如果预测模块只输出单条轨迹，一旦目标实际行为与预测不符，规划模块只能被动反应，很容易出现急刹车。因此 AutoWareAuto 里的预测模块会同时输出相互独立的若干条假设轨迹，比如“保持直行概率 70%”“减速靠边概率 20%”“突然切入本车道概率 10%”，每一条都带着概率估计和轨迹点序列。

6.2 交互场景下的多假设轨迹输出

交互预测是做得比较深的部分。比如我车想变道到左侧车道，而左后方有辆车正在加速靠近，这两件事是耦合的：对方的加速行为可能恰恰是因为他预料到我会变道。如果预测模块只把对方车辆当做一个独立运动物体，不去考虑我的意图对他行为的影响，那预测就失去了交互性。

AutoWareAuto 的预测模块在实现上会维护一个“目标级运动模型”，并结合车道结构先验信息，目标所在车道、是否有岔路口、红绿灯状态等，都会作为轨迹生成的约束条件。目标在路口前减速，预测轨迹会更大概率给出“右转”或“停车”的分支；目标在本车道内平滑行驶，预测轨迹则集中在“保持车道”。

6.3 预测结果如何反馈给决策层

预测模块输出的概率化轨迹会直接传给决策规划模块，决策层在计算风险时不再只看当前时刻的障碍物位置，而是看未来 3 秒内自车轨迹与每条预测轨迹是否可能在时空上产生冲突。

这里有个很关键的工程点：概率阈值不能设太高，否则系统对突发变道反应太慢。我一般把“潜在冲突”的判定阈值设在 0.2 以上，也就是说只要预测模块认为对方有超过 20% 的概率进入自车未来路径，规划层就要准备减速或让行，而不是等对方真的变过来了才开始动作。预测模块是整个框架里最容易被低估的一环，但没有它，决策规划就只能是反应式的，开起来会非常“愣”。

7. 模块间通信与工程落地：从能跑到跑得稳

7.1 消息/话题接口设计：先定契约，再写实现

我自己重构过一版 AutoWareAuto 的消息接口，最大的体会是：模块之间的接口约定，直接影响整个项目的研发效率。自动驾驶框架里有大量“同语义、不同精度”的数据，比如感知检测出的障碍物、预测模块处理后的障碍物，如果每个模块各自定义一套障碍物格式，集成就变成灾难。

正确的做法是先定义一套统一的消息协议，再让各模块向这套协议看齐。比如障碍物消息需要包含：全局唯一 ID、类型枚举、三维包围盒、运动状态（速度、加速度）、历史轨迹、置信度、时间戳。感知模块输出原始检测结果时填充它的置信度，预测模块输出预测结果时填充未来轨迹和概率，规划模块只管订阅协议里定义好的字段，不关心数据来源。这套设计让模块可以独立替换、升级，也不需要把所有模块同时重编译。

7.2 实时性优化：丢帧、延迟、缓冲区怎么处理

自动驾驶的实时性要求是硬性的。传感器数据以 10 Hz 到 20 Hz 的频率进入系统，规划控制链路必须在下一帧数据到来前完成处理，否则要么跳过当前帧，要么用上一帧结果继续控制，两种方式的后果都得仔细考量。

我处理这类问题的经验是先做端到端延迟测量，把激光雷达时间戳记为 T0，控制模块收到轨迹的时间记为 T1，正常情况下 T1 减 T0 应该稳定在 80 到 120 毫秒。如果超过 200 毫秒，就要排查瓶颈。常见瓶颈有三个：点云预处理用了单线程且体素网格太大；目标跟踪模块的匈牙利匹配在大目标数量下退化成了 O(n^3) 复杂度；规划模块在每条轨迹上都跑了完整碰撞检查。针对这些瓶颈分别优化线程池、匹配算法和碰撞检查的提前剪枝即可。

7.3 回放、可视化、日志：联调三板斧

没有回放工具，自动驾驶调试基本没法做。我习惯的做法是：所有传感器原始数据、中间结果、最终输出都带录制和回放功能，出了问题时把它录下来，离线逐帧回放，用可视化工具同时看点云、障碍物框、定位轨迹和规划轨迹。

日志分析是我认为最值得安利的习惯。很多人只在出问题时打点,平时不记录，结果问题复现不了。正确做法是给每个模块都增加详细日志，包括模块输入的时间戳、输出结果的处理耗时、关键判断分支走了哪个分支，日志要支持按模块和按级别过滤，跑一次路测就能生成结构化日志，回去用脚本统计分析哪个模块最耗时、哪个状态机卡住了，调试效率能提升一个量级。

8. 全流程集成联调中必须面对的四个实际教训

8.1 感知误检让规划器“急刹车”：先区分真假误检

我第一次联调时遇到最诡异的现象是：车辆在空旷场地里开得好好的，突然一脚急刹车，但可视化界面上看不到任何障碍物。排查日志时发现急刹前的瞬间感知模块确实输出过一个“障碍物”，持续两帧后消失了。

这个问题背后是感知和决策已经解耦过头的典型表现：感知模块短时误检，决策规划模块把它当成真实目标做了紧急制动。我的解决办法分两步：第一步是在感知跟踪状态机上把目标确认帧数从 3 帧提升到 5 帧，减少单帧误检；第二步是在规划层面给“突然出现的近距离障碍物”增加一个最小确认时间窗口，目标必须连续出现在视野里超过某个时间阈值才能触发紧急刹车行为。这两步叠加之后，空场地急刹的问题再也没出现过。

8.2 定位跳变导致控制震荡：回查协方差

还有一次车辆在路上左右画龙，方向控制一直在使劲纠正。我第一反应是横向控制参数太激进，调了好几次，效果一般。后来把定位输出的位姿序列画出来才看到，定位轨迹存在周期性跳变，每跳一次横向控制就猛打一把方向修正。问题根源是点云全局匹配偶尔会陷入局部极值，输出位姿大幅偏离真值，而滤波器的更新增益给得太高，没能抑制这个跳变。

解决思路是降低滤波器对点云匹配观测的信任权重，同时增加一项跳变检测：当前匹配结果与预测位姿的偏差如果超过某个阈值，就跳过这一帧的观测更新，把位姿交给 IMU 积分来维持。表面看这是降低了定位精度，实际换来的是输出的稳定性，对控制模块来说，稳定的低精度好于震荡的高精度。

8.3 时间戳对齐：所有“灵异问题”的隐藏根源

这类多传感器融合系统，有一个几乎必踩的坑：传感器之间时间基准不一致。激光雷达和相机各自有内部时钟，如果不用统一的同步机制，它们打出的时间戳差出 100 毫秒是很常见的事。而车辆在 30 m/s 时速下，100 毫秒就是 3 米的位置误差，感知把障碍物位置和速度算错，规划和控制自然就乱套了。

解决方案是引入统一的时间同步机制，让所有传感器数据在进入感知模块前就被贴上主机时间的时间戳，感知、定位、规划各模块在处理消息时都必须基于同一份时钟基准。这个改造看起来只是加了个时间同步模块，实际上对系统稳定性的提升是质变级别的，因为一旦时间基准统一，后面排查很多问题就不用再怀疑数据错位了。

8.4 封闭场地到开放道路：验证边界条件的差异

最后一条经验可能比较偏“管理”，但对项目落地很重要。仿真环境和封闭场地上的成功，最多只能证明逻辑正确，无法覆盖开放道路的长尾场景。天气变化、非机动车混行、道路施工标志、旁边车道车辆的突发变道，这些在代码逻辑里都是“可能需要处理但很难穷尽”的情况。不管 AutoWareAuto 这类框架的能力标签写得有多完整，到了实际路测阶段，把所有模块边界条件重新梳理一遍都是必须做的功课。

我在实际使用中的体会是：这套框架最值钱的地方不在于某个单点算法的性能有多强，而在于它把五件事整合在一个统一的数据流和消息协议里，让“我从哪里来、周围有什么、接下来去哪里、方向盘该转多少”这些自动驾驶的核心问题全部串在了一条链路里。踩过的坑当然不少，但每掉进一个坑，都会逼我把整个模块链路的数据关系重新梳理一遍，这个反复梳理的过程本身就是最好的系统学习方式。

如果你正在为毕业设计或工程验证搭建自己的自动驾驶平台，我建议你用 AutoWareAuto 的思路搭软件骨架，再按你自己的传感器配置和控制需求去替换各模块。第一步先让数据流完全打通，哪怕只是跑一圈最简单的停车场路线——不要一上来就追求变道超车，先把全链路的延迟、时间戳、坐标系这三件事调顺，后面的迭代会轻松得多。