ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

local costmap window slowly drifts over static global map

asked 2019-01-31 21:12:06 -0500

ed gravatar image

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?

edit retag flag offensive close merge delete


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...

mgruhler gravatar image mgruhler  ( 2019-02-01 01:04:43 -0500 )edit

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.

ed gravatar image ed  ( 2019-02-02 09:09:35 -0500 )edit

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.


mgruhler gravatar image mgruhler  ( 2019-02-04 00:32:39 -0500 )edit

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 ...(more)

ed gravatar image ed  ( 2019-03-16 10:53:43 -0500 )edit

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

mgruhler gravatar image mgruhler  ( 2019-03-18 05:06:46 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-12-03 19:47:36 -0500

ed gravatar image

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

edit flag offensive delete link more


@ed all good. Happy you figured out what the issue is.

mgruhler gravatar image mgruhler  ( 2019-12-04 01:24:49 -0500 )edit

Question Tools

1 follower


Asked: 2019-01-31 21:12:06 -0500

Seen: 449 times

Last updated: Dec 03 '19