Uno de los creadores de OpenBDX, la versión abierta de los droides bípedos BDX de Disney, contó en Make Magazine cómo un grupo de aficionados pasó de un paper académico a un robot que camina solo. Los archivos completos y la guía de armado se consiguen registrándose en OpenBDX.org.
El autor vio por primera vez los droides BDX de Disney en la Nvidia GTC de marzo de 2024, en San José. Moritz Bächer presentaba el trabajo de Disney Research "Design and Control of a Bipedal Robotic Character", y Disney llevó tres droides a la sala de la conferencia, Besh (azul), Grek (verde) y Oskar (naranjo).
"Eran los robots más realistas que había visto, pero lo notable no era que cumplieran una tarea. Era que la gente de inmediato los trataba como personajes", escribe. En segundos, el público dejaba de ver motores y lazos de control y veía droides con personalidad. El autor pensó que serían ideales para visitas a hospitales infantiles o para las presentaciones de los grupos de disfraces de Star Wars de los que forma parte. Como casi todos los que los ven, quiso uno, y decidió intentar construirlo. No fue el único.
El paper de Disney se convirtió en el mapa. Mostraba lo suficiente sobre actuación, diseño mecánico y estrategia de control como para que una versión abierta pareciera posible, aunque dejaba muchos detalles prácticos sin resolver.
Cómo empezó OpenBDX
Hasta ese momento, la comunidad de constructores de droides se había enfocado, con razón, en recrearlos de la forma más barata posible. El autor prefirió reducir las incógnitas primero. Siguió la dirección de hardware ya probada, validó el sistema y dejó la optimización para después. El punto más fácil para partir era el diseño mecánico.
Como ingeniero de software sin formación en diseño mecánico, necesitaba una forma de diseñar las piernas en torno a los mismos actuadores que describía el paper de Disney. Encontró la herramienta en Shapr3D, que corre en el iPad, se usa con el Pencil y le hizo el CAD mucho menos intimidante.
Esa primera versión mecánica fue su intento de convertir el paper en algo real, pero el proyecto pronto quedó grande para una sola persona. En junio de 2024, en la DroidCon de Indianápolis, conoció a Mimir Reynisson, otro constructor que ya avanzaba con su propia versión. Mimir tenía un prototipo que se movía, había diseñado PCB para que los Nvidia Jetson se comunicaran con los motores y también había armado una PCB para la cabeza que controlaba los ojos, la lámpara, los sonidos y los servos de las antenas.
Ese encuentro dejó claro que el proyecto podía ser más que una réplica aislada. Necesitaba diseño mecánico, electrónica, firmware, software, simulación, herramientas de animación y un proceso de armado que otros pudieran seguir.
Por su formación, el autor se concentró en la parte de ROS, con la descripción del robot, las interfaces de cámara, la odometría visual, el mapeo, la detección y el seguimiento de objetos, el control SteamDuck desde la Steam Deck y el puente hacia PuddleDuck, el entorno de ejecución de Mimir. Al principio, eso era secundario. La prioridad era que el BDX caminara de forma estable. Mimir lideró gran parte del hardware, el firmware, el entorno de ejecución, el aprendizaje por refuerzo y las herramientas web, entre ellas OpenBDX Studio, Duckmation, GaitForge y Waddlescope.
Más tarde, cuando las piezas impresas de las piernas empezaron a mostrar debilidades alrededor de los motores A1, se sumó Florian Bieregger. Con su formación en ingeniería mecánica empezó a rediseñar las piezas de las piernas para fabricarlas en CNC, un trabajo que terminó en el rediseño mecánico completo y la guía de armado actuales.
¿Cómo está hecho un BDX?
A simple vista, OpenBDX parece un droide más de Star Wars, pero en lo mecánico se acerca más a un humanoide real. Eso lo hace mucho más complejo que un droide tipo astromecánico, porque tiene que equilibrarse, trasladar su peso, coordinar el movimiento de las piernas y aun así parecer un personaje.
Cada pierna tiene cinco grados de libertad, con guiñada, alabeo y cabeceo de cadera, rodilla y tobillo. El pie no tiene una articulación separada de alabeo de tobillo, así que la planta inclinada lo compensa de forma mecánica. La parte superior suma cuatro grados de libertad más, para el cabeceo del cuello, el cabeceo, la guiñada y el alabeo de la cabeza, además de dos servos pequeños para las antenas.
Los actuadores principales de las piernas siguen la línea de hardware inspirada en Disney. Usan motores Unitree A1 para la rodilla, el cabeceo y el alabeo de cadera, y actuadores Unitree Go-M8010-6 para los tobillos, la guiñada de cadera y el cabeceo del cuello. La cabeza usa servos Dynamixel XH540, en versiones de 12 V o 24 V, y las antenas usan servos XC330 o los más nuevos XL330.
El cómputo se reparte entre dos módulos Nvidia Jetson Orin NX, uno en el pecho y otro en la cabeza, conectados por Ethernet. Es más cómputo del que necesita la política de marcha, pero deja espacio para percepción, mapeo, estimación de estado, navegación y conductas más avanzadas sin alterar el control que depende de tiempos estrictos.
Uno de los componentes centrales es PuddleDuck, una placa de pecho diseñada por Mimir. Usa un microcontrolador Teensy para conectar el USB del Orin con seis buses RS485 independientes para los motores. También maneja los amplificadores de audio, la iluminación NeoPixel, las conexiones de la IMU, I2C, CAN y las entradas de radiocontrol por SBUS o radio serial. Así el software tiene un camino limpio para mandar órdenes a los motores y leer la retroalimentación que necesita el control.
La retroalimentación viene de una IMU BNO085 montada en el chasis, de los propios actuadores y de las cámaras a bordo. El robot usa cámaras de profundidad para odometría visual y SLAM, y tiene cámaras adicionales en el pecho y la cabeza para trabajo de percepción. En el sistema de marcha actual, la política recibe una observación de 76 valores y entrega 14 acciones articulares, que PuddleDuck envía a los actuadores mientras devuelve al Orin la retroalimentación fresca de los motores.
La política de marcha y su entrenamiento
Lo más difícil del proyecto nunca fue hacer un droide que se viera bien quieto. Fue hacer uno que se moviera como un personaje sin caerse.
Ahí el BDX se aleja de la mayoría de los droides. Con un astromecánico, un operador humano puede pilotear directo la base y disparar animaciones encima. Con un bípedo pequeño eso no funciona, porque hay catorce articulaciones que coordinar sin pausa.
"Una persona con un control remoto no puede manejar como títere tantos motores en tiempo real y a la vez mantener el robot en equilibrio. Francamente, a la mayoría ya nos cuesta bastante manejar nuestras propias articulaciones", escribe el autor.
El operador elige hacia dónde va el personaje y qué pose o expresión debe hacer, pero el movimiento de las articulaciones lo tiene que resolver el robot.
El paper de Disney apuntaba a la idea correcta. Se usa un movimiento de referencia animado y se entrena una política de control capaz de seguir esas referencias mientras reacciona a la física real de un robot que camina. En OpenBDX entrenan las políticas de marcha en simulación con aprendizaje por refuerzo, sobre todo con MJLab y PPO, y también entrenaron políticas en Isaac Lab que se transfirieron con éxito al droide físico.
El entrenamiento usa referencias de imitación polinomiales generadas con sus propias herramientas de diseño de marcha y luego avanza por un currículo que agrega empujones, variaciones, terreno más irregular y conductas de recuperación. También aplica aleatorización de dominio, variando el peso, la fricción, la respuesta de los motores y otros parámetros físicos para que la política no quede entrenada para un único robot simulado perfecto. El objetivo es una política que mantenga al droide en equilibrio sin perder la personalidad de su andar.
OpenBDX Studio integra parte de este flujo en Gait Forge, un espacio de trabajo para el entorno de pruebas de marcha Automagerie. Gait Forge sirve para ajustar y previsualizar la marcha sobre el paquete de recursos del BDX que se elija. Studio lanza Automagerie con los recursos actuales del robot en vez de mantener una bifurcación aparte. Eso importa porque las herramientas deben seguir conectadas a la misma descripción del robot y a los mismos supuestos de movimiento que alimentan el entrenamiento y el despliegue.
Una vez entrenada, la política se exporta como un modelo ONNX. En el robot, ese modelo corre en el Jetson Orin NX del pecho a través del entorno de ejecución PuddleDuck. En vez de mandar órdenes a cada motor desde el control remoto, el operador envía un vector de comandos compacto con la velocidad hacia adelante y lateral, la tasa de giro, la altura del cuerpo, la pose de cabeza y cuello y la postura del tronco.
La política recibe ese vector junto con los datos de la IMU, las posiciones y velocidades de las articulaciones, las acciones recientes y el historial de objetivos de los motores. Con eso entrega los objetivos articulares para las piernas y la parte superior. PuddleDuck se encarga de la interfaz con los actuadores, que depende de tiempos estrictos.
Este enfoque también les permitió que el droide pareciera vivo mientras se lo maneja. Duckmation, otra parte del ecosistema OpenBDX, crea guiones de gestos que entran por la misma interfaz de la política. Los gestos no son poses fijas que toman el control del robot. Se montan sobre el control en vivo. La dirección de marcha y la tasa de giro siguen en manos del operador, mientras el gesto puede sumar movimiento de cabeza, cuello, tronco, altura y antenas. Así el droide puede seguir caminando o girando mientras ejecuta una expresión, siempre que la política logre mantenerlo de pie.
De la simulación al robot real
Antes de confiarle la política a un droide caro, el equipo la revisó en simulación. Corrieron la política en Isaac Sim como prueba de simulación a simulación, un paso más de verificación antes de llevarla al robot físico. Cuando la política pasó de la simulación al robot, y después de corregir algunos problemas de retroalimentación y otros errores del entorno de ejecución, la transferencia resultó sorprendentemente buena. El robot se comportó muy parecido a como lo hacía en simulación.
"Es exactamente lo que uno espera y rara vez se consigue gratis", escribe el autor.
Su primera prueba de marcha fue en septiembre de 2025, después de las primeras pruebas de Mimir, antes de que estuvieran listas las piezas CNC de las piernas e incluso antes de que el droide tuviera cabeza. Fue un hito, pero todavía se sentía como un banco de pruebas que demostraba un punto.
El momento en que todo se volvió real fue la Denver Fan Expo, en mayo de 2026. En lo mecánico el droide estaba terminado, aunque la marcha seguía inestable. Después de meses de CAD, electrónica, software, simulación, supuestos que fallaron y rediseños mecánicos, el droide por fin caminaba en el mundo real. Ya no era solo un paper, un modelo o un montón de piezas.
Duckmation y los gestos del droide
Caminar es solo una parte de lo que hace que un droide parezca vivo. La otra es cómo mira a su alrededor, reacciona, mueve el cuerpo, agita las antenas, cambia sus luces o reproduce un sonido justo en el momento preciso. Duckmation entrega a los constructores una línea de tiempo para crear esos gestos, con movimiento del cuerpo, la cabeza y las antenas, sonidos, estados de los ojos, de la lámpara y de la barra de luz.
