学术应用·046|自动驾驶感知:点云、图像和速度要一起说清楚

写在前面

自动驾驶里的“感知”，听起来像是在回答一个简单问题：车看见了什么？

但工程里真正要回答的，往往不是“看见”，而是更具体的几件事：前方有没有车，车在哪里；路面区域在哪里；点云里的每个点属于什么类别；自车和目标车正在怎样运动，速度是否足够稳定，可以交给后续规划模块使用。

王麒的博士论文《基于深度学习的自动驾驶感知算法》就是围绕这些问题展开的。它没有把自动驾驶讲成一个完整系统，而是把目光放在感知模块内部：激光雷达点云怎样做三维目标检测，图像和点云怎样互相补信息，单帧检测之后怎样进一步估计自车和目标车辆的位姿与速度。

这篇论文的价值，不在于给出一个“万能感知网络”。更准确地说，它提供了一组问题拆法：点云检测解决空间位置，图像-点云融合补足语义和几何，位姿网络与观测器把单帧结果推进到连续运动状态。

论文与项目信息

这篇论文到底讲什么

一句话概括：

这篇论文研究自动驾驶感知中的三个连续问题：先用点云检测三维目标，再让图像和点云互相补充，最后把单帧感知结果扩展到车辆位姿和速度估计。

论文的主线可以拆成三块：

这里有一个容易被忽略的点：论文并不是只追求“检测准确率”。它关心的是感知结果能不能继续被决策和规划使用。检测框告诉系统“车在哪”，道路分割告诉系统“哪里能走”，速度估计告诉系统“接下来会不会撞上”。

为什么不能只靠图像，或者只靠点云

相机和激光雷达看到的是同一个交通场景，但它们并不以同一种方式表达世界。

图像是稠密的。每个像素都有颜色、纹理和边缘，车道线、交通标志、行人外观都比较容易被表达出来。但图像天然缺少准确的三维深度，尤其在遮挡、远距离和尺度变化下，空间位置容易变得含糊。

点云是稀疏的。激光雷达直接给出三维坐标，距离和几何结构更可靠，但点没有天然顺序，也没有图像那样连续的纹理。近处车辆表面可能有足够多的点，远处车辆可能只剩下一小撮点。点云检测的难点，不是把点画出来，而是从稀疏、无序的点里恢复出物体中心、尺寸和朝向。

所以论文选择了两步走：

先研究只用点云时，怎样把三维检测做好；再研究相机和激光雷达都在车上时，怎样让两类信息互相传递。

3D-CenterNet：先找中心，再回归检测框

3D-CenterNet 的基本判断很直接：对三维目标检测来说，物体中心点比表面上的任意一个点更关键。

激光雷达扫到的通常是物体表面点。问题是，表面点并不稳定：同一辆车，距离不同、角度不同、遮挡不同，扫到的点都会变。论文的做法是让网络从这些表面点出发，逐步回归到更接近物体中心的位置，再用中心点特征估计检测框。

网络结构上，3D-CenterNet 使用 PointNet++ 作为点云特征提取主干，并设计串联的中心点回归模块。论文实验中，输入点云从相机视野内随机采样为 16384 个点；第一个中心点回归模块选取 1024 个关键点，第二个模块进一步选取 64 个关键点。经过多次中心点回归后，检测头再输出类别、尺寸、朝向和三维框。

这个设计的意义不只是“换一个网络结构”。它是在处理点云的一个基本矛盾：检测框要描述的是完整物体，而传感器看到的只是物体局部表面。

在 KITTI 测试集上，3D-CenterNet 的部分结果如下：

运行效率方面，论文报告 3D-CenterNet 在 NVIDIA TITAN XP 上一次前向计算约 0.06 秒。论文也提醒，漏检和错检更多发生在远距离场景，因为远处目标的点云变少，几何形状已经不足以稳定描述完整物体。

PI-Net：不是把点云变成图，而是让两边互相说话

很多图像-点云融合方法会先把点云投影成深度图、伪图像或其他二维表示，再交给卷积网络处理。这样做方便，但也可能损失点云自身的三维结构。

PI-Net 的思路更像是在两种坐标系统之间建立翻译通道：

论文把这个模块称为 PI-Fusion。它的关键不在“融合”这个词，而在双向：图像任务可以借点云的空间信息，点云任务也可以借图像的外观信息。不同任务可以共用融合后的特征主干，再接不同的任务头。

PI-Net 在三个任务上做了验证。

第一，道路分割。在 KITTI 道路分割测试集上，PI-Net 取得 MaxF 96.52%、AP 94.03%、Precision 96.57%、Recall 96.46%。论文中的可视化结果显示，错误分割多发生在道路边缘。

第二，3D 目标检测。在 KITTI 3D 检测任务中，PI-Net 基于 PV-RCNN 加入图像融合。在 Car 类别的 Moderate 难度上，3D 检测为 81.23%；在 Cyclist 类别上，Easy、Moderate、Hard 三档 3D 检测分别为 83.15%、67.69%、60.62%。论文特别指出，图像信息对 Cyclist 这类样本较少、外观特征更有帮助的类别提升更明显。

第三，点云语义分割。在 SemanticKITTI 验证集上，加入 PI-Fusion 后，PointNet++ 的平均 IoU 从 42.91% 提升到 47.34%，RandLA-Net 的平均 IoU 从 52.25% 提升到 54.12%。对于 bicycle、motorcycle、sidewalk、fence 等有形状或纹理特征的类别，融合带来的提升更明显；但对极小样本类别，论文也给出了谨慎解释，例如 motorcyclist 在验证序列中没有出现，IoU 长期为 0，参考价值有限。

这部分最有工程味的一点，是论文没有把融合当成无条件增加模块。消融实验给出一个比较实用的规则：

这说明融合不是“越多越好”。如果任务最终在图像平面上评测，就没有必要把全部信息再绕回点云；如果任务最终在点云上评测，也不一定需要付出完整双向传递的计算成本。

位姿与速度估计：感知不止是框，还包括运动

检测框回答的是“这一帧里车在哪里”。但自动驾驶规划需要的是“这辆车接下来会怎样动”。所以论文第 4 章把问题推进到自车和目标车辆的位姿、速度估计。

这里的处理方法分成两层：

这个设计有一个清楚的分工：神经网络负责从点云里提取语义和几何，观测器负责把连续时间里的位姿变化整理成速度。论文没有把所有事情都塞进一个黑箱网络，而是让可学习模块和可解释的动态估计方法各做一部分工作。

在 MATLAB 仿真中，论文使用 Automated Driving Toolbox 构建城市道路场景，包含避障、双移线跟车、十字路口跟车等工况。激光雷达点云频率为 10Hz，仿真时长 12 秒，位姿和速度真值由 Simulink 以 100Hz 提供。速度估计对比中，论文统计 1 秒收敛后的平均绝对误差：

在校园实车实验中，自车为观光车，目标车辆为 SUV，场景为环岛跟车。自车搭载 Velodyne 32 线激光雷达和差分 GPS，目标车搭载 GPS/IMU 组合导航系统。论文用 GPS/IMU 结果作为真值参考，并对比了多种位姿估计方法。

自车位置平均绝对误差如下：

目标车辆位姿估计结果如下：

效率方面，位姿估计网络一次前向约 0.06 秒；以网络估计为初值再做 ICP，平均收敛时间约 0.02 秒；速度观测器一次估计约 1.17 × 10^-5 秒。论文给出的整体方法运算时间约 0.08 秒，基本匹配 10Hz 激光雷达逐帧处理的需求。

这篇论文真正想解决的，不是“看得更准”

把三部分放在一起看，会发现论文一直在处理同一个矛盾：

感知系统拿到的是传感器原始数据，但下游模块需要的是结构化、稳定、可连续使用的状态量。

原始点云不是检测框，图像像素不是道路边界，连续点云帧也不是速度。中间需要一系列转换：

所以这篇论文并不是在重复“用神经网络做感知”这句话，而是在讨论感知结果怎样一步步变成规划能使用的事实。

论文的边界也要看清楚

第一，论文中的实验以 KITTI、SemanticKITTI 和校园低速场景为主。它验证了方法在公开数据集和受控实车场景中的有效性，但不能直接等同于任意道路、任意天气、任意交通密度下的完整自动驾驶能力。

第二，图像-点云融合仍然依赖准确的外参标定和时间同步。只要相机和激光雷达之间存在对齐误差，融合模块拿到的对应关系就会被污染。

第三，远距离、小目标、遮挡目标仍然是点云方法的薄弱处。论文自己的失败案例也指出，远处目标表面点太少会导致漏检；环境几何形状与车辆相似时，可能发生错检。

第四，连续帧位姿估计依赖相邻点云之间有足够公共覆盖区域。当车辆运动过快、转弯明显、点云重叠区域变小时，自车位姿估计误差会上升，后续速度估计也会受到影响。

可以带走的几点启发

最后

这篇论文把自动驾驶感知拆成了几个很实在的环节：点云要变成框，图像和点云要对齐，单帧结果要进入时间序列，速度估计要足够平滑。

它讨论的不是车“有没有看见”，而是传感器数据怎样变成可以被下一步计算使用的状态。