Update: switching from amcl to gmapping has no effect of current goal. The global path is direct to the goal but the current path to the goal is over over the place. Also turning off DWA had no effect.
Update: Here is a video of the odd behavor , note that the global path is fine but the local path can not be determined.
http://www.flickr.com/photos/107473518@N08/10625510473/
Update: Here are my setting I use for costmap and amcl. Can anyone see somthing in the setting to prevent the local plan.
TrajectoryPlannerROS:
# for details see: http://www.ros.org/wiki/base_local_planner
controller_frequency: 20
escape_vel: 0.1 # no backing up
max_vel_x: .2
max_trans_vel: .2
min_vel_x: 0.05
min_trans_vel: 0..05
max_rotational_vel: 0.1 # 0.1 rad/sec = 5.7 degree/sec
min_in_place_rotational_vel: 0.05
acc_lim_th: 0.05
acc_lim_x: 0.05
acc_lim_y: 0
holonomic_robot: false
# goal tolerance parameters
yaw_goal_tolerance: 0.5
xy_goal_tolerance: 0.5
latch_xy_goal_tolerance: true
# Forward Simulation Paramet
sim_time: 100.0 # The amount of time to forward-simulate trajectories in seconds
sim_granularity: 0.02 # The step size, in meters, to take between points on a given trajectory
angular_sim_granularity: 0.02 # The step size, in radians, to take between angular samples on a given trajectory.
vx_samples: 20 # The number of samples to use when exploring the x velocity space
vtheta_samples: 20 # The number of samples to use when exploring the theta velocity space
# Trajectory Scoring Parameters
meter_scoring: true # If true, distances are expressed in meters; otherwise grid cells
#path_distance_bias: 32.2 # The weighting for how much the controller should stay close to the path it was given
#goal_distance_bias: 22.4 # The weighting for how much the controller should attempt to reach its local goal, also controls speed
occdist_scale: 0.1 # The weighting for how much the controller should attempt to avoid obstacles
publish_cost_grid: true
prune_plan: false
common costmap.yaml
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[0.25, 0.1], [0.25, -0.1], [-0.25,-0.1], [-0.25, 0.1]]
max_scaling_factor: 0.02 # The scalling factor for footprint defined in local costmap
inflation_radius: 0.02 # Propagating cost values out from occupied cells that decrease with distance.
map_type: costmap
track_unknown_space: true
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_frame, data_type: LaserScan, topic: /scan, marking: true, clearing: true}
resolution: 0.005
global_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 30.0
publish_frequency: 30.0
static_map: true
width: 20.0
height: 20.0
origin_x: -10.0
origin_y: -10.0
local_costmap:
global_frame: /odom
robot_base_frame: /base_link
update_frequency: 10.0
publish_frequency: 10.0
static_map: false
rolling_window: true
width: 16.0
height: 16.0
origin_x: -8.0
origin_y: -8.0
amcl:
# Publish scans from best pose at a max of 10 Hz -->
odom_model_type : "diff"
odom_alpha5 : "0.1"
gui_publish_rate : "30.0"
laser_max_beams : "60"
laser_max_range : "12.0"
min_particles : "500"
max_particles : "2000"
kld_err : "0.05"
kld_z : "0.99"
odom_alpha1 : "0.2"
odom_alpha2 : "0.2"
# translation std dev, m -->
odom_alpha3 : "0.2"
odom_alpha4 : "0.2"
laser_z_hit : "0.5"
laser_z_short : "0.05"
laser_z_max : "0.05"
laser_z_rand : "0.5"
laser_sigma_hit : "0.2"
laser_lambda_short : "0.1"
laser_model_type : "likelihood_field"
# laser_model_type : "beam" -->
laser_likelihood_max_dist : "2.0"
update_min_d : "0.25"
update_min_a : "0.2"
resample_interval : "1"
# Increase tolerance because the computer can get quite busy -->
transform_tolerance : "1.0"
recovery_alpha_slow : "0.0"
recovery_alpha_fast : "0.0"
Update: move_base goes directly into recovery but there is no obstacle near the robot. Why would this happen , what would case move_base to use escape_vel.
Update: If I have rear wheels that extend outside the robot footprint , they are in back out of sight of the scanner , will this cause problems in path planning?
Update: By setting the escape_vel to a none negative number. The robot stop moving backward proving that in fact it was in a recovery mode. Now if only I can figure out why? Here is a pic of rviz.
I checked the log files but did not see any output related to recovery behaviors.
I was having problems with my robot following move base velocity commands as it tries to follow the local path. I could not see what was wrong so I hooked it up to turtlebot teleop keyboard. The robot followed the keyboard signals correctly. But when I set a simple goal in rivz move_base sends negative values to causing the robot to move backwards in both gazebo and rivz. Why is this? Where should I look. It I am to believe the keyboard controller there is nothing wrong with gazebos response or rviz. odometry and scaling as well as sim time seem to be ok.
Originally posted by rnunziata on ROS Answers with karma: 713 on 2013-10-30
Post score: 0