4. 感知系统集成：多传感器标定、算法部署与数据流管理

各位同学，今天我们聊一个非常实战的话题——感知系统集成。说实话，这部分内容在课本上往往被一笔带过，但在实际工程中，它往往是整个自动驾驶系统里最让人头疼的环节之一。我当年刚入行时，就因为在传感器标定上踩了个大坑，导致整个demo车在路上跑偏了三天……嗯，从那以后我再也不敢轻视这个环节了。

4.1 多传感器标定：联合标定

什么叫联合标定？说白了，就是让车上的各个传感器——摄像头、激光雷达、毫米波雷达、IMU——知道彼此之间的相对位置和姿态。你想想看，如果摄像头看到一个障碍物在正前方，但激光雷达却认为它在左前方，那融合出来的结果肯定是一团糟。

联合标定的核心，就是求解传感器之间的外参矩阵。这个矩阵包含旋转和平移信息。我习惯用以下流程：

  1. 单传感器内参标定——先搞定每个传感器自己的内部参数。比如相机的焦距、畸变系数，激光雷达的扫描角度偏差等。
  2. 两两外参标定——比如相机-激光雷达联合标定。常用的方法是找一个标定板，同时被相机和激光雷达看到，然后通过特征匹配求解。
  3. 全局优化——把所有传感器的外参放到一个图优化框架里，做一次全局的Bundle Adjustment。

重要提醒：联合标定不是一次性的工作。车辆在行驶中，传感器支架可能会因为振动、温度变化而产生微小形变。我建议每运行100小时或每季度做一次重新标定。

这里给出一段我常用的相机-激光雷达联合标定代码片段（基于OpenCV和PCL）：

// 伪代码示例：相机-激光雷达联合标定
// 输入：标定板上的3D点云 + 对应的2D图像角点
// 输出：外参矩阵 R, t

1. 提取图像中的棋盘格角点 (cv::findChessboardCorners)
2. 提取激光雷达点云中落在标定板上的点 (平面拟合 + 边界提取)
3. 建立3D-2D对应关系
4. 使用PnP算法求解初始外参 (cv::solvePnP)
5. 使用非线性优化 (Levenberg-Marquardt) 最小化重投影误差
6. 输出最终的 R, t 矩阵

我的小技巧：标定环境最好选在空旷、光照均匀的场地。我曾经在室内停车场做标定，结果因为墙面反射导致激光雷达点云出现大量噪点，标定结果偏差了5厘米。后来换到室外操场，一次就过了。

4.2 时间同步：让所有传感器“同时说话”

联合标定解决了空间对齐的问题，但时间对齐同样关键。你想想看，如果相机在t时刻拍到了障碍物，但激光雷达在t+100ms才扫描到同一个位置，那融合结果就会出现明显的“拖影”。

时间同步通常有两种做法：

  • 硬件同步——通过PPS（秒脉冲）信号或IEEE 1588协议，让所有传感器共享同一个时钟源。这是最可靠的方式，但需要硬件支持。
  • 软件同步——通过时间戳对齐和插值算法，将不同频率的传感器数据对齐到同一个时间轴上。比如相机是30fps，激光雷达是10fps，我们可以用线性插值把激光雷达数据插到相机的时间戳上。

我个人习惯的做法是：先用硬件同步保证粗对齐（误差在1ms以内），再用软件做精细插值。这样既保证了精度，又降低了系统复杂度。

避坑指南：我曾经遇到过一个案例，激光雷达的时间戳是UTC时间，而相机的时间戳是系统启动后的相对时间。两者差了整整8个小时（时区问题）。结果融合出来的点云和图像完全对不上。所以，务必统一所有传感器的时间基准！

4.3 感知算法部署：目标检测与语义分割

标定和同步搞定了，接下来就是把算法部署上去。这里我重点讲两个任务：目标检测和语义分割。

4.3.1 目标检测

目标检测的任务是回答“哪里有障碍物，它是什么”。常用的算法有YOLO系列、CenterNet、PointPillars（针对激光雷达）等。

部署时要注意几个关键点：

  • 模型量化——从FP32降到INT8，推理速度能提升2-4倍，但精度会损失1-2%。我建议在量化后做一次校准数据集上的精度验证。
  • NMS优化——非极大值抑制是目标检测的后处理瓶颈。可以用CUDA加速的NMS，或者改用Soft-NMS来减少漏检。
  • 多尺度检测——小目标（比如远处的行人）容易被漏掉。我习惯在输入图像上做多尺度金字塔，或者使用FPN（特征金字塔网络）结构。
# 部署示例：使用TensorRT加速YOLOv5
import tensorrt as trt

# 构建引擎
builder = trt.Builder(trt.Logger(trt.Logger.WARNING))
network = builder.create_network()
parser = trt.OnnxParser(network, trt.Logger())
parser.parse_from_file("yolov5s.onnx")

# 配置量化
config = builder.create_builder_config()
config.set_flag(trt.BuilderFlag.FP16)  # 使用FP16推理

# 构建并保存引擎
engine = builder.build_engine(network, config)
with open("yolov5s_fp16.engine", "wb") as f:
    f.write(engine.serialize())

4.3.2 语义分割

语义分割的任务是给图像或点云中的每个像素/点赋予一个语义标签。比如“路面”、“车道线”、“行人”、“车辆”等。

常用的算法有DeepLabV3+、PSPNet、PointNet++（针对点云）。部署时我特别关注两点：

  • 推理速度——语义分割通常需要处理高分辨率输入（比如1920x1080），计算量很大。我建议使用轻量级backbone（如MobileNetV3）或者使用注意力机制来降低计算量。
  • 边缘处理——分割结果在物体边缘容易出现锯齿或空洞。可以用CRF（条件随机场）做后处理平滑，或者使用Dice Loss来训练模型，让边缘更锐利。

我的经验：在部署语义分割模型时，别忘了做类别平衡。我在一个项目中，路面类别占了90%的像素，而行人只占0.1%。如果不做加权损失函数，模型会直接忽略行人。后来我用Focal Loss解决了这个问题。

4.4 数据流管理：让数据“跑”起来

标定好了，算法也部署了，但数据怎么在系统里流转？这就是数据流管理要解决的问题。

一个典型的感知数据流是这样的：

  1. 传感器驱动层——从硬件读取原始数据（图像帧、点云帧、雷达点迹等），打上时间戳。
  2. 预处理层——做去畸变、滤波、降采样等操作。
  3. 同步层——将多传感器数据按时间戳对齐。
  4. 推理层——送入模型做目标检测和语义分割。
  5. 后处理层——做NMS、跟踪、融合等。
  6. 输出层——将感知结果发布到下游模块（规划、控制）。

我建议使用流水线架构来管理数据流。每个模块是一个独立的节点，通过消息队列（如ZeroMQ、ROS2的DDS）进行通信。这样做的好处是：

  • 解耦——每个节点可以独立开发、测试、升级。
  • 可扩展——想加一个新传感器？加一个节点就行。
  • 容错——某个节点挂了，其他节点还能继续工作。
数据流层级 典型延迟要求 常用技术
传感器驱动 < 1ms DMA、中断、零拷贝
预处理 < 5ms GPU加速、OpenCV
同步 < 2ms 时间戳队列、插值
推理 < 30ms TensorRT、ONNX Runtime
后处理 < 10ms CUDA NMS、卡尔曼滤波
输出 < 1ms 共享内存、DDS

注意：数据流管理中最容易忽略的是背压问题。如果推理层处理不过来，而传感器层还在不断发数据，内存就会暴涨。我建议在消息队列中设置最大长度，超过阈值就丢弃旧数据，或者使用有界队列。

好了，以上就是感知系统集成的核心内容。从联合标定到时间同步，从算法部署到数据流管理，每一步都环环相扣。说实话，这部分内容没有太多捷径可走，就是靠一遍遍的调试和优化。但当你看到车在路上稳稳地跑起来，所有传感器数据完美融合，那种成就感是无可替代的。

下一章我们会聊规划控制系统的集成，到时候见。

← 上一章 📖 返回目录 下一章 →