第1章 MCAP 概述2020│ ├── Foxy ← LTS │2021│ ├── Galactic │2022│ ├── Humble ← LTS │2023│ ├── Iron ← rosbag2 默认开始使用 MCAP │2024│ ├── Jazzy ← LTS │2025│ ├── Kilted │2026│ └── Lyrical ← LTS1.1 MCAP 的基本定义MCAP（MCAP File Format）是一种面向机器人、自动驾驶、传感器系统以及发布/订阅系统（Publish/Subscribe Systems）的高性能日志容器格式。MCAP 的主要用途，是把来自不同数据源、不同 Topic、不同时间戳不同序列化格式的消息统一记录到一个.mcap文件中，并在此基础上提供压缩、索引、随机访问、元数据管理和附件存储等能力。从使用方式上看，可以将 MCAP 理解为一种更加通用、现代化的机器人数据日志格式。对于熟悉 ROS 的开发者来说，它在很多场景中承担着类似 ROS Bag 的角色，但其设计目标并不局限于 ROS，而是面向更加广泛的 ** 时间序列消息（Timestamped Messages）** 和 ** 发布/订阅数据（Publish/Subscribe Data）**。从系统设计角度看，MCAP 可以概括为：** MCAP（MCAP File Format）** = 多通道时间序列消息 + Schema + Channel + Chunk + Compression + Index + Attachment + Metadata。它的几个核心设计目标是：** 自描述（Self-describing）**；** 高效写入（Efficient Writing）**；** 高效压缩（Efficient Compression）**；** 快速随机访问（Fast Random Access）**；** 序列化无关（Serialization-agnostic）**。1.2 MCAP 主要解决的问题机器人和自动驾驶系统通常会同时产生大量异构数据，例如：相机图像；LiDAR 点云；IMU 数据；GPS 数据；CAN 总线数据；车辆状态；控制指令；规划轨迹；感知结果；调试日志；ROS Topic 消息。这些数据通常具有以下特点：数据类型不同；发布频率不同；序列化方式不同；时间戳来源不同；数据吞吐量差异巨大；单次记录产生的数据规模可能达到数十 GB、数百 GB，甚至 TB 级。例如，一个自动驾驶数据采集系统可能具有如下数据流：/camera/front/image ─┐ /camera/rear/image ─┤ /lidar/points ─┤ /imu/data ─┤ /gps/fix ─┼── drive_001.mcap /vehicle/status ─┤ /planning/path ─┤ /control/cmd ─┘MCAP 的作用，就是将这些来自不同数据源的消息按照统一文件结构保存下来，同时保留消息所属的 Topic、数据结构、时间戳以及相关元信息。1.3 MCAP 与普通日志文件的区别普通日志文件通常面向文本信息，例如：2026-08-27 10:21:03 vehicle speed = 72 km/h而机器人数据往往包含：图像 点云 二进制传感器数据 结构化消息 高频时间序列 模型输出 控制数据因此，只使用普通文本日志无法高效保存这些数据。MCAP 本质上不是简单的“日志文本格式”，而是一个 ** 二进制容器格式（Binary Container Format）**。它不仅保存消息本身，还可以保存：消息数据 + 消息结构 + Topic 信息 + 时间信息 + 压缩数据块 + 索引 + 附件 + 元数据因此，MCAP 更接近于一个专门针对大规模时序消息设计的数据容器。第2章 MCAP 的核心数据模型2.1 Schema：描述消息结构** 模式（Schema）** 用来描述消息的数据结构。例如，一条 IMU 消息可能具有：timestamp orientation angular_velocity linear_acceleration而一条车辆状态消息可能具有：timestamp speed steering_angle gear brake accelerator如果一个文件只保存原始二进制数据，而没有保存数据结构，那么未来读取文件时就必须额外寻找对应的消息定义。MCAP 可以将 Schema 直接写入文件，因此.mcap文件可以具有较强的 ** 自描述能力（Self-describing Capability）**。可以简单理解为：MCAP ├── Schema ├── Channel └── Message Data其中：Schema ↓ 描述消息应该如何解释 Message Data ↓ 保存真正的二进制数据例如，在 ROS 2 场景中，可以使用 ROS 消息定义描述 Schema，同时采用 CDR 作为消息编码。MCAP 本身并不强制使用某一种固定消息定义体系，因此可以承载不同类型的数据，例如：ROS 1；ROS 2；Protobuf；JSON；FlatBuffers；CDR；其他自定义序列化格式。这也是 MCAP 被称为 ** 序列化无关容器（Serialization-agnostic Container）** 的原因之一。2.2 Channel：描述消息来源** 通道（Channel）** 可以粗略理解为 ROS 中的 ** 话题（Topic）**。例如：/camera/front/image /lidar/points /imu/data /vehicle/speed一个 Channel 通常包含以下信息：Channel ├── channel_id ├── schema_id ├── topic ├── message_encoding └── metadata例如：channel_id = 3 schema_id = 2 topic = "/imu/data" message_encoding = "cdr"其中，schema_id用于指出该 Channel 使用哪个 Schema。于是可以形成如下引用关系：Schema 2 ↑ │ Channel 3 topic = /imu/data后续每条消息不需要反复保存完整的/imu/data字符串，只需要记录：channel_id = 3即可确定消息属于哪个 Topic。这种设计能够减少大量重复信息。2.3 Message：真正的数据记录** 消息（Message）** 是 MCAP 中真正承载业务数据的记录。一条 Message 主要包含：Message ├── channel_id ├── sequence ├── log_time ├── publish_time └── data其中：2.3.1 channel_id用于确定该消息属于哪个 Channel。例如：channel_id = 3可以对应：/imu/data2.3.2 sequence** 序列号（Sequence Number）** 用于表示消息的顺序信息。在一些系统中，它可以帮助判断：消息是否丢失；消息是否重复；消息顺序是否异常。2.3.3 log_time** 记录时间（Log Time）** 表示消息被日志系统记录下来的时间。例如：Sensor ↓ Middleware ↓ Recorder ↓ log_time