Rosanswers logo

I recently purchased turtlebot3 burger. I am running kinetic. I created a map using gmapping and explorer_lite. Next I started navigation. In rviz I set a goal 1 meter behind and in a rotated 90 degrees to the right. The robot starts to move backwards which it does not do well. It starts to buck up and down. The robot then stopped but the local costmap slowly consistently drifted backwards. This is the 2nd time I saw this happen. The first time it was a smaller map. in both instances the robot was stopped. Eventually I get a errors about DWA planner failed to produce a path and scans being out of bounds. The scans shown in the cost map still look look correct for the location of the robot. It just does not match the static map. Any ideas?

Originally posted by ed on ROS Answers with karma: 91 on 2019-01-31

Post score: 0

Original comments

Comment by mgruhler on 2019-02-01:
Without more information (maybe a screen vid? or even better a rosbag with all topics) it is hard to debug... What I've seen sometimes is that localization is drifting, even though the robot is standing still. This would explain all problems you describe. However, this is just a guess...

Comment by ed on 2019-02-02:
I retried with a bag recording but of course is did not happen. It might be tied when the battery getting low.I will update with a bag file when I can reproduce the issues.

Comment by mgruhler on 2019-02-04:
Please follow up with a response, once you found a solution. Also, if you didn't or if it didn't occur. This might help future readers.


Comment by ed on 2019-03-16:
Sorry I do not have a way to record. This is definitely only happens when the turtle3 burger battery gets low. I here a single beep. The robot stops moving but the local window keeps moving in the same direction at the same speed until the robot position on the local windows gets to the edge of the global map or over a know obstacle on the global map window. Then the local window stops moving and starts throwing all kinds of messages about not able to find a plan.

My theory is that some how the global planner continues to use that last speed and direction even though the robot is not moving. Something I need to check is if odom still being published by the raspberrypi after the beep.

This is difficult to diagnose as it only happens when the battery get low (every time for the 4 times the battery needed to be recharged) I guess I need to check the battery level before each run to decide when to record the data to a bag.

My work around is to just charge the battery.

Comment by mgruhler on 2019-03-18:
Well, if the battery gets low and the motors shut down, it could very well be that the odometry is still being published. If communication is down, some drivers still publish the last value.

My guess is that this is the problem


1 Answer 1


Rosanswers logo

As mgruhler said to opencr stops sending cmd_vels to the motors but the raspberry pi is still up and publishing the odom. The opencr is the one responsible for sending the odom through the pi. I have seen the wheel encoders to jitter back and forth and the imu also jitters a little. The opencr uses the imu for the orientation in odom and the wheel encoder jitter would produce some linear motion in the odom.

The opencr does make a sound but it is only a single beep and it is easy to miss. So now that I know what to look for I just simply stop and recharge.

mgruhler Sorry for stealing the points for answering but I didn't know how to upgrade you comment to an answer

Originally posted by ed with karma: 91 on 2019-12-03

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by mgruhler on 2019-12-04:
@ed all good. Happy you figured out what the issue is.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.