I want to clear the dynamic obstacles in the costmap manually for this I am trying to clear all the layers of the costmap except static layer by editing the clear_costmaps service (because if I use clear_costmaps service it will clear the whole costmap and the robot may hit the obstacles.) But that's not working and It is not clearing the obstacles in the costmap. It is calling the service and the program is running fine but the obstacles in the costmap are not cleared. I am using ros indigo , ubuntu 14.04 and I made the following changes in move_base.cpp and costmap_2d_ros.cpp programs. Can someone help how to fix this issue?
In move_base.cpp:
//advertise a service for clearing the costmaps
clear_costmaps_srv_ = private_nh.advertiseService("clear_costmaps", &MoveBase::clearCostmapsService, this);
//ros::NodeHandle cnh;
//advertise a service for clearing the costmaps except static layer
clear_costmaps_new_srv_ = private_nh.advertiseService("clear_costmaps_new", &MoveBase::clearCostmapsService_new, this);
----------
bool MoveBase::clearCostmapsService(std_srvs::Empty::Request &req, std_srvs::Empty::Response &resp){
//clear the costmaps
planner_costmap_ros_->resetLayers();
controller_costmap_ros_->resetLayers();
return true;
}
/////new function to clear the costmap layers except static layer/////
bool MoveBase::clearCostmapsService_new(std_srvs::Empty::Request &req, std_srvs::Empty::Response &resp){
//clear the costmaps
planner_costmap_ros_->resetLayers_new();
controller_costmap_ros_->resetLayers_new();
return true;
}
In costmap_2d_ros.cpp:
void Costmap2DROS::resetLayers()
{
Costmap2D* top = layered_costmap_->getCostmap();
top->resetMap(0, 0, top->getSizeInCellsX(), top->getSizeInCellsY());
std::vector < boost::shared_ptr> *plugins = layered_costmap_->getPlugins();
for (vector>::iterator plugin = plugins->begin(); plugin != plugins->end();
++plugin)
{
(*plugin)->reset();
}
}
//////new function to reset layers except static layer/////
void Costmap2DROS::resetLayers_new()
{
std::string SL = "global_costmap/static_layer";
Costmap2D* top_n = layered_costmap_->getCostmap();
top_n->resetMap(0, 0, top_n->getSizeInCellsX(), top_n->getSizeInCellsY());
std::vector < boost::shared_ptr> *plugins = layered_costmap_->getPlugins();
for (vector>::iterator plugin = plugins->begin(); plugin != plugins->end();
++plugin)
{
if((*plugin)->getName() != SL)
ROS_INFO("resetting layer %s",(*plugin)->getName().c_str());
(*plugin)->reset();
}
}
In my program the service is called as shown below:
///////////////////////////////////////////////////////////////////////////////
std_srvs::Empty ccn;
ros::service::waitForService("clear_costmaps_new",ros::Duration(2.0));
if (clear_costmaps_client.call(ccn))
{
ROS_INFO("every costmap layers are cleared except static layer");
}
else ROS_INFO("failed calling clear_costmaps service");
//////////////////////////////////////////////////////////////////////////////
↧
clear_costmap service not working.....
↧
global costmap is rotated compared to the map
Hello there.
I use navigation stack to perform autonomous navigation in known map.
I got help from this tutorial http://wiki.ros.org/navigation/Tutorials/RobotSetup but, as you can see in the picture below, global costmap is rotated compared to the map. The degrees are not fixed, other times it's 90 degrees, other times 180, or ~40 compared to the map.
Everything else (goal pose, local path, global path) is working right according to generated costmaps.
Any thoughts?

↧
↧
High CPU usage for AMCL and move_base under namespace
I am trying to run the ROS navigation stack on a turtlebot, with everything under a namespace (in this case, the namespace is `robot_0`). The netbook that everything is running on has a dual-core Intel Atom processor with 2GB of RAM, and is running ROS Indigo on Ubuntu 14.04. Everything is fine when I run the sample navigation launch files that do not use namespaces (i.e. `minimal.launch` from turtlebot_bringup and `amcl_demo.launch` from turtlebot_navigation). In this configuration, move_base uses approximately 22% of one core, and amcl uses under 10% of one core. Amcl then publishes the transform from the `/map` frame to the `/odom` frame at 30Hz, as expected.
However, when I switch to my custom configuration file that has everything running under a namespace, the cpu usage for amcl and for move_base each jump to approximately 80%, pushing the total usage for each core to 100%. Amcl is only able to publish the transform at around 5Hz, and the most recent transform available from `/map` to `/robot_0/odom` (the equivalent of `/odom` under the namespace) is over 2 seconds old. I tried the commonly suggested solutions of turning down costmap publishing frequency, and that didn't help (I also don't think it should be necessary because everything runs fine using the default parameters). The configuration I have causes the following warnings from the costmap:
[ WARN] [1466518518.525473823]: Costmap2DROS transform timeout. Current time: 1466518518.5254, global_pose stamp: 1466518518.0204, tolerance: 0.5000
[ WARN] [1466518518.525571024]: Could not get robot pose, cancelling pose reconfiguration
This warning is published at approximately 2Hz. If I increase the `transform_tolerance` on the costmaps to 3.5s (as you can see I did in the configurations I included below), then the warnings become much less frequent, but don't always disappear completely.
However, even if I increase the transform tolerance, I still occasionally get the following warnings:
[ WARN] [1466518719.455966268]: MessageFilter [target=map ]: Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.
[ WARN] [1466518719.713827484]: MessageFilter [target=robot_0/odom ]: Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.
The percentage of messages dropped varies from around 90% to 100%.
And I get errors like the following sporadically whether or not I increase the `transform_tolerance`:
[ERROR] [1466518772.987647336]: Extrapolation Error looking up robot pose: Lookup would require extrapolation into the past. Requested time 1466518762.913725848 but the earliest data is at time 1466518762.988183070, when looking up transform from frame [robot_0/base_footprint] to frame [map]
I have assumed that all of these problems are caused by amcl not publishing the transform as quickly as it should because of some performance issue, but I have not come across any differences between my launch configuration and the default that would increase the cpu load.
All of the configuration files are located in the `testing` branch of the git repository [here](https://github.com/amiller27/multiple_turtlebots_real_world/tree/testing). The tf trees are also there, with good_frames being the tf tree when running the default provided configuration, and bad_frames being the tf tree under the namespace. I have included below all of my launch files and parameter files that I think might be relevant; the main launch file is `robot_under_namespace.launch`. If another file might be helpful, I can add it. Unfortunately I can't just attach them because I don't have enough reputation, so I've pasted their contents here.
robot_under_namespace.launch:
single_robot_wild.launch:
amcl.launch:
move_base.launch:
costmap_common_params.yaml:
max_obstacle_height: 0.60 # assume something like an arm is mounted on top of the robot
# Obstacle Cost Shaping (http://wiki.ros.org/costmap_2d/hydro/inflation)
robot_radius: 0.20 # distance a circular robot should be clear of the obstacle (kobuki: 0.18)
# footprint: [[x0, y0], [x1, y1], ... [xn, yn]] # if the robot is not circular
map_type: voxel
obstacle_layer:
enabled: true
max_obstacle_height: 0.6
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
unknown_threshold: 15
mark_threshold: 0
combination_method: 1
track_unknown_space: true #true needed for disabling global path planning through unknown space
obstacle_range: 2.5
raytrace_range: 3.0
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
publish_voxel_map: false
observation_sources: scan bump
scan:
data_type: LaserScan
topic: scan
marking: true
clearing: true
min_obstacle_height: 0.25
max_obstacle_height: 0.35
bump:
data_type: PointCloud2
topic: mobile_base/sensors/bumper_pointcloud
marking: true
clearing: false
min_obstacle_height: 0.0
max_obstacle_height: 0.15
# for debugging only, let's you see the entire voxel grid
#cost_scaling_factor and inflation_radius were now moved to the inflation_layer ns
inflation_layer:
enabled: true
cost_scaling_factor: 5.0 # exponential rate at which the obstacle cost drops off (default: 10)
inflation_radius: 0.5 # max. distance from an obstacle at which costs are incurred for planning paths.
static_layer:
enabled: true
global_costmap_params.yaml:
global_costmap:
global_frame: /map
robot_base_frame: base_footprint
update_frequency: 1.0
publish_frequency: 0.5
static_map: true
transform_tolerance: 3.5
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
local_costmap_params.yaml:
local_costmap:
global_frame: odom
robot_base_frame: base_footprint
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 4.0
height: 4.0
resolution: 0.05
transform_tolerance: 3.5
plugins:
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
move_base_params.yaml:
# Move base node parameters. For full documentation of the parameters in this file, please see
#
# http://www.ros.org/wiki/move_base
#
shutdown_costmaps: false
controller_frequency: 5.0
controller_patience: 3.0
planner_frequency: 1.0
planner_patience: 5.0
oscillation_timeout: 10.0
oscillation_distance: 0.2
# local planner - default is trajectory rollout
base_local_planner: "dwa_local_planner/DWAPlannerROS"
base_global_planner: "navfn/NavfnROS" #alternatives: global_planner/GlobalPlanner, carrot_planner/CarrotPlanner
#We plan to integrate recovery behaviors for turtlebot but currently those belong to gopher and still have to be adapted.
## recovery behaviors; we avoid spinning, but we need a fall-back replanning
#recovery_behavior_enabled: true
#recovery_behaviors:
#- name: 'super_conservative_reset1'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'conservative_reset1'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'aggressive_reset1'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'clearing_rotation1'
#type: 'rotate_recovery/RotateRecovery'
#- name: 'super_conservative_reset2'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'conservative_reset2'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'aggressive_reset2'
#type: 'clear_costmap_recovery/ClearCostmapRecovery'
#- name: 'clearing_rotation2'
#type: 'rotate_recovery/RotateRecovery'
#super_conservative_reset1:
#reset_distance: 3.0
#conservative_reset1:
#reset_distance: 1.5
#aggressive_reset1:
#reset_distance: 0.0
#super_conservative_reset2:
#reset_distance: 3.0
#conservative_reset2:
#reset_distance: 1.5
#aggressive_reset2:
#reset_distance: 0.0
↧
how to let gmapping move_base and amcl work together?
now we can use gmapping to draw a map, and use move base and amcl to navagate,
but , how can I use the two part .
and when i viset a new zone , I can draw new map to add to old map?
↧
PID Control and the Navigation Stack
Hello,
I'm trying to learn how to properly set up a standard ROS navigation and control stack to drive a field robot (one that operates outdoors, navigating primarily by GPS and possibly a compass). My own previous experience with other systems keeps getting in the way and so I have some questions about how this is meant to work.
1) This system is not a wheeled system, (it's a boat) and so there's not a direct measure of "odometry", which move_base seems to require. Even with speed measured by the GPS and heading measured by a separate compass, the combination don't typically reflect the actual movement of the vessel, since the vessel's direction of travel rarely matches it's heading. The speed from the GPS is course made good, not speed in the vessel's reference frame. My questions is, how should one best set this up?
2) I understand the canonical output from move_base (from the local_planner specifically) is the Twist message, containing linear and angular velocity information. Having been told the robot's position, given a local cost map and a goal, the local planner calculates the optimal velocity message for the vehicle. What is confusing to me is that the output of all this. What the robot needs (it seems to me) is a direction to travel and a speed at which to go. But a Twist message outputs not a desired direction of travel, but the angular velocity or the **change** in direction of travel. It seems to me move_base is acting like a controller (think PID controller) on some level by not specifying the desired direction of travel directly. Do I understand this correct?
3) Finally, ros_control can implement a PID (or other) controller to adjust the speed of motors (or maybe maneuver a rudder on a boat) to match the desired setpoint. But in this case, it is matching a heading rate, not a heading directly. Is this not backwards? Shouldn't the output of the local_planner be a desired heading and since the motors, driving wheels or a rudder, actually change the heading rate directly, a PID controller in ros_control would then take adjust the heading rate to achieve the desired heading published by the local planner?
I hope this all makes some sense. I can't help but feel like the roles of the local_planner and ros_control are reversed in some sense (at least with respect to the desired direction of travel).
Thanks for your thoughts, in advance.
Val
↧
↧
how to judge move_base has go to the goal?
We can control the robot to a goal, using base_move and amcl.
but i can not judge that when the robot reached the goal.
I think, we can judge the vel or the tf not change to do it .
but, I think that ,it must have better solution.
I use rqt_graph and rosrun tf view_frames list all.
but , I can not find any solution than I do.
anyone can help me to solve it,
thanks!
↧
move_base action server doesn't come up with a real robot
Hello !
I try to run the move_base node on a real robot. When I run it in simulation (with another robot), it works successfully.
But, when I try to bring up the navigation stack on a real robot, the move_base action server doesn't come up.
Indeed, when I launch the move_base node, I get continuously the unexpected following warning: [ WARN] [1466504490.216963462]: Costmap2DROS transform timeout. Current time: 1466504490.2169, global_pose stamp: 1466504032.8989, tolerance: 0.3000 Moreover, when I run my own C++ node in order to send a goal command, the program stays blocked inside the waitForServer loop, this loop is as follows: while(!ac.waitForServer(ros::Duration(5.0))) { ROS_INFO("Waiting for the move_base action server to come up"); } I don't understand why it doesn't work and why when I run the move_base node the move_base action server doesn't come up.
If anyone can help me, I would be very grateful,
lfrupdate 1 Here the result of the roswtf command: WARNING: Package "ompl" does not follow the version conventions. It should not contain leading zeros (unless the number is 0). Loaded plugin tf.tfwtf No package or stack in context ================================================================================ Static checks summary: No errors or warnings ================================================================================ Beginning tests of your ROS graph. These may take awhile... analyzing graph... ... done analyzing graph running graph rules... ... done running graph rules running tf checks, this will take a second... ... tf checks complete Online checks summary: Found 3 warning(s). Warnings are things that may be just fine, but are sometimes at fault WARNING The following node subscriptions are unconnected: * /teleop: * /torso_controller/state WARNING The following nodes are unexpectedly connected: * /mugiro_node->/rqt_gui_py_node_4590 (/tf) WARNING Received out-of-date/future transforms: * receiving transform from [/sickS3000_publisher] that differed from ROS time by -460.430734051s * receiving transform from [/Publish_odom_TF] that differed from ROS time by -460.43225327s You can find the tf tree below:
 And the graph here:

But, when I try to bring up the navigation stack on a real robot, the move_base action server doesn't come up.
Indeed, when I launch the move_base node, I get continuously the unexpected following warning: [ WARN] [1466504490.216963462]: Costmap2DROS transform timeout. Current time: 1466504490.2169, global_pose stamp: 1466504032.8989, tolerance: 0.3000 Moreover, when I run my own C++ node in order to send a goal command, the program stays blocked inside the waitForServer loop, this loop is as follows: while(!ac.waitForServer(ros::Duration(5.0))) { ROS_INFO("Waiting for the move_base action server to come up"); } I don't understand why it doesn't work and why when I run the move_base node the move_base action server doesn't come up.
If anyone can help me, I would be very grateful,
lfrupdate 1 Here the result of the roswtf command: WARNING: Package "ompl" does not follow the version conventions. It should not contain leading zeros (unless the number is 0). Loaded plugin tf.tfwtf No package or stack in context ================================================================================ Static checks summary: No errors or warnings ================================================================================ Beginning tests of your ROS graph. These may take awhile... analyzing graph... ... done analyzing graph running graph rules... ... done running graph rules running tf checks, this will take a second... ... tf checks complete Online checks summary: Found 3 warning(s). Warnings are things that may be just fine, but are sometimes at fault WARNING The following node subscriptions are unconnected: * /teleop: * /torso_controller/state WARNING The following nodes are unexpectedly connected: * /mugiro_node->/rqt_gui_py_node_4590 (/tf) WARNING Received out-of-date/future transforms: * receiving transform from [/sickS3000_publisher] that differed from ROS time by -460.430734051s * receiving transform from [/Publish_odom_TF] that differed from ROS time by -460.43225327s You can find the tf tree below:
 And the graph here:

↧
move_base corrupt linked list
I have the navigation stack working, but the move_base node is consistently crashing. The behavior is very consistent; eventually it crashes with the same error every time. The amount of time it takes to crash does vary. I'm going to post this same question on the
Here's the exact error, each time corresponding to the following warning:
[ WARN] [1466704185.100935930]: InflationLayer::updateCosts(): seen_ array size is wrong
and the error:
*** Error in `/opt/ros/indigo/lib/move_base/move_base': corrupted double-linked list: 0x00000000029ad9b0 ***
[move_base-1] process has died [pid 8680, exit code -6, cmd /opt/ros/indigo/lib/move_base/move_base cmd_vel:=/mobility_base/cmd_vel odom:=/odometry/filtered map:=/rtabmap/proj_map __name:=move_base __log:=/home/mb/.ros/log/4d826ab2-396a-11e6-ad82-b8aeed747f2b/move_base-1.log].
log file: /home/mb/.ros/log/4d826ab2-396a-11e6-ad82-b8aeed747f2b/move_base-1*.log
all processes on machine have died, roslaunch will exit
Unfortunately, the log file isn't actually written, so I haven't been able to get any useful information from there. I've done some googling and the only thing I can turn up is line 192 of the source of costmap_2d's inflation_layer.cpp (http://docs.ros.org/jade/api/costmap_2d/html/inflation__layer_8cpp_source.html). So it seems deleting the seen_ array of costmap_2d's inflation layer is causing a corruption of a linked list somewhere else. What's odd is the warning doesn't always cause the error. I'm thinking it might be cause by how rtabmap is updating proj_map, but I'm somewhat shooting in the dark. Any insight would be helpful.
Here's my basic robot setup. A kinectv1 mounted on the robot with rtabmap_ros for odometry and mapping. The move_base package uses the following:
base_local_planner_params.yaml
TrajectoryPlannerROS:
acc_lim_x: 1.0
acc_lim_y: 1.0
acc_lim_theta: 2.0
max_vel_x: 0.4
min_vel_x: 0.05
escape_vel: -0.05
max_vel_theta: 0.5
min_vel_theta: -0.5
min_in_place_vel_theta: 0.01
holonomic_robot: true
y_vels: [-0.3, -0.05, 0.05, 0.3]
xy_goal_tolerance: 0.03
yaw_goal_tolerance: 0.05
latch_xy_goal_tolerance: true
# make sure that the minimum velocity multiplied by the sim_period is less than twice the tolerance on a goal. Otherwise, the robot will prefer to rotate in place just outside of range of its target position rather than moving towards the goal.
sim_time: 1.5 # set between 1 and 2. The higher he value, the smoother the path (though more samples would be required).
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 12
vtheta_samples: 20
meter_scoring: true
pdist_scale: 0.7 # The higher will follow more the global path.
gdist_scale: 0.8
occdist_scale: 0.03
publish_cost_grid_pc: false
# move_base controller_frequency
controller_frequency: 5.0
# global planner
NavfnROS:
allow_unknown: true
visualize_potential: false
costmap_common_params.yaml
footprint: [[0.42, -0.43], [0.42, 0.43], [-0.42, 0.43], [-0.42, -0.43]]
footprint_padding: 0.02
inflation_layer:
inflation_radius: 0.02
transform_tolerance: 2
obstacle_layer:
obstacle_range: 3.0
raytrace_range: 3.5
track_unknown_space: false
observation_sources: point_cloud_sensor
point_cloud_sensor: {
sensor_frame: /camera_link,
data_type: PointCloud2,
topic: /rtabmap/cloud_map,
expected_update_rate: 1.0,
max_obstacle_height: 3.0,
min_obstacle_height: 0.1,
marking: true,
clearing: true
}
global_costmap_params.yaml
global_costmap:
global_frame: /map
robot_base_frame: base_footprint
update_frequency: 0.5
publish_frequency: 0.5
always_send_full_costmap: true
static_map: true
plugins:
- {name: static_layer, type: "rtabmap_ros::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
local_costmap_params.yaml
local_costmap:
global_frame: odom
robot_base_frame: base_footprint
update_frequency: 1
publish_frequency: 1
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.025
#origin_x: -3.0
#origin_y: -3.0
plugins:
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
And here's my rtabmap.launch
↧
/move_base died when running rbx1 simulation
Hi all,
I'm running the fake_move_base in
> ros-by-example-indigo vol1
Chapter 8.2 using ArbotiX simulator.
I followed the instruction by typing (all the prerequisites have been fulfilled)
$ roslaunch rbx1_bringup fake_turtlebot.launch
and
$roslaunch rbx1_nav fake_move_base_blank_map.launch
What's more, I checked every related launch files and make sure they are the same with those in the book.
Unfortunately, I always got the following error:

Can anyone give me some idea about that?
Thanks a lot!!
↧
↧
move_base node without actual robot?
hello,
since i have only laser scanner and trying to show obstacles in a built map via hector_slam/gmapping.
first i tried to use costmap_2d only but i have some problems in there ( [my previous question about it](http://answers.ros.org/question/238150/static-map-and-costmap-unmatch/) ) , [and this too](http://answers.ros.org/question/237991/footprint-doesnt-move-in-the-costmap/) so at the same time i want to try move_base launch to see costmap in it with help of amcl...
is this possible to use move_base without having an actual robot?
↧
amcl dont do the localization job and results in unmatching maps
hello,
I'm using lms100 only, when i use gmapping+laser can matcher and costmap at the same time it was ok, but then i tried the other option; static map and amcl (again with laser scan matcher) cant manage it. it looks like amcl didnt do its job.
in rviz, it looks like this.

my launch file:
the errors in the terminal:
[WARN] [1467201369.564382684]: Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settins robust against changes of costmap resolution.
[ WARN] [1467201370.169816275]: The /scan observation buffer has not been updated for 2.27 seconds, and it should b updated every 0.40 seconds.
[ WARN] [1467201370.301085119]: The /scan observation buffer has not been updated for 1.25 seconds, and it should be updated every 0.40 seconds.
[ INFO] [1467201370.739975409]: Recovery behavior will clear layer obstacles
[ INFO] [1467201370.987085606]: Recovery behavior will clear layer obstacles
[ INFO] [1467201641.943586259]: Setting pose (1467201641.943557): -2.015 0.022 -0.000
[ INFO] [1467201669.857466951]: Setting pose (1467201669.857429): -1.915 0.013 -1.619
[ INFO] [1467201685.386250862]: Setting pose (1467201685.386178): -2.534 0.053 2.826
[ WARN] [1467201716.436344460]: Costmap2DROS transform timeout. Current time: 1467201716.4363, global_pose stamp: 1467201716.0885, tolerance: 0.3000
[ WARN] [1467201716.437433328]: Could not get robot pose, cancelling reconfiguration
↧
explanation of use_map_topic in amcl?
In AMCL page, for use_map_topic it says "When set to true, AMCL will subscribe to the map topic rather than making a service call to receive its map." but i dont get it. can someone explain it?
I created map with gmapping and saved it. After when i try to localize the robot in the static map how should i set this parameter?
↧
Hector Mapping and Exploration
Greetings!
I am still getting the hang of ROS and i have a couple questions about autonomous exploration to create a map.
I have Hector_Mapping working and my next goal is to have the robot map the room by itself.
1. What is Move_Base and Hector_Exploration_Planner. Does Move_Base require a Map and a goal? Or can i explore unknown environments with this package?
2. If i am to use Hector_Exploration_Planner, is there any documentation anyone has found on how to use the package?
3. Hector_Exploration_Planner is part of the Hector_navigation stack which is only available for hydro, however Hector_Exploration_Planner is up-to-date with kinetic. Will i still be able to use the Hector_Navigation stack then?
4. Where does the robot communicate with the Arduino node in these packages.
I have been looking for documentations or tutorials on how to implement these packages but i am unable to find anything.
Any help would be greatly appreciate. Thank you for your time!
↧
↧
Navigating a robot using same path every time
Hello,
I am not sure if I am clear here with my question. What I want to do is create a map with couple of obstacles in it and to make the robot drive around them, making an 8 shape. Something similar to the picture. Just imagine that in those 2 loops, there would be an obstacle. I am probably using wrong terms to find a similar example. I want the robot to be always driving that shape too (this is necessary for tests). Which tutorials could provide me with some samples?
Right now I am using teb_local_planner. One of the requirements for the robot is that it also has to localize itself while doing this.

Thank you!
**EDIT** So I have tried running samples of teb_local_planner following the Global Plan (Via-Points), however it didnt work for me.
I couldnt git clone the newest version of teb_local_planner because I already had it in my ~/catkin_ws directory (or at least I got git FATAL error), however I ran the rosdep install in the same folder and it didnt complain.
How do I know that it didnt work in the end? I could never see neither the global_plan_viapoint_sep parameter nor weight_viapoint when I ran the roslaunch teb_local_planner test_optim_node.launch. Heres proof:
https://www.dropbox.com/s/axq237aul1v1huu/Screenshot%202016-05-09%2020.11.06.png?dl=0
https://www.dropbox.com/s/l6x1a4cxgkg6wb7/Screenshot%202016-05-09%2020.11.01.png?dl=0
I tried setting it just in rqt config file, but to no avail.
↧
move_base turns clockwise when counterclockwise would be faster
In both of the scenarios depicted below, by robot turns clockwise. counterclockwise is obviously much faster. It will however turn counterclockwise if the goal is very close to in front of the robot, around 30deg maybe. Anything past that turns the other way.
I have min_rot_vel set to 0.07, since according to the DWA_local_planner wiki, it's an absolute value.


↧
Extrapolation error when sending goals to the robot via navigation stack
Hi there,
I am using the P3DX robot to navigate an indoor environment using the SICK 500 LIDAR. I have brought up the robot using [rosarnl](https://github.com/MobileRobots/ros-arnl).
I have defined my yaml parameters as follows:
- Costmap_common_params.yaml
obstacle_range: 0.1
raytrace_range: 0.1
#footprint: [[-115.375, -15.144], [-199.803, 93.368], [-7.863, 115.870], [58.644, -37.710]]
robot_radius: 0.4699 #meters
inflation_radius: 0.2048 #1 feet
observation_sources: laser_scan_sensor point_cloud_sensor
laser_scan_sensor: {sensor_frame: laser_frame, data_type: LaserScan, topic: /rosarnl_node/lms5XX_1_laserscan, marking: true, clearing: true}
point_cloud_sensor: {sensor_frame: odom, data_type: PointCloud, topic: /rosarnl_node/lms5XX_1_pointcloud, marking: true, clearing: true}
- global_costmap_params.yaml
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 1.0
publish_frequency: 5.0
static_map: true
sensor_frame: laser_frame
width: 160.3
height: 160.773
origin_x: -77.702
origin_y: -56.819
- local_costmap_params.yaml
local_costmap:
global_frame: base_link #map
robot_base_frame: laser_frame
update_frequency: 1.0
publish_frequency: 5.0
static_map: false
rolling_window: true # must be set to false to use static map
resolution: 0.5
transform_tolerance: 0.5 #tolerable delay in seconds
width: 160.3
height: 160.773
origin_x: -70.702
origin_y: -66.819
- base_local_planner_params.yaml
TrajectoryPlannerROS:
#Robot Configuration Parameters
max_vel_x: 1.2
min_vel_x: 0.2
max_vel_theta: 1.0
min_in_place_vel_theta: 0.4
acc_lim_theta: 1.2
acc_lim_x: 1.5
acc_lim_y: 1.5
#Trajectory scoring parameters: http://wiki.ros.org/base_local_planner#Map_Grid
escape_vel: -0.3 #speed for escaping when stuck
meter_scoring: true
sim_time: 0.5
dwa: true #use dynamic window approach
publish_cost_grid: true
global_frame_id: base_link #Should be set to the same frame as the local costmap's global frame
holonomic_robot: true
For some reason, when I send goals via the [actionlib simple action client](http://wiki.ros.org/actionlib#C.2B-.2B-_SimpleActionClient) to `move_base/goal`, I get the following errors:
```
ERROR] [1468101998.962293754]: Global Frame: base_link Plan Frame size 205: map
[ WARN] [1468101998.962348736]: Could not transform the global plan to the frame of the controller
[ERROR] [1468101999.060938901]: Extrapolation Error: Lookup would require extrapolation into the future. Requested time 1468102000.826297045 but the latest data is at time 1468102000.823431077, when looking up transform from frame [base_link] to frame [map]
[ERROR] [1468101999.061004147]: Global Frame: base_link Plan Frame size 205: map
[ WARN] [1468101999.061030274]: Could not transform the global plan to the frame of the controller
```
**EDIT 1: v0.1 tag contains the correct code**
The amcl launch script is [here](https://github.com/SeRViCE-Lab/p3-dx/blob/v0.1/p3dx_2dnav/launch/move_base.launch) if it helps.
Thanks guys!
↧
Setting default tolerance on Global Planner with Move Base
Hey, I am trying to set the default tolerance on the GlobalPlanner using move_base for a simulation I am doing with a husky. The key behavior I am looking for is that if I give the husky a goal that is in a known obstacle, it will use the default tolerance parameter to replan to a point that is not in an obstacle. I had success in this endeavor using NavfnROS as the planner and setting the default tolerance, but the behavior of NavfnROS is not what I want, it's very unreliable and the husky often stops 4 or 5 times along the way to a goal.
My problem is that when I set the default_tolerance parameter using the GlobalPlanner (using the same method I used to set it with the NavfnROS) is that the planner won't find a valid plan if I set a goal in an obstacle. I have included below the launch file I am using, with the portion of interest being the move_base launch include, as well as the .yaml file I am using to specify the parameters I want to use.
launch file portion:
global_planner.yaml file
GlobalPlanner:
default_tolerance: 0.5
↧
↧
Inconsistency between move_base and stage_ros
Hi, I'm using move_base and stage_ros in the indigo release and I'm getting a strange behavior of the simulated robot. I'll try to explain it with an example:
I have a map which is loaded both by the map_server for move_base and by stage (the map is the same, I checked). I'm also using amcl as localiser. Then, if I open rviz, I can clearly see the map, the robot, and what the robot is sensing with is laser. What the laser is scanning is exactly compliant with the map I see (that is the one published by the map_server). If I give a goal through the Nav2Goal tool, the robot starts moving, following the path evaluated by the motion planner. Everything ok until here. The strange behavior starts happening when the robot, for some reasons, gets stuck in an obstacle: at that point, in stage the robot is stuck (with the exclamation mark on it), while for move_base (and so in rviz) it keeps moving along the path. Moreover, the laser scan stays consistent with stage, so that it starts misaligning with the map in rviz. Even more strange, although the path is evaluated by move_base to avoid obstacles, the robot still drive over there without problem (only in rviz, not in stage, where, instead, it gets stuck generating the strange behavior). It seems like stage keeps publishing the odometry of the robot moving, and so move_base move the robot independently. Moreover, I get this warning on move_base
> [ WARN] [1468429179.824253819, 23.400000000]: MessageFilter [target=map laser ]: Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.
I checked the tf tree, and everything is connected as due.
I report my launch and config files for consistency.
test_move_base.launch
test_stage.launch
my_map.yaml
image: my_map.pgm
resolution: 0.050000
origin: [-100.000000, -100.000000, 0.000000]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.196
my_map.world
include "urg.inc"
include "erratic.inc"
define floorplan model
(
color "black"
boundary 1
gui_nose 0
gui_grid 0
gui_outline 0
gripper_return 0
fiducial_return 0
laser_return 1
)
resolution 0.02
interval_sim 100 # simulation timestep in milliseconds
window
(
size [ 917.000 688.000 ]
center [ 0 0 ]
rotate [ 0 0 ]
scale 19.757
)
floorplan (
name "my_map"
bitmap "kmi_podium_kinect_border.pgm"
size [200 200 0.5]
pose [ 0 -0.9 0 90 ]
)
erratic( pose [ 0.000 -1.000 0.000 90.000 ] name "robot0" color "blue")
my_map.png
[C:\fakepath\my_map.png](/upfiles/14684292331370116.png)
Move_base configuration files are the default ones.
↧
Using move_base without map
Very similar to this question but it went unanswered http://answers.ros.org/question/155091/move_base-without-map/
I'm trying to use `move_base` to drive my robot and have no map because I don't need to to any obstacle avoidance. I have `robot_localization` publishing all the necessary odometry information. This should be fine according to the navigation tutorial but when I launch the move_base node it gets stuck at `Requesting the map...` and just hangs, is there anything else I should be setting to tell move_base not to look for one? My launch and yaml files are below. Any help figuring out where I'm going wrong would be greatly appreciated. Thanks!
`costmap_common_params.yaml`
obstacle_range: 2.5
raytrace_range: 3.0
#footprint: [[x0, y0], [x1, y1], ... [xn, yn]]
robot_radius: 0.1
inflation_radius: 0.2`
`global_costmap_params.yaml`
global_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 5.0
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.05
`local_costmap_params.yaml`
local_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.05
`base_local_planner_params.yaml`
TrajectoryPlannerROS:
max_vel_x: 0.45
min_vel_x: 0.1
max_vel_theta: 1.0
min_in_place_vel_theta: 0.4
acc_lim_theta: 3.2
acc_lim_x: 2.5
acc_lim_y: 2.5
holonomic_robot: false
`move_base.launch`
↧
hector mapping and naviagtion
Hi,
I have a rplidar laser scanner and use rplidar driver to obtain my /scan topic. I use the hector mapping launch file to generate a map as I dont have an IMU, and sucessfully manage to create a map.
Now I want to use this map in move_base launch fíle to navigate in the map created.
I followed the instructions here http://wiki.ros.org/navigation/Tutorials/RobotSetup, and everthing loads well without error.
My question is now where do I get the odom from (I'm actually launching the hector_mapping again, remapping the /map topic so as to not cause any interference to the one published by map serve in move base). Is this the right way?
If I do that then, the odom is connected to a different map now rather than the map I already generated.
Can any one tell me what I'm doing wrong and how to correct it please? Thanks in advance.
↧