Local Planner Not Extending Beyond Robot's Footprint Boundaries to Distort Global Planner's Path

Question

I've been facing an issue with the local planner in my ROS2 navigation setup. The core of the problem seems to be that the local planner does not extend sufficiently outside the robot's footprint boundaries. This results in the local planner not having adequate "contact" with the local costmap, preventing it from effectively distorting the global planner's path when encountering obstacles.

I've visualized this behavior in several videos, which can be viewed here:

SMAC DUBIN + TEB

SMAC REEDS-SHEEP + DWB

Setup and Observations:

Robot Configuration: My robot is a truck with specific dimensions and footprint. The footprint is defined as: footprint: "[[-4.8025, -1.739], [4.8025, -1.739], [4.8025, 1.739], [-4.8025, 1.739]]".

Planners Tested:

Global Planners: Smac (Dubin and REED-SHEP) , ThetaStar, NAVFN Local Planners: DWB and TEB

Pictures (LOCAL PLANNER IS IN BLUE, GLOBAL IN RED): The global planner crosses the footprint boundary (green rectangle), but the local planner does not.

Behavior Observed:

Regardless of the combination of global and local planners, the local planner seems entirely submissive to the global planner's path.

Instead of deforming the global path to avoid obstacles, the local planner follows it.

Attempts to Resolve:

I've tried adjusting various parameters related to the local and global planners, including footprint configurations, costmap resolutions, and planner-specific parameters. I've also experimented with different motion models and cost functions. Despite these efforts, the core issue remains unresolved. Request:

I'm seeking assistance in understanding and resolving this behavior. It's crucial for the local planner to effectively distort the global path when necessary, ensuring safe and efficient navigation. Any insights, suggestions, or recommendations would be greatly appreciated.

Answer 1

After extensive debugging and parameter tuning, I identified the root cause of the issue and made significant improvements to the robot's path planning and obstacle avoidance behavior.

Turning Radius: The primary issue was related to the minimum_turning_radius parameter. Initially, it was set to a very low value (0.00001), telling the planner that the robot could make near-instantaneous turns. This is unrealistic for most non-holonomic robots. The planner started generating paths the robot could feasibly follow by adjusting this parameter to a more realistic value (2.0), leading to more predictable behavior.

Unknown Space Treatment: I also adjusted the unknown_cost_value parameter in the global_costmap. By default, unknown spaces are often treated as obstacles, causing the robot to stop when it encounters an unknown area. By setting this value to 120 (between free and lethal), the planner cautiously treats unknown areas but doesn't completely avoid them. This adjustment was particularly beneficial in dynamic environments, allowing the robot to replan paths based on new obstacle data.

With these changes, the robot now successfully avoids obstacles. However, there's still room for improvement. While the robot can navigate smaller obstacles like an ambulance, it struggles with larger obstacles like a bus. In such scenarios, the robot doesn't expand its search to farther regions to find a feasible path around the obstacle. Instead, it stops, which, while safe, isn't the most efficient behavior.

This video shows the fix for this issue: GPS waypoints follower +obstacle avoidance NAV2

Result:

Next Steps: To further enhance the robot's obstacle avoidance capabilities, I plan to:

Experiment with different combinations of path planner plugins (both local and global) to find the most suitable one for my robot and environment. Fine-tune the costmap layers, especially the inflation layer, to ensure the robot maintains a safe distance from obstacles. Adjust other parameters like the costmap resolution to make the obstacle avoidance more robust. In summary, while the current setup significantly improves the initial configuration, there's still work to achieve optimal performance, especially in complex environments with large obstacles.