Position cannot be repeated, deviation of several millimeters

Technical Questions
1

Hello everybody,

for my application I need my UR10e robot to repeatendly drive to an Position. However, even if that works for a couple of times, at some point the robot always starts missing the given Position by up to 3 mm (most times after the robot is turned off). It doesn’t help to restart the process and move to the Position again, the Waypoint always has to be adjustet. Then the whole Process repeats itself.

To reach the desired Position i am using multiple movej and movel commands. Is it normal that the robot is unable to reach a position repeatedly and misses it by a few millimeters?

2

Hi…
The fist thing you need to check are your blend radius’s…
While they ensure smooth transition between way point they do so by allowing the robot to deviate from the way-points to a certain degree.
so reduce the blend radius as much as possible in the poses where you need the robot to be precise.

If that do not help you might need to get your robot re-calibrated.

Best Regards Casper

3

Thank you for your response!

As the robot is supposed to stop at that specific position the blend radius is already set to zero.

Is it possible to re-calibrate the robot by my own?

4

You unfortunately need a special calibration rig to calibrate a robot.
So properly not.

5

But before going this route, do make sure that your TCPs are Calibrated perfectly.
and that both the mounting of the tool and the robot itself isn’t loose in anyway.

Ive also seen bad calibrations of the Payload and COG effect the repeatability, before.

Best Regards Casper

1 Like
6

3 mm. That’s a lot. Is that in the middle of a run?

I have a couple of UR10e’s and both seem to have this issue from time to time. Not in the middle of a run or anything like that, just when I am changing setups. (I usually change setups at least a couple of times a week.)

I do CNC machine tending and it seems every 2 or 3 setups I do I have to re-calibrate either a vise position or a pallet corner or something. Haven’t figured out why. I have learned to accept it as part of the job.

Some things that I’ve found affect accuracy:

Robot mounting. Make it as rigid as you can afford.
Payload and COG settings.
Deceleration settings.
Positive approach.
If you are using Force and are in contact with a surface (sliding along it, etc), the slower you go the more false contacts you will have.

1 Like
7

i will double check the listed points. Thank you!

8

Hey,

Have you tried to upgrade to the latest Polyscope version?
SW 5.11.5 lists improvements as

  • Motor control improvements:
  • 25% improvement in overshoot and stabilization of motions
  • Reduction to joint wear increases average joint life over time.
  • No change to cycle times or motion profiles
  • This improvement applies to all e-Series robots

From what I hear, the issue could very well be solved by what I know 5.11.5 contains.

9

Thank, I did not notice that there is a new version. WIll install it first thing in the morning!

10

Hi @mad

We have a customer who i think is having a similar problem to that which you mention. Their robot is not going to the programmed positions, and is deviating by a couple of millimeters. I’m in the process of investigating what might be causing this, as they are only experiencing this problem after having upgraded to 5.11.5. So im wondering if upgrading polyscope to this version solved the problem for you? If the issue is still occuring for you, what have you tried so far?

Thanks,
Sam

11

Which direction is the position error in? If it is horizontal, it could be due to the robot sliding in it’s mounting, or the counterbase sliding.
You can check the aceived pose at the waypoint by adding a script line “x_act_wp1 = get_actual_tcp_pose()” at the waypoint where yous ee problems. and then see if that changes between runs.

12

Hi @osn,

The deviation is occuring in random directions, not necessarily parallel to the base of the robot. I’m going to site today, so I will add the script line to check if the robot itself is measuring a deviation.

13

I went to the customer site yesterday to investigate this issue further yesterday, and added similar functionality to that suggested above. I defined an installation variable, ref_pos, which saved the waypoint I was testing against (I jogged the robot to the waypoint, and saved ran a program which saved get_actual_tcp_pose() to ref_pos. Then every time the program reached the waypoint in the program, I store the value returned by pose_dist(get_actual_tcp_pose(), ref_pos). The values i was seeing varied and bettwen 0.3mm to upwards of 0.5mm. I added a catch for anytime the variance was larger than 0.5mm as this was what seemed to be causing problems. In order to get the calculations as accurate as possible, I added a 0.2s wait before the calculations took place, and the issue still persisted.

I then upped the wait to 0.25s and reduced the velocity with which the robot approached the position and that brought the accuracy down to 0.2-0.4mm, does anyone know if this sort of offset is to be expected?

14

If you move with high accelerations to a waypoint, there may be some vibrations during the robot’s settling. Does the problem disappear if you set the ti wait to 1s, or set very low accelerations?

15

Hi everyone, I have a very similar problem at a client.
I am running the polyscope 5.14.3

does anyone found a solution?

16

Hi Sam.

I am also experiencing the same problems at a single customer, can you by any chance remember any details that might help?

Best Regrads CG1

17

Having a similar issue on UR5e using pallet template on Polyscope 5.14… I believe the locations are good as I can move to them and am happy with the location. My difference is it consistently in the same wrong location so I can adjust for it after getting to the approach waypoint. I do have my speeds and accel up so I can lower them and see what happens. I also don’t believe the payload calculations because I know the part is ~0.5# and from empty to loaded I saw a change of +~0.2# using the wizard.