Hover-Thrust Integrator Compensation

Summary

A mechanism that updates hover thrust estimate without step changes in controller output by computing an integrator adjustment that absorbs the thrust model change.

Key insight

Instead of allowing a hover thrust parameter update to cause a step change in controller output, this approach pre-compensates the velocity integrator by computing the acceleration setpoint that would produce equivalent thrust under the new model, then injecting the delta into the integrator. The compensation is derived from the specific multicopter thrust model T = a_sp*Th/g - Th and applied only to the Z-axis integrator to preserve vertical hover stability during online thrust estimation updates.

Interface

Hover thrust change (Th → Th'), current acceleration setpoint a_sp,
current velocity integrator state
→ Updated Z-axis velocity integrator (_vel_int(2)) that produces
  the same thrust output under the new hover thrust parameter

Technical approach

When hover thrust changes from Th to Th', computes acceleration adjustment a_sp' = (a_sp - g)*Th/Th' + g using the thrust model T = a_sp*Th/g - Th. Adds (a_sp' - a_sp) to velocity integrator (_vel_int(2)) so the next control cycle produces the same thrust despite the changed hover thrust parameter. Only adjusts Z-axis integrator.

Components

• Thrust model inverter
• Equivalent acceleration calculator
• Integrator delta injector
• Z-axis filter

Component interaction

When hover thrust changes, the thrust model inverter uses the existing thrust equation T = a_sp*Th/g - Th to compute what acceleration setpoint a_sp' would yield the same thrust T under the new hover thrust Th'. The equivalent acceleration calculator applies the rearranged formula a_sp' = (a_sp - g)*Th/Th' + g. The integrator delta injector computes (a_sp' - a_sp) and adds it to the velocity integrator. The Z-axis filter ensures only the vertical integrator (_vel_int(2)) is adjusted, leaving lateral control unaffected.

Engineering characterization

Technical

Dimension	Result
Technical distinctiveness	72%
Implementation depth	58%
Problem specificity	78%
Generality	45%
Estimated commonness (lower means less common in comparable systems)	25%
Paradigm shift	1 / 3

Strategic

Dimension	Result
Product centrality	68%
Defensibility	64%

Distinctiveness mechanism

What makes this engineering approach unusual, named in the model's own words. An engineering observation only.

Algebraic integrator pre-compensation from inverted thrust model

step_elimination

Eliminates the transient settling period after hover thrust updates by algebraically inverting the thrust model T = a_sp*Th/g - Th to compute the equivalent acceleration a_sp' = (a_sp - g)*Th/Th' + g, then directly injecting the delta into the integrator rather than waiting for feedback to re-converge.

Single-axis integrator adjustment for parameter change

cross_domain_transfer

Applies the bumpless-transfer concept (common in gain-scheduled controllers during mode switches) specifically to online parameter estimation updates, targeting only the Z-axis integrator to isolate vertical hover dynamics from lateral control.

Observability

Of the shipped product

Dimension	Result
Detectability	35%
Reverse-engineerability	25%

Observability reasoning

The mechanism runs onboard the flight controller and affects internal integrator state. An observer with telemetry access could detect the absence of thrust transients when hover thrust estimates change (comparing logged hover_thrust parameter vs. actual thrust output), but the specific algebraic compensation formula and Z-axis-only adjustment are not visible in MAVLink telemetry streams or external behavior. Reconstructing the method would require access to source code or detailed state logs showing _vel_int(2) jumps correlated with hover thrust updates.

Substrate discrimination

Dimension	Result
Substrate specificity	70%

Noun-swap reasoning

Substituting “hover thrust” → “model parameter,” “integrator” → “state accumulator” preserves the compensation logic, but the specific thrust model (T = a*Th/g - Th) and the choice to adjust only the Z integrator are load-bearing for multicopter hover dynamics. The compensation prevents transients during online thrust estimation updates, which is substrate-specific to adaptive hover control.

Reviewer summary

This mechanism prevents transient thrust changes when the hover thrust parameter is updated online by pre-compensating the velocity integrator. It computes an equivalent acceleration setpoint under the new thrust model using a_sp' = (a_sp - g)*Th/Th' + g, then injects the delta (a_sp' - a_sp) into the Z-axis velocity integrator so the next control cycle produces the same thrust output despite the changed parameter. The compensation is specific to the multicopter thrust model T = a_sp*Th/g - Th and targets only vertical dynamics.

Comparable techniques

Model-generated technical analogies that may help a qualified reviewer form search directions. These are not prior-art references, search results, or statements that any listed technique discloses this finding.

• Bumpless transfer in PID controllers (anti-windup reset)
• Integrator state scaling in gain-scheduled control
• Parameter update compensation in adaptive control (MIT rule with normalization)
• State predictor correction in model reference adaptive control (MRAC)
• Integrator clamping during mode transitions in flight control

Source

Location: src/modules/mc_pos_control/PositionControl/PositionControl.cpp

Source code omitted for clarity.

Depends on

• updateHoverThrust()
• setHoverThrust()
• _hover_thrust
• _vel_int

Confidence trace

Hover thrust update with integrator compensation computing acceleration adjustment (a_sp' = (a_sp - g)*Th/Th' + g) to prevent step changes in controller output is a distinct, grounded parameter-change compensation mechanism.

• Characterization confidence: high
• Filter confidence: 80%

Back to the PX4 scan case study

Obviously Not is a technical analysis tool, not a law firm. Obviously Not does not provide legal advice, represent scan users or repository owners, determine patentability, or create an attorney-client relationship by analyzing code or generating a report. Strategic concepts are technical findings for further review, not legal conclusions or filing recommendations. Consult your own qualified patent attorney about your specific facts, potential rights, deadlines, jurisdictions, and any patent application.