Please see the following two videos about the behaviour of the robot (video1, video2). The robot sometimes moves pretty well, but sometimes just keep spinning around. Such behaviour really confuses me, and your help to solve it is greatly appreciated.
I use ROS navigation stack with dwa_local_planner. I have two computers: one on the robot the publish odometry and laser scan, and the other desktop running the navigation stack. Both computers are on a local network, and I use chrony to sync their time. However, my hunch is that the negative delay shown in tf_monitor (see videos above) might be the cause of it, but I'm not totally sure. Also, if you find other things in the video don't seem right, please let me know too.
Here is the setting of dwa_local_planner.
DWAPlannerROS:
# Robot configuration parameters
acc_lim_x: 2.5
acc_lim_y: 0
acc_lim_th: 3.2
max_vel_x: 0.5
min_vel_x: 0.0
max_vel_y: 0
min_vel_y: 0
max_trans_vel: 0.5
min_trans_vel: 0.1
max_rot_vel: 1.0
min_rot_vel: 0.2
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.2
xy_goal_tolerance: 0.2
latch_xy_goal_tolerance: false
# Forward Simulation Parameters
vy_samples: 0
# Trajectory scoring parameters
occdist_scale: 5
Here is the tf_tree
Thanks for your help in advance!
[EDIT]
One way that seems to bypass the problem for me is to increase acc_lim_x, acc_lim_th, and acc_lim_trans to really really high, even higher than the true limit of my robot (see video 6). All previous videos showed that, when the robot exists the rotating behavior, all candidate trajectories were somehow pretty short, which means that the velocity is very small. To force dwa_local_planner considering a wider range of velocity (hence wider range of candidate trajectories), one way is to increase acc_lim, because candidate velocities are determined by vel +/- acc_lim. While increasing acc_lim bypass this particular issue, it is still unclear to me why the dwa local planner, when the robot rotates, keeps choosing those trajectories of small velocities and therefore prevents speeding up toward the target.
Originally posted by PT on ROS Answers with karma: 234 on 2015-06-02
Post score: 3
Original comments
Comment by PT on 2015-06-03:
p.s. Once I increase the publishing rate of /odom to 100Hz, the delay of tf frames improved. However, the rotating behavior persists (see video). I also plotted the /cmd_vel, looks like it is the planner that wants to rotate the robot, instead of motor's problem.
Comment by David Lu on 2015-06-04:
What version of ROS is this?
Comment by PT on 2015-06-04:
it's Indigo
Comment by [email protected] on 2020-04-21:
who can recommend a param setting about costmap and dwa params?
