A bit late, but I figured I would chime in (having been a maintainer of the navigation stack for going on 5 years now).
First, I concur with the several comments about better modularity. I’d almost suggest that the ROS2 navigation stack shouldn’t include any planners in the main repo (as is the case with MoveIt). There have been several newer (and probably better) planners developed – but users assume they should use only the “default” planners. At the same time, maintaining a code base that includes “all the planners” is just not feasible. Having better modularity, and having things like local and global planners exist in other repos, makes it far easier to have more maintainers involved, and for development to proceed quicker (if you don’t like planner X, go write and release planner Y).
While splitting those things out to other repos, I would suggest providing some basic/core code to build planners on. At some point a Willow Garage intern started to refactor base_local_planner in that direction – but it was never really finished.
On the subject of 2d/3d – I think there is a fine balance to walk here. While most research is pushing more in the 3d direction, commercialization tends to push towards cheaper/smaller processing power – and some of the optimization in terms of 2d/2.5d in the navigation stack is important here. While a full 3d mode is awesome, requiring the whole system to always act as 6Dof pose + 3d terrain may make it unusable on smaller platforms like Turtlebot.
With regards to not being monolithic – I think this will be a serious challenge. One of the things that ROS1 does a really poor job of is synchronizing the operations in multiple nodes. I’m not sure how much ROS2 really helps in that regard.
But here’s my most important feedback: we need better testing. One of the reasons we have a hard time merging things in the current navigation stack is that there is just almost NO test code (similar issues with MoveIt). I have spent an enormous amount of time physically testing code in simulation or on real robots to try and be sure something contributed works – only to find out that it actually breaks some particular feature that someone was using. If you’re going to largely overhaul/rewrite things – do it in a test-driven way, and make sure those tests are meaningful so that the system can actually be maintained.
Has anyone looked at what other ROS2 dependencies are missing? AFAIK, there is no equivalent of actionlib yet (which is probably a pre-req to actually building most robot applications in ROS2). I’m also not sure the status of things like parameter management or dynamic reconfigure (highly required for people to actually tune a navigation setup in a reasonable amount of time).
-Fergs