智身科技-钢镚L1EDU_W（一）多传感器的时间同步问题
- 一、平台与系统介绍
- 机械狗 | 计算平台与系统版本
- 二、传感器介绍
- 1、以数据为例xinghulou01为例 | 机械狗传感器总表
- 三、各个传感器的外参标定
- 轮足机械狗 / 空间标定总表
- 四、各个传感器的时间戳问题
- 💡 延伸探讨：多传感器时间对齐到底在做什么？
- 各传感器在 `xinghulou01` 数据中的处理逻辑
一、平台与系统介绍
机械狗 | 计算平台与系统版本
2026-11-04 通过机械狗 Wi-Fi 分别登录两台计算机，读取运行内核、设备树、已安装软件和厂家版本清单。
| 核查项 | 感知 / 导航工控机 · Orin NX | 本体运动控制机 · RK3588 | 用途与证据 |
|---|---|---|---|
| 平台与地址 | NVIDIA Jetson Orin NX 16 GB 192.168.234.234 | Firefly AIO-3588SJD4 HDMI 192.168.234.1 | NX 负责感知、导航和录制。RK 负责底盘控制、机体前视和网关。①② |
| 板级标识 | P3767-0000 模块；设备树载板标识 P3768-0000 | rockchip,aio-3588sjd4rockchip,rk3588 | 两块板均由正在运行的系统设备树识别。①② |
| CPU 与架构 | 8 核 Cortex-A78AE · aarch64 | 8 核 Cortex-A76 / Cortex-A55 · aarch64 | 两机均枚举 CPU 0–7。①② |
| 内存 | 16 GB 规格；系统可见 15.29 GiB | 系统可见 7.73 GiB | 可见内存取/proc/meminfo的MemTotal。①② |
| 系统存储 | 256.06 GB NVMe YSNN5M3YT256CNNNN · 固件 SN13406 | 62.55 GB eMMC Y1Y064 · 修订 0x0309000000000000 | 容量为整盘字节数换算的十进制 GB。①② |
| Ubuntu | Ubuntu 22.04.5 LTS | Ubuntu 22.04.5 LTS | 两机均为 Jammy Jellyfish，取自/etc/os-release。①② |
| 运行内核 | 5.15.148-rt-tegra | 5.10.160-rt78-preempt | uname -r；内核模块与驱动需分别匹配。①② |
| 板级软件 | NVIDIA Jetson Linux / L4T R36.4.7 | Firefly / Rockchip 平台；板级镜像发行号未取得 | NX 已确认 L4T 与引导包版本，未取得独立的 JetPack 元包版本。①② |
| ROS 发行版 | ROS 2 Humble | ROS 2 Humble | 安装目录/opt/ros/humble；两台均有 Humble 程序运行。①② |
| ROS 通信 | rmw_zenoh_cpp0.1.8 · Domain 24 | rmw_zenoh_cpp0.1.8 · 路由进程运行 | NX 在 Domain 24 收到本体dog_task发布的机型。①②③ |
| 录包与存储 | rosbag20.15.16 · MCAP 插件 0.15.16 | rosbag20.15.16 · 默认存储插件 | xinghulou01在 NX 侧使用 MCAP；此处列本次在机版本。①② |
| 系统运行库 | Python 3.10.12 · chrony 4.2 | Python 3.10.12 · chrony 4.2 | Python 取系统解释器；chrony 取已安装包。①② |
| GPU 计算库 | CUDA Toolkit 12.6.11 cuDNN 9.3.0.75 | — | NX 安装包版本；CUDA Runtime 为 12.6.68。①② |
| 机型代码 | XGWHSPD | 由dog_task发布 | 高速轮足机型代码来自/robot_type；整机铭牌商品型号未读取。③ |
传感器、部件固件和采集驱动见「设备与固件」。两块板分别部署的运动控制、导航、SLAM 等版本见「厂家与ROS软件」。
二、传感器介绍
1、以数据为例xinghulou01为例 | 机械狗传感器总表
2026-11-02 17:24:25-17:30:33 (北京时间) | 完整录制 367.787 秒 · 6 个原始 MCAP 分片 · ROS 2 Humble / CDR
| 比较项 | 激光雷达 | 雷达内置 IMU | 机体前视相机 | GNSS 接收机 | RealSense D435i（本次未录制） |
|---|---|---|---|---|---|
| 设备与类型 | Livox Mid-360 三维激光雷达 | Mid-360 内置六轴惯性测量单元 三轴陀螺仪 + 三轴加速度计 | 机体前置可见光相机 本次记录单路彩色图像，型号待确认 | 六分 GNSS 定位 / 定向接收机 配套资料型号 LK1220D，实物型号待核 | Intel RealSense D435i 主动红外双目 RGB-D 相机，内置六轴 IMU |
| 测量内容 | 目标在雷达系中的三维位置、回波强度及逐点相对时间 | 三个轴的角速度和线加速度 | 相机视野内的场景纹理及颜色 | 地理位置、地速与航迹方向、天线基线航向和俯仰 | 彩色、左右红外、逐像素深度；自身三轴角速度和加速度 |
| 数据用途 | 估计扫描间运动，构建三维点云地图 | 描述快速转动与振动，本次作为相对时间参考 | 跟踪图像特征，估计相邻帧之间的相机转动 | 给出室外位置与航向约束，并提供 UTC 解算历元 | RGB-D 感知、立体视觉与视觉惯性融合 |
| ROS 2 话题 | /front_lidar | /front_lidar/imu | /front_camera/image_compressed | /rtk_pvh | /d435i/下各图像与 IMU 话题完整名称见「D435i 通道」 |
| ROS 2 消息类型 | sensor_msgs/msg/PointCloud2 | sensor_msgs/msg/Imu | sensor_msgs/msg/CompressedImage | robots_dog_msgs/msg/UniRtkPvh | sensor_msgs/msg/Imagesensor_msgs/msg/CameraInfosensor_msgs/msg/Imu |
| header.frame_id | livox_frame | livox_frame | camera_frame | gps_link | 各光学通道与 IMU 使用独立 frame_id |
| 已知发布节点 | /livox_lidar_publisher | /livox_lidar_publisher | /ecal2ros2（图像桥接） | /sixents_gps_driver | /d435i（realsense2_camera_node） |
| 主要接口 / 数据形态 | 以太网 UDP 输入；ROS 聚合点云 | 同一雷达的 IMU 数据通道；独立 ROS 消息 | JPEG 压缩图像；3,677 张均为 1920 × 1080，解码为 RGB | 历史接口/dev/ttyTHS3，460800 baud；定位、航向合在一个 ROS 消息中 | 实机 USB 2.x / 480 Mbit/s；图像配置为 640 × 480 |
| 名义频率（Hz） | 10 | 200 | 10 | 10 | 10 图像各 15；原始陀螺 / 加速度各 200 |
| 实测平均频率（Hz） | 10.000 | 199.998 | 9.997 | 9.744 | 未录制，无法计算 |
| 实读消息数 | 3,678 | 73,558 | 3,677 | 3,584 | 0 |
| 本次已知限制 | 原始逐点字段名timestamp；物理扫描起点仍为条件判断 | 全段姿态四元数恒为单位四元数；线加速度单位待核 | 曝光事件与底层驱动待核；未建立硬触发证据 | 本段全部位置解为单点定位，定位精度未用外部真值检验 | 本包无 D435i 图像或惯性测量；安装外参与主机时间映射待核 |
| 派生包时间处理 | 使用原时间。+8 ms 候选改善不足 | 使用原时间，作为参考 | 每个图像 header 提前 43 ms，使用派生包时额外时偏设为 0 | 保留原始 header 及两个 UTC 历元 | 无 D435i 校正量；前视 -43 ms 仅用于机体前视相机 |
三、各个传感器的外参标定
轮足机械狗 / 空间标定总表
核查截至 2026-11-04。矩阵行按源系到目标系换算点坐标；杆臂行按 B 到 A 描述测量方向。
按“状态”筛选已有、待验证与待补充项目。5G 天线用于通信，不纳入本表的定位外参。
| 状态 | 空间关系 | 起点或源系 | 终点或目标系 | 现有依据 | 待办及使用条件 | 矩阵编号 | 数据来源 |
|---|---|---|---|---|---|---|---|
| 待补充 | RTK 主天线杆臂 | 机身参考原点 B | 后主天线相位中心 A | gps_link仅为定位消息帧名。CAD 标记是天线的外壳位置。 | 在 B 的前、左、上三轴测出 B 到 A 的分量。用 RTK 做位置精度评估时优先补此项。 | — | 实机坐标系核查 |
| 待补充 | RTK 双天线安装角 | 后主至前从的基线 | 机身前向 | 固定航向解的基线长度中位数约 0.303 m，配置中heading_flag为 1。 | 测两相位中心在机体系中的坐标，求基线方向。核对接收机航向改正值，再用独立方位验证。 | — | 固定航向解记录、FAST-LIO 配置 |
| 候选待验证 | 雷达到当前 D435i | livox_frame | D435i 左目、深度、RGB、右目及本体 | 已有 5 组候选值，共用一个假设：厂家左红外光学系与当前官方左目重合。 | 核对设备、左右目和整流旋转。用同步点云与左目图像验证近远目标，必要时重标一组雷达与 D435i 的安装外参。 | C1-C5 | OTA、D435i 内部 TF、候选外参 |
| 条件性缺项 | 底盘中央 IMU 安装 | 底盘 IMU 物理参考系 | base_link | 尚无可核实的机身安装变换；雷达imu_front与底盘中央 IMU 属不同设备。 | 仅在使用底盘 IMU 数据时，先确认数据源及消息帧，再测安装姿态与原点偏移。 | — | 机体 IMU 配置与实机核查 |
| 厂家明列 | 前置彩色相机到雷达 | camera_frame | livox_frame | OTA 明列camera_front_to_lidar_front。历史点云投影支持该方向。 | 使用新采集的同步帧核验边缘投影，重点看转弯及近距离目标。 | O1 | OTA 标定、四帧投影核查 |
| 厂家明列 | 雷达到雷达内置 IMU | livox_frame | imu_front（标定名称） | OTA 给出单位旋转和三维平移。点云与实时 IMU 消息都标作livox_frame。 | 确认算法读入的坐标系和驱动是否已处理偏移，避免重复应用。 | O2 | OTA 标定、实时消息头 |
| 厂家明列 | 雷达内置 IMU 到机身 | imu_front | base_link | OTA 明列imu_front_to_base。另一定位配置使用与之互逆的矩阵。 | 使用前核对矩阵乘法方向与实际加载项，量取机身原点做安装复核。 | O3 | OTA 标定、定位配置核查 |
| 可计算 | 雷达到机身 | livox_frame | base_link | 由雷达到 IMU、IMU 到机身的两段矩阵组合，可与定位配置比对。 | 继承 O2、O3 的安装核查。 | D1 | O3 × O2 |
| 可计算 | 前置彩色相机到机身 | camera_frame | base_link | 沿相机、雷达、雷达 IMU、机身的坐标链组合。 | 继承 O1-O3 的安装核查。 | D2 | O3 × O2 × O1 |
| 可计算 | 雷达到厂家左红外 | livox_frame | 厂家左红外光学系 | 厂家/rs_ir_left/compressed和/front_lidar都有相对同一标定基准的 R、T。 | 若应用于当前 D435i，须完成 C1-C5 共用的左目对应核验。 | D3 | OTA 中两组逐话题 R、T |
| 内部 TF 已有 | D435i 相机与 IMU 内部 | 各 D435i 子坐标系 | 各自父坐标系 | 历史录包读出 15 条静态 TF。左 IR 与深度重合，左右光心距约 50.054 mm。 | 更换设备或驱动配置后复读 TF。对精度有要求时，另做双目与 RGB-D 对齐验收。 | I01-I15 | 11 月 2 日 xinghulou01 录包/tf_static |
统计单位为上表的空间关系组。一个候选组包含 5 个派生矩阵，一个内部 TF 组包含 15 条记录变换。
| 厂家明列 | 可计算 | 内部 TF 已有 | 候选待验证 | 待补充 | 条件性缺项 |
|---|---|---|---|---|---|
| 3 | 3 | 1 | 1 | 2 | 1 |
TF 是 ROS 中用来表示和查询“两个坐标系之间是什么位置、什么朝向”的机制，名字来自 Transform（坐标变换）。它回答的是：同一个点，换一个坐标系来看，坐标是多少？
拿你机械狗上的 MID-360 举例。假设雷达装在机身原点正前方 20 cm，两者的轴方向完全一致。雷达看到一个点在自己正前方 1 m，那么这个点在雷达坐标系里是 (1.0, 0, 0)，在机身坐标系里就是 (1.2, 0, 0)。如果雷达安装时还有倾角，换算时就要同时考虑旋转和平移。这里的 20 cm 只是举例
四、各个传感器的时间戳问题
xinghulou01的四路header.stamp都采用 Unix 纪元形式。做视觉对齐时，参考轴是雷达自带 IMU 的消息时间。前视相机的 3,677 张图像统一提前 43 ms；雷达、IMU 和 GNSS 保留原时间。四路都能显示成北京时间，但尚未证明它们的物理采样时刻都在同一个 GNSS 硬件时钟上。
💡 科普：什么是 Unix 纪元？
Unix 纪元（Unix Epoch）是计算机系统中用来记录时间的一种通用标准。它定义为协调世界时（UTC）1970 年 1 月 1 日 00:00:00。简单来说，它记录的是“从那个时间点起，到现在一共过去了多少秒”。例如，在 ROS 2 的数据中，时间戳通常以秒（
sec）和纳秒（nanosec）的形式存储，它们本质上都是基于 Unix 纪元的绝对时间。为什么使用它？因为它是一个全球统一的绝对时间，不受地球时区（如东八区）和夏令时的影响，非常方便计算机在不同设备、不同传感器之间进行精确的时间对齐和运算。我们在表格中看到的“北京时间”，只是用代码在这个绝对时间戳上统一加上 8 小时转换显示出来的结果，其底层存储的依然是绝对数值。
| 传感器 | 原包header.stamp | 视觉对齐后header.stamp | NX 记录时间log_time |
|---|---|---|---|
| Mid-360 雷达 | 17:24:25.665687417 | 17:24:25.665687417 | 17:24:25.770388203 |
| 雷达自带 IMU | 17:24:25.728059013 | 17:24:25.728059013 | 17:24:25.730681641 |
| 前视相机 | 17:24:25.722000000 | 17:24:25.679000000 | 17:24:25.739604912 |
| GNSS | 17:24:25.764000000 | 17:24:25.764000000 | 17:24:25.817918552 |
💡 延伸探讨：多传感器时间对齐到底在做什么？
很多人在处理多传感器数据时会产生疑问：为什么只对齐相机的？其他的不需要对齐吗？对齐是指所有传感器都在同一瞬间采集吗？
答案是：不需要让四个传感器在同一物理瞬间采集。我们真正需要的是，当机械狗在快速转弯时，能够准确找到“这张图像曝光的前后”以及“这帧雷达扫描期间”，IMU 和 GNSS 分别测到了什么。
要做到这一点，必须区分两个概念：时间校正与时间关联。
- 时间校正（Time Correction）：解决的是“这条测量应该放在时间轴的哪里”。
- 例如：前视相机第一张图的原始时间是
17:24:25.722。根据相机与 IMU 观察到的转动，整段图像提前 43 ms 后，两者的运动特征对应得更好。因此，这张图按17:24:25.679与 IMU 关联。这 43 ms 是运动验证得到的相对校正量，其实际物理曝光时刻仍未独立测定。
- 例如：前视相机第一张图的原始时间是
- 时间关联（Time Association）：解决的是“这个时刻前后有哪些观测”。
- 例如：一帧雷达扫描持续约 100 ms，而 IMU 大约每 5 ms 采一次。我们需要取的是实际扫描起止窗口内的全部 IMU 样本，再加上两端的相邻样本。这些样本本来就应该有不同的时间戳。
因此，四路传感器都需要进行检查和关联，只是本次只有相机有足够证据去修改时间戳。
各传感器在xinghulou01数据中的处理逻辑
| 传感器 | xinghulou01目前怎么处理 | 为什么这么做 |
|---|---|---|
| 雷达自带 IMU | 选作相对时间参考轴 | 其他传感器的运动相对它来比较。选它作参考，并不代表它已经对准了绝对的 UTC 时间。 |
| 前视相机 | 每张图的时间戳减 43 ms | 在独立留出的 488 个运动区间中，相机与 IMU 的角速度相关系数由0.927提高到了0.993，强有力地支持了这项校正。 |
| Mid-360 雷达 | 保留扫描时间和逐点相对时间，按实际扫描窗口关联 IMU | 已确认雷达和 IMU 来自同一台 Livox，但本次数据未验证出一个稳定、值得写入的雷达偏移量。保留原值不等于证明偏移为零。 |
| GNSS | 保留接收机解算时间，按原值参与包内关联 | 转弯数据支持 GNSS 与 IMU 按原值对应；如果单独给 GNSS 加减 18 秒，会导致明显错开。但它相对外部真实 UTC 的绝对误差仍未验明。 |
📝 结论表述：
就这份数据而言，准确的表述是：以雷达 IMU 为参考，已校正前视相机的相对运动时延；雷达和 GNSS 沿用原时间做工程关联。
四路数据可以联合使用，但并未验收到“四个传感器在同一物理时钟上达到毫秒级同步”的绝对状态。
