What todo with the terrain estimator

[AndreasAntener]

@LorenzMeier @Tumbili
We have a separate terrain estimator and the position estimators which sometimes also provide a bottom estimate. I don't know your plans for the position estimators. Should we remove the terrain estimator where the position estimator provides a bottom estimate? Should both estimates co-exist?

[RomanBapst]

@AndreasAntener I can tell you that we are working on an integrated terrain estimator for ekf2, so we will not use the existing terrain estimator in the library. I guess for now the terrain estimator is still important for fixed wings which use the old ekf.

[AndreasAntener]

@Tumbili ok, any suggestions what we should do with INAV? Its currently mixing both and the bottom estimate published in local position is an unfused lidar reading.

[AndreasAntener]

@Tumbili who's working on INAV/Flow the most now? I was wondering if it would be ok if we just publish the bottom distance in local position also from the terrain estimator instead of the plain lidar value.

[sanderux]

If needed i could make the terrain estimator publish on lpos and change inav to use that

[jgoppert]

For LPE, I am getting ready to add a separate terrain altitude state (vertical distance above terrain). The issue is really that you lose your global altitude accuracy from lidar if you give it a separate terrain altitude state. That means that if we want precise terrain following, we need two modes in mc_pos_control. One that tracks terrains altitude, and one that tracks global altitude. The easiest approach would just be to make this dependent on a parameter that the user can set, similar to yaw mode.

[AndreasAntener]

@jgoppert I agree, for that the position controller would need two modes, which also would allow him to react on the loss of the terrain estimation.

Since your explanation on the dev call I think I'm one step further here. But I still don't fully understand your comment I think ;). If one flies outside the lidar range and back in again, you might end up with an offset global altitude compared to terrain estimation. Is that what you meant?

Here I was only talking about letting INAV publish the separate terrain estimation (for local and global), but actually let it internally do what ever it wants (not messing with it).

[jgoppert]

@AndreasAntener I just added terrain estimation to LPE and test flew it. For now I'm outputting AGL as local z. I'm also sending terrain altitude so if we fix mc_pos_control, it should work well.

tz is the distance of the altitude relative to the home altitude.

The dynamics I'm using are just:
d/dt(tz) = 0

with sonar/lidar measuring:
y = -(z - tz);

So when it goes out of range the the tz state freezes, and the AGL is reasonable, difference just estimated from change in ASL (from baro/ gps).

[AndreasAntener]

Closing this, as the old terrain estimator is/can be used with INAV but the new estimators bring their own. Position reset logic with the old one is not implemented though.