I think it's about time to resurrect this discussion about adding GPS
messages to sensor_msgs for the Diamondback release. Getting the
messages defined early and committed to unstable will provide people a
chance to experiment with them before interfaces get frozen for the
release.

I am interested in participating. Let's discuss options some more here
on the mailing list. If there is a consensus on a fairly concrete
approach, we could probably start a package proposal and API review on
it soon after.

On Fri, May 21, 2010 at 11:05 PM, Bill Morris <morris@ee.ccny.cuny.edu> wrote:
> On Fri, 2010-05-21 at 22:03 -0500, Jack O'Quin wrote:
>> On Fri, May 21, 2010 at 9:35 PM, Tully Foote <tfoote@willowgarage.com> wrote:
>>
>> > With regards to a location of a potential GPS message within the ROS package
>> > ecosystem, as the maintainer of common_msgs this seems like a strong
>> > candidate for inclusion in the sensor_msgs package.
>>
>> Good idea. I hadn't thought of that. I was imagining a new package
>> defining both the messages and some utility functions.
>>
>> Putting just the messages in sensor_msgs is better. There might end up
>> being two or three messages, depending on how people decide to
>> structure it.
>
> sensor_msgs seems like a good place for the messages. I think it should
> be three messages; GPS fix, status and waypoints/landmarks. A message
> that describes a moving object may also be useful for swarming aircraft.
>
>> > As for the library components doing a package proposal for gps_common would
>> > be a good idea.
>>
>> I just realized that Ken Tossell already has a gps_common package in
>> the umd-ros-pkg (University of Maryland). Looks like it only has a
>> message definition right now.
>>
>> Whether we call it that or something similar, should it be a separate
>> stack or part of some existing one?
>
> I would guess that the gps related functions belong in a package in the
> navigation stack. I think gps_common sounds like a reasonable name.
>
> Great circle distance between the current gps position and waypoints
> would be a useful function. Functions to calculate the heading to the
> next waypoint and time to next way point at current speed may also be
> useful.
>
> I imagine a waypoint/landmark being a position with a rectangular of
> spherical volume, an optional desired heading, and a text label.
>
> I am willing to try to find some time this weekend to put together the
> review page with a summary of the current ideas for the package and
> messages if/when we have consensus on where they belong.


-- 
 joq