ur_kinematics: getting private params when moveit plugin loaded from rviz/moveit_commander

[achim-k]

When the UR moveit plugin is being loaded via the rviz motion planning plugin or via the moveit_commander, the ur moveit plugin fails to load when an arm_prefix was set:

[ERROR] [1470304127.233379094, 4020.674000000]: Kin chain provided in model doesn't contain standard UR joint 'shoulder_lift_joint'.
[ERROR] [1470304127.233633625, 4020.674000000]: Kinematics solver of type 'ur_kinematics/UR10KinematicsPlugin' could not be initialized for group 'ur10'
[ERROR] [1470304127.234046407, 4020.674000000]: Kinematics solver could not be instantiated for joint group ur10.

The reason for this is the following: When the plugin is loaded via rviz/moveit_commander, the moveit plugin is loaded in a different namespace like e.g.

• /move_group_commander_wrappers_1470304126604460729
• /rviz_pcname_3652_1661548360095152202

Since for these namespaces the arm_prefix param is not set, it can't be found and the default value (empty string) is chosen (see here). It then fails here where the joint names from the urdf are compared with the expected once.

Long story short: The plugin can't retrieve private params if not loaded into the default moveit namespace (usually move_group) where the desired params are set.

What works for me is when replacing the line

private_handle.param<std::string>("arm_prefix", arm_prefix_, "");

with the following code:

arm_prefix_ = "";
std::string key;
if(private_handle.searchParam("move_group/arm_prefix", key)) {
  private_handle.getParam(key, arm_prefix_);
}

However, I consider this an ugly fix since it makes the assumption that the desired params are set in the move_group namespace which is probably not always true.

Is there a better way to fix this?

[BrettHemes]

Z! Congrats"7#9/9 hook

[gavanderhoorn]

@BrettHemes wrote:

Z! Congrats"7#9/9 hook

must admin I'm a bit curious as to what this actually means :)

[BrettHemes]

Wow, that must have been me sitting on my phone... sorry. :)

[gavanderhoorn]

Too bad, I thought it was an encoding of some sort. Would've been entertaining :).

[gavanderhoorn]

@achim-k: see #247 and #248 for a related / the same discussion.

[gavanderhoorn]

I believe this is captured by the issues I referred to, so I'm going to close this one.