💻 computer science

Exploiting Aggregate Programming in a Multi-Robot Service Prototype

This paper presents and validates a multi-robot service prototype that leverages Aggregate Programming to address the complexities of coordinating distributed systems in real-world environments, demonstrating its effectiveness through both simulations and tests in a university library.

Original authors: Giorgio Audrito (Dipartimento di Informatica, Universita' di Torino), Andrea Basso (MITO Technology), Daniele Bortoluzzi (Dipartimento di Informatica, Universita' di Torino), Ferruccio Damiani (Dipart

Published 2026-04-09

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Giorgio Audrito (Dipartimento di Informatica, Universita' di Torino), Andrea Basso (MITO Technology), Daniele Bortoluzzi (Dipartimento di Informatica, Universita' di Torino), Ferruccio Damiani (Dipartimento di Informatica, Universita' di Torino), Giordano Scarso (Dipartimento di Informatica, Universita' di Torino), Gianluca Torta (Dipartimento di Informatica, Universita' di Torino)

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a busy university library. Students are rushing around, trying to find specific books, but the shelves are huge, the codes on the books are confusing, and the librarians are overwhelmed. To help out, the library decides to hire a team of small, autonomous robots to act as personal book-finders.

But here's the tricky part: How do you get a team of robots to work together without a single "boss" robot telling everyone what to do? If the boss robot breaks, or if the Wi-Fi goes down, the whole team should stop working. That's a nightmare to program.

This paper introduces a clever solution called Aggregate Programming (AP). Think of it not as giving orders, but as creating a "hive mind" or a "flock of birds" behavior.

The Core Idea: The "Bird Flock" Metaphor

Imagine a flock of birds. No single bird is the leader. If a hawk attacks, the flock scatters and reforms instantly. If a bird gets tired, the others adjust. They don't need a central command center; they just react to their neighbors.

The researchers used a programming style (based on something called the "Exchange Calculus") that makes robots behave like that flock.

No Boss: Every robot is equal.
Local Chat: Robots only talk to the ones right next to them (like neighbors chatting over a fence).
Self-Healing: If one robot dies or the network splits in half, the group automatically reorganizes itself to keep working.

The Story of the Library Robots

Here is how the system works in their prototype:

The Request: A student walks up to a kiosk and says, "I need a book about cats."
The Broadcast: The system shouts this request into the air (digitally). Every robot in the library "hears" it.
The "Voting" Process: This is where the magic happens.
- Robot A is close to the cat section but has a low battery.
- Robot B is far away but has a full battery.
- Robot C is right next to the cat section and fully charged.
- Instead of a central computer calculating who should go, every robot calculates its own "score" based on distance and battery.
- They share these scores with their neighbors. Through a process of "voting" (mathematically finding the best option), the group naturally agrees: "Robot C, you go! You have the best score."
The Action: Robot C goes to get the book. The others go back to waiting.

What Happens When Things Go Wrong? (The "Resilience" Part)

The paper tested this in two ways: a computer simulation (Gazebo) and real robots (iRobot Create3) in a real library. They introduced chaos to see if the system would break.

The "Battery Drain" Test: They simulated a robot's battery dying instantly.
- Old Way: The robot might keep trying to walk until it stops, wasting time.
- AP Way: The robot realizes it's low on power. It tells its neighbors, "I can't do this." The neighbors instantly re-calculate the scores, realize Robot C is now the best choice, and Robot C takes over the task. No human intervention needed.
The "Wall" Test (Network Partition): They moved robots so far apart that they couldn't talk to each other, splitting the library into two isolated groups.
- Old Way: The system would freeze or get confused.
- AP Way: Both groups realized they were cut off. Group 1 started doing their own tasks, and Group 2 did theirs. When the robots moved back close enough to talk again, the system instantly noticed, "Oh, we are back together!" and resolved any conflicts (like two robots trying to grab the same book) automatically.

Why Is This a Big Deal?

Usually, programming robots is like writing a script for a play where every actor must follow a strict script. If one actor forgets a line, the play crashes.

This paper shows that you can program robots more like improvisational jazz musicians. They listen to each other, adapt to the moment, and if someone drops a note, the music keeps flowing without missing a beat.

The Bottom Line

The researchers successfully built a team of robots that can find books in a library, handle new requests on the fly, and recover from failures (like dead batteries or broken connections) all without a central boss. They proved that this "hive mind" approach is not just a cool theory, but a practical tool that works in the real world.

In short: They taught robots to be a self-healing, self-organizing team, making them much more reliable for helping us in the real world.

1. Problem Statement

The paper addresses the significant challenges in engineering Multi-Robot Systems (MRS), particularly for service applications in dynamic environments like university libraries. Building such systems involves two intertwined difficulties:

Hardware Complexity: Managing heterogeneous sensors, actuators, and communication constraints.
Distributed Coordination: Ensuring effective collective decision-making in physical environments where robots may fail, move, or experience network partitions.

Traditional approaches often rely on centralized control or complex, explicit message-passing protocols that are brittle in the face of failures. The authors aim to demonstrate that Aggregate Programming (AP) can provide a resilient, macro-programming approach to coordinate a team of robots for a Multi-Robot Task Assignment (MRTA) problem without a centralized infrastructure.

2. Methodology

The authors developed a prototype system where a team of robots collaborates to locate books for students in a library. The core methodology relies on the eXchange Calculus (XC) and the Field Calculus++ (FCPP) library.

A. System Architecture

The system integrates three main layers (Figure 2):

Web Dashboard: Users request books via a kiosk.
Aggregate Programming (AP) Engine: Built on FCPP (C++), this layer runs on every robot (simulated or physical). It handles the distributed logic, task assignment, and resilience.
ROS2 Control Layer: A "Robot Writer" and "Robot Reader" bridge the AP engine with the robot's navigation stack (NAV2) and sensors. The AP engine writes goals to text files/ROS topics, and the ROS2 layer handles low-level motion planning and telemetry feedback.

B. The Aggregate Algorithm (MRTA)

The core logic implements a ST-SR-IA (Single Task, Single Robot, Immediate Assignment) variant of MRTA with specific AP features:

Aggregate Processes: Each incoming book request ( $T_j$ ) spawns a distributed aggregate process. If multiple robots receive the task, the processes automatically merge into a single collective computation.
Consensus via Leader Election: Robots calculate a local score ( $r_{i,j}$ ) based on distance to the book and battery level. They use a self-stabilizing Leader Election operator (diameter_election) to find the robot with the optimal score (lowest value) across the network.
Self-Stabilization: The algorithm is designed to handle dynamic changes. If the current leader fails or a better candidate appears (e.g., due to battery drain), the system automatically reassigns the task without external intervention.
Conflict Resolution: In cases of temporary network partitioning where two robots might claim the same task, the system resolves conflicts once connectivity is restored by assigning the task to the robot with the higher score.

C. Cost Function

The scoring mechanism prioritizes efficiency and resilience:
$\text{score} = \text{dist} \times (1.0 - \text{percent\_charge})$
This ensures that robots closer to the target with higher battery levels are selected.

3. Key Contributions

First Real-World AP Deployment: To the authors' knowledge, this is the first system to deploy an AP algorithm on physical robots (iRobot Create3), moving beyond previous simulations or centralized AP implementations.
Resilient Coordination Logic: The system successfully handles:
- Dynamic Task Arrival: Concurrent processing of multiple book requests.
- Node Failures: Automatic reassignment if a robot fails or its battery drains.
- Network Partitions: The system continues to operate within isolated sub-networks and merges correctly upon reconnection.
Practical Integration: The paper details the engineering challenges of interfacing AP (which assumes asynchronous rounds) with ROS2 (real-time navigation), including handling latency, message mapping, and hardware constraints (e.g., RAM limits on Create3).
Validation: The prototype was validated in two environments:
- Simulation: Using Gazebo with up to 10 robots.
- Physical Prototype: A library setting with real iRobot Create3 robots equipped with LIDAR and onboard computers.

4. Results

Simulation: The system successfully simulated up to 10 robots. It demonstrated the ability to reassign tasks instantly when a robot's battery was artificially drained via a ROS2 service call.
Network Partitioning: A critical test involved reducing the communication range to induce a network split. The system allowed independent task execution in both partitions. Upon reconnection, it detected conflicting assignments (e.g., two robots moving to the same book) and automatically halted the less optimal robot to ensure consistency.
Physical Prototype: The system operated successfully with real robots in a university library. It handled navigation, task assignment, and failure notifications (e.g., robot lifted off the ground or critical battery levels) robustly.
Performance: The AP engine operated with a 0.2-second round interval, maintaining robust communication even with the overhead of the custom UDP driver and ROS2 integration.

5. Significance

This work is significant because it bridges the gap between theoretical Aggregate Programming and practical robotics engineering.

Resilience by Design: It proves that AP's self-stabilizing operators can handle real-world physical failures and network instability without complex, custom fault-tolerance code.
Scalability: The approach avoids centralized bottlenecks, making it suitable for large-scale swarms where a central server might be a single point of failure.
Engineering Stack: The paper provides a concrete blueprint (the "Engineering Stack" in Figure 1) for integrating high-level aggregate logic with low-level robot control systems (ROS2), offering a path forward for future service robots in healthcare, exploration, and logistics.

In conclusion, the paper demonstrates that Aggregate Programming is a viable, robust, and efficient paradigm for coordinating multi-robot service systems in dynamic, real-world environments.