Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Ryanf55
Copy link
Contributor

@Ryanf55 Ryanf55 commented Sep 12, 2024

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

image

Alternatives

References to other implementations of this

Earliest documented support

This work was sponsored by AeroVironment.


A vehicle flying facing east will have a unit identity quaternion for its orientation.

x,y,z=0, w=1
Copy link
Contributor Author

@Ryanf55 Ryanf55 Sep 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ros-discourse
Copy link

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

* This clarifies a standard way to publish global pose of a vehicle
* Add another example to REP-103 to remove ambiguity

Signed-off-by: Ryan Friedman <ryan.friedman@avinc.com>
Copy link

@tizianofiorenzani tizianofiorenzani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

rep-0147.rst Outdated Show resolved Hide resolved

A vehicle flying facing east will have a unit identity quaternion for its orientation.

x,y,z=0, w=1

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

the unknown fields should be populated with ``NaN`` to avoid Null Island [#null_island]_.

TODO add link to ArduPilot test code for orientation.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Co-authored-by: Tiziano Fiorenzani <tiziano.fiorenzani@gmail.com>
this yaw value is NOT equal to the traditional compass bearing.

In the situation that the position is known but orientation it not known, or vise versa,
the unknown fields should be populated with ``NaN`` to avoid Null Island [#null_island]_.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants