DEV Community: Gearotons

What is an integrated servomotor? (And when you actually want one)

Gearotons — Wed, 09 Sep 2026 22:39:46 +0000

If you've built anything with motors, you know the standard parts pile: a stepper or BLDC, a driver board, a controller to generate steps or commands, maybe an encoder if you care whether the motor actually went where you told it, and a loom of wires connecting all of it. An integrated servomotor collapses that pile into one part: motor + driver + motion controller + encoder in a single housing, speaking a single cable's worth of protocol to the outside world.

What's actually inside

The motor: usually a stepper in the maker/light-industrial class (steppers give high torque at low speed without a gearbox).
An encoder on the rotor, so the unit knows its true shaft position at all times.
A driver: the power electronics that energize the windings.
A motion controller: a microcontroller running a feedback loop between encoder and driver, accepting high-level commands ("go to 90° over 2 s") instead of step pulses.

The feedback loop is the point: this is what makes it a *servo*motor. An open-loop stepper trusts that every step happened; under a snag or a too-fast move it silently loses position. A closed-loop integrated unit measures and corrects, continuously.

What it replaces

The classic stack	The integrated unit
Motor + driver + controller + encoder, 3 vendors	one part, one datasheet
STEP/DIR wiring per axis + encoder cabling	one bus cable, daisy-chained
Tuning current/microstepping by hand	tuned at the factory for its own motor
"Which combination of parts failed?"	one thing to swap

The wiring difference compounds with axis count: a 6-axis machine on STEP/DIR is dozens of conductors; on a multi-drop bus (RS-485 in the M17's case) it's one twisted pair visiting each motor. Each unit gets an address; the controller talks to all of them on one port.

The honest trade-offs

Frame-size torque ceiling. Integration doesn't create torque. A NEMA-17 integrated unit is still a NEMA-17 motor (~0.3–0.65 N·m holding). If the axis needs more, you gear it or go up a frame size; don't expect the electronics to save you.
Heat shares a body. Driver and motor in one housing means one thermal budget (the M17 is 25–38 W by size, IP20, indoor use; we say so on the box).
You're trusting the vendor's firmware. With a closed product, a controller quirk is a support ticket. This is the strongest argument for open integrated servos: if the firmware is on GitHub, the failure mode is "read the code," not "wait for the vendor."
Unit price reads higher than a bare stepper, until you price the driver, encoder, controller board, wiring, and your integration hours that the bare motor still needs.

What to look for when buying one

Loop rate (how fast it corrects; the M17 runs its PID at 32 kHz)
Encoder type and resolution
The bus: multi-drop (RS-485/CAN) beats point-to-point if you'll ever add axes
Software: real libraries with units ("degrees", "seconds"), not register tables
Openness: schematics + firmware + libraries published, or a black box?
An AI/agent story, the newest differentiator: can an LLM drive it through a documented API, with the motor protecting itself in firmware? (No motor vendor we've found ships this first-party except us: the M17 comes with an MCP server, so Claude can run it in plain English.)

Where the M17 sits

The M17 is our take on what this category should be: NEMA-17 integrated closed-loop servo, RS-485 daisy-chain, open hardware/firmware/software, Python and Arduino libraries, and a first-party MCP server for plain-English AI control, from $20. Where it doesn't fit: axes needing more than ~0.65 N·m un-geared, wet/dusty environments (IP20), or more power than its 25–38 W (by size) rating.

See the M17 family · Watch Claude Code drive one

Written with the help of an AI and verified by a human. Hardware, firmware and software for the M17 are open source: github.com/tomrodinger/servomotor. The MCP server: github.com/Gearotons/servomotor-mcp.

How to control a stepper motor from a Raspberry Pi (without babysitting STEP/DIR)

Gearotons — Wed, 09 Sep 2026 22:35:03 +0000

If you've tried to drive a stepper motor from a Raspberry Pi the traditional way, you know it's more fiddly than it should be. You wire a driver board (A4988, TMC2209) to the Pi's GPIO pins, generate STEP and DIR pulses with precise timing, fight the Pi's non-real-time scheduler for smooth motion, add an encoder if you care about lost steps, and write your own homing logic. It works, but it's a project in itself, before you've done anything useful with the motion.

There's a much simpler path: an integrated servomotor that does the driving, the closed-loop control, and the motion planning inside the motor, and talks to the Pi over a single serial bus. You send high-level commands ("go to 90 degrees") and read back the true position. Here's how to do it with the Gearotons M17, and how the same idea applies whatever integrated motor you use.

The two approaches, side by side

Traditional (GPIO + driver):

Wire STEP, DIR, ENABLE, microstep pins, motor coils, motor power.
Generate step pulses in software (or with a HAT) at the right rate.
No idea if the motor actually moved: open-loop, lost steps possible.
Homing, acceleration curves, and multi-motor coordination are all on you.

Integrated servo over serial (the M17 way):

One USB-to-RS-485 adapter into the Pi; motor power from a 12–24 V supply.
High-level commands over the serial bus: position, speed, homing.
Closed-loop: the motor holds the commanded position and reports its real angle.
Daisy-chain more motors on the same two wires, each individually addressed.

The trade is cost per motor (an integrated servo costs more than a bare driver + motor) for a massive cut in integration effort and a big jump in reliability. For robot arms, plotters, lab automation, or anything you can't babysit, that trade is usually worth it.

What you need

A Raspberry Pi (any model with USB; Pi 4 / Pi 5 / Zero 2 W all fine).
A Gearotons M17 servomotor.
A USB-to-RS-485 adapter (a $5–10 part; the M17 speaks RS-485 at 230400 baud).
A 12–24 V DC power supply for the motor.
Python 3.10+ on the Pi.

Wiring is refreshingly boring: USB adapter into the Pi, the adapter's A/B lines to the motor's RS-485 pins, motor power from your supply. No GPIO pin-counting.

Install the library

pip install servomotor

That's the official Python library: it speaks the M17 protocol, handles the serial framing, and does automatic unit conversion so you can work in degrees and seconds instead of encoder counts and timesteps.

Find your motor

Each M17 has a factory-unique ID and a short alias (a single byte, e.g. X) so you can put many on one bus. First, see what's connected:

import servomotor
from servomotor import communication
from servomotor.device_detection import detect_devices_iteratively

communication.serial_port = "/dev/ttyUSB0"   # your USB-RS485 adapter
servomotor.M3(alias_or_unique_id=255)         # 255 = broadcast
servomotor.open_serial_port()

for d in detect_devices_iteratively(3):
    print(f"Found motor: unique_id=0x{d.unique_id:016X}, alias={d.alias}")

servomotor.close_serial_port()

Run it and you'll see each motor's unique ID and alias. (On a Pi the port is usually /dev/ttyUSB0; on a Mac it's something like /dev/cu.usbserial-XXXX.)

Move it, in six lines

Here's a complete program that connects, enables the motor, moves to 90°, reads the position back, and returns to zero:

import time
import servomotor
from servomotor import communication

communication.serial_port = "/dev/ttyUSB0"
servomotor.open_serial_port()

# Work in degrees and seconds; address the motor by its alias.
m = servomotor.M3("X", time_unit="seconds", position_unit="degrees")

m.enable_mosfets()                 # energize the motor
m.go_to_position(90, 1.0)          # absolute move to 90 deg, over 1 second
time.sleep(1.2)
print("position:", m.get_position())   # -> ~90.0, measured by the encoder
m.go_to_position(0, 1.0)           # back to zero
time.sleep(1.2)
m.disable_mosfets()                # release

servomotor.close_serial_port()

That's it. No pulse timing, no DIR pins, no microstepping config. go_to_position runs a smooth trapezoidal profile to the target; get_position returns the actual angle from the onboard encoder, not what you hoped happened. On our bench the read-back lands on the commanded angle to encoder resolution.

Smooth moves and relative jogs

A couple more commands cover most real use:

m.trapezoid_move(45, 0.5)    # relative: move +45 deg over 0.5 s (accel/decel)
m.trapezoid_move(-10, 0.3)   # nudge back 10 deg
print(m.get_status())        # health: [status_flags, fatal_error_code]
m.homing(360, 5)             # hard-stop homing: up to 360 deg of travel, 5 s max

Because the motor is closed-loop, get_status tells you if anything went wrong (it raises an error rather than silently losing steps), and get_position always tells you the truth.

Driving several motors on one bus

This is where serial-bus integrated motors shine on a Pi. Give each motor a different alias and address them independently, all on the same pair of wires:

base     = servomotor.M3("A", position_unit="degrees", time_unit="seconds")
shoulder = servomotor.M3("B", position_unit="degrees", time_unit="seconds")
elbow    = servomotor.M3("C", position_unit="degrees", time_unit="seconds")

for j in (base, shoulder, elbow):
    j.enable_mosfets()

base.go_to_position(30, 1.0)
shoulder.go_to_position(-20, 1.0)
elbow.go_to_position(45, 1.0)

A three-axis arm on a single Pi, three lines of motion code, one cable. Wiring a GPIO driver per axis would be a far bigger build.

From here

Once you can move a motor in a few lines of Python from a Pi, a lot opens up: a pen plotter, a camera slider, a small robot arm, a lab fixture. And because the M17's command interface is clean and well-documented, you can go one step further and let an AI assistant issue those commands. We have an open MCP server that does exactly that, so you can drive the hardware from plain language; here is Claude Code doing it on a real M17 (50 s).

The headline: controlling a stepper from a Raspberry Pi used to mean GPIO timing and lost-step anxiety. With an integrated closed-loop servo over serial, it's a pip install and six lines.

M17 vs Dynamixel: an honest comparison (and an open-source alternative)

Gearotons — Wed, 09 Sep 2026 22:32:28 +0000

If you're building a robot arm or a research platform, Dynamixel is probably the first smart servo you looked at, and for good reason. ROBOTIS has spent over a decade building one of the best motor ecosystems in robotics. So let's be upfront: this isn't a hit piece. It's an honest look at where Dynamixel is the right call, and where an open-source, NEMA-17 integrated servo like the Gearotons M17 is the better fit.

They're not actually the same kind of motor, and that's the whole point.

What each one is

Dynamixel (e.g. XL330-M288-T, XL430-W250-T) is a smart gearmotor servo: a small DC motor with a gearbox, an encoder, and a controller in a compact plastic housing, talking a TTL serial protocol. The XL330 is tiny and runs on 5 V; the XL430 is a bit bigger on 11.1 V. They daisy-chain, do position/velocity/current control, and have an SDK that's the envy of the industry.

The M17 is an integrated NEMA-17 stepper servomotor: a standard NEMA-17 stepper with a closed-loop driver, motion controller, and magnetic encoder built into one unit, talking RS-485. No gearbox: a stepper holds position directly, with no gear backlash, and you get the high holding torque and fine positioning steppers are known for.

That difference (geared DC servo vs. integrated closed-loop stepper, TTL vs. RS-485, proprietary vs. open) drives everything below.

Side by side

	Gearotons M17	Dynamixel XL330 / XL430
Type	Integrated closed-loop stepper (NEMA-17)	Smart gearmotor servo
Open source	Hardware + firmware + software	Proprietary HW/FW (open SDK + protocol docs)
Mounting	Standard NEMA-17 (any bracket, GT2 pulley, coupling)	Proprietary horn/frame (FR-series brackets)
Bus	RS-485, 230400 baud, daisy-chain	TTL, daisy-chain
Encoder / control	32 kHz closed loop, magnetic encoder	Contactless absolute encoder
Libraries	Python + Arduino, auto unit conversion	DYNAMIXEL SDK (C/C++/Python/ROS/Arduino), best-in-class
Ecosystem	Young, growing	Huge: ROS/MoveIt, years of research use
AI-native	First-party MCP server (drive from an LLM)	None first-party
Price (verified 2026-06/09)	$20–35 (4 sizes; US $23–40 with import duty included)	XL330 $27.49, XL430 $27.50
Voltage	12–24 V	5 V (XL330) / 11.1 V (XL430)

Where Dynamixel genuinely wins

Be clear-eyed about this:

The software ecosystem. The DYNAMIXEL SDK and its ROS/MoveIt integration are mature, documented, and battle-tested across thousands of research projects. If you're doing ROS-based manipulation research, Dynamixel is a paved road.
Compactness. The XL330 is tiny and light. For a small desktop arm or a humanoid hand where grams and millimeters matter, a NEMA-17 is simply bigger.
Proven track record. It's been the default smart servo in education and research for years. That maturity has real value: you're unlikely to hit a surprise.
Velocity and current modes. Dynamixel exposes both out of the box. The M17 has velocity moves in its command set, but no current-control mode.

If those are your priorities, buy Dynamixel. We mean that.

Where the M17 wins

It's open-source, top to bottom. Hardware, firmware, and libraries are all public. You can inspect it, modify it, fix it, and keep it running for years without depending on one vendor's roadmap. For a lot of people that's not a nice-to-have; it's the requirement.
Standard NEMA-17 mounting. The M17 drops into the entire maker/CNC/3D-printer hardware universe: standard brackets, GT2 pulleys, 5 mm shaft couplers, the lot. No proprietary horns. If you're building anything in that world, this matters enormously.
RS-485, not TTL. RS-485 is the industrial-grade differential bus: better noise immunity and longer cable runs, which you feel the moment your robot is bigger than a desktop toy.
AI-native control. The M17 ships with a first-party MCP server, so an AI assistant can drive it from natural language. No motor vendor, Dynamixel included, offers that today. Here is Claude Code driving a real M17 (50 s).
Stepper characteristics. High holding torque, precise open-frame positioning, no gearbox backlash. For pen plotters, CNC-style motion, camera rigs, and lab fixtures, a NEMA-17 stepper servo is often a more natural fit than a geared hobby servo.

On price (the honest version)

You'll notice the XL330, at ~$27, sits right in the M17's price range. That's a fair point, and a reminder to compare like with like. The XL330 is a tiny 5 V geared servo; the M17 is a full NEMA-17 integrated stepper servo with several times the physical size and a different torque/positioning profile. The more apples-to-apples comparison for "integrated closed-loop NEMA-17 over a serial bus" is the proprietary industrial options (StepperOnline's iCL/ESS at $62–84), and against those, the M17 is dramatically cheaper and open. (Separate post coming.)

So the M17 isn't trying to win on price against a $27 hobby servo. It's offering a different, standard-mount, open, AI-native motor at a price that's still accessible.

Which should you choose?

Choose Dynamixel if: you're doing ROS/MoveIt research, you need the most mature SDK and community, you're building something small and weight-sensitive, and proprietary hardware is fine for your project.

Choose the M17 if: you want open-source you can own and modify; you're building on standard NEMA-17 hardware (printers, CNC, plotters, larger arms); you want RS-485 robustness; you want to drive motors from an AI assistant; or you simply prefer a closed-loop stepper's positioning characteristics. And if you've been put off by proprietary lock-in or by the price of integrated industrial RS-485 servos, the M17 is built specifically for you.

Different tools for different jobs. We're glad Dynamixel exists: it raised the bar for what a smart servo should be. The M17 takes that bar and makes it open, standard-mount, and AI-ready.

What makes a motor "AI-friendly"?

Gearotons — Wed, 09 Sep 2026 22:29:34 +0000

"AI-friendly" is well on its way to becoming a meaningless sticker, slapped on anything with a microcontroller and a press release. So let me be precise about what it actually means for a piece of motion hardware, because it turns out to be the opposite of a marketing gimmick: it's a set of boring engineering properties that happen to matter enormously the moment an LLM is in the control loop.

Here's the thesis: a motor is AI-friendly to exactly the degree that it is human-friendly, because the things that make hardware easy for a person to program are the same things that make it reliable for a model to operate as a tool. Good docs for people turn out to be good docs for machines.

What an LLM actually needs from hardware

When you wire a language model to a physical device, via tool-calling, an MCP server, or an agent loop, the model isn't running a real-time control loop. It's doing something more like what a careful human operator does: deciding what should happen ("move axis 2 to 90 degrees, slowly"), calling a function, and reading back the result to decide what's next. For that to work reliably, the hardware interface has to provide four things:

Intent-level commands, not timing. A model should say go_to_position(90°) or homing(), not bit-bang STEP/DIR pulses with microsecond timing. Low-level protocols are fine for an FPGA and miserable for an LLM (and for a human writing a quick script). The command surface should be the intentions you actually have.
Clear, complete, structured documentation. A model reads your docs (or your tool schemas) and acts on them literally. Ambiguity, missing parameters, and "see the forum post" gaps that a human muddles through become hard failures for a model. The discipline that makes a datasheet pleasant for a person (every command defined, units explicit, ranges stated) is exactly what lets a model call the interface without guessing.
Real, readable feedback. The model has to be able to ask what happened: where is the shaft now? Did the move finish? Is there an error? A motor that silently drifts (see: open-loop step loss) is poison for an agent, because the model can't recover from a failure it can't observe. Closed-loop position feedback isn't just a precision feature here; it's what makes the loop honest.
Safety in the hardware, not the model's good behavior. Models hallucinate. An agent will occasionally emit a wrong tool call. You don't want the only thing standing between a bad command and a damaged mechanism to be a prompt that says "please don't break things." The protection that matters belongs in the motor itself. On the M17, the firmware enforces over-current, over-voltage, and over-temperature limits that hold no matter what command arrives. Safety belongs in the hardware, not in the model's goodwill.

Notice that none of these are AI features. They're just good interface design. The "AI-friendly" claim is really a claim that you did the unglamorous work well.

Automatic unit conversion is an underrated example

Here's a concrete one. Ask a model to "turn the motor a quarter turn" and it'll happily reason in degrees or rotations. Internally, the motor thinks in encoder counts and timesteps. If your library makes the caller do that conversion, every integration, human or model, becomes a source of off-by-a-factor bugs. If the library accepts degrees and seconds and converts for you, the model (and the human) can operate at the level they actually think at. Small thing; huge reliability difference across thousands of tool calls.

The MCP server is where it gets real

The cleanest way to make a motor drivable by AI today is to expose it as a set of MCP tools: a well-described API that any MCP-capable client (Claude Desktop, an agent, your own loop) can call. A good tool surface for a motor leads with intent-level tools: discovery (list_serial_ports, connect, list_motors), move_to, move_relative, get_motor_status, stop, and a run_sequence for choreographed motion, with the full firmware command set exposed underneath (one generated tool per command), so nothing the motor can do is out of the model's reach. Each tool's description states when to call it, not just what it does, because models, like junior operators, do better with explicit triggers.

Crucially, the MCP server stays a thin control layer: it forwards intent-level commands straight to the motor, so the model has the motor's full range and speed to work with. The safety that matters lives one layer down, in the motor's own firmware: over-current, over-voltage, and over-temperature protection that holds regardless of what the model asks for. The model drives; the hardware protects itself.

We've built exactly this for the M17 (servomotor-mcp; uvx --from servomotor-mcp servomotor-mcp runs it with a simulated motor), and the behavior holds up on real hardware. Here is a real session, replayed from the log, with the bench motor filmed alongside: 50-second video. In it, an LLM issues plain-language instructions, the motor moves closed-loop to the commanded angle, and the motor's firmware self-protects if a command would push it past its electrical or thermal limits. No vendor lock-in: the server is MIT-licensed and speaks plain MCP, so any MCP client can drive it.

Why this is a category, not a feature

No motor manufacturer markets this today. The bridges that exist are third-party software bolted onto generic servos. That's a tell: "AI-friendly" hasn't been treated as a hardware design goal, as something you build the command surface, the docs, the feedback, and the safety model around from the start.

We think that's where motion control is heading. Not because AI is magic, but because the properties that make a motor good for an agent (high-level commands, honest feedback, complete docs, hardware protection you can trust) are the same properties that have always made hardware good to work with. "AI-friendly" is just a forcing function for doing the basics right.