This is related to UR products, not Robotiq, but as the two are used together often I think there might be good input offered on this forum.

When working with our UR demo robots I've noticed that they will occasionally start vibrating considerably when they should be motionless.  The vibration can be stopped by putting the robot into free drive mode momentarily--however, this seems more like a work-around than a true solution.

This behavior poses a problem for any robot applications with sensitive sensing or noise constraints.  So far, we haven't really come up with a good explanation for what provokes this vibration or what software/mechanical issue is behind it.  I'm interested to know if others have experienced this vibration behavior, whether it has caused any problems in applications, and what solutions they have tried.

@Jbahner I've also seen this and like you, freedrive or changing position usually fix this.

This vibrating behavior is really linked to the robot PID control.
P : Proportional --> error, distance between the actual position and the target position
D : Derivative --> change in error
I : Integral --> accumulative error

Most robot motors will be controlled by a PID control, and a certain points, depending on the robot configuration, you can have a loop where the robot tries to go to a position but keeps going over it, and then move back. This king of very small motion will create this vibration, where the robot is shaking between the target position and an "error" position.

You should Google that, there are probably a lot of explanation better then mine...

@Jake_Huckaby is it what is happening? Can you tell?

@Etienne_Samson thanks for the explanation--that's what we were thinking as well.  For the record, the best solution we have for this right now is using URscript commands to quickly enter and then exit freedrive mode (see below).

freedrive_mode()

sync() or wait for a short time

end_freedrive_mode()

This isn't a true solution to the control issues that seem to cause vibration, but if there are certain points during operation where vibration or noise are totally unacceptable this can provide a workaround that may be good enough depending on the application.

@jbahner thanks for the tip, I'll mention the issue to UR tech support, I have a call with them today. I'll see if they have anything to say and keep you updated.

@xamla_andreas we would be interested if you can share. We don't see it often but we have a UR3 that does it almost anytime we are sitting waiting for material. We even weigh all of our end effectors at relatively precise levels and it doesn't seem to help. Much worse in my experience on the 3 than the 5 or 10. Anyone else see this as well?

I've seen this issue across the board as well, especially on the UR3. @xamala_andreas I'd be interested in your solution as well.

You can manually change the PID constants for a joint in the UR's scripting engine.  Changing them has it's own challenges and UR won't reveal it's defaults so you do at your own risk, but here's how you go about it  (I wouldn't do this without guarding):

while (j<6):

                                send_joint_regulation_parameter(j,1,p_kp)

                                send_joint_regulation_parameter(j,2,p_ki)

                                send_joint_regulation_parameter(j,3,p_kd)

                                send_joint_regulation_parameter(j,4,s_kp)

                                send_joint_regulation_parameter(j,5,s_ki)

                                send_joint_regulation_parameter(j,6,s_kd)

                                 j=j+1

                end

Where p_kp, p_ki, p_kd, s_kp, s_ki, and s_kd are the gains you're chaiging 

Generally lower values will result in lower vibration but worse path tracking response.  

@anphilip Indeed that is the solution we found too. Can you share some parameter sets that you successfully used?
I think UR intentionally did not document that function because it is quite easy to shoot yourself into the foot - e.g. I think it is even possible to set negative values etc.

Some general notes to the code by @anphilip:

p_XX are the parameters of the position controller
s_XX are the parameters of the speed controller

In general it might be a bad idea to really set the parameters of all joints of the same values (as in the sample). A good starting point (without prior knowledge about the defaults) would be to set the D and I values to 0.

Just as a general recommendation: Make an image of the UR cf card/ usb drive before you play with the robot. Most of the topics you can roll back by swapping cards or thumb drives with the old image. Additionally between firmware updates. Our common practice is leaving a system copy with the old firmware with the customer after updates of firmware so it can easily be rolled back if there are any issues. The beauty is the joint firmware gets changed automatically as well with the firmware which could recover from mistakes. Downside you lose the log file updates if you don't save them separately.

I don't think I can share gains at this point (customer confidentiality).  I'd start via standard PID methods and walk joint by joint outboard to inboard.  

I had similar problem of UR5 vibrations in particular configuration. After I upgrade the s UR software from 3.2 to 3.3 this doesn't happen any more. :)
I think this is the most easy way to solve this problem. 

@mdauser this post can be useful for what you are trying to do!

Thanks for posting this topic and the link to the fix. We have been dealing with this for about a year now on our UR3 robot. We had reported the issue, which is clearly classic limit cycling instability of the joint controllers, to Universal Robots and our distributors numerous times. After getting ignored for months, UR gave us a response in August that "The vibrations you are seeing are on a level that UR seems to think is irrelevant for the applications they are mainly focusing on." Looks like a number of users beg to differ. I am glad they have finally put out a patch, but this issue has been illustrative of how their users get frustrated after being ignored. I have spoken with other users who have been similarly frustrated with their recalcitrance. I wish they would improve their customer service and communication. Imagine if they would have acknowledged the issue with a "we're working on it guys". 

Thank you for the feedback @Michael_Costa, Sorry to hear that you have had a bad experience with slow or missing response from UR and the distribution side.

We are always trying to improve both our products and our communication, and appreciate any feedback. I will make sure to bring this information into our organization. Thank you

After struggling with limit cycling vibrations for a year (there is a previous thread on this), we recently applied the 3.3.x.x software/firmware update to our UR3/CB3 controller. We immediately noticed the vibrations at rest go away. But we also noticed that freedrive mode now seems very "coggy". Each joint seems more reluctant to move, as if they are cogging on the motor poles. We also noticed that when doing servoj moves, that our robot is vibrating more and that overall motion is less smooth than it used to be.

Has anyone else encountered this, and where they able to do anything about it? 

We haven't seen that to date, have one UR3 running the software but its a couple versions ago, maybe 3.3.1, but I am about to upgrade a UR3 in our shop to the latest so will let you know what we see on the free drive issue.

Hi guys @Michael_Costa @matthewd92 , remember we already had a post on this, I'll try to merge this.

http://dof.robotiq.com/discussion/167/what-causes-shaking-vibration-of-ur-robot