Autonomous Landing: Flare is too high

Hello everyone,

I’m using ArduPlane 4.6.2 with Mission Planner in a Multiplex FunCub with a 1400 mm wingspan.
As the flight controller, I’m using a SpeedyBee F405 Wing.
I have a compass with GPS, an airspeed sensor, and a Benewake LiDAR TF Mini Plus installed.

I want the Cub to perform an autonomous flight, and so far, it does that quite well.
My only problem is that the flare happens much too early.
I’ve already tried all sorts of parameter adjustments.
My LAND_FLARE_ALT is set to 0.1 m, yet during landing, the aircraft still begins to flare at about 3 m above the ground.

I haven’t recorded a log yet, and I’m also not able to track the aircraft live through the GCS.
I’d like to upload my parameter file here — maybe someone can help me figure out why the plane flares at around 3 m AGL and then consequently drops the remaining 3 meters.

Thank you!
Ingo
FunCub_NG_vers_2.param (19.1 KB)

I should also mention that I have already adjusted EK3_RNG_USE_HGT from the default -1 (as listed in the parameter reference) up to 70%.
The EK3_RNG_USE_SPD is set to 12 m/s.

Hi,

I don’t know if you missed it, but there is a bug fix for rngfnd use for flare in latest beta announcement. I think it’s worth checking.

Furthermore, as you might already saw, flare has 2 metrics, A. Time B. Height, whereas B usually kicks in as failsafe if time based fails by a baro drift.

So you can make an educated guess and put a realistic time for your plane i.e. : 12m/s, with 5deg slope angle and you want to flare ~2m above the ground = ~1.9sec. checking the log will refine that number

Best,
D

2 Likes

Generally you should not use rangefinder as EKF altitude source. If you do so any part of the flight that happens below EK3_RNG_USE_HGT at speeds below EK3_RNG_USE_SPD MUST be over flat and level ground.

Rangefinder can be used for landing if configured to do so using dedicated parameter, no need to mess with EKF.

Thank you very much for your quick help!
No, I wasn’t aware of that bug. From what I’ve researched now, it seems that firmware versions equal to or newer than 4.6.2 no longer have this issue, right?

If I understand you correctly, I should set LAND_FLARE_ALT to 0 and rely only on LAND_FLARE_SEC = 1.9s.
That would mean the LiDAR wouldn’t be used for the flare at all?
But if I don’t have the bug anymore and the LiDAR provides clean data, why can’t I just use LAND_FLARE_ALT instead?

This implies that if I reset the EKF parameters to default and only activate the rangefinder for the lidar landing, it should also function properly?

Correct, update to latest.

Yes, revert all ek3 Params and use only the use of rngfnd for landing

Then set the time as well as the minimum altitude this way you will have perfect results

1 Like

Altitude is there as a backup, ex. in case of a shallow landing.

Big thanks to both of you.
I will try it soon as possible and give you an update.

Best regards
Ingo

I have an update.
I flashed firmware 4.7.0 today. Everything is set to default as discussed (EKF is default, etc.). It’s best to look at the attached parameters. I’m slowly getting really desperate. It can’t be that difficult to integrate a LiDAR sensor and use it to plan an approach.

I have used different LAND_FLARE_ALT values. None of them really showed any change. I repeated the flight several times without making any changes, and each time it was at a different altitude, not by much but noticeable.
I believe that my LiDAR is not integrated into the approach. It works perfectly, the distances are correct in the DATA tab dialog box. However, I have never gotten a “BAD LiDAR Health” as a pre arm fail while my compass is complaining the whole time.

So could it be that it just wasn’t integrated properly? Or am I doing something wrong in the mission planning?


FunCub_NG_vers_3.param (19.2 KB)

So you enabled RNGFND_LANDING = 1 and then you have set:
TECS_LAND_THR = 20% less than Trim cruise throtle
LAND_FLARE_ALT = 2
LAND_FLARE_SEC = 2’’ for a 3.3d slope as your mission (actual is 2.9 without flare)
LAND_FLARE_AIM = Begin with 50
TECS_LAND_ARSPD = 12 or your prefered land speed (1.3x STALL speed is ok)

oh, needles to say, but you have already tuned TECS (or even checked that you are near ok)?

please repeat and post a log. You can use anonymize logs for the coords

1 Like


Yes, RNGFND_LANDING = 1 is there. But how can i check if the Rangefinder is working? As i said, there is no preArm fail with “Bad LiDAR health”. The only point is that RNGFND1 shows me a distance value in Data.

No, I haven’t tuned the Tecs parameters in detail yet. I’m using the default values for these parameters. I still need to set up the log. Would you be able to see right away if the LiDAR is working?

You must do AUTOTUNE for pitch and roll or manually tune the attitude. For good speed and altitude control TECS should be tuned too.

You shouldn’t expect consistent start altitude if flare is time triggered but level off altitude/touch down vertical velocity should be fairly consistent.

1 Like

Thank you for your answer and for the hint. As you’ve probably noticed, ArduPilot is new territory for me. From what I’ve learned, you use AUTOTUNE to automatically determine tuning values. So I just assign AUTOTUNE to a flight mode switch and fly until the battery is empty, right?
You mentioned that TECS should also be tuned. How does that work exactly?

However, I still have two questions:

  1. Even though I haven’t used AUTOTUNE yet, that shouldn’t really have much to do with the LiDAR, right? The LiDAR is supposed to measure the distance to the ground and therefore allow a more precise flare, correct?

  2. Is there anything I need to consider when using the data logger via SD card on the flight controller? Can I use the logs to check whether the LiDAR is working properly?

Greetings
Ingo

Then familiarize yourself with the Ardupilot Wiki, especially Setup for Plane — Plane documentation and First Flight — Plane documentation. Pretty much everything you need is described there.

If your attitude, altitude and airspeed control are off you can’t meaningfully evaluate landing precision.

IIRC rangefinder data is logged by default.

I have another question about my compass. Why do I keep getting the “Bad Compass Health” message?

I have calibrated the compass (several times) and it is installed at a sufficient distance from interfering objects. The supply line is even shielded. The FC is permanently installed in the aircraft with the compass. Why do I keep getting this message?

Are you sure about interference and compass orientation setting (some GPS units gave rotated compass)? Though IIRC with bad orientation EKF would be throwing a fit during flight.

Check for interference and orientation using Mag Fit.

I have now performed an autotune flight and recorded a log. I can see that the rangefinder has recorded something and is therefore technically working. I compared the barometric altitude and the GPS altitude. The barometric altitude peaks slightly. The GPS speed and airspeed sensor give better results.

Is there anything else of interest that can be deduced from the log? Is it already possible to say whether the rangefinder will work during autoland?

Here is a Google Drive link for the log.

The missionPlanner logAnalyser said that my compass isnt that good.. And yes the orientation is fine. I use the Matek M10Q5883.
image

Wow that is either a defective sensor or really bad electromagnetic interference. Check the log using the tool I linked.