Alternative for TPA in fixed wing.

[Dronek]

TPA is intended to attenuate PIDs with increasing throttle. While this is useful for multicopters, it makes sense for fixed wings exclusively in scenarios where high throttle is equivalent to high airspeed. However, there are possible scenarios where the mentioned equivalence is not met. Steep diving with low throttle might lead to oscillations due to high (not properly attenuated) PID gains. Steep climbing with high throttle might in turn result in lack of PID activity. It might be therefore more elegant to use "airspeed PID attenuation" instead of TPA. If airspeed sensing is not available PID attenuation could also be controlled as a function of throttle, aircraft orientation (nose up/down) and vertical speed with respective logical dependency.

[oleost]

Airspeed sensor is one the way to iNav, and once it's working it will become logical to use aitpseed sensor for PIDs attenuation. Which I believe is already planned.

Without airspeed sensor a simple solution was taken to map it to throttle with known limitations as you pointed out.

But I agree current implementation could be improved with having the TPA applied both weighted by throttle and pitch.

So full throttle and pitch up ( aircraft going up ) would still not reduce PIDs completely.

While also opposite low throttle and pitch down would still apply some TPA.

[WaspFPV]

@Dronek You mean when airspeed is not available, base TPA on 3D ground speed?

[Dronek]

@Dronek You mean when airspeed is not available, base TPA on 3D ground speed?

Not sure what you mean by 3D ground speed but I don't think that ground speed (or GPS based speed in general) is a useful reference for PIFF attenuation (PA), at least not when wind is involved. Also, if the plane is in a steep dive, groundspeed is very low but airspeed can get very high.

EDIT: The current TPA curve for fixed wing can actually lead to severe oscillation during steep dives in acro with zero throttle which is probably the most critical bug of the current "TPA for airplane" implementation. I will try to come up with some suggestions how to improve TPA for airplane...

[WaspFPV]

@Dronek by 3D ground speed I mean total sped, not only horizontal, but the total of horizontal and vertical. But you are right, it wouldn't work if there was too much wind. You would need telemetry to a weather station, and still calculate the airspeed to make it work well.

[Redshifft]

I suspect TPA gets used to deal with induced motor/prop vibration more than anything and people should know how to deal with that ;) lets not forget a steep dive at zero throttle is still going to make your motor spin not far short of the RPM it would be if propelling that speed itself. Speed sensitive TPA, like Car steering is a good thing but not essential if the car handles and steers properly in the first place.

[Dronek]

Not sure what your point is... I'm using a folding prop on my wing and ESC brake when throttle is zero. Nothing spinning there. But even when you have a regular prop and it continues to spin without throttle TPA will amplify PIFF gains in the current implementation during rhe dive.

[Redshifft]

@Dronek And how does it do that when your first point suggested TPA needs to be speed aware ? Unless things have changed TPA can only attenuate. As TPA is not working for you why don't you tune without it and see how you get on.

[Dronek]

OK, I see. Obviously there is a misconception here. TPA in iNav actually works differently for fixed wing than for multirotor. Please refer to the following wiki page and you will note that below mid throttle TPA factor becomes >1.0 https://github.com/iNavFlight/inav/wiki/PID-Attenuation-and-scaling

[Redshifft]

Wtf, that looks like some sort of work around and changes everything, is it even current (2 Nov 2016) with the new Aeroplane pid controller ? Very few will use an Airspeed probe anyway so it needs to be clarified that it's still there for 1.6 firstly. If it is add me to your supporter list :)

[digitalentity]

For airplanes TPA is not really attenuation accounting for thrust/vibration at high throttle. It's designed to be a substitute for airspeed sensor - in most cases airspeed is proportional to throttle (not talking about rapid climbs and steep dives).

[oleost]

@digitalentity Read my comment?

So a new variable called fw_tpa_pitch_weight. So when it's zero TPA will behave as now, only looking at throttle. But the more weight the more pitch will be used in combination with throttle.

So when flying straight throttle TPA would work as now, but when climbing the "fw_tpa_pitch_weight" would assume the airplane is going slower than just straight and therefore increase PIDs. Also same with diving. ?

Unsure if this is doable, or if it would be hard to tune when example diving and then going up again.

[digitalentity]

Yes, it's definitely possible to create, but it will be very hard to tune - pitch contribution to airspeed depends on too many factors (drag factor, mass, lift etc).

[digitalentity]

We need more data from BB logs to figure out some relation between pitch and airspeed. Unfortunately for that we need planes with pitot tubes and so far only @sambas has one (I might be wrong though).

[Dronek]

I already mentioned my readiness to test an airspeed sensor with inav in the forum. If you tell me which sensor is most likely to work reliable with inav I can provide you BB data as well. In my opinion TPA schould be additonally weighted by the angle between acceleration vector and a plane perpendicular to roll axis. This way an aircraft diving upside down could also be attenuated correctly...

[Redshifft]

A straight desensitizing of pids increasing from "flyable" throttle range should work - normal TPA Are we looking for it to "stabilize right" or "feel right" on the controls ?

[Dronek]

Rather to "not actively de-stabilize". In fact, throttle range below flyable throttle is more critical and more complicated to handle in terms of correct PIFF gain modulation.

[Redshifft]

@Dronek There are some very strange defaults in this fw/configurator for Aeroplanes, let me test it in the air before I comment further.

[oleost]

Defaults are not so well suited yet.

We need to update those. Please remember it's 1.6 is not out yet.

[digitalentity]

Airspeed support is in progress. Closing.

[brat002]

How about return to this feature? We don't really need airspeed to use TPA. Gps speed will give more accurate coefficient for tpa than throttle level. Say more - throttle based pid attenuation is a bit pain for hand launch and high speed planes.

[Dronek]

Gps speed will give more accurate coefficient for tpa than throttle level.

I don't think so. Really, TPA on fixed wing should be based solely on airflow aka airspeed or throttle as an alternative when airspeed is not available. GPS speed seems to be the worst option in my opinion. If you dive vertically with zero throttle GPS speed will be more or less zero too. Airspeed will be quite high, however, and thus PI should be attenuated properly.

If you disagree, feel free to describe how GPS based TPA is supposed to behave.

[brat002]

But we can calculate 3d speed instead of 2d, right? If plane dives, altitude also will go down. Flight controller always knows vertical and horizontal offset from previous point to current point.

Really almost none flies with pitot. We need working TPA, which has been based on fact "how fast plane flies", but not on "how fast plane can fly".

[digitalentity]

GPS has nothing to do with TPA for airplanes. Imagine flying a glider. With some headwind you can hover in one place. GPS will be reading zero, but you'll have sufficient airspeed to maintain lift. There's no way of knowing that airspeed without a specialized sensor.

However there is a very close relation between airspeed and throttle in near-horizontal flight. Climbing or diving is another story - we definitely need to account for pitch to get better TPA on airspeed-less airplanes.

[brat002]

The problem affects plane especially on launch when gps speed is 0, but throttle is full or almost full and TPA pull's PID's down instead of maximise rates and stabilisation forces. On Saturday one more Multiplex Funjet had crashed because of that.

[oleost]

That could be fixed with two different solution.

1. Don't enable TPA scaling before an minimum speed of 3m/s after armed. ( Stays enabled once above it )

2. Timer, wait 15s before enabling TPA after armed and throttle above min_check.

[brat002]

Don't enable TPA scaling before an minimum speed of 3m/s after armed. ( Stays enabled once above it )

Looks like a great solution. Would be nice to have <3m/s > configurable value.

[digitalentity]

Or even better - consider inertia/drag. Don't use raw throttle value for TPA. Instead filter it with a delay time-constant.

This way when throttle jumps from 0 to 100% TPA reduction will be delayed while plane accelerates.

Similarly for the opposite. When you fly fast and drop throttle to zero plane won't get all shaky due to TPA kicking gains up instantly.

[Dronek]

@brat002, did you actually try using no tpa at all? It seems to do more harm than good at this stage. I've been flying my wing perfectly fine without tpa in spite of quite high PI values.

[brat002]

I've personally tried 20-80% values. The lost FunJet had 35% TPA. Recommended TPA 50-80% for planes does almost impossible to hand launch after autotuned PID's because P/I values too small and TPA does them yet less.

[brat002]

@digitalentity Could you reopen this issue to fix the problem in future?

[digitalentity]

I'm going to open it and move to 1.9. A better TPA for planes w/o airspeed sensor would be a good addition.

[taileron]

A step before could be to add TPA via aux channel instead of throttle even a simple tx can mix a percentage of throttle into an aux channel so e.g. for a flying wing that starts vertical it can be done with a 2 or 3 position switch for climb and forward/dive with different TPA mix percentages in the rc tx by adding an aux scaling factor between 0 ... 1 into the P,D-term and .33 ... 1 into I-term PID calculation: float auxPgain = (((float)rcData[AUX1])/1000.0f)-1.0f; float auxIgain = (0.5f+auxPgain)/1.5f;

Later an additional scale factor could be added that takes an amount of nose up or down into the calculation to avoid the need of an airspeed sensor which would be the best solution. PID attenuation should best only be in relation to airspeed.

[lakotamm]

I would like to point out another issue here - is the airspeed itself linear enough?

Would not the differential pressure from the air speed sensor be better and more linear then the airspeed itself?

[taileron]

a good placed real airspeed sensor is always the best and would also be the best to lower pids according to it´s values but I´m searching for solutions that fit to very small airframes as well, where differential pressure sensors are much to heavy. https://www.youtube.com/watch?v=IVbhdopDhdI My first tests ... even in very much wind that flies great and quite fast it´s much fun outdoor

[b14ckyy]

push

I like the idea of a delayed TPA and also disable tpa completely during autolaunch procedure. This was causing my Talon GT to crash on multiple launch attempts. Now I removed the TPA and tried to find a good PI value to launch safely and stable and also to allow fast dives in emergency without the plane freaking out.

Maybe a good option would also be to not just use pitch for modifying PA but instead using climb and descent rate to modify tpa. On high Ascent rates the PA needs to be lowered to maintain stability and avoid a stall and on high descent rates it should raise the PA to lower the P and I. But just as an additional modifier to the throttle based PA.

[taileron]

The main problem always is that TPA doesn´t lower the i-term, so the relation between P and I ist wrong. e.g. the while the launch procedure there is too much I and not enough P gain. I accumulates too much ... the most important thing in all situations is to have the possibility to switch of I-term completely for the moments when control surfaces that have no effect.