Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
doc:coordinate_systems [2014/06/05 11:38] – external edit 127.0.0.1doc: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 60: Line 65:
   * 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]].