On Mon, Jun 13, 2011 at 9:48 AM, Eric Perko wrote: > On Mon, Jun 13, 2011 at 7:43 AM, Bill Morris > wrote: >> >> On Fri, 2011-06-03 at 21:24 -0500, Jack O'Quin wrote: >> > On Wed, Jun 1, 2011 at 5:33 PM, Chad Rockey >> > > Another possible tool would be KML import and export to >> > > waypoints/paths, >> > > since this makes it easy to visualize and create paths in Google >> > > Earth/Maps. >> > >  For our waypoints, we would define them in KML files either by >> > > clicking in >> > > Google Earth or manually typing in coordinates.  Then we could feed >> > > this to >> > > our robot which would start following them in order or we could look >> > > at the >> > > path either as markers or as a polygon in Google Earth.  Even though >> > > the >> > > imagery data could be a meter or two off, it was still very useful >> > > when >> > > great precision wasn't required or we just wanted to look at the >> > > overall >> > > shape/order. >> > > >> > > Here is an example KML path >> > > file: http://code.google.com/apis/kml/documentation/kml_tut.html#paths >> > >> > KML should definitely be considered. Good idea. >> >> I think KML should be useful as a guide and definitely a target for >> interoperability. I'm not sure kml is appropriate for everything that >> will be needed but it will be nice if we can output kml. Agreed. It is very useful for certain types of visualization. Chad proposed export and import for that format. >> > > Bill Morris morris@ee.ccny.cuny.edu writes: >> > > >> > > One of our projects this summer requires GPS based navigation for >> > > aerial >> > > robots so I'll be working on this more later in the summer. I would >> > > like >> > > to see GPS waypoints defined in E-Turtle and a gps_tools library for >> > > Fuerte. >> > >> > I could imagine defining a way-point ID as a 128-bit opaque value, >> > able to hold a UUID if desired. The basic WayPoint message would at >> > least contain an ID, latitude and longitude. Maybe that's it. Lat/Long >> > needs to be defined unambiguously, probably using fractional degrees, >> > positive North and East, negative South and West. >> >> I think that we should use ID, latitude and longitude as the initial >> definition of a waypoint so we are all on the same page. >> >> If we fix this then it will be easier to share code between the groups. >> >> I'm undecided if a waypoint needs a volume, a human readable name, or >> covariance. Should the determination of the requirements for achieving >> the waypoint be separated from the position of the waypoint. I think the basic way-point message should be fairly small and simple, because maps will contain a lot of them. We can define higher-level messages like NamedWayPoint, or WayPointWithCovariance that embed simpler messages. Similarly, I believe the basic WayPoint message should have no Header. One other WayPoint field I think we *should* add: "altitude". Unfortunately, most of the mapping databases don't include much elevation information, but I'd hate to define a bunch of interfaces that were only 2D. We need a "missing" value for altitude (NaN perhaps?). Unfortunately, messages constructors will default to 0.0, which is a perfectly valid elevation. >> Ground tasks are usually something like start at A drive to within 10m >> of B then proceed to within 20m but no closer then 2m (the waypoint is a >> tree) of C and stop within 1m of D. >> >> Aerial tasks will be something like start at A pass through B with a >> heading of 270deg magnetic and proceed to C and circle the waypoint with >> a range of 10m-15m at an altitude of 30-40m for 10minutes before landing >> at D 3m above sea level I think a WayPointTarget could contain a WayPoint and some of these other data. >> I think nav_msgs is the right place http://www.ros.org/wiki/nav_msgs >> Is gps_common fully integrated at this point? > > 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. I prefer to define a new messages package (see below). >> > If there is still design and development work to do before we know >> > what to standardize on, I suggest picking a repository and working >> > together on a general stack for mapping-related packages. We could use >> > the utexas-art-ros-pkg repo for that, maybe ros.org, or some other. >> > Perhaps it would be best to create a new repo just for this. I'll >> > volunteer to maintain it wherever seems best and most convenient to >> > the participants. >> >> Maybe someone at ros.org/wg can setup gps-ros-pkg to hold all of the >> packages related to GPS while we figure things out. My alternate >> preference would be github followed by something similar supporting svn. > > kforge.ros.org 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. > >> > We could do both: define a standard WayPoint and WayPointID, but >> > create a separate repo for GPS tools. >> >> I would like a separate repo for GPS tools so we cut down on duplication. >> 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. > > Agreed, see above. I like that approach. We don't have to release the new stack with Electric, we can develop on Electric and target Fuerte for an initial release. I recommend avoiding the GPS acronym. This stack is really about mapping, topography, and geographic navigation. The fact that the lat/long values of the way-points come from one of several navigation satellite services is a lower-level detail. I nominate "topography" as the stack name (other suggestions welcome). http://en.wikipedia.org/wiki/Topography The messages can go in a topography_msgs package, included in that stack. We could move that package to common_msgs later, if that ever makes sense. For me, the most convenient repository would be ros-pkg. I believe it should go there eventually, so we might as well work there until the new stack is ready to release. I doubt anyone at WG would oppose adding a "topography" stack (or whatever we choose to call it) to ros-pkg, as long as we commit to maintaining it and provide good documentation. (I am willing to create or maintain a different repo if y'all prefer someplace different.) >> Another thing to contemplate is if there is a need for a NavSatPose >> message or if Pose should be used with x and y >> set to lat and lon, or if it is better to use the navsatfix message. >> >> One of the more important library functions that will need to be written >> is a way to request the heading >> to a waypoint given the current position and orientation. Good point. We should keep it in mind. --  joq