We have run successfully a project where 2 UR10 CB-serie interact together each with a flexible tool with carbon rods. The flexible part introduces varying loads on the tools, but running in “Least Restricted” mode there was never protective stops as the varying load depending on the flex of the carbon rods was under the threshold to trigger it.
We recently acquired 2 UR10e, E-serie, and installed the exact same configuration in a new location, but we are having a lot of trouble with Protective Stops, which seem much more sensitive than on past CB-serie, even in Least Restricted mode. The issue is always on Wrist 3, and on both robots which are brand new so unlikely to be a fault in one robot.
I assume that the E-serie are more sensitive thanks to the proper torque sensors compared to past CB models, but as long as I run in Least Restricted even varying loads on the tool shouldn’t trigger Protective Stops?
I definitely don’t see more than 250N on the tool, and the error is always Wrist 3 path deviation. I have seen Protective Stops when the tools barely touched. I have tried various configurations of TCP and Payload, Center of Gravity, using the real CoG, or offsetting it to be closer to where the varying load is applied, same with TCP, etc. Always seeing very often Protective Stops when there was non on CB-serie.
Is there something I should double-check? Currently we have had to reduce drastically the amount of interaction between the tools to avoid this, but it just seems like in Least Restricted the tools should be able to take more force than that.
To me it does not sound like a problem with the forces involved, but more along the fact the the e-series is 5 times more precise then the old cb-series, which should also make it detect much smaller path deviations.
I would suggest playing around with the force_mode script function, as it “kinda” makes it possible to set you own path deviation limits for non-compliant axes.
I am controlling the robots over ROS via Joint Trajectory Controllers so cannot really mix that along force_mode, the robots are teleoperated to follow users’ inputs.
One thing I am wondering: path deviation is calculated from the TCP position, I currently have used a very offset TCP (-500 in Y), which means that when pushing/pulling with the tool I could imagine any smallest deviation would be seen on Wrist 3 as a large deviation since let’s say 1mm deviation at the TCP would be a very small error allowed at the flange.
One thing I am not fully certain as we’ve previously had this running on CB robots, is that the interface in Polyscope has slightly changed and there is a split screen for TCP and Payload. I have no access to the current CB-based setup, but it might be that we used a TCP at 0,0,0 and just checked the Center of Gravity option to be offset, which means the path deviation could be computed from the tool flange, so Wrist3 would have more margin of error before a Path Deviation would occur. Now on the recent Polyscope version the TCP and Payload options are split, and I have set a TCP at 500mm offset, which would mean any small error on Wrist3 would be interpreted as a large path deviation at the TCP due to the large offset.
I will see if I can make a test with TCP at 0,0,0 and Payload CoG with the proper offset, as the path deviation would be computed from the TCP and not Payload CoG, it might reduce the path deviation and could be why we see much more now since I think last time the TCP was left at 0,0,0 and only the Payload CoG was offset
So I had access to the CB robots and the TCP is actually set to -500Y offset, not only the Payload CoG, so indeed there is a very large difference in behavior between the CB and E-series regarding sensivity to Protective Stops, which I guess is good for most applications but here causing us quite some trouble.
I have just set the TCP position to (0,0,0) on both E-series with only the Payload offset, to see if it helps in reducing the Path Deviation errors, will report if it helps.
Hi, the path deviation is actually computed in joint space, so the TCP offset shouldn’t be the root cause. But you should be aware that if you do cartesian movements, e.g. orientation changes with a large TCP offset, it can lead to very high accelerations of the joints
It is important to set the payload mass, CoG, inertia correctly if you have a long and relatively heavy tool.
If you do motions where the robot does interact with the environment , you may need to use force control, or do some kind of adaptation in your own external control algorithm to avoid protective stops