RobotnixAcademy

Unit 17 · lab

Lab: Build the Robot System Readiness Dossier

This lab assembles the strongest evidence from the course into one review packet.

You are not building a new robot this week. You are proving which parts of the existing Java/WPILib and ROS 2 system are supported by evidence, injecting one controlled failure, and naming the integration or physical layers that remain outside the demonstrated scope.

Your final artifact is the Robot System Readiness Dossier.

Guided example: strong evidence in one layer does not fill another layer

Evidence:

JUnit boundary suite: PASSED
ROS bringup: PASSED

Claim:

The Java robot application is connected to ROS.

The claim is unsupported.

The Java tests prove Java behavior. The ROS bringup proves the ROS runtime can start and expose the expected demo graph. Neither record contains a bridge or cross-runtime data trace.

Correct capstone status:

Java layer: PASS
ROS bringup: PASS
Java-to-ROS integration: NOT DEMONSTRATED

Use the same separation throughout the dossier.

Part 1: Freeze the capstone scope

Write one paragraph defining what the review covers.

Include:

Java component design/testing
WPILib evidence
ROS 2 Jazzy runtime evidence
ROS workspace/launch reproducibility
Java-to-ROS integration status
physical robot evidence status

Do not add new major requirements halfway through the review.

Part 2: Build the Claim-to-Evidence Matrix

Include at least ten claims.

Required categories:

  • Java boundary rule;
  • Java invalid-state behavior;
  • JUnit/WPILib evidence;
  • ROS graph state;
  • /scan message/QoS evidence;
  • service/action/parameter interaction understanding;
  • workspace build;
  • bringup reproducibility;
  • Java-to-ROS integration;
  • physical robot behavior.

Each row requires:

claim
acceptance criterion
evidence source
status
limitation / next evidence

Use only:

PASS
CONDITIONAL PASS
BLOCKED
NOT DEMONSTRATED

Part 3: Select three Java/WPILib evidence items

Include:

  1. one exact-boundary JUnit case;
  2. one invalid-input/state-preservation case;
  3. one runtime/log/simulation record if it supports a distinct claim.

For every item, label:

local execution
supplied course evidence

or the actual provenance.

Do not paste the entire Unit 5 folder.

Part 4: Select four ROS evidence items

Include:

  1. one graph/node relationship record;
  2. one topic/message/QoS record;
  3. one service/action/parameter record;
  4. one workspace/bringup reproducibility record.

For each, write the strongest claim it supports and one stronger claim it does not support.

Part 5: Attach the Java-to-ROS Integration Contract

Required fields:

Java/WPILib runtime responsibility
ROS runtime responsibility
bridge/adapter status
data contract
units/types
freshness requirement
source of truth
startup dependency
failure behavior
verification evidence required

Canonical course status should remain:

proposed architecture only / not demonstrated

unless you independently implemented and documented an authorized integration path.

Part 6: Inject one controlled failure

Choose one safe course failure:

Java < vs <= boundary defect
invalid range update
QoS reliability mismatch
unsourced overlay
stale launch install
one-sided remap

Before the failure, record:

requirement
healthy state
expected detector

Then preserve:

failure evidence
diagnosis
repair
recovery evidence

Do not delete the failed record after recovery.

Part 7: Update the matrix after the failure

Ask:

  • Which readiness row did the failure test?
  • Did the expected detector catch it?
  • Did the repair restore the original acceptance criterion?
  • Did any other readiness row actually change?

Do not upgrade unrelated layers because one recovery succeeded.

Part 8: Write the readiness summary

Write 100–150 words.

It must state:

  • strongest supported software/runtime claim;
  • one conditional limitation;
  • Java-to-ROS integration status;
  • physical robot status;
  • next evidence required for the biggest unresolved claim.

Avoid vague phrases such as:

works correctly
ready for anything
everything passed

unless you define the exact scope.

Part 9: Build the technical defense index

Create a one-page index for Week 18.

For each major claim, list:

claim ID
evidence artifact
status
known challenge question

Example:

C-07
ROS bringup reproducible
Week 15 Bringup Verification Record
PASS in documented Jazzy environment
Challenge: does this prove Java integration? No.

The index will let you defend the dossier without searching through dozens of files during the final review.

Success criteria

Your Week 17 dossier is complete when:

  • every readiness claim has an acceptance criterion;
  • evidence provenance is explicit;
  • at least one failure and repair are preserved;
  • Java/WPILib and ROS evidence are not merged into a fake end-to-end test;
  • integration status is explicit;
  • physical hardware claims are bounded;
  • another student can find every load-bearing artifact from the defense index.

Week 18 will not add a hidden new requirement. It will stress-test this dossier, make you answer challenge questions, and produce the final handoff/readiness decision.