9.0.0-RC3 - PIFF Gain Attenuation and Scaling - Fixed Wing APA

[quadlawnmowerman-coder]

Wiki Link to Feature - https://github.com/iNavFlight/inav/wiki/PID-Attenuation-and-scaling#Fixedwing-APA

Current Behavior

The new attenuation for Inav 9 based on airspeed is working well for attenuating the PIFF gains on a fixed wing during acceleration above the cruise/PID tune speed, fiddle with apa_pow based on the speed your bird can get in a dive (or the max speed you wish to take airframe),up and down till you get rid of the overdriven surfaces sweet spot. The settings reduce the PIFF Gains by 70%, with the apa_pow enabling you to scale the top speed the the 70% reduction is applied by

Unfortunately it does the opposite to speeds below the cruise speed/PID tuned speed. This means when your airspeed slows down your PIFF gains increase which quickly becomes and issue on a well tune bird that is not only fast but also can fly really slow, or when there is significant tail winds. There is up to a 70% reduction on PIFF gains above cruise speed, but there us up to a 200% increase in the PIFF gains below cruise speed and it's scale is set/linked to the same apa_pow setting. I would argue there is simply no need to increase the PIFF gains below cruise speed, and if you did it would only be by small amount, maybe 30% if at all.

The issue really becomes a big problem if the airspeed sensor fails, gets blocked or you forget to remove the pitot sock, suddenly you have 200% PIFF gain increase at cruise speed and have to try to land.

Steps to Reproduce

1. Use the new Fixedwing APA for TPA (default TPA control in 9.00)
2. Aircraft traveling around cruise speed (in my case around 85km/hr)
3. Failure of pitot tube sensor on fixedwing (mechanical failure) with airspeed now reading under 25km/h
4. Can also be replicated by leaving airspeed sensor unplugged or by leaving pitot tube sock on and taking off
5. With an airspeed reading suddenly below 20-25km/h PIFF gains are increased to 200% (takes place around 50km/hr with my apa_pow setting)
6. Aircraft becomes almost unflyable due to tremendous increase in PIFF gains at cruise speed, which requires landing now with the 200% increased PIFF gains (windy conditions makes that a joy).

Expected behavior

I don't expect there is ever a case where I would really want the PIFF gains to increase, at the very least I think there would need to be some sanity tests on the airspeed data before applying any sort of increase to the gains. If the airspeed is below the min aircraft set speed then the changes to the gains should not be applied.

Suggested solution(s)

I think the simplest fix for this is not to increase the gains at all below cruise speed, I don't think there is a need for it. The other option would be to have a command to set the maximum value on each of the increase/decrease PIFF gain percentage. This way you could set it to zero % if you want to turn it off for either above or below the cruise speed, and then apa_pow can remain as the expo end point for the speed at which the maximum percentage change is applied to the PIFF gain).

So you would end up with say 2 extra set points
apa_pow for expo curve endpoint (stays the same)
apa_increase for percentage of max gain increase (add)
apa_reduce for percentage of max gain decrease (add)

• FC Board name and vendor: TBS Lucid AIO 2-6S
  #INAV version string: INAV/TBS_LUCID_H7_WING_MINI 9.0.0 Dec 22 2025 / 04:12:39 (2747993)

GCC-13.2.1 20231009

[sensei-hacker]

Thanks for this test info!

If there was no pitot plugged in on boot, that should be detected by a sanity check. If it isn't, we should make an issue for that

Regarding mechanical failure if the pitot tube in flight making the plane not fly well:
I have noticed the same is true for servos. If a servo fails in flight, the plane doesn't fly as well. Also props, motors, etc. Mechanical failures do tend make things not work as well.

IMHO fail-safes for mechanical failures in flight should be focused on don't totally crash the plane, but we don't need to limit features in order make a plane fly well as it's physically falling apart.

The control surface forces at 15 knots are much lower the than 25 knots, for the same throw. There is comparatively little difference between 100 knots vs 110 knots. So I would argue that slow flying is EXACTLY when you most need the adjustment most.

The exponential parameter (apa_pow) mainly is based on whether you are trying to stabilize response to external disturbances and keep it flying straight, or are trying to do aggressive maneuvers.

[Jetrell]

When we were testing with a Pitot tube speed source. We often found it less accurate in tight aerobatic flight (depending on the tubes placement), than using virtual airspeed. Which is GNSS derived, and provided more reliability.

@quadlawnmowerman-coder From you wording. It sounds like you are theorizing what would happen. And it didn't actually occur.
It is true that the airspeed dynamic gains will boost below the reference airspeed, if you get a partially blocked Pitot.
The airspeed source sanity check is only designed to look for hardware or sensor communication failure. Detecting a Pitot blockage inflight isn't something that can be done with certainty. It could be compared to the virtual airspeed source. But then why bother using a pitot tube at all.

I don't expect there is ever a case where I would really want the PIFF gains to increase,

I agree with @sensei-hacker statement concerning this.. And after much testing of the feature in development. Boosting the gains below fw_reference_airspeed made a noticeable difference in keeping the PID stabilization response much tighter as the plane slowed for landing in windy conditions. It was clear to see in the logs how much harder the stabilization would fight to oppose wind perturbations.

To reduce the likelihood of your issue occurring. apa_pow could be reduced, based on the reference airspeed. Or the based gain tune could be lowered. As I recommended; only tune them to about 85% of max at the reference airspeed. Tuning the PID's to the limit is never a good idea. Everything has fluctuations, and needs some leeway.

Unfortunately Pitot sensors aren't as reliable as the virtual airspeed source. And being that at least 90% of users don't add them. They will use virtual airspeed.. And its sanity check is adequate.

I have noticed the same is true for servos. If a servo fails in flight, the plane doesn't fly as well. Also props, motors, etc. Mechanical failures do tend make things not work as well.
IMHO fail-safes for mechanical failures in flight should be focused on don't totally crash the plane, but we don't need to limit features in order make a plane fly well as as it's physically falling apart.

True @sensei-hacker . If I encountered a pitot failure in flight, as with any other failure. I would take action to slow the plane if possible, by lowering the throttle and thus the airspeed. And if it occurred in a dive, I would pull up.

[sensei-hacker]

Detecting a Pitot blockage inflight isn't something that can be done with certainty. It could be compared to the virtual airspeed source. But then why bother using a pitot tube at all.

Not with certainty, for sure. A possible approach for future development would be to check whether the pitot is anywhere close to the GPS-based virtual pitot. (Allowing for a sane value of wind).
Ie, if the GPS shows 60 MPH and the pitot shows 0, we shouldn't trust the pitot. I don't know what sanity checks we currently have, if any.

In particular, zero and maximum readings may be less trustworthy.

This reminds me of a test question in my post grad encryption course. The question was whether one should eliminate zero as a possible key value, if the random source happens to generate zero. I knew that the mathematically correct answer is no. But also wrote that if a "random" source produces 64, 128, or 256 zero bits in a row, it's almost surely broken - either accidentally or on purpose. :) You'd be waiting billions of years for that to actually happen randomly.

[Jetrell]

When it comes to using either pitot or virtual for the airspeed source.

Pitot airspeed sensor.
Pros -

• Can fly a long straight line with accuracy still being maintained. (>500m)
• Will work if GNSS failure occurs. Which is good for dead reckoning estimation.

Cons -

• Can become blocked, causing a reduction in the speed reading.
• Runtime calibration can fail at power up, leading to an inaccurate reading. Depending on whether it's analog or digital type.
• Poor positioning of the tube on the model will effect its accuracy.

Virtual airspeed.
Pros -

• Source can't be blocked by debris. i.e. grass, bugs etc.
• Accuracy is just as good under most conditions.
• Less hardware required.
• Generally more accurate when used in aerobatics.

Cons -

• The reading will be come less accurate if the plane flies in a straight line for an extended period of time, without making a turn.
• Can provide a similar reading to ground speed at launch for the first 30 meters or so until the airspeed estimation becomes trusted.

So tuning the apa_pow , fw_reference_airspeed and base PID tune according to what suits your models requirements is the best way to lessen any impact airspeed source inaccuracy/partial failure would have on the dynamic gain adjustment.
e.g. A fast plane that is going to be used for aerobatics occasionally. Would generally have the fw_reference_airspeed base gain tune set to a higher airspeed. As it would also likely have apa_pow set a bit lower. And be better suited to using Virtual airspeed.

While a slower plane, or long range cruiser would be better suited to using a Pitot airspeed sensor. With the fw_reference_airspeed being set lower. Which would push the maximum boost onset lower in airspeed range. And you could also lower apa_pow by 10 or 20, just for more safety margin, in the case Pitot blockage did occur.

[quadlawnmowerman-coder]

In theory Senseri-hacker is right but it does not translate that way in practice, nor is there any weight being placed on the impact of something making such large changes to the PIFF gains linked to a sensor without some safety/sanity checks on the sensor data. When I talk mechanical failure I mean not just simply no data, this includes pitot tube clog, tubes coming off or not plugged in (as some pitot tubes are in the wings and need the air tube plugged in after transport) or the pitot sock being left on (we have all done that before). A servo failure and a sensor failure is not anything like the same thing as you should not have to crash because an airspeed sensor suddenly output data near zero.

Tuning the PIFF loop is not simply theory though, else we would not need to tune at all. It is based on a number factors which also include how the pilot likes the airframe to respond. When you tune your aircraft at low speed (as recommended) you already have the PIFF gains where you like them, and large increases in gains are not needed when you slow down, in fact they can become a problem as it has a pretty large impact/change on the handling of the aircraft, especially at a 200% increase. Maybe myself and my fpv group are in the minority, but the 5 guys I fly with all agree they don't want a change to gains below cruise speed at any point, but especially when they come in for a land (about the only time the gain increase really happens in earnest normally during a flight), admittedly 2 of them land in manual as they want the flight control out of the way on landing.

As Senseri-hacker points out, you can reduce the apa_pow, but that is linked to the gain changes above cruise, so you detune the TPA above cruise to effectively try to compensate for something not actually needed below cruise speed. The simplest check is to ensure airspeed sensor data is above min speed before applying TPA gain changes and to check the data is also within a reasonable number compared to virtual. If either check fails, then don't apply gain changes and make a warning flag for OSD, this way the airframe is not impacted and the pilot is alerted and can easily make a decision on what action they will take (i.e. no max speed dives).

I am not sure where Jetrell is coming from with the comments, yes tried and tested on 3 airframes which is why the issue is lodged and I can tell no sensor data checks taking place (super dangerous to happen on the TBS Mojito airframe, let me assure you I am glad I had manual mode setup). Yes it caused major impact on the airframes making it an extreme handful to land them, made worse by there also being decent amount of wind when it first occurred. Several additional test were made to determine if there was any sensor data checks (which there seems clearly none), no theory involved. I can only surmise from your comment that your testing was only on a single airframe and that airframe was slow and did not have much speed change between cruise, max dive and landing speeds. I think you are also forgetting the gain goes to 200% increase for all speed ranges in my example, so unless you are at near stall speed, you are fighting the massive gain overshoots left right and centre. As for pitot not being used, more people would use it if it wasn't such a pita to mount in many airframes, but this shouldn't be a reason to ignore a lack of sensor checks on the new TPA input (101 for using sensor data as a direct input for controls is to sanity check the data before accepting and applying it).

From a control perspective, just give the choice to remove the gain increase below cruise or better yet, give us the choice to set the max gain change amounts on either side of cruise (it is 2 constants now, just allow/give us a parameter to be able change each one). You should also implement a check on the sensor data as any sensor directly linked to control/gains should have a number of safety/sanity checks other than "is it connected". Adding the user changeable parameter for gain change amounts should be a simple addition to the current code for this feature, however I also suggest splitting apa-pow also between the gain increase and decrease so you can set the expo for this above and below cruise, there is no reason for them to be linked. It might also be beneficial to add a user set deadband parameter around cruise where the gains are not adjusted while adding additional parameters. The new TPA control works really well above cruise speed with valid data, it just needs a couple of minor tweaks to make it safer and more compatible/tuneable with different airframes.

And one last comment to give weight to the issue, how many people have requested an increase to the PIFF gains below cruise speed? I can't find a single request where someone has asked for this, so how relevant/needed is it in reality?

[Jetrell]

@quadlawnmowerman-coder

How much did you increase the base gains above what you used to fly with, before tuning it for use with APA ?
You must have increased them considerably to experience control surface oscillation at airspeeds below the fw_reference_airspeed.

And one last comment to give weight to the issue, how many people have requested an increase to the PIFF gains below cruise speed? I can't find a single request where someone has asked for this, so how relevant/needed is it in reality?

Fixedwing TPA has always had throttle based attenuation and BOOST with the same double scaling factor. This is nothing new. The only difference would be how tightly you increased your base tune. Otherwise you'd have experienced control surface oscillations at speeds below tpa_breakpoint in other INAV releases with your old tune.

[sensei-hacker]

some safety/sanity checks on the sensor data. When I talk mechanical failure I mean not just simply no data, this includes pitot tube clog, tubes coming off or not plugged in
...
If either check fails, then don't apply gain changes and make a warning flag for OSD

Can you give us some actual empirical values reported when the tubes aren't connected or similar failure modes, so we could attempt to recognize such?

I also suggest splitting apa-pow also between the gain increase and decrease so you can set the expo for this above and below cruise, there is no reason for them to be linked.

The control surface force scales with airspeed. I don't see any reason to artificially cause a sudden change in behavior at some arbitrary airspeed. That's why so many people talk about crashes caused by Horizon mode - it suddenly changes flight behavior at an arbitrary point. Hence people say "horizon is of the devil" etc.

A setting to limit the maximum effect at very low speed makes more sense to me. (You could even set "very low speed" as approximately your normal cruising speed, at which point it's own fault that the behavior of the aircraft changes as you go very slightly faster or slower).

[quadlawnmowerman-coder]

How much did you increase the base gains above what you used to fly with, before tuning it for use with APA ? You must have increased them considerably to experience control surface oscillation at airspeeds below the fw_reference_airspeed.

Base gains are tuned, and yes increased, I think you are focused on trying to defend an issue rather than discussing improvements to the new implementation. This is a new feature in a release candidate, so changes/amendments should be expected. And yes, with airspeed errors, with reported airspeed below the point where 200% gain was automatically applied, there was massive oscillations at every speed all the way to landing.

Fixedwing TPA has always had throttle based attenuation and BOOST. This is nothing new. The only difference would be how tightly you increased your base tune. Otherwise you'd have experienced control surface oscillations at speeds below tpa_breakpoint in other INAV releases with your old tune.

Has it though? I am not sure it did as the wiki does not note this and the diagram explaining it states otherwise, and if this was the case, at high speed shut of throttle you would get a massive gain increase which we didn't see previously (dive with no throttle saw no additional PIFF overshoot compared to part or full throttle at same speed), more importantly it was not directly linked to a sensor and you really don't reduce throttle that often below cruise other than right before landing so it wasn't really acting 99.9% of the time anyways (assuming it boost below TPA set point at all).

[sensei-hacker]

you really don't reduce throttle that often below cruise other than right before landing so it wasn't really acting 99.9% of the time

It's always interesting to hear about how different people fly differently. I fly about 30%-35% of my hours near idle. Basically, I go up and out, then down and back. (For most flights).

This kind of thing comes up often as people think about how "we really fly". Mr D, for example, flies completely differently than how I fly. So it's useful to hear about different flying styles, with different types of planes.

This is also why I tend to stick mostly with things that are guaranteed by the laws of physics. Mostly you'll see me talk about mathematical formulas that are true regardless, and rarely about my preferences on how I like to fly a particular plane.

[quadlawnmowerman-coder]

Can you give us some actual empirical values reported when the tubes aren't connected or similar failure modes, so we could attempt to recognize such?

I can, on 4525's you see a 0-8km/h moving data output and DLVR-L10's you see from 0-2km/h data output . However I would say looking at it this way is not the best approach. Better to simply check airspeed data against Minimum Airspeed (currently under osd settings), or add another parameter to set for this to check against.

The control surface force scales with airspeed. I don't see any reason to artificially cause a sudden change in behavior at some arbitrary airspeed. That's why so many people talk about crashes caused by Horizon mode - it suddenly changes flight behavior at an arbitrary point. Hence people say "horizon is of the devil" etc.

A setting to limit the maximum effect at very low speed makes more sense to me. (You could even set "very low speed" as approximately your normal cruising speed, at which point it's own fault that the behavior of the aircraft changes as you go very slightly faster or slower).

Yes, no sudden changes. So setting max effect above and below (separately) is ideal start with a simple sanity check data is above min speed to be valid, but seeing as apa_pow is just an expo curve, it is highly likely you want that curve to act differently below fw_reference_airspeed than above, so being able to set both separately like the max gain separately is also preferred but can technically be further influenced by max set points on either side of fw_reference_airspeed.

[Jetrell]

That curve shows how the multicopter TPA works. Not the way the older version of the fixedwing TPA works.

I'm not against a more detailed pitot sanity check. You made it sound like it doesn't have one at all, which it does.

I suggest you read through the wiki multiple times. And the warning.
It may help you get a better under standing of the link between apa_pow and fw_reference_airspeed. And how tight you can tune the based gains.

And for all we know. The reason you experienced this issue. Is because the airspeed sanity check did work and the speed function reverted to your un-tuned TPA + Pitch angle setup.

[sensei-hacker]

Base gains are tuned, and yes increased, I think you are focused on trying to defend an issue rather than discussing improvements to the new implementation. This is a new feature in a release candidate, so changes/amendments should be expected.

Certainly changes should be expected.

It may be very useful to cleanly separate observations and issues from ideas about how to address those issues.

If you observed some specific flight behavior, I would like to think about what you observed, what it might mean, and what changes or adjustments might be appropriate.

I was getting distracted from that by the idea of suddenly changing the exponent at some arbitrary speed that isn't based on any real life physics. I suspect we can come up with a better solution. But would first need to clearly understand the problem.