Differences

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

Link to this comparison view

Next revision
Previous revision
reason_using_computables [2012/12/01 12:58] – created tenorthreason_using_computables [2014/06/05 11:38] (current) – external edit 127.0.0.1
Line 1: Line 1:
-Computables in the knowledge representation serve for //computing// relations during the reasoning process instead of asserting them manually. This can for instance be done by querying external sources of information, or by combining the information in the knowledge base in order to create new statements. +#REDIRECT doc:reasoning_using_computables
- +
-When you wish to include answers generated by computables into the result set, you need to use //rdf_triple(Prop,Subj,Obj)// instead of //rdf_has(Subj,Prob,Obj)//, and //rdfs_instance_of(Inst,Class)// instead of //rdfs_individual_of(Inst,Class)//. These predicates will return all results their non-computable counterparts generate and, in addition to that, all results computed by any computable attached to the respective property or a sub-property of that. +
- +
-We will now present a few applications of computables - if you wish to define custom computables, please have a look at the [[Define computables | advanced tutorial]] on that topic. +
- +
-===  Qualitative spatial relations  === +
- +
-An important application of computables is to calculate qualitative spatial relations between objects, e.g. if one object is on top of, inside or below another object. Such relations can, of course, simply be asserted: +
- rdf_assert(knowrob:cup1, knowrob:'on-Physical', knowrob:table0). +
- +
-However, there are different problems with this approach: First, the number of relations between objects grows quickly as more and more objects are present in a scene, and all of these would have to be stored, even if they are never needed. Second, scenes are dynamic: Robots are supposed to interact with objects and to move them. Whenever this happens, the system would have to check which relations still hold and which ones have to be updated or retracted from the knowledge base. +
- +
-With computables, these relations can be computed when somebody queries for them based on the positions and dimensions of the objects involved. Like this, information is stored only once, and different views (like these qualitative relations) are computed from it. +
- rosmake ias_semantic_map +
- rosrun rosprolog rosprolog ias_semantic_map +
- +
-In this example, we are loading the ias_semantic_map package that provides a set of object instances, namely pieces of furniture in a kitchen. It already references the package comp_spatial which provides the computables for qualitative spatial relations. The map only consists of typed object instances at different locations. We can query for all objects that are on top of another, or for all objects that are on top of a specific object using the following queries: +
- rdf_triple(knowrob:'on-Physical', Top, Bottom). +
- rdf_triple(knowrob:'on-Physical', Top, ias_map:cupboard7). +
- +
-The computation is performed by the predicate on_Physical that is defined in the file comp_spatial.pl in the package comp_spatial. +
- +
-===  Matrix and point identifiers  === +
- +
-In order to facilitate the exchange of spatial information with other parts of the system, KnowRob supports simple matrix and point identifiers. Normally, the location and orientation of objects is described using 4x4 homography matrices, which are rather tedious to handle. Especially when reading information from remote sources, it is much more convenient to get the whole pose information using just one query in form of string that can then be split up into the respective components. +
- +
-A [[http://ias.in.tum.de/kb/api/comp_spatial|set of computables]] is provided by the module [[comp_spatial]] for translating specially formatted strings into homography matrices and for accessing their values. The same is true for points, which are related to homography matrices and to their components, and for 6x6 covariance matrices. For using these methods, the identifiers need to have the following format: +
- homography matrices: +
- rotMat3D_M00_M01_M02_M03_M10_M11_M12_M13_M20_M21_M22_M23_M30_M31_M32_M33 +
-  +
- points: +
- translation_<rotation matrix identifier> +
- +
-We can easily use these computables, e.g. with the following query that extracts the x-coordinate (value m03 of the homograpy matrix) from the matrix identifier: +
- +
- rosrun rosprolog rosprolog comp_spatial +
- rdf_triple(comp_spatial:'m03', knowrob:'rotMat3D_1_-0_0_2.31_0_1_0_3.54_0_0_1_4.76_0_0_0_1', B). +
- B = literal(type('http://www.w3.org/2001/XMLSchema#float', '2.31')) ; +
- +
-===  Reading information from external sources  === +
- +
-Examples for loading information from external sources, like other ROS nodes, are given in the following packages: +
- +
-  * comp_cop for reading information from the CoP perception system +
-  * tf_prolog reads coordinate transformations from tf +
- +
-Depending on the kind of information to be included, these interfaces need to be adapted, but the general principle should stay the same.+