OpenGo: Modular Robotics with LLM Control

• OpenGo is a modular framework for quadrupedal robotics that integrates LLM-driven reasoning, dynamic task planning, and natural-language interfaces.
• It features a hierarchical pipeline with an LLM-based Dispatcher, Memory/State-Check, and a validated Skill Library to ensure safe and efficient execution.
• The system employs policy-gradient self-learning to refine skill parameters and improve reactive performance in dynamic environments.

OpenGo refers to a modular framework for quadrupedal robotics that enables real-time acquisition, organization, and switching between a validated set of embodied skills. Engineered atop the OpenClaw stack and deployed on the Unitree Go2 robotic platform, OpenGo integrates LLM-driven task reasoning, natural-language user guidance, and policy-gradient self-learning to support responsive, robust, and user-friendly robot behaviors in dynamic environments (Li et al., 2 Apr 2026).

1. System Architecture

OpenGo is organized as a hierarchical control pipeline, featuring two high-level "brains": the Dispatcher and the Memory/State-Check modules, layered over a standard perception–control–safety stack. The core components are:

• Communication Interface: Integrates platforms (e.g., Feishu) for receiving natural-language tasks and transmitting logs or status.
• Dispatcher (LLM-based): Takes natural-language task descriptions $T$, extra instructions $I$, and current scene state $S$ as input, producing a skill execution plan $\Pi = \{(k_1, \theta_1), \dots, (k_n, \theta_n)\}$ using the current validated skill set $K$.
• Memory/State-Check: Logs historical execution, tracks the robot state, monitors success/failure and emergency events, and can trigger re-planning for unexpected transitions.
• Skill Library: Structured repository of validated skills, with each skill $k_i$ exposing tunable parameters $\theta_i$.
• On-Robot Stack: Integrates OpenClaw and Unitree Go2 hardware modules, handling perception, state estimation, low-level controllers, and safety monitors.

The high-level pipeline enables closed-loop, human-in-the-loop operation and direct mapping from natural-language user goals to executable robot behaviors. The key mapping is expressed $\Pi = f_{\mathrm{LLM}}(T, I, S, K)$, where $f_{\mathrm{LLM}}$ denotes the sequence-planning function performed by the LLM in the Dispatcher (Li et al., 2 Apr 2026).

2. Skill Library and Validation Pipeline

The Skill Library consists of modular behaviors compatible with physical robot deployment. Each skill is defined by a fixed five-field template:

Field	Example / Description	Constraints
skill head	"JumpOver", "WalkForward"	Unique label
parameters $\theta$	target_distance, speed	$I$0
constraints	Preconditions (e.g., flat terrain) Safety bounds (max torque/joint angle)	Hard pre/post-conditions
function	Compiled control routine (immutable)	Interface-checked
prompts	English-language guidance (LLM prompt)	Informative only

Skills are imported via a pipeline: code review (interface, definitions, safety), followed by simulation validation (e.g., Gazebo, Unity). Only skills passing both are eligible for invocation at runtime. No online recompilation of skill function is permitted; only parameterization ($I$1) is adjusted. This constrains LLM-driven generation to a pre-screened set of verifiable, safety-constrained behaviors (Li et al., 2 Apr 2026).

3. Dispatcher: Real-Time Task Decomposition

At run-time, the Dispatcher executes a three-stage sequence:

A. Skill Candidate Filtering

Skills incompatible with the real-time scene state $I$2 (e.g., violated preconditions) are excluded. Parameter bounds for each candidate $I$3 are enforced.

B. LLM Prompt to Plan Translation

A structured, context-rich prompt is composed—including scenario summary, available skills with their parameter domains, and the user's high-level request. The LLM then emits a skill sequence $I$4 as output.

C. Memory/State-Check Verification

Before each potential $I$5 execution, the Memory/State-Check module assesses for state conflicts and failure signals, triggering replanning if necessary.

Pseudocode Sketch

$S$7

A plausible implication is that this enables rapid and explainable skill-switching, where each step is check-pointed for feasibility and safety (Li et al., 2 Apr 2026).

4. Self-Learning and Feedback Integration

OpenGo dynamically adjusts skill invocation preferences (per-scenario weights $I$6) and default parameters $I$7 via feedback signals without modifying skill code. Feedback $I$8 consists of (i) task completion, (ii) error flags (e.g., emergency stops), and (iii) human feedback via the communication interface (e.g., "+1" for positive correction).

Learning updates are performed as follows:

• Skill preference update:

$I$9

where $S$0, $S$1 is a baseline, and $S$2 a learning rate.

• Parameter mean update:

$S$3

Default parameter values shift toward empirically successful settings, constrained to permissible intervals. The self-learning framework thus implements a lightweight, policy-gradient rule to iteratively align robot behavior with real-world outcomes and human intent, while maintaining strict boundary conditions (Li et al., 2 Apr 2026).

5. Human–Robot Interaction via Natural Language

The Communication Interface is tightly coupled with Feishu (and analogous platforms), enabling direct, dynamic human–robot dialog:

1. The user submits a text prompt (e.g., "dog, dance in place").
2. The prompt is relayed via webhook to the OpenGo server.
3. The Dispatcher synthesizes and issues an LLM plan.
4. Memory/State-Check validates, then skill(s) are executed.
5. Upon completion, success/failure status and logs are returned to the user.
6. Additional user input (e.g., "more energetic") is parsed as incremental instruction $S$4, triggering replanning.

This closed-loop structure ensures that both expert and inexperienced users can refine robotic dog behavior using only plain English. Empirical results indicate new users achieve successful robot operation (basic skill invocation, refinement) within 5 minutes on average (Li et al., 2 Apr 2026).

6. Empirical Results and Deployment

Deployed on the Unitree Go2 platform, OpenGo demonstrates the following characteristics:

• Latency:
  • Cold start: 700–900 ms per skill
  • Warm start (cached): 200–300 ms
  • Skill-sequence latency grows sublinearly with composition (e.g., 2-skill: 1.2 s; 4-skill: 2.1 s)
• Robustness and Success Rates:
  • $S$595% for basic locomotion (walk, turn, backflip, dance)
  • Real-time skill switching ($S$6200 ms between skills)
  • Graceful fallback on invalid/unsafe skill selections
• Human–Robot Dialog:
  • Average: 1.2 user corrections per 10-min session
  • Effective operation by users without robotics expertise

This empirical profile substantiates the framework’s capacity for robust, low-latency, user-driven skill switching under real-world constraints, all while preserving safety and transparency (Li et al., 2 Apr 2026).

7. Comparison and Context

The OpenGo framework for embodied robotics (Li et al., 2 Apr 2026) is distinct from ELF OpenGo for AI Go research (Tian et al., 2019). While the latter is an open-source, high-throughput, distributed deep RL system for board game play, the former addresses embodied intelligence and task generalization in physical robots. No technical or architectural dependencies connect the two frameworks beyond nomenclature. Each system is documented and evaluated in its respective domain, with OpenGo providing an instantiation of verified, LLM-guided autonomous decision making for quadrupedal robots (Li et al., 2 Apr 2026, Tian et al., 2019).