Robots that Fly and Cooperate

In 2014, this page contained one link.

It pointed to Vijay Kumar’s famous TED talk, Robots that fly … and cooperate, first presented in 2012. The small quadrotors in that talk could fly through tight spaces, coordinate with one another, form teams and carry out tasks that looked almost choreographed.

The original video is still worth watching: Vijay Kumar — Robots that fly … and cooperate.

But the interesting part in 2026 is no longer that small robots can fly.

We have had drones for years.

The deeper question is:

How do many imperfect machines cooperate well enough that the group can do something no single machine could do alone?

That question turns a spectacular flying demonstration into a lesson about systems.

It is a lesson about sensing.

Control.

Communication.

Local rules.

Shared tasks.

Failure.

Redundancy.

And the surprising fact that intelligence can be distributed across a group rather than concentrated in one central controller.

The original 2012 idea was already bigger than drones

Kumar’s quadrotors were compelling because they were small, agile and autonomous. But the demonstrations also showed another idea: the machines could sense nearby vehicles and coordinate their movement.

They could form ad hoc teams.

They could cooperate on tasks.

The TED description highlighted possibilities such as construction and disaster surveying. Later work across aerial robotics developed the same direction further: teams of autonomous robots mapping unknown spaces, inspecting infrastructure and coordinating physical work.

ETH Zurich’s Autonomous Systems Lab, for example, describes work on cooperative aerial robotic workers for infrastructure inspection and maintenance, while earlier sFly research explored coordinated micro-helicopters for navigation and 3D mapping in urban-like environments. Current research has moved further into learning, resilience and safe cooperation at scale.

Useful current routes include ETH Zurich — Flying Robots, ETH Zurich — SwarmMind and Penn Engineering — Swarm AI safety at scale.

One robot is a machine. A swarm is a network.

A single drone has a relatively clear problem.

Where am I?
Where am I going?
What obstacles are nearby?
How much battery remains?
How should the motors change to maintain stable flight?

Add a second robot and the problem changes.

Now each robot must also account for another moving agent.

Add fifty robots and the problem is no longer simply fifty copies of the single-robot problem.

The robots form a network.

Information has to move.

Conflicts have to be resolved.

Tasks have to be divided.

Failures have to be contained.

And the group must avoid becoming so dependent on central coordination that one broken link collapses everything.

Cooperation is not fifty robots obeying one command. Cooperation is a rule system that lets useful global behaviour emerge from many local decisions.

The first hidden problem is localisation

A flying robot cannot cooperate intelligently if it does not know where it is.

Outdoors, satellite navigation can help. Indoors, underground, between tall structures or in damaged environments, GPS may be weak or unavailable.

The robot then has to build position from other evidence.

cameras;
inertial sensors;
laser or depth measurements;
known landmarks;
relative positions of other robots; and
maps built while moving.

This is why autonomous flight is a perception problem as much as a propulsion problem.

A motor can produce thrust perfectly and still fly the robot into the wrong place if the machine’s estimate of reality is wrong.

Then comes control: knowing where you are is not the same as staying there

A quadrotor is continuously unstable in the ordinary sense of the word.

It remains airborne because the control system repeatedly measures its state and adjusts motor speeds.

This creates a fast feedback loop:

sense → estimate → compare → correct → sense again.

That loop happens again and again while the vehicle flies.

Cooperation adds another loop on top of it.

The robot is not only correcting its own orientation.

It may also be adjusting position relative to neighbours, maintaining formation, avoiding collisions, sharing a payload or moving toward a common objective.

Local rules can create global order

This is one of the most beautiful ideas in swarm systems.

A robot does not always need a complete global map of every other robot.

It can sometimes follow simple local rules.

Do not get too close to a neighbour.
Do not drift too far away.
Match a useful direction or velocity.
Move toward the task region.
Share new information when it matters.

If the rules are designed well, the whole group can form patterns, distribute itself across an area or maintain coordinated movement.

Nature offers familiar examples.

Birds flock.

Fish school.

Ants allocate labour.

Bees collectively search and communicate.

No single animal necessarily contains a complete plan for the full group pattern.

Order can emerge from interactions.

Cooperation needs communication—but communication has a cost

If every robot constantly broadcasts every sensor reading to every other robot, the network can become overloaded.

Communication consumes bandwidth.

It consumes energy.

Messages can be delayed.

Connections can disappear.

Information can become stale while it is travelling.

So a strong multi-robot system asks:

What information does this robot actually need?
Which neighbours need to receive it?
How fresh must the information be?
What happens when communication drops?
Can the robot continue safely with partial knowledge?

This is an information-design problem.

The group becomes powerful when tasks can be divided

One robot can inspect one location.

Several robots can inspect several locations at the same time.

A team can also specialise.

One robot maps.
Another relays communication.
Another carries a tool.
Another monitors a hazardous zone.
Another returns to recharge.

Task allocation is where cooperation becomes economically interesting.

The group can distribute work according to position, battery state, sensor capability, payload and urgency.

The problem begins to look less like piloting and more like logistics.

A swarm can also be more resilient than one machine

If a mission depends on one aircraft, the failure of that aircraft can end the mission.

If a mission is distributed across many robots, some failures can be absorbed.

Another robot may take over a region.

A route may be recomputed.

Work may be redistributed.

The mission can degrade gracefully instead of stopping completely.

But redundancy is not automatic.

If every robot depends on one central server, one central map or one central communication channel, the swarm can still have a single point of failure.

Many robots do not guarantee resilience. The architecture determines whether the group can survive loss.

The dangerous side of cooperation is correlated failure

Cooperation creates benefits because machines share information and rules.

The same sharing can create shared mistakes.

If one bad position estimate is propagated through the group, several robots may react incorrectly.

If one learned model contains a failure and that model is distributed to neighbours, the mistake can travel.

If all robots use the same vulnerable localisation or communication method, one disturbance may affect many at once.

Current 2026 research explicitly studies this problem. ETH Zurich has projects examining how autonomous multi-agent systems respond when localisation or communication becomes unreliable. Penn researchers are also studying safety as teams of physical AI agents cooperate and compete at scale.

The engineering question has evolved from “can they cooperate?” to “can they cooperate safely when the world is imperfect?”

Swarm intelligence changes the meaning of learning from failure

A conventional robot can fail, be inspected, receive a software update and try again.

A cooperative learning system raises a more interesting possibility.

One robot fails.

It extracts information from the failure.

The lesson is shared.

Other robots avoid repeating the same mistake.

ETH Zurich’s 2026 SwarmMind project describes this kind of decentralised collective learning: drones learn locally from deployment experience and share model updates with nearby robots.

The swarm therefore begins to resemble a community with accumulated experience.

But that creates another safety question:

When should a machine trust a lesson learned by another machine?

Cooperative robots are useful because the physical world is uneven

A factory floor can be designed around robots.

The outside world cannot.

Buildings have awkward geometry.

Disaster sites contain debris.

Forests block line of sight.

Fires create heat and smoke.

Infrastructure is spread over kilometres.

Some spaces are too dangerous for people to enter immediately.

This is where mobile robot teams become valuable. Different machines can take different routes, share maps and keep humans farther from immediate hazards.

Search and rescue is a natural swarm problem

After a disaster, time matters and the environment may be partially unknown.

A robot team can theoretically distribute the search.

Map different sectors in parallel.
Relay imagery to responders.
Maintain communication between difficult locations.
Identify blocked routes.
Search areas before people enter.
Reassign work when a robot fails or a region is cleared.

This is exactly the type of application that made cooperative flying robots compelling in the first place.

Infrastructure inspection turns a dangerous human task into a routing problem

Bridges, towers, facades and industrial structures are expensive to inspect because people must reach difficult places safely.

Aerial robots can move the sensor toward the structure instead.

Cooperative robots add another layer: several machines can divide the structure, share a map, carry different sensors or help manage tools and tethers.

ETH Zurich’s AEROWORKS work explicitly explored teams of collaborative aerial robotic workers for inspection and maintenance.

In 2026, ETH’s CORD project offers another striking example of cooperation: two tethered drones are used conceptually for high-rise firefighting, with one drone helping manage the cable while another carries the hose and camera.

The lesson is simple:

Sometimes a second robot is valuable not because it duplicates the first robot, but because it removes a constraint the first robot cannot solve alone.

The engineering trade-off: autonomy versus supervision

A fully autonomous swarm sounds attractive because fewer human operators are required.

But the physical world contains edge cases.

Humans still matter for mission intent, safety boundaries, exception handling and accountability.

So many practical systems sit between two extremes.

Manual control: a human directly controls the vehicle.
Assisted control: the robot stabilises itself while a human chooses direction.
Supervised autonomy: the robot plans and acts within constraints while a human monitors.
Cooperative autonomy: several robots allocate work and coordinate locally while humans supervise the mission.

The most advanced technology is not always the most appropriate operating mode.

Safety depends on choosing the right level of autonomy for the task.

Dual use: the same cooperation can serve very different purposes

Aerial robotics is a classic dual-use technology.

The same ideas that help robots map a disaster zone can also be applied in military systems.

That does not make the underlying mathematics or engineering good or bad by itself.

It means engineering education has to include questions of use, authority and responsibility alongside capability.

Who defines the mission?
Who is allowed to operate the system?
What actions require human approval?
How are failures contained?
How is responsibility assigned when autonomous systems make decisions?
What uses should designers refuse?

A technically successful swarm can still be a socially unacceptable system if these questions are ignored.

What students can learn from flying robots

This single topic connects many school subjects.

Physics: forces, torque, acceleration, stability and energy.
Mathematics: vectors, coordinate systems, optimisation, geometry and probability.
Computer Science: algorithms, state estimation, networking and distributed computation.
AI: perception, planning, learning and decision-making under uncertainty.
Engineering: sensors, actuators, control loops, power, materials and reliability.
Biology: collective behaviour in social insects, birds and fish.
Social Studies: regulation, public safety, dual use and accountability.
English: explaining a system clearly enough that another person can follow cause and effect.

The robots are interesting because they make abstract ideas visible.

A simple classroom thought experiment

Imagine one hundred small flying robots must search a damaged building.

Design the rules.

How do they divide the building?
How do they avoid searching the same room repeatedly?
How do they avoid collisions?
How do they share discoveries?
What if communication disappears?
What if ten robots lose power?
What if one robot reports the wrong location?
What information must reach the human rescue team immediately?
Which decisions can remain local?

That thought experiment is already a lesson in distributed systems.

2012 → 2026: what changed?

Period	Visible question	Deeper systems question
2012	Can tiny quadrotors fly autonomously and cooperate?	Can local sensing and control create coordinated group behaviour?
2014	Can students see these robots as a glimpse of the future?	How does cooperation change what machines can do?
2015+	Can aerial robots map, inspect and support agriculture or infrastructure?	How should tasks be allocated across mobile autonomous agents?
2026	Can large teams learn and act together?	How do we make cooperation resilient, safe, accountable and robust to bad information?

The spectacle changed less than the engineering questions.

We were impressed by synchronised flight.

Now we have to ask what happens when the synchronisation is stressed.

Failure is where the system reveals itself

A perfect demonstration tells us what the system can do under favourable conditions.

A failure tells us how the system is built.

If one robot fails, does the mission stop?
If one message is delayed, does the formation become unstable?
If localisation becomes noisy, do robots separate safely?
If the environment changes, can routes be replanned?
If the learned model is wrong, can the system refuse or recover?

This is why modern robotics research spends so much effort on robustness and resilience.

The receiver changes what “good cooperation” means

Different people judge the same swarm differently.

A researcher values a new algorithm.
A firefighter values reliability in smoke, heat and uncertainty.
An infrastructure owner values reduced inspection cost and risk.
A regulator values safety and accountability.
A member of the public values privacy and appropriate use.
A student values the chance to see mathematics become physical behaviour.

There is no single performance metric that captures all of these receivers.

A system can be fast but unsafe.

Efficient but fragile.

Autonomous but difficult to supervise.

Accurate but too expensive.

Good engineering balances the operating envelope.

So what does it really mean for robots to cooperate?

It means more than flying in formation.

Cooperation means that information, responsibility and action are distributed across machines.

Each robot has only a partial view.

Each robot has limited energy.

Each robot can fail.

Yet the group can become more capable because the limits are shared.

The swarm works when no single robot needs to contain the whole world, but the system still preserves enough shared truth to act together.

That is why the 2012 video still matters.

It was never only about little helicopters playing together.

It was a visible demonstration of a much larger idea:

simple machines can become a sophisticated collective when sensing, rules, communication and feedback are designed well.

And in 2026, the frontier is no longer just making the collective impressive.

It is making the collective trustworthy.

Sources and further exploration

Historical note: this eduKate page was first published in July 2014 as a direct link to Vijay Kumar’s TED talk. It was rebuilt in 2026 to preserve the original idea while explaining how cooperative aerial robotics evolved into a broader problem of distributed intelligence, resilience and safe multi-agent systems.

From Cooperative Quadrotors to Modern Multi-Robot Systems

The original flying-robots idea is powerful because one small machine can do only so much, while a group can divide work, share information and create patterns that no single robot could manage alone. Cooperative aerial robots therefore provide a useful bridge between robotics, control theory, artificial intelligence, communication networks and collective behaviour.

The important question is not simply how to make several drones fly. It is how to make each machine know enough about itself, its neighbours and the shared task to act safely without requiring one human to control every movement.

A Flying Robot Must Solve Several Problems at Once

estimate its position and orientation;
control motors quickly enough to remain stable;
sense obstacles or other robots;
communicate where necessary;
follow a local or global plan;
manage limited battery energy;
recover from uncertainty or sensor error.

Cooperation sits on top of these individual capabilities. A swarm cannot be reliable if each robot is already unstable.

Why Quadrotors Are Hard to Control

A quadrotor has four rotors whose thrust must be coordinated continuously. Small changes affect roll, pitch, yaw and vertical motion. The aircraft is dynamically unstable enough that control software must react rapidly. This is why autonomous flight depends on a feedback loop: sense the current state, compare it with the desired state, adjust motor commands and repeat.

The loop runs far faster than a human could manually correct every disturbance.

Feedback Is the Core Idea

Feedback control appears far beyond drones. A thermostat measures temperature and adjusts heating. Cruise control measures speed and adjusts throttle. A student can even think of revision as feedback: attempt, observe error, adjust method, attempt again.

The general pattern is target, measurement, difference, correction.

Local Rules Can Create Group Behaviour

Multi-robot systems often become interesting when individual robots follow relatively simple local rules. Maintain separation. Align with neighbours. Move toward a shared region. Avoid obstacles. The combination can produce coordinated group movement without one robot explicitly controlling every other robot.

This is similar to flocking models in biology and computer science: complex group patterns can emerge from repeated local interactions.

Centralised and Decentralised Control

In a centralised system, one controller may receive information from many robots and assign actions. This can make coordination easier to optimise, but creates communication demands and a potential single point of failure. In a decentralised system, robots make more decisions locally using limited information. This can improve resilience and scalability but makes global coordination harder.

Real systems may combine both approaches.

Communication Is Useful but Expensive

Robots can share position, velocity, task status or sensor data, but communication consumes bandwidth and energy and can fail. Good cooperative design therefore asks how much information each robot truly needs.

If every machine must know the exact state of every other machine at all times, the system may become difficult to scale. Local neighbourhood information can sometimes achieve enough coordination with less communication.

Collision Avoidance Is a Distributed Safety Problem

Cooperative flying robots must avoid one another as well as walls, trees, people and unexpected obstacles. A path that is safe for one drone may become unsafe when another drone changes route.

Safety therefore depends on prediction. Each robot estimates where other objects are likely to be, not only where they are now.

Formation Flight

Robots can be asked to maintain a geometric formation such as a line, grid or moving shape. The control challenge is to keep relative positions while the whole group moves. Wind, sensor noise and individual performance differences constantly disturb the formation.

Formation control is useful for sensing, mapping, communication coverage and coordinated displays, but the geometry should serve the task rather than exist only for visual effect.

Task Allocation

A group becomes more useful when work can be divided. One robot may inspect a region, another relay communication, another transport an object and another replace a robot whose battery is low. Task allocation becomes a scheduling problem under uncertainty.

The system needs criteria: distance, battery state, payload, sensor capability, urgency and risk.

Mapping With Multiple Robots

Several robots can explore different parts of an environment and combine maps. This can reduce time, but creates a hard question: how do the machines know their separate maps refer to the same coordinate system? Errors in localisation can make shared maps inconsistent.

Cooperative mapping therefore connects perception, geometry, communication and uncertainty estimation.

Search and Rescue

One potential use for cooperative aerial robots is search and rescue. Several small drones could divide a damaged area, scan for heat, movement or visual signs, and relay information to human teams. The advantage is reach and parallel search.

The limitations are equally important: battery life, weather, debris, communication loss, false detections, privacy, airspace coordination and the danger of distracting human responders.

Infrastructure Inspection

Bridges, roofs, power lines, wind turbines and industrial facilities may be difficult or dangerous for people to inspect closely. Cooperative drones can divide inspection tasks and collect imagery or sensor data.

The engineering challenge is not only flight. It includes data quality: can the system prove that every required surface was inspected and that images are sharp enough for a meaningful decision?

Agriculture and Environmental Monitoring

Multiple aerial robots can survey crops, forests, coastlines or wildlife areas more quickly than one machine. Different robots can carry different sensors. The group can revisit regions where unusual data appear.

This creates a useful systems idea: cooperation allows heterogeneous capability. Not every robot has to be identical.

Warehouse and Indoor Logistics

Flying robots are not always the best logistics solution, but indoor multi-robot coordination provides a useful engineering case. Machines operating near shelves, workers and other robots require precise localisation, collision avoidance and traffic rules.

At scale, the problem begins to resemble urban traffic management in three dimensions.

Energy Is a Hard Constraint

Small aerial robots have limited battery life because flight consumes substantial energy. Cooperation does not remove this constraint. It creates another coordination problem: when should a robot leave to recharge, and who covers its task?

Battery-aware planning is therefore part of mission planning.

What Happens When One Robot Fails?

A robust group should degrade gracefully. If one robot loses communication or battery power, the others should avoid collision and, where possible, redistribute the task. This is one reason decentralised designs can be attractive: the whole system does not necessarily collapse with one missing member.

Failure recovery should be designed before failure occurs.

AI and Learning-Based Control

Modern robotics increasingly uses machine learning for perception, planning and decision support. Learning systems can help robots recognise objects, estimate conditions or choose actions in complex environments.

But learning introduces verification challenges. A system that performs well in training may fail in unusual lighting, weather or geometry. Safety-critical robotics therefore needs testing beyond average performance.

Simulation Before Real Flight

Multi-robot experiments can be expensive and dangerous. Simulation allows engineers to test algorithms, communication delays, failures and large numbers of agents before risking hardware. Simulation is especially useful for rare dangerous conditions.

The limitation is the simulation-to-reality gap. A virtual world is only as useful as the assumptions built into it.

Safety, Privacy and Regulation

A fleet of autonomous flying cameras raises questions beyond engineering. Where may the robots fly? What data do they collect? Who is accountable if one fails? Can a person opt out of observation? What happens when software is updated?

Responsible robotics therefore includes law, ethics, human factors and public trust.

A Student Swarm Exercise Without Drones

Students can model cooperative robotics on paper or in code. Give each agent three rules: avoid neighbours that are too close, move toward a target and remain within communication range of at least one neighbour. Then vary one rule and observe the group pattern.

The exercise teaches emergence: group behaviour can arise from local rules.

A Failure-Mode Exercise

What if GPS is unavailable?
What if one robot reports a wrong position?
What if communication is delayed?
What if two robots choose the same narrow path?
What if battery estimates are wrong?
What if a person unexpectedly enters the flight area?

For each failure, students should propose detection, safe response and recovery.

What Cooperative Robots Teach About Systems

The deeper lesson is not about drones. It is about coordination. Each agent has limited information and limited capability. Rules determine how local actions affect the group. Communication has cost. Failure propagates. Redundancy can improve resilience. Global behaviour emerges from many small decisions.

These ideas appear in transport, computer networks, biology, economics and organisations as well as robotics.

Final Guide

Flying robots that cooperate are compelling because they make invisible systems visible. We can watch feedback, local rules, communication, uncertainty and task allocation become movement in physical space.

The future value of these systems will depend less on spectacular demonstrations than on reliability: can they perform a useful task safely, explainably and repeatedly when the environment is not perfectly controlled?

The Human Supervisor Still Matters

Autonomy changes the role of the human operator. Instead of steering every motor command, the human may define the mission, approve boundaries, monitor the fleet and intervene when conditions move outside the system’s competence. This creates a human-factors problem: the interface must show enough information for the supervisor to understand what the robots are doing without overwhelming attention.

Too little information hides danger. Too much information creates noise. Good supervisory design therefore includes alerts, confidence levels, mission status and clear ways to stop or redirect the system.

Trust Must Be Calibrated

If people trust autonomous robots too little, they may interfere constantly and lose the benefit of automation. If they trust them too much, they may stop monitoring important failures. The system should help operators understand both capability and limitation.

Calibrated trust requires predictable behaviour, testing, transparent status and clear failure handling. A spectacular demonstration is not enough.

Security Is Part of Cooperative Robotics

Connected robots create cybersecurity questions. Communication can be jammed, spoofed or manipulated. Software updates can introduce vulnerabilities. A false position report from one agent can affect group behaviour. Engineers therefore need authentication, secure communication, anomaly detection and safe fallback modes.

Physical safety and information security become one problem when software controls machines in the real world.

The Scale Test

An algorithm that coordinates five robots may not coordinate five hundred. Communication traffic grows, collision possibilities increase and central controllers can become bottlenecks. Scalability therefore needs to be tested explicitly.

This is one reason local rules are attractive: they can sometimes allow a larger group to behave coherently without requiring every agent to know everything about the whole system.

A Final Student Question

When watching a swarm demonstration, do not ask only, “How did they make the drones do that?” Ask which information each robot needed, what happened if communication failed, how collisions were prevented, how battery limits were handled and what a human would do if the system behaved unexpectedly. Those questions reveal the engineering hidden behind the choreography.

Cooperation Should Improve Mission Reliability

A group of robots is useful only if cooperation improves the mission rather than simply increasing complexity. Engineers should compare the fleet with simpler alternatives. Does using several robots reduce completion time, extend coverage, improve resilience or enable a task one robot cannot perform? If not, the extra communication, maintenance and collision risk may not be justified.

This is a general systems principle: more components are not automatically better. Additional agents create capability and coordination cost at the same time.

Measure the Whole Mission

Success should therefore be measured at mission level. Completion rate, safety incidents, energy used, communication failures, coverage quality, human supervision time and recovery from individual robot failure can all matter. A visually perfect formation is irrelevant if the inspection misses half the target area.

The strongest cooperative robot systems make the group more useful, not merely more impressive.

The Final Engineering Question

Cooperative flight becomes meaningful only when the group is more useful than several independent machines operating side by side. The engineering team should be able to explain what information is shared, what coordination improves, what new failure modes appear and why the added complexity is justified.

This is the general systems lesson. Cooperation creates capability, but it also creates dependencies. Every connection can carry useful information or propagate failure. Good design makes those connections explicit, tests them under degraded conditions and preserves a safe path when the network does not behave as expected.