DDS and container networking

Sentinel and your robot controller must discover each other before you configure the adapter. Run every check on this page from the same container, network mode, ROS domain, and DDS configuration that will run Sentinel.

Networking is ready when the Sentinel environment receives live joint-state samples and your controller reports the expected command subscriber.

Choose a topology

Your controller runs…	Recommended setup
On the Sentinel computer	Use host networking and the same `ROS_DOMAIN_ID`
In another container on that computer	Use host networking for both containers and the same domain
On another computer	Use the same domain, non-local discovery, and an explicit network interface or peer
In another domain	Robot control topics are not supported through an arbitrary second domain; move them into the Sentinel domain

Compressed cameras can use a dedicated cross-domain bridge. That exception does not make robot state or command topics visible to the generic robot bridge.

Set the baseline environment

Set the same domain on both sides:

export ROS_DOMAIN_ID=67

Replace 67 with the domain assigned to your robot. Restart processes after changing the environment; an existing ROS 2 process does not change domains.

ros2 daemon stop

Sentinel uses Cyclone DDS by default. For the shortest bring-up path, use Cyclone DDS on both computers:

export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

Verify the connection

Confirm the environment

Check the domain, localhost setting, RMW implementation, and DDS configuration URI:

printenv ROS_DOMAIN_ID ROS_LOCALHOST_ONLY RMW_IMPLEMENTATION CYCLONEDDS_URI

Confirm discovery

Start the robot controller, then run:

ros2 node list
ros2 topic list

Cross-computer discovery can take several seconds. If the graph looks stale, stop the ROS 2 daemon and retry.

Confirm live measured state

Seeing a topic name is not enough. Verify that samples arrive:

ros2 topic hz /robot/joint_states
ros2 topic echo /robot/joint_states --once

Confirm compatible QoS

Inspect the measured-state publisher:

ros2 topic info --verbose /robot/joint_states

Match Sentinel's state subscription to the publisher. Use the sensor preset for a best-effort sensor-data publisher and reliable for a reliable publisher.

Confirm command discovery

Start your controller subscription, then inspect its command topic:

ros2 topic info --verbose /robot/command

Confirm the expected message type and at least one subscriber before starting Sentinel.

Pin Cyclone DDS to the robot network

Use an explicit interface when a computer has Ethernet, Wi-Fi, VPN, Tailscale, Docker bridges, or other competing interfaces.

Diagnose common failures

Symptom	Check first
No remote topics	Domain mismatch, `ROS_LOCALHOST_ONLY=1`, RMW mismatch, or wrong network interface
Topic appears but no samples arrive	QoS incompatibility or a stale ROS 2 daemon
Discovery works intermittently	Multiple active interfaces, multicast restrictions, Wi-Fi roaming, or VPN routing
Cameras work but robot topics do not	The camera may use the cross-domain bridge; robot control still requires the Sentinel domain
Works on the host but not in Sentinel	Container network mode or environment differs from the shell used for testing

Do not arm the robot based only on ros2 topic list. Confirm live measured state, compatible QoS, and the command subscriber from the Sentinel environment.

Configure the robot interface

Map measured state, command outputs, joint names, and watchdog behavior.