2. 自动驾驶数据基础

在自动驾驶车队的数据回流与版本管理工程中，所有后续的采集、上传、标注、训练与回灌，都建立在对“数据本身”的准确理解之上。如果对传感器数据类型、采集频率、数据量级、数据格式与存储介质缺乏清晰认知，就会出现采样配置不合理、存储成本失控、回流链路拥塞、版本对不齐等连锁问题。本章从工程视角梳理这五个基础维度，并给出可落地的参数参考与判断方法。

一、核心原理：五维度共同决定数据资产形态

自动驾驶数据不是单一文件，而是由多传感器在同一时间轴上协同产生的“数据包”。理解它需要同时看五个维度：类型决定语义与处理方式，频率决定时间分辨率与数据量，量级决定存储与传输预算，格式决定读写效率与工具链兼容性，介质决定耐久性与成本。五者相互约束：提高频率会放大数据量，改变格式会影响压缩率，更换介质会影响写入寿命。工程上必须把它们作为一个整体来配置，而不是孤立调参。

二、传感器数据类型与采集频率

主流自动驾驶车队通常搭载以下几类传感器，它们的数据类型与典型频率差异很大：

• 相机（Camera）：输出图像帧，前视常用 1920×1080 或 3840×2160，频率 10–30 Hz，多路环视可达 6–12 路。
• 激光雷达（LiDAR）：输出三维点云，机械式 10–20 Hz，半固态 10–20 Hz，单帧点数 5 万–30 万。
• 毫米波雷达（Radar）：输出目标列表与原始回波，频率 10–20 Hz，数据量相对小。
• IMU / GNSS：IMU 100–1000 Hz，GNSS 1–10 Hz，用于定位与时间同步。
• 底盘与轮速：CAN 总线信号，频率 50–100 Hz，用于车辆状态估计。

频率选择的核心原则是“满足算法需求的最小充分采样”。例如感知模型训练通常需要 10 Hz 以上的图像序列，而定位融合对 IMU 频率要求更高。频率过高会带来数据量激增，频率过低则可能丢失关键动态信息。

三、数据量级与存储介质

数据量级是车队数据工程中最容易被低估的部分。以一辆车为例，若配置 8 路 1080p 相机（30 Hz）、1 台 128 线激光雷达（10 Hz）、1 套 IMU（200 Hz），连续采集 8 小时，原始数据量约为 1–4 TB。若车队规模为 100 辆，每天产生 100–400 TB，每月可达 PB 级。

存储介质通常采用“车载热存储 + 云端冷存储”的分层策略。车载端使用高耐久 NVMe SSD 承担高频写入，云端使用对象存储（如 S3、OSS）承载长期归档，并通过生命周期策略将冷数据转入低频或归档层，控制成本。

四、数据格式与工程实践

数据格式的选择直接影响读写效率、压缩率与工具链兼容性。常见格式包括：

• rosbag / MCAP：ROS 生态常用，适合多传感器时间同步记录，MCAP 在索引与压缩上更优。
• HDF5：适合大规模数值数据，支持分块与压缩，常用于训练数据集。
• Parquet：列式存储，适合结构化信号与标注结果，查询效率高。
• PCD / 二进制点云：激光雷达常用，PCD 可读性好，二进制更省空间。

以下是一个典型的采集配置片段，用于说明频率与格式的绑定关系：

sensors:
  - name: camera_front
    type: camera
    resolution: 1920x1080
    fps: 30
    format: jpeg
  - name: lidar_top
    type: lidar
    channels: 128
    fps: 10
    format: pcd_binary
  - name: imu_center
    type: imu
    hz: 200
    format: parquet
record:
  container: mcap
  chunk_size_mb: 512
  compression: zstd

五、常见误区与复盘

在实际项目中，以下误区最为常见：

1. 只关注单帧大小，忽略频率叠加。单张图像不大，但 8 路 30 Hz 叠加后数据率会迅速上升。
2. 格式选择与工具链脱节。选了压缩率高的格式，但下游标注工具不支持，导致额外转换成本。
3. 存储介质耐久性不足。车载 SSD 长期高频写入，若未考虑 TBW 指标，容易出现掉盘。
4. 时间同步被忽视。多传感器频率不同，若没有统一时间基准，后续融合与回放会出现错位。

综上，传感器数据类型、采集频率、数据量级、数据格式与存储介质构成了自动驾驶数据工程的底层坐标系。只有把这五个维度对齐，才能让数据回流与版本管理在可控的成本与稳定的质量下持续运转。