The previous post makes a hard claim: if you want current local-LLM tooling on the G1 EDU, JetPack 5.1.1's CUDA 11.4 ceiling is structural, and a reflash to JetPack 6.2 is the real fix, not a workaround. That claim needs one honest qualifier attached to it: it's only true if local inference is actually the goal.

If it isn't — if a cloud LLM is an acceptable part of your architecture — the ceiling doesn't apply to you at all. This post is about that path, because it's a completely legitimate one, not a lesser one, and it's exactly what this project ran on for its first real era.

This is the guide we wish existed before we started. If you're building conversational, gesture-capable behavior on a Unitree G1 EDU — or any embedded robotics platform stuck on an older JetPack/CUDA version — and you're deciding whether a cloud-first stack makes sense, this walks through the real architecture, the real latency numbers, what actually worked, and where the hard edges are.

This is a story about a tool that ended up nothing like what it started as — and about how the detour turned out to be the better path anyway. It starts with wanting to record real human motion for the robot to mimic, and ends with describing a gesture in plain English and getting back a validated, ready-to-run script.

Voice and gestures get most of the attention in this project, but the face is doing genuinely interesting real-time work of its own — fifteen parameters lerping independently, Perlin-noise-driven mouth movement instead of robotic on/off animation, and speech-synced expression timing that has to stay accurate across a live, streaming audio pipeline. This is how it's built.

If you're building an embodied AI project on the Unitree G1 EDU, and you're still on the stock JetPack 5.1.1 platform, there's a decision point coming that no amount of clever engineering will let you avoid — if local, on-device inference is your goal. This post is about why that ceiling is real for that specific goal, why the obvious workarounds don't actually work, and why the decision to stop patching around it was the right one to make earlier rather than later. (If local inference isn't actually required for your project, the ceiling may not apply to you at all — see the companion post on the cloud-LLM path before assuming you need to reflash.)

The WebRTC saga post covers what broke after April 11. This post is about what was actually running underneath the demo itself — the full loop from a person speaking to the robot physically responding, stage by stage, in enough detail to actually follow along if you're building something similar.

On April 11, 2026, the first real demo of Project Ziko ran at an open house — voice pipeline working end to end, wake word firing reliably, built-in gestures dispatched live by GPT-4o through a WebRTC connection to the robot. It was a full success. Six days later, the robot was non-operational, and it would take weeks, a community investigation, and eventually a full architectural pivot away from WebRTC before gesture control was genuinely solid again. This is that arc.

Scoping note: the WebRTC break was the most visible failure to come out of firmware 1.5.1, but it wasn't the only one. The same update also killed the internal speaker, introduced new motor alarms, and surfaced a separate (unrelated) custom-gesture failure — four compounding problems off one release, not one. This post follows the WebRTC thread specifically; the full triage across all four is in the 1.5.1 systemic-regression entry.