Swarm-Steward: commanding a robot swarm with natural languageSwarm-Steward: comandar un enjambre con lenguaje natural

Imagine telling a fleet of drones what to do the same way you'd brief a colleague — "search the northern sector, keep an eye on the tank farm, and orbit building 21" — and the swarm just… does it. That's the idea behind Swarm-Steward, the NAMUR project's flagship system, presented at IEEE ICUAS 2026 in Corfu, Greece.Imagina dar órdenes a una flota de drones igual que a un colega — "busca el sector norte, vigila el parque de tanques y orbita el edificio 21" — y el enjambre… simplemente lo hace. Esa es la idea de Swarm-Steward, el sistema insignia del proyecto NAMUR, presentado en IEEE ICUAS 2026 en Corfú, Grecia.

From running chilly winter field experiments in snowy Denmark to presenting under the summer sun in Corfu, this work is the project's most complete demonstration yet of LLM-driven multirobot control: Swarm-Steward: Scalable and Reliable Natural-Language Coordination of Autonomous Aerial and Ground Robots. De los fríos experimentos invernales en la nevada Dinamarca a la presentación bajo el sol de Corfú: esta es la demostración más completa hasta la fecha de control multirobot con LLMs — Swarm-Steward: Scalable and Reliable Natural-Language Coordination of Autonomous Aerial and Ground Robots.

The intent-to-control gapBrecha intención-control

Multi-robot systems offer strong advantages for tasks that benefit from coverage, redundancy, and parallelism — including search and rescue and infrastructure inspection. In practice, however, operating a swarm remains difficult: high-level intent must be translated into platform-specific commands, operators must track robot identifiers and constraints, and plans must be continuously adapted as state changes (battery, position, connectivity, environment). This intent-to-control gap limits who can effectively use swarm systems and how quickly they can be deployed. Los sistemas multi-robot son ideales cuando se necesitan cobertura, redundancia y paralelismo — p. ej., búsqueda y rescate o inspección de infraestructuras. Pero operar un enjambre sigue siendo difícil: hay que traducir la intención de alto nivel a comandos específicos de plataforma, seguir identificadores y restricciones, y adaptar los planes a cada cambio de estado (batería, posición, conectividad, entorno). Esta brecha intención-control limita quién puede usar sistemas de enjambre y con qué rapidez.

Swarm-Steward closes that gap through a conversational interface. Figure 1 shows the kind of interaction the system supports: the operator creates named groups, adjusts altitudes, reasons about spatial relationships, and requests coordinated behaviours — all in plain language. Swarm-Steward cierra esa brecha con una interfaz conversacional. La Figura 1 muestra la interacción: el operador crea grupos con nombre, ajusta altitudes, razona sobre relaciones espaciales y pide comportamientos coordinados — todo en lenguaje natural.

A hierarchical LLM multi-agent systemSistema de agentes LLM jerárquico

Swarm-Steward is a platform-agnostic architecture for conversational swarm control. The operator defines named groups and commands them through natural language to perform coordinated behaviours such as formation manoeuvring, orbiting, path traversal, and area coverage. The system separates concerns across four layers: Swarm-Steward es una arquitectura agnóstica para el control conversacional de enjambres. El operador define grupos con nombre y los comanda en lenguaje natural para ejecutar comportamientos coordinados: maniobras en formación, órbitas, recorridos y cobertura de áreas. El sistema separa responsabilidades en 4 capas:

• UI layer — natural-language commands, mission previews, and confirmations.Capa UI — comandos en lenguaje natural, previsualización y confirmaciones.
• LLM-MAS layer — a coordinator and specialized sub-agents that plan and ground requests.Capa LLM-MAS — un coordinador y sub-agentes que planifican y anclan peticiones.
• Action-execution layer — deterministic, schema-constrained group actions with a safety gate.Capa de ejecución — acciones de grupo deterministas y restringidas, con safety gate.
• Platform layer — the actual drones and robots, reached through a bridge (ROS 2/DDS or MQTT).Capa de plataforma — los drones y robots reales, a través de un bridge (ROS 2/DDS o MQTT).

Figure 2 summarizes the end-to-end pipeline: natural-language commands are decomposed by a Coordinator into staged sub-tasks executed by specialized agents, then dispatched as deterministic group actions. La Figura 2 resume el pipeline: un Coordinator descompone los comandos en sub-tareas por etapas que ejecutan agentes especializados, despachadas como acciones de grupo deterministas.

Specialized sub-agents strictly separate planning, grounding, and execution — see Figure 3. A key invariant is that only the Swarm agent may modify world state; the remaining agents are non-actuating and restricted to context gathering and synthesis. This keeps the LLM in the role of a smart operator rather than a risky driver. Los sub-agentes especializados separan estrictamente planning, grounding y execution — ver Figura 3. Un invariante clave: solo el agente Swarm modifica el estado del mundo; los demás solo recopilan y sintetizan contexto. Así el LLM actúa como operador inteligente, no como un conductor arriesgado.

The Coordinator decomposes natural-language commands into staged sub-tasks; the Spatial and History agents gather context (map relations and telemetry) but never actuate; only the Swarm agent proposes group-level actions through deterministic tools.El Coordinator descompone los comandos en sub-tareas por etapas; los agentes Spatial y History recopilan contexto (mapa y telemetría) pero nunca actúan; solo el agente Swarm propone acciones de grupo con herramientas deterministas.

Targeted retrieval-augmented groundingGrounding dirigido con RAG

All benchmarks below ran on the hardware summarized in Table 1. Todos los benchmarks usaron el hardware de la Tabla 1.

	Type	CPU	RAM	GPU (VRAM)	OS
PC-A	Desktop	Ryzen 9 5950X	32 GB	RTX 4090 (24 GB)	Ubuntu 22.04
PC-B	Laptop	Ultra 9 275HX	64 GB	RTX 5090 (24 GB)	Ubuntu 25.10

PC-A ran the simulation/model benchmarks; PC-B the real-world validation.PC-A ejecutó los benchmarks de simulación; PC-B la validación real.

To keep reasoning scalable, Swarm-Steward applies dual retrieval-augmented generation over both map features (Feature RAG) and telemetry variables (State RAG), injecting only relevant candidates at each step. Feature RAG grounds free-form geographic references by embedding map-feature descriptions and retrieving the top-k candidates most similar to the user query. Para escalar el razonamiento, Swarm-Steward usa generación dual aumentada por recuperación sobre features del mapa (Feature RAG) y telemetría (State RAG), inyectando solo los candidatos relevantes en cada paso. Feature RAG ancla referencias geográficas libres incrustando descripciones de features y recuperando los top-k más similares a la consulta.

We stress-tested it with up to 10,000 map features (in-domain synthetic noise included), across four embedding models — two cloud (OpenAI, Gemini) and two local (BGE-M3, E5-large-v2). Table 2 reports the results: all four saturate exact-name, partial-name, and category retrieval at or near 100% HR@10, so the main discriminator is descriptive queries, where Gemini and the local models reach 85–86% while OpenAI trails at 79%. Crucially, search latency stays below 30 ms even at the 10,000-feature pool, so scaling the map never inflates the LLM context. Lo estresamos con hasta 10,000 map features (con ruido sintético del dominio) y cuatro modelos de embedding — dos cloud (OpenAI, Gemini) y dos locales (BGE-M3, E5-large-v2). La Tabla 2 reporta: los cuatro saturan la recuperación por nombre exacto, parcial y categoría (≈100% HR@10); el discriminador son las consultas descriptivas: Gemini y los locales llegan a 85–86%, OpenAI a 79%. Además, la latencia de búsqueda queda bajo 30 ms incluso con 10,000 features: escalar el mapa nunca infla el contexto del LLM.

Model	Dim	Exact HR	Exact MRR	Partial HR	Partial MRR	Desc. HR	Desc. MRR	Mean HR	Mean MRR	Embed (ms)	Search (ms)
BGE-M3 (local)	1024	100	0.87	93	0.71	86	0.76	95	0.83	15.7	12.2
OpenAI (cloud)	1536	100	0.86	100	0.74	79	0.78	95	0.84	133.1	14.2
Gemini (cloud)	3072	100	0.87	100	0.74	86	0.84	97	0.86	380.3	24.7
E5-large-v2 (local)	1024	100	0.90	100	0.68	85	0.82	96	0.85	18.1	12.3

Category queries (always 100% HR / ≥0.98 MRR) omitted. (cloud) = API; (local) = GPU of PC-A.Consultas por categoría (100% HR / ≥0.98 MRR) omitidas. (cloud) = API; (local) = GPU PC-A.

Action management and lifecycle controlGestión de acciones y su ciclo de vida

World-modifying actions are tracked and executed under an explicit lifecycle managed by an Action Manager and an Action State Machine (ASM), shown in Figure 4. The Action Manager converts tool calls into tracked actions, maintains per-group priority queues, and dispatches actions sequentially per group; the ASM computes waypoints (including formation offsets and altitude adaptation), sends waypoint-level commands through the bridge, tracks progress from telemetry, and enforces runtime safety constraints — geofencing, altitude and separation limits — with optional operator preview before execution. Las acciones que modifican el mundo se rastrean y ejecutan bajo un ciclo de vida explícito gestionado por un Action Manager y una Action State Machine (ASM), ver Figura 4. El Action Manager convierte tool calls en acciones rastreadas, mantiene colas de prioridad por grupo y despacha secuencialmente; la ASM calcula waypoints (offsets de formación, adaptación de altitud), envía comandos por el bridge, sigue el progreso desde la telemetría y aplica restricciones de seguridad en runtime — geofencing, límites de altitud y separación — con vista previa opcional antes de ejecutar.

Does it scale? 5 to 500 drones¿Escala? De 5 a 500 drones

We evaluated the full orchestration pipeline in a controlled benchmark spanning two orders of magnitude: 5, 10, 25, 50, 100, 200, and 500 simulated drones, each configuration executed four times (28 sessions, 280 prompts total), using Llama 3.3 70B over an MQTT bridge. Table 3 reports the results. Evaluamos el pipeline de orquestación en un benchmark controlado de dos órdenes de magnitud: 5, 10, 25, 50, 100, 200 y 500 drones simulados, cada configuración ejecutada cuatro veces (28 sesiones, 280 prompts), con Llama 3.3 70B sobre bridge MQTT. La Tabla 3 reporta los resultados.

Drones	C	Success (%)	LLM time (s)	Tokens (×10³)	Payload (KB)
5	2,2,2,2	100.0	4.40 ± 0.10	600 ± 6	3.4
10	2,3,3,4	100.0	4.70 ± 0.42	619 ± 13	6.7
25	2,3,5,6	97.5	4.42 ± 0.28	619 ± 8	16.4
50	2,3,7,8	97.5	4.31 ± 0.06	623 ± 2	32.9
100	2,3,9,12	90.0	4.60 ± 0.28	655 ± 2	66.2
200	2,4,7,16	95.0	5.40 ± 0.36	728 ± 20	132.2
500	2,3,18,26	70.0	7.92 ± 0.70	899 ± 32	330.9

Overall: 92.9% success, 5.10 s mean LLM time, 678 ×10³ mean tokens, ~0.66 KB payload per drone. Llama 3.3 70B via Groq; MQTT bridge on PC-A.Global: 92.9% de éxito, 5.10 s de LLM, 678 ×10³ tokens, ~0.66 KB por drone. Llama 3.3 70B vía Groq; bridge MQTT en PC-A.

• 📈 Near-constant LLM token cost from 5 to 500 drones (600–899 ×10³ tokens) — the group-level abstraction means larger fleets mainly grow the state payload (~0.66 KB per drone), not the LLM context.📈 Coste de tokens LLM casi constante de 5 a 500 drones (600–899 ×10³ tokens): con grupos, las flotas grandes solo crecen el payload (~0.66 KB por drone), no el contexto.
• 🎯 92.9% task success across 280 distinct prompts; all configurations up to 50 drones stay at ≥97.5%.🎯 92.9% de éxito en 280 prompts; hasta 50 drones todo se mantiene en ≥97.5%.
• ✔️ The degradation appears mainly at N≥100 and stems from prompt-specific scaling limits (tool-call-budget constraints, context-window overflow) — not from incorrect coordinator planning, which stays accurate for every prompt where the model responds.✔️ La degradación aparece sobre todo con N≥100, por límites de escalado del prompt (tool-call budget, ventana de contexto) — no por fallos de planificación del coordinador, que acierta en todos los prompts donde el modelo responde.

Model benchmark: tool-calling reliability vs. latencyBenchmark: fiabilidad de tool-calling vs. latencia

To isolate model effects, we replayed the same 10 snapshots from the 50-drone setup across 15 models (3 runs × 10 snapshots = 30 replays per model) under identical world state, prompts, and evaluation rules, measuring Coordinator planning success, agent execution success, and mean end-to-end replay latency. Table 4 lists all benchmarked models; the stronger cloud models perform very well, but they do not dominate on efficiency — several high-capability models reach the same execution success while taking substantially longer. Para aislar los efectos del modelo, reproducimos los 10 snapshots de los 50 drones en 15 modelos (3 runs × 10 snapshots = 30 replays por modelo) con el mismo estado del mundo, prompts y reglas, midiendo planificación del Coordinator, ejecución de agentes y latencia media de replay end-to-end. La Tabla 4 lista todos: los cloud potentes rinden muy bien, pero no dominan en eficiencia — varios de alta capacidad logran el mismo éxito tardando bastante más.

The main weakness appears in planning, not in downstream tool execution: agent execution success is perfect for most models, whereas Coordinator planning success drops more often, especially for smaller and local models (clearest for Gemma 4 26B A4B and the two GPT-OSS 20B variants). Choosing the right multi-agent decomposition is the more intelligence-demanding part of the benchmark — once a good plan is produced, the sub-agents usually execute it correctly. Latency-wise, the Groq-hosted models (GPT-OSS 20B, GPT-OSS 120B, and Llama 3.3 70B) form the low-latency frontier, while Claude Opus 4.6, Claude Sonnet 4.6, Gemini 3.1 Pro, and Gemma 4 31B are at least 3× slower than the best Groq and lightweight OpenAI/Gemini runs. The clearest local comparison: dense Gemma 4 31B beats Gemma 4 26B A4B on planning while keeping perfect execution, but takes ~4.5× as long on the same tasks (65.5 s vs. 14.7 s). La debilidad principal está en la planificación, no en la ejecución de herramientas: la de agentes es perfecta en casi todos los modelos; la del Coordinator cae más, sobre todo en modelos pequeños y locales (Gemma 4 26B A4B y las dos variantes GPT-OSS 20B). Elegir la descomposición multi-agente correcta es lo más exigente del benchmark — con un buen plan, los sub-agentes suelen ejecutarlo bien. En latencia, los modelos de Groq (GPT-OSS 20B, GPT-OSS 120B, Llama 3.3 70B) son la frontera de baja latencia; Claude Opus 4.6, Claude Sonnet 4.6, Gemini 3.1 Pro y Gemma 4 31B son ≥3× más lentos que los mejores runs de Groq y los OpenAI/Gemini ligeros. La comparación local más clara: el denso Gemma 4 31B supera a Gemma 4 26B A4B en planificación con ejecución perfecta, pero tarda ~4.5× más (65.5 s vs. 14.7 s).

Model	Coord. success (%)	Agent success (%)	Mean time (s)
Llama 3.3 70B	100.0	100.0	8.2
GPT-5.4-nano	100.0	100.0	10.1
Gemini 3 Flash	100.0	100.0	15.5
Claude Haiku 4.5	100.0	100.0	15.7
Claude Sonnet 4.6	100.0	100.0	27.3
Claude Opus 4.6	100.0	100.0	31.5
Gemini 3.1 Pro	100.0	100.0	36.5
Gemma 4 31B	100.0	100.0	65.5
GPT-5.4	100.0	97.4	16.4
GPT-OSS 120B	93.3	100.0	7.5
Gemini 3.1 Flash-Lite	90.0	100.0	11.9
GPT-5.4-mini	90.0	100.0	12.6
GPT-OSS 20B	76.7	94.9	6.0
Gemma 4 26B A4B	70.0	100.0	14.7
GPT-OSS 20B	76.7	74.4	17.5

Models ordered by mean success, then latency. Local = 24 GB-VRAM deployments on PC-A with Q4_K_M quantization.Modelos por éxito medio y luego latencia. Local = 24 GB de VRAM en PC-A con cuantización Q4_K_M.

Simulation to real world, unchanged logicSimulación al mundo real, misma lógica

We validated sim-to-real transfer by executing the same scripted mission in simulation and on a physical 5× DJI Mini 4 Pro swarm at the SDU cricket field (55.367866° N, 10.435056° E). A seven-step operator script — multi-drone takeoff, dynamic grouping, formation traversal, building orbit, area coverage, sequential inspection, and return-to-home — ran through the same natural-language interface in both environments. Validamos la transferencia sim-to-real ejecutando la misma misión scriptada en simulación y en un enjambre físico de 5× DJI Mini 4 Pro en el campo de cricket de SDU (55.367866° N, 10.435056° E). Un script de siete pasos — despegue multi-drone, agrupación dinámica, formación, órbita de edificio, cobertura de área, inspección y return-to-home — se ejecutó con la misma interfaz en ambos entornos.

Simulated climbs and descents took slightly longer (e.g., takeoff to 30 m: 10.1 s sim vs. 9.6 s real), while path traversal and orbit maneuvers ran faster in reality (20.9 s vs. 16.1 s; 28.7 s vs. 25.3 s). Overall timing deviations stayed within 25%, primarily due to wind, GNSS noise, and simplified simulator dynamics — the same control interface worked unchanged in both worlds. Los ascensos y descensos simulados tardaron algo más (despegue a 30 m: 10.1 s sim vs. 9.6 s real), pero recorridos y órbitas fueron más rápidos en la realidad (20.9 vs. 16.1 s; 28.7 vs. 25.3 s). Las desviaciones quedaron dentro del 25%, por viento, ruido GNSS y la dinámica simplificada del simulador — la misma interfaz funcionó igual en ambos mundos.

A demonstration video of the real-world execution is available at youtu.be/eXD3l9EsT4M. Un vídeo de la ejecución real está disponible en youtu.be/eXD3l9EsT4M.

Ultimately, this is a step toward making autonomous systems accessible to non-experts without sacrificing the robustness and auditability required for field deployment. En definitiva, es un paso hacia sistemas autónomos accesibles para no expertos, sin sacrificar la robustez y auditabilidad necesarias para el despliegue en campo.

Swarm-Steward: Scalable and Reliable Natural-Language Coordination of Autonomous Aerial and Ground Robots
Jarabo-Peñas, Bravo-Arrabal, Rolland, Christensen · IEEE ICUAS 2026, pp. 796–804

IEEE Xplore · DOI · ResearchGate · Watch the system in action (video) IEEE Xplore · DOI · ResearchGate · Mira el sistema en acción (vídeo)

Supported by the Independent Research Fund Denmark (grant 10.46540/4264-00105B, NAMUR project), Innovation Fund Denmark through DIREC (PERSIST, U07), and the EU Horizon Europe WildDrone project (Marie Skłodowska-Curie grant 101071224).Financiado por el Independent Research Fund Denmark (grant 10.46540/4264-00105B, NAMUR), el Innovation Fund Denmark vía DIREC (PERSIST, U07) y el proyecto WildDrone de EU Horizon Europe (Marie Skłodowska-Curie grant 101071224).

Swarm-StewardICUAS 2026IEEE Xplore