Robot #3 · Hiwonder TonyBot
The complete record, including the three wrong turns — because the wrong turns cost the most time, and the next robot will offer the same ones.
Robot #3 came in with a bent right foot. This is what was actually wrong and what was done about it.
Repair summary
The robot's right foot sat at the wrong angle whenever it was switched on, and adjusting the settings did not fix it.
The fault was inside the motor that tilts the right ankle. A part had come loose, so the motor could still move the foot but could no longer hold it in place. Under the robot's own weight the foot slipped out of position.
This is why adjusting the settings never worked: a joint that cannot hold any position cannot hold a corrected one either. The problem was mechanical, not a setting.
The robot walks. Two joints in the arms do not report their status back to the computer, but both move normally and this does not affect how the robot is used. They are noted for a simple cable check.
The ankle repair reattached the original part rather than replacing it. That is a sound fix, but the joint carries a lot of force when the robot walks, so it is worth watching. If the foot drifts out of position again after a few sessions of use, that joint will need a replacement motor — an inexpensive part.
We also need to confirm the exact motor model fitted to these robots before ordering spares, as the part found inside did not match the published specification.
Outcome
| Servo | Joint | Finding | Status |
|---|---|---|---|
| 2 | Right ankle, forward/back | Output gear loose on the drive shaft — drove the joint but could not hold it. Rear shaft and bearing sound. Gear rebonded, bracket re-clocked, recalibrated to +6. | Repaired |
| 6 | Elbow, side A | Moves normally, does not answer Read Servo Deviations. | Cable |
| 15 | Shoulder out/in, side B | Same as 6 — drives fine, won't report back. | Cable |
The reported symptom was misleading. "The foot is bent after calibrating" points at calibration. But a servo that cannot hold a position cannot hold a calibrated position either — the fix was never going to be in software, and every minute in the deviation sliders was wasted until the health test in Gate 4 caught it.
The paper manual covers assembly, charging and getting the robot moving — nothing on diagnostics, servo IDs, or what to do when a joint misbehaves.
Scanned the QR code in the manual, installed the Hiwonder app, selected TonyBot, and ran the built-in poses to see what still worked.
The app plays pre-recorded actions only. No calibration screen, no servo list, no diagnostics. It confirms the robot powers up and the bus broadly works — that is the limit. Every real diagnostic step needs the PC software.
The first documentation found was for the TonyPi — a visually similar humanoid that is an entirely different machine underneath.
# Wrong product — Raspberry Pi based
https://docs.hiwonder.com/projects/TonyPi/en/latest/
# Correct product — ESP32 based
https://wiki.hiwonder.com/projects/Tonybot/en/latest/Everything derived from it had to be discarded: Wi-Fi hotspots, SSH as pi, VNC, wifi_conf.py. None of it exists on a TonyBot.
Looking for the Raspberry Pi's micro-HDMI ports and finding only USB Type-C. The hardware did not match the documentation, and the documentation was what was wrong.
The resources page has every link. The blocker: Bus Servo Control V3.5 is Windows-only and the bench machine was a MacBook.
| Route | Verdict |
|---|---|
| Boot Camp (Intel Mac) | Best if available — native, free, USB serial simply works |
| Parallels (Apple Silicon) | Workable; 14-day trial covers a repair job |
| UTM | Free, but USB passthrough is fiddly — and that is the part that must work |
| Wine / CrossOver | Rejected — serial port access unreliable |
A Windows PC became available. Worth arranging one before starting a batch rather than fighting a VM per robot.
Read failures reported on 6, 15, and everything from 17 to 40.
The robot has sixteen servos. 17–40 do not exist — the software polls past the robot's range. Only 6 and 15 were real.
Knowing which IDs failed was useless without knowing where they were. No Hiwonder page maps servo IDs to joints, so it was derived by testing: nudge one servo, watch which joint twitches, record, repeat. Result on the servo map.
Servos 6 and 15 are both in the arms — nowhere near the right foot. The robot had two unrelated problems, and the loud one was not the real one. It also gave the mirror-twin rule, which made every later test a comparison rather than a judgement call.
| Test | Servo 2 (R ankle) | Servo 10 (twin) |
|---|---|---|
| Answers Read | Yes | Yes |
| Moves on command | Yes | Yes |
| Holds against a push | No — loose, and only at certain angles | Locked solid |
| Motor sound while driving | Silent | Faint hum |
A servo with stripped gears normally still buzzes. Complete silence beside a humming twin meant the motor was not driving the output at all.
Disassembly confirmed it: the output gear had come loose on the metal drive shaft. Rear shaft and bearing sound. That explains every symptom — the motor drives the train, the loose gear slips at the output, so the joint can be pushed into position but never holds one.
The servo was identified as the LX-824HV, specified with brass gears. The failed gear here is plastic. Read the model number off the servo body before ordering anything.
The gear was rebonded. An adhesive joint has no teeth, so the gear can land at any angle — and this one landed roughly 120° out. The foot only looked level at position 0, the extreme end of travel, leaving no movement in one direction.
The foot bracket was lifted off the splined horn and rotated to bring centre back to 500. Reversible, and always the right move before re-doing a bond. Arithmetic on the calibration page.
With the mechanics close, the remaining degrees should have been deviation work. Instead the position slider was being adjusted and Downloaded, and the robot reverted on every power cycle.
POSITION 0 – 1000 where to go now NOT saved
DEVIATION -100 – +100 permanent correction saved by DownloadThe reported values — 365 and 620 — gave it away. Deviation cannot exceed 100, so three-digit numbers can only have come from the position column. That reading also measured the remaining mechanical error: level at 365 against a centre of 500 is 135 units, about 32°, roughly two more teeth.
1 ankle side 0 9 ankle side +2
2 ankle fwd +6 10 ankle fwd -9
3 knee -40 11 knee -18 <-- see below
4 hip fwd -34 12 hip fwd +36
5 hip side +1 13 hip side +1
6 elbow +12 14 elbow -1
7 shoulder out/in +11 15 shoulder out/in -4
8 shoulder up/dn -55 16 shoulder up/dn +40The repaired ankle at +6 is a good result — the mechanical work landed close enough that deviation barely had to do anything.
Mirrored joints normally read roughly equal and opposite. The hips do (-34 / +36) and so do the shoulders (-55 / +40). The knees do not: -40 / -18, same sign and 22 apart. Both knees biased the same way bends the body forward, matching the slight forward lean seen while walking. Unconfirmed — the check is to command everything to 500 and look at the knees from the side.
The mirror-opposite convention is inferred from this robot's own numbers across three pairs, not from Hiwonder documentation. Suggestive, not proven.
Left open on Robot #3
| Item | Status |
|---|---|
| Servos 6 and 15 not answering Read | Cable swap against their mirror twins. Joints work, so deprioritised. |
Knee pair -40 / -18 | Side-view check at 500. Suspected cause of the forward lean. |
| Glued gear on servo 2 | Watch for drift over several walking sessions. A bond carrying full torque in shear is expected to be temporary. |
| Actual servo model unknown | Read the number printed on the body. Needed before ordering spares for the batch. |