Paper deep dive
Exploiting Aggregate Programming in a Multi-Robot Service Prototype
Giorgio Audrito, Andrea Basso, Daniele Bortoluzzi, Ferruccio Damiani, Giordano Scarso, Gianluca Torta
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 95%
Last extracted: 4/10/2026, 1:59:56 AM
Summary
This paper presents a multi-robot service system prototype for a university library, utilizing Aggregate Programming (AP) and the eXchange Calculus (XC) to manage distributed coordination. The system addresses Multi-Robot Task Assignment (MRTA) by leveraging self-stabilizing consensus algorithms to ensure resilience against robot failures, network splits, and dynamic task arrivals. The prototype was validated through Gazebo simulations and real-world testing.
Entities (6)
Relation Signals (4)
Multi-Robot Service System â uses â Aggregate Programming
confidence 98% ¡ we present a prototype of a multi-robot service system, which adopts AP for the design and implementation of its coordination software.
Aggregate Programming â implementedby â eXchange Calculus
confidence 95% ¡ The reference programming language for AP is the recently proposed eXchange Calculus (XC)
FCPP â implements â eXchange Calculus
confidence 95% ¡ implemented by both the Field Calculus++ (FCPP) C++ library
Multi-Robot Service System â integrates â ROS2
confidence 95% ¡ It integrates a combination of a web-based dashboard, an Aggregate Programming (AP) engine, and ROS2-based robot control components.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Multi-robot systems are becoming increasingly relevant within diverse application domains, such as healthcare, exploration, and rescue missions. However, building such systems is still a significant challenge, since it adds the complexities of the physical nature of robots and their environments to those inherent in coordinating any distributed (multi-agent) system. Aggregate Programming (AP) has recently emerged as a promising approach to engineering resilient, distributed systems with proximity-based communication, and is notably supported by practical frameworks. In this paper we present a prototype of a multi-robot service system, which adopts AP for the design and implementation of its coordination software. The prototype has been validated both with simulations, and with tests in a University library.
Tags
Links
- Source: https://arxiv.org/abs/2604.06876v1
- Canonical: https://arxiv.org/abs/2604.06876v1
Trouble viewing inline? Open PDF directly â
Full Text
40,605 characters extracted from source content.
Expand or collapse full text
Lorenzo Gheri & Kirstin Peters (Eds.): 17th International Workshop on Programming Language Approaches to Concurrency and Communication-cEntric Software 2026 (PLACES 2026) EPTCS 444, 2026, p. 45â57, doi:10.4204/EPTCS.444.5 This work is licensed under the Creative Commons Attribution License. Exploiting Aggregate Programming in a Multi-Robot Service Prototype Giorgio Audrito UniversitĂ di Torino, Turin, Italy giorgio.audrito@unito.it Andrea Basso MITO Technology, Milan, Italy andrea.basso@alumni.epfl.ch Daniele BortoluzziFerruccio DamianiGiordano ScarsoGianluca Torta UniversitĂ di Torino, Turin, Italy name.surname@unito.it Multi-robot systems are becoming increasingly relevant within diverse application domains, such as healthcare, exploration, and rescue missions. However, building such systems is still a significant challenge, since it adds the complexities of the physical nature of robots and their environments to those inherent in coordinating any distributed (multi-agent) system. Aggregate Programming (AP) has recently emerged as a promising approach to engineering resilient, distributed systems with proximity-based communication, and is notably supported by practical frameworks. In this paper we present a prototype of a multi-robot service system, which adopts AP for the design and imple- mentation of its coordination software. The prototype has been validated both with simulations, and with tests in a University library. 1 Introduction Multi-robot systems are becoming increasingly relevant within diverse application domains, ranging from the exploration of dangerous or extreme environments [31, 18, 29], to rescue missions [22, 30], to service applications, e.g., in healthcare for the elderly [12, 20, 27]. Building multi-robot systems represents a significant challenge, because it involves solving two distinct, but interrelated problems. On one hand, the (possibly heterogenous) hardware characteristics of the robots (sensors, actuators, communication) have to be carefully taken into account and exploited; on the other hand, the distributed, multi-agent nature of multi-robot systems requires the deployment of mechanisms for coordination and collective decision making that perform effectively in real, physical environments. Aggregate Programming (AP) [11] has emerged as a generalization of various previous approaches to programming ensembles of devices [10, 35], applicable to distributed systems deployed in far edge, fog or cloud environments, as well as (simulations of) swarm robotics [7, 13, 3]. A central feature of this programming model is its ability to express complex distributed processes through function compo- sition. Aggregate computations are performed over distributed networks of (possibly) mobile devices, each capable of asynchronously performing local computations, and of interacting with a neighbourhood by local exchanges of messages (supported by a peculiar communication primitive namedexchange). Several characteristics make AP a promising candidate for tackling the problem of building multi-robot systems (see Section 2 for details). First of all, it embeds resilience (e.g., to failure of communications, failure of nodes) as a first-class citizen, through its self-stabilizing operators; Secondly, it simplifies pro- gramming networks of (heterogenous) devices with a compositional, macro-programming style; Finally, it has several practical implementations [15, 28], including FCPP[8], a C++ implementation that supports deployment on embedded systems. 46AP in a Multi-robot Prototype In this paper, we present in detail the design and implementation of a prototype of a multi-robot service system for helping users in a University library. The application was chosen because of the growing presence of service robots in libraries [26, 32], as well as because we had the possibility to experiment in one of the libraries of our University. While a recent paper applies AP to the formation control of swarms of Rover Wave mini-robots [1], it relies on a centralized deployment of AP which implements the computation and communication of each robot as a local process, leaving to the physical robots just the execution of commands and the production of sensor data. To the best of our knowledge, our system is then the first one to deploy an AP algorithm on real robots. Our main contributions are: (i) we applied AP to implement the coordination logic of a real multi-robot system, exploiting some of its features to ensure resilience to failures and changes, as well as ease of programming; (i) we coped with practical issues not directly addressed by AP, such as the possibility that in some situations two or more robots start the execution of the same task, or the need of efficiently interfacing the AP decision program with the robots navigation control, and sensors feedback; (i) we validated our implementation both with a realistic simulator (Gazebo), and with a prototype implementation of the system on a team of physical robots. 1 The paper is organized as follows. In Section 2, we describe the eXchange Calculus underpinning AP. In Section 3, we present our case study, namely a multi-robot library service, and then briefly de- scribe the main employed technologies. Section 4 presents in detail the logic of the AP algorithm we have developed for the case study, which is essentially a distributed, resilient Multi-Robot Task Assign- ment (MRTA). In Section 5 we report on further technical details about experimenting with the Gazebo simulator and with real robots, as well as on the test scenarios we explored. Finally, in Section 6 we close the paper, pointing out directions for further research. 2 Aggregate Programming The reference programming language for AP is the recently proposedeXchange Calculus (XC)[4, 5], implemented by both theField Calculus++ (FCPP)C++ library [2, 8, 9], that will be exploited in this paper, and theScala Fields (ScaFi)Scala library [14, 15, 13]. XC provides mechanisms to express and compose distributed computations, on a level of abstraction that avoids the explicit management of message exchanges, device position and quantity, and so on. In this context, a single program is periodically and asynchronously executed on every device, according to a cyclic schedule ofrounds. In each round, the device gathers sensorsâ inputs and recently collected messages; evaluates the program; and broadcasts the result to neighbours and (possibly) actuators. A formal semantics can be provided to XC programs through the notion ofevent structure[23], which is a finite set of eventsEalong with an acyclicneighbouring relationââEĂEmodelling message passing. An event corresponds to around of activationof a device. An example structure is illustrated in Figure 1 (left). In practice, event structures arise from device neighborhood graphs changing over time. For instance, device 3 is activated at a certain point in time, with devices 4 and 1 as neighbors; after a couple of activation rounds, its neighbors become devices 2 and 4. In XC, a fundamental role is played byneighbouring valuesw, which represent (sets of) local literals either received from or sent to neighbouring devices. These values are defined as mapsw= â[δ 1 7ââ 1 ,...,δ n 7ââ n ], mapping device identifiersδ i to their respective local literalsâ i . Additionally, there is a local literalâthat serves as adefault, e.g., for neighbours that are unknown to the device, but 1 The code for the simulations is publicly available athttps://github.com/fcpp-experiments/ ros2-library-project. G. Audrito et al.47 1 2 3 4 5 device time ÇŤ Device Capabilities Exchange Calculus Coordination Operators Developer APIs Applications sensors actuators communication state C G T perception behavior action builtins exchange spawn Figure 1: A sample event structure, split in eventsÎľ Ⲡin the past ofÎľ(Îľ Ⲡ<Îľ, in red), events in the future (Îľ<Îľ Ⲡ, in green) and concurrent (non-ordered, in black) (left). AP Engineering Stack Layers (adapted from [34]) (right). receive the nvalue. The language models local valuesâ(those not dependent on neighbours) as a special case of neighbouring valuesâ[], containing only the default local literal. Thus, in XC each value can be considered as a neighbouring value. Neighbouring values can be aggregated into a single local value through a functional-style fold operationnfold(f,w,l), which applies a specified binary operationf repeatedly to the local values that formw, except for the current deviceδ, whose value is taken from the largument. In XC, evaluation is performed within a context that includes all messages received from neighboring devices. A technique known asalignmentensures that for each sub-expression, the context is limited to values corresponding to the same sub-expression on neighboring devices. These context values are primarily utilized by a built-in function calledexchange, which models communication with neighbours. The expression: exchange (e 0 , (x) => returne r sende s ) is evaluated according to the following steps. ⢠First, gather aneighbouringvaluewthat maps each neighborδ Ⲡto the last value shared byδ Ⲡfor this exchange expression. ⢠If it is the first execution ofexchangeon the current deviceδ, the value ofe 0 is used as the value forδinw. Otherwise, the value shared byδitself in its previous round is used instead. ⢠Next, evaluatee r by substitutingwforx, resulting in a valuev r . Do the same fore s obtaining value v s . ⢠Finally, returnv r as the value of theexchangeexpression in the program, and broadcastv s to neighbors, who will use it in their subsequent rounds to produce their neighboring valuew. Consider, as an example, the following function declaration: defdist(source) exchange(infinity, (d)=> retsendmux(source, 0, nfold(min, d, infinity)+1)) 48AP in a Multi-robot Prototype In the function declaration above, we useretsendeas syntactic sugar forreturnesende. Func- tionmux(b,x,y)is the multiplexer function returning eitherxorydepending on whetherbis true or false, respectively. Thedistfunction calculates hop-count distances from the nearest device where sourceis true, using a singleexchangeconstruct. Aggregate Processes[16, 6] are distributed computations sustained by the dynamic aggregation of devices. They model transient collective activities, which may concurrently span and overlap over the fabric created by the devices of an AP network. Specifically, Aggregate Processes thus support the dynamic injection and execution of collective computations, their diffusion over selected regions of space-time, and their inherent self-adaptation to changes and faults. For the purposes of this paper, a better intuition on aggregate processes can be gained by understand- ing a modified version of thedistfunction described above, where different parallel computations are spawned by different source devices. 2 defmulti_dist(isSource, theta) val gen_set =if(isSource) set(uid())elseset(); spawn((i)=> val output = dist(uid()==i); val status = output<=theta; (output, status) , gen_set); Functionmulti_distspawns a new distance computation process in devices whereisSourceis true, limiting the computation to devices withinthetahops from the source. Variablegen_setis a set with the ID of the current device if it is a source, an empty set otherwise. Thespawnreceivesgen_set as the parameter specifying the set of processes it should create (if they donât exist yet). The behavior of the process is as follows: (i) theoutputis the value of thedistfunction above, computed w.r.t. one source, namely the device that has spawned the process; (i) thestatusistrue(i.e., active) for devices withinthetahops from the source,false(i.e. terminated) for other devices. The AP engineering approach goes beyond the features directly built into XC, by defining theEngi- neering Stackshown in Figure 1 (right). The first two layers denote the physicalDevice Capabilities, and theExchange Calculusconstructs, that provide the first abstraction over such capabilities. The third layer defines a number ofCoordination Operatorsthat play a crucial role both in hiding the complex- ity and in supporting efficient engineering of AP systems. Such operators are collective (i.e., computed across the network) and self-stabilising, meaning that when the topology or other network inputs change, after a certain delay also the outputs are updated to their (new) correct values [33]. The Figure names three key operators:Gis a highly general information spreading and outward computation operation;C is its inverse, a general information collection operation; andTimplements bounded state evolution and short-term memory. Finally, the top two layers are devoted, respectively, toDeveloper APIsfor particular domains, and toApplications. 3 Multi-Robot Library Service The ability to efficiently locate books within a library is crucial for both students and library staff. In the University library considered in our study, book identification is based on alphanumeric codes, which can be difficult for students to interpret without assistance from librarians. To address this issue, we 2 Note that, in this example,spawndoes not take the additional argument for the process function. G. Audrito et al.49 AP Engine [Container: FCPP, C++] Write actions to robot in [Text file] Robot Writer [Container: ROS2 Node, Python] Robot Reader [Container: ROS2 Node, Python] Read feedback from robots using [ROS2 topics] Send robots feedback with [Text file] Navigation System [Container: ROS2 Node, Python] Send actions to robot using [ROS2 Topic] Send low level commands to robot using [ROS2 actions and topics] Abort a goal [Text file] Read feedback robots using [ROS2 topics] Receive feedback from robot using [ROS2 topics] Send new goal [Text file] Figure 2: Architecture of the developed platform, integrating Aggregate Programming and ROS2. propose a system that leverages Aggregate Programming to enable a team of robots to collaborate and assist students in locating books. The use case is structured as follows: (i) A student arrives at the University library and searches for a desired book using an interactive kiosk located at the entrance of the experimental area; (i) The system processes the query and retrieves the bookâs location on the shelves; (i) The system selects the most suitable robot based on position, battery level, and availability; (iv) The chosen robot navigates to the appropriate shelf and moves toward the bookâs precise location. Thesystem architecture(Figure 2) is designed to efficiently coordinate autonomous robots. It integrates a combination of a web-based dashboard, an Aggregate Programming (AP) engine, and ROS2- based robot control components. In this paper, we focus on the AP Engine and ROS2 components. The process begins with a user searching for a book through the web dashboard. The system retrieves the bookâs location among the shelves and generates a text file containing the corresponding coordinates. This file contains thegoal, and is broadcasted to all AP nodes running on the available robots, either simulated or real. TheAP Engineis a layer built on top of the FCPP library, implementing the algorithm described in Section 4, and interfacing with the other system components. The AP nodes communicate to determine the most suitable robot for the task. Once a decision is made, the AP engine generates another text file, containing the assignedactionto the selected robot. The ROS2-basedRobot Writer component interprets the received command and forwards it to theNavigation Systemvia ROS2 topics. This component invokes the APIs of the third-partyNAV2library, which directly interfaces with both the real and simulated robots (also through ROS2) to ensure proper movement toward the shelf coordinates. TheNavigation Systemis responsible for handling motion planning and executing potential re-planning when necessary. Simultaneously, theRobot Readercomponent continuously monitors telemetry data and navigation status through ROS2 topics. Thesefeedbackfiles, containing information about localization, status of the task, status of the system, percentage of battery charge, are sent back to theAP engine, allowing it to detect failures and, if needed, reassign the task to another robot. 4 AP Algorithm The computational problem that we solve with AP is an instance of Multi-Robot Task Assignment (MRTA), a well known problem that has been widely studied in the literature [17, 21]. More specifi- cally, according to the taxonomy defined in [21], we address aST-SR-IAvariant of MRTA, meaning that robots can execute only asingle taskat a time (ST), that each task can be executed by asingle robot(SR), 50AP in a Multi-robot Prototype and that robots get their current task by animmediate assignment(IA), instead of a storing a queue of assigned tasks to be executed later. While the basicST-SR-IAvariant can be solved with many existing cooperative (distributed) MRTA algorithms, our proposed solution poses further important requirements that make the adoption of AP compelling: (i)on-line tasks arrival: several cooperative assignments should be handled concurrently by the team of robots; (i)proximity-based communication: there should be no need for a centralized communication infrastructure, and the peer-to-peer (P2P) communication may requiremultiple hopsto connect each pair of robots; (i)adaptivity to failures: the task assignment should be robust against failures of robots, communication failures, network splits into disconnected sub-networks; (iv)adaptivity to opportunities: a robotR i may opportunistically preempt a taskT j cur- rently executed by another robotR k if reassigningT j toR i is significantly more efficient than the current allocation. For solving the basicST-SR-IAvariant of MRTA, we have adopted aconsensus-basedap- proach [24], where each (idle) robotR i has a scorer i,j for executing taskT j , and the team agrees to assignT j to the robot with the highest score. Requirement (i) described above is addressed by spawning an aggregate process for each arriving taskT j , so that they can be processed concurrently. Note that, as an alternative to using aggregate processes, we may have each robot explicitly storing and handling a local list of currently active tasks. However, aggregate processes are significantly more convenient, since they transparently ensure that communications about each task assignment are aligned between devices (Section 2), and handle process propagation and termination. Requirement (i) applies to all AP algo- rithms, given the system model underlying XC, see Figure 1 (left). The other two requirements (i),(iv) are mostly addressed by implementing the collective consensus among robots by exploiting one of the leader election operators offered by FCPP. Specifically, we consider the variant diameter_election(value, diameter) which returns the minimumvalueamong all the devices, given an upper bound to the network diameter (i.e., maximum number of hops between any pair of devices). Since there is eventual consensus about such a minimum, the node holding it can be elected as theleader. 3 A fundamental feature of such op- erator for supporting adaptivity, is that it isself-stabilizing(Section 2). Specifically, if the current leader disappears (e.g., due to a severe failure), or another node becomes preferred for the leadership (e.g., be- cause the current leader is consuming more energy than normally expected), the operator automatically adapts its output to the changed inputs within a certain delay [25]. Figure 3 shows the pseudo-code of the program executed in each robotR i , in each round of com- putation according to the AP paradigm. Lines 1-4 are the main program, which handles the arrival of a new taskT j to robotR i by spawning a newAggregate Processfor it (withT j as the key of the new process), while also continuing to execute the processes thatR i was already executing. We donât specify how a new taskT j is sent to robots from the kiosk where the students ask for help, just assuming that it can reach at least one of the robots in the team. Note that, if more than one robot concurrently creates a new aggregate process forT j , the corresponding collective computations spawned over the network will automatically merge into a single collective computation, since they all share the same keyT j . The be- havior of the process is specified in procedure TASKPROCESSING, which receives the key of the process as its only argument. First of all, a scorer i,j is computed, measuring the quality of assigningT j toR i , e.g.,r i,j should be higher for a robot closer toT j ,ceteris paribus(in Section 5 weâl define a specific formula). Scorer i,j is then combined into apair(âr i,j ,R i )with the idR i of the robot, and used as the valuepassed to the collective LEADERELECTIONfunction that returns the minimum value among all connected robots in the network with diameter bounded byδ(see previous section). Scores and the 3 In the context of task assignment, thevalueargument should be set to the opposite of thescore r i,j for assigningT j to R i , since lower values are preferred. G. Audrito et al.51 1:ifnew taskT j arrived to robotR i then 2:AddT j to the set of processes to execute 3:end if 4:Execute TASKPROCESSING(T k ) for each process active in robotR i 5:procedureTASKPROCESSING(T j ) 6:R i computes scorer i,j forT j 7:compute(r best ,id best )with LEADERELECTION((âr i,j ,R i ),δ) 8:ifR i is leader forθconsecutive roundsthen 9:if(T j is unassigned)or(r best improves the score by at leastĎ%)then 10:T j is assigned toR i , which becomes busy 11:R i runs EXECUTETASK(T j ) and sets its scoresr i,k forT k ̸=T j toââ 12:end if 13:else if(R i is executingT j but another robot is new leader)then 14:R i becomes idle and stops executingT j , restoring its scores forT k ̸=T j 15:end if 16:ifR i fails executingT j then 17:the scorer i,j ofR i forT j becomes constantââ 18:else ifR i correctly finishes executingT j then 19:R i becomes free and initiates termination of processT j 20:end if 21:ifT j is assigned to bothR i andR k then 22:R i andR k solve the conflict, so thatT j is assigned to eitherR i orR k 23:end if 24:end procedure Figure 3: Distributed Task Assignment with AP. Parametersδ,θ, andĎdefine, respectively, the upper bound on network diameter, the stabilization time for election, and the improvement for re-assignment. network topology can change, due to robots moving, breaking, etc. but we assume that at some point the election process is stable enough, so that the idid best of the leader is the same forθconsecutive rounds of execution. If the local robotR i is the potential leader, it becomes so if eitherT j is currently unassigned, or the assignment toR j improves the score by at leastĎ%. In such a case, we letR i to be (at least temporarily) assigned taskT j , and starting its execution (lines 10-13), by calling EXECUTETASK. Note thatR i becomes unavailable for other pending tasksT k , with an infinitely low score. If, on the other hand, the local robotR i is executingT j but a better leader is elected,R i stops executingT j and becomes available for other tasks (lines 13-15). Lines 16-20 are dedicated to task termination and error handling. Finally (lines 21-23), although LEADERELECTIONensures that all the connected robots eventually reach a consensus on the leader, it can happen that two or more robots are assigned the same task when the network of robots becomes (temporarily) disconnected. When this is detected (because, e.g., the two elected robots get close enough to each other and restore network connection), theconflictis explicitly resolved by assigningT j to the robot with higher score for it. 52AP in a Multi-robot Prototype Figure 4: Library world simulated with Gazebo. 5 Validation 5.1 Simulation Scenario.The simulated environment is a near-identical replica of a portion of the [removed for double-blind review], as shown in Figure 4. In this scenario we used five differential wheeled robots, each equipped with a 360° 2D LIDAR to verify the feasibility of our solution. Gazebo, FCPP, and ROS2 Configuration.Simulation used Gazebo Classic for the physical simula- tion. Using SDF we defined the library world with relaxed physical constraints to increase the number of simulated robots. To that end we also defined a simplified version of the real robot with simpler geometry and a lower resolution LIDAR. With these tweaks we were able to simulate up to ten robots each with its own navigation stack up and running. The FCPP configuration replicates the real setting in the library, where the FCPP component is configured to operate within a defined area of 3.5mĂ6.0m. Central to the configuration is the cost function, defined as: score=distĂ(1.0âpercent_charge) This function effectively combines the distance to the target with the battery charge level, preferring robots that are both close to the target, and well-powered. The simulation uses thelazy(non-preemptive) version of the algorithm, as described in Section 4. Separately, all user-submitted goals are assigned the same priority, ensuring fair handling during task allocation. Moreover, the upper boundδon the diameter of the network (needed by functiondiameter_election, see Section 4) is not statically defined; instead, it is dynamically computed based on the current configuration of the network, in such a way that it is not (too much) larger than the true diameter. Since we worked into a multi-robot scenario, we had to use ROS2namespacesto avoid name colli- sions in the communication system. Two topics that required particular attention for remapping weretf andtf_static. In order to integrate with the Aggregate Programming component, the RobotWriter node was in charge of parsing comma-separated values files (CSV) and send the information as a ROS2 mes- sage toward the navigation stack. To produce feedback outside of ROS2, the RobotReader node was in charge of reading information, such as robotâs current pose, goal status, battery level, etc., and produce a CSV file to be fed to the AP Engine. G. Audrito et al.53 Figure 5: Network partition between robots (left): groups 1,2,3 and 4,5 (we show both the FCPP simulator, and the Gazebo simulator). Solving the network partition problem (right). Test Cases(the code for simulations can be found at the URL given in Section 1) Beyond the default test case, the system supports several variants that enhance its resilience and fault-tolerance by fully lever- aging Aggregate Programming. These behaviors are achieved without explicit reprogramming; instead, they rely on the coordination mechanisms provided by the FCPP library, as explained above in Section 4. For instance, in the simulation a ROS2 service call can instantly drain a robotâs battery, prompting the system to detect the change and reassign the task to an available robot. Moreover, the Aggregate Pro- gramming paradigm ensures resilience to network partitioning in multi-robot systems. To test this use case, the communication range configuration was reduced from 5m to 3m. A network partition occurs whenR.4moves toward a shelf to execute a task, Figure 5 (left). This movement causesR.4andR.5 to become isolated from the rest of the group, as shown by the loss of edges (links between robots are represented as edges between circles). Despite this, tasks can still be initiated independently within each partition. Once communication is restored, the system detects conflicting task executions, and promptly halts robotR.3, marked in red, ensuring consistent operation across the entire network, Figure 5 (right). 5.2 Physical Prototype Equipment.For the experimentation we used the iRobot Create3 [19] platform as the base robot ex- tended it with a FHL-LD19P Lidar and a on board MiniPC computer with 8GB of RAM and a Intel Gemini Lake N4000 processor. Power to the computer is provided by the Create3âs adapter board, communication between the robot and the computer is ensured by a Ethernet cable to reduce latency. Communication between computers for this prototype was realized using a WiFi 6 router. Another pos- sible solution, closer to the peer-to-peer communication required by AP, would have been to directly setup a WiFi mesh network between the AP nodes. While we were not able to implement it for our tests, this would have just required the definition of a new network driver class for FCPP. ROS2 and FCPP configuration.We choseCycloneDDSas the communication middleware, rather than Humbleâs default DDS (Data Distribution System), called FastRTPS, because we needed a more configurable system on the network side. Doing so, we set every robot to communicate only with itâs own computer on board and for every unit, composed by the robot and the added mini-computer, we set a 54AP in a Multi-robot Prototype Figure 6: Multiple robots in action. unique ROS domain ID. A single ROS domain ID is reserved for registering feedback from all the robots, and communication between the robots is handled using APâs communication scheme. This setup was necessary because discovery between nodes on the network would overflow the Create3 RAM, causing the robots to continuously restart. The physical experimentation replicated the configuration used in the FCPP simulator, adapting the communication layer to operate in a real-world network of robots. Com- munication between nodes was handled by a custom UDP-based driver that broadcasts messages in a non-blocking manner over the local wireless network. The driver implements the transceiver interface, and each packet includes the senderâs unique identifier, a counter for sequential messages, and the mes- sage payload. Each Aggregate Programming (AP) node (hosted on its associated robot) operated with a round interval of 0.2 seconds, and messages were retained in the AP context for up to 2 seconds to ensure robust inter-robot communication. Moreover, each AP node was assigned a unique ID, configured as a parameter on initialization. Test Cases.The same test cases executed in the simulation were also validated on the physical proto- type to ensure the system robustness in real-world conditions (Figure 6 shows the real-world deployment using two Create3 robots). We have implemented a failure notification mechanism that informs other robots whenever a given task cannot be completed due to specific conditions. Examples of such con- ditions include failures in the navigation stack, the robot being lifted from the ground, critical battery levels, and battery overheating. 6 Conclusions and Future Work In this work, we have applied AP to solve a multi-robot coordination problem, with satisfactory results. First, thanks to the asynchronous, round-based execution of AP, it has been easy to integrate the deci- sion module within the overall architecture including the robot controllers and feedback loops. Second, the features offered by AP have simplified the programming of a quite complex problem, involving the distributed assignment of tasks to robots, dynamic arrival of new tasks, and asynchronous termination/- failures of actual execution by the robots. Last, the self-stabilizing nature and resilience to changes of AP operators, has made it possible to deal naturally with several dynamic/failure scenarios. We have already started working on more complex use cases, e.g., involving the coverage and patrolling of real environments with teams of robots. Such scenarios require robots with a more sophisticated collective intelligence, and more hardware (e.g., cameras, outdoor navigation), and processing capabilities (e.g., computer vision). Integrating AP with them is another challenge of our ongoing research. G. Audrito et al.55 References [1] Gianluca Aguzzi, Lorenzo Bacchini, Martina Baiardi, Roberto Casadei, Angela Cortecchia, Davide Do- mini, Nicolas Farabegoli, Danilo Pianini & Mirko Viroli (2025):A Demonstrator for Self-organizing Robot Teams. In Cinzia Di Giusto & AntĂłnio Ravara, editors:Coordination Models and Languages, Springer Nature Switzerland, Cham, p. 230â244. [2] Giorgio Audrito (2020):FCPP: an efficient and extensible Field Calculus framework.In:Interna- tional Conference on Autonomic Computing and Self-Organizing Systems (ACSOS), IEEE, p. 153â159, doi:10.1109/ACSOS49614.2020.00037. [3] Giorgio Audrito, Gianluca Aguzzi, Roberto Casadei, Ferruccio Damiani, Gianluca Torta & Mirko Viroli (2023):Swarm Intell.17, p. 27â62, doi:10.1007/s11721-022-00215-y. [4] Giorgio Audrito, Roberto Casadei, Ferruccio Damiani, Guido Salvaneschi & Mirko Viroli (2022):Functional Programming for Distributed Systems with XC. In Karim Ali & Jan Vitek, editors:36th European Conference on Object-Oriented Programming, ECOOP 2022, June 6-10, 2022, Berlin, Germany,LIPIcs222, Schloss Dagstuhl - Leibniz-Zentrum fĂźr Informatik, p. 20:1â20:28, doi:10.4230/LIPICS.ECOOP.2022.20. [5] Giorgio Audrito, Roberto Casadei, Ferruccio Damiani, Guido Salvaneschi & Mirko Viroli (2024):The eX- change Calculus (XC): A functional programming language design for distributed collective systems.J. Syst. Softw.210, p. 111976, doi:10.1016/J.JSS.2024.111976. [6] Giorgio Audrito, Roberto Casadei & Gianluca Torta (2024):A general framework and decentralised algorithms for collective computational processes.Future Gener. Comput. Syst.158, p. 11â27, doi:10.1016/J.FUTURE.2024.04.020. [7] Giorgio Audrito, Ferruccio Damiani & Gianluca Torta (2022):Bringing Aggregate Programming Towards the Cloud. In Tiziana Margaria & Bernhard Steffen, editors:Leveraging Applications of Formal Methods, Verification and Validation. Adaptation and Learning - 11th International Symposium, ISoLA 2022, Rhodes, Greece, October 22-30, 2022, Proceedings, Part I,Lecture Notes in Computer Science13703, Springer, p. 301â317, doi:10.1007/978-3-031-19759-8_19. [8] Giorgio Audrito, Luigi Rapetta & Gianluca Torta (2022):Extensible 3D Simulation of Aggregated Systems with FCPP. In Maurice H. ter Beek & Marjan Sirjani, editors:Coordination Models and Languages - 24th IFIP WG 6.1 International Conference, COORDINATION 2022, Held as Part of the 17th International Federated Conference on Distributed Computing Techniques, DisCoTec 2022, Lucca, Italy, June 13-17, 2022, Proceedings,Lecture Notes in Computer Science13271, Springer, p. 55â71, doi:10.1007/978-3-031-08143- 9_4. [9] Giorgio Audrito & Gianluca Torta (2024):FCPP to aggregate them all.Sci. Comput. Program.231, p. 103026, doi:10.1016/J.SCICO.2023.103026. [10] Jacob Beal, Stefan Dulman, Kyle Usbeck, Mirko Viroli & Nikolaus Correll (2013):Organizing the Aggre- gate: Languages for Spatial Computing. In:Formal and Practical Aspects of Domain-Specific Languages: Recent Developments, chapter 16, IGI Global, p. 436â501, doi:10.4018/978-1-4666-2092-6.ch016. [11] Jacob Beal, Danilo Pianini & Mirko Viroli (2015):Aggregate Programming for the Internet of Things.IEEE Computer48(9), p. 22â30, doi:10.1109/MC.2015.261. [12] Patrick Benavidez, Mohan Kumar, Sos Agaian & Mo Jamshidi (2015):Design of a home multi-robot system for the elderly and disabled. In:2015 10th System of Systems Engineering Conference (SoSE), p. 392â397, doi:10.1109/SYSOSE.2015.7151907. [13] Roberto Casadei, Gianluca Aguzzi, Danilo Pianini & Mirko Viroli (2023):Programming (and Learn- ing) Self-Adaptive & Self-Organising Behaviour with ScaFi: for Swarms, Edge-Cloud Ecosystems, and More. In:IEEE International Conference on Autonomic Computing and Self-Organizing Systems, ACSOS 2023 - Companion, Toronto, ON, Canada, September 25-29, 2023, IEEE, p. 33â34, doi:10.1109/ACSOS- C58168.2023.00032. 56AP in a Multi-robot Prototype [14] Roberto Casadei & Mirko Viroli (2016):Towards Aggregate Programming in Scala. In:First Work- shop on Programming Models and Languages for Distributed Computing, PMLDC â16, ACM, p. 5:1â5:7, doi:10.1145/2957319.2957372. [15] Roberto Casadei, Mirko Viroli, Gianluca Aguzzi & Danilo Pianini (2022):ScaFi: A Scala DSL and Toolkit for Aggregate Programming.SoftwareX20, p. 101248, doi:10.1016/J.SOFTX.2022.101248. [16] Roberto Casadei, Mirko Viroli, Giorgio Audrito, Danilo Pianini & Ferruccio Damiani (2021):Engineering collective intelligence at the edge with aggregate processes.Eng. Appl. Artif. Intell.97, p. 104081. [17] Hamza Chakraa, François GuĂŠrin, Edouard Leclercq & Dimitri Lefebvre (2023):Optimization techniques for Multi-Robot Task Allocation problems: Review on the state-of-the-art.Robotics and Autonomous Systems 168, p. 104492, doi:10.1016/j.robot.2023.104492. [18] Florian Cordes, Ingo Ahrns, Sebastian Bartsch, Timo Birnschein, Alexander Dettmann, StĂŠphane Estable, Stefan Haase, Jens Hilljegerdes, David Koebel, Steffen Planthaber et al. (2011):LUNARES: Lunar crater exploration with heterogeneous multi robot systems.Intelligent Service Robotics4, p. 61â89. [19] iRobot Corporation (2021):Create 3 Educational Robot.https://iroboteducation.github.io/ create3_docs/. [20] Alessandro Di Nuovo, Frank Broz, Ning Wang, Tony Belpaeme, Angelo Cangelosi, Ray Jones, Raffaele Esposito, Filippo Cavallo & Paolo Dario (2018):The multi-modal interface of Robot-Era multi-robot services tailored for the elderly.Intelligent Service Robotics11, p. 109â126. [21] Brian P. Gerkey & Maja J. Matari Ě c (2004):A Formal Analysis and Taxonomy of Task Alloca- tion in Multi-Robot Systems.The International Journal of Robotics Research23(9), p. 939â954, doi:10.1177/0278364904045564. [22] Lydia Habib, Marie-Pierre Pacaux-Lemoine & Patrick Millot (2018):Human-Robots Team Cooperation in Crisis Management Mission. In:2018 IEEE International Conference on Systems, Man, and Cybernetics (SMC), p. 3219â3224, doi:10.1109/SMC.2018.00545. [23] Leslie Lamport (1978):Time, Clocks, and the Ordering of Events in a Distributed System.Commun. ACM 21(7), p. 558â565. [24] Prabhat Mahato, Sudipta Saha, Chayan Sarkar & Md. Shaghil (2023):Consensus-based fast and energy-efficient multi-robot task allocation.Robotics and Autonomous Systems159, p. 104270, doi:10.1016/j.robot.2022.104270. [25] Yuanqiu Mo, Giorgio Audrito, Soura Dasgupta & Jacob Beal (2022):Near-optimal knowledge-free resilient leader election.Automatica146, p. 110583, doi:10.1016/j.automatica.2022.110583. Available athttps: //w.sciencedirect.com/science/article/pii/S0005109822004459. [26] Linh Cuong Nguyen (2020):The impact of humanoid robots on Australian public libraries.Journal of the Australian Library and Information Association69(2), p. 130â148. [27] Max Pascher, Annalies Baumeister, Barbara Klein, Stefan Schneegass & Jens Gerken (2019):Little helper: a multi-robot system in home health care environments. In:1st International Workshop on Human-Drone Interaction. [28] Danilo Pianini et al. (2024):Collektive.https://collektive.github.io/. [29] David Portugal & Rui P. Rocha (2013):Scalable, fault-tolerant and distributed multi-robot patrol in real world environments. In:2013 IEEE/RSJ International Conference on Intelligent Robots and Systems, p. 4759â4764, doi:10.1109/IROS.2013.6697042. [30] Jorge PeĂąa Queralta, Jussi Taipalmaa, Bilge Can Pullinen, Victor Kathan Sarker, Tuan Nguyen Gia, Hannu Tenhunen, Moncef Gabbouj, Jenni Raitoharju & Tomi Westerlund (2020):Collaborative Multi-Robot Search and Rescue: Planning, Coordination, Perception, and Active Vision.IEEE Access8, p. 191617â191643, doi:10.1109/ACCESS.2020.3030190. G. Audrito et al.57 [31] Pradeep Ranganathan, Ryan Morton, Andrew Richardson, Johannes Strom, Robert Goeddel, Mihai Bulic & Edwin Olson (2010):Coordinating a team of robots for urban reconnaisance. In:Proceedings of the land warfare conference (LWC). [32] Adeyinka Tella & Yusuf Ayodeji Ajani (2022):Robots and public libraries.Library Hi Tech News39(7), p. 15â18. [33] Mirko Viroli, Giorgio Audrito, Jacob Beal, Ferruccio Damiani & Danilo Pianini (2018):Engineering Re- silient Collective Adaptive Systems by Self-Stabilisation.ACM Trans. Model. Comput. Simul.28(2), p. 1â16. [34] Mirko Viroli, Jacob Beal, Ferruccio Damiani, Giorgio Audrito, Roberto Casadei & Danilo Pianini (2018): From Field-Based Coordination to Aggregate Computing. In:Coordination Models and Languages (CO- ORDINATION),Lecture Notes in Computer Science10852, Springer, p. 252â279, doi:10.1007/978-3-319- 92408-3_12. [35] Mirko Viroli, Jacob Beal, Ferruccio Damiani, Giorgio Audrito, Roberto Casadei & Danilo Pianini (2019): From distributed coordination to field calculus and aggregate computing.J. Log. Algebraic Methods Pro- gram.109, doi:10.1016/j.jlamp.2019.100486.