Problem about KUKA kr4r600 with OPW solver

[JACKX-M]

Hi, guys. I want to use the OPW solver for my kuka kr4 project. But there is a problem. I used the opw parameters from opw_parameter_kr4r600.yaml file provided by ROS-I.

opw_kinematics_geometric_parameters:
    a1:  0.0
    a2:  -0.02
    b:   0.0
    c1:  0.33
    c2:  0.29
    c3:  0.31
    c4:  0.075

opw_kinematics_joint_offsets: [0.0, deg(-90.0), 0.0, 0.0, 0.0, 0.0]
opw_kinematics_joint_sign_corrections: [-1, 1, 1, -1, 1, -1]

But when I lauch my launch file, it shows:

[ INFO] [1689562581.960514870]: Loaded parameters for ik solver:
Distances: [0 -0.02 0 0.33 0.29 0.31 0.075]
Offsets = [0 -1.5708 0 0 0 0 ]
Sign_corrections = [1 1 1 -1 1 -1 ]
[ERROR] [1689562581.960898185]: Pose orientation error on element (0, 0).
[ERROR] [1689562581.960929503]: opw: 0.000000, moveit: 1.000000.
[ERROR] [1689562581.960948347]: Pose orientation error on element (0, 2).
[ERROR] [1689562581.960966460]: opw: 1.000000, moveit: 0.000000.
[ERROR] [1689562581.960990094]: Pose orientation error on element (2, 0).
[ERROR] [1689562581.961013026]: opw: -1.000000, moveit: 0.000000.
[ERROR] [1689562581.961027873]: Pose orientation error on element (2, 2).
[ERROR] [1689562581.961039865]: opw: 0.000000, moveit: 1.000000.
[ERROR] [1689562581.961063168]: The OPW parameters loaded from the parameter server appear to be incorrect (self-test failed for '0 0 0 0 0 0').
[ERROR] [1689562581.961107530]: Kinematics solver of type 'moveit_opw_kinematics_plugin/MoveItOPWKinematicsPlugin' could not be initialized for group 'kuka_kr4'
[ERROR] [1689562581.961265230]: Kinematics solver could not be instantiated for joint group kuka_kr4.

Is there any problems about the OPW parameters or my faults? Thanks.

Here is the launch file:

<launch>
  <!-- The planning and execution components of MoveIt! configured to run -->
  <!-- using the ROS-Industrial interface. -->

  <!-- Non-standard joint names:
       - Create a file [robot_moveit_config]/config/joint_names.yaml
           controller_joint_names: [joint_1, joint_2, ... joint_N] 
       - Update with joint names for your robot (in order expected by rbt controller)
       - and uncomment the following line: -->
  <rosparam command="load" file="$(find kuka_kr4_opw_moveit_config)/config/controller_joint_names.yaml"/>
 <arg name="debug" default="false" />
  <!-- the "sim" argument controls whether we connect to a Simulated or Real robot -->
  <!--  - if sim=false, a robot_ip argument is required -->
  <arg name="sim" default="true" />
  <arg name="robot_ip" unless="$(arg sim)" />

  <!-- load the robot_description parameter before launching ROS-I nodes -->
  <include file="$(find kuka_kr4_opw_moveit_config)/launch/planning_context.launch" >
    <arg name="load_robot_description" value="true" />
  </include>

  <!-- run the robot simulator and action interface nodes -->
  <group if="$(arg sim)">
    <include file="$(find industrial_robot_simulator)/launch/robot_interface_simulator.launch" />
  </group>

  <!-- run the "real robot" interface nodes -->
  <!--   - this typically includes: robot_state, motion_interface, and joint_trajectory_action nodes -->
  <!--   - replace these calls with appropriate robot-specific calls or launch files -->
  <group unless="$(arg sim)">
    <include file="$(find kuka_eki_hw_interface)/launch/robot_interface_streaming.launch" >
      <arg name="robot_ip" value="$(arg robot_ip)"/>
      <!-- <arg name="pos_ctrlr_name" value="kuka_kr4_controller"/> -->
    </include>
  </group>

  <!-- publish the robot state (tf transforms) -->
  <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" />

  <include file="$(find kuka_kr4_opw_moveit_config)/launch/move_group.launch">
    <arg name="publish_monitored_planning_scene" value="true" />
    <!-- <arg name="moveit_controller_manager" value="kuka_kr4r600"/> -->
  </include>

  <include file="$(find kuka_kr4_opw_moveit_config)/launch/moveit_rviz.launch">
     <arg name="rviz_config" value="$(find kuka_kr4_opw_moveit_config)/launch/moveit.rviz"/>
    <arg name="debug" value="$(arg debug)"/>
  </include>

  <!-- <include file="$(find kuka_kr4_opw_moveit_config)/launch/default_warehouse_db.launch" /> -->

</launch>

[gavanderhoorn]

@simonschmeisser: could you perhaps take a look?

[simonschmeisser]

The OPW config looks correct. Could you please add how you load it and also your SRDF file

[JACKX-M]

OK. I load it just using the moveit_setup_assistant at Define Planning Groups section.

And the SRDF file is here:

<?xml version="1.0" encoding="UTF-8"?>
<!--This does not replace URDF, and is not an extension of URDF.
    This is a format for representing semantic information about the robot structure.
    A URDF file must exist for this robot as well, where the joints and the links that are referenced are defined
-->
<robot name="kuka_kr4r600">
    <!--GROUPS: Representation of a set of joints and links. This can be useful for specifying DOF to plan for, defining arms, end effectors, etc-->
    <!--LINKS: When a link is specified, the parent joint of that link (if it exists) is automatically included-->
    <!--JOINTS: When a joint is specified, the child link of that joint (which will always exist) is automatically included-->
    <!--CHAINS: When a chain is specified, all the links along the chain (including endpoints) are included in the group. Additionally, all the joints that are parents to included links are also included. This means that joints along the chain and the parent joint of the base link are included in the group-->
    <!--SUBGROUPS: Groups can also be formed by referencing to already defined group names-->
    <group name="kuka_kr4">
        <link name="base_link"/>
        <link name="link_1"/>
        <link name="link_2"/>
        <link name="link_3"/>
        <link name="link_4"/>
        <link name="link_5"/>
        <link name="link_6"/>
        <joint name="joint_a1"/>
        <joint name="joint_a2"/>
        <joint name="joint_a3"/>
        <joint name="joint_a4"/>
        <joint name="joint_a5"/>
        <joint name="joint_a6"/>
        <chain base_link="base_link" tip_link="link_6"/>
    </group>
    <!--GROUP STATES: Purpose: Define a named state for a particular group, in terms of joint values. This is useful to define states like 'folded arms'-->
    <group_state name="initPos" group="kuka_kr4">
        <joint name="joint_a1" value="0"/>
        <joint name="joint_a2" value="-1.57"/>
        <joint name="joint_a3" value="0"/>
        <joint name="joint_a4" value="0"/>
        <joint name="joint_a5" value="0"/>
        <joint name="joint_a6" value="0"/>
    </group_state>
    <!--DISABLE COLLISIONS: By default it is assumed that any link of the robot could potentially come into collision with any other link in the robot. This tag disables collision checking between a specified pair of links. -->
    <disable_collisions link1="base_link" link2="link_1" reason="Adjacent"/>
    <disable_collisions link1="link_1" link2="link_2" reason="Adjacent"/>
    <disable_collisions link1="link_2" link2="link_3" reason="Adjacent"/>
    <disable_collisions link1="link_2" link2="link_5" reason="Never"/>
    <disable_collisions link1="link_2" link2="link_6" reason="Never"/>
    <disable_collisions link1="link_3" link2="link_4" reason="Adjacent"/>
    <disable_collisions link1="link_3" link2="link_5" reason="Never"/>
    <disable_collisions link1="link_3" link2="link_6" reason="Never"/>
    <disable_collisions link1="link_4" link2="link_5" reason="Adjacent"/>
    <disable_collisions link1="link_5" link2="link_6" reason="Adjacent"/>
</robot>

Hope for your response!

[simonschmeisser]

Please use tool0 as tip link

[JACKX-M]

Oh! It worked! Thanks a lot!!
By the way, I always use link_6 for industrial robot chain before and it worked for the KDL solver. Could you please tell me the difference?

[simonschmeisser]

OPW uses a separate description of the kinematic chain that needs to match the URDF. Since there is a rotation between link_6 and tool0 those two descriptions/models do not match.

[JACKX-M]

Oh I see. Thanks again! And I'll mark your reply as the answer! :)

[gavanderhoorn]

Independent of whether or not you use OPW, using tool0 as the end-of-chain would almost always be a good idea as base->tool0 transforms are supposed to provide the same result as the OEM's IK solver (ie: whatever the teach/programming pendant show you as "the Cartesian location of the EEF").

How accurate that will be will of course depend on whether or not the OEM includes robot calibration into those results, and what TCP you have active on your robot controller. tool0 would only coincide with an "all zeros toolframe", so any TCP different from that will cause base->tool0 to no longer match (or at least, it won't match directly, if you take the flange->TCP transform into account as well, things should be ok again).

link_6 is almost never going to coincide with what the OEM reports.