Un software de gestión de flotas de robots permite a un solo equipo ver y manejar muchos robots a la vez: dónde está cada uno, cuánta batería le queda, en qué tarea trabaja y qué falló cuando se detuvo. Un robot suelto viene con su propia aplicación. Una docena de robots de tres fabricantes vienen con tres aplicaciones, tres mapas y tres bandejas de alertas, y ese suele ser el momento en que los operadores empiezan a buscar una plataforma de gestión de flotas de robots.

Lo que los compradores suelen descubrir más tarde es que los robots no son lo único que importa en unas instalaciones. Puertas, muelles de carga, sensores de fugas y sistemas de alarma tienen información que los robots nunca ven, y que la flota pueda aprovecharla o no determina en buena medida lo útil que llega a ser.

Lo esencial

  • El software de gestión de flotas de robots sigue el estado, la batería, la ubicación, las tareas y las incidencias de muchos robots, y decide qué robot hace cada trabajo.
  • La mayoría de los fabricantes de robots ofrecen software de flotas para su propia marca. Las flotas mixtas necesitan una capa que hable con todas las marcas mediante API, MQTT o un estándar de interfaz como VDA 5050.
  • El paso más importante es que la flota comparta el contexto del edificio, de modo que el evento de un sensor pueda convertirse en una tarea para un robot.
  • Las órdenes atraviesan fabricantes y protocolos, así que cada escenario se prueba con respuestas simuladas antes de ejecutarse en robots reales.

¿Cómo funciona la gestión de flotas de robots móviles?

Los robots móviles se dividen en dos grandes tipos. Los vehículos de guiado automático (AGV) siguen rutas fijas marcadas con cables, cinta magnética o marcas. Los robots móviles autónomos (AMR) construyen un mapa y planifican su propio camino esquivando obstáculos. Ambos envían un flujo constante de datos de estado a un servidor de flota: posición en un mapa, nivel de batería, tarea actual, velocidad, códigos de error y si están circulando, cargando, inactivos o bloqueados. El servidor de flota convierte ese flujo en tres funciones: visibilidad, asignación de trabajo, y tráfico y carga.

La visibilidad consiste en un mapa con la posición de cada robot, una lista de qué robots están trabajando, cargando o en fallo, y un historial de lo que hizo cada uno durante el turno.

En la asignación de trabajo, las tareas llegan desde un sistema de gestión de almacenes, el sistema de pedidos de un hospital, un pulsador de llamada en la pared o una persona con una tableta, y el software de flotas decide qué robot se encarga de cada una. Los sistemas sencillos eligen el robot libre más cercano. Los más avanzados tienen en cuenta el nivel de batería, la carga útil y la longitud de la cola en el destino.

El tráfico y la carga entran en juego en cuanto los robots comparten espacio. Dos robots que se dirigen al mismo pasillo estrecho necesitan una regla que decida quién pasa primero, y una flota en la que todos los robots se quedan con poca batería a la misma hora necesita un plan de carga que mantenga suficientes robots en planta.

La planificación de rutas y la evasión de obstáculos se quedan en el robot. El servidor de flota indica adónde ir y cuándo; el software del propio robot calcula cómo llegar sin chocar con nada. Esa división importa al comparar productos, porque la «gestión de flotas» de un fabricante puede significar un control a fondo de sus propios robots, mientras que para otro significa una supervisión más ligera de varias marcas.

La carga se entiende mejor con números. Supongamos que un almacén utiliza 12 AMR durante 16 horas al día y que cada robot necesita aproximadamente una hora en el cargador por cada cuatro horas de circulación. Eso supone el 20 % del tiempo de cada robot, así que, de media, unos 2,4 de los 12 robots están cargando en cualquier momento y quedan unos 9,6 disponibles. Si el pico de la tarde exige 11 robots en movimiento, la flota solo puede cubrirlo si el software recarga las baterías durante las horas tranquilas previas al pico.

Gestión de flotas de robots de varios fabricantes

La mayoría de los fabricantes de robots incluyen software de flotas con sus máquinas, y para una sola marca suele cumplir bien. La dificultad empieza cuando unas instalaciones incorporan una segunda marca: un remolcador de una empresa, un robot de patrulla de otra, unos cuantos AMR de una tercera. Cada uno tiene su propio formato de mapa, sus propios códigos de estado y su propia idea de lo que cuenta como error.

Hay tres formas habituales de reunir una flota mixta:

  1. API de los fabricantes. La mayoría de los robots comerciales exponen una API REST o WebSocket, y algunos publican por MQTT, para el estado y las tareas. Una capa multifabricante consulta cada una y traduce los resultados a un modelo común. Es la vía más habitual hoy en día, y la mayor parte del esfuerzo se va en esa traducción.
  2. Estándares de interfaz. VDA 5050, publicado por la asociación alemana de la industria automovilística VDA junto con la asociación de fabricantes de maquinaria VDMA, define cómo un sistema de control maestro envía órdenes a los vehículos sin conductor y cómo estos informan de su estado, mediante mensajes JSON a través de un broker MQTT. Los vehículos que lo implementan pueden compartir un mismo controlador sin adaptadores a medida. El estándar cubre los mensajes, no cómo planifica cada vehículo su ruta.
  3. Middleware en el robot. Los equipos que construyen sus propios robots suelen ejecutar ROS 2 en ellos y llevar sus datos a la capa de flota mediante un puente.

Las tres vías desembocan en un modelo común: una única definición de batería, posición, estado de la tarea y fallo a la que se traduce cada marca, y el trabajo de integración de cada robot nuevo consiste precisamente en esa traducción.

Los mapas requieren el mismo tratamiento. Cada marca construye su mapa en su propio sistema de coordenadas, con su propio origen, orientación y, a veces, escala. Para mostrar todos los robots sobre un único plano de las instalaciones, las coordenadas de cada fabricante deben transformarse a un sistema común, normalmente haciendo coincidir unos cuantos puntos de referencia que comparten todos los mapas, como una puerta o una columna. Si esa alineación se desvía un metro, en la vista compartida los robots parecen atravesar paredes, aunque cada uno esté exactamente donde su propio software cree que está.

Al buscar empresas de software de gestión de flotas de robots aparecen dos grupos de proveedores. Los fabricantes de robots incluyen un gestor de flotas con sus propias máquinas, que a menudo es la solución económica para gestionar la flota cuando es de una sola marca. Los proveedores independientes de software de gestión de flotas multirrobot venden una capa que se sitúa por encima de varias marcas. Las listas del tipo «los 10 mejores software de gestión de flotas de robots de 2025» mezclan ambos grupos, y además incluyen software de gestión de flotas de robots industriales para brazos fijos y células de producción, que resuelve un problema distinto. Al comparar las principales empresas de software de gestión de flotas de robots, conviene preguntar a cada proveedor qué modelos de robot tiene ya integrados, qué datos obtiene de cada uno y quién mantiene la integración cuando cambia el firmware de un robot.

¿Qué debe mostrar un panel de gestión de flotas de robots?

Un buen panel de gestión de flotas de robots responde a las preguntas que se hace un supervisor de turno sin tener que abrir una segunda aplicación.

Pregunta Qué muestra el panel Por qué importa
¿Dónde está cada robot? Posición en directo sobre el mapa de las instalaciones, hora de la última actualización Un robot cuya última actualización es antigua puede estar atascado o desconectado
¿Puede seguir trabajando? Nivel de batería, estado de carga, tiempo hasta la próxima carga Indica si el trabajo de la próxima hora está cubierto
¿Qué está haciendo? Tarea actual, longitud de la cola, tiempo dedicado a la tarea Los tiempos de tarea largos apuntan a rutas bloqueadas o a malas asignaciones
¿Qué ha fallado? Fallos activos, paradas de emergencia, pérdida de localización, acoplamientos fallidos Indica a alguien adónde ir y qué arreglar
¿Cómo va la flota en conjunto? Tareas por hora, utilización, intervenciones por turno Muestra si ayuda más añadir robots o corregir procesos

Lo mejor es empezar por las intervenciones por turno. Una intervención es cualquier ocasión en que una persona tiene que actuar: despejar un pasillo bloqueado, empujar un robot que ha perdido su posición, volver a colocarlo en el cargador. Representadas por robot y por zona, las intervenciones muestran dónde está el problema real. Si la mayoría se producen en un mismo pasillo, es el pasillo lo que necesita atención, y comprar más robots solo alargaría la cola en ese punto.

Las incidencias de los robots también compiten con todas las demás alertas de las instalaciones. Un supervisor que recibe los fallos de la flota en una bandeja y las alarmas del edificio en otra acaba pasando por alto alguna, así que conviene decidir pronto qué incidencias llegan a las mismas personas que las alarmas del edificio.

Esa vista compartida es la parte para la que construimos Kilo, junto al gestor de flotas que suministre el fabricante del robot. Si un robot acepta órdenes por MQTT, directamente o mediante un pequeño puente desde su API, es posible conectarlo a los sensores LoRaWAN, mioty y MQTT del edificio y crear una regla que convierta el evento de un sensor en una tarea para el robot. Un sensor de fugas bajo una estantería detecta agua por la noche, y una sola regla lanza una alarma para el equipo de mantenimiento y, a la vez, envía a ese pasillo un robot equipado con cámara. Antes de que la regla mueva un robot real, se recorre paso a paso en el depurador de Kilo con la respuesta del robot simulada. Que sensores, puertas, máquinas y robots compartan así un mismo contexto es lo que entendemos por IA física para instalaciones conectadas.

Cómo implantar la gestión de flotas de robots

Los despliegues que salen bien suelen seguir más o menos este orden, sea cual sea la herramienta elegida:

  1. Inventariar la flota y sus interfaces. Para cada modelo de robot, anotar qué expone (API REST, MQTT, VDA 5050, ROS 2), qué datos se pueden leer (posición, batería, tarea, fallos) y qué órdenes acepta, como ir a una ubicación, volver a la base o hacer una pausa.
  2. Definir un único modelo de datos. Acordar nombres de campo, unidades y estados, y después traducir a ellos los códigos de cada fabricante.
  3. Decidir quién asigna las tareas. A menudo, el gestor de flotas del propio fabricante sigue controlando el tráfico dentro de su marca, mientras la capa propia le entrega los trabajos y recoge los resultados.
  4. Hacer un piloto en una zona durante un turno. Medir las tareas por hora y las intervenciones antes de escalar, para tener una referencia con la que comparar.
  5. Conectar el edificio. Puertas, muelles, sensores y alarmas forman parte del mismo panorama que los robots.
  6. Ensayar cada escenario fuera de la zona de operación. Probar la nueva lógica de tareas en una zona de pruebas o con un simulador antes de que llegue a un robot en producción, porque una tarea que atraviesa fabricantes y protocolos pasa por más sistemas que una que se queda dentro de una sola marca.

Preguntas frecuentes sobre la gestión de flotas de robots

¿Cuánto cuesta un software de gestión de flotas de robots?

Los modelos de precios varían. Los fabricantes de robots suelen incluir su software de flotas en la compra o el alquiler de los robots, mientras que las plataformas independientes suelen cobrar una suscripción por robot o por instalación. El trabajo de integración de cada nuevo modelo de robot se factura a menudo por separado, así que conviene pedir esa cifra junto con el precio de la licencia.

¿La gestión de flotas de AGV es lo mismo que la de robots móviles?

Se solapan, pero el énfasis es distinto. El software de flotas de AGV gestiona tramos de ruta fijos y bloquea el acceso a un tramo mientras un vehículo lo ocupa. El de AMR dedica más esfuerzo a las zonas, la asignación de tareas y la congestión, porque cada robot elige su propia ruta.

¿El software de gestión de flotas de robots funciona en la nube o en local?

Existen ambas opciones. El control del tráfico de robots que comparten pasillos suele ejecutarse en un servidor local, porque no puede depender de una conexión a internet, mientras que los informes y las vistas de varias instalaciones suelen funcionar en la nube. Normalmente, si se cae la red, los robots terminan el movimiento en curso y, cuando vuelve, esperan nuevas instrucciones.

Para probar la vista compartida basta con un robot que ya publique su estado por MQTT. Se registran su nivel de batería y el estado de su tarea como un dispositivo en Kilo, se añade un contacto en la puerta del muelle por la que más pasa y se representan ambos en un mismo panel. Después se crea una regla que avise al supervisor de turno cuando el robot informe de una parada de emergencia. Dos dispositivos y esa única regla funcionan con el plan gratuito, y una semana de datos muestra con qué frecuencia las paradas del robot coinciden con la actividad de la puerta.