Altitude Hold Oscillation Review

A controller can hit the target repeatedly and still be performing badly.

If altitude crosses above and below the target over and over, the important evidence is in the shape and timing of the response.

This lesson uses a supplied simulated altitude-hold trace. You are not tuning real flight hardware. Your job is to reconstruct the loop and identify which explanation best fits the evidence.

The supplied trace

The fictional target is 10.0 m.

time    altitude
0.0 s    8.0 m
1.0 s    9.6 m
2.0 s   10.8 m
3.0 s    9.3 m
4.0 s   10.6 m
5.0 s    9.5 m
6.0 s   10.4 m
7.0 s    9.7 m
8.0 s   10.2 m

The oscillation is shrinking.

That suggests the system is not diverging, but it is taking time to settle.

Now compare a second fictional trace:

time    altitude
0.0 s    8.0 m
1.0 s    9.5 m
2.0 s   10.9 m
3.0 s    8.9 m
4.0 s   11.4 m
5.0 s    8.3 m
6.0 s   12.1 m

The swings are growing.

That is a much more serious stability problem.

Plot error, not just altitude

For a 10.0 m target:

error = target - altitude

At 10.8 m:

error = 10.0 - 10.8 = -0.8 m

At 9.3 m:

error = 10.0 - 9.3 = +0.7 m

The sign changes every time the aircraft crosses the target.

A repeating sign flip is one clue that the controller is chasing past the setpoint instead of settling cleanly.

Three different causes can look similar

Oscillation does not automatically mean “gain too high.”

Aggressive controller response

Correction is strong enough to repeatedly overshoot the target.

Delayed measurement or actuation

The controller reacts to old state information, so correction arrives after the system has already changed.

Noisy or disturbed measurement

The controller follows a measurement that is moving even when true altitude is steadier.

Those mechanisms require different fixes. That is why you inspect multiple traces instead of one altitude line.

Use aligned evidence

The supplied packet includes:

• target altitude;
• estimated altitude;
• raw pressure-derived altitude signal;
• vertical actuator command;
• timestamps.

A useful review aligns all of them.

If the raw sensor signal oscillates first, the measurement path may be driving the controller.

If the sensor is smooth but actuator command alternates aggressively, control tuning becomes more plausible.

If the actuator response follows error with a long delay, latency becomes a stronger candidate.

The first changing signal matters.

Worked case: sensor lag versus high gain

Two simulated systems have similar altitude oscillation.

System A

• altitude estimate lags the physical model by 0.5 s;
• controller output responds strongly to the delayed error;
• reducing simulated sensor delay greatly improves the response without changing gain.

System B

• estimate closely follows physical altitude;
• controller output reverses sharply at small errors;
• reducing proportional gain makes the oscillation decay faster.

Same visible symptom. Different mechanism.

The diagnosis comes from controlled evidence, not from the word “oscillation.”

Measure response features

For the supplied trace, estimate:

• first time the response reaches the target;
• maximum overshoot;
• number of target crossings;
• whether peak error is shrinking or growing;
• approximate settling time if it settles;
• any visible delay between error change and actuator response.

You do not need advanced control mathematics to make these observations.

You need a timeline and a target.

A controller can fight sensor noise

Imagine a pressure-based altitude signal bouncing rapidly around the true value.

If the controller reacts to every tiny change, the actuator command can become busy and noisy too.

Filtering may smooth the signal, but heavy filtering can add delay.

Now you have a tradeoff:

less filtering → more noise reaches controller
more filtering → smoother signal but potentially more lag

There is no universal “turn filtering up” answer.

Build the oscillation review

Create four panels or sections.

Panel 1 — Response shape

Describe overshoot, target crossings, and whether oscillation grows or decays.

Panel 2 — Timing

Identify which signal changes first: sensor, estimate, error, or actuator command.

Panel 3 — Competing hypotheses

Rank at least three:

• aggressive gain;
• sensor/estimator delay;
• measurement noise;
• actuator saturation;
• physical disturbance.

Panel 4 — Separating test

Choose one simulation change that best distinguishes the top two hypotheses.

Do not recommend changing five parameters at once.

Bounded conclusion example

The altitude response overshoots repeatedly but the peak error decreases, so the supplied trace is underdamped rather than clearly divergent. The state estimate is smooth and closely timed to the physical altitude, while actuator output reverses strongly around small errors. Aggressive control response is therefore a stronger explanation than sensor noise in this packet. A reduced-gain simulation would test that hypothesis without changing the sensor model.

Notice the wording: stronger explanation, not absolute certainty.

Misconception: reaching the target means success

Control quality includes how the system reaches and stays near the target.

A controller that hits 10 m, overshoots to 15 m, drops to 6 m, and repeats is not successful because the trace crossed the correct number occasionally.

The mission needs bounded, predictable behavior.

Week 8 closes on time response

A feedback loop is not just target minus measurement.

It is a process unfolding in time:

measure → compare → correct → move → measure again

When something oscillates, ask which part of that timing chain causes the correction to arrive with the wrong strength, the wrong information, or at the wrong moment.