magazino / move_base_flex

Move Base Flex: a backwards-compatible replacement for move_base

Move Base Flex: A Highly Flexible Navigation Framework:

This repository contains Move Base Flex (MBF), a backwards-compatible replacement for move_base. MBF can use existing plugins for move_base, and provides an enhanced version of the same ROS interface. 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. For example, at Magazino we have successfully deployed MBF at customer facilities to control TORU robots in highly dynamical environments. Furthermore, MBF enables the use of other map representations, e.g. meshes. The core features are:

• Fully backwards-compatible with current ROS navigation.
• Actions for the submodules planning, controlling and recovering, and services to query the costmaps are provided. This interface allows external executives, e.g. SMACH, or Behavior Trees, to run highly flexible and complex navigation strategies.
• Comprehensive result and feedback information on all actions, including error codes and messages from the loaded plugins. For users still relying on a unique navigation interface, we have extended move_base action with detailed result and feedback information (though we still provide the current one).
• Separation between an abstract navigation framework and concrete implementations, allowing faster development of new applications, e.g. 3D navigation.
• Load multiple planners and controllers, selectable at runtime by setting one of the loaded plugin names in the action goal.
• Concurrency: Parallel planning, recovering, controlling by selecting different concurrency slots when defining the action goal. Only different plugins instances can run in parallel.

Please see also the Move Base Flex Documentation and Tutorials in the ROS wiki. And this repository contains a working minimal configuration for a turtlebot 3.

Concepts & Architecture

We have created Move Base Flex for a larger target group besides the standard developers and users of move_base and 2D navigation based on costmaps, as well as addressed move_base's limitations. Since robot navigation can be separated into planning and controlling in many cases, even for outdoor scenarios without the benefits of flat terrain, we designed MBF based on abstract planner-, controller- and recovery behavior-execution classes. To accomplish this goal, we created abstract base classes for the nav core BaseLocalPlanner, BaseGlobalPlanner and RecoveryBehavior plugin interfaces, extending the API to provide a richer and more expressive interface without breaking the current move_base plugin API. The new abstract interfaces allow plugins to return valuable information in each execution cycle, e.g. why a valid plan or a velocity command could not be computed. This information is then passed to the external executive logic through MBF planning, navigation or recovering actions’ feedback and result. The planner, controller and recovery behavior execution is implemented in the abstract execution classes without binding the software implementation to 2D costmaps. In our framework, MoveBase is just a particular implementation of a navigation system: its execution classes implement the abstract ones, bind the system to the costmaps. Thereby, the system can easily be used for other approaches, e.g. navigation on meshes or 3D occupancy grid maps. However, we provide a SimpleNavigationServer class without a binding to costmaps.

MBF architecture:

Future Work

MBF is an ongoing project. Some of the improvements that we have planned for the near future are:

• Release MBF Mesh Navigation, see mesh_navigation.
• Auto select the active controller when having concurrently running controllers
• Add Ackermann steering API
• Multi Goal API + Action
• Add new navigation server and core packages using grid_map.
• Constraints-based goal (see issue #8)

But, of course you are welcome to propose new fancy features and help make them a reality! Pull Requests are always welcome!

Build Status

ROS Distro	GitHub CI	Develop	Documentation	Source Deb	Binary Deb
Melodic
Noetic

move_base_flex's Issues

[move_base_legacy_relay.py] action result: status, error_msg

logdebug message in move_base_legacy_relay#L41 is incorrect: move_base_flex_msgs/action/MoveBase.action does not have fields result and error_msg.

This will end up with following stacktrace:

[ERROR] [1504259614.237105, 752.653000]: Exception in your execute callback: 'MoveBaseResult' object has no attribute 'status'
Traceback (most recent call last):
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/actionlib/simple_action_server.py", line 289, in executeLoop
    self.execute_callback(goal)
  File "/home/me/ws/src/move_base_flex/move_base_flex/scripts/move_base_legacy_relay.py", line 43, in mb_execute_cb
    rospy.logdebug("MBF execution completed with status [%d]: %s", result.status, result.error_msg)
AttributeError: 'MoveBaseResult' object has no attribute 'status'

GridMap Library Integration / Navigation Server

Since the move_base_flex allows to make implementations using different map representations (costmaps/gridmaps etc..), has there been a thought of making something like a AbstractMap from which one of these could be inherited/plugin-ed?

To give a context, I toyed around gridmaps and made mbf_gridmap_core and mbf_gridmap_nav which are just plain translations of mbf_costmap for now replacing costmap2dros with customgridmapros. If somehow the map representation could be abstract and inherited or loaded as a plugin, one navigation server can be used with different map representations. Examples of features that we might get are a) use components A, B, C with costmap, and D, E, F with gridmaps b) use planner A with gridmap and controller B with gridmap.

If we have two set of components(planner/controller/recoveries) , one working with costmaps and other with gridmaps, two separate instances of navigation servers have to be launched.

Although this idea seems to me problematic in many ways (eg. api is different for each, we enforce a single interface for different representations etc) but would like to know thoughts on this.

Thanks for the package 👍

[wiki][Tutorials] SMACH

Not sure where to put it so placing it here. In the tutorial, the transitions for WAIT_FOR_GOAL are defined as:

transitions={
    'invalid': 'GET_PATH',
    'valid': 'WAIT_FOR_GOAL',
    'preempted': 'preempted'
}

Shouldn't it be like valid -> GET_PATH and invalid -> WAIT_FOR_GOAL or am I missing something?

Setting new plan while moving warning in Turtlebot navigation

Hi,
I would like to thank you for developing such great project. I am currently working on integrating this project with my research project which uses Turtlebot2. However, I've encountered some problems that need some helps.

I am using Ubuntu 16.04 with Kinetic. I set up the navigation environment by launching the nodes mbf_costmap_nav and move_base_legacy_relay in my launch file.

1. I publish the goal via rviz, the robot can't finish the execution of the path and stopped randomly. Also I have tried using both dwa_local_planner and basic trajectory_planner. The error code I got is:

[ WARN] [1516878140.884170342, 123.947000000]: Setting new plan while moving!
[ERROR] [1516878140.884297843, 123.947000000]: Could not start moving, because another moving thread is already / still running! Canceling the action call.
[ WARN] [1516878140.884486489, 123.947000000]: Recovery behaviors are disabled!
[ WARN] [1516878140.884515078, 123.947000000]: Abort the execution of the controller:

I think the errors come from functions setNewPlan and startMoving in the class of mbf_abstract_nav::AbstractControllerExecution.
Do you guys have any suggestions on how to fix this problem?

2. Many Turtlebot navigation parameters are scripting in the yaml format, I want to load these parameters to the MBF node. Is it possible to implement another script (similar to move_base_legacy_relay) to porting these parameter to MBF?

Thanks again!

Compute current velocity for the controller.

move_base legacy relay ignores new goals when already executing one

Switching Controller/Planner

Hey, great work with move_base flex!
I want to implement a additional planner layer that runs on execution time.
So maybe one idea was to implement this as local planner and then call them in a sequence. Is this already possible in move_base_flex?

Recovery behaviors list not reset while moving properly

Handle INTERNAL_ERROR case

When catching an unknown error, the state is set to INTERNAL_ERROR. But this state is note processed appropriate.

Shouldn't the controller receive the current robot pose and speed?

As discussed on #11, that's one of the interesting innovations on nav2_core we should probably adopt.

issue compiling

Hi I' m receiving many errors while compiling the workspace. Are you sure that this version has no error?

More flexible target definition

Hi,

Thanks for this awesome extension to MoveBase / ROS Nav stack. I just watched your ROSCON video and I did really like it; especially since we are using SMACH for our state behavior as well together with a local and global planner interface (using the nav_core planners). I thing we encountered during the Robocup@Home competitions is that we would like to express the navigation targets with use of contraints. I see that you are still using the geometry_msgs/PoseStamped. What do you think about this?

Our implementation can be found here:

https://github.com/tue-robotics/cb_base_navigation

Would love to hear your thoughts. Thanks again!

Optional param: force reached goal check by mbf

Some plugins do not properly check if the robot reached the goal with the given tolerance. Implement a check within the mbf_abstract_nav/AbstractNavigationServer.

Replace MoveBaseResult::INVALID_PLUGIN error code with planner/controller/recovery codes

Error code MoveBaseResult::INVALID_PLUGIN means that one of the plugins requested to be used for move_base action doesn't exist or is not properly initialized.
I think here we should return instead:

• GetPathResult::INVALID_PLUGIN
• ExePathResult::INVALID_PLUGIN
• RecoveryResult::INVALID_NAME

True, MoveBaseAction should return MoveBaseResult-defined codes... but we are not following this anyway, as it also returns planner/controller/recovery-specific error codes, to maximize the value of the returned information

Force config. regeneration when adding new params

When adding new params to https://github.com/magazino/move_base_flex/blob/master/mbf_abstract_nav/src/mbf_abstract_nav/__init__.py, you need to touch https://github.com/magazino/move_base_flex/blob/master/mbf_costmap_nav/cfg/MoveBaseFlex.cfg before compiling so code for the new parameters is generated.

Cannot do better?

Avoid recursive mutexes on reconfiguration calls

We don't need recursive mutex in this case, and they introduce an unnecessary overhead.

Better handling continuous replanning

As we use now simple action server for exe_path, every new plan will stop the action, set the new plan, and restart exe_path. Following #64, this is not only ugly, but also will introduce a zero-velocity command at every new plan.

Possible solution: use a normal action server so every new goal received while running a previous one just updates the path we are already following, without preempting the previous goal.
🤔 actually, we can abuse a bit this to provide a simple interface for pause / resume: empty path for pause, non-empty to resume.

Robot oscillating detected while running rotate recovery

Best practices for using MBF

With the latest changes to master I am changing my code to suit the new way of doing things.
I have a question about what the intended way to use this is.

Should I be creating my classes to inherit directly from the various Abstract* classes, or are the Simple* classes designed to be subclassed?
#14 seems to imply that everything should directly inherit from Abstract*, but I'm not sure.

Support for AckermannDrive messages

At the moment mbf generates a TwistStamped message like the previous nav stack. This isn't great for non-holonomic robots.
Is it possible to change the type of command message returned to something like AckermannDrive?

I'm happy to help with the implementation - are there any suggestions as to the best way to do this given the way you have architected the rest of the project?

Clean up and sort parameter namespaces

This should not be:

/move_base_flex/TrajectoryPlannerROS/holonomic_robot
/move_base_flex/controller/holonomic_robot
/move_base_flex/holonomic_robot

Stop the robot during aborting from the `exe_path` action

As it's clear in this line:

move_base_flex/mbf_abstract_nav/src/abstract_controller_execution.cpp

Line 462 in 9c5fb1b

// publishZeroVelocity(); TODO comment this makes sense for continuous replanning

the robot wouldn't stop after aborting from the exe_path action, which is very problematic when there is no watchdog to stop the robot if it doesn't receive any new cmd_vel.
Also with the current implementation, the name of the stopMoving doesn't make sense, because it doesn't really do what it can be inferred from its name. I also understand the point of commenting out this line and it can be useful, but I would separate the implementation of these two cases.

Crash when empty plan is sent to controller

This occurs when using mbf_costmap_nav but this is most probably in the base class.

How to use move_base_flex in robot navigation?

I want to use move_base_flex in robot navigation instead of move_base, but I cannot configure luanch file to load global_planner and local_planner. So, I will appreciate if someone can help me, thank you very much!

Recovery behaviors not applied when oscillation is detected

On planner failure, move_base action fails without trying recovery behaviors

On general, move_base requires a full review, as it neither features oscillation detection (issue #1), and the action clients are created on every call, what I suppose can add some unnecessary delay.

Question: why are the controller, recovery behavior and planner bundled in one node?

What is the benefit of having one server that exposes these three functionalities instead of having three (or n) servers exposing these separate functionalities?

Questions about future works

Hi !
First of all thanks for your work. I like the idea of flexibility that you're trying to implement. Since I have two questions according future work:

1. You wrote, that you want to replace costmap2D with a grip map. What kind of grid map do you mean? This one?
2. What do you think about using multiple planner inside the move_base? For example an approach with, say, A* for global planning, Lattice Planner for a local plan and a controller for path execution?

Thanks in advance for your answers!

Implement continuous replanning on move_base action

By now, parameter planner_frequency is completely ignored on move_base action, and in AbstractPlannerExecution is read but is meaningless.
UPDATE: not really... was used but wrongly, to espaciate the retries in case of failure!

Cannot reuse the logic from old move_base?

move_base_flex is not actually a metapackage

This is more a question than an actionable item, but I was just wondering why the description of move_base_flex claims it to be a metapackage, while it isn't actually one.

The name metapackage has an 'official' definition and defined semantics (REP-149), and move_base_flex doesn't seem to adhere to that.

Is move_base_flex actually more a convenience package that users can find_package(..) to get the entire set of MBF dependencies / often used pkgs, instead of having to list all dependencies separately?

Move the monolithic move_base action out of mbf_abstract_nav

It's obviously anything but "abstract". Most simple change is to put it on mbf_costmap_2d_nav, but as @reinzor suggested, putting it in a separated node that calls the other actions would extend this feature to whatever navigation system we use, not only costmap-based navigation.

Better application of shutdown_costmaps feature

Now we startup/shutdown costmaps for every action goal, what is very inefficient (it takes in average (1/update_rate)/2 to start every costmap; stop is very fast, though)

Easy solution can be to add a delay on shutting down costmaps, so we don't need to reenable on actions coming soon after, like executing a path just after getting it from the planner.

Robot pose not correctly sent to controller

The call to getRobotPose() doesn't seem to be working.
My controller gets passed an uninitialised StampedPose - everything is zero and the strings are all blank.

Does move_base_flex offer better performance than move_base?

Does it support multi threading or CUDA acceleration?

Allow loading multiple planners and controllers, electable at runtime

Our ROS API already provides a xxx_name field for that, but it's not implemented in the server

Remove redundant error codes from MoveBaseResult

Candidates (apart from issue #51)

• PAT_EXCEEDED: this cannot happen unless we add a "global navigation patience", what is not the case by the moment. We should return one of the PAT_EXCEEDED constants on planner/controller/recovery
• ROBOT_STUCK: possibly redundant with controller version?

Implement recovery behavior patience

for the case one of them gets stuck

Add oscillation detection to move_base action

Drop make plan service, as it duplicates get_path action

Also we provide this service for backward compatibility in the move_base_legacy_relay script.

nav_core2

Are you planning to be compatible with https://github.com/locusrobotics/robot_navigation/tree/master/nav_core2 ?

Rotate recovery behavior sometimes run forever

when used in the move_base action

And sometimes doesn't run at all... not sure if related with continuous replanning

SIGSEGV crash when no recovery behaviors configured

If the mbf_action_recovery_behaviors parameter is unset, then when the local planner aborts, abstract_navigation_server will SIGSEGV. This is reproducible every time.

Question about computeVelocityCmd inheritance in mbf_costmap_nav

Function computeVelocityCmd in costmap_controller_execution intends to override the one in base class.
computeVelocityCmd in abstract, computeVelocityCmd in costmap_nav

To my understanding, the override function needs to take same inputs as base class function in c++. I've test it with output message which shows the move_base_server is calling the abstract one. Also, I'm using the latest commit in master branch.

Just want to clarify if this is an intentional move, please correct me if there is any misunderstanding, thanks!

Allow running more than one planner and recovery behavior simultaneously

Wouldn't it make sense to allow running more than one planner and recovery behavior simultaneously?
Some use cases:

• Run two complementary recovery behaviors simultaneously so they help each other, or at least reduce the overall time compared to sequential execution
• Run two or more different planners simultaneously and use the first / best plan obtained
• Start simultaneously fast and slow plannings so we can start moving asap but a bit after replace the "fast" plan by a (probably much better) "slow" plan

ExePath action result: fields not properly filled

• geometry_msgs/PoseStamped final_pose

doesn't get the final pose, but a pose a bit before and lacks stamp

• float32 dist_to_goal
• float32 angle_to_goal

not filled neither on success or failure

Also current_pose is missing on the feedback

Does it makes sense to lock global costmap when calling global planner?

On old move_base both local and global costmaps are locked when calling the local/global costmap (see ros-planning/navigation#441).

On mbf only global costmap is locked. I think it should be done by the planner itself, just the minimum time possible.

Request: Separate the abstraction from the implementation

I am browsing through your code (since there is not that much documentation yet, except for your roscon presentation and the tutorial). And what is not clear for me why you have a separate package for the interface definition (move_base_flex_core pkg) and another package (move_base_flex pkg) that holds an abstraction for the executioners and an implementation. Why not totally separate the abstraction from the implementation and create, for example, a mbf_move_base and mbf_simple package? Correct me if this remark does not make sense.

Advanced Plugin Loading

• make the plugin loading more safe-
• allow loading plugins using the actions or services.

mbf_costmap_nav: Sometimes the origin of the costmap is not updated when rolling_window is set to true

I cannot easily reproduce this but this occurred three times today.

Compute path length for action result in get_path