Un brazo robótico es fácil de fotografiar y difícil de reproducir. Dos laboratorios pueden comprar hardware nominalmente idéntico, ejecutar la misma política y aun así recopilar datos con posiciones de cámara, iluminación, rutinas de calibración, ajustes del controlador y definiciones de tarea diferentes. Cuando el resultado mejora, resulta complicado saber si el modelo aprendió algo mejor o si el experimento simplemente cambió a su alrededor.

Un brazo robótico colaborativo genérico en una celda de evaluación de investigación estandarizada, con cámaras y objetos de calibración.

Ese es el problema que OpenArm 2.0 intenta abordar. El proyecto de Enactic se presenta como un brazo humanoide de siete grados de libertad y código abierto, pero el cambio importante va más allá del mecanismo. La línea 2.0 combina el brazo con una celda de evaluación, un formato de datos, entornos de simulación, paquetes para ROS 2, flujos de teleoperación y un futuro dispositivo pasivo de enseñanza. El objetivo es hacer que los experimentos de IA física puedan trasladarse entre máquinas y, con el tiempo, entre laboratorios.

El proyecto ha despertado interés porque, según sus propios materiales, el hardware resulta especialmente accesible para los estándares de la robótica de investigación: un sistema bimanual completo se anuncia por 6.500 dólares, con opciones ensambladas y DIY. El precio importa, pero no es la razón más sólida para prestarle atención. La idea de mayor alcance es tratar el robot como una plataforma reproducible de software y datos, no como un montaje de investigación único.

OpenArm sigue en desarrollo activo. Su documentación señala puentes de hardware inestables, trabajo en curso con MoveIt 2 y un dispositivo KER que todavía no se ha publicado. Por eso, la pregunta sensata no es si ya está listo para sustituir todas las plataformas de laboratorio. Es si la pila abierta resulta útil para una clase concreta de investigadores y si sus limitaciones están suficientemente visibles como para gestionarlas.

Qué añade realmente OpenArm 2.0

OpenArm 1.0 estableció la propuesta básica: un brazo de escala humana con diseños de hardware, software y documentación públicos. La versión 2.0 conserva el volumen mecánico central, pero reorganiza el proyecto alrededor de un flujo de trabajo. La presentación de la versión 2.0 de Enactic describe tres piezas conectadas: el brazo OpenArm 2.0, OpenArm Cell y OpenArm KER. Este último aún no se ha lanzado, así que debe entenderse como un componente previsto y no como algo que los compradores puedan utilizar hoy.

El brazo sigue siendo un diseño de siete grados de libertad montado sobre una base con estructura MISUMI. Las especificaciones publicadas indican una carga útil nominal de 4,1 kilogramos y una carga útil máxima de 6,0 kilogramos, incluido el efector final. Esas cifras sirven para entender el margen de investigación previsto, pero no prometen que cualquier carga sea segura en todas las posturas o movimientos. La documentación define el valor nominal bajo una condición de peor postura durante un minuto y lo distingue de una carga máxima de corta duración. Una pinza, cámara, herramienta o soporte personalizado consume parte de ese presupuesto.

La OpenArm Cell es la incorporación más importante para la reproducibilidad. Ofrece un entorno estandarizado con fondo, iluminación y colocación de cámaras consistentes. Puede parecer un detalle menor hasta que un equipo intenta comparar demostraciones grabadas con meses de diferencia. Cambiar la altura de una cámara situada en el techo puede alterar el tamaño aparente de un objeto. Otra luz puede modificar los reflejos de una taza o el contraste alrededor de un cable. Una superficie distinta en la mesa puede convertir un agarre aprendido en un truco específico del benchmark.

Una celda no elimina todas las fuentes de variación, pero crea una referencia común. El sitio del proyecto describe la celda como una forma de apoyar la evaluación automática y comparar políticas robóticas entre iteraciones. Es una promesa más útil que la afirmación habitual de que el hardware abierto democratizará la robótica. Reducir el coste de una plataforma ayuda a que más personas puedan obtenerla; estandarizar el experimento ayuda a que puedan aprender unas de otras.

El tercer componente, KER, está diseñado como un dispositivo de enseñanza pasivo y sin motores. Enactic afirma que su diseño sin actuadores es lo bastante ligero para llevarlo puesto o montarlo cerca del operador, con la intención de reducir la fatiga durante sesiones largas de teleoperación. También deja claro que todavía no está disponible. La distinción importa porque la recopilación de datos actual depende de las herramientas ya publicadas: teleoperación mediante VR/WebXR, simulación y control directo del brazo físico.

La verdadera oferta es la pila de software

El repositorio está dividido en piezas que corresponden a tareas de investigación reconocibles. El proyecto principal enlaza con CAD del hardware, una descripción del robot, una biblioteca de control CAN, integración con ROS 2, nodos de teleoperación, entornos de simulación, una biblioteca de datasets y conexiones con Dora, un marco de flujo de datos. La guía de software describe la pila como un conjunto de componentes para la descripción del robot, el control de motores de alta frecuencia, la configuración CAN, el middleware ROS 2 y procesos Python independientes para control, grabación e inferencia.

Esa modularidad es valiosa porque los equipos de robótica rara vez coinciden en un único marco completo. Un grupo puede querer ROS 2 para los controladores y MoveIt 2 para la planificación, MuJoCo para los experimentos de dinámica, un servidor de políticas propio para la inferencia y un formato de almacenamiento separado para las demostraciones. OpenArm no obliga a reunir todos esos intereses en una aplicación monolítica. Expone interfaces que pueden sustituirse o ampliarse.

La contrapartida es que el usuario hereda el trabajo de integración. «Abierto» no significa «un comando y listo». La guía de instalación está construida alrededor de Ubuntu y recomienda ROS 2 Humble, mientras que el soporte para Jazzy se describe como trabajo en curso y potencialmente inestable. El paquete de ROS 2 requiere dependencias de controladores e interfaces de hardware. El hardware real necesita interfaces CAN y la biblioteca de bajo nivel correspondiente. Un equipo sin experiencia en ROS tendrá que aprender el middleware antes de llegar al experimento que le interesa.

La documentación de control de ROS 2 marca con claridad esa frontera. El paquete puede exponer comandos de posición, velocidad y par, y puede ejecutarse contra hardware simulado, algo útil para las pruebas. Pero la misma página advierte que los componentes de puente hacia el hardware se están actualizando, que el puente de la pinza está especialmente activo y que la integración con MoveIt 2 sigue en desarrollo. No son advertencias marginales: definen la diferencia entre una plataforma de investigación prometedora y un robot de producción maduro.

Una evaluación práctica debería comenzar con la ruta de hardware ficticio. Si un equipo no puede iniciar la descripción del robot, inspeccionar los estados de las articulaciones y ejecutar un bucle de control simulado, comprar el brazo no eliminará el problema de software. Añadirá motores, electrónica de potencia, calibración, límites mecánicos y procedimientos de seguridad.

La simulación sirve antes de que llegue el robot

El soporte de OpenArm para MuJoCo proporciona al proyecto una entrada más sólida que un kit basado únicamente en hardware. La guía de simulación ofrece archivos MJCF para el brazo y para la configuración bimanual, además de explicar cómo cargarlos en el simulador de MuJoCo. El proyecto utiliza control de par en la simulación, más cercano al problema de control que debe resolver un equipo de investigación que una simple animación de ángulos articulares.

La documentación también presenta la simulación como un lugar donde probar el flujo de recopilación de datos. Con WebXR, un investigador puede usar controladores de realidad virtual para operar una versión MuJoCo del brazo, grabar episodios, inspeccionar los datos resultantes y convertirlos a un formato de entrenamiento sin poseer todavía el hardware físico. El tutorial de WebXR incluye un recorrido completo por una interfaz local de recopilación de datos, un controlador de realidad virtual basado en navegador, etiquetas de éxito y fracaso y un directorio de salida OpenArmDataset.

Ese orden cambia la forma de reducir el riesgo de un proyecto. Un equipo puede preguntar primero si un operador puede realizar la tarea de manera fiable. Después puede comprobar si la representación de la tarea registra las observaciones necesarias. También puede construir la canalización de entrenamiento de una política y determinar si la interfaz de inferencia es suficientemente rápida. Solo entonces tiene que enfrentarse al coste y a los requisitos de seguridad del brazo real.

La simulación no revelará todo. La dinámica de contacto, el arrastre de los cables, la temperatura de los motores, el juego mecánico, el ruido de los sensores, la variabilidad de los objetos y el comportamiento de la parada de emergencia pueden invalidar una política que se vea bien en MuJoCo. La propia guía indicaba que el puente de ROS 2 para simular hardware de forma realista todavía estaba pendiente después de la versión anterior. La simulación debe tratarse como una herramienta de integración e iteración, no como una prueba de que el despliegue físico funcionará.

Hay otra complicación práctica: WebXR requiere HTTPS. El tutorial pide generar un certificado, abrir una página local y aceptar un certificado autofirmado en el dispositivo de realidad virtual. Es manejable en un laboratorio, pero pertenece exactamente a esa clase de detalles que desaparecen de un anuncio de lanzamiento y consumen una tarde durante la configuración. La documentación resulta valiosa porque muestra el problema antes del experimento.

La capa de datasets aborda un problema olvidado

Los proyectos de robótica suelen publicar un modelo y un vídeo breve de demostración mientras dejan implícita la canalización de datos. Eso dificulta reproducir un experimento incluso cuando el hardware está disponible. El trabajo de OpenArm con datasets intenta convertir el episodio en un artefacto de primera clase.

La documentación del dataset describe una estructura de directorios que contiene episodios, datos de acciones y estados, secuencias de cámara, metadatos e información de la tarea. La API está diseñada alrededor de un directorio en disco, no de un servicio de base de datos. Los metadatos se leen por adelantado, mientras que el resto de los datos puede consultarse cuando haga falta. Es una forma razonable de trabajar con grabaciones grandes: los equipos pueden mover un dataset como archivos ordinarios, inspeccionar sus metadatos y procesar solo las cámaras o episodios necesarios para un trabajo determinado.

La referencia de la API documenta cambios en la distribución de datasets 0.3.0. Los datos de estado se dividen en tablas de posición, velocidad y par para cada lado del brazo, mientras que los formatos antiguos pueden exponer únicamente datos de posición. La biblioteca también incluye una vía de conversión a LeRobot v2.1 mediante Python y mediante un punto de entrada de línea de comandos. Ese puente importa porque un formato específico del proyecto solo resulta útil si los investigadores pueden llevar sus datos al ecosistema más amplio.

El formato no hace que un dataset sea comparable por arte de magia. Los investigadores aún deben registrar la calibración de las cámaras, la versión del robot, la configuración de la pinza, la identidad del objeto, las instrucciones de la tarea, los datos del operador, la sincronización temporal, los intentos fallidos y las condiciones ambientales. Una estructura de archivos coherente es el suelo, no el techo. La ventaja es que OpenArm ofrece un lugar para esos campos y una API, en vez de pedir a cada laboratorio que invente sus propias convenciones.

Los controles de éxito y fracaso del tutorial de WebXR también son importantes. Los sistemas de aprendizaje son sensibles a qué se considera un episodio exitoso. Si un equipo deja de grabar después de un agarre casi logrado y otro etiqueta como éxito únicamente las colocaciones completadas, sus datasets no son intercambiables aunque coincidan los robots y las cámaras. Marcar explícitamente los episodios no elimina el etiquetado subjetivo, pero hace visible la decisión y permite que la máquina la lea.

La inferencia está separada del tiempo de ejecución del robot

El flujo de inferencia de OpenArm establece una frontera útil entre el código de la política y el control robótico. La guía de inferencia describe un servidor de políticas que recibe un paquete de observaciones con datos de cámara y posiciones articulares, ejecuta un modelo y devuelve un bloque de acciones de posición articular. El tiempo de ejecución se organiza como un flujo de datos de Dora, mientras que el código específico del modelo vive detrás de un contrato de socket local.

Esa separación ofrece varias ventajas. El autor de una política puede adaptar un modelo sin reescribir el transporte del hardware. Un equipo puede reemplazar el servidor del modelo y conservar estable la conexión de observaciones y acciones. Un fallo en el proceso del modelo puede gestionarse como un evento de nivel de proceso, sin quedar mezclado con cada función de control de motores. La interfaz también es más fácil de inspeccionar: entradas, salidas, marcas temporales y dimensiones de las acciones pueden probarse de forma independiente.

La frontera no constituye un sistema de seguridad completo. Devolver un bloque JSON válido de acciones no hace que una acción sea segura. El controlador sigue necesitando límites, comportamiento de vigilancia, gestión de colisiones, una parada de emergencia física y un operador capaz de intervenir. Un modelo que funciona bien en una repetición fuera de línea puede producir comandos peligrosos cuando una cámara queda obstruida o un estado articular llega con retraso. La pila abierta permite revisar estas capas, pero la responsabilidad continúa siendo del integrador.

Aquí es donde conviene interpretar con cuidado las afirmaciones de OpenArm sobre cumplimiento y retroaccionabilidad. Describen propiedades mecánicas pensadas para facilitar trabajos con mucho contacto y una interacción más segura. No eliminan la necesidad de una evaluación de riesgos, pruebas protegidas, velocidades conservadoras ni un margen operativo claro. Que una persona pueda mover un robot no significa automáticamente que sea seguro alrededor de cualquier persona, objeto o política de control.

Quién debería probarlo ahora

OpenArm 2.0 parece adecuado para investigadores que quieran estudiar aprendizaje por imitación, teleoperación, manipulación bimanual, aprendizaje robótico a partir de demostraciones o evaluación de políticas en una celda controlada. También resulta interesante para ingenieros que construyen herramientas alrededor de datasets de IA física, transferencia de simulación a realidad, control con ROS 2 e inferencia local. Poder comenzar en MuJoCo y avanzar después hacia el hardware proporciona a estos grupos una ruta de desarrollo concreta.

Puede ser especialmente útil para laboratorios académicos pequeños e investigadores independientes que no pueden justificar una plataforma de investigación propietaria, pero sí construir un sistema alrededor de CAD público, componentes comerciales y middleware abierto. La opción DIY también cambia la relación entre el investigador y la máquina. El equipo puede inspeccionar la lista de materiales, adaptar soportes, entender la ruta de control y aportar mejoras al proyecto. Es un entorno de aprendizaje más fértil que un robot sellado cuyo modo de fallo se reduce a «contacte con el proveedor».

Es menos apropiado para un grupo que necesite una celda de producción llave en mano, un contrato de soporte a largo plazo, certificación industrial de seguridad validada o compatibilidad garantizada con una pila fija de automatización comercial. También es una mala primera experiencia en robótica para quien no tenga interés en Linux, ROS 2, la depuración electromecánica o la ingeniería de datasets. El precio de compra, bajo en comparación con otros robots de investigación, no convierte el coste total en bajo. El laboratorio seguirá necesitando ordenadores, hardware de alimentación y comunicaciones, herramientas, cámaras, equipos de realidad virtual si utiliza WebXR, piezas de repuesto, soportes y tiempo.

Un primer proyecto sensato debería ser limitado: un objeto, un espacio de trabajo, una configuración de pinza y un número reducido de demostraciones de operadores. La meta tendría que ser medir el ciclo completo —grabación, etiquetado, entrenamiento, inferencia y recuperación—, no producir una demostración espectacular. Si el equipo puede reproducir su propio resultado después de cambiar de máquina o reconstruir el espacio de trabajo, habrá aprendido algo importante sobre la plataforma.

Qué revisar antes de comprar

La primera revisión debería ser la licencia. El repositorio principal enumera una combinación de licencias en el proyecto: el repositorio de hardware utiliza CERN-OHL-S-2.0, mientras que varios repositorios de software utilizan Apache-2.0. El repositorio de OpenArm enlaza con cada componente principal e identifica su licencia. Un laboratorio que planee modificar CAD, redistribuir un montaje, incluir firmware o publicar un derivado comercial debería leer la licencia de cada componente, en lugar de tratar «completamente de código abierto» como una única categoría legal universal.

La segunda revisión debería centrarse en la alineación de versiones. OpenArm tiene modelos v1.0 y v2.0, varios repositorios, submódulos, distribuciones de ROS 2 y documentación que evoluciona. Un tutorial puede funcionar para una revisión del brazo y requerir ajustes en otra. Fijar los commits de los repositorios, registrar la distribución de ROS y conservar una lista de materiales legible por máquina son prácticas básicas de reproducibilidad. Resultan especialmente importantes en una plataforma física, donde un pequeño cambio mecánico puede alterar la calibración y el comportamiento del control.

La tercera revisión es la distancia entre un sistema simulado y uno real. Ejecuta los archivos de lanzamiento del hardware ficticio. Carga el MJCF. Recopila un dataset pequeño. Conviértelo al formato de entrenamiento previsto. Implementa un servidor de políticas que emita acciones sin mover ningún motor. Después, lee las instrucciones para el hardware real e identifica cada componente que siga siendo ambiguo: adaptadores CAN, configuración de motores, comportamiento de la pinza, calibración, límites, secuencia de arranque y recuperación ante pérdidas de comunicación.

La cuarta revisión debería ser el mantenimiento. GitHub muestra repositorios activos y trabajo reciente en la organización OpenArm, pero la actividad no equivale a madurez del soporte. Conviene mirar los problemas abiertos, las notas de versión, la guía de contribución, los cambios incompatibles, la cobertura de pruebas y la manera en que se comunican las regresiones de hardware. Una plataforma robótica es una dependencia con consecuencias físicas. Si una actualización cambia un parámetro del controlador, el resultado puede ser algo más grave que una compilación fallida.

El historial de versiones muestra un proyecto que avanza mediante revisiones incrementales de hardware y software, incluidos cambios en la carcasa, la pinza, los paquetes de ROS 2, componentes relacionados con la carga útil y archivos de simulación. Es normal en una plataforma joven. También significa que el comprador debería presupuestar mantenimiento y no asumir que una instantánea del repositorio equivale a una versión de producto respaldada.

Alternativas y la pregunta que OpenArm deja abierta

Los investigadores tienen alternativas, aunque normalmente optimizan una restricción distinta. Los brazos comerciales pueden ofrecer soporte maduro e integración industrial. Las plataformas académicas consolidadas quizá cuenten con un cuerpo mayor de trabajos publicados, procedimientos de calibración conocidos o un ecosistema de datos más asentado. Los manipuladores educativos de bajo coste reducen la barrera de entrada, aunque tal vez no ofrezcan la carga útil, el cumplimiento mecánico o el flujo bimanual al que apunta OpenArm. Las plataformas solo de simulación evitan el coste del hardware, pero no pueden responder preguntas sobre el contacto y la percepción reales.

La elección distintiva de OpenArm es reunir hardware, simulación, recopilación de datos y evaluación en un único proyecto abierto. Eso crea una oportunidad para benchmarks compartidos, pero solo si la comunidad resiste la tentación de publicar demostraciones aisladas. La unidad útil de progreso no es simplemente una política nueva ejecutándose en un robot. Es una tarea, un dataset, una descripción del entorno, un script de evaluación y una pila de software versionada que otro grupo pueda ejecutar y poner a prueba.

El proyecto también deja al descubierto una tensión más amplia de la robótica abierta. Hacer público el CAD no crea automáticamente una comunidad. Una comunidad aparece cuando las piezas están documentadas, son suficientemente asequibles para obtenerlas, suficientemente estables para usarlas y suficientemente estructuradas para compararlas. El trabajo de OpenArm 2.0 con la Cell y el Dataset apunta a esa capa intermedia entre un diseño abierto y un ecosistema de investigación funcional.

Esa capa necesitará tiempo. El dispositivo KER aún no se ha lanzado. El puente de hardware y la integración de la pinza siguen marcados como trabajo activo. El soporte para Jazzy no se presenta como completamente asentado. La seguridad física, la disponibilidad de suministros, la calidad del ensamblaje y la calibración variarán entre montajes. La apertura del proyecto facilita investigar estos riesgos, pero no los hace automáticamente menores.

El veredicto práctico

Vale la pena probar OpenArm 2.0 si el experimento que quieres realizar trata sobre aprendizaje a partir de la interacción física y estás dispuesto a asumir la integración. Su aportación más fuerte no está en la reivindicación de un formato humanoide ni en el precio anunciado. Está en el intento de conectar piezas que normalmente permanecen separadas: un robot inspeccionable, un modelo de simulación, una interfaz de teleoperación, un dataset estructurado, una frontera de políticas y un entorno de evaluación repetible.

Para un investigador, el mejor punto de partida es la ruta de software. Usa el hardware ficticio, inspecciona la descripción del robot, ejecuta el modelo de MuJoCo, recopila demostraciones con WebXR y examina la salida de OpenArmDataset. Comprueba cuánto de la tarea prevista sobrevive a la conversión al marco de entrenamiento. Solo después debería el laboratorio decidir si el brazo físico y la celda responden a una pregunta que la simulación no puede resolver.

Para un comprador, el consejo es igual de concreto: fija las versiones, lee las licencias, planifica la ingeniería de seguridad y trata las advertencias actuales de la documentación como parte de la especificación del producto. OpenArm no es un robot industrial llave en mano. Es una pila pública y evolutiva de investigación cuyo valor se medirá por la facilidad con que otros equipos puedan reproducir, modificar y ampliar el trabajo.

Es un estándar exigente, pero es el correcto. La IA física no ganará credibilidad porque otro robot produzca un vídeo pulido. Ganará credibilidad cuando el mismo experimento pueda inspeccionarse, repetirse, fallar de forma segura y ser mejorado por personas que no construyeron la máquina original.

Fuentes