FEATURE REQUEST: Airspeed-based PID Attenuation for Fixed Wing

[trailx]

Current Behavior

TPA attenuates PIDs based on throttle. This makes sense for quadcopters, but its not ideal for fixed wing. This was outlined originally in #1269.

Despite being closed, I don't think anything was ever really completed on #1269 to address the original concern. I think others also outlined the problem well in that thread, and it even looked like an airspeed PID attenuation was planned to be added. All I have seen added was fw_tpa_time_constant, which really doesn't fix things. Its a bandaid that only accounts for inertial effects of quick throttle changes in level flight. I find that the current TPA implementation simply does not work if you climb or dive at all, especially if you are trying to maximize stabilization via the PIDs.

Desired Behavior

Since airspeed is supported now, TPA should have an option to use airspeed as the input instead of throttle. While the airspeed is loosely correlated to throttle, it doesn't take into account the effect that climbs and dives have on airspeed.

Suggested Solution

I have tried to work around this by creating a 'program' that changes the PIDFF profile (1-3) based on airspeed. This works relatively well, but it becomes a 'stepped' PID profile rather than linear. Under 45 mph airspeed, I have high PIDs. Between 45 and 55 mph airspeed, PIDs reduce by 20%. Above 55 the pids then drop an additional 20%, then I have TPA dialed in for higher speeds.

This works much better than the current TPA implementation, but my issue is that it is not linear. So I can tune my plane where it will get PID oscillations at 54 mph, but it will go away at 50 mph. So I'm unable to maximize the stabilization effects throughout the speed range due to the stepped nature of the PIDs.

My proposal is to create an additional CLI option that would allow a pilot to choose whether TPA pulls from either rcCommand[THROTTLE], or airspeed as the source variable. Call it TPA_source and allow it to be either throttle or airspeed. The units of airspeed (cm/s) seem like they would be close enough to the throttle command units that the current math would be really close. It looks like you'd need to open the allowable TPA_breakpoint range beyond the PWM_range_max (and probably adjust the min too).

It seems like this code in src/main/fc/mw.c is where we could make some minimal changes and fix this once and for all by simply checking the throttle or the airspeed, depending on the setting of the proposed TPA_source. I'm sure I'm oversimplifying it, but its a starting point.

else {
// TPA should be updated only when TPA is actually set
if (controlRateConfig->dynThrPID == 0 || rcCommand[THROTTLE] < controlRateConfig->tpa_breakpoint) {
tpaFactor = 1.0f;
} else if (rcCommand[THROTTLE] < motorConfig->maxthrottle) {
tpaFactor = (100 - (uint16_t)controlRateConfig->dynThrPID * (rcCommand[THROTTLE] - controlRateConfig->tpa_breakpoint) / (motorConfig->maxthrottle - controlRateConfig->tpa_breakpoint)) / 100.0f;
} else {
tpaFactor = (100 - controlRateConfig->dynThrPID) / 100.0f;
}

Who does this impact? Who is this for?

Fixed wing users who do more than level flying and want to maximize ACRO stability.

Additional context

On the original request #1269, it was brought up that 3Dspeed didn't account for windage. Airspeed does, and it seems like this hasn't been looked at again since Airspeed support was added.

[anti-vaxxer]

what is TPA? thanks

[Jetrell]

what is TPA? thanks

https://github.com/iNavFlight/inav/wiki/PID-Attenuation-and-scaling

[trailx]

Interesting to note in that link it covers the topic of airspeed-based PID attenuation:

Airplanes are different from multirotors as PID gains should be attenuated according to airspeed, not throttle. However, until airspeed sensor support is introduced it's safe to assume that speed is directly proportional to throttle.

[Jetrell]

@trailx This was also attempted by @JulioCesarMatias a few years ago. But I'm not sure if it was ever tested. #7206

[trailx]

Good spot @Jetrell. I hadn't seen that. It looks like in the conversation a legitimate limitation was brought up, where there was an artificial 79.2km/h (2200cm/s) limitation (likely brought on by existing limitations in today's code). But looking closer at @JulioCesarMatias's code, it looks like he since updated it to a 360 km/h limit, per his edited first post.

[trailx]

@sensei-hacker, I apologize for my ignorance. Is it possible to attempt to test or port in fork #7206 even though it was closed? Can it be reopened? Thanks for the insights. I don't mean to call you out specifically, but you helped walk me through my last issue. Figured you may be able to provide some insight.

[trailx]

I found another approach that the Betaflight devs have been working on. It looks like they are not only improving their basic TPA calculation by adding in "gravity" to their basic model. They are also creating an "advanced TPA" calculation that estimates airspeed independent of an airspeed sensor and wind estimations.
They have already performed some initial testing on this system, so there would likely be less risk by borrowing and implementing their solution than trying to create a new solution as I had proposed:
betaflight/betaflight#13895
How hard would it be to pull this solution into INAV?

[Jetrell]

@trailx I had a quick skim through his idea.. As much as it would work. It seems far from user friendly to setup and tune..
I don't mean to sound negative. But it wouldn't be as simple as PID scaling based on pitot airspeed.
Most users find tuning PIDs time consuming.. While tuning this type of attenuator with all its physics related settings, would be far more time consuming. Being beyond the grasp and willingness of most users to do so.
Calculating the coefficient of drag isn't an easy thing to do. Being that its specific to the hardware hanging off the individual build.

In saying that. All those settings do provide the navigation controller a far more informed snap-shot of the planes aerodynamic flight properties. Which could increase the present fixedwing flight accuracy, if such settings where integrated into operation, by augmenting the wind estimator.. But that would require considerable modifications and testing of the navigation software, being far from likely to occur.

[limonspb]

@trailx I had a quick skim through his idea.. As much as it would work. It seems far from user friendly to setup and tune.. I don't mean to sound negative. But it wouldn't be as simple as PID scaling based on pitot airspeed. Most users find tuning PIDs time consuming.. While tuning this type of attenuator with all its physics related settings, would be far more time consuming. Being beyond the grasp and willingness of most users to do so. Calculating the coefficient of drag isn't an easy thing to do. Being that its specific to the hardware hanging off the individual build.

In saying that. All those settings do provide the navigation controller a far more informed snap-shot of the planes aerodynamic flight properties. Which could increase the present fixedwing flight accuracy, if such settings where integrated into operation, by augmenting the wind estimator.. But that would require considerable modifications and testing of the navigation software, being far from likely to occur.

Sorry for breaking in here, just saw a link left to that PR.
You are right about ADVANCED setting. It needs at least one bbx log + run python script to find exact values for parameters based on the log.
But BASIC setting provides just two tuning parameters. "Delay" and "gravity effect" in precents. Its a bit simpler physical model, but works also super accurate, just easier to tune. Doesn't have to be perfect. Needs some ~"delay" and some ~gravity. As far as I understand this "delay" is not the same as "time constant" from INAV, but tuning is similar. "Gravity" it just how much faster/slower plane dives nose down with zero throttle from it flying horizontally full throttle.

A much simpler (in the code) approach was this:
betaflight/betaflight#13778
Just factoring in the sin(pitch angle) with throttle, and talking LPF from all that. Tuning process was the same as currently proposed BASIC model, just the result less accurate, especially for low speeds or fast throttle changes, because it didn't have much physics, just heuristics.

But of course all that is not needed if there is an actual air speed sensor on the plane.

[trailx]

Any thoughts on only adopting Ivan's more basic gravity function? Based on my experience with my own airspeed PID attenuation "program", I really think this would help the PID stabilization performance of any plane that climbs or dives. (all of them)