GetPath fails everytime

[jash101]

I'm implementing mbf along with state machine using smach, just as per this tutorial: http://wiki.ros.org/move_base_flex/Tutorials/SimpleSmachForMoveBaseFlex

I changed the import library names from move_base_flex_msgs to mbf_msgs. Upon launching all nodes, when I give a goal pose via rViz, I can see the state change to GetPath in smach_viewer, but I get this message on console: [WARN] [1601965214.477694]: Still waiting for action server '/move_base_flex/get_path' to start... is it running? And soon after, it aborts and goes back to wait for goal state.

How to solve this issue?

[Rayman]

How are you launching move_base_flex? Does /move_base_flex/get_path/goal show up in rostopic list?

For inspiration, you can look at my example repo with launch files for the turtlebot: https://github.com/Rayman/turtlebot3_mbf

[jash101]

Hi @Rayman , thanks for responding. I'm launching move_base_flex with the help of a launch file, similar to https://github.com/uos/ceres_robot/blob/master/ceres_navigation/launch/move_base_flex_simple.launch

Yes I can view/move_base_flex/get_path/goal and other topics when I type inrostopic list

Sure, I'll have a look at your repo, but any idea how this error occurs? I'm unable to get even a generic help regarding this error, although it seems like an action server error

[ML-S]

Hi @Rayman and @jash101, I have the same problem! I also posted a stackoverflow-thread with some code on how I started the launch-file (i used subprocess within the state machine but also tested it with mbf launched manually via roslaunch on which the issue remains the same!) and screenshots of my error/warning-output and of the result of rostopic list! Furthermore, my launch-file for launching mbf looks as follows:

<?xml version="1.0"?>

<launch>
  <!-- Move Base Flex -->
  <master auto="start"/>
  <node pkg="mbf_costmap_nav" type="mbf_costmap_nav" respawn="false" name="move_base_flex" output="screen">
    <param name="tf_timeout" value="1.5"/>
    <param name="planner_max_retries" value="3"/>
    <rosparam file="$(find joggingblinde_2dnav)/config/planners.yaml" command="load" />
    <rosparam file="$(find joggingblinde_2dnav)/config/costmap_common_params.yaml" command="load" ns="global_costmap"/>
    <rosparam file="$(find joggingblinde_2dnav)/config/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find joggingblinde_2dnav)/config/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find joggingblinde_2dnav)/config/local_costmap_params.yaml" command="load" />
  </node>
</launch> 

Edit: I don't know if it has something to do with the problem, but maybe it's also useful to know that when starting the mbf.launch, in the terminal output it only shows:

[ INFO] [1601983030.818125859]: local_costmap: Using plugin "static_layer"
[ INFO] [1601983032.166267435]: local_costmap: Using plugin "occgrid_to_costmap_layer"

and says nothing about global_costmap plugins loaded (since get_path calls the global planner, maybe this has something to do with the issue?)

[Rayman]

@jash101 I've replaced move_base_flex_msgs with mbf_msgs in http://wiki.ros.org/move_base_flex/Tutorials/SimpleSmachForMoveBaseFlex

[spuetz]

Make sure that the nodes are connected using the same roscore you can test your running MBF instance with: rostopic pub -1 /move_base_flex/get_path/goal mbf_msgs/GetPathActionGoal <goal message> For the goal message use tab tab and fill in reasonable arguments.

[ML-S]

@spuetz I tried your test-command but don't know if the arguments are reasonable and if the output is the desired output: Edit: running rostopic echo /move_base_flex/get_path/feedback simultaneously remains empty Edit2: the terminal where I started the mbf.launch doesn't show any output when running the command. And again another weird thing is that it apparently doesn't load all local and global costmap plugins. Here's the terminal-window (the termination with Ctrl+C of course was after running the test-command):

[spuetz]

The output of the MBF node would be useful too here ;) Have you tried to run it in a docker container? The GetPath works. The failure must be on the other side ;) MBF should react on this test action goal in any case.

[ML-S]

I attached the output to my previous comment.

Furthermore:

• I played a little with rqt: Using the Action Type Browser-Plugin in rqt there is no running action/message on mbf_msgs: (When selecting another actionlib like for example turtle_actionlib instead of mbf_msgs then there is a list of 8 messages available to choose from)

• Furthermore, what seems odd to me is the output on subscribers and publishers of the mfb-topics: The subscribers and publishers are exactly the other way around like they are in the turtle-tutorial. (like for example on the goal topic, mbf is the publisher while turtle is the subscriber)

• As I mentioned above, not all plugins appear to be loaded. Could it be that mbf being stuck on loading plugins and therefore doesn't respond to action-calls (or doesn't even properly start the servers)?

Maybe I missed something on the setup, I did the following steps:

1. cloned the mfb repository into my catkin-workspace
2. set up the launch-file in my first comment above while leaving the config-yaml-files exactly as I used them with move_base
3. catkin_make

[Rayman]

You don't have to install move base flex from source, you can also install the version from apt:

sudo apt install ros-$ROS_DISTRO-move-base-flex

[ML-S]

I just tried to use my state_machine with mbf installed via sudo apt install but the issue remains. Therefore, apparently the problem isn't with the way of installation.

When launching mbf and using rostopic info /move_base_flex/get_path/status, it shows that the action is subscribed but not published:

Could it be that the action-server-topics are shown in rostopic list because there are subscribers registered even though the servers themselves for any reason aren't actually started? (because if they were, mbf would be listed on publisher-side, wouldn't it? And it would explain why the smach-state can't find the server.)

Edit: I tried to figure out if the problem was with my launchfile or my configuration-files. Therefore I replaced my ./launch and ./config folders with the ones from the ceres_navigation project (and of course modified the package-references to make it work with my packages) - still the issue remains and rostopic info again shows that the server appears to not be started.

[jash101]

@Rayman The launch file in https://github.com/Rayman/turtlebot3_mbf had some effect. I changed the global planner to GlobalPlanner. The states are changing as expected, but irrespective of the goal and current pose, the bot only moves forward in full speed.

This can be due to the fact that dwa params were written in Kinetic and some of param names changed in dwa, and I run mbf on Melodic. However move_base worked fine with same params(just threw warning about outdated param names). So I'm unsure what is causing this behavior.

Any guesses?

[Rayman]

Yes, some parameter names of the dwa planner changed from kinetic to melodic. On kinetic you should use the dwa parameters from kinetic :)

Try searching for a dwa planner configuration that belongs (is tuned) for the robot that you are using.

[ML-S]

@jash101 where did you go wrong? What's the difference between the launch-file you used and the launch-file you're now using that solves the issue?

[jash101]

Mainly this line: <node name="move_base_legacy_relay" pkg="mbf_costmap_nav" type="move_base_legacy_relay.py"/>

[jash101]

@Rayman @spuetz I changed the parameters as per melodic, still no effect. Also, everytime I run the launch file, I receive these errors:

Traceback (most recent call last):
  File "/opt/ros/melodic/lib/mbf_costmap_nav/move_base_legacy_relay.py", line 129, in <module>
    mb_drs = Server(MoveBaseConfig, mb_reconf_cb)
  File "/opt/ros/melodic/lib/python2.7/dist-packages/dynamic_reconfigure/server.py", line 81, in __init__
    self._change_config(self.config, ~0)  # Consistent with the C++ API, the callback gets called with level=~0 (i.e. -1)
  File "/opt/ros/melodic/lib/python2.7/dist-packages/dynamic_reconfigure/server.py", line 104, in _change_config
    self.config = self.callback(config, level)
  File "/opt/ros/melodic/lib/mbf_costmap_nav/move_base_legacy_relay.py", line 101, in mb_reconf_cb
    mbf_drc.update_configuration(mbf_config)
  File "/opt/ros/melodic/lib/python2.7/dist-packages/dynamic_reconfigure/client.py", line 185, in update_configuration
    raise DynamicReconfigureParameterException('don\'t know parameter: %s' % name)
dynamic_reconfigure.DynamicReconfigureParameterException: don't know parameter: make_plan_add_unreachable_goal

And again, when ran with move_base, even deprecated DWA param names had no effect. So I don't think that's the problem. Is it some issue with move_base_legacy_relay? What does that script do btw?

[spuetz]

Which version of MBF are you using? If compiled from sources (move_base_flex in src folder) checkout 0.3.2. If you removed MBF from the src folder and used the apt version, please delete the build and devel folder. Just to be sure, that we are talking about the newest version 0.3.2.

[jash101]

@spuetz I installed move_base_flex using apt, I checked with rosversion move_base_flex but it says <unversioned>, so I checked version mentioned in package.xml and it is 0.3.2.

[jash101]

I changed all yaml files and launch file to be same as in @Rayman's repo. Getting issue in exe_path now:

[INFO] [1602322911.747704]: State machine transitioning 'WAIT_FOR_GOAL':'invalid'-->'GET_PATH'
[ INFO] [1602322911.753087621]: Start action "get_path" using planner "NavfnROS" of type "navfn/NavfnROS"
[INFO] [1602322911.844752]: State machine transitioning 'GET_PATH':'succeeded'-->'EXE_PATH'
[ INFO] [1602322911.881770833]: Start action "exe_path" using controller "DWAPlannerROS" of type "dwa_local_planner/DWAPlannerROS"
[ INFO] [1602322911.898788761]: Got new plan
[ WARN] [1602322915.349711770]: DWA planner failed to produce path.
[ WARN] [1602322915.350026458]: No velocity command received from controller! Controller failed
[ WARN] [1602322915.546796747]: DWA planner failed to produce path.

[ML-S]

I figured out that the reason for the Still waiting for action server '/move_base_flex/get_path' to start... is it running?-issue in my case really was that the actionserver didn't start because mbf was stuck waiting for the costmap-plugins to load (mbf appears to first load the plugins and then afterwards start the action servers).

In my case, the global and local costmap subscribe to occupancy grid-topics (for example in static-layer declared by the map-param). Apparently, for the plugin loader in mbf to load the plugins it is not enough for the topics to just exist (being declared and registered to the rosmaster). There must be data published on the topics after mbf was launched in order for the plugin loader to finish loading the plugins and then continue starting the action servers.

For some reason, when starting the mbf-launch-file inside the SMACH using subprocess.popen, it apparently cannot access the data published on the mentioned topics even if they were published (or there is some other reason why it keeps beeing stuck loading the plugins even though data was published on the required topics). When I start the mbf-launch-file outside the SMACH using roslaunch inside a terminal and then start SMACH (in which the node, that declares and publishes to the mentioned topics required by the costmaps is implemented), it works perfectly fine as soon as the SMACH-state publishes data to the topic...

I don't know yet if the problem is with subprocess or if it is with SMACH. Any ideas on that?

Edit: I just figured out that starting the mbf-launch-file with subprocess.popen inside a normal python-script outside SMACH also works perfectly fine! Therefore, the problem appears to be with SMACH. Another interesting thing is that I have another c++-file in the same procject which builds the connection between the odom and the _baselink-frame and at some point calls tf2_ros::TransformBroadcaster::sendTransform. This function also gets stuck when running the file via subprocess.popen inside SMACH. Same thing here: when running it outside SMACH, it runs perfectly fine as well!

[jash101]

Hey @ML-S even I was able to solve that issue, but still can't figure out why the controller always says DWA failed to produce path. Have you faced this issue? Also facing issue #224 when using mbf on Melodic, in particular when running move_base_legacy_relay.py (as in @Rayman's launch file)

[ML-S]

Hi @jash101 , I didn't use the move_base_legacy_relay so far since I've oriented myself on the ceres-project. What is the move_base_legacy_relay for anyway? Is it crucial for the use of mbf?

[spuetz]

As the word "legacy" expresses, it is just for the backwards compatibility. If you want the full flexibility you should use, e.g. SMACH (hierarchical concurrent state machine / task level architecture), or Groot (behaviour tree) to control the navigation process and to include it in an high level application.

[jash101]

@spuetz I tried with smach script shown in tutorial http://wiki.ros.org/move_base_flex/Tutorials/SimpleSmachForMoveBaseFlex along with a launch file similar to ceres-navigation, but I get a warning which says: [ WARN] [1602855507.563856791, 183.186000000]: DWA planner failed to produce path. And the bot doesn't move. To make sure it wasn't a DWA planner parameter tuning issue, I used it with turtlebot3_navigation params (like @Rayman's turtlebot3_mbf pkg) with launch file like in ceres-navigation Any idea how to solve it?

[jash101]

I solved this issue, it was because of bad parameter tuning only. I was mistakenly using different robot's dwa params. This works fine! Will try with more complicated state machines now!

[kc944201]

@jash101 I got the same problem with you, could you describe more detail?

DWA planner failed to produce path. show in the terminal every second. It would influence robot's motion, resulting in the robot's motion frustrated

[ju-mingyue]

@Rayman When I use the move_base_flex function package again, I follow the link https://github.com/uos/ceres_robot/blob/master/ceres_navigation/launch/move_base_flex.launch to configure the file, but after running it, it is found in the node graph that this function package does not subscribe to the map and the lidar signal (the topic here is corresponding), and I can’t read it To the planned path.I don’t quite understand what does move_base_legacy_relay do?