Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
coordinate_systems [2012/12/01 14:56] – [Find and select suitable maps from the RoboEarth DB] tenorth | coordinate_systems [2014/06/05 11:38] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Coordinate system representation ====== | + | #REDIRECT doc:coordinate_systems |
- | Robots continuously have to deal with coordinate systems, and while [[http:// | + | |
- | + | ||
- | ===== Use cases ===== | + | |
- | + | ||
- | ==== Transform robot-centric information into map coordinates ==== | + | |
- | When robots detect an object and estimate its location, they usually do this in robot-centric coordinates, | + | |
- | + | ||
- | ==== Integrate different maps ==== | + | |
- | Today' | + | |
- | * transform all coordinates into a ' | + | |
- | * perform the transformation on-demand when answering a query | + | |
- | + | ||
- | ==== Instantiate an object model with object-centric coordinates ==== | + | |
- | When describing the spatial configuration of an object type, for example the positions of a hinge and a handle of a cupboard, on the level of an object class, these poses need to be relative to the object' | + | |
- | + | ||
- | ==== Export object-centric coordinates ==== | + | |
- | The opposite case is also possible, especially in the RoboEarth context: The robot has detected the different parts of an object, estimated its articulation properties, and would like to export this information to make it available to other robots. In order to be able to use this model in a different environment, | + | |
- | + | ||
- | ===== Alternatives ===== | + | |
- | Different approaches can be taken for dealing with coordinate systems: | + | |
- | - All coordinates in the same global coordinate system | + | |
- | * All coordinates in the map can easily be compared | + | |
- | * Converting all poses during query time (option 2) could be computationally expensive | + | |
- | * Comparisons can be made without reasoning about the time at | + | |
- | - Coordinates in several local coordinate systems | + | |
- | * Dependencies between coordinates become more explicit, which is especially useful for articulated objects: When the door of a cupboard is opened, the global pose of the handle is changed, while its local pose relative to the cupboard remains the same. | + | |
- | * One needs to distinguish between static relative transformations (cupboard door -- handle) and dynamic ones (robot base -- object pose); the latter become invalid if the reference object has moved. | + | |
- | - static transformations between the systems | + | |
- | * Rather simple: | + | |
- | * Problems with changing transformations when objects are moved | + | |
- | - continuously updated transformations (e.g. [http:// | + | |
- | * Flexible: relative coordinates get updated if reference object has moved | + | |
- | * 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) | + | |
- | + | ||
- | ===== Approach chosen in KnowRob ===== | + | |
- | We tried to find a solution that (1) is compatible to existing components, (2) can be optionally loaded, but is not required for the whole system, and (3) is as simple and flexible as possible. The result is a combination of the alternatives mentioned above: | + | |
- | * 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, | + | |
- | * 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. | + | |
- | + | ||
- | ===== Implementation ===== | + | |
- | The code for transforming coordinates is contained in the package knowrob_objects in the file knowrob_coordinates.pl. Prolog-bindings to the tf library are provided by the package tf_prolog. | + | |
- | + | ||
- | * **instantiate_at_position(+ObjClassDef, | + | |
- | + | ||
- | * **pose_into_global_coord(+RelativePose, | + | |
- | * ReferencePose4d bound: transform into parent coordinate system of ReferencePose4d | + | |
- | * ReferencePose4d unbound, but poseRelativeTo set: use the specified relative pose as reference | + | |
- | * ReferencePose4d unbound, but tfFrame set: use tf to convert the coordinates into the /map frame | + | |
- | + | ||
- | * **pose_into_relative_coord(+GlobalPose, | + | |
- | + | ||
- | ===== Limitations/ | + | |
- | + | ||
- | ==== Truly global coordinates ==== | + | |
- | ' | + | |
- | * Specify e.g. WGS84 coordinates: | + | |
- | * Qualitative location description: | + | |
- | + | ||
- | ==== 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 " | + | |
- | * Assume a hierarchy of metric and topological maps to exist: The robot is continuously localized (quantitatively or qualitatively), | + | |
- | + | ||
- | 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]]. | + |