local costmap window slowly drifts over static global map
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?
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...
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.
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.
Thanks.
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)
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