Need to reconfirm how to enforce rangefinder ALT priority


i think i see some questionable behavior - so would like to reconfirm what specific options combination will enforce reading from the rangefinder to take priority over the BARO and GPS in PosHold and AltHold modes.

I observed lately that model deviates from the reading provided by rangefinder with no stick input.
current combination of options set is:

EK3_ALT_SOURCE 0 - to remain at “Use Baro” mode
EK3_RNG_USE_HGT 70 - that is, as i understand, supposed to take RNG reading as a preference and from what i saw before it did work as model would follow terrain up and down, in alt hold.

now, in pos hold - is there anything that could take a deviating signal from gps to set as a preference compared to a RGN ALT reading while in the RGN operational range?

or is there any other parameter that needs to be set to make sure rangefinder ALT is set as a most trustful source?

The only thing I can think of is EK2_OGN_HGT_MASK, which can possibly be set to have GPS altitude be used to slowly trim relative altitude. The default is 0, which prevents this behavior.

EK2_OGN_HGT_MASK is set to 0.

i just tested it - in alt hold it sits on the given altitude dead on. as my driveway is elevated it is a good test - when i move copter to the left it raises up, move to the right - it lowers down to reflect RNG reading.

so, in alt hold all is fine - it sits where it needs to be. in pos hold it shows slow but persistent attempts to ‘travel’ up and down, in combination with horizontal travel as gps signal stabilizes. when it sets on with good hdop - model stops all travel, but i still wonder - why it allows it to travel vertically if i have RNG data set? somewhere somehow it seems that GPS takes preference, not sure why.

and, while it still ‘travels’ it still respects RNG reading as when i move it left and right - it raises and lowers model as well, but still keeps those attempts to alter an altitude sometimes. odd.

Interesting. As far as I know, alt hold and pos hold have the same altitude tracking behavior. Can you post the dataflash log of your test flight?

Sure, i think both those short logs should have moments when Dist1 reading in RGNF shows changes while there is no input from the left stick - ch3 is the throttle

like this:

To give some background on how terrain following works in Loiter, PosHold, AltHold:

  • the EKF altitude estimate is done using the barometer (not the range finder)
  • the pilot’s input commands a desired altitude above terrain
  • the altitude controller uses the desired altitude received from the pilot, the actual altitude from the range finder (corrected for the vehicle’s attitude) and the RNGFND_GAIN parameter value to decide on a climb or descent rate to move the vehicle up or down.

Perhaps that’s a bit complicated but the important bits related to terrain following are:

  • The EKF is not involved in terrain following so it’s very good to see that you’ve left the EKx_ALT_SOURCE to Baro… It should, as it is in your logs, be left at the default.
  • in general nothing needs to be done to achieve terrain following in PosHold, Loiter, AltHold except connect a downward facing lidar
  • when looking to see how well the vehicle is performing terrain following, try comparing the CTUN.DSAlt and SAlt field.
1 Like

By the way, It looks like this vehicle is using EKF3. In the vast majority of cases, it’s best to stick with EKF2 (wiki). The only situations where we’d recommend using the EKF3 over EKF2 is for some advanced sensors like visual odometry or Pozyx beaconds.

In this thread, the summary of terrain following for Loiter/PosHold/AltHold mentions that an EKF altitude estimate is performed, but I am unsure how that estimated altitude is used. If the EKF altitude estimate is not used at all in the mentioned flight modes, when is it used?


Just as a reference we have these two pages on terrain following:

The EKF estimates the altitude using the accelerometers blended with one of three sources (Baro, GPS or rangefinder). Separately the EKF also estimates the altitude above terrain but this should not be used in 99% of cases and it should never be used when doing terrain following. Normally it should only be used when the EKF is using the optical flow sensor’s data for estimating horizontal speed (and position).

Hope that helps…