Acro: SuperExpo Stick Input

[MaEtUgR]

To do actual acrobatic moves you need to have high rotation rate inputs available which was until now achieved by setting high MC_ACRO_X_MAX parameters (X being R,P,Y). The problem with this is that you very fast loose sensitivity around the stick center to keep the vehicle stable and smooth with your small corrections.

That's why people flying model helicopters and race quads like to use a so called exponential curve.
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/19890199/Expo+setup
It's nothing else than rescaling your stick input depenting on the stick deflection. What it does mathematically is a linear combination of a linear function and a cubic function between your -1 to 1 stick values.

For more details refer to #6440 and #6625 where the expo input curve was already introduced for position controlled flight.

My tests so far are using jmavsim on very low resolution to reduce delay and a ***** xbox controller and it seems to work as far as it's possible to tell with bugging sticks and input delay. Looking forward to test this on the racer build https://dev.px4.io/en/airframes_multicopter/qav-r-5-kiss-esc-racer.html tomorrow.

@bkueng I plan to use this for further FPV performance tests.

mc_att_control: use expo input for acro mode to allow for high input rates without loosing input sensitivity

[bkueng]

Can you describe that this applies to roll, pitch & yaw? And maybe that a linear combination is used between the 2 extremas?
Other than that, it's ready to be test-flown.

[MaEtUgR]

Today while studying my current input rate settings I fly with in a tool I realize there's more to the very good control feel than just expo. Flyduino uses an additional f(x) = 1/(1-abs(x)*g) function to further enhance the input curve. While I totally see why they do this because the resulting curve feels very intuitive to fly I don't like the functions parameter g adjusting the maximal anglular output rate. I have to come up with a good way to parameterize the input function such that maximum and shape can be easily tuned.

[MaEtUgR]

I added a so called SuperExpo function for further stick input curve shaping which makes it in my opinion much more intuitive.

---

Reference implementations

• KISS FC rc curve http://ultraesc.de/KISSFC/rates.html (see javascript source for formula)
• betaflights implementation (thanks @bkueng for showing me)
  https://github.com/betaflight/betaflight/blob/master/src/main/fc/fc_rc.c#L128

KISS uses exactly the following formula: y = r * 200 * (x*x*x*e + x* (1-e)) * 1/(1-abs(x)*g);
interactive plot: https://www.desmos.com/calculator/zuqgbayd9g
and betaflight almost the same just with x^4 as expo which is a small difference in stick feel.

r*200 is basically to set your linear range of setpoints
(x*x*x*e + x* (1-e)) is the basic cubic expo
1/(1-abs(x)*g) is the superexpo term

The problem with this formula in my eyes is that it's not intuitively clear what maximal setpoint you'll have from the function parameters r, g and e. That's also why they have to supply users with the tools to thinker around https://kiss.flyduino.net/dwkb/ratetool/ . r changes the linear stpoint range in their formula as a factor of 200deg/sec, g changes the scale in a non-linear way which is horrible to tune and e does not change the scale when operating in [-1,1].

---

Adjustments
Hence I adjusted the superexpo term to preserve scale and only change curve shape which is what the user wants to achieve: (1-g)/(1-abs(x)*g) and made r*200 adjust to our maximal rate setpoint parameters. Which means that the maximal rate setpoints are defined by MC_ACRO_X_MAX and only the shape of the curve is adjusted by e - MC_ACRO_EXPO and g - MC_ACRO_SUPEXPO.
interactive plot: https://www.desmos.com/calculator/yty5kgurmc

The branch is only tested in jmavsim with an xbox controller yet. The feel enhanced a lot even with this **** quality gamepad. We should consider to also test this for position control input in the future to make manouvering easy but still have a high maximal velocity setpoint.

EDIT: I made a plot with PX4 and KISS one on top of the other for direct comparison: https://www.desmos.com/calculator/ugh6vstxkn

[MaEtUgR]

CI fixed, ready for outdoor test.

[MaEtUgR]

outdoortest went wrong... the RC curve worked, I did a roll flip and ~10 seconds later the racer dropped out of the sky and crashed...
Log: https://logs.px4.io/plot_app?log=b641202a-d22c-4556-964f-cd136a96cb9c
It's not accidental disarm and you can see the motors stop one second before the log stops...

The thrust spike was not commanded by me... and yaw does a strange spike as well. Something goes wrong in the rate controller or the mixer... I have to say I had these mixer changes flashed to test this pr: #7920

[bresch]

@MaEtUgR For the spike in the thrust output, it should not be related to the mixer since the spikes comes before it. In rate control, isn't the thrust directly a scaled version of the throttle stick?
However, the motor disarm part is most likely from the mixer and looks induced by the spike.

[MaEtUgR]

@bresch I assumed the same, the thrust should come directly from the stick and also the yaw did not command such a peek, while I touched yaw in this pr I did not touch thrust at all. I know the torque logging is before the mixer...
How can the mixer disarm?? That's new for me.

[bresch]

I'm pretty sure that the problem you encountered is unrelated to this PR nor the mixer PR. Since everything happens at the exact same time, it looks more like a glitch deeper in the autopilot.

[MaEtUgR]

@bresch I agree.
@bkueng found a plausible scenario that I would also assume happened:
I configured the arm switch, it reacts on a switch transition because in position control you cannot diarm and I wanted to still allow stick arming. For the flight I let the switch on disarmed and armed by stick. We had two FrSky Taranis both correctly bound to their respective vehicle (we are sure about that). The other Taranis could have been turned on in this moment and caused a twitch in the arm switch channel. The twitch first caused a transition to armed and then one back to disarmed (in which state the switch still was). The resulting state is disarmed.

That would explain everything and that's why I quickly tried to reproduce in a bench test. What I got is a message in QGC (while turning the other Taranis on and off) that transition from ARMING_STATE_ARMED to ARMING_STAT... is not allowed, sadly the rest of the message was cut and it seems to be not easy to reproduce... We need to be cautious with kill switch and armed switch if RC is not reliable. And see how we can reproduce the issue for safety measures.

It has most likely noting todo with this pr and as I repaired the vehicle I can test again without risking the same issue.

[bkueng]

Thanks for the update @MaEtUgR. I agree, I don't see a way how this, or the mixer PR could have caused it.
I see an RC glitch, which happened between 2 logged messages (since we don't log all RC messages) as the most likely cause.

[bkueng]

I think we can merge this