This is an old revision of the document!


Create and load a semantic map

Semantic maps are descriptions of an environment in terms of localized object instances and are stored in OWL files. There are different ways how to create such a file:

  • The Semantic Map Editor is a graphical editor for semantic maps. It can be used to create object instances and to set their positions.
  • If you already have a map datastructure and would like to create a semantic map from your program, you can use the SemanticMapToOWL ROS service.
  • If you have integrated a perception system into KnowRob, a kind of semantic map is automatically created by the objects the robot perceives. You can save the in-memory map to an OWL file using the methods in the owl_export module
  • In some cases, it may actually be the fastest to create the map manually in a good text editor in which you can copy and paste the object instances and their pose matrices. If you plan to do this, you should have well understood how object poses are represented in KnowRob.

SemanticMapToOWL

If you have the information for the semantic map available in your program, the easiest way to get a valid OWL file is probably to use the SemanticMapToOWL ROS service described here: http://ias.in.tum.de/kb/wiki/index.php/Mod_semantic_map#SemanticMapToOWL If you do not want to use the service, you can still have a look at how the OWL is generated using the OWLAPI, but since the internal object representation is quite a complex thing, I'd recommend to start with that service.

The object type that you get from the perception system indeed corresponds to the object class in KnowRob. If the identifiers do not match, you need to create a mapping at some point; if you use the conversion service, the easiest place would be to have the mapping in your code for now. You can get a list of all object classes in KnowRob using the following command:

$ rosrun mod_semantic_map SemanticMapToOWL list

The visualization module only supports a subset of these classes. We currently have two ways to define how an item is to be visualized: the legacy version used custom Java classes that draw the item to the visualization, see here:

$ roscd mod_vis/src/de/tum/in/fipm/kipm/gui/visualisation/items

We are currently switching to a more flexible system based on CAD models (e.g. Collada). To make this work, you need to specify the path to the model as a property of the respective instance or class, see the lower part of this file for an example:

knowrob_cad_models/owl/knowrob_cad_models.owl.in