micpalmia's profile - activity

After taking some time to acquaint myself with the KnowRob system, I'm now in the process of writing my own modules using its functionalities. As a simple starting point, I just want to write an action recipe telling my robot to get to the middle of the room (x=0.00, y=0.00), then just move to another point in the map (x=3.00, y=3.00).

I'm using the move_base module for navigation, and the robot is simulated in an empty room (no semantic map is needed as the space is empty).

CPL is not something I want to look into right now, as my time is limited and I think that system would add a layer of complexity that I don't need right now. I know that the KnowRob team has done experiments using action recipes in the past without using CPL and the cogito system.

In order to implement a working application, I decided to extend the KnowRob ontology with data about action execution on one hand, and to write a simple python module to query the prolog system to actually move the robot on the other hand.

This is the core of my extension to the ontology

> <owl:Class rdf:about="&move;GoToPoint">
>     <rdfs:subClassOf rdf:resource="&knowrob;Translation-LocationChange"/>
>     <rdfs:subClassOf>
>         <owl:Class>
>             <owl:intersectionOf rdf:parseType="Collection">
>                 <owl:Restriction> 
>                     <owl:onProperty rdf:resource="&move;providedByMotionPrimitive"/>
>                     <owl:hasValue rdf:resource="&move;move_base" />
>                 </owl:Restriction>
>                 <owl:Restriction> 
>                     <owl:onProperty rdf:resource="&move;destXValue"/>
>                     <owl:cardinality rdf:datatype="&xsd;decimal">1</owl:cardinality>
>                 </owl:Restriction>
>                 <owl:Restriction> 
>                     <owl:onProperty rdf:resource="&move;destYValue"/>
>                     <owl:cardinality rdf:datatype="&xsd;decimal">1</owl:cardinality>
>                 </owl:Restriction>
>             </owl:intersectionOf>
>         </owl:Class>
>     </rdfs:subClassOf> </owl:Class>

I added a MotionPrimitive class, of which move_base is a subclass. Each motion primitive provides a providedByROSAction property: a string containing the name of the appropriate ROS actionlib server. My action recipe is thus simply composed as an intersection of various GoToPoint restrictions.

The robot connects to json_prolog and, on being asked to perform the task, asks for

plan_subevents(move:'MovementTest', SEs)

then queries for the appropriate action primitives and, if it is aware of them, queries for the needed parameters and calls the corresponding servers.

I implemented this approach and it works just fine. I know there are a few minor things that should be fixed (e.g. in the ontology points in space should be represented as properties of a PointInSpace class) but I'm afraid about a major issue that this implementation brings up. Mainly, maintaining both the ontology and the robot executor might become very difficult with the number of action servers getting big. It would obviously be also very prone to errors, as the developers would have to both update one and the other, in two different languages.

Am I proceeding in the right direction with this implementation structure? Am I missing something big? Should I use some other built-in feature I didn't see/notice?

sry, didn't take the time to fully understand this. got it, works fine.

I guess the edit has to be made in the `init.pl` file, not the `init.pl.in` file. If I edit the latter (or clone the package from github as it is now) the problem is not solved.

Turns out that if I use the whole class name, without abbreviating with the shortened namespace, everything works. Not sure how I should specify the namespace in prolog anyway.

I'm trying to follow the tutorial on reasoning about actions on the KnowRob website.

As suggested in the tutorial, I execute

$ roscd knowrob_basics_tutorial
$ rosrun rosprolog rosprolog knowrob_basics_tutorial
?- owl_parse('owl/pancake-making.owl', false, false, true).

and get a very hopeful

true.

I then proceed with

?- class_properties(pancake:'MakingPancakes', knowrob:subAction, Sub).

that unfortunately answers with

ERROR: namespace `pancake' does not exist
^  Exception: (11) setup_call_catcher_cleanup('$expand':'$set_source_module'(user, user), '$expand':expand_goal(class_properties(pancake:'MakingPancakes', knowrob:subAction, _G239), _G303, user, [user, system]), _G373, '$expand':'$set_source_module'(_G328, user)) ?

The namespace is correctly included in the OWl file

<rdf:RDF
    xmlns         ="&pancake;"
    xmlns:pancake ="&pancake;"
    xml:base      ="&pancake;"
    xmlns:knowrob ="&knowrob;"
    [...] >

so it's really hard for me to understand what's going on. How do I ensure the pancake namespace is correctly included? Is there a way for me to print out all the namespaces?

My Gazebo model, written in Xacro, makes use of an Hokuyo laser scanner through the libgazebo_ros_laser.so plugin. Even though I specified a value for the frameName property, this plugin doesn't automatically publishes a transform from base_link to the frame I just specified. As the planar controller is automatically publishing the transformation of odom to base_link, I cannot understand why the laser scanner controller is not doing so.

I tried to manually specify a static transform publisher and everything seems to work, apart for the fact that when I try to visualize the scanner data in rviz, it flickers between the position it was in before I specified the transform and the one in which I _transported_ it. They only differ a tiny little, but it is enough to notice, and I definitely don't think it is something healthy for my system.

I think it's something related to the difference in frequency between the transform publication and the laser data publication, but even setting both to 40ms nothing changes. I also cannot understand how rviz establishes how to display the laser data if I don't specify any transformation (because yes, it does).

Any news about this? I get the same error. I guess the problem is some missing dependency in knowrob_basics_tutorial, as the same function works running mod_vis in rosprolog.

There is an extensive tutorial article on the Gazebo wiki about a lot of different sensors plugins, including libgazebo_ros_camera.so, you might want to give a look there. Sorry for the broken link but there seems to be a rule about needing 'karma' to post links. Didn't help enough old ladies crossing the strees lately.

gazebosim.org/wiki/Tutorials/1.9/ROS_Motor_and_Sensor_Plugins

Here is the use for the camera plugin proposed there

 <!-- camera -->
  <gazebo reference="camera_link">
    <sensor type="camera" name="camera1">
      <update_rate>30.0</update_rate>
      <camera name="head">
        <horizontal_fov>1.3962634</horizontal_fov>
        <image>
          <width>800</width>
          <height>800</height>
          <format>R8G8B8</format>
        </image>
        <clip>
          <near>0.02</near>
          <far>300</far>
        </clip>
        <noise>
          <type>gaussian</type>
          <!-- Noise is sampled independently per pixel on each frame.  
               That pixel's noise value is added to each of its color
               channels, which at that point lie in the range [0,1]. -->
          <mean>0.0</mean>
          <stddev>0.007</stddev>
        </noise>
      </camera>
      <plugin name="camera_controller" filename="libgazebo_ros_camera.so">
        <alwaysOn>true</alwaysOn>
        <updateRate>0.0</updateRate>
        <cameraName>rrbot/camera1</cameraName>
        <imageTopicName>image_raw</imageTopicName>
        <cameraInfoTopicName>camera_info</cameraInfoTopicName>
        <frameName>camera_link</frameName>
        <hackBaseline>0.07</hackBaseline>
        <distortionK1>0.0</distortionK1>
        <distortionK2>0.0</distortionK2>
        <distortionK3>0.0</distortionK3>
        <distortionT1>0.0</distortionT1>
        <distortionT2>0.0</distortionT2>
      </plugin>
    </sensor>
  </gazebo>

There are a number of different issues involved in running the roboearth_stack package on ROS Groovy. I wrote down the solution to most of them here, and even though it might not be complete, it should address quite a lot of the known problems.