Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:writing_an_interface_to_your_perception_system [2014/11/27 12:11] – [Setting up the perception tutorial] admindoc:writing_an_interface_to_your_perception_system [2014/11/27 15:24] (current) – [KnowRob integration] admin
Line 1: Line 1:
 ====== Write an interface to your perception system ====== ====== Write an interface to your perception system ======
 +~~NOTOC~~
 +\\
 +^ This page describes the 'catkinized' version of KnowRob that uses the [[http://wiki.ros.org/catkin/|catkin buildsystem]] and the pure Java-based [[http://wiki.ros.org/rosjava|rosjava]]. The documentation for the older version, which was based on the rosbuild buildsystem and rosjava_jni, can be found [[/doc/writing_an_interface_to_your_perception_system?rev=1417090277|here]].^
 +\\
  
 There are two main approaches how perception can be performed: Some perception algorithms continuously detect objects and output the results (in ROS terminology: publish the results on a topic), others perform recognition only on demand (in ROS: by calling a service). These two kinds of systems need to be interfaced in different ways: The former requires a topic listener that records the published object detections and adds them to the knowledge base, the latter can be interfaced by computables that trigger the perception procedure when a query involves the respective information. There are two main approaches how perception can be performed: Some perception algorithms continuously detect objects and output the results (in ROS terminology: publish the results on a topic), others perform recognition only on demand (in ROS: by calling a service). These two kinds of systems need to be interfaced in different ways: The former requires a topic listener that records the published object detections and adds them to the knowledge base, the latter can be interfaced by computables that trigger the perception procedure when a query involves the respective information.
Line 10: Line 14:
 ====== Setting up the perception tutorial ====== ====== Setting up the perception tutorial ======
  
-The knowrob_perception tutorial is part of the knowrob_tutorials repository. You need to check it out into your ROS workspace (i.e. into a directory that is part of your ROS_PACKAGE_PATH). +The knowrob_perception tutorial is part of the knowrob_tutorials repository. You need to check it out into your catkin workspace and compile it using catkin_make
-https://github.com/knowrob/knowrob_tutorials.git +<code bash> 
-<code>+cd /path/to/catkin_ws/src
 git clone https://github.com/knowrob/knowrob_tutorials.git git clone https://github.com/knowrob/knowrob_tutorials.git
 +cd /path/to/catkin_ws
 +catkin_make
 </code> </code>
  
-After the checkoutyou should be able to ''roscd'' into the knowrob_perception directory and to ''rosmake'' the packageIf the 'roscd' command does not change your working directory to the knowrob_perception directory, please check your ROS configuration (e.g. make sure knowrob_perception is part of the ROS_PACKAGE_PATH), because otherwise the following steps will fail as wellBoth commands should work without any error messages. +Since a large part of the tutorial is written in Javait is recommended to set up an Eclipse project and to inspect and edit the Java files from thereYou can generate the Eclipse project files using the following command and then only need to create a new "Java Project" for that directory inside EclipseThe classpath will then already be set up to include all dependencies of the knowrob_perception_tutorial package
- +<code bash
-<code> +./gradlew eclipse
-roscd knowrob_perception +
-rosmake+
 </code> </code>
 ====== Interfacing topic-based perception systems ====== ====== Interfacing topic-based perception systems ======
Line 26: Line 30:
 ===== Publisher ===== ===== Publisher =====
  
-The file src/edu/tum/cs/ias/knowrob/tutorial/DummyPublisher.java implements a simple dummy publisher that simulates a perception system that regularly detects objects and publishes these detections on the /dummy_object_detections topic once a second. Try to understand how these detections are generated by the generateDummyObjectDetection() method. You can start the publisher using+The file src/edu/tum/cs/ias/knowrob/tutorial/DummyPublisher.java implements a simple publisher of object detections. It simulates a perception system that regularly detects objects and publishes these detections on the /dummy_object_detections topic once a second. Try to understand how these detections are generated by looking at the generateDummyObjectDetection() method. You can start the publisher using
 <code> <code>
 rosrun knowrob_perception_tutorial dummy_publisher rosrun knowrob_perception_tutorial dummy_publisher
Line 58: Line 62:
 ===== Subscriber ===== ===== Subscriber =====
  
-The counterpart on the client side that consumes the object detections is implemented in the file ''src/edu/tum/cs/ias/knowrob/tutorial/DummySubscriber.java''. The subscriber has been realized using two threads: The ''listenToObjDetections'' thread subscribes to the topic and puts the incoming messages into the ''callback'' queue. The ''updateKnowRobObjDetections'' thread processes all object detections in this queue and creates the corresponding representations in KnowRob. The rationale behind this setup is to keep the subscriber thread as light-weight as possible to avoid problems of missing messages when the program is occupied updating the knowledge base. While the creation of an object detection in KnowRob is quite fast, this structure is crucial if the processing becomes more complex.+The counterpart on the client side that consumes the object detections is implemented in the file ''src/edu/tum/cs/ias/knowrob/tutorial/DummySubscriber.java''. The subscriber uses two threads: The main thread subscribes to the topic and puts the incoming messages into the ''detections'' queue. The ''updateKnowRobObjDetections'' thread processes all object detections in this queue and creates the corresponding representations in KnowRob. The rationale behind this setup is to keep the subscriber thread as light-weight as possible to avoid problems of missing messages when the program is occupied updating the knowledge base. While, in this case, the creation of an object detection in KnowRob is quite fast, this two-thread structure is crucial once the processing becomes more complex.
  
-The following code snippet is the main part of the ''updateKnowRobObjDetections'' thread. It pops the an ''ObjectDetection'' message from the ''callback'' queue, converts the pose quaternion into a 4x4 pose matrix and calls the ''create_object_perception'' predicate.+The following code snippet is the main part of the ''updateKnowRobObjDetections'' thread. It pops an ''ObjectDetection'' message from the ''detections'' queue, converts the pose quaternion into a 4x4 pose matrix and calls the ''create_object_perception'' predicate.
  
-<code> +<code java
-  while (n.isValid()) {+node.executeCancellableLoop(new CancellableLoop() 
 + 
 +  @Override 
 +  protected void loop(throws InterruptedException {
  
-    obj = callback.pop();+    ObjectDetection obj = detections.take();
  
-    Matrix4d p = quaternionToMatrix(obj.pose.pose);         +    Matrix4d p = quaternionToMatrix(obj.getPose().getPose());
     String q = "create_object_perception(" +     String q = "create_object_perception(" +
-          "'http://ias.cs.tum.edu/kb/knowrob.owl#"+obj.type+"', ["  +                      "'http://knowrob.org/kb/knowrob.owl#"+obj.getType()+"', [" 
-          + p.m00 + ","+ p.m01 + ","+ p.m02 + ","+ p.m03 + "," +                      + p.m00 + ","+ p.m01 + ","+ p.m02 + ","+ p.m03 + "," 
-          + p.m10 + ","+ p.m11 + ","+ p.m12 + ","+ p.m13 + "," +                      + p.m10 + ","+ p.m11 + ","+ p.m12 + ","+ p.m13 + "," 
-          + p.m20 + ","+ p.m21 + ","+ p.m22 + ","+ p.m23 + "," +                      + p.m20 + ","+ p.m21 + ","+ p.m22 + ","+ p.m23 + "," 
-          + p.m30 + ","+ p.m31 + ","+ p.m32 + ","+ p.m33 + +                      + p.m30 + ","+ p.m31 + ","+ p.m32 + ","+ p.m33 + 
-          "], ['DummyObjectDetection'], ObjInst)";+                      "], ['DummyObjectDetection'], ObjInst)";
  
     PrologInterface.executeQuery(q);     PrologInterface.executeQuery(q);
-    n.spinOnce(); 
   }   }
 +});
 </code> </code>
  
 +This predicate from the knowrob_perception package is defined as below. It creates a new object instance for the given object type (''rdf_instance_from_class''), creates an instance describing the perception event using the ''PerceptionTypes'' given as argument, links the object instance to this perception event, and sets the pose at which the object was detected. This convenience predicate assumes that the detected objects are always novel. By calling the different predicates individually, one can also add perception events to existing objects instances if the identity of the object instance is known.
  
-This predicate, defined in the knowrob_perception package, is defined as below. It creates a new object instance for the given object type (''rdf_instance_from_class''), creates an instance describing the perception event using the ''PerceptionTypes'' given as argument, links the object instance to this perception event, and sets the pose at which the object was detected. This convenience predicate assumes that the detected objects are always novel. By calling the different predicates individually, one can also add perception events to existing objects instances if the identity of the object instance is known. +<code prolog>
- +
-<code>+
 create_object_perception(ObjClass, ObjPose, PerceptionTypes, ObjInst) :- create_object_perception(ObjClass, ObjPose, PerceptionTypes, ObjInst) :-
     rdf_instance_from_class(ObjClass, ObjInst),     rdf_instance_from_class(ObjClass, ObjInst),
Line 96: Line 102:
 Whenever the subscriber is started, it creates the KnowRob-internal representations for all object detections that are received via the topic. It can be run from Prolog via the [[http://www.swi-prolog.org/packages/jpl/|JPL Java-Prolog interface]] as defined in prolog/perception_tutorial.pl: Whenever the subscriber is started, it creates the KnowRob-internal representations for all object detections that are received via the topic. It can be run from Prolog via the [[http://www.swi-prolog.org/packages/jpl/|JPL Java-Prolog interface]] as defined in prolog/perception_tutorial.pl:
  
-<code>+<code prolog>
 obj_detections_listener(Listener) :- obj_detections_listener(Listener) :-
-  jpl_new('edu.tum.cs.ias.knowrob.tutorial.DummySubscriber', ['knowrob_tutorial_listener'], Listener), +  jpl_new('org.knowrob.tutorials.DummySubscriber', [], Listener), 
-  jpl_call(Listener, 'startObjDetectionsListener', [], _).+  jpl_list_to_array(['org.knowrob.tutorials.DummySubscriber'], Arr), 
 +  jpl_call('org.knowrob.utils.ros.RosUtilities', runRosjavaNode, [Listener, Arr], _).
 </code> </code>
  
-If the dummy publisher is runningthe following sequence of commands starts the topic listener, queries for object instances and their poses.+To start a rosjava node from KnowRob, you first need to instantiate the class containing the node definition, create an array with the fully-qualified class name, and pass it to the ''runRosjavaNode'' method. After starting the dummy publisher in another terminalyou can start KnowRob, create the topic listener, and query for object instances and their poses.
  
-<code>+<code prolog>
 ?- obj_detections_listener(L). ?- obj_detections_listener(L).
-L = @'J#00000000000173056232'. +L = @'J#00000000000034668496
-Attaching 0x8afd1010+% ... several rosjava INFO messages ...
  
-<wait for a few seconds...>+wait for a few seconds...
  
 ?- owl_individual_of(A, knowrob:'HumanScaleObject'). ?- owl_individual_of(A, knowrob:'HumanScaleObject').
-A = 'http://ias.cs.tum.edu/kb/knowrob.owl#Cup_vUXiHMJy' ; +A = knowrob:'Cup_uGmuwKPo' ; 
-A = 'http://ias.cs.tum.edu/kb/knowrob.owl#Cup_bneXbLGX' ; +A = knowrob:'DrinkingBottle_TaVWzXre' ; 
-A = 'http://ias.cs.tum.edu/kb/knowrob.owl#DinnerFork_TaVWzXre'+A = knowrob:'DrinkingBottle_rMsqkRjP'
 +A = knowrob:'DinnerFork_tDjYwuhx'
  
-?- current_object_pose('http://ias.cs.tum.edu/kb/knowrob.owl#DinnerFork_TaVWzXre', P).+?- current_object_pose(knowrob:'DinnerFork_tDjYwuhx', P).
 P = [1.0,0.0,0.0,2.9473,0.0,1.0,0.0,2.6113,0.0,0.0,1.0,0.2590,0.0,0.0,0.0,1.0]. P = [1.0,0.0,0.0,2.9473,0.0,1.0,0.0,2.6113,0.0,0.0,1.0,0.2590,0.0,0.0,0.0,1.0].
 </code> </code>
Line 124: Line 132:
 ===== Perception service ===== ===== Perception service =====
  
-The dummy perception service is very similar to the dummy publisher. Whenever a request for an object detection is received, it responds with a simulated detection of a random object type at a random pose. In real scenarios, the request will probably not be empty, but specify properties of the perception method to be used. The code of the dummy service can be found in the file src/edu/tum/cs/ias/knowrob/tutorial/DummyService.java. It can be started with the following command:+The dummy perception service is very similar to the dummy publisher. Whenever a request for an object detection is received, it responds with a simulated detection of a random object type at a random pose. In the example, the 'request' part of the service is empty -- in real scenarios, the request will often specify properties of the perception method to be used. The code of the dummy service can be found in the file src/edu/tum/cs/ias/knowrob/tutorial/DummyService.java. It can be started with the following command:
 <code> <code>
 rosrun knowrob_perception_tutorial dummy_service rosrun knowrob_perception_tutorial dummy_service
Line 137: Line 145:
 ===== KnowRob integration ===== ===== KnowRob integration =====
  
-While the service client is much simpler than the topic listener, the integration with KnowRob is a bit more complex. The reason is that the service call needs to be actively triggered, while the topic listener just runs in the background in a separate thread. This means that the inference needs to be aware of the possibility of acquiring information about object detections by calling this service. Such functionality can be realized using [[doc/defining_computables|computables]] that describe for an OWL class or property how individuals of this class or values of this property can be computed. To better understand the following steps, it is recommended to have completed the [[doc/defining_computables|tutorial on defining computables]]. +While the Java side of the service client is much simpler than the topic listener, the integration with KnowRob is a bit more complex. The reason is that the service call needs to be actively triggered, while the topic listener just runs in the background in a separate thread. This means that the inference needs to be aware of the possibility of acquiring information about object detections by calling this service. Such functionality can be realized using [[doc/defining_computables|computables]] that describe for an OWL class or property how individuals of this class or values of this property can be computed. To better understand the following steps, it is recommended to have completed the [[doc/defining_computables|tutorial on defining computables]]. 
  
 In a first step, we need to implement a Prolog predicate that performs the service call, processes the returned information, adds it to the knowledge base, and returns the identifiers of the detected object instances. This predicate is implemented in prolog/perception_tutorial.pl. In contrast to topic-based example above, which performed most processing in Java, this example shows how more of the processing can be done in Prolog: In a first step, we need to implement a Prolog predicate that performs the service call, processes the returned information, adds it to the knowledge base, and returns the identifiers of the detected object instances. This predicate is implemented in prolog/perception_tutorial.pl. In contrast to topic-based example above, which performed most processing in Java, this example shows how more of the processing can be done in Prolog:
  
-<code>+<code prolog>
 comp_object_detection(ObjInst, _ObjClass) :- comp_object_detection(ObjInst, _ObjClass) :-
  
   % Call the DetectObject service for retrieving a new object detection.   % Call the DetectObject service for retrieving a new object detection.
   % The method returns a reference to the Java ObjectDetection message object   % The method returns a reference to the Java ObjectDetection message object
-  jpl_call('edu.tum.cs.ias.knowrob.tutorial.DummyClient', 'callObjDetectionService', [], ObjectDetection),+  jpl_new('org.knowrob.tutorials.DummyClient', [], Client), 
 +  jpl_list_to_array(['org.knowrob.tutorials.DummyClient']Arr), 
 +  jpl_call('org.knowrob.utils.ros.RosUtilities', runRosjavaNode, [Client, Arr], _),
  
- +  jpl_call(Client, 'callObjDetectionService', [], ObjectDetection),
-  % Read information from the ObjectDetection object+
  
   % Read type -> simple string; combine with KnowRob namespace   % Read type -> simple string; combine with KnowRob namespace
-  jpl_get(ObjectDetection, 'type', T), +  jpl_call(ObjectDetection, 'getType', [], T), 
-  atom_concat('http://ias.cs.tum.edu/kb/knowrob.owl#', T, Type), +  atom_concat('http://knowrob.org/kb/knowrob.owl#', T, Type),
- +
- +
-  % Read pose -> convert from quaternion to pose list +
-  jpl_get(ObjectDetection, 'pose', PoseStamped), +
-  jpl_get(PoseStamped, 'pose', PoseQuat),+
  
-  jpl_call('edu.tum.cs.ias.knowrob.tutorial.DummyClient', 'quaternionToMatrix', [PoseQuat], PoseMatrix),+  % Convert the pose into a rotation matrix 
 +  jpl_call(ObjectDetection, 'getPose', [], PoseMatrix),
   knowrob_coordinates:matrix4d_to_list(PoseMatrix,PoseList),   knowrob_coordinates:matrix4d_to_list(PoseMatrix,PoseList),
  
Line 170: Line 175:
 </code> </code>
  
-The predicate first calls the static ''callObjDetectionService'' method in the ''DummyClient'' class and receives an ''ObjectDetection'' object as result. It then reads its member variables (type, pose) and converts them from a quaternion into a pose matrix and into a Prolog list as row-based matrix representation. In the end, it calls the same ''create_object_perception'' predicate that was also used in the previous example.+The predicate first calls the static ''callObjDetectionService'' method in the ''DummyClient'' class and receives an ''ObjectDetection'' object as result. It then reads its member variables (type, pose) and converts them from a quaternion into a pose matrix and into a Prolog list as row-based matrix representation. In the end, it calls the same ''create_object_perception'' predicate that was also used in the previous example. This predicate can be used to manually query the perception service from Prolog (assuming the perception service is running in another terminal):
  
-This predicate can be used to manually query the perception service from Prolog (assuming the perception service is running in another terminal): +<code prolog>
-<code>+
 rosrun rosprolog rosprolog knowrob_perception_tutorial rosrun rosprolog rosprolog knowrob_perception_tutorial
 ?- comp_object_detection(Obj, _). ?- comp_object_detection(Obj, _).
Line 179: Line 183:
 </code> </code>
  
-Such a manual query requires that the user is aware of the existence of this service. It also requires adaptation of the query whenever the context changes, e.g. when different or multiple recognition systems are used. We can avoid these problems by wrapping the predicate into a computable; with this definition, the predicate will automatically be called whenever the user asks for an object pose and when the service interface is available. The following OWL code defines a computable Prolog class for the example predicate:+Such a manual query however requires the user to know of the existence of this service. It also requires adaptation of the query whenever the context changes, e.g. when different or multiple recognition systems are used. We can avoid these problems by wrapping the predicate into a //computable//. With this definition, the predicate will automatically be called whenever the user asks for an object pose as long as the service interface is available. The following OWL code defines a computable Prolog class for the example predicate:
  
-<code>+<code xml>
 <computable:PrologClass rdf:about="#computeObjectDetections"> <computable:PrologClass rdf:about="#computeObjectDetections">
     <computable:command rdf:datatype="&xsd;string">comp_object_detection</computable:command>     <computable:command rdf:datatype="&xsd;string">comp_object_detection</computable:command>
Line 190: Line 194:
 </code> </code>
  
-Instead of calling the service directly, we can now query for object poses and obtain -- in addition to already known poses from e.g. a semantic map -- the poses generated by our service:+Instead of calling the service directly, we can now query for object poses and obtain the poses generated by our service in addition to other object poses that have already been in the knowledge base, e.g. in a semantic map:
 <code> <code>
 ?- rdfs_instance_of(A, knowrob:'HumanScaleObject'). ?- rdfs_instance_of(A, knowrob:'HumanScaleObject').
-A = 'http://ias.cs.tum.edu/kb/knowrob.owl#TableKnife_vUXiHMJy'.+A = knowrob:'TableKnife_vUXiHMJy'.
 </code> </code>