Hacker News
Show HN: Cerulion – ROS 2-compatible robotics runtime with multi-process replay
I worked on off-road autonomy during my PhD at MIT, and we kept running into inter-process latency in ROS (2 lidars and 6 cameras). Loaned messages need POD types, which nukes standard, vendor-agnostic Image/PointCloud2. We ended up running some hot paths in a brittle single process, which made debugging a nightmare. I'm sure you've seen the heisenbugs ROS-based stacks can produce, with no way to easily reproduce the consumption order or interleaving of callbacks. Valuable data of runtime failures on the robot was hard to use effectively without deterministic reproducibility.
This is what we fix. Cerulion bags record per-input reads and scheduler traces alongside message content in standard MCAPs. cerulion bag play --resim all --verify re-executes node code on the recorded schedule and compares each byte for exact matches or within defined tolerances. Exit 0 is a match, 1 shows the first topic/frame that diverges, 6 shows schedule divergence and --report gives an optional CI verdict. Eligible ROS2 processes can replay deterministically as well.
Here's the data loop:
1. Run: Dependency-ordered level-based DAG scheduler with periodic/data/sync triggers, I/O deadlines, backpressure, and automatic profiling for process partitioning. Each node by default free-runs in its own process while preserving deterministic replay. Live runs pause/resume, and UMWAIT/WFE parks idle consumers on CPUs that support it. Wall-clock reads and runtime thread spawns in user code rejected at compile time by macros.
ROS 2 is supported with rmw_cerulion for Foxy, Humble, Jazzy and Lyrical, that lets you run ROS2 nodes/launch files unmodified in the same graph as native Cerulion nodes. LD_PRELOAD gives ROS2 code shared memory loans through std::vector/std::string. cerulion ros2 attach folds in already-running ROS2 robots, and cerulion ros2 run/launch lets you run existing ROS2 workspaces on Cerulion without any additional setup (with an optional automatic migrate suggested that rewrites C++ publish sites).
2. Move: iceoryx2 shared memory with no serialization, no payload copy and no payload-sized allocation, including for variable-length messages like sensor_msgs/Image and PointCloud2. Round trip latency for a 1MiB sensor_msgs/Image between two processes is 4.08µs p50, with a tight tail of 7.38µs p99 (under 2x p50), with recording on. This is default Cerulion, against 10.95 ms for default ROS 2 Jazzy. Cerulion's p50 and p99 stay flat from 64B to 16 MiB.
3. Capture: With this round-trip latency, there are no tradeoffs, not for process isolation and not for bagging. We can afford always-on or event-based logging. Flashback is our robot dashcam: keeps ~30s of all logs and message contents in memory and saves it automatically on process crashes, topic stalls or declared incidents/manual triggers.
4. Reach: A free account lets you pair robots and desks, letting all your devices find each other with no config, IP addresses or discovery chatter. Pubsub is authenticated and on-demand, with signed grants that the robot verifies offline. We use Iroh to hole-punch or relay over WAN, and mDNS over LAN to transmit data using QUIC. Remote topics mirror into local shared memory, and each device has a single network gateway.
5. Diagnose: cerulion doctor scans for compile/run-time issues (better than Windows Troubleshooter I promise) and suggests fixes. Hindsight is an early access MCP to let agents analyze your bags.
To get started: go to the repo, install Cerulion with the curl one-liner, and paste the prompt in Claude Code/Codex: https://github.com/cerulion-inc/cerulion#quickstart-run-reco.... Or shift your own gears, it's all in the repo that you should star!
The CLI needs a free account, which we use to make device pairing as easy as AirDrop USED to be ;) Everything runs on Linux (x86_64/ARM64), macOS and Android (JNI), with more platforms coming.
We'd love to hear your feedback! If you run ROS 2 on a real robot, point this at your stack and tell us what breaks.
Docs: https://docs.cerulion.com
Site: https://cerulion.com
known-developer
|next
[-]
leetrout
|next
|previous
[-]
Good luck! Excited to see more stuff like this coming.
noxs
|next
|previous
[-]
- Robot Operating System - it is not even an operating system
- ROS Node - okay a process/thread that runs the application logic (but why name it as node? it is a service)
for ROS Node to talking to another ROS Node:
- I need a ROS topic
- I need a ROS Message
- in C++ I need rclcpp that is a C++ client
- which then uses rcl which is a C implementation
- it goes through a ROS Middleware (rmw) that is an abstract DDS (hey what is DDS)
- now you have many implementation choices, FastDDS, Cycloe DDS etc. which one should I pick?
- finally it would make some syscall
oh you want to build this with your application?
- use some weird command line called ros2 pkg create
- you need to use ament_cmake (what the heck is this?)
- and yet another tool called colcon to build the package
lakshays
|root
|parent
|next
[-]
elBoberido
|root
|parent
|previous
[-]
- one 'O' but no 'S' in the name, therefore no claims for an OS ;)
- okay, it also has a Node but it runs no logic
- we call a Topic a Service since it defines the service ... but also does not run the application logic; actually there are no background threads to run the application logic, it's your decision to spawn a thread or not, not ours
- we need a Sample instead of a Message but it is up to you to decide what is in there; raw bytes, an actual struct, FlatBuffers or anything else (... as long as it is shared memory compatible); you decide
- with C++ you also have a C library as dependency, which is implemented in Rust ... yikes ... on the pro side, it's implemented Rust ;)
- no middleware layer like DDS is involved; it is the middleware layer
- just one implementation ... well, under the hood everything can be replaced by just implementing a trait on a struct but technically it is still just one implementation ;)
- no syscalls on the data delivery path, only when you really want to explicitly use a Notifier to notify another process which is waiting on a Listener
- we have a iox2 command but it is not used for building anything, just for introspection
- just plain cmake, no ament ... if you like also bazel ... but well, one needs to be into it ;)
- okay okay, cargo is also needed but it is invoked from cmake so you do not have to touch it