Primer On Servos Hits All The Basics

Servos are pretty basic fare for the seasoned hacker. But everyone has to start somewhere, and there’s sure to be someone who’ll benefit from this primer on servo internals. Who knows – maybe even the old hands will pick up something from a fresh perspective.

[GreatScott!] has been building a comprehensive library of basic electronics videos over the last few years that covers everything from using a multimeter to programming an Arduino. The last two installments delve into the electromechanical realm with a treatment of stepper motors along with the servo video below. He covers the essentials of the modern RC-type servo in a clear and engaging style that makes it easy for the newbie to understand how a PWM signal can translate into positional changes over a 180° sweep. He shows how to control a servo directly with an Arduino, with bonus points for including a simple 555-based controller circuit too. A quick look at the mods needed to convert any servo to continuous rotation wraps up the video.

If [GreatScott!]’s video whets your appetite for more, be sure to check out [Richard Baguley]’s deeper dive into servos. And when you’re ready to put your new-found knowledge into practice, maybe a nice project would be to convert a hobby servo into a linear actuator.

9 thoughts on “Primer On Servos Hits All The Basics

  1. Metal Gears? Snake, Snaaaaake!!!! Great Video!!
    Besides the control signal being technically a PWM I prefer to call is custom type of PWM, since its range is only 0-10%. My concern is about the resolution you can get by using 8 bit built in PWM from microcontrollers where 10% means roughly 26 steps (though for many applications this might be enough).

    1. A servo signal is not PWM because the information is not in the average value of the signal, but in the absolute duration of the pulse.

      It’s erroneously assumed that a servo signal is PWM because it’s assumed that the period of the signal is constant, but in reality the pulse frequency, and therefore the duty cycle can vary without affecting the servo position. That’s because the servo is comparing the signal pulse to an internal delay timer triggered by the incoming pulse, and seeing which one changes state first to determine which way to turn the motor.

      The servo doesn’t really care how often the pulses come – in fact making the pulses sparse will reduce the servo’s holding force and increasing the frequency will increase the holding force by increasing the actual duty cycle the motor sees. Increasing the frequency too much however runs the pulses into each other and the servo starts acting erratically.

      In robots, you can make use of that feature to reduce the power consumption when force is not needed, and to implement a soft-start so the whole thing doesn’t just jerk itself to pieces when the power goes on.

  2. Another trick:

    Disconnect the internal feedback pot and use an external pot at the end of a reduction gear train that is driven
    by the servo. Then the servo will run to position the *external* pot. This is useful where you need additional torque or would like to lower the output speed of the servo.

    I used this to position a rather large and heavy camera platform, which needed to move precisely but not quickly.

    1. A typical servo is a P-type controller, so it will always have a position error. The drive signal diminishes to zero at the correct position, so the resistance of the whole drivetrain will always stop the servo from reaching the set point. It always runs into a different position on the same command depending on which direction it is coming from, and how the drivetrain is loaded.

      If you want precision, you need to implement a PI or I type controller with the external pot and a microcontroller.

      The bonus point therein is, that since you know where you commanded the servo to go, and where it actually went, you how much you needed to change your command to make it go where you want because your PI loop automatically adjusts for that, so you know how much load is present in the drivetrain.

      Knowing how much load there is, you can change your internal model of the system and predict what your next command should be. For example, if you’re lifting the camera boom and a pigeon lands on it, the system detects the weight of the pigeon and adjusts the P and I parameters of your control loop to keep it from oscillating or getting too sloppy.

Leave a Reply to Dax Cancel reply
