Default MoveIt! setup forgets to load kinematics into /move_group namespace
pbeeson opened this issue · comments
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>
@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.
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..
@pbeeson I just noticed you're associated with TRAClabs.
Do you know if the trac plugin circumvents this problem?
I will try to validate and create an issue for this in the new repository later this week.