On Mon, Jun 13, 2011 at 9:08 AM, Jack O'Quin wrote: > 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.) We're (very) slowly moving stack development off the unified 'ros-pkg' repository mainly due to the fact that we prefer our kforge backend to the gforge backend, but that's the only (minor) pushback on using the ros-pkg repository. - Ken >>> 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 > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >