Skip to main content

MCAP Logging

Cerulion Core supports MCAP (Modular Container Format) logging, similar to ROS2 bag recording. MCAP logging lets you record messages for later playback, analysis, or debugging.

What is MCAP Logging?

MCAP is a container format for storing timestamped message data. It’s similar to ROS2 bag files but with better performance and cross-language support.
MCAP logging is opt-in. You choose which publishers or subscribers should log their messages. This gives you fine-grained control over what gets recorded.

Key Features

Automatic Schema Registration

Schemas are automatically registered when channels are created

Thread-Safe

Uses background thread for async writes to avoid blocking

Compression Support

Optional LZ4 or Zstandard compression

Timestamp Preservation

Messages are logged with nanosecond-precision timestamps

When to Use MCAP Logging

MCAP logging is useful for:
  • Debugging: Record messages to analyze issues after they occur
  • Testing: Capture test data for validation and regression testing
  • Analysis: Collect sensor data for offline analysis
  • Playback: Replay recorded messages to reproduce scenarios
  • Archival: Store important message data for compliance or auditing

Opt-in Design Philosophy

Unlike some robotics frameworks that record everything by default, Cerulion Core uses an opt-in approach:
  • Selective Recording: Enable logging only on specific publishers or subscribers
  • Performance First: No overhead for pub/sub operations that don’t need logging
  • Fine-Grained Control: Different recorders for different topics or recording sessions
  • Shared Recorders: Multiple publishers/subscribers can write to the same MCAP file
The opt-in design ensures that logging doesn’t impact performance of real-time systems. You pay for logging overhead only where you explicitly enable it.

How It Works

When you enable MCAP logging on a publisher or subscriber:
  1. Messages are sent/received normally (no blocking)
  2. MCAP logger receives a copy of the message
  3. Background thread serializes and writes to file
  4. File is automatically closed when recorder is dropped

Next Steps