Posts by Puck

    Have a look at Fubini's answer:



    Hi,
    driving in T1 absolute accuracy is deactivated, but the value reading $pos_act still has absolute accuracy included.
    Fubini


    Or look at my old post:


    Take a look at the german robot forum:


    http://www.roboterforum.de/rob…r/11462/msg55090#msg55090


    Calculate the flange orientation matrices and flange positions from the four flange frames:


    R_1 * t + r_1 = P with orientation matrix R_1 = R_1(A_1, B_1, C_1) and position r_1 = [X_1, Y_1, Z_1]^(T)
    R_2 * t + r_2 = P with orientation matrix R_2 = R_2(A_2, B_2, C_2) and position r_2 = [X_2, Y_2, Z_2]^(T)
    R_3 * t + r_3 = P with orientation matrix R_3 = R_3(A_3, B_3, C_3) and position r_3 = [X_3, Y_3, Z_3]^(T)
    R_4 * t + r_4 = P with orientation matrix R_4 = R_4(A_4, B_4, C_4) and position r_4 = [X_4, Y_4, Z_4]^(T)


    The vector t = [X_TCP, Y_TCP, Z_TCP] is the unknown TCP and the point P is the reference point used by the XYZ 4-point method.
    Rearrange the equations and eliminate the reference point P:


    R_1 * t + r_1 = R_2 * t + r_2
    R_1 * t + r_1 = R_3 * t + r_3
    R_1 * t + r_1 = R_4 * t + r_4


    Rearrange:


    [R_1 - R_2] [r_2 - r_1]
    [R_1 - R_3] [ t ]= [r_3 - r_1]
    [R_1 - R_4] [r_4 - r_1]


    9x3 3x1 9x1


    Solve the overdetermined system of the form A x = b. Good luck :zwink:


    Bye Puck

    RoboticsMan



    ... Then I rotate the tool 180 degrees around its vertical axis (usually the z-axis, angle A). Most of the time, the tcp-pointer will drift several mm sideways when I do this, even when the 4-point calibration claimed that the error was only 0.5 mm


    Be carefull, if you use an absolute accurate robot and jog the motion manually, then the TCP may/will move.


    http://www.robot-forum.com/rob…expect/msg50650/#msg50650


    Bye Puck


    PID import: Error 8 importing file prec_rob0000501068.xml


    The machine data ($robcor.dat, $machine.dat) of the robot are not consistent with absolute accurate robot model (prec_rob0000<Serial-No>.xml).


    The PID file is encrypted, because of that you can not search for the inconsistent machine data. You may ask KUKA for help.


    ... Its not like every part on the HA is custom for that model. I was told they are simply verifying the gearings experimentally, as opposed to using nominal numbers, measuring frictions, etc.


    If you compare machine data of a "HA robot" with a "not HA robot", they do not match. E.g. the gear ratios of #KR120R2700 EXTRA HA are different than #KR150R2700 EXTRA, because these robot types use mechanical different gearboxes. #KR120R2700 EXTRA HA and #KR150R2700 EXTRA are brothers, but not twins :zwink:



    regardless I think you are right, as all AA really means is having a customized CAL, maybe PID file as well, so you can do that at the factory or in the field(as long as its done by kuka).


    The CAL is used while mastering the robot with EMD (first mastering, teach offset, master load with offset). Every mastered robot has got an individual CAL file.
    The PID stores the paramaters of the absolute accurate robot model (KRC 5.X: <Serial-No>.pid, KRC 8.2 prec_rob0000<Serial-No>.xml). Every absolute accurate robot has got an individual PID file.


    They are indeed two different things. HA means matched gears, and careful calibration (at factory), etc.


    The "HA robots" are their own robot type. They may have the same dimensions like other robots, but they may use different gearings/motors. The HA robots use mechanical different gearings to improve the path accuracy and path dynamics.


    Additional all HA robots are "absolute accurate calibrated" at the factory.



    Also on the Quantecs they de-rate the max payload a bit for a given reach(KR150R2700 becomes KR120R2700).


    A #KR120R2700 EXTRA HA may look like a #KR150R2700 EXTRA, but it's a different kind of robot.



    AA means field laser calibration.


    I don't think so. It is possible to do field calibration with a laser tracker, but most absolute accurate robots are calibrated at the factory.


    ... it means that I should write down the X- Y- and Z- coordinates before I jog, and then compensate after changing the orientation, so that I end up with the same X-, Y, and Z- coordinates. I will try that!


    Or just display the actual Cartesian position and orientation and jog to compensate the displayed difference :zwink:



    Is this information that can be seen in any of the Kuka manuals?


    Yes it is, but the description is very cryptic, e.g. "KUKA System Software 8.2, Operating and Programming Instructions for System Integrators":




    Bye Puck


    ... If I use the teach pendant to change the A, B or C angle of the tool, then I expect the TCP pointer to remain stationary while the orientation changes. So what you are saying is that if the TCP drifts, then the X-, Y- and Z-coordinates will also change on the teach pendant?


    Yes, if you jog an absolute robot with the teach pendant, e.g. a rotation round z, the other components (x, y, z, b ,c) may/will change too. If you run a programme, e.g. a rotation round z, the other components (x, y, z, b ,c) will (hopefully) not change.


    The difference between jogging the robot and running a program:


      • Running a program: The motion planning is done a with the absolute accurate robot planning algorithm (abs. acc. forward kinematics and inverse kinematics) and the display shows the result of absolute accurate robot planning algorithm (abs. acc. forward kinematics).

      • Jogging: The motion planning is done without the absolute accurate robot planning algorithm, but the display shows the result of absolute accurate robot planning algorithm (abs. acc. forward kinematics).


    An absolute accurate robot allways knows and shows the correct position and orientation of the TCP (within the tolerances of the absolute accurate robot model), which is calculated by absolute accurate forward transformation.


    Bye Puck


    We jog the robot until the TCP-pointer is vertical, and is pointing down to a well-defined point. Then we change the A-angle by 180 degrees. When we do this, the TCP-pointer drifts 3-4 mm away from the starting point. This means that the TCP offset found by the 4-point calibration procedure is wrong by at least 1.5 to 2 mm. Furthermore, if we place the robot in a pose where the TCP pointer is horizontal, and then change the B or C angle by 180 degrees, then the TCP pointer drifts 5 mm or more.


    Uhh, if you manually jog an absolute accurate KUKA robot, the robot controller will not plan an absolute accurate motion. But the robot does not lie, it will display actual Cartesian position and hence the possible drift.


    Bye Puck


    1. Is it possible to restore factory mastering in the KRC4? (KR6 Agilus robot)


    Should be possible with the MEMD for A1 to A5, because that is the purpose of the MEMD. A6 can't be mastered with the MEMD, so the original factory mastering of A6 is lost. Does your robot use a MAM-File, i.e. $INDIVIDUAL_MAMES=#RDC within $machine.dat?



    2. Is it possible to manually write the mastering data? (because I have written on a sheet of paper the factory mastering results i.e. offset angles from where the MEMD registered 0 on each axis - as described in my first post)


    Nope, the mastering data are stored within the <Serial-No>.mam, but this file can not be edited.


    The technical manual says repeatability is +-0.1mm.


    Usually the repeatability RP of a KUKA robot (Fanuc, Motoman, ABB as well) is much better than 0.1 mm (error radius, not +/-). Often the measurement systems are not accurate enough to measure the robot's repeatability :zwink: Additional it is difficult to measure the repeatability, but not some kind of thermal drift.



    But according to ISO 9283 repeatability is given by an absolute value(without +-). Also the speed and loading conditions are not given in the manual.


    KUKA uses according to ISO 9283 the default payload and 100% speed.



    ... minimum accuracy of about 0.91mm ...


    With an absolute accurate KUKA robot (with correct load data) the mean value of the pose accuracy should be smaller than 0.7 mm, typically 0.5 mm (according to ISO 9283, i.e. ISO cube but not the whole workspace). If the robot is not absolute accurate the pose accuracy may be up to some millimeters.



    ... for planar motion at 30% speed ...


    Riby, maybe you have measured the path accuracy AT?

Advertising from our partners