The significance of acceleration limits

Question

This is a sequel to my earlier question here. I am trying to get move_base navigate through a set of goals. My config files are exactly those given in the earlier question. I am running move_base on a robot , which is very heavy - around 200 kg. I find that move_base's velocity commands move the robot very slightly every 10 minutes - a few mm for a goal of a few metres. I wonder if acceleration limits are significant here?

Note: With plain cmd_vel, the robot moves much faster. I don't have sensing nodes yet , so am publishing on /scan using the code here .

Update after Eric's comment: I determined the acc/vel limits, and when I ran cmd_vel commands at a very high frequency (3KHz), rxplot showed /odom/..linear/x rising to /cmd_vel/linear/x quite rapidly and the robot was moving very smoothly. The problem is, move_base doesn't send out cmd_vel commands at this frequency, it just sends it once ; this isn't enough to sustain motion. What param should I adjust in config? Changing controller frequency doesn't help. Or should I hack into move_base code and force it to transmit cmd_vel commands for say 1s continuously?

Update 2: I did the rostopic hz part & found that, even with a given controller frequency of 10KHz , move_base was sending out commands only @ around 600 Hz. I'm unable to understand this discrepancy. Should I send you more data?

Update 3: I have fixed this, finding a concurrent process running that was publishing zeroes to /cmd_vel. So the cmd_vel publisher causes the robot to run smoothly @ 20 Hz. But doing the same thing for move_base causes rostopic hz /cmd_vel to report .1 Hz! I really can't figure out why?

---

Originally posted by PKG on ROS Answers with karma: 365 on 2011-07-22

Post score: 1

---

Original comments

Comment by Eric Perko on 2011-07-23:
That's rather odd. move_base should send commands once per controller loop (default 20Hz). Could you update your post with a plot of move_base's commands? How often does move_base actually send a command ('rostopic hz /cmd_vel' while move_base is the only thing running could help you here)?

Answer 1

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.

---

Originally posted by Eric Perko with karma: 8406 on 2011-07-22

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by Eric Perko on 2011-07-23:
What you should determine is why your system won't have smooth motion if given commands at something just over 100Hz, say 150Hz. If the controller expects commands at 100Hz and you give it commands with rostopic pub at just over 100Hz, I would expect a properly done controller to be smooth.

Comment by Eric Perko on 2011-07-23:
move_base should never really run at that high of a rate. Each loop is supposed to be doing obstacle checks, acceleration limit checks, planning, etc so a rate of almost 3KHz would be very difficult to achieve.

Comment by PKG on 2011-07-23:
The cmd_vel listener is a controller that takes in commands every 10ms or so. That gives a value of 100Hz to the cmd_vel publisher to keep the controller fully engaged. For reasons not clear to me yet (I'm not a control systems person), increasing the frequency of cmd_vel to 3KHz gets smooth motion. I actually tested this out experimentally yesterday. That's why I am anxious to make move_base respond at the same rate.

Comment by Eric Perko on 2011-07-23:
Hmm... that's interesting... why is any slower rate jerky motion for the vehicle? Is the cmd_vel listener a controller that expects to receive velocity commands at 3KHz and is timing out?

Comment by PKG on 2011-07-23:
Well, 3 KHz is the "right" rate for my cmd_vel commands; anything less is very slow , jerky motion for a heavy vehicle. I deliberately stretched that to 10KHz to see what move_base would do. Interestingly, wrapping up move_base's cmd_vel publish command in a time loop (while time<desired_time do {cmd_vel_publish();}) forces move_base to move the vehicle quickly. I don't know a "legal" way to achieve 3KHz in move_base, and am not sure about your repeaters.

Comment by madmax on 2013-11-12:
Why are you always writing kHz?? I think you all mean hz, don't you?

Comment by Eric Perko on 2013-11-12:
We did mean kilohertz when writing KHz. That was most of the reason it seemed exceptionally high and difficult for move_base to achieve. 10 hertz would be a pretty standard rate. 10 kilohertz was higher.