KnowRob basics

Installing and launching the system

If you would just like to try KnowRob, you can use the binary packages, but if you would like to experiment more and adapt the packages, you should install the source distribution. Please refer to the installation guide for instructions.

You can now launch the system using the rosprolog script which takes the name of the package to be launched as parameter. When calling a package with rosprolog, the init.pl file is loaded, and all init.pl of referenced packages as well. That procedure ensures that all packages are initialized when being loaded. For more information on how to load your own packages, have a look at the rosprolog documentation or into one of the init.pl files.

 rosrun rosprolog rosprolog knowrob

You should now see the Prolog console.

Querying the KnowRob ontology

Starting KnowRob with default configuration will auto-load a set of ontologies including DUL and SOMA. Additionally knowrob.owl in the knowrob package is loaded. You can start exploring the available classes, e.g. with

 ?- subclass_of(A, dul:'PhysicalObject'). <ENTER>
 A = dul:'BiologicalObject' ;  <SPACE>
 A = dul:'ChemicalObject' ;    <SPACE>
 A = dul:'DesignedArtifact' ;  <SPACE>
 A = dul:'DesignedSubstance' . <ENTER>

Some notes on the query syntax: Predicates in a query can be linked with a comma, denoting the logical AND, or a semicolon for the logical OR. Each query is finished with a dot (full stop). You can step through the results with the semicolon or <SPACE>, or just hit <ENTER> or <DOT> again to stop generating more results. For more information on query predicates, have a look at KnowRob's API documentation.

Before continuing with the tutorial, try to get familiar with the ontology and its main classes and properties. The best way to explore the ontology is by loading SOMA into Protege.

Loading and querying environment information

So far, we only performed reasoning on the class level. For robotic applications, it is also important to reason about instances of these classes, for example observed objects or actions. An example set of instances are the semantic maps, contained as OWL file in the knowrob_map_data package. We can parse the OWL file containing the map by using a package:// URL and the path inside the package:

 ?- tripledb_load('package://iai_semantic_maps/owl/kitchen.owl').

You can query for properties of instances using the holds(S,P,O) predicate, which retrieve all triples with matching Subject, Predicate, or Object from the knowledge base. The following query, for example, asks for all objects of type knowrob:'IAIDrawer'.

 ?- holds(A, rdf:type, knowrob:'IAIDrawer').
 A = iai_kitchen:'iai_kitchen_fridge_area_lower_drawer_main' ;
 A = iai_kitchen:'iai_kitchen_kitchen_island_left_lower_drawer_main' ;
 A = iai_kitchen:'iai_kitchen_kitchen_island_left_upper_drawer_main' ;
 [...]

For getting an overview of the information that is available about one object instance, we can query for all triples where the respective instance fills the Subject slot. In this example we pass two unbound variables P and O as arguments and receive all possible combinations of values as result.

 ?- owl_has(iai_kitchen:'iai_kitchen_kitchen_island_left_lower_drawer_main', P, O).
 P = urdf:hasBaseLinkName,
 O = kitchen_island_left_lower_drawer_main ;
 P = urdf:hasEndLinkName,
 O = kitchen_island_left_lower_drawer_handle ;
 [...]

Using the SWI Prolog tracer for debugging

In Prolog, the debugger is called “tracer”. Like a debugger in other programming languages, it allows to step through the program execution and to inspect the variable bindings. In addition, it shows the call stack of predicates, from the query to the current context, and the “choice points” that are still open. When asked a query, Prolog performs a depth-first search for solutions, starting from the query, trying to prove it from the facts in the Prolog database. Whenever there are multiple possible outcomes a predicate can have, Prolog continues with the first one, but creates a “choice point” to remember that there are still other options that have not yet been explored. If the first option did not lead to a result or if more results are to be computed, it will return to these choice points and further explore the solution space from there.

The graphical tracer is an important tool for debugging Prolog programs as it allows to follow the inference and to figure out where the execution fails. The following pages explain the process in general and list the predicates for controlling the graphical tracer.

http://www.swi-prolog.org/pldoc/man?section=debugoverview

http://www.swi-prolog.org/pldoc/man?section=debugger