Nature already solved this
Watch a colony of ants carry a leaf many times the size of any single ant, or a flock of starlings twist through the sky as if it were one living cloud. No ant is in charge. No bird shouts orders. Each individual follows a few simple rules — stay close to your neighbors, don't bump into them, head roughly the same way — and out of all those tiny local choices, a large, smart-looking behavior appears. Nature solved a hard problem long before we built our first machine: how do you get a big job done with many small, limited workers?
Robotics borrows this lesson directly. A single robot — even a brilliant one — has one body, one set of sensors, and can only be in one place at a time. A multi-robot system is simply a group of robots working toward a shared goal: the team can be in many places at once, survive the failure of any one member, and split a giant task into bite-sized pieces. This guide opens the whole robotics-systems track by asking a deceptively simple question: when is a crowd better than a genius?
Swarms: cleverness from simple rules
One flavor of multi-robot system pushes the ant idea to its limit. In swarm robotics, you build many cheap, near-identical robots, give each one only local information — what it can sense within a short range or hear over a short-range radio link — and let useful group behavior emerge without any single robot understanding the whole plan. No member knows the global map. Each just reacts to its neighbors. We call the result emergent behavior: the team accomplishes something none of its members could describe on its own.
The famous toy example is "boids," Craig Reynolds's 1986 simulation of flocking. Each simulated bird obeys three rules — separation (don't crowd your neighbors), alignment (steer the way nearby neighbors are steering), and cohesion (move toward the average position of nearby neighbors). That's it. Yet a screen full of boids flows around obstacles like a real flock. Swarm robots do the same with physical wheels and sensors: local rules in, collective behavior out.
Centralized brains vs. decentralized teams
Not every team is a swarm. The big design fork is who decides. In a centralized system, one computer sees everything and tells each robot exactly what to do — like an air-traffic controller directing planes. In a decentralized system, every robot decides for itself using only what it can sense and hear from its neighbors — closer to a crowd leaving a stadium without a single usher. Both are valid; they just trade off different things. This trade-off is the heart of robot autonomy: how much each machine decides on its own versus how much is dictated from above.
Centralized control gives you a clean, globally optimized plan and is easy to reason about — but the central brain is a single point of failure, and the radio network can choke as the team grows. Decentralized control survives lost robots and dropped messages and scales beautifully — but no one can guarantee the team is doing the best possible thing, only something good enough. Real systems often blend the two: a supervisor sets high-level goals while each robot handles its own moment-to-moment moves.
Where does each shine? In a warehouse — think warehouse and logistics robotics — hundreds of shelf-carrying robots usually lean centralized: the building is mapped, the network is reliable, and a fleet manager can route everyone to avoid gridlock. For search and rescue in a collapsed building (search-and-rescue robotics), radios are spotty and robots get crushed, so a decentralized team that keeps working as members drop out wins. And in agricultural robotics, a swarm of small field robots can weed or scout a farm in parallel, cheaper and gentler on the soil than one giant machine.
The catch: coordination is the real work
Adding robots sounds like pure upside, but every extra robot is also one more thing to bump into, talk over, and disagree with. The price of a team is multi-robot coordination: making sure the robots help one another rather than trip over each other. Two robots that both decide to grab the same box, or both swerve the same way to avoid a collision and crash anyway, are worse than one robot working alone.
Coordination breaks down into a handful of recurring puzzles that the rest of this track unpacks one by one. The team must agree on shared facts even with noisy, partial information — that's distributed consensus, robots reaching agreement the way a committee votes. They must hold useful shapes while moving, which is formation control, like geese keeping their V. And they must divide the work fairly, which is multi-robot task allocation — deciding who picks up which package and who scouts which room.
Underneath all of it sits plumbing: the software that lets robots pass messages, share maps, and trigger each other's actions without descending into chaos. Later guides introduce the tools that make this practical — the publish–subscribe pattern for loosely coupled messaging, the Robot Operating System that ties a robot's programs together, and behavior trees for structuring what a robot does and when. For now, just hold the big picture: hardware lets a robot act, but coordination is what turns a pile of robots into a team.