cleanup/document altitude definitions: ellipsoid vs. geoid (msl)

[flixr]

Currently we are mixing up different altitude definitions in some cases/messages which clearly needs to be consolidated, cleaned up and documented.

We usually have global altitude as either

• alt above WGS84 reference ellipsoid
• Height above Mean Sea Level (hmsl), so altitude above geoid)

See also differences explained at https://wiki.paparazziuav.org/wiki/Altitude_definitions

Some things to check/fix/consolidate/document:

• fixedwing waypoint altitude seems to be passed as hmsl
• LLA coordinates usually have alt above ellipsoid (gps datum)
• in UtmCoor_f struct we say that alt is above ellipsoid (and assume that in conversion functions), but seems it is filled with hmsl in some cases
• etc...

LtpDef has alt above ellipsoid in LLA coordinates and an addtional hmsl field

[benlaurie]

On Thu Dec 04 2014 at 9:40:55 PM Felix Ruess notifications@github.com
wrote:

Currently we are mixing up different altitude definitions in some
cases/messages which clearly needs to be consolidated, cleaned up and
documented.

We usually have global altitude as either

• alt above WGS84 reference ellipsoid
• Height above Mean Sea Level (hmsl), so altitude above geoid)

See also differences explained at
https://wiki.paparazziuav.org/wiki/Altitude_definitions

Some things to check/fix/consolidate/document:

• fixedwing waypoint altitude seems to be passed as hmsl
• LLA coordinates usually have alt above ellipsoid (gps datum)
• in UtmCoor_d struct we say that alt is above geoid (and assume that
  in conversion functions), but seems it is filled with hmsl in some cases

Confused by this: you said above hmsl was altitude above geoid.

• etc..

—
Reply to this email directly or view it on GitHub
#1006.

[flixr]

yes... and your question is?

[benlaurie]

On Thu Dec 04 2014 at 10:34:51 PM Felix Ruess notifications@github.com
wrote:

yes... and your question is?

So why is it wrong to fill it with hmsl?

—
Reply to this email directly or view it on GitHub
#1006 (comment)
.

[flixr]

oh, now I see what you mean... sorry... typo...
The dox says UtmCoor_f alt is above ellipsoid: http://docs.paparazziuav.org/latest/structUtmCoor__f.html
And some conversion functions also assume that (or rather simply copy the alt to/from LLA).

For some conversion chains it still ends up being correct, but that is not generally the case...

[OpenUAS]

Specifics if all agreed upon will be added to http://wiki.paparazziuav.org/wiki/Demystified/Altitude_and_Height

As sideremark for future improvement(rotorcraft - fixedwing unification)
IMHO from user perspective fixedwing as well as rotorcraft height options/messages should all have same amount of options. I cannot come up with a reasonabel argument why one should have more or other.

[josibarns]

Does the WGS84 ellipsoid altitude come directly from the GPS or is it
computed by paparazzi?

On Sat, Dec 6, 2014 at 3:25 PM, OpenUAS notifications@github.com wrote:

Specifics if all agreed upon will be added to
http://wiki.paparazziuav.org/wiki/Demystified/Altitude_and_Height

—
Reply to this email directly or view it on GitHub
#1006 (comment)
.

[flixr]

Ellipsoid altitude is computed in paparazzi (e.g. when converting from ECEF to LLA, see lla_of_ecef_d function).
Geoid (MSL) altitude currently can't be computed onboard since we don't store a geoid model... so this usually comes from the GPS...

[josibarns]

Thanks Felix,

Does this mean that the altitude in the DC_SHOT message is computed by
paparazzi as well?

On Sat, Dec 6, 2014 at 6:56 PM, Felix Ruess notifications@github.com
wrote:

Ellipsoid altitude is computed in paparazzi (e.g. when converting from
ECEF to LLA, see lla_of_ecef_d function
http://docs.paparazziuav.org/latest/pprz__geodetic__double_8c_source.html#l00059
).
Geoid (MSL) altitude currently can't be computed onboard since we don't
store a geoid model... so this usually comes from the GPS...

—
Reply to this email directly or view it on GitHub
#1006 (comment)
.

[flixr]

The LLA position is fetched from the state interface with stateGetPositionLla_i(), so it depens in which format the position was set in the state interface.
So if you would set the position in UTM directly from the gps, it would convert the UTM coordinates to LLA (where the altitude can just be copied) and use that.
If set the position in NED (e.g. from your INS filter running in NED), then it will convert it from NED which requires computing the alt.

[flixr]

Do we need to keep this open? At least the current state is documented...
@dewagter what do you think?

[dewagter]

I think ellipsoid / geoid is quite clear.

• relative / absolute is a problem tough
• baro/gps is also not obvious

This issue can be closed, but at some point an update an update in the
altitude would be desirable

class Altitude
{
enum { ELLIPSOID, MEAN_SEA_LEVEL, LOCAL_AIRFIELD }
enum { BAROMETRIC, GPS, GROUND_SENSOR }
get() {

}
}

-Christophe

On Tue, Nov 3, 2015 at 10:33 PM, Felix Ruess notifications@github.com
wrote:

Do we need to keep this open? At least the current state is documented...
@dewagter https://github.com/dewagter what do you think?

—
Reply to this email directly or view it on GitHub
#1006 (comment)
.

[kirkscheper]

I am a bit confused with the utm alt... in the definition of the struct it states "in meters above WGS84 reference ellipsoid" but in state.c, the reference frame is set using hmsl (void ins_float_invariant_init(void):216). Shouldn't we just stick to one? The two are quite confusing.

[flixr]

@kirkscheper maybe we shouldn't specify the alt reference in the UtmCoor_f definition, as it can be use to represent altitude wrt. different references (geoid, ellipsoid, ground, ...)

[kirkscheper]

If it isn't consistently used, it may be more clear not to have a height in that structure at all, haha. Users would have to get the altitude from another place (lla for above ellipsoid, ins for ground, gps for geoid). Or alternatively... store the height somewhere readily available in each format (if available) in the state.c using a similar bit set method used for the other formats.

[flixr]

There is no simple solution for this... sometimes you simply need ellipsoid alt (e.g. converting to ECEF) and sometimes geoid/msl alt.
Same goes for LLA/LLH actually...

And you don't always have information for both ellipsoid and geoid.
IMHO the best we can do is to document in which cases what is used...

[kirkscheper]

:'(

On 22/03/16 12:54, Felix Ruess wrote:

There is no simple solution for this... sometimes you simply need
ellipsoid alt (e.g. converting to ECEF) and sometimes geoid/msl alt.
Same goes for LLA/LLH actually...

And you don't always have information for both ellipsoid and geoid.
IMHO the best we can do is to document in which cases what is used...

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1006 (comment)