Capstone: the real-time architecture of a robot joint controller

This capstone brings the course together in one design: the embedded software for a smart joint module of a collaborative robot arm. Each module contains a brushless motor, a gearbox, an absolute encoder on the output side, current sensors, a brake, a temperature sensor and a microcontroller that talks to the arm's main controller over EtherCAT or CAN FD. The task is to turn the module's requirements into a set of interrupts and tasks, choose priorities, show by analysis that every deadline is met with margin, check the end-to-end latency budget, plan memory and protection, define fault handling, and specify how the design will be verified. The approach is the one a real team would follow, and the numbers, while illustrative, are typical of current hardware.

Requirements

The module's timing and safety requirements, agreed with the controls and safety engineers, are:

• R1: the current (torque) loop shall update the PWM duty cycle every 50 µs (20 kHz), synchronized to the PWM centre.
• R2: the velocity and position loops shall run every 250 µs (4 kHz), and the time from encoder sample to updated current reference shall not exceed 120 µs.
• R3: commands from the main controller arrive every 1 ms; the module shall respond with feedback within the same cycle and shall decelerate to standstill if no valid command arrives for 3 ms.
• R4: the safety monitor shall check position, velocity, current and temperature limits every 1 ms and command safe torque off within 2 ms of a limit violation.
• R5: diagnostics and logging shall run at 100 Hz and may be delayed, but shall not delay any other function.
• R6: total processor utilization shall stay below 75 % so that future features fit, and every hard deadline shall have at least 20 % margin in its worst-case response time.

Architecture

The processor is a 480 MHz Cortex-M7 with tightly coupled memory, running FreeRTOS. Following lesson 4's advice, the 20 kHz current loop runs in an interrupt rather than a task, because switching a task in and out 20,000 times a second would waste several per cent of the processor. The encoder is read by SPI with DMA, triggered by a timer, so the read itself costs no processor time. Communication receive is interrupt-driven with a lock-free ring buffer (lesson 7). Everything else runs as RTOS tasks with deadline-monotonic priorities. Safe torque off is implemented in hardware, through a gate-driver enable line driven by both the safety task and an independent window watchdog, so that a software failure cannot prevent it (lesson 11).

The motion task's deadline of 120 µs comes straight from R2: it is released by the encoder DMA interrupt and must produce the new current reference within the budget. Communications gets a 400 µs deadline so that feedback is ready well before the next 1 ms command. Execution times were measured as in lesson 2: maximum over a 24-hour soak with all interfaces at full load and the cache flushed periodically, plus 30 % margin, with context-switch time added for tasks.

Shared data and blocking

The design limits sharing deliberately. The motion task passes the current reference to the current-loop interrupt through a double buffer with an atomic index swap, so neither blocks the other. The communications interrupt passes frames to the communications task through a single-producer single-consumer ring buffer. Two mutexes, both with priority inheritance and used only by tasks, protect the parameter set (critical section 10 µs in the communications task) and the statistics block (critical section 15 µs in the diagnostics task). The motion task reads parameters only through a copy refreshed by the communications task between cycles, so it never takes a mutex. The longest interrupts-disabled section anywhere is 2 µs, in the double-buffer swap, and it is counted as blocking for every interrupt.

Schedulability analysis

With priorities, execution times and blocking terms fixed, response-time analysis (lesson 5) checks every activity, treating interrupts as the highest-priority sporadic tasks.

import math
# name, C, T, D, B (all in microseconds); highest priority first
acts = [
    ("ISR current",      9,    50,    25,  2),
    ("ISR encoder",      3,   250,    20,  2),
    ("ISR comms rx",     4,   100,   100,  2),
    ("motion task",     42,   250,   120,  2),
    ("comms task",     110,  1000,   400, 15),
    ("safety task",     55,  1000,  1000, 15),
    ("diagnostics",    850, 10000, 10000,  0),
]
U = sum(C / T for _, C, T, _, _ in acts)
print("total utilization: %.1f %%" % (100 * U))
worst_margin = 1.0
for i, (name, C, T, D, B) in enumerate(acts):
    R = C + B
    while True:
        nxt = C + B + sum(math.ceil(R / Tj) * Cj for _, Cj, Tj, _, _ in acts[:i])
        if nxt == R or nxt > D:
            R = nxt
            break
        R = nxt
    margin = (D - R) / D
    worst_margin = min(worst_margin, margin)
    print("%-13s R = %5d us  D = %5d us  margin %5.1f %%  %s"
          % (name, R, D, 100 * margin, "ok" if R <= D else "MISS"))
print("smallest margin: %.1f %%" % (100 * worst_margin))

total utilization: 65.0 %
ISR current   R =    11 us  D =    25 us  margin  56.0 %  ok
ISR encoder   R =    14 us  D =    20 us  margin  30.0 %  ok
ISR comms rx  R =    18 us  D =   100 us  margin  82.0 %  ok
motion task   R =    69 us  D =   120 us  margin  42.5 %  ok
comms task    R =   227 us  D =   400 us  margin  43.2 %  ok
safety task   R =   349 us  D =  1000 us  margin  65.1 %  ok
diagnostics   R =  1980 us  D = 10000 us  margin  80.2 %  ok
smallest margin: 30.0 %

Total utilization is 65 %, inside R6's 75 % limit. Every activity meets its deadline with at least 20 % margin, but the analysis exposes one tight spot: the encoder interrupt, whose 20 µs deadline is the shortest in the system, sits below the current-loop interrupt, which is kept highest because it is synchronized to the PWM. Its 30 % margin is the smallest in the system, so adding work to the current-loop interrupt would erode it first. The design notes record this as the first thing to recheck after any change.

End-to-end latency budget

R2 requires 120 µs from encoder sample to new current reference, and the current loop then applies it at its next update. The chain and its worst cases are:

The 98 µs worst case leaves 22 µs, about 18 %, against R2. The full sample-to-torque delay of 148 µs is what the controls engineers use in the velocity-loop design: at a crossover of 150 Hz it costs \( 360^{\circ} \times 150 \times 0.000148 = 8.0^{\circ} \) of phase margin (lesson 1), which they have already included.

# Check the latency budget and the phase cost of the full delay
stages = {"encoder + SPI DMA": 14, "encoder ISR response": 14,
          "motion task": 69, "publish": 1}
to_ref = sum(stages.values())
req = 120
print("sample to current reference: %d us (requirement %d us, margin %.0f %%)"
      % (to_ref, req, 100 * (req - to_ref) / req))
to_torque = to_ref + 50
fc = 150.0
print("sample to torque: %d us; phase cost at %.0f Hz: %.1f deg"
      % (to_torque, fc, 360 * fc * to_torque * 1e-6))

sample to current reference: 98 us (requirement 120 us, margin 18 %)
sample to torque: 148 us; phase cost at 150 Hz: 8.0 deg

Memory and protection plan

All kernel objects are created statically at start-up, and no heap is used after initialization (lesson 8). The current-loop interrupt, the motion task and their data live in tightly coupled memory, so their timing is free of cache effects. Stacks were sized by call-graph analysis with 50 % margin and are monitored by high-water marks reported in diagnostics; the Armv7-M MPU places a guard region below each task stack and gives the communications and diagnostics tasks access only to their own data and the shared buffers, so a parsing bug in communications cannot overwrite the motion task's state. DMA buffers sit in a non-cacheable region.

Fault handling

The hung-software path is the slowest, at up to 14 ms, so the arm's safety concept must not rely on it for fast stops; the faster limit checks in the safety task and the hardware over-current comparator in the gate driver handle the urgent cases, and the watchdog is the backstop for everything else.

Verification plan

The design is verified at several levels, each producing evidence linked back to the requirements:

• Static: MISRA C checks and static analysis on every commit; worst-case stack analysis; review of interrupt priorities and the response-time analysis, rerun automatically from a table of measured WCETs.
• Unit: host tests of the control law, the double buffer, the ring buffer and the supervisor state machine, including fault injection, with structural coverage measured.
• Timing on target: debug-pin and trace measurements of every activity's execution and response time; a 24-hour soak at maximum interface load with overrun counters, high-water marks and maximum response times logged; cyclic comparison of measured maxima against the analysis.
• Hardware in the loop: the controller drives a real-time simulation of the motor, gearbox and arm load; tests inject encoder faults, command dropouts, CAN or EtherCAT errors and stalled tasks, and confirm each reaction and its timing against the fault table.
• System: on the real joint and then the full arm, step responses, stopping distances and safe-torque-off timing are measured and compared with the requirements, under the relevant functional safety process (lesson 11).

Reflecting on the design

The capstone shows the pattern that runs through the course. Requirements are turned into explicit timing numbers. Work is placed where its timing can be guaranteed: hardware for the fastest and most safety-critical paths, interrupts for the next tier, prioritized tasks for the rest, and the main Linux computer for planning and perception (lesson 9). Sharing is minimized and, where it remains, made non-blocking or bounded. Analysis shows the design can work, measurement shows the implementation does, and fault handling and testing show what happens when it does not. The same method scales from a single joint module to a whole robot, where the main controller's real-time Linux, the EtherCAT network and each module's firmware become stages in one end-to-end budget.