ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

doubt regarding cmd_vel published by move_base

asked 2015-10-15 14:34:49 -0500

Naman gravatar image

updated 2016-10-24 09:08:01 -0500

ngrennan gravatar image

Hi all,

(See Update 2)*

I am using move_base and everything seems to be working fine except sometimes, move_base publishes erratic velocities on cmd_vel topic. For example: if max_vel_x: 0.4 (or 0.3) is specified in base_local_planner_params.yaml, move_base publishes correct velocities. But if max_vel_x: 0.5, then velocities published by move_base keeps on switching between 0.5 and 0.3 for a straight line motion of the robot which results in a jerky motion of the robot. Similarly, if max_vel_x: 0.6, same thing happens and velocities switches between 0.6 and 0.35. Also, there are lot of jerks in angular velocities also. The base_local_planner is not able to send correct and smooth velocities. I have tried changing the base_local_planner_params.yaml and it didn't help. It causes lot of jerks in the robot. Does anyone have any idea why is this happening? Can it be a problem with the transformation or the way robot_footprint is specified?

I am using rotary encoders to get the odometry message and odom->base_link tf. I am using amcl for localization and move_base for planning with default local planner and sbpl_lattice_planner as global planner.


  #Set the acceleration limits of the robot
  acc_lim_th: 0.7
  acc_lim_x: 0.5
  acc_lim_y: 0

  #Set the velocity limits of the robot
  max_vel_x: 0.40
  min_vel_x: 0.10
  max_vel_theta: 1.0
  min_vel_theta: -1.0
  max_rotational_vel: 1.0
  min_in_place_rotational_vel: 0.8
  min_in_place_vel_theta: 0.8

  #The velocity the robot will command when trying to escape from a stuck situation
  escape_vel: -0.2

  #For this example, we'll use a holonomic robot
  holonomic_robot: false

  #Set the tolerance on achieving a goal
  xy_goal_tolerance: 0.20
  yaw_goal_tolerance: 0.15
  latch_xy_goal_tolerance: false

  #We'll configure how long and with what granularity we'll forward simulate trajectories
  sim_time: 1.5
  sim_granularity: 0.025
  angular_sim_granularity: 0.025
  vx_samples: 3
  vtheta_samples: 20
  controller_frequency: 10.0

  #Parameters for scoring trajectories
  goal_distance_bias: 0.8
  path_distance_bias: 1.0
  occdist_scale: 0.01
  heading_lookahead: 0.325

  #We'll use the Dynamic Window Approach to control instead of Trajectory Rollout for this example
  dwa: false

  #How far the robot must travel before oscillation flags are reset
  oscillation_reset_dist: 0.05

  #Eat up the plan as the robot moves along it
  prune_plan: false

  # Global Frame id
  global_frame_id: odom_combined

The footprint of the robot is :

#The footprint of the robot and associated padding
footprint: [[-0.08, -0.32], [-0.08, 0.32], [0.74, 0.32], [0.74, -0.32]]
footprint_padding: 0.01

Update 1:
So, it turns out the problem is with the robot_footprint. If I change the robot_footprint so that base_link is at the center of the robot by making footprint: [[-0.41, -0.32], [-0.41, 0.32], [0.41, 0.32], [0.41, -0.32]] and change the transformations accordingly, it seems to be working now. But in the original robot_footprint, base_link was at the center of rotation of the robot whereas in this case, base_link is at the geometric center of the robot (not center of rotation ...

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2015-10-20 19:11:17 -0500

nyquist09 gravatar image

Your planner samples trajectories and scores them. With the vx_samples and vtheta_samples you define how the linear and angular velocity space is sampled.

That means: if you have vx_samples: 3and vtheta_samples: 20 the planner simulates trajectories for 3 different velocity inputs and 20 different angulat velocity inputs. So in the end a trajectory of one of the discrete vx_samples is scored, i.e. /cmd_vel is set to one of the 3 distinct vx_samples.

What you can do is increase vx_samples to something like 10 ~ 20 to allow for a finer discretization of your velocity sample space, i.e. the base controller can choose between 10 ~ 20 different velocities.

edit flag offensive delete link more


Thanks @nyquist09! Increasing vx_samples helped but changing sim_time: 1.0 from sim_time: 1.5 helped more than that and it improved the results a lot and I am not exactly sure why? Do you know why reducing sim_time helped that much? TIA

Naman gravatar image Naman  ( 2015-10-21 10:05:57 -0500 )edit

Are you working in a constrained environment? Essentially you've given the robot less time to look ahead. So potentially getting close to objects isn't happening that often, which means the robot thinks it is OK to drive faster.

dornhege gravatar image dornhege  ( 2015-10-21 10:56:45 -0500 )edit

No.. I am working in a room of dimensions 5m x 11m with very few obstacles.

Naman gravatar image Naman  ( 2015-10-21 12:18:58 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2015-10-15 14:34:49 -0500

Seen: 1,781 times

Last updated: Oct 21 '15