iRMaster to fix robot drift

I would map the drift. if the drifting is in an arc to the robot center, then it indicates base bolts.

An M-20 is a rugged robot, i don't see crashes causing this. (smaller robots utilize harmonic drives which "skip" teeth easier)

end of arm tools, if not doweled, can cause issues like this, movement around the mounting bolts

The iRVision mastering is a great option, i would keep that one in my back pocket.

Good luck

I know nothing about iRVision…...but from what I'm reading this appears to be recommended to compensate for this...…..a complete waste of money if there are underlying issues mechanically.

I think this should be investigated a little further.....

If an industrial robot is 'so called drifting', majority of cases I have come across is down to mechanical or external influences.

Program code and stored data does not drift, therefore any positional data referenced will always be the same (unless changed manually).

Taking that into account, the zeroing, mastering, calibration data will not 'drift' either.

So using that as the 'constant'...….what are the variables that could attribute to 'drifting'.

- Loose bolts, or the mounting holes wearing on pedestal, robot base, tool flange, tool flange adapter.

- Bent or non visual forces being applied to the EOAT, causing a 'spring effect' on the EOAT assembly.

- Gearboxes rotate many times when cycling, and are not linear to the motor position, so sometimes there are periods when the 'drift' could fix itself and periods where it exists.

- External fixtures and peripherals the robot is servicing are moving not secured.

I would check for backlash by enabling the motors in T1 and not jogging the joints, as a colleague to apply force to each joint and see if there is movement.

I would also check in which directions it appears to drift and over what distance.

Usually mastering, zeroing issues if they are slightly out, will yield greater drift over longer distances, so I would monitor for this also.

I would consider getting one of the robots serviced too and see if anything appears during the inspection, usually the 'techs' on the ground have more 'real world' experience than a person on the other end of the phone, and the 'tech' may in fact highlight the problem.

I think it is important to eliminate as much as you can to ascertain where the problem lies before using additional 'tools' to compensate.....this way you can fix the underlying problem for good.

Just my 2 cents...….

I had the same problem in a Cell working with 2 robots. Robots never mastered and collisions were never too hard or many to cause a mechanical issue. I also use M710i 50kg payload which is a pretty stiff model with high rigidity. It turned out the mastering on both robots from FANUC was not the best. I used an accuracy enhancement technique by FANUC and problem solved. If you are interested to give it a try I can share the bulletin.

But before you try this could you share some more info?

1.How did you check the drifting ?

2.In which direction does the drift occur ?

3.did you try rotating the TCP using the tool frame ?

4.is the TCP taught or manually entered ?

5.are you sure it was taught precisely ?

6.Did you put the robot to 0 position and check the marks ?

7.Put your robot in home position and apply some force by hand on the wrist. Try moving the end effector by hand (like trying to rotate the robot) and up down, this way you can check your reducers for plays.

To my experience there are only 3 reasons for a TCP to drift: badly taught or inaccurate if directly entered TCP. Inaccurate mastering of the robot, reducer failure causing plays.

Quote from M3WIN

6.Did you put the robot to 0 position and check the marks ?

The marks are close, J3,J4 are about a line thickness off but very close.

7.Put your robot in home position and apply some force by hand on the wrist. Try moving the end effector by hand (like trying to rotate the robot) and up down, this way you can check your reducers for plays

Seems very firm and steady

Thanks!

Display More

Create a program and teach a point in space where your TCP touches a physical top. Be sure to check your J3 axis to be near zero degrees or at least 0-30 degrees and all turn count numbers in the positional data of the point to be zero.
Without moving the robot, create a second point on the same location and enter in the positional data. Change the configuration from NUT to NDB (or the opposite). Slowly move the robot to the new location. Be carefull not to speed up the robot, the robot will try to reach the same point in space using a different configuration. if the robot drifts away from the point taught when changing configuration then this suggests an inaccurate mastering.

A line thickness off is a lot !!!!! In my case I corrected 3 axis around + or - 0.2 to 0.5 degrees and it made a huge difference.

I have attached the Accuracy Enhancement mastering technique Engineering Bulletin. I hope it will help you solve the problem