C3PO, parte 1: Claude Code maneja un robot en Isaac Sim
Le estoy dando un cuerpo a Claude.
El proyecto se llama C3PO, y empezó como un proyecto escolar con una idea simple: tenemos LLMs de frontera que razonan y usan herramientas, y tenemos hardware humanoide realmente capaz — y viven en mundos separados. ¿Por qué no conectarlos? El objetivo final es que Claude controle un humanoide Unitree G1 real: que perciba, decida y se mueva en el mundo físico. El G1 cuesta plata de verdad y se rompe de verdad, así que antes del hardware: simulación.
Lo más simple que pueda funcionar
La primera implementación es deliberadamente cruda. Tres piezas:
- Isaac Sim en un host Ubuntu aparte, corriendo un G1
- Un bridge en Python que expone los controles del robot como herramientas MCP y habla DDS (CycloneDDS + el SDK de Unitree) con el simulador
- Claude Code como cerebro
La última parte es el truco: el bridge es un servidor MCP registrado en el .mcp.json del proyecto, así que cualquier sesión de Claude Code abierta en el repo tiene herramientas como walk_to y get_state al lado de sus herramientas normales de archivos. Sin UI propia, sin backend, sin orquestación. Escribo lo que quiero en la terminal, y Claude llama a las herramientas del robot igual que normalmente llama a grep.
Las herramientas centrales: get_state (pose, batería, postura y fallas en vivo — streameadas desde el simulador a ~100 Hz), walk_to (un loop de control de velocidad hacia una coordenada del mundo, con distancia mínima de frenado para que no se estampe contra las cosas), turn, y stop_everything, que cancela todas las tareas en curso y clava la velocidad en cero. Arriba de eso, un catálogo de las posturas y gestos del G1 — sentarse, agacharse, saludar, dar la mano, abrazar — veinte herramientas en total.
Y funciona, de punta a punta: el robot camina uno o dos metros por comando, rota 90° o 180° a pedido, y reporta dónde está todo el tiempo.
También está lleno de las rarezas que hacen divertida a la robótica. La política de caminata del simulador es tan conservadora que la velocidad efectiva es el 10–15% de lo que comandás. El multicast de DDS no funciona bien en macOS, así que el bridge escribe a mano una config unicast.
Se lo puede ver razonando sobre la diferencia entre lo que pidió y lo que consiguió: “moved 0.74 m of the 1 m target before reaching stop_distance”, y en el giro, “total 177° — within 3° of the 180° target, finished cleanly.”
Qué aprendí
MCP resulta ser una interfaz sorprendentemente buena para robótica. Las habilidades son solo herramientas con esquemas JSON; el modelo nunca necesita saber que existen los topics de DDS o los modos del firmware. Y tener un modelo de frontera como conductor desde el día uno significó validar toda la interfaz de habilidades en horas en vez de semanas.
Lo que sigue
Claude Code como conductor es un arranque, no el destino — el flujo de control vive adentro de un editor de código en mi laptop, y nadie más puede usarlo. Próximo paso: sacar el agente a un backend propio con una interfaz de verdad. Eso es la parte 2.
Todo el proyecto es open source: github.com/mercho40/C3PO.