夜雨聆风
自动驾驶圈这两年吵得最凶的一个问题：端到端到底能不能干掉模块化？
特斯拉说能，一个网络从像素到方向盘，梯度从控制端一路回传到传感器输入，整个系统联合优化。华为、小鹏也跟着往端到端冲。百度Apollo呢？依然坚持模块化——感知、预测、规划、控制各司其职，用明确的接口隔开。
我读Apollo源码读到现在，感知上篇拆完了LiDAR点云处理链。这篇来拆更核心的问题：Camera和LiDAR的检测结果，Apollo是怎么融到一起的？这种后融合架构，在端到端时代还站得住脚吗？
Camera先干了什么
LiDAR管几何，Camera管语义。这个分工在Apollo里体现得很直接。
Camera管线分两条腿走路：障碍物检测和车道线检测。
障碍物检测，Apollo先后用过YOLO3D和SMOKE。YOLO3D基于Darknet骨干网络，输入1440×800的图像，同时输出2D边界框和3D信息（方向、距离估算）。SMOKE是后来加入的，单目3D检测，基于关键点估计，用PyTorch训练再通过torch.jit.trace转成libtorch部署。
车道线检测，早期用DarkSCNN，后来换成了Denseline。核心思路都是语义分割——先像素级分割出车道线区域，再后处理拟合出多项式系数，最后从图像坐标系投影到世界坐标系。
检测完还得跟踪。Camera端的障碍物跟踪用自适应卡尔曼滤波，恒加速度模型，通过帧间相似度做关联——上一帧的障碍物和当前帧的哪个最像，就连上。
到这里，Camera管线输出的是：一堆2D/3D边界框（带类型标签、速度、方向）+ 车道线参数。
LiDAR那边，上篇已经拆过了，输出是：分割→聚类→跟踪后的3D障碍物列表。
两路结果格式不同，精度不同，时间戳也对不齐。怎么合？
ProbabilisticFusion：Apollo的后融合核心
Apollo选的是后融合——Late Fusion，决策级融合。每个传感器先各自检测、跟踪，输出障碍物列表，最后在融合模块里做匹配和合并。
核心类是ProbabilisticFusion，定义在modules/perception/fusion/lib/fusion_system/probabilistic_fusion/下。配置文件probabilistic_fusion.pt写得明明白白：
use_lidar: true
use_radar: true
use_camera: true
tracker_method: "PbfTracker"
data_association_method: "HMAssociation"
gate_keeper_method: "PbfGatekeeper"
prohibition_sensors: "radar_front"
max_lidar_invisible_period: 0.25
max_radar_invisible_period: 0.50
max_camera_invisible_period: 0.75
max_cached_frame_num: 50
几个关键参数值得注意。
主传感器是LiDAR。Apollo有"发布传感器"的概念——只有LiDAR的帧到达时才触发融合动作，Camera和Radar的结果先缓存着，等LiDAR来了再一起处理。融合频率等于LiDAR频率。
不可见周期各不相同。LiDAR最短0.25秒，Radar 0.5秒，Camera最长0.75秒。Camera不可见容忍度最高，因为它容易丢——遮挡、逆光、夜间都会导致Camera检测中断，但目标可能还在。LiDAR最不耐受，因为LiDAR一旦看不见，大概率目标真的不在了。
Radar不能创建新航迹。prohibition_sensors: "radar_front"——前雷达检测到的目标，只能去匹配已有航迹，不能凭空新建。因为雷达精度低、误检多，给它建航迹的权限只会引入噪声。
融合四步走：关联→匹配→更新→门限
第一步：数据关联
HMAssociation——基于匈牙利算法的二部图匹配。
当前帧的传感器检测目标和新旧航迹之间，先算一个关联矩阵，值是锚点间的欧氏距离。然后建二部图，切掉超过阈值的边，对每个连通子图跑匈牙利匹配，O(n³)复杂度。
匹配完，分三拨：匹配上的（assignments）、没匹配到观测的航迹（unassigned_tracks）、没匹配到航迹的观测（unassigned_measurements）。
Apollo还加了一步PostIdAssign——对没匹配上的再做一轮ID关联，检查是否之前就关联过。这是Apollo的工程优化，减少频繁新建和删除航迹。
第二步：四维融合更新
匹配上的航迹，通过PbfTracker::UpdateWithMeasurement依次更新四个维度：
存在性融合（DstExistenceFusion）——用D-S证据理论判断"这个目标到底存不存在"。每来一个传感器的观测，就更新一次存在概率。两个传感器都看见了，存在概率叠加升高；一个看不见，概率下降但不直接归零。这比简单投票鲁棒得多。
运动融合（KalmanMotionFusion）——自适应卡尔曼滤波，恒加速度模型。状态包括锚点位置、速度、加速度。有意思的是，Apollo用了观测冗余——速度的测量值同时从锚点偏移、边界框中心偏移、角点偏移三个来源取，哪个最可靠就用哪个。还有一个Breakdown机制：卡尔曼假设噪声是高斯的，但实际驾驶数据经常是肥尾分布，Breakdown阈值用来抑制过大的更新增益。
形状融合（PbfShapeFusion）——根据匹配的测量量更新目标尺寸、方向角、多边形轮廓。LiDAR对形状的测量比Camera可靠得多，所以形状主要听LiDAR的。
类型融合（DstTypeFusion）——又是D-S证据理论，加上线性链CRF（条件随机场）。CNN输出的类型概率作为CRF的一元势，类型转移概率作为二元势，用Viterbi算法解码，得到时序上最平滑的类型序列。这解决了"同一目标上一帧是车下一帧变成行人"的抖动问题。
第三步：未匹配航迹的衰减
没匹配到观测的航迹，PbfTracker::UpdateWithoutMeasurement——存在概率下降，运动状态靠预测外推，类型不变。如果在不可见周期内一直没有新观测匹配上，航迹就被删除。
第四步：门限控制
PbfGatekeeper决定融合后的目标是否发布。不是所有融合结果都有资格输出——存在概率太低、位置不确定性太大、或者只在Radar里出现过没有LiDAR或Camera确认的，都会被拦下。
后融合的软肋
把Apollo的融合管线从头读到尾，最大的感受是：工程上很漂亮，理论上很保守。
后融合的好处显而易见——模块化、可调试、容错好。LiDAR挂了Camera还能顶着，Camera逆光了LiDAR不受影响。每个传感器的管线独立开发独立优化，出了问题定位明确。
但后融合有一个绕不过去的硬伤：信息损失。
Camera检测完输出一个3D边界框，原始图像里多少纹理、阴影、上下文信息全扔了。LiDAR检测完输出一个点云簇，点云的密度分布、反射强度细节也丢了。到融合模块手里，只剩一堆边界框和概率值。如果Camera没检测到远处的行人，但LiDAR发现了一个模糊的点簇，融合模块拿到的只是"Camera没看见"+"LiDAR不太确定"——它再也无法回头去看原始图像，确认那个位置到底有没有人。
这正是端到端方案攻击模块化的核心论点：局部最优拼不成全局最优。每个模块各练各的，检测的mAP、跟踪的MOTA都是各自的指标，和最终"开得好不好"不是一回事。
端到端不是万能药
但端到端的问题也不少。
2025年6月，Tesla和Waymo同时在奥斯汀上线Robotaxi。Tesla纯视觉端到端，Waymo多传感器模块化+端到端混合。现实是，端到端在泛化性上确实强——数据喂够就能学会处理各种长尾场景，不用工程师一条条写规则。但在安全验证上，黑箱是硬伤。出了事故，你没法解释"网络为什么这么决策"，监管不买账。
华为JDC那份报告说得明白：短期最可行的不是完全端到端黑箱，而是混合架构。底层控制和安全冗余保持工程化约束，中层由端到端模型生成候选策略，上层用规则和安全检查兜底。
回到Apollo的融合，它其实也在变。最新版本里，Camera感知已经往BEV+Transformer方向迁移——多摄像头特征先编码到鸟瞰图空间，再和LiDAR的BEV特征做中间层融合。这不再是纯后融合了，更像是中融合（Feature-Level Fusion）。BEVFusion、TransFuser这些2023-2025年的工作，已经证明中间层融合在性能上明显优于纯后融合——既保留了一定的模块化优势，又让跨模态特征交互成为可能。
Apollo当前开源版本的ProbabilisticFusion还是经典后融合。但百度Apollo Go 2026年一季度交付了320万次全无人运营订单，三月周峰值超35万次，那个量产系统里的融合架构，大概率已经不是我现在读到的这套了。
我的判断
读源码不是读论文。论文追求SOTA，源码追求工程落地。
Apollo的后融合架构，在2017-2022年这个阶段，是最务实的选择。传感器标定不那么精确？后融合容忍度高。某个传感器偶尔挂？其他管线不受影响。团队协作？各管一摊，接口清晰。
但2025年往后，纯后融合的瓶颈会越来越明显。BEV+Transformer把Camera多视角特征统一到俯视图，LiDAR点云体素化后也在BEV空间，两个BEV特征图做注意力融合——信息损失大幅减少，跨模态关联能力指数级提升。这不是"后融合微调一下就能追上"的差距，是架构层面的代差。
Apollo的代码仓库目前还停留在后融合。如果你在做自动驾驶感知，我的建议是：读懂后融合的工程逻辑（D-S证据理论、匈牙利匹配、自适应卡尔曼），这些底层方法论不会过时；但架构方向上，BEV中间层融合才是未来。
端到端和模块化不是非此即彼。最有可能的终局是：模块化框架提供安全壳，端到端模型负责性能上限。Apollo的后融合代码，就是理解这条演进路线最好的起点。
本系列基于Apollo 8.0源码，下一篇：预测模块——3秒轨迹预测的Evaluator+Proposer双模型。
