When we need actuators for a project, a servo from the remote-control hobby world is a popular solution. Though as the number of servos go up, keeping their wires neat and managing their control signals become a challenge. Once we start running more servos than we have fingers and toes, it’s worth considering the serial bus variety. Today we’ll go over what they are and examine three products on the market.
Our Friend the RC Servo
Remote control hobby servos are remarkable little devices. Each one is a self-contained closed-loop actuator, available across a wide spectrum of price and torque. Their popularity means we have a large selection of hardware available to drive them and software libraries to control them. For quick and simple hacks, they can’t be beat. But the straightforward simplicity of hobby servos become limitations when a project grows in sophistication.
- Communication: RC servo signals only go outbound. There’s no way to get information back. Is it holding the designated position or has it been pushed off target? Is it running OK or is it overheating? Has the servo connector been jarred loose, disconnecting it? Our controller has no way to tell.
- Software Scaling: Each servo requires its own precisely timed control pulse. As the number of servos in a project go up, it demands more powerful controllers, or separate dedicated peripherals, to maintain accurate pulses across all servos.
- Hardware Scaling: Each servo requires its own wire to carry that precisely timed pulse. As the number of servos grow, taming the corresponding growth of wires poses its own challenge.
Enter Serial Bus Servos
Projects that start bumping into these issues may benefit from serial bus servos. They are mechanically similar to the RC hobby servos we all know and love: a gearmotor coupled to a position sensor for closed-loop feedback. Where they differ is the control scheme, communicating with our controller using TTL serial.
All servos are electrically wired in parallel (with each other and the controller) turning a serial line into a serial bus. While serial communication is usually between two endpoints, the servo control protocols are designed so it is unambiguous which device is talking. Everyone playing nicely together on a shared serial bus avoids data collisions and lets them solve the problems outlined above.
- Communication: Bidirectional serial communication allows querying servo status. The controller can now find out if a servo is at position or overheating, and know if a servo is no longer responding.
- Software Scaling: Once a command has been received, a serial bus servo requires no further maintenance. Freed from the need to generate regular pulses, our controller can work on other tasks.
- Hardware Scaling: Since individual servos do not each require a dedicated wire to the controller, they can share power and signal lines with nearby servos. This freedom opens up wiring possibilities and is especially helpful for robots with multi-jointed limbs. (Like hexapods and small humanoid robots.) Only one set of wires is required per limb, with each servo on that limb daisy-chained to the next.
A Tale of Three Servos
With the general concepts established, let’s take a look at three products on the market spectrum. They were evaluated for a personal project because they all shared the following features:
- Documented Command Protocol: Servo manufacturers offer software tools to control their servos, but anyone who wish to write their own custom software can easily do so. All three companies here have released documentation for their set of servo commands.
- Variable Speed: RC servos will always move to its position as quickly as it can, which isn’t always what we want. These servos can be commanded to move to a position at a specified speed and/or over a specified time period.
- Continuous Rotation: A common RC servo hack changes them from a position actuator to a variable speed gearmotor by cutting away any physical end stops and modifying the position sensor. In contrast, these servos can be switched to continuous rotation (or switched back) by sending a command. No hack needed.
- Over 250 Servos: In theory, at least. The control protocol requires that a unique address be assigned to each servo on the bus. This identifying address is an 8-bit number which, minus a few reserved values, still leaves over 250 valid IDs. We’d run into electrical signal integrity issues (distributing a single serial line across many devices) well before we run out of address space.
- Broadcast Address: Speaking of reserved addresses, one of them is the broadcast ID. No servo can be assigned to it, but they all listen to commands sent to it. This is useful in two scenarios:
- Query ID: When there is only a single servo on the bus, we can broadcast the “What is your ID?” query and that servo will respond with its actual ID. This is useful when we have a servo in hand but lost track of the ID previously assigned to it.
- Coordinated Action: We could only send commands to one servo at a time, but sometimes it’s important for multiple servos to move together. To coordinate action, servo commands can be deferred: “Servo 1, go to X on my signal.” “Servo 2, go to Y on my signal.” “Servo 3 ….”. Once individual servos have their orders, broadcasting a “Now, Go!” command triggers waiting servos to all act at once.
- Variable Voltage: These servos can draw motor power directly from a lithium chemistry battery pack (3-cell for Dynamixel AX-12A, 2-cell for the other two) without external voltage regulators.
These are all very useful features for them to share, but these three servos also differ in ways that may be important for a specific project’s requirements.
Robotis Dynamixel AX-12A
The Dynamixel line from Robotis is the most established product in this market. It can be found in many projects on Hackaday.io and elsewhere, by hobbyists and research labs alike. Dynamixel has robust documentation and software support, from low-level serial command reference to high level third-party libraries like pypot. AX-12A is the entry-level product to a large product line, so there are plenty of upgrade options if a project should outgrow its servo. AX-12A communicates via half-duplex serial where the transmit and receive lines are combined into a single wire. We need to either build our own circuit to set up a Dynamixel serial bus, or buy an adapter like the U2D2.
DST Robot HerkuleX DRS-0101
The HerkuleX line from DST Robot offers more features for roughly the same price as an equivalent Dynamixel. In addition to specifying speed, it is unique with the ability to specify acceleration/deceleration allowing much smoother robot movements. The DRS-0101 is also the entry-level item in a product line, though this line doesn’t go as high as Dynamixel in either capability or price. As for connectivity, HerkuleX is the easiest to use. HerkuleX serial transmit and receive lines can be directly connected to the controller. No half-duplex translation circuit required like the other two.
LewanSoul Lobot LX-16A
The most compelling feature of the LX-16A is its low cost, roughly one-third that of a Dynamixel AX-12A, drastically lowering the price of admission. Obviously this price point required making some trade-offs. On the software side, its command set has fewer features than the others. For example: coordinated action could only be specified for position mode but not for continuous rotation mode. An example on the hardware side is the mounting system. Instead of fine pitched machine screw threads like the others, LX-16A mounting screws self-tap coarse thread into plastic. But the basics of a useful servo are present with metal gears delivering competitive torque and speed. Upgrade options are limited in the small LewanSoul serial bus servo product line, where the LX-16A has but a single sibling. Connecting to a LX-16A requires LewanSoul’s own “BusLinker” board (sometimes “Debug Board”) to translate TTL serial signals to half-duplex serial communication.
Serial Servos for the Serial Hacker
These quick overviews should help when judging which serial bus servos make good project candidates. Obviously there’s a lot more information in their respective specifications we didn’t repeat here. Fully documented servo commands mean these servos can be used by any platform, not just those supported by manufacturer’s software. From an 8-bit PIC to a Raspberry Pi to a full blown PC, any platform can control a highly complex robot using serial bus servos.
More servos, more degrees of movement, more fun! What will you build?
24 thoughts on “Wrangling RC Servos Becoming A Hassle? Try Serial Bus Servos!”
Considering that smarts are getting ever smaller, one can move that towards the motor end.
You could definitely build your own smart serial servos with whatever mc, actuator and feedback sensors you demand.
Or hook up clusters of dumb servos to little sub-processors, kind of like how your spinal cord handles a lot of your lower motor functions.
Glad to see they’re becoming commercially available now. If you want to roll your own, check out https://hackaday.com/2016/04/22/intelliservo as discussed over two years ago. I’m surprised it wasn’t linked in the original article.
I knew I’d seen that somewhere. Thanks for finding the link.
It’s a shame Hobbyking have stopped selling these guys: https://hobbyking.com/en_us/turnigy-tgy-s518-300-digital-metal-gear-intelligent-robot-servo-17-3kg-0-21sec-75g.html?___store=en_us
Use the Dynamixel protocol, half the price of the Ax-12 with equivalent if not better performance in my experience.
They have these now (maybe). https://hobbyking.com/en_us/turnigy-tgy-s403p-180-digital-robot-servo-15-3kg-0-19sec-67g.html
They look worth a try.
Do you have a datasheet for them? I am not sure if they are a serial servomotor and support chaining.
I didn’t know about the HerkuleX line, the acceleration/deceleration settings sound boss as hell.
I didnt see any mention of it, but wouldn’t the practical limitation of these on a bus be the power leads?
I can imagine that each of these takes a few hundred milliamps, so a chain of 4, 5, 6 of these would be over an amp if moving at the same time? A higher voltage might alleviate some of these concerns, but I would think this would at least warrant a mention.
On the other hand, a nice serial bus would mean it should be very easy to make an interposer to run several strings off a nice large fused power supply.
Hmm. Might be time to look at servos again.
I mean it doesn’t take a big gauge to handle a few intermittent amps. Should you have a ludicrously long chain, you could always modify the harness to run thicker wire, or you could even make it run vcc and ground parallel while keeping the data serial.
The Atom/Astro Boy robot kit I am building (one of those magazine subscription deals) uses serial servos. Does make for much neater wiring.
Great title art as always, Joe. :-)
FYI – Dynamixel run the motors way out of spec.
We go through servos quite frequently.
I was just looking at some BLDC ESCs and seeing the same problems with communication and wiring bloat. And yes, a similar solution has emerged! There are CAN ESCs now, solving the same problem but using twisted-pair CAN instead of single-ended UART, which seems a lot saner in a noisy electrical environment.
There are more choices in the serial comms ESC realm, mostly because of quadcopters which benefit greatly from speeding the communication up.
CAN sounds a great way to go, albeit relatively expensive. What servos are out there today that support CAN at a reasonable price? Other protocols such as LIN or, for long distances, plain RS485, may be cheaper and good enough. Also wireless protocols such as Bluetooth or Wifi are very cheap these days. Although it may seem crazy overcomplicated, UDP over wifi using ESP8266 modules would be cheap and easy.
WiFi? Use a wire where a wire is possible. You need power to the servo anyway. Neither you want to unnecessarily clutter the electromagnetic spectrum nor you want the unpredictable latency and reliability of wireless transmission for this kind of control.
CAN has the advantage of not only specifying a physical layer but also includes arbitration and protocol. Although the latter possibly is “only” part of higher layers like CANopen. That’s a great advantage. With CPUs as cheap as an STM32F103 offering CAN, it should be not too expensive or difficult. At least it’s cheaper and smaller than an EP8266 and uses less power.
god, do i love the artwork
Many regular servos usually work quite well as input devices. Some will even quite happily read each others data line and copy them.
Then there’s always adding an extra wire to get the resistance of the potentiometer if you’d prefer an analog value rather than timing and counting pulses.
Stepper motors are also great for connecting back to back and having them follow each other. Steppers will put out quite a high voltage even at fairly low rpm. Just twisting with your fingers can get well up into the forty volt range and higher. Enough to give a reasonable shock if you don’t have completely dry hands.
It is quite easy to convert any analog RC servo to serial. I have done it on a couple. You simply remove the servo controller board and bring the two motor leads and three feedback pot leads to a small microcontroller board (say an attiny) and a cheap H bridge driver. Analog in from the pot and 2 gpio controlling the H bridge and a little software does it. Of course it would be great to make it small enough to fit in the servo case but a small external module is usually no issue. I seem to remember that there was a project for an open servo controller board that could fit in the case of a standard RC servo but I am not sure it is stl around,
Is there a device that would convert a standard 5VDC PWM servo to an addressing controller? I’m surprised this isn’t a thing. Would be really neat if it could buck higher input voltages to minimize current delivery needs to each servo.
There was a product called Openservo available from Sparkfun amongst others but it seems to be no longer available.
Inspired by this article, I made a new one with more smart servos, more data, and a big resume-table.
Check it out here: https://www.libreservo.eu/es/articulo/comparativa-smart-servos-serial-servos#comparativa
I have moved it to another url:
Please be kind and respectful to help make the comments section excellent. (Comment Policy)