common: add note about lan and lon = 0

[julianoes]

This just describes the state as it is implemented by ArduPilot and QGC.

Relevant discussion in PX4/PX4-Autopilot#15308.

MAVSDK change to match it: mavlink/MAVSDK#1144

[hamishwillee]

is ", expressed" needed here? I suspect a hangover from when the units were removed.

[hamishwillee]

@julianoes Yes, we need a way to indicate that specific values are not ready (if all values are not ready the message probably should not be emitted).

1. But 0,0 is actually valid (though admittedly an edge case). As you know it is considered bad form to use a valid value to indicate "not supported/supplied", which is why we use an INT32_MAX for things like this.

   Could we work with ArduPilot to "do the right thing" here? Practical code could still recognise that 0,0 is invalid for now.
   @auturgy FYI?

2. Presumably some of the other fields might also not be supplied - either on startup, or even in some GPS units. Can we add "not supported" cases for those too?

[auturgy]

Let’s not scope creep: I’d get this in (the edge case, aka Null Island, isn’t likely to be encountered), and perhaps raise an issue to review/add extras

[LorenzMeier]

Entering magic values into a valid range is against best practices. It is unlikely that a lat / lon of 0/0 ever hits a real system - yes. But if I were to review the MAVLink spec and found stuff like that I would loose trust into the implementers because very apparently they are too lazy to implement things correctly and have all sorts of magic easter eggs hidden.

Magic values are fine until they are not. And it is very simple to objectify this: If a unit test that does an input data sweep would fall over, then it is a bad change. In this case a sweep across all possible coordinates would generate an incorrect result here, so it is a bad change.

@DonLakeFlyer If you need altitude, please use the correct packet for it: http://mavlink.io/en/messages/common.html#ALTITUDE

[hamishwillee]

@LorenzMeier Is it worth though tightening the spec to do this "correctly"? i.e. specify reasonable values like INT32_MAX for the values that potentially might not be sent, and which are therefore sent as zero.

[DonLakeFlyer]

specify reasonable values like INT32_MAX for the values that potentially might not be sent

We should do that. There needs to be something, otherwise a GCS doesn't know how to get altitude information from what message.

[LorenzMeier]

The INT32 max approach is perfectly adequate and fine by me. It might however break existing receivers which lack range checking.

@DonLakeFlyer You really should be getting altitude information from the ALTITUDE message. GLOBAL_POSITION_INT is designed as a global position estimate that ONLY gets sent if you actually have one. The MAVLink spec has an approach to do all of this correctly for a long time, so it should be used.

[DonLakeFlyer]

The MAVLink spec has an approach to do all of this correctly for a long time, so it should be used.

Doc'ed where? Point me at the docs which tell a GCS what it should do and I'll update to it.

[LorenzMeier]

@DonLakeFlyer If you need altitude, please use the correct packet for it: http://mavlink.io/en/messages/common.html#ALTITUDE

[DonLakeFlyer]

Ages ago, this was changed: mavlink/qgroundcontrol#4346. It made GLOBAL_POSITION_INT take precedence over ALTITUDE. No comments in there as to why unfortunately.

So the question for mavlink spec is which one of these statements is correct:

• Send of ALTITUDE is required and should be the only place GCS gets altitude telemetry from
• Send of ALTITUDE is optional and if not sent a GCS should fall back to GLOBAL_POSITION_INT for altitudes