Landing issues (fast descent, won't slowdown on terrain approach)

Hello, my drone is starting to get to the point where i want, it flies amazing in auto mode, except for one thing: the landing is always too fast, no matter how slow i’ll set the maximum descent rate speed.

Here is the log of my last flight, it looks like when the landing starts, the DAlt for some reason won’t change, i still had enough battery to fly more so i don’t think it’s an underpower issue, but you’ll tell me.

As always thank you so much for your time helping me, it’s very appreciated.

LAND_ALT_LOW,3000 is 30 meters
You usually want this something like 5 or 10 meters
LAND_SPEED_HIGH,50 could probably be 100 or more
The default values for
are usually OK unless your copter is particularly sensitive

It looks like the non-landing issue might be terrain. I’d say the mission is created using altitude above terrain, and the terrain data is wrong??
You can see by the Baro that the copter descends slowly until a confirmed landing.

Instead of doing a mission, just fly in AltHold and Loiter, then use RTL and Land modes to test the copter performance. If you really want to test descent rate use Stabilise mode, check logs and set LAND_SPEED_HIGH to the fastest stable descent rate, and LAND_SPEED to about half of that or less.

Although attitude control is quite good, there is a few other things I can point out:
and set up the Harmonic Notch Filter - it’s easy and worth it.
There’s a few other things in the log that can be improved too, apart from these ESSENTIAL things:

and use the Initial Parameters in MissionPlanner to set correct battery failsafe levels and

see rule 1

Then I would look at running Autotune and doing some more test flights with RC control before worrying about missions.

1 Like

Also, I have noticed a downfacing rangefinder that is throwing up weird data, try to disable this rangefinder to see it this weird data is not messing up with land speed calculations.

1 Like

hi Shawn, thanks for your suggestions. I don’t think the mission was created using altitude above terrain, because as a matter of fact, it follows altitude correctly for the entire duration of the mission (also other missions where i tried higher altitude changes, it always followed perfectly). What i noticed is that when starting the land command, the altitude reading on the OSD (i have a fpv camera on the drone) doesn’t change, so let’s say the drone is 30 meters high, it’ll start descending but the altitude will stay at 30 meters until it touches down, for this reason it’s not slowing down to land_speed_low. All the settings related to landing were like this because i wanted to troubleshoot this problem but without success so far. Today i’ll try using land flight mode and record a DVR to show you better this problem.
I don’t know about the Baro reading in the logs, but it did an hard landing and definitely didn’t slow down when approaching terrain as it’s supposed to do.

The rangefinder is the matek one, with a range up to 2 meters and was set up accordingly to this limit, but i’ll try disabling it and see if it gets better, thank you.

1 Like

Another thing i’d like to point out: i was better analyzing the logs and if you look closely to the baro reading in the pic you posted, you see that it takes around 15 seconds to go from 30 meters to 0 (2m/s), so it’s way above the speed that i set in the parameters, and also it doesn’t really confirm the landing, it just gives the flag because i disarmed in the exact moment when the drone touched ground to avoid the props touching the ground while spinning since it was in a muddy terrain, but as a matter of fact it was an hard landing, definitely not smooth. If you see in CTUN, the values of DAlt and Alt stay at 30 meters, only BAlt will go down to zero, why does it happens?

Hi @Charlie_M,

It looks like EK3_RNG_USE_HGT parameter has been changed from the default (-1) to 50m but the rangefinder doesn’t appear to be working.

Coincidentally there is an EKF fix in Copter-4.3.1 to stop the EKF from consuming bad rangefinder values but this would not have helped because RNGFND1_MIN_CM has been set to “1” meaning almost all invalid readings it produces are being consumed as good values. This param should be restored to the default of 20 I think.

Can you set these two parameters and try again?

  • RNGFND1_TYPE = 0 (disables the rangefinder)
  • EK3_RNG_USE_HGT = -1 (disables use of rangefinder for the altitude estimation)

By the way, could you tell me what led you to set the EK3_RNG_USE_HGT parameter? Was it something written on the wiki? Advice from another user? … perhaps you were just browsing the parameter list and found this parameter?

I don’t meant to be pushy or “blame the user”, the reason I ask is just that setting this parameter is almost never a good idea. I have struggled for years to adjust the parameter descriptions and wiki to guide users away from setting it but still it is occasionally set and almost invariably causes problems.

The normal reason it is set is users incorrectly assuming that terrain following or surface tracking requires the EKF configuration be changed.

Here’s the EK3_RNG_USE_HGT parameter description

  • Range finder can be used as the primary height source when below this percentage of its maximum range (see RNGFNDx_MAX_CM) and the primary height source is Baro or GPS (see EK3_SRCx_POSZ). This feature should not be used for terrain following as it is designed for vertical takeoff and landing with climb above the range finder use height before commencing the mission, and with horizontal position changes below that height being limited to a flat region around the takeoff and landing point.

Hi @rmackay9, thanks a lot for your detailed response.

I’ll try to explain the reason of my settings, i discovered the EK3_RNG_USE_HGT parameter on my own while setting the Matek Lidar/Optical Flow sensor, i thought it was a percentile value, not meters, that’s why i put 50 as a value (that would correspond to 1 meter according to this sensor range).

In fact this Matek sensor has a very limited range, up to 2 meters only, so it’s impossible to use it for terrain following and i’m not interested in this, i wanted to use it for a precise takeoff/landing, avoiding the drone drifting around or descending too fast, so i thought that setting it as the primary height source below 1 meter through that parameter would make sense, since i don’t think the baro could be accurate on such a short distance from terrain, does it makes sense to you as well?

Also, about the RNGFND1_MIN_CM being set to 1 it’s my mistake, but the specs of this sensor say that it should be able to read correctly down to 8 cm, so i’ll change it to this value.

Anyway, i’ll try Land mode tomorrow with the rangefinder deactivated as you suggested and see if this will fix the problem

1 Like


Ah, sorry, you’re right that the EK3_RNG_USE_HGT parameter is a percentage not a distance. In any case though the rangefinder is reporting a distance of between 2cm and 7cm though, well below 50% of the 200cm range so the EKF is attempting to use it.

These very short rangefinders are really not useful I’m afraid.

By the way, AP’s landing controller lands the vehicle at a constant 0.5m/s descent rate. It actually doesn’t matter too much what the absolute altitude above the terrain is as long as it isn’t descending too quickly. The only way that a rangefinder may be used during landing is to trigger the vehicle to switch to the slower descent rate (e.g. LAND_SPEED) if the rangefinder reports a distance below LAND_ALT_LOW.

By the way, I agree with @xfacta that LAND_ALT_LOW is set too high at 3000cm (30m). There’s nothing particularly wrong with this but with LAND_SPEED = 30 (0.3m/s) it could take 100sec for the vehicle to land which is unnecessarily slow I think.

i might have found the issue: my rangefinder was covered with a clear heatshrink that was giving completely wrong data, i put it on the sensor because it was included in the package, but once removed, the altitude reading became super accurate. I don’t know if i’ll still have this landing issue since i didn’t have the chance to fly yet because of the rain, but at least i solved this weird data coming from the sensor.

1 Like

Thanks a lot for the detailed analysis @rmackay9!

Really learnt a lot here.