I’ve looked at your log. Here is how the altitude data looks like:
The red line is the rangefinder reading
The green line is the desired altitude based on the rangefinder reading (notice it disappears when you switch to AUTO)
The orange line is the altitude calculated by the EKF after fusing the different sensors (baro and rangefinder)
The blue line is the altitude data calculated from the barometer.
You can find that altitude data in the CTUN message (described in details here)
First thing that’s odd is that the green line (desired altitude based on rangefinder) disappears when you switch to AUTO. I converted your .bin log into a .log file to take a look at it packet by packet (with a simple app like Notepad). Here is what I see:
DSAlt becomes NaN when AUTO is activated.
My guess is it’s because it’s trying to use the SRTM terrain data that seems to be missing here):
@line = 37861 (in LOITER mode): note the “NaN” is TAlt , “2.480771” is your desired rangefinder alt in loiter mode:
CTUN, 319143978, 0.1584907, 4.422665E-05, 0.1564572, 0.1453676, 6.024798, 6.140826, 6, 2.480771, 2.56, NaN, -8, -7, 80
@ line = 67194 (in AUTO mode): your desired rangefinder alt has become NaN (=TAlt) which might explain why it’s not following rangefinder readings anymore:
CTUN, 545619893, 0.1468592, 6.400049E-05, 0.1446142, 0.1449793, 5.574391, 6.29668, 6.6, NaN, 2.26, NaN, -72, -71, 80
In your waypoint file, try changing “Frame” from “Terrain” to “relative” to see if that changes anything.
Another option: based on the graph above, the EKF relies on the baro data and seems to not give much weight to the rangefinder data. You could try to play with RNGFND_GAIN (increase it) see if that has an influence.
If that doesn’t work there are other options we can look at.
