doubt regarding cmd_vel published by move_base
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.
baselocalplanner_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) but this works better. I am slightly confused now. Does anyone have any idea why is this happening?
Update 2:
As suggested by @nyquist09, increasing vx_samples
helped. Also, changing sim_time: 1.0
from sim_time:1.5
helped a lot and improved the results. But I am not sure why reducing sim_time
helped that much? Does anyone know why is that?
Thanks in advance.
Naman Kumar
Asked by Naman on 2015-10-15 14:34:49 UTC
Answers
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: 3
and 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.
Asked by nyquist09 on 2015-10-20 19:11:17 UTC
Comments
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
Asked by Naman on 2015-10-21 10:05:57 UTC
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.
Asked by dornhege on 2015-10-21 10:56:45 UTC
No.. I am working in a room of dimensions 5m x 11m with very few obstacles.
Asked by Naman on 2015-10-21 12:18:58 UTC
Comments