Support thrust reversal for vtol back transition

[sanderux]

This enables active braking during back transition by reversing thrust.
It relies on ESC's that have a channel to control motor direction like the Hobbywing Platinum pro series.

Currently it has only been bench tested, flight test will be performed soon.

/cc @AndreasAntener @Tumbili

[dagar]

Awesome! Very interested to see a side-by-side comparison.

Thrust reversal (airbrakes) is common in real planes and this would fit into the FW controller nicely alongside flaps. Then VTOL would simply set apply_airbrakes at the appropriate time (https://github.com/PX4/Firmware/blob/master/msg/vehicle_attitude_setpoint.msg#L21) during back transition. Planes could then consider using it for braking during landing at the appropriate time.

It's the same solution, just moved to a different part of the codebase to enable wider usage.

[LorenzMeier]

@dagar The one corner case I see is that I could see us wanting to brake using this completely even with multicopter engaged. That would be much smoother.

[LorenzMeier]

@sanderux Could you add the same into the fixed wing controller and fix the circle CI error?

[sanderux]

@dagar Implementing this for FW is a good idea, but that cannot be implemented the way i have done now. Currently it applies a fixed reversed throttle for the duration of the back transition without any control on airspeed or velocity. Doing so to slow down a fixed wing will surely lead to problems.

After a chat with lorenz the current proposal is to leave it in the vtol attitude controller for now and replace it with a velocity controlled method in the FW controller as soon as we find the time to implement that properly.

Do you agree?

[dagar]

Yes a velocity controller would be preferred, but what I was proposing was simply moving the same implementation into fw_att_control, and enabling with a bool in the attitude setpoint (similar to flaps). During back transition vtol_att would set apply_airbrakes = true, otherwise it would be false. This is actually of limited utility initially, however it accomplishes a few things.

1. Gives a base for expanding the usage with pure FW.
2. Avoids parameter churn later on. Once this is in and you start relying on it are you really going to be okay with it changing?
3. Doesn't further entrench the current vtol architecture. This is a much larger discussion, but it's not actually necessary to hijack each controllers published actuator controls, make minor changes, and republish. Everything we need to do in vtol can be accomplished with FW and MC controllers maintaining ownership of their respective actuator controls and appropriate mixing.

Yet another idea is to find a way to do this at the mixer level. The idea of an actuator output with a direction controlled by another output seems even more general than vtol or fw airbrakes. Then you could simply publish a negative thrust during back transition. We'd have to find a way to make a negative thrust correspond to a fixed 20% output on the additional pwm + positive pwm output, but overall it would be much cleaner.

All that is to say, I'm not opposed to this implementation right now if you're willing to tolerate some churn (and likely retesting) later on.

[bresch]

I agree with @dagar that the best place to put this would be in the mixer itself and then simply be able to publish a negative value.

[sanderux]

Wouldnt that then require a different mixer for every esc?

[sanderux]

Yet another idea is to find a way to do this at the mixer level. The idea of an actuator output with a direction controlled by another output seems even more general than vtol or fw airbrakes. Then you could simply publish a negative thrust during back transition. We'd have to find a way to make a negative thrust correspond to a fixed 20% output on the additional pwm + positive pwm output, but overall it would be much cleaner.

Is the current mixer capable of doing this? The esc requires a constant PWM between 1000 and 1200 on the reversal channel for normal rotation and a PWM > 1200 for reverse rotation. If the signal goes below 1000 the esc goes into failsafe mode

[AndreasAntener]

It would require a new mixer class that steals 2 outputs and sets the second output according to the sign of the control input received. That way the system can just work with negative thrust to activate it and is independent of the ESC. In that case, any breaking logic implemented works as well with ESCs that support reversal below the midpoint (and have a simple mixer).

[sanderux]

Tested in fairly heavy wind, works: http://logs.px4.io/plot_app?log=f4ab18cc-a717-4a34-a8d5-13b5b24ef86a
It does need a fair amount of tuning as the prop in reverse seems to stall if the trust is too high.
There are 2 things that would be good to change in relation to this;

• Base acceptance radius on configured deceleration speed
• Make the current back transition time a max time and consider back transition complete when MPC_XY_MAX is achieved

[sanderux]

@dagar @AndreasAntener I added the 2 improvements i suggested based on my flight tests.
I will perform another flight test soon

[LorenzMeier]

Do you need both mixers? The reason I ask is that this precludes usage of the usual camera triggers, and a VTOL that doesn't have payload is not particularly interesting.

[sanderux]

For this solution you do. How many do you need for cam? There is one left

[mhkabir]

On current hardware, we need 2 for cam control. (AUX 5,6)

[sanderux]

I use 3 and 4 on the deltaquad for pusher and reserse so that should work

[sanderux]

@dagar so how do you propose we deal with this?

[sanderux]

Flight tested, this gave fantastic back transitions in wind conditions that would normally result in very eratic behavior.

tail wind: https://review.px4.io/plot_app?log=3b1cfd23-f41e-4b57-b13b-6c0a9ed6bfdf
nose wind (vt_b_dec_mss was a little too high): https://review.px4.io/plot_app?log=b7c4f3ec-20cd-46e1-a719-b31917e5f20e

@dagar @LorenzMeier Please review, i consider this ready to merge

[sanderux]

@LorenzMeier i dont know why semaphoreci keeps failing. Can you review and merge?

[sanderux]

Need to add:

• check if velocity is valid
• change description of VT_B_DEC_MSS

[sanderux]

@dagar points addressed. Please review

[dagar]

I'm still concerned that with the current implementation the parameter naming implies more functionality than actually exists outside of a very specific setup.

VT_B_REV_THR: reverse thottle output during back transition

This is simply the pusher throttle value during back transition right? There's nothing special about it that makes it a reverse throttle. A regular user (without the special ESC) is going to see this and enter a number expecting it to reverse somehow. If you describe (and name) what it actually does that removes some of the ambiguity.
What about "vtol standard pusher throttle during back transition" with an allowed range [-1, 1]? I think it would then be obvious to most it should be 0 (the default value). Users with setups that support commanding negative thrust could also use it.

VT_B_REV_OUT: Output on reverse channel during back transition

This is the INDEX_AIRBRAKES value during back transition. Why don't we just say what it actually is with a note that it isn't going to do anything unless you have AIRBRAKES in your mixer.

[sanderux]

@dagar I address a couple more things. can you review again?

[sanderux]

Flight tested new changes, works very well: https://logs.px4.io/plot_app?log=bd8740e0-f43b-418b-8f10-f27f50e9f989