zsaigol's profile - activity

Hi @gleb, the node doesn't really do anything - it just prints out the pose of the robot, as calculated in 3 different ways (as described above). You just run up Gazebo with the simulated Turtlebot, start this node, and it should print stuff out. Haven't tested with newer ROS versions, though.

@Mani, sorry I didn't. First project requirements made using ardrone_autonomy a lower priority, and then the whole project ended.

Thanks Mani, that is very helpful. I'll let you know how I get on.

The installation instructions for tum_ardrone say a modified version of ardrone_autonomy is needed, and this can be installed from https://github.com/tum-vision/ardrone... . However, this is a rosbuild package, and therefore the (catkinized) current tum_ardrone package cannot depend on it (see http://wiki.ros.org/catkin/migrating_... ).

What was changed for this modified version? Should I:

1. Use the Ubuntu package for ardrone_autonomy (I'm on Hydro)
2. Install ardrone_autonomy from its GitHub repo
3. Try to Catkinize the modified code...

I'm using Hydro on Ubuntu 12.04, but I suspect the same issue will apply to more up-to-date distros.

Just to note Moritz has now produced a Catkinized version - see http://www.knowrob.org/blog/catkinize... and http://www.knowrob.org/installation/c...

I've installed the new catkinized KnowRob under Hydro, following the instructions and the very useful migration guide, and everything seems to be working.

However I had a couple of minor issues with dependencies: first, rosdep doesn't seem to install dependencies recursively, so some were missed (e.g. see http://answers.ros.org/question/84616... ).

I suggest instead of doing

rosdep install --ignore-src knowrob

you can use

rosdep install --ignore-src --from-paths stacks/

Secondly, a few packages are referenced in knowrob_addons but aren't present in the git repo, specifically:

• knowrob_motion_constraints missing knowrob_mesh_reasoning
• semantic_map_to_owl missing semantic_map_to_owl_msgs
• knowrob_cad_models missing iai_cad_tools (for iai_cad_downloader -- which I tried installing, but then it seemed to need access to a private SVN repository)

To help anyone else trying to debug this, I thought I'd post my node that prints out the robot's pose from 3 sources:

1. The Gazebo model which I think is the ground truth, via topic /gazebo/model_states
2. The odometry published by Gazebo
3. The robot pose published by gmapping

While there may not be any noise added to Gazebo's odometry, it isn't simply publishing the ground truth, as you can see if you drive the robot into a wall for a bit.

#include <ros/ros.h>
#include <tf/transform_listener.h>
#include <geometry_msgs/Pose.h>
#include <gazebo_msgs/ModelStates.h>

tf::TransformListener * listener;
bool received_gazebo_message = false;
geometry_msgs::Pose model_pose;

void receivedGazeboMessage(const gazebo_msgs::ModelStatesPtr& model_states)
{
    if (!received_gazebo_message)
    {
        std::cout << "Gazebo model info received!" << std::endl;
    }
    for (unsigned int i = 0; i < model_states->name.size(); ++i)
    {
        if (model_states->name[i] == "mobile_base")
        {
            model_pose = model_states->pose[i];
            received_gazebo_message = true;
            break;
        }
    }
}

void printPoses(const ros::TimerEvent&)
{
    if (received_gazebo_message)
    {
        tf::StampedTransform odom_transform;
        tf::StampedTransform gmap_transform;
        try
        {
            listener->lookupTransform("/odom", "/base_footprint", ros::Time(0), odom_transform);
            listener->lookupTransform("/map", "/base_footprint", ros::Time(0), gmap_transform);
        }
        catch (tf::TransformException & ex)
        {
            ROS_ERROR("%s", ex.what());
            return;
        }
        std::cout << std::setiosflags(std::ios::fixed) << std::setprecision(3);
        std::cout << "* at " << odom_transform.stamp_.toSec() << ":" << std::endl;

        std::cout << "Model: " << model_pose.position.x << ", " << model_pose.position.y <<
                " / " << tf::getYaw(model_pose.orientation) << std::endl;
        std::cout << "Odom : " << odom_transform.getOrigin()[0] << ", " <<
                odom_transform.getOrigin()[1] <<
                " / " << tf::getYaw(odom_transform.getRotation()) << std::endl;
        std::cout << "Gmapg: " << gmap_transform.getOrigin()[0] << ", " <<
                gmap_transform.getOrigin()[1] <<
                " / " << tf::getYaw(gmap_transform.getRotation()) << std::endl;
    }
}

int main(int argc, char** argv)
{
    ros::init(argc, argv, "pose_printer");
    ros::NodeHandle n;
    listener = new tf::TransformListener();

    ros::Subscriber gazebo_ground_truth_sub =
                n.subscribe("/gazebo/model_states", 1, &receivedGazeboMessage);
    ros::Timer timer1 = n.createTimer(ros::Duration(1.0), printPoses);

    ros::spin();
    return 0;
}

Thanks for this clarification, jorge. I had thought the TB2 odometry drifted a bit, as I tried comparing 'tf_echo /odom /base_footprint' to the 'mobile_base' pose from topic /gazebo/model_states, but the discrepancy is tiny and may not really be increasing (2 cm after 10 mins).

@bvbdort - I'm happy that disabling the scan matching fixes the problem, thanks anyway.

@jorge - the second question I'm not 100% sure of is: 2) Does keeping noise non-zero in the gmapping parameters mean we get a more accurate localisation even when the scan-matcher is effectively disabled? Yes, i.e. gmapping still chooses the best particle.

@jorge - I mostly just meant this post to help people out. Regarding the motion model noise, the first question (which I don't need answering) is: 1) Why doesn't Gazebo produce perfect odometry? - I can see that it makes sense most of the time to simulate the real robot as faithfully as possible.

Not sure if you've got the same issue I had - but my fix here was to set the minimumScore parameter to a very large value.

Not sure if you've got the same issue I had - but my fix here was to set the minimumScore parameter to a very large value.

I've found that in relatively feature-poor environments, e.g. a large rectangular room, the maps produced by gmapping can be very wrong. This is using a Turtlebot simulated in Gazebo, I'm not sure how transferrable this issue is. Also when using the environment from the tutorial gmapping works fine, so I suspect it's the lack of features causing the problem.

The symptoms are that the robots position jumps suddenly by up to ~1.5m, and walls it maps from then on are offset correspondingly.

I've tracked down the cause of this to "scan matching" in the OpenSLAM Gmapping code - particle locations are updated in two cases, first when applying the motion model, and second when each particle is 'jiggled' by the scan matcher to better fit the scan data. The fix for this is to change the minimumScore gmapping parameter to a large value:

<param name="minimumScore" value="10000"/>

by editing / copying gmapping.launch.xml. This turns gmapping into a pure mapping rather than a SLAM algorithm. However, the odometry provided by Gazebo seems pretty good, and not the cause of the problem (as some people seem to have suspected previously, e.g. http://answers.ros.org/question/12919/map-and-odom-after-mapping-the-environment/).

You can also set the motion model noise to zero, and reduce the number of particles to 1:

<param name="srr" value="0.0"/>
<param name="srt" value="0.0"/>
<param name="str" value="0.0"/>
<param name="stt" value="0.0"/>
<param name="particles" value="1"/>

which means the algorithm assumes the odometry is perfect. I think there might be some benefit in leaving these parameters as the default, to allow some corrections as the Gazebo odometry drifts, but I'm not completely sure.

Have you checked your setting for the map_update_interval parameter? Probably set in gmapping.launch.xml.

http://wiki.ros.org/gmapping?distro=hydro

Trying to load a library of functions from a ROS package's init.pl file, json_prolog gives the error:

ERROR: /home/path/my_package/prolog/init.pl:19:
 source_sink `library(my_lib)' does not exist 
Warning: /home/path/my_package/prolog/init.pl:19:
 Goal (directive) failed: user:use_module(library(my_lib))

The init.pl file uses the code

:- use_module(library('my_lib')).

to load a file 'my_lib.pl' located in the same directory as init.pl.

When starting the package using rosrun rosprolog rosprolog my_package the module gets compiled and loaded fine.

I suspect the problem is that JSONPrologNode.java uses ensure_loaded('/home/path/my_package/prolog/init.pl') instead of register_ros_package(my_package) which is what rosprolog uses.