If you're just joining us, make sure to read Part 1 and Part 2 (firmware, wiring, and connectivity) before continuing on.
Table of Contents
- Part 1: Project Introduction and BOM
- Part 2: Firmware, Wiring, and Connectivity
- Part 3: Servos
- Part 4: Power and Neopixel Lights
In this article, we'll take some time to go over the servos needed to let our bots express themselves. Even if you're not building the Wi-Fi Eye, you might benefit from following along for choosing a servo for your next project.
3D Printing Your Bot's Body
I've assembled some very thorough instructions on how to 3D print the bot bodies for this project. You can find them on DIY Hacking:
The bodies are what give the bot its geeky character, but the device functions just fine without them.
The servos we'll talk about here are what will allow your Eye to do cool stuff like this to alert you that a new signal has come into range:
Picking the Right Servo
There are thousands of servos to choose from and it would take another article just to explain all the options. Here's a quick checklist you should run through when trying to decide:
A broad variety of servos.
Most of these are fairly self-explanatory—but deadband and failsafes, in particular, are often neglected and they will be important for this project.
- Dimensions and voltage
- Speed and torque
- Range of motion
- Analog vs digital
- PWM rate
- Cored vs coreless vs BLDC
- Precision and repeatability
Keeping Wearables Small: Eye of Agomotto Variant
The Agamotto variant uses two HK5330S servos from Hobbyking, which are the smallest commodity digital servos I could find that will run from a single-cell battery. That means no voltage converters are needed between it and the Lithium-ion cell, which saves power, heat, size, and cost.
Bonus: it's tiny!
The HK5330S digital "nano servo" compared to a 10-year old standard-sized analog model.
They’re quite strong and precise for their tiny size and come with the usual assortment of servo horns. For our application, their only problem is the digital failsafe which leaves it locked to the last sent position, so we can’t “power down” the servo. This would be nice on an RC plane, but here it means we have to be careful to only tell the servo to move to a position it can actually physically get to since it will never give up trying to get there while still powered.
Two servos are used to create the Agamotto animatronic eye with independent upper and lower lids driven from the side to keep the design as “flat” as possible. We just don’t have space for the usual linkage bar arrangement you see in animated heads.
Stationary and Lower-Maintenance: Destiny Ghost Variant
This uses a single 5V standard-sized “9-gram” servo, which many people have kicking around in the parts box. I deliberately used the cheapest, nastiest, oldest 9g servo I had, and it worked fine. A bit grindy, perhaps, (as these servos tend to be) but enough torque to spin the back half amusingly. The lifetime probably won’t be great, but I didn’t feel like consuming one of the $30 digital servos I use in my tricopters. Digital servos are scary strong and complete overkill here.
Various 9-gram micro servos: a cheap MG90 analog servo beside an expensive modern high-torque digital servo (note the metal heatsink "case").
Because these larger servos require 5 to 6 volts, the Ghost build doesn’t use an internal battery. One lithium-ion cell would be too low (3-4V), and two cells would be too high, (7-8V) so a DC converter would be needed to be just right, and with that more problems would surely come.
Besides, there’s not much point in making the Ghost “wearable” like the Eye of Agomotto—it’s designed to be more like an art installation, hung from the ceiling from wires and powered externally by a 5V USB port/adapter.
It’s nice if you can get matching connectors for your servo. Otherwise, you'll need to cut off the plug and strip the wires for direct soldering. Route the ground (black) and positive (center red/brown) connections to your power system (usually the pads on the “input” side of the voltage regulator). Remember that servos can soak up quite a bit of current, so be direct.
That will leave the third (usually yellow) PWM signal wire. That gets routed to one of the pins of the ESP-12 controller. Pins 11-14 are all available. Pin 14 is preferred but you can configure it later, so pick whatever creates the neatest wiring.
Testing lights and servos.
The servo PWM protocol is more forgiving than the WS2812b serial protocol, and there should be no problem driving 5V (or higher-voltage) servos from a 3V microcontroller signal. I’ve hardly tested the entire spectrum, but that kind of cross-mixing is common with RC gear, and every servo I’ve tried so far has worked.
It’s a good idea to get the servo electrically connected and powered up so that you can test it and roughly “zero” the servo to its logical starting position before physically installing it. So long as the range of movement you need is within the range of the servo, we can tweak the rest in software later.
Configuring Your Servos
From the admin interface, the “system: configuration” button opens a dialog that configures most aspects of the system, including the servos.
Under the “FX” section, you can set what mode the servo system enters on power-up. Once your device is complete and tested, you’ll probably put this into “auto” mode. But in the early stages, it’s best to stay “off” or “manual” and turn the servos on after each reboot through the interface.
If the full power system isn’t installed (e.g., if it's running from USB), you may not have enough current for the servos at startup and your device might go into a crash-loop, requiring you to physically disconnect the servos (or use a different power supply) in order to get back into the config and stop them. Because of this, only switch this to “auto” once you’re ready.
The current firmware supports two servo outputs by default. You can assign the GPIO pin for each servo in the config from a limited set of options. Pins 14 and 13 are used by default.
Degrees to Microseconds
The rest of the servo setup is all about turning an angle in degrees (as directed by the animatronics scripts) into a PWM pulse length duration in microseconds. Ideally, we want to be able to correct for variation among servos, so we don’t have to rewrite all our scripts if we swap out a broken motor.
For each servo, we have minimum and maximum pulse lengths. According to the “standard”, those should be 1000 and 2000 microseconds, respectively, and that’s a good start. However, here are some things to consider:
- The PWM signal goes from 0-100%, but servos have a range of motion anywhere from 30 to 270 degrees.
- The direction of “positive angle” depends on which way the servo faces (front or back).
- Your preferred "zero point" isn’t necessarily at one of the ends. It could be in the middle.
- Your servo might be physically constrained, so you don’t want it to use its full range and move past safe limits.
- The ESP8266 isn’t entirely accurate, though it is repeatable. The internal clock doesn’t provide a perfect frequency division for the job, so “1500” will actually give you something a little different.
- Every servo is different. Even identical servos are different. Even the same servo is different at different loads and temperatures.
The configuration, therefore, has an explicit zero point, which is allowed to be outside the limits (meaning the servo will never be allowed to go to "zero degrees", but still uses that logical position as a reference). The spline teeth can sometimes make it impossible to get the servo zeroed perfectly if the horn is already attached, so being able to tweak this position via software is very useful.
Each servo has a scale which converts degrees into microseconds. If this is negative, then the servo will flip directions. Changing the scale allows narrow-range and wide-range servos to all calibrate to the same units.
In practice, the commanded angle (from -90 to 90 degrees) is multiplied by the scale, added to the zero point, and then limited by the minimum and maximum. You should “map” each servo into this logical range in a way that makes sense for your application. For example, the Eye of Agomotto has one servo “reversed” (negative scale) so that the movement of both eyelids matches the slider directions in the UI.
To find the perfect values, change the configuration settings for the servo in the dialog, save, and close. Subsequent servo commands (either manual from moving the control sliders, or an automatic reaction) will use the new limits.
In the final article of the Wi-Fi Eye series, we'll go over our power systems and lighting.