A Novel Field Based Programming language for Swarm Computing

(1)

Swarm Computing

A Novel Field Based Programming Language for

Academic year 2019-2020

Master of Science in de informatica

Master's dissertation submitted in order to obtain the academic degree of

Counsellor: Robbert Gurdeep Singh Supervisor: Prof. dr. Christophe Scholliers

Student number: 01505701

Tobiah Lissens

(2)

Deze pagina is niet beschikbaar omdat ze persoonsgegevens bevat.

Universiteitsbibliotheek Gent, 2021.

This page is not available because it contains personal information.

Ghent University, Library, 2021.

(3)

Acknowledgements

First of all, I would like to thank my promotor Christophe Scholliers and my supervisor Robbert Gurdeep Singh. The weekly meetings, even at the most unusual times, and their dedication have been extremely helpful, towards realising my dissertation.

Furthermore, I would also like to thank my family, my mother Cecile and Sister Ma¨eli for proofreading my dissertation, my brother Sebastijn for reading my lay summary and my sister Ciel for going through the same emotions when writing a thesis.

I would also like to thank some important friends. First of all, I would like to thank my friend Pieter for proofreading my dissertation and helping me with various projects throughout the years. I also want to thank Alexander for providing being one of the best project partners throughout my studies and always keeping me motivated. The Graanpat´e telegram group was also instrumental in keeping me motivated by providing me with some great conversations and memes. Last but not least, I would like to thank the COVID19 virus for eliminating my entire social life. This enabled me to write my dissertation without ”distractions”. I am not sure if I would have been able to do it without you.

(4)

Summary

Over the last decades, both the size and price of electronics have vastly decreased, while the processing power and hardware efficiency have only increased. This evolution has led to the rapid development of many robot platforms. A robotic swarm is a large group of small robot devices which can collectively solve problems. Even though significant progress has already been made in the development of these hardware platforms, innovation is required to coordinate and program large swarms of robot devices efficiently.

Currently, there is no generally accepted programming model to solve this problem. Robotic swarms are often programmed in low-level languages, such as C or C++. However, these languages lack appropriate coordination abstractions to program robotic swarms. This de-ficiency requires programmers to reason with low-level robot interactions, which can make programming robotic swarms very tedious and prone to bugs.

To solve this problem, this dissertation proposes the reactive field programming model. This model is based on the reactive programming paradigm and extends this with novel coordi-nation abstractions. The model uses data streams to model continuously changing sensor values. Operators are used to transform these sensor data streams and combine them into new data streams that can modify the state of the robots. Furthermore, a new aggregate abstraction is added to enable robot coordination. This abstraction allows coordination in terms of reactive streams with other robots.

We have validated our new programming model by implementing several programs. One of the most basic programs instructs the robots to form a circle around a point in space. This program has been tested both in a simulated environment and on physical robots. Finally, to illustrate complex coordination, a rescue program is written that instructs the robots to rescue a victim and guide it to a safe zone. Although this program is more complex, we demonstrate that it can be broken down into small, easy to understand reactive programs, which can be combined to exhibit complex behaviour.

(5)

Samenvatting

In de afgelopen decennia is zowel de grootte als de prijs van elektronica enorm afgenomen, ter-wijl de rekenkracht van processoren en de efficiëntie van hardware alleen maar is toegenomen. Deze evolutie heeft geleid tot de snelle ontwikkeling van verschillende robotplatformen. Een robotzwerm is een grote groep kleine robot-apparaten die gezamenlijk problemen oplossen. Hoewel er al aanzienlijke vooruitgang is geboekt in de ontwikkeling van robotplatformen, is er nog innovatie nodig om grote robotzwermen efficiënt te programmeren en coördineren. Momenteel is er nog geen algemeen geaccepteerd programmeermodel om dit probleem op te lossen. robotzwermen worden vaak geprogrammeerd in low-level programmeertalen, zoals C of C++. Deze programmeertalen missen coördinatie-abstracties om robotzwermen te pro-grammeren. Dit heeft als gevolg dat programmeurs moeten redeneren met low-level robot interacties, wat het programmeren van robotzwermen erg moeizaam en vatbaar voor fouten kan maken.

Om dit probleem op te lossen wordt in dit proefschrift het reactive field programmeer model voorgesteld. Dit model is gebaseerd op het reactieve programmeer paradigma en breidt dit uit met nieuwe coördinatie-abstracties. Het model maakt gebruik van datastromen om continu veranderende sensor waarden te modelleren. Operatoren worden gebruikt om deze datastromen te transformeren en te combineren tot nieuwe datastromen die gebruikt kunnen worden om de toestand van de robots te veranderen. Daarnaast wordt een nieuwe ’aggre-gate’ abstractie toegevoegd om robotcoördinatie mogelijk te maken. Deze abstractie maakt coördinatie mogelijk door reactieve stromen te delen met andere robots.

We hebben ons nieuwe programmeermodel gevalideerd door verschillende programma ’s te implementeren. Één van de meest elementaire programma ’s geeft de robots de opdracht een cirkel te vormen. Dit programma is getest in een gesimuleerde omgeving en op fysieke robots. Tenslotte is een programma geschreven om complexe coördinatie aan te tonen. Dit programma geeft de robots de opdracht een slachtoffer te redden en te begeleiden naar een veilige zone. Hoewel dit programma complexer is, laten we zien dat dit programma kan wor-den opgesplitst in kleine, gemakkelijk te begrijpen reactieve programma ’s, die gecombineerd kunnen worden om complex gedrag te vertonen.

(6)

A novel field based programming language

for robotic swarms

Tobiah lissens

Ghent University

June 1 2020

Abstract

Currently, there is no generally accepted programming model to program robotic swarms. Robotic swarms are often programmed in low-level languages. However, these languages lack appropriate coordination abstractions to program robotic swarms. This deficiency requires programmers to reason with low-level robot interactions, which can make programming robotic swarms very tedious and prone to bugs. To solve this problem, we propose the reactive field programming model. This model is based on the reactive programming paradigm and is extended with coordination abstractions. We have validated our new programming model by implementing several programs. One of the most basic programs instructs the robots to form a circle. This program has been tested both in simulation and on physical robots. Finally, to illustrate complex coordination, a rescue program is written that instructs the robots to rescue a victim and guide it to a safe zone.

Reactive programming, Swarm robotics, Coordination, Programming model, Field programming

I. Introduction

In the last decade the prices for computer processors and other electronic devices have vastly decreased. Meanwhile, the power and efficiency of these processors have only increased. As a consequence, the research interest has risen immensely in a number of research domains. The domain of interest in this work is swarm robotics. This field investigates how multiple robots can be coordinated, to collectively solve coordinated tasks. These swarms consist of a large collection of robots. The robot devices in these swarms are often very simple devices with a limited amount of sensors and actuators. Inspiration is taken from swarm behaviours in nature, such as ants collectively finding the fastest route to a food source, birds flocking in V formations or fish swimming schools.

Although the increase in processing power and decrease in hardware costs have led to great innovations in the hardware of robot platforms, there is still a lot of innovation required in the software department. The distributed nature, increased processing power and increased parallelism make programming robotics swarms to accomplish a global task incredibly hard. At this point there is no generally accepted programming model to program robotic swarms.

To address this deficiency, the reactive field model is pro-posed. This model is based on the reactive programming

model. To implement the model the Reactive Extensions for Python framework [1] is used. This model has two im-portant features that simplify programming robotic swarms. First, the reactivity of the model enables simple modelling of constantly changing sensor values. Second, the model adds abstractions which allows swarm coordination. This enables programmers to write programs with more complex and interesting swarm behaviours.

II. Related work

The two most interesting and related programming lan-guages are Proto [2] and Buzz [3]. Proto is a programming language designed to program distributed systems, but can be extended to work with robotic swarms [4]. Buzz [3] on the other hand is specifically designed to program robotic swarms.

Proto abstracts the swarm of robots as one amorphous medium. In order to perform calculations on this medium, the Proto language uses fields and defines different oper-ations over these fields. A field is defined in Proto as a mapping projecting network nodes to values. The strength of Proto comes from the combination of four different operator families. The most interesting family is the neighbourhood family. These neighbourhood operations allow sharing data between robots that are close to each 1

(7)

Tobiah Lissens _{• June 2020 • A novel field based programming language for robotic swarms}

Figure 1: Example operation: filter

other within the amorphous medium. These operations can be used to coordinate the swarm.

The Buzz programming language is very similar to tra-ditional programming languages. To make programming robotic swarms easier, abstractions are added to the language. The language has two built-in coordination mechanisms. The first mechanism is stigmergy which is a global memory structure based on Linda’s tuple spaces [5]. The second mechanism is the neighbour structure. This abstraction is used to share both distance and azimuth with the other robots in same neighbourhood. This is loosely inspired on neighbourhood operations from Proto.

In this work, the existing Reactive Extensions framework is used. This framework brings reactive programming to more than 17 different popular programming languages. The framework incorporates data streams in the form of ob-servables, which is useful to model objects with constantly changing values, such as sensors. Reactive Extensions also has a vast library of operations to transform observables. These operations enable the transforming, combining and filtering of observables. Figure 1 illustrates the filter oper-ation on an observable. The sequence of numbers above the operator box represents the input observable. The sequence of numbers below the box represent the output observable.

III. Reactive field programming

The developed reactive field programming model uses ob-servables to model robot sensors. Every time a robot sensor reads out a new value its associated observable will emit a new value. The model provides certain built-in sensor observables, such as the position observable which tracks the position of the robot. Every time the robot’s position has changed, this observable will emit a new position. Ob-servables can also be used to actuate the robots. This is achieved by assigning observables to special output variables. An observable which emits vectors can for example be

as-signed to the motor output variable. The robot will then follow the directions emitted by the vector. The magnitude of these vectors represents the velocity.

Code example 1: Rotating swarm

1 centre = (100 , 100) 2 motor = p o s i t i o n. pipe ( 3 s u b r _ v e c t o r ( centre ) , 4 rotate ( pi / 2) , 5 norm 6 )

Program 1 illustrates the use of the position observable and the motor output variable. The program instructs the robots to rotate around a central point in space. This program uses the pipe operator to chain multiple operations on an observable. First, it transforms the emitted positions of the observable into vectors by subtracting the centre point from the positions (line 3). Next, these vectors are rotated 90 degrees using a rotate operation (line 4). Finally, to give the robots a sensible velocity the emitted vectors are normalised using the norm operation (line 5). The global behaviour of this program is visualised with the vector field in Figure 2.

Figure 2: Vector field: Rotating robots.

IV. Reactive field programming with coordination

An essential aspect in swarm computing is coordination of robots. Currently, no operator exists that allows coordination within the reactive programming model. This 2

(8)

Tobiah Lissens _{• June 2020 • A novel field based programming language for robotic swarms} paper adds coordination with the aggregate operator. The

aggregateoperator is derived from Proto’s [2] neighbour-hood operations and enables programmers to broadcast data emitted by observables to other robots. The operator also aggregates the latest data received from other robots to one value. This operator is implemented in just 33 lines by combining multiple common Reactive Extensions operators. The aggregate operator requires three different arguments and an optional fourth argument. The aggregate operator’ s signature is illustrated in code example 2. This operator can be applied to an observable using the pipe method, previously used in Program 1. The first argument of the operator is a subscription_topic. This argument is used by the aggregate operation to distinguish which aggregate operations are interested in the data and which ones are not. The aggregate function only sends data to aggregate operations on other robots that use the same subscription_topic. The second argument is a generator function. This function is a binary operation that is applied to each received element along with the local value. The final required argument is a binary function that is used to fold the latest received values from the other robots into one value. The fourth optional argument is an initial value, which is used as the initial aggregated value in the reduce phase, if specified.

Code example 2: aggregate arguments

1 a g g r e g a t e (

2 s u b s c r i p t i o n _ t o p i c , generator , 3 a g g r e g a t o r [ , init ]

4 )

Because many aggregate operations use the same folding functions more specific aggregate operators are added, such as the aggregate_min and aggregate_max operations. These specific variants make implementing certain programs easier and shorter.

Program 3 uses the aggregate operation to instruct the robots to form a circle. The program starts with the defini-tion of the collision_avoid observable (lines 5 through 12). This observable emits unit vectors that move away from the closest other robot in the swarm. This observable is defined by applying the aggregate operation to the built-in

Code example 3: Circle formation

1 _radius = 150 2 _delta = 20 3 _ s u b _ t o p i c = 0 4 5 c o l l i s i o n _ a v o i d = p o s i t i o n. pipe ( 6 a g g r e g a t e ( 7 _sub_topic , 8 vector_subr , 9 lambda x , y : 10 min (x , y , key = v e c t o r _ m a g n i t u d e ) 11 ) , 12 norm 13 )

14 vector = p o s i t i o n. pipe ( sub ( centre ) ) 15 i n s i d e _ c i r c l e = vector

16 o u t s i d e _ c i r c l e = vector . pipe ( reflect ) 17 motor = vector . pipe (

18 iff ( 19 lambda v : 20 v e c t o r _ m a g n i t u d e ( v ) - _radius < 0 , 21 inside_circle , 22 o u t s i d e _ c i r c l e 23 ) , 24 s e t _ m a g n i t u d e ( 25 lambda length : 26 min ( 27 _delta ,

28 abs ( length - _radius ) 29 ) / _delta

30 ) ,

31 w e i g h t e d _ a d d ( co l li s io n _a v oi d , 0.6 , 0.4)

32 )

positionobservable. Before aggregating the values received from the other robots the vector_subr function is used as a generator function to create vectors(line 8). The vector moving towards the closest robot is selected by use of the min function in combination with the vector_magnitude function (line 10). Finally, the magnitude of the vectors is set to 1 using the norm operation (line 12).

(9)

Tobiah Lissens _{• June 2020 • A novel field based programming language for robotic swarms} After defining the collision_avoid observable the

pro-gram defines the inside_circle and outside_circle observables. The first observable emits vectors that move from the circle’s centre towards the robot’s position. The second observable emits vectors moving in the opposite direction.

Lastly, the motor output variable is defined. The iff operation is used to determine which observable the robot should follow (lines 21 through 26). If the robot is located within the circle, the inside_circle observable is followed (line 24). Otherwise, the outside_circle observable is followed (line 25). After the iff operation, the set_magnitude operation is applied to change the robot’s velocity (line 27 through 32). The robot’s velocity decreases when the robots move closer to the circle’s circumference. Finally, the collision_avoid observable is added, which makes the robots move away from each other while moving towards the circle formation.

V. Reactive field programming on Sphero robots

Program 3 has also been tested on physical robots. Five Sphero SPRK+ robots were used. Sphero robots are sphere shaped robots, the size of a tennis ball, that can move around in two dimensions. The robots are equipped with an accelerometer, gyroscope and motor encoders. For each robot the reactive field programming model is evaluated in a dedicated process. These processes send instructions to their physical robot using Bluetooth. The position sensors of the robots are implemented using a camera. The positions are extracted using a simple centroid tracking algorithm [6]. This is implemented with the OpenCV library [7]. The camera continuously updates the robots with their positions. The result of executing program 3 is illustrated in Figure 3. The Sphero robots start out at random positions, within the field of view. After executing the program for 20 seconds, the robots reach an equilibrium and form a circle.

VI. Rescue program

The reactive field programming model was also validated with a program requiring more complex swarm coordination: a simulated rescue mission. This program is an extension of the circle formation program. Figures 4 illustrate the different stages of the rescue mission.

Figure 3: Sphero SPRK+ robots forming a circle

In the top left figure, all robots are scattered over the two dimensional plane. In the top right figure, the robots have moved to the victims location. The red flag indicates the location of the victim. In the bottom left figure, the robots guide the victim towards the safe zone. Finally, in the bottom right figure, the robots have arrived at the safe zone and stop moving.

During the rescue program a transition between subprograms is made: the first subprogram moves the robots towards surrounding the victim, while the second instructs the robots to guide the victim to the safe zone.

VII. Conclusion

The reactive field programming model is proposed to simplify the programming of robotic swarms. This model is based on the reactive programming paradigm and implemented within the Reactive Extensions for Python framework. The model uses observables to model continuously changing sensor values. Transformation operators are used to transform sensor observables and combine them into new observables that can modify the state of the robots, i.e the direction and speed of the robots. To make coordination possible this model is extended with the aggregate operator and its variants, such as the aggregate_min operation.

The programming model was validated with the implemen-tation of a number of programs. One of the most basic programs instructs the robots to form a circle around a point in space. This program has been tested both in a simulated environment and on five Sphero SPRK+ robots. Finally, to illustrate complex coordination, a rescue program 4

(10)

Tobiah Lissens _{• June 2020 • A novel field based programming language for robotic swarms}

Figure 4: Four different stages of the rescue mission

is written that instructs the robots to rescue a victim and guide it to a safe zone.

References

[1] Reactive extensions. http://reactivex.io/. [accessed 25-April-2020].

[2] Mirko Viroli, Jacob Beal, and Matteo Casadei. Core operational semantics of proto. volume 78, pages 1325– 1332, 01 2011.

[3] Carlo Pinciroli, Adam Lee-Brown, and Giovanni Bel-trame. Buzz: An extensible programming language for self-organizing heterogeneous robot swarms. 07 2015. [4] Jonathan Bachrach, Jacob Beal, and James Mclurkin.

Composable continuous-space programs for robotic swarms. Neural Computing and Applications, 19:825– 847, 09 2010.

[5] David Gelernter. Generative communication in linda. ACM Transactions on Programming Languages and Sys-tems, 7:80–112, 1985.

[6] Adrian Rosebrock. Simple object tracking with opencv. https://www.pyimagesearch.com/2018/07/ 23/simple-object-tracking-with-opencv/, 2018. [accessed 02-May-2020].

[7] G. Bradski. The OpenCV Library. Dr. Dobb’s Journal of Software Tools, 2000.

(11)

Een nieuwe veld gebaseerde programmeer taal

voor robotzwermen.

Tobiah lissens Universiteit Gent 1 juni 2020 Samenvatting

Momenteel is er geen algemeen geaccepteerd programmeermodel voor het programmeren van robotzwermen. Daarnaast worden robotzwermen vaak in ’low-level’ programmeertalen geprogrammeerd. Deze programmeertalen missen coördinatie-abstracties om robotzwermen te programmeren. Daardoor moeten programmeurs werken met low-level robot interacties, wat het programmeren van robotzwermen erg moeizaam en vatbaar voor fouten kan maken. Wij stellen het ’reactive field’ programmeer model voor als oplossing. Dit model is gebaseerd op het reactieve programmeer paradigma en breidt dit paradigma uit met nieuwe coördinatie-abstracties. We hebben ons nieuwe programmeermodel gevalideerd door verschillende programma ’s te implementeren. Één van de simpelste programma ’s geeft de robots de opdracht een cirkel te vormen. Dit programma is getest zowel in een gesimuleerde omgeving als op fysieke robots. Tenslotte is een programma geschreven om complexe coördinatie aan te tonen. Dit programma geeft de robots de opdracht om een slachtoffer te redden en te begeleiden naar een veilige zone.

Reactief programmeren, robotzwermen, Co¨ordinatie, Programmeer model, Veld programmeren

I. Inleiding

In de afgelopen decennia is zowel de grootte als de prijs van de elektronica enorm afgenomen, terwijl de rekenkracht van processoren en de efficiëntie van hardware alleen maar is toegenomen, waardoor onderzoek in verschillende domeinen is gegroeid. Het interessegebied van dit werk is robotzwermen. In dit domein wordt onderzocht hoe meerdere robots gecoördineerd kunnen worden, om geza-menlijk taken op te lossen. Deze zwermen bestaan uit een grote verzameling robots. De robots in deze zwermen zijn vaak zeer eenvoudige apparaten met een beperkt aantal sensoren en actuatoren. Inspiratie wordt gehaald uit het gedrag van de zwermen in de natuur, zoals mieren die gezamenlijk de snelste route naar een voedselbron vinden, vo-gels die vliegen in formaties of vissen die zwemmen in scholen. Hoewel er al aanzienlijke vooruitgang is geboekt in de ontwikkeling van robot-platformen, is er nog innovatie nodig om grote robotzwermen efficiënt te programmeren en coördineren. De gedistribueerde aard en de toegenomen parallellisatie maken het programmeren van robotzwermen, die een gezamenlijk taak uit voeren, enorm moeilijk. Op dit moment is er geen algemeen geaccepteerd programmeermo-del om robotzwermen te programmeren.

Om deze tekortkoming te verhelpen, wordt het ’reactive field’

model voorgesteld. Dit model is gebaseerd op het reactieve programmeer model. Om het model te implementeren wordt het ’Reactive Extensions for Python framework’ [1] gebruikt. Dit nieuwe model heeft twee belangrijke functies die het programmeren van robotzwermen vereenvoudigen. Ten eerste zorgt de reactiviteit van het model ervoor dat continu veranderende sensor waarden eenvoudig gemodelleerd kunnen worden. Ten tweede voegt het model abstracties toe die de co¨ordinatie van de zwerm mogelijk maken. Dit stelt programmeurs in staat om programma ’s te schrijven met complexer en interessanter zwerm-gedrag.

II. Verwant werk

De twee meest interessante en gerelateerde programmeerta-len zijn Proto [2] en Buzz [3]. Proto is een programmeertaal die is ontworpen om gedistribueerde netwerken te program-meren, maar kan worden uitgebreid om te werken met robotzwermen. Buzz is daarentegen speciaal ontworpen om robotzwermen te programmeren.

Proto abstraheert de zwerm-robots als ´e´en amorf medium. Om berekeningen uit te voeren op dit medium, gebruikt de Proto-taal velden en definieert verschillende bewerkingen over deze velden.Een veld wordt in Proto gedefinieerd als een 1

(12)

Tobiah Lissens• juni 2020 • Een nieuwe veld gebaseerde programmeer taal voor robotzwermen.

Figuur 1: Voorbeeld operatie: filter

afbeelding die robots afbeeldt op waarden. De kracht van Proto komt voort uit het combineren van vier verschillende operator families. De meest interessante familie is de ”neighbourhood-familie. Deze ”neighbourhood-operaties maken het mogelijk om gegevens uit te wisselen tussen robots die zich dicht bij elkaar bevinden binnen het amorfe medium. Deze operaties maken de co¨ordinatie van robotzwermen mogelijk.

De Buzz-programmeertaal is zeer vergelijkbaar met de traditionele programmeertalen. Om het programmeren van robotzwermen te vergemakkelijken, worden er enkele abstracties aan de taal toegevoegd. De taal heeft twee inge-bouwde co¨ordinatiemechanismen. Het eerste mechanisme is ’stigmergy’, wat een globale geheugenstructuur is gebaseerd op Linda’s tuple spaces [4]. Het tweede mechanisme is de ”neighbours structure”. Deze abstractie wordt gebruikt om zowel afstand als azimut te delen met de andere robots in dezelfde buurt. Dit mechanisme is ge¨ınspireerd op de ”neighbourhood-operaties van Proto.

In dit werk wordt gebruik gemaakt van het bestaande Reac-tive Extensions framework. Dit framework brengt reactief programmeren naar meer dan 17 verschillende programmeer-talen. Het framework bevat datastromen in de vorm van observables, wat nuttig is om objecten met constant veran-derende waarden, zoals sensoren, te modelleren. Reactive Extensions heeft ook een uitgebreide bibliotheek van opera-ties om observables te manipuleren. Deze operaopera-ties maken het mogelijk om observables te transformeren, te combine-ren en te filtecombine-ren. Figuur 1 illustreert de filter operatie op een observable. De volgorde van de getallen boven de operator box vertegenwoordigt de invoer van de observable. De getallen onder het vakje staan voor de getransformeerde observable.

III. Programmeren in het reactive field model

Het ontwikkelde reactive field programmeermodel maakt gebruik van observables om robot sensoren te modelleren. Elke keer dat een sensor een nieuwe waarde uitleest, zal de bijhorende observable een nieuwe waarde uitzenden. Het model voorziet ook ingebouwde sensor-observables, zoals de position-obervable die de positie van de robot modeleert. Elke keer dat de positie van de robot verandert, zal deze observable een nieuwe positie uitsturen. De observables kunnen ook gebruikt worden om de robots aan te sturen. Dit wordt bereikt door observables toe te wijzen aan speciale uitvoer-variabelen. Een observable die vectoren uitzendt kan bijvoorbeeld worden toegewezen aan de motor uitvoer-variabele. De robot volgt dan de richting van de vectoren die de observable uitzendt. De grootte van deze vectoren geeft de snelheid weer.

Voorbeeld programma 1: ronddraaiende robotzwerm

1 centre = (100 , 100) 2 motor = p o s i t i o n. pipe ( 3 s u b r _ v e c t o r ( centre ) , 4 rotate ( pi / 2) , 5 norm 6 )

Programma 1 illustreert het gebruik van de positie observa-bles en de motor uitvoer-variabele. Het programma geeft de robots de opdracht om rond een centraal punt in de ruimte te draaien. Dit programma gebruikt de pipe methode om meerdere bewerkingen na elkaar op een observable uit te voeren. Eerst worden de posities van de positie observable omgezet naar vectoren, door het centrum van de cirkel af te trekken van de posities (lijn 3). Vervolgens worden deze vectoren 90 graden gedraaid met behulp van de rotate ope-ratie (lijn 4). Ten slotte worden de vectoren genormaliseerd met behulp van de norm operatie (lijn 5), zodat de robots een redelijke snelheid kunnen hebben. Het globale gedrag van dit programma wordt gevisualiseerd met het vector veld in Figuur 2.

(13)

Figuur 2: Vector veld: Draaiende robots.

IV. Co¨ordinatie in het reactive field model

Een essentieel aspect bij het programmeren van robot-zwermen is de coördinatie van robots. Op dit moment bestaat er geen operator die coördinatie binnen het reactieve programmeermodel mogelijk maakt. Dit werk voegt coördinatie toe met de aggregate operator. De aggregate operator is gebaseerd op Proto’s [2] neighbourhood-operaties en stelt programmeurs in staat om gegevens die door observables worden uitgezonden naar andere robots uit te sturen. De operator aggregeert ook de binnenkomende gegevens van andere robots tot één waarde. Deze operator is ge¨ımplementeerd in slechts 33 regels door het combineren van meerdere Reactive Extensions operators.

De aggregate operator heeft drie verschillende argumenten nodig en een optioneel vierde argument. De signatuur van de aggregate operator wordt ge¨ıllustreerd in code voorbeeld 2. Deze operator kan worden toegepast op een observable met behulp van de pipe methode, die eerder werd gebruikt in programma 1. Het eerste argument van de operator is een subscription_topic. Dit argument wordt gebruikt door de aggregate operatie om te onderscheiden welke aggregate operaties ge¨ınteresseerd zijn in de data en welke niet. De functie aggregate stuurt alleen gegevens naar aggregate operaties op andere robots die dezelfde subscription_topic gebruiken. Het tweede argument is een generator functie. Deze functie is een binaire operatie die wordt toegepast op elk ontvangen element samen met de lokale waarde. Het laatste argument is een binaire functie die wordt gebruikt om de laatst ontvangen waarden van de andere robots tot één waarde te reduceren. Het vierde optionele argument is een initiële waarde die enkel wordt

gebruikt tijdens de reduceerfase.

Voorbeeld programma 2: aggregate argumenten

1 a g g r e g a t e (

2 s u b s c r i p t i o n _ t o p i c , generator , 3 a g g r e g a t o r [ , init ]

4 )

Omdat veel aggregate operaties dezelfde reduceerfuncties gebruiken, zijn er meer specifieke operatoren toegevoegd, zoals de operaties aggregate_min en aggregate_max ope-ratoren. Deze specifieke varianten maken het implementeren van bepaalde programma’s eenvoudiger en korter.

Programma 3 gebruikt de aggregate operatie om de robots de opdracht te geven een cirkel te vormen. Het programma begint met de definitie van de collision_avoid die observable (regel 5 tot en met 12). Deze observable zendt eenheidsvectoren uit die zich weg bewegen van de dichtstbijzijnde robot in de robotzwerm. Deze observable wordt gedefinieerd door de aggregate operatie toe te passen op de ingebouwde positie observable. Voordat de waarden van de andere robots worden geaggregeerd, wordt de vector_subr functie gebruikt als een generator functie om vectoren (lijn 8) te cre¨eren. De vector die naar de dichtstbijzijnde robot toe beweegt wordt geselecteerd door gebruik te maken van de min functie in combinatie met de vector_magnitudefunctie (regel 10). Tenslotte wordt de vector genormaliseerd met behulp van de norm functie (lijn 12).

Na het defini¨eren van de collision_avoid observable defini-eert het programma de inside_circle en outside_circle observables. De eerste observable zendt vectoren uit die van het centrum van de cirkel naar de positie van de robot bewegen. De tweede observable zendt vectoren uit die in de tegenovergestelde richting bewegen.

Ten slotte is de motor uitvoer-variabele gedefinieerd. De ifffunctie wordt gebruikt om te bepalen welke observable de robot moet volgen (lijnen 21 tot en met 26). Als de robot zich binnen de cirkel bevindt, wordt de inside_circle observable gevolgd (lijn 24). In het andere geval wordt de outside_circle observable gevolgd (lijn 25). Na de operatie iff wordt de set_magnitude operatie toegepast 3

(14)

Voorbeeld programma 3: Cirkel formatie

1 _radius = 150 2 _delta = 20 3 _ s u b _ t o p i c = 0 4 5 c o l l i s i o n _ a v o i d = p o s i t i o n. pipe ( 6 a g g r e g a t e ( 7 _sub_topic , 8 vector_subr , 9 lambda x , y : 10 min (x , y , key = v e c t o r _ m a g n i t u d e ) 11 ) , 12 norm 13 )

14 vector = p o s i t i o n. pipe ( sub ( centre ) ) 15 i n s i d e _ c i r c l e = vector

16 o u t s i d e _ c i r c l e = vector . pipe ( reflect ) 17 motor = vector . pipe (

18 iff ( 19 lambda v : 20 v e c t o r _ m a g n i t u d e ( v ) - _radius < 0 , 21 inside_circle , 22 o u t s i d e _ c i r c l e 23 ) , 24 s e t _ m a g n i t u d e ( 25 lambda length : 26 min ( 27 _delta ,

28 abs ( length - _radius ) 29 ) / _delta

30 ) ,

31 w e i g h t e d _ a d d ( co l li s io n _a v oi d , 0.6 , 0.4)

32 )

om de snelheid van de robot te veranderen (lijn 27 tot en met 32). De snelheid van de robot neemt af wanneer de robots dichter bij de omtrek van de cirkel komen. Tenslotte wordt de collision_avoid observable toegevoegd, waardoor de robots van elkaar weg bewegen, terwijl ze de cirkelformatie vormen.

Figuur 3: Sphero SPRK+ robots vormen een cirkel

V. Programmeren met Sphero robots

Programma 3 is ook getest op vijf Sphero SPRK+ robots. Sp-hero robots zijn bolvormige robots, met ongeveer de grootte van een tennisbal, die in twee dimensies kunnen bewegen. De robots zijn uitgerust met een accelerometer, gyroscoop en motor encoders. Voor elke robot wordt het reactive field model in een eigen proces uitgevoerd. Deze processen sturen instructies naar hun fysieke robot met behulp van Bluetooth. De positie sensoren van de robots worden ge¨ımplementeerd met behulp van een camera. De posities worden ge¨extraheerd met behulp van een eenvoudig centroid-tracking-algoritme [5]. Dit is ge¨ımplementeerd met de OpenCV-bibliotheek [6]. De camera informeert de robots continu over hun posities. Het resultaat van programma 3 wordt ge¨ıllustreerd in Figuur 3. De Sphero robots starten op willekeurige posities binnen het gezichtsveld van de camera. Na het uitvoeren van het programma gedurende 20 seconden bereiken de robots een evenwicht en vormen ze een cirkel.

VI. Reddingsprogramma

Het reactive field model werd ook getest met een programma dat complexere co¨ordinatie nodig heeft. Dit programma is een gesimuleerde reddingsmissie van een slachtoffer. Figuren 4 illustreren de verschillende stadia van de reddingsmissie. In de figuur linksboven staan alle robots verspreidt over het twee-dimensionale vlak. In de figuur rechtsboven zijn de robots verplaatst naar de locatie van het slachtoffer. De rode vlag geeft de locatie van het slachtoffer aan. In de linkerbenedenhoek leiden de robots het slachtoffer naar de veilige zone. In de rechterbenedenhoek zijn de robots bij de 4

(15)

veilige zone aangekomen en stoppen ze met bewegen. Tijdens het reddingsprogramma wordt een overgang ge-maakt tussen verschillende sub-programma ’s. Het eerste sub-programma beweegt de robots naar de omgeving van het slachtoffer, terwijl het tweede subprogramma de robots opdracht geeft om het slachtoffer naar de veilige zone te begeleiden.

Figuur 4: Vier verschillende staten van het reddings-programma

VII. Conclusie

We hebben het reactive field programeer model voorgesteld om het programmeren van robotzwermen te vereenvoudigen. Het model maakt gebruik van observables om continu veranderende sensor waarden te modelleren. Transformatie operatoren worden gebruikt om de sensor observables te transformeren en te combineren tot nieuwe observables die de toestand van de robots kunnen wijzigen. Om co¨ordinatie van robotzwermen mogelijk te maken is het model uitgebreid met de aggregate operator en enkele varianten, zoals de aggregate_minoperatie.

Het nieuwe programmeringsmodel werd getest met een aantal voorbeeld programma’ s. Een van de simpelste

programma ’s laat de robots toe om een cirkel te vormen rond een punt in de ruimte. Dit programma is zowel in een gesimuleerde omgeving als op vijf Sphero SPRK+ robots getest. Ter illustratie van de complexe co¨ordinatie wordt tenslotte een reddingsprogramma ge¨ımplementeerd dat de robots instrueert om een slachtoffer te redden en naar een veilige zone te leiden.

Referenties

[1] Reactive extensions. http://reactivex.io/. [accessed 25-April-2020].

[2] Mirko Viroli, Jacob Beal, and Matteo Casadei. Core operational semantics of proto. volume 78, pages 1325– 1332, 01 2011.

[3] Carlo Pinciroli, Adam Lee-Brown, and Giovanni Bel-trame. Buzz: An extensible programming language for self-organizing heterogeneous robot swarms. 07 2015. [4] David Gelernter. Generative communication in linda.

ACM Transactions on Programming Languages and Sys-tems, 7:80–112, 1985.

[5] Adrian Rosebrock. Simple object tracking with opencv. https://www.pyimagesearch.com/2018/07/ 23/simple-object-tracking-with-opencv/, 2018. [accessed 02-May-2020].

[6] G. Bradski. The OpenCV Library. Dr. Dobb’s Journal of Software Tools, 2000.

(16)

Lay summary

In a few years, fireworks might be completely replaced by hundreds of flying robots equipped with lights. This trend has already been picked up in Belgium where a first artificial robotic fireworks was tested on New Year’s Eve in Bruges. While such firework shows are very im-pressive, these drones are mostly programmed using animation software, where a designer dictates the trajectory of each drone. A more challenging task is to use hundreds of robots to collaboratively solve tasks. For example, spontaneously illuminate a path towards the nearest exit in a burning building to guide people to safety. Implementing such tasks is much more challenging than robotic fireworks because these robots need to adapt to changing conditions in the environment. Moreover, when one drone breaks down, the rest of the robots should compensate for the loss of the robots and attempt to solve the task with the remaining robots. In human languages, inventing new words with a

spe-cific meaning can change the way people think (Sapir-Worf hypothesis). One example comes from a hill tribe whose language has specific grammatical constructs to re-fer to ”up” and ”down” the hill. Because of this partic-ular grammatical construction members of this tribe are much more aware of their location relative to the hill. Another example is Inuit with a much broader vocab-ulary to describe snow. This idea also applies to pro-gramming languages in which the ability to concisely ex-press certain ideas can shape the way programs are writ-ten.

We propose ”reactive field programming” as a new approach to program robotic swarms. This approach adds specific vocabulary which simplifies programming and coordinating robotic swarms. We tested our new programming approach by implementing several programs. One of the programs instructs the robots to form a circle. This program was tested both in a simulated environment and on actual robots. The figure above displays the circle formation with five robots. We also implemented a more complex program. This program instructs the robots to rescue a victim and guide it to a safe zone. This program illustrates the ability to write complex programs with the new programming vocabulary.

(17)

2.1.5 Protelis . . . 11 2.2 Buzz . . . 12 2.2.1 Swarm management . . . 12 2.2.2 Neighbours structure . . . 12 2.2.3 Virtual stigmergy . . . 13 2.2.4 Evaluation . . . 13 2.3 Reactive programming . . . 14 2.3.1 Reactive Extensions . . . 14 2.3.2 Classification of observables . . . 16 2.3.3 Different Observables . . . 16 2.4 Summary . . . 16 2.4.1 Features definitions . . . 17 2.4.2 Language comparison . . . 17

3 Reactive field programming without interaction 20 3.1 Programming in reactive extensions . . . 20

3.1.1 Operations in Reactive Extensions . . . 20

3.1.2 Creation . . . 21

3.1.3 Transformation . . . 21 xvii

(18)

xviii CONTENTS

3.1.4 Filtering . . . 21

3.1.5 Combination . . . 22

3.1.6 Boolean . . . 22

3.2 Using observables in Reactive extensions for Python . . . 23

3.3 Vector operations . . . 24

3.4 Controlling robots. . . 25

3.4.1 Reading sensor values . . . 25

3.4.2 Setting state of robots . . . 26

3.5 Reactive field programming in a nutshell . . . 26

3.5.1 Moving the robots . . . 27

3.5.2 Rotating robots around a point in space . . . 28

3.5.3 Moving towards a target . . . 29

3.5.4 Forming a circle . . . 30

4 Reactive field programming with interaction 33 4.1 Aggregation operator . . . 33

4.1.1 Inclusive aggregate . . . 35

4.1.2 Derived operators . . . 36

4.2 Aggregate operator example . . . 37

4.2.1 Forming an equidistant circle . . . 37

4.3 Aggregate implementation . . . 39

4.3.1 Defining a minimal communication interface . . . 39

4.3.2 A minimal message specification . . . 40

4.3.3 Implementing new operators . . . 41

4.3.4 A simple reference implementation . . . 43

4.3.5 Deriving a programmer friendly version . . . 47

4.3.6 Dealing with failing robots . . . 48

4.4 Conclusion . . . 49

5 Evaluation of reactive field programming 50 5.1 Sphero robots . . . 50

5.1.1 Controlling the Sphero robots . . . 51

5.1.2 Determining the position of the Sphero SPRK+ robots . . . 52

5.1.3 Adapting examples to the Sphero robot setup . . . 53

5.1.4 Equidistant circle program on Sphero robots . . . 55

5.1.5 Final remarks on the setup . . . 58

5.2 Complex coordination . . . 58

5.2.1 Main program . . . 59

5.2.2 Moving to the victim . . . 60

5.2.3 Moving to the safe zone . . . 62

(19)

CONTENTS xix

5.4 Comparison with other programming models . . . 64

6 Conclusion 67 6.1 Contributions . . . 67

6.2 Future work . . . 68

Bibliography 69 A Appendices 71 A.1 Sphero read Locator . . . 71

A.2 Sphero equidistant circle example . . . 72

A.3 Rescue program . . . 73

(20)

List of Figures

1.1 Swarm platforms: Kilobots [1] top left, Cellulo [2] top right, E-puck [3] bottom

left and swarmbots [4, p. 19] bottom right . . . 1

2.1 Proto’s four different operation families [4, p. 6] . . . 7

2.2 Network graph example . . . 9

2.3 Observer UML diagram [5, p. 328]. . . 14

2.4 Example operation: filter . . . 15

3.1 Creation: interval function . . . 21

3.2 Transformation: scan operation . . . 21

3.3 Filtering: distinct_until_changedoperation . . . 22

3.4 Combining: combine_latest operation . . . 22

3.5 Conditional: take_until operation . . . 23

3.6 Vector: add operation . . . 25

3.7 Creation: of function . . . 27

3.8 Vector field: Robots moving left. . . 28

3.9 Vector field: Rotating robots. . . 29

3.10 Vector field: Moving towards a goal. . . 30

3.11 Vector field: forming a circle. . . 32

4.1 Vector fields: left non-equidistant circle field, centre right collision avoid field, right motor field . . . 39

4.2 Device 1 broadcasting its position to the other network devices. . . 40

4.3 Operator: sum divisible items . . . 42

4.4 Operator dependency graph . . . 44

5.1 Sphero SPRK+ robot . . . 51

5.2 Architecture controlling robots. The circles outside of the computer environ-ment represent the robots in the real world. . . 52

5.3 Python environment with a camera process. This camera process informs the robots of their positions. When odometry is used, the robots themselves communicate the position to the robot process. . . 53

5.4 Vector field viewing-space template. . . 55 xx

(21)

LIST OF FIGURES xxi 5.5 Equidistant circle on real robots: Initialisation and formation. . . 57 5.6 Equidistant circle using Sphero robots: Move one robot. . . 58 5.7 Four different stages of the rescue missions . . . 59

(22)

List of Tables

2.1 Neighbour operations . . . 9 2.2 Classification of observables [6] . . . 16 2.3 Comparison of programming models for robotic swarms . . . 19 4.1 Viewpoint device 1. . . 34 4.2 Generation on device with identifier 1. When local position updates to (200,

100) . . . 47 4.3 Aggregation on device with identifier 1. The result is a vector from robot

identifier 1 to its closest robot in the network. . . 47 5.1 Features of Sphero SPRK+ robot . . . 51 5.2 Features of reactive field programming . . . 66

(23)

Listings

2.1 Proto timer program . . . 8 2.2 Distance to source Proto [4] . . . 10 2.3 Random movement [4] . . . 11 2.4 Distance to source using Protelis [7] . . . 12 2.5 Stigmergy opertaions [8] . . . 13 2.6 Observer pattern Python . . . 15 3.1 Working with observables in RxPY . . . 23 3.2 Implementing custom sensors . . . 26 3.3 Swarm moving left . . . 27 3.4 Swarm rotating . . . 28 3.5 Swarm moving to a target . . . 29 3.6 Swarm circle formation . . . 31 4.1 Distance to closest robot . . . 35 4.2 Minimum temperature . . . 36 4.3 Derived aggregate min . . . 36 4.4 Vector towards nearest robot. . . 37 4.5 Swarm that forms an equidistant circle . . . 38 4.6 RxPY pipe operation . . . 41 4.7 RxPY pipe method . . . 41 4.8 Sum divisible items (composite) . . . 42 4.9 Sum divisible items (subscription logic) . . . 43 4.10 Aggregate implementation . . . 44 4.11 Scan accumulation operation . . . 45 4.12 Starmap derived from map . . . 46 4.13 Generation mapper . . . 46 4.14 Subscription topic generation . . . 48 5.1 Template for camera viewing-space compatibility . . . 55 5.2 Main rescue program . . . 60 5.3 Moving to the victim . . . 61 5.4 Moving to the safe zone . . . 63 A.1 Sphero read locator program . . . 71 A.2 Sphero equidistant circle example . . . 72

(24)

xxiv LISTINGS A.3 Rescue program . . . 73 A.4 Rescue program with obstacle avoidance . . . 75 A.5 Flocking program . . . 78

(25)

Chapter 1 Introduction

Over the last decade, the price of computer processors and other electronic devices has vastly decreased. Meanwhile, the power and efficiency of these processors have only increased. As a consequence, the research interest has risen immensely in many research domains. The domain of interest in this work is swarm robotics. This field researches how multiple robots can be coordinated, to collectively solve specific tasks. These swarms consist of an extensive collection of robots. The robotic devices in these swarms are often very simple devices with a limited amount of sensors and actuators. Inspiration is taken from swarm behaviours in nature such as ants collectively finding the fastest route to a food source, birds flocking in V formations or fish swimming schools.

Figure 1.1: Swarm platforms: Kilobots [1] top left, Cellulo [2] top right, E-puck [3] bottom left and swarmbots [4, p. 19] bottom right

A variety of swarm platforms have been developed, such as Kilobots [9], Cellulo [10], E-pucks 1

(26)

2 CHAPTER 1. INTRODUCTION [11], Swarmbots [12] and many more. These low-cost robot devices can be used together to solve a huge variety of tasks that cannot be solved by an individual robot. An example of such a task is self-assembly [13]. In self-assembly, robots act as material that can shape shift into different formations such as stars, circles or even more complex shapes. Robotic swarms can also play an essential role in rescue operations, as these swarms can reach places that are inaccessible to humans or single, large rescue robots. Additionally, robotic swarm robots generally have a tiny footprint. When these robots work together as one team, they can successfully rescue small objects from otherwise unreachable locations. Another more concrete example is using swarm robots to clean up oil spills. In this example, these swarms are deployed into the ocean where they soak up spilt oil leaks.

Besides the above examples, robotic swarms can also bring other advantages such as im-proved fault tolerance and resilience. This resilience implies that failing robots can swiftly and easily be replaced without interrupting the other robots in the swarm. In case there is no replacement robot available, fewer robots can approximate the task. In regular robotics, on the other hand, a faulty sensor can cause the entire task to fail.

Although the increase in processing power and diminishing hardware costs have led to signif-icant innovations in the hardware of robotic swarm platforms, there is still much innovation required in the software department. The distributed nature, increased processing power and increased parallelism make programming robotic swarms incredibly hard. Currently, there does not exist a generally accepted programming model to program robotic swarms.

Usually, low-level languages are used to program swarm robots, such as C or C++. These languages offer minimal higher-level abstractions to program robotic swarms. Currently, programmers developing robotic swarm programs mostly focus on programming every robot individually for their specific platform. This approach increases the chances of writing soft-ware bugs and slows down the development of new programs. As a result, researchers have started to create programming languages specifically designed to program robotic swarms. These languages have built-in abstractions that allow the programming of robotic devices in a more global task-oriented fashion.

The reactive programming model is an interesting programming model that has not been used for robotic swarms up to now. This model is based on data streams that emit events. These data streams have multiple operations that allows manipulation of incoming events. Currently, this model is quite popular for programming graphical user interfaces. Reactive programming simplifies responding to user events, such as mouse events or button clicks. As a result, web-frameworks, such as Angular [14], have embraced these principles.

(27)

1.1. PROBLEM STATEMENT AND CONTRIBUTION 3

1.1 Problem statement and contribution

This dissertation proposes the use of the reactive programming model to program robotic swarms. This model makes it easier for robots to react to continuously changing sensor values in the environment of the robots and adjust their actuators accordingly. Usually, swarm programs written in imperative models create an infinite loop that reads sensor values. Next, these sensor values are used to compute a direction vector, which is then used to adjust the robot’s actuator. This practice is illustrated in algorithm 1. In comparison, reactive programming provides a stream of sensor values on which a chain of operations is defined. This chain of operations eventually leads to a stream of vectors which is used to set the robot’s actuators. This programming style is illustrated in algorithm 2. The advantage of this approach is that the vectors are only recalculated when the sensor value is updated. Algorithm 1 Regular imperative programming approach.

while True do

sensor _{← read sensor value} ...

vector _{← computed direction from sensor} move(vector)

Sleep end while

Algorithm 2 Reactive programming approach. sensor stream _{← a stream of sensor values} vector stream _{← sensor stream}

.computation 1() ...

.computation n() move(vector stream)

Reactive modelling of robots works well when robots can make decisions themselves, based on their sensor values, i.e., when no coordination mechanism is required. However, a swarm can only function without any coordination in very few cases. Currently, the reactive pro-gramming model lacks abstractions that allow coordination. This dissertation focuses on using the reactive programming paradigm to program robotic swarms and extending it with communication abstractions that enable the programmer to coordinate robots within the reactive programming model.

The new programming model also promotes intensional programming. The term “intensional programming” denotes that programs describe rules from which the robots can derive the appropriate actions. This programming style is illustrated in example 3.

(28)

4 CHAPTER 1. INTRODUCTION Algorithm 3 Intenional programming example.

if obstacle in front of robot then stop

else

move forward end if

The opposite of intensional programming is extensional programming. In this program-ming style, programmers hard-code specific behaviours to individual robots. Because robotic swarms can contain more than 100 robots, this style is not scalable and should be discour-aged. An example feature that encourages programmers to program in the extensional style is the exposure of robot identifiers, which is illustrated in program 4.

Algorithm 4 Extensional programming example. if robot.id == 1 then

move forward

else if robot.id == 2 then move left

else if robot.id == 3 then move right

end if

The main contributions of this dissertation are:

1. Controlling actuators by using the events emitted by data streams. Chapter 3 explains how to transform these sensor streams into vector streams that can be used to actuate the robots.

2. Adding coordination abstractions to the reactive model. Chapter 4 introduces the aggregate operation. This solves the lack of coordination abstractions within the

reactive model required to program robotic swarms. The aggregate operation enables

broadcasting constantly evolving data streams to other robots on the network, while also aggregating the incoming data broadcasted by the other robots. Chapter 4 also shows a reference implementation in Python that can easily be ported to other program-ming models. This implementation takes special care not to expose network identifiers to the programmer. This makes it harder to program in an extensional style and therefore encourages programming in a rule-based intensional fashion.

3. Guided examples that illustrate programming robotic swarms using the reactive pro-gramming model. Chapter 3 introduces examples that do not require any coordination. The two most prominent examples are instructing the robots to move towards a chosen position and instructing the robots to rotate around a position. Chapter 4 describes a

(29)

1.1. PROBLEM STATEMENT AND CONTRIBUTION 5 program that directs the robots to form a circle around a centre point. This program introduces coordination where robots have to avoid each other while evenly distributing on the circumference of the circle. As a result of this, the robots form an equidistant circle. Finally, Chapter 5 provides a rescue program that illustrates more complex coordination.

4. Validation of the reactive model on Sphero SPRK+ robots. Sphero SPRK+ robots are small, sphere-shaped robots. These robots are the size of a tennis ball and can move freely in a 2-dimensional space. Chapter 5 explains how to use the reactive model with Sphero SPRK+ robots by using the equidistant circle example explained in Chapter 4.

(30)

Chapter 2 Related work

This chapter gives an overview of the work related to this dissertation. The two most re-lated works are Proto and Buzz. Proto is a programming language designed to program distributed systems, but it can also be used to program robotic swarms. Contrarily, Buzz was explicitly designed to program robotic swarms. Furthermore, this chapter introduces re-active programming, more specifically, the Rere-active Extensions framework. This framework is the foundation of the work in this dissertation. This chapter concludes with a comparison of these programming models.

2.1 Proto

Proto [15] is a language which was created specifically to program distributed, homogeneous devices in a scalable and robust fashion. The syntax of Proto is influenced by the functional language Lisp. Proto abstracts the network of devices as one amorphous medium. To perform calculations on this medium, the Proto language uses fields and defines operations over these fields. A field in Proto is defined as a mapping that projects nodes of the network to values. For example, the literal 1 in Proto actually represents a field. This field projects every

node in the network to the value 1. The operation (+ 1 2) represents the addition of two

constant fields. Proto defines different types of operations. Some examples include enabling communication between the nodes of the amorphous device or enabling evolving field values over time. The following sections dive deeper into the features and operations of Proto.

2.1.1 Operator families

The strength of Proto comes from the combination of four different operator families. The following section introduces these four different classes shown in Figure 2.1.

(31)

2.1. PROTO 7

Figure 2.1: Proto’s four different operation families [4, p. 6] Point-wise

The first operation displayed in Figure 2.1 is a binary pointwise operation with two fields. The illustrated operation adds all values, that have the same domain (devices), together. This family of operations is based on pointwise operations in mathematics. An example is the pointwise binary addition operation which is defined as follows:

Given functions f : X → Y and g: X → Y : ∀x ∈ X, (f + g)(x) = (f(x) + g(x))

In Proto; the functions f and g are discrete mappings, referred to as fields. The domain of these fields corresponds to the network devices contained in the amorphous medium. The pointwise family is not restricted to just binary operations but can be any n-ary operation. An example is the sqrt operation which is a unary operation that applies the square root to

all values contained in a field. The muxoperation is a more unconventional operation in this

family. This is a multiplexing operation that uses a boolean test field to choose between the values calculated by its first and second branch expressions. In other words, themuxoperator

evaluates both branches for every device in the field mapping. This operation results in a new field, where the nodes in the boolean test field which are mapped to the valuetrue select

the value from the first branch and the nodes which are mapped to the value falseselect the

value from the second branch. The fact that themuxoperator always evaluates both branches

is an essential notion and the main difference between restriction operations. Restriction

The top-right operation family in Figure 2.1 is the restriction family. These operations restrict the domain of a field over which computations are executed. The example in figure

(32)

8 CHAPTER 2. RELATED WORK 2.1uses two fields. The first field is a boolean field, while the second field consists of arbitrary values. The result of the restriction operator is a smaller field. The domain of this field is defined by the boolean values of the first field and the second field defines its values. The most common restriction operator is the ifoperator. This operator requires two arguments.

The first argument is a boolean field expression and the second argument is a arbitrary field expression. Similar to if expressions in other programming languages, the if operator only

evaluates the second expression on the devices where the field evaluates to true.

Feedback

The feedback operator family is illustrated in the bottom-left corner of Figure 2.1. These operations can be used to update the state of a field over time. Feedback operations start with an initial field. In every iteration, this field is updated by evaluating an expression. After waiting a small amount of time, the expression is recalculated based on the previous value. These operations can be compared to afold operation over time. The most commonly

used feedback operator is the rep operation. This operation expects three arguments. The

first argument is a variable name that references the previously calculated state. The second argument is an initial state. Finally, the third argument is an expression used to update the state based on the previous state. The result of this operation is a field that evolves over time. Code example 2.1 illustrates how to use the rep operation to create a timer.

Code example 2.1: Proto timer program

1 ( rep t 0 (+ t ( dt ) ) )

The dt variable is a special variable that keeps track of the elapsed time since the

previ-ous evaluation of the expression. This program adds the elapsed time since the previprevi-ous evaluation to the timer variable.

Neighbourhood

The last family of operations illustrated in the bottom-right of Figure 2.1are the neighbour-hood operations.

To share information between nodes inside the amorphous medium, neighbourhood oper-ations can be used. Proto abstracts this with operators that create a field of fields and operators that reduce a field of fields back to a regular field. Some examples of operators that create a field of fields are nbr and nbr-range. The nbr operator requires one field as its

argument. This operator creates a field that projects the nodes of the amorphous medium to new fields. These nested fields map the neighbouring nodes to their values in the first field. Examples of operators that reduce a field of fields back to a regular field include fold-hood

(33)

2.1. PROTO 9 and min-hood. Thefold-hood operator expects two arguments: a folding function, and a field

of fields respectively. The folding function specifies how two fields should be reduced back to one field. The min-hood operator is a derivation of the fold-hood operator, using the minimum

operation as the fold function.

Table 2.1illustrates these neighbourhood operations on the network illustrated in Figure2.2. The network graph consists of six individual nodes. The edges between the nodes represent the neighbour relationships. Neighbouring nodes in the graph can communicate with each other. In Proto, this relationship is usually unidirectional. However, for the sake of simplic-ity, a bidirectional relationship is used. The value d represents a field where every node is

mapped to the value located next to the node. The first and second columns in Table 2.1 illustrate field d. node d (nbr d) (min-hood (nbr d)) 1 4 2 8 3 6 6 3 3 2 8 1 4 3 6 4 3 6 1 4 2 8 4 9 4 4 9 3 6 5 2 6 3 2 5 2 4 9 6 3 3 6 3 1 4 4 9 5 2 2

Table 2.1: Neighbour operations Figure 2.2: Network graph example Columns one and three in Table 2.1 illustrate the (nbr d) operation. As explained before,

this operation creates a field of fields. This field of fields maps every node to another field where its neighbours are mapped to their value of d. For example, the node with identifier 1 is mapped to another field where its neighbouring nodes 2, 3 and 6 are mapped to 8, 6, 3 respectively.

(34)

10 CHAPTER 2. RELATED WORK 1 and 4 illustrate the application of the min-hood operation to the field of fields created by (nbr d). In Table 2.1, node 1 is projected to the minimum of the values of its field. The

values of node 1’s field are 8, 6 and 3. The minimum of these values is 3, which implies that the resulting field maps node 1 to the value 3.

2.1.2 Local evaluation

To implement the Proto language, every device needs to run a local program. These local programs are derived from the global Proto program, which describes the behaviour over the amorphous manifold. When all devices execute this derived program locally, the behaviour defined by the Proto program appears. To translate this global program into locally exe-cutable code, a compilation step is required. Here, neighbourhood operators are compiled into local code that communicates with other devices. Feedback operators are implemented by locally reevaluating the code in cyclic calculations. Restriction operators are converted into local if-else statements [15].

2.1.3 Distance to source example

Code example 2.2 below is an example of a Proto function. This function estimates the distance from every node in the network to a source node, using the triangle inequality.

Code example 2.2: Distance to source Proto [4]

1 ( def d i s t a n c e - t o ( source ) 2 ( rep d ( inf )

3 ( mux source 0

4 ( m i n - h o o d (+(( nbr d ) ( n b r - r a n g e ) ) ) ) ) ) )

This function expects a boolean source field as its input argument. This source field maps the source node to the value true, and maps all other nodes to the valuefalse. The function

returns a constantly evolving field that maps every node to its estimated distance to the source node. This is achieved by using a combination of point-wise, feedback and neighbourhood operations. The rep feedback operator defines a field variable d that is initialised with the

value inf. The value of field d evolves over time according to the body of the rep operator.

In other words, in every execution cycle, the rep operator assigns the evaluation of (mux source 0 (min-hood(+((nbr d)(nbr-range)))))to thedfield. Using themuxoperator, the source

node is mapped to the value 0. All other nodes are mapped to their estimated minimum distance, calculated by the (min-hood(+((nbr d)(nbr-range)))) expression. The expression ( nbr d)represents a field of fields. This is a mapping of nodes to another mapping that projects

(35)

2.1. PROTO 11 neighbouring nodes to their value of d. The expression nbr-range also represents a field of

fields. These two fields of fields are combined using pointwise addition. Afterwards, these field of fields are reduced back to a regular field using the min-hoodoperation. After several rep cycles, the field d will stabilise and every device will be mapped to its approximated

distance to the source node.

2.1.4 Proto and robotic swarms

Proto is mainly developed with general distributed networks in mind, but it can be adapted to work with robotic swarms [4] as well. Robotic swarms can be considered as distributed networks, where each device can move around while the network topology changes. To allow the robots to move around, a movoperation is added to the language. This operation expects

a vector field as input and moves the robot devices accordingly. Code example 2.3 contains a small Proto program that moves the swarm robots around in random directions.

Code example 2.3: Random movement [4]

1 ( def r a n d - v e c

2 ( tup ( rnd -1 1) ( rnd -1 1) ( rnd -1 1) ) 3 ( mov ( r a n d - v e c ) )

The rnd function returns a random field of floats within the supplied boundaries. Proto has

been verified to work both in simulation and on IRobot’s SwarmBots [16].

2.1.5 Protelis

The Proto language is mainly an academically focused language with little usage in real world applications. To tackle this problem, Protelis [7] was created. This language is a Java embedded version of Proto, with a syntax that closely resembles Java as well. Embedding Protelis in Java allows programmers to leverage all of Java’s features and libraries. Using a C/Java familiar syntax also allows most programmers to quickly adopt the Protelis language. Aside from these syntax and environment changes, the Proto operators and semantics remain unchanged. Code example 2.4 illustrates how example2.2 can be ported to Protelis.

(36)

12 CHAPTER 2. RELATED WORK Code example 2.4: Distance to source using Protelis [7]

1 def d i s t a n c e T o ( source ) { 2 rep ( d <- I n f i n i t y ) { 3 mux ( source ) { 0 } 4 else { minHood ( nbr { d } + n b r R a n g e ) } 5 } 6 }

2.2 Buzz

Buzz [8] is a very versatile programming language, specifically designed to program robotic swarms. The goal of this programming language is to create one programming language that can be used to program all kinds of robotic swarms. Buzz even supports using different types of robots together. I.e. Buzz allows programming heterogeneous robotic swarms. Buzz allows programming robots as an entire swarm (”top-down programming”) and on an individual basis (bottom-up programming). The syntax of Buzz is based on popular languages, such as Python and JavaScript, allowing programmers to quickly familiarise themselves with the Buzz language. The following sections give an overview of the builtin tools Buzz has to offer.

2.2.1 Swarm management

The Buzz programming language has built-in objects that allow managing smaller sub-swarms. These management objects can be created using the swarm.create function. This

function expects one argument, a swarm identifier, and returns the management object. The swarm management objects in Buzz are often just calledswarms. To decide which robots can

join the swarm, the object’s select method can be used. This method uses a predicate that

evaluates to true if the robot can join the swarm. For example swarm.select(id % 2 == 0) [8]

instructs all robots with an even identifier to join the swarm. Similarly robots can leave the swarm using the unselect method which also requires a predicate. To let robots enter and

leave the swarm without a condition, the join and leave methods can be used respectively.

Finally, to instruct the robots of the swarm to execute a task, the exec method should be

used. This method expects a function as its argument. This function is executed by all robots contained in the swarm.

2.2.2 Neighbours structure

The Buzz’s neighbours structure is inspired by Proto’s neighbourhood operations. The neigh-bours structures collect the azimuth, distance and elevation of its neighneigh-bours in a dictionary-like structure. The neighbours of a robot are the robots within communication distance of

(37)

2.2. BUZZ 13 the robot. The neighbour structure has methods for iteration (foreach), transformation (map)

and reduction (reduce). For example, the distance to the farthest neighbour can be calculated

as follows:

1 n e i g h b o u r s . reduce ( f u n c t i o n ( robot_id , data , accum ) { 2 return math . max ( data . distance , accum )

3 } , 0)

2.2.3 Virtual stigmergy

Buzz has a built-in structure called virtual stigmergy. This structure allows robots to share data globally with robots. Virtual stigmergy is an implementation of distributed tuple spaces taken from the Linda [17] language. To create a stigmergy structure, the stigmergy.create

function should be used. This function requires one identifier as its argument and returns a reference to the stigermergy structure. To atomically enter data into this structure, the put

method should be used. To read data from the structure, the get method should be used.

Code example 2.5 illustrates these operations.

Code example 2.5: Stigmergy opertaions [8]

1 # Create a new virtual s t i g m e r g y 2 # A unique id (1 here ) must be passed 3 v = s t i g m e r g y . create (1)

4 # Write a ( key , value ) entry into the s t r u c t u r e 5 v . put (" a " , 6)

6 # Read a value from the s t r u c t u r e 7 x = v . get (" a ")

2.2.4 Evaluation

Buzz uses discrete swarm, step-wise execution to evaluate the programs on each robot device. This evaluation happens in discrete steps consisting of five different phases. In the first phase, the robot reads all sensor values. The second phase consists of processing all messages present in the robot’s receive queue. The third phase executes a small portion of the Buzz script. Next, the robot sends out all messages contained in the Buzz’s output queue. The fifth and final step specifies the values of the actuators of the robot device. Buzz repeats these discrete steps until the program ends or an error occurs.