move_group dies when service /get_planner_params is called

[rhaschke]

Can you provide sample code that fails? On my side, retrieving and displaying the planner params in rviz works like a charm.

[nikhilkalige]

I wrote some 50 lines in the issue above, looks like it disappeared somewhere...

I tried the following code with

roslaunch ur_gazebo ur5.launch
roslaunch ur5_moveit_config ur5_moveit_planning_execution.launch sim:=true

I then queried with the following

rosservice call /get_planner_params RRTkConfigDefault manipulator

I also tried the python interface

import rospy
from moveit_msgs.srv import GetPlannerParams, GetPlannerParamsRequest
rospy.wait_for_service('/get_planner_params')
s = rospy.ServiceProxy('/get_planner_params', GetPlannerParams)
h = GetPlannerParamsRequest()
h.group = 'manipulator'
h.planner_config = 'BKPIECEkConfigDefault'
s(h)

I tried debugging with gdb and it usually stops at move_group::MoveGroupQueryPlannersService::getParams function call. Also if I print the config inside the above function call, I get

const planning_interface::PlannerConfigurationMap&
        configs = planner_interface->getPlannerConfigurations();

    for(planning_interface::PlannerConfigurationMap::const_iterator itx = configs.begin();
            itx != configs.end(); ++itx)
    {
      std::cout << itx->first << "\n";
    }

endeffector
endeffector[BKPIECEkConfigDefault]
...
manipulator
manipulator[BKPIECEkConfigDefault]
....

But the function call does it = configs.find(req.planner_config), so will this call not return a invalid value, as there is no planner_config value to be found in the above list printed. Or does find perform a string match on the key. I may be wrong, I am just trying to write my thoughts.

[rhaschke]

Good catch. The validity check is indeed missing. Created PR #684 to fix it.

[nikhilkalige]

Awesome.. Works properly now..