Move GLOBAL_POSITION msg from development to common by bresch · Pull Request #2403 · mavlink/mavlink

bresch · 2026-01-08T13:42:20Z

We're happy with the current definition of this message, so unless someone still wants to change something, I think it's time to move it to common.

sfuhrer · 2026-01-13T09:35:20Z

@peterbarker @hamishwillee @auturgy anything against this move?

hamishwillee · 2026-01-27T23:49:37Z

      <field type="uint8_t" name="flags" enum="AIRSPEED_SENSOR_FLAGS">Airspeed sensor flags.</field>
    </message>
+    <message id="296" name="GLOBAL_POSITION">
+      <description>Global position measurement or estimate.</description>


Can we expand on this a little? What rate are you outputting it/expecting it to be output. What are you expecting it to be used for? When would you use this instead of one of the GPS_RAW messages?

Basically I want it to be obvious from the description who it is for and when it should be used and how it might be consumed.

@MaEtUgR ^^^ Who is it for - is it just telemetry for consumption by a GCS? I know you all know what it is, but I don't

I have moved this discussion to #2419

hamishwillee

Thanks @bresch - I know this has been worked on before but I have more questions. Will add to discuss in the MAV call this evening.

peterbarker · 2026-01-28T06:09:07Z

On Tue, 27 Jan 2026, Hamish Willee wrote: My understanding is that the message had evolved to be too complicated and far from its original purpose, so @tridge and @bresch decided to cut it back.

Yes, I'm regretting weighing in now. I do want a replacement for GLOBAL_POSITION_INT where we can give more information about exactly what's going on, and to provide a uniform way of presenting information from multiple estimators on-board. Is it just me, or is this message currently equivalent to GPS_INPUT, give-or-take? See also ArduPilot/ardupilot#31738

hamishwillee · 2026-01-28T21:46:35Z

Is it just me, or is this message currently equivalent to GPS_INPUT, give-or-take?

Given the three messages:

The GLOBAL_POSITION lacks clarity on how it is supposed to be used - I assume it is output from a position system and input to flight stack, so serves the same purpose. However I see GPS_INPUT as very GPS focussed, while this is position-from-any-source focused.

It does raise questions about how much information you really need from a position source for use by an estimator. From the GLOBAL_POSITION message, assuming it does indeed do the job, "nowhere near as much as GPS_INPUT".

That all said, I am still not opposed to additions to allow this to replace https://mavlink.io/en/messages/common.html#GLOBAL_POSITION_INT if we can get that agreed.

peterbarker · 2026-01-29T09:23:08Z

Have talked with Paul, who is currently very interested in this area. He points out that the lense-to-transmission-time is important for any sensible estimator consuming the data. This information is present in the command we are currently using to consume similar information.

To that end, could I propose this as a structure? This does away with the message being at all emitted by the autopilot - this would simply be sensor data.

    <message id="296" name="GLOBAL_POSITION">
      <description>Global position measurement or estimate.</description>
      <field type="uint8_t" name="target_system">System ID (ID of target system, normally flight controller).</field>
      <field type="uint8_t" name="target_component">Component ID (normally 0 for broadcast).</field>
      <field type="uint64_t" name="time_usec" units="us">Timestamp (UNIX Epoch time or time since system boot). The receiving end can infer timestamp format (since 1.1.1970 or since system boot) by checking for the magnitude of the number.  This is the time at which this message was transmitted.</field>
      <field type="uint8_t" name="id" instance="true">Sensor ID</field>
      <field type="float" name="processing_time" units="s">The time spent in processing the sensor data that is the basis for this position. The recipient can use this to improve time alignment of the data. This is the time between measurement (e.g. camera exposure time) and transmission of this message. Set to NaN if not known.</field>
      <field type="uint8_t" name="flags" enum="GLOBAL_POSITION_FLAGS">Status flags</field>
      <field type="int32_t" name="lat" units="degE7" invalid="INT32_MAX">Latitude (WGS84)</field>
      <field type="int32_t" name="lon" units="degE7" invalid="INT32_MAX">Longitude (WGS84)</field>
      <field type="float" name="alt" units="m" invalid="NaN">Altitude (MSL - position-system specific value)</field>  <!-- is AMSL the right frame?  Do we want a FRAME? -->
      <field type="float" name="eph" units="m" invalid="NaN">Standard deviation of horizontal position error</field>
      <field type="float" name="epv" units="m" invalid="NaN">Standard deviation of vertical position error</field>
    </message>

I've removed several fields and added a couple. Addition of velocity to be argued over - Paul doesn't have a use for it ATM - we could add it as NaN-default or we could leave it as an extension.

peterbarker · 2026-02-02T10:44:05Z

Random thought. ArduPilot's EKF can impose constraints on control for the vehicle depending on its input - so if you're using optical flow then your height and velocity are limited.

That may be applicable for some of these external sources that may come in via (e.g. GLOBAL_POSITION) , but that hasn't come up in any conversation I've seen. Easy enough to say "outside the scope", but....

hamishwillee · 2026-02-04T00:23:05Z

@peterbarker Looking at your changes

you've dropped the source, which is probably relevant.
Having this like a sensor with status info seems great to me.
What flags were you considering for the status?
Dropping the elipsoid field could be a problem. Unlike AMSL it is a reliable reference that is independent of a particular vendor calcuulation.
I assume the timestamp is time of MAVLink emission. It does seem relevant that the delay from generation to emission be included if it can be.
I thought you wanted velocity so this might be a replacement for GLOBAL_POSITION_INT?

For all of this, I think we need Paul @bresch (and possibly @sfuhrer ) in a discussion. It isn't up to me.

Random thought. ArduPilot's EKF can impose constraints on control for the vehicle depending on its input - so if you're using optical flow then your height and velocity are limited.

That may be applicable for some of these external sources that may come in via (e.g. GLOBAL_POSITION) , but that hasn't come up in any conversation I've seen. Easy enough to say "outside the scope", but....

I was thinking that was what GLOBAL_POSITION was for. Its a reasonable question "do we have enough information to do the job from this".

peterbarker · 2026-02-05T01:00:24Z

* you've dropped the source, which is probably relevant.

Perhaps; as an input to the autopilot it is probably less relevant than as a report from the autopilot.

* What flags were you considering for the status?

I didn't have any in mind, but thought it prudent to include something.

* Dropping the elipsoid field could be a problem. Unlike AMSL it is a reliable reference that is independent of a particular vendor calcuulation.

I can add that back in. Should we allow only a single altitude and a frame for it?

* I assume the timestamp is time of MAVLink emission. It does seem relevant that the delay from generation to emission be included if it can be.

Yes, the timestamp is when the packet left the vehicle, near enough.

* I thought you wanted velocity so this might be a replacement for GLOBAL_POSITION_INT?

This is no longer a replacement for GLOBAL_POSITION_INT. We'll need a separate message for that.

bresch · 2026-02-05T10:02:07Z

+    <message id="296" name="GLOBAL_POSITION">
+      <description>Global position measurement or estimate.</description>
+      <field type="uint8_t" name="id" instance="true">Sensor ID</field>
+      <field type="uint64_t" name="time_usec" units="us">Timestamp (UNIX Epoch time or time since system boot). The receiving end can infer timestamp format (since 1.1.1970 or since system boot) by checking for the magnitude of the number.</field>


From Paul: add sensor delay

@bresch We can do that - what about the other comments?

priseborough · 2026-02-11T23:23:59Z

For my application the inclusion of a sensor delay field is essential.
Sending it as delay rather than a second time stamp is preferable for debugging because the MAVLink data stream can be monitored in real time and the sensor delay read directly rather than requiring the developer to mentally subract two large rapidly changing numbers form each other.
With respect to the height field, I don't use it in my application, however IMO it would be advisable to allow users to use ellipsoid height if they wish as there are sensing modalities, eg star trackers, that are doing the calculations in ECI with a transformation to ECEF.

hamishwillee · 2026-02-12T04:23:34Z

For my application the inclusion of a sensor delay field is essential. Sending it as delay rather than a second time stamp is preferable for debugging because the MAVLink data stream can be monitored in real time and the sensor delay read directly rather than requiring the developer to mentally subract two large rapidly changing numbers form each other. With respect to the height field, I don't use it in my application, however IMO it would be advisable to allow users to use ellipsoid height if they wish as there are sensing modalities, eg star trackers, that are doing the calculations in ECI with a transformation to ECEF.

@priseborough I think that makes sense, but can you please add the change as a github suggestion to this PR exactly how you want it? That way I don't bugger it up.

- target system/component I assume to allow routing - more clear timestamp description - add processing time for simple to support and debug compensation without separate time synchronization - for most clear definition unify to only elipsoidal altitude

priseborough · 2026-02-12T10:14:05Z

For my application the inclusion of a sensor delay field is essential. Sending it as delay rather than a second time stamp is preferable for debugging because the MAVLink data stream can be monitored in real time and the sensor delay read directly rather than requiring the developer to mentally subract two large rapidly changing numbers form each other. With respect to the height field, I don't use it in my application, however IMO it would be advisable to allow users to use ellipsoid height if they wish as there are sensing modalities, eg star trackers, that are doing the calculations in ECI with a transformation to ECEF.

@priseborough I think that makes sense, but can you please add the change as a github suggestion to this PR exactly how you want it? That way I don't bugger it up.

Hamish, I've coordinated with the authors and they've included the message I requested in their latest commit.

MaEtUgR · 2026-02-12T10:17:33Z

I just took over all the feedback into a commit while on a call with @priseborough and @haumarco to have a new version to review.

target system/component I assume to allow routing (@peterbarker 's suggestion)
more clear timestamp description (@priseborough 's suggestion)
add processing time for simple to support and debug compensation without separate time synchronization (@priseborough 's suggestion)
for most clear definition unify to only elipsoidal altitude (as far as I understand @priseborough , @bresch agree this is the most coherent way, does it have real-world limitations?)

hamishwillee · 2026-02-18T00:22:30Z

+      <entry value="0" name="GLOBAL_POSITION_UNKNOWN">
+        <description>Source is unknown or not one of the listed types.</description>
+      </entry>
+      <entry value="1" name="GLOBAL_POSITION_GNSS">
+        <description>Global Navigation Satellite System (e.g.: GPS, Galileo, Glonass, BeiDou).</description>
+      </entry>
+      <entry value="2" name="GLOBAL_POSITION_VISION">
+        <description>Vision system (e.g.: map matching).</description>
+      </entry>
+      <entry value="3" name="GLOBAL_POSITION_PSEUDOLITES">
+        <description>Pseudo-satellite system (performs GNSS-like function, but usually with transceiver beacons).</description>
+      </entry>
+      <entry value="4" name="GLOBAL_POSITION_TRN">
+        <description>Terrain referenced navigation.</description>
+      </entry>
+      <entry value="5" name="GLOBAL_POSITION_MAGNETIC">
+        <description>Magnetic positioning.</description>
+      </entry>
+      <entry value="6" name="GLOBAL_POSITION_ESTIMATOR">
+        <description>Estimated position based on various sensors (eg. a Kalman Filter).</description>
+      </entry>
+    </enum>
+    <enum name="GLOBAL_POSITION_FLAGS" bitmask="true">
+      <description>Status flags for GLOBAL_POSITION</description>
+      <entry value="1" name="GLOBAL_POSITION_UNHEALTHY">
+        <description>Unhealthy sensor/estimator.</description>
+      </entry>
+      <entry value="2" name="GLOBAL_POSITION_PRIMARY">
+        <description>True if the data originates from or is consumed by the primary estimator.</description>
+      </entry>


All the enums should be named with prefix GLOBAL_POSITION_SRC_ by convention.

Suggested change

<entry value="0" name="GLOBAL_POSITION_UNKNOWN">

<description>Source is unknown or not one of the listed types.</description>

</entry>

<entry value="1" name="GLOBAL_POSITION_GNSS">

<description>Global Navigation Satellite System (e.g.: GPS, Galileo, Glonass, BeiDou).</description>

</entry>

<entry value="2" name="GLOBAL_POSITION_VISION">

<description>Vision system (e.g.: map matching).</description>

</entry>

<entry value="3" name="GLOBAL_POSITION_PSEUDOLITES">

<description>Pseudo-satellite system (performs GNSS-like function, but usually with transceiver beacons).</description>

</entry>

<entry value="4" name="GLOBAL_POSITION_TRN">

<description>Terrain referenced navigation.</description>

</entry>

<entry value="5" name="GLOBAL_POSITION_MAGNETIC">

<description>Magnetic positioning.</description>

</entry>

<entry value="6" name="GLOBAL_POSITION_ESTIMATOR">

<description>Estimated position based on various sensors (eg. a Kalman Filter).</description>

</entry>

</enum>

<enum name="GLOBAL_POSITION_FLAGS" bitmask="true">

<description>Status flags for GLOBAL_POSITION</description>

<entry value="1" name="GLOBAL_POSITION_UNHEALTHY">

<description>Unhealthy sensor/estimator.</description>

</entry>

<entry value="2" name="GLOBAL_POSITION_PRIMARY">

<description>True if the data originates from or is consumed by the primary estimator.</description>

</entry>

<entry value="0" name="GLOBAL_POSITION_SRC_UNKNOWN">

<description>Source is unknown or not one of the listed types.</description>

</entry>

<entry value="1" name="GLOBAL_POSITION_SRC_GNSS">

<description>Global Navigation Satellite System (e.g.: GPS, Galileo, Glonass, BeiDou).</description>

</entry>

<entry value="2" name="GLOBAL_POSITION_SRC_VISION">

<description>Vision system (e.g.: map matching).</description>

</entry>

<entry value="3" name="GLOBAL_POSITION_SRC_PSEUDOLITES">

<description>Pseudo-satellite system (performs GNSS-like function, but usually with transceiver beacons).</description>

</entry>

<entry value="4" name="GLOBAL_POSITION_SRC_TRN">

<description>Terrain referenced navigation.</description>

</entry>

<entry value="5" name="GLOBAL_POSITION_SRC_MAGNETIC">

<description>Magnetic positioning.</description>

</entry>

<entry value="6" name="GLOBAL_POSITION_SRC_ESTIMATOR">

<description>Estimated position based on various sensors (eg. a Kalman Filter).</description>

</entry>

</enum>

<enum name="GLOBAL_POSITION_SRC_FLAGS" bitmask="true">

<description>Status flags for GLOBAL_POSITION</description>

<entry value="1" name="GLOBAL_POSITION_UNHEALTHY">

<description>Unhealthy sensor/estimator.</description>

</entry>

<entry value="2" name="GLOBAL_POSITION_SRC_PRIMARY">

<description>True if the data originates from or is consumed by the primary estimator.</description>

</entry>

hamishwillee · 2026-02-18T00:28:27Z

@MaEtUgR Thanks very much. @peterbarker @bresch @priseborough Otherwise are we all happy with this?

I have moved this back into development because it will need to be retested before being accepted #2419

peterbarker

I think this looks fine as a message. Lacking velocity data still - I wonder if that will come back to haunt us.

@priseborough and I will have a look at putting this into ArduPilot.

Not sure moving it from development.xml to common.xml is kosher, even according to the rules at https://docs.px4.io/main/en/mavlink/adding_messages , is it? I don't see an implementation in PX-AutoPilot

hamishwillee · 2026-02-18T09:26:04Z

Moving it from development.xml to common.xml is kosher, even according to the rules at https://docs.px4.io/main/en/mavlink/adding_messages , is it? I don't see an implementation in PX-AutoPilot

True. We need verification of implementation. Let's get #2419 in first, tested, and then we can do this move again.

hamishwillee · 2026-03-11T04:23:09Z

Closing. Superseded by #2422

move GLOBAL_POSITION msg from development to common

332d65b

sfuhrer approved these changes Jan 13, 2026

View reviewed changes

MaEtUgR reviewed Jan 13, 2026

View reviewed changes

Comment thread message_definitions/v1.0/common.xml

hamishwillee mentioned this pull request Jan 27, 2026

GLOBAL_POSITION: move message from dev to standard #2407

Closed

hamishwillee reviewed Jan 27, 2026

View reviewed changes

Comment thread message_definitions/v1.0/common.xml

hamishwillee reviewed Jan 27, 2026

View reviewed changes

hamishwillee reviewed Jan 29, 2026

View reviewed changes

Comment thread message_definitions/v1.0/common.xml

bresch commented Feb 5, 2026

View reviewed changes

hamishwillee reviewed Feb 18, 2026

View reviewed changes

hamishwillee mentioned this pull request Feb 18, 2026

development.xml - GLOBAL_POSITION_INPUT updates #2419

Closed

peterbarker reviewed Feb 18, 2026

View reviewed changes

haumarco mentioned this pull request Feb 20, 2026

development.xml - GLOBAL_POSITION -> GLOBAL_POSITION_SENSOR #2422

Merged

hamishwillee closed this Mar 11, 2026

Conversation

bresch commented Jan 8, 2026

Uh oh!

sfuhrer commented Jan 13, 2026

Uh oh!

Uh oh!

Uh oh!

hamishwillee Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

hamishwillee Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamishwillee Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

hamishwillee left a comment

Choose a reason for hiding this comment

Uh oh!

peterbarker commented Jan 28, 2026 via email

Uh oh!

hamishwillee commented Jan 28, 2026

Uh oh!

Uh oh!

peterbarker commented Jan 29, 2026

Uh oh!

peterbarker commented Feb 2, 2026

Uh oh!

hamishwillee commented Feb 4, 2026

Uh oh!

peterbarker commented Feb 5, 2026

Uh oh!

bresch Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

hamishwillee Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

priseborough commented Feb 11, 2026

Uh oh!

hamishwillee commented Feb 12, 2026

Uh oh!

priseborough commented Feb 12, 2026

Uh oh!

MaEtUgR commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hamishwillee Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

hamishwillee commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

peterbarker left a comment

Choose a reason for hiding this comment

Uh oh!

hamishwillee commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hamishwillee commented Mar 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

hamishwillee Feb 18, 2026 •

edited

Loading

MaEtUgR commented Feb 12, 2026 •

edited

Loading

hamishwillee commented Feb 18, 2026 •

edited

Loading

hamishwillee commented Feb 18, 2026 •

edited

Loading