Large motion is caused by smalll movement of the end effector

[jianchaoci]

Dear,

I am using this project in a simulation case with UR5 robot. The motion is first to move the robot to a pre-grasp pose, then slowly move to the grasp pose to perform object grasping. The pre grasp pose is super close to the grasp pose, just 5 cm smaller in z-axis and all the other are same. However, when changing the pose, the robot performs a very large motion. Also the solution from IK_LM() is large. See the attachment. But this problem only happened on Ubuntu 20.04, and not the case on Windows and Mac OS. All the machines are using exactly the same version of the package (1.1.0). How is this possible?
The code of the simulation

[jr-b-reiterer]

I am just starting with the robotics toolbox myself, so I am not sure about all the options, but if you want two IK solutions to be similar, I think you should set one as the q0 argument for the other. (And also the first IK call should probably get some joint pose as q0, maybe your previous or starting robot pose?)

IK in general is nondeterministic - in the case of a UR, there are up to 8 solutions for a reachable end effector pose, equivalent to a combination of 3 binary choices: shoulder right/left, elbow up/down, wrist in/out (names may be inaccurate for corner cases). So you cannot expect to get a solution similar to a certain one if you don't give it any hint to do so.

[francogassibe]

As explained by @jr-b-reiterer . Inverse kinematics may have multiple solutions (8 in your UR5 case). Witch solution is returned on numerical methods (like ikineLM ) depends on some seed value usually called q0. If you don't specify this q0 value it will choose it randomly and thus your solution is gonna be different each time you run the same code. This is what induces your change in configuration (aka: my joint solution is now very far and my robot makes a huge movement to go between two nearby poses). To solve this you should use this q0 value so the ikine function returns the same result. More so, if your q0 value is closer to the solution you are looking for then your chances to get that searched solution are higher! So for instance in your case : solution_pre_grasp, succes =ik_LM(pre_grasp_pose) solution_grasp, succes = ik_LM(grasp_pose, q0 = solution_pre_grasp)

but again here the same question still persist for the 1st call of the ik_LM function

i imagine your robot starts at some configuration (this is usually called home) lets say q_home.

solution_pre_grasp, succes =ik_LM(pre_grasp_pose,q0=q_home) solution_grasp, succes = ik_LM(grasp_pose, q0 = solution_pre_grasp)

WARNING! : if some singularity is present and the algorithm fails to return a solution when using your specified q0 it may retry to perform the inverse kinematics using some random q0 this time and thus potentially changing the configuration of your solution. i believe you can control this behavior by setting some search limit parameter.

And with respect to this change in behavior between operating systems i think that maybe you are just using a different version of the toolbox without knowing. Maybe the mac and windows version don't initialize q0 randomly, maybe they set them to some arbitrary fixed value like q0 = [0,0,0,0,0,0] and so their behavior is deterministic compared to the Linux version. that would explain the change of behavior.