False reading from lidar caused flare too high resulting in stall

Group - I have been using the TeraRanger One Lidar for several months with good success on flying wing drones. However it appears that it sent a false signal to the autopilot on decent that triggered the flare when the fixed wing drone was actually at about 9 meters from the ground. Normally the flare triggers at a much more lower altitude of around one meter or less. The result of the premature flare was a stall and crash. I tested it again with the same results.

A flight log as well as a screen shot are attached.

I would appreciate any insights that any of you have on this issue.
Thank you.
Bret C

<a class=“attachment"href=”/uploads/default/original/2X/5/52d21fc62e3310271d96c6b29b6fd9fcec6445fc.pdf">FlareTooHigh.pdf (129.6 KB)

I do not think it is a Lidar error , since the reading is quite similar to the barometer altitude reading.

The flare altitude can be set by user LAND_FLARE_ALT or calculated by the autopilot accordingly to the descent rate and altitude with LAND_FLARE_SEC parameter.

You should attach the .bin file of your flight as well as your parameters file so we can check how the LAND and TECS parameters were set.

Basically it does not work , take a look here Arduplane fails calculating descent slope

Below is a link to two flights documenting the issue with the Terrabee
LIDAR

https://drive.google.com/open?id=19py85mIVlcG0itbIblZ8rXXBT24SIe6V

Also - see the link to a screen shot of the BIN file graph per the link:

https://docs.google.com/document/d/1RpQTuGMok_mFGdNTLmZWGYlN46thV5823xY3Ic7o7ns/edit?usp=sharing

The BIN file is now attached.
I disagree - the flare was initiated at aromatically 35 foot AGL

Seems that you are NOT using the range finder since EK2_RNG_USE_HGT = -1

The range finder will be used as the primary height source when below a specified percentage of the sensor maximum as set by the RNGFND_MAX_CM parameter. Set to -1 to prevent range finder use.

1 Like

Lucamax - Thank you for the information. This is strange. We had been using the rangefinder Terabee without issue with the current parameter settings.

I don’t understand why the flare was triggered at such a high altitude. The logs show that the flare was triggered at an altitude of 34 feet. How is this explained?

Thank you.
Bret C

The range finder at the beginning of flight seems to work properly till 14 meters, this value correspond to RNGFND_MAX_CM: Rangefinder maximum distance .
In the Land stage the rangefinder returns to have a valid reading at 792.3 seconds, 14 meters.
So IMO the good news is that your rangefinder is working correctly while previous readings were erratics.

Your log bring me to these considerations:

  • the flare point has been engaged upon your LAND_FLARE_SEC = 3 parameter , when baro altitude was at 31,8 meters (almost exactly 6 seconds after landing approach was recorded in the log while LAND_PF_SEC = 6, might be just a coincidence )
  • In the same moment the rangefinder was marked in the log as “engaged” and the erratic reading recorded.
  • TECS.H correspond always to BARO.ALT , so to my understanding TECS controller has always used baro for altitude evaluation.

The flare point should had happened 3 seconds before touching the ground based on the plane descent vertical meters/seconds ratio but during landing approach where BARO.Alt follows TECS.Hdem curve, the plane was loosing 6 meters each 3 seconds .

So how was supposed the plane to land in 3 seconds after the flare setting with that descent ratio if at flare point the plane was at 31,8 metrs ?

TECS.Hdem after the flare looks weird but I have seen it like that in all my landings

BTW In Arduplane 3.8.4 I have notice that a parameter related to range finder use might prevent it

1 Like

Lucmax - Excellent evaluation of the situation. Thank you!

If this was your situation and you wanted to resolve it so that this situation will not occur again, what exactly do you suggest?

It would seam that if we change the EK2_MAG_MASK that we will lose much of the benefits of the LIDAR in improving the landing accuracy.

Also - what is your consideration of the EK2_RNG_USE_HGT = -1? Should this be changed?

If weather cooperates, I can do further testing tomorrow.

Thank you for your help!

Bret C

Unfortunately I have not many suggestions because I’m more or less in the same situation.
If you look in the 3.8 Arduplane section, you’ll see that I’m struggling too with Automatic landing but also with simpler altitude change between two waypoints.

I have done a lot of tries in the last 3 months , but discover only few things.

  • when Flare point happens at altitudes around 20 - 30 meters , crashing the plane is almost sure
  • If you use reverse thrust the plane at flare point will wait till the output to the Esc goes to zero before begin the flare. Since it takes usually 1 second to go from full throttle to zero, there is a serious delay and during that time the plane will continue to go to the ground.
  • So if you use LAND_FLARE_ALT rather than LAND_FLARE_SEC , set your value to at least 3 or 4 meters of your plane will flare too late.

My opinion is that the TECS controller has some problems , see in your case a wrong evaluation of altitude and descent rate that activate the flare too soon and that the landing strategy is not the best one for people that have Lidar , Airspeed sensor, and reverse thrust.

EK2_RNG_USE_HGT should be change to a percentage of the max range where you are sure your Lidar is reading correctly the altitude.

EK2_MAG_MASK , not sure to understand what you mean, since I see no relations between the Lidar and the mag.

If you decide to use LAND_FLARE_ALT to set the flare point remember to set LAND_FLARE_SEC to zero or a positive value will override LAND_FLARE_ALT.

Lucmax:

I changed the EK2_RNG_USE_HGT to 70% with good results. On the first test flight the drone overshot the lading a bit but it did not flare prematurely. The second flight I moved the loiter further out and it landed right on the desired landing location with out any premature flare.

The conditions were different because the grass was green instead of brown / silver like the area where we experienced the premature flare. So I do not know if the correction was caused by the change of the EK2_RNG_USE_HGT or the green grass.

I appreciate your help. Let’s keep this discussion going to further improve the auto landing.

1 Like