Skip to main content
Your middleware is eating 18% of your frame budget. At 30 Hz, your camera driver has 33 ms per frame. ROS2’s default transport burns 6 ms just moving a camera image from one node to another. That’s 18% of your frame budget gone — before your perception, planning, or control code even runs.
33ms frame budget comparison — ROS2 uses 6ms on transport overhead vs Cerulion's ~60ns
Cerulion runs your existing ROS code faster. No rewrite. Cerulion is a modern robot runtime — not just a transport layer. It runs your ROS2 node code directly in Cerulion’s backend, giving you sub-microsecond latency, zero-copy logging, and deterministic execution without changing a line of code.
Why Cerulion

​
How Cerulion Compares

How Cerulion compares across 14 dimensions:
DimensionROS2Cerulion
⚡ LatencySeveral ms, scales with payload~60 ns, payload-agnostic
🧠 Shared memoryAvailable but not default; expert config requiredDefault, zero-copy, no config — just works
📐 Variable-size messagesCannot do zero-copy SHM for unsized arraysZero-copy SHM even for variable-size messages
🔄 SerializationAlways serializes — even for SHM, even without subscribersOnly serializes for network transport, only if subscriber exists
📦 Wire formatHeap-allocated, fragmentedContiguous, zero-copy friendly
✂️ Lines of codeMassive boilerplateFraction of the code
🌐 TransportEntire stack locked to one transportPer-topic transport selection
🎯 DeterminismNon-deterministicDeterministic runtime
📝 LoggingBag recording slows the stackZero-copy logging — no performance impact
🔨 Build systemcolcon/amentCargo-based
⏱️ SchedulerLimited triggersTrigger topics, wait sets, synced topics, external triggers
🧮 Smart serializationAlways serializes per topicOnly serializes if ≥1 network subscriber
🦀 BackendC++Rust (memory safety, no undefined behavior)
🔗 Your ROS2 codeStays in ROS2Runs faster in Cerulion — no changes needed
We’re running reproducible benchmarks now. Want early access to the numbers? Schedule a 15-min call

​
The Case for Switching

thumbs-first

100x Faster

Sub-microsecond shared memory transport. ~60 ns, not 6 ms.
relaxing

0 Lines Changed

Your ROS2 nodes run directly in Cerulion’s runtime.
boxes

0% Overhead

Zero-copy logging that never slows your robot.

​
Bridge vs Cerulion

Bridge approach adds overhead between ROS2 and other systems — Cerulion runs your ROS code directly with zero-copy transport
Bridge approaches run your code in ROS2’s runtime, then copy data across a bridge into another system — two runtimes, bridge overhead, lowest-common-denominator performance. Cerulion runs your ROS node code directly in its own runtime. Same API, faster backend.

​
Code Comparison

The same pub/sub pattern — publishing an image from a camera node. Compare what it takes in ROS2 vs Cerulion. 
use cerulion_core_v2::prelude::*;

#[node(period_ms = 100)]
pub fn camera_pub() -> (#[out("image")] Image) {
    let mut img = Image::new();
    img.set_height(480);
    img.set_width(640);
    img.set_encoding("rgb8");
    img.set_data(&capture_pixels());

    (img)
    // Zero-copy for local subscribers
    // Only serializes if a network subscriber exists
}
ROS2 requires a class hierarchy, explicit QoS configuration, timer binding, manual lifecycle management, and a main() function. Cerulion requires a function with an attribute macro. Both publish the same sensor_msgs/Image. But Cerulion’s version uses zero-copy shared memory for local subscribers and only serializes if a network subscriber exists. ROS2 serializes on every publish, regardless.
Coming Soon Python SDK and C++ SDK are in development.

​
Backwards Compatibility

Cerulion doesn’t ask you to rewrite your ROS2 nodes. It runs them faster.
  • Standard message types — sensor_msgs/Image, geometry_msgs/Twist, sensor_msgs/PointCloud2, and sensor_msgs/LaserScan all work with zero-copy shared memory. No type changes needed.
  • Free upgrades — Existing nodes automatically get Cerulion’s transport, serialization, scheduling, and zero-copy logging. No code changes required.
  • Incremental migration — Start by running your ROS nodes in Cerulion, then gradually adopt native APIs where it matters. No big-bang rewrite.
  • Rust backend safety — Memory safety (no segfaults from middleware bugs), no undefined behavior, and fearless concurrency. Your middleware shouldn’t be a source of production crashes. Learn more about the Rust backend.
Your existing ROS2 pub/sub patterns work out of the box. Standard message types like Image, Twist, PointCloud2, and LaserScan are all supported.

​
ROS2 Pain Points

Cerulion is built to eliminate the seven frustrations ROS2 teams run into every day:

Expert-only efficiency

To use ROS2 efficiently, you need deep knowledge of shared memory configuration, transport tuning, and camera synchronization. It’s a secret society of documentation. You shouldn’t need to be a middleware expert to build robots — it should just work, like how Python dictionaries just work without you understanding hash tables.
At 30 Hz, you have 33 ms per frame. ROS2’s default transport burns 6 ms moving a camera image between nodes. That’s 20% of your frame budget gone before your application code runs.
ROS2 always serializes, whether or not there’s a subscriber. CPU cycles wasted on every publish, every topic, even when data stays on the same machine.
Bag recording slows the stack, so your robot behaves differently when you’re logging. The failure you’re trying to debug isn’t the behavior you recorded.
You can’t replay logs and get the same behavior. For self-driving and safety-critical applications, this is disqualifying.
You can’t use TCP for reliable inter-robot communication and UDP for fast visualization on the same system. One transport for everything.
ROS2 can’t do zero-copy shared memory for messages with unsized arrays (like images). You either accept the copy overhead or force vendors to specify exact pixel counts.