Real-Time Constraints

In most software, a program is correct if it produces the right output — timing is a matter of user experience, not correctness. In robotics, this is not true. A robot arm control loop that computes the right motor command but delivers it 50 ms late can overshoot its target, oscillate, or strike a human. Timing is a correctness requirement, not a performance metric. Understanding real-time constraints — where they come from, how to quantify them, and how to guarantee they are met — is a foundational skill for robot engineers.

What Makes a System Real-Time?

A real-time system is one in which the correctness of a computation depends not only on its logical result but also on the time at which that result is produced. Each computation has a deadline: a moment after which the result is too late to be useful or safe. Real-time requirements arise wherever a physical process evolves faster than the time budget allows for computation. A servo motor position controller must command current to the motor coils before the rotor overshoots its target — the physical dynamics of the motor set the deadline. A drone attitude controller must correct for wind gusts before the drone's attitude diverges unrecoverably — the aerodynamic dynamics set the deadline. A medical robot performing surgery must detect unexpected tissue contact and halt before force exceeds safe limits — the tissue response time sets the deadline. The deadline must be derived from a physical model, not guessed. An attitude controller for a drone with a time constant of 50 ms (the time for the attitude error to grow e-fold without correction) must run at least 10 times faster than the time constant — roughly every 5 ms. This is the rule of thumb: the control update rate must be at least 10x the closed-loop bandwidth to avoid degraded stability margins.

Latency: Where Time Is Lost

Latency is the total elapsed time from when a physical event occurs to when the system responds to it. It is the sum of all delays in the pipeline: Sensor acquisition latency: the time from when the physical quantity changes until the sensor's digital output reflects the change. A camera with a 30 ms exposure time adds at least 30 ms of latency before an image is even available to process. Data transfer latency: the time to move data from the sensor to the processor. USB 3.0 transfer latency is microseconds; a long CAN bus with many nodes can add milliseconds of arbitration delay. Computation latency: the time for the algorithm to run. A deep neural network for object detection might take 10–50 ms on a mobile GPU. A simple PID controller takes microseconds on a microcontroller. Actuator response latency: the time from when the motor command is issued to when the actuator physically responds. A servo motor with a 10 ms current-control loop adds 10 ms; a hydraulic valve may add 5–20 ms of valve response time. The total end-to-end latency is the sum of all pipeline stages. A system with 30 ms camera latency, 2 ms transfer, 15 ms neural network, 5 ms planning, and 5 ms actuator response has 57 ms of end-to-end latency. For a robot arm moving at 2 m/s, 57 ms of latency means the robot is responding to a state that is 114 mm out of date.

Scheduling, Jitter, and Deadline Guarantees

Guaranteeing that a task meets its deadline requires controlling when it runs. The relevant parameters are: Period (T): how often a periodic task executes. A motor controller with a 1 ms period executes 1,000 times per second. Worst-case execution time (WCET): the maximum time the task can take to complete under any input and processor state. WCET analysis is a formal discipline; for safety-critical systems it involves static analysis of every code path or exhaustive measurement. Deadline (D): the time by which execution must complete after the task is triggered. For a task to be schedulable, it must satisfy D >= WCET and the processor must not be over-committed. If the sum of (WCET / Period) across all real-time tasks exceeds 1.0, the processor cannot guarantee all deadlines — a condition called CPU overload. Jitter is the variation in the actual start or completion time of a periodic task relative to its nominal schedule. A motor controller with a nominal 1 ms period might have 50 microsecond jitter — it sometimes runs at 0.95 ms, sometimes at 1.05 ms. Small jitter is usually acceptable; large jitter causes control performance degradation and must be bounded. Rate-monotonic scheduling (RMS) is a classical algorithm for assigning CPU priorities to periodic real-time tasks: shorter-period tasks get higher priority. Under RMS, a set of tasks is provably schedulable if the total CPU utilization does not exceed approximately 69% for many tasks.