🔝​

Swarm Robotics Practice - Modular Design

• Swarm Robotics Practice - Modular Design
  • Prerequisites
  • General Motivation
  • Course Content
    • Getting started
      • 1. Download the laboratory package (All operating systems)
      • 2. Installation instructions by operating system
        • Step 1 — Install Docker Desktop
        • Step 2 — Start the laboratory for the first time
        • Step 3 — Open the Ubuntu desktop
        • Step 4 — Running experiments
        • Daily usage after the first execution
        • Troubleshooting
        • Step 1 — Install Docker
        • Step 2 — Enable Docker permissions
        • Step 3 — Verify the installation
        • Step 4 — Start the laboratory
        • Step 5 — Open the Ubuntu desktop
        • Step 6 — Running experiments
        • Daily usage
        • Troubleshooting
    • Introduction
    • Running the software
    • Designing modular control software for robot swarms
      • Low-level behaviors
      • Transition conditions
    • Experimental scenarios
      • Sub-missions
        • Sub-mission 1 ($\mathbf{S1}$)
        • Sub-mission 2 ($\mathbf{S2}$)
        • Sub-mission 3 ($\mathbf{S3}$)
        • Sub-mission 4 ($\mathbf{S4}$)
        • Sub-mission 5 ($\mathbf{S5}$)
        • Sub-mission 6 ($\mathbf{S6}$)
      • Single-criteria missions
      • Multi-criteria missions
    • To be considered
  • Contact
  • Credits

Prerequisites

To get the most out of this Swarm Robotics module, it’s helpful to have prior knowdlege on basic mobile robotic systems and to have followed the prior content on Swarm Robotics and the Practical Session on programming collective behaviors.

This session requires you to assemble modular control software, therefore, basic programming skills are recommended. The practical session also requires you to manually tune the parameters of the software, for which basic understanding of optimization processes is useful but not mandatory.

The tools required to develop the excercises are introduced in the material: Docker environments and the ARGoS simulator.

General Motivation

Many of the collective behaviors explored in swarm robotics share common behavioral components. For example, robots may explore the environment by performing random walks, either because they aim to find their peers and aggregate in a single cluster, or because they are looking for regions of interst from which to forage. In this example, a similar building block for a exploration behavior can be used to compose different collective behaviors: aggregation or foraging.

In the previous practical session, these behaviors were programmed manually with the goal of observing whether a given collective behavior would emerge when the robots followed certain rules. In this session, the problem is taken a step further. Instead of programming the robots directly, you are given a number of behavioral components that can be combined and tuned to produce control software for a variety of swarm robotics problems.

This introduces you to the use of optimization-based processes for designing collective behaviors in robot swarms. Given a performance metric that describes a swarm mission, the goal is to find suitable control software for the robots that improves their performance. The challenge is not to observe a desired behavior, but rather to optimize the performance of the swarm.

This enginnering approach to swarm robotics focuses in designing good performing systems, and not much on the specifics of the behavior obtained. After experimenting with this manual optimization-based process, you will be ready to set up your own architectures and implement your own tuning methods (for example, those based on heuristic optimization and reinforcement learning).

Course Content

Getting started

1. Download the laboratory package (All operating systems)

You will need approximately 8 GB of free disk space.

Download the laboratory package from the following link:

https://drive.google.com/file/d/1xqCiMZPd4pzFfCFxcel8zky25Dd0uPOl/view?usp=drive_link

After downloading:

1. Extract the compressed file anywhere on your computer.
2. Once extracted, you should obtain a folder named:

modular_design_lab/

This folder already contains:

• Docker configuration files
• The swarm robotics experiments
• The AutoMoDe interface
• The ARGoS3 configurations
• All required scripts and dependencies

The structure should look similar to this:

modular_design_lab/
├── docker-compose.yml
└── README.md/

2. Installation instructions by operating system

https://www.docker.com/products/docker-desktop/

Engine running

cd Desktop\modular_design_lab

docker compose up

http://localhost:6080/vnc.html

Connect

swarmbot

cd ~/sigsoft-swarms

source argos3-env.sh

bash start_experiment.sh 1

http://localhost:8088

sigsoft-swarms

docker exec -it sigsoft-swarms bash

sudo apt update
sudo apt install docker.io docker-compose-plugin

sudo usermod -aG docker $USER

docker --version

docker compose version

cd ~/sigsoft-swarms

source argos3-env.sh

bash start_experiment.sh 1

http://localhost:8088

docker compose up

http://localhost:6080/vnc.html

Connect

swarmbot

cd ~/sigsoft-swarms

source argos3-env.sh

bash start_experiment.sh 1

http://localhost:8088

docker compose stop

docker compose start

docker compose down

newgrp docker

docker compose ps

Introduction

In this practical session, the students will use a modular approach to design control software for a swarm of 20 e-puck robots that must perform a set of missions in the ARGoS3 simulator. The missions require the robots to communicate, navigate the environment, react to events, and display spatial-organization properties. Below the e-puck that is used as a basis for the simulations.

Figure 1. The e-puck considered in the practical session, by Garzón Ramos & Birattari.

The exercise is based on TuttiFrutti [3], a modular design method specialized in the realization of collective behaviors for robots that can display and perceive color signals. TuttiFrutti generates control software in the form of probabilistic finite-state machines that combine parametric software modules. Below a simplified example of how a set of behavioral modules are executed in a robot.

Figure 2. Simplified illustration of TuttiFrutti’s software modules assembled into a probabilistic finite-state machine (PFSM) and the resulting behavior on an e-puck, by Garzón Ramos et al.

In TuttiFrutti, the design process is conducted by an optimization algorithm that searches the space of possible control software for good-performing instances. This means that an optimization algorithm selects a possible combination of behavior modules, tunes its parameters, evaluates the performance of the swarm in simulation, and then iterates the process until a training budget is exahusted.

Conversely, in this practical session, the students will take on the role of optimization agents, combining and tuning TuttiFrutti’s software modules to create good-performing control software for the robots. The goal of this practical session is therefore to demonstrate how parametric software modules can be combined in different ways to obtain a variety of collective behaviors with a robot swarm.

To perform the exercise, students are provided with a visualization tool [4] (i) to produce and manipulate finite-state machines, (ii) to visualize simulations [5] of the resulting collective behavior, and (iii) to compute the performance of the swarm in each mission.

Running the software

After installing the required software, open a new terminal (in the container, VM, or your PC). Enter the work directory and source the relevant environmental variables:

cd ~/sigsoft-swarms
source argos3-env.sh

Start an experiment by running the following script. Replace ID by the number of the mission you want to test, between 1 and 21—see Experimental scenarios.

bash start_experiment.sh ID

Then, open the following URL in a browser,

http://localhost:8088

This will spawn an interface that will allow you to create finite state-machines to program the robots and run simulations in ARGoS3—see the figure below.

The interface allows you to add, remove, and reorganize nodes and edges in your finite state-machine. By clicking in a software module (either a node or an edge) you will have access to the parameters that can be modified in each case. For example, you can select the type of node and its functional parameters. When you are satisfied with your design, click on the Exec button to spawn the ARGoS3 simulator and play the simulation to observe the behavior of the robots.

Designing modular control software for robot swarms

You can design control software in the form of a probabilistic finite-state machine. In this architecture, states (nodes) represent low-level behaviors that the robots execute, and transition conditions (edges) represent events that trigger the change from one behavior to another. Each low-level behavior and transition condition is a parametric software module. You can design finite-state machines that have up to 4 states and up to 4 outgoing transitions from each state. The set of software modules that are available during the experiment is composed of 6 low-level behaviors (nodes) and 7 transition conditions (edges).

Low-level behaviors

The table below summarizes the set of TuttiFrutti’s low-level behaviors.

* All low-level behaviors display a color $\gamma\in\{\varnothing,C,M,Y\}$ alongside the action described.

Transition conditions

The table below summarizes the set of TuttiFrutti’s transition conditions.

Experimental scenarios

You will experiment with a swarm of twenty e-puck robots that must perform single-criterion missions, or multi-criteria missions composed of two sequential parts [6]. We create missions by combining a set of 6 sub-missions. For each sub-mission, the performance of the swarm is evaluated by an independent objective function: the design criteria.

The robots operate in an octagonal arena of $2.75\,\text{m}^{2}$ surrounded by RGB blocks—see the figure below. The robots are randomly positioned at the beginning of each experimental run. The RGB blocks are arranged in walls and each of them can possibly display a different color. The floor of the arena is gray with nine square patches, each measuring 25 cm on each side. One of the patches is white, and the other eight are black. In every mission, RGB blocks adjacent to black patches initially turn green, and afterward, they will randomly switch off with uniform probability. The remaining RGB blocks turn red or blue to inform the robots about the sub-mission to be executed.

The experimental arena. The pictures show examples of the two possible states of the arena. At the top, the RGB blocks of the walls display blue and all RGB blocks adjacent to a black patch are switched on, displaying green. At the bottom, the RGB blocks of the walls display red and some RGB blocks adjacent to a black patch have switched off, displaying no color. The robots are randomly positioned.

Sub-missions

We consider a set of six sub-missions ($\text{S}${${1,\cdots,6}$}). Each sub-mission is specified by a description of a task to be executed and a corresponding objective function.

Sub-mission 1 ($\mathbf{S1}$)

The robots must occupy the black patches whose adjacent RGB blocks display green. The swarm is given 1 point for every 100 cumulative timesteps that the robots spend on each suitable patch. For example, a single robot in a patch will be given one point after 100 timesteps, but 10 robots in a patch will be given 1 point after 10 timesteps.

The score of the swarm is the number of points it obtains in the allotted time:

$$f_{\text{S}1}=\sum_{t=1}^{T^{\prime}}\sum_{i=1}^{H}I_{i}(t),$$

which must be maximized. $H$ is the number of patches and $T^{\prime}$ the time available to the robots to perform the sub-mission. The indicator $I_{i}(t)$ is defined as:

$$I_{i}(t)=\begin{cases} 1, & \text{if at time $t$ the robots accumulate 100 timesteps in the patch $i$;} \\0, & \text{otherwise}.\end{cases}$$

Sub-mission $\text{S}1$ is inspired by aggregation missions in which the robots must gather at an indicated place [7],[8].

Sub-mission 2 ($\mathbf{S2}$)

The robots must iteratively travel from any black patch to the white one. The swarm is given 1 point every time a robot completes a trip.

The score of the swarm is the number of points it obtains in the allotted time:

$$f_{\text{S}2}=I_{T^{\prime}},$$

which must be maximized. $I_{T^{\prime}}$ is the number of trips executed in the time $T^{\prime}$ available to the robots to perform the sub-mission.

Sub-mission $\text{S}2$ is inspired by foraging missions in which the robots must travel between two locations: a food source and a nest [3],[7].

Sub-mission 3 ($\mathbf{S3}$)

The robots must occupy the black patches adjacent to RGB blocks that are switched off. The swarm is given one point if at least two robots spend 50 timesteps in the corresponding black patch. The count of timesteps starts as soon as the two robots step into the patch, and it will continue as long as they both remain on it. The count is not affected if more than two robots occupy the patch.

The score of the swarm is the number of points it obtains in the allotted time:

$$f_{\text{S}3}=\sum_{t=1}^{T^{\prime}}\sum_{i=1}^{H}I_{i}(t),$$

which must be maximized. $H$ represents the number of patches and $T^{\prime}$ the time available to the robots to perform the sub-mission. The indicator $I_{i}(t)$ is defined as:

$$I_{i}(t)=\begin{cases} 1, & \text{if at time $t$ two robots accumulate 50 timesteps in the patch $i$;} \\0, & \text{otherwise}.\end{cases}$$

Sub-mission $\text{S}3$ is inspired by strictly cooperative missions in which the robots must jointly perform a single task [9],[10].

Sub-mission 4 ($\mathbf{S4}$)

The robots must iteratively enter and leave the white patch. The swarm is awarded 1 point every time a robot performs these two actions.

The score of the swarm is the number of points it obtains in the allotted time:

$$f_{\text{S}4}=I_{T^{\prime}},$$

which must be maximized. $I_{T^{\prime}}$ is the number of times a robot entered and left the white patch in the time $T^{\prime}$ that is available to the robots to perform the sub-mission.

Also sub-mission $\text{S}4$ is inspired by foraging missions, as sub-mission $\text{S}2$, but here, the robots start and end at a single location.

Sub-mission 5 ($\mathbf{S5}$)

The robots must disperse and cover the arena. We consider the coverage to be the most effective when the minimum distance between any two pair of robots is maximized.

The score of the swarm is the cumulative sum of the minimum inter-robot distance, over time:

$$f_{\text{S}5}=\sum_{t=1}^{T^{\prime}}\min\big(d_{ij}(t)\big),$$

which must be maximized. Here, $d_{ij}$ is the minimum distance between any pair of robots ($i,j$) at time $t$, and $T^{\prime}$ is the time available to the robots to perform the sub-mission.

Sub-mission $\text{S}5$ is inspired by dispersion and coverage missions in which the robots must maintain a fixed inter-robot distance to achieve a specific spatial distribution [8],[11].

Sub-mission 6 ($\mathbf{S6}$)

The robots must remain within a 25 cm distance from the walls of the arena, without entering the black patches.

The score of the swarm is the aggregate time that the robots spend in the suitable areas:

$$f_{\text{S}6}=\sum_{t=1}^{T^{\prime}}\sum_{i=1}^{N}I_{i}(t),$$

which must be maximized. $N$ is the number of robots and $T^{\prime}$ is the time available to the robots to perform the sub-mission. The indicator $I_{i}(t)$ is defined as:

$$I_{i}(t)=\begin{cases} 1, & \text{if the robot $i$ is in gray floor and in a 25 cm distance from a wall at time $t$;} \\0, & \text{otherwise}.\end{cases}$$

Sub-mission $\text{S}6$ is inspired by missions in which the robots must display a specific spatial distribution, like sub-mission $\text{S}5$ [8],[11]. However, the robots here must maintain a specific distance from an element in their environment, irrespective of the distance to their peers.

Single-criteria missions

We define the set $\text{M}_{s}$ of single-criteria missions ($m_{\text{S}p.\text{S}p}$) by evaluating a single sub-mission in both parts of the mission, where $p=q$. This results in 6 missions—see the table below.

The time $T$ available to the robots to execute a mission is 120 s. Accordingly, the swarm’s performance in a mission is assessed for the whole time regarding a single performance metric. A single score is returned after each experimental run. We expect the swarm to be able to perform a mission $m_{\text{S}p.\text{S}q}$ regardless of the order of $\text{S}p$ and $\text{S}q$.

Set of single-criteria missions ($\text{M}_s$). The missions are execution of each of the six sub-missions ($\text{S}_{\{1,\cdots,6\}}$). The colors blue and red characterize the sub-missions $\text{S}p$ () and $\text{S}q$ (). In a mission ($m_{\text{S}p.\text{S}q}$), the sub-missions $\text{S}p$ and $\text{S}q$ represent the same sub-mission ($p=q$), but the order of the sequence and colors ($\text{S}p$ $\rightleftarrows$ $\text{S}q$) is randomly defined in every experimental run. $\text{S}p$ and $\text{S}q$ are executed during an equivalent period of time. The execution of a mission $m_{\text{S}p.\text{S}q}$ returns a single score for the swarm with respect to the corresponding sub-mission, regardless of the order of the sequence.

Multi-criteria missions

We define the set $\text{M}$ of multi-criteria missions ($m_{\text{S}p.\text{S}q}$) by pairing sub-missions ($\text{S}p$, $\text{S}q$) in fifteen combinations—see the table below. Unlike the single-criteria missions, in this case $p\neq q$.

In all cases, the robots must execute the two sub-missions, one after the other. The time $T$ available to the robots to execute a mission is 120 s. The time $T^{\prime}$ available to execute each sub-mission is 60 s. Accordingly, the swarm’s performance in a mission is assessed for the initial 60 s with regard to one sub-mission and for the remaining 60 s with regard to the other. The two scores are returned after each experimental run. We expect the swarm to be able to perform a mission $m_{\text{S}p.\text{S}q}$ regardless of the order of $\text{S}p$ and $\text{S}q$.

Set of multi-criteria missions ($\text{M}$). The missions are paired combinations ($m_{\text{S}p.\text{S}q}$) of the six sub-missions ($\text{S}_{\{1,\cdots,6\}}$). In each combination, the colors blue and red characterize the sub-missions $\text{S}p$ () and $\text{S}q$ (). In a mission ($m_{\text{S}p.\text{S}q}$), the sub-missions $\text{S}p$ and $\text{S}q$ must be executed in sequence, but the order of the sequence ($\text{S}p$ $\rightleftarrows$ $\text{S}q$) is randomly defined in every experimental run. $\text{S}p$ and $\text{S}q$ are executed during an equivalent period of time. The execution of a mission $m_{\text{S}p.\text{S}q}$ returns the score of the swarm with respect to $\text{S}p$ and $\text{S}q$, regardless of the order of the sequence.

To be considered

Contact

Like robot swarms, the swarm robotics community thrives through collaboration. If you would like to contribute to this page, please do not hesitate to get in touch.

David Garzón Ramos
University College Dublin
[email protected]

Feedback, erratas, bug reports, corrections, clarifications, extensions, and new content are all welcomed!

Credits

This course page was created by David Garzón Ramos, LIMAR, University College Dublin (UCD), and funded by IEEE RAS and a UCD Ad Astra Fellowship. The preparation of the material was assisted by Juan B. Medina, PhD student at University College Dublin.

Section 10.1 Swarm Robotics is based on ideas and reserch developed by David Garzón Ramos in collaboration with researchers at IRIDIA, the Artificial Intelligence Laboratory of Université libre de Bruxelles (ULB), and the Bristol Robotics Laboratory, University of Bristol.

Section 10.2 Practice on Collective Behaviors builds on the ideas an excercises developed by Marco Dorigo and Mauro Birattari in the Swarm Intelligence course of IRIDIA at ULB. The original implementation of this excercises is credited to Carlo Pinciroli, Head of NEST Lab, Worcester Polytechnic Institute.

Section 10.3 Practice on Modular Design builds on the ideas an excercises developed by David Garzón Ramos and Mauro Birattari for AutoMoDe TuttiFrutti and Mandarina, with an interface designed by Jonas Kuckling, University of Konstanz.

Back to Top