4. 数据采集规范

数据采集是自动驾驶数据治理链条的起点。采集阶段一旦出现标定漂移、时间错位、场景偏斜或丢帧，后续的清洗、标注、训练与评测都会在错误的基础上叠加误差。因此，采集规范不是“建议性文档”，而是必须可执行、可校验、可追溯的工程约束。本章围绕四个核心维度展开：采集设备标定、时间同步、场景覆盖策略、采集频率与数据完整性要求。

一、采集设备标定：让多传感器说同一种“空间语言”

自动驾驶采集车通常搭载激光雷达、前视/环视相机、毫米波雷达、IMU、GNSS/RTK 等传感器。每个传感器都有自己的坐标系，标定的目标就是求出它们之间的外参（旋转与平移）和内参（焦距、畸变、安装角等），使同一时刻的同一物理点能在不同传感器数据中对应起来。

标定分为出厂标定、上线前标定和在线标定三个阶段。出厂标定确定传感器自身参数；上线前标定在车辆装配完成后进行联合标定；在线标定则在运行中监测标定是否漂移。采集规范应明确：每次采集任务开始前必须校验标定文件版本，标定文件需与采集数据一同入库，形成“数据—标定—车辆”三元绑定关系。

二、时间同步：把不同频率的信号对齐到同一时间轴

相机通常为 30Hz 或 60Hz，激光雷达为 10Hz 或 20Hz，IMU 可达 100Hz 以上，GNSS 为 1Hz 或 10Hz。若不做时间同步，融合算法会把不同时刻的观测当作同一时刻处理，导致目标位置偏移、速度估计错误。时间同步的核心是统一时钟源与硬件触发。

推荐方案是：以 GNSS 的 PPS（秒脉冲）作为全局时钟基准，通过 PTP（IEEE 1588）或 gPTP 同步各传感器和采集主机；相机采用硬件触发曝光，激光雷达采用角度触发或时间戳对齐；所有数据包在写入时打上统一时间戳。采集规范应规定最大允许时间偏差，例如相机与激光雷达之间不超过 5ms，IMU 与主机之间不超过 1ms。

# 时间同步检查示例
sensor_timestamp_alignment:
  camera_front:  {freq: 30Hz, max_offset_ms: 5}
  lidar_top:     {freq: 10Hz, max_offset_ms: 5}
  imu:           {freq: 100Hz, max_offset_ms: 1}
  gnss:          {freq: 10Hz, max_offset_ms: 1}
  clock_source:  "GNSS_PPS + PTP"
  check_rule:    "abs(ts_sensor - ts_master) <= max_offset_ms"

三、场景覆盖策略：从“随机采”到“按需采”

采集数据如果只覆盖晴天、白天、主干道，训练出的模型在雨天、夜间、匝道、施工区就会失效。场景覆盖策略要求先定义场景维度，再按维度设计采集任务，最后统计覆盖度并补齐缺口。常见维度包括：天气（晴/雨/雪/雾）、光照（白天/黄昏/夜间）、道路类型（高速/城市/乡村/停车场）、交通参与者（行人/非机动车/大型车）、行为（切入/加塞/鬼探头/施工绕行）等。

覆盖度可以用“场景标签矩阵”来管理。每个采集片段打上多维标签，统计各标签组合的时长与片段数，低于阈值的组合进入补采队列。这样采集就从“司机凭感觉开”变成“数据驱动排班”。

四、采集频率与数据完整性要求

采集频率不是越高越好。频率过高会带来存储、传输和标注成本激增；频率过低则可能漏掉关键瞬间。规范应根据任务目标设定最低频率：例如高速场景相机不低于 30Hz，城市复杂路口建议 60Hz；激光雷达不低于 10Hz；IMU 不低于 100Hz。同时要规定丢帧率上限（如单传感器丢帧率 ≤ 0.5%）、片段最短时长（如 20s）、元数据完整性（车辆 ID、标定版本、时间戳、场景标签、采集人员等字段齐全）。

完整性校验应在采集端实时进行，发现异常立即告警并记录，避免“采完才发现坏了一半”。常见校验项包括：文件大小是否为零、时间戳是否单调递增、帧序号是否连续、校验和是否匹配、标定文件是否存在。

五、案例与常见误区

某项目在初期采集时未强制绑定标定文件，导致后期发现部分数据的外参版本与车辆实际装配不一致，融合标注出现系统性偏移，返工成本极高。另一个常见误区是“只关注数据量，不关注场景分布”，采集了数万公里高速数据，但城市无保护左转、夜间行人横穿等关键场景几乎为零，模型在长尾场景上表现很差。

复盘来看，有效的采集规范应做到“四个可”：可执行（有明确参数和脚本）、可校验（有自动检查规则）、可追溯（标定、时间、场景、人员全记录）、可迭代（根据模型反馈调整覆盖策略）。只有把采集规范做成工程闭环，后续的数据治理才有稳定的输入基础。