What does MOT_THST_HOVER represent?

MOT_THST_HOVER is the fraction of maximum throttle the autopilot expects to use for hover. A value of 0.4 means the airframe hovers at 40% of full throttle. The autopilot uses this as the feed-forward in altitude-controlled modes, so the value being correct means the closed-loop controller does less work.

Should I set MOT_HOVER_LEARN to 2?

Almost always, yes. Mode 2 (learn and save) means the autopilot adapts MOT_THST_HOVER during stable hover and persists the new value. Mode 1 learns without saving — useful for a one-flight test of a new payload, but the value resets on next boot. Mode 0 disables learning and is rarely the right choice.

What's a healthy MOT_THST_HOVER value?

0.3 to 0.5 for most well-sized multirotors at design weight. Below 0.3 means the airframe is oversized for the payload; above 0.5 means you're getting close to thrust limits; above 0.65 means you have no safety margin and should reduce payload or swap to higher-thrust motors.

Why does my drone climb when I switch to AltHold?

The learned hover throttle is too low — when AltHold engages and commands the feed-forward, the autopilot ends up commanding more throttle than needed and the drone climbs. The cause is usually a stale MOT_THST_HOVER from a previous lighter payload. Re-learn or reset the parameter and the next AltHold engagement will be neutral.

Can I learn hover throttle with a payload that varies between flights?

Yes but the value will be tuned to whatever you most recently flew at. For variable-payload operations, tune at the heaviest payload — the autopilot will feel slightly soft at lighter payloads but won't saturate. For mission-critical variable payloads, consider disabling learning and setting MOT_THST_HOVER manually to a sensible midpoint.

Should I worry about MOT_THST_HOVER climbing over many flights?

It's a fleet maintenance signal worth watching. A gradual climb over flights on the same airframe with the same payload usually means a worn prop, an underperforming motor, or a marginal ESC. Compare against other drones in the fleet — a single airframe drifting is a maintenance trigger.

Reading and Fixing the ArduPilot Throttle Hover Offset

TL;DR: The throttle hover offset in ArduPilot is the autopilot’s estimate of how much throttle the airframe needs to maintain altitude. The learned value lives in MOT_THST_HOVER (a fraction between 0 and 1; typical 0.3–0.5). It’s set automatically when MOT_HOVER_LEARN is enabled. If the learned value drifts from the true hover throttle, altitude-controlled modes feel sluggish or twitchy. Read CTUN.ThO against CTUN.ThH in your log to confirm whether the autopilot’s estimate matches reality.

Why hover throttle matters

Every altitude-controlled mode (AltHold, Loiter, PosHold, Auto, RTL, LAND) computes the throttle output as a feed-forward (hover throttle) plus a feedback correction for climb rate error. If the feed-forward is wrong, the feedback controller has to do all the work and the response feels delayed. If the feed-forward overshoots, the drone climbs unintentionally when you switch into AltHold.

The autopilot learns hover throttle in two ways: a brief calibration at first flight, or continuous learning during stable hover. MOT_HOVER_LEARN selects the mode:

0 — learning disabled. Uses whatever value is stored in MOT_THST_HOVER.
1 — learn only (don’t save). The autopilot adapts during flight but the value resets on next boot.
2 — learn and save. The value updates persistently during steady hover; this is what you almost always want.

Reading the offset in the log

The CTUN message has both the commanded and the estimated hover throttle:

CTUN  TimeUS  ThI  ABst  ThO  ThH  DAlt  Alt  BAlt  DSAlt  SAlt  TAlt  DCRt  CRt

ThO — throttle output the autopilot is commanding right now.
ThH — the calculated hover throttle estimate the autopilot is currently using.

During steady hover (no climb or descent commanded), ThO and ThH should agree closely. If ThO sits noticeably above ThH while altitude is stable, the autopilot’s estimate is too low; if ThO sits below ThH, the estimate is too high. Plot both during a 30-second stable hover to see whether the offset matches reality.

Confirming it in MAVExplorer

MAV> graph CTUN.ThO CTUN.ThH
MAV> graph CTUN.DAlt CTUN.Alt
MAV> param show MOT_THST_HOVER MOT_HOVER_LEARN

The parameter dump tells you what value the firmware was carrying at takeoff and whether learning was enabled.

Why the offset drifts

Payload change. A drone tuned at one weight will hover at a different throttle with extra payload. MOT_THST_HOVER values around 0.35 mean you have headroom; values approaching 0.65 mean you’re close to maximum thrust capacity and adding more payload risks saturation.
Pack ageing. A worn pack delivers less voltage under load; the autopilot needs more throttle for the same thrust. Re-learn after a battery change.
Prop replacement. Different props of the same size can have different thrust constants. Re-learn after any prop change.
Altitude effects. Flying at high elevation (less air density) raises hover throttle. A tune learned at sea level will mis-feed at 3000 m elevation.
Damaged prop. A chipped prop produces less thrust than expected; the autopilot raises throttle to compensate; MOT_THST_HOVER climbs over flights as the autopilot learns the higher requirement. Watch this trend across flights for a fleet preventive-maintenance signal.

Reading `MOT_THST_HOVER` as a fleet health indicator

For an operator running multiple identical airframes, the MOT_THST_HOVER value tells you a lot:

Values below 0.3 — the airframe is oversized for the payload, plenty of authority.
Values between 0.3 and 0.5 — typical for a well-matched build at design weight.
Values between 0.5 and 0.65 — getting close to thrust limits; expect reduced climb rate authority, less ability to recover from wind disturbances.
Values above 0.65 — flight controller is saturating motors at hover; you have no safety margin. Reduce payload, swap to higher-thrust motors, or fly only in calm conditions.

Across a fleet, a single drone’s MOT_THST_HOVER climbing relative to its siblings is a maintenance flag — usually a worn prop, an underperforming motor, or a marginal ESC.

Fixing a stuck or wrong offset

Confirm MOT_HOVER_LEARN = 2. Most issues are from this being set to 0 historically.
Reset the learned value if it’s clearly wrong. Set MOT_THST_HOVER manually to a sensible starting value (0.4 if you don’t know your airframe; otherwise the average from previous flights), then take off and let the autopilot relearn in stable hover.
Verify in the next log. Plot CTUN.ThO versus CTUN.ThH; they should agree within a few percent during steady hover.
For payload-variable operations, accept the learned value won’t be ideal for both extremes. Tune for the heaviest payload; the lighter configurations will feel slightly soft in AltHold but won’t saturate.

When the issue isn’t the hover offset

Untuned PIDs. If the altitude controller is over-reacting to climb-rate error, that’s a PSC_ACCZ_* or PSC_VELZ_* tune problem, not a hover-throttle issue.
Baro drift. If BARO.Alt reports a different altitude than the drone is at (sun on the sensor, ground effect), the autopilot adjusts throttle for a phantom altitude error. See our BARO glitch post.
Wind. Vertical wind components (downdrafts) require the autopilot to increase throttle beyond the learned hover — that’s correct behaviour, not a hover-offset bug.

When LogHat helps — and when it doesn’t

LogHat plots CTUN.ThO versus CTUN.ThH on the throttle envelope panel and surfaces the takeoff value of MOT_THST_HOVER in the parameter snapshot. For fleet operators, we trend the value across flights of the same airframe and flag drift outside the expected band. What we can’t do is decide whether the payload was the design payload — that needs you to record the configuration.