RobotnixAcademy

Unit 01 · lesson

Make the Claim Match the Evidence

Technical work is not finished when you collect output. You still have to decide what that output supports.

This lesson gives you a simple habit that will appear throughout the course: write the claim last.

Start with the evidence, identify its source, and only then write the conclusion.

A bad status message

Suppose a report says:

The robot is ready. Java ran successfully and both ROS nodes are online.

That sounds reasonable until you separate the evidence.

Assume you actually observed:

$ java RobotStatus
status=READY

and:

$ ros2 node list
/sensor_bridge
/motor_guard

The report contains at least three claims:

  1. the Java program ran;
  2. two ROS node names were visible;
  3. the robot was ready.

Only the first two have direct supporting evidence.

The word ready is much larger. Ready for what? Simulation? Message inspection? Motor output? Human operation? Physical movement?

A status word without defined criteria is difficult to defend.

Repair the first claim

Instead of:

Java is working.

write:

RobotStatus executed in the Java runtime and printed status=READY.

The repaired version is more precise because it names the program and observation.

It does not turn one successful class execution into a claim about every Java component in the project.

Repair the graph claim

Instead of:

Both ROS nodes are online.

write:

ros2 node list showed /sensor_bridge and /motor_guard in the inspected lesson graph.

Why avoid the word online here?

Because node list tells you about graph visibility. It does not tell you whether each node is healthy, publishing expected data, receiving expected messages, or connected to real hardware.

Now address the missing robot claim

The original report ended with:

The robot is ready.

The current evidence does not establish that.

A responsible report could say:

Java execution and ROS graph presence were observed. Physical robot readiness was not evaluated.

That is not a weak conclusion. It is a useful boundary.

A technician reading the report now knows what to test next instead of assuming someone already tested it.

Strong claims have criteria

If you eventually want to claim:

The range-processing software is ready for integration testing.

then define what ready means.

For example:

  • Java code compiles;
  • unit tests pass;
  • expected ROS nodes are visible;
  • expected topic endpoints exist;
  • sample messages match the expected type;
  • configuration values are known;
  • startup can be repeated from a clean shell;
  • known integration gaps are documented.

Now the word ready refers to stated criteria instead of confidence.

The exact criteria will change with the system and stage of development.

Observation, interpretation, and conclusion

These three ideas are related but different.

Observation is what the tool or person directly recorded.

Example:

/motor_guard

appeared in ros2 node list.

Interpretation explains what that observation means within the tool's scope.

Example:

A node with the name /motor_guard was visible in the ROS graph.

Conclusion combines relevant observations and interpretations to answer a question.

Example:

The expected guard node name is present, but no message or hardware evidence has been collected yet.

If you skip directly from observation to an oversized conclusion, debugging gets unreliable.

One fact can support more than one next question

Suppose /motor_guard is visible.

If your question is:

Does it subscribe to /scan?

then use:

ros2 node info /motor_guard

If your question is:

Is /scan carrying messages?

then use topic inspection.

If your question is:

Did a physical motor stop?

then ROS graph evidence alone is not enough.

The missing claim determines the next evidence source.

Practice: repair these statements

Rewrite each statement so that it matches the evidence given.

Case A

Evidence:

javac RobotStatus.java

returns without an error.

Weak claim:

The robot program works.

Case B

Evidence:

ros2 topic list
/scan

Weak claim:

The lidar is sending good data.

Case C

Evidence:

needsCharge(18) == true

Weak claim:

The robot battery is low.

Case D

Evidence:

ros2 node info /motor_guard
Subscribers:
  /scan: sensor_msgs/msg/LaserScan

Weak claim:

/motor_guard received the latest scan.

For every repaired statement, add one sentence naming the evidence you would collect next if you wanted to make the original stronger claim.

Prepare for the lab

Your Week 1 lab combines four evidence sources:

  • Java source;
  • Java compile/run behavior;
  • one Java method result;
  • ROS 2 graph inspection.

Your job is not to make all four agree with a dramatic conclusion.

Your job is to keep each record in its correct layer and produce one final statement that another engineer could challenge line by line.

That is the standard the rest of the course will use.