FixTheRobot Explore Robotics / Systems Engineering / Engineering Guides / Module 04

Engineering Guides · Module 04

Real-time Linux and RTOS basics for robots

Real-time means meeting deadlines predictably, not running fast. Check utilisation against a bound and measure the jitter.

  • Intermediate
  • Module 04: Embedded Systems & Hardware Interfaces
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-06

Assumptions: Numbers in the examples are illustrative and the code is executed by the site’s tests. Facts taken from a cited source are marked; other statements are general engineering knowledge and must be confirmed on the datasheet of the part you use.

1. Engineering problem

A control loop that sometimes runs late can make a robot unstable. General-purpose Linux optimises throughput, not worst-case latency; an RTOS or a real-time kernel configuration provides priorities and bounded behaviour.

2. When is this needed?

  • Running a control loop at 500 Hz to 1 kHz or above.
  • When a loop shows period jitter under load.
  • When choosing between an RTOS and a real-time Linux kernel.

3. Selection and design decisions

Rate-monotonic scheduling gives the shortest-period task the highest priority. For n independent periodic tasks, a utilisation of at most n(2^(1/n) − 1) guarantees all deadlines, and this bound tends to ln 2 (about 0.693) as n grows (Wikipedia, rate-monotonic scheduling, read 2026-11-06). Exceeding the bound does not mean failure; exact analysis is then needed.

OptionStrengthsWeaknesses
RTOS on a microcontroller (for example FreeRTOS, Zephyr)Small, bounded latency, direct hardware accessLimited resources and tooling
Linux with the PREEMPT_RT patch setReal-time priorities with a full OS and ROS 2Needs a tuned kernel; drivers and power management can still add latency
Standard Linux with real-time prioritiesEasiest to tryNo hard guarantee under load
Separate microcontroller for the loopIsolates timing from the computerNeeds an interface and a protocol

4. Advantages and disadvantages

  • Hard real-time (deadline miss is a failure) needs an RTOS or a dedicated controller; soft real-time tolerates occasional misses.
  • Locking memory and pinning threads to cores reduces latency and costs flexibility.
  • More tasks need a stricter utilisation limit.

5. Requirements and constraints

  • Utilisation below the bound, or an exact response-time analysis.
  • No blocking calls, memory allocation or logging in the control thread.
  • Jitter measured under full system load, not at idle.

6. Architecture

timer interrupt ─▶ high-priority control thread (fixed period, no allocation) ──▶ actuator
lower-priority threads: logging, ROS 2 publishing, diagnostics

7. Implementation

  1. List the periodic tasks with period and worst-case execution time.
  2. Compute utilisation and compare with the bound (below).
  3. Give shorter periods higher priorities.
  4. Remove allocation, locks and logging from the control path.
  5. Measure the period error under full load with timestamps or a tool such as cyclictest (from the rt-tests package) and compare with the requirement.
def rm_bound(n):
    return n * (2 ** (1 / n) - 1)
tasks = [(0.001, 0.0002), (0.005, 0.001), (0.020, 0.004)]   # (period s, worst-case run time s)
u = sum(c / t for t, c in tasks)
print(f"utilisation {u:.3f}, rate-monotonic bound for {len(tasks)} tasks {rm_bound(len(tasks)):.3f}", "-> schedulable" if u <= rm_bound(len(tasks)) else "-> not guaranteed")
stamps = [0.0, 0.0100, 0.0201, 0.0299, 0.0400, 0.0512]
jit = [round((b - a - 0.01) * 1000, 2) for a, b in zip(stamps, stamps[1:])]
print("period error (ms):", jit, "max", max(abs(j) for j in jit))

Printed (checked by the site’s tests):

utilisation 0.600, rate-monotonic bound for 3 tasks 0.780 -> schedulable
period error (ms): [0.0, 0.1, -0.2, 0.1, 1.2] max 1.2

Reading it: three tasks use 60 % of the CPU against a bound of 0.78 for three tasks, so they are schedulable under rate-monotonic priorities. The jitter line shows a period error of 1.2 ms on a 10 ms loop in the last sample, which would need investigation if the requirement is tighter. All numbers are illustrative; measure your own.

8. Real examples

  • Wheel velocity loop: a 1 kHz task on a microcontroller RTOS; ROS 2 on Linux sends setpoints at 50 Hz.

9. Failure scenarios

  • A control thread that allocates memory and misses deadlines when the garbage collector or allocator runs.
  • Priority inversion through a lock shared with a low-priority thread.
  • Latency tested at idle and not under load.

10. Troubleshooting

  1. Measure the maximum period error under load.
  2. Check CPU frequency scaling and power-saving states.
  3. Check interrupts and other threads on the same core.

11. Validation

  • The example prints the lines shown (executed by the site tests).
  • Measured maximum period error under full load is within the requirement over at least an hour.

12. Engineering checklist

13. Further references

Related on FixTheRobot