Closed dschnabel closed 4 years ago
I noticed that my navigation stack was using 100% CPU and frequently missed update loops. This was because I had built all my packages in debug mode without optimization (CMAKE_BUILD_TYPE=Debug
). After I rebuilt everything in release mode (CMAKE_BUILD_TYPE=Release
) the CPU usage went down and no more missed update loops.
This also improved the path given by dwb_local_planner, so that my robot is now driving forward most of the time and more closely follows the global path. However, occasionally the robot stops and drives backwards bumping into obstacles. I need to further investigate and will update my findings here. Until then I'll leave the issue open.
Fiddled a lot with this lately. I had to make a few code changes to the PreferForwardCritic
and also stopped using the ObstacleFootprintCritic
because it's using too much CPU on my Raspberry Pi 4.
Instead I added a mechanism to the dwb_local_planner
to force recalculating a new global plan if there's an obstacle detected in the costmap which is on or too close to the global plan. This is giving me pretty good driving behavior.
Anyway, closing this issue as the mentioned code changes give me the results I was looking for. If interested I can share the code but not sure how helpful it would be to others.
I think there's something configured not quite right in my navigation stack, specifically in my local planner. If I set a goal 1 meter in front of the robot, then the global plan looks correct (the trajectory pointing in a straight line towards the goal) but the local plan points in the opposite direction. The robot starts backing away from the goal and does random rotations. It's not following the global plan at all and crashes into obstacles.
I would like to know why I'm getting trajectories that point away from my goal. Where would I start to look for the problem?
Used configuration for local planner: