Long distance altitude control

[EwoudSmeur]

Following up on #3091, I made some code to control the ellipsoid altitude, and obtain position errors in a local NED frame centered at the drone (not at the origin), because if the origin is far away from the drone it will be tilted wrt the earth surface. I only changed the hybrid code so far.

Now though it is somewhat straightforward to calculate the horizontal position errors and the altitude, this has some implications:

• Position reference positive up (following the ellipsoid alt definition)
• The horizontal reference model will become more complicated, as the position reference can no longer be a NED coordinate.
• I am not sure what that would mean for nav routines such as the circle.

An alternative could be to move the NED origin every kilometer or so and do the vertical control in altitude above ellipsoid, but keep the horizontal control in NED. Every time the origin is moved, the waypoints and reference models need to be reset. This could lead to some difficulty with the GCS, as it needs to be communicated over the datalink that the origin has moved. It will also lead to jumps in all the NED signals.

Another issue is that EKF2 estimates altitude in the NED frame, but puts the altitude above the ellipsoid there. If you get the current LLA altitude from the state, it will be too low if the drone is not close to the origin.

Any input is welcome! @gautierhattenberger @dewagter @noether

[noether]

Mmm, maybe I am wrong here because I do not remember all the "nav"s in Paparazzi.

When the GPS is on, do not we have MSL altitude? I mean, the problem is only in the XY because the error by the tangent plane to the sphere is noticeable, right? The Z is always okei since it is always on the line between the center of the Earth and the vehicle. This is what I thought Paparazzi was doing, but I am probably wrong haha.

[EwoudSmeur]

Well, it may depend on the INS, as what you describe is what is done in EKF2. However, for instance in ins_int.c a height correction is done, such that the barometer measurement is transformed in an approximately correct NED height (though incorrect if the distance gets really large).
Also all the waypoints are transformed to the NED frame, which you can observe if you compile a flight plan with some waypoints far away from the origin, they will have a NED down coordinate which is lower, such that it matches the earth's curvature. So this works now for ins_int, but not for ins ekf2. For ekf2, no correction should be done to the NED waypoint z, but they wouldn't be real NED coordinates then.

[noether]

Regardless of this hack :P.

It looks like we should divide (add a tag or dependency?) between code/modules that support operations far from the initial and fixed ground station and local operations.

Maybe a feature to have in the wish list is to count on navigation that operates directly in LLA.

What do you think @gautierhattenberger ? Do you see it feasible? Or will it break most of the code? :P.

[gautierhattenberger]

If you want to make a proper navigation on a non flat ground, you need to have your guidance/navigation in lla directly. Years ago, I tried a hack where the x/y coordinates and differences where computed using the Haversine formula that @EwoudSmeur have also used here. So the x/y where not orthonormal Cartesian coordinates anymore, and it kind of works. It was for fixedwing and before having the state interface. Now, I think it is a bit more complex.
Probably we need to redefine the different coordinates:

• LLA based on ellipsoid
• LTP tangent plane frame at LLA0/ECEF0
• NED something that always have Z pointing down and X/Y following the earth curvature; something else ?
• UTM certainly a bad idea, but for now required for fixedwing

Then the altitude to track: z in LTP, alt above ellipsoid or hmsl ? Fixedwing firmware is flying with hmsl. It seems to be the best choice to me, also compatible with EKF2, and probably easy to adapt to our filters if needed.

[gautierhattenberger]

sorry, for close/reopen, wrong button

[EwoudSmeur]

Yes, so what I implemented is the haversine approach (which is the same as calculating waypoint errors in an LTP frame at the drone position) with vertical ellipsoid alt (but can be changed to hmsl).

I also fixed some bugs in the state conversions by the way.

@gautierhattenberger @noether @Fabien-B @fvantienen @dewagter

I think it would be good to have a video call about this topic, such that we implement something that everybody is happy with.
Would any of these dates work? (CET time)

• Wednesday 8th at 11:00
• Monday 13th 9:00
• Tuesday 14th at 14:00

[gautierhattenberger]

I'm only available tomorrow (8/11) at 11:00.

I saw the bug fix in state, I think it deserves a specific PR...

[noether]

I can make it tomorrow at 11.00 too. At least, it is nice to see your faces again.

[fvantienen]

Tomorrow at 11:00 is fine with me as well