Load data accuracy?

    Hello all,

    I have a small question. How accurate does Load data need to be on a robot?

    A little bit of detail. I am in the process of creating an application for a tool-manufacturing company for their CNC lathe machine. What the robot needs to do is take a raw material from the pallet of raw material, put it into the machine, wait, take out the finished product and put it on the pallet of finished products. Everything else, the safety and the gripper is done by the Siemens PLC. I have already created a prototype working model and we have also developed a working gripper. One of the first things I want to clear off my checklist is the load data. We do not have KUKA.LoadDataDetermination on our controller, so I get Load Data from the the CAD software we use and some mathematical tricks to get it to line up with Load Data that KRL uses.

    However, the problem is the large list of tool-holders that the CNC lathe will be creating out of a large number of starting raw cylinders of material. Some of these raw materials can weigh up to 20 kg, which is the same weight as the gripper itself.

    As I understand accurate Load Data can greatly increase the robot life-time and the number of cycles it can do. The robot I use is not Positionally accurate robot, and that is fine for this application.

    My problem is that it is cumbersome to increase the TOOL_DATA and LOAD_DATA lengths to the number of actual elements that the robot will be handling, and then enter all that into CAD software to get all the data manually. We also want to make the program adaptable, so if suddenly that specific CNC lathe needs to create some new tools that can be as easily incorporated as possible. That is why I would like to use some tricks to make it easier.

    My first option is create a static LOAD_DATA and TOOL_DATA of some length. The tools and the raw materials all have similar shapes and so I could just make a number of virtual copies of different masses and calculate the values on these imaginary parts. Then, when the data is sent from the HMI to the PLC and then to the KRC4 I just examine the data and choose the best approximation out of the statically defined LOAD_DATA[]. This is where the question about accuracy comes in. Using this method I am able to get a maximum mass deviation to equal 1.5% the robot arm's nominal load. I have read in the KUKA.LoadDataDetermination manual that the limiting accuracy is 5% the nominal arm load, but that might just be the LoadDataDetermination algorithm when no load data is input prior.

    My second option is to use mathematical tricks, namely the fact that the payload's primary axes of inertia are almost parallel to the gripper's (one axis is always perfectly parallel). And so I could use parallel axes theorem to calculate simple formulae depending on the payload given the fact that gripper is always the same. The accuracy of this method could even be better than 1% the nominal load.

    I would like to use the LOAD_DATA also to check if the part fell out of the gripper, but I would not want the robot to constantly tell me it is underloaded or overloaded, as overload could be used to check for collisions or for part length using some tricks.

    Controller: KRC4 - KSS v 8.3.17

    Robot arm: KR 90 R2700 pro

    • Best Answer
    Post

    RE: MANY DIFFERNT LOADING DATA FOR A SINGLE TOOL

    If your program uses Inline Forms (ILFs), then you must alter LOAD_DATA[ x ]. If your motions are "raw" KRL, you need to alter $LOAD.

    Inside every ILF motion command is a call to BAS.SRC which, among other things, sets $ACT_TOOL to the number of the tool selected in the ILF, and then sets $LOAD = LOAD_DATA[$ACT_TOOL]

    TOOL_DATA and LOAD_DATA are parallel arrays in $CONFIG.DAT. When an ILF motion is using Tool 11, the contents of TOOL_DATA[ 11 ] are assigned to $TOOL (the "live" TCP, XYZABC…
    SkyeFire
    September 17, 2021 at 3:47 PM

    Short version: you can rewrite $LOAD or any member of LOAD_DATA as you need, from inside your program.

    The more accurate the $LOAD value is, the better. But in the real world, +/- 5% is probably pretty typical -- even if you run KUKA.LoadDetermination, there's always a margin of error. And LoadDetermination loses accuracy fast once the payload is below 30% of the robot's rated payload.

    The amount of $LOAD error needs to be considered proportional to the robot's payload. An error of 20kg would be nearly irrelevant to a KR500 (4%), but very important to a KR60 (33%).

    The CoG and Inertia values are just as important as the mass, especially as the robot moves faster. A 20kg payload mounted far enough from the wrist can actually overload a KR60 due to the moment arm of that distance.

    I don't think you can use LOAD_DATA or $LOAD to detect a dropped part -- you'd be better off using direct sensors on the gripper.

    Quote from SkyeFire
    Post

    RE: MANY DIFFERNT LOADING DATA FOR A SINGLE TOOL

    If your program uses Inline Forms (ILFs), then you must alter LOAD_DATA[ x ]. If your motions are "raw" KRL, you need to alter $LOAD.

    Inside every ILF motion command is a call to BAS.SRC which, among other things, sets $ACT_TOOL to the number of the tool selected in the ILF, and then sets $LOAD = LOAD_DATA[$ACT_TOOL]

    TOOL_DATA and LOAD_DATA are parallel arrays in $CONFIG.DAT. When an ILF motion is using Tool 11, the contents of TOOL_DATA[ 11 ] are assigned to $TOOL (the "live" TCP, XYZABC…
    SkyeFire
    September 17, 2021 at 3:47 PM

    Short version: you can rewrite $LOAD or any member of LOAD_DATA as you need, from inside your program.

    The more accurate the $LOAD value is, the better. But in the real world, +/- 5% is probably pretty typical -- even if you run KUKA.LoadDetermination, there's always a margin of error. And LoadDetermination loses accuracy fast once the payload is below 30% of the robot's rated payload.

    The amount of $LOAD error needs to be considered proportional to the robot's payload. An error of 20kg would be nearly irrelevant to a KR500 (4%), but very important to a KR60 (33%).

    The CoG and Inertia values are just as important as the mass, especially as the robot moves faster. A 20kg payload mounted far enough from the wrist can actually overload a KR60 due to the moment arm of that distance.

    I don't think you can use LOAD_DATA or $LOAD to detect a dropped part -- you'd be better off using direct sensors on the gripp


    Continuing with this thread.

    Here is a public link to a presentation by a KUKA engineer. It is about absolute accuracy robots.

    Understanding Robot Absolute Accuracy Webinar
    Many robotic applications require high positional and path accuracy. These include machining, non-destructive testing, and any application that uses offline ...
    www.youtube.com

    I have a question at minute 55:44. According to your experience or knowledge, in robots that do not have absolute accuracy AA.
    Is it correct to assume that working with a tool that weighs less than 30% of the nominal load will bring significant accuracy problems?
    Or is this only considered for AA robots?

    I am not referring to the accuracy error when loading the weight values!

    Quote from panic mode

    when robot is using small payload, and it is not told what the mass of the payload is, results obtained by Load Data Determination are poor.

    Sure, I understand that, but I'm talking about using a robot without Load Data Determination. Just load the data from the tool by typing and assuming that it is fairly accurate.

    My question refers to the behavior of a robot without AA, if the weight of the tool is below 30% of the nominal load (the load to which the kinematics and dynamics the robot is calibrated from the factory. "the kuka gym ") accuracy is greatly lost. This is what I understand the engineer is implying in the video, but they are talking about robots with AA. (minute 55:44)

    What happens, would we expect the accuracy to lose too much (go from 0.7 to 1 or 2 mm for example)?

    You Panic Mode talked about a case similar to what I am trying to refer to. But in your case, you demonstrate the problem of not loading the data correctly and the consequence in the engines. But it does not specify whether using a large robot to move a small load decreases the factory robot's own accuracy.

    internal working of KSS is proprietary so only KUKA would know them in and out. cannot help there. i have seen cases where one or the other model is turned on/off to achieve different performance.

    i have not tested it myself but i doubt that robot repeatability will change when load is incorrect. the cycle time will suffer. robot wear and tear will increase. positioning accuracy and certainly path accuracy will change. arm may be deviating from position/path due own elasticity and used model (AA uses different model, it has corrections). there may also be oscillations on one or more axes.

    and btw. please do not use term engine to refer to motors. engines burn fuel, motors do not. engine operation is possible because of flames. when flames die, engine stops. if you see motors get hot or somehow exhibit flames, something is very wrong.

    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

    Quote from Alfredo Iglesias

    Continuing with this thread.

    Here is a public link to a presentation by a KUKA engineer. It is about absolute accuracy robots.

    https://www.youtube.com/watch?v=dNBQme…ts%26Automation

    I have a question at minute 55:44. According to your experience or knowledge, in robots that do not have absolute accuracy AA.
    Is it correct to assume that working with a tool that weighs less than 30% of the nominal load will bring significant accuracy problems?
    Or is this only considered for AA robots?

    I am not referring to the accuracy error when loading the weight values!

    I have a 240kg payload robot (not AA). With axis 2 tilted forward around 30deg from vertical, and axis 3 approximately horizontal (so robot reaching forward but not fully outstretched) adding 60kg (around 25% of the robots max payload) to the rollface will result in the rollface moving down approximately 1mm (a combination of sponge in the gearbox and flex in the arm). On a non-AA robot, I believe this will be the same regardless of what you set the load data to, as I don't think the controller compensates static positions based on the load. The load ID is important for dynamic movement though.

    And in relation to your original question, on a 90kg payload robot, with a 20kg gripper and upto 20kg part, you could probably program your pick positions/frame with the gripper holding a 10kg part (middle of the range giving a combined mass of 30kg) and not run into any major accuracy issues over the +- 10kg range. Having something to approximate the load parameters based on the estimated part weight would be nice if possible but if your movements aren't too fast and your gripper keeps the part close to the rollface basing it on a 30kg weight may be adequate.

    Quote from cnccreations

    I have a 240kg payload robot (not AA). With axis 2 tilted forward around 30deg from vertical, and axis 3 approximately horizontal (so robot reaching forward but not fully outstretched) adding 60kg (around 25% of the robots max payload) to the rollface will result in the rollface moving down approximately 1mm (a combination of sponge in the gearbox and flex in the arm). On a non-AA robot, I believe this will be the same regardless of what you set the load data to, as I don't think the controller compensates static positions based on the load. The load ID is important for dynamic movement though.

    And in relation to your original question, on a 90kg payload robot, with a 20kg gripper and upto 20kg part, you could probably program your pick positions/frame with the gripper holding a 10kg part (middle of the range giving a combined mass of 30kg) and not run into any major accuracy issues over the +- 10kg range. Having something to approximate the load parameters based on the estimated part weight would be nice if possible but if your movements aren't too fast and your gripper keeps the part close to the rollface basing it on a 30kg weight may be adequate.


    According to what I have learned in Dynamic and Kinematic Robotics (theoretical) and I think it is mentioned by the engineer in the video. The internal models do compensate for the "spring" deformations that occur in each link. That's why I think the engineer says at the end of the video that if you have a robot with a capacity of 120kg and no load or a load of less than 30% is placed on it. Some accuracy will be lost. That's why he then explains that Kuka should be sent to "recalibrate", because they have access to change the Internal Models of the robot.

    Also something interesting that he hints at, which is calibration with a laser tracker, he hints that if you calibrate the robot you can improve it a lot, but you will not be able to access the data from the Internal Model of the robot, in order to leave it even better calibrated.

    That is why I asked you my question, based on your experiences, that you have lost so much accuracy when using large robots with loads of less than 30%.

    Thank you for sharing your experiences!

    This is a problem with multiple layers. AA robots are factory calibrated across their entire motion envelope, with their near-maximum payloads, mostly to fine tune the differences between the robot's as-built condition and the ideal kinematic model that all robots typically assume they match. AA robots then attempt to extend that calibration to the actual working payload, relying on $LOAD to be highly accurate. "Load Mastering" also plays a part here. But like any sort of model, the further reality and the model diverge, the weaker the extrapolation becomes.

    For maximum accuracy, the better approach is to recalibrate the AA model "in the field", under actual working conditions. If the application only needs accuracy within a specific subset of the robot's entire working volume, then performing the calibration only in that sub-volume can improve the calibration a bit more.

    Correction tables can (in my experience) achieve another level of accuracy above what AA can, like the SARCA product from New River Kinematics. These generally require even more data collection than AA calibration does.

    Quote from Alfredo Iglesias

    According to what I have learned in Dynamic and Kinematic Robotics (theoretical) and I think it is mentioned by the engineer in the video. The internal models do compensate for the "spring" deformations that occur in each link. That's why I think the engineer says at the end of the video that if you have a robot with a capacity of 120kg and no load or a load of less than 30% is placed on it. Some accuracy will be lost. That's why he then explains that Kuka should be sent to "recalibrate", because they have access to change the Internal Models of the robot.

    Also something interesting that he hints at, which is calibration with a laser tracker, he hints that if you calibrate the robot you can improve it a lot, but you will not be able to access the data from the Internal Model of the robot, in order to leave it even better calibrated.

    That is why I asked you my question, based on your experiences, that you have lost so much accuracy when using large robots with loads of less than 30%.

    Thank you for sharing your experiences!

    Hi Alfredo Iglesias, I think most of what is discussed in the video is relating to "absolute accuracy" optioned robots, which have been factory measured under certain load conditions in a wide range of poses to determine the difference between the commanded position and the actual position of the robot rollface, and have internal compensation for these differences which can then be activated (effectively accounting for spring deflection in the arm sponge/backlash in the gearboxes etc.) and improving the accuracy when carrying a similar load. But the majority of KUKA robots sold do not have this AA option and so don't have this internal compensation.

    Load mastering (adjusting the zero position for each axis depending on the tool load) as SkyeFire mentioned can also be helpful and is something I should revisit since we've added some new tools. The SARCA product sounds interesting too!

Advertising from our partners