Robohub.org
Should we fence the arms of Universal Robots?
There is no doubt that the robot arms of Universal Robots are by far the easiest industrial robots to use, as I already explained on this blog. The UR5 and UR10 are also robust, relatively light and affordable, and beautifully designed. But are they really safe to use without a fence?
In the user manual of UR5, Universal Robots warn to “not enter the safety range of the robot or touch the robot when the system is in operation.” Yet in their marketing material, they claim that their “robots can … operate without safety shielding for most applications and this is true for 80 per cent of current installations.” They specify that “this is because … in a collision, the robot delivers less force than the 150 Newton”. What is more, there are several videos where we see a UR5 bump into an operator, and the robot does seem harmless indeed. So is UR5 harmless or not?
I myself have let our UR5 bump into me several times… at low speeds, of course. But we take safety very seriously in our lab, so I had one of my engineering students perform a thorough risk assessment with the help of an optical tracker, a force plate and a force gauge. Unfortunately, his tests show clearly that even the smaller UR5 is powerful enough to seriously harm a person.
The current ISO norm that specifies the safety requirements for industrial robots is 10218-1:2011. In addition, an ISO technical specification (TS 15066) for the safety requirements of collaborative robots is currently under development. In this article, however, I will not analyze whether the UR5 meets ISO 10218-1:2011, but rather use common sense to evaluate whether the UR5 needs a fence.
The UR5 is indeed very fast
We measured the TCP speed of our UR5 using Creaform’s C-Track optical tracker. We used a relatively small 5 kg square plate as an end-effector. The maximal TCP speed in joint mode measured was nearly 3,000 mm/s. We forgot to measure the TCP linear speed in Cartesian mode, but it seems to be limited to 1,500 mm/s. But even this speed is far greater than the 250 mm/s speed limit of industrial robots when operated in (reduced-speed) manual mode. Yet the arms of Universal Robots do not have manual mode.
I must admit that the TCP Cartesian velocities during jogging or homing/initializing are much lower. However, this could be treacherous. Imagine that you have a program where the UR5 performs very rapid motions, with high accelerations. You want to start your program, but you must first “Move Robot into Position,” and because this homing is very slow, you impatiently move the speed slider to 100%. Then you forget to move back the slider, and run the program. I guarantee that you will jump back in fright.
I would recommend that the 100% limit always correspond to maximum (Cartesian or joint) robot velocities. However, in jogging, initialization or other similar modes, the slider should be automatically reduced to and remain limited at a smaller percentage (e.g., 25%).
The UR5 acts like a spring
The UR5 is not equipped with torque sensors like KUKA’s LBR (which is several times more expensive), nor with a six-axis force/torque sensor, so its controller cannot detect impact forces per se. Instead, it seems to only measure the distance between the actual end-effector pose and the desired one. The following tests illustrate this clearly.
We positioned the end-effector of the UR5 next to a six-axis force plate by AMTI and programmed the robot to (attempt to) cross that plate at various speeds. The target end-effector pose (obviously unattainable because of the obstacle) was set relatively far on the other side of the plate. At low speeds, it took as much as two seconds before the controller executed a protective stop (“Joint security stop”). At maximum speed (as shown in our video), the protective stop occurred very quickly. In all cases, the maximum reaction force observed was slightly more than 200 N, which is greater than 150 N, but is still acceptable.
Next, however, we programmed the UR5 to attempt to penetrate the force plate but only 50 mm, then return to its initial pose, then repeat the motion and so on. At low speeds, nothing happened (not even a protective stop). At higher speeds, however, the robot repeatedly bounced back and hit the plate. The maximum impact force registered during this test was nearly 1,500 N. What is worse, however, is that no impact was detected and the robot continued to hit the plate until we pressed the emergency stop.
Finally, we demonstrated that a disturbance load of up to 100 N applied to the end-effector of the UR5 makes the robot deviate from its path. A greater disturbance force makes the robot stop (with either protective stop or security stop).
I would obviously recommend that the collision detection algorithm be improved, so that a collision is not detected simply by measuring distances.
The UR5 is powerful
Universal Robots don’t hide it. They clearly warn that “the robot force limitation does not give protection against momentum.” Nevertheless, it is interesting to have some data on impacts. Clearly, we didn’t risk hitting the force plate at maximum speed, so we only ran impact tests at 500 mm/s, with 1 to 5 kg payloads. The maximum impact force detected was an astounding 1,500 N. Of course, the impact was metal to metal, and the obstacle was fixed. This does not mean that the robot will exert 1,500 N if the force plate were a standing human.
Nevertheless, I think that it would be useful that a key switch be installed on either the controller or the pendant, which allows selection between manual mode, possibly called “collaborative mode,” and automatic mode. After all, in collaborative mode, you don’t need the robot to move fast, so why not minimize the risk of injuries.
The teach mode is error prone
Finally, we installed a 5 kg end-effector on our UR5 and intentionally “forgot” to specify this payload. Naturally, when we pressed the “Teach” button on the back of the pendant, the robot fell down instantly with high velocity. It could have been the other way around (the robot going up, if a higher than the actual payload was specified).
I would recommend that the robot detect the payload before the “Teach” button is pressed and if that payload is different from the one configured, then the button should be disabled. Alternatively, a message like this should appear when the “Teach” button is pressed “Attention! The payload specified is 3.5 kg. Are you sure you want to continue?”.
There is no collision detection during initialization
Obviously, this is not a big issue, but there seem to be no collision detection during initialization. However, since initialization is needed after every safety stop (e.g., after a collision), it might be useful to have collision detection at all times.
Conclusions
The UR5 is an impressive piece of technology, given its relatively low price. We believe in its potential and recently bought another UR5, as well as an UR10. However, it should be emphasized that the UR5 is potentially harmful, and certainly the UR10 even more so. There surely exist situations where safety guarding must be installed around these arms. That said, I am inclined to agree that in many other situations, the use of fences might be an overkill, especially if Universal Robots implement some of our recommendations.
AUAI is supported by:
