# 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.

edit retag close merge delete

Sort by ยป oldest newest most voted

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.

more

Thank you for pointing out the discussion. The problem was that I did not consider the manufacturer's calibration. Without the calibration data, using moveIt and universal_robot package to navigate the robot will result in at least 2mm off from the target TCP pose. The positional error I mentioned was in meter actually.

( 2019-06-11 14:37:28 -0500 )edit

The positional error I mentioned was in meter actually.

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

( 2019-06-11 14:43:13 -0500 )edit

I hope this may help those who are new to UR robot.

I talked to UR technical support and was aware of the calibration.config file generated from kinematic calibration[1]. The kinematic solutions, namely forward and inverse, must be compensated according to calibration. For example, compensate for DH parameters in forward kinematics, compensate for position error in inverse kinematics using Jacobian inverse.

A detailed discussion that might help in using the calibration data can be found here[2].

more