RobotnixAcademy

Unit 17 · lesson

Select ROS Evidence That Proves Runtime Structure, Communication, and Startup

The ROS side of the capstone can produce a lot of terminal output. The challenge is deciding which records actually support your readiness claims.

For Unit 8, select a small set of evidence that covers different ROS questions.

A useful minimum set is:

  • one graph/node record;
  • one topic/interface/message or QoS record;
  • one configuration or interaction record;
  • one repeatable bringup record.

Choose one graph record

A graph record can answer:

Which nodes were visible and what relationships did one node expose?

For example:

ros2 node list
ros2 node info /motor_guard

may support:

/motor_guard was visible
/motor_guard subscribed to /scan
/motor_guard published /cmd_vel

That does not prove the subscriber processed a fresh message.

If your matrix claim is about graph structure, this evidence fits.

Choose one topic communication record

A stronger communication record from Week 12 can include:

/scan
sensor_msgs/msg/LaserScan
publisher /sensor_bridge
subscriber /motor_guard
BEST_EFFORT QoS on both endpoints
one supplied LaserScan message
approximately 10 Hz supplied receiving-rate window

You do not need every topic command if one concise table contains the evidence.

The important question is:

Which communication claim does this record support?

For example:

The supplied /scan endpoints are type-compatible and QoS-compatible under the documented deterministic profile.

That is reviewable.

Failure evidence can be more valuable than a healthy snapshot

The deliberate QoS mismatch is useful because it proves you understand a specific failure mechanism:

publisher offers BEST_EFFORT
inspection subscriber requests RELIABLE
result: incompatible reliability policy

Then:

inspection subscriber requests BEST_EFFORT
result: supplied message becomes available

That record shows a controlled failure and a bounded repair.

It does not prove a physical sensor network recovered.

Choose one service/action/parameter record only if it supports a claim

Possible evidence includes:

Trigger service returned success/message
Fibonacci action goal accepted, feedback received, final result succeeded
caution_distance_m changed 0.5 -> 0.75, invalid -1.0 rejected

Do not include all three just because Week 13 taught all three.

Choose the one that best supports your system-review claim.

A parameter record is especially useful if your capstone discusses configuration validation.

Bringup reproducibility deserves its own evidence

The bringup record answers a different question:

Can another student start the same ROS-side system from a clean shell?

Useful evidence includes:

Jazzy sourced
robot_ws overlay sourced
robotnix_bringup prefix resolved
colcon build succeeded
launch file found
/talker_demo visible
/listener_demo visible
/robotnix/demo type/endpoints correct
shutdown verified

This is operational evidence, not algorithm correctness.

Keep supplied and local evidence separate

If your ROS evidence came from the course reader lane, label it:

supplied deterministic ROS evidence

If you ran it locally, label:

local ROS 2 Jazzy evidence

If a record comes from a screenshot, transcript, or lab report supplied by another source, label that source too.

A capstone should never make provenance ambiguous.

Do not merge unrelated clocks into one timeline

Java logs and ROS logs may use different clocks or independent supplied timestamps.

If you cannot prove the timestamps are synchronized, do not write:

Java event happened 10 ms before ROS event

You can write:

Both records occurred in their respective supplied/local observation windows; cross-runtime ordering is not established.

That preserves technical honesty.

A healthy ROS runtime can coexist with an unimplemented bridge

Suppose the bringup passes every ROS check.

That supports:

ROS bringup readiness

It does not automatically improve this matrix row:

Java-to-ROS integration demonstrated

If the bridge is not implemented, the integration row remains:

not demonstrated

Do not let strong evidence in one subsystem hide missing evidence in another.

Worked evidence section

Claim

The ROS demo bringup is reproducible in the documented Jazzy environment.

Acceptance criterion

Clean shell -> source underlay/overlay -> resolve package prefix -> launch -> observe expected nodes/topic/endpoints.

Evidence

Week 15 Bringup Verification Record
robotnix_bringup prefix resolved to robot_ws
/talker_demo visible
/listener_demo visible
/robotnix/demo std_msgs/msg/String
publisher 1
subscriber 1

Status

Pass for ROS demo bringup

Limitation

Does not prove Java/WPILib integration or physical robot behavior.

Your turn

Choose four ROS evidence items:

  1. one graph/node record;
  2. one topic/message/QoS record;
  3. one configuration/service/action record that supports a real claim;
  4. one workspace/launch reproducibility record.

For each, write:

  • claim;
  • acceptance criterion;
  • exact evidence;
  • status;
  • limitation.

Then remove any terminal output that does not support a distinct claim.

In the next lesson, you will inject one controlled failure and test whether your evidence process can detect, diagnose, and verify recovery rather than only describe healthy states.