4. 数据采集体系

数据采集体系是Robotaxi数据闭环的“入口”。如果入口设计不当,后续的标注、训练、仿真和回放都会受到牵连:要么数据量巨大但价值密度极低,要么关键场景被漏采,要么因合规问题无法使用。本章围绕车端采集架构、传感器同步、数据脱敏以及触发式与全量采集策略四个核心问题展开,帮助建立一套可落地、可扩展、可审计的采集体系。

一、车端数据采集架构:从传感器到落盘的分层设计

Robotaxi车端采集架构通常分为四层:传感器层、采集接入层、预处理与缓存层、落盘与上传层。传感器层包括激光雷达、摄像头、毫米波雷达、GNSS/IMU、轮速计等;采集接入层负责时间戳对齐、数据格式统一和带宽整形;预处理层完成脱敏、压缩、抽帧和触发判断;落盘层则根据策略决定写入本地SSD还是上传云端。

架构设计的关键在于“采集不干扰主链路”。自动驾驶主链路对实时性要求极高,采集模块必须运行在独立进程或独立计算单元上,通过共享内存或零拷贝方式获取数据,避免因磁盘IO或网络抖动影响控制循环。常见做法是使用独立的采集工控机或Orin上的独立容器,并设置CPU亲和性与IO优先级。

采集配置示例(YAML):
sensors:
  - name: front_camera
    type: camera
    topic: /cam/front/image
    rate_hz: 30
    format: h265
  - name: top_lidar
    type: lidar
    topic: /lidar/top/points
    rate_hz: 10
    format: pcd
sync:
  master: gnss_time
  tolerance_ms: 5
trigger:
  collision: true
  hard_brake: true
  takeover: true
  full_capture_ratio: 0.02
privacy:
  face_blur: true
  plate_blur: true
  gps_offset_m: 50

二、传感器同步:硬件触发与软件对齐

多传感器同步是采集质量的基础。Robotaxi上常见的同步方式有三种:硬件触发同步、PTP/gPTP网络同步、软件时间戳对齐。硬件触发通过同一触发源同时激励相机曝光和激光雷达扫描,精度可达微秒级;PTP适用于以太网连接的传感器,精度在亚微秒到微秒级;软件对齐则依赖各传感器自带时间戳和插值算法,精度较低但成本最低。

实际工程中往往采用混合方案:激光雷达与相机使用硬件触发,毫米波雷达和GNSS通过PTP同步,IMU以最高频率采样后作为参考时钟。同步误差需要被记录并写入数据元信息,供后续训练时判断是否可用。一般要求相机与激光雷达的同步误差小于5ms,否则融合标注会出现明显错位。

同步质量检查建议:在采集回放工具中叠加显示各传感器时间戳曲线,若某一路出现周期性抖动,优先检查触发线缆屏蔽和PTP主时钟负载。

三、数据脱敏:合规前提下的可用性平衡

Robotaxi采集的数据包含大量人脸、车牌、地理位置等敏感信息。脱敏不是简单打码,而是要在合规、可用、可追溯三者之间取得平衡。常见脱敏对象包括:人脸、车牌、行人衣着特征、住宅门牌、GPS精确坐标。脱敏时机分为车端实时脱敏和云端离线脱敏:车端脱敏可减少上传带宽和合规风险,但算力有限;云端脱敏效果更好,但原始数据已离开车辆,需要加密传输和访问审计。

推荐策略是车端做粗脱敏,云端做精脱敏。车端对图像中的人脸和车牌区域进行模糊或马赛克,对GPS坐标做偏移;云端再利用更高精度模型进行二次检测和脱敏,并保留脱敏日志。脱敏后的数据仍需保留原始数据的哈希索引,以便在合规审计时证明数据来源和脱敏过程。

四、触发式采集与全量采集策略

全量采集指车辆在所有运行时段持续记录所有传感器数据,优点是数据完整、可回溯,缺点是存储和上传成本极高。触发式采集则只在特定事件发生时保存前后一段时间的数据,例如急刹车、接管、碰撞、近距离cut-in、施工区等。两者并非互斥,而是按比例组合。

典型策略是“全量低帧率+触发高帧率”:日常以低帧率、低分辨率保存全量数据用于统计和长尾挖掘;当触发条件满足时,自动切换到高帧率、全传感器原始数据保存,并标记事件类型。触发条件需要可配置、可版本化,避免因阈值调整导致数据分布漂移。

策略维度 全量采集 触发式采集
数据完整性 高,可回溯任意时刻 仅覆盖事件前后窗口
存储成本 极高,需大容量SSD 低,按事件量弹性增长
上传带宽 压力大,需边缘压缩 可控,优先上传高价值片段
适用场景 新区域开城、算法大版本验证 日常运营、长尾场景挖掘
风险 数据冗余、标注成本高 触发漏报导致关键场景丢失

五、案例与复盘:一次漏采引发的迭代延迟

某Robotaxi团队在夜间雨天场景中频繁出现误制动,但回传数据中却找不到对应片段。复盘发现:触发条件只配置了“急刹车”和“接管”,而误制动发生时安全员并未接管,车辆也未达到急刹车阈值,导致数据未被保存。团队随后增加了“纵向减速度异常”“感知置信度骤降”“雨刷高频动作”等软触发条件,并将触发前后窗口从5秒扩展到15秒。调整后,同类场景的捕获率从不足20%提升到85%以上。

常见误区:只依赖硬触发(碰撞、急刹)会漏掉大量“未接管但体验差”的场景;触发阈值长期不更新,会导致数据分布与当前ODD脱节。建议每月复盘触发命中率与漏报案例。
Robotaxi 车端数据采集体系与触发式采集流程 传感器层 摄像头 × 7 激光雷达 × 2 毫米波雷达 × 5 GNSS / IMU / 轮速 同步与接入层 硬件触发同步 PTP / gPTP 时间戳对齐 共享内存零拷贝 预处理与脱敏层 人脸 / 车牌模糊 GPS 坐标偏移 H.265 压缩 触发条件判断 落盘与上传层 本地 SSD 环形缓存 事件片段打包 5G / Wi-Fi 上传 云端对象存储 触发式采集流程:环形缓存 + 事件窗口 t-15s t-5s t(触发点) t+5s t+15s 环形缓存(持续写入,低帧率全量) 事件窗口(高帧率原始数据,前后各15s) 触发事件 硬触发 碰撞 / 急刹 / 接管 / 气囊 软触发 置信度骤降 / 减速度异常 / 雨刷 全量策略 低帧率全量 + 高帧率触发

总结来看,Robotaxi数据采集体系需要在架构上做到“采集与主链路解耦”,在同步上做到“硬件优先、软件兜底”,在脱敏上做到“车端粗脱敏、云端精脱敏”,在策略上做到“全量保底、触发提效”。只有这四者协同,才能让数据闭环真正跑起来,而不是被存储成本和合规风险拖垮。