A bipedal humanoid robot that walks, recovers from falls, follows people by camera, and understands speech commands can now be built for under $400 in hardware — using an Android phone priced at $50 to $80 as its sensor array, processor, radio, and display simultaneously. UCLA’s Robotics and Mechanisms Laboratory has open-sourced full hardware designs, aiming to put humanoid locomotion research within reach of programs, educators, and individuals who have been priced out of the field.

The platform, called PhoneBot, was published as an arXiv preprint on October 6 by RoMeLa researchers Ruochen Hou, Quanyou Wang, Daniel Kohl, and Professor Dennis Hong, and drew international robotics press coverage this week from outlets including New Atlas and Interesting Engineering. The cost gap it represents is stark: the closest comparable open-source bipedal research platform costs $3,500, and the most widely used academic competition humanoid runs to $13,800. PhoneBot’s ~$400 build cost — excluding the phone — puts an otherwise inaccessible class of hardware within a university club’s budget.

Five Subsystems, One Pocket-Sized Device

Building a small research humanoid typically requires sourcing and integrating five or more separate subsystems: a depth camera or stereo rig for vision, an inertial measurement unit for balance sensing, a single-board computer for inference, a wireless radio for remote operation, and a touchscreen or speaker for interaction. Each component adds cost, wiring complexity, and potential failure points. As the PhoneBot paper documents, open-source bipedal platforms comparable in capability range from roughly $3,500 to $13,800 — a cost that effectively locks many university programs and most individual researchers out of the field entirely.

PhoneBot’s answer is architectural: one commodity Android smartphone replaces all five subsystems at once. The phone’s rear camera handles vision. Its built-in IMU—the same chip that determines screen orientation and tracks motion in fitness apps—provides the real-time orientation and angular velocity data stable bipedal walking requires.

The phone’s application processor runs the neural-network locomotion controller and on-device vision models at 50 Hz. Its Wi-Fi radio handles all communication. Its touchscreen and speaker handle interaction. One piece of consumer hardware, priced for the prepaid market, replaces a subsystem bundle that would cost hundreds of dollars even purchased at academic pricing.

What PhoneBot Is

PhoneBot stands 483 millimeters (19 inches) tall and weighs 1.8 kilograms (4 pounds) including its phone and battery — roughly the size and weight of a large house cat. It carries 13 servo motors: six joints in each leg (hip, knee, and ankle, with three axes of rotation at the hip), plus a single torso-yaw joint that allows the phone’s camera to track a person without pivoting the entire robot. The servos are Dynamixel XL430-W250-T units, a standard academic robotics component available on the open market.

The phone itself sits in the torso above the hips but does not connect directly to the motors. Instead, it communicates over a local Wi-Fi UDP link to a small single-board computer (SBC) housed in the lower body, which translates its joint-angle commands into the serial signals the Dynamixel bus requires. That wireless indirection is a deliberate engineering choice: it makes the phone swappable without touching the robot’s electronics, treating a component that will be upgraded or replaced as an interchangeable peripheral rather than a permanent part of the hardware stack.

How Does PhoneBot Learn to Walk?

Bipedal locomotion is not a motion that can be reliably hand-coded — the physics of an inverted pendulum walking on two legs is too sensitive to small perturbations and hardware tolerances. PhoneBot’s locomotion controller was instead trained using reinforcement learning in simulation: a virtual robot in the MuJoCo/MJX physics engine earned reward for maintaining forward speed, alternating its steps correctly, and staying upright, and lost reward for dragging its feet, consuming excessive energy, or falling.

The specific algorithm is an asymmetric actor-critic variant of Proximal Policy Optimization (PPO), a training approach in which the critic — used only during training — has access to privileged simulator information (precise foot contact states, exact velocities) that the deployed policy does not. This asymmetry lets the training process guide the policy with richer information than the phone can actually observe, producing a more capable policy without increasing the inference requirements on the phone at runtime.

Crucially, the simulation was parameterized to match the real hardware’s actual limitations: servo torque ceilings, maximum speeds, and gear-train backlash were explicitly modeled, and their values were randomized during training — a technique called domain randomization — so that policies robust to variation in simulation would also transfer to variation in real hardware. The final policy runs on the phone via TensorFlow Lite at 50 Hz, issuing a fresh set of 13 joint-angle targets every 20 milliseconds.

Sagittal Mirroring: A Fix for Every Low-Cost Biped

One of the paper’s most transferable contributions addresses a problem every developer of a low-cost, RL-trained biped eventually encounters: the real robot walks crooked, even when the simulation robot walks straight. The cause is manufacturing tolerance. Real servo motors are not perfectly symmetric — a left-leg motor and a right-leg motor rated to identical specifications will have slightly different stall torques, gear ratios, and friction characteristics. A policy trained on a perfectly symmetric simulated robot inherits none of this asymmetry, and the mismatch shows up as a bias in the real robot’s gait.

RoMeLa’s solution, which the paper calls sagittal mirroring, addresses this during training rather than during hardware calibration. After each training gradient step, the policy’s parameters are averaged with a left-right mirrored version of itselfthat has been left-right mirrored —forcing the policy to behave well in both the original and the mirror image of the robot. The effect is to train a policy that cannot be asymmetric by construction.

The results are quantified. Without mirroring, PhoneBot’s trained policy produced a joint-angle symmetry error of 0.254 radians between left and right legs and a left-right torque imbalance of 0.205 newton-meters. With mirroring, the symmetry error dropped to 0.003 radians — a 98.8 percent reduction — and the torque imbalance fell to 0.034 newton-meters, an 83.4 percent improvement. Power asymmetry dropped from 0.339 watts to 0.040 watts.

This technique is not specific to PhoneBot’s hardware. Any RL-trained bipedal robot whose locomotion policy is learned in symmetric simulation and deployed on physically asymmetric hardware faces the same problem—that is, virtually every low-cost research biped in the field. The sagittal mirroring result is a reusable methodology contribution to that broader class of platforms, published in a form other builders can apply directly.

Which Phone? Any of These

The researchers tested PhoneBot with four different Android devices to verify that the platform generalizes across hardware. Three were current prepaid consumer phones purchased for between $50 and $80: a moto g 2025 (~$50), a Samsung Galaxy A16 5G ($50–$80), and a moto g 2024 (~$50). The fourth was a 2017 Honor 9, included to probe the limits of older or less mainstream hardware.

All four devices handled the core functions: balance sensing and locomotion control via TensorFlow Lite, on-device human detection via ML Kit and MediaPipe, and speech interaction. The lone exception was the Honor 9’s inability to run PhoneBot’s simultaneous localization and mapping (SLAM) feature, which relies on ARCore — Google’s augmented-reality framework. The Honor 9 cannot access Google services in the United States, which is a distribution restriction rather than a processing limitation. Every function that does not depend on Google services ran without issue on the nine-year-old device.

The paper cautions that testing four models does not guarantee compatibility across the full Android device ecosystem, but the range tested — from a nearly decade-old flagship to current sub-$100 hardware — supports the architecture’s design intent: the phone is a replaceable component, not a fixed specification.

Open-Source Lineage: From OpenBot to the Competition Floor

PhoneBot did not invent the idea of using an Android phone as a robot’s primary computer. OpenBot, a project from Intel Labs published in 2020, developed and validated that concept at scale, showing that commodity Android phones could serve as fully capable controllers for small wheeled mobile robots. OpenBot showed that a phone provides sufficient CPU, GPU, camera, IMU, and wireless connectivity in one device to drive a robot—and it triggered a generation of research building on that architecture.

PhoneBot extends that architecture to the significantly harder problem of bipedal locomotion. A wheeled robot is statically stable: its center of mass is always above its support polygon, and it does not fall over if the controller pauses or makes a poor decision. A biped must actively manage dynamic balance through every step cycle, which imposes real-time constraints on the controller that a wheeled platform does not face. Demonstrating that phone-class hardware can satisfy those constraints — at 50 Hz, across varied phone hardware, including fall recovery — is the substantive extension.

RoMeLa’s own open-source tradition runs deep. DARwIn-OP, jointly developed with Virginia Tech with NSF support, became a standard competition platform at RoboCup’s Humanoid League and the technical foundation for the ROBOTIS OP commercial series. RoMeLa teams using DARwIn-OP derivatives earned multiple RoboCup world championship titles. ARTEMIS, the lab’s full-size humanoid, won the Adult-Size championship at RoboCup 2024 in Eindhoven, Netherlands, making RoMeLa a six-time world champion. PhoneBot targets a different point in the cost-capability spectrum — one designed not for competition performance but for maximum accessibility.

Professor Hong, who founded RoMeLa and whom the Washington Post described as “the Leonardo da Vinci of robots,” has given a TED Talk on robot locomotion and consistently oriented the lab’s open-source releases around democratizing access to advanced robotics research. PhoneBot continues that orientation, applying it to the current moment’s defining bottleneck: not capability, but cost.

What PhoneBot Cannot Do Yet: Current Limits and the Road Ahead

The PhoneBot paper is candid about three meaningful limitations. First, the robot has no arms. In bipedal locomotion, arms provide angular-momentum compensation during turning and disturbance recovery; without them, the platform is more vulnerable to pushes and can execute fewer gaits stably. Second, we trained and validated the locomotion policy exclusively on flat terrain. Stairs, ramps, and outdoor surfaces are outside the current envelope. Third, the robot’s conversational AI — speech recognition on the phone, language model response generation — currently routes language model inference through external laptop over Wi-Fi rather than running entirely on the phone.

Each of these gaps has a planned path forward in the paper’s stated roadmap. Lightweight arms are on the near-term list. Terrain adaptability will require extending the RL training to include varied surface randomization, which is a straightforward extension of the existing pipeline. On-device LLM inference — running the full conversation stack locally on the phone — is explicitly listed as a near-term goal, and the current generation of on-device AI inference chips (Snapdragon, Dimensity, and their NPU accelerators) makes it technically plausible in a way that would not have been true even two years ago.

The full hardware designs, firmware, and software stack for PhoneBot are available at phonebot.dev.

Frequently Asked Questions

How much does it cost to build a humanoid robot?

PhoneBot can be built for approximately $400 in hardware, not including the phone. The phone itself — tested using devices priced between $50 and $80 — brings the total to roughly $450 to $480. For comparison, comparable open-source bipedal research humanoids cost between $3,500 and $13,800. PhoneBot represents a 9x to 35x reduction in platform cost versus those alternatives.

Can I use an Android phone to control a robot?

Yes, and that is exactly what PhoneBot does. The phone serves as the robot’s IMU (balance sensor), camera (vision and SLAM), neural-network inference processor (locomotion policy via TensorFlow Lite), wireless radio (Wi-Fi to the onboard servo controller), and user interface (touchscreen and speaker) simultaneously. The architecture was validated across four different Android devices, including a $50 prepaid handset and a 2017 flagship phone.

What is sim-to-real transfer, and why does it matter for PhoneBot?

Sim-to-real transfer refers to the challenge of training a robot’s controller in physics simulation — where crashes are free — and successfully deploying it on physical hardware, where simulation simplifications cause failure. PhoneBot’s locomotion policy was trained in the MuJoCo/MJX simulator using domain randomization: servo torque limits, gear backlash, and friction were randomly varied during training so the resulting policy would be robust to real-hardware variation. The team also introduced a novel technique called sagittal mirroring that specifically addresses left-right motor asymmetry from manufacturing tolerances, reducing joint-angle symmetry error by 98.8 percent compared to training without it.

What does PhoneBot’s open-source release include?

The open-source release at phonebot.dev includes the full mechanical CAD files for 3D-printed structural components, electronics schematics, firmware for the onboard single-board computer that drives the Dynamixel servo bus, and the trained locomotion policy and vision software stack for Android. The design uses off-the-shelf components (Dynamixel XL430-W250-T servos, commodity Android phones), so you can replicate the full build without access to any proprietary hardware or software.