# Gemm

**Robótica industrial autónoma.**

Gemm está construyendo un humanoide que pueda hacer una ronda de refinería que hoy camina una persona cada tres horas: llegar a un horno, leer su perilla, y girar una válvula según lo que lea. Yo llevo el bridge de datos, el mapeo 3D y 2D en tiempo real, y el dashboard.

- Rol: Backend e investigación de IA. Bridge de datos, mapeo y dashboard.
- Período: 2026 — hoy
- Estado: Activo
- Trabajo: Robótica, IA, Visión por computadora, Hardware
- Sitio: https://www.gemm.ar

## 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: **G**uido, **E**itan, **M**artín, **M**atí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.

---

Página: https://eitanf.com/es/work/gemm · English: https://eitanf.com/work/gemm.md · llms.txt: https://eitanf.com/llms.txt