AbuIbra's profile - activity

Try adding it simply by executing this command: export ROS_PACKAGE_PATH= /opt/ros/hydro/share:/opt/ros/hydro/stacks:/path/to/your/ws Does this work?

Perhaps you just have to change your fixed frame to /map in rviz.

When you visualize your laserScan with "rostopic echo /scan" does it show a lot of zeros (or Infs)?

If so, create a filter to change these values to your laser max range values.

Maybe you are not clearing because your lasers do not tell that "they see staff beyond" the place where there used to be an obstacle.

To make robots go to the same place, both robots have to subscribe to this same topic

/move_base/simple_navigation_goal

and process the goal for both robots to make them go to the same place.

I am not sure I exactly understood what you wanna do. But here is a suggestion:

First when you announce your publisher, specify 0 to avoid missing a msg (infinite queue: WATCH OUT! This can be dangerous..). Like this!

ros::Publisher msg_pub = nh.advertise("new_topic_name", 0);

Then just do this inside your callbacks:

msg_pub.publish(new_msg);

Note that you do not need to create a node to change a topic name. This is easily done by just adding this line in the right place on your launch file:

<remap from="old_topic_name" to="new_topic_name"/>

So... the question is... ?

I am using gmapping to create maps with lasers. I managed to have successful maps but since obstacles in some indoor spaces (like malls etc..) are transparent (such as glass walls and doors etc...), my project is to enhance the mapping by adding a node using sonars and the laser-created-map (and tf data of course to localise the robot in the map) to generate a more general map with the transparent obstacles in it. (the introduction is to let you know why this question and to have some advices regarding what I want to do..)

So, my question is: Are the /map frame axes (X and Y) parallel to the sides of the "rectangular map"? If not, I guess the information about the /map frame orientation is in "map.info.origin.orientation". No? I read in some previous question :(/question/10268/where-am-i-in-the-map/) that "in practice there's no rotation". Is "map.info.origin.orientation" then useless?

Try creating GMapping launch file and adding <remap from="/tf" to="/tf2"> in gmapping <node> in this launch file. Note that this is only to make your recorded data work because clearly name of topics do not match.

@Warrior: this :"((math.atan2(goalY - robotY, goalX - robotX)) * 180/math.pi) - robotAngle" can be always equal to "((math.atan2(goalY, goalX)) * 180/math.pi)" because in robot frame: robotX =0 robotY=0 and robotAngle=0! So without the frame, this is useless. So you really have to think **FRAMES**!

Is "/local_map" the frame of the map created by GMapping? And if so tell me how /local_map and /map are linked? is local_map-->map link something you can choose freely? If you answer those two questions, I think I have a good idea for you

Have you tried to use [amcl](http://wiki.ros.org/amcl)?

As for your change in the comment, I can't say much about it. You have to understand that there are frames. So your "self" thing means nothing unless you tell me in which frame it is. For example, imagine you have robotPose variable expressed in /base_link(robot frame), you always have x=0 y=0 !

I edited my answer to put more explanatory comments to make my code clearer. Believe me man, this is not complicated, this , I think, is the straight forward way to do things with ROS basic tools (tf, poseStamped, etc. )

What you need is a fixed reference for both goal and robot pose. Here's an example with /map frame (sorry it is a C++ cause I don't master Python code):

while(ros::ok())
{
    //declare some variables
    tf::StampedTransform poseRobot;
    geometry_msgs::PoseStamped robot_pose;
    //initialize robot angle
    double yaw_r(50);
    //try what's between {}
    try
    {
        ROS_DEBUG("Pose du robot ...");
        // have the transform from /map to /base_link (robot frame) and put it in "poseRobot": this is the robot pose in /map!
        listener.lookupTransform("/map","/base_link",ros::Time(0), poseRobot);

        //get the orientation: it is a quaternion so don't worry about the z. It doesn't mean there is a 3D thing here!
        robot_pose.pose.orientation.x = poseRobot.getRotation().getX();
        robot_pose.pose.orientation.y = poseRobot.getRotation().getY();
        robot_pose.pose.orientation.z = poseRobot.getRotation().getZ();
        robot_pose.pose.orientation.w = poseRobot.getRotation().getW();

        // convert the quaternion to an angle (the yaw of the robot in /map frame!)         
        yaw_r = tf::getYaw(robot_pose.pose.orientation);  
    }
    catch(tf::TransformException &ex) //if the try doesn't succeed, you fall here!
    {
        // continue
        ROS_INFO("error. no robot pose!");
    }

            //angleDes is the goal angle in /map frame you get it by subscribing to goal 
            //The angleDes you should get it in a call back normally by converting the goals orientation to a yaw. Exactly as we have done to get robot's yaw

            //delta_yaw is what you want to get
            double delta_yaw = angleDes - yaw_r;
            //and here I just make sure my angle is between minus pi and pi!
    if (delta_yaw > M_PI)
            delta_yaw -= 2*M_PI;
    if (delta_yaw <= -M_PI)
            delta_yaw += 2*M_PI;

You can replace /map frame with /odom frame.

Suppose now that your goal is not in /map frame. This how you convert it with tf:

//some bool to check if conversion is alright
success =false;
try
{
    ROS_DEBUG("transform from goalFrame to mapFrame ...");

    //prepare conversion by sync'ing times
    ros::Time current_transform = ros::Time::now(); 
    listener2.getLatestCommonTime(currentGoal.header.frame_id, "map", current_transform, NULL);
    currentGoal.header.stamp = current_transform;

     //conversion
    geometry_msgs::PoseStamped goalInMap;
    listener2.transformPose("/map", currentGoal, goalInMap);

    angleDes = tf::getYaw(goalInMap.pose.orientation);

    success =true;
}
catch(tf::TransformException &ex)
{
    // continue
    ROS_DEBUG("error. no transform from goal frame to map frame!");
}

Good question.. I am interested in having an answer to this.

move_base node DOES NOT subscibe to the /map but to /tf published by gmapping

This is normal, I guess, since the costmap is created using the laser detections (or whatever source of mesures about obstacles you are using) and it is updated according to what these sensors are seeing in real time. (cause if not you won't be avoiding moving obstacles like people and chairs moved so often for example)

/map is only used for localisation (whether by launching GMapping which does it while building the map OR by loading some previously built map and using amcl), and sending goals intuitively in rviz using the right tool..

I suggest you use this: http://wiki.ros.org/yocs_waypoints_navi

It allows you to set waypoints throw where the robot will go before reaching the final goal. Tell me if you have any problem using it.

good "karma-question"!

When I run the rqt_reconfigure, I can see that some of the base_local_planner params can't be chosen outside certain limits. If we look at the package responsible for this we can see on the /opt/ros/fuerte/stacks/navigation/base_local_planner/cfg/BaseLocalPlanner.cfg file for example: (min = 0.0 and max = 20.0)

gen.add("min_vel_x", double_t, 0, "The minimum x velocity for the robot in m/s", 0.0, 0.0, 20.0)

What if I want the min and max to be different. For example, min = -5.0 and/or max = 25.0? How can I do this (without touching the original code if possible)?

Edit

ahendrix: I wonder if your answer is just a guess: In fact, a negative minimum velocity does make sense (you give no evidence for why this does not make sense)!
Putting a negative value on my base_local_planner_param.yaml file make my robot able to move backwards when given a goal to move_base. While it doesn't at all when this value is >= 0.0 (or when I use the rqt_reconfigure to change params of course) That's exactly the change I want to be able to do dynamically (i.e. without relaunching move_base with a new config file). As for the 25.0 change it was just a suggestion, and it would be great if Icould lower the max value (and many other max values) to avoid the uselessly high velocities possibilities.

Edit 2

Here's the solution I found. Copy the whole base_local_planner package, then modify the .cfg file on the copy. Rename the original package to avoid conflict with copy. Finally, compile the copy: it compiles with no problem! Every thing looks fine! I can now dynamically change configuration to make the robot move only backwards for the manoeuvres of my choice: it works perfectly.

(PS: Renaming a ROS installed package is not a healthy practice I guess. I could have modified the copy to make it compile with a complete new name. But... I am lazy)

see this new package:

http://www.ros.org/news/2013/03/new-p...

You can simulate a robot in morse too. It is easy to use:

http://www.openrobots.org/morse/doc/l...

That's why, I put this first line if you look with more attention at my answer: source /opt/ros/hydro/setup.bash

you have to change your fixed_frame to /map in RVIZ.

EDIT: Make sure there is no time delay too, the system clocks of the computers you are running on have to be synchronized. http://wiki.ros.org/navigation/Troubl...