DH parameters – UR10 Calibration

[Fotalo]

#867

Dear,

I’m calibrating motion between a 3D camera system and a tool. I compute all forward and inverse kinematics using the DH parameters. I ran into a strange issue. I’m using a UR10 CB3 model. From the CalibrationManual.pdf (PDF), I get the following DH parameters:

r1 = 0.0000; d1 = 0.1180;
r2 = -0.6127; d2 = 0.0000;
r3 = -0.5716; d3 = 0.0000;
r4 = 0.0000; d4 = 0.1639;
r5 = 0.0000; d5 = 0.1157;
r6 = 0.0000; d6 = 0.0922;

However, from the website: https://www.universal-robots.c…..ics-45257/ 62 (WEB) I get:

r1 = 0.0000; d1 = 0.1273;
r2 = -0.6120; d2 = 0.0000;
r3 = -0.5723; d3 = 0.0000;
r4 = 0.0000; d4 = 0.1639;
r5 = 0.0000; d5 = 0.1157;
r6 = 0.0000; d6 = 0.0922;

The differences amount into a different TCP Z value of about 8.1mm. The (WEB) appears to be in line with what the teach pendant says. So why are there 2 different sets? And why does the “official” CalibrationManual.pdf has such an error? Anyway, for calibration it doesn’t really matter (I work with motor angles directly), but here’s the real kicker, The absolute error of the robot positioning is very different depending on the set used (note that I do compensate with the values given in the file calibration.conf), And even after CAM tool calibration I’m left with positioning errors…

I’ve checked the tool calibration data by computing the TCP from 4 poses by a) the teach pendant and b) my own matrix calculations. Both calculations agree within 0.1mm.

Q1: What set of DH to use? (WEB) or (PDF) or something different?
Q2: Why is the calibration from cam to tool still a few mm’s off?

[Fotalo]

#981

A little update. Turns out that the “website”-values are the correct ones. These correspond with the values in urcontrol.conf.UR10 as found on the robot. The (PDF) values are wrong.

[Wioman]

#982

Hello,

I suggest you to read this post, it could help : Direct Kinematic model – DH parameters 73
The right DH values of your robot are stored in the installation file ( *.urp).

Bye

[Fotalo]

#983

Hi,

Hmm seems similar, but not exactly. Were can I find the .urp file? these are binary, so how to convert to human readable form? And I’m using calibration.conf + controller.conf.UR10 (just like you). My FK does match the display, but not the real world. What python implementation did you use? Any .py file to share?

Thanks.

[Wioman]

#984

Hi,

The urp file of a program is located in the program folder of the robot. You can download it using an ftp connexion (user : root / psw : easybot), filezilla works fine. The extension is .urp but in fact you can unzip it. Inside the zip there is an xml file. The first lines of this file describe the DH parameters.
Q1 answer : use in your calculations these parameters ( the controller uses these values)

How do you measure the accuracy in the real world?
It’s normal to do not have the same real position as the controller in the real world. A robot is repeatable (+/-0.1mm announced by UR) but not accurate ( I have in mind minimum 10x it’s repeatability so +/- 1mm in the best case).

hope it will help

[Fotalo]

#985

Ok, thanks. I checked the unzip trick and it works fine  I also noticed that the DH parameters in the XML part are exactly the sum of the DH parameters from the urcontrol.conf.UR10 + the calibration.conf.

I determine the “accuracy” as follows. I scan a ref object with a 3D camera, compute 3 locations. Then I touch the 3 locations with the robot. This gives me a conversion matrix from camera to robot. I then scan a new object and have the robot trace out the outer contour of this new object. The result is not bad, but the points are off, 1 location is good enough, 2 locations have 2 to 3mm error and one has 5mm error. As if there’s some rotation about the robots Z axis of say roughly 0.5 degrees.

The calibration of the camera seems ok, so does the 3 point calibration and now the DH checks out, too. I could remove the tool calibration, just to eliminate another source of error.

[Wioman]

#986

The robot manufacturer speaks about cartesian repeatability +/-0.1 mm (X, Y, Z) but there is also the orientation repeatability (RX, RY, RZ)… I do not have a value for this one. But if you have an important lever arm ( distance TCP – flange) it will increase significantly the cartesian error.

[Giuzus]

#987

we don’t state an accuracy specification. There is repeatability then there is accuracy, industrial robots in general have pose accuracy not quite as precise as their repeatability.

There is a ISO standard that goes into a lot more detail for related test methods when it comes to manipulating industrial robots if you want to check that out I believe it is ISO9283. Usually accuracy is used to compare different industrial robots in similar applications, since it could be dependent on mass, axial CG offset, radial CG & TCP offset, and axial TCP offset.

[Fotalo]

#988

So I experimented a bit more. Turns out, it was bad calibration all along! I 3D printed a new calibration shape to calibrate camera-to-robot and everything is fine now.

As a side effect, it doesn’t really matter if you use the “corrected” DH parameters at all, which opens up the possibility of using Inverse Kinematics formulas, which are a lot faster then the Jacobian method. But if you need “Polyscope”-accuracy, eg your calculations should match the PolyScope display, you should use the robot calibration correction values, including the smoothing on the rotation part!

[Author]

Posts