Counter-UAS and Dual-Use Drones, Explained Plainly

If you only read drone headlines, you would think the field splits cleanly into two worlds: friendly robots that photograph rooftops, and military machines that do something you would rather not think about. The reality is messier and more interesting. The same autonomy that lets a drone inspect a refinery on its own is the autonomy that matters for security, and the line between "civilian" and "defence" is drawn less by the hardware than by the mission and the rules around it.

This is a primer for people with no defence background. I want to explain three things plainly: what dual-use means, what counter-UAS systems actually try to do, and where the engineering overlaps with the autonomous-inspection work I have done for a decade at Dronehub. I will ground it in a real project, the AUDROS study I took part in, described accurately, as a consortium feasibility project and nothing grander.

What "dual-use" actually means, without the cloak-and-dagger

Dual-use sounds ominous and is mostly mundane. It means a single technology has both civilian and defence or security applications, without being fundamentally redesigned for each. A delivery van is dual-use. Encryption is dual-use. GPS is dual-use. And a good chunk of autonomous-drone technology is dual-use too.

Here is the concrete version. A drone-in-a-box system, which I have written about in What "Drone-in-a-Box" Actually Means, runs a specific loop: it launches from a weatherproof docking station with no pilot present, flies a planned route, captures imagery or sensor data, and returns to swap or charge its battery. The whole point is that a human does not stand at the controls. Now ask: what changes if that same loop runs along a border fence instead of a power line? Almost nothing in the hardware. The autonomy, the docking, the battery handling, the computer vision that flags an anomaly, all of it is identical. What changes is the mission and the legal and ethical framework around it.

That is why the term exists at all. It is a way of saying: this capability does not care what you point it at, so somebody has to. In the EU, dual-use technologies sit under export-control regimes for exactly this reason, and as a builder you can drift into that territory without intending to. Recognising the overlap is not paranoia; it is literacy about what you are actually making.

What counter-UAS systems are really trying to do

Counter-UAS, often written C-UAS, is the discipline of dealing with small drones you do not want in a given piece of airspace. If dual-use is about the drone, counter-UAS is about everything that wants to detect or stop one. It is fundamentally defensive, and it splits into two problems.

The first is detection: finding a drone, tracking where it is, and ideally identifying what it is and whether it is a threat. This is harder than it sounds. Small drones are slow, low-flying, often made of plastic, and easy to confuse with birds. Systems lean on a mix of radio-frequency sensing (listening for the control link), radar, acoustics (the rotor signature) and optical or infrared cameras. No single sensor is reliable on its own, so detection is usually a fusion problem.

The second is mitigation: actually stopping the drone once you have found it. This is where the trade-offs get sharp. You can jam the radio link, which is cheap but illegal in many places and can knock out other devices. You can spoof its navigation, feeding it false position data so it lands or drifts. Or you can physically capture it, often a net fired from the ground or carried by another drone.

That last category, net-capture, is where my own work brushed against this field. A net is clumsy compared to electronic warfare, but it has one honest virtue: it brings the drone down intact and without flooding the spectrum, which matters near airports, crowds or critical infrastructure where you cannot just start jamming everything.

AUDROS: a real CBRNe feasibility study, described accurately

Here is the part where I have to be disciplined, because this is precisely the kind of project that gets inflated in retelling.

AUDROS was a feasibility study funded through the Integrated Applications Promotion programme of the European Space Agency, with the involvement of the European Defence Agency. Its Phase 1, around 2018, had a budget of roughly EUR 350,000, and it explored two concepts: counter-UAS net-capture, and CBRNe sensing. CBRNe stands for chemical, biological, radiological, nuclear and explosive threats, the category of hazard you want to detect with a robot rather than a person walking into it.

It was a Czech-led, multi-partner consortium. The prime was BizGarden. The partners included GINA Software, a Brno military research institute, our company (then Cervi Robotics, now Dronehub) and Fly4Future. Within that group, Dronehub's contribution was the docking hangar — the housing and ground infrastructure that lets a drone operate autonomously from a fixed point. We did not build the interceptor; the "Eagle One" interceptor work belonged to Fly4Future. And we did not lead the project. We were one partner contributing one piece.

I am spelling this out because consortium projects collapse in memory into solo achievements, and I have seen versions of this story that credit Dronehub with the whole thing. That is not true, and it does not need to be true to be worth talking about. The accurate version is more useful: a small European company, brought into a defence-and-space R&D consortium to supply the autonomous docking layer, working alongside a military research institute and a software house on whether net-capture and CBRNe-sensing were feasible.

And note the word feasibility. A Phase 1 study asks whether a concept is technically and operationally plausible and what building it would take. It produces analysis, architecture and risk assessment. It does not produce a deployed system. There is a wide gap between "we studied whether this could work" and "this is fielded," and honest people keep that gap visible.

Why the docking layer is the dual-use bridge

You might wonder why a counter-UAS and CBRNe study would want a docking-hangar specialist in the room at all. The answer is the cleanest illustration of dual-use I know.

Counter-UAS and CBRNe sensing share a hard requirement: the system has to be ready without a human standing next to it. A CBRNe sensor is worth most when it can sit at a site, unattended, and dispatch a drone the moment something registers, because the entire point is to keep people away from the hazard. A counter-drone net-capture concept has the same logic; the threat arrives on its own schedule, not yours. So the autonomous docking station, the thing that keeps a drone charged, sheltered and launch-ready around the clock, is not a side detail. It is the enabling layer.

That is the same enabling layer I build for inspection, where the argument is identical in shape: a robot should do the dull, dangerous, repetitive part, and a human should not climb the tower or walk into the gas cloud. I made that case in Why Robots Should Inspect Towers and Refineries, Not People. The defence-adjacent version simply swaps "tower" for "threat." The autonomy and the docking do not know the difference, which is exactly what makes the technology dual-use and exactly why somebody responsible has to decide where to point it.

There is also a battery dimension that non-experts underrate. Persistent, always-ready autonomy lives or dies on how the drone handles energy, a trade-off I broke down in Battery Swap vs. Charging. A security or CBRNe application that needs instant response leans toward swap; a monitoring loop that can tolerate downtime tolerates charging. These are the same engineering decisions on both sides of the civilian-defence line.

What I would tell a journalist or a policymaker to keep straight

If you are writing or legislating about this space, a few distinctions will save you from the most common errors.

First, detection is not mitigation. A system that spots a drone is doing something legally and technically very different from a system that takes one down. Many "counter-drone" products are detection-only, and conflating the two overstates capability.

Second, dual-use is a property of the technology, not a confession of intent. When a commercial-drone company appears in a defence-and-space consortium, the honest read is usually that its civilian capability turned out to be relevant, not that it has pivoted to weapons. The interesting policy questions, export controls, oversight, accountability, sit on top of that fact; they are not the same as it.

Third, feasibility studies are early. They are how Europe explores whether something is worth building, often through bodies like ESA, the EDA, and Horizon Europe. Treating a Phase 1 study as a fielded system inflates the story past what the evidence supports, and the people who actually did the work can tell.

Fourth, consortium roles are specific. Ask who the prime was and which partner supplied which piece. In AUDROS, the answer is BizGarden as prime, Fly4Future on the interceptor, and Dronehub on the docking hangar. Those are not interchangeable.

Where I would start if you are coming from the commercial side

If you build commercial drones and the defence and dual-use adjacency feels foreign, here is the practical entry point. Start by understanding counter-UAS from the receiving end, because it tells you how your own aircraft will be detected, restricted or treated near sensitive sites. Then look honestly at your own autonomy stack and ask which parts are dual-use; usually it is more than you assumed, and knowing that early keeps you on the right side of export rules.

The deeper lesson from a decade in this field, which I unpacked in A Decade in Autonomous Drones: What I Got Wrong Since 2015, is that the civilian and security worlds are not separated by a wall. They are separated by a decision, made by humans, about where to point a capability that does not care. The engineering is shared. The responsibility is not, and pretending otherwise is how people get the story, and the policy, wrong.

If you want the rest of the European R&D context, including the harder constraints of building hardware and AI here, I wrote about that in Building Hardware + AI in Europe. And if you are working on something in this space and want to compare notes, the door is on the contact page. I would rather have an accurate conversation than an impressive one.