Add GeoPoseStamped interface for REP-147 to help clarify geographic orientation

[Ryanf55]

Purpose

Recommend a standard way of publishing the pose of an aerial vehicle and clarify ambiguities with regards to geographic orientation values in outdoor scenarios.

Details

This clarifies a standard way to publish global pose of a vehicle. This has been adopted by the ArduPilot DDS interface and is part of the stable 4.5 release. I added another example to REP-103 to remove ambiguity of the orientation.
Once we add a test in ArduPilot for the orientation, I would like to link the code directly here in the REP as a reference.

Rendered

Alternatives

• GeoPoseStampedWithCovariance - This could be an alternative that gives accuracy data. GeoPoseStamped must be taken as-is.
• px4_msgs/msg/GlobalPosition which includes a horizontal and vertical accuracy but not orientation

References to other implementations of this

• https://www.stereolabs.com/docs/ros2/geo-tracking#gnss-fusion-results
• AP_DDS: Support publishing GeoPoseStamped ArduPilot/ardupilot#23534

Earliest documented support

• https://discourse.ros.org/t/proposed-standard-interface-for-aerial-vehicles-in-ros/287/15

This work was sponsored by AeroVironment.

[Ryanf55]

If there is a more standard way to document the value for the quaternion (perhaps yaml), please supply a reference to the syntax I should use. Or, if we can find an authoritative reference on this definition of unit identity quaternion, that would be great. The Wikipedia does not directly mention it.

[tizianofiorenzani]

Suggested change

	x,y,z=0, w=1
	`x,y,z=[0,0,0], w=1`

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/september-2024-meetings-aerial-robotics-back-from-summer/39383/6

[tizianofiorenzani]

I left a couple of suggestions, mostly to provide some help to developers.

[tizianofiorenzani]

Suggested change

	x,y,z=0, w=1
	`x,y,z=[0,0,0], w=1`

[tizianofiorenzani]

For reference, I would also add the following quaternion transformations, which can be used to convert between Ardupilot's and REP-103 reference frames.

• Assuming that quaternion is expressed as q = [w, x, y, z];
• ned is North, East, Down, standard inertial Ardupilot's frame;
• fru is Forward, Right, Up, standard Ardupilot's body frame;
• enu is East, North, Up, REP-103 inertial frame;
• flu is Forward, Left, Up, REP-103 body frame;

sq2_2 = sqrt(2)/2;
q_ned_2_enu = [0, sq2_2, sq2_2, 0];
q_enu_2_ned = [0, sq2_2, sq2_2, 0];
q_frd_2_flu = [0, 1, 0, 0];
q_flu_2_frd = [0, 1, 0, 0];

Assuming that we start from vehicle's quaternion q_frd_2_enu from Ardupilot's telemetry, and we want to obtain its correspondent in REP-103 q_flu_2_enu, then the following transformation is to be applied (where * is the quaternion product):

q_flu_2_enu = q_ned_2_enu * q_frd_2_ned * q_flu_2_frd

Of course the inverse can be applied: if an orientation is known in RED-103 q_flu_2_enu , that can be transformed into Ardupilot's frame q_frd_2_ned with:

q_frd_2_ned = q_enu_2_ned  * q_flu_2_enu  * q_frd_2_flu

[Ryanf55]

This looks good, although I wonder if the maintainers want the REP to be language agnostic. If they prefer code language agnostic, I can write it up in Latex or something.

[Ryanf55]

Suggested change

	the unknown fields should be populated with ``NaN`` to avoid Null Island [#null_island]_.
	the unknown fields should be populated with ``NaN`` to avoid Null Island [#null_island]_.
	It is up to the platform to decide at what accuracy threshold the data will stop being published
	or switch to ``NaN`.

Thoughts on this for addressing accuracy?