Swarm Robotics - A gentle introduction

Have you ever seen a group of birds flying in perfect formation, or ants teaming up to build a nest? Those are natural swarms: lots of simple creatures working together, without a single boss telling everyone what to do. Swarm robotics tries to capture that same idea in the world of robots. Instead of one big, complicated machine, you have many smaller robots that each do something simple—and by coordinating with each other, they can achieve impressive results!

Why Swarm Robotics?

Scalability: If you need more work done, just add more robots.
Robustness: If one robot breaks, the swarm can keep going.
Flexibility: Small robots can tackle many tasks by reassigning roles among themselves.

In large‐scale operations like warehouse sorting or search‐and‐rescue, a swarm of simple robots can sometimes beat a single, costly robot by dividing the workload. Of course, making these robots “swarm together” takes clever algorithms, which is where the fun and challenge begins. A great example is shown below of how Amazon uses a swarm of warehouse robots to optimize its fulfillment processes, drastically reducing order processing times and increasing overall efficiency.

Let’s Get Hands‐On!

In this blog, I intend to simulate a small-scale swarm system using Ubuntu (any recent version, e.g. 20.04, 22.04, or 24.04) and ROS 2 (Robot Operating System). For more information on ROS 2, you can follow the official ROS 2 Installation Guide. You can also need to clone or download the code from our GitHub repository

Defining GOAL for small-scale swarm system

I want a swarm of robots to collaboratively draw the pattern "SWARM ROBOTICS." Just like in research and the real world, I kept the goal of the small-scale swarm system vague for iterative development and learning. Why the words "SWARM ROBOTICS?" I chose this phrase because it (complex task) naturally breaks down into multiple letters (sub-tasks), perfect for demonstrating how swarm robots can multitask.

Environment Setup

We’ll start with the Turtlesim simulator, a simple 2D environment where each “turtle” is like a small robot. Our task is to have these turtles “draw” the words SWARM ROBOTICS by visiting waypoints that outline each letter. We’ll begin with just one turtle (to learn the basics of controlling position and orientation), and then scale up to multiple turtles—showcasing how a group of robots can demonstrate swarm behavior.

Turtlesim uses an 11×11 coordinate system for its drawing space, so the first task was figuring out which points (waypoints) each turtle should follow to form the letters in “SWARM ROBOTICS.” To do this, I plotted and tested the letter shapes using the matplotlib python package, then wrote down their coordinates so the turtle could trace them out correctly.

Robot Internal Components

For moving the robot, we need two important components: Controller and Planner. If a robot is a car, the planner is Google Maps, and the controller is a person driving it. Google Maps gives you the route to go from point A to B, and the person applies brakes, acceleration, and steering to follow the route while avoiding other vehicles and obeying traffic signals.

Controller and Planner:

To draw “SWARM ROBOTICS” in a structured way, each letter is broken down into a sequence of waypoints—points in the Turtlesim space that, when visited in order, form that letter’s shape. To accomplish this, we need both a planner and a controller:

Planner (High-Level):
- The planner decides where the turtle should go next. In our case, it has a predefined set of waypoints for each letter.
- It also decides when the turtle has reached a waypoint and needs to switch to the next one. Essentially, the planner handles the overall “path” through the letters, making sure the turtle visits the correct points in the correct sequence.
Controller (Low-Level):
- Once the planner says “go to waypoint (1.5, 8),” the controller figures out how to move there.
- This involves computing the linear and angular velocities (forward speed and turning speed) based on the turtle’s current position.
- If the turtle is facing the wrong direction, the controller turns it first; if it’s already aligned, the controller moves it forward until it’s close enough to the next waypoint.

Both layers are crucial: the planner organizes all waypoints for each letter, and the controller ensures the turtle can precisely follow that plan in real-time.

Math behind a simple Controller:

To move the turtle from its current position (x, y) toward a target waypoint (x_t, y_t), we set two control signals: a linear velocity v (how fast the turtle goes forward) and an angular velocity ω (how fast it turns). First, we measure how far away the turtle is from the goal and figure out the direction we want it to face.

We compare that desired direction to the turtle’s current orientation and compute an angle error, making sure to keep that error in a sensible range (so we only turn the “short way around”).

Next, we apply a simple proportional control. The angular velocity ω is a constant times the angle error: a big angle error means the turtle rotates faster, and a small angle error means a gentle turn. The linear velocity v is a separate constant times the distance to the goal, but only if the angle error is smaller than some threshold (like 0.1 radians). This prevents the turtle from driving in a wide curve if it is facing the wrong direction; it will turn in place first, and then move forward once aligned.

Finally, after every position update, we check if the turtle is close enough to the current waypoint. If it is within a threshold distance (0.05), we say the waypoint is “reached” and move on to the next one. After visiting all waypoints for a letter, the turtle proceeds to the next letter.

With this approach—proportional control for turning and moving, plus a waypoint threshold—the turtle can smoothly traverse the Turtlesim environment and form each letter of “SWARM ROBOTICS.”

SINGLE ROBOT IMPLEMENTATION:

I created a simple ROS package in Python that gives linear and angular velocities to a turtle in the Turtlesim simulator to follow the waypoints to draw the “SWARM ROBOTICS” pattern and it finished in 24 minutes and 36 seconds. The output is not exactly as you hope as it shows how factors like distance threshold, angular error tolerance, and a basic proportional controller affect both precision and speed. For clarity, the video below is shown at 16× normal speed.

MULTI-ROBOT IMPLEMENTATION:

Once we introduce multiple turtles into the same environment, a natural question arises: which turtle draws which letter? This is a classic task allocation problem, where we need to divide up the workload so that each robot contributes without stepping on another’s toes. Here each task is drawing a letter in "SWARM ROBOTICS". The below figure shows a example of task allocation done for 3 turtles.

As you may have noticed, the tasks are assigned in a mutually exclusive way. I purposefully made this choice to eliminate swarm coordination because it is hard to do. Additionally, for such a simple "SWARM ROBOTICS" task swarm coordination might be overdoing it. But, I will explain when the swarm coordination becomes a necessity later in this blog.

By assigning tasks (letters) in a mutually exclusive way, we ensure that no two turtles attempt to draw the same letter hence no collision possibility. Once the letters are uniquely assigned, each turtle can draw its portion in parallel with minimal overlap, which significantly speeds up the overall time compared to a single-turtle scenario. But, how do we allocate tasks in a mutually exclusive way?

Task Allocation Using an Auction Algorithm

One powerful tool is the auction algorithm, originally introduced by Dimitri Bertsekas [1] to solve one-to-one assignment problems. The auction algorithm is an iterative algorithm that converges to give the optimal solution when there are equal numbers of robots and tasks meaning each robot gets one unique task to perform. Well, in our case there are 13 letters (tasks) in SWARM ROBOTICS hence we need 13 turtles. This is not realistic in the real world from a cost perspective. So, we modify this auction algorithm to solve the general assignment problem which works sub-optimally irrespective of the number of robots or tasks.

What Is the Auction Algorithm?

The auction algorithm is a method for assigning tasks to agents (in our case, letters to turtles) to minimize the overall “cost.” The cost here is the total distance traveled by all the turtles to draw the pattern, In classical form, it works like a real auction:

Tasks are like “items for sale.”
Agents (robots/turtles) place bids on the tasks they want, based on how “cheap” or “easy” it is for them to complete those tasks.
As tasks receive higher bids, their prices go up. Eventually, each task ends up with exactly the agent that values it the most (i.e., can do it at the least cost).

How It Works (A Simple 2-Turtle Example)

Imagine we have two turtles (Turtle A and Turtle B) and just four letters to assign, say S, W, A, R:

Initial State
- Each letter has a price of 0.
- No turtle owns any letter yet.
- No turtle has started traveling any amount of distance.

'S' price	'W' price	'A' price	'R' price
0	0	0	0

Turtle A distance	Turtle B distance
0	0

Turtle Evaluations (Round 1)
- Each turtle computes the cost of drawing each letter, typically based on distance.
- Turtle A: finds S the cheapest (5), second cheapest is R (6).
- Turtle B: finds W the cheapest (4), second cheapest is R (5).
- Below are sample costs:

	'S' cost	'W' cost	'A' cost	'R' cost
Turtle A	5	7	9	6
Turtle B	8	4	10	5

Bidding (Round 1)
- Each turtle bids on its best letter. The bid is the letter’s current price plus an increment turtle.
- ϵ is very small say 0.01. This ensures that if another turtle has already bid for that letter, the new turtle must bid above the current price to claim it.
- The new bid formula is a simple way to make sure that not one turtle gets over-allocated with many tasks, as with each task allocation, the robot's ability to bid higher decreases because we are dividing by the distance traveled by the turtle.
- So, a turtle that has not yet allocated any letters will place a higher bid and win the auction.
- The second benefit of the bid formula and perhaps the point of this blog when you have multiple robots and multiple tasks that need to be allocated, equitable (or close) allocation of tasks amongst robots will result in the quickest completion of all tasks.
- The statement is assuming all robots have the same capabilities.

	'S' price	'W' price	'A' price	'R' price
Turtle A	0+6-5+0.01 = 1.01	0	0	0
Turtle B	0	0+5-4+0.01 =1.01	0	0

Task “Ownership” Updates (Round 1)
- S is now “won” by Turtle A (price = 1.01).
- W is now “won” by Turtle B (price = 1.01).
- Letters A and R remain at price = 0 (unassigned).
- Finally, turtle distances are updated based on the assignment.

Turtle A distance	Turtle B distance
5	4

Repeat (Round 2)
- Turtle A: finds R the cheapest (6), second cheapest is A (9).
- Turtle B: finds R the cheapest (5), second cheapest is A (10).
- Below are sample costs:

	'S' cost	'W' cost	'A' cost	'R' cost
Turtle A	5	7	9	6
Turtle B	8	4	10	5

Bidding (Round 2)
- Now we need to consider the turtle distances in the bid formula.
- Turtle A: new bid on R = (0 + (9 - 6) + 0.01)/5 = 0.62
- Turtle B: new bid on R = (0 + (10 - 5) + 0.01)/4 = 1.25

	'S' price	'W' price	'A' price	'R' price
Turtle A	1.01	0	0	0.62
Turtle B	0	1.01	0	1.25

Turtle A distance	Turtle B distance
5	9

Task “Ownership” Updates (Round 2)
- R is now “won” by Turtle B (price = 1.25).
Bidding (Round 3)
- As there is only one task left there is no first or second best.
- Turtle A: new bid on A = (0 + 0.01)/5 =
- Turtle B: new bid on A = (0 + 0.01)/9
- A is automatically “won” by Turtle A because of a higher bid than Turtle B mainly because it has traveled less distance.
Final Assignment:

S → Turtle A

W → Turtle B

R → Turtle B

A → Turtle A

Turtle A distance	Turtle B distance
14	9

The algorithm iterates until every letter is “won” by exactly one turtle:
- No overlaps: each letter is assigned to only one turtle.
- Cost Efficiency: tasks end up with the turtle that can do them at the lowest relative cost, so overall cost is minimized or near‐minimized.

As each letter’s “price” rises, only the turtle that can handle it the most efficiently (lowest cost) remains willing to bid on it. Eventually, every letter is assigned to exactly one turtle—no overlaps.

Why an Auction Algorithm?

Decentralized Friendly: Although we can implement it with a central “auctioneer,” the math and logic can be distributed among the turtles (they each broadcast bids, and “ownership” updates spread throughout the network).
Proven Effectiveness: Auction algorithms are known to converge to optimal or near‐optimal solutions in assignment problems. That means minimal overall “cost” (e.g., total travel distance) or maximum efficiency in many scenarios.

In the next part, we’ll see how applying this auction logic to “SWARM ROBOTICS” allows each turtle to “grab” the letters it can draw most cheaply, resulting in a faster (and conflict‐free) multi‐robot solution.

Simulation Results

For the multi-robot simulation, we begin by randomly spawning a given number of turtles across the 11×11 environment. We then run the auction algorithm to assign each letter (task) of “SWARM ROBOTICS” to exactly one robot. After the assignment, every turtle draws its allocated letters in parallel, using simple proportional controllers for movement. The process is repeated for different numbers of turtles—2, 4, 6, 8, 10, 11, 12, 13, and 14—and the results are compiled into a GIF to visualize how multiple turtles working together can drastically cut down on total drawing time.

The graph below plots the final time required to complete “SWARM ROBOTICS” against the number of robots. The red dashed line shows the single‐robot scenario taking far longer (well over 1400 seconds), while the blue dashed line demonstrates how increasing the swarm size steadily reduces the overall time. By about 12–14 turtles, the pattern is drawn in roughly 240 seconds, highlighting the efficiency gains achieved through task allocation and parallel work.

Findings

It doesn't take a genius to see that adding more robots can speed up a complex task. However, the challenge is knowing how many to use and how to assign them. Beyond a certain point, more robots yield diminishing returns. For example, adding a second robot might cut the drawing time by 10 minutes, but adding two more only saves 6 minutes. There's an optimal point where every robot is busy all the time. Finding that sweet spot requires optimization, and the current auction algorithm sometimes falls short. For instance, when using 10, 12, 13, or 14 turtles, one turtle was never used. This happens because the general assignment problem is NP-hard, and the auction algorithm uses a greedy heuristic that focuses on the best immediate match rather than long-term planning.

Resilient Swarm

There was one aspect that was briefly touched upon earlier in this blog: swarm communication. For example, in our pattern drawing scenario, if one turtle fails to complete its task, effective communication allows the other turtles to be alerted and take over the assignment. This ensures that even in the face of individual robot failures, the overall task continues to progress—a critical feature of any resilient swarm. In essence, the swarm becomes self-organizing, with each unit ready to adapt and reassign tasks dynamically. This resilience against uncertainty, whether due to hardware malfunctions or unpredictable environments, is a key area of research. By developing robust communication protocols and adaptive algorithms, we can design swarms that not only optimize task allocation but also maintain high levels of performance and reliability under adverse conditions.

Conclusion

In summary, optimizing task allocation in robot swarms is a multifaceted challenge that goes beyond simply adding more robots. The auction algorithm offers a practical, albeit sometimes suboptimal, method for assigning tasks efficiently. However, its limitations—especially when considering real-world issues like robot failures—highlight the need for resilient swarm behavior. By integrating robust communication protocols and adaptive strategies, we can design systems where each robot not only contributes effectively under normal conditions but also compensates for unexpected disruptions. Moving forward, research in resilient swarms and advanced optimization algorithms will be critical in realizing fully autonomous, efficient, and fault-tolerant robotic systems.

Github repo: link

References

Bertsekas, D. P. (1979). A distributed algorithm for the assignment problem. Lab. for Information and Decision Systems Working Paper, MIT.