Swarming & collective robotics
Coordinated multi-agent autonomy
Overview
Swarming and collective-robotics capability that coordinates many unmanned systems as one: collaborative mission execution, obstacle avoidance and distributed tasking across air and ground platforms. The force-multiplication layer of the unmanned architecture.
Many unmanned systems commanded as one: the force-multiplication layer that turns individual platforms into a coordinated capability.
Capabilities
- Collaborative mission execution across multiple unmanned systems
- Distributed tasking, obstacle avoidance and formation behaviour
- Coordinates across the air and ground unmanned fleet
- Operator-in-the-loop command aligned to rules of engagement
- Multiplies the effect of a single operator: many platforms tasked as one capability, without a controller per airframe
- Delivers resilience through numbers: the mission continues when individual platforms are lost, because no single unit carries it alone
Specifications
| Type | Swarming / collective robotics |
| Scope | Air & ground unmanned systems |
| Control | Operator-in-the-loop |
| Origin | Independent / non-aligned |
In depth
Coordination above the platform
The product is a swarming and collective-robotics capability, not a replacement for the unmanned platforms that make up the fleet. Its recorded role is to coordinate many systems as one. The detail record names collaborative mission execution, distributed tasking, obstacle avoidance and formation behaviour. Those functions sit above individual aircraft or vehicles. They allow a mission to be assigned across multiple platforms while the systems coordinate the work between themselves. The catalogue does not specify a swarm size, autonomy level beyond the operator-in-the-loop control, or a particular mission outcome. The verified proposition is coordinated multi-agent operation across air and ground.
Distributed tasking
Distributed tasking is the mechanism that lets the command layer assign work across the unmanned fleet. The catalogue states that the capability multiplies the effect of a single operator and does not require a controller per airframe. That is a specific control relationship, not a claim that one person can manage any number of systems in every condition. The operator remains in the loop and command remains aligned to the rules of engagement. The robotics layer handles coordination between the platforms, while the human supplies mission intent and retains the authority described in the product record.
Air and ground together
The scope covers air and ground unmanned systems. That makes the product broader than an air-only formation controller and gives the architecture a common coordination problem across different platform types. The detail record says the fleet can be coordinated across air and ground, while the catalogue lists obstacle avoidance and formation behaviour. Those facts support a system that shares tasking and manages movement relationships across the fleet. They do not identify a particular vehicle, aircraft, sensor, communications link or terrain. The appropriate configuration therefore begins with the platforms and mission that the buyer intends to coordinate.
Behaviour that is part of the system
Obstacle avoidance and formation behaviour are named capabilities, alongside collaborative mission execution. They describe how the platforms act while carrying out a shared task. Obstacle avoidance addresses movement around hazards; formation behaviour concerns the relationship between platforms in the group. Neither is presented as a guarantee of autonomous operation without supervision. The product detail explicitly retains operator-in-the-loop command. The result is a collective system in which the recorded behaviours support coordination, but the buyer's operator remains connected to the mission and rules that govern employment.
Resilience through distribution
The detail record describes resilience through numbers: a mission continues when individual platforms are lost because no single unit carries it alone. That is the stated consequence of distributing the task across the group. It is narrower than a promise that a swarm is invulnerable or that every mission continues regardless of losses. The architecture's resilience comes from not concentrating the entire mission in one platform. Collaborative execution and distributed tasking are therefore operational features, while the exact number of platforms, the effect of a loss and the communications conditions remain unspecified in the product record.
Integration and local capability
The swarming layer is delivered through one accountable channel, with integration and training in-region according to the exposition. The catalogue records an independent and non-aligned origin and identifies related anti-jam mesh data links and autonomous command and control as adjacent capabilities, not as specifications of this product. The safe description is that the swarm coordinates the buyer's unmanned fleet through its command layer, with training and integration handled as part of the engagement. The record does not claim a particular datalink, customer, deployment or production arrangement. Those questions belong to configuration rather than to the verified product description.
Why Unstrat: the difference
Unstrat is the authorised global representative and distributor for this capability. It is already in service with a track record behind it, so you are buying something that has done the job elsewhere, not funding a first attempt. You are not the test bed.
Independent, non-aligned origin, with no political exposure to any major-power ecosystem.
One accountable team from first briefing through delivery and in-region sustainment.
Distributed tasking across air and ground platforms from one command layer.
How it reaches you
Related capability
View all →
Procurement & sustainment
Classification and the end-user-certificate chain are confirmed before this capability is represented to your market.
Sourced from an independent manufacturer: no major-power disclosure rules or political conditions.
A single team responsible from first briefing through delivery: not a chain of foreign primes to integrate yourself.
Lifecycle support and operator training delivered in-region, building capability that outlasts the initial deployment.
Applications it supports
Questions buyers ask
What is drone swarming?
Swarming is the coordination of many unmanned systems as one capability: collaborative mission execution, distributed tasking, obstacle avoidance and formation behaviour under a single command layer. The Unmanned Systems Developer's swarming layer runs across air and ground platforms that are already in service, with the operator in the loop and aligned to your rules of engagement. It is the force-multiplication layer of an unmanned architecture rather than a separate fleet.
See: Swarming across air and ground platformsCommand layer that runs the swarm
How many operators does a drone swarm need?
Fewer than one per airframe, which is the entire point. Our swarming layer tasks many platforms as one capability without a controller per aircraft, and STM takes the same approach by alerting operators to detected threats rather than asking them to watch every video feed. Neither vendor publishes a hard operator-to-platform ratio, so make the trial measure it: number of platforms, number of operators, mission completed or not.
Is a drone swarm autonomous, or does a person decide?
Coordination is autonomous; the engagement decision is not. The Unmanned Systems Developer's swarming layer is operator-in-the-loop and aligned to rules of engagement, and STM states that strike inside its swarm is performed by the operator on the man-in-the-loop principle. If your legal framework requires positive human authorisation, insist on seeing the authorisation path demonstrated live rather than described.
What can a swarm do that individual drones cannot?
Two things, mainly. It holds a mission together when platforms are lost, because no single unit carries the task alone, and it multiplies a scarce operator across many airframes. STM adds a useful specific: targets detected by one platform are shared across the group and tasks are allocated by target type. Ours coordinates across air and ground systems from one command point, which matters when the sensor that finds the target and the platform that reaches it are different machines.
See: Scope of the swarm, air and groundWhat STM publishes and what we do not
Swarming system that coordinates air and ground unmanned platforms together
That cross-domain scope is where our layer differs. STM's swarm is an air swarm built around its own KARGU and TOGAN family; the developer's is specified across air and ground unmanned systems from a single command point. Cross-domain coordination is harder to demonstrate and easier to over-claim, so ask both suppliers to fly and drive it in front of you rather than comparing brochures.
See: Air-plus-ground scope, side by sideGround platforms in the same architecture
Is a decentralised swarm architecture worth paying for?
Yes, when the swarm is expected to take losses. A centralised swarm becomes inoperable if the central node is destroyed, and STM says so plainly and states its own system is decentralised for that reason. We publish distributed tasking, obstacle avoidance and formation behaviour without naming our architecture, and that gap is ours to close. Ask every vendor to state the architecture and then to remove an element mid-mission in front of you.
Can platforms join or leave a swarm during a mission?
STM publishes real-time addition and removal of platforms and the division of a swarm into sub-swarms by mission or payload. We do not publish in-flight membership change, and a tender should ask us for it. What our layer does state is that the mission continues when individual platforms are lost, because no single unit carries it alone.
Swarming software for an existing mixed fleet of unmanned systems
Our swarming layer coordinates across the developer's air and ground fleet, and STM's is built around STM's own mini UAV family. Neither is a universal adapter, so if your fleet is mixed, the honest requirement is a demonstration of control over a platform the bidder did not build. Put that in the trial script before the tender closes rather than discovering the limit afterwards.
See: Platform tie for each supplierControl layer for multi-platform tasking
What training does a swarm capability require?
More than the software purchase suggests. Swarming changes the operator ratio, which is a manpower and doctrine decision before it is a technical one. Our training pipeline and the command layer are sold and sustained by the same team, so the doctrine change is supported in-region rather than left to the buyer. Buying a swarm module from a vendor whose training sits in another country leaves the hardest part of the transition unowned.
See: Operator pipeline that supports the doctrine changeSimulator rehearsal before live swarm flying
We can afford the platforms but not one operator per platform. Does swarming genuinely solve that?
It is the only thing that does, and it is worth testing rather than assuming. The mechanism is that the operator supervises a task rather than an aircraft, with detection and coordination handled on the platforms. Run the trial with your own soldiers at your own manning level, count how many platforms one supervisor can hold, and treat any vendor unwilling to be measured that way as answered.
How do we test whether a swarm keeps working after we start losing aircraft?
Remove an element mid-mission, without warning, and see whether the remaining platforms complete the task. STM states that decentralised swarms tolerate the loss of individual elements up to a limit, which is the correct engineering claim and the correct thing to verify. Our layer is specified so the mission continues when individual platforms are lost. Neither statement is worth anything until you have watched it happen.
Our ISR platform finds the target and a ground vehicle has to reach it. Can one swarm layer run both?
That is the case our layer is specified for: air and ground unmanned systems coordinated from one command point, with distributed tasking across them. STM's published swarm is air only. Because cross-domain claims are the easiest to overstate, the trial should include a handover from an airborne sensor to a ground platform under a single operator, with the datalink degraded partway through.
See: Swarming scope and platform coverageCross-domain coordination, examined
Which swarm supplier carries the least political risk over a ten-year programme?
Swarm software is upgraded continuously, which makes the supplier relationship long-lived and the political exposure long-lived with it. STM's system is strong and combat-connected, and it arrives with its home state's export approvals attached to every future release. The Unmanned Systems Developer's origin is non-aligned, and the command layer, the platforms and the training come from one accountable team with in-region sustainment, so the upgrade path is not a diplomatic question.
What should a ministry write into a swarm requirement so it cannot be met with a slideshow?
State the architecture the bidder must declare, the number of platforms and operators in the demonstration, the loss event they must survive, and the domains involved. Add a requirement to show target detection shared between platforms and task allocation by target type, which STM publishes and which is a reasonable bar for anyone selling a swarm. Then hold us to the same wording.
See: Every published swarm claim in one tableSwarming inside the unmanned architecture
Is swarming useful for defence as well as attack, for example against a mass drone raid?
It is, and the two problems are related: the counter-drone side needs many effectors cued from one picture, which is the same coordination problem seen from the other end. The Unmanned Systems Developer's counter-drone architecture sits above the individual effectors with sensors fused and multiple defeat options cued from one command layer. If mass attack is the threat you are actually funding against, look at both lines together rather than in sequence.
See: Layered defence priced for the mass threatCounter-UAS approaches compared
Swarming & collective robotics: questions
What are Swarming & collective robotics?
Swarming & collective robotics are Unstrat's Sky (Air Domain) capability: Swarming and collective-robotics capability that coordinates many unmanned systems as one: collaborative mission execution, obstacle avoidance and distributed tasking across air and ground platforms. The force-multiplication layer of the unmanned architecture.
How do Swarming & collective robotics work?
Swarming & collective robotics deliver their effect through collaborative mission execution across multiple unmanned systems, Distributed tasking, obstacle avoidance and formation behaviour and Coordinates across the air and ground unmanned fleet, capabilities matched to the requirement and confirmed under briefing rather than published.
Who makes Swarming & collective robotics?
Swarming & collective robotics are built by The Unmanned Systems Developer, whose focus is counter-uas, loitering munitions & unmanned aircraft. Unstrat represents The Unmanned Systems Developer to government and enterprise buyers worldwide as an independent, non-aligned prime vendor.
Why choose Swarming & collective robotics over a major-power alternative?
Swarming & collective robotics are sourced from an independent, non-aligned manufacturer, so they carry no major-power disclosure rules, upgrade-locks or political ramifications. Concretely: distributed tasking across air and ground platforms from one command layer. The capability is accountable to you, not to a foreign vendor's government and its release schedule.
How are Swarming & collective robotics procured, and where can it be exported?
Many unmanned systems commanded as one: the force-multiplication layer that turns individual platforms into a coordinated capability. Every engagement begins with a briefing, and export eligibility is confirmed per market under briefing rather than published. Where controlled capabilities are involved, the classification and end-user-certificate chain is confirmed first. Swarming & collective robotics are then sustained in-region by one accountable team from briefing through long-term operation.