Hello,

I have a question/problem with inverse kinematics in VREP. I'm using Jaco

Arm as provided by VREP and successfully set up the IK Group between

end-effector and target dummy. I selected all of constraints x, y, z,

alpha-beta, gamma. it gives correct IK result and follows the target in

most cases. However, in some cases, it fails.

1-Using Pseudo Inverse

In the beginning, I tried the pseudo-inverse method. It resulted in strange

behavior (looks like give random angles to joints) if the target is out of

workspace, so it is clear we can understand that. However in some target

poses within the workspace, it gives wrong results, which means IK solver

gives a result and arm is stable but the end effector is not at the target

position and orientation. So there is a large error.

2-Using DLS

As you suggested DLS is more stable but even in some target poses within

the workspace, DLS also gives wrong results, which means couldn't solve.

I'm wondering why it fails to solve even some target poses looks so easy?

Is that caused by lack of IK solver algorithms or something else? I suppose

that the target poses are not required singular configurations because IK

solver gives a result with an error. It does not just move like crazy as

target pose in out of workspace case.

My second question is it possible to determine the singular configurations

from VREP?

Thanks!

## Inverse Kinematics Question

### Re: Inverse Kinematics Question

Hello,

my guess is that you have joint limits that hinder the IK solver to reach the position. Or (if your robot is dynamically enabled), it could be that some collisions are in the way (e.g. also self-collisions). IK results can also appear wrong if the start configuration is too distant (in terms of configuration space) from the target. If this is the case, try smaller steps.

You can compute the manipulability value of the current configuration. See sim.getIkGroupMatrix.

Cheers

my guess is that you have joint limits that hinder the IK solver to reach the position. Or (if your robot is dynamically enabled), it could be that some collisions are in the way (e.g. also self-collisions). IK results can also appear wrong if the start configuration is too distant (in terms of configuration space) from the target. If this is the case, try smaller steps.

You can compute the manipulability value of the current configuration. See sim.getIkGroupMatrix.

Cheers

### Re: Inverse Kinematics Question

Thank you for your answer. It is caused by joint angle limits and too distant configurations as you said.

I read and implemented simGetIkGroupMatrix. I have some issues about this function. First, I call sim.computeJacobian and then I call simGetIkGroupMatrix, in this way I get current Jacobian. As it is said in document, I calculate sqrt(det(J*JT)) and I can obtain a numeric value. However If I retrieve the manipulability value from API, it is not equal to calculated one so I confused.

Also in some cases, even if the manipulability value from API gives not 'nan' value, it cannot solve the inverse kinematics.

I read and implemented simGetIkGroupMatrix. I have some issues about this function. First, I call sim.computeJacobian and then I call simGetIkGroupMatrix, in this way I get current Jacobian. As it is said in document, I calculate sqrt(det(J*JT)) and I can obtain a numeric value. However If I retrieve the manipulability value from API, it is not equal to calculated one so I confused.

Also in some cases, even if the manipulability value from API gives not 'nan' value, it cannot solve the inverse kinematics.

### Re: Inverse Kinematics Question

I also tried it with PhantomXPincher. I can get Jacobian but when I compute sqrt(det(J*JT)), it is not equal to the manipulability value from API.

here is my scene, https://drive.google.com/open?id=195GfC ... YMltlO20GD

here is my scene, https://drive.google.com/open?id=195GfC ... YMltlO20GD

### Re: Inverse Kinematics Question

Did you check that your Jacobian is the same as the one returned by the API?

Also, there is never a guarantee that IK can be solved. As you know, the Jacobian is the linearization around the current robot configuration. If the target dummy is too far away (or generates too large joint velocities), then IK will overshoot and can become instable.

Cheers

Also, there is never a guarantee that IK can be solved. As you know, the Jacobian is the linearization around the current robot configuration. If the target dummy is too far away (or generates too large joint velocities), then IK will overshoot and can become instable.

Cheers

### Re: Inverse Kinematics Question

Hello again,

I'm not computing Jacobian by myself. I'm getting Jacobian from API, and calculate the manipulability by using this formula sqrt(det(J*JT)). I compare this calculated result with the manipulability value from API.

I used the current value of Jacobian (from API) and, yes, I tried to print Jacobian in the VREP console, this is equal to what I get in python.

I'm not computing Jacobian by myself. I'm getting Jacobian from API, and calculate the manipulability by using this formula sqrt(det(J*JT)). I compare this calculated result with the manipulability value from API.

I used the current value of Jacobian (from API) and, yes, I tried to print Jacobian in the VREP console, this is equal to what I get in python.

### Re: Inverse Kinematics Question

So that means, you use the same Jacobian but your calculation of sqrt(det(J*JT)) is different?

Then one other part of the calculation above must be wrong.

You can have a look how V-REP computes this in file

Cheers

Then one other part of the calculation above must be wrong.

You can have a look how V-REP computes this in file

*v_rep/sourceCode/inverseKinematics/ik/ikGroup.cpp*, function*CikGroup::getLastManipulabilityValue*Cheers