wow, very detailed, and right, it’s what I meant…
All, thanks for the input so far, keep it coming!
A few comments.
- I plan to create a github.com repo for this (hopefully under github.com/ros2 namepace, working on that), and will start capturing the wish list items and requirements, as well as documenting design decisions, etc. This thread is just the primer for that.
- The many different types of maps requested, to me means we need a more abstract data type for maps, that can represent many different types of maps that might be inputs to the system. I’m not sure what that will be exactly yet, but to me, this illustrates that we need to decouple the map type as much as possible from the system.
- I also agree on the use of ROS2 nodes for the low level plug-ins like global and local planning. That will improve decoupling and make it easier to replace those components with other algorithms, and will also ease the debug effort as pointed out before. We can do this using shared memory pointer passing so that the performance overhead is small.
Keep the feedback coming!
To enable autonomous navigation, you have to allow the robots to sense the environment around to create its map and enable collision avoidance, In other words, sensor data input to any algorithm is important.
Now there are various sensor solutions serving for this purpose, for example, Sonar, Lidar, MMW, Vision and so on they serves different preference and it’s possible to sensor fusion with them in the real autonomous navigation. Free to think ROS2 navigation can consider more:
- general flexibility to smoothly use their output in different phase of autonomous navigation
- how to adapt their combination or sensor fusion well while engaging with ros2 navigation stack
- consideration to certain solution with upcoming trend or innovation to extend, for example, for vision based, it may not require to create map firstly to navigation in the future.
Late to the party, but here’s my $0.02. Generally, +1 to all of Geoff Biggs’ coimments. I’d like to see:
- More pluggability in the elements of the nav stack, and the ability to hot-swap implementations.
- A common API that will allow people to add their own underlying representations.
- The ability to handle time. I’ve been toying with the idea of a map that changes throughout the day (as corridors become congested, and such), so the ability to integrate this into the system would be important to me as a specific use case.
- The ability to run more than one algorithm at a time, compare the results and mux them. This is important for localization, where it can be used to compare the performance of two algorithms, or to use different algorithms at different time.
- Factoring things up as finely as possible. As Geoff pointed out, this should be more lightweight in ROS2
- Ability to develop in Python or C++.
- Use floats or doubles as the underlying representation, not some fixed-point hack. Actually, it might be nice to use arbitrary underlying representations (of probabilities).
- Some more modern algorithms from the literature.
- Being able to swap maps in and out of core seamlessly, so that I don’t have to keep all of campus in memory at the same time.
- Multiple floors in a building. Hybrids to let me get from one building to another.
I’d be interested in having our group here at Oregon State help with some of this, depending on where it goes.
Not really a navigation stack user myself, so just passing by, but I was surprised
move_base_flex wasn’t / isn’t mentioned more. Only @Jeremie mentioned it once earlier in this thread.
Move Base Flex (MBF) is a backwards-compatible replacement for move_base. MBF can use existing plugins for move_base, and provides an enhanced version of the planner, controller and recovery plugin ROS interfaces. It exposes action servers for planning, controlling and recovering, providing detailed information of the current state and the plugin’s feedback. An external executive logic can use MBF and its actions to perform smart and flexible navigation strategies. Furthermore, MBF enables the use of other map representations, e.g. meshes or grid_map This package is a meta package and refers to the Move Base Flex stack packages.The abstract core of MBF – without any binding to a map representation – is represented by the mbf_abstract_nav and the mbf_abstract_core. For navigation on costmaps see mbf_costmap_nav and mbf_costmap_core.
Would seem to be a good idea to get some input from its maintainers (@spuetz et al.).
Yes, I was overjoyed when I saw
move_base_flex announced at ROSCon last year. I consider it a major step in the direction I want to see the navigation stack go. I haven’t had time to try it out myself yet, but I agree with @gavanderhoorn that any effort to develop a new navstack for ROS2 should consider it the biggest input into design.
We’ve created a repo for the ROS2 Navigation project here:
We’re going to collect all design inputs, here, starting with high level use cases and requirements:
Please submit your use cases and requirements via pull requests so we can have design discussions there.
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).
I’m quite late to the party. Sincere apologies.
A simple way to switch from 2D (which can be the default) to nD would be awesome. By n, I mean 2.5, and 3 (and community might come by with weird n = 1, 1.5 or 4). It might not be sensible to support 3D always, but flipping a switch to turn 2D off and 2.5D or 3D on would be a god-sent.
It might be not be possible but I would like some approach similar to how ROS Control allows addition and removal of resources and then allows selection of control system based on free resources. This would allow people to swap between different types of maps (2 different 2D maps for different conditions or 1 2D map for exhibition and a 2.5D map for rest of the building) and thus different kinds of planners and localization (or SLAM) modules. The swapping time would require either both navigation stacks to work together during transition period and come to consensus or the robot has to come to stand still.
The inspiration for this comes from node lifetimes in ROS2.
Also, on a separate note, I expect the Navigation stack would have to use matrix multiplication somewhere or the other. Can Eigen/Boost math libraries be used(or provide compile time option to choose the preferred version) instead of rolling a new math library?
Thanks for the input, I was actually going to reach out to you directly and ask if you want to participate. I can see your point that maybe putting the planners in a separate repo might be a good idea for modularity. I also see your point on the difficulty of supporting 3D Navigation. We’ll need to discuss that one more. I’m trying to start first with use cases, and there are both 3D and 2D+elevation ones that need to be discussed.
I really hope you’ll participate and contribute, your expertise is welcome!
@tyagikunal - thanks for the input. I agree we need to look at the math libraries. I believe Eigen is already being used in the ROS Nav stack, but we’ll look at all options.
Great input. Let’s start collecting some of this into the repo. https://github.com/ros-planning/navigation2
Also, we welcome the help from OSU, I’ll follow up with you on that one directly.
ROS2 helps significantly in that regard. I don’t want to say it’s a magic bullet, but synchronising the execution of multiple nodes that make up a single navstack should be easy in ROS2.
Navigating in Lineworld is hard.
We have been using parts of the nav stack for quite some while now, however, we were using our own state machines instead of the default move_base one. Recently we switched to https://github.com/magazino/move_base_flex so we could implement our own high level logic and switch planners on run time, e.g. docking planner, wall following planner, line following planner, default dwa_planner. But I think the best thing of move base flex is the action interface. This also allows users to implement planners in python that are not dependent on the costmap_2d representation. We have been using https://networkx.github.io/ for example to draw graphs with rviz and plan routes along this graph and follow these paths with a line follower using LQR or simple PD controllers. I am also involved in the Robocup@Home competition, here we often have to various areas instead of poses. Therefore, we expressed our goals with goal constraints instead of poses ( https://github.com/tue-robotics/cb_base_navigation ). This allowed for sending goals like: ‘In front of the table’ or ‘close to the sofa’ or ‘in the living room’. Long story … to sum up, our wish list:
- More rich goal definition (volumes or constraints) on geometric level
- Action interface for planners / controllers and recovery on geometric level that is independent of planning representation (enables implementing planners / controllers in other languages + own world models + custom top level behavior)
- Action definition for topological planning that relates to geometric plans / goals
- Playground package with simple simulator that provides an overview of the various planners and controller combination that people can try.
I’d like to also give a vote on the ability to develop in Python the different parts of the navigation stack.
In general, thank you all guys for thinking about all these very important and interesting improvements for the next version!
Several people have mentioned move_base_flex. For another take on the ActionLib interfaces, you might check out http://wiki.ros.org/flexible_navigation . This slightly pre-dates move_base_flex and was designed to work with FlexBE, but shares many of the same motivations to separate the planning and logical control.
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.
If you’re interested in our ROS2 Navigation plans and status, we’re going to start a regular working group to discuss.
Our first WG will be this Thursday, 8/2/18, at 8am Pacific time. If you are interested in joining, message me with your email and I’ll send you an invite.
Update - due to a conflict, I have to move the Kick-off meeting to 7am Pacific time, still on Thursday 8/2. If you’re interested, message me with your email address.
Sorry, thanks a lot for the invitation, but I completely missed it (summer mode…). Will try to join to the next one. I reviews the notes, though.