ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

IK for this IkParameterizationType not implemented yet.

asked 2014-09-03 23:17:20 -0500

bjem85 gravatar image

Hi All,

I have followed the instructions for generating an IKFast plugin located here, and have successfully generated an IKFast package using the instructions. Unfortunately the link to the method of running the plugin in Rviz (link) does not have any content so I am once again left guessing.

When I run RViz using: roslaunch hyd_sys_complete_sldasm_moveit_config demo.launch

I get the following errors repeatedly: [ERROR] [1409802774.965529932]: IK for this IkParameterizationType not implemented yet.

This does not make sense to me, as when I examine the source code the control type (Translation3d) was specifically given as an argument for generating the IKFast package, yet it claims there is no implementation for it.

Here's the offending generated code. I am using Translation3D as my solver yet it is not covered in the solve function given below.

int IKFastKinematicsPlugin::solve(KDL::Frame &pose_frame, const std::vector<double> &vfree, IkSolutionList<IkReal> &solutions) const
{
  // IKFast56/61
  solutions.Clear();

  double trans[3];
  trans[0] = pose_frame.p[0];//-.18;
  trans[1] = pose_frame.p[1];
  trans[2] = pose_frame.p[2];

  KDL::Rotation mult;
  KDL::Vector direction;

  switch (GetIkType())
  {
    case IKP_Transform6D:
      // For **Transform6D**, eerot is 9 values for the 3x3 rotation matrix.

      mult = pose_frame.M;

      double vals[9];
      vals[0] = mult(0,0);
      vals[1] = mult(0,1);
      vals[2] = mult(0,2);
      vals[3] = mult(1,0);
      vals[4] = mult(1,1);
      vals[5] = mult(1,2);
      vals[6] = mult(2,0);
      vals[7] = mult(2,1);
      vals[8] = mult(2,2);

      // IKFast56/61
      ComputeIk(trans, vals, vfree.size() > 0 ? &vfree[0] : NULL, solutions);
      return solutions.GetNumSolutions();

    case IKP_Direction3D:
    case IKP_Ray4D:
    case IKP_TranslationDirection5D:
      // For **Direction3D**, **Ray4D**, and **TranslationDirection5D**, the first 3 values represent the target direction.

      direction = pose_frame.M * KDL::Vector(0, 0, 1);
      ComputeIk(trans, direction.data, vfree.size() > 0 ? &vfree[0] : NULL, solutions);
      return solutions.GetNumSolutions();

    case IKP_TranslationXAxisAngle4D:
    case IKP_TranslationYAxisAngle4D:
    case IKP_TranslationZAxisAngle4D:
      // For **TranslationXAxisAngle4D**, **TranslationYAxisAngle4D**, and **TranslationZAxisAngle4D**, the first value represents the angle.
      ROS_ERROR_NAMED("ikfast", "IK for this IkParameterizationType not implemented yet.");
      return 0;

    case IKP_TranslationLocalGlobal6D:
      // For **TranslationLocalGlobal6D**, the diagonal elements ([0],[4],[8]) are the local translation inside the end effector coordinate system.
      ROS_ERROR_NAMED("ikfast", "IK for this IkParameterizationType not implemented yet.");
      return 0;

    case IKP_Rotation3D:
    case IKP_Translation3D:
    case IKP_Lookat3D:
    case IKP_TranslationXY2D:
    case IKP_TranslationXYOrientation3D:
    case IKP_TranslationXAxisAngleZNorm4D:
    case IKP_TranslationYAxisAngleXNorm4D:
    case IKP_TranslationZAxisAngleYNorm4D:
      ROS_ERROR_NAMED("ikfast", "IK for this IkParameterizationType not implemented yet.");
      return 0;

    default:
      ROS_ERROR_NAMED("ikfast", "Unknown IkParameterizationType! Was the solver generated with an incompatible version of Openrave?");
      return 0;
  }
}

Is there something in the kinematics.yaml file for the RViz plugin I need to change?

I know that the standard kinematic solvers do not work properly for my arm as it only has three degrees of freedom, but unfortunately IKFast has proven much more trouble than it is worth.

Is there a solution to this?

Kind Regards Bart

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2014-09-04 03:39:24 -0500

updated 2014-09-04 03:40:17 -0500

What this means is: You have correctly created a Translation3D solver using IKFast. But the plugin, which wraps your solver, doesn't know how to handle Translation3D yet, because I haven't implemented it yet; I have never used Translation3D, so I couldn't test it.

What the switch statement you quoted does is that it calls ComputeIk() from the generated solver; the ComputeIk() type signature is always the same, but the meaning of the arguments differs depending on the IkParameterizationType. For Translation3D there is only the translation, which is already stored in the variable trans, so you can probably leave the second argument (the direction/rotation/...) as NULL, like this:

    case IKP_Translation3D:
      ComputeIk(trans, NULL, vfree.size() > 0 ? &vfree[0] : NULL, solutions);
      return solutions.GetNumSolutions();

Please let me know if it works, so I can update the moveit_ikfast package!

P.S.: I recommend asking MoveIt-related questions on the moveit-users mailing list, since most developers are reading that.

edit flag offensive delete link more

Comments

Thank you. It did cross my mind to put in the ComputeIK call in those case statements, but I was not sure of the calling convention for it. Can I confirm that if this works properly I will be able to drag the arm around in Cartesian coordinates in 3D in RViz?

bjem85 gravatar image bjem85  ( 2014-09-04 03:54:23 -0500 )edit

Yes, correct.

Martin Günther gravatar image Martin Günther  ( 2014-09-04 04:20:59 -0500 )edit

I can confirm that Martin's answer is correct. Thank you very much. I just need to tidy up the behaviour a little when the end effector reaches the limits of its workspace (it tends to jump around) but other than that this is the answer.

bjem85 gravatar image bjem85  ( 2014-09-04 20:22:12 -0500 )edit

I just noticed that somebody already added Translation3D support to moveit_ikfast (in commit f8c8cc2e76) in February, so this is already fixed in the source (only not released as .deb yet).

Martin Günther gravatar image Martin Günther  ( 2014-09-05 03:23:23 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2014-09-03 23:17:20 -0500

Seen: 729 times

Last updated: Sep 04 '14