<div class="gmail_quote">On Mon, Jun 13, 2011 at 7:43 AM, Bill Morris <span dir="ltr"><<a href="mailto:morris@ee.ccny.cuny.edu" target="_blank">morris@ee.ccny.cuny.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div></div><div class="gmail_quote"><div><div></div><div class="h5">On Fri, 2011-06-03 at 21:24 -0500, Jack O'Quin wrote:<br>> On Wed, Jun 1, 2011 at 5:33 PM, Chad Rockey <<a href="mailto:chadrockey@gmail.com" target="_blank">chadrockey@gmail.com</a>> wrote:<br>
> > Hi Jack,<br>> > Eric and I are both finishing our theses and starting jobs this month, but<br>> > we'd be willing to provide our limited input to this.  We've only worked<br>> > with off-road mobile robots with very simple waypoints, nothing like Open<br>
> > Street Maps or Google Maps; although something like that would be great to<br>> > see happen.<br>><br>> > I do like the idea of a common UTM conversion tool.<br>><br>> UTM conversions are fairly easy and quite useful. We've got some that<br>
> can be used. They need some cleanup, so better implementations would<br>> be welcome.<br>><br>> > Another possible tool would be KML import and export to waypoints/paths,<br>> > since this makes it easy to visualize and create paths in Google Earth/Maps.<br>
> >  For our waypoints, we would define them in KML files either by clicking in<br>> > Google Earth or manually typing in coordinates.  Then we could feed this to<br>> > our robot which would start following them in order or we could look at the<br>
> > path either as markers or as a polygon in Google Earth.  Even though the<br>> > imagery data could be a meter or two off, it was still very useful when<br>> > great precision wasn't required or we just wanted to look at the overall<br>
> > shape/order.<br>> ><br>> > Here is an example KML path<br>> > file: <a href="http://code.google.com/apis/kml/documentation/kml_tut.html#paths" target="_blank">http://code.google.com/apis/kml/documentation/kml_tut.html#paths</a><br>
><br>> KML should definitely be considered. Good idea.<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>I think KML should be useful as a guide and definitely a target for<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>interoperability. I'm not sure kml is appropriate for everything that<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>will be needed but it will be nice if we can output kml.<br><br>><br>> > Bill Morris <a href="mailto:morris@ee.ccny.cuny.edu" target="_blank">morris@ee.ccny.cuny.edu</a> writes:<br>
> ><br>> > One of our projects this summer requires GPS based navigation for aerial<br>> > robots so I'll be working on this more later in the summer. I would like<br>> > to see GPS waypoints defined in E-Turtle and a gps_tools library for<br>
> > Fuerte.<br>><br>> I could imagine defining a way-point ID as a 128-bit opaque value,<br>> able to hold a UUID if desired. The basic WayPoint message would at<br>> least contain an ID, latitude and longitude. Maybe that's it. Lat/Long<br>
> needs to be defined unambiguously, probably using fractional degrees,<br>> positive North and East, negative South and West.<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote>I think that we should use ID, latitude and longitude as the initial<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>definition of a waypoint so we are all on the same page.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>If we fix this then it will be easier to share code between the groups.<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>I'm undecided if a waypoint needs a volume, a human readable name, or<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>covariance. Should the determination of the requirements for achieving<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>the waypoint be separated from the position of the waypoint.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>Ground tasks are usually something like start at A drive to within 10m<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>of B then proceed to within 20m but no closer then 2m (the waypoint is a<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>tree) of C and stop within 1m of D.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>Aerial tasks will be something like start at A pass through B with a<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>heading of 270deg magnetic and proceed to C and circle the waypoint with<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>a range of 10m-15m at an altitude of 30-40m for 10minutes before landing<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>at D 3m above sea level<br><br>> Getting those messages defined, reviewed and agreed to in time for<br>
> E-turtle sounds difficult but possible. Should they go in some<br>> common_msgs package? If so, which one?<br>><br>>  <a href="http://www.ros.org/wiki/common_msgs" target="_blank">http://www.ros.org/wiki/common_msgs</a><br>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>I think nav_msgs is the right place <a href="http://www.ros.org/wiki/nav_msgs" target="_blank">http://www.ros.org/wiki/nav_msgs</a><br>
Is gps_common fully integrated at this point?<br></div></div></div></blockquote><br>I thing having a separate GPS tools stack is best, containing gps_msgs package, gps_visualization, gps_tools, etc. Currently, nav_msgs is described as messages for interfacing with the navigation stack, which does not deal directly with GPS (at least not yet). I prefer not putting these into common_msgs or other released stack. This will allow for much faster iteration, ignoring backwards compatibility, etc while fleshing out what will go into the first release. If we put the messages into common_msgs, we are stuck with the release schedule for common_msgs. I would much prefer something like what trajectory_msgs did - started out in pr2_controllers, became useful outside of that stack and was then moved to common_msgs.<br>
 <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<br>> If there is still design and development work to do before we know<br>> what to standardize on, I suggest picking a repository and working<br>> together on a general stack for mapping-related packages. We could use<br>
> the utexas-art-ros-pkg repo for that, maybe <a href="http://ros.org" target="_blank">ros.org</a>, or some other.<br>> Perhaps it would be best to create a new repo just for this. I'll<br>> volunteer to maintain it wherever seems best and most convenient to<br>
> the participants.<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>Maybe someone at <a href="http://ros.org/wg" target="_blank">ros.org/wg</a> can setup gps-ros-pkg to hold all of the<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>packages related to GPS while we figure things out. My alternate<br>
preference would be github followed by something similar supporting svn.<br></div></div></blockquote><br><a href="http://kforge.ros.org" target="_blank">kforge.ros.org</a> would let us setup a git repo, trac, etc right (or Hg or svn), correct? If we can't get a repo hosted by WG, I vote for Github.<br>
 <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<br>> We could do both: define a standard WayPoint and WayPointID, but<br>> create a separate repo for GPS tools.<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote>I would like a separate repo for GPS tools so we cut down on duplication.<br>
I think a standard waypoint message would be nice but I'm fine if we can put it in the gps tools repo until fuerte.<br></div></div></blockquote><br>Agreed, see above.<br><br><span class="Apple-style-span" style="color: rgb(136, 136, 136); ">- Eric</span></div>
<div class="gmail_quote"><font class="Apple-style-span" color="#888888"><br></font></div><div class="gmail_quote"><font class="Apple-style-span" color="#888888">P.S. Removed all of the extra CC's, since the message got bounced originally due to having too many recipients.<br>
</font> <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>Another thing to contemplate is if there is a need for a NavSatPose message or if Pose should be used with x and y<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>set to lat and lon, or if it is better to use the navsatfix message.<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>One of the more important library functions that will need to be written is a way to request the heading<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>to a waypoint given the current position and orientation.<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br></blockquote></div></div></blockquote></div>