Proposed standard interface for aerial vehicles in ROS

I’ve updated to make the WGS-84 ellipsoid the default and referenced MSL/WGS84EDM96 geoid as an example of an application specific choice. [quote=“johannesmeyer, post:19, topic:287”]
I am happy with the current draft or REP-105, that leaves it open whether the map frame itself is directly geo-referenced and/or aligned or whether some other intermediate frame(s) between earth and map, so that map would be only indirectly geo-referenced if the transformation is known. Or is “Map Conventions” meant as a subsection specific for the map frame?
[/quote]

It’s intended to be generic and I hope people will use the same guidance for any coordinate frame reference choice.

I called out that the most important thing is that the choice is clearly documented.

Please take a final look at the PR if there’s any outstanding issues please raise them now otherwise please commend on the PR with a +1

Reviewing open PRs I found that we haven’t ratified this. Please take a moment to review the final draft on the follow up to ratify this.

And we’ll be able to close this out.

It’s been a while without action on this REP and I’ve come back to it recently expanding sections and filling in parts. I’ve updated the PR with new content including adding proposed standardized Flight Modes and transitions.

Please take a look at it on github:

1 Like

Thank you for trying to make a unification effort.

I scanned briefly the topic and the proposal and I didn’t find any mention that aerospace and especially UAV literature uses NED for inertial frame instead of ENU and FRD for body frame instead of FLU.

This is IMO the greatest barrier between generic packages and UAV-specific algorithms, which isn’t easy to overcome.
I, for one, prefer to have the guarantee that when I copy-and-paste an algorithm or equation from a UAV book or paper (which is in NED/FRD) it will work and then worry with frame conversions with the outside world instead of,
trying to covert the equations to ENU/FLU.

1 Like