Planner vs controller responsibilities

Navigation Stack
,
1

Me and my team are having a hard time understanding the responsibilities of the components of the navigation stack and would like to open a discussion, as we believe others might also benefit from this clarification.

The original problem is the following. Most of the controllers provided are unable to find their way around dynamic obstacles. They are only controllers that follow the global path, assuming only small deviations from it, but certainly not to a path planning extent that would be possible on the local costmap.

The turtlebot demo includes an obstacle layer on the global costmap, and replans regularly, which means it is meant to help with obstacle avoidance. This gives rise to a few problems.
It is not necessarily suitable for huge maps (few hundred meters). The computational effort can be mitigated by less frequent replanning, on the expense of reaction time.
This also brings the question, what is the point then of the local costmap? For only collision detection nav2 now has the collision monitor, and obstacle avoidance could be fully delegated to the “global” planner.

Two ideas come to mind to resolve this problem.
Using route server (which is not implemented yet, but suppose it is) to overcome the problem of planning on huge maps, use a rolling global costmap for obstacle avoidance and local costmap for control. Then I still don’t see why the local costmap is needed at all other than collision detection.
Or using an “intermediate” planner. This would mean that the global costmap doesn’t include dynamic obstacles and because of this doesn’t need replanning. There would be an intermediate planner, which would take the global plan and based on it, create a new plan on the local costmap (for example take the last pose of the global plan that is still on the local costmap and plan to that). this “intermediate planner server” would have to be in the same process as the controller server so they can share the costmap instance on which to plan.

I know these are very broad ideas. The point of my question is more of an intuitive understanding of the scope of responsibilities of the components, than an actual feature request.

5 Likes
2

I think one phrase you should do some research into is Hybrid Planning, which is the separation of concerns that we use generally in mobile robotics land and more recently in MoveIt2 which you’re describing. I’m not going to go into detail about it in general since there is a wide body of literature, courses, and explanations available by searching the phrase which will be more detailed and complete.

The replanning can be for many reasons, such as trying to find better routes through a space given current information about the environment. Its not all just about obstacle avoidance, it can be about refining behavior or using new non-obstacle semantic information to make better trade offs. With that said, some use the BT structure to remove consistent replanning in exchange for event-based replanning when something goes wrong or it becomes necessary. This is one trivial example of the many ways you can use behavior trees to design complex and/or specialized robotic behavior for your application. You should pick the best behavior that is appropriate for your application, what you’re trying to accomplish, behavior, environment, etc.

This is for the local trajectory planner, not the global route planner. The local costmap can have different characteristics, process different types of sensor data, or consider more granular information about the robot or its environment. The controllers in Nav2 don’t simply follow paths as you suggest. The local costmap is frequently setup differently than the global costmap to perform its task (simple example: no static layer since you want to control based on the perceived world independent of localization error).

I don’t want to get lost in the myriad of ways you can customize or setup Nav2, but for another example you could not use a global planner at all in favor of a general route planner through a navigation graph or via GPS breadcrumb following and you need a local environmental model to do the actual trajectory planning to be collision free considering the real world around you. That necessitates the local costmap and there are users that deploy Nav2 that way.

So suffice it to say that even for a generic warehouse AMR use-case, there is real value in a separate local trajectory planner environmental model. Some may make more use out of it than others, but it has value nonetheless. It has even more value for less indoor-warehouse-y applications which we have many of in the Nav2/ROS world.

This is not accurate, but I can understand why you feel that way and most are setup by default to generally follow paths but that is far from all that they can do. Especially MPPI and DWB which are objective-scoring based controllers that can be setup to do any number of things very well. I think its important not to mix up what we give to you out of the box in terms of configurations and critics as somehow the “limit” of what’s possible. Moreover, many professional users have their own customized algorithms which do what they need them to do for their precise application to optimize for that last few percentage points of efficiency for their exact environmental, behavioral, and application constraints. That’s why we have plugins everywhere, to actively support extensibility and customizations within the framework.

But overall, this text makes me point back up to Hybrid Planning and that the default out of the box behavior might not be properly optimized for what you are looking to do, but its a framework, not a rigid one-size-fits-all solution which allows users to tune, tweak, extend, etc to get what they want done, done. We have users that demonstrate Nav2 in use from rigid line-following to highly dynamic social situations; operating in a home to a 2M sqft warehouse and everything in between. I won’t claim that there aren’t areas of improvement, there’s always places that we can be better/faster/stronger/more flexible/more options/etc. But, its far from as rigid as what I think your question implies. :slight_smile:

There are alot of applications of mobile robotics technologies and some need or desire different types of behavior. For example,

  • An assembly line following robot in a factory where deviation is bad unless explicitly asked
  • A robot in a convention center that has a general objective of getting back to the kitchen, but the route it takes to accomplish this wildly varies

Frameworks like Nav2 support both use cases, so some features might not necessarily be as important to some users as others.

https://docs.nav2.org/concepts/index.html#navigation-servers

7 Likes