Must every robot know the whole task state?

Often not; local information is a central design theme.

Are swarm robots always identical?

Many systems use similar robots, but heterogeneous groups are also possible.

Does swarm robotics require machine learning?

No. Collective behavior can arise from designed rules, learned policies, or combinations of methods.

AI Glossary / Reinforcement learning and robotics / Intermediate

SWARM ROBOTICS

Definition

SWARM ROBOTICS studies how groups of robots can produce useful collective behavior through interactions among their members and with the environment. It often draws inspiration from social insects, flocks, and other biological groups. The emphasis is on designing local behavior that supports a group-level task, rather than merely operating several robots at the same time.

What it means

A swarm may contain many relatively simple robots whose individual capabilities are limited. Through local sensing, communication, and coordinated behavior, the group can perform tasks such as aggregation, coverage, collective transport, or pattern formation.
Decentralization and self-organization are common themes, but the exact architecture varies. A swarm can receive a shared task specification or use reference robots without assigning every movement through a central controller. It is useful to describe which information and decisions are local, shared, or centralized instead of relying on the label alone.

How it works

Design begins with a collective objective and the capabilities available to each robot. Local rules may determine how robots move relative to neighbors, share observations, select tasks, or respond to congestion. The challenge is understanding how these interactions produce the desired global behavior.
Scaling introduces physical and communication effects. More robots can increase parallel effort, but they can also obstruct one another, repeat work, or overload shared communication resources. A rule that works for a small group may behave differently at higher density.
Robustness must also be tested. Losing one robot may have little effect when others can take over, but correlated failures, critical reference roles, or blocked communication can disrupt the group. Decentralization does not automatically remove every single point of failure.
Harvard's Kilobot work provides a documented research example: 1,024 small robots used local interactions to assemble specified shapes. This demonstrates a particular collective behavior under experimental conditions, not unrestricted competence across environments or tasks.

Three practical examples

Coverage research: distribute robots across an area to gather observations while limiting duplicated work.
Collective transport: investigate how several robots can move an object through coordinated local actions.
Self-assembly experiments: create specified group patterns from robots following shared local rules.

Think of it this way

Think of a team whose members can see nearby colleagues but lack a complete overhead view. Good local habits can help the whole team spread out, coordinate, and recover from small disruptions. Poor local habits can create queues or duplicated work even when every member is functioning correctly.

Worked example

Consider a fictional coverage experiment with 100 distinct cells. Twenty robots each inspect five different cells chosen uniformly at random. Choices made by different robots are independent, and there are no travel, collision, or communication costs in this simplified baseline.
For any particular cell, one robot has probability 5/100 = 0.05 of inspecting it and probability 0.95 of missing it. The probability that all twenty robots miss that cell is 0.95 raised to 20, approximately 0.3585. Therefore its probability of being inspected at least once is approximately 0.6415.
Summing this probability across the 100 cells gives expected unique coverage of approximately 64.15 cells. The robots performed 20 times 5 = 100 inspections, but repeated coverage means they did not necessarily inspect all 100 distinct cells. Expected inspections beyond the first visit to each covered cell total approximately 100 - 64.15 = 35.85.
Now double the group to forty robots under the same assumptions. Expected unique coverage becomes 100 times (1 - 0.95 raised to 40), approximately 87.15 cells. Twice as many robots do twice as many inspections, but unique coverage rises by only about 23 cells because overlap increases.
For comparison, a perfectly coordinated allocation of five disjoint cells to each of twenty robots would cover all 100 cells. That is an ideal reference requiring suitable allocation and execution; it is not a claim that a local swarm rule automatically achieves perfect partitioning.
If four of the twenty robots fail before inspecting anything, the remaining sixteen give expected coverage of 100 times (1 - 0.95 raised to 16), approximately 55.99 cells. Coverage degrades rather than dropping to zero in this model. Real failures may be more damaging if a stopped robot blocks a passage or removes a communication bridge.
The calculation is an independent-random baseline for testing coordination. It does not model the correlated trajectories of a real swarm, and it should not be presented as a measured swarm-robotics result.

Illustrative case study

Fictional case: BirchSurvey tests local rules that encourage small robots to avoid recently visited regions reported by nearby peers. A larger group initially covers more ground, then begins to congest narrow passages. The team measures unique area covered and elapsed time instead of counting robot movements alone.
It compares the local coordination rule with an independent-random baseline and an idealized partitioning reference. The case is invented and illustrates why group-level evaluation must include interference and duplicated effort.

Common misconceptions and mistakes

Common mistakes include calling every centrally managed robot fleet a swarm, assuming more robots always produce proportional gains, and treating individual simplicity as proof of low total cost. Charging, maintenance, deployment, retrieval, and communication can dominate operations. A visually impressive formation also does not establish robust performance on unrelated collective tasks.

Business use

Businesses considering swarm approaches should identify the reason a group is useful: parallel coverage, redundancy, distributed sensing, or another measurable benefit. Compare the entire system with fewer more capable robots and with ordinary fleet coordination. Evaluate scaling, loss of members, environmental bottlenecks, and recovery effort under representative conditions before extrapolating from a small demonstration.

Check your understanding

Why do 100 inspections cover only about 64 unique cells in the example?

Answer: Different robots can inspect the same cells.

Does doubling the robots double unique coverage?

Answer: No; the expected coverage rises to about 87 cells.

Why is the failure calculation limited?

Answer: It ignores physical blockage and communication dependencies.

Related terms

Aggregation
Scalability
Robustness
Multi-robot systems
collective behavior
self-organization
decentralized control
local communication
coverage
collective transport

Learn next

Next, compare group performance at several population sizes while holding the environment fixed. Measure unique useful work, congestion, communication load, and recovery after selected robots stop participating.

Sources

IEEE Spectrum ROBOTS, Robotics Glossary, Swarm Robotics: https://robotsguide.com/learn/robotics-glossary Harvard School of Engineering and Applied Sciences, A Self-Organizing Thousand-Robot Swarm: https://seas.harvard.edu/news/self-organizing-thousand-robot-swarm

Previous: SWAR Next: Swendsen--Wang Algorithm