Enigma says six FeeTech STS3215 magnetic-encoding servos make up a standard SO-101 arm, and it chose the same units for custom arms used in its online robot event. In a separate account, the company reported putting more than 100 AI-powered robots online through its foundation model and keeping the deployment live for four days.

That deployment needed both software observability and a hardware repair loop. Enigma says a central dashboard displayed every active station with real-time logs, while a maintenance line repaired and recycled arms back into service.

Why identical servo IDs caused trouble

The STS3215 contains a 32-bit Arm microcontroller and uses a proprietary protocol over UART, according to Enigma. In an SO-101 arm, the servos share a multidrop bus through a daisy chain of three-pin 5264 connectors. Each servo decides whether to act on a packet by matching the packet ID against an ID stored in EEPROM.

Every unit in Enigma’s bulk order arrived with ID 1. That created a setup problem: when multiple servos shared that ID, all of them acted on the same write command and answered the same read request. Enigma says the replies collided and became unreadable.

One test produced a well-framed but invalid position value equal to the bitwise OR of the two servos’ actual positions. A blind attempt to change the shared ID did not separate the devices; both test servos ended up on ID 2.

How Enigma split servos on the shared bus

Enigma reports finding an undocumented instruction, 0x8, that appeared to reboot the STS3215. The company says the command was absent from FeeTech’s official datasheet but present in an unofficial firmware reimplementation.

Tests on two servos found wake times that were usually no more than one millisecond across the devices and their positions in the chain. The timing was consistent enough to target a short interval after reboot, yet variable enough that one servo could be ready while the other was still starting.

Enigma’s first method sent the reboot instruction to every servo still on ID 1, then repeatedly sent an EEPROM unlock and a new ID write. If the messages landed while only some servos were awake, those units moved away from ID 1. Repeating the process separated the devices.

The company says this approach worked from a MacBook but failed to converge on the Raspberry Pi 5 used during assembly. Enigma attributed the difference to roughly one millisecond of USB write jitter between the Pi and a Waveshare adapter, enough to miss the wake window.

Its workaround packaged many unlock-and-write bursts into one large USB transfer, with successive bursts carrying different IDs. The adapter could then send the bursts with lower timing variance. Enigma says this made the assignment process more reliable and allowed more than one servo to separate during a write.

Unique IDs still did not reveal which servo occupied each physical joint. Enigma considered several inference methods but chose a manual sequence: a person moved each joint while the software watched position readings and assigned the expected order.

Heat, overload protection and recognizable failures

Enigma says the STS3215’s default maximum-temperature setting is 70°C. Above that limit, torque is disabled; current temperature is available from the Present_Temperature register. During long continuous operation, particularly on high-load arms, the team found the temperature reading useful enough to log across the fleet.

The company describes the default overload threshold as 80% of stall torque with a two-second dwell. Triggering it reduces output to a configurable fraction of stall torque. FeeTech’s specification says a new position command clears the protection, so software that continuously streams commands without reading the overload state can defeat the safeguard.

Enigma says its initial control stack behaved that way and eventually produced shorted servos. The team reported multiple units emitting smoke, but said it was unsure of the exact electrical mechanism. Once shorted, a servo could flood the shared bus and make every joint in the chain feel stiff. The team isolated the failed unit by disconnecting sections of the chain—or by locating the smell of burnt electronics.

Gear wear had a different signature. Enigma describes a loud clacking noise caused by damaged teeth. A servo could keep operating for a while, but the company treated the sound as an early warning that replacement would soon be needed.

Calibration and the maintenance loop

Enigma also described a calibration script that moved each joint toward an unreachable target at low torque, polled the Moving flag to detect the mechanical stop, and recorded the joint limits and midpoint. It stored the homing offset and minimum and maximum positions in the six servos’ EEPROM rather than using a separate serial-number-keyed JSON file.

The company released its servotools utilities for SO-101 users, including the automated ID-assignment work. In preparation for the online release, Enigma says its team learned to tear down, repair, cannibalize, recalibrate and rebuild arms quickly.

During the event, an arm with a problem entered what Enigma called the ArmPit Stop. The company says serviced and tested replacements could return to the fleet within minutes, while the central dashboard helped operators identify the stations that needed attention.

Sources

This article was researched and fact-checked against the following sources: