Skip to main content
A live Cerulion run is network-viewable by default. A robot on your LAN announces the topics it produces and forwards one the moment a remote subscriber asks for it, with no configuration. You restrict that with a network: block, or turn it off for a run. Local transport is unaffected by any of this: nodes on the same machine always talk through zero-copy shared memory.

​
What a run resolves to

Evaluated in this order: Recording keeps the network on, so a robot stays viewable while it records.

​
Restrict what leaves the machine

The network: block is a tightening, not an on-switch. Declaring one puts the run in strict mode.
Validation refuses each mistake by name — a topic in both lists, an egress topic nobody produces, an ingress topic this graph already produces, a relative topic name, or a non-empty list under mode: disabled. Empty lists under peer are valid: that is an export-restricted robot.
--record together with a block that declares ingress: is refused, because recorded ingress re-injection is not yet replay-faithful. Record without the ingress bridge, or run without --record.
The full key reference is in Graph and schema files.

​
Find robots on the network

cerulion topic list prints local topics instantly, then discovers robots and their topics over the LAN.
The local TOPIC section prints first and instantly, so a slow network never delays it. A ROBOTS section then lists each robot found, its visible-topic count, and its locator, followed by REMOTE TOPICS — every topic a networked robot is advertising or asking for:
With nothing discovered, both remote sections are simply absent. The remote half is best-effort and bounded to a few seconds. A discovery failure is a loud note and still exits 0, since the local list already printed.
A robot that should be findable needs a listen endpoint. Set CERULION_NETD_LISTEN=tcp/0.0.0.0:7683 in the robot’s service environment and restart its cerulion-netd; the shared network plane then binds the port and advertises it over mDNS. Without it, the robot is reachable only where LAN multicast is allowed, which is why an intermittent robot is usually a discovery problem rather than a Cerulion one.

​
Pull a robot’s topics to your desk

cerulion connect demands topics from a robot and re-injects them into your machine’s shared memory, so every local tool sees them as ordinary topics.

Pair with the robot once

The robot’s owner starts code pairing on the robot and reads you a short code; type it at the prompt. Pairing puts this desk on the robot’s access list, then pins name → endpoint locally so cerulion connect lab-go2 works with no flags afterwards. Your desk key is created once and never overwritten.Exit codes are stable for scripting: 0 paired, 2 the robot refused, 3 unreachable, 4 wrong code.
--code exists for a driver piping the code in, but prefer the prompt: a code on the command line is visible in process listings for the length of the ceremony, and it authorizes durable enrollment.

See the catalog

With no --topic and no --all, connect prints the robot’s catalog and demands nothing.

Demand the topics you want

Then, in another shell, the topic behaves like a local one:
--all demands the whole catalog. Demand only what you need: every demanded topic is real traffic over the link.
To watch a robot without demanding topics by hand, connect to it in Cerulion Studio and check the topics you want — see Visualize a running graph.

​
Manage the machines on your account

login prints a short code and a verification URL and waits while you authorize it in a browser. Any command that needs an identity triggers it for you. Robot access management itself lives in the web account page, not the CLI — account devices is for your own desks.

​
Next steps

Visualize a running graph

Watch local or remote topics on the Studio stage.

Bridge a ROS 2 system

Attach to an existing DDS graph.