RRT* alternative planner #7
Conversation
|
Hi @estherag I see a problem with the stability of the path creation, as I saw in the video. If the planner keeps updating so different plans during the first few steps continously, the robot may end up oscillating all the time. I would suggest that if the algorithm has a metric to evaluate how good or bad a plan is, then once a plan is generated, it should not be replaced unless the new one is significantly better. This “significantly” could be defined through a configurable threshold, acting as a margin that determines when the new plan is good enough to justify switching to it. |
|
Or maybe, to avoid oscilation, It could be enough to take into.comsideration no only the start posición, but also the robot orientation. It could produce reactive paths, but the first steps could be more stable |
|
Yes, I noticed the same limitation. Initially, I only triggered replanning if the robot deviated significantly from the path or if a new goal was set. But with new obstacles, evaluating the map first and then replanning was too computationally costly. To ensure safety, I currently regenerate the path at each iteration, which leads to different paths across executions. To overcome this, I really like your suggestion to also consider robot orientation. I’ll add that along with a cost comparison metric to decide when the path should actually be updated. Thanks for the feedback! |
|
Hi, @fmrico I've updated the planner to only publish a new path when there are goal changes, robot deviations, or when a new path has a lower cost than the previous one. Path trimming now removes waypoints already passed by the robot. Path smoothing has been improved to reduce sharp turns and better preserve the goal orientation. I tried the orientation-aware planner but it generated unnecessary L-shaped turns, perhaps it would be a nice future work. Here is a video with the behavior, note that at the beginning I apply an offset to improve visualization in both the planned path (in green) and the actual path from the localization (in blue). rrt_simple_cont_trimmed_low.mp4 |
| result.push_back(node->rrt_node); | ||
| } | ||
|
|
||
| // Determine axis and distance along that axis |
There was a problem hiding this comment.
I have noticed that the indentation of most of the comments is not correct. This is not critical, but looks better
There was a problem hiding this comment.
I think it is because the automatic formatter I am using in VSCode, I will clean it!
|
Hi @estherag You did a good job. LGTM, if you don't want to correct the comments, we can merge. |
|
LTGM Merging!!! 🚀 |
2 participants
Hi!
I've added an alternative planner to this stack. It is an RRT* for gridmaps using slope-aware traversal cost, goal biasing, and KD-Tree acceleration for efficient searches.
The planner also includes Catmull–Rom spline-based path smoothing with minimal spacing enforcement to reduce redundant waypoints.
A demonstration video shows the planner in action using the EasyNav simple controller and LiDAR-SLAM for localization.
rrt_simple_cont_trimmed_low.mp4
Any feedback or suggestions are more than welcome! :)