cerulion ros attach points Cerulion at a robot that is already running ROS 2. It discovers the live DDS topics, generates a bridge graph for the ones whose types resolve, and runs it — so those topics become ordinary Cerulion topics you can echo, record, visualize, and consume from your own nodes.
Run it on the robot, or on a machine on the robot’s DDS network.
Look before you write
--dry-run prints the discovery report and stops: it writes nothing and runs nothing.
The report tells you which topics resolved to a known type and which did not. A topic whose type Cerulion cannot resolve is left out of the generated graph — add the message definition to your workspace and re-run if you need it.
Generate and run the bridge
graphs/go2.yaml plus graphs/go2.bridge.yaml, asks you to confirm, and then runs the bridge. Use --yes for scripts and non-interactive shells.
--robot-name is not the network identity. The name that shows up in cerulion topic list and over mDNS comes from the machine’s hostname, or from CERULION_ROBOT_IDENTITY if you set it.See the data on your desk
The generated graph bridges the robot’s topics and nothing else — no visualization node is staged on the robot, which keeps the robot’s job to shipping raw frames. To look at the data, work from your own machine:Consume a bridged topic from your own node
A bridged topic is a normal topic, so wire an input to it by absolute name:Record a bridged system
A bridge run records like any other run, and a recording of one plays back as a robot substitute when the robot is not available:Use plain
bag play for a bridge recording. A bridge node reads a live device rather than computing from its graph inputs, and --resim all re-executes every node in the bag — including the bridge, against DDS that is no longer there. See Record and replay a run.Next steps
Message types
The 254 built-in ROS 2 messages that resolve out of the box.
Record and replay a run
Bag a bridged system and play it back without the robot.