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.
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>.
>