📚 课程目录第4章数据采集与同步

4. 数据采集与同步

在泊车多传感器融合系统中，数据采集与同步是决定后续感知精度与算法上限的“地基”。泊车场景中，车辆低速运动、环境结构密集、传感器视场高度重叠，若相机、毫米波雷达、超声波雷达、IMU与轮速计的数据在时间轴上错位，融合结果就会出现目标“重影”、车位线断裂、轨迹抖动等问题。本节围绕ROS/ROS2数据流组织方式、时间戳对齐策略、硬件触发同步、多传感器录制以及回放与标注工具链展开，帮助建立可复现、可验证的数据闭环。

一、ROS/ROS2数据流与时间语义

在ROS中，传感器数据以消息形式发布到话题（Topic），每个消息头（Header）携带stamp与frame_id。ROS1使用全局系统时间或仿真时间，ROS2则通过use_sim_time参数与/clock话题统一时间源。泊车数据采集通常涉及以下典型话题：

/camera_front/image_raw      # 前视相机图像
/camera_front/camera_info    # 相机内参
/radar_front/objects         # 前向毫米波雷达目标
/ultrasonic/ranges           # 超声波测距
/imu/data                    # IMU姿态与角速度
/vehicle/wheel_speed         # 轮速计
/tf                         # 坐标变换树

关键点在于：消息到达时间（接收时间）不等于采样时间（传感器曝光或雷达扫频时刻）。若直接使用接收时间做融合，低速泊车时1~2帧的错位就可能导致车位边界偏移十几厘米。因此，必须区分“采集时间戳”与“接收时间戳”，并在驱动层尽量保留硬件时间。

ROS2中推荐使用rclcpp::Time与message_filters的ApproximateTime策略，但近似对齐只是软件补偿，不能替代硬件同步。

二、时间戳对齐：从软件补偿到硬件触发

时间戳对齐的目标是让不同传感器在同一物理时刻的观测进入同一融合帧。常见策略分为三类：

软件时间戳对齐：以某一主传感器（如相机）为基准，通过message_filters::ApproximateTime或TimeSynchronizer匹配最近邻消息，适合对精度要求不高的场景。
硬件触发同步：由FPGA或同步控制器输出PPS/触发信号，同时触发相机曝光、雷达扫频和IMU采样，时间偏差可控制在微秒级。
混合对齐：硬件触发保证采样时刻一致，软件层再根据曝光延迟、雷达处理延迟做二次补偿。

泊车场景中，超声波雷达通常由车身控制器轮询，周期约20~50ms；毫米波雷达帧周期约50ms；相机30fps。若不做硬件同步，仅靠软件近似，融合帧的时间不确定度可能达到30ms以上。以车速5km/h计算，30ms内车辆移动约4.2cm，对车位线检测尚可接受，但对近距离障碍物测距已接近误差边界。

三、多传感器录制：rosbag与MCAP

ROS1使用rosbag record，ROS2推荐ros2 bag record，底层格式逐步从SQLite3迁移到MCAP。录制时需注意：

使用--all会录下大量无关话题，建议显式列出关键话题，并设置--max-split-size避免单文件过大。
开启--compression-mode file --compression-format zstd可显著降低存储占用，但会增加回放时的CPU开销。
录制前确认/clock与use_sim_time配置一致，否则回放时时间戳会跳变。

ros2 bag record \
  /camera_front/image_raw \
  /camera_front/camera_info \
  /radar_front/objects \
  /ultrasonic/ranges \
  /imu/data \
  /vehicle/wheel_speed \
  /tf /tf_static \
  --max-split-size 2048 \
  --compression-mode file \
  --compression-format zstd \
  -o parking_session_001

建议在录制目录中同步保存一份metadata.yaml，记录车辆VIN、传感器标定版本、软件版本与采集地点，便于后续追溯。

四、数据回放与标注工具链

回放是验证融合算法与同步策略的核心手段。ROS2中可使用ros2 bag play配合--rate控制速度，--clock发布仿真时间。回放时需关注：

环节	工具/命令	关键参数	常见问题
回放	ros2 bag play	--rate 0.5, --clock	时间戳跳变、TF缺失
可视化	RViz2 / Foxglove	Fixed Frame, QoS	QoS不匹配导致无数据
标注	CVAT / LabelCloud / SUSTechPOINTS	3D框、车道线、车位角点	相机与雷达标注不同步
校验	evo / rqt_plot	APE, RPE	轨迹对齐误差累积

标注工具链方面，泊车场景需要标注车位角点、车位线、障碍物3D框与可行驶区域。推荐流程是：先用ros2 bag导出同步后的图像与点云帧，再导入CVAT或SUSTechPOINTS进行标注，最后通过脚本将标注结果与原始时间戳绑定，生成训练集。若标注时未使用统一时间基准，相机与雷达的标注框会出现系统性偏移，导致训练出的模型在融合时“学错”对应关系。

五、误区与复盘

误区一：只看接收时间，不看采样时间。驱动层若未保留硬件时间戳，后续任何对齐都是“将错就错”。

误区二：认为软件近似对齐可以替代硬件同步。在低速泊车中，30ms错位可能被容忍，但在近距离障碍物与窄车位场景中会直接导致误检。

误区三：录制时忽略QoS配置。ROS2中传感器数据常用SensorDataQoS（Best Effort），而录制节点若使用Reliable，可能收不到数据或丢帧。

误区四：回放时不发布/clock。导致依赖仿真时间的节点时间戳错乱，融合结果不可复现。

复盘建议：每次采集后，用ros2 bag info检查各话题消息数、时间跨度与频率；用rqt_plot绘制时间戳差值曲线，确认同步误差是否在阈值内；对关键场景（如窄车位、低矮障碍物）单独切片保存，形成可回归的测试集。只有把数据采集与同步做成可量化、可复现的工程链路，后续的融合与车位检测算法才有稳定的输入基础。