Fix FW transition throttle glitch for tilting rotor quadplanes

[priseborough]

This is a fix for the instant forward motor(s) throttle drop that can occur when a quadplane with tilting rotors completes the transition from VTOL to FW flight. This issue was reported here #28957

This fix:

Extends the functionality of the set_throttle_min function such that the rate that the lower limit releases can be controlled by a TECS_THR_ERATE parameter and the throttle out previous value used by the TECS throttle rate limiter can also be optionally reset. If TECS_THR_ERATE is <=0 the legacy behaviour will be observed, ie the minimum throttle will be held for one TECS frame after the function is called.

Adds a function to the motors library that enables the raw normalised throttle demand to be obtained for a specified motor index.

Adds a function to the SRV_Channels library that enables the slew rate limiter state to be set for a specified channel function.

Adds a function to the tiltrotor class that provides the mean throttle of all tilting motors.

When the transition into FW flight is ready to complete it checks for a throttle demand from tilting rotors or if not available the forward motor throttle demand. The TECS minimum throttle and SRV_Channels forward throttle are both set to this value.

Testing on a multirotor VTOL with forrward tilting motors shows that the TECS throttle lower limit is set and releases at the specified 0.2 rate.

Here's a before and after for a SITL test using the -v Plane -f quadplane-tilthvec option

Before - the throttles of the tilting motors step to 0 before increasing

After - the throttles of the tilting motors ramp down smoothly

[priseborough]

@tridge - I need help with setting up compiler directives to manage flash space

[tridge]

thanks for this @priseborough !

[tridge]

@priseborough also please note this PR which allows the existing throttle slew limit to apply to tilted motors:
#28960
we may want both mechanisms. The advantage of the other PR is it works for non-TECS modes

[priseborough]

@priseborough also please note this PR which allows the existing throttle slew limit to apply to tilted motors: #28960 we may want both mechanisms. The advantage of the other PR is it works for non-TECS modes

I think we need both. That PR deals with issues before transition completes, this one with what was happening immediately after for tiltrotor setups. Note that the reset of servo throttle channel slew limiters should also help for non TECS modes after transition completes.

[IamPete1]

This looks good. #29011 Would handle the smoothing of the throttle outputs. But you would still need to workout the average throttle for the TECS re-set.

[IamPete1]

Do we need a new param? Can't we use the existing plane throttle slew limit?

[priseborough]

It needs to be slower based on flight testing where the tilting rotors were energising the front wing in a tandem wing configuration.

[IamPete1]

OK, should we default to 0 meaning use the existing slew limit? Or at least we should use the larger of this and the existing slew limit. Someone may have set a very slow slew limit already.

[priseborough]

In the process of cleaning it up and updating in response to review comments a single frame glitch in the servo demands has been introduced. I'll remove the needs rework flag when the cause of this has been resolved.

[priseborough]

The reason for the glitch in servo demand after incorporating review comments was af73ffb

The current throttle state also has to be reset to avoid a glitch if the TECS throttle demand is fetched before the next TECS update cycle.

I've added a patch that adds the set of current throttle state.

[priseborough]

@IamPete1 and @tridge using the conversion form thrust to throttle applied to thrust demand is not exactly the same as retrieving the raw throttle demand.

If I revert commits 3ad8f32 and 8d227d9 I get the following ESC demands for vectoring quad SITL test

Using the thrust to throttle scaling I get a small dip at the time of the reset, indicating that motors->thr_lin.thrust_to_actuator does not produce the same result as motors->get_raw_motor_throttle.

I worked out why this was happening. The motors library throttle to thrust and vice-versa transformations operate with throttle in the range from spin min to spin max. Plane does not do this so the throttle returned by thr_lin.thrust_to_actuator needed to be mapped to the range from spin min to spin max. Doing this removed the throttle glitch.

[priseborough]

@tridge and@IamPete1 I've tagged it for the next dev call.

[priseborough]

It has been flight tested on a ARACE tiltrotor at commit 1204cba

Here are a couple of the forward transitions from the flight:

Transition in AUTO - no sudden dips in forward throttle on completion

Transition from QLOITER to CRUISE - no sudden dips in forward throttle on completion

[IamPete1]

OK, should we default to 0 meaning use the existing slew limit? Or at least we should use the larger of this and the existing slew limit. Someone may have set a very slow slew limit already.

[priseborough]

@IamPete1 wrt your comments on the default value for TECS_THR_ERATE here #29696 (comment), the AP_TECS::set_throttle_min function is only called with the reset output and slew limiter option for the tiltrotor cases so no other airframes are affected and it might be safer to decay TECS throttle lower limit for tilt rotors rather than wait for a user to stall a flow energised wing during transition and then realise they should have set TECS_THR_ERATE to a positive value.

[priseborough]

I've rebased and fixed the conflicts by removing an unnecessary reverted logging commit in TECS.

[tridge]

looks good, thanks!
just a small update to the new TECS parameter. Let me know if you'd like me to make and test that change

[IamPete1]

With the throttle scale corrected it seems to work as expected. This is Qloiter to FBWB.

Throttle min is set to the current throttle then it decays back at the default 20% per second. High throttle in this case so it takes nearly the full 5 seconds to get down to 0. In this case the output throttle was soon constrained on that limit,

[tridge]

@IamPete1 @priseborough I've pushed the fixes and squashed

[tridge]

looks good in RealFlight testing

[IamPete1]

LGTM

fixed