1. ADAS数据采集概述
大家好，我是老张。做ADAS系统这些年，我最大的感触就是——数据采集是地基。地基没打好，后面算法、测试、验证全得翻车。今天咱们就聊聊数据采集的那些事儿。
1.1 传感器类型：ADAS的“眼睛”和“耳朵”
ADAS系统依赖多种传感器协同工作。每种传感器都有自己的脾气。我刚开始接触时，也踩过不少坑。
摄像头
摄像头是ADAS最常用的传感器。说白了，它就像人的眼睛。但摄像头有个致命弱点——怕黑、怕强光、怕雨雾。
- 单目摄像头：成本低，但测距精度一般。我曾在项目中用单目做前向碰撞预警，结果雨天误报率飙升。后来加了双目才解决。
- 双目摄像头：通过视差测距，精度高。但标定麻烦，两个镜头稍微错位，数据就废了。
- 环视摄像头：一般4-6个，覆盖车身周围。做自动泊车必备。
激光雷达
激光雷达是“精度担当”。它直接输出3D点云，不受光照影响。但价格嘛...嗯，你懂的。
- 机械式：旋转扫描，360°视野。但寿命短，震动环境下容易坏。
- 固态式：没有旋转部件，可靠性高。但视场角有限，一般需要多个组合。
我记得有一次做路采，激光雷达的旋转电机突然卡死。排查了半天，发现是灰尘太多。从那以后，我每次出车前都会检查雷达窗口是否干净。
毫米波雷达
毫米波雷达是“全天候选手”。雨雪雾天照样工作。它主要测距和测速，但角度分辨率低。
- 24GHz：短距，常用于盲区监测。
- 77GHz：长距，用于自适应巡航和自动紧急制动。
你想想看，如果只有摄像头，大雾天ACC还能用吗？不能。但毫米波雷达可以。这就是为什么高端车必须配雷达。
超声波雷达
超声波雷达成本最低，但精度也最低。它主要用于近距离探测，比如倒车雷达和自动泊车。
它的原理很简单——发射声波，等回波。但有个问题：温度会影响声速。我曾在冬天做测试，超声波测距偏差了5厘米。后来加了温度补偿才搞定。
1.2 数据采集硬件架构
传感器选好了，怎么把它们连起来？这就涉及到硬件架构了。我个人习惯把架构分成三层：
| 层级 | 组件 | 作用 |
|---|---|---|
| 感知层 | 摄像头、激光雷达、毫米波雷达、超声波 | 采集原始数据 |
| 传输层 | 以太网、CAN、LVDS、GMSL | 把数据传到处理单元 |
| 处理层 | 工控机、数据记录仪、存储设备 | 存储和预处理数据 |
这里有个坑要注意——带宽。摄像头数据量最大。一个200万像素的摄像头，30fps，YUV格式，每秒数据量接近1Gbps。如果同时接6个摄像头，再加上激光雷达的点云...嗯，普通千兆网卡根本扛不住。
1.3 数据同步机制：GPS/IMU时间戳对齐
这是数据采集中最头疼的问题。没有之一。
为什么需要同步？因为每个传感器都有自己的时钟。摄像头用系统时间，激光雷达用内部晶振，毫米波雷达用CAN时间。如果不做对齐，你看到的“同一时刻”的数据，可能差了100毫秒。
100毫秒是什么概念？车速60km/h，100毫秒车已经跑了1.67米。做目标融合时，这个误差足以让算法把一辆车识别成两辆。
硬件同步方案
最可靠的方式是用GPS的PPS（秒脉冲）信号。PPS每秒输出一个精确的脉冲，所有传感器都以此校准自己的时钟。
// 伪代码：PPS同步流程
void PPS_Interrupt_Handler() {
// 收到PPS脉冲
local_timestamp = GPS_UTC_Time;
// 校准本地时钟
adjust_local_clock(local_timestamp);
// 给每个传感器打时间戳
for each sensor in sensor_list {
sensor.set_timestamp(local_timestamp);
}
}软件同步方案
如果硬件不支持PPS，那就只能用软件对齐了。常见做法是：
- 所有传感器数据都带上本地时间戳
- 用GPS/IMU的精确时间作为基准
- 通过插值或最近邻匹配，把传感器时间对齐到GPS时间
我建议优先用硬件同步。软件同步虽然省钱，但精度有限。有一次我为了省成本，用了纯软件同步。结果做回放分析时，发现激光雷达和摄像头的数据总是对不上。排查了三天，最后发现是系统时钟漂移了。从那以后，我再也不敢省同步硬件的钱了。
IMU时间戳的特殊性
IMU（惯性测量单元）输出频率很高，一般100Hz以上。它的时间戳问题在于——数据是“积分”出来的。如果时间戳不准，积分误差会累积。
举个例子：IMU输出角速度和加速度，需要积分才能得到姿态和位置。如果时间戳偏差1毫秒，积分10秒后，位置误差可能达到几十厘米。所以IMU的时间戳必须精确到微秒级。
好了，这一章就聊到这儿。下一章咱们讲讲数据存储格式和文件管理。到时候我会分享一个我踩过的坑——关于文件命名不规范导致数据丢失的惨痛教训。敬请期待。