RobotnixAcademy

Unit 18 · lab

Lab: Defend the Readiness Decision and Hand Off the System

This is the final capstone lab.

You will not add a surprise feature. You will challenge the readiness dossier, defend the load-bearing claims, preserve the limitations, and produce an engineering handoff another student can continue from.

Your final deliverables are:

  • Final Readiness Decision;
  • Technical Defense Packet;
  • Engineering Handoff.

Guided example: answer the bigger claim by refusing it

Reviewer asks:

Your JUnit tests pass and your ROS bringup passes. Does that prove the robot is safe to deploy?

A weak answer tries to say yes.

A technically correct answer is:

No. The Java tests and ROS bringup satisfy their documented software/runtime criteria. They do not establish Java-to-ROS data exchange, physical sensor accuracy, motor-controller response, stopping distance, or hardware interlocks. Those layers remain not demonstrated in the required course path.

The goal of the defense is not to make every answer positive. It is to make every answer traceable to evidence.

Part 1: Freeze the final readiness table

Copy the Week 17 matrix into the final packet.

Do not change acceptance criteria unless you discover a genuine error in the criterion itself. If you change one, document why and identify which previous evidence must be reevaluated.

Every row must contain:

claim
acceptance criterion
evidence
status
limitation / condition / next evidence

Allowed statuses:

PASS
CONDITIONAL PASS
BLOCKED
NOT DEMONSTRATED

Part 2: Select six defense claims

Choose six claims that represent the architecture rather than six similar Java tests.

Required coverage:

  1. Java/WPILib component behavior;
  2. invalid-state or failure behavior;
  3. ROS graph/topic/interface evidence;
  4. ROS workspace/bringup reproducibility;
  5. controlled failure/recovery;
  6. Java-to-ROS integration or physical-system boundary.

For each claim, record one primary artifact ID.

Part 3: Run the challenge sheet

For each claim, answer:

What exactly does this prove?
What does it not prove?
What alternative explanation could fit the observation?
What evidence would make this claim fail?
How could another student reproduce it?

If any answer depends on:

I remember doing it

or:

it looked right

repair the evidence or downgrade the claim.

Part 4: Defend one Java claim

Show:

  • requirement;
  • exact test cases;
  • result;
  • one defect the test can catch;
  • one physical claim it cannot support.

The reviewer should be able to ask why 0.50 m matters and receive a requirement-based answer rather than "because it was in the lesson."

Part 5: Defend one ROS communication claim

Show one selected record such as:

/scan type/endpoints/QoS

or:

/robotnix/demo bringup topic/endpoints

State whether the evidence is local or supplied.

Explain the exact runtime question the evidence answers.

Part 6: Defend bringup reproducibility

Use the Repeatable Startup Runbook.

The reviewer may ask:

How do I know the correct overlay is sourced?
Where is the installed launch file?
What proves both nodes are visible?
What proves the remapping worked?
What happens after Ctrl+C?

Point to the relevant evidence instead of answering from memory.

Part 7: Defend the controlled failure

Show:

healthy requirement
injected defect
failure evidence
diagnosis
repair
same detector after repair
recovery evidence

Explain why the experiment changed one intended variable.

If the failure was supplied rather than locally executed, say so.

Part 8: Defend the integration status

Required question:

Where is the evidence that Java data crossed into ROS?

If the canonical course path was followed, answer:

No cross-runtime trace exists. The integration contract is a proposed architecture artifact, so the matrix marks Java-to-ROS integration NOT DEMONSTRATED.

Then show the evidence required to change that status in the future.

Part 9: Defend the physical-system status

Required question:

Which physical sensor/controller/actuator tests were performed?

If none were performed, say:

Physical robot behavior was not demonstrated in the required course path.

Then identify what a future approved validation plan would need to measure.

Do not invent a hardware test result.

Part 10: Produce the Engineering Handoff

Include:

Current state

Short summary of what is demonstrated and not demonstrated.

Environment

Java/OpenJDK version
Ubuntu version
ROS distribution
workspace path
bringup package

Reproduce Java evidence

Point to tests and key acceptance criteria.

Reproduce ROS bringup

Point to the runbook and expected package/node/topic evidence.

Integration status

Attach the Java-to-ROS Integration Contract.

Known failure cases

List detector, diagnosis, and repair evidence for the controlled regression cases worth preserving.

Known limitations

State missing integration/physical evidence.

Next actions

List the next two or three bounded milestones in dependency order.

Evidence index

Point to every load-bearing artifact.

Part 11: Five-minute defense

Deliver or rehearse a five-minute defense with this order:

  1. scope and architecture;
  2. strongest Java evidence;
  3. strongest ROS evidence;
  4. bringup reproducibility;
  5. controlled failure/recovery;
  6. final readiness decision;
  7. missing integration/physical evidence;
  8. next milestone.

Do not spend the first three minutes explaining course history.

Lead with the current engineering state.

Part 12: Final contradiction check

Before submission, search the dossier for phrases such as:

fully integrated
robot works
safe to deploy
production ready
Java connected to ROS

For each phrase, ask whether the evidence really supports it.

If not, repair the wording or provide the missing evidence.

Also check that no supplied transcript is presented as local execution.

Success criteria

The course capstone is complete when:

  • every major claim has an acceptance criterion and exact evidence;
  • contradictory evidence is explained rather than hidden;
  • at least one controlled failure/recovery record is preserved;
  • the startup procedure is reproducible from a clean shell;
  • Java/WPILib and ROS evidence remain correctly scoped;
  • Java-to-ROS integration status is explicit;
  • physical readiness status is explicit;
  • the defense packet can answer skeptical challenge questions;
  • the handoff gives another student a bounded next step without depending on your memory.

The final grade-worthy skill is not saying "everything works." It is knowing exactly what you can prove, what you cannot prove, and what evidence would move the system to the next readiness level.