In a digital robot controller, the continuous-time control law is executed as a periodic task on a processor. Ideally, the loop executes every \( h \) seconds exactly, with negligible computation time, and samples plus actuates at perfectly periodic instants. A typical control loop is:

• Read joint sensors (encoders, IMUs, force-torque sensors).
• Estimate state (possibly via an observer from Chapter 11).
• Evaluate control law (e.g., computed torque, impedance, MPC).
• Write commands to actuators (currents, torques, PWM).

Real systems are imperfect. Let \( t_k \) be the time of the \(k\)-th sampling instant. Instead of \( t_k = k h \), we have

\[ t_k = k h + \delta_k,\quad k = 0,1,2,\dots \]

where \( \delta_k \) is the sampling jitter. There may also be actuation jitter (variation of the time when the actuator actually receives the command) and execution-time variations. These timing uncertainties arise from:

• Preemption by other tasks (logging, communication, planning).
• Cache misses, interrupts, and OS scheduling overhead.
• Bus contention (e.g., CAN, EtherCAT) and sensor latency.

From the viewpoint of control, jitter effectively perturbs the sampling period and introduces time-varying delays, which modifies the discrete-time closed-loop dynamics derived in previous lessons.

flowchart TD
  CLK["Hardware timer"] --> SCHED["Real-time scheduler"]
  SCHED --> CTL["Control task (periodic)"]
  SCHED --> SENS["Sensor task (aperiodic/event-driven)"]
  SCHED --> LOG["Logging / UI (low priority)"]
  SENS --> CTL
  CTL --> ACT["Robot actuators"]

  LOG --> PRE["Preemption / overload"]
  PRE -.-> CTL

  SCHED --> POL["Priority / policy"]
  POL --> JIT["Jitter in start times"]
  JIT -.-> CTL
  

In real-time scheduling, each software component (control loop, state estimator, logger) is modeled as a task. For robots, the primary control loop is typically a periodic hard real-time task, while logging and diagnostics are soft real-time tasks.

A standard periodic task model characterizes task \( i \) by

\[ \tau_i = (C_i, T_i, D_i, \phi_i),\quad i=1,\dots,n, \]

where:

• \( C_i \): worst-case execution time (WCET).
• \( T_i \): period (minimum inter-arrival time).
• \( D_i \): relative deadline.
• \( \phi_i \): release offset (phase).

The utilization of task \( i \) is \( U_i = C_i / T_i \). The total CPU utilization of a task set with \( n \) tasks is

\[ U = \sum_{i=1}^{n} U_i = \sum_{i=1}^{n} \frac{C_i}{T_i}. \]

For a typical robot:

• Joint control task: \(T_c \) in the order of 0.5–2 ms (kHz loop).
• State estimation task: \(T_e \) in the order of 2–5 ms.
• High-level planning: \(T_p \) in the order of 50–200 ms.
• Logging/monitoring: \(T_l \) in the order of 10–100 ms.

These tasks share the same CPU. To guarantee that control deadlines are always met, we must analyze the schedulability of this task set under a chosen scheduling policy.

Hard real-time: missing a deadline is considered a system failure (e.g., inner torque loop for a high-speed manipulator). Soft real-time: occasional deadline misses are tolerable (e.g., GUI updates, non-critical logging).

Two fundamental scheduling policies for independent, preemptive, periodic tasks with deadlines equal to periods (\(D_i = T_i\)) are:

• Rate-Monotonic (RM): static priority, shorter periods get higher priority.
• Earliest-Deadline-First (EDF): dynamic priority; at each instant the task with the earliest absolute deadline runs.

3.1. Rate-Monotonic Utilization Bound

For RM, Liu and Layland established a sufficient condition for schedulability of \( n \) periodic tasks:

\[ U \le U_{\text{RM}}(n) \equiv n\bigl(2^{1/n} - 1\bigr). \]

The bound \( U_{\text{RM}}(n) \) is decreasing in \( n \) and converges to \( \ln(2) \approx 0.693 \). In practice:

• If \( U \le U_{\text{RM}}(n) \), all deadlines are guaranteed to be met under RM (for the assumed model).
• If \( U \) is larger, the task set may still be schedulable; more precise response-time analysis is needed.

3.2. EDF Utilization Bound

For EDF with implicit deadlines (\( D_i = T_i \)), a simple and tight condition is:

\[ U \le 1 \quad \Rightarrow \quad \text{task set schedulable under EDF}. \]

Thus, EDF can in principle utilize the full CPU, while RM leaves some slack. However, RM is easier to implement and analyze in many embedded controllers and is frequently adopted in robot control computers.

Consider a continuous-time LTI robot joint subsystem

\[ \dot{\mathbf{x}}(t) = \mathbf{A}\mathbf{x}(t) + \mathbf{B}\mathbf{u}(t), \]

with state \( \mathbf{x}(t) \) (e.g., joint angles and velocities) and control input \( \mathbf{u}(t) \). Under zero-order hold (ZOH) sampling with sampling instants \( t_k \) and inter-sample intervals \( h_k = t_{k+1} - t_k \), the exact discrete-time model between two samples is

\[ \mathbf{x}(t_{k+1}) = \boldsymbol{\Phi}(h_k)\,\mathbf{x}(t_k) + \boldsymbol{\Gamma}(h_k)\,\mathbf{u}_k, \]

where

\[ \boldsymbol{\Phi}(h_k) = e^{\mathbf{A} h_k},\qquad \boldsymbol{\Gamma}(h_k) = \int_{0}^{h_k} e^{\mathbf{A} \sigma}\,\mathbf{B}\,\mathrm{d}\sigma. \]

If the control law is a state-feedback \( \mathbf{u}_k = \mathbf{K}\mathbf{x}(t_k) \), then

\[ \mathbf{x}(t_{k+1}) = \bigl(\boldsymbol{\Phi}(h_k) + \boldsymbol{\Gamma}(h_k)\mathbf{K}\bigr) \mathbf{x}(t_k). \]

In nominal design, we assume a constant period \( h_k = h \) and obtain a fixed matrix \( \mathbf{A}_d(h) = \boldsymbol{\Phi}(h) + \boldsymbol{\Gamma}(h)\mathbf{K} \). Jitter makes \( h_k \) time-varying, so the closed-loop becomes a linear time-varying (LTV) system:

\[ \mathbf{x}(t_{k+1}) = \mathbf{A}_k\,\mathbf{x}(t_k),\quad \mathbf{A}_k \equiv \boldsymbol{\Phi}(h_k) + \boldsymbol{\Gamma}(h_k)\mathbf{K}. \]

In addition, the actuation may be delayed within each sampling interval (e.g., the actuator is updated a short time after the sample is taken), which can be modeled as a bounded input delay and folded into \( \mathbf{A}_k \) and \( \boldsymbol{\Gamma}(h_k) \) using augmentation techniques from discrete-time delay systems.

Assume the sampling period satisfies the bounds \( h_{\min} \le h_k \le h_{\max} \). This corresponds to bounded sampling jitter as long as the nominal period \( h \) lies inside this interval. We ask:

• Does the closed-loop remain stable for all possible sequences \( \{h_k\} \) in the interval?
• How much jitter can be tolerated before performance degrades beyond a given specification (overshoot, settling time, tracking error)?

5.1. Scalar Case Intuition

For a scalar system with continuous-time dynamics \( \dot{x}(t) = a x(t) \) and \( a \) strictly negative, the ZOH discrete-time system with sampling period \( h_k \) is

\[ x_{k+1} = e^{a h_k} x_k. \]

If \( h_k \) belongs to a bounded interval, then \( e^{a h_k} \) lies in the interval \( (0,1) \); the worst-case contraction ratio is \( \rho_{\max} = \max_{h \in [h_{\min},h_{\max}]} e^{a h} = e^{a h_{\min}} \). This remains less than one, so the system is exponentially stable for any allowed jitter sequence.

5.2. Matrix Case via Common Lyapunov Functions

In the multidimensional case, stability under jitter can be studied using a common quadratic Lyapunov function. Suppose there exists a symmetric positive-definite matrix \( \mathbf{P} \succ 0 \) such that for all \( h \in [h_{\min}, h_{\max}] \):

\[ \mathbf{A}_d(h)' \mathbf{P} \mathbf{A}_d(h) - \mathbf{P} \prec 0. \]

Then the LTV system \( \mathbf{x}_{k+1} = \mathbf{A}_d(h_k) \mathbf{x}_k \) is exponentially stable for any sequence \( \{h_k\} \) in the interval. This condition is often enforced by solving matrix inequalities at a finite grid of sampling periods or by convex relaxations.

Performance metrics (variance of tracking error, overshoot) can be computed or bounded using the induced operator norms of the varying matrices \( \mathbf{A}_k \) and input-output analysis with jitter treated as a structured uncertainty.

flowchart TD
  M["Discrete-time model A_d(h)"] --> GRID["Sample h in [h_min, h_max]"]
  GRID --> LMI["Solve inequalities A_d(h)' P A_d(h) - P < 0"]
  LMI --> RES["Common P found?"]
  RES -->|yes| STAB["Provable stability for all jitter"]
  RES -->|no| REDES["Redesign K or reduce jitter bound"]
        

A typical robot control computer distinguishes between multiple scheduling levels:

• Servo loop (inner loop): high-priority, small period, running on an RTOS or a real-time thread. Implements joint/torque control and safety interlocks.
• Motion generation / MPC: medium priority, updating desired trajectories every few milliseconds.
• Perception, planning, logging: lower priority, often soft real-time, sometimes on a separate core or computer.

In ROS-based systems, these are often implemented using:

• Python: rclpy timers for soft real-time, or custom loops using python-control for offline analysis.
• C++: rclcpp timers or ros2_control controllers running in real-time threads with priority scheduling.
• MATLAB/Simulink: real-time workshop / Simulink Real-Time, with fixed-step solvers and explicit sample times.

The key design practice is to isolate the hard real-time control loop from potentially heavy computations and communications that could cause overload and jitter.

We now illustrate how real-time scheduling and jitter-aware simulation can be implemented in several common languages used in robotics. These examples are simplified and focus on timing structure rather than full robot models.

7.1. Python: Simulating a Jittered Control Loop

The following Python script simulates a discrete-time PD controller for a scalar joint position with random sampling jitter. It uses numpy for dynamics and can be adapted into a ROS2 rclpy control node by replacing the simple loop with a timer callback.

import time
import math
import random
import numpy as np

# Simple scalar joint model: x = [position; velocity]
A = np.array([[0.0, 1.0],
              [0.0, -2.0]])   # some damping
B = np.array([[0.0],
              [1.0]])         # torque input

# Nominal sampling period (seconds) and jitter bound
h_nom = 0.002   # 2 ms
jitter_max = 0.0005  # +/- 0.5 ms

# PD gains
Kp = 50.0
Kd = 5.0

x = np.array([[0.5],
              [0.0]])  # initial position error
xref = 0.0

def step_euler(x, u, h):
    return x + h * (A @ x + B * u)

t = 0.0
for k in range(2000):
    # Compute control
    pos = x[0, 0]
    vel = x[1, 0]
    e = xref - pos
    u = Kp * e - Kd * vel

    # Draw jittered step size
    h = h_nom + random.uniform(-jitter_max, jitter_max)

    # Integrate
    x = step_euler(x, u, h)
    t += h

    if k % 100 == 0:
        print(f"k = {k}, t = {t:.4f}, pos = {pos:.4f}, h = {h:.6f}")

    # In a real RT system the sleep is driven by a timer interrupt
    time.sleep(h_nom)
      

7.2. C++: Periodic Real-Time Thread with Jitter Monitoring

In C++, we typically use std::chrono and std::this_thread::sleep_until in combination with a real-time scheduler (e.g., POSIX SCHED_FIFO) to achieve low-jitter control loops. Libraries such as ros2_control and Orocos RTT build on these ideas.

#include <chrono>
#include <thread>
#include <atomic>
#include <iostream>

std::atomic<bool> running{true};

void control_loop()
{
    using clock = std::chrono::steady_clock;
    using namespace std::chrono;

    const microseconds period(1000); // 1 kHz
    auto next_time = clock::now();

    while (running.load()) {
        auto start = clock::now();

        // TODO: read sensors, compute control, write actuators here
        // e.g. call into your robot dynamics / controller library

        // measure jitter as difference between actual start and ideal time
        auto jitter = duration_cast<nanoseconds>(start - next_time);
        std::cout << "jitter (ns) = " << jitter.count() << std::endl;

        next_time += period;
        std::this_thread::sleep_until(next_time);
    }
}

int main()
{
    std::thread th(control_loop);

    // In a real system, set real-time priority via sched_setscheduler
    // and pin the thread to a CPU core to reduce jitter.

    std::this_thread::sleep_for(std::chrono::seconds(2));
    running.store(false);
    th.join();
    return 0;
}
      

7.3. Java: Fixed-Rate Scheduling and Jitter Logging

Java is less common in low-level robot control but appears in higher-level layers and some educational platforms. Using ScheduledExecutorService, we can implement a fixed-rate control task and log the jitter in execution times.

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

public class JitterExample {
    public static void main(String[] args) {
        ScheduledExecutorService exec = Executors.newSingleThreadScheduledExecutor();

        final long periodNs = 1_000_000; // 1 ms
        final long[] expectedNext = { System.nanoTime() + periodNs };

        Runnable task = () -> {
            long now = System.nanoTime();
            long jitter = now - expectedNext[0];
            System.out.println("jitter (ns) = " + jitter);

            // TODO: read sensors, compute control, send commands

            expectedNext[0] += periodNs;
        };

        exec.scheduleAtFixedRate(task, 0, 1, TimeUnit.MILLISECONDS);

        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        exec.shutdown();
    }
}
      

7.4. MATLAB/Simulink: Jittered Sample-Time Simulation

In MATLAB, we can numerically examine the effect of random jitter on a discrete-time model. Below we use an Euler-discretized second-order joint model with random step sizes; in Simulink, similar behavior can be modeled via variable-step solvers or explicit jitter blocks.

A = [0 1; 0 -2];
B = [0; 1];

h_nom = 0.002;
jitter_max = 0.0005;

Kp = 50;
Kd = 5;

x = [0.5; 0.0];
xref = 0.0;

T = 2.0;          % total simulated time
t = 0.0;
k = 0;
log_t = [];
log_x = [];

while t < T
    pos = x(1);
    vel = x(2);
    e = xref - pos;
    u = Kp * e - Kd * vel;

    h = h_nom + (2*rand - 1)*jitter_max;
    xdot = A * x + B * u;
    x = x + h * xdot;

    t = t + h;
    k = k + 1;
    log_t(k,1) = t;
    log_x(k,1:2) = x.';
end

plot(log_t, log_x(:,1));
xlabel('time (s)'); ylabel('position');
title('Joint position under sampling jitter');
      

In Simulink, a typical setup for jitter studies is:

• Use a discrete-time controller block with sample time Ts.
• Introduce a jitter block that modulates Ts within a bound.
• Use Robotics System Toolbox for plant models (e.g., rigid-body tree).

7.5. Wolfram Mathematica: Jittered Sample Times

Mathematica is useful for symbolic and numerical exploration of jittered sampling effects. The code below simulates a scalar joint model with random sampling intervals and plots the trajectory.

a = -3.0;
hNom = 0.002;
jitterMax = 0.0005;

steps = 2000;
x0 = 0.5;

hSamples = hNom + RandomReal[{-jitterMax, jitterMax}, steps];
tSamples = Accumulate[hSamples];

x = ConstantArray[0.0, steps + 1];
x[[1]] = x0;

Do[
  x[[k + 1]] = Exp[a*hSamples[[k]]] * x[[k]],
  {k, 1, steps}
];

ListLinePlot[
  Transpose[{tSamples, Rest[x]}],
  AxesLabel -> {"time (s)", "x"},
  PlotLabel -> "Scalar state under sampling jitter"
]
      

This framework can be extended to matrix systems and used in symbolic derivations of Lyapunov inequalities for jitter-robust stability.

Problem 1 (RM Schedulability for a Robot Controller): Consider three periodic tasks on a single-core CPU:

• Joint control task: \( C_1 = 0.2\text{ ms},\; T_1 = 1\text{ ms} \).
• State estimation task: \( C_2 = 0.4\text{ ms},\; T_2 = 4\text{ ms} \).
• Logging task: \( C_3 = 1.0\text{ ms},\; T_3 = 20\text{ ms} \).

Are these tasks guaranteed schedulable under rate-monotonic scheduling?

Solution:

Compute utilizations:

\[ U_1 = \frac{0.2}{1} = 0.2,\quad U_2 = \frac{0.4}{4} = 0.1,\quad U_3 = \frac{1.0}{20} = 0.05. \]

Hence the total utilization is \( U = 0.2 + 0.1 + 0.05 = 0.35 \). For \( n = 3 \), the RM bound is

\[ U_{\text{RM}}(3) = 3\bigl(2^{1/3} - 1\bigr) \approx 3(1.2599 - 1) \approx 0.7797. \]

Since \( U \le U_{\text{RM}}(3) \), the task set is guaranteed schedulable under RM. In practice, there is significant slack (only 35% CPU usage).

Problem 2 (Task Reordering and Jitter): Suppose a new perception task with \( C_4 = 1.5\text{ ms},\; T_4 = 10\text{ ms} \) is added. Check the RM bound and discuss likely jitter impact on the highest-priority control task.

Solution:

The new utilization is

\[ U_4 = \frac{1.5}{10} = 0.15,\quad U_{\text{new}} = 0.35 + 0.15 = 0.50. \]

For \( n = 4 \), the RM bound is

\[ U_{\text{RM}}(4) = 4\bigl(2^{1/4} - 1\bigr) \approx 4(1.1892 - 1) \approx 0.7568. \]

Again \( U_{\text{new}} \le U_{\text{RM}}(4) \), so the set remains schedulable. Since the joint control task has the shortest period, it keeps the highest priority and experiences minimal preemption. Jitter in its start times should remain small, dominated by timer granularity and interrupt latency, not by lower-priority tasks.

Problem 3 (Scalar Stability under Jitter): Consider the scalar continuous-time system \( \dot{x}(t) = a x(t) \) with negative constant \( a \). Show that for any bounded sampling sequence with \( h_{\min} \le h_k \le h_{\max} \), the discretized system \( x_{k+1} = e^{a h_k} x_k \) is exponentially stable.

Solution:

Since \( a \) is negative, \( e^{a h} \) is strictly between 0 and 1 for any positive \( h \). The sampling bounds ensure \( h_k \) stays in a compact subset of the positive reals, so there exists a constant \( \rho \in (0,1) \) such that \( e^{a h_k} \le \rho \) for all \( k \). Iterating,

\[ |x_{k}| = \bigl|e^{a h_{k-1}} \cdots e^{a h_0} x_0\bigr| \le \rho^{k} |x_0|. \]

Thus the origin is exponentially stable with decay rate \( \rho \). Jitter only affects the precise trajectory, not stability.

Problem 4 (Lyapunov Condition for Jitter-Robust Stability): Let \( \mathbf{A}_d(h) \) be a family of discrete-time closed-loop matrices for a robot joint subsystem, parameterized by sampling period \( h \in [h_{\min}, h_{\max}] \). Suppose there exists a symmetric positive-definite matrix \( \mathbf{P} \) such that \( \mathbf{A}_d(h)'\mathbf{P}\mathbf{A}_d(h) - \mathbf{P} \prec 0 \) for all \( h \) in the interval. Prove that the system is exponentially stable for any jitter sequence \( \{h_k\} \subset [h_{\min}, h_{\max}] \).

Solution:

Define the Lyapunov function \( V(\mathbf{x}) = \mathbf{x}'\mathbf{P}\mathbf{x} \). For a given \( h_k \), we have

\[ V(\mathbf{x}_{k+1}) - V(\mathbf{x}_k) = \mathbf{x}_k' \bigl(\mathbf{A}_d(h_k)'\mathbf{P}\mathbf{A}_d(h_k) - \mathbf{P}\bigr) \mathbf{x}_k. \]

By assumption, the matrix in parentheses is negative definite for every admissible \( h_k \), so there exists a scalar \( \epsilon > 0 \) such that \( V(\mathbf{x}_{k+1}) - V(\mathbf{x}_k) \le -\epsilon \|\mathbf{x}_k\|^2 \). Using standard discrete-time Lyapunov arguments and equivalence of norms, one obtains exponential decay of \( V(\mathbf{x}_k) \) and hence of \( \|\mathbf{x}_k\| \). Because the inequality holds for all possible \( h_k \) at each step, the result is valid for any jitter sequence.

Problem 5 (Effect of Utilization on Jitter): Two task sets share the same highest-priority control task but differ in the number and utilization of lower-priority tasks. Explain qualitatively why increasing the total utilization of lower-priority tasks typically increases jitter in the control task when using a non-ideal timer and finite interrupt latencies, even though the highest-priority task still always meets its deadlines.

Solution:

In preemptive fixed-priority scheduling, the highest-priority task cannot be preempted once it starts, so its response time (release to completion) is deterministic as long as lower-priority tasks do not disable interrupts. However, in real systems:

• Timer interrupts may be delayed by critical sections in lower-priority tasks.
• Cache and pipeline state may be disturbed by heavy lower-priority activity, introducing variability in control-task WCET.
• Interrupt handling and context switches contribute to jitter in the exact start time of the control task.

As overall utilization increases, these effects tend to accumulate, causing the start-time jitter and execution-time variation of the control task to increase, even though deadlines are still met. This justifies keeping some utilization headroom in robot control computers.

In this lesson we connected real-time scheduling theory with digitally implemented robot controllers. We defined periodic task models with parameters \( (C_i, T_i, D_i, \phi_i) \) and reviewed classical RM and EDF schedulability conditions. We then modeled sampling jitter as a time-varying sampling interval entering the exact ZOH discrete-time dynamics, showing how it transforms a nominal LTI closed loop into an LTV system.

Using Lyapunov methods, we discussed conditions under which bounded jitter preserves stability via common quadratic Lyapunov functions, and related these to practical implementation strategies in Python, C++, Java, MATLAB/Simulink, and Mathematica. These concepts will be used in the next lesson's lab, where we will implement real controllers and empirically observe the impact of timing imperfections on robot behavior.