Chapter 22 · Bring up real robot hardware through bounded, evidence-led gates

Today in the field story

One problem, then the next

The Bench Zero review assembles requirement rows, sources, calculations, mock lifecycle logs, calibration identity, simulated teleoperation trace, stop-function distinctions, unknowns, owners, and decisions. The uncut evidence run starts from no motion, demonstrates only mocks and simulation, injects one declared fault, and ends with the same zero-power boundary. A conditional accept means the dossier can proceed to qualified planning, not that hardware should be purchased or energized. Week 23 inherits the mock interfaces and safe collection constraints.

Why now: A final dossier prevents scattered paper checks from becoming an accidental readiness claim.
Ignore today: Do not film first motion or convert conditional review into purchase approval.
Unlocks next: A safe, versioned collection-system baseline for the capstone dataset.

Understand

Build the physical picture first

Hardware acceptance is a chain of mandatory evidence gates from identity and static inspection through simulated faults and qualified safety records, with no averaging away a critical failure.

Freeze acceptance before the run. Give each requirement a stable ID, test level, initial condition, configuration, procedure reference, expected result, measured field, tolerance, artifact, owner, witness where required, and mandatory or informational classification. Group evidence across task fit, exact hardware identity, mechanical installation, electrical design and inspection, firmware and manifests, communication and clocks, ros2_control resources and lifecycle, calibration and frames, low-risk command behavior, diagnostics, shutdown, safeguards, emergency functions, documentation, training, maintainability, and unresolved defects.

Use a ladder whose claims match its physical boundary. A calculation reviews sizing assumptions; a mock checks plugin logic; simulation checks commands, leases, limits, frames, and fault transitions; HIL can add named compute, firmware, bus, I/O, or controller behavior while the plant remains emulated; restricted-energy tests can add selected mechanics under approval; real load and site tests add further evidence. Never relabel a missing rung as passed because another rung succeeded. Not run, blocked, not applicable with rationale, and not verified at this level are valid outcomes.

Mandatory gates are conjunctive, not an average. Eighteen passes out of twenty equals 90 percent checklist completion, but acceptance remains reject when the missing rows concern a required calibration or validated emergency response. Noncritical deviations can support a conditional decision only when impact, containment, owner, due date, retest, and release authority are explicit. A screenshot, green dashboard, responsive device, controller activation, video, or one successful motion proves only its observed scope; keep raw measurements and failures beside the summary.

Make the repeatable video an index into evidence, not theatre. Begin with visible date, test ID, exact code, firmware, configuration, device or mock identities, calibration, environment, and safety boundary; show the checklist and one continuous low-risk run; narrate expected versus observed checkpoints; inject a predeclared fault; end on terminal state and unresolved rows. Timecode the trace, logs, measurements, and decision. For this learner exercise, the run remains unpowered or simulated, and all real electrical, mechanical, load, E-stop, STO, and site acceptance stays explicitly pending qualified procedures.

Words you need

Name each idea precisely

Acceptance criterion: A predeclared observable condition, measurement method, tolerance, and decision rule used to determine whether a requirement is met.
Physical example:
The mock drive manifest must contain the two expected identities and protocol version before the ros2_control component may enter its simulated active state.
Mandatory gate: An acceptance row that must pass at the required evidence level before release; other successes cannot compensate for it.
Physical example:
A failed qualified emergency-function test blocks release even when all ordinary navigation and UI tests pass.
Evidence level: The exact physical and software boundary exercised, such as calculation, unit, mock, simulation, HIL, restricted hardware, full hardware, or site.
Physical example:
A real edge computer exchanging CAN frames with an emulator is HIL evidence for compute and bus behavior, not proof of motor torque or braking.
Deviation: A documented difference between required and observed behavior with impact, containment, ownership, disposition, and retest status.
Physical example:
Clock drift exceeds the acceptance bound; activation remains blocked while the cause and corrective test are assigned.
Acceptance baseline: The frozen set of code, firmware, configuration, calibration, hardware identities, environment, procedures, and criteria to which results apply.
Physical example:
Changing a gearbox, encoder mapping, plugin version, or drive firmware invalidates the affected baseline rows and triggers declared regression.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalZero-power electricity bridge: voltage, current, resistance, and power

Before buying, wiring, or energizing hardware, use paper calculations and manufacturer documentation to detect impossible loads, overheated conductors, and incompatible supplies.

V = IR: voltage equals current multiplied by resistanceUnit: volts (V)
P = VI: electrical powerUnit: watts (W)
I: charge flow through one declared pathUnit: amperes (A)

On paper, a documented 12 Ω test load across 24 V would draw I = V/R = 24/12 = 2 A.
Its electrical power would be P = VI = 24×2 = 48 W, so an ordinary low-power resistor would be unsuitable even though the arithmetic is simple.
Stop at the calculation: do not assemble or energize the circuit. Verify ratings, protection, isolation, polarity, grounding, wiring, thermal limits, and a supervised low-voltage commissioning plan with qualified guidance.

Programmer analogy

Types and range checks catch bad values in software; electrical ratings are physical contracts whose violation can create heat, fire, shock, or loss of braking.

On paper, what current would an ideal 10 Ω load draw from 5 V?

I = V/R = 5/10 = 0.5 A; this calculation is not permission to build or energize a circuit.

Checklist completion is

r_{\mathrm{pass}}=\frac{18}{20}=90\%.

Acceptance still fails when either missing item is a mandatory safety gate. Report electrical measurements such as $P=VI$ separately; a power value cannot prove safe behavior.

Decide a twenty-row bring-up gate

A mock-first acceptance matrix has twenty required rows. Eighteen passed at their declared simulation or document-review level. CAL-04 has the wrong joint sign, and SAFE-02 requires qualified emergency-function evidence that this learner run cannot perform.

Verify the denominator and arithmetic: 18 / 20 × 100% = 90% checklist completion. Keep completion separate from acceptance because rows have mandatory classifications and different evidence levels.
Mark CAL-04 failed: the independent reference contradicts the reported sign. Link the raw count table, simulator trace, calibration version, impact on commanded motion, containment, owner, and required corrected rerun.
Mark SAFE-02 blocked — qualified real validation required, not passed from the symbolic state-machine test and not failed merely because the learner lacks authority. Link the responsible safety owner and exact prerequisite procedure.
Review every passing row's scope. Plugin load, read/write conversion, lease expiry, and mock watchdog pass only for the frozen simulation baseline; remove any language implying device timing, torque, stopping, or safety performance.
Issue REJECT / HOLD: one mandatory calibration failure plus one mandatory unavailable safety result prevents hardware acceptance. Do not use the 90 percent summary to override either gate.
Correct the mock sign mapping, create a new calibration version, rerun all dependent frame, limit, and teleoperation rows, and preserve both the original failure and new result; SAFE-02 remains blocked until the qualified external process occurs.
Record an uncut simulated run with baseline, expected checkpoints, one predeclared stale-state fault, terminal state, artifact timecodes, failures, decision, and explicit list of real-world evidence still absent.

Result

The matrix reports 90 percent completion but correctly rejects release, preserves the calibration defect, and separates a learner-blocked safety gate from ordinary simulation evidence.

What this proves

Acceptance is a logical decision over requirement-linked gates and evidence levels, not a percentage, polished video, or majority vote.

Physical examples

Where this appears in real life

Ninety percent but rejected

A checklist contains twenty required rows. Eighteen pass, the calibration-sign row fails, and qualified emergency-stop evidence is not available.

Look for:

The arithmetic completion is 90 percent, yet two mandatory gates remain failed or blocked; the honest decision is reject or hold, not a rounded success.

Continuous mock bring-up recording

An uncut screen recording shows the test manifest, mock identities, plugin lifecycle, calibrated simulator state, leased jog, injected stale read, bounded error response, and final matrix.

Look for:

The video correlates time and artifacts for the simulated scope while title cards state that wiring, power, torque, braking, E-stop, STO, and real load are unverified.

Hands-on exercise

Make the idea observable

Use the Week 22 paper decisions, calculations, manifests, mock plugin, calibration table, and simulator. Keep actuators unpowered and represent all safety functions symbolically.

Create a twenty-or-more-row matrix spanning selection, sizing, power review, identity, firmware, buses, clocks, plugin, calibration, frames, limits, teleoperation, watchdog, shutdown, diagnostics, safety ownership, documentation, and residual defects.
For each row assign requirement ID, evidence level, mandatory status, frozen baseline, initial condition, expected result, observation, artifact, owner, and disposition before running the final rehearsal.
Execute only the unpowered and simulated rows, preserving failed, blocked, not-run, and not-applicable states rather than coercing the matrix to green.
Inject one duplicate device, one stale state, one calibration-sign fault, and one lost teleoperation lease; verify each reaches its predeclared bounded mock outcome.
Calculate completion separately from acceptance, apply mandatory-gate logic, and issue one explicit accept, conditional accept, hold, or reject decision with approver boundaries.
Record one continuous simulator video showing the baseline, nominal path, one injected fault, measured terminal result, linked artifacts, final decision, and real hardware and safety evidence still outstanding.
Ask a reviewer to reproduce three results from raw artifacts and identify one claim whose evidence level is overstated; correct the matrix and rerun only the formally affected rows.

Observe

A rigorous matrix becomes less green and more useful: it exposes which claims stop at calculation, mock, simulation, or HIL and prevents absent qualified evidence from becoming implied success.

Done when

Every requirement maps to a frozen result and artifact, all injected faults are explainable, mandatory-gate logic determines the decision, and the video makes the unpowered or simulated boundary unmistakable.

Build today

Bring up a LeRobot-supported arm or mobile robot with calibration, limits, teleoperation, and emergency stop.

Evidence to save

DONE when the weekly ship note explains how “Hardware acceptance checklist and repeatable bring-up video” changed the build, what still fails, and the first task for next week.

Common mistakes

Catch the wrong mental model

Wrong

Accepting hardware because the checklist percentage is high.

Better

Apply mandatory gates and required evidence levels; one critical failure or unresolved qualified safety requirement can block release regardless of the aggregate.

Wrong

Counting simulation of an E-stop state as validation of the physical emergency function.

Better

Label the state logic as simulation evidence and keep sensing, wiring, safety logic, outputs, stopping, reset, failure performance, and integration pending qualified validation.

Wrong

Editing or discarding the failed run after a correction passes.

Better

Preserve the original baseline, evidence, deviation, corrective change, impact analysis, new version, dependent reruns, and final disposition so the causal history remains auditable.

Job connection

How this becomes employable evidence

Lead a hardware bring-up gate that joins mechanical, electrical, firmware, ROS 2, calibration, operator, safety, support, and test evidence; preserve failures and unavailable qualified checks; and give deployment owners a reproducible decision rather than a demo narrative.

Relevant target roles

Robotics Deployment, Integration & Validation Engineer
Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR
Robot HMI / Control & Monitoring Engineer
Robot Learning Deployment / Physical AI Integration Engineer

Chapter 22 interview drill

Interview questions: Hardware acceptance checklist and repeatable bring-up video

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

Your robot passed eighteen of twenty bring-up checks, but calibration sign is wrong and E-stop validation is unavailable. Decide release, show evidence-level and mandatory-gate logic, explain the retest scope, and design an uncut video that does not overclaim.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1Can 90 percent checklist completion be an acceptance pass?

Model interview answer

Only if the predefined acceptance logic permits it and every mandatory gate passes at the required level; a failed critical row cannot be averaged away.

Q2What must an acceptance result say about simulation or HIL?

Model interview answer

It must name exactly which components and physical effects were real or modeled, what the result establishes, and which loads, motion, energy, environment, or safety behavior remain unverified.

Q3What makes an uncut bring-up video useful evidence?

Model interview answer

A visible frozen baseline, test ID, expected checkpoints, measured observations, time-correlated artifacts, injected fault, terminal state, failures, decision, and explicit evidence boundary.

Chapter starter artifact

Reject an incomplete paper power budget before purchase

Complete a zero-power Bench Zero dossier that compares task-fit candidates, exposes unknown electrical and safety data, runs a mock ros2_control lifecycle and calibration rehearsal, and ends with buy, energize, and move decisions explicitly deferred pending qualified review.

week-22-bench-zero.mjsJavaScriptDownload starter

const requiredFields = ["supplyVoltage", "continuousCurrent", "peakCurrent", "documentedLimit"];
const paperCandidate = { supplyVoltage: 24, continuousCurrent: 3, peakCurrent: 7, documentedLimit: 10 };
const plantedFailure = { supplyVoltage: 24, continuousCurrent: 3, documentedLimit: 10 };
const negativeCurrent = { ...paperCandidate, continuousCurrent: -1 };
const nonfiniteCurrent = { ...paperCandidate, peakCurrent: Infinity };

function paperReview(candidate) {
  const missing = requiredFields.find((field) => candidate?.[field] === undefined);
  if (missing) return "REJECT missing_" + missing.replace(/[A-Z]/g, (c) => "_" + c.toLowerCase());
  const invalid = requiredFields.find(
    (field) => !Number.isFinite(candidate[field]) || candidate[field] < 0,
  );
  if (invalid) return "REJECT invalid_" + invalid.replace(/[A-Z]/g, (c) => "_" + c.toLowerCase());
  if (candidate.peakCurrent > candidate.documentedLimit) {
    return "REJECT documented_limit";
  }
  return "PASS paper_checks";
}

console.log("zero-power baseline: " + paperReview(paperCandidate));
console.log("planted missing-current fault: " + paperReview(plantedFailure));
console.log("negative current: " + paperReview(negativeCurrent));
console.log("nonfinite current: " + paperReview(nonfiniteCurrent));
console.log("next action: VERIFY DOCUMENTATION; DO NOT BUY OR ENERGIZE");

Download the file into your terminal's current folder, then run the command below. The expected output is exact.

Run: node week-22-bench-zero.mjs
Expected output: zero-power baseline: PASS paper_checks planted missing-current fault: REJECT missing_peak_current negative current: REJECT invalid_continuous_current nonfinite current: REJECT invalid_peak_current next action: VERIFY DOCUMENTATION; DO NOT BUY OR ENERGIZE
Planted failure to diagnose: The candidate omits peak current, while companion cases use negative and non-finite current; every malformed power budget fails before purchase or energization.