Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
doc:coordinate_systems [2013/04/22 09:31] – created admindoc:coordinate_systems [2014/12/07 08:57] (current) – admin
Line 35: Line 35:
     * Costly: Also static transformations need to be continuously re-published     * Costly: Also static transformations need to be continuously re-published
     * Storing all transformations over an extended period of time (hours, days) is infeasible (but would be needed to support time-traveling and reasoning over past world states)     * Storing all transformations over an extended period of time (hours, days) is infeasible (but would be needed to support time-traveling and reasoning over past world states)
 +
  
 ===== Approach chosen in KnowRob ===== ===== Approach chosen in KnowRob =====
Line 40: Line 41:
   * By default, all coordinates are in a global coordinate system, especially all coordinates of object instances in the environment. This allows to use existing methods for spatial reasoning and visualization, and makes simple queries possible.   * By default, all coordinates are in a global coordinate system, especially all coordinates of object instances in the environment. This allows to use existing methods for spatial reasoning and visualization, and makes simple queries possible.
   * Poses can be specified relative to other poses or objects, and can also be qualified with their tf frame ID. This is mainly used when importing or exporting information and considered a rather temporary representation. There are methods to transform coordinates with respect to a reference object or into a tf frame.   * Poses can be specified relative to other poses or objects, and can also be qualified with their tf frame ID. This is mainly used when importing or exporting information and considered a rather temporary representation. There are methods to transform coordinates with respect to a reference object or into a tf frame.
 +
 +A recent addition (Summer 2014) that has not yet been integrated into all part of KnowRob offers a tf-like interface, but operates on logged transformation data stored in a MongoDB database instead of the runtime data on the /tf topic. Please have a look at the package //knowrob_mongo// for further information.
 +
 +
  
 ===== Implementation ===== ===== Implementation =====
Line 56: Line 61:
  
 ==== Truly global coordinates ==== ==== Truly global coordinates ====
-'Global coordinate' so far means 'coordinate in the robot's environment map'. There is currently no system for linking these maps to a world-global coordinate system like the [[http://en.wikipedia.org/wiki/WGS84 WGS84]] system used for [[http://en.wikipedia.org/wiki/Global_Positioning_System GPS]] localization. There are different options how this could be done, while one has to keep in mind that they should be usable by an autonomous robot without human intervention:+'Global coordinate' so far means 'coordinate in the robot's environment map'. There is currently no system for linking these maps to a world-global coordinate system like the [[http://en.wikipedia.org/wiki/WGS84|WGS84]] system used for [[http://en.wikipedia.org/wiki/Global_Positioning_System|GPS]] localization. There are different options how this could be done, while one has to keep in mind that they should be usable by an autonomous robot without human intervention:
   * Specify e.g. WGS84 coordinates: This would be the easiest to use, but requires the robot to have access to global positioning data (e.g. GPS), which is often not available in indoor environments, or to have a human manually specify these coordinates.   * Specify e.g. WGS84 coordinates: This would be the easiest to use, but requires the robot to have access to global positioning data (e.g. GPS), which is often not available in indoor environments, or to have a human manually specify these coordinates.
   * Qualitative location description: A hierarchy of town, street, house number, floor number, room number could be used to find appropriate maps.   * Qualitative location description: A hierarchy of town, street, house number, floor number, room number could be used to find appropriate maps.
  
-==== Find and select suitable maps from the RoboEarth DB ==== 
-Closely related to the previous point, this issue comes up when robots are to search for a map for the environment they are currently in. This should be possible as autonomously as possible 
-  * Search by GPS coordinate: often no GPS signal available 
-  * Search by house number/room number: only possible in public buildings where rooms are numbered, not in private homes. Possible alternative are tags like "kitchen", i.e. a hierarchy munich:80333:karlstr:45:3:3006 or munich:80333:karlstr:45:3:kitchen 
-  * Assume a hierarchy of metric and topological maps to exist: The robot is continuously localized (quantitatively or qualitatively), can detect when it runs out of one map, and can then download an extension map 
  
-In the RoboEarth project, the latter approach was chosen as a pragmatic solution that is close to the way humans describe locations. See also the page about representing [[environment map meta information]].