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:
I like...
* plugin architecture
* highly (dynamically) configurable works in many robots just tweaking parameters
To improve...
* 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](
http://wiki.ros.org/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 dont 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.
---
[Visit Topic](
https://discourse.ros.org/t/ros2-navigation-input-requested/4884/29) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)