Hover Drift Diagnosis

“Drone drifts left” is a symptom, not a diagnosis.

Drift can come from the environment, the mechanical layout, the measurements, the state estimate, the control system, or a combination of them. Week 7 gives you enough physics to separate those possibilities instead of calling every unwanted motion “wind.”

The supplied flight trace

A fictional simulator records a position-hold test in a low-wind environment.

The packet shows:

commanded horizontal velocity: 0 m/s
observed motion: slow drift to the right
roll estimate: about +2° during drift
wind model: near 0 m/s
payload: mounted slightly right of center
accelerometer bias check: small but nonzero offset
motor outputs: left-side motors slightly higher than right-side motors

Several clues matter. None of them alone proves root cause.

Build the force-and-state story

Start with the physical observation.

If the aircraft accelerates right, then during that acceleration there must be a rightward net force in the simplified model.

Where could that force come from?

• a tilted thrust vector;
• aerodynamic disturbance;
• asymmetrical propulsion;
• a controller commanding correction in the wrong direction;
• an attitude estimate that says the aircraft is level when it is not.

Now the diagnosis has structure.

Separate disturbance from compensation

A subtle problem in flight logs is that a control action can look like the original fault.

Suppose the aircraft drifts right because the state estimate has a small roll bias. The controller may increase left-side thrust trying to correct the attitude it thinks it sees.

The higher left motor output is then compensation evidence, not proof that the left motors caused the drift.

That distinction matters in almost every closed-loop system.

You need timing:

Did the motor-output difference appear before the drift, or after the controller detected an error?

A static screenshot cannot answer that. A time-aligned trace can.

Candidate hypotheses

Use at least these five categories.

External disturbance

Wind or another aerodynamic force pushes the aircraft.

Mechanical imbalance

CG shift, frame geometry, or propulsion asymmetry changes the physical response.

Measurement bias

A sensor reports a consistent offset.

Frame or mapping error

The system interprets an axis or direction incorrectly.

Control behavior

The controller reacts too weakly, too strongly, too late, or around a bad state estimate.

The point is not to keep every hypothesis alive forever. The point is to kill them with evidence in the correct order.

Worked diagnosis: is it wind?

A learner says:

The drone drifted, so wind must have pushed it.

Check the supplied evidence.

• wind model reports near zero;
• the drift repeats in the same direction across several runs;
• a small roll-estimate offset is present before motion begins;
• the payload is also offset right of center.

Wind is now a weak explanation.

Two stronger hypotheses remain:

1. the mass distribution creates a real mechanical bias;
2. the state estimate contains a roll bias that leads to incorrect control action.

How do you separate them?

Run a controlled simulation where one condition changes at a time.

For example:

• recenter the payload but keep the sensor bias;
• then remove the simulated sensor bias while restoring the payload offset.

The resulting traces reveal which change moves the drift.

That is much stronger than staring at one flight and guessing.

Direction matters in the evidence

If the estimated roll is positive, you need the simulator’s sign convention before interpreting it.

If +roll means right side down in the supplied model, a persistent +2° estimate could cause a particular corrective command. If the convention is opposite, your interpretation changes.

Never diagnose from a signed value without knowing the frame and sign convention.

Week 7 Lesson 1 was not vocabulary practice. This is where axis discipline pays off.

Use a cause-versus-response timeline

Create a timeline with these columns:

Your job is to identify the first meaningful divergence from expected behavior.

If the roll estimate is already wrong before the motor response changes, that is important.

If the roll estimate is normal until after the aircraft begins moving, that points somewhere else.

One-variable tests

A useful simulated test matrix might be:

You are not trying to model every real-world variable. You are trying to make the remaining hypotheses distinguishable.

Write the diagnosis

Your review should contain four short sections:

Observed behavior

Describe the drift using direction, timing, and reference frame.

Strongest hypotheses

List the two explanations most consistent with the supplied evidence.

Best separating test

Choose the single simulated change that most clearly distinguishes those hypotheses.

Bounded conclusion

State what the current packet supports and what remains unresolved.

A strong conclusion might look like:

The repeated rightward drift is not well explained by the supplied wind model. The preexisting roll-estimate offset and right-side payload placement are both plausible contributors. A recentered-payload simulation with the sensor bias unchanged would help isolate the mechanical contribution before control tuning is changed.

Misconception: fix drift by increasing correction

If the state estimate is wrong, stronger control can make the aircraft more confidently wrong.

If the CG is poor, aggressive tuning may hide a mechanical problem while increasing motor demand.

If the problem is wind, changing calibration may make things worse.

Control adjustments should come after the team understands which layer owns the error.

Week 7 closes with a diagnostic model

You now have a physics-first workflow:

frame → forces → acceleration → observed motion → competing explanations → separating test

That is enough to move into feedback control next week, where we will stop looking only at what force caused motion and start asking how the controller changes its response over time.