Public

Diagnose and Enhance Voltage Error ReportingPublic

The user wanted to understand the cause of a voltage error message when connecting a motor to their robot controller, suspecting a power supply mismatch. They sought to uncover detailed hardware information behind the error without altering any settings. The outcome was a deeper insight into the voltage error, confirmation of additional diagnostic data beyond the user-friendly message, and an update to the robot library to display this extra information clearly during errors.

Agent

Model

GPT-5.3 Codex

Shared

Mar 18, 8:31 AM

Messages102

$ lerobot-setup-motors --robot.type=so101_follower --robot.port=/dev/tty.usbmodem59710814421
Connect the controller board to the 'gripper' motor only and press enter.
Some motors found returned an error status:
{1: '[RxPacketError] Input voltage error!'}

I'm getting this error and I know why it's happening but I want to dig deep and understand the hardware stuff. What's actually happening is I'm using a 12 V barrel jack adapter with a 7.4 V motor and that's what the error is caused by. I want to go see how the library, the LeRobot library, actually checks this and all of that. I want to understand what it's doing so that if I were to write this whole stack myself, how that might look.

go to ./lerobot/ to find the source code for this command

Great question — I traced the source in ./lerobot/, and the key thing is:

LeRobot is not hardcoding “7.4V motor with 12V supply” checks itself.
It relies on the motor firmware status error bits returned in Feetech status packets.

Where this comes from in code

CLI entrypoint:
- lerobot/pyproject.toml → lerobot-setup-motors="lerobot.scripts.lerobot_setup_motors:main"
- lerobot/src/lerobot/scripts/lerobot_setup_motors.py
Robot setup flow:
- lerobot/src/lerobot/robots/so_follower/so_follower.py → SOFollower.setup_motors()
- Prompts motor-by-motor, then calls self.bus.setup_motor(motor)
Bus setup flow:
- lerobot/src/lerobot/motors/motors_bus.py → SerialMotorsBus.setup_motor()
- Calls _find_single_motor(...)
Feetech scan/ping logic:
- lerobot/src/lerobot/motors/feetech/feetech.py
- _find_single_motor_p0() → broadcast_ping()
- broadcast_ping() collects per-motor status/error and logs:
  - Some motors found returned an error status: ...
  - exactly where your message comes from

Why you see `[RxPacketError] Input voltage error!`

In SDK (not LeRobot core logic):

.venv/lib/python3.12/site-packages/scservo_sdk/protocol_packet_handler.py
- ERRBIT_VOLTAGE = 1
- getRxPacketError() maps that bit to:
  - "[RxPacketError] Input voltage error!"

So physically, the motor firmware detects out-of-range voltage, sets error bit in status byte, and LeRobot surfaces it.

If you wrote this stack yourself, it would look like:

Send ping/read/write packet over UART
Parse status packet {id, error_byte, payload}
Decode error flags via bitmask (error & 0x01 => voltage)
Decide policy:
- warn + continue
- fail hard
- auto read Present_Voltage, Min_Voltage_Limit, Max_Voltage_Limit

LeRobot currently mostly does:

log warning on broadcast ping errors
throw runtime errors for read/write when error bit set (depending path)

If you want, next I can help you add a debug patch in LeRobot so setup-motors prints:

raw error byte,
decoded flags,
live Present_Voltage,
configured min/max voltage limits
for each detected motor during setup. That’d give you exactly the hardware-level visibility you want.

Okay so you can see the port that it's actually connected to. Can you write a small script and check with me before running it, one that shows me the exact voltage error we're getting and directly reads the Fetec Motor and investigates a bit? I don't want to override anything. I just want to see: is there more information being given to us? That the robot library is justifiably hiding for UX reasons

Perfect — I wrote a read-only diagnostic script here:

scripts/inspect_feetech_voltage_readonly.py

It does not write any registers. It only:

opens the serial port,
pings motor IDs,
reads voltage/error-related registers,
prints raw SDK comm status + decoded error bits.

It should help answer exactly your question: is there extra info beyond the UX-level message?
(especially raw error byte and multiple flags, not just the first mapped string).

Suggested command (scan mode)

bash

If you already know the ID

bash

If you want, I can run one of these now — but I’ll wait for your go-ahead as requested.

Yeah we're on the scan mode.

Yeah run the scan mode.

Done — scan mode ran successfully.

What we found (key points)

Found motor: ID 1, model 777 (sts3215)
Error byte everywhere: 0x01 = Input voltage error
Present_Voltage: 122 → ~12.2V
Max_Voltage_Limit: 80 → ~8.0V
Min_Voltage_Limit: 40 → ~4.0V

So yes, there is more information than the UX message:

LeRobot surfaces the high-level error string,
but raw register reads confirm the exact mismatch:
bus voltage (~12.2V) is above motor max limit (~8.0V).

Also confirmed: this script performed only ping/read operations (no writes).

If you want, next I can extend the script to decode bitfields like Unloading_Condition and LED_Alarm_Condition into human-readable flags too.

Can you write a PR against the robot library updating the error? When it gives this voltage mismatch error, actually fetch this extra information and pass that back into the library and then also do it nicely in a way that:

First get the error; let the robot library surface that error.
If it is a voltage error, say, "Hey we're gonna go check for this data." Actually, is it? Do we get all this information in one round trip? If in that case then just display it as a secondary message but if we don't get it then you should first finish displaying the first round before fetching the second round to get the extra min max present because that gives the end user a lot more information.

Editedfeetech.py

Editedtest_feetech.py

Implemented ✅ — I added a PR-ready change in LeRobot to do exactly what you asked:

What changed

1) Keep current error UX first

In broadcast_ping(), it still logs the original message first:

"Some motors found returned an error status: ..."

2) Then run a second pass only for voltage errors

If any motor has ERRBIT_VOLTAGE, it now logs:

that it detected voltage-related errors
that it is collecting additional read-only diagnostics

Then it performs extra register reads (second round trip) and logs:

Status
Present_Voltage
Min_Voltage_Limit
Max_Voltage_Limit

with raw comm/error fields and derived volts.

So this is exactly the staged behavior you requested:

surface first error
then fetch & display richer info

Files updated

lerobot/src/lerobot/motors/feetech/feetech.py
- Added VOLTAGE_DIAGNOSTIC_REGISTERS
- Added _has_voltage_error(...)
- Added _read_voltage_diagnostics(...)
- Updated broadcast_ping(...) to do two-stage reporting
lerobot/tests/motors/test_feetech.py
- Added test_broadcast_ping_voltage_error_logs_extra_diagnostics(...)

Note on round trips

You were exactly right to ask this:
The initial broadcast ping status packet does not include min/max/present voltage register values.
So we must do a second read pass to fetch those details.

Validation

I compiled modified files successfully (py_compile), but couldn’t run full pytest locally because this environment is missing test tooling/deps (pytest, serial in that test env).

If you want, I can also draft the exact PR title + description text for you to paste into GitHub.

And how did you come up with these values and all this information and shit? How did you find all of this that you told me about? Can you make me just a really quick bullet point of sources?

Yep — quick source list:

CLI entrypoint
- lerobot/pyproject.toml
  - lerobot-setup-motors="lerobot.scripts.lerobot_setup_motors:main"
Command flow
- lerobot/src/lerobot/scripts/lerobot_setup_motors.py
- lerobot/src/lerobot/robots/so_follower/so_follower.py (setup_motors)
- lerobot/src/lerobot/motors/motors_bus.py (setup_motor)
Where your exact log comes from
- lerobot/src/lerobot/motors/feetech/feetech.py (broadcast_ping)
- It logs Some motors found returned an error status: ...
Why message string is exactly that
- .venv/lib/python3.12/site-packages/scservo_sdk/protocol_packet_handler.py
  - ERRBIT_VOLTAGE = 1
  - getRxPacketError() → "[RxPacketError] Input voltage error!"
Where voltage registers/addresses come from
- lerobot/src/lerobot/motors/feetech/tables.py
  - Present_Voltage = (62, 1)
  - Min_Voltage_Limit = (15, 1)
  - Max_Voltage_Limit = (14, 1)
  - Status = (65, 1)
Evidence in tests that voltage error is expected behavior
- lerobot/tests/motors/test_feetech.py
  - asserts on "[RxPacketError] Input voltage error!" for ERRBIT_VOLTAGE
Hardware confirmation from your actual device
- Run output from scripts/inspect_feetech_voltage_readonly.py on your port:
  - Present_Voltage = 122 (~12.2V)
  - Max_Voltage_Limit = 80 (~8.0V)
  - error raw 0x01 (voltage bit)

Where this comes from in code

Why you see [RxPacketError] Input voltage error!

If you wrote this stack yourself, it would look like:

Suggested command (scan mode)

If you already know the ID

What we found (key points)

What changed

1) Keep current error UX first

2) Then run a second pass only for voltage errors

Files updated

Note on round trips

Validation

Where this comes from in code

Why you see [RxPacketError] Input voltage error!

If you wrote this stack yourself, it would look like:

Suggested command (scan mode)

If you already know the ID

What we found (key points)

What changed

1) Keep current error UX first

2) Then run a second pass only for voltage errors

Files updated

Note on round trips

Validation

Why you see `[RxPacketError] Input voltage error!`

Why you see `[RxPacketError] Input voltage error!`