En resumen: la asignación de tareas en un RCS no es "enviar a quien esté más cerca". Las cuatro variables que realmente deciden la calidad de la asignación son la distancia, la batería, el tipo de tarea y la congestión, ponderadas en conjunto. He visto fallar tres veces el valor predeterminado de más cercano primero, siempre con el mismo guion. Si la lógica de asignación es correcta, una flota de 20 robots AMR puede reducir su tasa de viajes en vacío de alrededor del 40% a menos del 25%, y el bloqueo de pasillos en hora punta prácticamente desaparece.
Por qué la asignación por cercanía sigue fallando
Septiembre de 2023, un almacén de ropa de un 3PL en el este de China, 18 AMR de tipo elevador en puesta en marcha. El RCS usaba la política predeterminada del proveedor: asignación puramente por cercanía. El día del lanzamiento, en plena promoción, cayeron seis tareas de entrada a la vez. El RCS envió los seis robots más cercanos, y los seis convergieron en el mismo pasillo principal. Los robots delanteros esperaban a que los traseros cedieran el paso; los traseros estaban bloqueados por los delanteros. Once minutos de parálisis total. Mientras tanto, cuatro tareas de salida en el extremo opuesto quedaron sin robots disponibles: los más cercanos estaban todos atrapados en el atasco. He visto este mismo fallo tres veces.
La asignación por cercanía optimiza la distancia en vacío de un solo envío e ignora cómo queda la flota después del envío. Enviar seis robots en la misma dirección a la vez es fabricar tu propio atasco.
Las cuatro variables que realmente usa la asignación de un RCS
En mi lista de verificación de la víspera de la puesta en marcha, la asignación de tareas tiene cuatro puntos, verificados uno por uno:
- Distancia: no la distancia en línea recta, sino la longitud del trayecto en vacío: la distancia real de desplazamiento desde el robot hasta la tarea, incluyendo pasillos de sentido único y desvíos. Muchas tareas están a 30 metros en línea recta y a 120 metros de conducción real.
- Batería: los robots por debajo del 30% de carga deben quedar automáticamente relegados solo a viajes cortos; por debajo del 20%, deben quedar bloqueados para nuevas tareas y enviarse a cargar. Vi un proyecto en el que el RCS asignó un transporte largo entre zonas a un robot al 12%. Se quedó sin batería en medio del pasillo, bloqueando una arteria principal hasta que alguien lo empujó a mano.
- Tipo de tarea: no todos los robots pueden hacer todos los trabajos. Los de tipo elevador y los de tipo horquilla no se pueden mezclar, y los palés pesados (de más de una tonelada, por ejemplo) solo van a modelos de alta capacidad. El conjunto de tareas del RCS debe filtrarse por las etiquetas de capacidad del vehículo antes de cualquier asignación.
- Congestión: ¿entrará otro robot en el pasillo objetivo en los próximos dos minutos? El RCS debe asignar por reserva: al enviar, reservar el trayecto y limitar las entradas en el mismo sentido por pasillo (normalmente dos o tres, según el ancho del pasillo).
Mi orden de prioridad recomendado: tipo de tarea (filtro estricto primero) → batería (restricción estricta) → congestión (penalización dinámica) → distancia (desempate). La mayoría de los valores predeterminados de RCS ponen la distancia primero. Esa es la causa raíz de los fallos.
Estrategias de asignación de tareas robóticas comparadas: elegir una de cuatro
| Estrategia | Lógica | Fortalezas | Debilidades | Ideal para |
|---|---|---|---|---|
| Más cercano primero | Gana el trayecto en vacío más corto | Simple, respuesta rápida | Atascos, ignora la batería | Flotas de menos de 10 robots, fuera de hora punta |
| Asignación por zonas | Almacén dividido en zonas, robots fijos por zona | Cero trayectos en vacío entre zonas, fácil de razonar | Desequilibrio de carga; una zona caliente colapsa | Almacenes con distribución de tareas estable |
| Basada en subastas | Las tareas se difunden; cada robot puja su coste; gana la puja más baja | Casi óptimo global, considera de forma natural batería y distancia | Compleja; necesita mucha capacidad de cómputo del RCS | Flotas de más de 30 robots |
| Preasignación + replanificación dinámica | Planifica 5 minutos por adelantado, replanifica en vivo ante congestión | La más estable en hora punta, menos bloqueos | Necesita previsiones de pedidos del WCS | Almacenes de comercio electrónico con picos marcados |
¿Cómo elegir? Tres preguntas: ① ¿La flota supera los 20 robots? Si es así, descarta el más cercano primero. ② ¿Hay picos evidentes? Si es así, usa preasignación. ③ ¿Puede el hardware de tu RCS ejecutar subastas? Si no, recurre a zonas con ajuste manual. No adores el algoritmo más sofisticado: gana el que funciona de forma estable.
Lista de verificación de la víspera de la puesta en marcha: edición de asignación de tareas del RCS
- ¿Umbrales de bloqueo por batería baja establecidos? Yo uso 20% de bloqueo, 30% de relegación.
- ¿Etiquetas de capacidad del vehículo emparejadas con los tipos de tarea? Haz una prueba negativa: emite deliberadamente una tarea incompatible y confirma que el RCS la rechaza.
- ¿Límites de concurrencia por pasillo establecidos? Establece las arterias principales y los pasillos secundarios por separado.
- ¿Línea base de viajes en vacío medida? Primera semana: registra diariamente el kilometraje en vacío dividido por el kilometraje total. Por encima del 35%, reajusta.
- ¿Responsabilidades de RCS frente a WCS documentadas? Quién divide las tareas, quién asigna los robots, quién asume la contingencia cuando la interfaz expira: todo por escrito.
Tres modos de fallo costosos
Fallo 1: atascos de robots en un pasillo. Mayo de 2024, un almacén de comercio electrónico de cosmética en el sur de China, 24 AMR. En la promoción de medianoche, cayeron 40 tareas de salida en 10 segundos. El más cercano primero envió 14 robots al mismo pasillo principal hacia el muelle de salida. Bloqueo total. La solución: añadir reserva de pasillo al RCS; cuando las entradas en el mismo sentido superan tres, las tareas posteriores se desvían automáticamente o retrasan el envío 30 segundos. Tras el cambio, el tiempo de recorrido del pasillo principal con oleadas de igual tamaño bajó de una media de 9 minutos a menos de 3.
Fallo 2: líneas difusas entre RCS, WCS y PLC. La causa raíz más común de los proyectos condenados. La división del trabajo debe ser: el WCS descompone los pedidos en tareas de movimiento (mover qué de A a B); el RCS asigna tareas a robots concretos, planifica rutas, gestiona el tráfico y programa la carga; el PLC solo maneja el hardware de bajo nivel (rodillos, elevadores). Vi un proyecto en el que tanto el WCS como el RCS planificaban rutas, y los dos planes de ruta se enfrentaban entre sí: robots girando en el sitio en las intersecciones. La cura: escribir el contrato de interfaz en piedra. El WCS emite tareas, nunca rutas. Las rutas son territorio 100% del RCS.
Fallo 3: enviar sin comprobar la batería. Cubierto arriba: un robot con poca batería en un transporte largo es una bomba de relojería. Un detalle más: las ubicaciones de los cargadores pertenecen al modelo de asignación. Al enviar, asigna a los robots con poca batería tareas que terminen cerca de un cargador, para que terminen el trabajo y entren directamente a cargar. Dos pájaros de un tiro.
Una decisión contraintuitiva: no operar la flota a plena carga
Muchos propietarios de almacenes piensan que un robot parado es dinero desperdiciado. Error. Mi regla: mantener siempre el 15–20% de la flota como capacidad flexible. Las tareas llegan en oleadas; una flota a plena carga golpeada por una oleada no tiene robots que enviar, así que todo se acumula en cola, y las colas retrasan todas las tareas a la vez. Con el 20% en reserva, la oleada se absorbe y el tiempo medio de espera de las tareas realmente baja. En ese almacén de cosmética, mantuvimos 4 de 24 robots como flex (solo para tareas de emergencia), y el tiempo medio de espera de las tareas durante la promoción cayó aproximadamente un tercio frente a operar con los 24. El contrapunto: cuatro robots parecen ociosos en lo local, pero todo el sistema funciona más rápido en lo global. Esa es la lección más difícil de la asignación de tareas en un RCS: la asignación óptima no es la que mantiene ocupado a cada robot; es la que mantiene el sistema desbloqueado.
Por Lin Xiao, Consultor de Implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
