MCAP

MCAP – definition

MCAP is an open container-file format for recording, storing, indexing, and replaying timestamped messages from robotic systems. In mobile robotics, it is commonly used as a rosbag2 storage format for data collected from ROS 2 topics. An MCAP file can contain LiDAR scans, IMU samples, camera images, odometry, transforms, GNSS fixes, diagnostics, and command messages in one time-indexed recording.

The format is designed for efficient sequential writing during data capture and indexed access during later analysis. It stores message payloads together with channel definitions, schemas, timestamps, metadata, attachments, and optional summary indexes. MCAP is a file format, not a middleware protocol. It does not replace DDS, ROS 2 topics, QoS policies, or the ROS 2 graph.

For a UGV, MCAP provides a reproducible record of what the robot observed, estimated, and commanded during a mission. This is useful when validating SLAM, navigation, sensor synchronization, localization, perception, or drivetrain behaviour on Leo Rover and Raph Rover.

MCAP structure and time model

An MCAP file starts with a magic sequence and a header record, followed by data records representing schemas, channels, messages, chunks, indexes, and other records. It can also contain an optional summary section and a footer, and ends with a magic sequence. The specification defines records in a binary format and uses unsigned 64-bit nanosecond timestamps for recorded messages.

Each message record contains two timestamps. Their distinction is important when analysing sensor latency or replaying a ROS 2 dataset.

Log time – the timestamp assigned when the recorder logs a message. This is normally the primary ordering timestamp in a bag.
Publish time – the timestamp associated with message publication. If the publication time is unavailable, it may be set to the log time.
Channel – identifies a stream of messages, including its topic name, message encoding, schema reference, and metadata.
Schema – describes the message type definition. In ROS 2 recordings, this can use the ros2msg schema encoding.
Message payload – contains serialized message bytes. ROS 2 messages are typically stored with the cdr message encoding.

MCAP may divide a recording into chunks. Chunks can be compressed and indexed, allowing readers to seek to a time range or topic without decoding the complete file. The MCAP specification defines lz4 and zstd compression identifiers. Compression is optional and must be selected with regard to available CPU resources and storage throughput.

Source: MCAP Specification; MCAP ROS 2 Guide.

MCAP in ROS 2 and rosbag2

In ROS 2, recording and playback are usually performed through rosbag2. Rosbag2 separates its command-line interface, transport layer, converter layer, and storage plugins. The MCAP storage plugin enables rosbag2 to write bag data to files with the .mcap extension.

When the MCAP storage plugin is installed, a selected set of ROS 2 topics can be recorded with the following command.

ros2 bag record -s mcap \
  /scan \
  /imu/data \
  /odom \
  /tf \
  /tf_static \
  /camera/depth/image_rect_raw

The resulting bag should be accompanied by its rosbag2 metadata file. The metadata describes the storage identifier, recorded topics, message counts, duration, and serialization format. Engineers should retain both the MCAP file and metadata when moving recordings between development machines or CI pipelines.

Playback can use simulated ROS time. Nodes that must follow bag time should be configured with use_sim_time:=true and must receive the /clock topic generated during playback.

ros2 bag play <bag_directory> --clock

ROS 2 support depends on the installed rosbag2 packages and distribution. The exact plugin version, available compression options, and conversion behaviour should be verified in the documentation for the deployed ROS 2 distribution, such as Humble, Iron, Jazzy, or newer releases.

Source: ROS 2 documentation: Recording and playing back data; rosbag2_storage_mcap repository documentation.

MCAP datasets for Leo Rover and Raph Rover

Leo Rover runs ROS 2 natively on its integrated Raspberry Pi compute unit. Its differential-drive kinematics require consistent recording of wheel odometry, IMU data, transform frames, and velocity commands when diagnosing navigation behaviour. A typical recording should include both estimated robot motion and the raw sensor inputs used by the estimator.

For an autonomous Leo Rover experiment, useful topics commonly include the following.

/scan – sensor_msgs/msg/LaserScan data used by 2D SLAM or obstacle detection.
/imu/data – sensor_msgs/msg/Imu measurements for orientation and acceleration estimation.
/odom – nav_msgs/msg/Odometry from wheel encoders or a fused state estimator.
/tf and /tf_static – frame transforms required to reconstruct sensor poses during replay.
/cmd_vel – commanded linear and angular velocity, useful for comparing command input with observed motion.

Raph Rover can carry larger sensor payloads and may produce substantially larger datasets, especially with multiple cameras, 3D LiDAR, or RTK GNSS receivers. In such systems, storage write speed must be tested under realistic topic rates before field deployment. Dropped messages, timestamp discontinuities, and missing transforms can invalidate later SLAM or sensor-fusion analysis.

MCAP does not make Leo Rover or Raph Rover autonomous by itself. It records the ROS 2 data needed to develop, reproduce, and evaluate an autonomy stack such as Nav2, robot_localization, SLAM Toolbox, or a custom perception pipeline.

Operational limitations and validation

MCAP preserves serialized data, but data quality still depends on the ROS 2 system that produced it. A valid file can contain incorrect frame IDs, inconsistent timestamps, unsuitable QoS settings, or incomplete topic coverage. Recording configuration must therefore be treated as part of the experimental method.

Before using an MCAP bag as a benchmark dataset, verify the following conditions.

All required coordinate frames are available through /tf and /tf_static.
Sensor clocks and host clock are synchronized or their offsets are documented.
Topic types and serialization formats can be resolved on the playback system.
Recorded QoS compatibility is checked for playback subscribers.
Storage throughput is sufficient for the expected aggregate message bandwidth.

Source: ROS 2 Quality of Service settings; MCAP Specification.