Imagina esto: cuarenta robots móviles autónomos compartiendo el suelo de un almacén. Se cruzan en las intersecciones y se ceden el paso. Pasan por pasillos estrechos sin un rasguño. Honestamente, son más disciplinados que los conductores humanos en hora punta. La primera vez que lo vi desde un entresuelo en un centro de distribución en Arizona, me quedé allí unos veinte minutos con una sola pregunta en la cabeza: ¿quién dirige esta orquesta? Después de pasar una tarde con sus ingenieros, tenía la respuesta. No hay un único "supercerebro" que dé cada orden. Hay un sistema llamado programación multiagente. Este artículo lo desglosa en tres partes — cómo se asignan los trabajos, cómo los robots encuentran su camino y qué pasa cuando dos quieren el mismo trozo de suelo — y luego dice a partir de qué tamaño de flota realmente merece la pena el esfuerzo.
Dos cifras para poner escala. En 2012, Amazon pagó 775 millones de dólares por Kiva Systems, incorporando robots transportaestanterías a sus centros logísticos. En 2023, Amazon dijo que tenía más de 750.000 robots desplegados en sus almacenes. En poco más de una década, los robots móviles pasaron de proyectos piloto a equipamiento estándar en las grandes instalaciones. Y detrás de esa cifra de 750.000, lo difícil nunca fue hacer que un robot conduzca. Fue hacer que docenas o cientos de ellos compartan un mismo techo sin chocar, sin bloquearse mutuamente ni dejar media flota ociosa. Ese es el problema que la programación multiagente existe para resolver.
Quién se queda el trabajo
La primera tarea del programador es la asignación de tareas: entregar un trabajo como "recoger una bandeja en la estantería A y llevarla a la estación de empaquetado B" al robot adecuado. Simple de describir, lleno de matices en la práctica.
Hay dos escuelas principales. Una es la basada en subastas: cada vez que aparece un trabajo, todos los robots libres hacen una "oferta" según lo lejos que estén de la estantería, cuánta batería les queda y si ya tienen algo cerca. La oferta más baja gana. La otra es la optimización centralizada: un servidor central recoge todos los trabajos y el estado de todos los robots, y calcula de una vez la asignación globalmente óptima.
Las subastas son rápidas y sobreviven a puntos únicos de fallo — que un robot se quede fuera de línea no impide que el resto siga tomando trabajos. El precio es la optimalidad local: el kilometraje total de la flota sale más alto que el óptimo teórico. La optimización centralizada produce planes preciosos, pero con docenas de robots y cientos de trabajos nuevos por segundo, el solucionador no puede seguir el ritmo en tiempo real, y cuando el servidor tose, todo el suelo tose con él.
Mi opinión es directa: para flotas de menos de 50 robots, las subastas más un puñado de reglas simples son más que suficientes. No persigas la optimalidad global desde el primer día. Los kilómetros que ahorres no cubrirán la complejidad ni el tiempo de depuración que te cuesta. Una vez vi un almacén de comercio electrónico de 30.000 pies cuadrados con 12 robots corriendo un programador con optimización global completa. Los ingenieros lo ajustaron durante tres meses, y la temporada alta la salvó igualmente un humano tocando asignaciones manuales en una tableta. En la elección de algoritmos, "suficientemente bueno" vale su peso en oro.
Cómo encuentran su camino
Una vez asignado el trabajo, el robot necesita una ruta. Los AMR no leen señales como las personas. Leen mapas.
El suelo del almacén se divide en una cuadrícula invisible. Cada celda es transitable u obstáculo. El programador ejecuta un algoritmo de búsqueda de rutas de la familia A* para calcular la ruta de inicio a fin de cada robot. Suena como la navegación del teléfono, pero la versión de almacén añade una capa de código de circulación: los pasillos principales se convierten en calles de un solo sentido, las intersecciones reciben puntos de cesión, las zonas de carga y las áreas de trabajo manual se convierten en zonas lentas, y los robots cargados circulan por carriles virtuales distintos a los vacíos.
Aquí va un tropiezo que viví yo mismo, para que no tengas que vivirlo tú. Los robots se detenían en emergencia en una esquina, los registros llenos de alertas de obstáculos. Cambiamos el lidar, reajustamos parámetros tres veces, nada funcionó. Resultó que se había instalado un nuevo punto de acceso de alta potencia encima de esa esquina, y sus ráfagas de radio dejaban sin paquetes de localización durante unos milisegundos cada vez. Los robots creían haber perdido su posición, así que frenaban y esperaban instrucciones. Lección: cuando la planificación de rutas se porta mal, revisa la cobertura wifi y la planicidad del suelo antes de culpar al algoritmo. Los algoritmos no pueden arreglar el entorno físico. Esta frase aparecerá una vez más.
Qué pasa en la intersección
Docenas de robots comparten una misma red de vías, así que los encuentros en las intersecciones son rutina. La resolución de conflictos decide quién pasa primero, quién cede y — lo más importante — cómo garantizar que dos robots nunca acaben cara a cara en un pasillo de un solo robot de ancho sin que ninguno quiera retroceder.
La técnica caballo de batalla es la tabla de reservas. Cada robot no solo planifica su propia ruta; "reserva" los tramos de vía que ocupará en los próximos segundos, reservando espacio tanto en el tiempo como en la geografía. Cuando el siguiente robot planifica su ruta y ve un tramo ya reservado para un intervalo de tiempo dado, cambia de ruta o espera un momento. Las reglas de prioridad suelen ser por orden de llegada, los robots cargados antes que los vacíos, y un robot que corre a cargar gana a todo — porque un robot muerto cuesta más que un atasco.
El bloqueo mutuo es el escenario de pesadilla. Dos robots se encuentran de frente en un pasillo estrecho, y la tabla de reservas de cada uno dice "yo tengo la preferencia". Punto muerto. No evitas el bloqueo mutuo con negociación al borde de la vía. Lo evitas con el diseño de la red vial: pasillos principales en bucles, pasillos estrechos estrictamente de un solo sentido, de modo que un encuentro frontal sea estructuralmente imposible. Cuando evalúo un sistema de programación, el conteo de bloqueos mutuos es una métrica obligatoria. Pónlo a correr una semana seguida — si los bloqueos llegan a dos cifras, el diseño de la red vial está mal. No dejes que nadie te tranquilice con "caso límite raro".
Cuándo merece la pena
Finalmente, la pregunta que más me hacen: con nuestro tamaño de flota, ¿necesitamos programación multiagente?
Esta es mi línea divisoria. Con menos de 10 robots, no te molestes en la programación centralizada. La inteligencia por robot más reglas fijas de circulación más una tableta para intervención manual son suficientes. La programación centralizada a esa escala es un mazo para un clavo, y un mazo torpe además. De 20 a 50 robots, la asignación centralizada de tareas más las reglas de circulación de la red vial empiezan a rendir claramente — ese es el punto dulce de la programación multiagente. Pasado el centenar, necesitas zonas y jerarquía: el sistema central solo gestiona el flujo de trabajos entre zonas mientras cada zona se autogobierna, o el cómputo y la latencia de comunicación del servidor central cederán primero.
Dos escenarios en los que te diría que ni lo toques. Primero, almacenes antiguos con suelos desnivelados y estanterías de separación irregular, donde la localización se desvía todo el día. Un algoritmo de programación en ese entorno físico se la pasa apagando fuegos. Segundo, almacenes con mareas extremas de demanda — digamos, volumen de temporada alta diez veces el normal, 20 robots bastan en un día tranquilo y en diciembre hacen falta 80. La programación resuelve "cómo operar". No resuelve "no hay bastantes robots". Arregla primero la capacidad elástica, luego hablemos de inteligencia.
Tres recomendaciones accionables para mañana:
Primero, antes de comprar un solo AMR, saca una semana de datos de tareas de tu WMS y construye un mapa de calor de dónde y cuándo se agrupan los trabajos. Luego dimensiona la flota y elige el enfoque de programación. Si no sabes cómo se ve tu propia carga de trabajo, no estás listo para elegir un algoritmo.
Segundo, diseña primero la red vial. Pasillos de un solo sentido, bucles, ubicación de las zonas de carga — dibújalo en papel y pasa el peor caso por él: dos robots totalmente cargados encontrándose en el pasillo más estrecho, cinco robots necesitando cargar a la misma hora pico. Si no funciona en papel, no funcionará en el suelo.
Tercero, no aceptes "los robots se están moviendo" como éxito. Vigila tres números: tiempo medio de espera de los trabajos, bloqueos mutuos por semana y tiempo en cola de carga. Cuando esos tres se ven sanos, el sistema de programación está genuinamente sano.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
