Exploiting Aggregate Programming in a Multi-Robot Service Prototype Giorgio Audrito
Andrea Basso
Università di Torino, Turin, Italy
MITO Technology, Milan, Italy
Daniele Bortoluzzi
Ferruccio Damiani
Giordano Scarso
Gianluca 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 implementation 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 composition. 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 named exchange). 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 programming 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. Lorenzo Gheri & Kirstin Peters (Eds.): 17th International Workshop on Programming Language Approaches to Concurrency and Communication-cEntric Software 2026 (PLACES 2026) EPTCS 444, 2026, pp. 45–57, doi:10.4204/EPTCS.444.5
This work is licensed under the Creative Commons Attribution License.
46
AP 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; (ii) 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; (iii) 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 describe 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 Assignment (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 proposed eXchange Calculus (XC) [4, 5], implemented by both the Field Calculus++ (FCPP) C++ library [2, 8, 9], that will be exploited in this paper, and the Scala 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 of rounds. 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 of event structure [23], which is a finite set of events E along with an acyclic neighbouring relation ⇝⊆ E × E modelling message passing. An event corresponds to a round of activation of 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 by neighbouring values w, which represent (sets of) local literals either received from or sent to neighbouring devices. These values are defined as maps w = ℓ[δ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 a default, e.g., for neighbours that are unknown to the device, but 1 The code for the simulations is publicly available at https://github.com/fcpp-experiments/ ros2-library-project.
G. Audrito et al.
47
Applications
perception
device
5
4
3
C
behavior
action
G
T
Coordination Operators
ǫ builtins
2
1
sensors
actuators
time
spawn
Exchange Calculus
communication
Device Capabilities
exchange
state
Developer APIs
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 operation nfold(f,w,l), which applies a specified binary operation f repeatedly to the local values that form w, except for the current device δ , whose value is taken from the l argument. In XC, evaluation is performed within a context that includes all messages received from neighboring devices. A technique known as alignment ensures 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 called exchange, which models communication with neighbours. The expression: exchange (e0 , (x) => return er send es ) is evaluated according to the following steps. • First, gather a neighbouring value w that maps each neighbor δ ′ to the last value shared by δ ′ for this exchange expression. • If it is the first execution of exchange on the current device δ , the value of e0 is used as the value for δ in w. Otherwise, the value shared by δ itself in its previous round is used instead. • Next, evaluate er by substituting w for x, resulting in a value vr . Do the same for es obtaining value vs . • Finally, return vr as the value of the exchange expression in the program, and broadcast vs to neighbors, who will use it in their subsequent rounds to produce their neighboring value w. Consider, as an example, the following function declaration: def dist(source) { exchange(infinity, (d) => retsend mux(source, 0, nfold(min, d, infinity)+1))}
48
AP in a Multi-robot Prototype
In the function declaration above, we use retsend e as syntactic sugar for return e send e. Function mux(b,x,y) is the multiplexer function returning either x or y depending on whether b is true or false, respectively. The dist function calculates hop-count distances from the nearest device where source is true, using a single exchange construct. 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 understanding a modified version of the dist function described above, where different parallel computations are spawned by different source devices.2 def multi_dist(isSource, theta) { val gen_set = if (isSource) {set(uid())} else {set()}; spawn((i) => { val output = dist(uid() == i); val status = output <= theta; (output, status) }, gen_set); }
Function multi_dist spawns a new distance computation process in devices where isSource is true, limiting the computation to devices within theta hops from the source. Variable gen_set is a set with the ID of the current device if it is a source, an empty set otherwise. The spawn receives gen_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) the output is the value of the dist function above, computed w.r.t. one source, namely the device that has spawned the process; (ii) the status is true (i.e., active) for devices within theta hops from the source, false (i.e. terminated) for other devices. The AP engineering approach goes beyond the features directly built into XC, by defining the Engineering Stack shown in Figure 1 (right). The first two layers denote the physical Device Capabilities, and the Exchange Calculus constructs, that provide the first abstraction over such capabilities. The third layer defines a number of Coordination Operators that play a crucial role both in hiding the complexity 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: G is a highly general information spreading and outward computation operation; C is its inverse, a general information collection operation; and T implements bounded state evolution and short-term memory. Finally, the top two layers are devoted, respectively, to Developer APIs for particular domains, and to Applications.
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, spawn does not take the additional argument for the process function.
G. Audrito et al.
49
Send new goal [Text file]
AP Engine [Container: FCPP, C++]
Write actions to robot in [Text file]
Robot Writer [Container: ROS2 Node, Python]
Send actions to robot using [ROS2 Topic]
Navigation System [Container: ROS2 Node, Python]
Send low level commands to robot using [ROS2 actions and topics]
Abort a goal [Text file] Read feedback from robots using [ROS2 topics]
Send robots feedback with [Text file]
Read feedback robots using [ROS2 topics]
Robot Reader [Container: ROS2 Node, Python] Receive feedback from robot using [ROS2 topics]
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; (ii) The system processes the query and retrieves the book’s location on the shelves; (iii) 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. The system 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 ROS2based 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 the goal, and is broadcasted to all AP nodes running on the available robots, either simulated or real. The AP Engine is 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 assigned action to the selected robot. The ROS2-based Robot Writer component interprets the received command and forwards it to the Navigation System via ROS2 topics. This component invokes the APIs of the third-party NAV2 library, which directly interfaces with both the real and simulated robots (also through ROS2) to ensure proper movement toward the shelf coordinates. The Navigation System is responsible for handling motion planning and executing potential re-planning when necessary. Simultaneously, the Robot Reader component continuously monitors telemetry data and navigation status through ROS2 topics. These feedback files, containing information about localization, status of the task, status of the system, percentage of battery charge, are sent back to the AP 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 specifically, according to the taxonomy defined in [21], we address a ST-SR-IA variant of MRTA, meaning that robots can execute only a single task at a time (ST), that each task can be executed by a single robot (SR),
50
AP in a Multi-robot Prototype
and that robots get their current task by an immediate assignment (IA), instead of a storing a queue of assigned tasks to be executed later. While the basic ST-SR-IA variant 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; (ii) proximity-based communication: there should be no need for a centralized communication infrastructure, and the peer-to-peer (P2P) communication may require multiple hops to connect each pair of robots; (iii) 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 robot Ri may opportunistically preempt a task T j currently executed by another robot Rk if reassigning T j to Ri is significantly more efficient than the current allocation. For solving the basic ST-SR-IA variant of MRTA, we have adopted a consensus-based approach [24], where each (idle) robot Ri has a score ri, j for executing task T j , and the team agrees to assign T j to the robot with the highest score. Requirement (i) described above is addressed by spawning an aggregate process for each arriving task T 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 (ii) applies to all AP algorithms, given the system model underlying XC, see Figure 1 (left). The other two requirements (iii),(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 minimum value among 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 the leader.3 A fundamental feature of such operator for supporting adaptivity, is that it is self-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., because 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 robot Ri , in each round of computation according to the AP paradigm. Lines 1-4 are the main program, which handles the arrival of a new task T j to robot Ri by spawning a new Aggregate Process for it (with T j as the key of the new process), while also continuing to execute the processes that Ri was already executing. We don’t specify how a new task T 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 for T j , the corresponding collective computations spawned over the network will automatically merge into a single collective computation, since they all share the same key T j . The behavior of the process is specified in procedure TASK P ROCESSING, which receives the key of the process as its only argument. First of all, a score ri, j is computed, measuring the quality of assigning T j to Ri , e.g., ri, j should be higher for a robot closer to T j , ceteris paribus (in Section 5 we’ll define a specific formula). Score ri, j is then combined into a pair (−ri, j , Ri ) with the id Ri of the robot, and used as the value passed to the collective L EADER E LECTION function 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, the value argument should be set to the opposite of the score r for assigning T to i, j j Ri , since lower values are preferred.
G. Audrito et al.
51
1: if new task T j arrived to robot Ri then
Add T j to the set of processes to execute 3: end if 4: Execute TASK P ROCESSING (Tk ) for each process active in robot Ri 2:
5: procedure TASK P ROCESSING (T j )
Ri computes score ri, j for T j 7: compute (rbest , idbest ) with L EADER E LECTION((−ri, j , Ri ), δ ) 8: if Ri is leader for θ consecutive rounds then 9: if (T j is unassigned) or (rbest improves the score by at least ω%) then 10: T j is assigned to Ri , which becomes busy 11: Ri runs E XECUTE TASK(T j ) and sets its scores ri,k for Tk ̸= T j to −∞ 12: end if 13: else if (Ri is executing T j but another robot is new leader) then 14: Ri becomes idle and stops executing T j , restoring its scores for Tk ̸= T j 15: end if 16: if Ri fails executing T j then 17: the score ri, j of Ri for T j becomes constant −∞ 18: else if Ri correctly finishes executing T j then 19: Ri becomes free and initiates termination of process T j 20: end if 21: if T j is assigned to both Ri and Rk then 22: Ri and Rk solve the conflict, so that T j is assigned to either Ri or Rk 23: end if 24: end procedure 6:
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 id idbest of the leader is the same for θ consecutive rounds of execution. If the local robot Ri is the potential leader, it becomes so if either T j is currently unassigned, or the assignment to R j improves the score by at least ω%. In such a case, we let Ri to be (at least temporarily) assigned task T j , and starting its execution (lines 10-13), by calling E XECUTE TASK. Note that Ri becomes unavailable for other pending tasks Tk , with an infinitely low score. If, on the other hand, the local robot Ri is executing T j but a better leader is elected, Ri stops executing T 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 L EADER E LECTION ensures 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), the conflict is explicitly resolved by assigning T j to the robot with higher score for it.
52
AP 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 simulation. 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.5 m × 6.0 m. 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 the lazy (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 function diameter_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 ROS2 namespaces to avoid name collisions in the communication system. Two topics that required particular attention for remapping were tf and tf_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 message 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 leveraging 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 Programming 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 when R.4 moves toward a shelf to execute a task, Figure 5 (left). This movement causes R.4 and R.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 robot R.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 extended 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 possible 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 chose CycloneDDS as 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
54
AP 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. Communication 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 message 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 prototype 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 conditions 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 decision 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 Domini, 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, pp. 230–244. [2] Giorgio Audrito (2020): FCPP: an efficient and extensible Field Calculus framework. In: International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS), IEEE, pp. 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, LIPIcs 222, Schloss Dagstuhl - Leibniz-Zentrum für Informatik, pp. 20:1–20:28, doi:10.4230/LIPICS.ECOOP.2022.20. [5] Giorgio Audrito, Roberto Casadei, Ferruccio Damiani, Guido Salvaneschi & Mirko Viroli (2024): The eXchange 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, pp. 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 III, Lecture Notes in Computer Science 13703, Springer, pp. 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 Science 13271, Springer, pp. 55–71, doi:10.1007/978-3-031-081439_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 Aggregate: Languages for Spatial Computing. In: Formal and Practical Aspects of Domain-Specific Languages: Recent Developments, chapter 16, IGI Global, pp. 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 Computer 48(9), pp. 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), pp. 392–397, doi:10.1109/SYSOSE.2015.7151907. [13] Roberto Casadei, Gianluca Aguzzi, Danilo Pianini & Mirko Viroli (2023): Programming (and Learning) 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, pp. 33–34, doi:10.1109/ACSOSC58168.2023.00032.
56
AP in a Multi-robot Prototype
[14] Roberto Casadei & Mirko Viroli (2016): Towards Aggregate Programming in Scala. In: First Workshop on Programming Models and Languages for Distributed Computing, PMLDC ’16, ACM, pp. 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. SoftwareX 20, 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 Robotics 4, pp. 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 Robotics 11, pp. 109–126. [21] Brian P. Gerkey & Maja J. Matarić (2004): A Formal Analysis and Taxonomy of Task Allocation in Multi-Robot Systems. The International Journal of Robotics Research 23(9), pp. 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), pp. 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), pp. 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 Systems 159, 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. Automatica 146, p. 110583, doi:10.1016/j.automatica.2022.110583. Available at https: //www.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 Association 69(2), pp. 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, pp. 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 Access 8, pp. 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 News 39(7), pp. 15–18. [33] Mirko Viroli, Giorgio Audrito, Jacob Beal, Ferruccio Damiani & Danilo Pianini (2018): Engineering Resilient Collective Adaptive Systems by Self-Stabilisation. ACM Trans. Model. Comput. Simul. 28(2), pp. 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 (COORDINATION), Lecture Notes in Computer Science 10852, Springer, pp. 252–279, doi:10.1007/978-3-31992408-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 Program. 109, doi:10.1016/j.jlamp.2019.100486.