Google Runs Gemma 4 on a Wireless-Free Robot Without Any Cloud

Google’s Gemma team demonstrated a battery-powered Reachy Mini on the PyTorch Conference floor without Wi-Fi or a remote inference server. The prototype, called Reachy on Wheels, combines the open-source desktop robot from Hugging Face and Pollen Robotics with two local Gemma models for conversation, tool calling, vision, and driving.

Gemma DevEx engineer Ian Ballantyne and Xavier Plantaz built the system by extending an earlier Raspberry Pi demo with a mobile base and a second model for visual control. The resulting architecture separates high-level language tasks from the timing-sensitive loop that steers the motors.

Two models split the job

The language model has a narrow control role: it interprets the user’s request and starts or stops the vehicle. EmbeddingGemma 2 handles the faster perception-to-action loop, keeping continuous steering outside the conversational model.

The Ventuno Q combines a Linux processor with 16 GB of LPDDR5 and a real-time controller running Zephyr. Linux hosts model inference and the application, while the controller manages CAN-FD, PWM, and GPIO interfaces for motors and sensors. This split lets language and vision workloads use general-purpose compute while motor commands run on a predictable schedule.

LiteRT keeps the pipeline moving

Google’s earlier Reachy voice demo measured Gemma 4 E2B generation at roughly 27.3 characters per second with LiteRT-LM, equivalent to about 300 words per minute. Its application schedules vision and language work across the CPU and GPU so camera processing does not have to wait for text generation to finish.

That throughput figure covers text generation in the earlier stationary demo, rather than the complete response time of Reachy on Wheels. End-to-end latency also includes audio capture, speech recognition, prompt processing, speech synthesis, camera inference, and motor control.

The public GitHub reference provides the voice portion of the stack. Speech recognition, synthesis, and vision use ai-edge-litert, while the language model runs through litert-lm. The documented setup imports the E2B checkpoint and starts a local service bound to the loopback interface:

litert-lm import --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm \
                 gemma-4-E2B-it.litertlm e2b
litert-lm serve --host 127.0.0.1 --port 9379

Those commands package the model for LiteRT-LM and expose it on port 9379 to software running on the same machine. The cited repository covers the earlier voice robot; the available project material does not identify a complete Reachy on Wheels repository or reproduce the vision and driving setup.

Edge deployment changes the constraints

• Lower network latency: Local inference removes the round trip to a hosted model, although model execution and sensor processing still take time.
• Local data processing: The inference path does not require microphone recordings or camera frames to be sent to a cloud service.
• Offline operation: The robot can continue processing commands where connectivity is unavailable or unreliable.
• Isolated control loops: The conversational model handles intent, while the smaller decision model and real-time controller handle steering.

On-device inference still imposes limits on model size, reasoning depth, memory use, and thermal performance. Cloud models may provide stronger reasoning and more fluent responses, while this local design prioritizes predictable connectivity, data locality, and direct access to hardware.

The missing engineering numbers

• End-to-end voice-command latency on the wheeled prototype
• Camera inference rate and motor-control frequency
• Model quantization, memory consumption, and sustained power draw
• Training or fine-tuning details for the EmbeddingGemma 2 decision model
• Obstacle handling, emergency-stop behavior, and other safety controls
• A complete bill of materials and installation guide for the mobile build

Who can build on it

Reachy Mini starts at around $299 and is programmable in Python, making the base robot accessible to individual developers and small research teams. Adding the Ventuno Q, mobile hardware, power system, and camera raises the total cost, but the architecture remains suitable for offline assistants, robotics prototypes, and research environments where sensor data must stay on the device.

The project provides a concrete pattern for local robotics: use a language model for sparse, high-level decisions; assign continuous perception to a smaller model; and leave hard-real-time motor control to an RTOS. LiteRT connects those layers without requiring a cloud inference service.