Moveit: Could not find the planner configuration. Bug in MoveIt config generation with the Assistant.

[Polonium19]

Description

No OMPL default configs found.
Issue also is described here: https://answers.ros.org/question/294136/moveit-param-server-is-missing-planner-configurations/

Seem it must be updated one line of code in moveit_config_data.cpp (here):

from:

std::string defaultconfig = planner_des[i].name_;

to

std::string defaultconfig = planner_des[i].name_ + "kConfigDefault";

Your environment

• ROS Distro: [Kinetic]
• OS Version: e.g. Ubuntu 16.04
• build

Steps to reproduce

Generate config with MoveIt setup assitant and launch it.

Actual behaviour

No configs found in RViz MoveIt plugin.

Backtrace or Console output

[[ERRORERROR]]  [[1528993777.3220798171528993777.322079817]:]:  CouldCould  notnot find the planner configuration  find the planner configuration 'RRTConneckConfigDefault' on the param server
[ERROR] [1528993777.326028820]: Could not find the planner configuration 'SBLkConfigDefault' on the param server
[ERROR] [1528993777.326619022]: Could not find the planner configuration 'ESTkConfigDefault' on the param server
[ERROR] [1528993777.327209350]: Could not find the planner configuration 'LBKPIECEkConfigDefault' on the param server
...
...

[gavanderhoorn]

I believe the code referenced was introduced in #658.

@akgoins, do you have any idea what could be happening?

[akgoins]

@gavanderhoorn, MoveIt is looking for the planners available under /move_group/planner_configs/ but for some reason it is not including the "kConfigDefault" in the planner names that it is searching for. I thought that the legacy system had "kConfigDefault" written in the ompl_plannering.yaml file, which is why I included it in the yaml writer. If "kConfigDefault" is not included in the planner name anymore, then the fix should be exactly what @Polonium19 has mentioned. If "kConfigDefault" was used in legacy systems and backwards compatibility is desired, then we need to find where the planners are being read in by MoveIt and see if/when the 'kConfigDefault" was dropped from the parsing of the parameter server.

[quattro1996]

i did find a method to side step the issue in the link above. however as @gavanderhoorn pointed out this is probably a reverse-fix.

[Sanddog23]

These issues might correlate to the problems of the ompl planner errors. I noticed that some of my movements for my arm before the newest release of MoveIt were jerky at some points and now after the new release seem to be smoother.
-#416 (https://github.com/ros-planning/moveit/issues/416)
-https://bitbucket.org/ompl/ompl/issues/309/performance-regression-going-from-ompl
-https://github.com/ros/rosdistro/pull/17747

[YiKangJ]

I also met this problem when I reinstalled the ROS kinetic. And I compare the ompl.yaml with the file I created before, I found that there was no "kConfigDefault" in the new yaml file. So I think @akgoins has got the real reason of this problem.

[scchow]

I also ran into this problem with a new install of ROS Kinetic.

I created my moveit_config package using the setup_assistant. In the generated config/ompl_planning.yaml file, I noticed all the planner names did not have kConfigDefault appended:

planner_configs:
  SBL:
    type: geometric::SBL
    range: 0.0  # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0, set on setup()
  EST:
    type: geometric::EST
    range: 0.0  # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0 setup()
    goal_bias: 0.05  # When close to goal select goal, with this probability. default: 0.05
...

I found by manually appending kConfigDefault to the name of each of these planners, the errors no longer occur:

planner_configs:
  SBLkConfigDefault:
    type: geometric::SBL
    range: 0.0  # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0, set on setup()
  ESTkConfigDefault:
    type: geometric::EST
    range: 0.0  # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0 setup()
    goal_bias: 0.05  # When close to goal select goal, with this probability. default: 0.05
...

So perhaps the problem could be solved by fixing the generator of this file.

[impala454]

I just ran across this as well. Seems like the cleaner solution is simply find and remove all instances of kConfigDefault?

[mlautman]

This should be fixed by #1040 which was just merged. Closing the issue. If the problem persists, feel free to re-open the issue and ping me.