Hay un término circulando en manufactura para las plantas nuevas que arrancan con intervención humana mínima: fábricas fantasma. Se construyen con capital fresco, lo que significa que cada contenedor y cada rack en ellas está diseñado para la precisión desde el primer día. Las piezas llegan en la misma posición y la misma orientación, miles de ciclos seguidos, porque los contenedores se diseñaron junto con la automatización que los vacía.
Las plantas establecidas no tienen ese lujo. Corren cientos de contenedores y racks existentes, atados a distribuciones de línea anteriores a los robots, dañados y deformados por años de servicio. Reemplazar esa infraestructura para comprar repetibilidad costaría más de lo que devuelve.
Así que la pregunta de ingeniería interesante en automatización hoy no es cómo construir una fábrica fantasma. Es cómo sacar confiabilidad de fábrica fantasma de equipo que nunca se diseñó para eso.
Este es un proyecto sobre exactamente eso.
El planteamiento
Un proveedor automotriz Tier 1 importante llegó a Ethos Automation para automatizar una operación de descarga de racks. Querían piezas estampadas sacadas de racks de embarque por un robot, encontradas por un sistema de visión con IA y colocadas listas para la siguiente operación. La pregunta sobre la mesa no era precio ni tiempo de entrega. Era si la cosa era posible siquiera.
Así que antes de que cambiara de manos un solo peso, el cliente le mandó un robot a Ethos.
Entregó en consignación un FANUC ArcMate, dos racks llenos de piezas de producción y dos racks vacíos, y los envió a Brantford. El arreglo era directo. Ethos construiría una celda funcional en su propio piso, correría piezas reales por ella, mediría lo que pasara y lo documentaría. Si el estudio los convencía, seguiría una orden de compra. Si no, ambas empresas habrían aprendido algo barato.
Esa es una cantidad inusual de confianza para extenderle a un integrador, y una cantidad inusual de exposición para que un integrador la acepte. También es, se puede argumentar, la forma correcta de comprar automatización que nadie ha construido antes.
Por qué los racks son más difíciles que los contenedores
El picking de contenedor es el problema más conocido, y el más fácil. Un contenedor es una caja. Sus paredes se le pueden describir al software como obstáculos fijos, y un planeador de trayectoria puede rodearlas.
Los racks son peores en todas las dimensiones que importan. Varían de rack a rack. Su geometría no es estándar. Y de forma crítica, se deforman con el tiempo, así que la forma que el software espera no es la forma que está frente a la cámara. La prevención de colisiones que funciona dentro de un contenedor no se puede simplemente apuntar a un rack y encender.
La visión vino de Apera AI, cuyo sistema construye una reconstrucción 3D a partir de un par estéreo de cámaras monocromáticas 2D, combinando emparejamiento clásico de características con estimación de profundidad por IA para que las sombras, el bajo contraste y la oclusión parcial no dejen huecos en la nube de puntos. Un segundo modelo, entrenado desde cero para la pieza específica usando millones de ejemplos simulados, encuentra entonces la pieza dentro de esa reconstrucción y califica con cuánta confianza se podría tomar.
Esa calificación de confianza importa más de lo que suena. Las piezas en un rack de embarque no están donde un modelo CAD dice que deberían estar. Se recargan, se mueven en el transporte y se apelmazan. Un sistema que reporta qué tan seguro está puede recibir la instrucción de saltarse aquellas de las que no está seguro, que es un comportamiento distinto y más útil que un sistema que simplemente reporta una posición.
La pieza no es el problema. El rack sí.
Los componentes estampados llegan apilados sobre varillas horizontales dentro de un rack de acero, alrededor de setenta y cinco piezas por varilla, apretadas. Un robot que mete el brazo tiene que caber entre las varillas, librar el labio frontal del rack, sujetar una pieza que puede estar tocando a sus vecinas, y retirarse sin arrastrar nada más.
El equipo de Ethos destiló la restricción en una sola regla práctica que aparece en el reporte del estudio:
Si el operador no puede cargar o descargar la pieza manteniéndola plana, el robot, tal como está diseñado hoy, no va a poder tomarla.
Vale la pena detenerse en esa frase, porque define el límite del sistema con honestidad. El robot no es más diestro que una persona. Es más consistente y nunca se cansa, pero hereda cada defecto del rack que una mano humana sortearía: deformación en la barra de sujeción superior, deformación en las barras inferiores, acumulación de óxido que hace que las piezas rechinen al deslizarse, soldaduras sobresaliendo donde la superficie debería ser lisa, y piezas apelmazándose en el labio frontal.
Retirar la cámara para ver más
La cámara va en el herramental de punta de brazo, lo que lo convierte en una aplicación eye-in-hand: dónde mira el robot y dónde alcanza el robot son el mismo problema.
Eso creó una dificultad inmediata. Las piezas son lo bastante grandes para que el componente completo no quepa en el campo de visión de la cámara a corta distancia. Para capturar una imagen utilizable la cámara tiene que quedarse al menos a un metro, que es lo contrario de lo que uno quiere para resolución.
La respuesta fue dejar de tratar la captura como un evento único. Después de la imagen inicial, la cámara avanza de forma incremental, manteniendo la pieza dentro de una ventana de 1.1 a 1.3 metros donde la resolución es mayor y la pieza completa sigue en cuadro. Trabajando dentro de esa banda, la celda logra 0.3 mm de precisión de colocación con menos de un grado de desviación rotacional.
El cliente también pidió que los operadores no tuvieran que decirle al sistema a qué profundidad viene cargado un rack nuevo. Así que el robot lo establece solo: una pasada de estimación de profundidad identifica la pieza más cercana y fija una distancia de referencia, y a partir de ahí offsets matemáticos colocan la cámara en el rango óptimo. Cada toma posterior arranca desde el mejor punto de vista disponible en vez de desde la estimación de un operador.
Construir una herramienta que quepa
El problema mecánico central fue el herramental de punta de brazo, y el reporte del estudio lo nombra sin rodeos: la herramienta tenía que ser lo bastante compacta para navegar dentro del rack y lo bastante fuerte para manipular las piezas de forma confiable, sin levantar más de una sin querer.
Esos dos requisitos jalan en direcciones opuestas. La fuerza de retención magnética escala con el tamaño del imán. El alcance dentro de un rack saturado escala a la inversa del tamaño de la herramienta.
Ethos trabaja este problema desde el inicio en vez de descubrirlo después de fabricar. El robot, la herramienta y toda la trayectoria de movimiento se modelan en Siemens Process Simulate antes de cortar hardware, y el diseño de la herramienta se somete a prueba contra miles de configuraciones aleatorias de rack para ver si sigue cumpliendo los requisitos bajo variabilidad real. Así es como uno se entera de que necesita un pedestal de reorientación, o una geometría distinta de herramienta, cuando todavía es un dibujo.
Aun así, los imanes trajeron un modo de falla que solo aparece en metal. Un gripper magnético no falla limpio. Sostiene, más o menos, hasta que la pieza se desplaza lo suficiente para que el campo no la retenga, y entonces la pieza se desliza. Así que el equipo definió la falla en términos medibles en vez de por sensación: una falla de imán era cualquier caso donde el robot necesitara tres o más intentos para tomar una pieza.
300 piezas, contadas de una en una
El 25 de junio de 2025 la celda corrió 300 piezas, 150 de mano izquierda y 150 de mano derecha. Cada toma se registró a mano contra cuatro criterios: engancharon los imanes, tocó la pieza la varilla, tocó la pieza el labio frontal, y se soltó con éxito.
Las pruebas de velocidad produjeron el hallazgo más útil. Corriendo el robot entre 30 y 50 por ciento del máximo, el equipo encontró que al 50 por ciento las piezas ocasionalmente se resbalaban del imán durante ciertas maniobras, y dos se cayeron de plano. Cerca del 45 por ciento la celda era estable y seguía cómodamente dentro del objetivo de tiempo de ciclo. El programa se ajustó para hacer más lentos movimientos específicos y no todo el ciclo.
Un segundo hallazgo fue contraintuitivo. El tiempo de ciclo no se veía afectado de forma significativa por qué tan adentro del rack tenía que alcanzar el robot. La variación venía casi por completo de tomas fallidas que requerían reintentos. En otras palabras, el costo de una posición difícil en el rack no es tiempo, es confiabilidad, y las dos cosas no son intercambiables.
Escribir lo que no funcionó
Lo más inusual del reporte de Prueba de Principio no es la tasa de éxito. Es la sección que lista lo que todavía estaba mal.
El reporte dice directamente que el modelo de reconocimiento no estaba terminado, y después enumera tres limitaciones específicas. Cuando el rack está lleno y la cámara está a su mayor distancia, el sistema podía identificar el propio poste del rack como pieza candidata. Una columna en particular calificaba de forma consistente con menor confianza de toma que las demás, a veces lo bastante bajo para quedar excluida del procesamiento. Y el sistema no tenía forma de reportar que un rack estaba vacío.
Nada de eso tenía que ir en un documento escrito para ganar una orden de compra. Ponerlo es lo que vuelve creíbles los demás números, y le dio a ambas empresas una lista compartida sobre la cual trabajar en vez de una sorpresa durante la puesta en marcha.
Los tres se cerraron, y cómo se cerraron es instructivo. La detección falsa del poste se corrigió en Brantford, trabajando con Apera. La columna débil se corrigió en sitio, otra vez junto con Apera. El tercero no se corrigió, porque al revisarlo no hacía falta: en vez de enseñarle al sistema a reconocer un rack vacío, la celda simplemente cuenta piezas y se detiene cuando ha tomado las que espera.
Vale la pena detenerse en ese último. El instinto en automatización guiada por IA es resolver cada problema con más modelo. La mejor respuesta aquí fue un contador.
El reintento que hizo la diferencia
La pieza de ingeniería más interesante de este proyecto está enterrada en la diferencia entre dos programas del robot.
La primera rutina de toma magnética hizo lo obvio. Si una pieza estaba atorada, aplicar más fuerza magnética, liberarla y llevarla a la posición de descarga. Funcionaba, y producía descargas fallidas, por algo que solo es obvio en retrospectiva.
Como lo dijo el programador del robot: la cámara te da una posición confiable la primera vez, pero una vez que interactuaste con la pieza, tu ubicación de toma ya no es exactamente la misma.
Una pieza que necesita fuerza extra para zafarse no se libera en una orientación predecible. Se libera chueca, sostenida por un imán que ahora la está sujetando en un lugar distinto al que el sistema de visión dijo. Llevar esa pieza a la descarga es cargar un agarre que uno sabe malo a través de la celda, a ver qué pasa.
La rutina revisada se niega a hacer eso. Cuando una pieza requiere más magnetismo para zafarse, el robot la suelta de inmediato, en la posición de zafado, sin intentar la descarga. Después vuelve a tomar la pieza, que ahora está suelta, desde una posición de cámara fresca y con un agarre conocido. El conteo de descargas fallidas bajó.
Es un cambio pequeño de lógica y un cambio significativo de filosofía: en vez de intentar rescatar una toma comprometida, deséchela y tome una limpia.
Leer el rack en vez de suponerlo
El otro desarrollo notable atacó la deformación del rack de frente.
Como los racks se distorsionan con el tiempo, los ganchos que sostienen las piezas al frente de cada columna no están donde dice el dibujo. Se mueven de columna a columna y de rack a rack. En vez de tratarlo como ruido a tolerar, el equipo entrenó un modelo de IA adicional para encontrar los ganchos mismos.
El resultado es una rutina que localiza el gancho al frente de cada columna y lo usa como referencia en vivo. Después de tomar una pieza, se asocia a su columna de gancho, se posiciona respecto a ese gancho, se inclina alrededor de él y se fusiona en una sola trayectoria para la descarga. La posición XY y la profundidad vienen ambas de lo que la cámara realmente ve y no de cómo se supone que se ve el rack.
Un rack deformado deja de ser fuente de error y se vuelve una entrada medible.
Del estudio a la celda
El cliente firmó la Prueba de Principio el 8 de julio de 2025. La orden de compra llegó al día siguiente.
De ahí el proyecto corrió a buen paso. Aprobación de diseño a mediados de julio. Enrejado, puerta corrediza, caja de puerta, carros y dress pack en consignación llegando durante julio y principios de agosto. Revisión de salud y seguridad previa al arranque el 22 de agosto. Pruebas de aceptación de sistema y liberación el 28 de agosto, con la lista de puntos abiertos de liberación cerrada el mismo día. El paquete completo de documentación para el cliente salió el 10 de septiembre.
El cliente emitió su propia lista de puntos abiertos posterior a la liberación el 10 de septiembre. De los once puntos, Ethos cerró del uno al diez para el 16 de septiembre. El punto once quedaba fuera del alcance original y se cotizó por separado en vez de absorberse en silencio, que es la manera correcta de manejar una pregunta de alcance entre dos empresas que piensan seguir trabajando juntas.
Por qué este importa
El logro técnico es un robot sacando piezas de forma confiable de un rack que nunca se diseñó para un robot, guiado por un modelo de visión que califica su propia confianza y al que se le permite no estar seguro.
El logro comercial es distinto y probablemente más interesante. Ethos asumió el riesgo de demostrar una aplicación no probada, en su propio piso, con hardware del cliente, antes de que hubiera contrato. El cliente asumió el riesgo de entregar un robot y piezas de producción para averiguarlo. Ambas partes recibieron un reporte honesto con las fallas contadas, y después el trabajo avanzó sobre un entendimiento compartido de exactamente dónde era fuerte el sistema y dónde seguía delgado.
Esa es mejor base que una especificación que promete todo y descubre la verdad en la corrida a ritmo.
Para los fabricantes que sopesan la misma pregunta, el camino ya está trillado: un estudio de factibilidad con CAD o piezas de muestra para establecer el ajuste técnico y el tiempo de ciclo antes de comprar hardware, después una celda piloto que demuestre toma y colocación en condiciones reales, después producción. La mayor parte del riesgo se retira en el piso del integrador, que es donde corresponde.