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?
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.
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?
Software rev: 18.104.22.168201
- Position: (0,0,0)
- Orientation: (0,0,0)
- Payload 5.68kg
- CoG: (-10mm, 20mm, 54mm) (CX, CY, CZ)
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 https://dof.robotiq.com/discussion/167/what-causes-shaking-vibration-of-ur-robot
@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.