Ask Your Question

move base velocity commands [closed]

asked 2013-10-30 07:42:17 -0600

rnunziata gravatar image

updated 2013-11-02 09:44:25 -0600

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.

Update: Here are my setting I use for costmap and amcl. Can anyone see somthing in the setting to prevent the local plan.

  # for details see: <a href=""></a>
  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_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

  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

   # 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 ...
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by rnunziata
close date 2013-12-16 03:11:22

1 Answer

Sort by ยป oldest newest most voted

answered 2013-10-30 07:52:17 -0600

dornhege gravatar image

It depends on your controller setup for move_base and might warrant deeper investigation, but here is a guess: You are hitting recovery behaviors, most likely because the local planner could never find a plan. This would hint at a problem with the costmap setup.

edit flag offensive delete link more


Nothing in the status logs...but by setting the escape_vel to a none negative number. The robot stoped moving backward proving that in fact it was in a recovery mode as you say.

rnunziata gravatar image rnunziata  ( 2013-10-30 08:25:13 -0600 )edit

After backing out costmap configurations going to defaults and moving to ekl combined odom with an GPS in gazebo I resolved this issue.

rnunziata gravatar image rnunziata  ( 2013-12-16 03:11:15 -0600 )edit

Question Tools

1 follower


Asked: 2013-10-30 07:42:17 -0600

Seen: 1,040 times

Last updated: Nov 02 '13