Hi everyone,
We have a customer using a long aluminum end-effector with light payloads at either end, when the robot moves you can see the end-effector vibrating. When the robot reaches its ‘home’ position, (no movement) the robot will start oscillating and moving. As a team we are diagnosing this as an issue with the end-effector causing vibration, but why would this oscillating cause the robot to physically move when it’s in home state?
Hi,
did you check your TCP and payload settings? I also noticed such behavior having wrong settings. I would also check the screw connections of the joints and the end-effector tool. While staying in any Position in Normal Mode the robot always tries to stay in this Position so the oscillation is caused by unstable regulation. I would also check the joint currents in the protocol tab to see which joint causes the behavior.
@m.birkholz Has great recommendations! I’d also be careful when using long end-effectors to make sure your CoG is as accurate as possible, and you have a stable base for the robot. Sometimes just having the correct TCP location and payload are not enough. Another possibility could be rigidity in the end-effector itself. I’ve seen long end-effectors preform great in the past (18 inches/about .5m from flange in Z) made from carbon fiber. Might be worth investigating for future designs.
@m.birkholz @inu Thank you for your feedback. We did confirm CoG and payload are correct. The end-effector is made of aluminum and we are in the works of switching it out to a carbon fiber one.
The unstable regulation for the robot trying to maintain position makes sense, with the end-effector continuing to oscillate at home position the joints must be trying to stabilize its position.
I was hoping to provide a more detailed mechanical reasoning for why this would occur, this is a big customer of ours and it would be beneficial to explain it from a mechanical standpoint.
@roman.reiner Could you tell me what robot model this is and polyscope version this robot is running? And also curious on what your TCP settings are?
UR10e
Software rev: 5.4.3.76201
TCP settings:
Tooling is about a meter long, with both payloads being equal on either side of rod.
Let me know what else I can provide to assist you. I have flight reports and log files.
Curious if any script commands would assist in keeping robot at home position such as ‘servoj,’ ‘stopl’, or ‘stopj.’
The CoG seems off to me are those suppose to be (-100mm,200mm,540mm) ? With a length of 1m they seem to be on the low side that may be the issue, but I’m not sure of the full design of the end-effector.
A quick test can be to extend the arm horizontally and press the free drive, if you see some motion in the arm, the settings may need to be adjusted.
Yeah we tested everything with freedrive for CoG and payload, it felt good when free driving it. Because the end effector has equal weights on either side the CoG is towards center, it is on the x axis of the tool flange.
I am not an expert and completely unaware of UR control mechanism, but it could be related to PID settings on the motors. The aluminium end effector could be adding a lot of inertia (the I of PID) to the system in the flex direction making it unestable. I found more information here What causes shaking/vibration of UR robot? — DoF
@davidmorillacabello Good info, it could definitely be an issue. I’d also make sure that the home position being used takes into account the CoG of the entire setup, ie, I would try to keep the TCP point as close to the system CoG as possible to avoid any unnecessary noise from external forces in the system.
Thank you @davidmorillacabello that was super helpful. That’s kind of what I was curious about with the robot motors and how that vibration/shaking happens. It’s useful to understand how some users put the robot into free drive for a moment to cease the vibration, but not necessarily a full proof fix. Any additional script commands that could potential help with these types of shakes that you know about? @inu
@roman.reiner You may want to explore using a servoj command to get to your home position. It is used for online control of the robot joint position, calculating the error from the desired position relative to the actual position.
The interesting part would be to adjust your input parameter, the lookahead_time. This parameter plays a role in error calculations and ranges from .03 to .2 seconds. The higher the value the slower the reaction is, this may cause smoother moments. The gain can also be adjusted between 100-2000, it’ll have a similar effect as adjusting the proportional gain of a PID controller. Lowering this value may produce less oscillations and shakiness, the default is 300 I believe.
Hi,
did you finally find a solution?
I have the same issue with my UR3e. When the robot is stopped in home position it is oscillating. I have to stop it with my hand and then it stays still. It happens even when no program is running. It looks like the robot tries to reach the home position but can’t do it with certain accuracy and goes + - + - and so on.
I just checked payload and cog settings and they are correct. Curious is that when I took the gripper (RG2 OnRobot) from robot the oscillations stops after few passes (they are weaker every pass) but when I mount it again it is oscillating continously.
The issue we had was solved when we made the end effector more stable. I am surprised to hear that just the OnRobot gripper would be causing the oscillating.
In addition to the end effector changes, at every waypoint we were stopping at we added a command to free drive for a moment and end that free drive. This wasn’t effective until we changed the end effector, but maybe it will help you.
Are you on the latest software rev? New robot?
Our robot is from 2019 and we use 5.11 soft rev.
The gripper is mounted on original Onrobot quick changer so it cannot be more stable.
I think that 2axis joint has some looses 
When loads with long offsets from the tool flange are being implemented, it is a good idea to add the custom inertia matrix to the installation/payload page. This lets the robot know to expect a higher moment of inertia.
I have seen this calm down oscillating loads.