Robot Math

    Goodmorning,


    i have a problem with a kuka robot. i will not specify the robot because i think it's common for everyone. When i do a calculation with the robot and then with a calculator the results are different.


    i make an example:


    On robot : 1402.64*1402.64*199.69= 392869920

    On calculator: 1402.64*1402.64*199.69= 392869900,239424


    For the robot i'm using a REAL variable. This is just a little calculation, part of a bigger one. I have already a problem if it is so different.

    I don't get it, why the results are so different? Why doest it happens?

    that is because you do not understand data types and REAL variable limitations.

    REAL is a 32-bit variable but only 23 bits are used for mantissa or significand.

    that is because REAL data type is encoded, 1 bit is used for sign and 8 more bits are used for exponent so from original 32bits used for REAL, only 23 bits remain for significand... (or 24 because there is a trick in binary format representation that recycles MSB of the significand)


    so using only 23 bits one can represented maximum 8388608 states


    but your significand value is 392869900239424

    (when looking at significand, decimal point or decimal comma is just cosmetic...)

    to represent such value you would need more bits (more states).


    unlike REAL, integers are not encoded so all bits could be part of significand.

    but even so, with 32 bits you only get up 4294967296 states.


    so 32-bit data types simply cannot store your value with accuracy that you expect.

    and KRL does not implement 64-bit FLOAT or CURRENCY. if you want to retain as many digits as possible you have few options but each requires intimate knowledge of computing systems.

    then you could get something like 392869900.24 instead of 392869920

    for more info read https://en.wikipedia.org/wiki/IEEE_754


    using 64-bit FLOAT one gets 53 (54) bits for significand.


    Currency is another format that uses 80-bits in total.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    we all know that 1/3.0 is 0.33333333333333333333333

    but when constrained to 32-bit REAL you get rounded result as seen here. note that 23bit significand means that in base 10, only maybe 7 or so figures are correct but you are expecting 15 or more.


    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Yeah. For 99.9% of applications, it never matters, b/c for robots, you usually only do math like this to compute motion offsets. And when we're talking about mm, anything past 0.01, maybe 0.001, is simply noise -- the robot cannot move accurately enough for the difference to matter.


    For example, a typical industrial robot rated for a 200kg payload might have a rated repeatability of 0.1mm, and an accuracy of 1.0mm. So anything more than 1 decimal place serves little purpose, aside from reducing rounding error when projecting coordinates throughout the robot's reach envelope. So most robots' math capabilities are built to be "good enough," and not waste resources on trying to go further.


    (from personal experience, this can trip you when you're trying to program the robot in a vehicle coordinate system where the the origin is 100m away from the robot's base. But in a case like that, you need to convert your coordinate system at the CAD/Simulation level, not try to do mathematical projection in the robot)


    For the very rare 0.1% of applications where higher precision is required, it's usually achieved by the use of special tuning, anti-backlash techniques, or external high-accuracy measuring devices feeding corrections to the robot (often a combination of 2 or more).

    yes, doing math externally using 64-bit or higher is a one way to go. the other thing is to rethink what the numbers actually represent. if the value is a distance in mm, then 392869900.24mm is nearly 393km or 244miles.


    so using 32-bit REAL one gets some 20mm approximation error on a length of 392.9km which is not that bad. if this robot was on a 40m long rail, this rounding error would be 10000x smaller too - on the order of a micrometer. so to really see if this is even a problem, one would need to know what the numbers represent.


    here is an example of direct assignment (error is 12.24 or 0.000003%)

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Goodmorning. Thanks for the replies. my problem was that I needed to calculate the radius of an arc passing through 3 points. To do that I used a system with 3 variables with very high X, Y terms due to the high distance of the points taken from the origin of the base. Approximating how the robot does made the error in the end turned out to be too large (The radious in the end it should have been 25 but it was 21 for the robot calculation). I was able to realize that it was a problem related to the max value of a REAL, but since I cannot rely on a PC to do the calculations I was "forced", as a solution, to consider the first point of the arc as the point of origin (so that the terms of my system were smaller). After that I still couldn't understand the problem about REAL but you solved a huge dilemma for me. Thanks so much guys.

    Quote

    maybe post your code or method to compute the result. that will offer chance to comment on it and offer tips to resolve it.


    not sure what do you mean by radius 25 or 21. is that millimeters?

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Ye, i was talking about the radius of the arc ( in millimeters).

    Anyway this is the code i wrote to calculate the radius of my arc.

    The first part is just the resolution of the system to find out a,b,c. after that i calculate the arc.

    i tryed with the traslation of the origin to the first point of the arc to "fix" the approssimation of the robot and now it is working good.


    so what kind of input data you are feeding into your function?

    i just tried some large input values for three points that form 25.000mm radius and got good result..


    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Now it works with big numbers because i modified it.


    in the lines:

    ---------

    ;TRASLO LO ZERO DELLA BASE AL PRIMO PUNTO DEL ARCO E ESTRAPOLO LE COORDINATE DEGLI ALTRI DUE PUNTI


    X2=X2-X1

    Y2=Y2-Y1

    X3=X3-X1

    Y3=Y3-Y1

    X1=0

    Y1=0

    ---------

    I set the input values of first point as zero (origin). Then i calculate the delta between zero and the other 2 points.

    It's like i am drawing my arc not where his really position is but near the zero of the base. In this way the x,y values of my 3 points are low. In the end i just need to find a radius of an arc. If it's a kilometer far from my origin or just at 2 millimiters it doesn't change the radius value. But for me is better use the little values instead of big ones.

    I'm not sure if i explained it well.

    foffulaRob

    I just wondering what kind of robot you are using.

    panic mode made a test with a 25m radius and it worked well.


    Normally for distance you have to expect 1/10th of millimeter and for degree 1/1000th of degree.


    In your first post you mentioned the number 392869920 (for kuka, these are mm) and this means, that you are actually talking about 392.7 km. What kind of robot is that?


    I did not know that kuka is selling a robot this size



    Quote from MOM

    In your first post you mentioned the number 392869920 (for kuka, these are mm) and this means, that you are actually talking about 392.7 km. What kind of robot is that?

    This value was an intermediate result in the calculation. The initial value was 1402 mm, that's a normal robot.

Advertising from our partners