Add GeoPoseStamped interface for REP-147 to help clarify geographic orientation #407
Conversation
|
|
||
| A vehicle flying facing east will have a unit identity quaternion for its orientation. | ||
|
|
||
| x,y,z=0, w=1 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
| x,y,z=0, w=1 | |
| `x,y,z=[0,0,0], w=1` |
|
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 <[email protected]>
Ryanf55
force-pushed
the
clarify-aerial-orientation
branch
from
8fd867d
to
02bfa52
Compare
|
|
||
| A vehicle flying facing east will have a unit identity quaternion for its orientation. | ||
|
|
||
| x,y,z=0, w=1 |
There was a problem hiding this comment.
| 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. | ||
|
|
There was a problem hiding this comment.
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]; nedis North, East, Down, standard inertial Ardupilot's frame;fruis Forward, Right, Up, standard Ardupilot's body frame;enuis East, North, Up, REP-103 inertial frame;fluis 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
There was a problem hiding this comment.
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 <[email protected]>
| 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]_. |
There was a problem hiding this comment.
| 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?
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
References to other implementations of this
Earliest documented support
This work was sponsored by AeroVironment.