Power Supply and Voltage for Hobby Servos: Sizing an SO-100 Rail

A robot arm that is short of current does not switch off. It gets weaker. The elbow drops a centimetre under load, the gripper closes on air, a joint that reached its target yesterday stops two degrees short today, and every one of those failures looks like bad calibration or a bad policy. It is neither. It is the rail.

This page covers the electrical side of a SO-100 class arm: what 7.4 V actually buys you, how much current six Feetech STS3215 servos really draw, what a sagging supply looks like in the servo registers and in a recorded LeRobot dataset, and how to size a brick. Every number below comes from the STS3215 product specification, from the Feetech register map version 3.7, or from LeRobot source you can open yourself. Where two documents disagree, both are quoted rather than averaged.

What 7.4 V means on an STS3215, and what it does not

The Feetech STS3215 is a bus servo with a 12-bit magnetic encoder, a 1/345 metal gearbox on the C001 variant, and a half-duplex TTL bus that leaves the factory at 1 Mbaud. Its product specification lists two operating points, 6 V and 7.4 V, and one rated input range that covers both. The 7.4 V figure everyone quotes is the upper operating point, which is where the marketing torque number comes from.

Three of those rows changed between editions, which is worth knowing before you argue with someone quoting a different PDF. Edition A/0, dated 2020-04-10, lists idle current as 6 mA and Kt as 8 kg.cm/A, and puts over-voltage protection above 7.4 V. Edition A/1, dated 2023-06-23, raises idle to 21 mA, drops Kt to 7.8 kg.cm/A, and moves the over-voltage trip above 8 V. The register map version 3.7 agrees with A/1: the Maximum input voltage register at address 14 ships with 80 in units of 0.1 V, which is 8.0 V, and the minimum at address 15 ships with 40, which is 4.0 V. Read A/1 as current.

The reference build ships a 5 V brick, not a 7.4 V one

This surprises people. The SO-ARM100 bill of materials has a single line item called Power Supply at about 10 USD, linked to a switching adapter with a 5.5 x 2.1 mm barrel, and the README's own prose calls it "a 5V one". Waveshare's SO-ARM100/101 wiki puts a number on it in one sentence: the power supply for SO-ARM100 is 5 V 4 A, and for SO-ARM101 it is 12 V 5 A. The README even acknowledges the cost, noting that the 7.4 V servo has 16.5 kg.cm at 6 V and likely slightly less on a 5 V supply.

How much less is arithmetic you can do from the datasheet. Divide voltage by stall current at the two published points and you get 6 / 2 = 3.0 ohm and 7.4 / 2.5 = 2.96 ohm, so the motor plus driver looks like a constant resistance to a first approximation. Extrapolating to 5 V gives about 1.7 A of stall current, and 1.7 A times the 7.8 kg.cm/A torque constant is roughly 13 kg.cm.

The margin column is the one that matters for brownouts. A 5 V rail sits 1.0 V above the voltage at which the servo declares an under-voltage condition. A 7.4 V rail sits 3.4 V above it. At 4 A of draw, every 0.1 ohm of round-trip resistance in the barrel lead, the jack and the daisy-chain connectors costs 0.4 V, and 0.1 ohm is not an exotic amount of resistance for a cheap DC lead and six push-fit 3-pin connectors in series.

The driver board does not regulate anything

Most of the confusion comes from assuming the little board between USB and the servos does something to the power. It does not. Waveshare's ST3215 servo wiki is the page that says it outright: you provide 6 to 12.6 V via the DC port (5.5 x 2.1 mm) on the board, "and the port will directly power the servo", and if you use a large number of servos you need to provide enough current for that port. The board is a serial level shifter and a barrel jack wired to the bus.

The adapter's own page is worth reading next to that, because its spec strip and its instructions point in different directions. Waveshare lists the Bus Servo Adapter (A) as 9 to 12.6 V input with a 5.5 x 2.1 mm DC socket, and then says twice, in the specification and again in the feature list, that the input voltage must match the voltage of the servos you connect. The second rule is the operative one on a 7.4 V arm, and it is why the SO-ARM100 build runs a brick well below the printed input range. If your board is a different Waveshare model, check its own page rather than assuming this one.

• The barrel jack voltage is the servo bus voltage. There is no buck converter protecting you from a wrong brick.
• All six servos on a follower arm hang off one 5.5 x 2.1 mm connector, daisy-chained through 3-pin cables.
• The current for every downstream servo flows through the first cable in the chain and its two contacts. LeRobot's own assembly order runs the board to shoulder_pan (id 1) and out to the gripper (id 6), so the gripper sits at the far end of the accumulated drop.
• USB carries data only. Waveshare states plainly that USB does not power the servo, and that both the power supply and USB must be connected.
• The leader arm needs its own supply. The BOM lists two power supplies for a leader plus follower build, one each.

Sizing the rail: a current budget you can defend

Six servos, each with a published idle, no-load, rated and stall current, gives you a budget you can write down instead of guessing. Every row below is at 7.4 V, because those are the currents the datasheet publishes; rows marked as combinations are arithmetic on datasheet points, not measured values.

Read the amps column against your supply's amp rating and the watts column against its wattage, and do not mix the two rails up: a 5 V 4 A brick is 20 W, while 4 A at 7.4 V is 29.6 W. The fourth row is the interesting one either way. Six servos merely holding rated torque sits right on a 4 A rating, and 5 kg.cm is not much with the arm extended and something in the end effector. The rows below it are transients rather than steady states, but a transient is exactly what collapses a rail: the supply current-limits or droops for the tens of milliseconds it takes to accelerate the arm, and by the time you reach for a multimeter everything reads fine again.

What a sagging supply looks like in the data

The reason this failure eats a day is that nothing raises an error. LeRobot reads Present_Position and writes Goal_Position, and both succeed whether or not the servo actually got where it was told. You have to go and ask. The STS3215 reports its own supply voltage, current, load and temperature, and LeRobot's Feetech control table already has names for all of them.

1. 1
   Read the rail through the servos, at rest

   Present_Voltage lives at register 62 in units of 0.1 V. LeRobot only normalizes Goal_Position and Present_Position, so everything else comes back raw and needs no calibration file. Start with the arm folded and torque off, which is the best case your rail will ever show. Note that connect() runs configure(), which is where the gripper limits above get written.

   python

   from lerobot.robots.so_follower import SO100Follower, SO100FollowerConfig
   
   # SO100FollowerConfig is the registered dataclass; the bare SOFollowerConfig
   # has no `id` field and will raise TypeError if you pass one.
   robot = SO100Follower(SO100FollowerConfig(port="/dev/ttyACM0", id="follower"))
   robot.connect(calibrate=False)
   bus = robot.bus
   
   raw = bus.sync_read("Present_Voltage")   # register 62, 1 byte, 0.1 V per count
   print({m: v / 10 for m, v in raw.items()})
   # {'shoulder_pan': 5.0, 'shoulder_lift': 5.0, 'elbow_flex': 5.0,
   #  'wrist_flex': 4.9, 'wrist_roll': 4.9, 'gripper': 4.9}

2. 2
   Read it again while the arm is holding itself up

   Enable torque, drive the arm to a fully extended pose, hang the payload you actually intend to manipulate, and sample voltage, current, load and temperature together. Present_Current is register 69 in units of 6.5 mA, Present_Load is register 60 in units of 0.001 of drive duty and is sign-magnitude encoded, and Present_Temperature is register 63 in whole degrees C. A rail that drops more than a few tenths of a volt between the two measurements is the answer to your question.

   python

   import time
   
   for _ in range(50):
       volt = bus.sync_read("Present_Voltage")            # 0.1 V per count
       curr = bus.sync_read("Present_Current")            # 6.5 mA per count
       load = bus.sync_read("Present_Load")               # 0.001 duty, signed
       temp = bus.sync_read("Present_Temperature")        # register 63, deg C
       stat = bus.sync_read("Status")                     # register 65, error bits
       for m in volt:
           print(f"{m:<14} {volt[m]/10:>4.1f} V  {curr[m]*6.5:>6.0f} mA  "
                 f"load {load[m]:>5}  {temp[m]:>3} C  status 0b{stat[m]:06b}")
       time.sleep(0.1)

3. 3
   Decode the status bits instead of guessing

   Register 65 uses the same bit layout as the unloading and LED alarm masks: bit 0 voltage, bit 1 sensor, bit 2 temperature, bit 3 current, bit 4 angle, bit 5 overload. A set bit 0 is the servo telling you the rail left its configured window. While you are there, read back the two masks so you know what the servo will and will not do about it.

   python

   BITS = ["voltage", "sensor", "temperature", "current", "angle", "overload"]
   
   for name, val in bus.sync_read("Status").items():
       flags = [BITS[i] for i in range(6) if val >> i & 1]
       print(name, flags or ["ok"])
   
   print("unloading mask", bus.read("Unloading_Condition", "shoulder_lift"))   # factory 44
   print("led alarm mask", bus.read("LED_Alarm_Condition", "shoulder_lift"))   # factory 47
   print("min volt", bus.read("Min_Voltage_Limit", "shoulder_lift") / 10)      # factory 4.0
   print("max volt", bus.read("Max_Voltage_Limit", "shoulder_lift") / 10)      # factory 8.0

One detail from that fifth row is worth knowing before you chase it. SOFollowerConfig ships with num_read_retries set to 2, and its own comment says Feetech buses occasionally return a corrupted status packet "especially when several joints move at once", which would otherwise abort the control loop. Several joints moving at once is also exactly when a weak rail dips, so retries can mask the electrical symptom while the tracking error quietly grows.

The second half of the fingerprint is in the episodes you already recorded. A LeRobot dataset stores action as the commanded joint vector and observation.state as the measured one, both with names like shoulder_lift.pos, so the residual between them is the tracking error of the follower. Under a healthy rail that residual is small and roughly symmetric. Under a sagging one it grows on the gravity-loaded joints exactly when the arm is extended, and it returns to zero when the arm folds. This belongs in the same pre-flight check as everything in collecting high-quality VLA training data, because it is a data defect that no amount of GPU time undoes.

import numpy as np
from lerobot.datasets.lerobot_dataset import LeRobotDataset

ds = LeRobotDataset("your-user/your-so100-dataset")
names = ds.features["observation.state"]["names"]   # ['shoulder_pan.pos', ...]

cols = ds.hf_dataset.select_columns(["action", "observation.state"]).with_format("numpy")
goal = np.asarray(cols["action"])              # (T, 6) what the leader commanded
state = np.asarray(cols["observation.state"])  # (T, 6) where the follower got to
resid = goal - state

for i, n in enumerate(names):
    print(f"{n:<18} mean {resid[:, i].mean():+7.2f}  p95 {np.percentile(np.abs(resid[:, i]), 95):6.2f}")

# A constant non-zero mean on one joint is usually calibration.
# A p95 several times the mean, concentrated on shoulder_lift and elbow_flex,
# is the shape a sagging rail leaves behind.

The protection rules you hit first

The datasheet lists four electronic protections, and you will meet them in a specific order. All four are configurable, all four ship with values you can read out of the register map, and the defaults are not the ones you would guess. In particular, the servo is far more willing to give up on torque than on current.

There is one more default worth decoding by hand, because it explains why an under-volted arm never tells you it is under-volted. The unloading condition register at address 19 ships with the value 44. In the register map's bit order, that is bit 5 overload plus bit 3 current plus bit 2 temperature: 32 + 8 + 4 = 44. Bit 0 is voltage, and it is clear. The LED alarm register at address 20 ships with 47, which is 32 + 8 + 4 + 2 + 1, and there bit 0 is set.

So the factory configuration flashes an LED for a voltage fault but does not unload on it. The servo keeps trying, at whatever torque a low rail can produce, and your Python never sees an exception. That is the whole reason this failure mode gets misdiagnosed as calibration drift, a bad policy, or a flaky serial link for a full day before anyone puts a meter on the barrel jack.

Two routes to a rail you trust

The measurement is the same either way. The difference is what you have to own to do it, and whether you have a known-good arm to compare against.

Where a hosted platform cannot help you

It is worth being blunt about the boundary. Everything upstream of the barrel jack is yours. Remote teleoperation does not change how much current a servo draws, fine-tuning a 3 B parameter model does not compensate for a joint that physically cannot hold its pose, and no dataset validation step inspects your rail because your rail is not in the dataset. What is in the dataset is its consequence, which is why the residual check earlier is the only remote-friendly diagnostic on this page.

There is a related trap at the other end of the loop. Per-action inference latency here runs from 20 ms for ACT to 485 ms for Pi0.5, and adding public internet round trips turns a working policy into a hesitant one. A hesitant policy and a sagging rail produce a similar-looking video. Measure the voltage before you blame the network, and the network before you blame the model.

What to actually buy

There is no single right answer, because the reference build and the datasheet headline point at different voltages. Pick based on what you are doing with the arm rather than on which number is bigger.

Two practical notes that are not about voltage. Buy a regulated supply rather than the cheapest one with the right sticker, because the 16 V measurement reported in issue 3394 was on a brick whose label said 12 V. And give the leader arm its own supply, as the BOM does. It runs with torque disabled and draws almost nothing, but sharing one jack between two arms puts the follower's stall transients on the leader's rail, and the leader is the thing generating your action labels. If you are still choosing hardware, SO-100 against SO-101, LeKiwi and Koch v1.1 lay out the rest of the differences, the arm overview collects them, and the full SO-100 setup guide covers the build end to end.