Launch Succeeded, Graph Wrong: Diagnose the Runtime Contract

A launch file can import correctly, resolve its dependencies, and start both processes while the resulting ROS graph still differs from the design.

At this point, package and launch infrastructure are no longer the first suspects. Inspect the runtime graph.

Verify the nodes first

Expected:

/talker_demo
/listener_demo

Run:

ros2 node list

If both names appear, you have node-presence evidence.

If one is missing, inspect the launch/process output for that executable before blaming topic remapping.

Verify the topic identity

Expected default:

/robotnix/demo [std_msgs/msg/String]

Run:

ros2 topic list -t

Suppose the graph instead shows:

/chatter [std_msgs/msg/String]

The nodes are running, but the remapping did not produce the expected topic name.

Now inspect the installed launch file and runtime argument values.

Inspect each node's relationships

Run:

ros2 node info /talker_demo
ros2 node info /listener_demo

Suppose:

/talker_demo publishes /robotnix/demo
/listener_demo subscribes /chatter

The launch is partially configured.

The likely defect is a one-sided remapping or differing launch configuration.

The exact runtime evidence tells you which side is wrong.

Endpoint counts can expose hidden mismatches

If:

ros2 topic info /robotnix/demo

shows:

Publisher count: 1
Subscription count: 0

and /chatter shows one subscription, the graph explains why the listener is not receiving the remapped talker stream.

No build-system theory is needed yet.

The endpoint relationships are already inconsistent.

Message evidence comes after endpoint evidence

Once the graph shows one publisher and one subscription on the same std_msgs/msg/String topic, inspect one message:

ros2 topic echo /robotnix/demo --once

If a message appears, you have stronger communication evidence.

If no message appears during a bounded observation, investigate runtime behavior rather than assuming the node list was enough.

Argument overrides can explain the mismatch

Someone may have launched:

ros2 launch \
  robotnix_bringup \
  demo_pair.launch.py \
  topic_name:=/robotnix/test

while another engineer expects the default /robotnix/demo.

The source launch file can be completely correct. The runtime is using a different launch-time configuration.

Record the exact launch command in your runbook.

Without it, a perfectly intentional override looks like a configuration failure.

Graph correctness is not physical-system correctness

Even if:

nodes correct
topic correct
type correct
endpoints correct
message observed

this demo still proves nothing about robot motors, sensors, or Java/WPILib integration.

It proves the ROS demo bringup created the expected ROS-side communication path.

Keep the scope honest.

Worked runtime mismatch

Expected:

/talker_demo -> /robotnix/demo -> /listener_demo

Observed:

/talker_demo -> /robotnix/demo
/listener_demo <- /chatter

A strong diagnosis is:

Both demo nodes are visible. The talker publishes the expected remapped /robotnix/demo topic, but the listener subscribes to /chatter, so the runtime graph does not contain the intended shared communication path.

Repair the listener remapping, rebuild the installed launch resource, relaunch, and verify the graph again.

Your turn

For each runtime observation, identify the next command that best narrows the problem.

1. /listener_demo missing from ros2 node list.
2. both nodes visible, /robotnix/demo missing.
3. /robotnix/demo exists with publisher 1, subscriber 0.
4. endpoint counts are correct, but no message arrives during a bounded observation.
5. /robotnix/test appears even though the source default is /robotnix/demo.

Use only commands that answer the next unresolved question.

In the next lesson, you will define the boundary between this ROS bringup and the Java/WPILib application so the course does not pretend two healthy runtimes are automatically integrated.