# inverse kinematics in ur_driver is not accurate

I am trying to use the inverse kinematics (IK) solver in ur_driver for my UR5 robot. My goal is to move the robot to a target joint position given a set of robot TCP pose/end-effector pose. However, there is always a small error (about 1mm) in each x/y/z axis after positioning. So I did this quick test for the ur_driver as follows.

1 First, position robot using movegroup.

map<string, double> jointPose;
jointPos["shoulder_pan_joint"] = -0.9217;
jointPos["shoulder_lift_joint"] = -1.5935;
jointPos["elbow_joint"] = 2.236;
jointPos["wrist_1_joint"] = -0.4291;
jointPos["wrist_2_joint"] = 0.2916;
jointPos["wrist_3_joint"] = 0.7746;
move_group.setPoseTarget(another_pose);
move_group.move();


2. Second, record robot tool0 pose as shown in RViz, result as follows.

[position(m),orientation(quaternion)] = [0.33561, -0.13135, 0.1815, 0.64684, 0.33476, 0.68078, 0.077926].


3. Third, position robot with URScript movej() command, record robot tool pose as shown on the polyscope.

[position(m),orientation(rxryrz)] = [0.33667,-0.13125,0.18217,0.7471,-1.4515,-0.1768]


As I can see, there is a slight position difference in each x/y/z direction. So my assumption is the IK solution given by ur_driver is not precise.

I have compared the DH parameters in the driver to that given by [1]. They seem to be the same.

Does anyone know how to compute the accurate IK solution for UR robot? I appreciate any help and insight that could potentially solve the problem.

Originally posted by myf123asd on ROS Answers with karma: 3 on 2019-06-06

Post score: 0

So my assumption is the IK solution given by ur_driver is not precise.

ur_driver does not contain any functionality related to IK or FK.

FK is performed by robot_state_publisher based on the urdf, or the integrated version of that in MoveIt.

IK is performed by whatever kinematics solver you have configured. That could be ur_kinematics, trac_ik, KDL or something else.

The urdf is most certainly not completely correct for your robot. That would be one source of positional error. That is being addressed in ros-industrial/universal_robot#414.

Secondly: both URScript, MoveIt and the driver use different tolerances for when a motion is completed. It could well be that this also contributes here.

Finally, the differences you show appear to be in the micrometers range (ROS uses metres for distances):

        X        Y        Z
moveit: 0.33561 -0.13135  0.1815
movej:  0.33667 -0.13125  0.18217
----------------------------------
-0.00106  0.0001  -0.00067


The repeatability of a UR5 is specced as +-0.1mm or 0.001m (datasheet). Taking that into account the differences don't seem to be so egregious.

Originally posted by gvdhoorn with karma: 86574 on 2019-06-06

This answer was ACCEPTED on the original site

Post score: 1

yes, as I assumed. But 1e-4 would still fall in the micrometre range.