[AustinMooreZ]

I've ran into a few situations in RoboDK with a calibrated robot where I can solve forward kinematics, but I can't solve inverse kinematics.

Example joints where this occured:
[-12.330000, -2.750000, -36.190000, 170.420000, 0.030000, 19.520000]

For example these joint values for my calibrated Motoman mh180-120 will work forward and inverse for uncalibrated kinematics.

But if I enable calibrated kinematics forward kinematics works, but inverse fails.

I found the above joint values from a robot operating in the field that came across this error, but I was able to find many more by running the following script. 

It randomly sample joint space within the robot's joint limits at whole degree values for simplicity.

I used this code for testing:

Code:

import random
limit_upper = [89.0, 75.0, 89.0, 359.0, 129.0, 359.0]
limit_lower = [-89.0, -59.0, -85.0, -359.0, -129.0, -359.0]
step = 1.0 
seed = 42
counts = [int((hi - lo) / step) for lo, hi in zip(limit_lower, limit_upper)]
if seed is not None:
    random.seed(seed)
tool = rbt.PoseTool()
frame = rbt.PoseFrame()
def random_joints(num_trials, func):
    for _ in range(num_trials):
        offsets = [random.randrange(c) for c in counts]
        jnt = [lo + off * step for lo, off in zip(limit_lower, offsets)]
        if func(jnt):
            return jnt
    return []
def test(jnt):
    rbt.setJoints(jnt)
    pose = rbt.SolveFK(rbt.Joints(), tool=tool, reference=frame)
    newjnts = rbt.SolveIK(pose, rbt.Joints(), tool=tool, reference=frame)
    if len(newjnts.tolist()) == 1:
        print(jnt)
    return False
random_joints(10000, test)

[Albert]

When using calibrated kinematics, the inverse kinematics solver can fail even if forward kinematics works because the calibration modifies the robot's kinematic model, potentially introducing small deviations or complexities that make the IK problem harder to solve or cause no valid IK solution to be found for certain poses.

This issue can happen near joint limits. You could customize joint limits for the nominal model to be slightly more constrained to avoid finding solutions for the nominal model but not for the accurate model.

Also, if you use the robot kinematics for self positioning (you self calibrate the tool/TCP and you use the robot TCP to teach the location of the part) it may help if you remove the calibrated base frame parameters and the tool frame parameters. You may need to re-teach your TCP though.

Can you share your calibration project with your robot? We may be able to take a better look.

[AustinMooreZ]

I expected that there wouldn't be a clean one to many inverse for the forward kinematics given both the calibrated links and the mass modeling preventing us from having a nice closed form expression for the inverse.

I'd imagine your inverse kinematics uses some sort of optimization method (Nelder–Mead maybe) to produce the joint solution. And if your TCP is near the edge of your working envelope, then it may not converge to a solution.

I would imagine if I'm well within joint limits I wouldn't have any issues with the inverse kinematics solver.
For example these joints are well within my robots joint limits, but the inverse kinematic solver fails to find a solution. See attached image for reference on how close this is to the limits.
[0.000000, 0.000000, 0.000000, 66.600000, 0.000000, 0.000000]

   

Here is the code I used to test to see if there was an issue with inverse kinematics.

Code:

rbt, _, _, _, _ = connect_to_robot(simulate=True)
tool = rbt.PoseTool()
frame = rbt.PoseFrame()
jnts = rbt.Joints()
print(jnts)
pose = rbt.SolveFK(jnts, tool=tool, reference=frame)
print(pose)
newjnts = rbt.SolveIK(pose, tool=tool, reference=frame)
print(newjnts) # if singleton no solution

[[ 0.000 ],
[ 0.000 ],
[ 0.000 ],
[ 66.600 ],
[ 0.000 ],
[ 0.000 ]]

Pose(2036.443, 426.672, 3610.794,  -66.652, -0.043, -0.096):
[[ 1.000, 0.002, -0.001, 2036.443 ],
[ 0.000, 0.396, 0.918, 426.672 ],
[ 0.002, -0.918, 0.396, 3610.794 ],
[ 0.000, 0.000, 0.000, 1.000 ]]

[[ 0 ]]

Lastly, I'm working with folks to get you a station with one of our calibrated robots. We have some proprietary information that would like to not disclose.

[Albert]

The issue you are referring to in your last example is happening because you are very close to a singularity (joint 5 is zero). Which will have a behavior similar to calculating the inverse kinematics near the joint limits.