2、感知系统基础：自动驾驶感知系统功能定义、感知模块在自动驾驶软件栈中的位置、感知系统的评价指标（mAP、IoU、FPS、延迟）
大家好，欢迎来到《英伟达自动驾驶感知系统实战课程》的第二讲。
上一章我们聊了自动驾驶的整体架构，算是开了个场。今天咱们把镜头拉近，聚焦到感知系统本身。说白了，感知系统就是自动驾驶汽车的“眼睛”和“耳朵”。没有它，车就是盲人骑瞎马，再牛的规划控制算法也白搭。
我个人习惯，在讲任何系统之前，先搞清楚三件事：它要干什么？它待在哪？怎么才算干得好？ 今天我们就围绕这三个问题展开。
2.1 感知系统功能定义：它到底要“感知”什么？
你想想看，一个人类司机开车，眼睛在看什么？
- 车道线：我在哪条道上？
- 其他车辆：他们会不会撞我？
- 行人：有没有人突然窜出来？
- 交通标志和信号灯：现在能不能走？
- 障碍物：路上有没有石头、锥桶？
- 可行驶区域：哪块地是能压的？
感知系统的任务，就是把上面这些信息，从传感器数据（摄像头、激光雷达、毫米波雷达）里提取出来，变成计算机能理解的“结构化数据”。
具体来说，感知系统通常包含以下几个核心子任务：
- 目标检测（Object Detection）：找出“有什么东西在哪”。比如，一辆车在正前方20米处，一个行人在右前方5米处。这是最基础的任务。
- 目标分类（Object Classification）：给检测到的目标打上标签。是轿车？卡车？还是自行车？
- 目标跟踪（Object Tracking）：给每个目标分配一个ID，并持续追踪它的运动轨迹。这能帮我们判断前车是在减速还是急刹。
- 语义分割（Semantic Segmentation）：给图像或点云中的每个像素/点都赋予一个类别。比如，哪些像素是道路，哪些是天空，哪些是车辆。这能精确地划分可行驶区域。
- 实例分割（Instance Segmentation）：比语义分割更进一步，不仅要分出类别，还要区分出同一类别的不同个体。比如，把两辆并排停着的车分开。
- 车道线检测（Lane Detection）：识别出车道线的位置、类型（实线、虚线、双黄线）。
- 交通标志与信号灯识别（Traffic Sign & Light Recognition）：读懂路牌和红绿灯。
核心观点：感知系统不是单一算法，而是一个多任务、多传感器融合的复杂系统。它的输出质量，直接决定了上层决策规划的安全性。
2.2 感知模块在自动驾驶软件栈中的位置：承上启下
自动驾驶软件栈，通常可以抽象成几个层级：
- 传感器层：摄像头、激光雷达、毫米波雷达、IMU、GPS等。这是数据的源头。
- 感知层：就是我们今天讲的。它接收原始传感器数据，输出环境模型。
- 定位与地图层：回答“我在哪”的问题。通常与感知层紧密耦合。
- 预测层：基于感知结果，预测其他交通参与者未来几秒的轨迹。
- 规划层：根据感知、预测和定位结果，规划出一条安全、舒适的路径。
- 控制层：将规划路径转化为方向盘、油门、刹车的具体指令。
感知模块，就夹在传感器层和预测/规划层之间。它的位置非常关键——它是整个软件栈的“瓶颈”。
我记得在早期做项目时，我们花了很多精力优化规划算法，但效果一直不理想。后来一查，发现是感知模块的延迟太高，导致规划器拿到的永远是“过时”的环境信息。你想想看，规划器以为前车还在10米外，其实人家已经刹停了，这不出事才怪。
所以，感知模块不仅要准，还要快。它的输出，是后续所有决策的基础。如果感知错了，后面再怎么优化也是白搭。这就是所谓的“Garbage In, Garbage Out”。
避坑指南：我曾经犯过一个错误，就是只关注感知算法的精度，忽略了它的延迟。结果在实车测试时，车辆反应总是慢半拍。后来我们不得不重新设计整个推理管线，加入了异步处理和流水线优化。所以，从一开始就要把延迟作为第一优先级来考虑。
2.3 感知系统的评价指标：怎么才算“干得好”？
评价一个感知系统，不能光看它“能不能检测到”。我们需要一套量化的指标。这里我重点讲四个最常用的：mAP、IoU、FPS、延迟。
2.3.1 IoU（Intersection over Union，交并比）
IoU是衡量检测框与真实框重合程度的指标。说白了，就是看你的框“画得准不准”。
计算公式很简单：
IoU = (检测框 ∩ 真实框的面积) / (检测框 ∪ 真实框的面积)IoU的值在0到1之间。通常，我们会设定一个阈值，比如0.5。如果IoU大于0.5，我们就认为这个检测是“正确”的（True Positive）。
| IoU值 | 含义 |
|---|---|
| 1.0 | 完美重合，几乎不可能 |
| 0.7 - 0.9 | 非常精准，常用于高精度场景 |
| 0.5 - 0.7 | 可接受，大多数检测任务的标准 |
| < 0.5 | 定位不准，通常视为误检 |
注意：IoU阈值的选择非常关键。阈值设得太高（比如0.9），会导致很多“差不多”的检测被过滤掉，召回率降低。设得太低（比如0.3），又会引入大量误检。我个人习惯，在自动驾驶场景下，对车辆和行人，IoU阈值设在0.5-0.7之间比较合理。
2.3.2 mAP（mean Average Precision，平均精度均值）
mAP是目标检测领域最核心的指标。它综合了精度（Precision）和召回率（Recall），能全面反映模型的检测能力。
简单理解：
- 精度：你检测出来的东西里，有多少是对的？
- 召回率：所有真实的目标里，你找出来了多少？
mAP的计算过程稍微复杂一点，但核心思想是：对于每个类别，计算在不同召回率下的平均精度，然后再对所有类别取平均。
在自动驾驶领域，我们通常使用mAP@0.5（IoU阈值为0.5时的mAP）和mAP@0.5:0.95（IoU阈值从0.5到0.95，步长0.05，取平均）。后者更严格，更能反映模型的精细定位能力。
实战经验：我在做项目时，发现mAP高并不代表一切。有一次，我们的模型在公开数据集上mAP达到了80%，但一上路就频繁误检。后来分析发现，是因为数据集里几乎没有“异形车”（比如洒水车、工程车），而模型对这些没见过的东西泛化能力很差。所以，mAP只能反映模型在特定数据集上的表现，不能完全代表真实世界的性能。
2.3.3 FPS（Frames Per Second，每秒帧数）
FPS衡量的是感知系统的处理速度。对于自动驾驶来说，速度就是生命。
为什么？
- 如果FPS是30，意味着每33毫秒处理一帧。车辆以60km/h行驶，33毫秒能跑出约0.55米。
- 如果FPS是10，每100毫秒处理一帧，车辆能跑出1.67米。
你想想看，在紧急制动场景下，1.67米的差距可能就是撞上与没撞上的区别。
一般来说，对于高速公路场景，至少需要10-15 FPS；对于城市复杂场景，最好能达到20-30 FPS。
2.3.4 延迟（Latency）
延迟和FPS容易混淆。FPS是吞吐量，延迟是单次处理的时间。延迟通常包括：
- 传感器延迟：从物理世界事件发生到传感器输出数据的时间。
- 预处理延迟：数据格式转换、去畸变等。
- 推理延迟：神经网络前向传播的时间。
- 后处理延迟：NMS（非极大值抑制）、目标跟踪等。
在自动驾驶中，我们通常关注端到端延迟，即从传感器捕获数据到感知结果输出给规划模块的总时间。
一个常见的误区：很多人以为FPS高就等于延迟低。其实不一定。比如，一个系统可以做到30 FPS，但每帧的处理时间可能并不均匀。有时候这一帧花了10ms，下一帧花了50ms。这种抖动对规划控制非常不友好。所以，除了关注平均延迟，还要关注延迟的方差（抖动）。我建议，在实车部署时，要设置一个延迟的上限（比如100ms），超过这个上限的帧直接丢弃，避免给规划器传递过时信息。
2.4 总结与思考
好了，这一章我们讲了感知系统的三个核心问题：
- 功能定义：它负责将传感器数据转化为环境模型，包括检测、分类、跟踪、分割等。
- 系统位置：它位于传感器层和预测/规划层之间，是整个软件栈的瓶颈。
- 评价指标：IoU衡量定位精度，mAP衡量综合检测能力，FPS和延迟衡量实时性。
最后，我想留一个问题给大家思考：如果让你在mAP和延迟之间做取舍，你会怎么选？为什么？ 下一章，我们会深入讲解传感器选型与数据预处理，到时候再聊。
我们下节课见。