A biped whose computer is a phone
PhoneBot, from UCLA’s Robotics and Mechanisms Laboratory, is a small biped that reuses an Android phone as its main sensor and computer. The authors are Ruochen Hou, Quanyou Wang, Daniel Koh and Dennis W. Hong. The preprint is arXiv:2610.08737, submitted on 6 October 2026. The project page is phonebot.dev. [1] [2]
UCLA researchers built PhoneBot, a 48 cm robot with 13 motorized joints. The phone handles vision and walking control. Hardware costs around $400, excluding the phone.
The post’s summary matches the paper’s headline numbers. The useful part is the split underneath them: the phone does not pulse the motors directly, the policy is a flat-ground walk, and “humanoid” here does not include arms. [1]
Thirteen servos and a phone on the torso
| Item | Stated figure | Scope |
|---|---|---|
| Height | 0.48 m | Specification table |
| Mass | 1.8 kg | Includes the phone |
| Actuated joints | 13 | Six per leg, plus torso yaw |
| Actuator | Dynamixel XL430-W250-T | Stall torque stated at 1.4 N·m |
| Hardware cost | About $400 | Phone excluded |
| Action rate | 50 Hz | Joint-position residuals |
Each leg has hip yaw, hip roll, hip pitch, knee pitch, ankle pitch and ankle roll. Torso yaw is the thirteenth joint. The paper gives the XL430-W250-T a no-load speed of 57 rpm, a mass of 57.2 g and a gear ratio of 258.5:1. Stall torque of 1.4 N·m is the limit the authors then put into the simulator. A robot this light can walk. It cannot be assumed to carry a payload or to swing an arm it does not have. [1]
The phone decides, a second board moves the joints
The phone reads its IMU and camera, runs the walking policy in TensorFlow Lite, and handles on-device vision with ML Kit and MediaPipe. A small single-board computer receives joint-position commands and talks to the Dynamixel bus. The link is Wi-Fi UDP in both directions. The paper says there is no electrical data connection between the phone and the rest of the robot. Commands and joint telemetry share that wireless hop. [1]
Some speech-to-text, language-model and text-to-speech features are described as backend calls over Wi-Fi, not as part of the 50 Hz walking loop. A walk can be an on-phone policy. A conversation in the same app may leave the phone. Those are different autonomy claims, and the paper’s contribution list keeps them apart. [1]
The action is a 13-dimensional residual on joint position, added to a gait. Observations include a noisy IMU, joint position and velocity relative to a home pose, and a gait phase. Training used torque-aware MuJoCo and MJX models that saturate the XL430, and an asymmetric actor-critic PPO. Sagittal mirroring, which feeds a mirrored batch into the update, is there to stop the gait becoming left-right lopsided under the torque limit. [1]
What the experiments report
In simulation, the paper compares training with and without that mirroring, across five seeds. With mirroring, it reports a joint-angle symmetry error of 0.003 rad against 0.254 rad without, a left-right torque imbalance of 0.034 against 0.205, and a mechanical-power imbalance of 0.040 against 0.339. The deterministic check is a 0.5 m/s forward command held for 20 seconds, on flat ground, in 256 environments. Those numbers are about symmetry of a simulated gait, not about a distance walked in a hallway. [1]
On hardware the authors show walking, following a person, and standing up from a face-down pose. The get-up policy is trained toward a standing height they denote z* = 0.282 m. The paper does not publish how many physical trials were run or how many failed. Four phones ran the app: a 2017 Honor 9, a moto g 2025, a Galaxy A16 5G and a moto g 2024. ARCore tracking is described as unavailable on the Honor 9 because Google services are missing, while the other three could use it. IMU sensing and policy inference are reported on all four. [1]
Flat ground, no arms
Locomotion policies were trained on flat terrain. The conclusion says the platform lacks arms, and that the servo torque limits payload and faster motion. Uneven ground and language-model task planning are listed as future work. A clip of a get-up on a lab floor does not establish outdoor walking, stairs, or any manipulation. [1]
Where this architecture breaks
- Wi-Fi loss between the phone and the motor board stops new position commands even if the policy is still running.
- A torque limit of 1.4 N·m leaves little margin once the robot holds a pose far from the trained gait.
- Person following uses the phone camera. If the torso yaw cannot keep the person in frame, the detector has nothing to track.
- A phone that cannot run ARCore can still walk. It should not be described as running the same mapping stack.
Training a walk in simulation, and the measurements that should follow, is a separate guide. Train a humanoid walk in simulation
Sources and verification
- PhoneBot: A Low-Cost Open Humanoid Robot Platform Reusing Smartphones ↗Ruochen Hou, Quanyou Wang, Daniel Koh and Dennis W. Hong, UCLA RoMeLa · Read 13 October 2026
arXiv:2610.08737, submitted 6 October 2026. The HTML version at arxiv.org/html/2610.08737v1 was read for hardware, the 50 Hz action loop, phone split, symmetry figures and stated limits. Project page: https://phonebot.dev.
- Post on PhoneBot ↗TechniaHQRobot on X · Read 13 October 2026
Post text checked. Numbers in the article come from the paper, not from the caption alone.
Evidence limits
- Hardware walking, following and get-up sequences are shown. The paper does not give a trial count or a success rate for those sequences.
- Inference time on each phone is not restated here beyond the split of work.
- Code and CAD are described as open. A specific archive URL was not verified beyond the project page named in the paper.
Article history
Added the paper’s hardware split, flat-ground limit, symmetry comparison and the original post.
Report a correction