Revision history [back]

What are the actual limits of your system? Can it accelerate at the rate you set in that launch file (1.5 meters per second)? Can you smoothly command a speed of 0.05 meters per second using just plain cmd_vel? If not, you'll have to set the min_vel to the lowest speed you can smoothly command via cmd_vel.

Also, while commanding a speed via cmd_vel, you should plot the speed reported by your robot's odometry. An example of this would be rxplot /cmd_vel/linear/x,/odom/twist/twist/linear/x. This will give you a plot with two graphs, one for the commanded velocity and one of the reported velocity (both over time). If those graphs do not match up (e.g. odometry reports the robot is not moving while the command is set and the robot actually is moving), you can see some strange behavior from move_base, since it expects the base to actually carry out it's commands.

UPDATE to address loop rate discrepency.

!! 10KHz!!! Ya, I would not expect move_base to get ANYWHERE close to a 10KHz output rate. For each controller loop cycle, move_base is doing a trajectory rollout (dynamic window approach), updating the costmaps, replanning, etc. I don't think I've ever heard of someone attempting to use move_base at a rate nearly that high before. Note that move_base isn't a control loop, it's calculating commands to send to the robot's control loops, so it shouldn't need to run at a very high rate.

Is there any reason your base needs to receive commands at 10KHz? Or some rate much greater than the default 20Hz?

If you need to, you could write some sort of repeater node that would take the slow updates from move_base and repeat the last one at the very high rate that you require, though I'm not sure how well ROS publishers/subscribers handle sending/receiving at something like 10KHz.