Chapter 22

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

Turn a capstone design into a reviewable hardware bring-up plan without treating a purchased robot, a responsive device, or first motion as proof of readiness. This chapter chooses a platform backward from a frozen task; sizes actuator, encoder, supply, wiring, and thermal operating points; separates MCU deadlines and field buses from host ROS 2 behavior; implements a mock-first ros2_control hardware component; calibrates joint meaning and rehearses leased low-speed teleoperation in simulation; distinguishes ordinary software stops from independently engineered emergency and Safe Torque Off functions; and closes with a mandatory-gate acceptance pack whose unknowns and failures remain visible.

Before you start

Complete the earlier dynamics, feedback, Linux, ROS 2 graph, URDF, transforms, ros2_control, simulation, validation, agent-safety, and scenario-evaluation chapters; this week integrates those contracts at the physical boundary rather than reteaching them.
Bring a frozen capstone task statement, a simulated or mock robot model, one known-good no-motion startup path, a risk and requirements ledger, and official documentation for any platform being considered. No purchase or powered connection is required.
Be able to distinguish requested command, accepted command, measured state, physical outcome, and safety-function evidence; read voltage, current, torque, speed, temperature, encoder, timing, and interface units without silently converting them.
Keep learner exercises unpowered, paper-based, or simulated. Any inspection inside electrical equipment, energization, joint motion, E-stop or STO validation, load test, or change to a safety parameter requires the manufacturer procedure, the responsible qualified people, an approved test area, and the site's risk controls.

By the end

Write a task-first hardware specification with mandatory safety, support, environment, maintainability, payload, reach, sensing, interface, power, and evidence gates, then compare documented candidates without converting unknowns into passes.
Build separate continuous, peak, thermal, torque-speed, encoder, electrical-power, energy, cable, connector, and protection budgets whose assumptions and margins can be reviewed before any hardware is energized.
Partition MCU interrupts, RTOS tasks, watchdogs, device manifests, CAN or EtherCAT links, local UART/I²C/SPI, Ethernet, and time synchronization by ownership, deadline, topology, diagnostics, and failure response.
Implement and test a mock ros2_control Actuator, Sensor, or System component with declared command and state interfaces, validated configuration, lifecycle behavior, bounded read and write work, explicit faults, and safe application outputs.
Version an encoder-to-joint calibration, verify joint identity, sign, zero, scale, limits, and frames against independent references, and rehearse one-axis leased teleoperation with bounded increments and measured stop evidence in simulation.
Explain why a UI stop, ROS cancellation, ordinary watchdog, E-stop, STO, electrical isolation, braking, and holding are different functions, and route every safety claim to qualified risk assessment, implementation, and validation.
Publish a repeatable acceptance matrix and uncut low-risk evidence run that links every requirement to configuration, expected result, observed result, artifact, owner, deviation, and explicit accept, conditional accept, or reject decision.

The field story

Bench Zero Hardware Dossier

The Courier-17 gate has produced requirements for workspace, command limits, freshness, diagnostics, stopping behavior, and evidence. At Bench Zero, nothing is plugged in. Your mission is to translate those requirements into a hardware dossier using manufacturer documentation, paper calculations, mock interfaces, and simulation. Candidate platforms remain candidates: a responsive USB device, an attractive arm, or a seller's payload figure is not proof that the complete task, support path, electrical budget, or safety concept is acceptable. Unknown values stay marked unknown, and no purchase decision is allowed to outrun the evidence.

Bench Zero advances from task-first selection through actuator and power budgets, MCU and bus ownership, mock ros2_control lifecycle behavior, calibration rehearsal, and stop-function distinctions. Every learner exercise remains zero-power, disconnected, or simulated. Opening electrical equipment, selecting protection, energizing a supply, moving a joint, or validating an E-stop or Safe Torque Off function is explicitly deferred to manufacturer procedures, qualified people, an approved area, and site controls. The finish is an acceptance dossier and a no-motion evidence run, not a first-motion video or encouragement to buy hardware before prerequisites and support are verified.

Why this chapter now: The Week 21 gate defines what the capstone hardware must support. Translating those needs before purchase prevents attractive components from dictating an unsafe or unsupported task.
Ignore for now: Do not buy equipment, connect a supply, open electrical enclosures, move a joint, validate protective functions, or interpret paper calculations as permission to energize.
This unlocks: A task-shaped mock hardware contract, calibration identity, and acceptance ledger that Week 23 can use for safe simulation-first data collection.
Proof you will leave with: A requirements ledger, dated manufacturer sources, candidate comparison with unknowns, torque-speed and electrical budgets, interface ownership map, mock lifecycle logs, calibration rehearsal, stop-function matrix, and zero-power acceptance decision.

Environment contractrepository-supported Node.js 22.13.0 or newer, paper specifications, manufacturer documentation, a mock robot description, and simulation only; supplies remain disconnected and no purchase, wiring, energization, or motion is required.

Compatibility boundary: The starter checks documentation completeness, not electrical design or platform safety. Real voltage, current, wiring, protection, actuator, E-stop, STO, load, or thermal work requires the exact hardware documentation and qualified application-specific review.
Smoke check: Run node week-22-bench-zero.mjs; confirm the documented paper case passes, the planted missing peak-current value is rejected, and the output explicitly prohibits buying or energizing.
Contract reviewed: 2026-07-25
Runtime evidence: The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
Drift risk: high

Today in the field story

One problem, then the next

Bench Zero starts with Courier-17's frozen task and Week 21 gate, not a shopping page. You turn workspace, payload, reach, sensing, support, maintainability, interfaces, environment, stopping expectations, and evidence needs into mandatory and preferred rows. Each candidate receives pass, fail, or unknown only from dated documentation. An unknown cannot become a pass because the product is popular. Buying is deferred until task fit, local support, replacement parts, integration effort, and unresolved safety prerequisites receive explicit owners.

Why now: Task-first selection prevents hardware features from redefining the capstone after purchase.
Ignore today: Do not compare prices or order a platform before mandatory gates close.
Unlocks next: A reviewable shortlist with unknowns and rejection reasons intact.

Understand

Build the physical picture first

Hardware selection is a requirements gate: the winning platform is the least uncertain complete fit for one task, environment, support model, and controlled-risk boundary.

Freeze the work before comparing machines. Name the object and tool masses, center-of-mass range, reachable poses, approach directions, floor or bench geometry, cycle-time target, repeatability tolerance, sensing conditions, operator interaction, expected hours per day, contaminants, temperature, transport, and maintenance access. Separate required values from desirable values and state how each will be measured. A platform is not suitable merely because its maximum payload and reach exceed two numbers in a brochure; it must complete the whole task inside its documented operating envelope.

Make safety, support, and evidence mandatory gates rather than small weighted preferences. Ask which hazards the application creates, which safeguards and operating modes the manufacturer supports, which manuals and declarations are available, who may integrate and validate the system, how emergency and energy-isolation functions are handled, and what training the site requires. Also inspect software support, firmware availability, ROS 2 or vendor APIs, interface stability, diagnostic access, calibration workflow, replacement parts, repair lead time, warranty boundaries, and whether the exact hardware revision is still supported.

Compare like with like. Payload includes object, gripper, adapter, cables, and any off-axis moment; reach must cover approach and retreat with joint and collision margin; accuracy is closeness to a commanded absolute pose while repeatability is consistency when returning; headline speed may apply only under a restricted load or trajectory. For a mobile base, payload, grade, floor transition, wheel traction, braking, turning envelope, localization sensors, battery duty, charger behavior, and docking all interact. Record the test condition attached to every published number.

Use a two-stage decision record. First reject any candidate that fails a mandatory task, environment, support, or safety requirement. Then score the remaining evidence with declared weights and confidence. Mark absent or incomparable data as unknown, attach an owner and verification method, and run sensitivity analysis: if a small weight change reverses the ranking, the decision is fragile. The deliverable is not a shopping recommendation; it is a traceable short list, explicit unknowns, and a no-buy boundary until the high-impact unknowns close.

Words you need

Name each idea precisely

Task envelope: The complete set of loads, poses, paths, rates, environmental conditions, interactions, and terminal outcomes that the hardware must support.
Physical example:
A tabletop arm must lift a 0.8 kg part plus 0.35 kg gripper, approach two fixtures from above, avoid a 120 mm wall, and repeat the placement within the declared tolerance for a four-hour shift.
Mandatory gate: A requirement whose failure or unresolved evidence blocks selection regardless of the candidate's weighted score elsewhere.
Physical example:
A platform with no approved way to implement the required guarded operating mode is rejected even if it is cheaper and faster.
Accuracy: Closeness of the measured physical result to the commanded or true reference under stated test conditions.
Physical example:
Ten commanded visits to a surveyed fixture may cluster tightly yet remain 6 mm away, indicating good repeatability but poor absolute accuracy.
Repeatability: Consistency of repeated physical results under the same declared approach, load, configuration, and environment.
Physical example:
The tool returns within a 0.4 mm spread when approaching the same point from one direction, without proving the point is globally accurate.
Evidence confidence: A declared assessment of how directly a source, test condition, revision, and measurement support one selection claim.
Physical example:
A current manual for the exact model and load condition is stronger evidence than an unsourced reseller table for an older revision.

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.

Payload capacity margin is

m_c=\frac{m_{\mathrm{rated}}-m_{\mathrm{required}}}{m_{\mathrm{required}}}=\frac{1.5-1.0}{1.0}=50\%.

Electrical power is $P=VI=(12\,\mathrm{V})(3\,\mathrm{A})=36\,\mathrm{W}$ . Neither calculation covers reach, duty cycle, support, or safety.

Gate and rank two documented tabletop platforms

A task needs a 1.0 kg object, 0.25 kg tool, 520 mm effective reach, four hours of intermittent use, a documented ROS 2 integration route, and an approved integration path for the site's required safeguards. Candidate A lists 1.5 kg payload and 600 mm reach; Candidate B lists 2.0 kg and 540 mm. Several conditions differ.

Write the required moving mass as 1.0 + 0.25 = 1.25 kg, then attach the required center-of-mass range, pose, acceleration, and duty condition; do not compare 1.25 kg with an unspecified maximum-payload headline.
Compute only a preliminary mass margin: A has (1.5 - 1.25) / 1.25 = 20%; B has (2.0 - 1.25) / 1.25 = 60%. Label both provisional until moment, speed, thermal, and tool limits are checked.
Gate reach using the complete approach model. A has 80 mm nominal radial margin and B has 20 mm, but mark both unresolved until the actual wrist orientation, tool length, joint limits, fixture collision, and retreat path are modeled.
Create mandatory rows for exact model revision, payload condition, environment, safeguard integration, emergency and reset behavior, electrical requirements, support region, spares, firmware, diagnostics, calibration, and approved ROS-facing interface. Reject any confirmed gate failure and assign owners to unknowns.
For candidates still eligible, score task fit, maintainability, integration evidence, service life, cost of ownership, and delivery confidence using weights frozen before viewing the final totals; cite the evidence cell used for each score.
Repeat the total with each non-mandatory weight varied by plus and minus 20 percent. If the winner changes, record the decision as sensitive and close the highest-leverage unknown rather than reporting false precision.
End with short-list, hold, or reject plus a verification plan. Neither the 20% nor 60% preliminary payload margin authorizes purchase, mounting, electrical connection, or motion.

Result

The decision record preserves task conditions, distinguishes hard gates from preferences, exposes incomparable specifications, and keeps both candidates on hold until reach, safeguard, and operating-condition evidence closes.

What this proves

A useful selection matrix eliminates incomplete systems first and ranks only the candidates whose evidence supports the whole task.

Physical examples

Where this appears in real life

Arm that reaches but cannot approach

Candidate A advertises 900 mm reach and can touch a fixture point in a simplified drawing, but its wrist and gripper collide with a wall along the required vertical approach.

Look for:

Reach to a point is not path feasibility; include tool geometry, approach direction, joint margin, cable routing, collision volume, retreat, and the loaded operating condition.

Repairable rover versus impressive prototype

Candidate B is slower on paper but publishes wiring, firmware support, spare-wheel and battery procedures, diagnostics, and regional service; Candidate C has a higher top speed but an unclear API and no replacement-part plan.

Look for:

Availability, maintainability, interface evidence, and safe service procedures can dominate a small performance advantage over the system's intended life.

Hands-on exercise

Make the idea observable

Use two manufacturer datasheets or archived product manuals, paper silhouettes or CAD screenshots, and a spreadsheet. Do not order, mount, connect, open, energize, or move either product.

Write one measurable capstone task envelope with payload composition, center-of-mass assumption, workspace, approach, tolerance, cycle, duty, environment, operator, maintenance, and safe terminal state.
Create at least ten mandatory gates spanning task fit, documentation, support, electrical compatibility, integration, diagnostics, calibration, safeguards, emergency behavior, and serviceability.
Extract only values that name the exact product revision and test condition. Put the source page and unit beside each value, and write unknown where the source is silent.
Trace the tool silhouette through three critical poses on paper or in a disconnected model; mark reachable point, approach, retreat, singular or joint-limit concern, collision, and cable clearance separately.
Score only candidates that have no confirmed gate failure, run one weight-sensitivity check, and identify the three unknowns most likely to change the decision.
Ask another learner to audit five cells back to their source and to challenge one hidden assumption; revise the record without turning an unresolved item into a pass.

Observe

The apparent winner often changes when payload conditions, approach geometry, documentation quality, support lifetime, and unknown evidence receive the same attention as headline reach and price.

Done when

Every selection claim names a source and condition, mandatory gaps visibly block purchase, rankings survive or disclose sensitivity, and the output contains no instruction to power or test physical equipment.

Build today

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

Evidence to save

DONE when the learning log explains “Choose hardware from task, support, and safety constraints” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Selecting the platform with the largest maximum payload and reach.

Better

Model the full tool-plus-object load, center of mass, motion, duty, approach, collision, environment, interfaces, support, and safeguards under the published test conditions.

Wrong

Giving an unknown safety or support row a neutral score so the candidate can remain competitive.

Better

Make high-consequence evidence a mandatory gate, label the row unknown, assign a closure owner, and block selection until the required proof exists.

Wrong

Treating repeatability and accuracy as interchangeable evidence.

Better

Ask how each value was defined and measured; consistent returns can still share one absolute offset, and one accurate result does not establish repeatability.

Job connection

How this becomes employable evidence

Translate a customer task into a cross-discipline robot specification, challenge vendor claims against exact operating conditions, preserve unknowns and lifecycle costs, and produce a short list that safety, mechanical, electrical, software, service, and validation owners can sign or reject.

Relevant target roles

Robotics Application / ROS 2 Integration Engineer
Robotics Deployment, Integration & Validation Engineer
Robot Learning Deployment / Physical AI Integration Engineer

Chapter 22 interview drill

Interview questions: Choose hardware from task, support, and safety constraints

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

Two arms meet payload and reach on their landing pages. Walk through the mandatory gates, comparable evidence, geometry checks, support questions, unknown-data treatment, and decision record you require before recommending either platform.

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

Q1Why is a 50% payload-rating margin not enough to select an arm?

Model interview answer

The rating may depend on center of mass, pose, speed, acceleration, duty, tool moment, and environment, while reach paths, accuracy, support, interfaces, and safety remain separate gates.

Q2What happens when a required manufacturer value is absent?

Model interview answer

Record it as unknown with its decision impact, source searched, owner, and verification method; do not infer a pass or silently substitute another model.

Q3When should a weighted score be calculated?

Model interview answer

Only after candidates with confirmed mandatory-gate failures are removed and high-impact unknown gates are either closed or explicitly hold the decision.

Chapter references

Zephyr Project — kernel and hardware documentationVendor-neutral embedded reference for priority-based scheduling, interrupt context, timing and watchdog services, device descriptions, and CAN, UART, I²C, SPI, Ethernet, and other peripheral interfaces; the chapter uses these as interface concepts, not as a claim that one RTOS or driver automatically meets a deadline.
CAN in Automation — CAN CCIndependent CAN industry association material for frame-level error detection, acknowledgment, retransmission, error signaling, and fault confinement including bus-off; application semantics, freshness, termination, timing, and recovery still belong to the system design.
EtherCAT Technology Group — EtherCAT CompendiumOfficial technology-group reference for EtherCAT physical and data-link concepts, device identity and state machine, process data, diagnostics, distributed clocks, synchronization, conformance, and the separate existence of safety technology.
ros2_control Jazzy — Writing a Hardware ComponentMaintainer instructions for Actuator, Sensor, and System interfaces; lifecycle callbacks; configuration validation; command and state interfaces; read and write ownership; pluginlib export; load tests; diagnostics outside the real-time path; and mock-first component development.
Schneider Electric — STO prerequisites and requirementsManufacturer safety documentation establishing that STO removes torque-producing power to the motor but not hazardous voltage from the DC bus, can allow coast-down, and may require an external safety-related brake; used only for awareness, never as a universal circuit or validation procedure.