Weird and inconsistent autoland behaviour + some key autoland parameters missing from my firmware (no GCS warning, but they just aren't there)

We’re using a Ranger 2000 model aircraft with a Mateksys H743 board. PIDs are quite good, and airspeed is very well calibrated and enabled for use by the TECS. The ARPSD_RATIO is very high but that’s just what worked for us, there are no leaks and the pitot tube location is optimal, we just ended up needing that high of a value to get it properly calibrated. We’re aiming for a parameter config more on the minimalist side, so all parameters that were about right by default we left alone. Everything works as expected except for autoland which has the following issues:

1 - The plane traces very different glide slopes on autoland attempts few minutes apart (so very similar wind conditions) even though the TECS demanded and achieved rates are very similar. The TECS doesn’t seem to want the aircraft to actually be down at the ground by the LAND waypoint, at least not all of the time. The only reason I can think of is that the glide slope is on the steeper side for the model and any kind of thermal makes it impossible for it to follow it, but judging by the TECS graphs, that just doesn’t seem to be the case. It seems to me based on the TECS demands that they sometimes mean to arrive to the LAND waypoint at the correct height, and sometimes they don’t.
Here’s a log that shows many land attempts, some of which are very different from each other:
https://drive.google.com/file/d/1q2Q3lPpvS4mTXKNumOfgLNAHhzfvtBqd/view?usp=sharing. All of them overshoot, so even though this is more of a glider model, I think increasing TECS_SPDWEIGHT would make it worse.

2 - When we let the plane flare, according to the graphs the TECS demanded height suddenly increases by a lot and sure enough the plane lifts off instead of simply reducing its sink rate. This doesn’t happen in the previous log because we decided to fix it with a very high TECS_LAND_SINK of 1.5 m/s, but clearly that’s a very hacky fix. Here’s a log of what happens with the default value of 0.25 m/s: https://drive.google.com/file/d/1jqZ74GIjnQ6bUeQnoQvRRkuUP9gAdtnz/view?usp=sharing. The plane even turns up the throttle right before flaring for no apparent reason.

3 - We figured we might be able to solve these issues with the TECS_FLARE_HGT and LAND_FLARE_AIM, but they seem to be missing from our firmware (ArduPilot firmware : /Plane/stable-4.3.7/MatekH743). They just don’t appear in any GCS.

  • Since TECS_LAND_SPDWGT is set to -1, the aircraft becomes sensitive to altitude error as it approaches the landing point, and when the altitude is lower than the demanded height, nose-up and throttle-up occur even just before the flare. As with TECS_SPDWEIGHT, it would be a good idea to set TECS_LAND_SPDWGT to 1 as well.

  • I guess the flare problem is what is fixed in the following, reflected in Plane-4.4.

  • TECS_FLARE_HGT and LAND_FLARE_AIM are also available in Plane-4.4.
2 Likes

Thanks for your answer! I had no idea that those were 4.4 parameters. In the second log, is the sudden spike in demanded altitude by the TECS a bug? I don’t understand why after flaring at 3 m height you’d want the TECS to command ~10m height. After that the demanded altitude does drop at a speed of TECS_LAND_SINK. Seems a bit weird.

I ran Automatic landing with SITL (ArduPlane V4.3.7). In this simulation I performed a landing only once and exactly the same flare problem was reproduced as in your log. The git hub issue I mentioned above is a bug that occurs when you abort the flare and run the flare again, so it may be different from your problem.

Your log:

My SITL log:

I dug into the TECS code but could not quite figure out why this was happening. It might be resolved in V4.4, so I’ll investigate a bit further.

I guessed that there is a bug in the filter that is applied to demanded height only during auto landing and commented out that process. The result is below: Tecs.hdem goes from glide slope to flare smoothly, and the problem seems to be gone.

I disabled the following if statement like below.

if(0) {
  ...

Next I will see if the problem is resolved in version 4.4.

Ver 4.4.0 gave an ideal result.