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?
Mike,
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.
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.
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.
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.
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.
All,
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.
I currently seem to be having a use case where running the global planner (working on large maps) and the local planner on separate computers is desired. The global_planner on some heavy stationary computer and the local planner on the lightweight robot itself.
Splitting the nav stack into nodes enables this of course, but is that something the nav stack is currently pursuing?
As a robotic engineer, I would be grateful if you (and your team) improve the GlobalPlanner such as it takes into account the FootPrint of the robot. In the Ros1’s nav_stack, the GlobalPlanner does not take into account the footPrint which may cause some difficulties.
I’m interested in using the ROS 2 variant of the navigation stack for a simple navigation task, namely, follow a given nav_msgs::Path without caring about obstacle avoidance or anything else.
Are the tools needed for this task already ported to ROS 2? After going through bits of the ROS 1 documentation, it seems that move_base would be the component to use, but AFAIK, that is not ported to ROS 2. Anything I’m missing? What would you suggest for the application at hand?
P.S. @mkhansen thanks for your efforts on the library migration.
ROS Discourse is for news and general interest discussions. ROS Answers provides a forum which can be filtered by tags to make sure the relevant people can find and/or answer the question, and not overload everyone with hundreds of posts.