OmniEgo 帧对齐完全指南:30Hz 主时间线如何同步5路摄像头、骨架与头显状态

• 数据集
• 具身智能
• 计算机视觉
• 人工智能

OmniEgo(即 DOHC 头戴式多相机人体动作数据集)采用一条30Hz 主时间线,将 5 路摄像头、全身骨架与头显状态对齐到统一的"主帧"上。本文面向新手,用最少代码讲清 OmniEgo 帧对齐原理:为什么需要主时间线、master_frame_indices如何把不同帧率的图像"挂"到主帧、骨架与头显状态为什么天然对齐,以及新手最容易踩的帧同步坑。

为什么 OmniEgo 需要一条 30Hz 主时间线

OmniEgo 每条录制同时采集5 路相机 + 全身骨架 + 头显运动状态。关键在于:各路数据的采样率并不相同。

💡 如果"按序号直接配对"各数据流:第 1 帧骨架配第 1 帧cam1图像——这是错的,因为cam1只有 15 FPS,它的第 1 帧其实对应主时间线上靠后的时刻。

所以 OmniEgo 在导出时建立了一条30 Hz 主时间线(master timeline),所有数据围绕它组织。这套设计的细节可参考 README.md 的Frame Alignment小节。

主时间线:frame_index 与归一化时间戳

理解帧对齐,先记住两个核心字段:

1. frame_index/frame_id(主帧序号)主时间线上的每一帧都有唯一序号。/dohc/state(头显状态)和/dohc/skeleton(骨架)消息都直接携带主帧序号——它们与主时间线一一对应。

2. 归一化时间戳(timestamps_ns)元数据/dohc/metadata声明timestamp_clock = DELTA_NORMALIZED_TIMELINE,即所有时间戳都是归一化录制时间,不是真实墙钟时间。每个相机流都附带自己的timestamps_ns(本流时间戳)和master_frame_indices(本流每帧对应的主帧序号),这两组数组就是"相机帧 ↔ 主帧"的映射表。

一句话总结对齐关系:

master frame f: state[f] <-> skeleton[f] <-> Parquet row[f] -> metadata.times.<stream>.master_frame_indices 把相机样本映射到 f -> cam0 / cam1 / cam2 / loca_left / loca_right 在 f 处可用时才有图像 -> 用各流自己的时间戳;等长数组下标不是合法关联方式

⚠️ 录制会先按人工审核的"保留区间"裁剪再导出(crop_mode: retained_union)。不要用相邻帧序号推断跨剪切的连续性,剪接点两侧帧号虽连续但时刻不连续。

5路摄像头如何锚定到主时间线

每条录制的权威映射记录在 manifest.jsonl 中(约 7000+ 行,一行一条 MCAP/Parquet 配对记录)。挑出与帧对齐最相关的字段:

打开任意一条记录可以看到典型的image_counts,例如cam0: 510, cam1: 254, cam2: 254, loca_left: 510, loca_right: 510——30 FPS 的流图数约等于主帧数,15 FPS 的流恰好约为一半。这正是"每 2 个主帧才有 1 张广角图"的直接体现。

两种文件格式中,映射信息的存放位置略有不同:

• MCAP:图像消息保留本流时间戳,并把主帧序号作为消息 sequence。某主帧若该流没有样本,就不写图像消息——所以图像 topic 上的消息数天然少于主帧数。
• Parquet:data/ 下每行对应一个主帧,图像列是带bytes与path字段的 struct(字节内嵌,path为 null)。主帧处若某流缺图,则图像为 null 且has_<stream> = false。关联字段是available_images、has_<stream>、<stream>_frame_index与<stream>_timestamp_ns。

🔍 快速核对示例:一条 17 秒的 dish-washer 录制有 510 个主帧(510 ÷ 30 ≈ 17s),cam1恰好 254 张(254 ÷ 15 ≈ 16.9s),与标称帧率完全吻合。

骨架与头显状态:天然对齐的一对

这两路数据不需要"映射",因为它们本身就按主时间线逐帧产生:

• /dohc/skeleton:SMPL 风格24 关节全身骨架,每条消息含smpl_joints等命名数组(shape+dtype+data),单帧形状(24, 3),整段录制为(frame_num, 24, 3),按主帧序号与时间戳对齐。另有/dohc/skeleton/scene以 ProtobufSceneUpdate在 Foxglove 中按帧时间戳可视化 24 关节 23 骨。
• /dohc/state:头显状态,顶层含translation(3,)、rotation(4,)、velocity(3,)、angular_velocity(3,)、acceleration(3,),同样逐主帧输出。

因此做"视频 ↔ 骨架 ↔ 头显轨迹"同步分析时,只需:

1. 读 Parquet 第f行(或主帧f的 state/skeleton 消息)拿到骨架与位姿;
2. 查/dohc/metadata中times.<stream>.master_frame_indices,确认各相机在该主帧是否有样本;
3. 有则取图,无则跳过该流(检查has_<stream>)。

📌 注意:状态字段的坐标约定以消息内pose.position_reference、pose.orientation_representation为准(已检录制使用init_pose参考与[qx, qy, qz, qw]四元数),不能默认是绝对世界坐标。详见 README.md 的/dohc/state小节。

帧对齐避坑清单(新手必读)

• 🚫不要用"数组下标对齐"跨流关联。只有master_frame_indices与timestamps_ns是合法的关联键;各路流长度不同,下标相等毫无时间意义。
• 🚫不要假设每个主帧都有 5 张图。cam1/cam2只有约一半主帧有图,缺图时 Parquet 中图像列为 null、has_<stream> = false。
• 🚫不要把时间戳当真实日期。DELTA_NORMALIZED_TIMELINE是归一化时间线,只能用于相对时序比较。
• ⚠️跨越剪接点要停一下。source_ranges记录了保留区间,剪接点两侧主帧号连续但时刻不连续,连续性分析必须用时间戳差值验证。
• ✅逐录制读取标称帧率。times.<stream>.nominal_source_fps以每条录制自己的元数据为准,而非全局假设。

如何验证对齐结果:Foxglove 可视化与校验文件

OmniEgo 附带了一套完整的转换校验产物,方便你验证帧对齐的正确性:

• foxglove/VALIDATION.md:552 条早期转换录制的验证报告,含状态帧数、各 topic 图像消息数(如/dohc/cam1/jpeg66,477 条,约为cam0133,246 条的一半)与校验方法(chunk CRC、JPEG 全解码、24 关节 23 骨拓扑检查)。
• foxglove/SHA256SUMS:全部输出文件哈希,用于完整性核对。
• foxglove/foxglove-layout.json:现成的 Foxglove Studio 布局,加载后可在五个图像画布 + 骨架画布上直观检查"同一时刻多路画面与骨架是否一致"。
• manifest.jsonl:每条记录的foxglove_validation与validated字段,确认该录制已通过校验。

总结:一张图理解 OmniEgo 帧对齐

记住核心口诀:主时间线是"脊椎",相机是"挂在脊椎上的侧枝"——用master_frame_indices找挂点,用timestamps_ns校时间,用has_<stream>防缺图。掌握这三点,OmniEgo 的 270 多万帧多模态数据就再也不会"对不齐"了。

• 数据集
• 具身智能
• 计算机视觉
• 人工智能