Gemm

El problema

Una refinería tiene muchos hornos. Cada tres horas, alguien tiene que caminar hasta cada uno, leer una perilla, y girar una válvula según lo que diga esa perilla.

No es trabajo complicado. Es trabajo que tiene que pasar a las cuatro de la mañana, en un área donde estar presente es en sí mismo el riesgo, en un loop que no para nunca. Y su valor está enteramente en hacerlo: una lectura tomada tres horas tarde no es una lectura, es una suposición.

Esa ronda es el trabajo. No "inspección" en abstracto — ese loop específico, que hoy camina una persona.

Qué estamos construyendo

Un humanoide que camine la ronda y opere la válvula.

Esa última parte es la mitad difícil, y es el punto. Un robot que lee la perilla y transmite un número sigue necesitando que una persona salga a girar la válvula, lo que significa que el viaje sigue pasando. Cerrar el loop es lo que lo elimina.

Todavía no llegamos. Lo que funciona hoy es la capa de abajo, y es sustancial.

De dónde salió la idea

El nombre somos los cuatro: Guido, Eitan, Martín, Matías. Arrancó como el proyecto de investigación del último año del colegio, en un programa que quería que el año produjera investigación y no otra app.

Tuvimos un cuadrúpedo Go2 antes de tener un caso de uso, y lo fuimos a buscar en reuniones con las energéticas que operan sitios así — gente que manda humanos a esas áreas y podía decirnos qué ronda les gustaría más dejar de caminar. Esa es una respuesta muy distinta de la que escribís en un escritorio. Después llegó el humanoide G1, y la ronda pasó a ser algo que un robot plausiblemente podía hacer en vez de algo de lo que hablar.

Qué funciona hoy

Un mapa 3D y 2D del entorno en vivo, armado con los propios sensores del robot. Todo sale del mismo pipeline: un mapa 3D generado en tiempo real mientras el robot camina, una pasada 3D completa procesada después, y un plano 2D derivado de eso. El mapa 2D es contra el que corre la navegación; el 3D es el que lee una persona.

Teleoperación por realidad virtual. Un operador con un headset mueve las manos y el robot las copia, con un delay mínimo. Eso es de Guido, y es lo que hace tratable la operación de válvulas: antes de que un robot pueda hacer el movimiento solo, una persona tiene que poder hacerlo a través del robot.

Un dashboard que pone el mapa, el estado del robot y el feed en vivo en un solo lugar, así quien lo está corriendo no está leyendo una terminal.

Qué estamos construyendo ahora

Llevar al robot de un punto A a un punto B solo, contra el mapa 2D. El mapa existe y la relocalización funciona; el ruteo es la pieza actual.

Las restricciones

• Los robots no tienen certificación ATEX. No están homologados para atmósfera explosiva, así que ninguna prueba de concepto puede pasar en zona clasificada. Todo hay que demostrarlo en área no clasificada y argumentarlo desde ahí.
• El cómputo de a bordo está compartido con otro subsistema, así que el presupuesto de percepción no es la máquina entera.
• El link al operador es WiFi, dentro de una refinería, atravesando acero. Y la teleoperación es la única cosa de esta lista donde la latencia no es un problema de calidad sino de seguridad.

Qué decidí

Nuestro propio SLAM, no el del fabricante

FAST-LIVO2 sobre ROS2, corriendo a bordo. El stack del fabricante es una caja negra: te entrega un mapa y ninguna forma de razonar sobre cómo se armó, así que cuando el mapa está mal no hay nada que hacer al respecto.

Ser dueño del pipeline es la diferencia entre una demo y un sistema. Es también lo que hizo posibles todos los hallazgos de abajo: no se puede perfilar una caja negra.

Un render por densidad, no un occupancy grid

Para un humano que decide dónde mandar un robot, un occupancy grid tira justamente la información que hace legible una escena. Un render por densidad de la misma nube de puntos conserva la estructura que una persona reconoce.

El mapa lleva un contrato espacial explícito

Con autolevel, así "dónde cree el robot que está" y "dónde lo dibuja el dashboard" no pueden separarse en silencio. La alternativa es un sistema que se ve bien hasta el día en que está confiadamente equivocado.

Mapeo con Metal MPS del lado de macOS

Para que la pasada procesada corra en las máquinas que realmente tenemos.

Lo que llevó el tiempo de verdad

No los algoritmos: el bridge, que es mío. Cada uno de estos está escrito en las notas, porque los hallazgos son más útiles que las decisiones.

El adaptador era el cuello de botella, no el SLAM. Pasamos semanas optimizando un pipeline cuyo límite real era la capa de apariencia fina que traducía entre dos formatos de mensaje, copiando y reallocando en cada frame.

El path de SLAM se estaba comiendo el link de WiFi. Publicar la trayectoria completa a tasa completa saturaba el link que necesitaba la vista en vivo.

El techo de tasa del relay se estaba mordiendo su propio input. Un throttle aplicado en el punto equivocado del grafo retroalimentaba a lo que estaba limitando.

El cómputo de a bordo está compartido. Obvio una vez que lo sabés, invisible mientras estás midiendo.

El equipo

• Yo — el bridge que saca datos del robot con el menor delay que consigo, el mapa 3D en tiempo real, la pasada 3D procesada y la derivación 2D, y el dashboard.
• Guido Jacofsky — el sistema de teleoperación por VR.
• Matías Tenenbaum — investigación.
• Martín Durán — diseño.

Con un mentor que empujó para que el proyecto fuera investigación de entrada, y mentores industriales que nos dicen cuándo una idea no sobreviviría una refinería de verdad.

Dónde está

En desarrollo, y esta página dice cuál parte es cuál, porque exagerar la autonomía de un robot es la forma más rápida de perder un aliado que trabaja en el campo de verdad:

• Percepción y mapeo — funcionando. 3D en vivo, 3D procesado, 2D.
• Teleoperación por VR — funcionando.
• Navegación autónoma de A a B — en progreso.
• Operación de válvulas — el objetivo.

Qué haría distinto

Perfilar antes de optimizar, en ese orden, una sola vez. Teníamos dos problemas en la misma zona y solo uno era el que estábamos trabajando — y arreglar el real nos dio más confianza en el modelo equivocado, no menos. Esa es la peor forma posible para debuggear y me metí derecho en ella.