Skip to content

FW Flaps on landing Abort #23795

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Conversation

ryanjAA
Copy link
Contributor

@ryanjAA ryanjAA commented Oct 10, 2024

Currently when you manually abort an auto-landing, the flaps retract immediately.

This is a problem because you can potentially be below the stall speed of a "clean" (flaps not extended wing). We saw several vehicles crash at MTOW like this.

This PR solves this by keeping flaps set to the landing flaps amount until the rotation airspeed is met.

Landing flap scale (FW_FLAPS_LND_SCL) was chosen rather than takeoff flaps as you may not use flaps on takeoff but are using them on landing.

Rotation speed (RWTO_ROT_AIRSPD) was chosen as that should be a comfortable airspeed at which you are getting ready to climb at the beginning of your mission, min speed didn't make sense given it could be much higher... Also, it is latching so you don't go slightly above rotation speed and then have the flaps retract and extend, I saw that in SITL testing early on.

Concerns would be climbing with flaps and hitting critical AoA of the flap, if that is an issue (or at least a valid concern) we can divide the landing flap value by 2 here to deploy half the flap amount or add a new param for abort flaps.

This was tested in SITL extensively on 1.14.x to not impact hold mode or scenarios where you were below rot speed and put it into hold, etc.

EDIT: updated airspeed to eas for main.

@sfuhrer

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Oct 11, 2024

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Oct 12, 2024

@sfuhrer
Copy link
Contributor

sfuhrer commented Nov 1, 2024

Hi @ryanjAA , thanks for the proposal. I though wonder if we cannot make it much simpler and without the airspeed dependency and just keep the flaps extended in the landing configuration until we have cleared the abort altitude. Have a look at #23877 thus please and let me know what you think!

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Nov 1, 2024

@sfuhrer, I’m with you on this, and I initially implemented a similar approach to what you proposed in #23877. However, after discussing it with our aero guy, we decided to change course because of a potential issue with climbing to the loiter altitude (especially if it's high). The problem is that with landing flaps deployed, a high angle of attack during climb could stall the airfoil, as landing flaps typically have a much larger deployment than takeoff flaps on a full-size aircraft.

Without dedicated takeoff flaps, there's a gap: we either need an "abort flap" setting (which isn't ideal because it introduces a new param and setting) or simply retract the flaps once sufficient airspeed is reached, hence rotation speed. The concern is that if the flaps remain deployed during the climb, the pitch-up could put the aircraft into a "flap-induced stall."

Landing flaps are designed (im sure you know this, just writing it for good measure) to create lift and drag, slowing the aircraft for descent. But in a climb, they can push the angle of attack beyond what the airfoil can handle at low speed and high power. This excessive drag, combined with a high angle of attack, risks causing a stall or preventing effective climb.

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Feb 12, 2025

@sfuhrer We probably should make a decision on this and #23877 for the next release. While im a fan of the simplicity of the other, it (#23877) opens a big hole in flight dynamics and to anyone who doesnt know about the aero side of things, they won't understand the implications (aka most).

Getting out of a flap induced stall (and actually knowing it is even happening) when close to the ground will be a hard pressed by most if not all... Also, we have airspeed so why not consume it.

@sfuhrer
Copy link
Contributor

sfuhrer commented Feb 19, 2025

Hi @ryanjAA , you're ofc very right, sorry for dropping out of the conversation here last year.

I've pushed an addition to #23877 - it would now retract the flaps once above the MIN airspeed. The definition of the MIN airspeed is "minimum airspeed vehicle can fly without flaps (safe margin above stall speed)", which seems to exactly represent the moment where we want to retract the flaps.

That way we the flap retraction during landing aborts is not linked to RWTO_ROT_AIRSPD, which is a parameter that not every fixed-wing user will have set. We need to find a good balance between powerful configuration abilities (for people like you who really fine-tune it) and the average FW user who at the max sets AIRSPD_MIN correctly. What do you think of this compromise?

But in a climb, they can push the angle of attack beyond what the airfoil can handle at low speed and high power

If you're still concerned about that after my change (basically for the case where the airspeed doesn't rise above the MIN fast enough and thus the flaps stay deployed): I really want to avoid adding yet another parameter ("flap setting during abort"), and I also don't like abusing the takeoff flap setting for the landing abort, so I would then prefer to settle with setting 50% of the landing flaps during the abort.

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Feb 19, 2025

Hi @ryanjAA , you're ofc very right, sorry for dropping out of the conversation here last year.

I've pushed an addition to #23877 - it would now retract the flaps once above the MIN airspeed. The definition of the MIN airspeed is "minimum airspeed vehicle can fly without flaps (safe margin above stall speed)", which seems to exactly represent the moment where we want to retract the flaps.

That way we the flap retraction during landing aborts is not linked to RWTO_ROT_AIRSPD, which is a parameter that not every fixed-wing user will have set. We need to find a good balance between powerful configuration abilities (for people like you who really fine-tune it) and the average FW user who at the max sets AIRSPD_MIN correctly. What do you think of this compromise?

But in a climb, they can push the angle of attack beyond what the airfoil can handle at low speed and high power

If you're still concerned about that after my change (basically for the case where the airspeed doesn't rise above the MIN fast enough and thus the flaps stay deployed): I really want to avoid adding yet another parameter ("flap setting during abort"), and I also don't like abusing the takeoff flap setting for the landing abort, so I would then prefer to settle with setting 50% of the landing flaps during the abort.

No worries. Life happens!

This is a good compromise.

Setups that have a high or tight min to cruise speeds this can be a problem for but I'd argue those setups will have people knowing what they are doing... This will work for many and is an improvement of the current.

I'm going to use our code in the AA branch because I know the issues this poses on the aero side when coupled with our high min air speed but I think we will be the minority (will also refactor ours based on yours to keep this part as close as possible to upstream).

I don't think the 50% flap addition is needed atm. This plugs a big hole albeit opens another one, the latter is not definitive whereas losing flaps close to the ground while slow was a definite issue.

Closing as solved

@ryanjAA
Copy link
Contributor Author

ryanjAA commented Feb 19, 2025

Solved via #23877

@ryanjAA ryanjAA closed this Feb 19, 2025
@ryanjAA
Copy link
Contributor Author

ryanjAA commented Feb 19, 2025

@sfuhrer side note, no 50% flaps because if we are going to go down that route, let's just plumb full speed based flaps in. We made a branch with it awhile back, wouldn't be too hard so no need to go partly the way there now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants