no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Previous revisionNext revision | |||
— | environment_map_meta_information [2013/02/12 17:41] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Meta-information about environment maps ====== | ||
+ | ~~NOTOC~~ | ||
+ | In particular in the context of the RoboEarth project, which deals with the exchange of knowledge between robots, robots face the problem how to represent which environment is described in a map in such a way that robots can query for a map and retrieve the right one? The following approach has been chosen in the RoboEarth context: | ||
+ | * Hierarchical, | ||
+ | * These upper-level categories are described as instances (e.g. Munich as instance of City) which are linked by the transitive properPhysicalParts-relation | ||
+ | * This allows to query based on a conjunction of class restrictions, | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | There can be multiple maps describing the same environment in different ways, for example a 2D occupancy grid, used e.g. for laser-based localization, | ||
+ | |||
+ | ====== | ||
+ | The objects in the map are represented using the general spatio-temporal [[object pose representation]] used in KnowRob. This allows to incorporate more current information about the objects, e.g. updated poses, transparently by just storing the novel detections. | ||
+ | |||
+ | Articulation information is stored as a property of the respective objects. The relation between an object' | ||
+ | |||
+ | ====== | ||
+ | |||
+ | The general structure for rotational joints is the following: | ||
+ | |||
+ | * cupboard1 -- SemanticMapPerception10 -- PoseMatrix10 | ||
+ | * type Cupboard | ||
+ | * properPhysicalParts hinge1 | ||
+ | * properPhysicalParts door1 | ||
+ | * properPhysicalParts handle1 | ||
+ | |||
+ | * hinge1 -- TouchPerception11 -- PoseMatrix11 | ||
+ | * type RotationalJoint | ||
+ | * minJointValue 0.1 | ||
+ | * maxJointValue 0.9 | ||
+ | * connectedTo-Rigidly cupboard1 | ||
+ | * connectedTo-Rigidly door1 | ||
+ | * radius 0.3 | ||
+ | |||
+ | * door1 -- SemanticMapPerception12 -- PoseMatrix12 | ||
+ | * type Door | ||
+ | * properPhysicalParts handle1 | ||
+ | |||
+ | The rotation happens around the z-axis of the joint, described by the pose matrix observed by TouchPerception11 (the tactile estimation of the joint parameters). | ||
+ | |||
+ | ====== | ||
+ | |||
+ | Prismatic joints are described in a similar way, though the parameters are obviously slightly different from rotational joints: | ||
+ | |||
+ | * cupboard2 -- SemanticMapPerception20 -- PoseMatrix20 | ||
+ | * type Cupboard | ||
+ | * properPhysicalParts slider2 | ||
+ | * properPhysicalParts drawer2 | ||
+ | * properPhysicalParts handle2 | ||
+ | |||
+ | * slider2 -- TouchPerception21 -- PoseMatrix21 | ||
+ | * type PrismaticJoint | ||
+ | * minJointValue 0.0 | ||
+ | * maxJointValue 0.3 | ||
+ | * connectedTo-Rigidly cupboard2 | ||
+ | * connectedTo-Rigidly drawer2 | ||
+ | * direction dirvec2 | ||
+ | |||
+ | * drawer2 -- SemanticMapPerception22 -- PoseMatrix22 | ||
+ | * type Drawer | ||
+ | * properPhysicalParts handle2 | ||
+ | |||
+ | * dirvec2 | ||
+ | * type Vector | ||
+ | * vectorX 1 | ||
+ | * vectorY 0 | ||
+ | * vectorZ 0 | ||
+ | |||
+ | The direction of articulation of prismatic joints is explicitly described by a direction vector. | ||
+ | |||
+ | |||
+ | ====== | ||
+ | |||
+ | Query for a map that belongs a room #3001 in Munich: | ||
+ | < | ||
+ | ?- rdf_has(M, rdfs:label, literal(like(' | ||
+ | owl_has(M, knowrob: | ||
+ | owl_has(R, knowrob: | ||
+ | owl_has(R, knowrob: | ||
+ | M = ' | ||
+ | R = ' | ||
+ | Map = ' | ||
+ | </ | ||
+ | |||