一、自动驾驶数据采集系统概述

大家好，我是老张。在自动驾驶这个行当摸爬滚打了七八年，踩过的坑比走过的路还多。今天咱们聊聊数据采集系统——说白了，这就是自动驾驶的「眼睛」和「耳朵」。没有它，后面的感知、决策、控制全是空中楼阁。

我记得刚入行那会儿，团队花三个月攒了一套采集系统，结果上路第一天就发现数据丢了三分之一。嗯，从那以后我养成了一个习惯：先搭系统架构，再填功能模块。今天就把这套方法论掰开揉碎了讲给你听。

1.1 系统架构：分层解耦才是王道

一个成熟的数据采集系统，我习惯把它拆成四层。你想想看，如果所有功能都揉在一起，后期维护起来得多痛苦？

层级	核心职责	我踩过的坑
感知层	摄像头、激光雷达、毫米波雷达、IMU等传感器数据获取	曾经因为摄像头和激光雷达时间戳没对齐，导致融合算法跑出来的结果全是鬼影
传输层	数据从传感器到计算单元的搬运，包括CAN总线、以太网、PCIe等	有一次用USB3.0传激光雷达点云，带宽不够直接丢包，后来全换成万兆网口
处理层	数据预处理、压缩、编码、时间同步	建议在车上就做轻量级压缩，不然回传带宽撑不住
存储层	本地缓存、云端上传、冷热数据分级	固态硬盘写寿命是个大坑，我后来改用NVMe加RAID0才解决

我个人习惯在感知层和处理层之间加一个「数据总线」的概念。什么意思呢？就是所有传感器数据都先丢到总线上，下游模块按需订阅。这样做的好处是——新增传感器不用改代码，改个配置文件就行。

1.2 核心功能模块：少了哪个都不行

一个能用的采集系统，至少得包含下面这几个模块。我按重要程度排了个序：

1. 传感器驱动模块——说白了就是让摄像头、激光雷达这些硬件「开口说话」。这里有个坑：不同厂商的传感器协议千奇百怪，我建议统一封装成ROS2的msg格式，后期切换传感器只需要改驱动层。
2. 时间同步模块——这是整个系统的命门。我曾经在项目里用PTP（精确时间协议）做多传感器同步，精度能到微秒级。但要注意，GPS的PPS信号必须接入，否则长时间运行会漂移。
3. 数据压缩模块——一辆自动驾驶测试车，一天能产生2-5TB数据。不压缩的话，存储成本能把你公司搞破产。我常用的方案：视频用H.265硬编码，点云用Draco库压缩，IMU数据直接用差分编码。
4. 健康监控模块——这个很多人会忽略。我建议每100ms检查一次传感器状态、CPU温度、磁盘剩余空间。曾经有一次因为散热风扇坏了，采集到一半系统过热关机，半天数据全白干了。
5. 数据回传模块——车端到云端的管道。4G/5G网络不稳定是常态，我习惯用断点续传+多线程分片上传。嗯，这里要注意：千万别用TCP长连接，运营商会掐。

1.3 数据流：从传感器到硬盘的完整旅程

咱们来走一遍数据流的完整路径。你想象一下，一辆测试车正在路上跑：

传感器（Camera/LiDAR/Radar）
    ↓ 触发信号（硬件触发或软件触发）
时间同步模块（打上全局时间戳，精度1μs）
    ↓ 原始数据
数据预处理（去噪、格式转换、ROI裁剪）
    ↓ 压缩后的数据流
本地缓存（NVMe SSD，循环写入，保留最近2小时数据）
    ↓ 4G/5G/以太网
云端存储（对象存储S3，冷热分层）
    ↓ 按需下载
数据回放系统（模拟真实传感器输出）

这里有个关键点：数据流必须是异步的。我曾经犯过一个错误——让采集线程等压缩线程，结果传感器数据堆积，最后内存溢出。正确的做法是：采集线程只管往环形缓冲区里写，压缩线程从缓冲区里读，两者互不阻塞。

为什么会这样？因为传感器的帧率是固定的（比如摄像头30fps），但压缩耗时是不确定的。如果同步处理，一旦压缩卡住，下一帧数据就丢了。

1.4 存储策略：别让数据成为负担

存储这块，我建议分三级：

存储层级	介质	容量	用途
L1 热数据	NVMe SSD（车端）	1-2TB	最近2小时的原始数据，用于实时回放和快速验证
L2 温数据	HDD/SSD（边缘节点）	10-50TB	最近一周的数据，用于模型训练和场景挖掘
L3 冷数据	对象存储（云端）	PB级	长期归档，按需取用

另外，数据命名规范也很重要。我习惯用这个格式：

采集日期_车辆ID_场景标签_传感器类型_时间戳.bin
示例：20250315_CAV001_highway_camera_1742000000.bin

这样做的好处是——回放时不需要查数据库，光看文件名就知道这段数据是什么场景、哪个传感器、什么时间采集的。嗯，这个习惯帮我省了无数查日志的时间。

1.5 避坑指南：我这些年交的学费

• 时间戳精度不够——我曾经用系统时间戳做同步，结果不同传感器的时间差最大能到50ms。后来强制要求所有传感器必须硬件触发，并且用PTP协议同步到GPS时钟。
• 磁盘写满不预警——有一次测试车跑了4个小时，突然发现磁盘满了，后面的数据全没存下来。从那以后，我规定磁盘使用率超过80%就要弹窗报警，超过90%自动停止采集。
• 数据格式不统一——团队里有人用ROS bag，有人用自定义格式，还有人用CSV。回放时各种格式转换，烦得要死。我后来强制统一用Apache Arrow格式，跨语言、跨平台都兼容。
• 忽略电磁干扰——在强电磁环境下（比如高压充电桩旁边），CAN总线数据会出错。我建议在传感器端加隔离芯片，并且数据包里带CRC校验。

好了，关于数据采集系统的架构、功能模块、数据流和存储策略，今天就聊到这儿。下一章咱们深入讲讲传感器选型与标定——这可是个技术活，选错了传感器，后面所有工作都白搭。

公众号:蓝海资料掘金营，微信deep3321