I’m looking for guidance on how to determine recommended safety settings like:
- SPEED, POWER, FORCE and MOMENTUM safety limitations.
To estimate the SPEED and MOMENTUM I can examine the process requirements and estimate the maximum / minimum needed speed and payload.
Regarding FORCE and POWER safety limits what should I do / consider ?
The force and power limits are in general most relevant towards “clamping” situations.
Essentially, you are looking at the maximal pressure the end-effector or robot is able to excert on a human.
Hence, the force by area, so it also depends a lot on the design and shape of the end-effector.
The speed and momentum limits applicates most towards a “free-space collision” situation.
Here looking at what kinetic energy, a human body should have to absorb in such a case.
In general, it all comes down to your risk assessment, and compliance with national laws.
There is a page or two in ISO 10218-2 regarding this, but also there are some optional guidelines and good thoughts available in ISO / TS 15066 regarding setup of these limits.
Thank you for your prompt reply.
Any practical example (real numbers) for references ?
We would like to understand how to avoid frequent “protective stop”.
Frequent protective stops are typically due to incorrect settings in payload, Center of Gravity or potentially Mounting.
Please ensure these settings are correct.
Also, they may arise to due inconvenient motions, e.g. through singularity, or too high acceleration settings.
For acceleration, my recommendation would be to stay within 2500 mm/s2 respectively 300 deg/s2.
Thanks for your updates.
We’ll recheck our programs.
@jbm Could you clarify me how the power safety limitation affects to the robot’s behavior in a collision?
Let’s assume that the power safety limitation is set to 300 W and the force safety limitation is set to 100 N. How UR’s behavior in the collision would change if power safety limit is decreased from 300 W to 80 W?
It’s all about force levels in ISO/TS 15066, so is the power safety limitation irrelevant?
The Power limit constraints the maximum level of mechanical work the robot is allowed to exert on its environment.
Since mechanical power is
P = F*s/t [N*m/s][W] this limits takes into account also the distance and time, used to exert this power to the environment.
If the limit is exceeded. the robot will perform a Stop Category 0 stop.
Force only takes the force itself into account.
It compares a bit to the Speed and Momentum limits
Speed only limits the TCP speed itself. Where the momentum limit is the product of both speed and mass. Hence also taking the moving mass into account, and not just the speed itself. I.e. when payload/moving mass increases, the speed must decrease - keeping the momentum the same.
ISO/TS 15066 is a guideline, and gives some good estimations of reasonable force and more interestingly pressure limits. But bear in mind that as this is a TS, it is immature by ISO definition. If, in your application, you realize that the Power limit makes more sense, to reduce the risks discovered in your risk assessment, then you can also implement this limit at a reasonable level.
Thank you for the quick reply.
According to this website UR’s force reading is derived by monitoring the current of the motors and the position of the encoders. Since P=U*I I suppose that force and power readings are both based on motor currents.
As you wrote mechanical power is P=F*s/t and force F=P*t/s.
If UR’s collision force algorithm is based on formula F=U * I * t / s, in my opinion this means that also force limit takes into account the distance and time.
Your previous message would make perfectly sense if there would be a force/torque sensor in the robot. Now I’m a bit confused.
We do not correlate voltage and currents towards the “power” limit, as this refers to the mechanical power.
This is derived from the force.
The force is derived from the torque calculated at each joint. And the torque is derived from the joint data, including motor currents and encoder readings - combined with the calibrated joint parameters.
This was really helpful. Thank you Jacob!