Quantcast
Channel: ROS Answers: Open Source Q&A Forum - RSS feed
Viewing all articles
Browse latest Browse all 74

doubt regarding cmd_vel published by move_base

$
0
0
Hi all, **(See Update 2)*** I am using [move_base](http://wiki.ros.org/move_base?distro=jade) 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](http://wiki.ros.org/amcl?distro=indigo) for localization and [move_base](http://wiki.ros.org/move_base?distro=indigo) 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) 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

Viewing all articles
Browse latest Browse all 74

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>