Kuka Acceleration setting and values

    Hi everyone,

    Working with a Kuka KR16 and I have been researching this for a while to try and understand how the velocity and acceleration settings work. I understand that in LIN and CIRC modes the velocity set is the tooltip linear velocity and when you set the percentage in PTP mode this limits the rotational velocity of each of the joints? (i think this is correct).

    What I am trying to understand now/find out is if the acceleration setting in each mode works the same as the velocity in PTP mode? when setting the acceleration as a percentage does this limit the maximum angular acceleration of each joint by that percentage from its rated maximum? Also are the rated maximum acceleration rates of each of the joints published somewhere in documentation as so far I have not been able to find it?

    The reason I am trying to understand these parameters is that I want to be able to predict the completion time of a pre-calculated Kuka path and need to now begin working on these values in order to improve the accuracy of this prediction. If anyone can think a better way to receive this prediction or calculate it this would also be much appreciated.

    Thanks,
    Callum

    Edited once, last by callumq (April 19, 2018 at 4:32 PM).

    This would be very difficult to calculate. When ptp movements are involved, you can't determine the path that the robot will actually take between the 2 points...

    Easiest way would be to program your desired path in a spline block; then you can specify a time in which the spline motion is completed (within the limits of the robots capability).

    Sorry to clarify at this point I am trying to just estimate a predefined linear motion using this method but was trying to understand how the acceleration value works.

    My plan at this point for estimating the time is:
    [list type=decimal]

    • Use an IK which seems to be giving accurate results to calculate individual postions along a linear path and the corresponding joint angles for each of these

    • Calculate the required joint angular velocities and accelerations in order to move between these points and check these against the set robot limits

    • If anything is running over a limit I am assuming at this point that the robot will still follow the path but just move slower than the set speed through this area?

    • Loop through every point and then have the final time for the full motion to be completed?

    [/list]

    Does this method seem feasible? Also I didnt know about being able to set the overall motion time when using a spline block thank you for the suggestion. When using this setting will the robot hold a constant velocity along the whole path aslong as you respect the other constant velocity constraints that is in the documentation?

    Thanks for you quick reply.

    Edited once, last by callumq (April 19, 2018 at 5:34 PM).

    The acceleration is extremely complex, because there are a number of different subsystems influencing it from behind the scenes. And many of these are not visible to us.

    First off, for any PTP motion, the slowest axis dictates the speed for all the others. The trajectory time for the slowest axis is calculated, and all other axes' accelerations and velocities are de-rated to match, in order to keep all the axes' starts and stops time-synchronized.

    Then, there's the program acceleration values, which the robot tries to achieve. However, if achieving these accelerations (based on the current position, gravity, inertia, and payload) conflict with the maximum of any axis, the entire robot slows down to stay within those limits.

    Then, there's the realtime dynamic factors -- position (gravity has different leverage over each axis as the robot changes pose), payload (mass, CG, and inertia), velocity&inertia (in all 6 degrees of freedom), and others I'm probably not aware of. All of these get taken into account, and (to a first approximation), whichever one returns the lowest acceleration and/or velocity sets the upper limit for the entire robot for that motion.

    So, this is one of the reasons that most "simulation" software does not accurately predict motion speeds and times, unless you pay additional money for an add-on (usually written by the individual brand robot manufacturer) that emulates the real-world robot's low-level kinematic calculations in the simulation environment.

Advertising from our partners