OpenMind OM1: Go-Powered Robot Runtime Aims for Embodied AI's 'Android Moment'

Embodied AI's 'Android Moment'?

The embodied intelligence landscape is splitting into distinct layers: foundation models (VLA, world models), robot hardware (humanoid, quadruped, wheeled), simulation platforms (Isaac Sim, Genesis, MuJoCo), and a crucial connective layer that binds diverse brains to diverse bodies. OpenMind targets this connective layer with OM1, positioning it as the "Android of robots" — an open-source AI runtime that lets the same AI capabilities migrate across humanoid robots, quadrupeds, mobile apps, and simulation environments.

OM1 Is Not an Embodied AI Model

OM1 defines itself as a Modular AI Runtime / AI HAL for Robots . It does not produce intelligence; it schedules and orchestrates it. Sitting between AI models (LLM, VLM, VLA, Policy) and robot hardware (ROS2, Zenoh, robot SDKs), OM1 decouples "which model thinks" from "which body acts." Installing OM1 on a bare robot will not make it walk — OM1 assumes a mature low-level HAL already handles trajectory execution, battery management, and sensor calibration. If that HAL is missing, traditional robotics methods (RL, sim training, custom VLA) are still required first.

Five-Layer Stack: Where OM1 Sits

The article decomposes embodied intelligence into five layers:

Layer 1: Embodied AI Foundation Models (VLA, World Models)

Layer 2: Robot Hardware (Humanoid, Quadruped, Wheeled)

Layer 3: AI Runtime / HAL (OM1) — connects thinking capabilities to execution capabilities

Layer 4: Middleware / Communication (ROS2, Zenoh, DDS)

Layer 5: Simulation Platforms (Isaac Sim, Gazebo, MuJoCo)

OM1 occupies Layer 3. It is not a competitor to LeRobot (which teaches robots how to learn skills) nor to ROS2 (which handles robot-level communication). Instead, OM1 focuses on running already-acquired intelligence stably on arbitrary robots, while explicitly supporting ROS2, Zenoh, and CycloneDDS as underlying middleware.

Why the Android Analogy Fits (and Where It Doesn't)

Android lets developers write one app that runs on Samsung or Xiaomi phones without hardware concerns. OM1 replicates this logic: developers write high-level commands like "go to kitchen" or "pick up red apple," while OM1's hardware plugins translate them into Unitree Go2 cmd_vel commands or Isaac Sim joint angles. This hardware-agnostic promise addresses the industry's "hardware convergence, software fragmentation" problem — Unitree G1/H1, UBTech, Figure, etc., all have incompatible SDKs, protocols, and sensor formats.

However, two caveats remain: (1) Android's hardware differences are parameter variations within a single form factor (handheld screen), whereas quadruped vs. humanoid differences are far deeper (degrees of freedom, sensor suites, kinematic models); HAL can only abstract so much. (2) OM1 embeds unique designs absent from Android, such as writing system constitutions to blockchain and the FABRIC decentralized inter-robot collaboration protocol — choices with strong Web3 DNA whose mainstream adoption is still an open question.

Core Design: Natural Language Data Bus (NLDB)

OM1's most technically distinctive mechanism is the Natural Language Data Bus (NLDB) . Instead of vectors or tensors, all inter-module communication uses natural language. Camera feeds, microphone audio, battery levels — all structured signals — pass through an "AI compression/captioning" layer to become human-readable sentences (e.g., "see a person smiling and pointing at a chair"). A State Fuser merges these fragments into a complete situational description for the decision-making LLMs.

This design is justified in OpenMind's paper A Paragraph is All It Takes: Rich Robot Behaviors from Interacting, Trusted LLMs (arXiv:2412.18588): a baseline system of four LLMs communicating via natural language at 1 Hz, with the central bus compressed to ~40 bits/s (near human language processing rate), still produces competent robot behaviors across tasks. An added benefit: humans can directly read the robot's "inner monologue," aiding debugging and safety auditing.

Multi-LLM Decision Layer

A typical OM1 deployment runs three or more LLMs concurrently:

Fast Action LLM — Local or cloud small model; handles time-critical, emergency actions; typical latency ~300 ms

Cognition / Core LLM — Cloud large model; handles complex reasoning, long-term planning; typical latency ~2 s

Mentor / Coach LLM — Cloud model; third-person review of human-robot interaction quality; emits feedback every 30 s; latency seconds to minutes

All LLMs are governed by a natural-language "system constitution" stored in the system_governance config field. OpenMind also supports anchoring these constitutions on public, immutable ledgers (e.g., Ethereum) for transparent, auditable behavior constraints.

End-to-End Data Flow

The full pipeline: Sensors → Input Plugins (ASR, VLM, face detection) → State Fuser (natural language fusion) → NLDB → Multiple LLMs (Fast, Core, Mentor) → Action Plugins (speak, emotion, navigation, unitree) → HAL (ROS2/Zenoh/DDS) → Robot Hardware. The HAL layer translates high-level intent ("gently pick up red apple") into low-level servo sequences, often using existing ROS2 functions or Dockerized DDS/websocket bridges. OM1 does not replace this low-level control.

Architecture diagram showing data flow from sensors to actions via NLDB and multiple LLMs (source: https://mmbiz.qpic.cn/mmbiz_png/GBGgDA2CUoU1tkaZ2Tzg45dRYFDJHIhAY0lD8Zy99E6fKiaT9V5HrdaLSAgQ8q0EaJHIs89x6e7lyt6porYI1glMUP2dtsRIg9PNd9uM7icaw/640?wx_fmt=png&from=appmsg)

Why Go? A Full Rewrite from Python

OM1 began as a pure Python project but has been completely rewritten in Go; the Python version is now deprecated. The rationale:

Lower latency: Every link in the robot decision chain adds to perceived "sluggishness."

Better concurrency: Parallel sensor streams and multiple LLM calls need efficient handling.

Smaller memory footprint: Critical for edge devices like NVIDIA Jetson where Python runtime overhead is significant.

Simpler deployment: Go compiles to a single binary (including Zenoh's C library), eliminating the need to maintain a full Python virtual environment on the robot.

This choice reflects OM1's role as a system-level runtime requiring long-term stability, concurrency efficiency, and resource control on edge devices — Go's comfort zone — rather than a training framework needing algorithmic flexibility (where Python excels). The project structure reveals a thorough system rewrite:

OM1/
├── cmd/                 # Main entry
├── config/              # JSON5 configuration
├── internal/
│   ├── runtime/         # Core runtime management
│   ├── fuser/           # Input fusion logic
│   ├── llm/             # LLM integration
│   ├── mcp/             # MCP client & orchestration
│   ├── zenoh/           # Zenoh communication (CDR codec, session mgmt)
│   └── ...
└── plugins/
    ├── inputs/          # ASR, VLM, face detection plugins
    ├── actions/         # speak, emotion, navigation, unitree plugins
    └── llm/             # OpenAI, Gemini, DeepSeek, Ollama plugins

The system runs on a fixed-frequency main loop (set by hertz field, typically ~1 Hz) that each tick fetches latest inputs, fuses them into text, queries LLMs, and translates responses into actions. This loop governs the robot's "attention and working memory" rhythm, while physical stability control (50–500 Hz gait maintenance) runs independently on lower-level hardware loops.

Modular Configuration: One JSON5 File Defines a Robot's "Personality"

All agent behavior — LLM choice, sensor inputs, action capabilities, system prompts — converges into a single JSON5 config. This enables cross-robot reuse: swapping robots theoretically only requires changing the Action plugins while keeping the reasoning logic intact. Configs support single-mode and multi-mode (state-machine) definitions. A simplified example:

{
  version: "v1.1.0",
  default_mode: "welcome",
  cortex_llm: {
    type: "OpenAILLM",
    config: { agent_name: "Bits", history_length: 10 },
  },
  modes: {
    welcome: {
      system_prompt_base: "You are Bits, a friendly robot dog meeting a user for the first time...",
      agent_inputs: [{ type: "VLMGemini" }, { type: "GoogleASRInput" }],
      agent_actions: [{ name: "speak", connector: "elevenlabs_tts" }],
    },
    conversation: {
      system_prompt_base: "You are in conversation mode, focused on meaningful exchange...",
      agent_inputs: [{ type: "GoogleASRInput" }, { type: "VLMGemini" }],
      agent_actions: [{ name: "speak", connector: "elevenlabs_tts" }],
    },
  },
  transition_rules: [
    {
      from_mode: "welcome",
      to_mode: "conversation",
      trigger_keywords: ["talk", "chat", "tell me"],
    },
  ],
}

Inputs ( agent_inputs), decision ( cortex_llm), and actions ( agent_actions) are all pluggable registries. Adding a new sensor, LLM vendor, or robot action interface means writing a new plugin and registering it — no core runtime changes needed.

Hands-On: Running a "Digital Robot Dog" in Simulation

OM1 treats simulation as a first-class citizen, officially supporting Gazebo and Isaac Sim (no native MuJoCo integration, as MuJoCo targets lower-level RL training). The article walks through a Gazebo + Unitree Go2 simulation on Ubuntu 22.04:

Environment prep: Install ROS2 Humble, CycloneDDS, rosdev tools, and uv (Python package manager for sim toolchain).

Clone and build sim workspace: git clone https://github.com/OpenMind/OM1-sim.git, then rosdep install, colcon build, and uv pip install ..

Launch Gazebo: ros2 launch go2_gazebo_sim go2_launch.py — opens Gazebo and RViz with a virtual Go2.

Start Zenoh bridge: zenoh-bridge-ros2dds -c ./zenoh/zenoh_bridge_config.json5 connects sim topics to OM1.

Run OM1: Set OM_API_KEY (from OpenMind Portal), then CONFIG=unitree_go2_autonomy USE_SIM=true make dev.

Verify: Use ros2 run teleop_twist_keyboard teleop_twist_keyboard to keyboard-drive the virtual dog; observe OM1's fused natural-language state logs, LLM decisions, and Gazebo actions.

Tip: With an NVIDIA GPU, you can switch to the more physically accurate Isaac Sim path; official docs provide Go2 and G1 sim support at docs.openmind.com/simulators/isaac-sim.md .

Ecosystem & Ambition: From Robot OS to Robot App Store to FABRIC

OpenMind's roadmap extends beyond a runtime:

Step 1: Become the de-facto standard runtime. Founded by Stanford professor Jan Liphardt in 2024; $20M Series A led by Pantera Capital (Aug 2025); ~2.9k GitHub stars, ~1k forks; reported 180k+ waitlist signups in three days.

Step 2: Robot App Store. Package robot behaviors, models, and task logic into installable, distributable, updatable units — shifting developers from "build a whole robot" to "build a skill installable on any compatible robot."

Step 3: FABRIC protocol. While OM1 handles intra-robot AI scheduling, FABRIC targets inter-robot communication, collaboration, capability sharing, and identity verification — together forming a Physical AI infrastructure for multi-robot systems.

This evolution stretches the Android analogy: Android solved "one phone runs many apps"; OpenMind aims for "one AI agent runs on 100 humanoid types and 1000 service robots, develops once, runs everywhere, collaborates peer-to-peer."

Conclusion: A Valuable Reference Architecture

Whether the "Android moment" fully materializes, OM1's design paradigm — Natural Language Data Bus + Multi-LLM Collaborative Decision-Making + Modular HAL — offers a concrete, engineering-grounded sample for understanding how embodied intelligence software can be built today. For engineers accustomed to a systems perspective, starting with a runtime like OM1 may be a smoother entry path than diving straight into VLA model training details.

References

OpenMind/OM1 GitHub: https://github.com/OpenMind/OM1

OM1 Official Docs: https://docs.openmind.com/

Paper: A Paragraph is All It Takes: Rich Robot Behaviors from Interacting, Trusted LLMs (arXiv:2412.18588)

TechCrunch: "OpenMind wants to be the Android operating system of humanoid robots"

Pantera Capital Blog: "Investing in OpenMind"