Skip to content

Plane: Allow lower speeds in landing final #29265

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

Conversation

rubenp02
Copy link
Contributor

Plane: Allow lower speeds in landing final

Description

This PR allows for lower airspeeds during the landing final while maintaining appropriate limits during other phases of the flight, including the landing approach phase, if AIRSPEED_STALL is set. This enables smoother/slower landings when a conservative AIRSPEED_MIN is used, which previously resulted in fast touchdowns.

Changes

  • Relaxed target airspeed constraints in navigation.cpp to allow for target airspeeds as low as AIRSPEED_STALL if set. This enables the following changes while maintaining safety, as the TECS further constraints the target airspeed as appropriate.
  • Added a method to the landing controller to determine if the aircraft is on landing final.
  • Adjusted the TECS airspeed constraints during landing final to allow speeds as low as AIRSPEED_STALL, if set.
  • Corrected an inaccuracy in the AIRSPEED_STALL parameter description (this can be moved to a separate PR if required, but I thought it was small enough to include here).
  • Updated the AIRSPEED_STALL parameter description to explain its new role during landing.

@Hwurzburg Hwurzburg added the WikiNeeded needs wiki update label Feb 10, 2025
Copy link
Collaborator

@Hwurzburg Hwurzburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a change in behavior, probably should be a flight option with current behavior as default.

@rubenp02
Copy link
Contributor Author

rubenp02 commented Feb 10, 2025

Since this is a change in behavior, probably should be a flight option with current behavior as default.

It could be added to LAND_OPTIONS, but currently you need to have AIRSPEED_STALL specified, and TECS_LAND_ARSPD or LAND_PF_ARSPD set to a value lower than AIRSPEED_MIN for this to do anything different than the current behavior. What do you think?

@Hwurzburg
Copy link
Collaborator

Up to @tridge ...many set airspeed_stall, but default for landing airspeed is 1/2 way between min and cruise....so probably not a big deal...

@rubenp02 rubenp02 requested a review from Hwurzburg February 13, 2025 08:27
@Hwurzburg Hwurzburg requested a review from IamPete1 February 13, 2025 12:41
@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from 1ca0dbb to 989f4bf Compare March 3, 2025 18:34
@rubenp02 rubenp02 requested a review from IamPete1 March 3, 2025 18:36
@IamPete1
Copy link
Member

IamPete1 commented Mar 3, 2025

This seems like a reasonable change. Am I correct that this should only do anything is the user has set stall speed and a landing speed less than min airspeed?

What testing has been done? What happens in the case of a go-around?

tridge
tridge previously requested changes Mar 4, 2025
Copy link
Contributor

@tridge tridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'd like to see a log showing an improvement with this change

@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from 989f4bf to 67b7ee9 Compare March 4, 2025 08:25
@rubenp02
Copy link
Contributor Author

rubenp02 commented Mar 4, 2025

This seems like a reasonable change. Am I correct that this should only do anything is the user has set stall speed and a landing speed less than min airspeed?

That's right.

What testing has been done? What happens in the case of a go-around?

It was tested in SITL and we're currently running it in our commercial aircraft. In the case of a go-around the commanded airspeed is immediately corrected.

@rubenp02
Copy link
Contributor Author

rubenp02 commented Mar 4, 2025

we'd like to see a log showing an improvement with this change

feature-allow-lower-speeds-in-landing-final-comparison.zip

In the default SITL config. w/ the current behavior:

AP: SIM Hit ground at 0.697724 m/s

With both LAND_PF_ARSPD and AIRSPEED_STALL set to 7.5:

AP: SIM Hit ground at 0.337572 m/s

@rubenp02 rubenp02 requested a review from tridge March 4, 2025 09:12
@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from 67b7ee9 to f1ef53b Compare March 5, 2025 12:08
@IamPete1
Copy link
Member

IamPete1 commented Mar 10, 2025

image

The target airspeed is set with LAND_PF_ARSPD, it is 7.5. The target speed starts going down, although it never gets to the set speed of 7.5 before the flare, the target airspeed is 12.5 or so when the flare starts. Since this is above AIRSPEED_MIN of 10, I don't think the changes to the constraints made in this PR make any difference in the example log?

@rubenp02
Copy link
Contributor Author

rubenp02 commented Mar 10, 2025

If the LAND_PF_ARSPD wasn't allowed to go below AIRSPEED_MIN like in master, the airspeed demand wouldn't be so low by the time the aircraft flares.

Here's a log showing that. It's the same flight as the other 2, with the same parameters as lower-speed-final.BIN, but running master (probably what I should've included in the first place 😄):
lower-speed-final-master.zip

AP: SIM Hit ground at 0.644917 m/s

I reckon the PF airspeed demand interpolation should be done between the PF and flare altitudes, instead of between the PF and landing alt. Is that a viable addition to this PR, or would it overcomplicate things too much?

@IamPete1
Copy link
Member

In the new log we see this:
image

The target speed goes down but is constrained to 10 m/s as set by AIRSPEED_MIN. The flare message says the flare start speed is 14.3 m/s. The log with this PR starts flare at 14.1 m/s, so there is no significant difference in speed or the other conditions at the start of the flare.

However, as you say there is a difference in the speed at which the ground is hit. Any idea why this is? Is it reproducible over a number of tests?

@rubenp02
Copy link
Contributor Author

rubenp02 commented Mar 10, 2025

I've done more runs with each and it seems like the improvement is not reproducible, so what you're saying checks out. It's a bit surprising to me because it really seemed to make a difference in real world tests but maybe it was just an illusion or luck.
I'll give it another go.

I thought there was an explicit interpolation of demanded airspeeds at this stage but it seems like its governed by some maximum negative acceleration rates. These should probably be made higher for this to work as expected, at least during the preflare stage. If you have reverse thrust, this is very important I think. Thoughts?

@rubenp02 rubenp02 marked this pull request as draft March 10, 2025 13:16
@IamPete1
Copy link
Member

really seemed to make a difference in real world tests

If you have a longer pre-flare, it could well make more of a difference.

I thought there was an explicit interpolation of demanded airspeeds at this stage but it seems like its governed by some maximum negative acceleration rates. These should probably be made higher for this to work as expected, at least during the preflare stage. If you have reverse thrust, this is very important I think. Thoughts?

Stuff like this is a bit tricky, we can't change or bypass the existing limits because we don't want to start breaking existing aircraft, I guess you could have a new parameter for just this phase. If you can prove it helps I think we would accept it. As ever were trying to trade off more code/flash space/parameters/complexity vs real world benefits for users.

@rubenp02
Copy link
Contributor Author

If you have a longer pre-flare, it could well make more of a difference.

I have asked for some real-world logs and yes, it does make a major difference in those, so I was getting confused over here but it all makes sense. I'll replicate them with a minimal SITL setup later. Sorry for the useless logs!

@rubenp02
Copy link
Contributor Author

rubenp02 commented Mar 10, 2025

Instead of making the PF longer I just dropped the TECS_LAND_ARSPD to the AIRSPEED_MIN (10 m/s), which I think is more canonical. So the following logs are generated by a default SITL except for the following parameters;

  • TECS_LAND_ARSPD: 10 m/s
  • LAND_PF_ARSPD: 7.5 m/s
  • AIRSPEED_STALL: 7.5 m/s (this is what actually enables the functionality)

The only difference between the logs is that one of them has this patch applied.

allow-lower-speeds-in-landing-final-vs-master.zip

I don't think SITL is the best place to analyze how soft the landings are, and I checked that there is a lot of random variation in the simulated touchdown speed, but the provided logs do show a softer touchdown with this PR. However, it's obvious that a lower touchdown speed means less energy, and therefore a softer touchdown with a shorter landing roll.

Again, sorry for wasting time with the previous logs.

@rubenp02 rubenp02 marked this pull request as ready for review March 11, 2025 08:47
@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from f1ef53b to fbd228f Compare March 17, 2025 22:21
@rubenp02
Copy link
Contributor Author

Hi, anything left to do or discuss here?

Copy link
Member

@IamPete1 IamPete1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code changes look OK. The SITL logs show a marginal benefit, but I could believe that on a better setup vehicle this could make a larger difference.

Its been a while so I will rebase. EDIT: seems like I'm not allowed, @rubenp02 can you rebase please.

@rubenp02
Copy link
Contributor Author

I can rebase myself if it's ready to merge. I can confirm that in real life there's a substantial benefit.

@rubenp02
Copy link
Contributor Author

rubenp02 commented May 12, 2025

Maybe it could be discussed in dev call to see if anyone wants anything else changed before rebasing and merging?

@IamPete1
Copy link
Member

Maybe it could be discussed in dev call to see if anyone wants anything else changed before rebasing and merging?

It's marked for this evenings call.

@tridge
Copy link
Contributor

tridge commented May 13, 2025

@rubenp02 please rebase

Copy link
Member

@IamPete1 IamPete1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, with a rebase and CI pass were happy to merge.

@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from fbd228f to 65c4820 Compare May 13, 2025 10:42
@peterbarker
Copy link
Contributor

@rubenp02 I think you will need to rebase this again on top of some CI fixes.

I just tried to do that for you but your repository denied the push for whatever reason.

@rubenp02
Copy link
Contributor Author

My repo is a default GH fork AFAIK. Should it allow the push?

I'll rebase myself.

rubenp02 added 4 commits May 13, 2025 15:04
Relaxed target airspeed constraints in navigation.cpp to allow for
target airspeeds as low as the AIRSPEED_STALL if set. The TECS will
still further constrain the target airspeed as appropriate.
Introduced the is_on_final public method, which determines if the
landing is at the pre-flare stage or later, so the aircraft is on final
for landing. Similar to the existing is_flaring and is_on_approach
methods.
Previously the TECS never allowed for a speed demand outside of the
navigation airspeed range (AIRSPEED_MIN to AIRSPEED_MAX), even on
landing final. This can be too fast for touchdown if a conservative
AIRSPEED_MIN is used, which might be preferable for other phases of
flight.

This commit lowers the min. airspeed to AIRSPEED_STALL, if set, during
landing final only. Using a value of TECS_LAND_ARSPD or LAND_PF_ARSPD
lower than AIRSPEED_MIN, it enables slower touchdowns while ensuring the
rest of the flight remains safely at or above AIRSPEED_MIN.
Updated the AIRSPEED_STALL parameter description to explain its effects
on the landing final
@rubenp02 rubenp02 force-pushed the feature/allow-lower-speeds-in-landing-final branch from 65c4820 to 0a1b974 Compare May 13, 2025 13:04
@IamPete1
Copy link
Member

There should be a "allow edits from maintainers" check box on the PR, usually it's checked by default.

@rubenp02
Copy link
Contributor Author

Ready to merge I think

@IamPete1 IamPete1 enabled auto-merge (rebase) May 14, 2025 15:35
@IamPete1 IamPete1 disabled auto-merge May 14, 2025 15:35
@IamPete1 IamPete1 dismissed tridge’s stale review May 14, 2025 15:42

Was discussed on the call.

@IamPete1 IamPete1 merged commit 63642b7 into ArduPilot:master May 14, 2025
103 of 104 checks passed
@IamPete1
Copy link
Member

Thanks!

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

Successfully merging this pull request may close these issues.

6 participants