1. 感知模块的整体设计与定位1.1 为什么先说定位再说算法我先提一个可能和你直觉相反的观点感知模块在Apollo无人驾驶系统里技术含量最高的未必是某个深度学习模型的精度而是它与其他模块之间那条清晰、稳定、可维护的数据链路。我最初自学时把大部分精力花在调参和换网络上后来对照Apollo课程进阶篇才发现感知模块的定位是个“承上启下”的中间层上游是传感器激光雷达、摄像头、毫米波雷达它们的输出格式完全不同一个是一堆离散的3D点一个是带色彩的二维像素矩阵另一个是目标的距离/速度测量结果。下游是预测、规划、控制这些模块根本不关心你用了什么网络、几个头、多少层。它们只关心一个东西——你输出的障碍物列表是否干净、稳定、低延迟。课程进阶篇里反复强调了一个概念叫“冗余与协同”。不是说传感器越多越好而是说每个传感器在感知链路里的分工不同最终再由融合模块来统一仲裁。这套思路是Apollo感知框架的核心骨骼我建议你在读任何一篇关于Apollo感知的博客之前先把这条链路刻在脑子里感知上游数据输入 → 预处理与标定 → 单传感器感知 → 多传感器融合 → 输出障碍物/车道线/红绿灯状态 → 交给预测和规划如果不先建立这个全局视角你走马观花看完课程大概率只会记下一堆网络名和精度数字过两周全忘光。这是我踩过的第一个坑先说给你。1.2 这个进阶篇笔记能帮你解决什么问题网上关于Apollo感知的公开资料不少但多数集中在“跑起来”的阶段比如怎么装环境、怎么启动DreamView、怎么看点云效果。而进阶篇的核心价值是把“能跑”和“能干活”之间的差距补齐。至少有三个问题是我见过身边不少同行在脱离教程、自己上手时卡壳的地方第一传感器数据不是对齐的。激光雷达和摄像头各有各的时钟哪怕都是10Hz一张图像和前一帧点云之间也存在毫秒级的时间差。这个差值在车辆高速运动时直接导致融合错位。课程里提到的做法是引入时间同步模块而不是简单在代码里拼接数据。这个细节很多人不知道。第二单传感器感知都有硬伤。摄像头在强光、逆光、夜间就退化激光雷达在大雨、雾霾天返回的点云质量明显下降毫米波雷达对静止目标的行人几乎无感。进阶篇强调的不是“哪个传感器更准”而是怎么通过融合策略用A传感器的优势去补B传感器的盲区。第三感知输出的不是“结果”而是“任务请求”。感知模块最终要把连续帧的障碍物ID关联起来做“目标跟踪”和“轨迹预测前置处理”否则下一帧目标换了ID规划模块会以为出现了一个新障碍物而紧急刹车体验非常糟糕。所以如果你是想做自动驾驶系统研发、感知算法落地或者单纯想把Apollo这套整个感知架构从原理到代码都吃透这篇笔记会比较适合你。纯算法研究的朋友也可以看但你需要额外补充深度学习的基础。2. 传感器选型与底层数据——感知的“食材”从哪来2.1 激光雷达它不是“摄像头的高级版”很多初学者第一次看激光雷达点云时觉得这东西就是一个“三维摄像头”。这个类比很误导人。激光雷达的本质是测距设备。它通过发射激光束测量光束从发出到被物体反射回来的时间差TOFTime of Flight换算成距离。一束激光只有一个距离值但以不同角度扫描就能形成一圈一圈的点。叠加多个扫描线比如64线、128线就成了三维点云。从感知算法角度看激光雷达数据有几个鲜明的特点点云是稀疏的。距离越远点越稀。一个行人在20米外可能只有不到10个点没法直接用像素那种密集特征。点云没有颜色和纹理。它只有坐标(x,y,z)和反射强度(intensity)。红绿灯是红的还是绿的激光雷达看不出来。点云对光线不敏感。夜里、逆光、进出隧道点云质量基本不受影响。反射强度能提供额外信息。比如车道线上的反光强度通常与柏油路面不同这是做车道线检测的辅助线索。Apollo课程进阶篇在讲激光雷达感知时反复用到一个词叫“多尺度特征”。原因是远、中、近距离的目标在点云里的稀疏程度差异很大。同一个行人30米外可能是一小簇点3米外则是一堆密集的轮廓。你不能只用一种尺度的特征去覆盖这两种极端情况。实操里我建议你把点云按距离分段来观察一次——近距离段、中距离段、远距离段各截一个场景看同一个目标在三个距离下长什么样。这一步花不了十分钟但对理解后面所有3D检测算法都有帮助。2.2 摄像头感知任务的“信息最丰富、但也最脆弱”的输入摄像头是唯一能提供颜色、纹理、文字信息的传感器。红绿灯的颜色、路牌的箭头、车道线的走向全靠它。但摄像头的致命弱点也很直接它是被动传感器依赖环境光线。白天强太阳光直射镜头、夜晚对向车灯眩光、隧道内明暗突变这些都会让图像质量断崖式下降。在Apollo进阶篇的传感器章节里我还注意到了一个容易被忽略的细节曝光与白平衡的自动调节对感知任务的影响比想象中大。同一段路上午10点和下午4点的光照色温完全不同。如果摄像头自动曝光跟不上车速图像会拖影motion blur。课程里提到的处理方案是在硬件层面锁定曝光时间配合光传感器做粗调而不是完全依赖ISP的自动曝光。图像数据的存储也有讲究通常使用sensor_msgs/Image格式但Apollo内部做了共享内存传输优化避免在高速场景下因为频繁copy图像数据带来CPU峰值。这一点如果只是在仿真环境里看数据是体会不到的。对于做感知算法的人来说摄像头数据最需要考虑的是“数据多样性”。同一辆车在不同城市、不同季节、不同天气下的外观差异巨大模型稍微过拟合一点换一个城市就失效。Apollo的感知模型训练有一套庞大的数据采集和标注流程课程里没有全部展开但反复强调了一个原则感知模型要覆盖“场景分布”而不是只追求“单场景精度”。2.3 毫米波雷达被忽视的稳定型选手激光雷达和摄像头占据了大部分讨论热度但毫米波雷达在Apollo的感知架构里同样占有一席之地。它的原理是利用毫米级波长的电磁波探测目标直接输出目标级数据距离、速度、角度。相比激光雷达和摄像头毫米波雷达有两个独有优势全天候工作。雨、雪、雾、烟尘对毫米波的影响远小于对激光和可见光的影响。直接测速。雷达可以根据多普勒效应直接测得目标的径向速度。激光雷达和摄像头都没法这么直接。但它的缺点也很明确角分辨率低横向位置精度差对静止目标的检测能力弱。如果你试图用毫米波雷达点云去做精细的目标轮廓分割基本是徒劳。所以Apollo课程进阶篇对毫米波雷达的定位是“辅助角色”。它不负责识别目标种类但负责为融合模块提供速度信息以及对视觉/激光数据进行交叉验证。比如摄像头漏检了一个目标雷达在低置信度下先报了目标存在融合模块就有机会维持这个目标的跟踪ID防止断检。我用一个不太严谨但很生动的比喻激光雷达是主力侦察兵摄像头是情报分析员毫米波雷达是那个一直放哨的哨兵。哨兵不一定能告诉你来的是谁但能告诉你“有东西在靠近”。2.4 三种传感器其实都在“说谎”这是进阶篇里给我启发最深的一句话每一种传感器都在某个条件下“说谎”。激光雷达在雨天把雨滴当成障碍物产生大量“鬼点”。摄像头在逆光时出现大量高光过曝区域等于局部盲区。毫米波雷达在金属井盖、隧道内壁处产生多径反射导致虚警。如果只信单一传感器出了误检你都不知道是哪个环节的问题。所以整个感知模块的终极任务不是把单个传感器的性能推到极限而是让它们互相检验、互相纠错。我在实际调试中多次被“鬼点”折磨过。一个雨夜场景里融合输出了一串高速移动的“假目标”预测模块直接触发了急刹车逻辑。后来定位原因就是激光雷达在雨滴上的反射点被当作障碍物聚类而又恰好匹配上了毫米波雷达在隧道口的多径虚警两个错误“互相佐证”了。所以传感器融合不只融合信号还要在算法层面设计“交叉验证”逻辑。3. 单传感器感知算法——从点云到目标框3.1 基于点云的3D目标检测从手工特征到端到端网络Apollo课程进阶篇讲3D目标检测时脉络非常清晰先从经典的“手工特征聚类”讲起再逐步过渡到深度学习方法。手工特征时代的核心流程是“地面滤除 → 点云聚类 → 目标框拟合”。先说地面滤除这一步至关重要。点云里地面点占据了极大比例如果不滤除一个路面上行驶的车辆与它的下方地面点会被聚类成一个整体目标目标框的高度会被撑到地面高度直接废掉。地面滤除的常见思路是栅格法。在xy平面上划分栅格每个栅格里取z坐标最低的点作为地面种子点再根据相邻栅格的z差值判断哪些栅格属于地面。Apollo的代码库里用的是ray ground filter原理类似但考虑到了激光雷达扫描线的放射状特性效果更好。聚类阶段常用的是基于欧几里得距离的区域生长算法。从任意一个未被访问的点出发把距离不超过阈值的邻近点归入同一个簇反复迭代直到所有点都有归属。这个阈值的选择很有讲究设在0.5米到1米之间比较合理。阈值太大两个并排的骑车人会合成一个目标阈值太小一辆车的车头和车位会被拆成两个目标。聚类完成后每个簇就是一个候选目标。接下来要做的就是用规则或者学习模型去判断这个簇是车、行人、骑行者还是某个静态障碍物。规则方法会统计簇的尺寸、点云密度、反射强度分布等特征与预设的类别模板做匹配。这种方法简单、可解释在低速园区场景里至今仍有使用价值但泛化能力有限。深度学习登场后3D目标检测大致分成两类路线基于点云直接检测point-based这类方法直接处理原始点云比如PointNet系列和PointPillars。PointPillars的特点是把点云划分成柱体pillars在每个pillar内提取特征再把特征映射成伪图像用2D检测网络处理。这个思路既保留了点云的3D信息又享受了2D卷积的高效特性在Apollo早期版本里也出现过采用类似思想的方案。基于BEV鸟瞰图检测BEV就是把点云投影到水平面上形成“从上往下看”的俯视图。车辆目标在BEV里是俯视图的矩形框尺寸比例稳定边界清晰非常适合检测。BEV检测是当前感知领域的主流方向因为它天然统一了激光雷达和其他传感器的坐标系表达。从课程笔记的角度看我认为你至少要掌握PointPillars和BEV检测之间的技术演进关系。它们本质上都在解决同一个问题如何把稀疏、无序的三维点云变成适合卷积网络处理的结构化数据。3.2 基于图像的2D检测与3D信息恢复摄像头的图像感知走的路线跟点云完全不同。2D目标检测已经是非常成熟的领域Faster R-CNN、YOLO、SSD这一类网络大家应该都不陌生。但在自动驾驶里2D检测只是中间产物最终还是要换算到3D空间中去。这里有个核心难点单目图像本身没有深度信息。你可以通过深度学习网络直接回归目标到摄像头的距离但精度有限而且在远距离和遮挡场景下极不稳定。Apollo里的做法是把深度学习检测网络输出的2D目标框和激光雷达点云做“关联”。简单说就是用2D框在图像上画一个区域然后把这个区域内的激光雷达点云投影到图像坐标系再用这些点的距离计算目标的近似深度。这个过程的专业名称叫“Camera-LiDAR Fusion”相机-激光雷达融合的前置步骤。课程里专门花了一部分讲“投影关联”我第一次看的时候完全没意识到里面的坑激光雷达点云和图像是不同坐标系需要通过标定外参转换。点云投影到图像后只落在图像的部分区域不是整幅图都有点。一个2D框内部可能既包含目标车身上的点也包含背景墙上的点需要做深度有效性过滤。实操建议当你用2D检测网络输出目标框时一定要把“框内的稀疏点云深度”和“网络回归的深度”做一个交叉校验。两者相差过大时优先相信点云深度因为它在近距离时更可靠。当然如果目标距离超过80米点云也稀疏得可怜那只能以图像估计为主了。3.3 车道线和红绿灯感知的“另一个阵营”进阶篇的感知部分不只是障碍物检测还覆盖了车道线检测和红绿灯识别。这两个任务和3D目标检测是完全不同的思路。车道线检测的关键是在图像中找“线状结构”。经典的语义分割网络输出“车道线像素掩码”再做聚类和多项式拟合。实际工程里有几个很考验细节的地方车道线不是连续的。虚线车道线有间隙需要跨帧拼接。车道线在远距离会变得模糊通常只拟合近处30~40米的有效范围。路面反光、水渍、新旧标线混杂会产生大量“伪车道线”。我见过一个案例白天强光下路面上的裂缝被当作车道线导致车辆方向盘异常修正。Apollo课程里讲到的方案是“车道线后处理”先提取候选线再用几何约束如线宽、曲率连续性、与车辆当前位置的相对位置做过滤最后做基于历史的平滑。你单独训练一个很强分割模型还不够后处理工程上的打磨占据了至少一半的工作量。红绿灯感知则是一个典型的“小而专”问题。红绿灯本身在图像中占比很小远距离时可能只有十几像素大小。直接在大图上检测效率低、误检率高。Apollo里的方案是先获取地图信息中的红绿灯位置投影到图像上生成“候选区域”再在这些区域里做目标检测和颜色分类。这就是课程里强调的“先验引导感知”的思路——在有地图和定位的条件下不要浪费计算资源在全图搜索。这个思路给我一个启发感知模块不一定要完全依赖传感器本身的能力还可以把高精地图、实时定位的信息引入作为先验把“搜索问题”变成“验证问题”。这也是Apollo这类大系统与单点算法Demo的本质区别。4. 多传感器融合——感知系统的粘合剂与仲裁者4.1 融合的三个层次光做好单传感器感知还不够进阶篇的重头戏是“多传感器融合”。我见过不少初学者只关注检测网络的精度而忽视了融合策略结果做出来的系统在单一数据集上表现不错一上路就各种“抽风”。Apollo里的融合大致分三个层次我建议你按这个递进来理解第一层数据级融合。指在原始数据层面进行融合比如把点云投影到图像形成RGB点云或者把图像特征与点云特征在某个特征层拼接。这一层最大的成本是计算量高且对传感器标定精度要求极高。数据级融合用得不好反而会因为噪声叠加导致性能下降。第二层目标级融合。指每个传感器先独立输出“目标列表”位置、尺寸、速度、类别、置信度再由融合模块对这些目标做“关联”与“生死管理”。这是Apollo主线采用的思路也是工业界最稳妥的做法。它能容忍某个单传感器暂时失效其他传感器仍然可以维持系统运行。第三层决策级融合。指各传感器独立完成完整的感知任务后感知模块在不同置信度下选择某个传感器的结果作为最终输出。比如天气差时优先信任毫米波雷达的目标列表天气好时信任激光雷达视觉融合结果。这个层次最简单但决策粗糙信息利用不充分。目标级融合之所以是主流是因为它在“鲁棒性”和“信息利用程度”之间取得了最佳平衡。它不需要像素级配准传感器各自独立工作任意一个传感器被遮挡或出故障系统不至于整体瘫痪。4.2 目标关联别让同一个目标被“感知两次”目标级融合最核心的难点是“目标关联”。说白了摄像头报告了一个目标位置在(10.5, 3.2)激光雷达也报告了一个目标位置在(10.6, 3.1)你怎么判断这俩是同一个目标最简单的方法是用距离阈值。两目标在空间上的距离小于某个阈值就认为是同一个。但实际场景远比这个复杂激光雷达测距准、测速差雷达测速准、测距稳摄像头测距受深度估计误差影响。不同传感器的误差特性不同不能简单用欧几里得距离一刀切。目标靠近时很多传感器输出会互相干扰比如两个并排行人的距离小于阈值关联时很容易错配。传感器输出频率不同需要先做时间对齐再在空间上匹配。Apollo的融合模块引入了“证据权重”的概念每个传感器目标根据其历史置信度和当前环境状态动态调整在融合结果中的权重。比方说强光场景下摄像头的置信度权重自动下降而毫米波雷达的权重上调。这个机制比固定权重聪明得多。写代码时我建议你先把“关联”和“状态估计”分开理解。关联解决的是“哪些测量对应同一个物体”状态估计解决的是“这个物体在哪、速度多少”。两个问题混在一起讨论很容易逻辑混乱。Apollo里对应的实现模块分别是Probabilistic Fusion和Track Management课程源码里分得很清楚。4.3 Track的生命周期管理目标级融合输出的不是一帧一帧独立的检出框而是一条条连续的Track轨迹每条Track有唯一的ID。生命周期管理是融合模块里最繁琐、也最体现工程复杂度的地方。一个Track的生命周期大致是这样诞生新目标出现连续多帧都被检测到置信度累积超过阈值才允许诞生新Track。这一步是为了过滤“瞬时虚警”。维持每帧用新的传感器测量更新Track的状态和置信度。如果某个传感器暂时丢失目标其他传感器还能维持Track存活。消亡连续N帧没有任何传感器更新它置信度逐渐衰减直到低于阈值删除Track。合并/分裂两个Track靠太近时可能被合并一个Track因为遮挡被拆成两个时分裂成两条新Track。这个生命周期管理对下游规划的影响怎么说都不为过。规划模块依赖Track的ID连续性和稳定性来判断“前方目标是否是新出现的”。如果一个停着的车的ID每帧都在变规划模块会认为前方不断出现“新障碍物”直接触发急刹车策略。课程进阶篇里有一段话我印象很深感知系统稳定性的评估指标不只是“检测率”和“误检率”还有一个重要维度叫“ID Switch率”——就是目标ID跳变的频率。这个指标对用户体验的影响甚至比单帧检测精度更显著。我自己在实车上测试时最直观的感受是ID稳定了车辆加减速立刻顺滑很多。4.4 融合结果的数据结构与下游交接融合模块最终输出的结构在Apollo里通常用PerceptionObstacle表示。它包含一系列字段目标ID、位置、速度、加速度、目标类型车/行人/自行车/未知以及一个表示“是否可信”的置信度。这个结构的设计有两点值得注意第一它把所有传感器的原始信息都“归一化”了。不管目标来自激光雷达、摄像头还是雷达最终下游模块看到的是统一的接口。这是系统解耦的关键我强烈建议你在自己的项目里也养成这个习惯别把某个传感器的特有字段直接暴露给下游逻辑。第二它包含了“行为预测前置信息”。目标的速度和方向不仅是当前位置的瞬时值还会做短时预测供预测模块直接使用。Apollo在这里做了一个很聪明的处理感知模块负责“现在在哪”预测模块负责“即将去哪”但“现在在哪”的质量直接决定了预测的起点准不准。感知和预测的边界在这里深度融合。我也遇到过一些开发者在自研系统时忽略了这个细节感知输出了目标位置但没输出速度和朝向下游预测模块只能自己用位置差分去“猜”效果大打折扣。这种问题一旦到了系统层面返工成本很高。5. 实操中的典型问题与排查经验——照着抄就能少走弯路5.1 时间戳对齐融合错位的隐藏元凶我在前面反复提到时间同步这里展开讲一次踩坑经历。某次调试我在可视化工具里看到一辆车的点云和摄像头框位置严重错位车已经被框出好几米。第一反应以为标定出了问题重标一套外参问题依旧。后来一步一步排查才发现是传感器时间戳没有对齐。当时激光雷达是10Hz摄像头是10Hz看起来频率相同但实际上二者的采样时刻相差近40毫秒。车辆在30km/h时走40毫秒位移约0.33米。这点位移在视野开阔时不太明显但在近距离比如车头前2米处被进一步放大框和点云就产生了肉眼可见的偏差。Apollo的处理方式是在数据进入感知模块前先做时间同步缓存把同一时刻附近的传感器数据组合成一个“感知帧”。这个机制在底层数据通道上做了对齐避免在算法层处理发散的时间差。排查建议如果你发现融合目标位置在车辆运动时出现周期性抖动先检查时间戳而不是急着动标定参数。查看一条Track的位置误差曲线如果误差随车速增大而线性增大大概率是时间同步问题。5.2 标定参数正确但图像投影还是歪的标定是所有传感器融合的前置条件。很多人在标定这一步反复折腾标定结果看起来误差很小但点云投影到图像上仍然有偏移。我总结过最可能导致这种情况的三个原因第一标定板的检测本身有误差。棋盘格或标定板在点云里的角点提取精度受点云分辨率影响很大。尤其是在远距离标定或标定板反光不均匀时角点误差会被放大。建议采集多组标定图像挑选点云清晰的帧不要用自动采集的一整段数据。第二时间同步和标定耦合了。标定时的传感器数据如果在时间上没对齐标定外参里会把时间误差“吸收”进去结果就是标定误差看着小实际使用时投影错位。所以标定前先确认时间同步正确再做外参标定。第三标定板材质对激光雷达的反射强度过低。某些吸光材料的标定板在点云里几乎看不见角点提取失败。建议用高反光材料制作的标定板并保证标定板表面干净。5.3 点云中的鬼点与滤波策略鬼点是激光雷达感知最头疼的问题之一。雨滴、灰尘、玻璃反射、甚至飞虫扫过都会产生一组不真实的点。鬼点既会影响聚类生成假目标也会影响地面滤除让地面高度估计出现抖动。处理鬼点常见的策略包括基于反射强度过滤雨滴和灰尘的反射强度通常很低可以通过强度阈值过滤。但这个方法要慎用因为远处的真实目标强度也很低一刀切会导致远距离检测率下降。基于点云密度过滤真目标在空间中是连续表面点云密度高雨滴和灰尘是离散的孤立点周围邻居点少。通过计算每个点的局部密度可以滤除孤立点。这个思路相对稳健。基于多帧回波一致性过滤短暂出现的点在历史帧中没有连续对应可以通过时序一致性来剔除。这个方法计算成本略高但对动态噪声效果好。实操上我给出的建议是先做“基于局部密度”的滤波再做“基于距离分段”的强度滤波。两个滤波器的参数不要静态固定可以根据天气模式动态切换。比如雨天模式开启更强的时间维滤波晴天模式可以关闭一部分滤波以保全远距离召回。5.4 模型在仿真环境表现好实际路上崩了这个现象几乎每个做感知的人都遇到过。仿真环境的传感器模型比较理想点云干净、光线均匀、没有极端角度。而真实路上传感器噪声、遮挡、天气、路况的复杂性远超想象。解决这个问题不能指望“换一个更大的模型”或者“无脑加数据”。我建议用一套递进式的验证流程第一步先在官方数据集上复现基线结果确认你的复现环境与官方没有明显差距。第二步用自己录制的真实道路数据做测试重点关注“少见场景”而不是平均精度。第三步设计“故障注入”测试——比如在测试时故意遮挡某个传感器、压低分辨率、增加运动模糊观察系统会不会崩。这一步是检验系统鲁棒性的最直接手段。Apollo课程进阶篇虽然没有专门讲“故障注入”但我在实际工程中的经验是一个感知系统能不能用看的不是它的最好成绩而是它“在最差条件下还能不能保持基本可用”。系统里一定要有“降级策略”比如激光雷达坏了视觉还能维持多远距离的检测摄像头失灵时雷达还能不能报目标。这些逻辑比“把模型精度再提0.5个点”重要得多。6. 对未来感知演进的思考——从多传感器融合到端到端感知我最后想谈一点进阶篇之外的延伸思考。当前Apollo的框架是“多传感器输入 → 各自感知 → 融合”的经典架构这条路线成熟、稳定、可解释性好尤其适合工程落地。但业界也确实在探索另一条路径端到端感知。端到端感知的典型形态是把多传感器的原始数据直接输入到一个统一的深度网络中网络内部自主完成特征提取、跨模态关联和目标输出不再显式地分“激光雷达网络”“摄像头网络”“融合模块”三个独立部件。它的优势在于特征层面的深度融合可以学出一些人工设计难以发现的关系但劣势也很明显可解释性差调试困难“在哪里错了”很难定位。我自己对这种演进的态度是经典架构在相当长时间内仍然是量产方案的主流因为它符合安全行业的工程习惯——模块边界清晰、每个环节可单独验证、错误可追溯。端到端方向可能更适用于某些特定场景的优化但如果你想深入学习感知系统的全貌先吃透经典架构再去看端到端方案会容易得多。还有一点我觉得值得所有做感知的人时常提醒自己感知的任务不是“把图认得越准越好”而是“让下游的规划和控制系统能在真实环境中安全、舒适地运行”。如果某个模型精度的提升不能让下游体验有实际改善那么它在系统中的优先级就应该往后排。这个视角是项目从“算法Demo”走向“系统级产品”的必经之路。我个人的体会是学Apollo的进阶篇最大的收获不在于记住了几个检测网络的结构而在于理解了一套完整的系统思维传感器有局限、数据有噪声、时间有偏差、下游有要求——感知模块所做的每一层设计都是在这些约束下做最优权衡。后面如果再遇到一个新的传感器、一个新的模型试着从“它在这个系统链路里承接了什么、约束是什么、怎么与其他模块协同”的角度去分析你也会更容易抓住重点。对我自己而言下一步打算把BEV视角下的纯视觉感知方案和激光雷达方案都重新梳理一遍对比两者的合适应用场景和各自的精度边界。这个方向的内容整理完之后如果实践中有新的心得我会再回来补一篇。