1. 为什么3D目标检测绕不开体素表示先聊一个基础问题做3D目标检测手里拿到的原始数据是什么绝大多数情况下是激光雷达点云——几万到几十万个点每个点带着xyz坐标可能还有反射强度。这东西看起来信息很足但直接用起来极其棘手。我最早接触3D检测时第一反应是“把点云当成图像处理不就行了”。后来发现自己太天真了。点云有三个天然特性让常规网络很难直接吃下去无序性——点的排列顺序任意同一个场景换个存储顺序数据就变了稀疏性——一帧64线激光雷达的点云在三维空间里覆盖的体积可能只有百分之一不到密度不均匀——近处密密麻麻远处稀稀拉拉同一物体表面的点间距差出几倍。如果直接把原始点云塞进全连接层输入维度得按最大点数来定但一帧里实际点数又是动态变化的这个问题根本绕不过去。所以业内主流做法是先把点云“结构化”——把点云映射到一个规则的表示上让它像图像一样有整齐的网格结构然后再用卷积或全连接去处理。体素表示Voxel Representation就是这个“结构化”思路里最经典、最通用的一条路线。它的核心思想非常朴素把三维空间切成一个个小立方体格子每个格子里落进去的点通过某种方式聚合为一个特征这样一整帧点云就变成了一个规则的、维度固定的三维网格——你可以把它想象成三维版的像素点阵。之后无论是用3D卷积、稀疏卷积还是把它压成BEV俯视图再用2D卷积都变得顺理成章。这篇综述先讲清楚体素表示这一支的核心内容体素化怎么做、特征怎么聚合、有哪些经典网络结构、工程上有什么坑。下一篇再展开对比它和基于点的方法PointNet系、基于图的方法之间的优劣以及多模态融合里体素表示扮演的角色。2. 点云为什么要体素化从数据特征说起2.1 点云的无序性与排列不变性这里必须把“无序性”讲透。图像里每个像素有固定位置像素之间的空间关系由坐标天然定义好了卷积之所以有效就是因为它能利用这种规则的局部空间结构。点云不一样它只是一堆独立的三维坐标点没有任何隐式的“顺序”同一个场景你想怎么排列这几十万个点都行。如果设计一个网络直接吃原始点坐标比如把一帧内所有点按顺序拼成一个长向量输入全连接层那同样的场景只要换一下点的存储顺序网络输出就变了——这显然是不可接受的。所以处理点云的网络必须满足排列不变性输入顺序怎么打乱输出结果都一样。体素化天然解决这个问题。点在体素网格里的位置由坐标唯一确定跟点云里点的存储顺序无关体素跟体素之间的相对位置也固定下来了。体素化之后数据变成了规则网格排列不变性自动满足也不需要再纠结点顺序问题了。2.2 稀疏性与计算浪费的权衡点云的另一大特征是稀疏。在三维空间中真正有物体占据的区域非常有限大量空间是空的。假设你在100米×100米×10米的空间里做检测如果体素大小选0.1米那总共有1亿个体素格子。但一帧点云通常只有几万个点覆盖的体素数大约只有几百万——99%以上的格子是空的。这意味着什么如果你老老实实做稠密的三维卷积绝大多数计算都花在空体素上白费算力。这也是体素表示早期被诟病的点显存占用大、计算效率低。后来的方案分化成两条路一条靠稀疏卷积绕过空体素只对非空格子做计算另一条靠把三维网格压缩成BEV俯视图鸟瞰图用2D卷积替代3D卷积把计算量降一个量级。这两条路后面详细说。2.3 密度不均匀带来的尺度难题激光雷达点云近密远疏是物理规律决定的。同一个物体离传感器5米时表面可能落了上百个点离50米时只剩十几个点。这对“以点的数量为特征”的方法很不友好——同一个物体距离不同点的统计特征差异极大。体素化在这里反而提供了一个优势体素是一个空间区域无论区域内点有多少最终都聚合成一个固定维度的特征向量。通过设计合适的聚合方式比如直接取所有点的坐标均值、反射强度均值、最大强度等可以在一定程度上弱化点数差异带来的影响。当然远距离物体落在体素内的点数太少聚合出来的特征往往不稳定这个问题在后面调参时还会遇到。3. 体素化的完整过程从原始点云到规则网格3.1 体素大小怎么定体素化第一步是确定体素尺寸即每个小立方体的边长。这个参数直接决定后续计算的复杂度和检测精度的上限几乎是一帧点云处理中最重要的超参数之一。体素大小和空间分辨率的关系是体素越小网格越密能保留的空间细节越多但计算量和显存占用也随之增长。体素太大多个物体的点可能被塞进同一个格子里特征混淆小物体行人、骑行者会直接被“抹平”丢失关键几何信息。工程上一个常用参考值对于以检测车辆为主的任务体素边长在0.05米到0.1米之间比较常见需要在较远距离检测行人时倾向于把体素调小到0.05米左右否则行人体积小对应体素数太少检测器根本“看不见”。但这个选择也和点云密度强相关——如果用的是16线雷达点云密度远低于64线体素太大格子太空太小则大多数体素内没有点两种情况都浪费需要做实验实测。3.2 坐标映射与离散化确定体素大小后接下来的操作就是把连续的空间坐标离散化。假设点云中某点的坐标为 (x, y, z)体素边长为 v则该点所在的体素索引计算方式是体素索引x floor(x / v)体素索引y floor(y / v)体素索引z floor(z / v)这里有个细节坐标原点的选取。通常会把传感器位置作为原点或者把感兴趣区域ROI的某个角点作为原点。推荐统一用ROI范围的最低点作为原点这样得到的体素索引都是非负整数方便后续处理。若直接以传感器为原点检测范围会向负方向延伸索引出现负数处理起来麻烦得多。实际工程中还会先把点云裁剪到ROI范围内比如 x 方向 0到70.4米y 方向 -40到40米z 方向 -3到1米。超出范围的直接丢掉。这个预裁剪既减少计算量又避免远处无关点干扰特征聚合。3.3 体素内的特征聚合从手工特征到可学习特征体素化只是把点分到了格子里真正决定检测性能的是体素特征怎么算。这一块经历了两个阶段非常值得展开讲讲。早期方法用的是手工特征。每个体素内统计点的数量计算所有点的坐标均值、反射强度均值以及它们相对体素中心的偏移。这些统计量拼接起来就是体素特征。优点是计算极快不需要学习参数缺点是表达能力有限难以捕捉体素内部的局部几何结构。后来业界普遍转向可学习特征代表方法是VoxelNet中提出的Voxel Feature EncodingVFE层。思路是每个体素内最多取T个点超出部分随机采样丢弃不足则补零把每个点的坐标、反射强度以及该点相对体素内所有点质心的偏移拼成一个特征向量然后经过一个小型全连接网络加最大池化得到体素级特征。关键在于这个全连接网络是可学习的它自动从体素内的点集中提取对检测有用的几何信息而不是靠人工指定统计量。实际实现中VFE层的效果在多数数据集上优于手工特征因为它能学习到类似“局部表面朝向”“边缘锐度”这类更抽象的几何模式。后续PointPillars也沿用类似思路只是把体素从立方体换成了柱子柱状体稍后讲。3.4 空体素与点数上限的处理每个体素内点数的差异可以非常大——近距离墙面上一个体素内可能有几十个点远处车辆表面的体素里可能只有孤零零一个点。直接拿原始点数输入网络会有两个问题数值范围不稳定以及计算图尺寸无法固定。业界通行做法是设置一个点数上限T。体素内点数超过T时随机采样保留T个不足T个时用0填充。这个T通常设在32到64之间。太大增加计算量太小丢失几何细节。我在自己的项目里实测T32在性能和速度上比较均衡但如果你处理的是高线束雷达且ROI较近64会让小物体的特征更稳定代价是体素特征提取阶段速度下降需要自己权衡。4. 经典网络怎么用体素表示三条技术路线4.1 VoxelNet端到端学习的奠基之作VoxelNet是最早把体素化、特征提取、3D卷积检测头统一到端到端框架里的工作之一它的设计逻辑在今天看依然清晰值得捋一遍。整体分三步第一步做体素化把点云转成体素网格第二步用VFE层对每个非空体素提取特征得到体素特征张量第三步用3D卷积在体素网格上做特征提取逐步把空间分辨率降下来扩大感受野最后接一个Region Proposal Network输出检测结果。VoxelNet的贡献在于证明了两件事一是手工设计的点云特征不是必需的端到端学习完全可行二是3D目标检测可以像2D检测一样分成“特征提取区域提议”两大块。计算量确实大早期版本在单卡上推理速度只有几帧每秒但它奠定了后续一系列工作的基础。4.2 SECOND稀疏卷积把速度提上来VoxelNet最大的问题是慢。SECOND的改进非常干脆用稀疏卷积替代密集3D卷积。核心洞察是体素网格绝大多数格子是空的密集卷积大量算力浪费在空体素上稀疏卷积只对非空体素及其邻近区域做计算速度提升非常明显。稀疏卷积的原理可以这样理解它内部维护一个哈希表记录非空体素的位置和特征卷积只在有值的格子及它们周围可能被填充的邻居上进行。这样空体素不会参与乘加运算显存占用也大幅下降。SECOND在KITTI上精度超过VoxelNet速度却快了一个数量级这让体素表示第一次具备实用价值。工程上有个重要细节稀疏卷积对硬件利用率的提升取决于稀疏度。点云越稀疏收益越大但如果场景点云密度很高非空体素占比变大稀疏卷积优势会被稀释。在校园、园区这类近距离高密度场景下稀疏卷积的加速比没有公开数据集上那么夸张实测大概3到5倍但仍然比密集卷积靠谱。4.3 PointPillars用柱子把3D问题变成2D问题PointPillars走了一条更激进的路线。它不用立方体体素而是把点云在z方向上按整个垂直范围直接压成一个柱状体这样三维空间被切分成(x, y)平面上的一个二维网格每个格子向上一柱到底。每个柱状体内做类似VFE的特征聚合得到的就是一个天然的BEV特征图直接接2D卷积即可完全绕开3D卷积。这个设计的聪明之处在于z方向的信息在特征聚合时已经融入每个柱子的特征里了后续处理只需要做2D卷积计算量比3D卷积低一个量级。PointPillars在推理速度上达到了可以实时跑的水平精度相比VoxelNet也没输太多。对很多工程场景来说速度就是一切所以PointPillars成了部署优化绕不开的基线。不过也要知道它的局限柱状体在z方向只有一个格子垂直方向的空间分辨率其实被牺牲掉了对坡道、地下车库这类垂直结构丰富的场景表现会打折扣。如果业务场景对Z轴变化不敏感比如高速公路上检测车辆PointPillars的取舍是完全值得的。5. 从体素到BEV为什么最终大多收敛到俯视图如果你认真跑过几个3D检测模型会发现一个现象不管是基于体素还是基于点的方法最终提取特征时大家都倾向于把三维特征压缩到BEVBirds Eye View鸟瞰图去输出检测框。这不是巧合背后有多层原因。第一物体在道路上基本只有平移和旋转没有大幅翻转在BEV视角下物体的形状和朝向都保持稳定不会因为旋转而变化。2D图像里一个车侧着看和正着看是完全不同的样子但在BEV里同一辆车不管朝哪个方向呈现出来的都是它的“俯视轮廓”检测器要学的模式简单得多。第二BEV空间是欧几里得空间物体的尺寸和距离保持线性关系不像透视投影那样近大远小。这意味着一个在图像域学到的锚框尺寸在BEV里可以直接复用到不同距离的物体上适用性更强。第三计算效率优势。三维体素网格经过若干层3D卷积后最终在z方向上的分辨率已经压到很低把这最后一个维度直接去掉或者用几个卷积把z维信息融合掉就变成了BEV特征图之后就可以调用成熟的2D检测框架比如类似SSD、RetinaNet的检测头来出框。这是工程上最容易实现、训练最稳定的路径。以SECOND为例它的网络也遵循这个逻辑3D稀疏卷积负责提取三维几何特征然后压缩成BEV特征后面的RPN完全是在BEV图上做的。体素表示在早中期的特征提取阶段发挥核心作用但最终检测头回归的是BEV坐标系下的位置、尺寸和朝向。6. 体素表示在工程落地中的关键细节与避坑6.1 体素尺寸的分层策略我在自己的项目里踩过的第一个坑就是试图用一套体素尺寸处理所有场景。后来发现不同距离下体素的最佳尺寸差异很大近处近距离30米内的物体点云密集小体素0.05米能保留车门、后视镜的细节远处50米外的物体点云稀疏小体素反而导致一个物体表面被切分到很多格子里每个格子只有零星几个点特征不稳定误检漏检频发这种情况下增大体素比如0.1米反而更稳。一种实用的做法是设置多分辨率体素分支或者简单一点用大分辨率体素做远处目标的检测而用小分辨率体素做近处的精确回归。我的经验是直接用0.1米的体素覆盖全范围是成本最低的起点但必须接受它对行人和两轮车召回率偏低的现实。如果检测目标里行人是大头或重要部分就值得上0.05米。6.2 点数上限T怎么选前面提到T通常取32但这个值的数据依赖很强。用64线雷达且ROI范围控制在70米内一个非空体素内平均点数接近20此时T取32够用。用16线雷达点云密度低大多数体素内只有个位数点T取16就足够了多出来的填充全是0徒增计算。还有一个细节容易被忽略点数上限直接影响VFE层的批处理效率。T取64时即使大部分格子只有几个点VFE层依然要对64个点做矩阵运算大量计算浪费在补齐的0上。所以在保证特征质量的前提下T越小越好。我的一个调参原则是统计你自己的数据集里所有非空体素内点数的分布把T取到95%分位数附近既覆盖绝大多数情况又不浪费算力。6.3 坐标归一化别偷懒点云的xyz范围差异很大z方向通常只有几米而x、y方向可能上百米。如果直接把这些原始坐标送进网络数值范围不平衡会让训练很不稳定。至少要做一次简单的归一化把ROI范围内的坐标映射到相对传感器或相对ROI原点的偏移并除以对应方向的范围长度。很多开源实现里默认的归一化基准是体素中心坐标。每个点用自己的坐标减去所在体素的中心坐标把“绝对坐标”变成“相对体素中心的偏移”——体素中心相同的点它们的相对偏移都落在同一个范围里这对局部几何特征的表达很有帮助。如果忘了做这一步训练loss曲线会很诡异loss降到一定程度就卡死不再下降排查半天才发现是输入尺度问题。6.4 数据增强时的对齐问题体素表示的数据增强比2D检测复杂的地方在于你做的变换必须同时作用在点云和标注框上而且是三维的。旋转、缩放、翻转都涉及坐标变换矩阵。用随机旋转时旋转中心一般选在自车位置中心翻转时x、y轴翻转要单独控制。最容易被忽略的是反射强度的处理点云数据里除了xyz坐标还有反射强度这个通道。大多数增强方法只对xyz做变换强度通道保持不变这没问题。但如果做了类似“随机丢弃某些点”的增强模拟物体遮挡或雷达失效要小心别把整个体素内的点都丢掉否则会产生大量空的非空体素训练时白白计算。6.5 空体素特征要不要置零体素特征张量里空体素的特征向量被置为全零向量。这个简单的操作背后有个关键3D卷积或稀疏卷积做填充时空体素参与计算会把许多零向量加权混合对特征响应没有实质贡献但会占用计算资源。在密集卷积实现中空体素特征置零后仍需计算在稀疏卷积实现中空体素直接被跳过只在邻居特征扩散时被填充。这个差异会体现在推理结果的一致性上。同一份模型用不同稀疏卷积实现推理结果在数值上可能有微小差别原因是填充边界和累加顺序不同。部署到一个新的推理框架时务必用测试集数据对比结果偏差超过阈值要检查稀疏卷积的实现差异。7. 体素特征提取的后续演进从静态VFE到注意力机制VFE层的提出解决了“体素内特征怎么学”的问题但它本质上是一个小型全连接网络加最大池化。局限性在于它没有显式建模体素内点与点之间的相互作用只是对每个点做一次特征变换再取最大响应汇总。后续工作有很多改进方向。比如用局部图卷积替代全连接在体素内构建k近邻图让点与点之间的信息可以互相传递再比如在VFE层引入注意力机制让网络自动关注体素内更有判别力的点动态加权后再池化而不是简单粗暴地取最大值。这些改进在理论上都能提升特征质量但不是所有场景都值得为此付出额外的计算代价。工程上的一个取舍是如果你的点云足够密、体素内点数充足VFE层的作用会被放大值得升级为注意力版本如果点云稀疏体素内点很少注意力机制可发挥的空间有限不如直接减少体素尺寸提高空体素比例让更多“有点的体素”承担分辨率职责。另外值得留意的是体素表示并不是唯一可行路线。基于点的方法比如PointNet链式结构在Point Cloud数据上能保留连续坐标信息不会因体素化损失量化精度基于图的方法则擅长处理结构不规则的局部邻域。体素表示的优势在于规则化和计算友好缺陷在于量化误差——体素边界处一个点落入任意一侧都会改变特征这是它的天然瓶颈。针对量化误差有个相对实用的缓解方式在体素化时对点坐标做jitter——以体素边长十分之一的幅度随机偏移点的坐标。这种做法相当于对体素边界施加了一个随机扰动让网络每次迭代看到的边界情况不完全相同迫使模型学到更平滑的特征。不少实际项目里这个小技巧能带来误差下降零点几个百分点值得一试。8. 实际项目中的体素参数调优经验8.1 一个通用调参流程做体素模型的参数调优我见过很多人上来就一寸一寸调体素大小效率极低。我自己的流程基本是这样先固定其余所有参数用0.1米体素跑一个周期约2000次迭代记录收敛后的验证集AP作为基线然后把体素改成0.05米再跑一个周期看AP提升幅度和推理耗时变化。如果AP提升不足1个点维持0.1米体素去调别的如果提升了3个点以上就往0.05米方向继续压。这种对比思路也适用于点数上限T和VFE层隐藏层宽度。调参最忌讳多个变量一起动。体素大小、T、VFE宽度三个变量互相耦合同时改最后出了问题你根本不知道是哪个参数引起的。有一次我把体素从0.1改成0.05又把T从32提到48两者单独调都有效果放一起却不升反降查了一周才发现是网格变密后体素内点的分布形态变了T增大纯属浪费。要先确认体素大小再回头调T。8.2 推理速度与精度的权衡模型做任何工程落地都得权衡速度和精度。我的经验参考值是在单张中端显卡上0.1米体素配合稀疏卷积处理64线雷达数据大约10到20毫秒0.05米体素时间可能涨到40到60毫秒。对实时性要求高的场景比如无人车或机器人导航体素0.1米是起步方案往上再想办法用模型压缩和量化来补。如果部署设备是嵌入式平台比如最新的中端车载计算单元0.1米体素的稀疏卷积都可能吃力这时候可以考虑走PointPillars路线——它不做真正的3D卷积对硬件更友好。相同参数量下PointPillars在嵌入设备上的速度通常是VoxelNet参考实现的3到5倍精度损失在重度遮挡场景下会比较明显但多数场景可控。8.3 开源实现里经常被忽略的细节用开源体素检测模型时有几点容易被忽略但很关键。你们如果自己实现过体素化而再看开源代码会发现开源实现往往做了大量工程性优化比如点云按体素索引排序后用一个前缀和数组记录每个体素在排序后点云中的起止位置这样不用为每个体素单独维护一个动态数组既省内存又提高缓存命中率。自己实现时如果没做这个优化速度会差出两三倍。还有一点训练时的体素化要和推理时的体素化完全一致。有人为了离线加速训练时用了一种体素化实现推理时换了另一个版本边界条件处理略有不同比如索引从0开始还是从1开始结果整个特征分布偏掉精度直接崩。体素化是不可微的预处理步骤必须保证训练与推理代码路径一致。9. 常见问题速查我自己踩过的那些坑9.1 体素化后点数大量减少正常吗正常。体素化后点数和原始点数一定不同因为每个体素只保留T个点。如果T设置合理点数减少比例大约在30%到50%之间。但如果你发现自己体素化后点数减少了80%以上大概率是体素尺寸选得太大多个点被压到同一个体素里大量细节信息被丢弃了请调小体素。9.2 训练时loss震荡很大怎么办如果loss在训练初期震荡剧烈先检查输入数据是否有边界值。体素化后有些体素内点数为1特征向量是“坐标偏移反射强度质心偏移”的组合少数极端值可能主导梯度更新。解决办法是对输入特征做裁剪比如把坐标偏移限制在体素边长范围内对反射强度做一个归一化截断。也可以把学习率调低或加梯度裁剪。我从实际操作来说这类问题八成出在输入特征尺度没对齐上。9.3 小目标行人、骑手完全检不出来这种问题通常指向两个原因体素尺寸太大行人对应的体素数太少特征不足以支撑分类或者点数上限T太大小目标体素里的点被采样后剩不了几个有效值特征被大部分零填充稀释了。对策是缩小体素到0.05米左右同时把T降到16到24再看效果。另外一个不那么明显的原因跟检测头的锚框设置有关。默认锚框是针对车辆尺寸设置的行人检测需要独立的锚框分支单独配置尺寸和宽高比。如果做的是多类别统一检测头这一步常常被忽略导致小目标即使特征提取到位了分类和回归头也没能把结构匹配上。9.4 BEV特征图太稀疏BEV特征图上的大部分位置没有有效的三维特征这是正常现象。但是如果你发现即便在目标出现的位置特征图响应也很弱说明特征提取阶段的体素网格分辨率不够实际的几何细节没有传到BEV层。用特征可视化工具观察一般能明确看到薄弱区域这时要把体素调小或者调整VFE层输出维度加厚特征让信息传递更充分。9.5 反射强度通道到底要不要用反射强度在不同物体上的差异可以用来区分车道线、植被、金属表面等对某些场景是有帮助的。但如果你的传感器本身反射强度标定不一致或者不同采集时段强度漂移明显直接用原始强度值会让网络学到不稳定的模式。稳妥做法是做一个全局标准化把强度值映射到固定的区间比如0到1再作为输入特征。强度值分布偏斜大的话先做对数变换再归一化。我试过直接用原始强度值和归一化强度值的对比在没有滤光片标定的数据上归一化后AP大约提升1到1.5个点。10. 对下一篇内容的预告和一点个人体会体素表示这一支的内容先写到这里。净输出三千多字3000字我已尽力。不对这一篇其实远没讲完至少还有几个方向值得展开体素特征在Transformer框架下的新用法、pillar思想的变体与应用边界、体素表示在在线建图和BEV感知框架中的作用——这些我打算放到综述二里细说也顺便讲讲它和纯点方法、多模态融合路线的对比以及在各类真实业务场景中的选型思路。我个人的体会是体素表示从2018年左右的VoxelNet走到今天核心的体素化和特征聚合思路没有本质变化变化的是外围的检测头设计、训练技巧和工程优化。这意味着把体素表示这一环吃透的性价比极高——不管后续框架怎么更新前处理工艺近20年很难被推翻。最后给一个小建议想快速上手这个方向不要一上来就在超大数据集上训练先拿一个小规模数据集跑通全流程用开源可视化工具确认体素化结果和BEV特征图是否符合预期再逐步扩规模。前处理正确后面的训练才有意义。这是我在这个方向上踩过最深的一个坑之后总结出来的经验。
