Adding geographical clarifications to REP-0103.

This pull request adds some clarification to REP-0103 about how systems aware of their global location and orientation should represent that information in standard cartesian ROS messages.

As the manufacturer of many outdoor, GNSS-equipped ROS systems, @clearpathrobotics is strongly interested in having clarity around these issues, as it helps us deliver value and consistency to our users, helps our users understand how their systems are configured, and helps everyone achieve harmonious integration between different IMUs, GNSSes, and INSes, as well as higher level localization and planning systems.

I'd prefer to save this follow-on discussion for later, but the larger context here is to work toward an amendment or follow-on to REP-0105 which would clarify what the meanings of the `odom` and `map` frames are in a globally-aware system, and whether a new frame is required which represents an absolute reference.
I don't know why this didn't come thought the github issue tracker - I
pasted it in there.

Let progress continue - even on Christmas day. Merry Christmas everyone.

Paul

On Thu, Dec 25, 2014 at 12:26 PM, Paul Bouchier <paul.bouchier@gmail.com>
wrote:

> Mike,
>
> This rep is very much better than it was when you started, and I'm not
> trying to re-open anything, but I'm struggling to integrate the two
> paragraphs under "Geographical Frames" with the rest of the standard. Can
> you help me understand how it fits. Perhaps it just needs its own
> subsection that helps what it standardizes fit into the whole.
>
> When I look at the updated REP103 as a whole, I see:
>
> - Units. All good
> - Coordinate frames: standards for orientation relative to the body, how
> to represent rotation & covariance. All good.
> - Geographic frames, where I struggle with:
> -------
>
> Systems representing global geographical locations should do so using
> latitude and longitude in float64 decimal degrees, referencing the WGS 84
> ellipsoid <http://en.wikipedia.org/wiki/World_Geodetic_System>, with
> altitude specified in meters above the ellipsoid.
>
> It may also be desirable to define a local Cartesian frame, especially as
> this allows a GNSS- or compass-equipped system to interoperate with
> software built around Cartesian indoor systems.
>
> ----
>
> Then standards for cartesian frames in a geographic context which specify
> axis orientation & rotation representation. All good.
>
> Whereas the rest of the standard deals with cartesian frames and their
> orientation and how to represent position and orientation, the first
> paragraph under the "Geographic Frames" heading seems to come out of left
> field by requiring global geographic locations to be represented in a
> non-cartesian manner (lat/lon). If it had said UTM it would have fit right
> into the whole cartesian coordinate frames concepts, but plugging lat/lon
> into this standard seems like a singularity - discordant.
>
> The second paragraph seems to undermine the first by saying "oh and you
> might want a local cartesian frame for certain reasons". It is not
> normative, and while informative to a degree, doesn't say it standardizes
> anything. Is the second paragraph an introduction to the subsections that
> follow and the first paragraph something else?
>
> Reality for outdoor robots is that they will use some kind of cartesian
> frame for local navigation, and that's what the subsections that follow the
> Geographic Frames heading standardize. Although introducing the
> representation of global geographic locations in paragraph 1 is certainly a
> relevant consideration, standardizing it with lat/long jars with the rest
> of the standard. What messages does this drive? Or is it driven by the
> NavSatFix message (which would seem backwards). Something more is needed
> that connects it to what follows, if it should even be there, but I don't
> know what.
>
> Put another way, this whole standard tells me how to represent locations
> and orientations in cartesian space, in both geographic and non-geographic
> contexts. Then jammed in the middle is a statement that waypoint and
> obstacle locations - very important considerations - should be represented
> in a non-cartesian way, but only if they're geographic.
>
> If lat/lon belong here, I agree with specifying their representation &
> interpretation (float64 decimal degrees, altitute, WGS84, etc.)
>
> Regards
>
> Paul Bouchier
>
> On Wed, Dec 24, 2014 at 10:10 PM, Mike Purvis <notifications@github.com>
> wrote:
>
>> In rep-0103.rst
>> <https://github.com/ros-infrastructure/rep/pull/88#discussion-diff-22267628>
>> :
>>
>> > @@ -164,6 +165,61 @@ Six Dimensional
>> >      float64[36] covariance
>> >
>> >
>> > +Geographical Frames
>> > +===================
>> > +
>> > +Systems representing global geographical locations should do so using
>> > +latitude and longitude, referencing the `WGS 84 ellipsoid`_, with
>> > +altitude specified in meters above the ellipsoid.
>> > +
>> > +It may also be desirable to define a local cartesian frame,
>>
>> Changed.
>>
>> —
>> Reply to this email directly or view it on GitHub
>> <https://github.com/ros-infrastructure/rep/pull/88/files#r22267628>.
>>
>
>