A preface to this is that this is my personal experience on this subject matter. I cannot speak to ever variant of sampling-based planning nor every library that implements them, but this has been my experience genuinely trying several because I would have rather used pre-existing libraries than build something myself (which I ended up needing to):
You're talking about 2 major sets of algorithms: local trajectory planners (e.g. DWA, TEB) and global path planners (e.g. A*, Dijkstras). Each have their own areas of research and relationships with techniques like RRTs but I'm going to focus on Global Path Planning, since that is typically what new robotics engineers typically are thinking about when they think about RRT.
For realistically complex global environments, RRTs seem to fail to produce good quality results in a regular timeframe. In many situations using common libraries like OMPL, I could request 3 very similar goals and one would take 100 ms, another 4 seconds, and another would hang indefinitely. The actual quality of the path is usually quite low and would involve significant post-processing to make it something drivable and produce 'reasonable' behavior to any bystander watching the robot. There are of course additional constraints you can place on this for cost information, types of primitives used to expand the sampling, and such. Even after having investigated that at some length, I never got path results I felt were worthy of releasing a supported planner within the Nav2 ecosystem for -- let alone run-time competitiveness with other planners and predictability of runtime.
Heuristic Search-based planners however are very effective and provide baseline guarantees on performance and optimality. When I request 3 similar goals, they take similar amounts of time to complete and do not require (strictly speaking) any post-processing before handing it off to a local trajectory planner to track (though certainly in some situations some post-processing would be helpful, but it is not a minimum requirement to make predictable / rational behavior). They run quite fast, generally speaking as fast as I'd ever require them to. The determinism is important as @gvdhoorn points out when we're conducting regular replanning, not simply planning once as following it for indefinite periods of time. Typical planning times for Search are well under 200ms, while that would be irregularly achieved with sampling based planners based on RRT variants with the necessary constraints to make a rational path through the environment - plus needing an additional 100ms+ for some involved optimization-based smoothing to make it drivable.
For something like a local trajectory planner though, sampling approaches are of particular interest. Since in the local time horizon (lets say 5-10 seconds, typically) we're not dealing with complex global environments where we need to weave between corridors or find your way through what essentially could be considered a simplified maze. We're only dealing with what's right in front of us trying to maximize some objective function like following a path or staying far away from ... (more)
Just a quick note: probably because there weren't any suitable implementations of those algorithms at the time the main
navigation
planner packages were created.And "suitable" in this case could mean:
and something to also consider: RRT is inherently stochastic. (many of) the alternatives you list are deterministic. Determinism is a desirable feature for planning algorithms for mobile robots.
thanks for letting me know, i am a beginner in motion planning and path planning techniques, when i was reading book of LaValle it occured to me that RRT or RRT* with inbuild differential constraint can negate the requirement of two different planners. what you say about RRT to be stochastic or or problematically complete is also true.