Add GPS_GLOBAL_ORIGIN mavlink msg.

[nsteele]

Adds a previously unsupported common mavlink message GPS_GLOBAL_ORIGIN.

The motivation is to allow external systems and companion computers to know the global location of the local frame origin.

Testing

I ran a few simulated flights to test. The local frame origin is set by the state estimator and is published as part of the vehicle_local_position msg. Here are the relevant fields of that message:

pxh> listener vehicle_local_position

TOPIC: vehicle_local_position instance 0 #1
 vehicle_local_position_s
        ...
        ref_lat: 47.397742
        ref_lon: 8.545593
        ref_alt: 0.0000
        ...
        xy_global: True
        z_global: True
        ...

I enabled GPS_GLOBAL_ORIGIN to be published to QGC with this command:

mavlink stream -u 14570 -s GPS_GLOBAL_ORIGIN -r 1.0

and you can see in the following image that QGC is receiving the same values from the vehicle_local_position msg:

The lat/lon values of GPS_GLOBAL_ORIGIN in the image above are similar to the lat/lon of the GLOBAL_POSITION_INT message, which is expected because I didn't fly far from the first gps fix position during this simulation.

The following two images show GLOBAL_POSITION_INT.latitude (red) vs GPS_GLOBAL_ORIGIN.latitude (white) and GLOBAL_POSITION_INT.longitude (blue) vs GPS_GLOBAL_ORIGIN.longitude (red) respectively. In both graphs, the vehicle takes off from the first vehicle position of the simulation then eventually returns home. As expected, the vehicle lat/lon aligns with the global origin lat/lon at the beginning and ending.

As a test on the altitude, we expect the global origin altitude plus the vehicle local altitude to equal the vehicle global altitude. The first graph below is the global origin altitude (white) and the vehicle local altitude (red), and if you add them together, you would get the same shape as the second graph below, which has the vehicle global altitude (orange). The reason we use the shape as our test instead of actual values is because the two graphs are at different scales.

[dagar]

Looks good, although sending it constantly (even at 1 Hz) seems like a waste for something that will likely only be sent once.

[dagar]

Check the CI output (jenkins). There's a trivial formatting issue. http://ci.px4.io:8080/blue/organizations/jenkins/PX4%2FFirmware/detail/PR-12665/1/

[nsteele]

Ok I fixed the formatting issue

[nsteele]

This is somewhat related to this PR. @dagar could you check that out as well?

[hamishwillee]

Looks good, although sending it constantly (even at 1 Hz) seems like a waste for something that will likely only be sent once.

FWIW the message docs indicate that this should be emitted when changed (e.g. on getting a GPS lock) - there is no implication that it should be streamed by default.

So some options for consideration

• explicitly set it by pinging SET_GPS_GLOBAL_ORIGIN
• Add support for a one-off query using MAV_CMD_REQUEST_MESSAGE
• Request a stream using MAV_CMD_SET_MESSAGE_INTERVAL

FYI, also tidying up the wording of the message in mavlink/mavlink#1201

[nsteele]

@hamishwillee thank you. For my application, I will use one of the methods you suggested for getting GPS_GLOBAL_ORIGIN instead of relying on a hard-coded default stream.

@dagar I removed the hard-coded default streaming.

[hamishwillee]

Sounds great. FWIW I'd love to see support for both MAV_CMD_REQUEST_MESSAGE Request a stream using MAV_CMD_SET_MESSAGE_INTERVAL.

Note that MAV_CMD_REQUEST_MESSAGE is supposed to be a "generic" message for getting a flight stack to emit any particular message. It isn't implemented for any message yet, but I'm sure if you do it for GPS_GLOBAL_ORIGIN we will be extending for lots of others :-)

[TSC21]

@nsteele can you take the chance to take a look at #7368? My main concern here is that we lose the definition of global if we are updating the msg with the content of a local position message. Also, as you can read, soon enough we will move to support the local frame navigation onboard, which will through the global frame into second.
I would say that the global origin should be propagated system wise the same way the home position is. On multi-entity systems, this will also make sure that we have granular control over that origin and have a specific pipeline to handle it. So whatever fields with have with the ref position should move to a new uORB in my opinion.
@julianoes any comments you want to bring as well?

[nsteele]

@TSC21 yes I saw #7368 and I'm hoping to make positive progress towards that with this PR. I have a few questions.

I would say that the global origin should be propagated system wise the same way the home position is.

Could you elaborate on this? Do you only mean that there should be a dedicated uORB topic/message for the global origin, like home position has a dedicated topic/message?

So whatever fields with have with the ref position should move to a new uORB in my opinion.

Does this data model work?

uint64 timestamp		# time since system start (microseconds)

float64 lat			# Latitude, (degrees)
float64 lon			# Longitude, (degrees)
float32 alt			# Altitude AMSL, (meters)

Do you prefer it be called gps_global_origin, global_origin, or something else?

Here is my proposed work remaining to merge this:

1. Define the new global origin uORB message.
2. Update my existing changes to send a mavlink message based on the new uORB message

Of course nothing would publish this new uORB message just yet, but perhaps we could capture that follow-on work in #7368 ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[LorenzMeier]

Thanks for originally proposing this! I'm closing this PR as stale - if you still would like to add this, a new, rebased PR would be most welcome! Our apologies for not being more on top of it earlier. Closing stale PRs helps us to make sure that overall we can drive PRs to completion.

[mcsauder]

Hi Everyone, I think this is all closely related to the following:
#16544
PX4/PX4-ECL#962
mavlink/MAVSDK#952

Perhaps we can pull things together.

[dagar]

Hi Everyone, I think this is all closely related to the following:
#16544
PX4/PX4-ECL#962
mavlink/MAVSDK#952

Perhaps we can pull things together.

We actually added the GPS_GLOBAL_ORIGIN stream separately at some point.

PX4-Autopilot/src/modules/mavlink/streams/GPS_GLOBAL_ORIGIN.hpp

Lines 39 to 80 in 10d94e5

	class MavlinkStreamGpsGlobalOrigin : public MavlinkStream
	{
	public:
	const char *get_name() const override
	{
	return MavlinkStreamGpsGlobalOrigin::get_name_static();
	}
	static constexpr const char *get_name_static()
	{
	return "GPS_GLOBAL_ORIGIN";
	}
	static constexpr uint16_t get_id_static()
	{
	return MAVLINK_MSG_ID_GPS_GLOBAL_ORIGIN;
	}
	uint16_t get_id() override
	{
	return get_id_static();
	}
	static MavlinkStream *new_instance(Mavlink *mavlink)
	{
	return new MavlinkStreamGpsGlobalOrigin(mavlink);
	}
	unsigned get_size() override
	{
	return _vehicle_local_position_sub.advertised() ?
	(MAVLINK_MSG_ID_GPS_GLOBAL_ORIGIN_LEN + MAVLINK_NUM_NON_PAYLOAD_BYTES) : 0;
	}
	private:
	uORB::Subscription _vehicle_local_position_sub{ORB_ID(vehicle_local_position)};
	/* do not allow top copying this class */
	MavlinkStreamGpsGlobalOrigin(MavlinkStreamGpsGlobalOrigin &) = delete;
	MavlinkStreamGpsGlobalOrigin &operator = (const MavlinkStreamGpsGlobalOrigin &) = delete;
	protected: