Plane: Pitch stick mixing doesn't conserve energy

[rubenp02]

Bug report

Issue details
Stick mixing operates by changing the attitude demand, which is fine for roll but can have really bad consequences for pitch, as the system is decoupled from the TECS. If a stick nudge is held long enough, an overspeed or a stall WILL occur. This could be worked around by weighting the mix with the flight energy, but ideally the pitch mixing logic should live in the TECS itself and operate by nudging the altitude rate instead of the pitch directly.

Since there's a removed "DIRECT" stick mixing mode that falls back to the FBW logic, this could become the way to use the current stick mixing logic with FBWA-style pitch control, and a new "FBWBMixing" mode that uses the TECS-based pitch mixing could replace the "FBWMixing" mode, and be the new default. The "DIRECT" mode would be renamed to "FBWAMixing".

Platform
[ ] All
[ ] AntennaTracker
[ ] Copter
[X] Plane
[ ] Rover
[ ] Submarine

[Georacer]

Hi Ruben!

In general, we consider it important that each flight mode flies as expected.
For example, MANUAL mode is expected to provide direct control to the servos.
FBWA is expected to map directly to roll/pitch angles.
And FBWB is expected to govern roll angle and climb rate.

It's not clear to me to which mode this style of mixing that you describe would/should apply?

[rubenp02]

It would apply to all modes that provide stick mixing support, such as Auto, Guided, Loiter, etc...

The only difference between it and the current "FBWMixing" default stick mixing mode would be that the pitch stick would nudge the TECS rate instead of the pitch demand like it currently does.

[Georacer]

Ah, I got confused with servo mixers, my apologies.

I must admit I haven't used stick mixing much. But indeed currently I would expect them to act upon angle, not climb rate.
This is simpler, because the attitude controller doesn't hold a lot of state. Whereas it would be harder to reset TECS back onto the original trajectory.

I agree that an 'FBWBMixer" would be the safer option.

[rubenp02]

I've taken a shot at a safe, FBW-B style pitch stick nudge, and it turns out it is not trivial like I thought. The idea was to implement it as a rate nudge (a given pitch stick position commands a rate that is added or subtracted to the current rate), but since the setpoint of the system is an altitude and the rate is its derivative, that's not really possible.

Here's a diagram of the possible behaviours of this approach:

In this example, a 3 m/s rate nudge is added and held, which of course means the aircraft should climb at 3 m/s. But the problems arise when the nudge is changed (in the example, increased to 5 m/s):

• Pink option: Discontinuities in the altitude demand occur when the nudge changes. The altitude reference point must be reset on stick release, which introduces even more discontinuities. The longer the nudge is held, the worse this behavior gets.
• Blue option: Starts a new rate path on nudge change. Among other issues, this causes an initial move in the opposite direction when the nudge is increased. If the previous nudge was held for a long time, this deviation can be very large and highly undesirable.
• Green option: It's the only one that doesn't introduce discontinuities, but effectively makes the nudge persistent, defeating its purpose. If it's reset to zero when the stick is released, going from a minimal nudge to zero would cause a large correction with no way to immediately undo.

Furthermore, in practice, the stick inputs would be continuous and noisy, which makes pink and blue even less viable.

So the only somewhat viable option is nudging the altitude instead of the rate, which would of course have limits and probably feel quite unintuitive to control. Because the existing pitch stick mixing is very likely to cause stalls/overspeeds if overused (and a stall in an autonomous mode is very bad news, as the attitude control tends to make the aircraft spin), maybe a way to disable pitch stick mixing would be a good idea? By the way, the current pitch mixing has a bug in it: it doubles the stick input on max deflection in an attempt to ensure full override of any pitch setpoint, but since pitch limits are typically asymmetric, this can result in cases where the override is not fully achievable.

Edit: At least some sort of warning text in the documentation and/or STICK_MIXING param. description should be added IMO.

[LupusTheCanine]

1. We probably need TECS rework to support more "edge of envelope" though automatically finding max flight path angle velocity will likely be quite hard without a characterization flight and there would be need to update it if weight/performance changes.
2. I would do a combination ±0.9 is either linear or exponential altitude offset and edges of the range are maximum vertical speed climb/descent. If we exceed offset range switch to half range vertical speed control (unrestricted climb/descent) where midpoint means return to setpoint at maximum rate, ±0.5 maintains altitude and ±1 moves away from setpoint at maximum rate. Switchback to offset mode would occur when demanded offset would be greater than current offset (minding the sign of correction).
   I would provide option to allow or inhibit unrestricted climb/descent though I am not sure which would be better.

PS modern RC systems aren't that noisy.

[rubenp02]

I agree with point 1 but I a simpler and more immediate solution should probably be implemented in the meantime, no? As for point 2, I like the idea in general (although maybe it's a bit too complex to be immediately intuitive? Not sure), but there's currently no non-hacky way to command a specific climb/sink rate, and the hacky ones can't be cleanly integrated with the standard altitude control without introducing height demand discontinuities which I think introduce too much potential for bugs/unpredictable behavior. As for the noisy input, I was mostly referring to the jitter in user input, not to RC noise.

[peterbarker]

The current "damn the controllers, full speed [up]" approach is there quite on purpose.

We don't involve the controllers as if auto or loiter or whatnot isn't doing what you expect and you need to control the vehicle - you really shouldn't be involving the controllers in responding to those inputs. This is how we get ridiculous i-term buildups and whatnot when doing stick-mixing. It's known and expected :-)

We in fact balance things so that the operator can always override the controllers.

Do you think that reasoning is sound? It's not neat, it's very messy, but it is also extremely reliable.

[rubenp02]

I completely agree that the current FBWMixing mode is useful for what you say, i.e., emergency situations where there's an immediate obstacle, the aircraft has lost control, etc. In those situations, the energy control is of course a secondary issue. I also agree that its very reliable because its behaviour (aside from the stick mapping bug) is simple and predictable, whereas a safer version probably wouldn't. My main issue is that, as it is right now, you'd want to disable it for well tuned, production aircraft, because its an inherently unsafe feature. Since the roll part is fully safe and also nice to have for reasons other than emergency situations/obstacle avoidance, IMO at least that should be possible to keep enabled.