Keep More Than One Explanation Alive Until the Evidence Rules It Out

A technical diagnosis becomes fragile when the first plausible explanation is treated as fact.

Good debugging keeps alternative hypotheses alive until evidence eliminates them.

One symptom can have several causes

Observed:

/robotnix/demo has publisher count 1
subscription count 0

Possible explanations include:

• listener process is not running;
• listener node is running but remapped to another topic;
• listener subscription failed to initialize;
• you are inspecting the wrong launch configuration;
• another process owns the publisher while the expected listener is absent.

The endpoint count tells you the symptom, not which explanation is true.

Rank hypotheses by the next evidence they predict

Suppose you have two hypotheses.

H1

The listener process crashed.

Prediction:

ros2 node list

will not show /listener_demo.

H2

The listener is running but subscribed to /chatter.

Prediction:

ros2 node list

will show /listener_demo, and:

ros2 node info /listener_demo

will expose /chatter.

Now you can choose the next command based on which evidence separates the hypotheses.

Do not collect evidence that both hypotheses predict equally

If both hypotheses predict:

/robotnix/demo subscriber count 0

running the same topic info command repeatedly does not move the diagnosis forward.

Choose a command that produces different expected results under H1 and H2.

This is one reason hypothesis-driven troubleshooting is faster than command wandering.

Java failures also have alternatives

A test fails at:

0.50 m

Possible explanations include:

• implementation uses <= instead of <;
• test expectation is wrong;
• test input is not actually 0.50 due to setup;
• another configuration value changes the threshold;
• shared state leaked between tests.

Read the failure record and test setup before immediately editing the comparison operator.

The simplest bug is common, but evidence should still support it.

Missing ROS messages can have several layers

Observed:

/scan exists
publisher count 1
subscriber count 1
no message arrives in the observer window

Possible explanations:

publisher is not producing data
QoS incompatible for the observer
source input is stalled
observer window too short
network/discovery condition changed

Week 12 taught you to inspect endpoint QoS before deciding the publisher is broken.

A disciplined diagnosis keeps these layers separate.

A successful repair can support the diagnosis

Suppose the reliable inspection subscriber receives nothing.

You change only:

RELIABLE -> BEST_EFFORT

and the supplied message appears.

That controlled repair supports the QoS incompatibility explanation because the relevant variable changed while topic name/type/publisher stayed the same.

It does not prove every possible network condition was healthy.

Failed repairs are useful too

Suppose you suspect the overlay is missing and source:

source ~/robot_ws/install/setup.bash

but package lookup still fails.

Now the missing-overlay hypothesis is incomplete or wrong.

Check:

• does the install setup file exist;
• was the package built;
• is the package name correct;
• are you using the intended workspace path?

A failed repair updates the diagnosis.

Do not silently ignore it.

Build an Alternative Hypothesis Table

For one incident, use:

Choose at least three hypotheses before testing.

The table forces you to separate:

what you observed
what you think it means
what evidence would distinguish the explanations

Worked example: stale launch behavior

Observed:

source default = /robotnix/stale_test
runtime default = /robotnix/demo

Hypotheses:

H1: package was not rebuilt

Prediction: installed launch file still contains /robotnix/demo.

H2: wrong workspace overlay is sourced

Prediction: ros2 pkg prefix robotnix_bringup resolves another workspace.

H3: launch argument override forced /robotnix/demo

Prediction: launch command contains topic_name:=/robotnix/demo.

These hypotheses require different evidence.

That is much stronger than saying:

ROS cached my file.

without checking what actually happened.

Alternative explanations protect against overconfidence

A system review should include at least one place where you say:

This observation is consistent with X, but Y and Z remain plausible until the following evidence is collected.

That is not weakness. It is accurate engineering reasoning.

Your turn

Choose one capstone incident:

• Java boundary test failure;
• no /scan message;
• package not found;
• stale launch behavior;
• missing listener subscription.

Write three plausible hypotheses.

For each, specify:

• predicted evidence;
• one test that distinguishes it;
• what result would reject it.

Then perform or analyze the evidence and update the table.

In the next lesson, you will freeze the final readiness decision. No more changing acceptance criteria to make the outcome look better.