When moving using the arrows in the TCP position section of the move screen (the straight arrows), the TCP rotates as much as 10 degrees from one end of the table to the other on one of my two UR10e’s.
It ONLY happens on one robot and it seems to be new behavior. I checked the TCP settings in Installation and both robots are almost identical.
In case I’m not stating this clearly, here’s how I tested both robots. Set TCP to a position with a piece of flat metal in the grippers. Place a ball bearing or dowel pin on the flat metal. It doesn’t roll off. Now when I start moving the robot with the TCP arrow along the X axis the TCP rotates as it’s moving along X and the ball bearing rolls off the plate. This DOES NOT HAPPEN ON THE OTHER ROBOT.
What could be causing this? I cannot use this robot now because it does not pick up parts after the first 4 or 5 parts.
Are you jogging with respect to the robot base, or tool, or some other custom TCP?
I’m jogging relative to the base.
You need to change the feature to Tool instead in the Move tab to have the robot move relative to the tool or end-effector.
That’s not it. That flips the entire robot upside down and it STILL rotates the TCP while doing a linear move.
I have never, ever, jogged relative to the Tool in almost 3 years with 2 robots. Only the Base.
Here is Robot 1. I put a bearing on a part and jogged the extents of the table relative to the Base. The bearing stays on.
Here is Robot 2. The bearing falls off before it gets to the other end of the table.
Does it do the same thing if you run a MoveL command vs using the arrows to jog? Seems like you’re experiencing some really strange behavior, and might be worth a call to your distributor, especially if you think this is new behavior. Maybe a joint is going bad?
Yes, it does the same whether I’m jogging or using a MoveL in a program.
I would say take the exact same program (URP and Installation file) and load them into your other robot. Maybe just a simple program that just runs a MoveL command. If your other robot now ALSO starts rotating, then it’s something in the TCP, or the waypoint, or something. If it DOESN’T rotate, then I’d say it’s definitely something with the robot. Whether that be a joint going bad, or a bad calibration, or whatever. The former would be something you can fix, while the latter will likely involve a call to a distributor/UR. Unfortunately.
Hmm… If you have been using using the Base moves on both robots for 2-3 years and haven’t seen this issue until now, I’d 1) check to make sure your gripper, table, or robot base are still securely mounted or haven’t shifted and 2) follow @eric.feldmann advice and see if you need to have some service done on the robot.
Are both the table surface and pedestal level and in the same plane? Where is your TCP, is it offset or [0,0,0,0,0,0]? Are you flipping between two different TCPs (image shows dual gripper)?
The flip you see in the graphics window is the interface aligning with the coordinate system, if you select “base”, “tool”, “plane_1”, etc. you will see the window change (I believe it aligns with X vector facing in-out of screen), this is NOT however true for “view” though.
In one of your images it looks as though you have the robot seated on a pedestal near the table, if both are not truly level AND on the same plane this could happen. I really only trust moving relative to the base if robot is mounted directly to surface of table and/or if the end-effector is designed to be used orthogonally from the tool mounting surface. You could check mounting to make sure when you align the robot to the table at several locations that they are all level, or you can try creating a plane in the installation and have the program moves be relative to that.
The reason I recommend moving in Tool is you can have better control of TCP and rotation about it. If you offset the TCP to where the bearing is on that plate you can potentially use the rotation arrows to balance the ball then use linear X,Y, and Z arrows to have robot hold this vector when moving the rest of the joints.
Seems like an interesting problem, but if it’s not a bad joint I’m pretty sure it’s something in the TCP.
@eric.feldmann I loaded the same program in the other robot and it does not show the same tilting behavior as the other robot.
The only difference between the two is the position of the table relative to the machine it tends.
Robot 1 has it’s table 90 degrees from the machine doors and Robot 2 is 0 degrees from the machine doors. Everything else is the same. Same Vention stand, same grippers etc.
@MikeM I checked as much as I could yesterday to make sure everything was still secure. Seems to be.
Table and pedestals are very close to parallel and in the same plane. As mentioned, I’ve not seen this behavior before and I am 99.9% sure I would have noticed it when I was setting pallet corners (I do that multiple times every month so I have quite a bit of experience/exposure to it.
I do use 2 grippers and have never had any misalignment issues when I swap between them to do the same thing.
I’ve never used motion relative to Tool so I am hesitant to start. I believe it will require me to re-teach all my waypoints (I have scores of them in dozens of programs, would be a monumental task)
Thanks for all the help and feedback. Next move is to call my distro and have him come take a look.
It looks like entire robot, and stand are flexing slightly.
Try to setup a plane with corners same distance from the table - check if robot keeps distance to the table constant when jogging relative to this plane.
It’s not flex.
The TCP is tilting as it moves along the X axis.
It starts flat and progressively tilts more as it moves further along the X.
That looks wrong. Check if there is no warning 213, or 214 in log, that would indicate invalid calibration.
Likely arm needs to be recalibrated at technical support facility.
I sent the log files to UR and got a response back; they said the shoulder and wrist 2 joints need to be zeroed and sent me instructions. Looks like it’s simple enough, will do it later in the week after I finish the current run. I am only using 1/4 of the table at this point because that tilting is causing it to fail picking up parts when it gets half a table away.