BlitzRobots

Natural language in. Deterministic robot code out. A browser-based sim where an LLM compiles once at edit time — never drives the motors live.

Robotics is stuck behind cost and syntax

Physical robots are expensive and fragile. Learning with ROS 2 forces a dual curve: physics and strict software syntax.

Live LLM control makes it worse — latency, API cost, and non-deterministic behavior that is unsafe around real hardware.

What breaks today

Hardware cost & friction
Syntax barriers for beginners
AI-at-runtime latency & risk

Compile intent. Run deterministically.

Design robots visually and write control logic in plain English. At an explicit compile step, an LLM translates intent into a sanitized Python/C++ state machine. That script runs natively at 60Hz+ in the sim — or flashes to ESP32 / Pi Pico.

Visual canvas

Drag-and-drop motors, sensors, and chassis into a structural manifest.

Intent cards

Natural-language behaviors, capped and modular — e.g. “Drive until 10cm…”

3D viewport

Zero-install WebGL sim with physics — same code path toward real hardware.

How the pipeline works

Manifest — canvas parts become structural JSON (actuators, sensors, pins).
Prompt builder — injects component APIs and allowed calls into a compiler system prompt.
LLM compiler — runs once per compile; outputs a state-machine script, not a live control loop.
AST validation — sanitizes syntax, strips illegal calls, enforces the restricted robot API.
Runtime — approved code executes in-browser (WebAssembly physics) or flashes over WebUSB / serial.

Roadmap

V1 — Frontend mesh

Split workspace: parts + intent on the left, live 3D primitive robot on the right.

V2 — Sim & physics

60Hz loop with Rapier.js; JS hooks mirroring the robot API for mesh control.

V3 — Compiler & AST

Prompt synthesis + AST checks so generated code stays sandboxed and schema-safe.

V4 — Hardware bridge

Export MicroPython-compatible builds to ESP32 / Pico via WebUSB or Web Serial.

Safety is not optional

LLM output never owns the runtime. Sandboxed workers, hardcoded hazard interceptors, and hard caps on intent cards keep sim and metal predictable.

Guardrails

Web worker isolation (no DOM / network)
Hardcoded stop on critical sensor thresholds
250-word cap per intent card

Early interest

Building toward blitzrobots.com — tell us if you want education pilots, sim access, or hardware kits.

Register interest