KUKA base transformation not accurate enough

Hi there!

I work with a KUKA KR 16 R2010 and I am having an issue with setting a base.

My task is to devise an algorithm that would process two sets of input points – one of points expressed in the coordinate system of the robot, and one of the same points expressed in the global coordinate system - and output a transformation between the two coordinate systems. This transformation would be defined by a set of XYZ-ABC values and would be used to ‘teach’ the robot a base that would enable it to move to points expressed in the global coordinate system. I managed to do that, but the problem is that the distance between the points where the robot is instructed to go and the points it actually goes to (the average Euclidian distance, which I will be referring to as ‘error’) is too large. The steps of my process are the following:

• I set the global coordinate system in a total station
• I move the robot to some arbitrary points and store their coordinates in the robot’s coordinate system
• I measure the position of each point with the total station and store its coordinates in the global coordinate system
• using Ordinary Least Squares regression, I obtain a translation matrix and a rotation matrix
• I compute the angles of rotation A, B, C with the following algorithm:
• After I obtain the angles A, B, C, I use them to compute a quaternion by following these steps (first image from attachment, or https://doc.rc-cube.com/v21.07/en/pose_format_kuka.html )
• I use the resulting quaternion to compute a new rotation matrix using this formula (second image from attachment, or https://doc.rc-visard.com/v21.…ernion-to-rotation-matrix)
• To test the transformation, I apply it to the points expressed in the global coordinate system and compare the result (now expressed in the robot coordinate system) with the points that were not transformed (which were originally expressed in the robot’s coordinate system, stored when the robot was moved, not measured with the total station).

sb = R(3, 1);

cb = sqrt(1 - sb^2);

ca = R(1, 1);

sa = -R(2, 1);

cc = R(3, 3);

sc = -R(3, 2);

A = atan2(sa, ca) * -180 / pi;

B = atan2(sb, cb) * -180 / pi;

C = atan2(sc, cc) * -180 / pi;

where R is the rotation matrix

If the next steps show that the transformation is accurate enough, these A, B and C would be passed to the robot (manually, via the HMI) together with the translation found at step 4 to teach it the base that would enable it to go to points expressed in the global coordinate system.

The error is calculated as the average Euclidian distance between points (third image from attachment). If the transform is good, they should be very close.

Right now, the average error that I get is 4.85 mm, and I would like to have an error of 2 mm or less.

Notes:

• From what I’ve seen, what I call ‘robot coordinate system’ is usually referred to as ‘world coordinate system’
• I mastered the robot, which made the error decrease from 5.67 mm to 4.85 mm
• I use 6 points; measuring more did not help, and we are looking for a solution that would work with only 4 points
• The total station measures in a left-handed coordinate system; I compensate for this by multiplying the y-coordinates with -1 before computing the transformation
• I assume that once the robot is given a transformation XYZ-ABC, it computes the quaternion and the rotation matrix the same way I do
• One thing I forgot to mention is that I don't work with KRL. I use a Matlab script which I will later use to create a TcCOM object and that's where the transformation will take place.
  

If you have any suggestions or know a resource that I could use to solve my issue, I would greatly appreciate it.

Thank you!

Quote from MOM

With the angles A, B and C you can also calculate rotation matrix R.

You must actually get the same values as using quaternations to calculate a rotation matrix

You mean calculate the Euler angles? Yes, I checked and that returns the same values. One thing I forgot to mention is that I don't work with KRL, so I can't use the zip files from panic mode. I use a Matlab script which I will later use to create a TcCOM object and that's where the transformation will take place.

Quote from panic mode

provided code is shared working example. how can it not be useful, specially for someone aiming to write code? also it is in a plain text and easy to translate to any other language. and it is commented too...

in other words - a perfect job for a student...

vectors are simply declared as FRAME but only X,Y,Z values are used (A,B,C is ignored)

VEK_LAENGE = vector length (magnitude), in MATLAB that is norm(A)

KREUZ_PROD = cross product of vectors, in MATLAB that is cross(A,B)

SK_PROD = dot product of vectors, in MATLAB that is dot(A,B)

NORM_VEK = normalize vector, in MATLAB that is A/norm(A)

ATAN_EPS = a constant of sufficiently small value, value here is chosen for 32-bit computation, in MATLAB you could also make is smaller

https://www.mathworks.com/matl…ize-vector-to-unit-length

https://www.mathworks.com/help/matlab/ref/cross.html

https://www.mathworks.com/help/matlab/ref/dot.html

https://www.mathworks.com/help…/math/array-indexing.html

Display More

Yes, you are right, I should be able to use it. I did try to understand it, but I got stuck at the point where a function is called, but the output is not stored to a variable, nor a global variable seems to be modified (the line NORM_VEK (P_X[], 3)). A colleague explained what that and other parts of the code do, so I think I got it.

This being said, I still have a question.

I compute the transformation between two coordinate systems using points expressed in both of them - the world points (expressed in the robot coordinate system) and global points (same points in space, but expressed in the global coordinate sysytem, measured with the total station).

In your algorithm, you only use one set of points - the coordinates of the points in only one coordinate system. Is it correct if I assume that the three input points for your algorithm are considered to be exactly in the origin, on the X axis and on the Y axis, of the new coordinate system?

If that is true, it will be difficult for me to use your algorithm, since I cannot measure the origin of the world coordinate system with the total station because that point is inside the robot. I also cannot measure the origin of the global coordinate system with the robot because the robot cannot reach that point.

Maybe my assumptions are wrong, but I hope I express them clearly.

Thank you

Thank you for your reply.

By 'measure WORLD' I mean measuring using the total station, which is necessary for the algorithm I described.

I cannot use the transformation done in KSS because our use case requires this step to be automated, this is why I am using Matlab. I will still try the KSS 3-point calibration to see if the error is coming from something else other than my algorithm.

One question about your algorithm: how do you deal with translation? The only outputs are the A, B, C angles, but when I set a base in the KUKA HMI, for example, I also have to specify a translation matrix (X, Y, Z).

Thank you!

Thank you, I don't know how I missed that

I am confident I implemented the algorithm exactly as it is in your file, but I still get an average error of 9.584 mm. Moreover, I used the 3-point calibration method available in the KUKA HMI, and with that I get an error of 9.481 mm. With the indirect method (4 points), I get an average error of 16.071 mm.).

Do you have any ideas/suggestions?

Thank you for your help so far.

Quote from SkyeFire

What's the residual when you perform the transformation?

4.85mm... over what distance? In what directions? Relative to what? Are you using anti-backlash techniques? How far is the robot being stretched? How rigid is your EOAT? How good is your TCP? How much is the TCP orientation changing across your test sample? How large is your test sample -- how many points across what spatial volume?

Every one of these can contribute to accuracy errors, and isolating and testing for each one is required to get good performance. Robots are not accurate devices -- they are built for precision/repeatability, but sacrifice accuracy to achieve their expansive motion envelopes and low price point compare to CNC machines of comparable working volume.

https://info.appliedmfg.com/mmc-ebook

I'm not sure what you mean by 'residual', given that I am not comparing my measurements with predicted values or a mean, but to the actual true values. To answer your questions:

- my error is just the average distance in space (so sqrt((x₁-x₂)² + (y₁-y₂)² +(z₁-z₂)²) ), so not in a specific direction

- the distance is relative to where the points SHOULD be. I work with the assumption that the robot has a neglijable error when it stores the coordinates of its tool. I compare these coordinates (x, y, z) to the coordinates measured with the total station (I take these by pointing the total station at the tool tip - a reflector, in my case, leica gmp 101)

- I don't know what anti-backlash techniques are

- the 6 points measured are never farther from the robot's base than 1.7 m on any axis

- I calibrated the TCP recently, but I don't remember what was the error for that

- it is changing a lot, and I prefer it that way becasue I want to have a less than 2 mm error for any orientation (or sequence of changes in orientation)

- I measure 6 points; I will add the 2 sets here, in case anyone would like to try finding a XYZ-ABC base that maps from one to the other:

XYZ_GLOBAL = [720.9, -1608.7, 1140.1; 316.4, -1599.9, 1649.1; 444.3, -1284.2, 509.8; 626.6, -1041.0, 956.1; 632.7, -538.3, 1349.3; 220.2, -519.3, 1241.7];

XYZABC_ROBOT = [542.573792, -1015.0, 1139.8335; 944.124817, -1015.0, 1652.27429; 823.826416, -689.0, 512.620239; 645.906067, -447.0, 959.713867; 645.90625, 53.4078636, 1356.29163; 1058.31787, 67.6461945, 1251.17578];