Add fall back for when VTOL pusher cannot produce enough thrust

[AndreasAntener]

@Tumbili @sanderux Something to think about: If the pusher during MC mode doesn't hold the plane against the wind anymore, either because it's not strong enough, or the scaling factor is too low, or it's malfunctioning, can we take action?

I was thinking along the lines of integrating thrust first, then maybe start tilting again, when the velocity error gets too large (although for manual you would need a different trigger). Of course, if the airframe just can't handle the conditions nothing helps (tilting might even be worse), but in case of a pusher failure some fall back mode of operation would be good.

[sanderux]

I agree, perhaps we could monitor if the position error gets bigger and disable pusher assist beyond a certain threshold

[sanderux]

@Tumbili do you have any suggestion on how to integrate the value so it can potentially use the full range of available pusher thrust?

[sanderux]

@Tumbili @AndreasAntener
After some sitl testing it seems MPC_TILTMAX_AIR (45 degree) * VT_FW_THRUST_SC approximates the maximum pusher thrust. Thus a scale of 2 generally uses full range. PID controller should take care of the rest.

To address ada's issue i propose we publish https://github.com/PX4/Firmware/blob/master/src/examples/mc_pos_control_multiplatform/mc_pos_control.cpp#L815 on the vehicle_attitude_setpoint topic and use that as a failsafe to un-limit the pitch down angle for the quad when pusher assist is active.

Any objections for me to implement this?

[sanderux]

@dagar we need to address this, you have any ideas?

[PX4BuildBot]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[TSC21]

@sanderux still relevant?

[sanderux]

Yes, it's a risk factor still

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.

[julianoes]

@sanderux is this still something you're interested?

[LorenzMeier]

I think we need to change the style of discussions here a bit: Issues that represent not outright bugs but robustify the system in certain environments (like wind) need an owner and a commitment from the owner. @RomanBapst are you taking that into the roadmap and if yes for when? Otherwise please close and we can reconsider later.

[julianoes]

@LorenzMeier that's exactly why I'm asking these kinds of questions. If I don't get an answer or commitment, I'll close it.

[sanderux]

I think we need to change the style of discussions here a bit: Issues that represent not outright bugs but robustify the system in certain environments (like wind) need an owner and a commitment from the owner.

Protection against failure of a component seems to me to be part of the core of the flight control system. Andreas had put it maybe a bit strange referring to wind, but the pusher assist method can -and should- be failsafed just like a sensor failsafe. The pusher could malfunction, or not function at all. The vehicle is more than capable to failover to regular quadcopter flight, and i think it should do that when it deems pusher assist is not effective.

From a design perspective i also think that ANY non-critical feature or restriction should be encapsulated in an operating band and disabled beyond a certain threshold. For example: a maximum pitch angle should be applied until its clear that this restriction is preventing the vehicle from climbing. A proper bandwidth for this restriction could be altsp/2 (only applies when the vehicle is within 50% of its target altitude) beyond that the restriction should be removed as a risk of stalling is better than a guaranteed crash. (in this example the level setting could be off) but i might be getting off-topic here

[julianoes]

Otherwise please close and we can reconsider later.

I think it's perfectly fine to have an open issue which is labelled as enhancement. That makes it clear it's not a bug and you can easily filter for actual bugs. The reason why I like enhancement labels is that someone that wants to contribute can pick it up and make a PR. I know that's not always very likely but I think we should work in that direction and invite that sort of engagement. It has worked for MAVSDK in the past!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.