Altitude control during terrain following

Dear all,

While I test plane-soaring on SITL, I realize that terrain following behavior is changed in ArduPlane V4.1.
It seems that current terrain following shows more altitude errors than previous version.

The first plot: terrain following on ArduPlane V4.0.0
The second plot: ArduPlane V4.0.3
The third plot: ArduPlane V4.1



Maybe, I miss some updates on ArduPlane V4.1.
Could you give me an advice to decrease the altitude errors?

FYI, I have attached mission and log files.

Reproduce this issue:

  1. ./Tools/autotest/sim_vehicle.py -v ArduPlane -f plane-soaring --console --speedup=10 -L Karuizawa
  2. Run the mission

I have tested quadplane on SITL, I see that the altitude issue also happens.

Plane V4.1 version crashes on the terrain while running this mission.


Otherwise, Plane V4.0.3 version succeed in conducting the mission.

Mission & log files

@tridge,
Do you have any comments with this issue?
I am interested to do terrain following with 4.1. Thank you…

Hi @Benjamin,
FW 4.1 has several beta, the latest version is beta7. Which beta version of 4.1 did you test? Can you do the test again with the Latest beta 7 if FW 4.1 ??

@ton999
Thanks for the feedback!
I tested this version, and I also try to test Plane V4.1-Beta7.
Unfortunately, I could still see the altitude errors on Plane V4.1-Beta7 as shown in the figure below.


For your information, I have added a log file obtained from Plane V4.1-Beta7 to this link.

Hello @Benjamin,
Have you tried this test using the Latest Stable version Fw 4.09 ?? It is interesting to see the result…

@Benjamin and @ton999 thanks for reporting this! It is great that you are using SITL to check this type of behaviour.
I had a look at it, and reproduced the issue. It turns out not to be a terrain problem, but a very small difference between how baro is fused in the EKF.
The top of the mountain is 2532m AMSL.
In the 4.0.3 log the GPS altitude peaks at 2540m. At that time the BARO altitude, adjusted for home alt, is 2687. So the plane thinks it is 150m over the ground, when in fact it is skimming the tops of the trees.
In the 4.1.0 log the GPS altitude peaks at 2536m and the baro at 2686. It does manage to just touch the top of the mountain in SITL. The difference between 4.1 and 4.0 is very small, but just enough to make the difference.
If you change the EKF to use GPS alt then it clears the mountain with no problem. For EKF2 use EK2_ALT_SOURCE=2. For EKF3 use EK3_SRC1_POSZ=3.
This is a general problem with our atmospheric simulation in SITL. I have fixed it in this PR:


but that PR was a bit too late for 4.1.0. I may include it in a later 4.1.x release. I tested your mission with that PR and baro altitude and it clears the top of the mountain by 150m, which is what the mission asks for.
It is also worth mentioning that when doing SITL tests of terrain code that a high speedup can cause issues due to the way the timing works with the terrain thread. It may not be able to fetch blocks far enough ahead to be able to climb. At speedup 10x it is flying at 250m/s, which is pretty quick!
The second lesson is that if you ever do want to fly a mission like this then use GPS altitude with a good quality GPS (such as ublox F9P). Don’t rely on the barometer when you go through that much height change.
Cheers, Tridge

1 Like

@tridge
Thank you very much for your analysis. So based on this fact, I conclude that it is better and safer to use GPS as the main Altitude source than barometer, right? I am curious to understand why in default setting we use barometer? What is the reason or benefits of using baro compared with Gps? Thank you.

it isn’t as clear as that. It depends on the mission and which GPS.
A M8 or lower u-blox may sometimes have 10s of meter of altitude error. That is terrible for vehicle landing without rangefinder, but the error doesn’t tend to grow larger as the mission covers a wider height range. The baro error is usually small for a local flight, but gets worse as you fly for a long time or over a large height range.
The best option if you can afford it is a better quality GPS. Hopefully as the new L5 band starts getting more widely available (and in full service) lower cost GNSS modules that have good height accuracy will become common.

@tridge
Thanks for the work!
I tested the fixed version. I used GPS as primary altitude source and did not speed up the SITL.
But, I still see the altitude error…


Did I wrong something?
FYI, I have added a log file (“Fixed_version_GPS.BIN”) into this link.