ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Why RRT based algorithms are not the default choice in ROS for mobile robots ?

asked 2022-09-09 04:08:11 -0500

Rahulwashere gravatar image

Hello all, so my question is not related to some hardware or software issue, instead i wanted to ask why RRT based algorithms are not fundamental choices for ROS (i am using melodic), instead why a combination of (A*, Dijkstra etc) and DWA,TEB planners is used ? can anyone explain? i know there are rrt based packages but why they are not de facto choice ?

edit retag flag offensive close merge delete

Comments

1

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:

  • performance was lacking (ie: too slow)
  • under incompatible licenses
  • under control of an organisation with incompatible goals
  • etc

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.

gvdhoorn gravatar image gvdhoorn  ( 2022-09-10 02:53:09 -0500 )edit

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.

Rahulwashere gravatar image Rahulwashere  ( 2022-09-13 00:25:18 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2022-09-12 15:25:10 -0500

updated 2022-09-12 15:28:58 -0500

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)

edit flag offensive delete link more

Comments

Thank you for letting me know. it is often said that RRT based algorithms are really good at searching(planning) in high dimensional spaces where search based methods would not be appropriate(due to a high cost of representing the entire config space and then searching through it). if that is the case, how come RRT struggles with complex environments in ROS which is generally 2D or 3D. i also would be greatful if you can guide me to some books or material where kinodynamic planning is in detail? for most of what i have seen there is little material on it except research papers. Any open source code for ROS or something else can also help for me to understand.

Rahulwashere gravatar image Rahulwashere  ( 2022-09-13 00:29:13 -0500 )edit

Usually higher dimensional planning spaces aren't nearly as constrained in their configuration spaces than trying to find a solution through many maze-like corridors that realistic mobile robotic solutions have. Arms have their own joint limits, self collision, and external collisions, but I think trying to visualize this you'll see that its set up as a very different problem.

stevemacenski gravatar image stevemacenski  ( 2022-09-13 12:32:47 -0500 )edit

Thanks again! you are correct i guess but i need to look into it on my own as well.

Rahulwashere gravatar image Rahulwashere  ( 2022-09-15 01:31:42 -0500 )edit

Awesome, can you mark this as the right answer then to remove from the unanswered questions queue?

stevemacenski gravatar image stevemacenski  ( 2022-09-15 12:04:42 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2022-09-09 04:08:11 -0500

Seen: 354 times

Last updated: Sep 12 '22