When Timing Breaks Your Controller

Problem Setup

The Controller Does Not Update Continuously

Start from the previous high-altitude flight problems. The aircraft is already under wind disturbance, and the actuator has physical limits. Now we add another real-world effect: the controller does not update continuously.

In real flight software, the control loop follows a timing sequence:

sensor reads state → controller computes command → actuator receives command

But this does not happen at every instant. It happens at a finite update rate. A controller that works in a continuous model may behave differently when sampled slowly or delayed.

Main idea: same controller, same gains, same aircraft — different timing can produce different behaviour.

Continuous vs Real-Time Control

Ideal Control Updates Every Instant

In the ideal continuous case, the control command is updated at every instant using the current aircraft state.

$$ u(t) = K(h_{target} - h(t)) - K_{\theta}\theta(t) $$

In real-time digital control, the controller updates only every sample time $T_s$. Between updates, the previous command is held.

$$ u_k = K(h_{target} - h_k) - K_{\theta}\theta_k $$ $$ u(t) = u_k,\quad kT_s \leq t < (k+1)T_s $$

This is called sample-and-hold behaviour. The controller is not wrong, but the timing assumption has changed.

Control Type	What Happens	Risk
Continuous	Command updates every integration step	Idealized behaviour
Discrete fast	Command updates frequently	Usually close to continuous behaviour
Discrete slow	Command updates slowly	Late correction, oscillation, poor damping

Sensor Delay / Latency

The Controller Reacts to Where the Aircraft Was

Real sensors and estimators do not always provide the true current state instantly. The controller may use delayed altitude and pitch measurements.

$$ h_{measured}(t) = h(t - \Delta t_{delay}) $$ $$ \theta_{measured}(t) = \theta(t - \Delta t_{delay}) $$

This means the controller reacts to where the aircraft was, not where it is now. The result can be late correction, extra overshoot, reduced damping, and possible oscillation.

Key risk: delay adds phase lag. Phase lag can turn a stabilizing correction into a late correction.

Longitudinal Aircraft Model

Same Model, Timing-Dependent Control Input

The simplified aircraft model remains consistent with the earlier HAPS problems. The states are velocity, altitude, and pitch.

$$ \dot{V} = -D(V) + a_u u_{applied} + w_V(t) $$ $$ \dot{h} = V\sin(\theta) + w_h(t) $$ $$ \dot{\theta} = b_u u_{applied} - c\theta $$

The difference is that $u_{applied}$ now depends on controller timing. It may be updated continuously, sampled quickly, sampled slowly, or computed using delayed sensor data.

dynamics remain the same → controller gains remain the same → timing changes the closed-loop behaviour

Three Timing Cases

Same Controller, Different Timing

This problem compares four timing behaviours.

Case A — Continuous control: controller updates every integration step.
Case B — Discrete fast: controller updates quickly, such as $T_s = 0.05$ s.
Case C — Discrete slow: controller updates slowly, such as $T_s = 0.5$ to $1.0$ s.
Case D — Discrete slow + sensor delay: the controller updates slowly and uses delayed measurements.

The fourth case is the most realistic failure case because it combines sample-and-hold behaviour with sensor latency.

Interactive Simulator

Compare Continuous, Discrete, and Delayed Control

Use the sliders to adjust controller gain, sample time, sensor delay, wind gust strength, aircraft damping, and simulation time. The same aircraft and same controller are used. Only the timing behaviour changes.

Choose timing mode:

Continuous Discrete fast Discrete slow Discrete + delay Compare all

Show controller update markers

Controller gain: 0.035

Sample time: 0.50 s

Sensor delay: 0.30 s

Wind gust strength: 6 m/s equivalent

Aircraft damping: 0.25

Simulation time: 100 s

Select a timing mode and run the simulation to generate results.

Why Timing Breaks the Controller

The Control Law Assumed Immediate State Information

The control law was designed as if it had immediate state information and continuous update. But real implementation includes sampling, latency, sample-and-hold behaviour, finite computation time, and sensor filtering delay.

delayed measurement → late command → overshoot → corrective command arrives late → oscillation grows

Timing changes the closed-loop dynamics. This is why the same gain values can look safe in one simulation and unstable in another.

Important: slow sampling does not merely make the controller less smooth. It changes when corrective action enters the physical system.

Connection to Existing Timing Page

How This Connects to Discrete vs Continuous Controller Timing

This aircraft timing problem is the high-altitude flight version of the same timing issue shown in the spacecraft discrete-vs-continuous page.

In both cases, the controller law is unchanged. The behaviour changes because the controller update timing changes.

spacecraft sample-and-hold timing ↔ aircraft flight-control update timing

Open Discrete vs Continuous Page →

Engineering Interpretation

Timing Is Not Just a Coding Detail

Timing changes the dynamics of the closed-loop system. A controller should be tested not only by its gain values, but by its actual update rate, sensor latency, actuator response, and computation delay.

Why This Matters for HAPS

Long-endurance aircraft may use slower control loops, filtered sensor data, delayed estimation, and low-bandwidth actuators. At high altitude, the aircraft may already respond slowly. A slow controller or delayed measurement can make correction arrive too late.

What the Engineer Should Check

Control loop sample time
Sensor and estimator latency
Sample-and-hold command behaviour
Phase lag between true state and measured state
Closed-loop behaviour under wind disturbance

A controller is not fully specified until its timing is specified.

Python Implementation

Reproducing Timing Effects in Python

The key implementation step is to update the command only at sample times and optionally use delayed measurements.

import numpy as np

dt = 0.01
t_final = 100
Ts = 0.5
delay = 0.3

t = np.arange(0, t_final, dt)

h_target = 1000
V = np.zeros_like(t)
h = np.zeros_like(t)
theta = np.zeros_like(t)
u = np.zeros_like(t)

V[0] = 25
h[0] = 950
theta[0] = 0

K = 0.035
K_theta = 0.8
damping = 0.25

current_u = 0
next_update = 0

for k in range(len(t)-1):

    if t[k] >= next_update:
        delay_steps = int(delay / dt)
        measured_index = max(0, k - delay_steps)

        h_measured = h[measured_index]
        theta_measured = theta[measured_index]

        current_u = K*(h_target - h_measured) - K_theta*theta_measured
        next_update += Ts

    wind = 6*np.sin(2*np.pi*0.10*t[k])

    V_dot = -0.015*(V[k] - 25) + 0.04*current_u + 0.03*wind
    h_dot = V[k]*np.sin(theta[k]) + 0.7*wind
    theta_dot = 1.2*current_u - damping*theta[k]

    V[k+1] = V[k] + V_dot*dt
    h[k+1] = h[k] + h_dot*dt
    theta[k+1] = theta[k] + theta_dot*dt
    u[k+1] = current_u

Takeaway

Timing Is Part of the System

A controller is not fully defined by its gain values. It is also defined by when it reads the state, when it computes the command, and when the actuator applies it.

Continuous model

Useful for theory, but idealized.

Discrete implementation

Introduces sample-and-hold behaviour.

Sensor delay

Makes the controller react to old information.

Timing is part of the system, not an implementation detail.