Servo Starts Oscillating Under Disturbance

Question

I'm using MG996R servos to control a 6-axis desktop robot arm. When no disturbance (like a gentle push to the robot), the servos are fine and can hold their places. But under a gentle disturbance, servos at the top will oscillate a little and come back to the set position, while servos at the bottom will keep oscillating.

The question here is what is causing the oscillation?

I understand inside a servo there is a PID for angular position control, and the oscillation, really is the response to the disturbance (and one can do s-plane analysis, etc.). The bottom servos have heavier loads, so my suspicion is there is not enough stall torque.

I didn't hear buzz, and without load, the servos would work fine (it could go to the set position, being able to hold its place when I use my finger to rotate the plate right on top of the motor shaft). So I don't think it's the PWM that causes the issue.

The PWM is set to 50%, so that should be near a neutral position.

PS: One follow-up observation is if I change this motor to a different one, the oscillation stops, and the new motor performs quite robustly. Therefore, my current suspicion is manufacturing defects, which make the internal PID loop work less reliably with the real hardware

Answer 1

I can add one more point to RowanP's excellent list: the servo's PID is unreliable, not because of a defect, but because it is mistuned for your application.

Recall that tuning a PID control is arcane, if not entirely a black art. The servo manufacturer tuned the control PID coefficients for some use case, perhaps moving RC aircraft control surfaces. That might need to exert considerable torque, but against a minimal moment of inertia.

Your setup, on the other hand, has a considerable moment of inertia. Imagine that the manufacturer's tuning expects a quick response when it gives a certain push, but your setup responds slower and has inertial overshoot. Without refreshing my undergrad s-plane analysis, I think that might explain what you observe. If you have the patience to conduct more experiments, you might try attaching loads with various moments of inertia and see how the behavior changes.

I agree with your surmise that a beefier servo might have a stiffer response. But it might also be slower, depending on how fast the motor actually grinds the gearbox around. Either way it might change the PID-vs-MoI enough to scare away your problem.

Some people have modified servos to supply an error or position signal to the controlling microcontroller. That would let software exert some more control, sort of servoing the servo. Further gutting could effectively disable the servo's internal control entirely, making it just a gearbox motor with a position encoder.

I have seen a sort of hybrid approach, where the $\mu C$ would gradually direct the servo to go from point A to point B. But won't help with your setup , where the oscillation happens when it's merely trying to maintain a position.

Answer 2

I had a few ideas about what might cause the jitter action you showed in the video. I suggest you'll need to be more specific in the information provided to enable more specific answers.

Idea 1 - Movement Boundaries Conflict
Is the joint trying to move past a physical boundary? When constructing your robot arm for the first time, the servos need to be in a known position. Often the neutral 1500$\mu$s pulsewidth mid-rotation point. Each joint can then be assembled to a suitable mid-point joint rotation, matching the range of movement available on the servo to the range of movement possible in that joint.

Idea 2 - Insufficient power to the servos
Are you powering the servo from an external supply capable of supplying sufficient current, and not via a microcontroller (MCU) pin? The MG996R datasheet notes a stall current of 2.5A (@6V) per servo. A power supply capable of supplying power for multiple servos in the robot arm is recommended. They won't all be stalled (maximum drain) at the same time, but you should allow leeway. Base load equals number of servos times 900mA plus extra to allow for stalls. Your video shows three servos so 3*0.9+2.5 = 5.2A, so say a 6A 6V supply.

Idea 3 - Incorrect PWM signal (out-of-range)
You mention a PWM of 50% (which is a 10,000$\mu$s pulsewidth at 50Hz - see this explanation). A neutral 1500$\mu$s will be more like 7.5% duty cycle.

The datasheets I located were unclear or conflicting regarding the designed range for pulsewidth. I suggest working out from the neutral point until you establish the maximum travel of your particular servo. Minimum is anticipated in the range 500 - 1000$\mu$s; maximum in the range 2000 - 2500$\mu$s

Idea 4 - Servo Quality
These servos are on the economy end of the hobbyist market and get mixed reviews. You may just have a dud servo.

Idea 5 - PWM signal quality
You didn't mention in your question how you are generating the controlling PWM signal. If you're using an MCU then your code, the libraries you selected, and the other things going on in your program can impact the quality of the generated PWM signal. An oscilloscope is useful for checking the generated PWM.