如果你已经做过一段时间的激光雷达感知大概率看过不少点云检测的教程。前四章我们聊了传感器原理、点云预处理、传统聚类分割还有经典的PointNet系列——从点的无序性讲到特征聚合再到如何用MLP一步步逼近三维空间里的几何结构。那些内容解决的是“让模型看懂单帧点云”的问题。但真正上车之后你会发现单帧点云做得再漂亮也不够用。原因有两个一是场景太复杂稀疏、遮挡、远距离小目标单帧信息根本不够二是车规级要求极高你不能只在离线评测里刷几个漂亮数字得考虑算力、延迟、鲁棒性还有和多模态传感器的配合。第5章和第6章正是冲着这两个问题去的。第5章讲数据驱动的检测分割新范式从体素化到稀疏卷积再到CenterPoint这类基于中心点的方案核心解决“怎么从海量点云里又快又准地找到目标”。第6章讲多传感器融合与部署优化核心解决“怎么把激光雷达和其他传感器捏在一起还得让它跑得动、跑得稳”。这两章合在一起才是真正能落地到智能驾驶项目里的完整感知闭环。这篇内容我会把两章的核心脉络拆开讲配合我在几个模拟项目里的实操经验把一些常规文档里不会提到的细节补上。不管你是在搞算法预研还是准备上车部署应该都能从中找到点参考价值。1. 第5章核心思路从体素化到特征提炼的感知主线第5章的技术选型逻辑本质上是在回答一个问题点云是无序、稀疏、密度不均的怎么让卷积神经网络这套为规则网格设计的方法也能优雅地处理它答案有两个流派一个是PointNet系列那种直接吃原始点的方法另一个就是第5章重点展开的体素化流派。体素化流派的思想其实很朴素——既然点云不规则那就把它规则化。你把三维空间切成一个个小方块每个方块里统计点的分布、强度、数量这样点云就变成了一个规则的、稠密的、可以直接喂给3D卷积的结构化数据。但这里有个很现实的矛盾如果你把三维空间切得非常细体素数量会爆炸。假设检测范围是前后各75米、左右各75米、高度4米如果切成0.1米见方的体素那光是要维护的体素网格就达到上亿个。直接对全量体素做3D卷积显存当场就要爆。所以第5章里反复强调的稀疏卷积才是真正的杀招。它只对“有物体的体素”做卷积计算空体素直接跳过计算量能砍掉一个数量级还多。我第一次在模拟数据集上跑稀疏卷积推理时对比稠密3D卷积的耗时感受极其深刻——同样的骨干网络推理速度能快接近十倍。第5章的另一个重点是特征提炼的走向。早期的体素方法比如某些早期方案通过3D卷积从体素里提炼特征之后直接拉平做检测头。这种方式在稀疏场景下对远处小目标很不友好因为体素化本身就有信息丢失。到了后来大家更愿意用2D鸟瞰图视角来做特征图输出把高度维压缩掉只保留水平平面的空间结构再配合一个专门设计的检测头。这种设计非常有智慧因为自动驾驶场景里物体不会上下乱飞地面基本是平的鸟瞰图最能保留目标之间的距离和大小关系而且2D卷积比3D卷积省太多计算量。我个人强烈建议把第5章理解成一条完整的主线点云清洗 → 体素化 → 稀疏卷积提炼 → 鸟瞰图特征 → 检测头输出。每一个环节的取舍都会直接影响最终精度。比如体素大小的选择我做过对比实验体素尺寸从0.05米改成0.1米模型推理速度能提升约40%但小目标的召回率会掉两三个点。可别小看这两三个点在真实路口场景里可能就是能不能检测到远处行人的区别。1.1 第5章检测头的演进从Anchor到Center的转变检测头这块是第5章里我认为最值得琢磨的部分因为它代表了激光雷达算法设计思路的一次重要转向。早期方案大量采用基于锚框的方法——先在鸟瞰图特征图上预设大量不同尺寸、不同朝向的锚框然后让网络去预测每个锚框和真实目标的偏差。这个思路从图像检测迁移过来对点云场景来说有一个先天不足锚框的超参数太多。长宽高、朝向、中心偏移、还有正负样本的划分阈值每一个都要反复调参。点云场景里目标尺寸差异非常大自行车和卡车的大小能差十几倍锚框设计得再好总有边缘情况照顾不到。CenterPoint的出现算是把这个问题解决得比较干净。它的思路是我干脆不预设锚框了直接预测每个目标中心的概率热力图然后再回归中心点的偏移、尺寸、朝向。结构上更简洁稀疏场景里也不容易因为锚框设计不合适而漏检。我在实际项目里把检测头从基于锚框的方式换成CenterPoint之后最关键的变化是省心——不用再去纠结锚框的尺寸聚类和正负样本比例。模型的整体召回率提升了大概一个多点而且对罕见尺寸目标的泛化能力明显变好。CenterPoint还有一个衍生优势就是它天然适合做两阶段精调。第一阶段先预测中心点热力图和粗略的包围盒第二阶段对每个检测到的中心点做二次特征提取精调包围盒。这种两阶段设计在延时允许的场景里特别管用精度提升非常可观。我见过不少工程团队把CenterPoint作为基架再把第二阶段替换成更精细的ROI特征网络在自家数据集上都能涨点。关于CenterPoint有件事得提醒一下热力图生成和标签分配是很容易翻车的环节。你要用一个高斯核把真实的中心点“抹”到热力图上去但高斯的半径如果不匹配目标的实际尺寸小目标可能根本学不到有效的峰值响应。我建议你在预处理里根据目标占地尺寸动态调整高斯半径而不是用一个固定值。这个细节我踩过一次坑后来比对了几个半径设置确认动态版本最稳。1.2 从单帧到时序第5章里的帧间融合技巧第5章还用了一个非常关键的技巧就是帧间点云融合来弥补单帧密度的不足。这点新手容易忽略却是我认为效果最显著、成本最低的提点手段。原理一句话就能讲清楚当前帧的点云加上之前几帧的历史点云放在同一个坐标系下去检测。有了时间维度的补充远处本来看不清的目标因为多个角度扫描的叠加点就变密了检测自然更稳。帧间融合最重要的不是深度学习而是标定的精确性和运动补偿。车在往前开之前的帧不能原地不动地叠加你得根据每帧之间的车辆运动把历史点云变换到当前帧的车体坐标系下。这个变换用到的就是组合惯导输出的车辆位姿变换矩阵算准了叠加才有效。如果不做运动补偿直接叠加你会看到两侧的静态物体出现“拖影”模型很容易就被这些假特征带偏。我建议在帧间融合时保留一个时间衰减权重或者距离阈值把过于久远、过于稀疏的旧点滤掉。因为我试过把十帧历史点云全部叠加进来效果反而变差——多帧叠加带来的动态物体残影会把网络搞糊涂。大概保留三到五帧每帧按时间做权重衰减效果是最平衡的。在雨雪天气或隧道场景里这个技巧的收益会让你意外实测中小目标召回率能提升四个点左右。第5章最后还会介绍如何用模型的输出做后处理和置信度校准。激光雷达模型输出的置信度往往不是准确的概率你不能直接用0.5作为阈值。我的习惯是拉一段真实路测数据的分布找precision和recall曲线最平衡的阈值点来用。这看起来是个小事但在恶劣天气下特别管用因为雨雾天模型普遍会变得过度自信校准之后阈值上移就能滤掉一批假阳。2. 第6章核心思路多传感器融合与部署优化如果说第5章解决的是“单模态把感知做极致”那第6章就务实得多它直接面对一个灵魂拷问激光雷达再强单靠它你敢让车全程自动驾驶吗说实话不敢。雨雾天激光点云衰减严重灰尘遮挡、传感器本身的盲区都会让激光雷达单独工作变得不可靠。所以量产方案几乎无一例外走的是多传感器融合路线把激光雷达、摄像头、毫米波雷达放在一个统一的感知框架里。第6章的第一个重点就是讲清楚融合到底有哪些层次。低层融合数据级、中间层融合特征级、高层融合目标级三种方案各有各的取舍。数据级融合对时间和空间标定要求极高一旦标定有偏差整个输入就废了目标级融合实现简单但信息损失太大容易出现感知结果互相矛盾的情况。目前主流量产方案更倾向特征级融合就是让激光雷达和图像在特征层面做对齐与叠加兼顾信息量和鲁棒性。这和很多人的直觉不一样。你可能会觉得目标级融合不是最稳定吗各感知各的最后用逻辑规则融合一下多清晰。但如果激光雷达漏检了一个目标而摄像头检到了目标级融合还能救回来如果两者都漏检呢那就彻底没了。特征级融合的好处在于图像和激光雷达的特征在较早阶段就互相补充网络能够学到“哪里该信谁”的权重哪怕单模态有瑕疵融合后仍然能输出稳定的结果。第6章对特征级融合的展开很有层次从图像特征和点云特征的坐标变换讲到ROI区域的特征提纯再到时序上的特征记忆融合。里面最难的不是网络结构本身而是如何保证两个模态在物理意义上对齐。相机和激光雷达的联合标定要做好内参外参哪里差一丁点特征对齐就会出现系统性的偏移这种偏移在网络里很难自行纠正。我遇到过转向角标定偏差0.2度的情况远距离目标的特征错位能偏大几十厘米直接就压到了标注边界上。部署优化是第6章的另一根顶梁柱。一个模型论文里刷点再好看如果车规级芯片上跑不动那就只是一堆权重文件。部署优化要解决的问题很明确怎么把计算量压在规定预算内同时把精度损失控制在可接受范围内。其中最关键的就是量化。从FP32降到FP16几乎无损从FP16进一步缩到INT8精度的损失就开始显现了。我在一个项目里对比过同一个检测模型在FP16和INT8下的精度和延时INT8方案能省一半以上的推理时间但目标置信度普遍会降零点几需要重校准阈值。具体取舍是横穿行人这类高危场景必须做到同时支持多路传感器信号和并行检测线程所以在关键子模型上我会保留FP16精度而那些耗时大户比如背景语义分割则大胆用INT8加速。算子融合是部署里另一项重要的工程手段。简单说把神经网络的多个层合并成一个算子减少内存搬运的频次。举个例子卷积 BatchNorm ReLU三个操作在训练时是一个个调用但在推理时可以融合成一个大的计算内核因为BN和ReLU本质上都是逐元素的变换。算得少了数据在内存和计算单元之间搬运的次数就少了延时就降下来了。我自己实测过单单做一层算子融合模型的端到端推理时间能减少约20%而且精度完全不受影响。2.1 BEV感知统一多模态特征的最佳载体第6章里关于BEV感知的讲解我觉得尤其值得细说因为它已经成为多传感器融合的主流范式。BEV鸟瞰视角核心思想是把图像特征和激光雷达特征都投影到一个统一的车体俯视平面上去做融合。这样做的好处特别明显不同传感器的特征终于有了一个可对齐的公共空间。你不需要再去操心图像特征和点云特征在几何上怎么互动因为到了BEV视角下所有目标都变成“平面上的占位和类别”融合逻辑就变得自然了。要真正理解BEV感知关键要搞清楚一个叫“视角转换”的模块。相机和激光雷达的坐标系不同图像是透视视图点云是三维空间想把它们统一到BEV平面网络结构里必须有一个可学习的变换模块让网络自己学会从图像特征到俯视图特征的映射。这个变换异常重要因为相机的透视畸变、遮挡关系都需要在变换中处理好否则融合出来的BEV特征会有一堆空洞和错位。在我实现过的一个模拟项目里BEV融合方案显著提升了目标检测的稳定性。纯激光雷达模型在逆光环境下对深色车辆的检测会时有时无但BEV融合后因为图像特征在俯视图上提供了颜色和纹理的补充哪怕激光雷达点云很稀疏目标也能稳定输出。我还在同一个框架里做了多任务扩展检测任务和可行驶区域分割、车道线检测放在一起共享同一个BEV特征在算力开销几乎不再增加的条件下上下游任务都拿到了增益。这种“一个特征平面多个感知任务”的架构长远看是智能驾驶感知收敛的大趋势。实操中需要注意BEV融合的精度天花板很大程度上取决于深度估计和相机标定质量。如果你的图像深度信息不准投影到BEV平面后目标位置就会偏移和激光雷达对不上。这里我建议你为相机-雷达融合单独设置一个标定验证流程每更换一次车辆或传感器布局就采集一帧标定板的联合数据检查特征对齐距离在近端不超过20厘米、远端不超过1米再往下做模型训练。2.2 部署优化的主线从训练到量化校准再到精度回测第6章的后半部分把部署优化的流程写得相当清楚我按这个流程走下来基本能做到“模型能力不缩水地搬上车”。先说整体流程训练好的模型先转成通用中间表示然后用推理引擎做层融合和算子重写再跑一组代表性的校准数据完成INT8量化最后在目标芯片上做精度回测和延时统计。这几个环节是环环相扣的任何一步偷懒都会在最终端到端测试里暴露问题。量化校准选择数据特别重要。你要是随手拿几十帧公开数据集跑一下量化大概率在自家场景上精度崩盘。因为校准数据必须覆盖你真实场景中的传感器噪声、天气变化、目标密度。以后我在量化前都会专门攒一份代表数据集目标密度、大小目标比例、夜间和白天比例尽量拉齐。这样产出来的量化模型才真能用。校准数据的质量问题我用一个词来形容就是“垃圾进、垃圾出”这个环节真的不能省。INT8量化之后还有一个很常见的坑就是某些层对量化特别敏感。比如注意力模块、多层特征融合相加的地方一旦精度损失过大整个检测头就会不稳定。我的排查方法是逐层对比量化前后每层输出的最大绝对误差然后把误差最大的那几层单独保留为FP16精度。这种混合精度策略在推理引擎里实现起来并不复杂却能把关键层的精度损失压回来。我试过在一个baseline模型上做混合量化整体检测mAP比全INT8方案高出1.7个百分点延时只增加8%。精度回测也不能只看mAP一个指标。对智能驾驶来说你要拆成小目标、远距离、雨天、夜间、逆光等多个切片来看。有的模型平均掉点看着很小但切片一拆发现远距离行人的召回掉了20%这种情况就必须回头调量化策略或者改进训练时的数据增强。我项目里最后定了三层回测第一层是全量离线测试集跑平均精度第二层是场景切片精度对比第三层是实车路跑的主观体验和问题记录。三层齐了才敢说这个模型可以上车。2.3 时间同步最容易翻车的工程细节第6章里有个常常被人忽略、却在量产项目中扮演致命角色的角落——多传感器时间同步。你要融合激光雷达、摄像头、毫米波雷达的数据如果它们的采集时间不对齐那融合出来的感知结果就是在“各说各话”。比如车在高速运动时相机画面和激光点云相差80毫秒目标在图像里已经前移了两米而点云还停在原来的位置融合出来的目标位置就必然在前后抖动。解决时间同步的方案有很多最底层的思路是硬件级的脉冲同步让不同传感器在同一硬触发信号下采集这样每一帧数据的时间戳能精确对齐到微秒级。在计算平台支持的条件下这是体验最好的方式彻底避免了软件端对时间戳的无奈补偿。软件级同步则是靠算法去插值或找最近邻帧来匹配时间精度差一些但实现成本低。工程实的策略通常是两种都做硬同步做主软同步兜底。我在项目里遇到过一种很典型的故障雨天场景下摄像头因为自动曝光调整导致实际采集时刻发生偏移和点云时间戳对不上融合结果在弯道处出现目标分离。排查了很久才定位到是因为我没有监控每个传感器的实时时间戳差。后来我在融合模块前面加了一层时间戳监测逻辑一旦偏差超过阈值就丢弃该帧融合结果重新对齐传感器数据。加了这层保护之后弯道场景的目标稳定性直接恢复到了正常水平。3. 实操记录用OpenPCDet和自研后处理做一次完整验证前面讲了这么多思路我想拿我实际做过的一个模拟项目来展示一下整体流程怎么落地。项目背景是某园区低速无人车的激光雷达感知模块改造要求在不升级计算平台的前提下提升行人和小型障碍物的检测稳定性。传感器方案是128线激光雷达加一个前视双目摄像头。我基于OpenPCDet改了一套CenterPoint检测流程然后接了一个自定义的时序融合后处理模块。第一步是数据准备。我从园区连续采集了几天的原始点云和图像数据按时间戳做了离线对齐然后把点云和图像标注统一到车体坐标系下。这个对齐过程一定要逐帧检查不能只看几帧就盲目信任标定。我截图抽查了近端和远端的对齐效果近端偏差控制在5厘米内才放心拿去做训练。第二步是模型训练。我用的主干网络是稀疏卷积结构检测头是CenterPoint的变体。训练参数上我按一个经验比例来设置初始学习率2e-3batch size设成16训练60轮后开始做余弦退火。整个训练在单卡A100上大约跑了9个小时。关键的是我加了一个数据增强策略物体级别的点云随机翻转、旋转、缩放再加上全局的帧间拼接效果提升比较明显。增强之后的模型在本地验证集上小目标AP从我最早跑出来的46.5涨到了52.1涨幅相当可观。第三步是把模型从离线流程搬到推理引擎上。这一步会触及部署优化的核心。我把整个CenterPoint模型导出成通用中间表示然后做算子融合和INT8量化。校准数据我特意选了白天和夜间各半的数据集目标类别覆盖行、自行车、小汽车、卡车。量化后跑了一遍切片精度对比发现夜间远处的行人掉点较多就单独把那部分层改成FP16混合精度成功率立竿见影夜间行人AP从量化后掉3.2个点回收到了只掉0.4个点。第四步是时序融合后处理。我用的是一个滑动窗口策略把最近五帧的检测结果按车辆位姿变换到当前帧坐标再用匈牙利匹配做关联对同一轨迹的检测结果做置信度加权融合。这个后处理直接砍掉了很多单帧的抖动检测连续帧之间目标位移平滑了很多。最终在园区实测路测里小目标漏检率比改造前下降了约30%置信度输出也变得稳定了许多。这个流程跑完之后我最大的感受是算法设计和工程部署必须从一开始就并行考虑而不是等模型训好了再做部署适配。你在选网络结构时就要估算它在目标芯片上的感受野、耗时、算子支持度。比如有些新的注意力模块在GPU上效果很好但换到车规级芯片上可能根本不支持就得重写算子。你要做的不是找一个理论最优模型而是在精度、速度、可部署性之间找一个真正适合你实际场景的平衡点。3.1 模型导出与算子兼容性容易卡住的细节模型导出阶段最容易卡住的坑是自定义算子在推理引擎里的兼容性。很多激光雷达模型里都会写一些自定义的算子比如体素化、稀疏卷积、特定形式的NMS。这些算子在训练框架里能跑但直接转到推理引擎很可能根本没实现你只能一边查算子缺失列表一边改写模型结构。我见过不止一个团队在这里卡了两三周最后只能重写网络层来绕开不兼容的算子。解决办法有两个方向。第一个方向是尽量使用推理引擎官方算子库里的操作比如把自定义的卷积变体换成原生的稀疏卷积或分组卷积。虽然网络性能可能有细微下降但换来的是部署流程的顺畅。第二个方向是自己在推理引擎里注册自定义算子这个工作量看算子复杂度有些简单的逐点算子半天就能搞定但如果涉及复杂的数据排布和并行优化顺利的话也要一周以上。我的原则是算法选型阶段就打开推理引擎的算子支持列表对着它去设计网络结构而不是等模型训完才想起来查兼容性。做智能驾驶落地最重要的不是炫技是把已知的、经得起考验的算法稳定地放到产品里去跑。这个观念在实际项目中能帮你省下大量的返工时间。3.2 后处理逻辑与工程调优后处理逻辑在工程项目里常常被低估但它对最终体验的影响极其深远。在激光雷达感知里后处理主要包含NMS和时序逻辑。NMS本身有好多版本贪心NMS、SoftNMS、IoU替换策略。对于点云检测目标之间一般不会像图像里那样成片重叠但同一目标的多帧高置信度输出却很常见如果不加时序抑制就会出现同一个障碍物被连续输出好几次的情况。我在这个项目里用了一个比较实用的处理流程先对单帧检测结果做Score阈值过滤再做类别内NMS最后做跨帧轨迹关联。跨帧关联用的是IoU加中心点距离的加权相似度匹配法用贪心加全局最优混合保证大多数帧里目标轨迹稳定。配合上前面说的置信度加权融合最终输出的目标数量其实比单帧检测结果要少一些但每一个都更可靠。这种“宁缺毋滥”的取舍对智能驾驶很重要因为下游的规划控制模块经不起层出不穷的虚假目标惊吓。后处理参数的调节也需要一套系统的方法不能全凭肉眼。我会在连续几百帧路测数据上做离线重放调NMS阈值、置信度阈值、轨迹生命周期等参数然后看输出轨迹的稳定性和跳变情况。这比上车看效果高效得多因为同一个场景可以反复调参回放而不是在车上跑一趟就结束了。我建议所有做感知算法的团队都搭一套这样的离线重放工具它对工程效率的提升不是一点半点。4. 常见问题与排查技巧实录我把这两年多雷在激光雷达感知项目里最常见的问题整理了一下做成一个速查表相信很多做同类工作的人都能在里面找到自己踩过的坑。这些问题大多不是高深的算法问题而是工程实践里反复出现、又极容易被忽视的细节。点云和图像的标定偏差症状是融合目标在远距离出现错位或分离。排查方向是重新做联合标定重点检查时间戳对齐和相机外参是否在行驶振动后漂移。我见过一个案例车辆过减速带后相机支架轻微位移标定就废了最后重新紧了一遍螺丝再标定才恢复正常。量化后模型精度崩掉症状是INT8量化模型在真实场景猛然掉点。先检查校准数据是否覆盖多样化场景再看敏感层是否被强制量化。把关键层单独提成FP16混合精度通常能救回来。稀疏点云下小目标漏检症状是20米外的行人或锥桶经常丢帧。除了加大帧间融合和增强数据还可以检查体素尺寸设置适当缩小体素化粒度能直接提升小目标召回但会牺牲速度要反复权衡。时序融合拖尾症状是运动目标后方出现不存在的尾迹。原因是历史帧权重过大或运动补偿不准确。试试缩短历史帧窗口以及在变换前对动态目标做单独处理。实车推理延迟波动症状是平时推理速度正常偶尔出现极端卡顿。先排查是否为散热降频然后检查是否存在未融合的算子导致CPU和NPU频繁交替。对模型结构做一次算子分布统计往往能看出瓶颈在哪。排查这类问题我有一个笨但有效的习惯把每一步的中间输出都存下来做成离线可视化。模型训练好之后先跑一遍推理把体素特征、鸟瞰图特征、检测头输出、后处理结果全画出来逐层看。很多时候你盯着数字看半天看不出问题可把特征图渲染出来一眼就能发现哪里的激活值怪异、哪里的特征出现空洞。这种做法比单纯看日志直观得多也更容易让团队里的其他成员快速理解问题所在。还有个很有用的技巧是给模型做一个“消融开关”工具。你要能一键关闭帧间融合、一键关闭图像融合、一键关闭时序后处理这样当你遇到效果异常时可以快速定位是哪个模块惹的祸。我在项目里花了一天时间做了这个开关工具之后所有的问题排查速度都上了一个台阶。很多人喜欢直接在大模型上debug我却觉得不如先做减法把可疑模块一个个关掉剩下的自然就是问题所在。5. 对后续章节的延伸思考看到第5章和第6章的内容聪明的读者应该已经能感觉到激光雷达感知这条线还有好几个方向可以继续深入。比如无监督或自监督的预训练方法让模型从海量未标注点云里学通用特征再微调到下游任务。现在的感知模型对标注数据非常依赖采集几万帧数据容易但给几万帧做高质量3D标注那可是真金白银的投入。另外就是4D场景理解。前几章主要处理单帧或者短时序拼接但真正要做出色的行为预测和规划模型得理解整个动态场景的演变过程。比如路口处一辆车是不是在减速让你这种判断需要跨更长的时间窗口去观察和学习。激光雷达在长时序连续观测下的巨大数据量给了这个方向很好的燃料。还有一个我在实际项目中越来越看重的方向就是感知模型和规划控制模块的联合优化。现在普遍的做法依然是感知出目标规划再去避让两者之间有墙。但有些危险场景比如突然闯入的横穿目标如果感知能和规划做更紧密的联动反应速度和安全冗余都会提升。这个方向短期看有难度长期看一定会成为智能驾驶技术栈进化的重点。就我个人这么多项目下来的体会做智能驾驶激光雷达算法真正的难点从来不是复现某个论文里的网络结构而是在一个受限的算力平台和繁杂的工程约束下依然能让感知系统稳定、可靠、不惹事。第5章的算法思路给了你精度上限第6章的部署优化给了你工程下限而在这两者之间填满的全是耐心调试和细节把握的功夫。最后再分享一个小技巧哪怕你的任务不需要实时跑也要在开发早期就按实时性约束去设计模型和预处理流程。因为很多在无约束条件下能用的操作一上嵌入式平台就变成不可接受的瓶颈到时候再回头重构代价会翻好几倍。拿激光雷达感知来说点云预处理那些频繁用到的地面分割和降采样如果早期直接写成一个能用但效率低下的版本后面再优化一次涉及的改动面非常大。从一开始就奔着高效实现去写后面部署会轻松非常多。
阅读完成 · 觉得有帮助?