Add airspeed TPA support #11042
Add airspeed TPA support #11042
Conversation
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Explore these optional code suggestions:
|
||||||||||||||
|
throttle position vs tpa factor |
|
This does look kinda over-complicated for historical reasons. But I'm not volunteering to refactor it, so I'm not really complaining. We originally saw we need to reduce the PID when airspeed increases. Because the force/lift from the control surface is proportional to ( 0.5 * airspeed) ². What we really wanted originally when TPA was introduced was the airspeed. But we often don't have the airspeed. So we used the throttle value to make a rough estimate of what the airspeed might be, in order to reduce the PID appropriately. Now when we DO have the airspeed (the value we wanted in the first place), we're using the airspeed to simulate a throttle value, in order to estimate how much the throttle value might affect the airspeed and therefore the PID. Kinda like: Given we already know the airspeed, there's no need to mess around with estimating a "virtual throttle", then estimating how much that will affect the velocity and therefore the force. |
I think this only explain the first half of the theory and it is not proportial but inverse propotional, The following are my thoughts, in short the angular velocity of the plane is propotional to the control surface multiplied by airspeed. If the old TPA assumes throttle is propotional to airspeed. then it is on same page with the following. And airspeed gain reduction(TPA) will need some internal variable to calculate, then why dont we use the virtual throttle value as the internal variable to maintain the compability, reducing the workload of users to shift from throttle based to airspeed based. Relationship Between Airspeed, Control Surface Deflection, and Angular Velocity in Model Aircraft1. Fundamental Dynamic EquationFor a single rotational axis (roll, pitch, or yaw):
Interpretation: 2. Steady-State ConditionIn our small plane, the plane enters Steady-State quily, that is why the plane is mainly driven by FF gain
Therefore:
3. Key Proportional Relationships
4. Quick Reference
Summary
High-speed flight requires smaller control deflections to achieve the same rotation rate due to aerodynamic damping and increased control effectiveness. |
Agreed. Therefore the deflection needed to generate the force is ~ inversely proportional. (Given assumptions). So no need to bring a simulated throttle into it. THAT said, you actually wrote the dang code. And it works, presumably. I didn't write it and probably wouldn't, so whichever way you want to write it is fine by me. I'm somewhat regretting having said anything because you do great work and my comment wasn't pointing out a real problem that needed to be fixed. It just felt awkward to do a "virtual throttle". Ps I had mentioned inversely proportional to (0.5 * V)², I see why you said inversely proportional to V itself. I see V is probably more correct for correcting for external disturbances, whereas V² would be for initiating maneuver, for starting a a turn. (If I understand correctly). On an unrelated topic - I wanted to let you know I'm hoping to cut an INAV 9.0RC1 in the next couple of weeks. Hopefully with airspeed PID attenuation included. I sent a build with this plus some other PRs over to James Downing for testing. |
I think V is more important for continuous control stick input , and V² is more important for everything else including disturbances and starting a turn. I am changing my mind. considering only V, then the TPA formula can be much simplier but have some promlems.
While the virtual throttle method has some extra parameters to toggle, or add a new parameter/modify δ = δref * Vref / V curiousto know how others think |
|
I love that I have someone to discuss this with who understands it better than I do. :)
It occurs to me that V^1.3 or V^1.4 will always be in between. I think V^1.3 would probably be a good compromise between the two. Of course, if you didn't want to do a decimal exponent, something like (0.5 * V) ^ 2 would also give a compromise value in between V and V² 😜
The baseline is not having any airspeed-based attenuation at all, so IMHO capping the attenuation at 4 * vref or so would be pretty good. It's not like it explodes at the cap. It just doesn't attenuate any further. I don't think the exact cap is critical. Of course one could smooth out the saturation by multiplying by (10 - Vfactor) / (Vfactor + 8) or whatever. (Where Vfactor = current airspeed / Vref). |
Yeah I expect the deflection will be approximately linear to the force (0.5V)^2 given the material is reasonably sized for the application. In the end, I suspect that's about the difference between V^1.3 and V^1.35. |
|
I got to do a preliminary test flight of this today. I am particularly interested in this because I've wanted it for a couple years. Currently I fly the three PID profiles based on custom programming logic that auto changes control profile based on airspeed. I have tuned these breakpoints as shown below (ignore the best-fit curves). These profiles are tuned fairly high to provide the best performance and stabilization without inducing oscillations. I've put many hours of flight on these settings without issues, and these PIDs are well established. Also I am using the Matek digital airspeed sensor.
To test this PR, I applied airspeed TPA to profile 2, and added a switch that would force that profile over the airspeed-based changes. Profile 2 was tuned for use between 45 and 55 mph with no TPA in effect. So I applied the reference airspeed at 55mph, and the TPA throttle reference (BP) at 1500, which is roughly the throttle that achieves 55mph. I'll talk through my flight today. I set up the TPA % at 35 to start. I expected increasing TPA to progressively attenuate PIDs and delay oscillation onset to higher speeds. However, changing it from 35% to 100% didn’t significantly affect the oscillation airspeed, suggesting the attenuation scaling or mapping may not be strong enough. I also tried moving the BP or TPA throttle reference up and down, from 1380 to 1605 and it always seemed to oscillate around the same airspeed, 69 mph-ish. I was hesitant to change this a whole lot because I didn't really understand what effects it would have on flight performance. I never ran into any oscillations or issues at lower airspeeds, only higher airspeeds. It was hard to tell, but it seemed like it may have a little more stability when in my profile 1, than when I locked in profile 2. Because TPA is largely an invisible adjustment behind the scenes, its difficult to fully understand and visualize what's going on inside it while flying, and because airspeed is mapped on top of throttle, it makes it difficult to understand the attenuation curve when looking at the current graphs. If you've got any advice for how I should adjust the "TPA levers", I can do another test flight tomorrow to test anything different. My takeaway is that 100% TPA doesn't seen to be enough. I'd love to get a better idea of what the formula is that I applied, and what that looks like on top of the stepped profile program that I use today. BTW, I am James Downing FPV on discord. |
|
I did some further digging on this, and I attempted to visualize the airspeed TPA math directly to my stepped curve. I think I uncovered something. First, I realized I had something wrong in my earlier graph. In my second step profile, my Roll-P (which is what was likely causing my roll oscillation) is actually higher than I have depicted. I have it set at 46. So I marked that on the graph below with the green dot. That's at the reference airspeed, 55 mph. I then graphed in red and orange the two curves I flew. Starting with 35% TPA factor, and then again at 100% TPA factor. I encountered an oscillation at roughly 65mph and 70 mph. Those two points are shown purple and annotated. A rough "local max" slope line can be inferred by these two points. It shows that the ideal curve needs to be steeper than what is provided. I found what look to be two potential solutions, both graphed below. The preferred solution I believe is to remove the reference to idle throttle (or more accurately pull that down to 0). This is shown in the blue line. Unless I did something wrong in my math, its not doing what we want it to. Its really the cause of the slope limitation. When I set that to 0, I get a curve that looks much more like what is intended, and its very close to the "local max" slope in that airspeed range. An alternative approach could be to increase the TPA %. I increased it to 300% and was able to create the grey dashed line. I don't think this is as ideal, but it would be preferred to at least have greater control on the effective slope. There's also a non-zero potential I got my math wrong and translated this incorrectly, but this matches my experience. Hope this helps shed some light on what I saw. 
|
|
I need to apologize, the graph I originally produced didn’t sit right with me. The curves didn’t match the logic I expected and saw from the code and other reference material, they were far too linear looking. After re-checking the math carefully, I found some errors. The overall takeaway about why oscillation occurs was still correct, but my earlier recommendation was not. Below is the corrected airspeed-TPA graph based on the exact formulas pulled from the code (double checked this time). The red and orange lines and purple points still represent the same things in my prior post, but they show the correct overall shape. 100% TPA attenuates more than I showed before, but not significantly more. This increased the slope of the "local max" roll-P term calculated based on the oscillation points I encountered. The low-speed is boosted much more than I calculated last time, and I show the 2x cap on the graph rather than leaving it unbounded. 
My conclusion has changed. We simply need a higher dynamic TPA range in order to better match the curve of the dynamic pressure effects. Planes with looser tuning may not reveal these effects when testing. However on my tightly tuned Penguin, the mismatch is noticeable. If I had to make an educated guess at the best dynamic pressure curve based on the data I have available, I think it would be in the range of 200-250% TPA. I recommend opening the bounds for the dynamic TPA factor. Instead of limiting it to 0-100%, it needs to be 0-300% at minimum, but it may make sense to open this up further to accommodate and anticipate future needs. I also recommend the removal of the lower bound of 1/2 attenuation factor. If I had a lower bound of 1/2 TPA factor, there's a chance I'd still run into an oscillation at or above 100 mph. Difficult to extrapolate this, but I'd recommend lowering the lower scaler bound to 1/4 TPA. I think the upper bound of 2X can remain. Thanks for your time on this. I think with these small tweaks it will be ideal. Recommendations:
|
|
In speaking with Jetrell, I realized some minor clarification would be helpful. In my last post, I referred to the "TPA dynamic factor", for lack of the correct term. The correct term is Second, I recommended moving the lower attenuation limit from 1/2 to 1/4. This is a hard coded sanity limit. I added an annotation on the graph with the dotted blue lines, showing where my "theoretically ideal" 225% The recommendation is to adjust the following line in 
|
|
I'm looking to get INAV 9RC1 cut very soon so that 9.0 can be released in time to flash Christmas gifts with it. Based on the above discussion about using an exponent of around ^1.3 or ^1.5, and the testing by @trailx , do you expect to make further refinements on this soon? |
|
My tests showed the current And due to this. I also think it might be good to have the Just to add a bit more. I think it would also aid attenuation/boost response time if Down Pitch was accounted for in the calculations. I noticed there was occasionally a little bit of lag in the virtual airspeed. Likely GPS velocity related. Another thing that would be helpful for tuning. Is if the TPA gain changes could be shown on the OSD |
shota3527
force-pushed
the
sh_airspeed_tpa
branch
from
10ae664 to
4c44d5f
Compare
|
@sensei-hacker |
|
Update the pitot LPF Hz default value to 1hz, default 0.35hz is lagging |
|
Looks like you changed the code to no longer map to throttle. If I followed the math right, the proposed ^1.2 default looks like its effectively really close to my proposal of 225%. Purple line is new power function. Is this power value adjustable in the air? I didn't look that far into the code, but that's typically how I tune. 
Thanks! Looking forward to flying it. Hopefully tomorrow. |
|
@shota3527 Thanks for the extra commits.. You've ticked a lot more boxes with its handling. However, I don't mean to come across ungrateful for your work here. But integrating pitch angle based on + or - from gravity vector, would help in a GNSS failure or if a reduction in airspeed accuracy occurs in aerobatic maneuvers, which Turnrate can't detect either... Or the pitot tube gets partially blocked. It's in the case of a dive condition that the current fixedwing TPA doesn't work correctly. Because throttle can be low and airspeed will still rise in a dive. |
|
I got two flights in today on this PR. I'll try to keep my notes short. Wind was between 10-15 mph according to both feel and windspeed estimator in INAV. Once again I took off into my airspeed-driven 3-profile setup. I had a switch that would lock the middle profile, which is the one that had airspeed-pid-attenuation power at 1.20. Reference airspeed was set to 55 mph, where profile 2 maxed out previously. First flight, overall everything performed as expected. Low speeds worked flawlessly, showing excellent control at low speeds even in the wind. I did run into some oscillations in the 75+ mph range, but I noted that my pitot was under-reporting airspeed. I have both GPS 3D speed and airspeed on the OSD, and airspeed was consistently low. I've had a consistent struggle with this and am working on tuning the scale properly. Assuming this was the issue, I landed and adjusted the scale. Second flight, the airspeed was more inline with expectations at normal flight speed, while over-estimated at low speeds. I think the FC restart in windy conditions disturbed the zero offset. That said, the oscillations were gone. I did a few steep power off and power on dives without issue. Overall, this flew extremely well, and I'm looking forward to getting my pitot sensor dialed in a little better, and further adjusting things as needed. I'd like to try flying with the virtual pitot too. TLDR:
Thanks for all your work on this! |
|
In case of climb/dive situation, how about based on current throttle based tpa, offset the throttle value by "pitch to throttle value"(i forget the variable name but it is in navigation settings). Then hopefully no additional parameters needed. I am also thinking about raise the default tpa value from 0, if it is also 0 in the default presets. |
|
Notable is the physics as you dive steeper - the effect that gravity has isn't linear, especially as you get to very steep dive angles - its added effect is minimal for every additional degree of tilt. It may make sense to apply a sine function over top of the It would end up something like: 
|
Agreed. The force of gravity accelerating the aircraft (replacing motor thrust) is proportional to the sine of the angle. |
|
Yes, throttleAdjusted will decrease when the pitch is up. A 2000us throttle will decrease to 1100us for calculation with the current default value, and then the PID might be too high. |
Due to this being a shared variable. We have to be cautions of how much this setting is altered, without it effecting the navigation climb/dive throttle. Meaning that the user would also have to retune all other setting related to pitch2thr for navigation. |
|
My penguin is overpowered, and the default pitch2thr would result in it exiting automated flight climbs at a very high rate of speed. Right now its at 8 and climbs well, if maybe still a little too strong. (In RTH I like it to pop up pretty fast) The difficulty is the non-linearity of throttle % vs airspeed, and the users just need to be aware that the addition of the pitch calculation is probably limited somewhat in its effectivity to the automated flight pitch limits (its not, but it effectively may be). Tuning pitch2thr so that when in automated flight the plane does high angle climbs and dives roughly at a constant speed may be a good prerequisite to tuning TPA. |
|
@shota3527 After reading yesterdays conversation. I took one of my planes with a 2:1 thrust to weight out to test it with commit 00c9db0. As it would appear in the logic and raised by Jet. The PIDs are boosted at high climb speeds, when the throttle is significantly above the I proceeded to alter the I'm aware setting variables are a limited hardware resource. However cutting corners on such an important feature as this is not the way to go. @shota3527 I would like to encourage your efforts towards implementing such an overdue feature. ❤️ What about adding a tpa pitch scaler variable that could be adjusted by the user if their plane has a high thrust to weight. It could reduce the effect PID boost would have on such aircraft at a high climb speed/angle, without altering the dive angle attenuation function. I have not forgotten that APA is still the best approach. But this method is also required to work well if the air speed source fails. How about this extrapolation? Adding |
|
@rts18 , I don't know how tightly you have your PIDs adjusted, but did TPA+pitch work for a certain range of pitch angles? At what angles, speeds, and throttles did you run into oscillations? How far did try you adjusting pitch2thr? I have to assume that at 0, it would not create this oscillation. I also assume that at 1, it will likely not create the oscillation. Academically, at some point, you should be able adjust the pitch-up-TPA-gain oscillation out of the system by adjusting the P2T. But at that point - where it no longer creates oscillations on a climb - does it create other issues from pitch2thr being too low? Rather than going on a hunt for new solutions to fixing TPA, at what point do we try to adopt something more akin to the "basic TPA" solution that was developed by betaflight? I don't think we need to consider betaflight's advanced method, because APA fills that gap, arguably better. I'm also a bit concerned that we won't find a solution to TPA that works in all situations - and APA gets held up. I don't want perfecting TPA to hold up the implementation of APA, and at least getting that improvement out to people in 9.0. |
Climbing vertical at 80 km/h @ 85% throttle. It has a 25.2v 700w power system.
No, why would it. Have you not read how the logic works. Down pitch works as it should. pitch angle overrides raw throttle and attenuates the gains if the plane is in a low throttle dive. Instead of boosting them as the old fixedwing tpa used to.
No it won't. This was the whole point of my last post.
Dude you worry too much. What's the good of merging something that has a known and real life tested bug. When things don't get cleaned up before a merge, you end up with bugs everywhere that never get addressed. |
|
My 2 cents. APA can be effected by the results of |
You're right, I wasn't thinking. And yes I fully understand how the logic works. I was really trying to understand the details of what you experienced. Down-pitch may over-attenuate, but you're right over-attenuation isn't the concern, it just becomes less stabilized. The concern is over-boost where it can generate oscillation. I think there's another potential issue when switching to TPA and simply flying level at high throttle because it may not attenuate enough because TPA's curve is flatter than APA.
It wasn't completely clear in your last post, so I wanted to understand. I've got my P2T down to 7 now and it still maintains speed in climb. I think I could probably go lower without issue. I may have my cruise throttle set proportionally higher than you to stay further away from stall.
Maybe you're right, its my engineering brain mitigating schedule risk. To me, APA is the single most important fundamental fixed-wing feature that I've been wanting and advocating for over the last couple years. That said, TPA has never controlled gains appropriately on a fixed wing, and I don't think it will ever function as well as APA. If it did, we wouldn't even need an APA solution. So that’s why I’m concerned about a fundamental mismatch here that may not have a solution: But, I realized last night that there may be a simple workaround for anyone using APA. I think you can avoid almost all TPA-fallback oscillation issues by setting tpa_breakpoint to a throttle value significantly below the throttle required to maintain the reference airspeed used by APA. For example, on my penguin, looking at the graphs, I’m thinking I'll actually set it to 1000, while it flies at the ref airspeed at about 1450. Doing this accomplishes several things at once:
This basically “chops” the PID gains if APA drops out. No code changes needed, just documentation of best practices, and this only becomes an issue if people start tuning higher PIDs, I doubt theres any issue when flying defaults. |
|
The following graph overlays APA’s adjustment factor with TPA’s adjustment factor on roughly equivalent X-scales between throttle (top) and airspeed (bottom) for my particular airframe. Obviously this will vary from plane to plane (and airspeed and throttle are not linear) but this gives a reasonable visual comparison and shows the fundamental flaw. If you tune your PIDs to be very stable (but not oscillatory) at ~50 mph / 1500 μs, you can see the mismatch that appears between APA (green) and TPA (dotted red), even with 100% TPA. At any point beyond their common setpoint. TPA is simply unable to attenuate gains enough. Simply divorcing On the opposite end, if you pitch up hard enough to drive throttle into a region where TPA-boost would exceed APA’s factor, then you hit the other issue we’ve been discussing, its just not as visually evident. If you lower the TPA breakpoint to 1020 μs, you get the yellow curve. As far as I can tell, it still bottoms out at 0.5, due to the (Oh yeah, and I dropped the idlethrottle to 1000 in this graph, which may not be ideal... when breakpoint and idle throttle invert, the graph does strange things.) Here's the reference graph, with what I think is a decent workaround, and the way I will set up my plane for now (yellow) to mitigate the issues we've discussed: |
That won't have any effect on the reported condition because the throttle is still above the breakpoint no matter how far. @trailx Please stop distracting from the problem with workarounds. Open a chat in the Discussions section. shota3527 is a capable developer. He will fix the issue when he has time. There are two issues.
|
|
Let's not discourage active participation... I agree with you that the workaround I mentioned isn't the final solution, but openly talking through the issues is part of the process of solving it. I think if we put it simply, if TPA is the fallback, the solution needs to ensure TPA's gains are never above APA's. After more thought, I think I can boil my thoughts down to two code recommendations, and one general setup recommendation:
I'd like to test the fallback functionality directly... is there a clever way to force APA to dropout via a switch? Best I can think is setting up two identical control profiles, and setting APA_pow = 0 on one of them? |
|
I flew the "workaround" that I had mentioned, setting The only issue I saw was about 1 second of roll oscillation at high throttle during a pitch-up maneuver, but damped out quickly as the airspeed dropped. Considering this plane is tuned very tight, the workaround seems viable for flying APA currently and concerned about inducing oscillations in the case TPA is engaged. Plus, I still don't know of another way to functionally and cleanly reduce PIDs when it falls back from APA to TPA. In the case of a fall-back to TPA, it may make sense to issue a system warning on the OSD, so the pilot can have situational awareness of the error and know to fly more conservatively. Something like "AIRSPD FAIL - TPA" could be displayed, just to alert to you an otherwise invisible function that could cause issues if not carefully configured and tested. |
|
@shota3527 do you have any thoughts on the last few comments? |
|
I have read comments and made some updates
I think BaroVerticalSpeed is not a good idea because it is speed, not acceleration/trust or force, so it is not appropriate to add or convert it to the throttle value. |
shota3527
force-pushed
the
sh_airspeed_tpa
branch
from
e40f197 to
253cd41
Compare
|
Thanks for making the changes @shota3527 I updated the Wiki to fall inline with your last commits. To help other testers understand how to tune it. |
|
I did more in depth testing of TPA + pitch angle with high speed vertical climbs and dives. The results were good, no oscillations where seen on this model at over 100km/h sustained climb. I had I could leave my tuning results here. But in reality, this plane is at the high end of FPV performance. So its tune is unlikley to be used by most people..
I also tested APA again. It still works as before. |
|
Tested with new This TPA_APA feature works fine out of the box for most models. However it's good that it now accounts for faster airplanes as well if the air speed source fails. Thanks again @shota3527 |
Add airspeed TPA support (backport from #11042) via merge from master
7 participants
User description
add a cli command to let fixed wing use airspeed based tpa.
It calculates the corresponding throttle value based on the airspeed. Ensure a seamless integration with the current throttle-based TPA. Turn it on with cli command and no more tunning is needed, fallback to old throttle based tpa if airspeed is not avaliable
tpa_breakpoint + (airspeed - fw_reference_airspeed)/fw_reference_airspeed * (tpa_breakpoint - ThrottleIdleValue(default:1150))
sim test ok
recommend to raise pitot_lpf_milli_hz on vitual pitot
PR Type
Enhancement
Description
This description is generated by an AI tool. It may have inaccuracies
Add airspeed-based TPA calculation for fixed-wing aircraft
New
airspeed_tpasetting to enable airspeed TPA modeRefactor TPA calculation to support both throttle and airspeed
Add airspeed validity check function for sensor health
Diagram Walkthrough
File Walkthrough
controlrate_profile.c
Initialize airspeed TPA settingsrc/main/fc/controlrate_profile.c
airspeed_tpafield initialization to control rate profile resetfunction
controlrate_profile_config_struct.h
Add airspeed TPA configuration fieldsrc/main/fc/controlrate_profile_config_struct.h
airspeed_tpaboolean field to throttle configuration structuresettings.yaml
Configure airspeed TPA settingsrc/main/fc/settings.yaml
airspeed_tpasetting configuration with descriptionpid.c
Implement airspeed-based TPA calculationsrc/main/flight/pid.c
calculateMultirotorTPAFactorto accept throttle parameterpitotmeter.c
Add airspeed sensor validity checksrc/main/sensors/pitotmeter.c
pitotValidForAirspeedfunction to check sensor validitypitotmeter.h
Expose airspeed validity functionsrc/main/sensors/pitotmeter.h
pitotValidForAirspeedSettings.md
Document airspeed TPA settingdocs/Settings.md
airspeed_tpasetting