Skip to main content
ROS2 locks your entire stack to one transport. Cerulion selects the fastest available path automatically. You can’t tell ROS2 “use TCP for loop closure frames between robots but UDP for point cloud visualization.” Every topic gets the same transport, regardless of whether the data needs reliability or speed. Cerulion selects automatically — shared memory locally, Zenoh over the network — with per-topic TCP/UDP overrides planned for future releases. Automatic for the common case. Per-topic overrides coming soon.

​
Local Transport — iceoryx2

Ultra-low latency communication between processes on the same machine.
PropertyValue
⚡ Latency< 1 μs (~60 ns typical)
📦 SerializationNone — raw bytes in shared memory
🧠 MechanismPublisher writes to shared memory, subscriber reads from the same location
📐 RangeSame machine only
🔄 ThroughputLimited by memory bandwidth, not CPU
// Zero-copy publish — no serialization, no copies
#[node(period_ms = 33)]
pub fn camera() -> (#[out("frame")] Image) {
    // This Image lands in shared memory
    // Local subscribers read it directly — ~60 ns
    (capture_frame())
}
The zero-copy design means that for local communication, Cerulion is essentially a shared memory allocator. There’s no serialization overhead — a 6 MB camera image has the same transport cost as a 24-byte pose message.

​
Network Transport — Zenoh

Reliable communication across machines and networks.
PropertyValue
⚡ Latency1–10 ms (network dependent)
📦 SerializationAutomatic (raw bytes for Copy types)
🧠 MechanismBackground thread serializes and sends via Zenoh
📐 RangeAny machine on the network
🔄 SemanticsLatest-message — stale data is replaced, not queued
// Network subscribers get the same data — automatically
// The publisher doesn't know or care who's local vs remote
#[node(trigger = "frame")]
pub fn detector(frame: &Image) -> (#[out("detections")] DetectionList) {
    // If this node runs on a different machine,
    // Cerulion automatically serializes and sends over Zenoh
    (run_detection(frame))
}
Network publishing happens asynchronously on a background thread. Local publishing never blocks waiting for network I/O — even if the network is congested, local subscribers see data in nanoseconds.

​
Transport Comparison

DimensionLocal (iceoryx2)Network (Zenoh)
⚡ Latency< 1 μs1–10 ms
📦 SerializationNoneAutomatic
🔒 BlockingMinimal (memory alloc)Non-blocking (background thread)
📐 RangeSame machineAny machine on network
🔄 SemanticsImmediateLatest-message
🎯 Best forHigh-frequency sensors, real-time controlDistributed systems, cross-machine communication

​
Automatic Selection

Cerulion selects the transport for each topic automatically:
  1. Publisher starts local-only — writes to shared memory, no network overhead
  2. Remote subscriber appears — TopicManager enables network publishing for that topic
  3. Remote subscriber disconnects — TopicManager disables network, stops serializing
You never configure this. The system discovers subscribers and adapts in real time.
Like how your phone switches between Wi-Fi and cellular without you choosing — Cerulion routes each topic through the fastest available path.

​
Per-Topic Overrides

Coming Soon For structured environments where you know the network topology, you will be able to override transport per topic: 
# Graph configuration with explicit transport (coming soon)
nodes:
  - id: camera
    type: camera_node
    transport:
      type: tcp
      endpoint: "192.168.1.10:5000"

When to use TCP (coming soon)

Reliable streaming — video feeds between robots, loop closure frames, map updates. TCP handles ordering, retransmission, and flow control natively. No chunking overhead for large payloads.
Low-latency small messages — control commands, heartbeats, status updates. UDP avoids TCP’s connection overhead and head-of-line blocking. Best for payloads under ~1 KB.
Most of the time — and always in the current release. Automatic selection handles the common case correctly: shared memory for local, Zenoh for network. Per-topic TCP/UDP overrides are coming soon.
UDP chunking adds significant overhead for large payloads — a 1 MB frame split into UDP packets requires reassembly logic, timeout handling, and duplicate detection that TCP handles natively. When per-topic overrides ship, prefer TCP for video and LiDAR streams.
Ready to try Cerulion? Start with the quickstart and have a working camera-to-display pipeline in 5 minutes — or schedule a 15-min call with the team.