Sorry for the late answering!
@mkhansen, thanks a lot for starting this very interesting discussion.
As a ROS navigation user, answers to the initial questions:
- plugin architecture
- highly (dynamically) configurable → works in many robots just tweaking parameters
- zero tests! (good point @mikeferguson)
- poor ROS interface → hardcoded FSM
- plugin architecture also for maps
- rigid plugin interface, e.g. planning just to a pose; why not an area? or close to something?
- multimap, or partially loaded maps to avoid exploding RAM usage
Just to focus the discussion a bit more, and following @mikeferguson comment, to my understanding, what we are talking about is to re-design the navigation framework, that is, replace current move_base node and the plugin and ROS interfaces. More powerful planners and controllers are up to anyone to develop by herself using the new framework.
As Move Base Flex maintainer:
MBF already provides some of the features requested here. I can recall from previous comments:
- external executive
- tolerance on goals
- multiple planners and controllers, selectable an action goals
- simultaneous goals for planners and controllers (not yet finished)
And we are currently working on using grid_map. Instead of a plugin-based costmap interface, we have decouple the code into a general, abstract navigation scaffolding, extended by particular implementations making use of a particular map representation. The rationale behind this architecture is that the map representation is tightly linked to the planner/controller nature, and so it’s difficult to allow choosing your costmap back-end on run-time.
About separating components on different nodes, we decided to keep a single node to make available both costmaps to all components. But of course this is linked to using the plugin strategy. As @Edu and @gbiggs mentioned, ROS2 nodes grouping (or whatever is called the replacement to nodelets) offers new options potentially more flexible. But I don’t know enough about ROS2 to go beyond this vague comment.
All in all, it sounds reasonable to use Move Base Flex as a first step, or at least to borrow some features for the future development. And as MBF is still an ongoing project (though due to shortage of time, progress is way slower that we would like), we definitely want to align further development in the direction of ROS 2 nav.