Chapter 22 · Bring up real robot hardware through bounded, evidence-led gates
Today in the field story
One problem, then the next
Bench Zero now maps the invisible timing network. MCU interrupts, RTOS tasks, watchdogs, device manifests, CAN or EtherCAT links, local UART, I²C, or SPI devices, Ethernet services, and clock synchronization each receive an owner, deadline, topology, diagnostic, and failure response. You model messages without connecting a bus. Host ROS 2 behavior cannot rescue a missed motor deadline, and a fast field bus cannot correct an unnamed unit or stale timestamp.
- Why now
Hardware integration fails when timing and ownership cross layers without an explicit contract.
- Ignore today
Ignore bus wiring, termination, firmware flashing, and live timing measurements.
- Unlocks next
A mockable device and communication manifest for lifecycle integration.
Understand
Build the physical picture first
The hardware boundary is a timed chain: interrupts capture events, RTOS tasks meet measured deadlines, buses transport versioned state, and the host refuses incompatible devices.
Put work where its deadline and failure consequence can be controlled. A microcontroller close to the actuator can timestamp encoder edges, sample current, run a bounded control task, update outputs, supervise a local watchdog, and expose a compact device protocol. An interrupt service routine should capture the urgent condition and do the minimum required work before deferring parsing, logging, or policy to a task. An RTOS scheduler chooses which ready task runs by its configured rules; it cannot make an infeasible schedule feasible or certify that worst-case interrupt, blocking, execution, and communication time meet a deadline.
Budget time as a chain, not a target frequency. For a 1 kHz task the period is 1 ms. Measure or conservatively bound sensor acquisition, interrupt interference, task release jitter, control computation, output update, bus transfer, queueing, clock conversion, and watchdog service. Record worst observed and designed bounds, missed-cycle counts, and the response when the budget is exceeded. Average loop time can look comfortable while one long flash operation, priority inversion, bus retry, or diagnostic call violates the physical deadline.
Choose each link by scope and required evidence. UART is commonly a simple asynchronous serial point-to-point link; I²C is a clocked, addressed shared local bus; SPI is a clocked controller-selected local interface; CAN is a multi-node field bus with arbitration, acknowledgment, error signaling, retransmission, and fault confinement; ordinary Ethernet provides a network foundation whose application timing depends on the complete stack; EtherCAT adds a defined industrial process-data and distributed-clock architecture. These descriptions are selection prompts, not universal distance, rate, noise, or determinism guarantees.
Make identity and time part of every device contract. A manifest can bind product and serial identity, hardware revision, firmware hash or version, bootloader, protocol version, bus address or device identity, joint mapping, command and state fields, units, sign, limits, update periods, clock domain, calibration version, watchdog behavior, and compatible host range. Startup discovers the expected set, rejects missing, duplicate, unexpected, incompatible, or stale devices, estimates clock offset and drift, and remains motion-disabled until the application contract is coherent. An ordinary communication bus is not a safety-rated channel simply because it is reliable.
Words you need
Name each idea precisely
- Interrupt service routine (ISR)
Code entered asynchronously in response to a hardware or software interrupt, normally kept bounded so time-critical capture does not block other work.
Physical example:An encoder index interrupt stores the timer count and signals a task; it does not format a long log, wait for Ethernet, or run a planner.
- Real-time deadline
The latest acceptable completion time for a response, defined by physical and system needs rather than by how fast the processor usually runs.
Physical example:A current-monitor task must complete its sampled decision before the next 1 ms cycle under the declared interrupt and communication load.
- Bus arbitration
The rule that decides which participant may transmit when multiple devices contend for a shared communication medium.
Physical example:CAN identifiers participate in non-destructive priority arbitration, so traffic design affects latency even when no frame is corrupted.
- Device manifest
A versioned record binding physical identity and firmware to protocol, units, mappings, rates, limits, clock, calibration, and compatibility expectations.
Physical example:The host expects wheel-drive serial D17, hardware revision C, firmware 2.4, protocol 3, two velocity commands in rad/s, and two position states in radians.
- Clock offset and drift
Offset is the difference between two clocks at an instant; drift is how that difference changes, both of which affect timestamp alignment and freshness.
Physical example:An encoder sample timestamped by the MCU can appear fresh on the host while actually being 12 ms old if clock conversion uses an outdated offset.
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.
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.
The loop budget is
Measured work is , so
Audit a 1 kHz firmware and bus budget
A mock actuator MCU has a 1 ms control period. Measured conservative stage values are 0.18 ms sensing, 0.31 ms control computation, 0.22 ms command and state transfer, and 0.17 ms worst accounted interrupt and scheduling interference.
Convert frequency to period:
1 / 1,000 s = 0.001 s = 1.00 ms; name the release clock, completion point, and physical consequence of a late cycle.Add the accounted work:
0.18 + 0.31 + 0.22 + 0.17 = 0.88 ms, leaving1.00 - 0.88 = 0.12 msof modeled margin rather than calling processor utilization simply 88 percent.List what the 0.12 ms does not yet cover: measurement uncertainty, cache or flash variation, interrupt bursts, shared-resource blocking, RTOS overhead, bus arbitration, retransmission, clock conversion, and any branch triggered only on a fault.
Draw one timeline with timer release, ISR capture, control task, bus task, output update, watchdog service, and diagnostics. Move formatting and noncritical telemetry out of ISR and control contexts.
Create a bus table for CAN, EtherCAT, UART, I²C, SPI, and Ethernet with intended endpoints, topology, electrical layer or transceiver, nominal payload, required period, maximum age, diagnostics, clock owner, termination or chip-select responsibility, and failure response.
Create a manifest for two mock drives and deliberately introduce a duplicate bus identity, incompatible protocol version, and stale clock. Require startup to remain disabled and produce a distinct reason for each.
Inject a simulated deadline miss, error frame or bus-off event, link loss, and clock jump; preserve detection time, last trusted state, response, and recovery rule without claiming the mock proves physical or safety timing.
The stated tasks consume 0.88 ms of a 1 ms modeled cycle, but only an explicit coverage ledger and fault response prevent the remaining 0.12 ms from becoming unjustified confidence.
A real-time architecture is credible when deadlines, scheduling interference, transport behavior, identity, time, and overruns are measured and closed, not when an RTOS or fast bus appears in the block diagram.
Physical examples
Where this appears in real life
Motor-controller timeline
A timer releases a 1 kHz control task; an encoder ISR captures edges; a communication task handles CAN state; a lower-priority diagnostic task formats counters.
The ISR remains short, the control task has measured worst-case execution and blocking, diagnostics cannot starve it, and every missed deadline increments an observable counter and enters a declared response.
Local sensors and coordinated drives
An MCU reads a short-board-distance temperature sensor over I²C and an encoder interface over SPI, while multiple drive devices exchange process state on a field bus and the host publishes noncritical diagnostics over Ethernet.
Each interface has a distinct topology, timing, electrical layer, ownership, identity, fault behavior, and clock contract; one successful packet does not prove suitability for the other links.
Hands-on exercise
Make the idea observable
Use index cards, a timeline spreadsheet, and a small deterministic simulation or recorded trace. Do not flash an MCU, connect a transceiver, attach a battery, or probe any powered board.
Create cards for timer ISR, encoder capture, current sample, control update, bus receive, bus transmit, watchdog, and diagnostics; assign owner, release condition, deadline, and maximum execution assumption.
Arrange a 1 ms timeline, add the stage times, then inject one longer interrupt and one blocked shared resource; mark which deadline fails and what evidence detects it.
Build a protocol-choice table for CAN, EtherCAT, UART, I²C, SPI, and Ethernet using only verified documentation; write
platform-dependentrather than inventing universal rates or distances.Write two versioned mock device manifests with identities, firmware, protocol, units, mappings, periods, clocks, calibration, limits, and safe application default.
Shuffle, remove, duplicate, or age device cards and run the startup decision by hand; no mismatch may reach the mock
enablestate.Replay nominal, missed-deadline, corrupt-frame, bus-off, link-loss, and clock-jump records and ensure each ends in an explicit detected, degraded, disabled, recoverable, or review-required state.
Most hidden uncertainty sits between the boxes: ISR work, queueing, physical transceivers, bus contention, timestamp conversion, duplicate identity, and recovery after a device responds differently than expected.
Every scheduled activity and link has a bounded contract, the manifest rejects all injected incompatibilities before simulated enable, and no bus or RTOS label is presented as timing or safety proof.
Build today
Bring up a LeRobot-supported arm or mobile robot with calibration, limits, teleoperation, and emergency stop.
Evidence to save
DONE when a deterministic “MCU firmware and RTOS basics; CAN, EtherCAT, UART, I²C, SPI, Ethernet, device manifests, and clock synchronization” failure test reports expected versus actual behavior and passes after the documented fix.
Common mistakes
Catch the wrong mental model
Assuming an RTOS makes firmware deterministic.
Define deadlines, measure worst-case execution and interference, bound blocking and interrupt work, count misses, and test the designed late-cycle response under representative load.
Choosing a bus from nominal bit rate alone.
Compare topology, physical layer, payload and overhead, arbitration, device ecosystem, diagnostics, timing, clock, cabling, fault handling, and the complete required application contract.
Activating because every expected device returned some response.
Verify exact identity, revision, firmware and protocol compatibility, joint mapping, units, limits, calibration, rates, clock health, and absence of duplicate or unexpected devices.
Job connection
How this becomes employable evidence
Partition a robot's MCU and host workload, review ISR and RTOS timing, define versioned device manifests across local and field interfaces, diagnose bus and clock faults, and make incompatible or stale hardware fail closed before ros2_control activation.
Relevant target roles
- Robotics Software Engineer — ROS 2 / AMR
- Robotics Application / ROS 2 Integration Engineer
- Robotics Deployment, Integration & Validation Engineer
Chapter 22 interview drill
Interview questions: MCU firmware and RTOS basics; CAN, EtherCAT, UART, I²C, SPI, Ethernet, device manifests, and clock synchronization
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
Design the firmware-to-ROS boundary for four drives and local sensors. Place interrupts and tasks, choose and justify buses without universal claims, budget one control period, handle identity and clock drift, and explain the response to bus-off or a missed deadline.
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
Q1What does a positive average deadline margin fail to prove?
It does not cover worst-case execution, interrupt bursts, blocking, retries, queueing, clock error, rare fault branches, or the correctness of the overrun response.
Q2Why can a responsive device still be unsafe to activate?
It may be the wrong device or revision, use incompatible message layouts, units, limits, mapping, calibration, timing, clock, or fault semantics, or duplicate another identity.
Q3Does a robust ordinary CAN or EtherCAT link automatically carry a safety function?
No. Functional safety requires the appropriate safety architecture, qualified components and protocol, risk-derived performance, integration, verification, and validation; ordinary communication success is insufficient.