High Bandwidth Optimization

A 1080p camera frame is ~6 MB. Traditional middleware serializes it on every publish. At 30 Hz, that’s 180 MB/s of serialization overhead — per topic. Latency scales linearly with payload size, eating into your frame budget at exactly the moment you need it most. Cerulion’s zero-copy transport is payload-agnostic: a 6 MB image has the same transport overhead as a 24-byte pose message, because neither gets serialized or copied for local subscribers. Payload size doesn’t affect local latency. Period.

Stream Presets

Coming Soon Instead of tuning 30 QoS parameters, Cerulion will provide presets that match real robotics workloads:

Live Video Streams

Optimized for: Camera feeds, compressed video, visual SLAM

Setting	Value	Why
History	Latest-only	Stale frames are useless
Latency	Bounded	Fixed max delay, then drop
Reliability	Lossy OK	Missing frame beats frozen stream

#[node(period_ms = 33, preset = "live_video")]
pub fn camera() -> (#[out("frame")] Image) {
    // 30 FPS camera feed
    // Preset handles QoS — latest-only, bounded latency, lossy OK
    (capture_frame())
}

Live LiDAR Streams

Optimized for: Point clouds, laser scans, depth sensors

Setting	Value	Why
History	Latest-only	Old scans create phantom obstacles
Redundancy	Optional	Critical safety data can be sent twice
Latency	Bounded	Stale data is dangerous

#[node(period_ms = 100, preset = "live_lidar")]
pub fn lidar() -> (#[out("scan")] PointCloud2) {
    // 10 Hz LiDAR scan
    // Preset: latest-only, bounded latency, optional redundancy
    (read_lidar())
}

Control Commands

Optimized for: Twist commands, joint targets, waypoints

Setting	Value	Why
History	Latest-only	Stale commands cause oscillation
Reliability	Best-effort	Speed over guaranteed delivery
Latency	Minimal	Control loops are latency-sensitive

#[node(period_ms = 10, preset = "control")]
pub fn planner() -> (#[out("cmd_vel")] Twist) {
    // 100 Hz control output
    // Preset: minimal latency, latest-only, best-effort
    (compute_velocity())
}

When presets ship, they will configure multiple settings at once. You’ll be able to override individual parameters when needed, and the defaults will be tuned for real-world robotics workloads — not synthetic benchmarks.

Backpressure

Coming Soon When a subscriber can’t keep up, traditional middleware queues grow silently until the system becomes unresponsive. Cerulion will provide explicit, predictable backpressure. The publisher knows subscriber capacity and paces accordingly. When the queue fills, an explicit policy determines what happens.

Drop Oldest

Keep latest data, discard old. Best for sensor streams where only current state matters.

Drop New

Reject new messages when full. Best when every message must be processed in order.

Block

Publisher waits for queue space. Best for reliable data that can tolerate latency.

// Configure backpressure policy per output
#[node(period_ms = 33)]
pub fn camera() -> (
    #[out("frame", overflow = "drop_oldest")] Image
) {
    // If the subscriber falls behind, old frames are dropped
    // No silent queue growth, no mystery lag
    (capture_frame())
}

“Mystery lag” happens when queues grow silently until everything explodes. When backpressure ships, Cerulion’s explicit policies will eliminate this failure mode by making queue behavior visible and predictable.

Minimizing Copies

High-bandwidth streams can’t afford unnecessary memory copies or serialization overhead:

Scenario	Traditional Middleware	Cerulion
🏠 Local pub/sub	Serialize → Copy → Deserialize	Zero-copy (shared memory)
🌐 Network send	Copy → Serialize → Copy → Send	Serialize in-place → Send
📐 Large fields (`Image::data`)	Multiple allocations	Single contiguous buffer

Cerulion Wire Format
FlatBuffers

Optimized for Rust-to-Rust communication — minimal overhead even for dynamically-sized fields.Image data is stored in a single contiguous buffer — no intermediate allocations, no fragmentation. When network deserialization is needed, it is a single-pass read from that buffer directly into the typed struct.Best for: Maximum throughput, Rust-native pipelines

Observability

You can’t optimize what you can’t measure. Cerulion exposes detailed metrics for every topic:

Per-topic throughput

Monitor publish rate with cerulion topic hz:

cerulion topic hz camera/image
# Subscribed to: camera/image
# Average rate: 30.1 Hz
#   Min: 29.8 Hz
#   Max: 30.4 Hz
#   Std Dev: 0.1 Hz
# Window: 100 messages

Drop reasons

Distinguish between failure modes:

Reason	Meaning	Action
Queue overflow	Subscriber too slow	Increase queue or optimize subscriber
Network loss	Packets dropped in transit	Check network, add redundancy
Fragment timeout	Large message reassembly failed	Reduce message size or switch transport

Latency histogram

Coming SoonEnd-to-end latency distribution from publish to subscriber callback — p50, p95, p99, and max latency per topic.

Buffer occupancy

Coming SoonTrack queue fill levels over time to detect backpressure before drops occur — current, average, and peak occupancy per topic.

Use cerulion tui for real-time node status, topic flow, and throughput. Monitor per-topic publish rate now with cerulion topic hz. Latency histograms and buffer occupancy metrics are coming soon.

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.

Cerulion

AI Tools

​Stream Presets

​Backpressure

Drop Oldest

Drop New

Block

​Minimizing Copies

​Observability

Stream Presets

Backpressure

Minimizing Copies

Observability