# Odd "pulsed" acceleration when using amcl and move_base [closed]

Hello,

I am trying out amcl and move_base on a new home built robot that is similar to the TurtleBot but uses the Serializer microcontroller and Pololu motors and encoders. I also have a Hokuyo laser scanner.

I'm running the odometry loop at 20Hz and the robot can do dead reckoning fairly nicely. Next I created a small map of a couple of rooms using gmapping and that also looks good.

The trouble occurs when I then run amcl and move_base and set a navigation goal in RViz. The robot always gets to the goal fine and follows the planned path fairly well. However, as it is moving it does a kind of pulsed acceleration and deceleration, even when it is moving across a complete clear space. The frequency of the pulsing is about 2 seconds. Is this something that could be tweaked somewhere in the base local planner parameters? I am basically using the TurtleBot parameters for the planner and the cost maps so I won't post them here.

Thanks!
patrick

UPDATE: Jan 1, 2012: It seems I spoke too soon. I am still getting oscillations in cmd_vel as sent to the robot by move_base. I have posted a bag file here demonstrating the phenomenon. I am running move_base with a blank map and fake localization. Then I set a nav_goal about a meter ahead and slightly to the right of the robot in an otherwise clear area. If you rxplot cmd_vel you can see the oscillations in the x component which are very noticeable when watching the robot. For move_base, I am using essentially the identical parameters as in the turtlebot_navigation package.

Can anyone see the cause of this oscillation--perhaps some kind of asynchronization between /odom and /cmd_vel?

Update 2: Here is an rxplot of /cmd_vel/linear/x and /odom/twist/twist/linear/x with the robot up on blocks so the wheels are spinning with no resistance:

edit retag reopen merge delete

### Closed for the following reason the question is answered, right answer was accepted by Procópio close date 2018-02-20 08:57:08.462166

Have you looked at an rxplot of cmd_vel/linear/x and /odom/twist/twist/linear/x while this pulsing is going on? Do the commands pulse because of weirdness in the reported velocity or do the reported velocities pulse to follow pulsing commands?
( 2011-12-30 15:54:47 -0500 )edit
Thanks @ahendrix and @Eric Perko. I looked at cmd_vel/linear/x in rxplot and the robot was definitely being sent an oscillating velocity command. Since I wrote the odometry node for the Serializer I figured that was the weakest link. ;-) So I went back to the code and sure enough, I had used Python time() instead of rospy.Time() when computing and publishing odometry messages. Once I fixed that bug, the oscillations disappeared. So I'm guessing I had a small time synchronization error between odom messages and move_base.
( 2011-12-31 12:01:03 -0500 )edit
@Pi Robot: Can you plot rxplot /cmd_vel/linear/x,/odom/twist/twist/linear/x against the live system while you are seeing the oscillations? I can't seem to get it to plot on the same graph on your bag file, and this graph is the one that I think would be most illuminating.
( 2012-01-01 10:19:31 -0500 )edit
@Pi Robot: Just curious - are you able to create the rxplot while playing back from the bag file you posted or only against the running robot?
( 2012-01-03 19:37:33 -0500 )edit
@Eric Perko - I was not able to create the rxplot on the running robot either--then I discovered that I was not publishing a timestamp on the odom message header. Once I added the timestamp, I was able to get the plot. Unfortunately, adding the timestamp did not fix the oscillation problem.
( 2012-01-04 13:40:38 -0500 )edit

Sort by » oldest newest most voted

This post is a wiki. Anyone with karma >75 is welcome to improve it.

From comment above: Thanks @ahendrix and @Eric Perko. I looked at cmd_vel/linear/x in rxplot and the robot was definitely being sent an oscillating velocity command. Since I wrote the odometry node for the Serializer I figured that was the weakest link. ;-) So I went back to the code and sure enough, I had used Python time() instead of rospy.Time() when computing and publishing odometry messages. Once I fixed that bug, the oscillations disappeared. So I'm guessing I had a small time synchronization error between odom messages and move_base

more

@ahendrix and @Eric Perko -- please see Update to my original question.
( 2012-01-01 03:44:16 -0500 )edit

I've seen problems like this in the past when I've had multiple nodes publishing to the cmd_vel topic; usually move_base and teleop. move_base was sending movement commands, while teleop was sending stop. This usually manifested as stutter rather than pulsing.

An easy check would to be rostopic echo cmd_vel and look at what commands are being sent. You could also use rxgraph to look at individual fields in cmd_vel.

more

Thank you sir!!! I included teleop in my launch file and I completely forgot about it. It was secretly sending zero velocity commands the entire time!

( 2018-02-20 04:06:58 -0500 )edit

I was able to export some of the data to CSV using rostopic echo -p and plot it in Matlab.

The interesting behavior from that (assuming that the times are sync'd properly... which I'm not 100% confident about, since rostopic -p seemed to be ignoring use_sim_time and --clock when I tried to record them to CSV individually), is that the odometry lags a lot behind the commands. Being able to plot it in rxplot would make me a lot more confident about the possible time sync issue, but rxplot /cmd_vel/linear/x,/odom/twist/twist/linear/x only plots odometry, never commands. rxplot /cmd_vel/linear/x,/odom/twist/twist/linear/x is what the above Matlab plot is supposed to show.

Regarding the lag between command and odometry, I suggest you check the accelerations you are using. I feel like I've seen behavior similar to this when move_base essentially tries to command something, the robot doesn't really respond as expected, and then move_base backs off the command; after backing off, move_base tries to ramp up again, the robot again lags behind, etc etc. Where that behavior is coming from, I can't really say exactly, but I recall seeing behavior along those lines a while back.

Try lowering your acceleration values to see how that affects that rxplot. You are looking for a plot that may have a small static time offset (make sense, the robot doesn't instantaneously achieve commands), but otherwise the graphs should look the same (modulus noise in odometry). Since you aren't actually on a TurtleBot, it's entirely possible your accelerations are different.

more

Hi @Eric Perko. Thanks for all your time on this! I have added a second update to the original question with an rxplot of /cmd_vel/linear/x and /odom/twist/twist/linear/x with the robot up on blocks so the wheels are spinning with no resistance. I'm still setting the nav_goal in RViz on a blank map. So I think the offset between cmd_vel and odom is expected. What's odd is the saw-tooth periodicity in cmd_vel. I played around with acceleration limits but I always get the wave form.
( 2012-01-01 11:34:38 -0500 )edit
In the meantime, I have gotten my ArbotiX to work again instead of the Serialzier for PID control. The ArbotiX does not create the oscillation problem that the Serialzier does. I suspect that the difference is the superior driver @Fergs has for the ArbotiX. One of these days I'll try directly emulating his newest driver code for my Serializer driver to see if that fixes the problem.
( 2012-01-01 12:47:01 -0500 )edit
Hmm... having the oscillation go away with a different controller definitely points to your PID control - does it show oscillation if you manually set the command and hold it for a while? How about when you change commands?
( 2012-01-01 17:04:20 -0500 )edit
There is no oscillation if I manually publish /cmd_vel commands. In fact, the motion is very smooth and accurate. However I didn't try it with changing commands and now I have the robot all closed up again with the ArbotiX in control instead of the Serializer. When I get a chance I want to go back and try it again with a longer sim_time value for the base_local_planner. I was using 1.5 seconds but I noticed I get much smoother results with 2.5 seconds when using the ArbotiX. (Otherwise, the caster of the robot tends to fish tail around the desired path...)
( 2012-01-02 12:16:32 -0500 )edit