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

#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]]


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 close merge delete

Sort by » oldest newest most voted

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.

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

( 2015-10-21 10:05:57 -0500 )edit
1

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.

( 2015-10-21 10:56:45 -0500 )edit

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

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