[nicolas-rabault]

What

Replaces the vendor Feetech and Dynamixel Python SDKs with rustypot (>= 1.13.1), removes the control tables LeRobot carried for them, and merges the two family buses into one SerialMotorsBus.

feetech-servo-sdk and dynamixel-sdk are pure-Python implementations of the two serial protocols. rustypot implements both in Rust behind pyo3 bindings: framing, checksums and packet parsing run in compiled code, and the GIL is released for the whole transaction. It also states the facts LeRobot transcribed by hand from the vendor manuals (register addresses and sizes, byte order, sign encoding, resolution, baud-rate codes, model numbers), and since 1.11.0 the ones that told the two families apart: the homing offset sign, the operating mode values, whether the drive mode is a register, the Feetech EEPROM lock, and since 1.13.1 which status bits mean a refused access. So both tables.py and the per-family bus classes go.

How

Each motor's model (sts3215, xl330-m288, ...) is looked up with rustypot.find_model, which returns its exact model number and its servo definition. On connect, the bus opens a rustypot.Bus with each motor's definition, so models share a port (STS and SCS, XL430 and XL330), each read and written with its own layout, byte order and sign encoding.

What used to differ between FeetechMotorsBus and DynamixelMotorsBus now comes from the definition:

	Feetech	Dynamixel	decided by
homing offset	subtracted from the position	added to it	homing_offset_sign
position control	operating mode 0	operating mode 3	set_operating_mode("position")
drive mode	applied in software, from the calibration file	Drive_Mode register	whether the register exists
firmware check	the motors of each servo definition on one version	none	whether Firmware_Major_Version exists
configure_motors accelerations	Maximum_Acceleration (STS), Acceleration	none	whether the registers exist
torque	the EEPROM lock follows it	torque only	rustypot's Bus.set_torque

What stays LeRobot's: normalisation, the calibration procedure, the recommended settings (configure_motors), the operating mode each robot uses.

Behaviour and API changes

• Extras: feetech and dynamixel install rustypot instead of the vendor SDKs and no longer pull deepdiff. They now alias a new serial-motors extra (rustypot + pyserial, which lerobot-find-port needs); a missing rustypot points to it.
• Deprecated, for one release: FeetechMotorsBus and DynamixelMotorsBus, now aliases of SerialMotorsBus that emit a DeprecationWarning; FeetechMotorsBus(protocol_version=...), accepted and ignored; their OperatingMode and TorqueMode enums. Use SerialMotorsBus (exported from lerobot.motors) and bus.set_operating_mode("position").
• New: SerialMotorsBus.set_operating_mode(mode, motors=None), with position, velocity and pwm on both families, extended_position, current_based_position and current on Dynamixel, step on Feetech; DriveMode in lerobot.motors.
• Removed: lerobot.motors.{feetech,dynamixel}.tables and their star re-exports, encoding_utils, the MotorsBus alias, the model_*_table attributes (bus.resolution(model) gives the encoder resolution), models, apply_drive_mode, set_timeout(), get_baudrate(), broadcast_ping(), scan_port() (nothing in LeRobot called it; rustypot's Bus.scan and Bus.broadcast_scan do the same), the SDK objects (port_handler, packet_handler, sync_reader, sync_writer) and the PortHandler, PacketHandler, GroupSyncRead and GroupSyncWrite protocols of motors_bus.py.
• Model check: the handshake and setup_motor() check the exact model number of the configured model: an SM8512BL set as sts3215 is refused, although both share a control table.
• Torque: disable_torque() and enable_torque() go through rustypot, which attempts every selected motor: failures are reported in a ConnectionError naming them, and a motor that does not answer may stay under torque. On a closed bus they raise DeviceNotConnectedError. The Feetech lock still follows the torque.
• Timeout: the port waits 50 ms per status packet and per attempt, and each retry waits again. The SDKs recomputed their wait per packet (about 50 ms for Feetech, 34 ms for Dynamixel); a dead motor at disconnect() costs 0.3 s.
• Checks and errors: set_operating_mode() and set_half_turn_homings() check every selected motor before writing any register. read(), write() and sync_read() raise a RuntimeError when a motor refuses the access, as rustypot's ServoDefinition.refuses tells it (an error number on Dynamixel), not on an alarm it reports while carrying it out: a Feetech status only reports alarms, and the alert bit of a Dynamixel is a latched hardware fault. Error messages name motors by motor ID. Register names are normalised whatever their case. set_baudrate() and ping() raise DeviceNotConnectedError on a closed bus.
• Half-turn homing: the fix of fix(motors): keep Feetech half-turn homing offsets representable #4940 is carried over from main. A Feetech homing offset that does not fit its sign-magnitude register (2048, for a joint held at position 4095) is clamped to 2047, the bound coming from the register's sign bit in the definition. The Acceleration_Multiplier name fixed in fix(motors): remove trailing space from Feetech Acceleration_Multiplier name #4926 now comes from rustypot, and test_control_tables.py no longer checks the removed tables.
• Finding and setting up motors: a broadcast ping where the servo answers one (Feetech STS, Dynamixel X), which covers a USB adapter's latency timer once; one Model Number read per ID elsewhere (Feetech SCS). setup_motor() tries the default baud rate, then the factory one, then the rest in a fixed order, has rustypot write the ID and the baud rate (torque off and lock open first), puts the port back at the default rate even when the search or the writes fail, and reads the model number back at the new ID and the default rate, raising if the motor does not answer there as the model it is configured as. ping() reads Model_Number instead of sending a ping instruction.
• SCS values: Present_Velocity, Present_Load and Goal_Velocity of the SCS0009 are decoded with their sign bit (e.g. -232 instead of the raw 33 000), as they already were on STS servos. Resetting an SCS calibration no longer writes a homing offset it does not have.
• Dynamixel is_calibrated no longer compares the ID stored in the calibration file, like Feetech.
• disconnect() is safe on a closed bus and releases the port even when disabling torque fails.
• Devices: every Feetech and Dynamixel robot and teleoperator builds a SerialMotorsBus and names its operating modes. HopeJR's hand drops protocol_version and reads its SCS servos with sync_read. OpenArm Mini asks the bus for the motor resolution. LeKiwi clamps wheel speeds to ±32767, the sign-magnitude range of Goal_Velocity.

Tests

The byte-level SDK mocks are replaced by an in-memory rustypot.Bus (MockBus) keyed by motor ID and register name. Register access and its error statuses, connection handling, torque, scanning and setup are tested once, on SerialMotorsBus with dummy definitions. The family files run the real rustypot definitions: Feetech (STS and SCS sharing a bus, the SCS without a homing offset, the acceleration registers, the firmware check, the drive mode applied in software to reads and commands, the STS3215 Phase quirk, an SM8512BL refused as an sts3215, the deprecated alias) and Dynamixel (two definitions sharing a bus, the homing offset sign, the operating mode values, the drive mode left to the register, the calibration mismatches, configure_motors, the deprecated alias).

tests/motors, tests/robots, tests/teleoperators and tests/test_control_robot.py: 321 passed at 2eea94e, 3 skipped (they need onnx, the Unitree SDK and Damiao hardware).

Hardware

• On SO-101 follower and leader, before the bus merge: scan, handshake and calibration identical to main, a 47-minute and a 2-minute teleop at 30 fps with no communication error, a lost reply costing 52 ms. A community review (above) found no regression against main on an SO-101 driven from a Jetson Orin NX, including lerobot-record.
• The rustypot 1.11.0 features this branch now uses (broadcast scan, changing a motor's ID and baud rate, torque on a whole bus) were checked on SO-101 arms in Proposal: find motors with a broadcast ping, and set their id and baud rate pollen-robotics/rustypot#142, running python lerobot/scripts/eval.py \ -p lerobot/diffusion_pusht \ eval.n_episodes=10 \ eval.batch_size=10 on apple silicon Mac  #143 and Override pretrained model config #147.
• After the bus merge, at 8d35116, on two more SO-101 arms: handshake, read_calibration (identical to the registers read through rustypot directly), sync_read at p50 1.00 ms / p99 1.09 to 1.22 ms, disable_torque in about 5 ms, setup_motor rewriting a motor's own id and rate and reading its model back, and a failed motor search leaving the port at 1 Mbps (see the comment below).
• With refactor(motors): share the hand calibration and the motor setup of serial-bus devices #4867 stacked on 8d35116: hand calibration of two SO-101 pairs (end stops within about 15 encoder steps of their previous calibration), a kept calibration file and 20 s teleoperations at 60 Hz; an OMX pair, Dynamixel XL430 and XL330 on OpenRB-150 boards: handshake, factory calibration, is_calibrated and a 20 s teleoperation at 60 Hz.
• At ecc1b54 with refactor(motors): share the hand calibration and the motor setup of serial-bus devices #4867 stacked on it (9acb3d5) and rustypot 1.13.1, on an SO-101 pair: a 50 s teleoperation with the follower gripper squeezing a rigid object (load up to 31 %, jaws held at 15.6 % open). The gripper answered the overload alarm (0x20) on 784 sync reads and 79 reads, and the loop ran its 1367 ticks without an exception, where 703164d raised on any non-zero status.
• Not run on hardware yet: the checks before writing of 703164d, and Koch. Tests on those are welcome.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[Copilot]

🟡 Changes recommended

Optional-dependency tests will fail isolated CI tiers, and protocol-1 scanning remains incorrectly blocked.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Replaces vendor motor SDKs with a shared rustypot-backed transport and introduces automatic serial motor-family selection.

Changes:

• Adds MotorTransport/RustypotTransport and centralizes serial I/O.
• Adds the SerialMotorsBus factory and migrates robot/teleoperator consumers.
• Reworks dependencies and tests around an in-memory transport.

File summaries

File	Description
uv.lock	Replaces vendor SDK packages with rustypot.
pyproject.toml	Defines rustypot motor dependencies.
docs/source/integrate_hardware.mdx	Documents SerialMotorsBus.
src/lerobot/motors/__init__.py	Exports the bus factory.
src/lerobot/motors/transport.py	Adds the rustypot transport seam.
src/lerobot/motors/motors_bus.py	Centralizes transport I/O and family resolution.
src/lerobot/motors/feetech/feetech.py	Adapts Feetech behavior to raw transport bytes.
src/lerobot/motors/dynamixel/dynamixel.py	Adapts Dynamixel behavior to rustypot.
src/lerobot/motors/dynamixel/tables.py	Extracts the model-number address.
src/lerobot/utils/import_utils.py	Removes vendor SDK availability flags.
src/lerobot/robots/so_follower/so_follower.py	Uses automatic bus selection.
src/lerobot/robots/omx_follower/omx_follower.py	Uses automatic bus selection.
src/lerobot/robots/lekiwi/lekiwi.py	Uses automatic bus selection.
src/lerobot/robots/koch_follower/koch_follower.py	Uses automatic bus selection.
src/lerobot/robots/hope_jr/hope_jr_arm.py	Uses automatic bus selection.
src/lerobot/robots/hope_jr/hope_jr_hand.py	Retains explicit protocol-specific construction.
src/lerobot/teleoperators/so_leader/so_leader.py	Uses automatic bus selection.
src/lerobot/teleoperators/openarm_mini/openarm_mini.py	Uses automatic bus selection.
src/lerobot/teleoperators/omx_leader/omx_leader.py	Uses automatic bus selection.
src/lerobot/teleoperators/koch_leader/koch_leader.py	Uses automatic bus selection.
tests/motors/test_motors_bus.py	Tests shared I/O and factory behavior.
tests/motors/test_feetech.py	Tests Feetech-specific encoding and calibration.
tests/motors/test_dynamixel.py	Tests Dynamixel-specific behavior.
tests/mocks/mock_motors_bus.py	Adds an in-memory transport fake.
tests/mocks/mock_feetech.py	Removes packet-level Feetech mocks.
tests/mocks/mock_dynamixel.py	Removes packet-level Dynamixel mocks.
tests/robots/test_so100_follower.py	Patches the new bus factory.

Review details

• Files reviewed: 26/27 changed files
• Comments generated: 6
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ravediamond]

Community review

Tested this branch on a real SO-101 (follower + leader, Jetson Orin NX, aarch64, Python 3.12, rustypot 1.10.0) and compared against main with the same scripts and calibration.

Read-only, same arm and pose on both:

• scan_port: ids 1-6, model 777 on both. 14.2 s on this PR, 16.1 s on main.
• Raw Present_Position identical: 2030 / 852 / 3065 / 2844 / 2013 / 2066. Normalized identical too (e.g. shoulder_lift -102.99).
• Min/Max_Position_Limit, Homing_Offset and Phase (12) identical.
• sync_read x200: mean 0.92 ms on the PR, 1.00 ms on main (p95 0.99 vs 1.00), so no regression.

Through the real scripts, on the PR:

• SOFollower.connect() + configure(): torque 1 on all six, position unchanged after 2 s, Torque_Enable 0 after disconnect().
• lerobot-teleoperate, 20 s with the leader at 30 fps: loop stayed at 33.40 ms, no errors, clean exit, torque 0 afterwards.
• lerobot-record, 2 episodes of 8 s with a reset in between: 480 frames, 29.94 Hz measured, 0/478 ticks over the 33.3 ms budget (work mean 2.1 ms, worst 2.4 ms). Torque 0 afterwards.

Everything above works on the SO-101 with this PR, no regression compared to main.
I only tested the SO-101 (Feetech), so I can't speak for the other motor families.

[nicolas-rabault]

Updated, in four commits on top of the reviewed ones:

• b0c67a0 rustypot 1.11.0, and a serial-motors extra that feetech and dynamixel now alias.
• 498e3f2 SerialMotorsBus is now the one bus for both families. rustypot 1.11.0 states what told them apart (homing offset sign, operating mode values, drive mode register, Feetech lock), so FeetechMotorsBus and DynamixelMotorsBus become deprecated aliases for one release. The same commit carries the review fixes: exact model number check, a 50 ms timeout instead of 1 s, torque turned off on every motor even when one fails, motor search and setup through rustypot (broadcast ping, fixed baud rate order, ID and baud rate written by rustypot), and the port always released or restored.
• 79860bc every Feetech and Dynamixel robot and teleoperator builds a SerialMotorsBus and names its operating modes (set_operating_mode("position")).
• 4184107 docs.

The description lists every behaviour and API change. Each commit passes tests/motors, tests/robots, tests/teleoperators and tests/test_control_robot.py, and pre-commit. The SO-101 runs, including the community review above, predate the bus merge, and nothing Dynamixel has run on hardware yet, so tests on Koch or OMX would help.

[Sjeongheon]

Hi, I ran into an intermittent calibration write failure on an SO-101 / Feetech STS3215 and was looking through the related motor-bus work when I found this refactor.

On LeRobot v0.6.0, calibration would intermittently fail on persistent register writes with errors like:

Failed to write 'Min_Position_Limit' on id_=3 with '880' after 1 tries.
[TxRxResult] There is no status packet!

I saw this repeatedly enough that it prevented calibration from completing reliably.

What was interesting was that after one of these failures, I immediately read the calibration registers back and found that the write reported as failed had actually been applied.

At that point the range-limit state was roughly:

ID1: Min / Max applied
ID2: Min / Max applied
ID3: Min = 880 applied
     Max still unchanged
ID4-ID6: range limits not updated yet

(Homing_Offset is not useful for showing the progress of this particular write_calibration() step because those offsets had already been written earlier in the calibration flow.)

So at least on the STS3215 I tested, this sequence appears possible:

write reaches the servo
-> persistent register is updated
-> status reply is lost
-> host reports the write as failed
-> write_calibration() aborts

This leaves a partially applied calibration even though the failed write itself may already be stored on the servo.

As a local workaround, I changed the calibration write path so that on a communication failure it reads the same register back before deciding that the write failed:

try:
    write(register, motor, value)
except ConnectionError:
    readback = read(register, motor)

    if readback == value:
        # The write was applied; only the reply appears to have been lost.
        continue

    raise

With that verification in place, I was able to complete calibration despite the intermittent missing status replies.

I also tried writing the same register/value repeatedly, running Homing_Offset -> Min_Position_Limit -> Max_Position_Limit repeatedly, and running the sequence across all six motors. Those later tests completed successfully, so I could not tie the failure to a specific register, value, or simply to consecutive EEPROM writes.

I have also tested the current #4672 branch on the same STS3215 hardware, but I have not been able to reproduce the failure again so far. Since the original issue was intermittent, I don't know whether the rustypot backend changes its occurrence rate.

However, looking at the current write path, my understanding is that a communication failure is retried by issuing the write operation again. Unless I am missing another verification mechanism, the semantic ambiguity still seems possible: after a lost status reply, the caller does not know whether the write failed or whether it succeeded and only the reply was lost.

I also noticed that #4695 deliberately kept torque-register readback / write semantic changes out of scope, so I am not assuming this necessarily belongs in this PR.

Would you prefer this kind of verification to be handled here in the new serial write path, in write_calibration() as a follow-up, or possibly lower in rustypot?

For persistent readable configuration registers, readback-after-communication-failure worked well as a practical workaround for me.

I have only observed the write-applied / reply-lost behavior on Feetech STS3215 hardware; I have not tested the same failure mode on Dynamixel.

[nicolas-rabault]

Ran the bus merge on hardware: two more SO-101 arms (six STS3215 each, firmware 3.10, 1 Mbps), driven through SerialMotorsBus at 8d35116.

• Handshake (exact model numbers, one firmware) passes on both; read_calibration returns the same homing offsets and limits as reading the registers through rustypot directly.
• sync_read of the six positions: p50 1.00 ms, p99 1.09 and 1.22 ms over 300 reads.
• disable_torque on the six motors: 4.7 to 5.5 ms.
• setup_motor("gripper", initial_baudrate=1_000_000, initial_id=6), which rewrites the id and rate it already has, then reads the model number back: passes in 3 to 4 ms.
• setup_motor for a model that is not on the bus (an XL330): the search walks every XL330 baud rate, fails after 10 s, and the port is back at 1 Mbps (the next read answers).

Not covered yet: calibration and teleoperation on these arms, and anything Dynamixel.

[s1lent4gnt]

Thanks @nicolas-rabault, this is an exciting step for LeRobot. Consolidating Feetech and Dynamixel under SerialMotorsBus eliminates duplicate SDK code and control tables by offloading that logic to rustypot. It sets a much cleaner foundation for our current motor support and future arm integrations. Excited to see this land on main, approved, great work!