After takeoff, I climbed to approximately 80 m above home while maintaining about 20 m AGL. This means the vehicle effectively flew 60 m uphill, and during this phase the system behaved correctly.
I then flew back downhill at a higher speed. Surface tracking attempted to maintain the constant AGL altitude by commanding a descent rate of 2 m/s, which corresponds to the configured limit (PILOT_SPD_DN = 2).
However, I noticed the following issues:
At 12:46:08, I set the throttle to minimum (RC3 = 1000). The vehicle’s descent rate increased to 4 m/s, which is twice the limit set byPILOT_SPD_DN.
Because the terrain slope was relatively steep, the desired AGL altitude (CTUN.DSAlt) began to diverge from the actual AGL altitude (CTUN.SAlt). At 12:46:26 the desired AGL altitude is -10 m, while the actual AGL altitude is 8 m. As a consequence, when the pilot commands full throttle up (RC3 = 2000), the vehicle does not immediately start climbing. Instead, there is a ~10 second delay while CTUN.DSAlt increases until it matches CTUN.SAlt. Only then does the vehicle begin climbing at the expected rate. I think this delay could be very dangerous.
To reproduce this issue, just lunch sitl near some mountains
Sorry to poke you @rmackay9, but I think these could be quite dangerous issues, both the down speed of the drone reaching 2*PILOT_SPD_DN and the throttle response delay
In autonomous modes (Auto, Guided, RTL) we handle this situation by slowing the horizontal speed to allow the vertical to catch-up. In the simulated situation, the 10m altitude error would lead to the vehicle slowing down almost to a stop.
Doing the same thing in pilot controlled modes (e.g. Loiter) is a slightly more difficult choice because we end up overriding one of the pilot’s controls which makes them unhappy. In this case the pilot had the pitch stick pushed far forward and kept them forward despite the altitude error. If we slowed the vehicle in surface tracking (as we do in terrain following) then in very rough terrain (or with a noisy rangefinder) this could lead to the vehicle bucking (e.g. pitching forward and back) unless we’re very careful about filtering.
I’m not saying there’s not a problem but sometimes we can do more harm than good if we override the pilot. We want the system to be safe but especially in manual modes we also need to trust the pilot to fly safely.
We do have a plan to combine terrain following and surface tracking so when we do that it might be a good time to address this.
It would be good to create an issue or enhancement request for this in our issues list.
Thanks for the prompt reply, actually I think the main issue is that the pilot is no longer in control of the altitude when there is an accumulated AGL altitude error. I performed this SITL test after an agricultural UAV crashed in a mountainous scenario. The issue was that when the pilot commanded full throttle to make the UAV gain altitude after descending the mountain, but the UAV kept slowly descending for about 7 seconds before starting to climb, due to the accumulated AGL terrain altitude error, and it hit a tree.
By the way thank you for your support, I’ll open an issue about this and I’ll think more about possible fixes.
