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.