Home› Integration
Discussion
Back to discussions page
Sebastien
Posts: 219 Handy
Increasing speed and acceleration on UR robot |
9.1K views
|
Answered | |
/ Most recent by Erik_Cornelsen
in Integration
|
16 comments |
in Integration
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?
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?
Tagged:
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.
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?
@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.
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.
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!
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.
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