<div>Bill,</div><div><br></div><div>I'd also like to see this happen before the deadline and would be willing to participate in the review process.</div><div><br></div>On Fri, Oct 8, 2010 at 2:58 PM, Bill Morris <span dir="ltr"><<a href="mailto:morris@ee.ccny.cuny.edu">morris@ee.ccny.cuny.edu</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, 2010-09-16 at 11:16 -0500, Jack O'Quin wrote:<br>
> I think it's about time to resurrect this discussion about adding GPS<br>
> messages to sensor_msgs for the Diamondback release. Getting the<br>
> messages defined early and committed to unstable will provide people a<br>
> chance to experiment with them before interfaces get frozen for the<br>
> release.<br>
><br>
> I am interested in participating. Let's discuss options some more here<br>
> on the mailing list. If there is a consensus on a fairly concrete<br>
> approach, we could probably start a package proposal and API review on<br>
> it soon after.<br>
<br>
</div>I'm interested in making this happen, and now we have a deadline.<br>
I would like something similar to the GPSd message but with additions to<br>
make it easier to interface to googlemaps and navigation systems.<br>
<br>
Perhaps one approach is to break the GPS messages down into several<br>
primitives; a point, a volume and a vector.<br></blockquote><div><br></div><div>What additions to a GPS message would make it easier to interface to googlemaps? Don't we just need a lat/long in order to draw a marker in googlemaps? I think it is very important to split the message into basic chunks and build composite messages of that with indicators of whether or not to use the data. This is especially important for non-GPSd devices - I have a GPS unit that currently only outputs lat/long/altitude, standard deviations on each of those in meters, a fix type and number of satellites used. This would leave some of the fields empty in the current GPSd message with no way to say whether or not they should be used. Do we really need both dilution of precision information and the err* fields or can one be derived from the other?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think it would be best to separate the geometry from the satellite<br>
information. this way status information can be optional.<br></blockquote><div><br></div><div>I think it would be best to actually have a GPS position message that includes both the fix itself and status information. Anytime I've used GPS, we've always needed the status information to tell us whether or not to even believe the fix information at all, so I'm not sure how useful an optional status is.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The next question is it worth supporting multiple datums and ellipsoids?<br></blockquote><div><br></div><div>Is there a datum and/or ellipsoid that many others can be converted to? I think it would be best to specify one for this message so that any tools such as the gpsd_viewer only have to worry about one datum and ellipsoid. A gps_tools package could then provide conversion facilities (perhaps similar to the laser_filters used by the laser_pipeline). Mainly, I don't want to have to write code over and over to handle which  GPS reference system is being used in order to support arbitrary GPS receivers.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
In addition to the messages I would like to see a gps tools package with<br>
functions for calculation of distance, time of arrival, time to<br>
intercept, direction to waypoint and etc.<br></blockquote><div><br></div><div>I'd also love to see a reusable set of functions for this. However, I think it's separate from the message definition process besides anytime during the message definition process where we can say that a gps_tools package could handle a conversion instead of having to make the message itself handle it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
My use case is a quadrotor helicopter that needs to fly from point A to<br>
near point B to point C. It would also be nice for the aircraft to track<br>
moving objects as we are looking towards implementation of swarm<br>
control.<br>
<br>
Eventually we are looking toward building 3D map infrastructure so that<br>
we can have the aircraft flying in a global map, switch to a local map<br>
as it approaches a building and switch to a floor map as it enters the<br>
building.<br>
<br>
Related Info<br>
<br>
<a href="http://earth-info.nga.mil/GandG/publications/tm8358.1/toc.html" target="_blank">http://earth-info.nga.mil/GandG/publications/tm8358.1/toc.html</a><br>
<a href="http://code.google.com/apis/kml/documentation/kml_tut.html" target="_blank">http://code.google.com/apis/kml/documentation/kml_tut.html</a><br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>