Autolanding lessons

I’ve had great success performing autolanding without a lidar, however flight time has to be under 10 or 15 minutes and a good 5 minutes is needed before take off, to ensure a settled baro. Even then, there’s no guarantee. I’ve recently got my lidar working (viewtopic.php?f=105&t=11463) but something weird is happening since I’ve activated (RNGFND_LANDING). As soon as my plane hits the last waypoint (8) before landing (9), in stead of gliding down to the landing location, it shoots up, throttle high to above 20m, which is the limit of the lidar (the code then using the baro again), and then settles into an almost “stabilise” mode, drifting off the runway and losing altitude. I’m thinking maybe it’s the flare, but I’ve got the flare set to 1 meter and 1 second. The lidar is reading correctly.

My log:

Video of the anomaly: (There are 3 attempts)

This is the log showing sonar distance in CM for all 3 attempts:
[attachment=1]3Samples (Custom).jpg[/attachment]
Zoomed in on the first attempt (The second dip is me taking over manual control)
[attachment=0]sample (Custom).jpg[/attachment]

So it seems as if the lidar is reporting correct altitude, but the APM code is reading it lower than it really is.

Any insights?

The plane is climbing sharply not because of a flare, but because it thinks it is too low on the glide slope. The issue happens because the lidar isn’t used until you are on a landing waypoint. When it hits the landing waypoint it suddenly gets the altitude correction of the lidar and sees that it is 7 meters below where it wants to be on the glide slope. So it puts on lots of throttle and pitches up to get on the calculated glide slope.
You will do a lot better if you just remove waypoint 8, or move it to be much further from waypoint 9. That way it will be using the lidar from a much higher altitude and will not get the sudden transition.
I’d also suggest using terrain relative waypoints, instead of home relative waypoints. You have around 10m of terrain change over the last leg of the mission.
Cheers, Tridge

Thanks Tridge

Are you saying the Baro and lidar disagreed with 7m?

I assumed 160m should be enough to lose 33m altitude, but looking at it again (7.1%), perhaps it’s not! I’ve now moved 8 way back, at 45m (same as 7) because the tree line is ~38m… I’ve added a new 9 altitude 8m (low enough for lidar to kick in), 10% gradient and then 10 is landing, 286 away, 2.8%.

Thanks for the tip re. terrain relative - will this use the terrain data on the pixhawk flash disk?


yes. Plot SONR.DistCM*0.01 and BARO.Alt

It is a bit steep, but that isn’t the problem. The problem is the sudden change in target altitude (by 7m) when the landing waypoint started.
The landing waypoint started with the Lidar showing just 7m off the ground.

yes, see the terrain following page on
Cheers, Tridge

Awesome, going to give it a try and report back.

Hi Tridge, I hope you’re still checking this thread - looks like it’s not the barometer/ lidar discrepancy.

I’ve removed the waypoint in the approach giving it 681m to glide down to a land from 50m, but as soon as it hits the command to land, the plane climbs sharply, indefinitely!

It’s as if it’s interpreting a completely different value from the lidar. It tracks correctly on the ground, though, just climbing in stead of descending… I’m completely stumped.

Please can you help!

See my video, Waypoint 8 is the approach waypoint, waypoint 9 is the landing waypoint:


Many many thanks

Plotting Baro vs Lidar:


Can’t see anything explaining the behaviour.

I’m thinking one cause of the infinite climb is that once the APM receives the land command (after the last waypoint) it switches to Lidar. However, if the plane is above the lidar’s limit (say the limit is 20m in this case), the APM will keep on thinking it’s at 20m and keep climbing because it’s below the glide slope.

So I’ve reduced the last waypoint to 10m and tested again, this time the climb is not indefinite, but the plane “bounces” on the approach, overshooting the landing spot completely, climbing a bit, then sinking again, apparently indefinitely. I’ve plot Ntune Altitude vs Ntune Alt Error:


I see that the RED line - representing NTune Alt - is NOT the Lidar measurement but agrees with the barometer reading! Is this a mistake?

Here’s the video:

Tridge wrote a lot of the code :slight_smile: but I think that your issue may actually be something different…

do you have an airspeed sensor ?

when the autopilot goes into LAND there is a parameter that you have set which commands landing speed.

There is also a parameter TECS_SPDWEIGHT which allows the pitch controller to control speed vs height…

I think whats happening is that as you go into LAND the plane is looking for the lower speed and is pitching up.


Thanks Julian, yes I have an airspeed sensor, I’ve set TECS_LAND_ARSPD to 14.5, however it’s going faster than that when landing, but I don’t think APM will pitch up to reduce speed?

I haven’t messed with TECS_SPDWEIGHT before, although I know what it’s supposed to influence, have you had any success tuning that value?

yes a lower value near zero and it will try to focus on height not speed… otherwise its trying to lose the speed before you land and going long.

there is very limited aileron authority on landing so thats why its being pushed off the runway i suspect… i think you can change that, but be careful.

have you spent time tuning sink rates etc in the TECS engine ? thats the key to good navigation and landing.

can you post a tlog ?

Thanks, I’ll take it into consideration, but it’s already landing a bit too fast as it is.

I’ve only entered the calculated sink rate based on the wiki’s formula.

Here is today’s tlog:

The first landing is without lidar, the second with lidar, but with bad altitude oscillations and I think it only stopped in time because of the high head wind at the time.

Thanks for answering.