doubt regarding cmd_vel published by move_base

edit

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.

base_local_planner_params.yaml

TrajectoryPlannerROS:
  #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 ...
(more)