Experiencia · Sistemas para robots

Software para robots: la capa que decide el movimiento, el módulo de visión y el de audición. Hoy tenemos verificación offline y simulación — no tenemos nada que controle un motor real.

Escribimos cinemática, verificación de trayectoria y simulación física reproducible, con gates que bloquean cuando falta la prueba. Para visión tenemos un prototipo con cámara fija, no en un robot. Para audio en el robot no tenemos nada construido, y la página lo dice en lugar de tomar prestadas pruebas de la telefonía. No trabajamos con ROS.

Habla de un proyecto

Oferta, con condicionesHe ejecutado hoy todo lo que se puede ejecutar. La capa de control existe y es seria, pero está offline: un módulo propio de cinemática para un brazo con seis ejes, que resolvió 8.400 de 8.400 puntos de trayectoria, y un validador de física en MuJoCo 3.10.0 con 34 pruebas aprobadas, más 14 pruebas en la parte de visualización. Ambos declaran en su propio código que no tienen transporte al hardware y no pueden comandar un robot real. A la vista tenemos un prototipo propio — detección y seguimiento de personas en una cámara IP fija — con un solo commit y con el directorio de pruebas vacío. En audio en el robot tenemos cero: todo lo que hay en el disco es voz de call-center o biblioteca externa de telefonía, y la única obra acústica propia terminó con un resultado negativo, escrito en la aplicación. ROS: cero instalado, cero escrito. La regla exige un mínimo de dos implementaciones propias para «he hecho»; en control las tengo, pero ninguna alcanza el hardware, y las otras dos capas del servicio están por debajo del umbral. Así que: oferta con condiciones, con los límites dibujados.

El software de un robot tiene tres capas que se rompen de forma distinta: lo que ve y oye, lo que decide, y lo que envía a los motores. En las dos primeras tenemos trabajos propios con pruebas que se ejecutan. En la tercera — el puente hacia hardware — no tenemos nada, y ese es el límite del servicio, no un detalle de implementación. Dos de nuestros códigos lo dicen en su propio encabezado, en inglés, precisamente para que no puedan leerse mal: el módulo de cinemática no tiene transporte hacia hardware y no puede controlar un robot real.

Lo que existe en la parte de movimiento es verificación antes del movimiento. Un módulo propio calcula la cinemática directa, el jacobiano y la cinemática inversa para un brazo de seis ejes, con una reserva impuesta frente a los límites de cada eje, y se usó para verificar una trayectoria completa: 8.400 puntos solicitados, 8.400 resueltos, con la velocidad máxima por eje quedando por debajo del 8% del límite de catálogo. Por separado, un validador de física se ejecuta en MuJoCo 3.10.0 en procesador, con paso de cálculo de un milisegundo, en seis escenarios, cada uno dos veces, con la misma semilla — y las dos ejecuciones dan huellas idénticas. El determinismo no es una afirmación, es una comparación de sumas de control.

Lo que existe en la parte de visión es menos, y es honesto decir cuánto. Un prototipo propio hace detección y seguimiento de personas en flujos de cámara IP, con un pequeño detector de la familia YOLO, un rastreador multiobjeto, estimación de postura para cinco estados y control de giro-inclinación-zoom de la cámara. Tiene un solo commit y el directorio de pruebas está vacío. Y la diferencia entre esto y la visión de un robot es real, no formal: la cámara de un robot se mueve con él, la escena está cerca, la exposición cambia en cada paso y el presupuesto de latencia es otro, porque la imagen tiene que llegar a una decisión de movimiento, no a una pantalla. No tenemos cámara de profundidad, no tenemos calibración de cámara, no tenemos odometría visual.

En la parte de audio para robots no tenemos nada construido, y no vamos a tomar prestadas pruebas de otro lado. Tenemos trabajos reales de voz para telefonía y para asistentes conversacionales, pero un micrófono en un robot tiene otros problemas: el ruido propio de la máquina, ventiladores y servomotores que arrancan justo cuando el robot se mueve, la dirección desde la que llega la voz, el eco en la habitación y la distancia variable. El único trabajo acústico propio que tenemos terminó con un resultado negativo, escrito en la aplicación, y lo publicamos como tal — porque un resultado negativo medido es más útil que una promesa.

Qué incluye

El trabajo, por componentes

Verificamos la cinemática antes de mover algo

Cinemática directa, jacobiano analítico construido a partir de productos vectoriales, cinemática inversa numérica con cuatro posiciones de inicio y una reserva impuesta de 10° frente al límite de cada eje, con convergencia a 0,05 mm por posición. Con ella verificamos una disposición en 1.331 posiciones de rejilla y una trayectoria completa de 8.400 puntos, todas resueltas. Los resultados: velocidad máxima por eje al 7,86% del límite de catálogo y margen mínimo frente a los límites de 19,9°. El informe escribe por sí solo su naturaleza: cribado discreto offline, sin salida al hardware.

Ejecutamos la física separada de la imagen, y de forma reproducible

El validador de física es un programa separado de la parte visual, en MuJoCo 3.10.0, en CPU, con paso de un milisegundo y muestreo cada 20 milisegundos. Seis escenarios, cada uno ejecutado dos veces con la misma semilla, con huellas idénticas entre ejecuciones. Las tolerancias están declaradas en el código, no subentendidas: deriva de energía por debajo del 1% relativo, penetración en el suelo por debajo de 3 cm, infracción del límite articular por debajo de 0,03 radianes. Lo que se mide en caída libre es la aceleración del centro de masa, comparada con la gravedad configurada — 9,80665, 1,62 y 3,72076 metros por segundo al cuadrado.

Ponemos una puerta que bloquea, no una que solo etiqueta

El registro de acciones exige que cada movimiento declare su procedencia, y las 15 acciones registradas están marcadas como cinemáticas, validadas en cero — porque ninguno de esos controladores está impulsado por un simulador de cuerpos rígidos con límites de actuador y validación de contacto. Encima de eso, una puerta de liberación lee el archivo de prueba y falla si una constante clave no está calibrada en hardware. Hoy falla: una sola constante de parada articular, de 5 milisegundos, está declarada en el código como parámetro provisional, no como valor medido — y eso basta para que la verificación completa dé error. Es una regla escrita por nosotros contra nosotros.

Leemos la descripción del robot con un parser propio, y decimos lo que deja fuera

Para la visualización e inspección de modelos escribimos nuestro propio analizador del formato MJCF: cuerpos, articulaciones de tipo bisagra, libre, deslizante y esférica, geometrías, materiales y carga de mallas, con caché de geometría. Deja fuera intencionalmente las geometrías de colisión, porque es un analizador visual, no uno de contacto — escrito en código, no descubierto después. Los modelos utilizados son los oficiales, con 29 grados de libertad para el humanoide y 12 para el cuadrúpedo.

No confundimos los valores comandados con los medidos

Los ángulos que aparecen en pantalla son los comandados por el controlador, publicados en una sola dirección hacia la interfaz. No contienen ruido de encoder, estado medido, par, velocidad ni temperatura — escrito explícitamente en la auditoría técnica del proyecto. Esa distinción parece pequeña hasta que alguien toma un gráfico bonito por telemetría de robot; por eso la escribimos en el código, en la auditoría y aquí.

Visión: detección y seguimiento de personas, en cámara fija

Un prototipo propio que toma flujos de cámara IP, detecta personas con un pequeño modelo de la familia YOLO, las sigue entre cuadros con un rastreador multiobjeto con un umbral de confianza de 0,5, estima la postura en cinco estados — desconocido, sentado, de pie, caminando, inclinado — y puede girar la cámara mediante el protocolo estándar de control. Corre forzosamente en CPU, debido a una incompatibilidad anotada en el código. Su estado real: un solo commit y el directorio de pruebas vacío. Es un prototipo, no un módulo de producción, y nunca ha estado en un robot.

Audio en robot: decimos lo que falta, en lugar de tomarlo prestado de la telefonía

No tenemos detector de palabra de activación, no tenemos detector de voz ejecutado localmente, no tenemos formación de haz, no tenemos estimación de dirección y no tenemos código de cancelación de eco escrito por nosotros. Lo que tenemos en la zona de voz es para llamadas telefónicas y para asistentes conversacionales: la interrupción del hablante se hace o bien mediante el detector del servicio del proveedor, o bien pulsando una tecla en el menú telefónico, y la cancelación de eco viene de las bibliotecas del navegador o de una pila de telefonía de terceros. Son cosas reales, pero resuelven otro problema distinto al de un micrófono montado en una máquina que se mueve y hace su propio ruido.

ROS: no tenemos, y no fingimos que sí

No está instalado en ninguna de nuestras máquinas y nunca hemos escrito un nodo, un archivo de lanzamiento ni un paquete propio. El único paquete con sistema de construcción específico de ROS en el disco es la descripción pública de un robot industrial, descargada como archivo de modelo y usada exactamente así, no compilada. Si tu proyecto presupone ROS 2 de entrada, es una información que debes tener antes de la primera reunión, no después.

Qué aceptaríamos y qué no

Aceptaríamos: verificación cinemática y de trayectoria antes de una compra, simulación con tolerancias declaradas, un módulo de percepción medido con tus datos, y un puente hacia hardware hecho junto con el integrador responsable de la seguridad. No aceptaríamos: escribir nosotros mismos la capa que detiene un robot en caso de emergencia, prometer un módulo de audio en el robot sin una medición previa del ruido propio de tu máquina, ni decir que nuestra experiencia de voz por teléfono cubre la audición de un robot.

Qué aspecto tiene

El recorrido, paso a paso.

Definimos la tarea y los límites físicos, y luego verificamos si caben

Qué debe alcanzar el robot, en qué volumen, con qué velocidad y qué carga. Luego la verificación: cobertura del volumen, margen frente a los límites de cada eje, velocidad y aceleración en la trayectoria, colisiones sobre geometría real como cribado. Entregamos el informe con sus limitaciones escritas. Esta etapa tiene una buena relación entre coste y daño evitado, porque se hace antes de una compra.

Simulamos con tolerancias declaradas y con determinismo verificado

Escenarios, semilla fija, ejecuciones repetidas, comparación de huellas, tolerancias escritas en código. Entregamos también la lista de cosas que la simulación NO demuestra — en nuestro caso, por ejemplo, un validador que confirma caída libre y mantenimiento de posición sobre un plano de prueba no confirma marcha, contacto complejo ni dinámica del actuador, y eso lo escribe por sí solo.

Construimos la percepción con tus datos, no con un conjunto público

Un detector que funciona con imágenes de internet no dice nada sobre tu nave industrial. La etapa significa captura del entorno real, un conjunto de evaluación propio, una medición de referencia y solo después la elección del modelo y del lugar donde se ejecuta. Entregamos las cifras de referencia y el método con el que puedes reproducirlas, incluso cuando son débiles.

El puente hacia hardware — la etapa que nunca hemos hecho

La escribimos al final y la escribimos con condiciones, porque es la única de la lista en la que no tenemos experiencia propia. Se hace junto con el integrador o con el fabricante del robot, y las funciones de parada de emergencia, limitación y seguridad siguen siendo responsabilidad de quien responde por la máquina. Lo que nosotros podemos llevar hasta ahí es la capa de decisión, verificada, con su interfaz documentada.

La cadena de un robot, de izquierda a derecha, con el estado real de cada eslabón. Visión: prototipo con cámara fija, un solo commit, sin pruebas. Oído: vacío — nada construido para un micrófono en una máquina que se mueve. Decisión y cinemática: verificado, con 8.400 puntos resueltos y con una gate que bloquea cuando una constante no está calibrada. La última flecha, la que va hacia los motores, está interrumpida: ningún código nuestro tiene transporte hacia hardware. El diagrama está hecho para que se vea dónde se detiene el servicio, no para parecer completo.

Los datos

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

La cámara de un robot graba personas, y eso lo cambia todo: Un módulo de visión que detecta y sigue personas produce datos personales en el sentido propio de la palabra, aunque nadie sea identificado por nombre. Las preguntas se plantean antes de la primera línea de código: si se guarda la imagen o solo el resultado, dónde se procesa, quién tiene acceso a las grabaciones, cuánto tiempo se conservan, qué se muestra a las personas grabadas. Nuestro prototipo fue construido como experimento técnico, no como sistema puesto en funcionamiento, y no lo proponemos como tal.
En el dispositivo o en el servidor — una decisión de latencia, no de preferencia: Si la imagen tiene que llegar a una decisión de movimiento, el camino hasta un servidor y de vuelta entra directamente en el presupuesto de reacción. Si el resultado solo se muestra o se registra, el servidor es aceptable. La decisión se toma a partir del presupuesto de latencia medido en tu caso, y se escribe. Nuestro prototipo funciona forzosamente en el procesador, lo que es una limitación real de velocidad, anotada en el código.
Las simulaciones se conservan con semilla y con huella: Un resultado de simulación sin la semilla del generador y sin la suma de control de las entradas no es una prueba, es una historia. Nuestros informes de física llevan la semilla, el número de ejecuciones por escenario, la versión del motor y el estado de determinismo; los informes de cinemática llevan la huella de los archivos de entrada. Así se puede verificar, meses después, si una cifra citada sigue siendo válida.
Audio significa grabar una habitación: Un micrófono en un robot oye todo lo que ocurre a su alrededor, no solo la orden que se le da. La regla que aplicaríamos es que la grabación continua no exista de forma implícita, sino solo la ventana necesaria para la decisión, y que lo que se conserve para mejora sea una elección explícita, con plazo. Todavía no tenemos construido un sistema así, así que es una posición declarada, no una práctica demostrada.
Los modelos y las descripciones de robot tienen sus licencias: Los modelos de robot que usamos en simulación provienen de colecciones públicas, bajo licencias permisivas, y las descripciones de robots industriales son archivos públicos de los fabricantes. No son nuestros y no los reivindicamos; en un proyecto tuyo, la licencia de cada fuente externa se verifica antes de entrar en el entregable.

Un caso

Una medición acústica propia que terminó con «no», y por qué la publicamos

La situación

En una aplicación propia de macOS quisimos averiguar si el altavoz y el micrófono de un dispositivo de consumo pueden usarse como un sonar simple — una señal emitida, su eco medido, una distancia deducida. La pregunta es exactamente la que aparece también en un robot: cuánto puedes saber sobre el espacio de alrededor usando hardware de audio que ya tienes, sin sensores adicionales.

Qué construimos

Construimos la cadena completa, no un esquema: una señal barrida de 12 milisegundos que sube de 2 a 8 kilohertzios, con ventana, emitida con amplitud baja; correlación cruzada entre la señal emitida y la registrada; detección de la llegada directa con una ventana de guarda de 1,5 milisegundos, para que los lóbulos laterales de la autocorrelación no se tomen por eco; búsqueda del eco en una ventana de hasta 60 milisegundos, con umbrales separados de correlación y de ganancia relativa; velocidad del sonido corregida con la temperatura del aire. Casi 800 líneas de Swift, con detección del trayecto de audio — si el emisor y el receptor están en dispositivos distintos, la geometría es bistática y un solo tiempo de retardo define una elipse, no un punto.

Qué salió

La conclusión está escrita en la aplicación, en la pantalla que dice qué puede y qué no puede medir: en el altavoz y el micrófono del mismo ordenador se pueden detectar cambios groseros de las reflexiones después de la calibración, porque la latencia es relativamente estable. En cambio, con auriculares inalámbricos, la cancelación activa de ruido, la formación de haces, el códec y la latencia variable destruyen la medición métrica precisa — así que pueden usarse para la orientación de la cabeza, no como un sonar preciso. Escribimos esto en el producto, no en una nota interna.

Qué no dice el caso

El resultado trata sobre hardware de consumo sobre un enlace inalámbrico, no sobre un robot con micrófonos montados y cableados. Lo que se transfiere no es la conclusión, sino el método: se mide el canal antes de prometer la función. Para un robot, la misma investigación empezaría por el ruido propio de la máquina en movimiento — y solo el resultado de esa medición diría qué es posible.

Preguntas

Lo que nos pregunta la gente antes de llamar

¿Habéis puesto alguna vez vuestro software en un robot físico?

No. Ningún código nuestro ha comandado nunca un motor real, y dos de nuestras codebases lo declaran incluso en el encabezado del archivo, para que no puedan leerse mal. Lo que hemos ejecutado es simulación y verificación offline. Si eso es un problema para tu proyecto, es mejor saberlo desde la primera frase que descubrirlo en la tercera reunión.

Entonces, ¿qué tenéis exactamente?

Tres cosas, todas ejecutables delante de ti. Un módulo de cinemática para un brazo de seis ejes, que verificó un trayecto de 8.400 puntos sin ningún fallo, con un margen mínimo de 19,9° respecto a los límites de los ejes. Un validador de física sobre MuJoCo 3.10.0, con 34 pruebas que pasan y con determinismo demostrado mediante huellas idénticas en ejecuciones repetidas. Y un demostrador en el navegador con 14 pruebas, cuya qualification gate cae hoy de manera deliberada. Además, un prototipo de visión, del que decimos abiertamente que tiene un solo commit y ninguna prueba.

¿Trabajáis con ROS?

No. No está instalado en nuestras máquinas, no hemos escrito ningún nodo, ningún archivo de lanzamiento ni ningún paquete. El único paquete de tipo ROS en nuestros discos es la descripción pública de un robot industrial, descargada como archivo de modelo para los cálculos de cinemática — usada como datos, no construida. Si tu equipo ya trabaja en ROS 2 y eso es un requisito, nosotros empezamos desde cero allí, y hay que contarlo.

¿Podéis hacer el módulo de visión para nuestro robot?

Con una etapa de medición antes, no a partir del prototipo que tenemos. Lo que se transfiere de él es la forma de trabajar — detector, seguimiento entre fotogramas, umbral de confianza, dónde corre el cálculo. Lo que no se transfiere es la situación: la cámara de un robot se mueve, el sujeto está cerca, la luz cambia en cada paso, y el resultado debe llegar a una decisión de movimiento, no a una pantalla. Además, no tenemos cámara de profundidad, calibración de cámara ni odometría visual en ningún proyecto propio. La primera etapa sería captura de tu entorno y una medición de referencia.

Tienes agentes vocales. ¿No es lo mismo que oír un robot?

No, y no queremos que parezca que lo es. Por teléfono, el canal es conocido y estrecho, el hablante está pegado al micrófono, y la interrupción del hablante la resuelve o bien el servicio del proveedor, o bien una tecla pulsada. En un robot, el micrófono está sobre una máquina que hace su propio ruido justo cuando se mueve, la voz viene de una dirección que cambia, la sala produce eco y la distancia varía. Son problemas de acústica, no de conversación. Podríamos empezar con una medición del ruido propio de tu robot, pero sería un trabajo nuevo, no una extensión del de telefonía.

¿Por qué publicas un gate de calificación que falla?

Porque la alternativa es que pase sin significar nada. Nuestra gate lee un archivo de prueba y verifica si una constante crítica — el tiempo de parada en el tope de carrera de la articulación — se ha calibrado en hardware. No se ha calibrado: es un valor provisional de 5 milisegundos, puesto para que exista una simulación estable. Mientras sea provisional, la verificación completa falla, y todas las acciones siguen marcadas como cinemáticas. El día en que pase significará algo precisamente porque hoy no pasa.

¿Qué no demuestran vuestras simulaciones?

Más de lo que demuestran, y está escrito en los informes. El validador de física confirma la caída libre y el mantenimiento de la posición sobre un plano de prueba — no la marcha, no el contacto complejo, no la dinámica del actuador, no los sensores sintéticos. El screening de trayectoria confirma la cinemática y la geometría — no el material, no las mangueras flexibles, no los retrasos de proceso, no las rampas de arranque-parada del controlador. Y el movimiento en el navegador es una vista previa, no un resultado de simulación.

Necesitamos certificación de seguridad. ¿La hacéis?

No. La arquitectura de seguridad la podemos diseñar — circuito separado del control de movimiento, controlador de seguridad independiente, parada segura del par, frenos con feedback, estados de fallo que caen en seguro; eso también lo hemos hecho en un proyecto propio de máquina. Pero la evaluación de conformidad y la responsabilidad por la máquina puesta en el mercado siguen siendo del fabricante o del integrador. No asumimos ese rol y no firmamos en lugar de nadie.

¿Por qué pone „ofertă” en esta página?

Porque el servicio tiene tres capas y ninguna supera por completo el umbral que nos hemos fijado. En control tenemos dos trabajos propios con pruebas que pasan, pero ninguno llega al hardware. En visión tenemos un prototipo con un commit y sin pruebas. En audio para robots tenemos cero. Podríamos haber escrito una página que sonara a experiencia, usando palabras como „percepción” y „control” sin cifras. Habría resistido hasta la primera pregunta de un ingeniero.

En qué se basan las afirmaciones anteriores (17 fuentes)

`vision.megapromoting.com` no es un sistema de visiónhttps://vision.megapromoting.com · 2026-09-06

16 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.

Cómo trabajamos Todos los servicios

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar