Default MoveIt! setup forgets to load kinematics into /move_group namespace

[pbeeson]

Whenever you use the MoveIt! Setup Wizard to set up a new package with move groups, it makes all the launch files. But forgets an important portion.

When run out of the box, kinematics.yaml gets loaded in /robot_description_kinematics/. But, the moveit kinemaitcs plugins themselves are run under the /move_group namespace, so they expect to get parameters at /move_group//parameter1, etc. Whenever you change any non-'kinematics_solver' parameters in the kinematic.yaml, the KDL plugin (for instance) looks for things like 'kinematics_solver_timeout' in /move_group/left_arm/kinematics_solver_timeout as an example. But the MoveIt setup doesn't include loaded the kinematics.yaml into /move_group namespace. This is an oversight that could be VERY confusing to people.

Simple solution: Add the following to the move_group.launch file created for the robot.

 <group ns="move_group">
    <rosparam command="load" file="$(find PACKAGE_NAME)/config/kinematics.yaml"/>
  </group>

[ceesietopc]

@pbeeson Thank you for pointing this out! I've been spending the last days trying to figure out why I could not control my robotic arm. I tried MoveIt! commander's set_pose_target and sending the MoveActionGoal myself, but it did not work and the only feedback I got was "Unable to construct goal representation".

Only when I tried to explicitly call the /compute_ik service, I received a warning that the necessary components were not loaded. Adding your snippet to my launch file fixed the problems for all methods I tried before.

Any reason why this is not part of the default move_group.launch? It would greatly increase the "works-out-of-the-box"-aspect for cartesian setpoints.

[v4hn]

If this is really still an issue, it would be a pretty severe one and it just should not be there.
I never noticed problems with this until now.

@ceesietopc Could you create an issue for this in the new repository?
I'm not able to verify this at the moment.

The proposed fix is a workaround and would upload the parameters in two different locations and we should avoid this upstream.
Also I'm not sure which code exactly too look into here.
A couple of links to the respective lines of code would probably help to understand this..

[v4hn]

@pbeeson I just noticed you're associated with TRAClabs.
Do you know if the trac plugin circumvents this problem?

[pbeeson]

No the trac plugin does not circumvent this. https://bitbucket.org/traclabs/trac_ik/issues/25/unable-to-set-solver_type-in-launch-file

…

On Sun, Feb 26, 2017 at 9:15 AM Michael Görner ***@***.***> wrote: @pbeeson <https://github.com/pbeeson> I just noticed you're associated with TRAClabs. Do you know if the trac plugin circumvents this problem? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#629 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADrfxrZ4eKdiWCWGFtaWR2kbMc0vdE3xks5rgZcjgaJpZM4GyRMI> .

[ceesietopc]

I will try to validate and create an issue for this in the new repository later this week.