Closed avsaase closed 4 years ago
Issue-Label Bot is automatically applying the label Feature request
to this issue, with a confidence of 0.90. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
A workaround might be to disable yaw stabilization (freeze I and zero P) when there is pilot input on roll or yaw axis. If the pilot doesn't command anything - keep full yaw stab enabled.
I can understand why Devs wouldn't want to break a long established naming convention, but I think it's useful to reflect on the use of these terms in other flight controllers/receivers.
Acro mode in its current implementation is akin to what other gyro systems call a heading hold mode. The behaviour described by the OP is more akin to a traditional rate mode gyro.
The proposed solution is similar to what other ecosystems call stick priority, although it would be dialling back gains on the yaw axis in response to inputs on the roll axis.
I'd be happy to do some testing and offer input. I'm a full scale pilot and on any larger aircraft we have an autopilot function called Yaw Damper. Its primary role is to eliminate an effect called dutch roll, but it functions secondary to reduce the effect of turbulence, and adverse yaw.
This is the exact function needed to turn a inav plane with rudder into a true "fly-by-wire" machine. The pitch and roll axis lock of ACRO with a pilot induced yaw aware gyro response on the rudder.
I've got a plane with a Matek F405-Wing for blackbox logging and it has a rear camera that can see the tail and rudder surfaces. It's actually an A-tail so it's a rudder-elevator but still should be able to directly observe tail surfaces.
There is no easy way to distinguish between pilot input or a wind gust in ACRO
since stick is no longer applied once you reach the desried bank angle. To be honest I don't see the need of yaw stabilization in ACRO
mode at all. In a plane with a tail the vertical sabilizer is what gives the yaw stabilization aerodynamicaly, in a turn its a pilots responsability to coordinate aplying rudder. And if he goes for some sport acrobatic flying, last thing he needs is an algorithm not aware of whats going on messing with the tail.
ANGLE
is a different story because there is a constant pilot input during a maneouver so that the system knows when it is a commanded response. The maneouvers are also quite limited by max angle which makes things simpler. I think its enough to dynamicaly reduce or even block I
therm above certain bank degree to stop the rudder counteracting the turn.
There is no easy way to distinguish between pilot input or a wind gust in
ACRO
since stick is no longer applied once you reach the desried bank angle. To be honest I don't see the need of yaw stabilization inACRO
mode at all. In a plane with a tail the vertical sabilizer is what gives the yaw stabilization aerodynamicaly, in a turn its a pilots responsability to coordinate aplying rudder. And if he goes for some sport acrobatic flying, last thing he needs is an algorithm not aware of whats going on messing with the tail.
Then why bother with stabilization at all? We can build aircraft with dynamic stability. Just add a bit of dihedral and boom, your roll is stabilized aerodynamically. Who needs iNav? Except that active stabilization by a computer is faster and better. It's the same with Yaw.
As proposed yaw stabilization works the same way as pitch and roll stabilization in Acro, with the addition it needs to be able to understand the effect of a banked aircraft and determine if the aircraft's movement about the vertical axis is as desired. It will dampen turbulence and uncommanded movement while not fighting an aircraft turning. It absolutely has value, and as I've said, in manned aircraft equipped with such a system it is almost always on, even if the rest of the autopilot is off. In terms of an FPV craft it will lead to smoother experience through the goggles. Yaw waggle is a common affection of most flying wings, and even airplanes with tails/rudder are not immune. With this functionality I'd be inclined to maybe try something like drag rudders too on a wing.
I don't know anyone flying iNav with a sport/3d aerobatic aircraft. However, if they were they wouldn't be happy with ACRO mode as it is now either. I've flown very maneuverable parkjets with an FC that had a rate/acro mode and experienced the same issue. Yaw is fundamentally linked to bank an airplane, it can not be decoupled like a multicopter. During normal flight when you roll into a turn you only need to apply rudder when using the ailerons because of adverse yaw. Once you reach your desired bank angle and return the ailerons to neutral the rudder should be centered. Now as you continue your turn iNAV in ACRO mode sees a uncommanded yaw error accumulating and it will use the rudder to resist it. Most iNav aircraft either don't even have a rudder (wing), or it isn't very strong. Try that in a 3d airplane with a massive rudder and I think we would see some interesting effects. I certainly saw some funky things in my parkjet. So the pilot is forced to input the "incorrect" use of rudder during the steady state turn. But it's hard to say how much rudder since we have no slip indicator. So you are just guessing. I've seen this on my own iNav aircraft, thankfully the rudder is fairly anemic and being a little off isn't really a problem. It would be better though if a flight controller didn't ask you to make an input that you wouldn't need if it didn't have a flight controller.
It's actually somewhat simple to decipher the required yaw rate in a turn. It's a calculation from airspeed and bank angle, (G * Tan(Bank Angle)) / V. There is a "correct" amount of vertical axis angular change for a given speed and bank angle to fly coordinated and any movement that occurs outside of that parameter should be corrected. iNav already does this with TURN ASSIST mode. It's less then perfect because most of us don't have an airspeed sensor so it uses a preconfigured value if you don't have one.
Take something similar to that code, and add it to a new version of ACRO mode where it fights uncommanded movement about the yaw axis, but understands that a 30 degree bank at 40 mph will have a rate of turn of 18° per second and that only deviations from that should be considered error. It won't be accurate without an airspeed sensor, but it should be ok as long as you configure that speed to a common speed range.
A workaround might be to disable yaw stabilization (freeze I and zero P) when there is pilot input on roll or yaw axis. If the pilot doesn't command anything - keep full yaw stab enabled.
I think yaw stabilization should be disabled when the plane is banked, not when there is no stick input. When making a turn in acro you give some roll input intil the plane is at the desired bank angle, but after that point the plane will make a turn without any more pilot input.
Take something similar to that code, and add it to a new version of ACRO mode where it fights uncommanded movement about the yaw axis, but understands that a 30 degree bank at 40 mph will have a rate of turn of 18° per second and that only deviations from that should be considered error. It won't be accurate without an airspeed sensor, but it should be ok as long as you configure that speed to a common speed range.
This is exactly how ACRO + TURN ASSIST behave.
I think yaw stabilization should be disabled when the plane is banked, not when there is no stick input. When making a turn in acro you give some roll input intil the plane is at the desired bank angle, but after that point the plane will make a turn without any more pilot input.
"Banked" is not quantifiable. Is 10 degree == "banked"? Is 5 degree banked? Is 0.5 degree banked? From stabilization perspective anything that is not exactly zero is "banked". There is no "one size fits all" solution here, so I'm sticking to the TURN ASSIST logic which guesstimates the desired turn rate and tries to enforce it.
"Banked" is not quantifiable. Is 10 degree == "banked"? Is 5 degree banked? Is 0.5 degree banked? From stabilization perspective anything that is not exactly zero is "banked". There is no "one size fits all" solution here, so I'm sticking to the TURN ASSIST logic which guesstimates the desired turn rate and tries to enforce it.
I understand that, but implementing an cutoff point such as 5 or 10 degrees roll could work. My problem with TURN ASSIST is that on all of my planes it just doesn't fly nice. It always feels like there is someone else adding extra roll input or playing with the pitch which makes it very awkward to fly. While TURN ASSIST may be a theoretical solution to this issue, it just doesn't work well enough in many cases.
I understand that most people here fly wings, but I read a lot of complaints about INAV and rudder on YT and FB so I think it would be worthwhile to address these issues.
Again, there is no "one size fits all" solution, therefore we're sticking to one that at least has laws of physics backing it.
Disabling stabilization on Yaw is trivial - zero out P, I and D and leave only FF. You'll still have stick control, but no yaw stabilization.
I think its enough to dynamicaly reduce or even block
I
therm above certain bank degree to stop the rudder counteracting the turn.
I am playing around with something like this and I wonder if this should apply to pitch as well. It may not be that noticeable as with yaw, but making a banked turn also induces a pitch rotation in the plane reference frame. WDYT?
Disabling stabilization on Yaw is trivial - zero out P, I and D and leave only FF. You'll still have stick control, but no yaw stabilization.
Never thought of this, I hope it helps with yaw instability causing roll instability on my micro flying wings.
@paralin wing normally don't have yaw control, so then making these changes has no effect.
Disabling stabilization on Yaw is trivial - zero out P, I and D and leave only FF. You'll still have stick control, but no yaw stabilization.
Never thought of this, I hope it helps with yaw instability causing roll instability on my micro flying wings.
Beware, thats true for PIFF controller but not for PID controler that is now selectable for planes.
Current Behavior
In
ACRO
, all three axes are controlled independently. This may be desirably for pilot who fly acro manoeuvrers, but leads to unexpected behaviour for all other pilots. When the air plane is banked, the rudder tries to counteract the resulting turn because this is seen as uncommanded yaw. This leads to a cross-controlled air plane. The same behaviour occurs inANGLE
andHORIZON
, where it is definitely not needed.TURN ASSIST
provides a a partial solution by automatically applying rudder and elevator when the plane is banked. However, many pilots don't want to use such a "mix", so I don't consider this a full solution. Moreover,TURN ASSIST
requires turning parameters that you currently cannot change in the OSD menu or the configurator, only in the CLI.Setting the yaw P and I gains to zero, or using rc yaw instead of stabilized yaw solves the problem, but at the cost of losing all yaw stabilization.
Desired Behavior
There is a mode (perhaps called
STABILIZE
orSTAB
) that flies similar toACRO
, but the rudder does not counteract turns. I think this should then replaceACRO
as the default mode because it is probably only a small minority that use INAV on fixed wing aircraft for acro flying.Suggested Solution
I understand that this may not be an easy problem to solve. After all, how does the flight controller know that you want to turn, or that it is a gust of wind that need to be corrected? Ideally, you'd have some sort of equation that determines the expected turn rate based on the bank angle so that the flight controller can correct any additional yaw movement. If I understand correctly,
TURN ASSIST
does something like that, but not exactly the same, because it calculates the desired turn rate for a nice coordinated turn.As a simpler solution, the yaw gains could be reduced proportional to the bank angle. For sharp bank-and-yank turns, this would momentarily disable stabilization, but keep yaw stabilized in level flight.
I am by no means an expert on this, so there may be better ways to tackle this.
Who does this impact? Who is this for?
All pilots that fly fixed wing aircraft that have direct yaw control, either with a rudder or differential thrust.
Additional context
This feature request is a follow-up from #5800 . See also this and this video by Andrew Newton, and the comments on those videos. I think a lot of pilots would be happy with such a flight mode :)