Alternativa DIY a Violoop: automatización con GL-RM10 y Codex

¿Te gusta la idea de Violoop? Una ruta DIY más sencilla

Si probaste Violoop y te gustó la idea de un asistente que ve la pantalla y maneja un ordenador, una configuración DIY con KVM puede servir para unas pocas tareas repetibles. Violoop merece consideración si prefieres una experiencia integrada y lista para usar. Su IA integrada, hardware de aprobación y funciones entre aplicaciones anunciadas son una propuesta diferente.

Esta es una guía de construcción, no una reseña de una prueba personal ni una promesa de equivalencia. Conectaremos un Comet Pro GL-RM10, veremos el ordenador objetivo en un navegador de Ubuntu y usaremos Codex para planificar y construir un puente pequeño. El modelo utiliza el proveedor elegido para Codex en el controlador; el KVM aporta vídeo, teclado y ratón.

Divulgación: Como afiliado de Amazon, obtengo ingresos por las compras adscritas que cumplen los requisitos aplicables. Este enlace de afiliado al GL-RM10 en Amazon puede apoyar a Manabi Kōbō sin coste adicional. Comprueba modelo, cables, precio y vendedor.

Paso 1: Prepara controlador y objetivo

Necesitas GL-RM10 y fuente de alimentación, cable de vídeo desde la salida HDMI del objetivo, conexión USB de datos indicada por el fabricante, red local y un controlador Ubuntu con escritorio. Un conector USB-C no garantiza salida de vídeo: utiliza el adaptador adecuado si hace falta.

Empieza con un ordenador de pruebas propio y abre un editor de texto vacío. El ejemplo requiere Ubuntu con Xorg/X11 porque xdotool envía entrada mediante X11. Si el comando muestra wayland, selecciona una sesión Xorg disponible al iniciar sesión; un escritorio solo Wayland requiere otro mecanismo de entrada.

Arquitectura: HDMI del objetivo → GL-RM10 → red local → navegador del controlador; entrada del controlador → visor KVM → USB HID del GL-RM10 → objetivo. Codex trabaja en el controlador, no en el KVM.

Abre el ejemplo completo para copiar — example-01.txt

echo "$XDG_SESSION_TYPE"

Paso 2: Conecta y comprueba el GL-RM10

Enciende el equipo. Conecta HDMI OUT del objetivo a HD IN del Comet Pro y, opcionalmente, HD OUT al monitor. Conecta el puerto USB-C de datos del KVM al objetivo y añade Ethernet o configura Wi-Fi en la pantalla táctil. El controlador debe estar en la misma red.

Abre glkvm.local o la IP de la pantalla en Chrome o Edge y establece la contraseña inicial. Entra en la consola, comprueba el vídeo y escribe en el editor remoto. Vídeo y entrada USB deben funcionar antes de automatizar. Consulta la guía oficial de conexión correspondiente al firmware.

Anota el firmware y fija tamaño y zoom del visor. Empieza en la LAN. Para acceso externo posterior, utiliza una vía VPN o remota compatible y compruébala manualmente.

Paso 3: Instala herramientas y conecta Codex

En Ubuntu instala las dos utilidades y crea un proyecto limpio. Descarga y revisa el instalador oficial de Codex antes de ejecutarlo. Reabre la terminal si el comando no aparece en PATH.

Ejecuta codex en el proyecto e inicia sesión por la opción ofrecida de ChatGPT o API. Codex con proveedor en la nube puede enviar instrucciones e imágenes adjuntas: el vídeo en la LAN no convierte la inferencia en local. Usa una pantalla de pruebas sin información sensible. Consulta la instalación oficial.

Pídele que explique el puente. Una instrucción útil: ‘Trabaja solo aquí. El objetivo es otro ordenador mostrado en un visor KVM. Empieza con simulaciones y pregunta antes de operar. No escribas en consolas administrativas’.

Abre el ejemplo completo para copiar — example-02.txt

# Open full code above.

Paso 4: Construye un puente de entrada

Guarda el código como kvm_bridge.py. Activa una ventana elegida, captura su imagen y permite tres acciones pequeñas. Las entradas son simulaciones por defecto. Las coordenadas corresponden a la ventana del controlador, no a la resolución nativa del objetivo. Es una implementación inicial original sin API privada del GL-RM10.

Con el visor abierto, ejecuta xdotool selectwindow y haz clic en el borde de la ventana del navegador. Exporta el ID numérico en la terminal del puente y de Codex. El editor remoto es una imagen dentro del navegador, no una ventana X11 independiente. El puente también podría pulsar controles del navegador: limita las coordenadas al escritorio remoto visible.

Consulta xdotool y scrot. El ejemplo no se ha validado con todas las combinaciones de firmware y navegador; comprueba primero la entrada manual.

Abre el ejemplo completo para copiar — kvm_bridge.py

# Open full code above.

Paso 5: Captura la pantalla y pide una acción

Sustituye el ID de ejemplo por el obtenido con selectwindow. El puente imprime en JSON el nombre de la imagen. Adjunta ese archivo real a Codex con --image. Pide un punto dentro del editor remoto vacío y una sola pulsación propuesta.

La imagen muestra la ventana del controlador, también sus controles. Mantén tamaño y enfoque, y mide desde la esquina superior izquierda de la ventana. Si el vídeo sale negro, corrige primero la captura o el renderizado: una imagen sin el objetivo no sirve para guiar clics.

Ejemplo: ‘Esta es mi ventana GL-RM10. Propón una coordenada relativa a la ventana dentro del editor vacío. No ejecutes. Evita la barra de herramientas y detente si no lo identificas’. Revisa la respuesta visualmente.

Abre el ejemplo completo para copiar — example-04.txt

# Open full code above.

Paso 6: Automatiza el ordenador transmitido

Simula primero la coordenada revisada; cambia 420 y 350 por tu posición medida. Ejecuta después el mismo clic con --execute y comprueba el enfoque en el editor objetivo. Si la escritura llega al controlador o activa un atajo del navegador, detente y corrige el enfoque o la captura.

Con esa comprobación superada, las acciones type y Return son tu primera automatización remota: escriben una frase a través del KVM y capturan el resultado. Empieza con ASCII para evitar diferencias de teclado. No uses el controlador mientras se ejecuta.

Para sesiones posteriores, documenta el contrato en AGENTS.md: snapshot solo observa; entrada simulada salvo aprobación de --execute; una sola ventana; imagen nueva tras cada acción; detenerse tras cinco acciones o una pantalla inesperada. Codex puede llamar al script con sus herramientas de terminal si los permisos lo permiten. Primero ejecuta tú los comandos revisados. El sandbox del controlador no limita por sí solo el objetivo remoto.

Abre el ejemplo completo para copiar — example-05.txt

# Open full code above.

Paso 7: Convierte la demo en un flujo fiable

La siguiente tarea puede ser introducir tres líneas aprobadas en una nota desechable. Añade condición inicial, máximo de acciones, parada de emergencia y frase final esperada. Conserva imágenes antes y después. Una captura prueba lo visible, no que se guardara un archivo o cambiara un servidor.

Antes de ejecutar sin supervisión, calibra el adaptador, añade registros duraderos y pasos idempotentes. Revisa compras, mensajes y borrados. Las instrucciones en la pantalla objetivo no autorizan cambios de tarea. Los bucles más grandes encajan con la guía de LangGraph de esta serie.

Preguntas: ¿Codex corre en el GL-RM10? No, en Ubuntu. ¿Reproduce la IA y aprobación física de Violoop? No. ¿Puede operar sin instalar agente en el objetivo? El KVM transmite vídeo y USB HID, pero debe pasar la prueba de entrada. ¿Es todo local? Solo si también lo son inferencia y servicios auxiliares; Codex en la nube no lo es.

Para practicar japonés, compara sujeto, objeto y verbo en la columna derecha. Consulta las funciones de Violoop como afirmaciones del fabricante y las guías oficiales para configurar.

Continúa la serie

• Ollama en Ubuntu: modelo pequeño y conocimiento de contexto
• Primeros pasos con Codex en Ubuntu para trabajo Linux y automatización
• Cómo empezar con OpenClaw y agentes locales en Ubuntu
• LangGraph para flujos prácticos: estado, aprobación y recuperación