PhoneBot

• PhoneBot is a low-cost, open-source humanoid robot platform that utilizes an Android smartphone as its primary sensing, computing, and interaction unit, costing approximately $400, excluding the smartphone. It is designed with 13 rotational degrees of freedom, controlled by 13 DYNAMIXEL actuators, and a single-board computer (SBC) which facilitates human interaction and locomotion tasks.
• PhoneBot is optimized for educational, reinforcement learning research, low-cost telepresence, and quick prototyping tasks, with applications in walking simulation, object recognition, and speech- interaction due to it being powered by TensorFlow Lite, ARCore, and MediaPipe technologies, enabling 3D foot placement and position orientation.
• The robot is a viable candidate for research and experimentation in humanoid locomotion and perception, owing to the sensor-rich and hardware-comprehensive specification of modern smartphones.

PhoneBot is a low-cost, open-source humanoid robot platform that reuses a commodity Android smartphone as its principal sensing, computing, wireless-communication, and human–robot-interaction unit. The robot combines a modular 13-degree-of-freedom lower body, 13 DYNAMIXEL XL430-W250-T actuators, an onboard single-board computer, and a torso-mounted smartphone. The smartphone performs inertial sensing, camera-based perception, TensorFlow Lite policy inference, speech interaction, display, and networking, while the robot-side computer communicates with the actuators. The platform is reported at approximately $483 \times 183 \times 125~\mathrm{mm}$, $1.8~\mathrm{kg}$, and approximately $$400$, excluding the smartphone (Hou et al., 6 Oct 2026).

1. Concept and development context

PhoneBot addresses three barriers to humanoid-robot adoption: hardware cost, system-integration complexity, and the computational and sensing requirements of perception and learning-based control. Conventional small humanoids commonly require separate cameras, inertial sensors, computers, displays, microphones, networking hardware, and specialized integration. PhoneBot instead treats the smartphone as a replaceable robotics module.

The smartphone supplies a camera, inertial measurement unit (IMU), CPU, wireless interfaces, microphone, speaker, touchscreen, and operating-system support. The robot body provides the actuators, mechanical structure, battery, and low-level actuator interface. This division is intended to reduce the need for a dedicated high-performance onboard computer while preserving access to modern perception, networking, and machine-learning software.

The platform is designed for education, reinforcement-learning research, bipedal locomotion, smartphone robotics, human–robot interaction, visual perception, SLAM, low-cost telepresence, and rapid prototyping. Its open-source hardware and software are intended to support reproducible deployment using off-the-shelf smartphones and actuators.

PhoneBot is related to the broader smartphone-robotics architecture demonstrated by OpenBot, in which a commodity smartphone supplies onboard perception and control while a low-cost body supplies locomotion and auxiliary sensing (Müller et al., 2020). PhoneBot differs in its humanoid morphology, bipedal locomotion, torque-aware actuator model, and 13-actuator control system.

2. Mechanical and actuator architecture

PhoneBot has a symmetric bipedal lower body with six actuated joints per leg and one torso-yaw joint. Each leg includes hip yaw, hip roll, hip pitch, knee pitch, ankle pitch, and ankle roll. The right leg uses joints $J1$–$J6$, the left leg uses $J7$–$J12$, and $J13$ provides torso yaw.

The leg configuration provides three rotational degrees of freedom at each hip, one degree of freedom at each knee, and two degrees of freedom at each ankle. This arrangement supports three-dimensional foot placement and foot-orientation control. The torso-yaw actuator rotates the smartphone and camera relative to the stance direction, enabling visual reorientation without necessarily rotating the entire lower body.

Component	Specification
Active actuators	13 DYNAMIXEL XL430-W250-T servos
Robot dimensions	Approximately $483 \times 183 \times 125~\mathrm{mm}$
Mass	$1.8~\mathrm{kg}$, including smartphone
Robot-body cost	Approximately $1.8~\mathrm{kg}$0, excluding smartphone
Servo gear ratio	$1.8~\mathrm{kg}$1
Servo stall torque	$1.8~\mathrm{kg}$2
Servo no-load speed	$1.8~\mathrm{kg}$3
Servo encoder resolution	4096 pulses per revolution
Servo mass	$1.8~\mathrm{kg}$4

All joints use XL430-W250-T servos. Their low cost supports the platform’s economic objective, but their torque and speed limitations constrain payload, dynamic motion, and robustness. The asymmetric hip-pitch limits enlarge sagittal-plane workspace and support crouching, larger leg swings, and recovery motions.

The phone is mechanically mounted to the torso rather than electrically connected to the robot. This permits replacement of the smartphone without redesigning the actuator system and allows the robot to use different phones with different computational and sensing capabilities.

3. Smartphone, SBC, and communication stack

PhoneBot divides computation between the smartphone and a small onboard single-board computer (SBC). The smartphone performs high-level sensing and computation; the SBC provides the actuator-bus interface.

The smartphone performs IMU acquisition, camera acquisition, TensorFlow Lite policy inference, vision processing, human detection and pose estimation, SLAM, voice recording, touchscreen interaction, and wireless command transmission. It sends high-level joint-position commands rather than motor torques.

The SBC receives UDP packets from the smartphone, communicates with the DYNAMIXEL actuator bus, forwards desired joint positions, reads joint positions and velocities, and returns telemetry. The smartphone and SBC communicate over Wi-Fi using UDP. The absence of a physical phone–robot cable simplifies mechanical mounting and permits the smartphone to remain a detachable computational component.

The principal software components are:

• Android application;
• TensorFlow Lite;
• UDP over Wi-Fi;
• ML Kit for object detection;
• MediaPipe for human-pose estimation;
• ARCore for visual-inertial SLAM;
• MuJoCo/MJX for simulation and training;
• proximal policy optimization (PPO) with an asymmetric actor–critic;
• whisper.cpp for speech recognition;
• a laptop-hosted LLM;
• Piper text-to-speech.

The current conversational system is not fully onboard. The phone records speech and sends it to a laptop backend, where whisper.cpp performs speech-to-text, a LLM generates a response, and Piper produces speech. The generated audio is played through the smartphone speaker. The API key remains on the laptop rather than being embedded in the Android application.

This architecture places latency-sensitive actuator communication below the smartphone’s policy and perception stack, but it also introduces dependence on Wi-Fi quality, packet delivery, phone operating-system behavior, and, for conversation, an external laptop backend.

4. Torque-aware locomotion and control

Actuator modeling

A central technical contribution is the use of a torque-aware actuator model rather than treating the servos as ideal position sources. The simulator converts policy position commands into torques subject to joint limits, speed-dependent torque saturation, asymmetric acceleration and braking limits, damping, friction, and encoder backlash.

The desired joint target is represented as

$1.8~\mathrm{kg}$5

The unconstrained proportional–derivative torque is

$1.8~\mathrm{kg}$6

The effective stiffness increases during back-driving:

$1.8~\mathrm{kg}$7

The acceleration-side torque limit decreases with joint speed. Braking and acceleration are clamped asymmetrically because the actuator can apply greater braking torque than acceleration torque. If an accelerating command would exceed the no-load speed, full braking is applied. Passive damping and friction are also modeled, and encoder backlash is included in the policy-observed joint position.

Nominal parameters include $1.8~\mathrm{kg}$8, $1.8~\mathrm{kg}$9, $$400$0, $$400$1, peak acceleration torque $$400$2, torque taper beginning at $$400$3, no-load speed $$400$4, residual acceleration torque $$400$5, braking torque $$400$6, joint damping $$400$7, rotor armature $$400$8, and friction loss $$400$9. Training randomizes actuator parameters, including proportional and derivative gains, torque limits, and backlash width.

Learned walking policy

The walking controller is an omnidirectional policy trained using asymmetric actor–critic PPO in MuJoCo/MJX. The actor receives only information intended to be available on the physical robot:

• noisy angular velocity;
• noisy projected gravity;
• commanded velocity;
• noisy joint positions;
• noisy joint velocities;
• previous action;
• gait phase.

The critic additionally receives privileged simulation information, including base velocity, clean IMU and joint measurements, base height, actuator forces, foot contacts, foot velocities, and swing airtime. The actor observation dimension is 52, while the privileged critic observation dimension is 120.

The commanded velocity is

$J1$0

with

$J1$1

Ten percent of commands are zero commands for standing. The policy produces a 13-dimensional vector of joint-position residuals at $J1$2, corresponding to a control interval of $J1$3. When command magnitude is below $J1$4, the gait phase is replaced by a stand-still phase.

The reward combines velocity tracking, upright survival, foot airtime, foot-phase tracking, foot-corner phase tracking, and penalties for vertical motion, roll and pitch rates, orientation error, torque magnitude, torque utilization near saturation, rapid action changes, excessive joint speed and acceleration, joint-limit violations, home-pose deviation, foot-clearance error, foot nonparallelism, foot slip, insufficient foot distance, and foot collisions.

Sagittal mirroring

Without symmetry handling, the policy sometimes converged to an asymmetric gait in which one foot led and one leg carried most of the load. PhoneBot addresses this by adding sagittal mirrors of collected actor samples during each PPO update. The physical transition is simulated once, while the mirrored transition is added to the actor-training batch. Advantages and returns are copied from the real trajectory; the critic is trained only on real samples because its privileged observations contain world-frame quantities that are not straightforward to mirror.

The mirroring operation swaps left and right legs and gait phases, transforms IMU quantities and velocity commands, and negates hinge angles according to the robot’s CAD convention. This produces two actor-training samples per physics step without doubling simulation.

The reported symmetry evaluation used a $J1$5 forward command for $J1$6, beginning from phase pairs $J1$7 and $J1$8. After $J1$9 environment steps, sagittal mirroring reduced joint-angle symmetry error from $J6$0 to $J6$1, relative left–right torque imbalance from $J6$2 to $J6$3, and relative left–right mechanical-power imbalance from $J6$4 to $J6$5.

5. Perception, interaction, and embodied capabilities

PhoneBot uses the smartphone as its main sensor suite.

The IMU supplies angular velocity and gravity-orientation information for locomotion. Joint positions and velocities returned from the actuators are combined with phone IMU measurements to construct the locomotion-policy observation.

The camera supports object detection, human-pose estimation, person following, camera-heading control, filming, and visual-inertial SLAM. ML Kit is used for human or object detection, MediaPipe for human-pose estimation, and ARCore for SLAM on compatible devices. ARCore SLAM remained stable during qualitative walking trials despite periodic body motion.

The heading policy represents the desired camera direction using remaining look error in the IMU frame:

$J6$6

where $J6$7 is look yaw and $J6$8 is look elevation. The torso-yaw joint is used first. Walking begins when pelvis-frame look yaw exceeds $J6$9 and stops when it falls below $J7$0. This allows the robot to rotate its camera without immediately turning the entire body.

Person following is implemented by detecting a person through the phone camera and using image position and pose to generate visual-following or look-at behavior. The supplied evaluation reports this capability primarily qualitatively; it does not provide a tracking-distance metric, trajectory-level success rate, or quantitative following benchmark.

Conversational interaction follows a modular speech pipeline:

1. the smartphone records speech;
2. audio is sent to a laptop;
3. whisper.cpp produces text;
4. a LLM generates a response;
5. Piper synthesizes speech;
6. the smartphone speaker plays the response.

Filming uses the smartphone camera, while torso yaw reorients the camera. Mobile telepresence combines bipedal mobility, camera streaming, touchscreen controls, wireless communication, and remote interaction. The supplied results do not specify a complete telepresence protocol, latency measurement, remote-user study, or quantitative telepresence evaluation.

A separate stand-up policy recovers from sitting and prone configurations to a standing height of $J7$1. Its rewards emphasize height, upward velocity, upright orientation, stable standing, low slip, low action variation, avoidance of trunk–floor contact, joint limits, and self-collision.

6. Evaluation, deployment, and limitations

Locomotion evaluation

Locomotion policies with and without sagittal mirroring were trained from scratch using five independent random seeds, $J7$2, on flat terrain. Training curves covered the first $J7$3 environment steps, with evaluation conducted in 256 environments. The mirrored policy produced earlier return gains, higher final return, narrower seed-to-seed variation, improved velocity tracking, greater upright survival, improved foot-airtime and phase behavior, reduced foot slip, flatter feet, closer home-pose tracking, and reduced action variation after an initial transient.

Smartphone evaluation

Four Android smartphones ran the same application:

• Honor 9, a used 2017 handset;
• moto g 2025, approximately $J7$4;
• Galaxy A16 5G, approximately $J7$5;
• moto g 2024, approximately $J7$6.

All supported IMU sensing, UDP motor communication, locomotion inference, onboard vision, and human–robot interaction. The Honor 9 could not run the reported ARCore SLAM configuration because Google services were unavailable on that device.

Phone	Policy CPU	Vision CPU	SLAM CPU	HRI CPU
Honor 9	$J7$7	$J7$8	unavailable	$J7$9
moto g 2025	$J12$0	$J12$1	$J12$2	$J12$3
Galaxy A16 5G	$J12$4	$J12$5	$J12$6	$J12$7
moto g 2024	$J12$8	$J12$9	$J13$0	$J13$1

These measurements support the feasibility of running the core sensing, control, vision, and interaction stack on old or inexpensive smartphones. They do not establish identical performance across all Android hardware, operating-system versions, camera configurations, wireless environments, or thermal conditions.

Comparison with small humanoids

PhoneBot is reported as substantially less expensive and lighter than several conventional small humanoids. The comparison includes the ROBOTIS OP3 at $J13$2, BRUCE at $J13$3, and HighTorque MiniPi at $J13$4, excluding the smartphone.

The cost and modularity advantages are accompanied by significant trade-offs: 13 degrees of freedom, no arms, no manipulation capability, low actuator torque, limited payload, dependence on Wi-Fi, dependence on a laptop for current conversational AI, flat-terrain training, and variable support for smartphone services such as ARCore.

Deployment requirements

A typical deployment requires assembly of the lower body and torso-yaw mechanism, installation of the 13 servos and DYNAMIXEL bus, installation of the SBC and battery, mechanical phone mounting, Android application installation, Wi-Fi configuration, UDP and motor-ID configuration, joint-limit and home-position verification, policy loading, telemetry testing, and standing or stand-up validation before walking.

A suitable smartphone should provide Android support, a functioning camera, IMU, Wi-Fi, sufficient CPU capability for TensorFlow Lite and vision, adequate memory, and a secure mechanical mount. Google services and ARCore support are required for the reported SLAM configuration.

The project’s open-source claim concerns the hardware and software designs released through phonebot.dev; the supplied material does not enumerate every repository, CAD file, license, wiring diagram, calibration script, or build procedure.

Limitations and future directions

The platform has no arms and is therefore limited to locomotion, sensing, interaction, filming, and telepresence rather than manipulation. Locomotion policies were trained on flat terrain, and the XL430 actuators constrain torque, payload, and dynamic motion. Conversational interaction depends on an external laptop backend, while smartphone and service compatibility varies by device.

The paper identifies uneven-terrain locomotion, lightweight arms, object manipulation, language-model-based task planning, on-device LLMs, and broader whole-body learning as future directions. Adding arms would alter whole-body dynamics, contact conditions, balance, and actuator requirements. On-device LLMs would reduce reliance on the external laptop backend but would introduce additional computational and thermal constraints.

PhoneBot is therefore best understood as a reproducible research platform rather than a general-purpose humanoid replacement. Its principal contribution is architectural: a smartphone becomes a detachable robotics computer and sensor suite, while a lightweight humanoid body supplies embodiment and actuation. The resulting system lowers the cost of experimentation in locomotion, embodied perception, interaction, and rapid robot-system development, while leaving high-torque manipulation, uneven-terrain autonomy, fully onboard language processing, and long-duration reliability as open engineering problems.