Targets, Error, and Correction Limits

A controller cannot command infinite correction.

Motors have limits. Batteries have limits. The aircraft has geometry, mass, and aerodynamic limits. Software may also impose explicit output limits for safety and stability.

That means the controller’s job is not simply “make error zero.” It is reduce error using the authority the system actually has.

Targets come from somewhere

Before analyzing correction, identify the target source.

A target may come from:

• pilot stick input;
• an altitude-hold mode;
• a waypoint or mission command;
• a return-to-home routine;
• another layer of the autopilot.

A controller can follow a bad target perfectly.

So the control chain begins one step earlier than the loop itself:

mission / pilot intent
→ target
→ error
→ controller
→ actuator command

If the target is impossible or unsafe, tuning the controller is the wrong fix.

Error has sign and scale

Suppose a fictional roll controller uses:

error = target roll - estimated roll

If target roll is 0° and estimated roll is +8°:

error = 0 - 8 = -8°

The negative sign matters because it tells the controller which direction to correct under the stated convention.

If the axis convention is wrong, the correction can reinforce the error instead of reducing it.

That is positive feedback behavior in the bad sense: the response pushes the system farther from the target.

Saturation: when the command hits the wall

Imagine a controller calculates that it wants a motor command of 115%, but the actuator output is limited to 100%.

The actual command becomes:

requested: 115%
applied:    100%

That is saturation.

The controller may still have error, but it has no more actuator authority in that direction.

This can happen during:

• aggressive maneuvering;
• heavy payload conditions;
• strong disturbances;
• poor CG placement;
• propulsion degradation;
• unrealistic target commands.

Saturation is not necessarily a software bug. It may be evidence that the system requirement exceeds available physical authority.

Control margin matters before the limit

A system does not need to be at 100% output to have a problem.

Suppose hover already requires 85% of available thrust because the aircraft is heavy. Only 15% remains for upward acceleration or disturbance rejection in that simplified model.

A lighter configuration hovering at 55% has much more control margin.

This connects Week 4 propulsion choices and Week 3 payload mass directly to Week 8 control behavior.

Hardware design changes the control problem.

Deadband and noise

Not every tiny error should produce frantic actuator motion.

Real systems may use filtering, deadbands, thresholds, or other logic so measurement noise does not constantly command corrections.

A simplified deadband rule might be:

if |error| < 0.05:
    correction = 0
else:
    correction = controller(error)

That can reduce unnecessary response to tiny noise—but a deadband that is too large may leave a visible steady error.

Again, every design choice creates a tradeoff.

Integral action and accumulated error

A proportional controller may leave a small steady offset when a constant disturbance exists.

One common control idea is to accumulate error over time. In PID control, the integral term does that.

Conceptually:

persistent error
→ accumulated correction grows
→ controller pushes harder against the steady disturbance

But accumulated correction can also become a problem when actuators saturate. If the controller keeps integrating error while the system cannot respond, the stored correction can become excessive. This is related to integral windup.

You do not need to tune a real PID controller here. The important lesson is that controllers can carry memory of past error, and limits affect that memory.

Derivative behavior and rapid change

The derivative term in a PID-style controller reacts to how quickly error changes.

Conceptually, it can add damping by resisting rapid change.

But derivative behavior can also amplify measurement noise if the signal is noisy.

So now control design depends on sensor quality again.

There is no clean wall between “sensor engineering” and “control engineering.”

Worked case: altitude target under limited thrust

A fictional simulator has:

current altitude: 10 m
target altitude: 20 m
aircraft mass: high-payload configuration
maximum climb thrust: limited
battery state: reduced voltage under load

The controller commands maximum available upward response, but climb rate remains slow.

A weak diagnosis says:

Increase the gain.

That may do nothing because the actuator is already saturated.

The real limitation is available propulsion authority under the current aircraft configuration.

The target, hardware state, and controller limit have to be analyzed together.

Correction limits should be visible

Use a supplied control trace and mark:

• target value;
• measured or estimated value;
• error;
• requested correction;
• applied correction;
• actuator limit;
• moment when saturation begins;
• whether error decreases, remains, or grows after saturation.

Then answer:

Is this primarily a tuning problem, a target problem, a measurement problem, or a physical-authority problem?

Defend one choice with the trace.

Misconception: bigger gains always fix slow response

Higher gain can create faster correction under some conditions.

It can also create:

• overshoot;
• oscillation;
• sensitivity to noise;
• actuator saturation;
• instability.

And if the actuator is already at its limit, more requested command does not create more physical force.

The control question to carry forward

When a controller performs poorly, ask four things before touching a gain:

1. Is the target reasonable?
2. Is the state estimate trustworthy and timely?
3. Does the controller have enough actuator authority?
4. Does the time response show under-correction, over-correction, delay, or saturation?

Those questions set up the oscillation diagnosis in the next lesson.