Skip to main content
Your robot behaves differently when you record it. Every production failure is unreproducible — because the act of recording changed the behavior that led to the failure. This is the logging trap, and it affects every team running ROS2 in production.
The fundamental problem: If recording changes your robot’s timing, then your logs don’t represent what actually happened. Debugging from those logs is debugging a different system.

​
Why Recording Slows Your Robot

ROS2 bag recording inserts itself into the data path. Every message that gets recorded must be serialized, copied to a buffer, and written to disk. This adds CPU load, memory pressure, and timing jitter to the entire stack. ROS2 recording adds serialization and copy overhead to every message. Cerulion writes directly from shared memory — the publisher never knows recording is happening. The consequences compound:
  • CPU contention — Serialization competes with your perception and planning pipelines
  • Timing changes — Added latency shifts when nodes execute, changing the order of operations
  • Memory pressure — Buffer allocations trigger garbage collection and page faults
  • Debug ≠ production — The system you’re recording is not the system that failed

​
How Zero-Copy Logging Works

Cerulion’s logging reads directly from shared memory. No serialization. No copies. No CPU impact on the publishing node.

Direct shared memory access

Messages already exist in shared memory for pub/sub transport. The logger reads from the same memory region — it doesn’t ask the publisher to do anything extra. The publisher’s timing is completely unchanged.
ROS2 bag recording requires serializing every message before writing it. Cerulion’s wire format is already in shared memory — the logger writes the raw bytes directly to disk. Zero CPU overhead on the data path.
Because logging doesn’t perturb the system, timestamps in the log accurately reflect when events actually occurred. There’s no jitter introduced by the recording process itself.
Disk I/O happens on a dedicated background thread with its own CPU affinity. Even disk latency spikes don’t affect your real-time nodes.

​
What This Means for Safety

For self-driving vehicles, surgical robots, and any safety-critical application, two capabilities are non-negotiable:
  1. Faithful recording — The log must represent exactly what happened, with correct timing
  2. Deterministic replay — Playing back the log must reproduce the same behavior
Zero-copy logging makes both possible. Because recording doesn’t change behavior, and because Cerulion’s runtime is deterministic, you can replay a production log and get the same execution — the same node ordering, the same timing, the same outputs. This is the foundation of trustworthy log resim.
When your autonomous vehicle makes an unexpected decision in the field, you need to understand exactly what happened. Not what would have happened if you’d been recording. Not an approximation. The exact sequence of events, faithfully captured with no observer effect.

​
Next Steps

Why Cerulion

Full comparison with ROS2 across 14 dimensions

Determinism

How Cerulion achieves deterministic execution

Quickstart

Build your first pipeline or migrate from ROS2

Architecture

System architecture and component design