SDK de robótica, ROS 2 y entornos de simulación

Una plataforma robótica de 2026 —humanoide o cuadrúpeda— llega con tres capas de software con las que hay que lidiar antes de que se ejecute una sola línea de código propio. El SDK del fabricante, que habla con las articulaciones. El wrapper de ROS 2, que habla con todo lo demás. Y el simulador, que se usa porque estrellar contra la pared un Unitree G1 EDU de 43 000 $ es una forma cara de depurar una errata.

Estas tres capas no son intercambiables. El SDK es propietario y de tiempo real. ROS 2 es la lengua franca que permite que el resto del código robótico del mundo funcione con su plataforma. El simulador es donde se hace el trabajo que no se quiere hacer sobre el robot real: aprendizaje por refuerzo, generación masiva de datos, diseño de escenas, CI headless. La mayoría de los equipos invierten de menos en las tres.

Este artículo repasa lo que aporta realmente cada capa en 2026, dónde están los límites y qué combinaciones merece la pena montar con el presupuesto real de un laboratorio de robótica. Las plataformas de referencia son las de R01 y R02. La computación de referencia es la gama Kentino AI (4× u 8× RTX 5090 o RTX Pro 6000 Blackwell, con host EPYC o Xeon).

La capa del SDK: qué le dan realmente los fabricantes

Todo fabricante de robots solvente entrega un kit de desarrollo de software. El nombre es el mismo; el contenido, no. Esto es lo que hay realmente en la caja.

Hay dos divisiones que importan más que el resto.

Abierto frente a cerrado. Unitree, Booster, EngineAI y DeepRobotics dan acceso a nivel de articulación. Se pueden enviar comandos de par de 500 Hz a 1 kHz directamente a los actuadores. Eso es lo que hace falta para desplegar políticas de aprendizaje por refuerzo, para investigación en locomoción a medida y para cualquier cosa dinámica. Boston Dynamics y ANYbotics mantienen cerrado el control articular: se obtienen primitivas de alto nivel (camina hasta aquí, trepa eso, manipula esto), el SDK las expone como llamadas RPC y el trabajo articular lo hace el controlador de la propia empresa. Es una decisión deliberada. El stack cerrado es más fiable y el software de autonomía es por lo que se pagan de 74 000 $ a 200 000 $. También es el stack equivocado si su investigación está en el control de bajo nivel.

Tiempo real frente a lo demás. Unitree SDK2 usa Cyclone DDS sobre una interfaz de red dedicada y ofrece una ida y vuelta de menos de un milisegundo en el bucle articular. El stack de Booster es similar. El SDK de Spot es gRPC sobre HTTP/2: perfecto para ordenar un comportamiento, inútil para cerrar un bucle de control a 1 kHz. Si su trabajo necesita un bucle de menos de 2 ms, la arquitectura importa más que el lenguaje.

Una nota sobre la cuestión de Python. Todos los fabricantes ofrecen bindings de Python. Ninguno de ellos es el lenguaje en el que corre el bucle de control. El patrón es idéntico en todo el sector: C++ para el controlador en tiempo real, Python para todo lo que está por encima. Los SDK de los fabricantes lo reflejan: los bindings de C++ exponen más, van más rápido y son aquellos en los que están escritos los propios ejemplos del fabricante. Los bindings de Python son de primera clase para el trabajo de alto nivel y un envoltorio para la vía de bajo nivel. Elija C++ cuando escriba el bucle de control interno y Python para la orquestación, la integración de la percepción y la conexión con el servidor de inferencia.

ROS 2: por qué todo el mundo lo adopta como norma

El SDK nativo le pone dentro del robot. ROS 2 le pone dentro del ecosistema.

Hay tres razones por las que toda integración seria acaba hablando ROS 2, incluso cuando el SDK del fabricante basta:

1. Interoperabilidad. Su stack de percepción, su SLAM, su navegación, su planificador de manipulación, su teleoperación: todos tienen implementaciones en ROS 2 mantenidas por cientos de colaboradores. Ninguna habla de forma nativa el formato de topics DDS de Unitree. Basta con envolver el SDK una vez en mensajes de ROS 2 para que se abra todo el ecosistema.
2. Flotas multifabricante. El día que añada un segundo robot de otro fabricante, el enfoque del SDK nativo se viene abajo. ROS 2 es la única abstracción que permite que un Spot, un ANYmal y un G1 compartan el mismo servidor de mapas, el mismo grafo de tareas y la misma interfaz hombre-máquina.
3. Contratación. La gente conoce ROS 2. No conoce las convenciones de nomenclatura de topics DDS de Unitree. Un equipo que construye sobre ROS 2 puede contratar en un mercado global. Uno que construye sobre un stack propietario, no.

Estado de las distribuciones de ROS 2, mayo de 2026:

La lectura honesta. Los despliegues en producción siguen hoy sobre Humble. Humble es la LTS a la que apuntan los fabricantes: unitree_ros2 de Unitree, el stack de Booster, el spot_ros2 de la comunidad y el grid_map de ANYbotics tienen todos ramas estables para Humble. Jazzy es donde deberían arrancar los proyectos nuevos: le quedan otros tres años de vida LTS y las herramientas de migración están maduras. Lyrical Luth es demasiado nueva para comprometerse con ella; dele hasta finales de 2026 antes de montar un sistema de producción encima.

Si empieza un proyecto en mayo de 2026, vaya con Jazzy. Si amplía uno iniciado en 2023, siga en Humble hasta que la siguiente compra de robot obligue a migrar. Descarte Iron y Kilted por completo; las versiones no LTS son para quien quiere seguir de cerca las actualizaciones de Gazebo Harmonic y aceptar el peaje de mantenimiento.

La separación del bucle de control

Esta es la decisión arquitectónica que pilla desprevenidos a la mayoría de los equipos.

La separación del bucle de control: abajo, la capa del SDK en C++ y tiempo real; arriba, la orquestación en Python sobre ROS 2, conectadas a 10–50 Hz mediante mensajes de estado por DDS.

El bucle de control se queda en el robot, en C++. La capa de alto nivel corre en nodos de ROS 2, ya sea en el procesador de aplicaciones del robot (Jetson Orin AGX) o, para trabajos más pesados, en el servidor de inferencia externo (véase I01). Las dos capas se comunican a 10–50 Hz por DDS. No comparten proceso.

Esta separación no es opcional. Un nodo de ROS 2 en Python no puede cerrar un bucle articular a 1 kHz: solo el recolector de basura ya lo hace imposible. Intentarlo es el error más habitual en el primer año de trabajo con humanoides. El SDK del fabricante existe precisamente para que no tenga que hacerlo.

Cuándo necesita un simulador (y cuándo no)

El simulador es obligatorio para cuatro tipos de trabajo:

• Aprendizaje por refuerzo. No se puede entrenar una política de locomoción desde cero sobre un robot real. El robot se rompería, el entrenador dimitiría y el coste sería desmesurado. El aprendizaje por refuerzo ocurre en simulación: millones de episodios, miles de entornos en paralelo.
• Generación masiva de datos. Datos sintéticos para el fine-tuning de VLM, comprensión de escenas, agarres de manipulación. Los equipos más punteros (R09) generan cientos de miles de escenas etiquetadas de un día para otro.
• CI headless. Querrá que cada push a git compruebe que el robot sigue caminando. Hacerlo sobre el hardware es impracticable; una ejecución nocturna en simulación que ejercite el stack de locomoción y percepción, no.
• Diseño de entornos. Distribuir un almacén, una celda de fábrica o un laboratorio y saber si el robot podrá moverse por él antes de construirlo.

No necesita un simulador para:

• Prototipado inicial. Si está escribiendo una demo de «haz que el robot salude», el simulador es un lastre. Use el robot real.
• Manipulación sencilla. Coger una caja, abrir un cajón. En estas tareas, la brecha entre simulación y realidad suele ser mayor que el tiempo que habría invertido haciéndolo sobre el robot real.
• Desarrollo de teleoperación. Todo el sentido de la teleoperación es el humano en el bucle. La simulación no ayuda.
• Comportamientos puntuales. Cualquier cosa que vaya a ejecutar dos veces y después desechar.

El error que cometen los equipos es tratar el simulador como la opción por defecto. No lo es. Es una herramienta para los cuatro casos anteriores, más el evidente caso de seguridad de «no quiero estrellar el robot real».

Los simuladores de 2026

Hay cuatro simuladores que cuentan en robótica con patas en 2026. No son equivalentes y la elección es cuestión de criterio.

Las cifras de la columna de entornos en paralelo son prácticas, no teóricas. Dependen de la complejidad del modelo. Un brazo Franka admite más entornos en paralelo que un humanoide de 41 grados de libertad con manos diestras.

Isaac Sim e Isaac Lab: la apuesta de NVIDIA

Isaac Sim es el simulador fotorrealista y acelerado por GPU construido sobre el stack Omniverse. Isaac Lab es el framework de aprendizaje robótico que se apoya en él. Juntos son la respuesta de NVIDIA a cualquier pregunta sobre simulación en robótica.

Lo que hace bien:

• Renderizado fotorrealista. Iluminación por trazado de rayos, materiales fieles, modelos de cámara realistas. Si su stack de percepción necesita aprender qué aspecto tiene realmente el mundo, este es el único simulador que lo ofrece a escala.
• Física acelerada por GPU. Los entornos en paralelo residen en la memoria de la GPU. Una sola RTX 5090 ejecuta miles de instancias de humanoide a cientos de pasos de física por segundo.
• Isaac Lab. Un framework de aprendizaje por refuerzo limpio, con soporte integrado para RSL RL, RL-Games, SKRL y Stable Baselines3. Entre los más de 16 modelos de robot preconstruidos están el G1, el H1, Spot, ANYmal, Franka y una lista creciente de recién llegados.
• Integración con GR00T. El stack de modelos fundacionales para humanoides de NVIDIA vive aquí. Si quiere entrenar una política de visión-lenguaje-acción y desplegarla en varias plataformas, este es el camino.

Lo que hace mal:

• El dolor de instalar Omniverse. El runtime de Omniverse es rígido, pesado y poco amable con una instalación estándar de Ubuntu. Cuente con un día peleándose con el lanzador, el servidor Nucleus y la caché de recursos antes de ejecutar su primera simulación.
• Dependiente de la GPU. Isaac Sim no funciona en CPU. Tampoco funciona bien con una sola 4090. La configuración de referencia es una 5090 como mínimo, preferiblemente una Pro 6000 Blackwell, y un host EPYC que alimente los datos.
• Poco flexible. Los formatos de recursos son USD. La física es PhysX. El renderizado es RTX. Si quiere otro motor de física, se ha equivocado de simulador.

La realidad del cómputo. Un servidor Kentino AI con 4× RTX 5090 ejecuta con holgura un entrenamiento de humanoide en Isaac Lab: de 4,000 a 8,000 entornos en paralelo, fotorrealismo completo a 30–60 FPS de renderizado y convergencia de la política en una tarea de locomoción en 6–24 horas. Con 8× 5090 se escala más o se ejecutan varios experimentos en paralelo. La Pro 6000 Blackwell es la elección correcta cuando la memoria es el factor limitante (lotes grandes, bibliotecas de recursos de humanoide más extensas).

MuJoCo y MJX: la respuesta centrada en la física

MuJoCo es el simulador de física de DeepMind. MJX es la reescritura en XLA / JAX que ejecuta MuJoCo en la GPU con batching completo. MJWarp es un esfuerzo conjunto más reciente de NVIDIA y Google que escribe MuJoCo en Warp y escala mejor en escenas con muchos contactos.

Lo que hace bien:

• Velocidad. Física pura de cuerpos rígidos rica en contactos, escrita para la GPU desde cero. En una sola RTX 5090, MJX ejecuta miles de entornos de humanoide a un número de pasos de física por segundo que Isaac Sim no alcanza con la misma complejidad de escena.
• Determinismo. Misma semilla, misma trayectoria. Que el aprendizaje por refuerzo sea reproducible es una ventaja.
• El respaldo de DeepMind. Todos los artículos importantes de robótica de DeepMind de los últimos cinco años usan MuJoCo. Las bibliotecas de modelos (MuJoCo Menagerie) incluyen el G1, el H1, Spot, ANYmal, el brazo Franka y la Shadow Hand.
• Más sencillo. Sin Omniverse, sin USD, sin Nucleus. Pip install y a correr.

Lo que hace mal:

• Renderizado visual. El renderizador de MuJoCo es de la era de OpenGL. Suficiente para visualizar, inútil para generar datos fotorrealistas.
• Ecosistema de recursos. Más reducido que el de Isaac. La importación de URDF funciona, pero el acabado es menor.
• Modelos de sensores. Los modelos de cámara, profundidad y LiDAR son básicos. Si su política depende de un ruido de sensor realista, tendrá que construir esos modelos usted mismo.

La realidad del cómputo. Una sola RTX 5090 ejecuta entre 4,000 y 16,000 entornos de humanoide en MJX en paralelo, según la complejidad de los contactos. Un servidor Kentino AI con 4× 5090 puede ejecutar más de 50,000 entornos de humanoide en paralelo para aprendizaje por refuerzo de locomoción. Estas son las cuentas que tienen a DeepMind y a la mayoría de los laboratorios académicos trabajando con MuJoCo en el bucle interno del entrenamiento de políticas.

Gazebo Harmonic: el nativo de ROS 2

Gazebo es el simulador de código abierto que lleva dos décadas siendo el estándar de ROS. Gazebo Harmonic es la LTS actual y se integra limpiamente con ROS 2 Humble y Jazzy.

Lo que hace bien:

• Integración con ROS 2. De primer nivel. El puente ros_gz hace que sus nodos de ROS 2 funcionen en simulación sin ningún cambio.
• Abierto y gratuito. Sin licencia, sin Omniverse, sin dependencia de NVIDIA. Funciona en CPU, en GPU de AMD, en lo que sea.
• Idóneo para pruebas de integración. Cuando el objetivo es «comprobar que el stack de navegación y el planificador siguen funcionando tras una refactorización», Gazebo es la elección correcta.

Lo que hace mal:

• Lento. Física monohilo y renderizado por software por defecto. Los entornos en paralelo implican levantar varios procesos de Gazebo. En Gazebo no se entrenan políticas de aprendizaje por refuerzo; se hacen pruebas rápidas.
• Poco amigable con la GPU. Sin batching en GPU. Añadir aceleración del renderizado ayuda, pero no cambia el escalado de fondo.
• Mayor brecha entre simulación y realidad. El modelo de contactos es menos riguroso que el de MuJoCo y los modelos de sensores, menos realistas que los de Isaac.

La realidad del cómputo. Gazebo funciona con lo que tenga. El servidor Kentino AI es excesivo para él; con un portátil basta. La contrapartida es que, para cualquier carga de aprendizaje por refuerzo no trivial, se le quedará pequeño en cuestión de días.

Genesis: el aspirante académico de alto rendimiento

Genesis es el simulador multiinstitucional que apareció a finales de 2024 con afirmaciones de rendimiento audaces y que desde entonces ha demostrado casi todas. Contribuyeron CMU, Stanford, el MIT CSAIL, NVIDIA y Tsinghua.

Lo que hace bien:

• Rendimiento. Genesis supera los 40 millones de FPS en una sola RTX 4090 para una carga de cinemática inversa de un Franka. En humanoides la cifra es menor, pero sigue en los millones. La arquitectura está construida desde el principio en torno a la simulación masivamente paralela.
• Multifísica. Rígida, fluidos, cuerpos blandos, granular, MPM. Si su tarea implica algo distinto del contacto rígido (manipulación de deformables, vertido de líquidos, interacción granular), Genesis es el único simulador de esta lista que lo gestiona de forma nativa.
• Herramientas generativas de escenas. Genesis incorpora generación de escenas a partir de prompts. Usted describe un entorno con texto y obtiene una escena.

Lo que hace mal:

• Ecosistema más nuevo. Menos modelos preconstruidos, menos tutoriales y una comunidad más pequeña que la de MuJoCo o Isaac.
• Menos contrastado en la transferencia a la realidad. La física es rápida; si transfiere tan bien como MuJoCo al hardware es algo que la comunidad aún está estableciendo.
• Lagunas en la documentación. Algo habitual en proyectos de investigación en rápida evolución.

Dónde encaja en 2026. Genesis es la elección correcta para el aprendizaje por refuerzo de corte académico, cuando se busca el máximo rendimiento en número de entornos y se está dispuesto a escribir más código propio de integración. Para una canalización de transferencia a la realidad en producción hoy, MuJoCo o Isaac son la apuesta más segura. Conviene no perderlo de vista.

La realidad de la transferencia a la realidad, edición 2026

El estado práctico de la transferencia de simulación a realidad en mayo de 2026:

• La aleatorización de dominio es obligatoria. No se puede entrenar con un único conjunto de parámetros físicos y esperar que transfiera. Masa, fricción, retardos de los motores, ruido de los sensores, latencia: todo eso se aleatoriza dentro de un rango durante el entrenamiento.
• El retardo de actuación importa más de lo que se admite. Los actuadores de un robot real tienen entre 5 y 25 ms de retardo entre el comando y el par. Una simulación sin ese retardo produce políticas que oscilan sobre el hardware. Incorpore el retardo a la simulación desde el primer día.
• Hay que inyectar ruido de sensor. Deriva de la IMU, ruido de cámara, pérdidas del sensor de profundidad. Los artículos de 2026 que funcionan incluyen todo esto en el entrenamiento.
• El entrenamiento multisimulador es la vanguardia. PolySim y otros frameworks similares entrenan simultáneamente sobre MuJoCo + Isaac y, a veces, Gazebo. Los primeros resultados son buenos. El coste de cómputo es de 2 a 3 veces el del entrenamiento con un solo simulador.
• El movimiento de humanoides con carga sigue siendo difícil. Transportar una carga útil o recuperarse de un empujón mientras se lleva algo: estas tareas siguen degradándose entre un 50 y un 80 % al pasar de la simulación a la realidad en las plataformas de R01.

Cuente con que dos tercios de su rendimiento en el mundo real vendrán de la simulación. Y con que el tercio restante será ajuste fino sobre el hardware, identificación del sistema y depuración obstinada.

Receta concreta: G1 + ROS 2 Humble + Isaac Lab en un servidor Kentino AI

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 grados de libertad)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (la Pro 6000 para la simulación, las 5090 para el entrenamiento por lotes)
  - Punto de acceso Wi-Fi 6E, con línea de visión a la zona de trabajo
  - Conmutador 10 GbE, enlace por cable del Kentino AI al punto de acceso

Software en el servidor Kentino AI:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (runtime de Omniverse, Nucleus local)
  - ROS 2 Humble (o Jazzy, si se empieza de cero hoy)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM sirviendo un VLM para la percepción de alto nivel (véase I02)
  - MuJoCo + MJX como segundo simulador, para validación cruzada

Software en el G1:
  - Unitree SDK2 (bucle de control articular en C++)
  - unitree_ros2 (Humble) en la Jetson
  - Nodos ROS 2 propios: command_router, perception_relay
  - Cliente gRPC hacia vLLM en el servidor Kentino AI

Flujo de trabajo:
  1. Entrenar una política de locomoción o de cuerpo completo en Isaac Lab
     sobre la Pro 6000 (más de 4,000 instancias G1 en paralelo, RSL RL).
  2. Validar la política en MJX (4× 5090 por lotes) con distintas
     semillas de aleatorización de dominio.
  3. Desplegar la política mediante TorchScript en la Jetson del G1,
     envuelta en un nodo ROS 2 que invoca el bucle de control de Unitree SDK2.
  4. Los comandos de alto nivel de ROS 2 fluyen desde el grafo de tareas
     del laboratorio a la política a través del command_router.
  5. La percepción pesada (VLM) reside en el servidor Kentino AI, al que se
     accede por Wi-Fi 6E + gRPC.

El tiempo total de puesta en marcha para un equipo con experiencia previa en ROS 2 es de dos a tres semanas. Para un equipo que aprende ROS 2 desde cero, de dos a tres meses. Planifique en consecuencia. La parte de cómputo del servidor Kentino AI es la más sencilla.

La valoración honesta

Tres opiniones, sin rodeos:

1. ROS 2 es la capa de abstracción correcta. Los SDK nativos son necesarios, pero no suficientes. Construya sobre el wrapper de ROS 2 y trate el SDK del fabricante como un servicio que ese wrapper consume. Irse a lo propietario no le aporta nada y le cuesta el resto del ecosistema.
2. Isaac Sim es el futuro, pero el presente de la mayoría de los equipos es MuJoCo + ROS 2. Si su trabajo es aprendizaje por refuerzo en locomoción y manipulación diestra, MuJoCo / MJX es la opción más barata, más rápida y más fácil de desplegar. Si su trabajo es percepción fotorrealista, generación masiva de datos o fine-tuning de modelos fundacionales de tipo VLA, Isaac es la única opción. La mayoría de los laboratorios necesitan ambos, y el servidor Kentino AI tiene margen para ejecutar los dos.
3. Los laboratorios más punteros usan los cuatro. Isaac para el renderizado y la canalización de modelos fundacionales. MuJoCo para el bucle interno de aprendizaje por refuerzo. Gazebo para las pruebas de integración de ROS 2. Genesis para el trabajo multifísica. Creer que solo necesitará uno es la forma en que los equipos acaban reescribiendo su stack un año después.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.