Hi pros,
We have a UR10 robot picking parts from a conveyor. Nothing fency, just a simple vacuum cup picking up a part that is not much heavy, maybe 1lbs-3lbs max.
We are adding an area sensor because when no-one is around we want to go faster with the UR. I know we can increase the speed and acceleration relatively high, like 3000mm/s for example. However I don't want to damage the robot prematurely by going to fast since the robot will fun all day. What typical speed and accelerations have you seen running for a while in your applications without running into any issue?
@Stefan_Stubgaard  maybe you can provide a few comments?

@Sebastien most of our robots run at 90% of max speed and accel or higher. This was my experience before Hirebotics as well. We have one currently running at that rate 6 days a week, 24 hours a day and a couple more generally putting in 20 hours a day 5 days a week and we've seen no mechanical issues. They are all carrying no more than 20% of rated payload at that rate. 

The thing we found with UR10's is that they need an extremely rigid base to run that fast as the robot carries a lot of momentum. 

@matthewd92
when you say 90% do you mean 90% of the 1000mm/s speed in the technical specs of the robot or the maximum value that can be entered in the robot which is much higher?

Maximum values that can be entered

@Sebastien

Agree with @matthewd92 that the mounting base needs to be very rigid, when running high speed operations. There's a lot of energy being released when running a robot of this size, so safety needs to be addressed as well if robot is planned to collaborate with humans. For that you have the adjustable safety that can be customized for the individual application.

The acceleration parameter is actually more critical than the speed parameter. If speed is set to high value but the acc is set low, the robot will never reach the speed before it needs to decelerate. But if acc is set to high value it can potentially cause protective stops.

There's a script code available you can use for debugging when installing the robot in order to identify where the robot operates close to it's limits:  position_deviation_warning() will output a number between 0 and 1, where 1 is close to causing a protective stop. (after debugging is done, delete the code as it will write to the log and float it)

Of course the TCP and CoG settings are important to have correct values as well.

@Stefan_Stubgaard that is good to know about that function.  When you look to update the URScript manual, you may want to consider adding a section on debugging applications and put all of the functions that are handy for debugging in there.  I have been through the manual I can't tell you how many times but never thought of this function that way.

Does this position_deviation_warning() need to be placed before a waypoint or does it go in a background thread?

The one that I have started to use for calculated waypoints is the is_within_safety_limits() so that I can verify that the position is reachable before I try to go to it and throw an error


@Sebastien one other thing that is worth mentioning again, especially if you are using a UR10 and making a large, fast move, is to use a midpoint between the start and finish that is blended.  This allows you to effectively have a different acceleration and deceleration for the move.  As long as both waypoints share the same velocity you are able to give them each their own unique acceleration value, which becomes an accel for the first waypoint and a decel for the second waypoint.  Use as large a blend as possible to make the motion as smooth as possible.  Often times I will find this midpoint in a joint scenario by simply moving the robot from the starting point to the end point and then stop somewhere in the middle and apply a new waypoint.  This would have helped us had we thought about it a couple years ago when we had a UR10 making a 180 degree base rotation with the arm about 3/4 of the way extended.  We had issues getting the robot to stop smoothly due to the momentum it was carrying, we ultimately had to sacrifice some speed in that application to get the robot to decelerate slower so we conversely accelerated slower as well.

@Stefan_Stubgaard it would be a nice addition to be able to specify the accel and decel separately, even if its only in the URScript call and not within the Polyscope interface

@matthewd92 thanks for the inputs, this is appreciated

Btw. when using position_deviation_warning() place it in the BeforeStartSequence and it will have effect during program run.

Thanks for the clarification on use @Stefan_Stubgaard that should be added to the API manual.

@Stefan_Stubgaard is there anyway to write the value of that call to a variable?  That way the program can do something based on this value, like cause the speed slider to slow to prevent a protective stop?  We have a robot that will run for 90 minutes without a single fault and then other times it won't run 10 minutes without faulting out doing the exact same operation.  It might be handy to be able to use that value to adjust the speed slider in the background based on the returned value....this robot needs to be able to run for over an hour unattended and right now thats not possible due to the random nature of the protective stops.

There is no way to use the function that way as it is today, but it's a very good proposal.

I will ask for the scritp manual to be updated with better information. Thanks!

@Stefan_Stubgaard
 quick question regarding maximum speed. It is written that maximum TCP speed for UR5 is 1m/sec in the specification sheet but I used a UR5 once that the speed set was above that value. What is the real maximum speed of the UR robot? This is a common question that we get from clients using the reduced mode when collaboration is needed but high speed when nobody is around.

Sounds like you are running really close to the limit. We have found that using the position deviation warning script with a threshold of 0.8 seems to keep us out of trouble. We keep fiddling with the motion until we can complete the actions without throwing any warnings. Trying to find these seemingly random events is very frustrating and can cause you to spend a lot of time trying to find a way to make the robot run reliably. 

If the payload and center of gravity is not changed when picking up and placing the part, this can also result in protective stops. You can use the scriptcode set_payload(m,GoG) after picking the part and set the payload to [4 kg + weight of gripper] and addjust the CoG in same scriptcode. When placing the part set the payload and CoG back to original setting. If you have high accelerations this might also result in protective stops, so you can try reduce the acceleration in the affected motions.

Hi @matthewd92

could you please explain a bit more about the threshold of 0.8 that seems to keep you out of trouble.
Any example?

Thanks in advance, 
Kind regards, 
Erik