formatievorming in multi-robot systemen

Faculteit IngenieurswetenschappenVakgroep Elektrische Energie, Sytemen en Automatisatie

Voorzitter: Prof. Dr. ir. Jan Melkebeek

Formatievorming in multi-robot

systemen

door

Jan De BeuleKristof Vandoorne

Promotor: Prof. Dr. ir. D. AeyelsScriptiebegeleider: Dr. ir. J. Rogge

Afstudeerwerk ingediend tot het behalen van de academische graad vanBurgerlijk Elektrotechnisch Ingenieur

Academiejaar 2005–2006

Dankwoord

We wensen iedereen te bedanken die ons geholpen heeft.In de eerste plaats onze promotor, Dirk Aeyels, die op het goede moment ons inspireerde metwaardevolle ideeen en daarnaast onze scriptiebegeleider, Jonathan Rogge, voor het interessanteonderwerp en het vele overleg.

Zonder bepaalde mensen zou de ontwikkeling van de Sonar Turret onmogelijk geweest zijn.Sean Hoyt en Pierre Bureau hielpen het PCB te ontwikkelen en verduidelijkten de KNET-bus,terwijl Bjorn Vandecasteele ons bijstond tijdens de uiteindelijk fabricage van de Sonar Turret.Daarnaast willen we Michiel De Wilde bedanken omdat hij ons uit de deadlock -situatie hielptijdens de ontwikkeling van de code voor de microcontroller.Toen de noodzaak kwam om onze robots in een nieuwe behuizing te stoppen, stond Kristof’snonkel, Francky Callewaert, klaar om die te helpen ontwerpen en fabriceren. Zijn neefje ennichtje verlosten tegelijk onze robots van hun naamloosheid.

De lijst met mensen die ons inspiratie gaven, maar ons vooral mentaal steunden is te langom iedereen op te noemen maar in het bijzonder denken we aan Lieve Van den Eeckhout, diehet geduld en de volharding had om de volledige scriptie nauwgezet na te lezen. Joke, omdat zeonze video’s wou bewerken, Stijn voor zijn hartmeter en tenslotte Nathalie voor haar interesseen inspiratie.We willen ook zeker onze ouders niet vergeten te bedanken voor de inspanningen die ze moetenleveren en onze familie, omdat ze met ons moet leven.

Als laatste willen we vooral elkaar bedanken voor de verhelderende brainstorm-sessies en deinspiratie, maar ook voor de ontspannende badmintonpartijtjes!

i

Toelating tot bruikleen

De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen vande scriptie te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingenvan het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijkte vermelden bij het aanhalen van resultaten uit deze scriptie.

Datum Handtekening

ii

Formatievorming in multi-robot systemen

door

Jan De BeuleKristof Vandoorne

Afstudeerwerk ingediend tot het behalen van de academische graad vanBurgerlijk Elektrotechnisch Ingenieur

Academiejaar 2005–2006

Universiteit GentFaculteit Ingenieurswetenschappen

Vakgroep Elektrische Energie, Systemen en AutomatiseringVoorzitter: Prof. Dr. ir. Jan Melkebeek

Promotor: Prof. Dr. ir. D. AeyelsScriptiebegeleider: Dr. ir. J. Rogge

Samenvatting

Het doel van dit afstudeerwerk was het ontwikkelen van algoritmes om Khepera II -robots eerstin formatie te laten komen en hen daarna deze formatie te laten behouden in een op voorhandonbekende en onvoorspelbare omgeving. Om dit doel te bereiken, dienden echter enkele belang-rijke voorbereidende stappen genomen te worden. Zo werd de communicatie tussen de KheperaII -robots onderzocht en werden software-mechanismen ontwikkeld om deze communicatie zo be-trouwbaar mogelijk te maken. We denken hierbij aan detectie van verloren gegane boodschappenen retransmissie ervan. Betrouwbare communicatie werd zowel via de High Speed Radio Turretals via de normale Radio Turret verwezenlijkt. Uiteindelijk werd voor de rest van dit onderzoekgebruik gemaakt van de Radio Turret, omdat die het meest gebruiksvriendelijk is.Een tweede voorbereidende stap, was de ontwikkeling van een extensieturret, de Sonar Turret,voor de Khepera II die toelaat om nauwkeurige afstandsmetingen uit te voeren. Hiervoor wordtgebruik gemaakt van SRF05-modules, die ultrasone metingen uitvoeren en zeer eenvoudig aante sturen zijn. De communicatie tussen de extensieturret en de Khepera II gebeurt door middelvan de KNET-bus. Het KNET-busprotocol werd geımplementeerd op de PIC16F877A, de mi-crocontroller die we gebruiken op de Sonar Turret.Na deze voorbereidende stappen werd overgegaan tot de ontwikkeling van formatievormingsal-goritmes. In een eerste fase werd een algoritme ontwikkeld dat enkel steunt op de IR-sensorenvan de Khepera II. Hierbij bleek dat de IR-sensoren van verschillende robots elkaars metingenbeınvloeden, waardoor hun sensorwaarden onbetrouwbaar worden. Omdat formatievorming opdie manier niet mogelijk is, baseren de algoritmes die daarna ontwikkeld werden zich enkel opmetingen met de Sonar Turret. Deze algoritmes laten toe om Khepera II -robots vanuit een wil-lekeurige positie in een voorafbepaalde formatie (driehoek) te laten komen en hen een onbekendterrein te laten verkennen waarbij ze tegelijkertijd obstakels ontwijken.

Trefwoorden: formatievorming, multi-robot systeem, Khepera II, ultrasone sensor, inter-robotcommunicatie

iii

Inhoudsopgave

1 Inleiding 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Doel van deze scriptie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Structuur van het werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Communicatie 5

2.1 Communicatie via de High Speed Radio Turret . . . . . . . . . . . . . . . . . . . 5

2.1.1 Features van de High Speed Radio Turret . . . . . . . . . . . . . . . . . . 5

2.1.2 Uitzicht van de turret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Structuur van de berichten . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Controlemechanisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.5 De Java-code voor de PC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.6 De C-code voor de robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.7 Evaluatie van de High Speed Radio Turret . . . . . . . . . . . . . . . . . 16

2.2 Communicatie via de Radio Turret . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1 Features van de Radio Turret . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2 Uitzicht van de turret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.3 Eigenschappen van de transmissie . . . . . . . . . . . . . . . . . . . . . . 20

2.2.4 Communicatie tussen de Khepera II en de Radio Turret . . . . . . . . . . 21

2.2.5 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.6 Communicatie in de testopstelling zonder QoS . . . . . . . . . . . . . . . 25

2.2.7 Communicatie in de testopstelling na het inbouwen van QoS . . . . . . . 26

2.3 Algemene Communicatiestructuur . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1 Vaste berichtstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.2 Verpakken van boodschappen . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.3 Boodschappen bufferen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.4 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4 Uitbreiden van QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.1 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.2 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4.3 Ontvangerszijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iv

2.4.4 Zenderzijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.5 ACK-versturend proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.6 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.5 Dynamische groepstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.5.1 Voortbouwen op de huidige communicatiestructuur . . . . . . . . . . . . . 45

2.5.2 Aanpassingen aan de communicatiestructuur . . . . . . . . . . . . . . . . 46

3 Sonar Turret 49

3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 SRF05-module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Extensieturret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4 PIC16F877A-microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Het PCB van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5.1 Aanpassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6 Code voor de microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6.1 Algemene werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6.2 Aandachtspunten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.7 Aansturing van de turret vanop de Khepera II . . . . . . . . . . . . . . . . . . . 61

3.8 Evaluatie van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.8.1 Nadelen van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.9 Nieuw ontwerp Sonar Turret (Rev. 1) . . . . . . . . . . . . . . . . . . . . . . . . 64

3.9.1 De MAX530 DAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.9.2 PCB van de vernieuwde Sonar Turret . . . . . . . . . . . . . . . . . . . . 65

3.9.3 Code voor de microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.9.4 Aansturing vanop de Khepera II . . . . . . . . . . . . . . . . . . . . . . . 68

4 Formatiegedrag met IR-sensoren 69

4.1 De IR-sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 Metingen met de IR-sensoren . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.2 Interpretatie van de metingen . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Formatievorming: doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.1 Doelstellingen 1 en 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2.2 Doelstelling 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2.3 Doelstelling 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.4 Problemen bij de realisatie van de gezamelijke doelstellingen . . . . . . . 78

4.3 Nieuwe aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.1 Dalende waarden opvangen . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.2 Stijgende waarden opvangen . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.3.3 Bijkomende problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3.4 Bijkomende oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.4 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

v

5 Formatievorming met de Sonar Turret 87

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.2 Robots detecteren en formatie vormen . . . . . . . . . . . . . . . . . . . . . . . . 89


5.2.2 Praktische implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.3 Formatie behouden met verschillend interactiegedrag . . . . . . . . . . . . . . . . 94



5.3.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.4 Formatie behouden met verschillend autonoom gedrag . . . . . . . . . . . . . . . 99



5.4.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6 Conclusies en perspectieven 104

6.1 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.1.1 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.1.2 Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.1.3 Formatievorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.2 Perspectieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Bibliografie 108

vi

Lijst met afkortingen

A/D Analoog / Digitaal

ACK ACKnowledgement

ADC Analoog-naar-Digitaal Converter

bps bits per second

CPU Central Processing Unit

CSMA/CD Carrier Sense Multiple Access with Collision Detection

DAC Digitaal-naar-Analoog Converter

EMA Exponential Moving Average

I/O Input / Output

ID IDentificatie

IR InfraRood

LED Light Emitting Diode

LF LineFeed

MAS Multi-Agent System

msg message

MSG MeSsaGe

Nr Nummer | Number

PCB Printed Circuit Board

QoS Quality of Service

REQ Request

SN SerieNummer

SPI Serial Peripheral Interface

TDMA Time Division Multiple Access

uint unsigned integer

vii

Lijst van figuren

1.1 De Khepera II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Foto en bovenaanzicht van de High Speed Radio Turret . . . . . . . . . . . . . . 6

2.2 De structuur van de ontwikkelde Java-klassen . . . . . . . . . . . . . . . . . . . . 14

2.3 Foto en bovenaanzicht van de radioturret . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Modus- en ID-selector van de Radio Turret . . . . . . . . . . . . . . . . . . . . . 20

2.5 De testopstelling voor de communicatie . . . . . . . . . . . . . . . . . . . . . . . 24

2.6 ACK die verloren gaat als dataverkeer . . . . . . . . . . . . . . . . . . . . . . . . 36

2.7 Proces- en bufferstructuur voor de communicatie . . . . . . . . . . . . . . . . . . 39

2.8 Testopstelling bij uitgebreide QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.9 Communicatie via polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.10 Communicatie via een virtual token ring . . . . . . . . . . . . . . . . . . . . . . . 48

3.1 De SRF05-module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2 De KNET-bus met (a) alle turrets in slaaptoestand (b) een turret in actieve toestand 51

3.3 De toestand van de KNET-bus gedurende de communicatie met een slave . . . . 52

3.4 PCB-layout van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 Khepera II met Sonar Turret (bovenaan), High Speed Radio Turret en Radio

Turret (onderaan) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.6 Opmeten van een andere robot in het geval van ideale ultrasone sensoren en

behuizing van de robots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.7 Bundelbreedte van SRF05-modules . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.8 De Sonar Turret met aanpassingen voor nauwkeurige sonarmetingen . . . . . . . 56

3.9 Reflectie van een ultrasone bundel op een schuine muur volgens de wet van de

reflectie: θ1 = θ2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.10 PCB-layout van de Sonar Turret Rev. 1 . . . . . . . . . . . . . . . . . . . . . . . 66

viii

4.1 IR-sensoren op de robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Detecteren van een andere robot . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3 Draairichtingen van de robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.4 Ontmoeting met verschillende maximale sensor . . . . . . . . . . . . . . . . . . . 74

4.5 Situatie na het draaien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.6 Verloop van een zijsensor bij een muur . . . . . . . . . . . . . . . . . . . . . . . . 75

4.7 Sensorwaarden zonder uitmiddeling al draaiend bij een voorwerp . . . . . . . . . 77

4.8 Sensorwaarden met een lopend gemiddelde (i.c. parameter gewicht : 0.0645) . . . 78

4.9 Situatie waarbij sensoren elkaar kunnen beınvloeden . . . . . . . . . . . . . . . . 79

4.10 Situatie waarbij sensoren elkaar niet kunnen beınvloeden . . . . . . . . . . . . . . 80

4.11 Dalende waarden bij de robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.12 Te grote waarden bij het heropstarten van de robot . . . . . . . . . . . . . . . . . 84

4.13 Langzaam oplopende sensorwaarden . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.14 Bijkomende gevallen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.1 Ontwijkgedrag door robot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2 Laatste stap in de formatievorming . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3 (links) Positie voor het uitvoeren van het formatievormingsalgoritme (rechts) Po-

sitie na het uitvoeren van het formatievormingsalgoritme . . . . . . . . . . . . . . 94

5.4 Herpositionering van de tweede robot ten opzichte van de eerste (stilstaande)

robot, zodat de gelijkzijdige driehoeksformatie hersteld wordt. . . . . . . . . . . . 98

5.5 Draaien van de formatie over 90 graden (de robots in lichtere kleur geven de

situatie weer van voor het draaien) . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.6 Verschillend autonoom gedrag met volledig elk-om-beurt-principe . . . . . . . . . 100

5.7 Verschillend autonoom gedrag met gelijktijdig-bewegen-principe . . . . . . . . . . 101

5.8 Omgeving waarbij robots elkaar kunnen kwijtgeraken . . . . . . . . . . . . . . . . 103

ix

Lijst van tabellen

2.1 De algemene vorm van een bericht . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Ontvangen berichten zonder QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Algemene berichtstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4 Buffer voor inkomende berichten: initiele toestand . . . . . . . . . . . . . . . . . 33

2.5 Buffer voor inkomende berichten: nieuw bericht van robot 3 ontvangen . . . . . . 33

2.6 Circulaire buffer voor ACK’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7 Structuur van een ACK-bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Draaitabel voor een robot met 2 sensoren . . . . . . . . . . . . . . . . . . . . . . 73

x

Lijst van algoritmes

2.1 De aangepaste getReply()-functie . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 De aangepaste sendBytesSyn(byte[] msg)-functie . . . . . . . . . . . . . . . . . . 11

2.3 De messageAvailable()-functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 De run()-functie in de KheperaComm-klasse . . . . . . . . . . . . . . . . . . . . . 13

2.5 De run()-functie in de KheperaSend-klasse . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Het proces dat instaat voor het ontvangen van boodschappen op de robot . . . . 15

2.7 De functie die instaat voor het verzenden van boodschappen op de robot . . . . . 16

2.8 Ontvangerszijde zonder QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.9 Zenderzijde zonder QoS voor robot 2 . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.10 Ontvangerszijde met QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.11 Zenderzijde met QoS voor robot 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.12 Zendfunctie met QoS: sendRobot() . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.13 Testprogramma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.14 Ontvangerszijde met uitgebreide QoS . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.15 Zendfunctie 2 met uitgebreide QoS: sendAckRobot() . . . . . . . . . . . . . . . . 43

2.16 Het ACK-versturend proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1 PIC16F877A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2 De sonar(direction)-functie op de Khepera II . . . . . . . . . . . . . . . . . . . . 62

3.3 PIC16F877A Rev. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1 Doelstelling 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2 Maximum vinden in real-time: differentieel . . . . . . . . . . . . . . . . . . . . . 76

4.3 Maximum vinden in real-time: tweede methode . . . . . . . . . . . . . . . . . . . 77

4.4 Dalende waarden opvangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.5 Stijgende waarden opvangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.1 Algemene werking van het beurtensysteem: algoritme-proces . . . . . . . . . . . 88

xi

5.2 Algemene werking van het beurtensysteem: luister-proces . . . . . . . . . . . . . 88

xii

Hoofdstuk 1

Inleiding

Inhoudsopgave

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Doel van deze scriptie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Structuur van het werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1 Situering

Een van de grootste uitdagingen in de robotica is het creeren van machines die in staat zijn teinterageren met onvoorspelbare omgevingen in ware tijd [1]. Toepassingen hiervoor situeren zichvoornamelijk in het verkennen van onbekend1 of gevaarlijk2 terrein dat (nog) niet toegankelijkis voor de mens. Een bijkomende uitdaging hierbij is het gebruik van een multi-agent system(MAS), waarbij meerdere agents samenleven en -werken in een gemeenschappelijke omgeving.De centrale idee achter MAS is dat agents samenwerken en op die manier een collectief gedragkunnen vertonen om problemen op te lossen die boven hun individuele capaciteiten of kennisliggen. Het is dit collectief gedrag dat we zullen onderzoeken.Robotica is een goed domein om MAS te onderzoeken. Robots kunnnen gezien worden als agentsmet de volgende karakteristieken [2]:

• Belichaamd: Robots hebben een fysische behuizing en ervaren de wereld direct. Hunacties maken deel uit van een dynamisch interactiesysteem met de wereld en hebben eenonmiddellijke weerslag op de robots zelf.

• Gesitueerd: Robots zijn gesitueerd in hun omgeving. Ze werken in het ‘hier’ en ‘nu’ vande omgeving die het gedrag van het systeem direct beınvloedt.

• Autonomie: Robots werken zonder de directe interventies van mensen en hebben controleover hun acties en interne toestand.

1bv. verkenningstochten op andere planeten2bv. landmijnen opzoeken en onschadelijk maken

1

Hoofdstuk 1. Inleiding 2

Figuur 1.1: De Khepera II

• Mogelijkheid tot sociaal gedrag: De robots kunnen met elkaar communiceren enhebben de mogelijkheid om sociaal gedrag te vertonen om hun doel te bereiken.

• Mobiliteit: Robots kunnen zich verplaatsen in de omgeving.

• Aanpasbaarheid: Robots kunnen hun individueel of collectief gedrag aanpassen aannieuwe situaties door hun constante interactie met de omgeving.

Er zijn verschillende mogelijkheden om het gedrag van deze interagerende agents te imple-menteren. Een mogelijkheid is het centraal coordineren van deze machines in een master-slavecombinatie. Een master-robot zal het gedrag regelen van elk van de andere robots, zodat deandere robots zelf niets moeten (kunnen) beslissen. Het nadeel aan deze configuratie is dekwetsbaarheid van het systeem. Aangezien de hele formatie (slaves) valt of staat met de cor-recte werking van de master, mag er geen enkel risico bestaan dat die niet meer correct zoufunctioneren om welke reden dan ook.Daarentegen zijn evenwaardige agents veel minder kwetsbaar [3], omdat het wegvallen van eenvan hen kan opgevangen worden door de anderen. Bovendien zal het ontwerp van de individuelerobots eenvoudiger zijn in vergelijking met het systeem van een master waarbij de master allesmoet regelen en daardoor heel vlug een complex systeem vereist.Daarom wordt in deze scriptie niet uitgegaan van een master-slave configuratie. We zullen tijdensde formatievorming elke robot een evenwaardige positie geven en proberen hen zoveel mogelijkhetzelfde gedrag te laten vertonen. We willen hiermee het risico dat de formatie verloren gaatbij het uitvallen van een van de robots zo klein mogelijk houden.

In dit onderzoek wordt gebruik gemaakt van drie Khepera II -robots. Deze robots werdenaangekocht bij het Zwitserse bedrijf K-Team Corporation dat gespecialiseerd is in het ontwik-kelen van mobiele minirobots voor educatieve en onderzoeksdoeleinden.

De voordelen van de Khepera II -robot (Fig. 1.1) bestaan uit, maar zijn niet beperkt tot dekrachtige microcontroller, de kleine afmetingen en de mogelijkheid tot het creeren van sensoren-


en actuatoren-extensies3.

Voor elk van de drie robots werd een High Speed Radio Turret [4] aangekocht. Dit iseen extensieturret met Bluetooth-module waarmee de Khepera II draadloos geprogrammeerdkan worden. Ook communicatie tussen de robots onderling (via een PC om) behoort tot demogelijkheden. Deze manier van communiceren wordt in paragraaf 2.1 uitgebreid beschreven.

Daarnaast werd dit jaar ook voor elk van de drie robots een Radio Turret [5] aangekocht omrechtstreeks communicatie tussen de robots toe te laten (zonder via de PC om te moeten gaan).Deze manier van communiceren wordt beschreven in paragraaf 2.2.

Deze scriptie bouwt verder op het onderzoek van Brecht Senepart [6]. In zijn scriptie wordt deKhepera II -robot uitgebreid besproken en worden enkele algoritmes uitgewerkt met individueleKhepera II -robots.

1.2 Doel van deze scriptie

Het uiteindelijke doel van deze scriptie (of eventueel een volgende), was met de Khepera II -robotsformatievormingsalgoritmes uit te testen in de praktijk. In de literatuur is er reeds heel wat tevinden over dit onderwerp; meestal blijft het echter bij theoretische afleidingen van algoritmesen strategieen. De bedoeling was dan ook om hier verandering in te brengen en ons niet zozeerop het theoretische aspect te concentreren, maar zoveel mogelijk algoritmes uit te testen op derobots zelf, om op die manier te ontdekken waar de problemen zich in de praktijk situeren.

In referentie [6, sectie 5.2] is te lezen dat de Khepera II -robot ook zijn onvolkomenhedenheeft. Zo is het onmogelijk om een precieze absolute positie bij te houden door zich louter tebaseren op de metingen van de ingebouwde sensoren van de robot. Absolute positionering houdtin dat de robot op elk moment over zijn coordinaten beschikt in een voorgedefinieerd assenstel-sel. De robot zal geprogrammeerd worden met een beginpositie op t = 0 in dit assenstelsel enzijn positie op elk ogenblik t > 0 berekenen aan de hand van de waarden van zijn sensoren (deadreckoning). De ingebouwde sensoren die hiervoor gebruikt kunnen worden, zijn positie-encodersop de wielen van de robot (odometrie). Deze blijken echter onvoldoende nauwkeurig4 om eenprecieze positionering toe te laten. Daarom wordt in deze scriptie gewerkt met het principe vanrelatieve positionering. Dit wil zeggen dat elke robot op elk moment zijn positie ten opzichtevan de andere robots kent, maar niet zijn absolute positie in de ruimte.De robots beschikken over ingebouwde IR5-sensoren die deze taak zouden kunnen vervullen,maar die zijn sterk afhankelijk van de reflectiviteit van de oppervlakken waartegen de uitge-stuurde IR-bundel geweerkaatst wordt, waardoor ze de exacte afstand tot een obstakel nietkunnen bepalen. Een bijkomend nadeel van deze IR-sensoren is hun beperkte bereik (slechts en-kele centimeters). Daarom werd besloten om voor deze scriptie een extensieturret te ontwikkelenvoor elk van de robots met daarop ultrasone sensoren om zo de exacte afstand tot obstakels tekunnen meten.

3http://www.k-team.com/kteam/index.php?site=1&rub=22&page=17&version=EN4De sensoren op zich zijn wel nauwkeurig, maar door het doorslippen van de wielen, geven ze geen nauwkeurige

meting van de afgelegde afstand.5IR = infrarood

http://www.k-team.com/kteam/index.php?site=1&rub=22&page=17&version=EN


1.3 Structuur van het werk

In hoofdstuk 2 zullen we de communicatieopties bespreken waarover de Khepera II beschikt ommet andere Khepera II ’s of de PC te communiceren. Dit hoofdstuk is opgesplitst in twee grotedelen, namelijk communicatie via de High Speed Radio Turret en via de Radio Turret enerzijdsen algemene communicatiestructuur anderzijds. Voor beide extensieturrets wordt onder anderede berichtstructuur besproken, de mogelijkheid tot foutdetectie en eventuele retransmissie vaneen verloren gegaan bericht, de transmissiesnelheid enz.

In hoofdstuk 3 bespreken we de ontwikkeling van de Sonar Turret. We overlopen zowel hethardwaregedeelte als het softwaregedeelte. Bij de hardware gaan we vooral in op de werking vande gebruikte PIC16F877A-microcontroller en de verschillende ingebouwde modules waaroverdie beschikt. In het softwaregedeelte gaan we in op het KNET-protocol dat we dienden teimplementeren om een communicatiekanaal te kunnen opzetten tussen de Khepera II en deSonar Turret. Ten slotte maken we ook een evaluatie van het gerealiseerde ontwerp.

In hoofdstuk 4 behandelen we het eerste algoritme dat door ons ontwikkeld werd om forma-tiegedrag te implementeren op de Khepera II. Hierbij werd enkel gewerkt met de ingebouwdeIR-sensoren van de Khepera II. In dit hoofdstuk worden de IR-sensoren uitgebreid besproken,alsook de belangrijke nadelen die ze hebben bij het gebruik van meerdere Khepera II ’s in een-zelfde ruimte.

In hoofdstuk 5 bespreken we dan enkele formatievormingsalgoritmes die ontwikkeld werdenin het kader van dit onderzoek, waarbij enkel gebruik gemaakt werd van de Sonar Turret.Zo bespreken we een algoritme waarmee de robots elkaar kunnen vinden, startend van eenwillekeurige positie voor elk van de robots. Verder werken we enkele algoritmes uit om derobots in een driehoeksformatie te houden en eventueel zelfs obstakels te ontwijken.

In hoofdstuk 6 ten slotte geven we enkele conclusies omtrent het door ons gerealiseerde werken proberen we al even in de toekomst te kijken.

Hoofdstuk 2

Communicatie

Inhoudsopgave

2.1 Communicatie via de High Speed Radio Turret . . . . . . . . . . . . . 5

2.2 Communicatie via de Radio Turret . . . . . . . . . . . . . . . . . . . . . 18

2.3 Algemene Communicatiestructuur . . . . . . . . . . . . . . . . . . . . . 30

2.4 Uitbreiden van QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5 Dynamische groepstructuur . . . . . . . . . . . . . . . . . . . . . . . . . 45

In dit hoofdstuk worden de communicatiemogelijkheden tussen de robots besproken. DeKhepera II ondersteunt twee manieren van communiceren, waarvoor telkens een extensieturret1

nodig is:

• High Speed Radio Turret [4] Deze turret ondersteunt snelle (tot 115200 bps2) Bluetooth-verbindingen tot een afstand van 30 m tussen robot en PC (tot 7 robots tegelijkertijd).

• Radio Turret [5] Deze turret ondersteunt trage (tot 9600 bps) verbindingen tot eenafstand van 10 m tussen robots onderling (tot 32 tegelijkertijd) en tussen robot en PC.

Beide mogelijkheden werden gebruikt in dit scriptieonderzoek en zullen worden besproken in dithoofdstuk.

2.1 Communicatie via de High Speed Radio Turret

2.1.1 Features van de High Speed Radio Turret

De specificaties van de High Speed Radio Turret zijn de volgende:

1. 2.4 GHz draadloos communicatiekanaal

2. communicatiesnelheid: 38400 bps of 115200 bps1Het begrip extensieturret wordt in hoofdstuk 3 uitgebreid besproken.2bps = bits per second

5

Hoofdstuk 2. Communicatie 6

3. geen kabel meer nodig tussen robot en PC

4. maximaal 7 robots tegelijk verbonden met een PC

Er werd voor dit onderzoek in eerste instantie gekozen voor de High Speed Radio Turretomdat deze hogere communicatiesnelheden toelaat. Voor dit soort van communicatie bestondechter nog geen protocol, dus werd er een ontwikkeld in het kader van deze scriptie. Aangezienalle verkeer via de PC om moet, zal op de PC een programma moeten lopen dat luistert naarde verschillende robots en de berichten onderling doorstuurt.

De High Speed Radio Turret verschilt van andere extensieturrets omdat deze de RS232seriele kabel (om de robot te programmeren en data van de robot te loggen) vervangt door eendraadloze verbinding. Het seriele kanaal zorgt voor een verbinding tussen de Khepera II en eenPC, maar laat geen rechtstreekse communicatie tussen robots onderling toe. Communicatie,bestemd voor andere robots, dient dus via de PC om te gebeuren.

2.1.2 Uitzicht van de turret

Figuur 2.1: Foto en bovenaanzicht van de High Speed Radio Turret

In figuur 2.1 zien we een bovenaanzicht van de High Speed Radio Turret met daarop devolgende onderdelen aangeduid:

1. Dip switches Hiermee kan de modus en het ID van de High Speed Radio Turret geselec-teerd worden.

2. Reset knop Heeft dezelfde functie als de resetknop op de Khepera II -robot.

3. De antenne

4. Power LED

5. Connect LED AAN wanneer er een connectie opgezet is tussen de PC en de turret.


6. Tx LED AAN wanneer de turret data verstuurt.

7. Rx LED AAN wanneer de turret data ontvangt.

8. Seriele kabel (S) connector [7, sectie 3.1.4]

Modus- en ID-selectie

In deze paragraaf verduidelijken we de modus- en ID-selectie bij de High Speed Radio Turret.Hieronder worden de belangrijkste mogelijkheden van deze instelling besproken.Er zijn 4 switches die naar links (waarde 1) of naar rechts (waarde 0) geschoven kunnen worden.

• Switch 1 bepaalt de communicatiesnelheid van de turret (waarde 1: 115200 bps, waarde0: 38400 bps).

• Switches 2 tot 4 laten toe om het ID in te stellen van de turret, wat nodig is om verschillenderobots te kunnen onderscheiden op de PC.

2.1.3 Structuur van de berichten

Om het protocol zo eenvoudig mogelijk te maken, werd gekozen voor een broadcast-mechanisme.Dit wil zeggen dat, wanneer de robots een bericht versturen naar de PC, de PC ervoor zal zorgendat dit bericht naar alle andere robots doorgestuurd wordt.

Het ontwikkelde protocol bepaalt hoe elk bericht van robot naar PC, en omgekeerd, ingedeeldis. Er bestaan in beide richtingen telkens twee soorten berichten. Er zijn berichten die databevatten en er zijn berichten die een ACK3 bevatten. Waarom dit zo is, wordt besproken inparagraaf 2.1.4.

Data van robot naar PC

Elk bericht (met data) dat verstuurd wordt vanop een robot naar de PC bestaat uit de volgendebytes:

controlByte size func khepFrom msgNr data0 data1 data2

• controlByte We zullen deze byte de waarde 126 geven, zodat de controle-eenheid opde PC hieruit kan besluiten dat dit een bericht is dat nuttige communicatie-informatiebevat, hetzij data voor de andere robots, hetzij een ACK voor een bericht dat de PC naardeze robot gestuurd heeft. Indien deze byte een andere waarde bevat, zal de controle-eenheid besluiten dat dit geen geldig communicatiebericht is en zal het bericht dan ookniet broadcasten naar de andere robots.

• size Deze byte geeft het totaal aantal bytes weer dat het bericht bevat.3ACK = acknowledgement: bericht dat gebruikt wordt om de zendende robot te laten weten dat de boodschap

goed ontvangen is.


• function Deze byte wordt in dit geval op 0 gezet, omdat het bericht data voor andererobots bevat.

• khepFrom Deze byte bevat het ID van de robot die het bericht verzonden heeft.

• msgNr Deze byte is nodig voor het controlemechanisme.(zie paragraaf 2.1.4)

• data Dit is een array van drie keer vier bytes (dus een totaal van drie keer 32 bits = 96bits) die data bevat voor de andere robots.

ACK van robot naar PC

Elk bericht (met een ACK) dat verstuurd wordt vanop een robot naar de PC bestaat uit devolgende bytes:

controlByte size func msgNr

• controlByte Deze byte is opnieuw 126 omdat het een communicatie-bericht is.

• size Deze byte geeft het totaal aantal bytes weer dat het bericht bevat.

• function Deze byte wordt in dit geval op 1 gezet, omdat het bericht een ACK bevat.

• msgNr Deze byte geeft aan welk bericht van de PC wordt acknowledged.

Data van PC naar robot

Voor de communicatie in omgekeerde zin, elk bericht (met data) vanop de PC naar een robotbevat de bytes:

controlByte size func khepFrom msgNr1 msgNr2 msgNr3 data0 data1 data2



• function Deze byte wordt in dit geval op 0 gezet, omdat het bericht data voor andererobots bevat.

• khepFrom Deze byte bevat het ID van de robot die het bericht verzonden heeft.

• msgNr1 Deze byte is nodig voor het controlemechanisme.(zie paragraaf 2.1.4)

• msgNr2 Extra byte voor het controlemechanisme

• msgNr3 Extra byte voor het controlemechanisme

• data Dit is een array van drie keer vier bytes die de data bevat van een andere robot.


ACK van PC naar robot

Elk bericht (met een ACK) dat verstuurd wordt vanop de PC naar een robot bestaat uit devolgende bytes:

controlByte size func msgNr



• function Deze byte wordt in dit geval op 1 gezet omdat het bericht een ACK bevat.

• msgNr Deze byte geeft aan welk bericht van deze robot wordt acknowledged.

2.1.4 Controlemechanisme

Er werd ook een controlemechanisme voorzien dat ervoor zorgt dat alle berichten die verstuurdworden vanop de PC ook daadwerkelijk aankomen op de robot en omgekeerd.Het programma dat op de robot loopt, bestaat namelijk uit verschillende processen die veron-dersteld worden parallel te werken. De robot beschikt echter maar over een processor zodat deprocessen slechts elk om beurt voor een bepaalde tijdsspanne de processor kunnen gebruiken.Hierdoor kan het gebeuren dat het proces dat luistert naar berichten afkomstig van de PC tochzo’n bericht mist, omdat hij op dat moment de processor niet voor zich heeft en het berichtdus niet kan verwerken. Daarnaast kan het gebeuren dat er al een volgend bericht verstuurdwerd, terwijl het vorige nog niet verwerkt was, zodat het nieuwe bericht verloren gaat. Om dezeproblemen op te vangen werd een controlemechanisme geımplementeerd.

Wanneer de PC een databericht verstuurt naar een robot, stuurt hij naast de data ook driekeer het berichtnummer4 mee. Wanneer de robot nu een databericht ontvangt, zal hij eerstcontroleren of de drie berichtnummers dezelfde zijn en zal, in het geval dat dit zo is, een ACK-bericht sturen naar de PC. Het programma op de PC is zo geschreven dat de PC slechts eennieuw databericht naar de robot kan sturen wanneer hij het juiste ACK-bericht (van het vorigverstuurde databericht) heeft ontvangen. Hierbij is ook een time-out-mechanisme ingebouwddat ervoor zorgt dat de PC niet blijft wachten op een ACK, maar na een bepaalde tijd (100 ms)het databericht opnieuw doorstuurt naar de robot. Hierdoor weet de PC dat, wanneer hij eennieuw databericht probeert te versturen, het vorige zeker ontvangen is.

Voor de databerichten van robot naar PC is een soortgelijk mechanisme aanwezig. Ookhier werd vastgesteld dat sommige berichten van de robot verloren gingen. Daarom wordt metelk databericht vanop de robot ook een berichtnummer meegestuurd en zal elk databerichtacknowledged moeten worden door de PC.

4Dit berichtnummer is 1 bij het eerste databericht en incrementeert elke keer er een databericht wordt verstuurdvanop de PC.


2.1.5 De Java-code voor de PC

De robots communiceren met de PC over een draadloos kanaal. Via een Bluetooth-dongle komthet signaal binnen op de PC. Deze dongle laat toe om een seriele poort te emuleren zodathet voor de PC lijkt alsof de robots via een seriele poort met de computer verbonden zijn.Elke robot zal een verschillende (virtuele) COM-poort toegewezen krijgen naargelang het IDdat ingesteld staat op de turret (zie paragraaf 2.1.2). Voor het aansturen van deze poorten,maken we gebruik van de Khepera-klasse (geschreven in Java) uit het JKhepera-package datbeschreven staat in referentie [8]. We zullen de aanpassingen die we maakten aan deze klassein de volgende paragraaf kort beschrijven. In de paragrafen die daarop volgen, bespreken webijkomende klassen die volledig ontwikkeld werden in het kader van dit onderzoek.

De Khepera-klasse

Eerst werd de functie getReply() aangepast om de specifieke berichten uit het nieuw ontwik-kelde protocol te kunnen ontvangen. Deze functie was oorspronkelijk geschreven om standaard-berichten van een Khepera-robot te ontvangen. Deze berichten eindigen altijd met een linefeed

(een byte die het getal 10 voorstelt), zodat deze berichten gelezen werden in een while()-lustotdat de linefeed ontdekt werd. Voor de berichten uit het ontwikkelde protocol was dit echterniet mogelijk omdat het getal 10 meerdere keren kan voorkomen in een bericht. Daarom wordtnu eerst gecontroleerd of de eerste ingelezen byte gelijk is aan 1265 en indien dit zo is, wordthet aantal bytes ingelezen dat te vinden is in de tweede ingelezen byte. Indien de eerste byteniet 126 is, worden bytes ingelezen tot een linefeed ontdekt wordt. Dit algoritme staat inpseudo-code beschreven onder Algoritme 2.1.

Algoritme 2.1 De aangepaste getReply()-functie1: b = incoming byte2: add b to reply3: if (b == 126) then4: size = incoming byte5: add size to reply6: for (0 ≤ i < (size− 2)) do7: b = incoming byte8: add b to reply9: end for

10: else11: while (b 6= LF ) do12: b = incoming byte13: add b to reply14: end while15: end if16: return reply

Het probleem met seriele poorten is dat er niet gelijktijdig van gelezen en naar geschrevenkan worden. Daarom werd een algoritme ontwikkeld waarbij het schrijven altijd voorrang krijgt

5Waarbij we mogen veronderstellen dat een standaard-bericht nooit met 126 begint.


op het lezen en waarbij het lezen onderbroken wordt wanneer er geschreven moet worden. Defunctie sendBytesSyn(byte[] msg) implementeert dit algoritme. Deze functie wordt gebruikom vanop de PC berichten te versturen naar een robot. We zullen nu de code in deze functieskort overlopen (zie ook Algoritme 2.2).De eerste while()-lus wacht tot vorige schrijfoperaties afgelopen zijn. Aangezien alle zend-en ontvangstfuncties van het synchronized6-type zijn, moeten we hier gebruik maken van dewait()-functie die andere synchronized functies toelaat om de variabele writingBusy aan tepassen. Wanneer deze variabele op 1 staat, kan er enkel een bericht verstuurd worden naar derobot en zal er niet meer geluisterd worden naar inkomende berichten. De volgende while()-luswacht tot de thread die luistert naar deze robot, gepauzeerd is. Vervolgens kan het berichtverzonden worden. Om het controlemechanisme (zie 2.1.4) te implementeren, worden eerst nogdrie extra bytes ingevoegd die het berichtnummer bevatten. Tenslotte wacht de functie opeen ACK van de robot en indien een time-out optreedt of de ACK niet overeenkomt met hetverstuurde berichtnummer, wordt het bericht herverzonden.

Algoritme 2.2 De aangepaste sendBytesSyn(byte[] msg)-functie1: while (other threads are sending to this robot) do2: wait()3: end while4: while (thread is listening to this robot) do5: wait()6: end while7: msgNr + +8: compose message msg with msgNr in it9: sendBytes(msg);

10: let thread start listening again to this robot11: while !(correct ACK received from robot) do12: wait(100)13: if (time-out occurred) then14: sendBytes(msg)15: end if16: end while

De functie messageAvailable() controleert of er een zendfunctie een aanvraag voor deCOM-poort gedaan heeft. Indien dit zo is, zal deze functie niet meer luisteren naar deze COM-poort, maar aan de zendfunctie duidelijk maken dat de COM-poort vrij is om te zenden (m.b.v.de notifyAll()-functie die andere synchronized functies toelaat om de variabele writingBusyte controleren). Indien er geen aanvraag is, zal de messageAvailable()-functie (zie Algoritme2.3) controleren of er een bericht ontvangen is via de getReply()-functie.

De functie sendAck(int mesNr) ten slotte stuurt een ACK-bericht naar de robot zoalsbeschreven in paragraaf 2.1.4. Eerst wordt het bericht opgebouwd zoals voorgeschreven in hetontwikkelde protocol en wanneer de COM-poort vrij komt, wordt het bericht verzonden (analoogaan Algoritme 2.2, maar hierbij wordt op het einde niet meer gewacht op een ACK van de robot).

6Voor meer informatie omtrent gesynchroniseerde threads en threads in Java in het algemeen, verwijzen wenaar http://java.sun.com/docs/books/tutorial/essential/threads/index.html

http://java.sun.com/docs/books/tutorial/essential/threads/index.html


Algoritme 2.3 De messageAvailable()-functie1: returnV alue = 02: if (other thread wants to send to robot) then3: notifyAll()4: else5: if (message is incoming) then6: returnV alue = 17: end if8: end if9: return returnV alue

De KheperaComm-klasse

Elk KheperaComm-object komt overeen met een specifieke robot en dit object zal voordurendcontroleren op nieuwe berichten van deze robot. De KheperaComm-klasse stamt af van deThread-klasse (standaard klasse uit Java). Threads zijn processen die parallel naast elkaarkunnen lopen op een processor (de CPU van de PC in dit geval). In elke KheperaComm-thread wordt er naar een specifieke robot geluisterd en een ontvangen bericht zal, indien nodig,doorgestuurd worden naar de andere robots (via de KheperaSend-klasse).

Omdat het luisteren naar een robot ondergeschikt is aan het zenden naar een robot, contro-leert de run()-functie7 voortdurend (via de messageAvailable()-functie uit Algoritme 2.3) ofer ergens (in andere threads) een zendfunctie naar deze robot opgeroepen werd en in dat gevalzal de messageAvailable()-functie het luisteren onderbreken totdat de data verzonden is (depseudo-code is te vinden onder Algoritme 2.4).

De KheperaSend-klasse

Ook de KheperaSend-klasse stamt af van de Thread-klasse. Voor elk ontvangen bericht ineen KheperaComm-object, wordt dus een nieuw KheperaSend-object aangemaakt en opgestart(run()-functie). Bij het verzenden (via de sendBytesSyn()-functie uit de Khepera-klasse)zijn er twee mogelijkheden. Indien het KheperaComm-object het bericht al ontvangen had(sendAckOnly == true), zal hij enkel nog een ACK (via de sendAck()-functie uit de Khepera-klasse) doorsturen. Dit is nodig wanneer de acknowledgment die reeds verstuurd werd, verlo-ren is gegaan. Indien het KheperaComm-object het bericht nog niet ontvangen had, zal hetKheperaSend-object eerst het bericht naar alle andere robots doorsturen en pas dan een ACKsturen naar de robot die bij het KheperaComm-object hoort (Algoritme 2.5).

De KheperaPC-klasse

De main(String[] args)-functie van de KheperaPC-klasse begint met het openen van de ver-schillende seriele poorten waarop een Khepera II is aangesloten. Omdat deze poortnummersvan PC tot PC kunnen verschillen, worden ze meegeven als argument bij het opstarten van hetprogramma. Vervolgens zal er voor elk Khepera-object ook een KheperaComm-thread opgestart

7deze functie wordt gestart wanneer een thread van de klasse KheperaComm start


Algoritme 2.4 De run()-functie in de KheperaComm-klasse1: loop2: while (messageAvailable() ≤ 0) do3: sleep(50)4: end while5: read message msg6: controlByte = msg[0]7: if (controlByte 6= 126) then8: jump to line 1 and wait for next message9: else

10: if (msg[2] == 0) then11: khepFrom = msg[3]12: msgNr = msg[4]13: if (new message) then14: start new KheperaSend-thread to broadcast the received message and send ack to

robot15: else16: start new KheperaSend-thread, but only to send ack to robot17: end if18: else if (msg[2] == 1) then19: msgNr = msg[3]20: setAckReceived(true,msgNr)21: end if22: end if23: end loop

Algoritme 2.5 De run()-functie in de KheperaSend-klasse1: if !(only send ack) then2: for (0 ≤ i < Number of Kheperas) do3: if (i 6= own ID) then4: send message to Khepera with ID i5: end if6: end for7: end if8: send ACK for this message to Khepera with own ID


Figuur 2.2: De structuur van de ontwikkelde Java-klassen

worden. Tot slot wacht het programma totdat de gebruiker het programma wenst af te sluitenen het sluit dan de verschillende seriele poorten.

Een voorbeeld van hoe alle hierboven beschreven klassen samenwerken en de communicatieverzorgen tussen de robot 1 en robot 2 is te zien in figuur 2.2.De Java-code voor de communicatie via de High Speed Radio Turret is te vinden op de bijgele-verde CD in de map ”Communicatie\High Speed Radio Turret\Java-code”.

2.1.6 De C-code voor de robot

Data ontvangen

Het proces op de robot dat inkomende berichten detecteert (Algoritme 2.6), controleert voortdu-rend de ontvangstbuffer op een ontvangen byte8 en indien er een byte gedetecteerd wordt, wordende volgende ontvangen bytes in de juiste volgorde (zie paragraaf 2.1.4) naar juiste variabelengeschreven. Wanneer het volledige bericht ontvangen is, worden de drie ontvangen berichtnum-mers vergeleken met elkaar en indien ze dezelfde zijn, wordt een ACK-bericht verzonden naarde PC.

8m.b.v. de ingebouwde functie ser receive byte()


Algoritme 2.6 Het proces dat instaat voor het ontvangen van boodschappen op de robot1: loop2: while !(incoming byte) do3: read buffer4: end while5: controlByte = incoming byte6: if (controlByte == 126) then7: while !(incoming byte) do8: read buffer9: end while

10: sizeBuffer = incoming byte11: for (0 ≤ i < sizeBuffer − 2) do12: while !(incoming byte) do13: read buffer14: end while15: msgBuffer[i] = incoming byte16: end for17: if (msgBuffer[0] == 0) then18: robotNrSndr = msgBuffer[1]19: msgNr1 = msgBuffer[2]20: msgNr2 = msgBuffer[3]21: msgNr3 = msgBuffer[4]22: save real data from received message23: if (msgNr1 == msgNr2) AND (msgNr2 == msgNr3) then24: sendAck(msgNr1)25: if (msgNr1 > msgNrPrev) then26: msgNrPrev = msgNr127: process message28: end if29: end if30: else if (msgBuffer[0] == 1) then31: msgNr1 = msgBuffer[1]32: ackReceived = msgNr133: end if34: else35: receive message (read till linefeed) and discard it36: end if37: end loop


Data versturen

Door het oproepen van de sendRobot()-functie (Algoritme 2.7), zal data verstuurd worden naaralle andere robots via het broadcast-mechanisme op de PC. Eerst wordt het bericht opgebouwdzoals we besproken hebben in paragraaf 2.1.4. Vervolgens wordt het volledige bericht als byte-array verzonden met de ingebouwde functie ser_send_buffer(). Ten slotte wordt er gewachtop een ACK van de PC, die aangeeft dat het bericht correct9 naar alle andere robots is verstuurd.

Algoritme 2.7 De functie die instaat voor het verzenden van boodschappen op de robot1: buffer[0] = 1262: buffer[1] = size of message3: buffer[2] = 04: buffer[3] = own ID5: buffer[4] = msgNr6: msgNr + +7: convert 3 uint32’s (data0, data1, data2) to byte-array data[]8: save data[] in buffer[]9: com reserve channel()

10: com send buffer(buffer, buffer[1])11: com release channel()12: while !(correct ack received) do13: if (time-out occurred) then14: com reserve channel()15: com send buffer(buffer, buffer[1])16: com release channel()17: end if18: end while

De C-code voor de communicatie via de High Speed Radio Turret is te vinden op de bijge-leverde CD in de map ”Communicatie\High Speed Radio Turret\C-code”.

2.1.7 Evaluatie van de High Speed Radio Turret

Het communicatieprotocol voor de High Speed Radio Turret werd ontwikkeld in het begin vandeze scriptie . Betrouwbare communicatie tussen de robots via de PC om werd echter pas in deeindfase van dit onderzoek gerealiseerd. Het perfect betrouwbaar10 maken van deze communi-catie hield het optimaliseren in van heel wat parameters (bv. de tijd die we inbouwen voor eentime-out optreedt en een boodschap opnieuw verstuurd wordt). Aangezien ons de tijd ontbrakom dit iteratief proces te vervolledigen, werd besloten om de Radio Turret aan te schaffen voorde Khepera II ’s. De Radio Turret ondersteunt rechtstreekse communicatie tussen robots en duswas het implementeren van een communicatieprotocol voor deze turret een stuk eenvoudiger.We bespreken deze vorm van communicatie in paragraaf 2.2.Zoals reeds hierboven vermeld, werd uiteindelijk toch betrouwbare communicatie gerealiseerd

9Dit houdt in dat de verzonden berichten vanop de PC ook acknowledged zijn door de individuele robots.10Dit houdt in dat boodschappen met voldoende hoge snelheid verzonden moeten kunnen worden en dat zelfs

bij druk dataverkeer elke robot ervan verzekerd moet kunnen zijn dat alle andere robots zijn boodschappenontvangen.


via de High Speed Radio Turret, omdat er op het einde van deze scriptie nog tijd restte om deparameters alsnog te optimaliseren.

Een groot nadeel echter aan het gebruik van de High Speed Radio Turret als communicatie-kanaal tussen de robots is het feit dat er geen printf()-statements11 meer mogen voorkomenin de rest van de code op de Khepera II. Deze informatie ontvingen we van K-Team Corpo-ration zonder verdere uitleg. We weten dan ook niet wat de precieze reden hiervoor is. Deinformatie waarover we beschikken is dat de printf()-boodschappen over hetzelfde kanaal ver-stuurd worden als de communicatieboodschappen die we versturen. Verder weten we ook dat eenprintf()-boodschap heel wat tijd in beslag neemt om te versturen over dit kanaal. Toch vindenwe het onbegrijpelijk dat communicatie via de High Speed Radio Turret de printf()-statementsuitsluit.

11Deze functie wordt gebruikt om gegevens van de robot te kunnen loggen op een PC.


2.2 Communicatie via de Radio Turret

2.2.1 Features van de Radio Turret

De specificaties van de Radio Turret zijn de volgende:

1. Inter-robot communicatie tussen maximaal 32 robots. De beperking tot 32 robots wordtverduidelijkt in paragraaf 2.2.2.

2. Foutdetectie en -correctie.

3. Een bereik tot 10 meter.

4. Een transmissiesnelheid van maximaal 9600 bps. Deze snelheid is echter afhankelijk van degrootte van de berichten en daarom wordt er een typische waarde van 4800 bps opgegeven.De reden hiervoor wordt verduidelijkt in paragraaf 2.2.3.

5. Twee operationele modes: als bijkomend communicatiekanaal of als hoofdkanaal waarbijdeze laatste modus de mogelijkheid biedt tot communicatie met een PC.

Punt 5 verdient enige bijkomende uitleg. De Radio Turret kan op twee verschillende manierengebruikt worden [5, sectie 4.2]:

• Main Communication Channel : In dit geval dienen we ook over een basisstation (deRadio Base [9]) te beschikken. Alle boodschappen die de robots naar elkaar versturen,zullen dan via het basisstation hun bestemming bereiken. Indien dit station verbonden ismet een computer, kan al het verkeer ook geanalyseerd worden op de computer.Er is nog een tweede implicatie. Standaard gebeurt de communicatie tussen robot en PCimmers via het S seriele kanaal. Dit kan zowel via de High Speed Radio Turret (paragraaf2.1) als via de S seriele kabel. Met de Radio Turrets ingesteld als Main CommunicationChannel nemen zij deze taak over en zal bijvoorbeeld het inladen van programma’s via hetbasisstation en de turrets verlopen.

• Extensieturret : In dit geval wordt de Radio Turret gebruikt als een extensieturret. Decommunicatie tussen de robots verloopt nu enkel via hun Radio Turrets zonder dat een pcof basisstation tussenkomt. Elke robot kan alle andere robots die zich binnen het bereik(10 m) van de Radio Turret bevinden, individueel aanspreken. In paragraaf 2.2.2 zullende details van de Radio Turret besproken worden.

We hebben ervoor gekozen om in het kader van deze scriptie de turrets als gewone extensiet-urrets te gebruiken, zodat de optie wegviel om het verkeer te monitoren12 via de Radio Base. Ditwas geen handicap, omdat het communicatieverkeer via de Radio Turrets, indien nodig, steedste monitoren was via de S seriele kabel (en TeraTerm Pro) of via de High Speed Radio Turretop elk van de robots. Het sluit zelfs dichter aan bij de doelstelling van het onderzoek, omdatdeze stelt dat de robots als onafhankelijke eenheden moeten opereren en een centrale eenheid

12Observeren vanop een PC.


zoals de Radio Base of PC dus best vermeden wordt. Bij het falen van het basisstation zou decommunicatie tussen de robots volledig wegvallen, wat meteen de kwetsbaarheid van de eersteconfiguratie aantoont.

2.2.2 Uitzicht van de turret

Sommige functies zoals retransmissie en detectie van verloren boodschappen worden gevisuali-seerd op de radioturret [5, sectie 4.1] via LED’s.

Figuur 2.3: Foto en bovenaanzicht van de radioturret

In figuur 2.3 zien we een bovenaanzicht van de Radio Turret met daarop aangeduid devolgende onderdelen:

1. Reset knop Deze heeft dezelfde functie als de resetknop op de Khepera II -robot.

2. De antenne

3. Rx LED AAN wanneer de turret klaar is om data te ontvangen .

4. Tx LED AAN wanneer de turret data verstuurt.

5. Channel active AAN wanneer de turret een actief radiokanaal heeft gedetecteerd.

6. Seriele kabel (S) connector

7. Dip switches Hiermee kan de modus en het ID van de robot geselecteerd worden

8. Repeat data LED AAN wanneer er data verloren is gegaan (retransmissie van het be-richt).

9. Lost data LED AAN wanneer de data 10 keer herverzonden werd zonder succes (geenACK ontvangen) en het bericht dus als verloren wordt beschouwd.Deze LED is rood van kleur in tegenstelling tot de andere LED’s, die groen zijn.


Modus- en ID-selectie

In deze paragraaf verduidelijken we de modus- en ID-selectie. Deze instelling van de RadioTurret gebeurt via de switches die te zien zijn in figuur 2.3 (nummer 7). Figuur 2.4 toonthiervan een uitvergroting. Hieronder worden de belangrijkste mogelijkheden van deze instellingbesproken.Er zijn 8 switches die naar boven (waarde 1) of naar onder (waarde 0) geschoven kunnen worden.

• Switches 1 tot 5 laten toe om het ID (5 bits = maximaal13 32) in te stellen van de robot.

• Switch 6 bepaalt of de Radio Turret als extensieturret gebruikt wordt (waarde 0) of alsMain Communication Channel (waarde 1). Zoals besproken in sectie 2.2.1, wordt in ditonderzoek altijd voor de eerste optie gekozen: deze switch zal dus altijd op nul moetenstaan.

• Switches 7 en 8 hebben geen betekenis, maar staan standaard op nul.

Op figuur 2.4 zien we dat ID 4 werd gekozen en dat de turret als een extensieturret gebruiktwordt.

Figuur 2.4: Modus- en ID-selector van de Radio Turret

2.2.3 Eigenschappen van de transmissie

Het kanaal is half duplex wat wil zeggen dat er niet tegelijk verzonden en ontvangen kan worden.De turret zal zich standaard in de ontvangst-toestand bevinden, waarbij de turret zal wachtenop binnenkomende boodschappen. Enkel wanneer er data moet verzonden worden, zal de turretoverschakelen op de zend-toestand.De toestand van de Radio Turret wordt gevisualiseerd via de Rx LED en de Tx LED, zichtbaarin figuur 2.3 met de nummers 3 en 4.

Data wordt automatisch verpakt in berichten en die bevatten:

• informatie over het type bericht13Indien gebruik wordt gemaakt van de Radio Base-eenheid, heeft deze altijd ID 0, zodat in dat geval nog

slechts 31 robots gebruikt kunnen worden om te communiceren.


• het ID van de zender

• het ID van de gewenste ontvanger

• lengte van de data

• een checksum voor foutcorrectie

Deze informatie vormt de header van het bericht en bevat de noodzakelijke gegevens om deeigenlijke data foutloos bij de gewenste robot te bezorgen. De ontvanger stuurt een ACK alsde boodschap goed ontvangen is. Enkel wanneer de zender deze ACK ontvangt, beschouwt hijde boodschap als correct verstuurd. Als na een zekere tijd (enkele milliseconden) geen ACKontvangen wordt voor een verzonden bericht, dan beschouwt de zender het bericht als verlorenen genereert hij een time-out. Hierop zal hij het bericht opnieuw versturen en tegelijk de Repeatdata LED aanzetten. Deze cyclus van time-out en retransmissie wordt, indien nodig, tot 10 keerherhaald, waarna de boodschap als definitief verloren beschouwd wordt. In dit laatste geval zalde Lost data LED aanstaan.

De data-encapsulatie en het transmissieprotocol voegen een niet te verwaarlozen vertragingtoe aan het dataverkeer. Dit is echter noodzakelijk om alles correct te laten verlopen. Een berichtbestaat naast de header altijd uit 16 bytes pure data. Als die niet allemaal opgevuld worden,zal de nuttige informatie van het bericht kleiner zijn. De berichten blijven even lang, zodat devertraging en de hoeveelheid toegevoegde informatie dezelfde blijft, ongeacht het aantal nuttigedata-bytes dat de gebruiker wil verzenden. Om de transmissiesnelheid optimaal te benutten, ishet dus beter om de pure data volledig op te vullen tot 16 bytes. Dit verklaart het verschil tussende maximale en de typisch haalbare transmissiesnelheid, die we reeds bespraken in paragraaf2.2.1. Een transmissiesnelheid van 9600 bps is enkel haalbaar als alle boodschappen maximaal(16 bytes) opgevuld zijn. Wanneer dit niet het geval is, zal de transmissiesnelheid lager liggen.In dit laatste geval blijft de overhead per boodschap hetzelfde, maar ligt de nuttige hoeveelheidgetransfereerde informatie lager en bijgevolg ook de nuttige datatransmissiesnelheid.

2.2.4 Communicatie tussen de Khepera II en de Radio Turret

De communicatie tussen de robot en de Radio Turret heeft net als bij de Sonar Turret (zie ookparagraaf 3.3) een master-slave karakter. De robot initieert alle communicatie. Hij vraagt destatus en de inhoud van de ontvangstbuffer op van de Radio Turret en stuurt zelf een boodschapnaar de zendbuffer van de Radio Turret. Bij dit laatste zal de turret de boodschap onmiddellijkversturen, onafhankelijk van het reeds verstuurd zijn van de vorige boodschap. Het zou kunnendat de turret nog volop de boodschap uit zijn zendbuffer aan het versturen is als de robot alweereen nieuwe boodschap in die zendbuffer duwt. Dit kan de communicatie onbetrouwbaar makenen moet dus vermeden worden. Dit kan door eerst de status van de Radio Turret te controlerenvoor een bericht verstuurd wordt.

De communicatie tussen de Khepera II en de Radio Turret gebeurt met behulp van deMSG-module14, die ingebouwd is in de BIOS van de robot [10, sectie MSG]. Het master-slave

14De MSG-module maakt gebruik van het KNET-protocol om te communiceren met extensieturrets. DitKNET-protocol wordt uitgebreid beschreven in hoofdstuk 3.


karakter houdt in dat de robot enkel commando’s kan sturen naar de turret en dat de tur-ret pas informatie zal terugsturen wanneer de robot erom vraagt. Dit gebeurt via de functiemsg_snd_rec_message(msgS, sizeS, msgR, sizeR, rep) waarbij de verschillende argumen-ten duiden op:

• msgS Een pointer naar het begin van de byte-array met data die de robot naar de turretwil sturen.

• sizeS De grootte van de boodschap.

• msgR Een pointer naar het begin van de byte-array waarin het antwoord zal terechtkomendat de turret terugstuurt.

• sizeR De grootte van het antwoord.

• rep Aantal keer dat de robot zal herproberen als er een fout optreedt.

Structuur van het bericht voor de Radio Turret

De algemene structuur van een bericht voor de MSG-module is te zien in tabel 2.1. De eerstetwee bytes vormen de MSG-header. De eerste byte daarvan bevat het ID van de Radio Turretwaarnaar een boodschap verstuurd moet worden en de tweede byte de lengte van die boodschap.Het ID van de Radio Turret is 4 (dit ID werd in de hardware van de Radio Turret geprogram-meerd) en de lengte is afhankelijk van het bericht. Het ID van de Radio Turret mag niet verwardworden met het ID van de robot dat ingesteld kan worden via de ID-selector (paragraaf 2.2.2).Het eerste is intern, opdat de Khepera II een onderscheid zou kunnen maken tussen de verschil-lende extensieturrets. Het laatste is enkel voor de communicatie, opdat de robots zich zoudenkunnen onderscheiden van elkaar.

Tabel 2.1: De algemene vorm van een bericht

Turret ID lengte byte 1 byte 2 ... byte n

Het tweede deel van de boodschap (rechts van de dubbele streep in tabel 2.1) is het turret-afhankelijke deel. De eerste byte van een boodschap van de robot bevat het commando en wordtvoorgesteld door het ascii-karakter dat overeenkomt met deze eerste byte. De eerste byte vanhet bijhorende antwoord van de turret zal altijd het corresponderende kleine karakter zijn. Deeventuele bytes die daarna verstuurd worden tussen de robot en de turret, bevatten parametersvoor het gebruikte commando.

Gebruikte commando’s voor de Radio Turret

Voor deze scriptie zijn slechts vier commando’s belangrijk en die zullen we nu bespreken. Bijelk commando vormen de eerste twee bytes de header (gescheiden door een dubbele streep zoalsin tabel 2.1). In het antwoord is geen header aanwezig.


• Opvragen van het ID

– commando

4 1 c

– antwoord

c eigen ID

Het ’c’-commando vraagt het ID aan van de robot (eigen ID). Dit kan ingesteld wordenvia de ID-selector bovenop de Radio Turret. Als enige commando van de vier gebruiktdeze voor commando en antwoord een kleine letter.

• Versturen van een boodschap

(De bytes met pure data worden van de rest van de boodschap gescheiden door een drie-dubbele streep, waarbij de grootte van dit blok nuttige bytes vervat zit in de byte (size)links van deze driedubbele streep (zie ook paragraaf 2.2.3).)

– commando

4 19 S dest ID size byte 1 byte 2 ... byte 15 byte 16

– antwoord

s

Het berichtonderdeel dat specifiek is voor de Radio Turret (na de dubbele streep) bevathet commando (S ), het ID van de Radio Turret (dest ID) waarnaar gestuurd wordt enhet aantal nuttige bytes (size) in het bericht. Dit commando stuurt een boodschap naarde zendbuffer van de Radio Turret, die op zijn beurt laat weten of de boodschap succesvolgeschreven is in de zendbuffer via het terugsturen van een kleine ’s’. Dit wil niet zeggendat de boodschap correct verstuurd is naar de doelrobot. Om dat te controleren, moet destatusbyte van de Radio Turret opgevraagd worden.Dit commando initieert een duidelijke fire-and-forget actie.

• Opvragen van de ontvangstbuffer

– commando

4 1 R

– antwoord

r source ID size byte 1 byte 2 ... byte 15 byte 16

Hiermee vraagt de robot de ontvangstbuffer aan van de Radio Turret. Die bevat, naasthet ID van de robot die de boodschap stuurde (source ID), ook de nuttige lengte (size)van de boodschap.

• Opvragen van de status

– commando

4 1 F

– antwoord

f status


Het antwoord bevat de 8-bit status van de robot, waarbij de bits de volgende betekenishebben.

– bit 0 (minst significante bit) is 1 als de zendbuffer leeg is en de Radio Turret klaaris om een nieuwe boodschap te verzenden.

– bit 1 is 1 wanneer een nieuwe boodschap in de ontvangstbuffer zit.

– bit 2 is 1 wanneer de boodschap 10 keer zonder succes verstuurd werd en zodanigals verloren beschouwd wordt. Deze bit wordt ook op nul gezet wanneer een nieuwbericht in de zendbuffer terechtkomt.

– bit 3 - 7 Geen betekenis.

Via de eerste drie bits kan er dus een zekere kwaliteitsgarantie in de communicatie inge-bouwd worden. Dit wordt beschreven in paragraaf 2.2.7.

2.2.5 Testopstelling

Figuur 2.5: De testopstelling voor de communicatie

De communicatie moet in de eerste plaats betrouwbaar zijn. Dit wordt voor een deel doorde Radio Turret zelf verzorgd door de boodschappen uit te breiden met extra informatie voorfoutdetectie en -correctie en met een ACK-mechanisme.De testopstelling om de betrouwbaarheid te testen van de ingebouwde mechanismen is te zien infiguur 2.5, waarbij de drie robots in elkaars buurt staan. Een robot zal voortdurend controlerenof er boodschappen binnenkomen. In de testopstelling is dit de robot met ID 1. De andere robotszullen voortdurend boodschappen (elk in totaal 256) sturen naar die ene robot. Elk zullen zetwee verschillende boodschappen continu afwisselen zodat makkelijk kan nagegaan worden op de


ontvangende robot of er iets fout gaat. De boodschappen bevatten enkel een serienummer15 eneen reeks getallen die allemaal hetzelfde zijn. Elke robot houdt een eigen serienummer bij voorzijn boodschappen, zodat voor elke robot meteen gezien kan worden of boodschappen herhaaldwerden of verloren gegaan zijn. Naast het zenden of ontvangen van berichten loopt er ook nogeen parallel proces op elk van de robots dat elke halve seconde een LED zal doen veranderenvan toestand (aan/uit).

2.2.6 Communicatie in de testopstelling zonder QoS

Hieronder staan de programma’s aan de zender- en ontvangerszijde beschreven in pseudocodewaarbij we geen gebruik maken van extra QoS16. De gebruikte commando’s van de Radio Turretwerden uitgebreid besproken in paragraaf 2.2.4.

Ontvangerszijde

Aan de ontvangerszijde wordt bijgehouden welke robot (ID) het laatst een bericht stuurde enmet welk serienummer (SN). De robot controleert voortdurend de ontvangstbuffer en als hetserienummer, het ID van de zendende robot of beide veranderen, zal dit geınterpreteerd wordenals de ontvangst van een nieuw bericht.

Algoritme 2.8 Ontvangerszijde zonder QoS1: loop2: Read reception buffer3: if ( current SN 6= previous SN or current ID 6= previous ID ) then4: Message received from robot current ID with serial number current SN5: previous SN = current SN6: previous ID = current ID7: end if8: end loop

Zenderzijde

Elke robot stuurt afwisselend twee verschillende boodschappen naar de luisterende robot metID 1. Dit wordt getoond in figuur 2.5. Ze doen dit zo snel als hun hardware hen toelaat. Hetserienummer wordt, voor het versturen van een nieuwe boodschap, met 1 verhoogd zoals te zienis in algoritme 2.9.

De C-code voor de communicatie zonder QoS via de Radio Turret is te vinden op de bijge-leverde CD in de map ”Communication\Radio Turret\without QoS”.

15Dit serienummer is 1 bij het eerst verzonden bericht en incrementeert elke keer er een nieuw bericht verzondenwordt.

16QoS = Quality of Service, extra mechanismen in de communicatiestructuur die er zullen voor zorgen dat decommunicatie betrouwbaarder wordt.


Algoritme 2.9 Zenderzijde zonder QoS voor robot 21: SN = 02: loop3: Send message {SN, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1} to the Radio Turret4: SN + +5: Send message {SN, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2} to the Radio Turret6: SN + +7: end loop

Evaluatie

In tabel 2.2 is het resultaat van een experiment te vinden met enkele opeenvolgende boodschap-pen die robot 1 ontvangen heeft van robots 2 en 3. Normaal moeten de serienummers voor elkerobot mooi oplopend zijn. Dit is duidelijk niet het geval. Voor elke ontvangen boodschap vanrobot 3 gaan er drie of meer verloren, terwijl de boodschappen van robot 2 amper tussen deberichten van robot 3 raken. Het hoge aantal verloren boodschappen is slechts een aspect; ookde integriteit van de boodschappen wordt niet gewaarborgd. In principe moet elke boodschapuit een en het hetzelfde cijfer bestaan, maar in de tabel is te zien dat boodschappen in elkaaroverlopen. Het is duidelijk dat het sturen en ontvangen op deze manier niet betrouwbaar is endat de mechanismen, beschreven in paragraaf 2.2.1, ontoereikend zijn.

Tabel 2.2: Ontvangen berichten zonder QoS

ontvangen bericht van robot met serienummer

4,4,4,4,4,4,4,3,3,3,3,3,3,3,3 3 614,4,4,4,4,4,4,4,4,4,4,4,4,4,4 3 654,4,4,4,4,4,4,4,4,4,4,4,4,4,4 3 693,3,4,4,4,4,4,4,4,4,4,4,4,4,4 3 723,3,3,3,3,3,3,3,3,3,3,3,3,3,3 3 761,1,1,1,1,2,2,2,2,2,2,2,2,2,2 2 2024,4,4,4,4,4,4,4,4,4,4,4,4,2,2 3 834,4,4,4,4,4,4,4,4,4,4,4,4,4,4 3 873,3,3,3,3,3,3,3,3,3,3,3,3,3,4 3 903,3,3,3,3,3,3,3,3,3,3,3,3,3,4 3 944,4,4,4,4,4,4,4,3,3,3,3,3,3,3 3 97

2.2.7 Communicatie in de testopstelling na het inbouwen van QoS

Om de tekortkomingen uit de vorige paragraaf op te vangen, kan een beroep gedaan worden opde statusbyte van de Radio Turret. Het commando om deze byte op te vragen en de betekenisvan de afzonderlijke bits werd reeds beschreven in paragraaf 2.2.4.


Ontvangerszijde

Aan de ontvangerszijde is er slechts een statusbit van belang, namelijk bit1 die op 1 wordt gezetals er een nieuwe boodschap in de ontvangstbuffer zit. De robot zal de statusbyte van de RadioTurret opvragen tot bit1 op 1 staat. Pas daarna zal de ontvangstbuffer opgevraagd worden. Deboodschappen zouden hierdoor niet meer in elkaar mogen overlopen.

Bij druk radioverkeer bleek dat boodschappen vaak herverstuurd werden en na elkaar in deontvangstbuffer terechtkwamen. Dit doet vermoeden dat er vaak iets fout loopt met de ACK diede ontvanger terugstuurt. In dit geval zal de zender vaak onnodig boodschappen herversturen.De Radio Turret van de ontvanger aanziet die duplicaten dus onterecht als nieuwe berichten.Daarom wordt het ID van de robot die het laatst een bericht stuurde bijgehouden en ookhet bijhorende serienummer (SN), zodat duplicaten die net na elkaar toekomen er uitgefilterdkunnen worden. Als er zich een andere boodschap tussen bevindt, zal deze eenvoudige filteringniet werken, maar met een verstandig gebruik van het serienummer, zijn die toch gemakkelijkop te sporen. Als het serienummer monotoon stijgt bij elke nieuwe boodschap, kunnen alleboodschappen met een lager of gelijk serienummer genegeerd worden. De pseudo-code wordtweergegeven in algoritme 2.10.

Algoritme 2.10 Ontvangerszijde met QoS1: loop2: repeat3: Read the 8 bit status of the Radio Turret4: until (bit1 == 1)

5: Read reception buffer6: if ( current SN 6= previous SN or current ID 6= previous ID ) then7: Message received from robot current ID with serial number current SN8: previous SN = current SN9: previous ID = current ID

10: end if11: end loop

Zenderzijde

Aan de zenderzijde zijn er twee bits van de statusbyte die voor een QoS kunnen zorgen. Bit0controleert of de zendbuffer leeg is en desgevallend kan een nieuwe boodschap naar de RadioTurret verstuurd worden. Dit is het duale geval als bij de ontvanger. Via bit2 kan gecontroleerdworden of de verzonden boodschap verloren is gegaan. Na het sturen van een bericht naar dezendbuffer, wordt de statusbyte gecontroleerd tot bit0 terug 1 is en er opnieuw gezonden magworden. Als tegelijk ook bit2 1 is, weet de robot dat het laatste bericht verloren is gegaan. Alsbit2 nul blijft, is de boodschap correct toegekomen. Het volledige proces van het zenden wordtin een aparte functie gestopt die −1 teruggeeft wanneer het bericht verloren is gegaan.

Het programma aan de zenderzijde valt op die manier uiteen in 2 delen. Ten eerste is er dezendfunctie zelf (sendRobot()), die de boodschap als argument meekrijgt en een waarde terug-geeft, zodat de robot weet of een boodschap al dan niet verloren is gegaan. Dit staat beschreven


Algoritme 2.11 Zenderzijde met QoS voor robot 31: SN = 02: loop3: repeat4: Send message {SN, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3} with sendRobot()5: until (sendRobot() == 0)6: SN + +

7: repeat8: Send message {SN, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4} with sendRobot()9: until (sendRobot() == 0)

10: SN + +11: end loop

in algoritme 2.12.Het andere deel is het hoofdprogramma zoals te zien in algoritme 2.11. Hier zullen de bood-schappen geschreven worden en daarna verstuurd worden via sendRobot(). Het versturen metsendRobot() wordt herhaald tot die 0 teruggeeft.

Algoritme 2.12 Zendfunctie met QoS: sendRobot()1: repeat2: Read the 8 bit status of the Radio Turret3: until (bit0 == 1)

4: Send message to the Radio Turret

5: repeat6: Read the 8 bit status of the Radio Turret7: until (bit0 == 1) {Message sent}

8: if (bit2 == 1) then9: return −1 {Message lost}

10: else11: return 0 {Message sent successfully}12: end if

De C-code voor de communicatie met QoS via de Radio Turret is te vinden op de bijgeleverdeCD in de map ”Communication\Radio Turret\with QoS”.

Evaluatie

De test met de opstelling uit figuur 2.5 werd een aantal keer uitgevoerd. Eerst met een zendendeen een ontvangende robot. In deze configuratie gingen er geen berichten verloren en moestener zelfs geen herverstuurd worden. De ingebouwde kwaliteitsgaranties bleken in dit geval dusvoldoende. De ontvangende robot kon de toestroom van berichten dus perfect binnenhalen enverwerken aan het tempo dat de andere robot zendde. De integriteit van de boodschappenbleek geen probleem meer te zijn, want nergens werd het verschijnsel van in elkaar overlopendeboodschappen nog waargenomen. Het probleem bleek dus volledig opgelost met de genomen


maatregelen.

Als de derde robot ook geactiveerd werd en boodschappen verstuurde, werd het ganse plaatjewat minder rooskleurig. Ten eerste bleek de robot met ID 3 dominanter te zijn dan die metID 2. Robot 3 slaagde er immers in om zijn boodschappen zonder veel retransmissies door testuren, terwijl robot 2 er maar af en toe in slaagde om een boodschap correct te verzenden. Alsrobot 3 zijn 256 boodschappen verstuurd had, kon robot 2 weer probleemloos boodschappenverzenden zonder dat er zelfs retransmissies nodig waren. Dit bevestigde opnieuw dat com-municatie met maar twee robots en alle ingebouwde veiligheden foutloos verloopt. Als beiderobots tegelijk communiceerden, gingen er soms geen, vaak twee of drie en maximaal zeven ofacht boodschappen verloren. Een oplossing waarbij robots niet tegelijk mogen zenden staatbeschreven in paragraaf 2.5.2.

Dit duidt er dus op dat de ingestelde veiligheidsmechanismen nog ontoereikend zijn voorde communicatie met meer dan twee robots. Het probleem is dat de verloren boodschappendoor de ontvangende robot moeten bevestigd zijn met een ACK, omdat de zendende robotanders de boodschap herverstuurd zou hebben. De fout ligt dus hoogstwaarschijnlijk bij deontvangende robot die de boodschappen uit de ontvangstbuffer niet snel genoeg uitleest, zodatdie al overschreven kunnen worden door een bericht van een derde robot.Een tweede mogelijkheid is dat er iets foutloopt in de communicatie (via de KNET-bus) tussen deKhepera II en de Radio Turret, net zoals bij de Sonar Turret ook soms het geval was (hoofdstuk3). Dit gebeurde heel sporadisch, maar toch lijkt de belofte van K-Team Corporation, beschrevenin paragraaf 2.2.1, dat inter-robot communicatie mogelijk is met 32 robots wat onrealistisch, zelfsmet de veiligheidsmechanismen die tot hiertoe werden ingebouwd.

Er moet wel een belangrijke kanttekening gemaakt worden bij de observaties van de voor-gaande paragraaf. Er gaan inderdaad nog boodschappen verloren, maar de test ging dan ook uitvan een worst-case scenario met robots die continu boodschappen versturen. Het is niet onlo-gisch dat een robot slechts de stroom berichten van een andere robot op maximale zendsnelheidaankan. Als er meer robots in het spel zijn, die elk zo snel mogelijk zenden, zal, door de veleretransmissies, de uiteindelijke datatransmissiesnelheid veel lager liggen dan in het geval dat erslechts een robot zendt en een ontvangt.

Dit heeft een belangrijke implicatie op de mogelijke toepassingen van de communicatie. Hetzal bijvoorbeeld onmogelijk zijn de robots voortdurend gegevens te laten uitwisselen om zo deandere robots te monitoren. Een permanente interactie tussen drie robots via communicatie,waarbij ze hun gedrag voortdurend aanpassen aan dat van de andere is dus een utopie.

Dit hoeft niet noodzakelijk een zware beperking te zijn. De communicatie is immers eenuitstekend middel om afspraken te maken tussen de robots onderling, waarna ze elk hun eigenprogramma volgen tot de nood aan nieuwe afspraken zich manifesteert. Het aantal verzondenboodschappen zal per sessie nooit echt hoog liggen, zodat een verzadiging van het medium nooitlang kan duren. De veiligheden die ingebouwd zijn, blijken voor deze niet-intensieve vorm vancommunicatie te volstaan. Verloren boodschappen die niet gedetecteerd werden, kwamen nietmeer voor en de communicatie kon dus als betrouwbaar beschouwd worden.


2.3 Algemene Communicatiestructuur

Tot hiertoe werd enkel besproken hoe de communicatie tussen de robots verloopt en hoe dezebetrouwbaar gemaakt wordt. De communicatiestructuur voor de robots zoals beschreven in dezeparagraaf zal voor een deel specifiek zijn aan de berichtstructuur van de Radio Turrets, maar ditgeldt enkel voor de concrete implementatie. De concepten zoals een vaste berichtstructuur, hetbufferen en verpakken van berichten zijn algemeen toepasbaar voor andere communicatievormen,zoals die met de High Speed Radio Turret (paragraaf 2.1).

2.3.1 Vaste berichtstructuur

Bij de Radio Turrets werd in het voorgaande deel enkel het rauwe bericht beschouwd dat bestaatuit 16 bytes data. Deze bytes zijn unsigned17, maar er kan ook afgesproken worden dat eengroepje bytes samen een groter getal vormt. Een typische groepering bestaat uit 2 bytes (uint16)of 4 bytes (uint32)18, maar ook decimale getallen zouden voorgesteld kunnen worden door eenaantal bytes. De afspraak om bytes te groeperen kan nu op twee verschillende manieren gebeuren:

• zonder vaste structuur: Indeling van de 16 bytes in groepjes verschillend voor elkeandere boodschap.

• met vaste structuur: Indeling voor alle boodschappen gelijk.

Het probleem met de eerste optie is dat de ontvanger zal moeten kunnen detecteren hoe de16 bytes data ingedeeld zijn in groepjes. Hij zal hiervoor extra informatie nodig hebben diewe dus ook zullen moeten verwerken in de 16 bytes die we ter beschikking hebben. Concreethoudt dit in dat we enkele bytes zullen moeten reserveren waarmee de zender aan de ontvangerkan duidelijk maken hoe het huidige bericht ingedeeld is. Hierdoor verliezen we dus kostbarebytes, zodat we voor eenzelfde hoeveelheid informatie uiteindelijk meer berichten zullen moetenversturen.

We zullen bijgevolg gebruik maken van de tweede optie, waarbij we elk bericht een vastestructuur geven. Deze structuur bestaat uit twee grote delen: de header en de pure data.Elk bericht dat binnenkomt, kan onmiddellijk ontleed en verwerkt worden aan de hand vande headerinformatie. Die heeft dezelfde vorm voor elk bericht. Eenvoudige velden zoals hetserienummer en het functienummer kunnen het behandelen van een bericht veel eenvoudiger ensneller maken. De header gebruikt een deel van de byte-ruimte die voor zuivere data bedoeld is,zodat uiteindelijk minder zuivere data verstuurd kan worden per bericht, maar de flexibiliteitdie een header met zich meebrengt is te belangrijk om er geen te gebruiken.

Een groot voordeel van de Khepera II -robots is dat ze in staat zijn met parallelle processen tewerken [11, sectie 2.1]. Hierbij kiezen we ervoor om een proces voortdurend de ontvangstbuffer te

17Een byte bestaat uit 8 bits en als de byte unsigned is, kan hij waarden aannemen van 0 tot 255.18De 16 en 32 slaan op het aantal bits waarmee de integer gerepresenteerd wordt. Het zijn altijd veelvouden

van acht omdat ze uit een paar bytes zullen bestaan en deze bevatten 8 bits. Als er een ’u’ voor staat, is het getalunsigned.


laten lezen en een eerste verwerking te laten doen, waarna de rest van de verwerking afgehandeldwordt door een ander proces. Het ontvangend proces kan zo meteen weer verder gaan met zijnkerntaak: het lezen van de ontvangstbuffer. Als de volledige verwerking in het ontvangendproces zou gebeuren en dit te lang zou duren, zouden nieuwe berichten niet vlug verwerktkunnen worden. Een vaste structuur laat gemakkelijk toe om een opsplitsing te maken tusseneen ontvangend en een verwerkend proces. Het ontvangend proces verwerkt de header, waarnahet afhandelen van de data wordt overgelaten aan het verwerkend proces.

Naast de header kan voor elk bericht ook vastgelegd worden hoe de bytes in het pure data-gedeelte gegroepeerd zullen zijn tot grotere eenheden. Het voordeel is dat de verwerking van dedata altijd op dezelfde manier gebeurt. Het nadeel is dat bepaalde informatie minder efficientopgeslagen wordt, zodat de beschikbare bytes niet optimaal benut worden. De lengte van deberichten ligt bij de Radio Turrets vast en daardoor wordt het aanlokkelijk om de groeperingenop voorhand vast te leggen. In de uiteindelijke berichtstructuur die hieronder beschreven wordt,werd getracht om een evenwicht te vinden tussen groeperingen van bytes en afzonderlijk bytes,opdat de structuur zowel flexibel als algemeen toepasbaar zou zijn.

De berichtstructuur

Tabel 2.3: Algemene berichtstructuur

SN functieNr byte 1 byte 2 uint32 -1 uint32 -2 uint32 -3

Elk bericht bestaat uit de volgende onderdelen:

• SN Het serienummer dat toelaat om retransmissies er uit te filteren.

• functieNr Deze byte laat toe te specifieren welke functie de daaropvolgende data-byteshebben.

• 2 extra bytes Deze bytes worden gebruikt om kleine waarden in op te slaan.

• 3 uint32’s Deze uint32’s worden gebruikt om grote waarden in op te slaan.

De oorspronkelijke 16 bytes worden gereduceerd tot zeven informatieve cellen. Daarvanvormen de eerste twee de header, die bedoeld is om het verwerken gemakkelijk te maken voorhet ontvangend proces.Het serienummer van een bericht kan algemeen opgeslagen worden, waarbij enkel gecontroleerdkan worden of het serienummer verandert tegenover een vorig bericht (zonder dat hierbij het IDvan de verzender in rekening wordt gebracht), zoals in algoritmes 2.8 en 2.10, maar het kan ookmet een uitgebreid geheugen werken. Hierbij wordt voor elke sturende robot het serienummerbijgehouden van zijn laatste bericht. De manier waarop dit wordt opgeslagen, staat beschreven inparagraaf 2.3.3. Hierdoor zal de filtering veel strikter gebeuren, omdat per robot een onderscheidgemaakt kan worden tussen nieuwe berichten, herverzonden berichten en vervormde berichten.Hoe het precies werkt voor de eerste twee komt terug in de volgende paragraaf.


De categorie van vervormde berichten is erg zeldzaam, maar toch kunnen ze met een vervormdfunctienummer op het verkeerde moment het gedrag van een robot grondig in de war sturen.De tweede byte in de header stelt het functienummer voor dat voor een eerste opsplitsing zorgt,zodat er met de rest van de data kan omgesprongen worden op een manier die eigen is aan defunctie.

Het tweede aspect van de vaste structuur betrof het groeperen van de pure data-bytes. Degrootste eenheid voor integers bij de Khepera II -robots bestaat uit 32 bits en het lag voor dehand om die als eenheid te nemen voor het doorsturen van data. Door de twee headerbyteswas er slechts plaats voor drie van deze uint32 waarna er nog twee bytes overbleven van de16. Die laatste twee zullen gebruikt worden om kleine stukjes extra informatie door te geven,zoals bijvoorbeeld het teken van een uint32. Dit kan nodig zijn, omdat negatieve getallen nietkunnen worden doorgestuurd aangezien alle doorgegestuurde waarden unsigned zijn.

Om de overgang van de vaste berichtstructuur naar de uiteindelijke fysische communicatiete realiseren, moet een zekere functionaliteit ingebouwd worden. Die wordt in de volgende tweeparagrafen beschreven.

2.3.2 Verpakken van boodschappen

De hoofdtaak van de inpakfunctie bestaat erin om de zeven informatievelden die beschrevenwerden in de vorige paragraaf om te zetten in de 16 bytes van het eigenlijke bericht dat naar deRadio Turret gestuurd zal worden. De eerste vier informatievelden (serienummer, functienum-mer en twee extra bytes) zijn al van het type byte en kunnen rechtstreeks in de uiteindelijkebyte-rij geschreven worden. De drie uint32 zullen via modulorekenen omgezet worden in telkensvier bytes. Het omzetten kan ook gerealiseerd worden met een 8-bit masker (acht keer ‘1’), datvier bytes uit de uint32 filtert (door de AND-functie te nemen van het masker en de uint32).

Het uitpakken van een bericht van de Radio Turret verloopt op dezelfde manier, maar danin de omgekeerde richting, waarbij de laatste twaalf bytes per vier weer omgezet worden in eenuint32.

Het inpakken heeft ook nog een tweede functie: het zal ervoor zorgen dat elk bericht het goedeserienummer meekrijgt. Dit serienummer vormt dus geen argument van de functie packMsg(),maar maakt gebruik van de bufferstructuur die aanwezig is in de software. Die zal in de volgendeparagraaf beschreven worden; het volstaat te weten dat de robot, voor elke andere robot waar-naar hij boodschappen stuurt, het serienummer bijhoudt van de laatst verzonden boodschap.Als de functie packMsg() wordt opgeroepen, zal de robot het serienummer bij de goede robotautomatisch met een verhogen. Zolang de packMsg()-functie niet opgeroepen wordt, zal ditserienummer niet verhogen en zal de vorige boodschap (die hoort bij dit serienummer) bewaardblijven in een buffer, zodat het bericht eventueel herverzonden kan worden.

In de volgende paragraaf wordt wat dieper ingegaan op de buffers.


2.3.3 Boodschappen bufferen

De buffers zijn in feite niets meer dan twee matrices. Een matrix waarin we de ontvangenboodschappen bufferen en een waarin we de verstuurde boodschappen opslaan.Het aantal rijen is gelijk aan het totale aantal robots dat op dat moment binnen het RadioTurret-bereik is van de robot.

Als er een boodschap verstuurd wordt naar een andere robot, zullen de zeven informatie-velden van een bericht, die beschreven staan in paragraaf 2.3.1, in de zeven kolommen van dematrix gestopt worden. Dit zal gebeuren in de rij die overeenkomt met het ID van de robotwaarnaar gestuurd wordt.

Bij een ontvangen bericht is de situatie volkomen duaal. De informatievelden worden opge-slaan in de rij die overeenkomt met het ID van de zendende robot. De rij met het ID van derobot zelf zal natuurlijk nooit ingevuld worden.

Er zijn meerdere voordelen aan dit buffersysteem. Ten eerste maakt de functie packMsg()

hiervan gebruik om het serienummer van te verzenden berichten aan te passen en op te slaan.Ten tweede wordt de binnenkomende data meteen beschikbaar en bereikbaar voor alle parallelleprocessen die erop wachten. Hierdoor kan de afhandeling van de eigenlijke data van de bood-schap door een ander proces gebeuren dan het proces dat boodschappen ontvangt, zodat hetontvangend proces weer kan doorgaan met de controle op nieuwe berichten.

Om dit alles te verduidelijken wordt een voorbeeld gegeven van een situatie afkomstig uit detestopstelling die te zien is in figuur 2.5. De matrix voor inkomende berichten wordt weergegevenvan de robot met ID 1 voor en na het ontvangen van een nieuwe boodschap van robot 3.

Tabel 2.4: Buffer voor inkomende berichten: initiele toestand


0 0 0 0 0 0 0

30 10 1 1 1 1 1

133 5 4 4 4 4 4

Tabel 2.5: Buffer voor inkomende berichten: nieuw bericht van robot 3 ontvangen


0 0 0 0 0 0 0

30 10 1 1 1 1 1

134 12 3 3 3 3 3

Zoals te zien is in de tweede tabel verandert de derde rij (in vet) omdat er een nieuweboodschap is van robot 3.


2.3.4 Evaluatie

Deze communicatiestructuur vormt de ruggengraat bij het inbouwen van QoS. Ze ondersteuntde initieel geımplementeerde QoS (paragraaf 2.2.7), die enkel gebaseerd was op de statusbytevan de Radio Turret. Door de flexibiliteit van het systeem kan dezelfde communicatiestructuurzonder problemen gebruikt worden om een verhoogde QoS te implementeren, zoals we zullenbespreken in paragraaf 2.4. De zenden ontvangstfuncties dienen aangepast te worden, maarhet verpakken, bufferen en indelen van een bericht kunnen blijven.In de toekomst kan nog extra functionaliteit ingebouwd worden zoals het opvangen van nieuwerobots, robots die herstarten of wegvallen... Dit alles kan gerealiseerd worden met de hierbovenbeschreven communicatiestructuur, zoals zal blijken in paragraaf 2.5.1.

Het belangrijkste minpunt is de vaste lengte van boodschappen, maar dit is eigen aan deRadio Turret die met dergelijke berichten werkt. Het algemene concept voor een communica-tiestructuur via berichten met variabele lengte is net hetzelfde, maar de buffering van berichtendient te gebeuren met behulp van matrices met een dynamische lengte.


2.4 Uitbreiden van QoS

In paragraaf 2.2.7 was de statusbyte van de Radio Turret de basis om kwaliteitsgaranties in tebouwen. De statusbyte laat toe drie zaken te controleren:

• Het beschikbaar zijn van de Radio Turret om te zenden (bit0)

• Het beschikbaar zijn van de Radio Turret om te ontvangen (bit1)

• Verloren gegane boodschappen (bit2)

Er zijn twee soorten observaties waaruit bleek dat deze drie controlebits toch niet voldoendewaren.Ten eerste konden er bij druk verkeer toch nog boodschappen verloren gaan, zoals bleek in pa-ragraaf 2.2.7.Ten tweede zijn er observaties waarbij de robots een half uur probleemloos hun algoritme uitvoe-ren, waarbij relatief weinig communicatie nodig is en waarbij toch plots enkele boodschappenna elkaar om onverklaarbare redenen verloren gaan. De zendende robot denkt dat zijn bood-schappen zijn toegekomen, maar de andere heeft ze nooit ontvangen. Met de huidige QoS kandit niet opgevangen worden.Hoe zeldzaam deze observaties ook zijn, toch waren de gevolgen voor het verloop van het algo-ritme dat de robots uitvoerden, meestal dramatisch. Vaak wachtte een robot op input van eenandere en aangezien die informatie nooit meer kon komen, omdat de andere robot dacht dat zijnboodschap was toegekomen, zat de hele formatie in een deadlock.Wegens deze problemen werd ervoor gekozen om extra veiligheden in de communicatie in tebouwen.

2.4.1 Werking

Het detecteren van definitief verloren berichten zal niet meer door de Radio Turret afgehandeldworden, maar door de software op de robot zelf, door middel van time-outs and ACK-berichten.Ook de Radio Turret zelf werkt met time-outs en ACK’s, maar dit gebeurt zonder dat desoftware op de robot hierin kan tussenkomen. Aangezien er blijkbaar toch berichten kunnenverloren gaan, zullen we dit mechanisme in de software van de robot zelf implementeren, zodatwe er meer controle over hebben.

Het principe is als volgt. Een robot stuurt een bericht en start een timer. Als er binnen eenzeker tijdsinterval (enkele milliseconden) geen ACK voor het verzonden bericht is ontvangen,dan verloopt de timer en wordt een time-out gegenereerd. In dit geval zendt de robot dezelfdeboodschap - met hetzelfde serienummer - opnieuw. Als er wel een ACK binnenkomt, gaat derobot verder met zijn programma tot er een nieuw bericht verzonden moet worden, waarbij hetserienummer verhoogd wordt.


Loskoppelen van ACK-verkeer

Indien een bericht ontvangen wordt, stuurt de robot een ACK terug. Dit gebeurt zonder eentime-out-mechanisme, hoewel ook ACK’s verloren kunnen gaan. De achterliggende visie hierbijis dat de zendende robot zijn bericht maar moet herversturen als de ACK verloren gaat en hij dusgeen ACK ontvangt. Dit maakt de ACK-structuur eenvoudiger dan het normale dataverkeer.We krijgen bijgevolg een opsplitsing van het verkeer in verschillende stromen waarbij het ACK-verkeer volgens andere regels verstuurd wordt dan het dataverkeer.De ACK wordt verstuurd volgens best-effort principe. Een robot verstuurt een ACK als hij eendatabericht ontvangen, maar kijkt er verder niet meer naar om. Dit in tegenstelling tot hetdataverkeer waarbij de robot pas een volgend bericht zal versturen indien hij zeker is dat hetvorige goed ontvangen is.

Er is nog een tweede reden om het ACK-verkeer los te koppelen van het dataverkeer en datis het serienummer. Bij het dataverkeer zullen berichten ingepakt en uitgepakt worden. Hetserienummer zal daarbij automatisch verhogen en boodschappen zullen opgeslagen worden inde buffers. Zo kan een ontvangende robot filteren op het serienummer. Als de robot een be-richt binnenkrijgt met hetzelfde serienummer, dan weet hij dat het een retransmissie is. Als hetserienummer een hoger is, gaat het over een nieuw bericht (paragraaf 2.3.2). Als ACK’s in dit-zelfde systeem betrokken werden, zouden ze de strikte filtering met het serienummer onmogelijkmaken. Dit wordt duidelijk met figuur 2.6. Hierin sturen twee robots tegelijk een bericht naar

Figuur 2.6: ACK die verloren gaat als dataverkeer

elkaar (volle pijlen). Ze ontvangen deze ongeveer op hetzelfde moment en sturen beide een ACK(gestreepte pijlen) voor het ontvangen bericht. Stel dat de ACK met serienummer 6 verlorengaat (dit is een ACK-bericht voor het bericht dat verstuurd werd vanop de robot met ID 2 enhet serienummer 13 had). Dan zal de robot met ID 2 het bericht met serienummer 13 opnieuwdoorsturen op het moment dat zijn timer is afgelopen. Dit is echter onmogelijk geworden, omdater nu een ander bericht (ACK met SN 14) in zijn buffer zit in plaats van het bericht met SN 13.Bovendien is ook het serienummer van de berichten naar de robot met ID 1 al verhoogd, aan-gezien we het ACK-bericht voor bericht met serienummer 5 ook een serienummer (14) gegeven


hebben.Omdat de robot met ID 1 een filtering toepast op de inkomende berichten, waarbij enkel be-richten met een serienummer gelijk aan of een hoger dan het huidige serienummer in de bufferaanvaard worden, zal het herverzonden bericht met serienummer 13 niet meer door deze filteringgeraken (aangezien het huidige serienummer reeds op 14 staat, door de ACK voor boodschapSN 5 die ook een serienummer gekregen heeft).

De strenge filtering kan weggelaten worden, maar op die manier vervalt een belangrijk vei-ligheidsmechanisme.Daarom hebben we voor een andere oplossing gekozen. Indien we de ACK niet inpakken ofbufferen, waardoor het serienummer niet verhoogt, verdwijnt het filterprobleem dat we hierbo-ven beschreven. De ACK’s staan op die manier los van de andere berichten en zullen verstuurdworden via sendRobot() beschreven in algoritme 2.12.

Processen

De Khepera II -robot ondersteunt parallelle processen. Hiervan werd eerder al gebruik gemaaktdoor de opsplitsing in een ontvangend en verwerkend proces (paragraaf 2.3.1). In het geval vanACK’s hebben we opnieuw een ontvangend en een verwerkend proces. Het ontvangen van ACK’smaakt deel uit van het globaal ontvangend proces dat voortdurend de Radio Turret controleertop nieuwe boodschappen en elke nieuwe boodschap naar functie indeelt. Het tweede proces zalinstaan voor de verdere verwerking van de data en het algoritme van de robot.

Met het invoeren van het ACK-verkeer, hebben we ook nog een derde proces geımplementeerddat enkel instaat voor het versturen van ACK’s en dit doet de robot wanneer een bericht van eenandere robot ontvangen wordt. Het voordeel van het ontkoppelen van deze twee taken (nieuweboodschappen detecteren en ACK’s versturen) is dat ze beide op een verschillende snelheidkunnen werken en dat bij druk verkeer de te versturen ACK’s gebufferd kunnen worden enrustig verstuurd kunnen worden op het eigen tempo van het derde proces. Bovendien verliesthet ontvangend proces zo geen tijd met het versturen van ACK’s en kan het terug verdergaanmet het ontvangen van berichten.

We zullen dus de te versturen en de ontvangen ACK’s bufferen vanuit het ontvangend pro-ces. Via twee arrays van booleans (0: verwerkt, 1: niet verwerkt) laten we de verschillendeprocessen met elkaar communiceren over welke ACK’s nog verstuurd moeten worden en voorwelke verstuurde berichten reeds een ACK ontvangen is. Een array bevindt zich tussen het ont-vangend proces en het ACK-versturend proces waarbij het ontvangend proces een boolean op1 zet als er een nieuwe ACK verstuurd moet worden. Het ACK-versturend proces heeft echtermeer gegevens nodig om de correcte ACK te versturen, namelijk naar welke robot en voor welkserienummer de nieuwe ACK verstuurd moet worden. Daarom gebruiken we een 2-dimensionalearray met de volgende drie kolommen:

• Eerste kolom: bevat 0 (verwerkt) of 1 (nieuw te versturen ACK).

• Tweede kolom: bevat het ID van de robot waarnaar de ACK verstuurd moet worden.

• Derde kolom: bevat het serienummer dat acknowledged moet worden.


Een tweede, soortgelijke array bevindt zich tussen het ontvangend proces en het proces datboodschappen verzendt, waarbij het ontvangend proces een boolean op 1 zet indien een ACKvan een andere robot ontvangen werd. Het verzendend proces dat wacht op een ACK, zal ditdetecteren en vervolgens verdergaan met het proces. De array bestaat uit:

• Eerste kolom: bevat 0 (verwerkt) of 1 (nieuw ontvangen ACK).

• Tweede kolom: bevat het ID van de robot vanwie de ACK afkomstig is.

• Derde kolom: bevat het serienummer van het bericht dat acknowledged werd.

Deze buffer lijkt op het eerste gezicht niet nodig aangezien ervoor gezorgd wordt dat boodschap-pen - ACK’s niet meegerekend - enkel verstuurd worden indien er een ACK voor het voorgaandebericht ontvangen is. Toch wordt er op die manier geen rekening gehouden met de grootte vande time-out timer. Als deze zeer klein gekozen wordt, zodat berichten snel herverzonden kun-nen worden, kan het gebeuren dat een ACK nog ontvangen wordt nadat de time-out optrad.Ondertussen is het bericht al herverstuurd en zal er even later nog een tweede ACK voor hetbericht ontvangen worden. De verzendende robot kan geen onderscheid maken tussen een ACKvoor het oorspronkelijke en een voor het herverzonden bericht en zal dus, na het ontvangen vande eerste ACK, doorgaan met het sturen van een volgende boodschap.In dit geval kunnen zowel de ACK voor het nieuwe bericht en dat voor het herverzonden berichttegelijk toekomen en om dit op te vangen is er een kleine buffer nodig tussen de twee processen.

De buffers zijn circulair wat wil zeggen dat wanneer het laatste element van de buffer ge-schreven werd, de volgende keer opnieuw het eerste element overschreven zal worden. Maarbelangrijker is dat ze niet te groot gekozen moeten worden. Ze dienen vooral om plotse golvenvan binnenkomende boodschappen op te vangen en dan rustig te verwerken. Ze vormen dus eenoplossing voor korte ”uitbarstingen”. De proces- en bufferstructuur wordt weergegeven in figuur2.7 met de drie processen en de twee buffers.

Een voorbeeld van zo’n buffer is te zien in tabel 2.6. De buffer houdt enkel het serienummerbij, het ID van de sturende robot en of er nieuwe informatie is toegevoegd. De buffer wordtvan boven naar onder opgevuld om daarna weer bovenaan te beginnen. De buffer kan zowelgebruikt worden om binnengekomen ACK’s in op te slaan als boodschappen waarvoor nog eenACK gestuurd moet worden. In het laatste geval stelt de buffer uit tabel 2.6 een situatie voorwaarbij de robot een ACK moet sturen voor een retransmissie (SN 34) en een nieuw berichtvan robot 3 (SN 67). Elke rij met een nul in de eerste kolom toont een verwerkt bericht datoverschreven mag worden door het ontvangend proces. Als er een een staat moet het nogverwerkt worden (vet).

In het andere geval zal de buffer binnenkomende ACK’s bevatten en nu toont tabel 2.6 desituatie waarin een ACK (SN 34) een tweede keer is toegekomen en een ACK (SN 67) bevat voorhet bericht dat daarna al verstuurd werd. Deze situatie werd hierboven beschreven in paragraaf2.4.1 bij de uiteenzetting over de noodzaak van een buffer voor ontvangen ACK’s.


Figuur 2.7: Proces- en bufferstructuur voor de communicatie

Tabel 2.6: Circulaire buffer voor ACK’s

nieuw/oud ID sturende robot SN

0 2 34

1 2 34

1 3 67

0 2 33

0 3 66

Structuur van een ACK-bericht

Tot hiertoe werd een ACK steeds beschouwd als een speciaal soort boodschap die gescheidenmoet zijn van het normale dataverkeer. Om dit te verkrijgen, nemen we een gewoon berichtmaar geven we het een functienummer 250 om aan te duiden dat we hier te maken hebben meteen ACK-bericht. Het serienummer doet er niet toe maar zal altijd op 0 gezet worden. Verderwordt ook het serienummer meegestuurd van de boodschap die acknowledged wordt.

De robot die een boodschap verstuurd heeft en wacht op de correcte ACK, controleert of degoede ACK ontvangen is. De boodschap die verstuurd is, zit immers nog altijd in zijn buffervoor uitgaande berichten. Door te controleren of de ACK van de goede robot afkomstig is enhet meegestuurde serienummer overeenkomt met het serienummer in de buffer voor uitgaandeberichten, kan de robot de ACK verifieren.


De structuur wordt hieronder weergegeven in tabel 2.7 en via het speciale functienummer kanhet ontvangend proces met algoritme 2.14 achterhalen of een bericht een ACK is of niet.

Tabel 2.7: Structuur van een ACK-bericht


0 250 SN ontvangen bericht 0 0 0 0

In het volgende deel wordt de zender- en ontvangerszijde besproken bij de robots. Omdatelke robot nu ook ACK’s zal moeten versturen is het moeilijk om deze helemaal los te koppelenvan elkaar. Al de veiligheden zijn maar mogelijk door gebruik te maken van de communicatie-structuur beschreven in paragraaf 2.3 en de zender- en ontvangerszijde zullen hier dan ook opsteunen.

2.4.2 Testopstelling

Analoog aan de testopstelling uit figuur 2.5, zullen de robots stil staan en communiceren ze enkelmet elkaar. Het verschil met de vorige testopstelling zit hem in de aard van de communicatie.Elke robot zal nu twee berichten sturen en er ook twee ontvangen. Een naar elke andere roboten een van elke robot. In het totaal zullen dus zes verschillende boodschappen doorgestuurdworden en dit is te zien in figuur 2.8. Het programma zal dus voor elke robot hetzelfde zijn opde inhoud van de verstuurde boodschappen na.

Figuur 2.8: Testopstelling bij uitgebreide QoS


Testalgoritme

Het testprogramma zorgt ervoor dat elke robot een verschillende boodschap stuurt naar detwee andere robots zoals te zien in algoritme 2.13. Dit verkeer is dataverkeer en telkens zaleen boodschap ingepakt worden met de packMsg()-functie en verstuurd met sendAckRobot()

(paragraaf 2.4.4).

Algoritme 2.13 Testprogramma1: loop2: if (Eigen ID == 1) then3: packMsg({5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5}) for robot 24: Send message with sendAckRobot() and wait for ACK

5: packMsg({6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6}) for robot 36: Send message with sendAckRobot() and wait for ACK

7: else if (Eigen ID == 2) then8: packMsg({3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3}) for robot 19: Send message with sendAckRobot() and wait for ACK


12: else if (Eigen ID == 3) then13: packMsg({1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}) for robot 114: Send message with sendAckRobot() and wait for ACK



2.4.3 Ontvangerszijde

In deze sectie breiden we het vorige algoritme voor de ontvangerszijde (paragraaf 2.2.7) uit. Ditresulteert in algoritme 2.14 waarbij de robot eerst zal controleren of de ontvangen boodschapeen ACK is door te kijken of het functienummer gelijk is aan 250. In dat geval wordt de ACK inde circulaire buffer geplaatst voor binnenkomende ACK’s. Het proces dat berichten verstuurt,zal dit opmerken en na controle van de ACK zal dit proces verdergaan en kan het opnieuwboodschappen versturen.

Indien het functienummer niet 250 is, zal de robot controleren of het huidige serienummereen hoger is dan dat van het voorgaande bericht van die robot. De robot weet in dat geval dathet om een nieuw bericht gaat en zal de nodige gegevens in de buffer plaatsen, zodat het ACK-versturend proces de correcte ACK kan versturen. In dit geval zal de boodschap ook uitgepaktworden en opgeslagen in de buffer voor ontvangen berichten.

Indien het serienummer gelijk is aan dat van het vorige bericht dat ontvangen werd, zal de


robot besluiten dat zijn ACK niet is toegekomen. Hierop zal hij dezelfde actie ondernemen alsbij een nieuw bericht zodat er een nieuwe ACK verstuurd wordt. De boodschap zal evenwel nietuitgepakt worden, omdat het bericht al in de buffer zit.

In alle andere gevallen zal de ontvangen boodschap genegeerd worden.

Algoritme 2.14 Ontvangerszijde met uitgebreide QoS1: loop2: repeat3: Read the 8 bit status of the Radio Turret4: until (bit1 == 1)

5: Read Reception Buffer

6: if (funcieNr == 250) then7: ACK received8: Place in ACK-in-buffer ⇒ Deal with ACK in sending process

9: else if (current SN == previous SN + 1) then10: unpackMsg()11: New message Received12: Place in ACK-out-buffer ⇒ Send ACK in ACK-sending process

13: else if (current SN == previous SN) then14: Same message received15: Place in ACK-out-buffer ⇒ Send ACK in ACK-sending process16: end if17: end loop

2.4.4 Zenderzijde

Voor het zenden van berichten wordt nog altijd gesteund op de zendfunctie (sendRobot()) be-schreven in algoritme 2.12. Die vormt nu echter enkel de kern van de nieuwe zendfunctie en ronddie kern is een extra kader gebouwd, zodat het systeem van ACK’s en time-outs geımplementeerdkon worden.In deze nieuwe zendfunctie (sendAckRobot()) zal, na het verzenden van een bericht, een timergestart worden en indien die afloopt zonder dat een correcte ACK ontvangen werd, zal de bood-schap herverstuurd worden. Wordt uiteindelijk toch de correcte ACK ontvangen, dan wordt denieuwe zendfunctie afgesloten en wordt verdergegaan met de rest van het programma.

2.4.5 ACK-versturend proces

Dit proces controleert de circulaire buffer die aanwezig is tussen dit proces en het ontvangendproces om te zien of er nieuwe berichten zijn waarvoor een ACK moet gezonden worden. Alsdit zo is, dan zal er een ACK aangemaakt worden die ook het serienummer zal meekrijgen vande ontvangen boodschap. Deze informatie zit in de buffer naast het ID van de robot waarnaarhet ACK moet worden verstuurd en de byte die aangeeft of informatie in de buffer nieuw is ofniet. De ACK wordt verstuurd met de oude zendfunctie (sendRobot()) van algoritme 2.12.


Algoritme 2.15 Zendfunctie 2 met uitgebreide QoS: sendAckRobot()1: Send message with sendRobot()

2: repeat3: Start timer4: repeat5: Check elapsed time6: until (ACK received or time-out)

7: if (time-out) then8: Resend message with sendRobot()

9: else if (correct ACK received for sent message) then10: Continue program

11: else12: Received ACK is incorrect13: end if14: until (Correct ACK received)

Algoritme 2.16 Het ACK-versturend proces1: loop2: repeat3: Check ACK-in-buffer4: until (new ACK to be sent)5: Send ACK6: end loop


De C-code voor de communicatie met uitgebreide QoS via de Radio Turret is te vinden opde bijgeleverde CD in de map ”Communication\Radio Turret\with extended QoS”.

2.4.6 Evaluatie

De robot heeft nu volledige controle over de communicatie dankzij het invoeren van de ACK’sen time-outs. Bij het uitvoeren van de test met de opstelling in figuur 2.8 bleek dat de drierobots in 12 minuten elk ongeveer 256 berichten hadden doorgestuurd naar elke andere robot.Dit is eigenlijk niet zo snel, maar er zijn toch een paar heel interessante zaken op te merken. Bijde vorige kwaliteitsgaranties was het meestal zo dat een robot de bovenhand haalde, waardoorde andere hun boodschappen er amper nog door kregen. Met meerdere robots wil dat zeggendat een enkele robot het ganse verkeer kan overheersen door verzadiging van het medium. Deandere robots kunnen in dat geval nog amper communiceren.Daarnaast konden boodschappen af en toe verloren gaan zonder dat ze herverzonden werden.

Deze twee problemen zijn nu verholpen met de huidige communicatie. Niet alleen zullenboodschappen nooit meer verloren gaan omdat ze bevestigd moeten worden via een ACK, maarhet verkeer blijkt ook veel eerlijker verdeeld te zijn. In de test slaagde de ene robot erin om ietssneller te zenden dan een ander, maar deze verschillen waren verwaarloosbaar in vergelijkingmet de situatie ervoor. Op 256 berichten liep het verschil tussen de verstuurde boodschappenvan beide robots op tot 50 maar dat is veel beter dan de situatie waarbij de andere robots nietmeer kunnen communiceren.Daarbij komt dat deze situatie het worst-case scenario simuleert waarbij robots continu infor-matie doorzenden. Dit zal bij de gebruikte algoritmes in dit onderzoek nooit voorkomen, omdatde communicatie enkel wordt gebruikt om afspraken te maken.Deze vorm van communicatie waarbij de drie robots tegelijk mogen zenden, voldeed aan deopgestelde eis voor foutloze transmissie.


2.5 Dynamische groepstructuur

Nu de communicatie helemaal op punt staat, kan nagedacht worden over de uitdagingen in detoekomst. De belangrijkste is het omgaan met dynamische groepen. In deze scriptie bestondeen formatie steeds uit drie robots. Dit is eigenlijk slechts een startpunt voor het onderzoek,want veel situaties zijn denkbaar waarbij het aantal variabel is. Zo kan een robot die later isopgestart vragen aan de huidige robots om zich aan te sluiten bij de formatie. In dit gevalzullen de robots samen hun gedrag moeten herbepalen. Maar evengoed kan een robot uitvallen,zodat de resterende robots hun formatiegedrag zullen moeten aanpassen aan de nieuwe situatie.Vanuit een communicatie-oogpunt is dit een uitdagend gegeven en in de volgende paragrafenzullen hiervoor twee aanpakken aangebracht worden19. De eerste bouwt voort op de bestaandestructuren die in dit onderzoek ontwikkeld werden, terwijl de tweede aanpassingen vereist aanhet huidige communicatieprotocol.

2.5.1 Voortbouwen op de huidige communicatiestructuur

Het is mogelijk om het dynamisch groepsgedrag te implementeren, voortbouwend op de be-staande communicatiestructuur. In de volgende twee paragrafen besteden we aandacht aan hoerobots het wegvallen en toevoegen van een robot in de groep kunnen implementeren.

Detecteren van een weggevallen robot

De reeds besproken zendfunctie (sendAckRobot()) kan een ondersteuning bieden voor het de-tecteren van weggevallen robots. Als er voor een boodschap na een zeker aantal time-outs nogaltijd geen ACK ontvangen is, kan deze robot als verloren beschouwd worden. Hij kan dan uitde lijst van actieve robots verwijderd worden. Bovendien zal de rij die overeenkomt met zijn IDin de buffer van inkomende en uitgaande berichten weer op nul geınitialiseerd worden. Als derobot heropstart en weer boodschappen zou versturen, dan zullen deze door de andere robotsniet meer genegeerd worden omdat het eerste bericht serienummer 1 zal hebben, wat inderdaadeen hoger is dan nul.

Robot toevoegen aan een groep andere robots

Het toevoegen van een robot kan geregeld worden via een speciaal soort bericht (zoals hetACK-bericht dat reeds beschreven werd in paragraaf 2.4.1) met een functienummer dat webijvoorbeeld gelijkstellen aan 251. Deze boodschap zal vanaf nu een REQ20 genoemd worden.Het ontvangend proces zal nu ook moeten controleren of een boodschap een REQ-boodschapis. In dat geval zal de robot de nieuwe robot toevoegen aan zijn lijst van actieve robots en derij overeenkomstig met zijn ID in de buffers voor binnenkomende en uitgaande berichten op nulinitialiseren. De manier waarop de nieuwe robot in de formatie opgenomen wordt, valt buiten

19Beide aanpakken worden besproken uitgaande van de communicatie met behulp van de Radio Turrets, maarde aangebrachte oplossingen kunnen ook toegepast worden op de communicatie via de High Speed Radio Turrets.

20REQ (request) duidt op een robot die verzoekt om een deel van de groep te zijn.


de communicatie en moet in de robot zelf geımplementeerd worden. Een weggevallen robot kanook met een REQ boodschap vragen om weer opgenomen te worden in de groep.

Het dynamisch omgaan met robots in een groep kan dus met de huidige structuur opgevangenworden. Het voordeel is dat er geen master nodig is en dat elke robot lokaal bijhoudt welkerobots binnen zijn bereik zijn. Een grotere groep robots kan zo spontaan uiteenvallen in kleineregroepjes die binnen elkaars communicatiebereik voorkomen.

2.5.2 Aanpassingen aan de communicatiestructuur

Bij de Radio Turrets kan elke robot met elke andere robot communiceren. Als er druk dataver-keer is, kunnen er boodschappen met elkaar botsen, waardoor de boodschap moet herverzondenworden. Het aantal botsingen stijgt kwadratisch [12] met het aantal robots, zodat er bij eengroot aantal al vlug een verzadiging van het medium zal zijn met herverzonden boodschappen.Om dit op te vangen zijn in principe twee denkpistes mogelijk.

1. CSMA/CD: Carrier Sense Multiple Access with Collision Detection

2. TDMA: Time Division Multiple Access

CSMA/CD

Dit principe wordt onder andere gebruikt in het ethernet protocol [13]. Als een robot eenboodschap wil versturen, zal hij luisteren of een andere robot aan het zenden is. Als dit zois, zal hij zelf wachten met zenden tot niemand anders nog zendt. Het kan gebeuren dat tweerobots tegelijk opmerken dat het medium vrij is zodat ze beide tegelijk proberen te zenden. Zezullen dan echter opmerken dat hun boodschappen door elkaar verstuurd zijn en zullen daaruitbesluiten om een zekere tijd te wachten alvorens nogmaals te proberen de boodschap te versturen.Deze tijd is random maar kleiner dan een ingestelde bovengrens. Botsen de boodschappen nogeens, dan zullen ze dit keer langer wachten alvorens opnieuw te proberen. Deze wachttijd bijherhaalde botsingen wordt exponentieel langer, zodat men spreekt van exponential back-off. Dewachttijden zijn random om ervoor te zorgen dat een robot eerst zal beginnen zenden en deanderen, die zien dat deze ene robot eerst was, zullen wachten tot hij klaar is met zenden.

Met de bestaande Radio Turrets valt niet te achterhalen of boodschappen gebotst zijn. Hetstrikt toepassen van CSMA/CD is in dit geval dus niet onmiddellijk mogelijk. De exponentialback-off kunnen we echter wel implementeren door bij een time-out steeds langer en een wil-lekeurige tijd te wachten vooraleer opnieuw te zenden. Bij een communicatie met drie robotsblijkt dit bij weinig verkeer nog niet nodig te zijn, omdat time-outs niet voorkomen en ook bijdruk verkeer konden alle robots nog blijven communiceren aan een redelijke snelheid. Als hetaantal robots zou verhogen, kan dit geımplementeerd worden om de bestaande communicatie teverbeteren.


TDMA

In referentie [12] vinden we nog een andere manier om robots niet tegelijk te laten zenden.Hierbij wordt de tijd opgedeeld in tijdslots op zo’n manier dat slechts een robot mag zenden ende andere enkel mogen luisteren tijdens elk tijdslot. Er zijn twee verschillende manieren om tebepalen wie wanneer mag sturen:

• Polling Deze eerste manier is te zien in figuur 2.9. In deze configuratie is er een masterdie de robots een voor een afgaat, zodat deze elk om beurt mogen zenden. Het toevoe-gen en wegvallen van robots aan de ring wordt enkel aan de master toevertrouwd. Dezeconfiguratie heeft als nadeel dat er een master in het spel is. Hoewel deze masterrol nietstatisch hoeft te zijn en kan worden doorgegeven, is het een stap terug van gelijkwaardigerobots. De master maakt het geheel kwetsbaar. Er kan natuurlijk een veiligheidsmecha-nisme ingebouwd worden dat de andere robots na een bepaalde tijd van radiostilte doetbesluiten dat de master weg is en er dus een nieuwe moet gekozen worden.

Bij grote groepen kan het heel lang duren voor een robot weer aan beurt is. Om dit teverhelpen kan de grote groep in subgroepen ingedeeld worden met elk een master, terwijlde masters onderling ook een groep vormen. Deze laatste groep zal dan opnieuw eenmaster hebben en zo kan een piramide opgebouwd worden van groepen. De verschillendesubgroepen kunnen elkaars radioverkeer natuurlijk beınvloeden als ze in elkaars buurtstaan. Om de piramide praktisch te realiseren zou elke subgroep een andere frequentiekunnen gebruiken.

• Virtual Token Ring De tweede aanpak is te zien is in figuur 2.10. In dit geval is ereen token dat wordt doorgegeven van robot naar robot. Enkel wanneer iemand het tokenheeft, mag hij zenden. Het concept is analoog aan dat van polling, maar de rol van eendelegerende master wordt nu grotendeels overgenomen door het token. Toch is ook hiereen master nodig, omdat er maar een token mag zijn en er ook maar een robot voor heteerst het token mag aanmaken en versturen. Als een token verloren gaat, mag er ookslechts een robot dit opvangen en een nieuw token maken. Het toevoegen en wegvallenvan robots aan de ring wordt ook hier aan de master toevertrouwd. Net zoals bij pollingmoet het wegvallen van de master door de andere robots gezamenlijk opgevangen worden.

De virtual token ring is iets flexiber dan polling, maar in essentie staat de master bij virtualtoken ring gewoon in de kring in plaats van erbuiten. Bij grote groepen kan de wachttijdvoor elke robot onaanvaardbaar groot worden en zal er naar andere oplossingen gezochtmoeten worden. Het idee van de subgroepen kan ook hier een interessant pad zijn om allesschaalbaar te houden.


Figuur 2.9: Communicatie via polling

Figuur 2.10: Communicatie via een virtual token ring

Hoofdstuk 3

Sonar Turret

Inhoudsopgave

3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 SRF05-module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Extensieturret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4 PIC16F877A-microcontroller . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Het PCB van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6 Code voor de microcontroller . . . . . . . . . . . . . . . . . . . . . . . . 57

3.7 Aansturing van de turret vanop de Khepera II . . . . . . . . . . . . . 61

3.8 Evaluatie van de Sonar Turret . . . . . . . . . . . . . . . . . . . . . . . . 63

3.9 Nieuw ontwerp Sonar Turret (Rev. 1) . . . . . . . . . . . . . . . . . . . 64

3.1 Inleiding

In dit hoofdstuk wordt de ontwikkeling beschreven van de Sonar Turret voor de Khepera II.Deze turret werd ontwikkeld om nauwkeurige afstandsmetingen te kunnen maken.Vooreerst wordt de gebruikte SRF05-sonarmodule besproken. Vervolgens wordt ingegaan op demogelijkheden die de Khepera II biedt om extensieturrets te creeren. Daarna bespreken we demicrocontroller die de SRF05-modules zal aansturen. Ten slotte overlopen we het gerealiseerdePCB1, de code ontwikkeld voor de microcontroller en de robot en maken we ook een evaluatievan de Sonar Turret.

3.2 SRF05-module

De SRF05-sonarmodule (Fig. 3.1) werd speciaal ontwikkeld voor minirobot-toepassingen enheeft als belangrijkste voordelen een laag vermogenverbruik, een hoge resolutie, kleine afmetin-gen en een lage kostprijs.

1PCB = Printed Circuit Board

49

Hoofdstuk 3. Sonar Turret 50

Figuur 3.1: De SRF05-module

De module bestaat uit een ultrasone sensor (verzender en ontvanger), enkele analoge com-ponenten en een eenvoudige microcontroller. Het starten van de module gebeurt door een hogepuls (10µs, 5V) aan te leggen aan de Trigger Input-pin (figuur 3.1). Vervolgens zal de moduleeen ultrasone puls uitsturen en zet hij de Echo Output-pin hoog (5V). Daarna wacht de moduleop de echo van de ultrasone puls en zet hij, wanneer deze echo ontvangen wordt, de Echo Out-put-pin terug laag (0V). De tijdsduur dat de Echo Output-pin hoog was, is dan evenredig metde afstand tot het gedetecteerde object.

3.3 Extensieturret

De Khepera II is modulair opgebouwd. Dit wil zeggen dat de robot aangepast/uitgebreid kanworden met behulp van zogenaamde extensieturrets. Dit zijn kleine PCB’s die bovenop de Khe-pera II passen en die een bijkomende functionaliteit geven aan de robot. De communicatie tussende robot en de extensieturrets gebeurt door middel van pinnen die zich bevinden onder elke tur-ret en die connecteren op de turret/robot eronder [14, sectie 2]. Er zijn twee mogelijkheden omzulke turrets te ontwikkelen voor de Khepera II :

• Parallelle Turret Dit soort turrets maakt gebruik van acht digitale I/O2-pinnen, drieanaloge I-pinnen, zes adres-pinnen en twee pinnen voor asynchrone communicatie. Wan-neer de robot een commando (via acht digitale I/O-pinnen) schrijft naar een bepaald adres(via de zes adres-pinnen), vergelijken alle aanwezige parallelle turrets dat adres met huneigen (voorgeprogrammeerde) adres en weten op die manier of het commando voor henbedoeld is. Dit is een eenvoudig principe dat toelaat zeer snel extensieturrets te ontwik-kelen.

• Seriele Turret Dit soort turrets maakt gebruik van de KNET-bus [15]. Die is gebaseerdop de SPI-bus3 en beschikt over zes pinnen om te communiceren:

2I/O = Input / Output3SPI = Serial Peripheral Interface


Figuur 3.2: De KNET-bus met (a) alle turrets in slaaptoestand (b) een turret in actieve toestand

1. /CS COM (standard SPI signal) Chip select

2. SCK (standard SPI signal) Clock

3. MOSI (standard SPI signal) Master Out Slave In

4. MISO (standard SPI signal) Master In Slave Out

5. /F7 (additional signal) Communication request

6. PAI (additional signal) Acknowledge

Wanneer verschillende seriele turrets aanwezig zijn op de Khepera II, krijgen we een struc-tuur zoals in figuur 3.2a. Alle turrets bevinden zich initieel in slaaptoestand. Wanneer derobot iets wil sturen naar een van de turrets, stuurt hij een lage puls (1µs, 0V) naar pinF7 en vervolgens het adres van de turret die hij wil aanspreken via de seriele pin MOSI.Wanneer de juiste turret dit ontvangt, configureert hij zijn MISO- en PAI -pin als output-pin (zie Fig. 3.2b, slave #1); alle andere turrets blijven in hun slaaptoestand. Vanaf datmoment communiceert de robot (voor dit bericht) enkel nog met die ene turret. Dezecommunicatie tussen de master en een slave gebeurt altijd in twee fasen:

– De master stuurt een bericht (opdracht) naar de slave.

– De slave verwerkt dit bericht en stuurt een antwoord hierop terug naar de master.

De toestand van de verschillende pinnen van de KNET-bus gedurende deze communicatieis te zien in figuur 3.3 waarbij we nog opmerken dat elke verstuurde byte van de robotacknowledged moet worden door de turret via een puls op de PAI -pin en elke te versturenbyte naar de robot voorafgegaan wordt door een puls op diezelfde PAI -pin.


Figuur 3.3: De toestand van de KNET-bus gedurende de communicatie met een slave

Wanneer het bericht naar de master verstuurd is, keert de slave terug naar zijn slaaptoe-stand en wacht op de volgende puls op pin F7.

Ons eerste idee was te kiezen voor een parallelle turret. Die zou dan rechtstreeks de TriggerInput-pinnen van de drie4 SRF05-modules aansturen en de breedte van de puls op de EchoOutput-pinnen meten. Helaas bleek de timerfunctie op de robot een te kleine resolutie te hebbenzodat een bijkomende microcontroller voor het meten van de duur van de puls onvermijdelijkwas. Er werd dan overgegaan op het principe van seriele turrets, omdat het terugsturen vandata vanop de turret via een parallelle turret niet eenvoudig is. Een bijkomend voordeel aanseriele turrets is dat de commando’s op de robot zelf zeer eenvoudig blijven (cfr. paragraaf 3.7).Het nadeel is dat op de microcontroller van de turret het volledige seriele KNET-busprotocolgeımplementeerd moet worden, wat niet zo eenvoudig bleek te zijn (cfr. paragraaf 3.6).

3.4 PIC16F877A-microcontroller

Als microcontroller werd gekozen voor de PIC16F877A. Daar zijn twee redenen voor. Ten eersteis de PIC16F877A een van de weinige microcontrollers die het SPI-busprotocol in slave-modeondersteunt. Slave-mode houdt in dat de microcontroller niet zelf het kloksignaal aanmaakt,maar afhankelijk is van het kloksignaal dat de master verstuurt (Fig. 3.2). De tweede redenom voor deze microcontroller te kiezen is het feit dat de onderzoekers bij K-Team Corporationervaring hebben met deze microcontroller en zelfs reeds code geschreven hebben om vanuit deKhepera II te communiceren met deze microcontroller.

Bijkomende features van de microcontroller zijn onder andere 33 I/O-pinnen, ondersteuningvan kristallen tot 20 MHz, in-circuit seriele herprogrammering, 8-bit en 16-bit timers. Eenkristal van 20 Mhz in samenwerking met de 16-bit timers laat toe om een zeer nauwkeurigetijdsduurmeting uit te voeren.

4een om links te scannen, een om rechts te scannen en een derde om recht voor de robot te scannen


Figuur 3.4: PCB-layout van de Sonar Turret

3.5 Het PCB van de Sonar Turret

In figuur 3.4 is het layout-ontwerp van de Sonar Turret te zien. We hebben gekozen voor eentweezijdig PCB omdat er relatief veel signalen over het PCB gerouteerd moesten worden. Opeen enkelzijdig PCB kunnen signaallijnen elkaar nooit kruisen (omdat dit tot kortsluiting zouleiden); op een dubbelzijdig PCB kan men echter zowel op de onderkant (blauwe lijnen in figuur3.4) als op de bovenkant (rode lijnen in figuur 3.4) signaallijnen routeren zodat een denserestructuur mogelijk is. Centraal in figuur 3.4 is de microcontroller te zien die aangestuurd wordtmet het kristal van 20 MHz. Uiterst links en rechts en helemaal bovenaan bevinden zich deconnectoren voor de SRF05-modules. Links onderaan bevindt zich de ICSP-connector (nodigom de microcontroller te programmeren) en links bovenaan een circuit om de microcontroller teresetten.

3.5.1 Aanpassingen

Bij de eerste tests met de Sonar Turret bleek al snel dat de SRF05-modules zeer nauwkeurigeafstandsmetingen toelaten. De afstandsmetingen geven ook steeds nagenoeg hetzelfde resultaatwanneer eenzelfde afstand gemeten wordt. Dit is een groot voordeel ten opzichte van anderesensoren die vaak te kampen hebben met ruisproblemen. Toch bleken nog enkele aanpassin-gen noodzakelijk om de Sonar Turret ten volle te kunnen gebruiken in onze situatie. Deze


Figuur 3.5: Khepera II met Sonar Turret (bovenaan), High Speed Radio Turret en Radio Turret (on-deraan)

aanpassingen worden besproken in de volgende paragrafen.

Onregelmatige vorm

In de eerste plaats willen we de Sonar Turret gebruiken om de afstanden tot andere robots temeten. In een ideale situatie, waarbij de ultrasone bundel zo smal zou zijn dat hij als een straalkan worden beschouwd en waarbij de robot een perfecte cilinder zou zijn (zie figuur 3.6), zoudende afstandsmetingen tot de robot het kleinst zijn als de bundel er recht op invalt. Hoe meerde straal dan op de zijkant van een robot invalt, hoe groter de gemeten afstand zal zijn. Doorde smalheid van de bundel, zal de bundel echter al snel weerkaatsen op zo’n manier dat desensor geen echo meer kan opmeten, waardoor de andere robot dus ook niet meer gedetecteerdkan worden (cfr. tweede situatie in figuur 3.6). In dit ideale geval zal de robot dus vanuit elkerichting dezelfde meetwaarden geven (op voorwaarde dat de afstand tussen beide robots dezelfdeblijft) over de hoek waarin de ultrasone sensor van de andere robot hem kan detecteren.

In de praktijk is dit helaas niet zo. De robot heeft een zeer onregelmatige vorm (grotendeelsdoor de Sonar Turret (figuur 3.5) bovenop de robot). Daardoor detecteren de robots elkaar alseen onregelmatige kromme, en niet als een cirkelboog. De afstand van een robot tot een andererobot bleek dus niet gedefinieerd. Uit experimenten met formatievormingsalgoritmes (hoofdstuk5), is gebleken dat het feit dat een robot als een onregelmatige kromme werd gedetecteerd eenprobleem was dat we dienden op te lossen. We zijn dan op zoek gegaan naar een soort cilinderdie we rond de robot met Sonar Turret konden monteren opdat de robot als een cirkelboog zoukunnen worden gedetecteerd. Dit werd uiteindelijk uitgevoerd door een PVC-buis rond de robotte plaatsen en te bevestigen aan de ultrasone sensoren.


Figuur 3.6: Opmeten van een andere robot in het geval van ideale ultrasone sensoren en behuizing vande robots.

Bundelbreedte

In figuur 3.7 is een illustratie te zien van de vorm van de ultrasone bundel die de ultrasonesensoren uitsturen.

De ultrasone sensoren van de SRF05-modules ‘kijken’ dus niet enkel in de richting waarin zemeten, maar detecteren ook objecten die zich in de buurt van deze richting bevinden. Dit zorgtvoor een grote hoek waarover objecten gedecteerd worden door de ultrasone sensoren. Ook ditleek ons een probleem dat we moesten aanpakken. Daarom brachten we smalle PVC-buisjesaan rond de ultrasone sensoren met een lengte die ongeveer dubbel zo lang is als de lengte vaneen ultrasone sensor. De gehele binnenkant van de buisjes bedekten we met Velcro. De redenwaarom dit de bundelbreedte verkleint, is de volgende. Een deel van de ultrasone bundel verlaatde ultrasone sensoren onder een bepaalde hoek5. Wanneer die ultrasone golf de Velcro bereiktvoor het de PVC-buis kan verlaten, zal die golf geabsorbeerd worden door de Velcro. Velcro heeftnamelijk een heel onregelmatige structuur zodat de invallende golf onmiddellijk verschillendekeren gereflecteerd wordt, waarbij telkens een groot deel van de energie geabsorbeerd wordt.Bijgevolg zal enkel dat deel van de uitgestuurde ultrasone bundel de uitgang van de PVC-buisjes bereiken, dat onder een voldoende kleine hoek vertrekt uit de ultrasone sensoren. Eenafbeelding van de Sonar Turret na het aanbrengen van de hierboven vermelde aanpassingen iste vinden in figuur 3.8.

Verloren echo’s

Na het aanbrengen van de verschillende PVC-buizen, werden nieuwe sonarmetingen uitgevoerd,waarbij we trachtten te bepalen over welke hoek een robot een andere robot detecteert. Een

5Dit deel van de ultrasone bundel maakt dus een hoek ten opzichte van de hoofdrichting waarin de sensor meet


Figuur 3.7: Bundelbreedte van SRF05-modules

Figuur 3.8: De Sonar Turret met aanpassingen voor nauwkeurige sonarmetingen


probleem dat tijdens deze tests aan het licht kwam, was het probleem van de echo’s die verlorengaan. Wanneer een robot een ultrasone bundel uitstuurt en deze bundel komt in een smalPVC-buisje (dat met Velcro bedekt is) van een andere robot terecht, dan wordt deze bundelgeabsorbeerd en zal de robot die aan het meten is, denken dat er geen object in de buurtis. Dit is een probleem dat niet opdook voor de aanpassingen en een logisch gevolg van hetaanbrengen van de PVC-buisjes met Velcro. We lossen dit op door in dit geval de robotsonderling te laten afspreken wie wie zal meten en we laten de robot die opgemeten wordt metzijn achterkant (waar geen PVC-buisjes aanwezig zijn) naar de andere draaien. We zullen ditdan ook consequent toepassen in de algoritmes die we ontwikkelen waarbij afstanden tot andererobots moeten worden gemeten (en waarbij we kennis hebben over de positie van de andererobots).

3.6 Code voor de microcontroller

Zoals reeds vermeld in paragraaf 3.4, werd de PIC16F877A gekozen omwille van de ervaringdie aanwezig is bij K-Team Corporation met deze microcontroller. Er werd dan ook gestartvan een template-C-file die we ontvingen van K-Team Corporation. Helaas bleek deze nietrechtstreeks bruikbaar in onze situatie en ook de mensen bij K-Team Corporation konden onsniet onmiddellijk verder helpen. De problemen situeerden zich vooral rond de communicatietussen de Khepera II en de microcontroller. De KNET-bus bleek niet gedetailleerd beschrevenen we hebben dan ook zelf uitgebreide tests uitgevoerd om te proberen de KNET-bus zo goedmogelijk te doorgronden om op die manier de communicatie in orde te krijgen. Tijdens ditproces zijn we ook van programmeertaal veranderd en hebben we de volledige code die we reedshadden, herschreven in Assembler, omdat die dichter aanleunt bij de hardware en we dus meercontrole hadden over wat er juist moest gebeuren op hardware-niveau.

Toen het KNET-protocol naar behoren werkte op de microcontroller, werd ook code geschre-ven voor de aansturing van de SRF05-sonarmodules en ten slotte werd de code uitgebreid vancommentaar voorzien.

De volledige Assembler-code voor de PIC16F877A is te vinden op de bijgeleverde CD in demap ”Sonar Turret\PIC16877A”.

3.6.1 Algemene werking

In deze paragraaf geven we een schematisch overzicht van de Assembler-code waarmee de mi-crocontroller geprogrammeerd is (zie ook Algoritme 3.1).

• De code die zich bevindt voor het Main-label, zorgt ervoor dat de verschillende modules6

van de microcontroller correct geconfigureerd worden en dat alle variabelen die we verderzullen gebruiken geınitialiseerd worden. Ook de I/O-pinnen worden hier geconfigureerd7.

6timermodule, ADC-module, SPI-module,... (laatste twee worden besproken in paragraaf 3.6.2)7Bij het configureren wordt bepaald of de pinnen als input of als output gebruikt zullen worden en wat hun

initiele toestand (0V of 5V) is.


Algoritme 3.1 PIC16F877A1: initialise variables2: initialise modules3: initialise I/O-pins4: loop5: Main label6: while (pin B0 high) do7: wait8: end while9: start SPI-module

10: wait for incoming byte (RXDATA addr) via SPI-module11: generate ACK on PAI-line12: if (RXDATA addr 6= correct turret address) then13: discard message14: else15: wait for incoming byte (RXDATA nr) via SPI-module16: generate ACK on PAI-line17: wait for incoming byte (RXDATA len) via SPI-module18: generate ACK on PAI-line19: wait for incoming byte (RXDATA comm) via SPI-module20: generate ACK on PAI-line21: if (RXDATA comm == ’S’) then22: send ’s’ to SPI-buffer23: generate ACK on PAI-line24: trigger SRF05-modules and measure echo-time with 16-bit timer-module25: save each 16-bit timer-value in 2 bytes (TXDATA lowX and TXDATA highX whe-

re X is replaced by the direction of the measured SRF05-module)26: else if (RXDATA comm == ’F’) then27: send ’f’ to SPI-buffer28: generate ACK on PAI-line29: send (TXDATA lowleft) XOR (TXDATA highleft) via SPI-module30: generate ACK on PAI-line31: send TXDATA lowleft via SPI-module32: generate ACK on PAI-line33: send TXDATA highleft via SPI-module34: generate ACK on PAI-line35: else if (RXDATA comm == ’G’) then36: send ’g’ to SPI-buffer37: generate ACK on PAI-line38: send XOR of TXDATA-values39: send TXDATA-values for front sonar measurement40: else if (RXDATA comm == ’H’) then41: send ’h’ to SPI-buffer42: generate ACK on PAI-line43: send XOR of TXDATA-values44: send TXDATA-values for right sonar measurement45: end if46: end if47: stop SPI-module48: end loop


• De code die zich na het Main-label bevindt, zal sequentieel en cyclisch doorlopen wordentot de voeding wegvalt of de microcontroller gereset wordt.De code begint met het pollen8 van de B0 -pin (deze is verbonden met de F7 -pin van deKhepera II ). Dit gebeurt in een lus die wacht tot de B0 -pin laag (0V) komt. Vervolgenswordt de SPI-module geactiveerd en wordt in een volgende lus gewacht tot de BF -bit, dieaangeeft dat een nieuwe byte van de robot ontvangen is, ’1’ wordt. De eerst verzondenbyte door de robot bevat het turretadres en we controleren of deze byte het correcteturretadres bevat. Indien dit niet het geval is, wordt de SPI-module gedeactiveerd enwordt er opnieuw naar het Main-label gesprongen. Als het turretadres wel correct is, wordtgewacht tot de volgende byte ontvangen is. Op dezelfde manier worden alle bytes van hetbericht, afkomstig van de robot, ingelezen en weggeschreven. We merken hierbij op dat,overeenkomstig het voorgeschreven KNET-busprotocol, elke ontvangen byte acknowledgedwordt via een puls op de A3 -pin (die verbonden is met de PAI -pin van de Khepera II ).

• Enkel de laatst ontvangen byte is echt belangrijk want die bevat het eigenlijke commandovoor de turret9. Alle mogelijke commando’s worden dan ook een voor een gecontroleerden wanneer er een overeenkomt met het ontvangen commando, worden de overeenkomstigeopdrachten uitgevoerd.Die opdracht kan het opstarten van een sonarmeting zijn of het doorsturen van de opge-meten data.In het geval van een sonarmeting (commando ’S’), worden de SRF05-modules sequentieelgetriggerd en de duur van de echo-pulsen wordt opgemeten. Het opmeten van die duurgebeurt met behulp van de ingebouwde 16-bit timermodule. Die wordt achtereenvolgens:

1. gestart: ’1’ schrijven naar de T1CON -bit van het TMR1ON-register

2. gestopt: ’0’ schrijven naar diezelfde bit wanneer de echo ontvangen is

3. gereset: timer wordt terug op nul gezet

• Om een byte terug te sturen naar de robot, maken we opnieuw gebruik van de ingebouwdeSPI-module, waardoor we enkel de te versturen byte naar een welbepaalde geheugenlocatiehoeven te schrijven (SSPBUF) en de SPI-module ervoor zal zorgen dat deze byte bit perbit op een correcte manier verzonden wordt. Ook hier brengen we, overeenkomstig hetKNET-busprotocol, een puls aan op de A3 -pin als we een byte willen verzenden.

• Wanneer het antwoord verzonden is naar de robot, wordt ook hier de SPI-module gedeac-tiveerd en wordt teruggesprongen naar het Main-label, zodat gewacht kan worden op eenvolgend bericht van de robot.

3.6.2 Aandachtspunten

In deze paragraaf zullen we enkele punten bespreken die ons veel tijd gekost hebben in deontwikkeling van de code. Het zijn vooral stukken code die betrekking hebben op de werking

8pollen = inlezen en controleren9De andere bytes, RXDATA nr en RXDATA len, staan respectievelijk voor het nummer van de boodschap

(analoog aan het serienummer dat we bespraken in hoofdstuk 2) en de lengte van het bericht.


van het KNET-protocol en die op een andere manier werken dan beschreven in de oorspronkelijketemplate-file. We vermelden ze hier dan ook opdat de eventuele ontwikkeling van bijkomendeextensieturrets in de toekomst eenvoudiger zou verlopen.

SPI-module

In paragraaf 3.3 bespraken we de algemene werking van het KNET-protocol. Alle aangeslotenturrets bevinden zich in een slaaptoestand en wachten op een lage puls op de F7 -pin voor zenaar een nieuw inkomend bericht beginnen te luisteren.

Deze berichten van de robot zullen we op de PIC16F877A ontvangen via de ingebouwdeSPI-module. Deze module zorgt ervoor dat de opeenvolgende bits van een byte (8 bits), ver-stuurd via de SPI-pinnen naar de PIC16F877A, correct ingelezen worden op de klokflankenvan het aangelegd kloksignaal. Eens de volledige byte ontvangen, wordt deze byte naar eengeheugenlocatie op de microcontroller geschreven en wordt er een ’1’ geschreven naar de BF -bitin het SSPSTAT-register. Dit alles gebeurt op de achtergrond zodat de programmeur van demicrocontroller enkel de BF -bit moet pollen om te controleren of een volledige byte ontvangenwerd.De SPI-module moet helemaal in het begin10 geconfigureerd worden (bv. slave-modus selecte-ren), door een bepaalde bitconfiguratie naar het SSPCON-register te schrijven. Via dit SSPCON-register is het ook mogelijk de SPI-module te activeren of tijdelijk te deactiveren.

Het is gebleken dat de communicatie tussen de robot en de microcontroller enkel werktwanneer deze SPI-module geactiveerd wordt na het ‘zien’ van een lage puls op de F7 -pin enwanneer deze SPI-module onmiddellijk wordt gedeactiveerd na het ontvangen van een bericht.

SDO-pin

In figuur 3.2(a) is te zien dat alle pinnen geconfigureerd moeten zijn als input11 als de micro-controller zich in de slaaptoestand bevindt. Enkel wanneer het correcte turretadres ontvangenwordt, zal de microcontroller de SDO12- en PAI-pin als output configureren. In de template-filewaarover we het reeds hadden in paragraaf 3.6 en die we ontvingen van K-Team Corporation,wordt de SDO-pin echter van in het begin als output geconfigureerd. Oorspronkelijk was dit ookbij ons zo, maar dit bleek een probleem wanneer er nog een andere extensieturret (bv. de RadioTurret) werd aangesloten op de robot. De oorzaak hiervan was de volgende: aangezien de SDO-pin van de Sonar Turret geconfigureerd was als output-pin, bleek deze elektrisch verbonden tezijn met de voeding. De SDO-pin van de Sonar Turret komt echter samen met de SDO-pin vande andere turret(s) en deze lijn vormt het MISO-signaal voor de robot. Wanneer deze andereturret nu informatie wou verzenden naar de robot, probeerde de robot deze bits te lezen van deMISO-pin. De robot las echter enkel ’1’-en omdat de MISO-pin via de Sonar Turret verbondenwas met de voeding.

10bij het opstarten en na een reset van de microcontroller11Op elektrisch niveau wil dit zeggen dat deze pin noch aan de voeding, noch aan de grond hangt, maar een

open-keten (hoge impedantie) vormt voor de buitenwereld12De SDO-pin op de microcontroller is verbonden met de MISO-pin van de Khepera II.


De code voor de microcontroller werd dan ook zo aangepast dat de SDO-pin in slaaptoestandals input-pin fungeert. Hierdoor werd het probleem opgelost.

ADC-module

Een laatste struikelblok situeerde zich bij het inlezen van de SRF05-modules, meer bepaaldde linkse module. De Echo Output-pin van deze module is verbonden met de A5-pin van demicrocontroller. Deze A5-pin is echter ook verbonden met de ingebouwde A/D13-converter enom van deze pin een digitale I/O-pin (nodig om de SRF05-module uit te lezen) te maken, moetenwe deze ingebouwde A/D-converter deactiveren. Dit gebeurt door helemaal in het begin van decode een welbepaalde bitconfiguratie naar het ADCON1-register te schrijven.

3.7 Aansturing van de turret vanop de Khepera II

Zoals vermeld in paragraaf 3.3 is het aansturen van de Sonar Turret erg eenvoudig door gebruikte maken van het principe van een seriele turret. Er zijn wel enkele controlemechanismen in-gebouwd, zodat men er steeds van kan uitgaan dat de microcontroller wel degelijk het correctecommando ontvangen heeft en dat de data die de robot inleest, de data is die de microcontrollerverstuurd heeft. Een voorbeeld van zo’n veiligheidsmechanisme is het feit dat de robot contro-leert of het eerst ontvangen karakter van de microcontroller correct is. Het is namelijk zo datelk commando volgens het KNET-protocol moet worden beantwoord met de ascii-code van hetcommando, maar dan als kleine letter (het commando zelf is meestal een hoofdletter). Indien deontvangen letter niet overeenkomt met het verstuurde commando, wordt het commando opnieuwverstuurd.

Bij het versturen van de opgemeten data (commando’s ’F’, ’G’ en ’H’) wordt voor de opge-meten data nog een extra byte meegestuurd vanop de microcontroller die een logische combinatie(XOR14) is van de andere twee verzonden bytes. Hiermee kunnen we controleren of het uitvoerenop de robot van de logische functie op de laatste twee ontvangen bytes hetzelfde resultaat geeftals de ontvangen eerste (extra) byte.

Ten slotte zorgen we er ook voor dat de Radio Turret niet aangesproken wordt tijdensde sonar(direction)-functie (algoritme 3.2), omdat dit soms tot ongewenste resultaten kanleiden. Tijdens het testen werden bijvoorbeeld onbestaande boodschappen via de Radio Turretontvangen wanneer de Sonar Turret aangesproken werd. Dit afspreken tussen de turrets gebeurtmet behulp van de sonarRequest-variabele. Wanneer die door de sonar(direction)-functieop ’1’ wordt gezet, zal het proces dat instaat voor het ontvangen van boodschappen via de RadioTurret dit opmerken en stoppen met het controleren van de Radio Turret tot deze sonarRequest-variabele opnieuw ’0’ wordt.

De C-code is te vinden op de bijgeleverde CD in de map ”Sonar Turret\C-code”.13A/D = Analoog-naar-Digitaal14De XOR-operatie geeft true enkel en alleen als slechts een (en niet meer) van de operandi true is.


Algoritme 3.2 De sonar(direction)-functie op de Khepera II1: error = 02: sonarRequest = 13: mess[2] = ’S’4: reserve channel5: send command (mess) to turret and wait for answer (ans)6: while (error sending OR ans[0]!=’s’) do7: release channel8: reset MSG-module (module for communicating with turrets)9: reserve channel

10: send command to turret and wait for answer11: end while12: release channel13: reset MSG-module14: if (direction == 0) then15: mess[2] = ’F’16: reserve channel17: send command (mess) to turret and wait for answer (ans)18: retry = 019: while (error sending OR ans[0]!=’f’ OR ans[1]!=(ans[2] XOR ans[3])) AND (retry < 25))

do20: release channel21: reset MSG-module (module for communicating with turrets)22: reserve channel23: send command to turret and wait for answer24: retry + +25: end while26: if (retry == 25) then27: error = 128: end if29: save received measured values in sonarLeft30: release channel31: reset MSG-module32: else if (direction == 1) then33: mess[2] = ’G’34: the rest is the same as with command ’F’, but save value in sonarFront35: else if (direction == 2) then36: mess[2] = ’H’37: the rest is the same as with command ’F’, but save value in sonarRight38: else if (direction == 3) then39: get all measured values by sending the commands ’F’, ’G’ and ’H’ sequentially40: end if41: sonarRequest = 042: return error


Figuur 3.9: Reflectie van een ultrasone bundel op een schuine muur volgens de wet van de reflectie:θ1 = θ2

3.8 Evaluatie van de Sonar Turret

Zoals we reeds eerder vermeldden, laat de Sonar Turret ons toe om zeer nauwkeurige, ruisvrijeafstandsmetingen te doen. Dit is een zeer groot voordeel ten opzichte van de ingebouwde in-fraroodsensoren en gaf het ons de mogelijkheid om formatievorming te verwezenlijken met deKhepera II -robots.

3.8.1 Nadelen van de Sonar Turret

Een nadeel van de Sonar Turret dat we reeds bespraken, is het feit dat andere robots niet meteen SRF05-module mogen gericht zijn naar de robot die meet in hun richting (omdat echo’szo verloren kunnen gaan). Dit is echter pas mogelijk als de robots elkaars positie voldoendenauwkeurig kunnen inschatten en dit is niet altijd het geval, zodat bijkomende veiligheidsme-chanismen ingebouwd moeten worden. We kunnen bijvoorbeeld steeds ook enkele graden linksen rechts van de te meten richting een afstandsmeting uitvoeren.

Een tweede nadeel van de Sonar Turret zijn de onbetrouwbare resultaten indien we de afstandtot een schuine muur proberen te meten. We bedoelen hiermee een muur waarvan de richtingniet loodrecht staat op de kijkrichting van de gebruikte SRF05-module. De verklaring hiervoor iseenvoudig. Wanneer een ultrasone bundel de schuine muur bereikt, zal die bundel gereflecteerdworden en het gereflecteerde deel in een richting vertrekken bepaald door de wet van de reflectie(zie figuur 3.9). Zoals ook te zien op deze figuur, zal de gereflecteerde bundel op die manierde sensor op de Sonar Turret niet meer bereiken. De Sonar Turret zal hieruit besluiten dat erzich geen object bevindt in de richting waarin we de meting uitvoerden, hetgeen niet correct is.Dit probleem wordt nog versterkt door de aanpassingen die we gemaakt hebben aan de SonarTurret om de bundelbreedte van de uitgestuurde ultrasone bundel te verkleinen. Toch was het


aanbrengen van deze aanpassingen noodzakelijk voor een nauwkeurige afstandsmeting in eenbepaalde richting en de aanpassing kon dus niet ongedaan gemaakt worden. Bijgevolg is hetprobleem van de detectie van schuine muren een probleem waarmee we rekening moeten houden,maar dat we niet kunnen vermijden.

Het grootste nadeel echter van de Sonar Turret is de tijdsduur die een meting in beslagneemt: gemiddeld vijf seconden per afstandsmeting. Het is niet de meting zelf die zoveel tijd inbeslag neemt, maar de communicatie tussen de Khepera II en de Sonar Turret via het KNET-protocol. Zoals reeds besproken in paragraaf 3.6, bleken er zeer veel vragen te bestaan rondde precieze werking van de KNET-bus. Ook al is de KNET-bus nu geımplementeerd zoals zebeschreven staat in [15], toch blijkt ze helemaal niet zo goed te werken als bij de turrets dieK-Team Corporation zelf ontwikkelde en die ook voor dit onderzoek beschikbaar waren (nl. deRadio Turret). De communicatie tussen de Khepera II en de Sonar Turret verloopt zeer traagen veel boodschappen gaan verloren of worden vervormd.Het probleem kan niet bij de microcontroller (PIC16F877A) liggen, aangezien die ons aangera-den werd door K-Team Corporation. We vermoeden een storing op het PCB door bijvoorbeeldoverspraak tussen naburige signaallijnen.Een andere mogelijkheid is dat er timing-verschil zit in het KNET-busprotocol dat door onsgeımplementeerd werd in vergelijking met het protocol dat K-Team Corporation zelf implemen-teert voor de turrets die zij ontwikkelen en dat dit voor een probleem zorgt. Om dit uit te zoekenzouden opnieuw uitvoerige tests uitgevoerd moeten worden met de Sonar Turret, maar hiervoorontbrak de tijd tijdens deze scriptie. Met de veiligheidsmechanismen (cfr. paragraaf 3.7) diewe ingebouwd hebben, werkt de Sonar Turret - zij het zeer traag - en dus zijn we onmiddellijkbegonnen met de implementatie van formatievormingsalgoritmes zonder uit te zoeken of we deSonar Turret sneller konden maken.

Een totaal andere mogelijkheid om de Sonar Turret sneller te maken is het herontwerpenvan de Sonar Turret. Deze mogelijkheid zullen we bespreken in de volgende paragraaf.

3.9 Nieuw ontwerp Sonar Turret (Rev. 1)

In de eindfase van dit scriptieonderzoek hebben we nagegaan of bij het ontwerp van een nieuweSonar Turret de communicatie via de KNET-bus vermeden kan worden. De inspiratie hebbenwe gehaald bij de sonarsensor die ontworpen is voor de Koala II 15 [16]. Het versturen van deopgemeten data van de turret naar de robot verloopt dan niet via de KNET-bus maar via deingebouwde analoog-naar-digitaal converter van de Khepera II.Voor de aansturing van de turret vanop de robot werken we in dit geval niet met het principevan seriele extensieturrets, maar met het principe van een parallelle extensieturret (paragraaf3.3).Het principe van aansturing en uitlezing werkt als volgt. We starten een sonarmeting via hetcommando var_put_extension(adres, 0) op de Khepera II. De microcontroller leest het adresdat aangelegd wordt door de Khepera II en controleert welke sonarmodule aangestuurd moetworden. Elke sonarmodule (links, vooraan of rechts) komt overeen met een ander adres dat dient

15De Koala II is een andere mini-robot die door K-Team Corporation ontwikkeld werd.


aangelegd te worden door de Khepera II. De microcontroller start dan de correcte SRF05-module(die hoort bij het aangelegde adres) en meet de duur van de puls op de Echo Output-pin vande SRF05-module. Om deze opgemeten data door te sturen naar de robot zet hij de opgemetentijd nu eerst om naar een analoge waarde via een digitaal-naar-analoog converter (zie paragraaf3.9.1). De analoge waarde die de opgemeten tijd voorstelt, wordt dan naar een pin gestuurdvan de Khepera II die intern verbonden is met een analoog-naar-digitaal converter (CH3 -/CH4 -/CH5 -pin). Deze (opnieuw gedigitaliseerde) waarde kan dan in de code van de robot gebruiktworden na het uitvoeren van de ingebouwde functie sens_get_ana_value(CH_X).

3.9.1 De MAX530 DAC

Een digitaal-naar-analoog converter is helaas niet aanwezig op de gebruikte PIC16F877A. Eeneenvoudig te gebruiken converter die zeer snel kan worden aangestuurd door de microcontroller isde MAX530 van Maxim [17]. De MAX530 is een 12-bits precisie digitaal-naar-analoog convertermet parallelle ingangen, zodat 4096 (12 bits) verschillende analoge waarden kunnen gegenereerdworden tussen 0V en 5V. De MAX530 beschikt over acht data-ingangen die toelaten om de 12bits in slechts twee cycli (eerst de laagste acht bits, dan de hoogste vier bits) naar het geheugenvan de DAC te schrijven. Na het aanleggen van een lage puls (4 µs, 0V) aan de LDAC-pin, wordtde analoge waarde die overeenstemt met deze 12 bits aan de uitgang van de DAC gegenereerd.

3.9.2 PCB van de vernieuwde Sonar Turret

In figuur 3.10 is het layout-ontwerp te zien van de nieuwe Sonar Turret. We hadden ervoorkunnen kiezen om bij het nieuwe ontwerp ook een extra SRF05-module te plaatsen die de robottoelaat om ook achter zich een afstandsmeting uit te voeren. Tijdens de ontwikkeling van enkeleformatievormingsalgoritmes (zie hoofdstuk 5) is gebleken dat dit tijd kan besparen (omdat derobot zich dan niet in die richting hoeft te draaien). Toch bleek dit achteraf geen goed ideeomwille van het probleem van de echo’s die verloren gaan (paragraaf 3.5.1). Stel dat we eenvierde SRF05-module plaatsen om de robot toe te laten achter zich te meten, dan zou de robotdie opgemeten wordt, zich al zeer precies moeten positioneren ten opzichte van de robot die aanhet meten is om geen risico te lopen op een verloren gaande echo. Dit zou dan enkel mogelijk zijnindien de robots elkaars positie en orientatie perfect kennen en zoals zal blijken uit hoofdstuk 5is dit niet altijd het geval.

We zien in figuur 3.10 heel wat meer signaallijnen dan in het vorige ontwerp (figuur 3.4). Ditis in de eerste plaats te wijten aan de data- en controlelijnen waarmee we de DAC aansturen(rechtsboven op de figuur) en in de tweede plaats aan de adreslijnen die komen van de KheperaII en die we moeten inlezen om te detecteren wanneer de robot een sonarmeting wenst en inwelke richting. Dit is een rechtstreeks gevolg van het werken met een parallelle extensieturretin plaats van een seriele extensieturret.


Figuur 3.10: PCB-layout van de Sonar Turret Rev. 1

3.9.3 Code voor de microcontroller

In deze paragraaf geven we een schematisch overzicht van de Assembler-code16 waarmee denieuwe Sonar Turret moet worden geprogrammeerd (zie ook Algoritme 3.3).

• De code die zich bevindt voor het Main-label, zorgt ervoor dat de verschillende modulesvan de microcontroller correct geconfigureerd worden en dat alle variabelen die we ver-der zullen gebruiken geınitialiseerd worden. Verder worden ook alle I/O-pinnen correctgeconfigureerd.

• De code die zich na het Main-label bevindt, zal sequentieel en cyclisch doorlopen wordentot de voeding wegvalt of de microcontroller gereset wordt.De code begint met het pollen van de B4 -pin (deze is verbonden met de CSExt-pin vande Khepera II ). Dit gebeurt in een lus die wacht tot de B4 -pin laag (0V) komt.

• Vervolgens wordt het door de Khepera II aangelegde adres ingelezen en wegschreven naarde variabele RXADDRESS en deze wordt vergeleken met alle mogelijke adressen die overeen-komen met de verschillende SRF05-modules van de Sonar Turret. Zo zal het aanleggenvan adres ‘16’ aanleiding geven tot een afstandsmeting in de linkerrichting, adres ‘17’ aan-leiding geven tot een afstandsmeting in de riching recht voor de robot, enz.

16De volledige code is te vinden op de bijgeleverde CD in de map”Sonar Turret Rev 1\PIC16877A Rev 1”.


Algoritme 3.3 PIC16F877A Rev. 11: initialise variables2: initialise modules3: initialise I/O-pins4: Main label5: loop6: while (pin B4 high) do7: wait8: end while9: Read address (RXADDRESS) generated by the Khepera II

10: if (RXADDRESS == ’16’) then11: trigger left SRF05-modules and measure echo-time with 16-bit timer-module12: save 16-bit timer-value in 2 bytes (TXDATA low and TXDATA high)13: goto sendValuesDAC14: else if (RXADDRESS == ’17’) then15: trigger front SRF05-modules and measure echo-time with 16-bit timer-module16: save 16-bit timer-value in 2 bytes (TXDATA low and TXDATA high)17: goto sendValuesDAC18: else if (RXADDRESS == ’18’) then19: trigger right SRF05-modules and measure echo-time with 16-bit timer-module20: save 16-bit timer-value in 2 bytes (TXDATA low and TXDATA high)21: goto sendValuesDAC22: else23: goto Main24: end if25: sendValuesDAC label26: generate 4 highest bits for DAC27: generate low pulse on WR/CS-pin of DAC28: generate 8 lowest bits for DAC29: generate low pulse on WR/CS-pin of DAC30: generate low pulse on LDAC-pin of DAC31: end loop


• De desbetreffende SRF05-module zal dan gestart worden via een puls (12 µs, 5V) op deTrigger Input-pin en de duur van de echo zal gemeten worden op de Echo Output-pin viade ingebouwde 16-bit timermodule.

• Deze 16-bit waarde zal vervolgens omgezet worden naar een 12-bit waarde (omdat deMAX530 slechts een resolutie heeft van 12 bits) en zal in twee cycli geschreven worden naarde DAC. De conversie van 16-bit naar 12-bit kan op verschillende manieren gebeuren, zodatde range en resolutie van de Sonar Turret aangepast kunnen worden door de microcontrollerte herprogrammeren.

• Ten slotte wordt er een negatieve puls (4µs, 0V) gegenereerd op de LDAC-pin zodat deanaloge waarde aan de uitgang van de MAX530 verschijnt.

3.9.4 Aansturing vanop de Khepera II

De aansturing vanop de Khepera II blijft ook nu eenvoudig. Door het oproepen van de in-gebouwde functie var_put_extension(adres, 0), waarbij het adres de waarden 16, 17 of 18kan aannemen, kunnen we een sonarmeting uitvoeren in de gewenste richting. Via de functiesens_get_ana_value(3) (De DAC is aangesloten op de CH3 -pin van de Khepera II, dus moetenwe hier als argument ”3” gebruiken), kunnen we dan de analoge waarde, die de duur van de echovoorstelt, inlezen. We dienen er wel rekening mee te houden dat deze twee functies niet te snelna elkaar uitgevoerd mogen worden, om de turret voldoende tijd te geven om de sonarmetinguit te voeren en de analoge waarde te genereren.Een tweede mogelijkheid zou zijn om een I/O-pin van de microcontroller te verbinden met bij-voorbeeld de CH4 -pin van de Khepera II en de microcontroller deze pin enkel hoog (5V) telaten zetten wanneer de analoge waarde (op CH3 ) klaar is om ingelezen te worden. De KheperaII kan dan door het pollen van deze CH4 -pin (via sens_get_ana_value(4)) controleren of hijal een nieuwe analoge waarde op CH3 mag inlezen.

Hoofdstuk 4

Formatiegedrag met IR-sensoren

Inhoudsopgave

4.1 De IR-sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2 Formatievorming: doelstellingen . . . . . . . . . . . . . . . . . . . . . . 71

4.3 Nieuwe aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.4 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

In dit hoofdstuk bespreken we de algoritmes die ontwikkeld werden voor formatievormingmet behulp van de ingebouwde IR-sensoren. De C-code die deze algoritmes implementeert opde robot is te vinden op de bijgeleverde CD in de map ”Formation with IR sensors”

4.1 De IR-sensoren

De Khepera II robot heeft acht IR-sensoren die verdeeld zijn over de robot zoals te zien is opfiguur 4.1. Er zijn twee opvallende zaken aan de verdeling. Ten eerste staan de zijsensorenniet loodrecht op de hoofdrichting, maar maken ze een hoek van ongeveer 80 graden met dehoofdrichting. De hoofdrichting is de richting die in figuur 4.1 aangeduid is met de zwarte pijl.Dat de zijsensoren niet loodrecht op de hoofdrichting staan, zal bepaalde zaken bemoeilijkenzoals doelstelling 3 in paragraaf 4.2.

Ten tweede is het zicht naar achter veel beperkter, omdat daar maar twee sensoren staan integenstelling tot de zes die naar voor gericht zijn. De plaatsing van de sensoren geeft aan dat deKhepera II beter geschikt is om een andere robot te volgen of zijn weg te zoeken in een labyrintdan om bijvoorbeeld parallel te rijden naast een andere robot.

4.1.1 Metingen met de IR-sensoren

De IR-sensoren kunnen metingen uitvoeren volgens twee principes:

1. Ambient light: Hierbij wordt de sterkte van de infraroodcomponent (λ = 950 nm) dieaanwezig is in het omgevingslicht door de sensor gemeten .

69

Hoofdstuk 4. Formatiegedrag met IR-sensoren 70

Figuur 4.1: IR-sensoren op de robot

2. Reflected light: Hierbij wordt, naast het ambient light, ook de sterkte van een weer-kaatste uitgestuurde IR-bundel gemeten en wordt de som van de twee opgemeten waardenteruggegeven.

Het ambient light geeft enkel aan hoe sterk de IR-component is in het omgevingslicht. Dezeinformatie was voor ons onderzoek irrelevant en werd verder dan ook niet opgevraagd. De reflec-tiewaarden zijn een indicatie voor de afstand tot een voorwerp (verder besproken in paragraaf4.1.2). We spreken af dat, als vanaf nu over de IR-waarden gesproken wordt, we daarmee degereflecteerde waarden bedoelen. De details van de sensoren staan beschreven in referentie [7,paragraaf 3.1.6], maar het is vooral belangrijk om te weten dat de acht sensoren sequentieelworden aangestuurd en ingelezen en dat dit vanuit de software op de robot niet kan wordengestopt. Of de robot de IR-waarden nu opvraagt of niet, de sensoren zullen blijven meten. Bei-de zaken komen later in de scriptie aan bod, omdat ze de werking van de sensoren bepalen inaanwezigheid van andere robots.

4.1.2 Interpretatie van de metingen

De gereflecteerde waarden liggen steeds tussen 0 en 1023 (10 bit getal: 210 = 1024) en geveneen heel ruwe indicatie over de afstand van de robot tot een object. Als er geen voorwerp in debuurt van de robot staat, is de waarde niet nul. Afhankelijk van de sensor kan dit tussen 60 en120 liggen, maar dit is voor elke sensor anders.

In figuur 4.2 is een grafiek te zien van de IR-sensorwaarden, uitgezet in functie van de afstandtot een andere robot. We zien dat de waarden van de sensoren pas beginnen oplopen als de roboteen andere robot op minder dan 3 cm nadert.De gereflecteerde waarde op grote afstand valt niet op nul maar blijft, zoals eerder vermeld, inde buurt van 100. Dit zal vanaf nu de achtergrondruis genoemd worden. Wanneer een object


zich op meer dan 3 cm bevindt, kan de gereflecteerde waarde niet meer onderscheiden wordenvan de achtergrondruis. Dit toont meteen het beperkte bereik aan van de IR-sensoren.De gereflecteerde waarde bij een voorwerp op een cm is de hoogste in de grafiek. De redenhiervoor is dat de IR-sensoren in de behuizing van de Khepera II verwerkt zitten en dat dezebehuizing helemaal onderaan iets breder is. Hierdoor zullen de IR-sensoren, wanneer twee robotsperfect tegen elkaar staan met hun behuizing, altijd op een afstand van 1 cm van elkaar blijven.De reden waarom de grafiek daalt bij nog kleinere afstanden is ons niet geheel duidelijk, maarheeft hoogstwaarschijnlijk te maken met de aanstuurelektronica die achter de IR-sensoren zit.

Figuur 4.2: Detecteren van een andere robot

4.2 Formatievorming: doelstellingen

In referentie [6, Sectie 7.2.14] werden met de hulp van de IR-sensoren al verschillende algoritmesontwikkeld. Een eerste is bedoeld om een robot een muur te laten volgen. Een tweede bevatteeen kleine aanpassing waardoor dit algoritme ook kon gebruikt worden om twee robots naastelkaar te laten rijden1. Dit algoritme bleek echter niet in alle situaties te werken, maar wehebben getracht om op deze resultaten verder te bouwen.Het voordeel van deze ingebouwde IR-sensoren is dat ze zeer snel opeenvolgende metingen kun-nen uitvoeren waardoor formatievorming in real-time (terwijl de robots rijden) in principe mo-gelijk wordt.

De eerstvolgende uitbreiding hierop die we zelf implementeerden, had betrekking op hetparallel naast elkaar rijden. Twee robots zullen vanuit een willekeurige positie starten en elkaarop een bepaalde plaats ontmoeten. Onder de voorwaarde dat ze geen obstakels op hun pad naar

1Hierbij fungeert elke robot dan als een soort van rijdende muur voor de andere.


elkaar tegenkomen, zullen ze elkaar detecteren en stoppen. Vervolgens zullen ze proberen zichzo te orienteren dat ze beide in dezelfde richting ‘kijken’2.Er moeten dus vier doelstellingen gerealiseerd worden:

1. Doelstelling 1: Naar elkaar toe rijden en stoppen.

2. Doelstelling 2: Afspreken in welke richting ze zullen draaien.

3. Doelstelling 3: Draaien in de afgesproken richting en stoppen wanneer de zijkant naarde andere robot gericht is.

4. Doelstelling 4: Parallel rijden naast elkaar volgens het muurvolgen-principe.

Doelstellingen 1 tot 3 werden los van elkaar getest, waarbij we telkens het algoritme uitvoer-den op een robot en waarbij een kartonnen doos of stilstaande robot, de andere robot in hetalgoritme voorstelde.

Na het realiseren van de vier doelstellingen kan het idee uitgebreid worden naar drie robots.

4.2.1 Doelstellingen 1 en 4

De uitwerking van de eerste doelstelling werd reeds beschreven in referentie [6], waarbij de robotseen muur moesten vinden. Van zodra de sensorwaarden een bepaalde drempel overschrijden,stopt de robot. Ook de vierde doelstelling werd in het onderzoek van referentie [6] gerealiseerd,zoals eerder vermeld.

4.2.2 Doelstelling 2

De robots spreken af in welke richting ze zullen draaien. Om deze doelstelling te bereiken is ernood aan communicatie tussen de robots en hiervoor wordt de communicatiestructuur gebruiktdie we bespraken in hoofdstuk 2.Als de robots na doelstelling 1 elkaar vinden, zullen ze een boodschap naar elkaar sturen metde volgende gegevens:

• Het nummer van de sensor die de grootste waarde heeft (enkel de voorste zes sensorenworden in rekening gebracht, omdat de robot vooruit rijdt om de andere robot te zoeken)

• De waarde van die sensor zelf

• Een randomwaarde

Elke robot kent op dat moment niet alleen zijn eigen drie waarden, maar ook die van de andererobot. Via deze informatie kan op een eenduidige manier bepaald worden in welke richting derobots, volgens het algoritme, moeten draaien, opdat ze uiteindelijk zullen alligneren.

We zullen er in dit algoritme voor zorgen dat wanneer twee robots elkaar vinden met devoorste sensoren, beide in een verschillende richting draaien om zich uiteindelijk in dezelfde

2De kijkrichting is hier gelijk aan de hoofdrichting die we reeds bespraken in paragraaf 4.1.


richting te positioneren. Als de robots in dezelfde richting draaien, kunnen ze ook alligneren,maar dan zal de ene robot veel meer moeten draaien. Naast een verspilling van tijd, zou hierdoorde uitvoering van doelstelling 3 niet meer mogelijk zijn door de plaatsing van de zijsensoren,maar dit wordt verder verduidelijkt in paragraaf 4.2.3. Het draaien is te zien in figuur 4.3.Als ze beide in dezelfde richting willen kijken, zijn er maar twee mogelijkheden: naar onder ofnaar boven. Als ze naar boven draaien, volgens de gestippelde pijlen, moet de linkerrobot integenwijzerzin draaien en de rechter in wijzerzin. In het andere geval is de situatie omgekeerden hun draairichtingen ook.

Figuur 4.3: Draairichtingen van de robots

Tabel 4.1: Draaitabel voor een robot met 2 sensoren

eigen Max Sensor ander Max Sensor

2 3

2 - -1

3 1 -

We hebben een draaitabel opgesteld die afhangt van de eigen sensor met maximale waardeen die van de ander. De waarde −1 staat voor het draaien in wijzerzin, de waarde 1 voor draaienin tegenwijzerzin. Deze tabel is dezelfde voor alle robots. Ze is anti-symmetrisch, zodat ze ineen andere richting zullen draaien met elkaars informatie. Dit wordt eenvoudig geıllustreerdbij een robot die enkel de voorste twee sensoren (2 en 3) gebruikt in tabel 4.1. Als ze eenverschillende sensor hebben die maximaal is (zie figuur 4.4), dan zullen ze in een tegengestelderichting draaien, net omdat de tabel anti-symmetrisch is.In het geval dat bij de linkerrobot sensor 2 maximaal is en bij de rechter sensor 3, dan zullen zebeiden naar beneden willen kijken, omdat ze zo het minst moeten draaien. Na het raadplegenvan tabel 4.1 zal de linkerrobot inderdaad in wijzerzin (-1 in de tabel) draaien en de rechter integenwijzerzin (1 in de tabel).

Als de beide robots dezelfde sensor hebben met een maximale waarde, zullen ze eerst kijkenof hun eigen sensorwaarde groter is dan die van de ander. De robot met de grootste waarde zalin tegenwijzerzin draaien en de ander in wijzerzin. Er is echter ook een kleine kans dat beidedezelfde sensorwaarde hebben en daarom kan dezelfde test nog eens uitgevoerd worden op hunrandomwaarde om in elke situatie uitsluitsel te brengen.


Figuur 4.4: Ontmoeting met verschillende maximale sensor

Bij de test werden de robots op voldoende kleine afstand van elkaar gezet, zodat ze elkaarmeteen detecteerden. Na het uitwisselen van de boodschappen draaiden ze beide steeds in degoede richting. Dit afspreken is een typisch voorbeeld van hoe de communicatie voornamelijkgebruikt zal worden. Doelstelling 2 wordt nog eens schematisch weergegeven in algoritme 4.1vanaf het moment dat de communicatieboodschappen uitgewisseld zijn en beide robots overelkaars gegevens beschikken.

Figuur 4.5: Situatie na het draaien

4.2.3 Doelstelling 3

Opdat de robots naast elkaar zouden staan, kunnen ze draaien op twee manieren: over een vastaantal graden of tot een zijsensor maximaal wordt. In het eerste geval moet exact geweten zijnonder welke hoek de robots elkaar zullen ontmoeten. Bij de tweede mogelijkheid is dit niet hetgeval en zal de robot zich met zijn zijkant naar de andere robot kunnen richten vanuit eenderwelke startpositie. We kiezen dan ook voor deze tweede optie.

De robots draaien ter plaatse rond3 en lezen de waarde van hun zijsensor uit. Als die hogerewaarden aanneemt, zal de robot met zijn zijkant meer naar het voorwerp toegekeerd zijn. Alsde waarden weer dalen, zal de robot zich van het voorwerp wegdraaien zoals te zien is in figuur4.6. Het komt er dus op neer om een maximum te detecteren. Op dat moment moet de robot

3Dit wordt gerealiseerd door aan beide wielen een tegengestelde snelheid te geven.


Algoritme 4.1 Doelstelling 21: if (own sensor maximal 6= sensor other maximal) then2: Look up direction of rotation in the table3: else4: if (value own sensor maximal < value sensor other maximal) then5: Rotate clockwise6: else if (value own sensor maximal > value sensor other maximal) then7: Rotate counterclockwise8: else if (value own sensor maximal == value sensor other maximal) then9: if (own random value < random value other) then

10: Rotate clockwise11: else12: Rotate counterclockwise13: end if14: end if15: end if

stoppen en staat hij met zijn zijkant naar het voorwerp gekeerd.Het is een probleem dat de zijsensoren niet helemaal op de zijkant staan, maar een beetje naarvoor, zoals reeds eerder vermeld. De robot zal bijgevolg voorbij het maximum moeten draaientot de IR-waarden onder een zeker niveau gezakt zijn. Dit niveau kan absoluut of relatiefgedefinieerd worden ten opzichte van het maximum. Als we figuur 4.6 doorlopen van bovennaar onder, dan draait de robot in tegenwijzerzin. Links staan de robotposities ten opzichte vande muur en rechts een kwalitatieve illustratie van het verloop van de sensorwaarden van sensor5.

Figuur 4.6: Verloop van een zijsensor bij een muur

In realiteit ziet de grafiek er niet zo glad uit als in figuur 4.6. De ruwe waarden bevatten


veel ruis, zoals te zien is in figuur 4.7.

Maximum vinden in real-time

Er zijn twee manieren om het maximum in real-time te vinden.De eerste manier (algoritme 4.2) bestaat erin om te controleren hoeveel een waarde kleiner isdan de vorige opgemeten waarde. Als dit verschil groter is dan een bepaalde ruisdrempel4, kanaangenomen worden dat het maximum reeds bereikt werd en de waarden al weer aan het dalenzijn.Dit algoritme leverde in onze situatie geen consistente resultaten op. Soms draaide de robot nietver genoeg door en soms te ver. De reden hiervoor is de ruis, die een plotse piek kan veroorzakenin het signaal, zodat het algoritme er vroegtijdig vanuit gaat dat het maximum bereikt werd.Het is bovendien belangrijk dat de zijsensoren niet loodrecht op de zijkant staan. Hierdoor moetde robot niet alleen voorbij het maximum draaien, maar de mate van doordraaien moet zeerprecies zijn, opdat de robot steeds op dezelfde positie zou stoppen. Dit kon niet gerealiseerdworden door enkel twee opeenvolgende waarden te bekijken. Deze eenvoudige methode, weerge-geven in algoritme 4.2, kan in deze situatie dus niet gebruikt worden.In het algoritme staat read new IR value() voor de functie die de laatste sensorwaarde op-vraagt. Uit experimenten is gebleken dat de waarde 30 voor het verschil tussen twee opeenvol-gende metingen een goede keuze is. Die moet groot genoeg zijn, zodat plotse ruisschommelingenhet mechanisme niet triggeren en tegelijk mag deze waarde ook niet te groot gekozen worden,opdat een echte daling nog gedetecteerd zou worden.

Algoritme 4.2 Maximum vinden in real-time: differentieel1: current sensor value = read new IR value()2: repeat3: previous sensor value = current sensor value4: current sensor value = read new IR value()5: until ((previous sensor value - current sensor value) > 30 )6: Maximum reached ⇒ Stop robot!

De tweede manier (algoritme 4.3) bestaat erin om zelf het maximum te bepalen door rekeningte houden met alle reeds opgemeten IR-waarden. Dit kan door de waarde van een tijdelijkmaximum steeds te verhogen als een sensorwaarde voorkomt groter dan het tijdelijke maximum.Deze waarde is dan het nieuwe maximum. Indien de sensorwaarden onder een fractie van ditmaximum duiken, werd het maximum bereikt. Door de fractie te veranderen, kunnen we regelenhoeveel de waarden moeten zakken en hoeveel de robot dus nog doordraait na het detecterenvan een maximum op zijn zijsensor.De onderste grafiek in figuur 4.6 illustreert deze aanpak. Als de fractie zo wordt gekozen dathet niveau overeenkomt met de rode stip, dan zal de robot stoppen bij de eerste sensorwaardedie kleiner is dan die rode stip. Algoritme 4.3 beschrijft het idee waarbij het stopniveau bepaaldwordt door zowel de fractieparameter als het bereikte maximum. De fractieparameter moet zogekozen worden dat de robot net genoeg doordraait om perfect gepositioneerd te zijn met zijnzijkant.

4Dit is de maximale amplitude van de ruiscomponent die aanwezig is in het opgemeten signaal.


Het verder doordraaien om exact parallel te eindigen met het object naast de robot, heeftevenwel gevolgen op de te kiezen draairichting. Om de robot met zijn rechterzijde ergens naar toete richten, wordt er gebruikt gemaakt van sensor 5. In dit geval moet de robot in tegenwijzerzindraaien zodat hij nog even verder zal draaien in tegenwijzerzin en zo net op zijn rechterzijkantzal eindigen. In het geval dat de robot zich met zijn linkerkant wil positioneren via sensor 0,moet hij in wijzerzin draaien.

De ruis vormt bij deze manier van werken een aanzienlijk probleem, omdat de onzekerheid ophet maximum en de fractie toeneemt, waardoor het moeilijk is de robot consequent op dezelfdeplaats te laten stoppen. Daarom werd ervoor gekozen om de sensorwaarden in real-time uit temiddelen.

Algoritme 4.3 Maximum vinden in real-time: tweede methode1: maximum = 02: fraction = 0.803: repeat4: current sensor value = read new IR value()5: if (current sensor value > maximum) then6: maximum = current sensor value7: end if8: until (current sensor value < (fraction ∗maximum))9: Maximum reached ⇒ Stop robot!

Uitmiddelen in real-time

De ruwe sensorwaarden bij het draaien naar een voorwerp, worden weergegeven in figuur 4.7.

Figuur 4.7: Sensorwaarden zonder uitmiddeling al draaiend bij een voorwerp

Er zit een duidelijk lijn in de sensorwaarden die oplopen naarmate de robot zich meer draaitin de richting van het voorwerp. We zien echter ook dat de sensorwaarden een belangrijke


ruiscomponent bevatten. De grootte van deze ruissprongen blijft normaal onder de 30, wat ookde waarde van het verschil verklaart tussen twee opeenvolgende waarden in algoritme 4.2. Detweede manier om het maximum te vinden (paragraaf 4.2.3) zou aanzienlijk betere resultatenopleveren met kleinere ruiscomponenten. Daarom werd ervoor geopteerd om de sensorwaardenuit te middelen met behulp van een Exponential Moving Average mechanisme [18]:

EMA = ([sensorwaarde− EMA(vorig)]× gewicht) + EMA(vorig) (4.1)

De mate waarin het lopend gemiddelde beınvloed wordt door een nieuwe meetwaarde hangt afvan de parameter ‘gewicht’. Een voorbeeld waarbij het EMA-mechanisme toegepast werd opeen reeks IR-waarden, is te zien in figuur 4.8.

Figuur 4.8: Sensorwaarden met een lopend gemiddelde (i.c. parameter gewicht : 0.0645)

Dankzij het uitmiddelen werd doelstelling 3 veel betrouwbaarder uitgevoerd, zodat de robotbijna altijd met zijn zijkant parallel aan het voorwerp stopte.In de rest van dit hoofdstuk wordt dit EMA-principe dan ook op alle sensorwaarden toegepast.

Het nadeel van EMA is dat de robot grote veranderingen in zijn sensorwaarden iets trageropmerkt, omdat het verleden een verzachtende invloed heeft op het EMA. Een voordeel is dateen veel kleinere stijging van de sensorwaarden al meteen mag geınterpreteerd worden als hetnaderen van een voorwerp. Het belangrijkste voordeel is echter het gladdere verloop, wat hetmakkelijker maakt om een marge in te stellen als er iets gedetecteerd moet worden.

4.2.4 Problemen bij de realisatie van de gezamelijke doelstellingen

De vier doelstellingen werkten naar behoren toen ze apart getest werden met een kartonnen doosof een uitgeschakelde robot. De volgende stap was het uittesten van de combinatie van de vierafzonderlijke algoritmes waarbij de robots recht tegenover elkaar gezet werden als startpositie,


zodat ze bij het recht vooruit rijden elkaar zeker zouden vinden.

De testen verliepen echter niet helemaal zoals gepland. Vreemd genoeg ging het meestal alfout bij doelstelling 1. Dit is nochtans het meest eenvoudige programma, omdat de robot enkelmoet rijden tot zijn sensorwaarden oplopen. De robots stopten vaak wanneer de afstand tussenhen beide nog veel te groot was. Na het herhaaldelijk uitvoeren van het experiment, bleek datelk experiment tot een van de drie volgende klassen behoort:

1. De sensorwaarden lopen normaal op en de robots detecteren elkaar op zo’n 2 cm.

2. De sensorwaarden lopen sterk op wanneer de robots zich nog op grote afstand van elkaarbevinden en de robots stoppen bijgevolg te vroeg.

3. De sensorwaarden gaan naar nul, zodat de robots botsen.

Het grote verschil met het testen van de aparte doelstelling was het feit dat we nu, bijhet testen van het totale algoritme, telkens werkten met twee robots die hetzelfde algoritmeuitvoerden. De problemen die opdoken, bleken dan ook de schuld te zijn van de tweede robot.Wanneer beide robots werken, voeren ze voortdurend metingen uit met hun IR-sensoren. Ditzorgde in ons geval voor beınvloeding tussen de IR-sensoren van verschillende robots.

Figuur 4.9: Situatie waarbij sensoren elkaar kunnen beınvloeden

De verklaring voor deze beınvloeding is waarschijnlijk dat de IR-bundel van de ene robot opde IR-sensoren van de ander invalt en zo de waarden van de laatste beınvloedt. De observatiein de voorgaande paragraaf laat uitschijnen dat het probleem niet zuiver van ruimtelijke aardis, aangezien het fenomeen soms niet opduikt als de robots recht naar elkaar toerijden hoeweler op die manier altijd een vorm van overlapping5 is.

De zaken liggen dus iets subtieler, omdat de sensoren sequentieel gecontroleerd worden (pa-ragraaf 4.1). Dit gebeurt om de 2.5 ms per IR-sensor, zodat om de 20 ms de acht sensorengecontroleerd worden. Overlapping zal dus niet enkel ruimtelijk, maar ook in de tijd moetengebeuren. Als de sensor van de ene robot een IR-bundel uitstuurt die op een sensor van de

5Er zal altijd minstens een bundel van een bepaalde IR-sensor gericht zijn op een sensor van de andere robot.


ander terechtkomt op het moment dat de andere robot deze sensor net inleest, is de kans opbeınvloeding groot. Dit is te zien in figuur 4.9: de sensoren met groene stippen kunnen beınvloedworden door een bundel afkomstig van de rechterrobot.Als het meten links en het sturen rechts tegelijk gebeurt, dan krijgen deze sensoren geen ver-zwakte gereflecteerde bundel binnen, maar wel een van de andere robot die enkel geattenueerd isdoor propagatie in lucht. Dit zal dan een hoger signaal opleveren dan verwacht, wat het oplopenvan de sensorwaarden op grote afstand verklaart.

Er is natuurlijk ook een kans dat op het moment dat een bundel invalt op een deel van desensoren van een andere robot, deze robot andere sensoren aan het inlezen is, zodat er geenbeınvloeding is (afgebeeld in figuur 4.10: de vier sensoren die op dat moment ingelezen kunnenworden (met blauwe stip), liggen buiten het bereik van de inkomende bundel).

Door het grotere aantal sensoren vooraan zal de kans dat de sensoren elkaar beınvloedenwanneer ze recht op elkaar af rijden relatief groot zijn. Dit blijkt ook uit de experimenten,waarbij er een kans was van twee op drie dat er iets fout liep.

Het onterecht dalen van de sensorwaarden is een heel stuk moeilijker te verklaren. De enigeverklaring die we konden bedenken is de volgende. We weten dat het opmeten van een gere-flecteerde waarde eigenlijk uit twee fases bestaat. In een eerste fase wordt het ambient lightopgemeten en in een tweede fase wordt een IR-bundel uitgestuurd en wordt de gereflecteerdewaarde opgemeten. De totale waarde is dan de som van de ambient light-waarde en de gereflec-teerde waarde.Om het dalen van de totale waarde te verklaren, gaan we uit van het feit dat de ambient light-waarde kleiner wordt naarmate er meer IR-licht aanwezig is. Wanneer er nu een IR-bundel opde sensor valt tijdens het opmeten van de ambient light-waarde, zal die dus naar nul gaan en zalbijgevolg ook de totale waarde naar nul gaan (waarbij we ervan uitgaan dat ook de gereflecteerdewaarde zeer klein is, omdat er geen object in de buurt is).

Figuur 4.10: Situatie waarbij sensoren elkaar niet kunnen beınvloeden


4.3 Nieuwe aanpak

In het voorgaande deel werd geschetst hoe de sensoren zowel in tijd als in ruimte moeten over-lappen om beınvloeding te krijgen. Eens de robot in een ongewenst regime zit, zal hij er nor-maalgezien in blijven, omdat de sensoren van de beide robots aan dezelfde snelheid gecontroleerdworden.Er bestaat echter een mogelijkheid om de robots vanuit de software te resetten, waarbij hetmogelijk is dat de robot in een goed regime terechtkomt, omdat er geen overlapping in de tijdmeer is. Dit komt overeen met de overgang van figuur 4.9 voor het herstarten naar figuur 4.10na het herstarten. Er is echter ook een kans dat de robot opnieuw in een ongewenst regimeterechtkomt. We blijven de robot dan herstarten totdat een goed regime bereikt wordt. Eensin een goed regime, kan de robot hopelijk zijn normale programma vervolgen zonder proble-men. Deze belangrijke veronderstelling vormde de basis voor de oplossing die in de volgendeparagrafen geschetst zal worden.

4.3.1 Dalende waarden opvangen

Dalende waarden opvangen kan eenvoudig door te controleren of de waarden onder een bepaaldedrempel zakken. We moeten deze drempel wel per sensor apart en dynamisch6 bepalen, omdatniet elke sensor in elke startsituatie dezelfde hoeveelheid achtergrondruis meet. Het kiezen vandeze drempel gebeurt door bij het opstarten de robot eerst 100 metingen te laten doen en delaatste EMA-waarde te nemen als referentiewaarde. De grens om dalende waarden te vinden isdan bijvoorbeeld veertig lager dan de referentiewaarde en de grens om een voorwerp te detecterenveertig hoger.

Door een correcte keuze van deze bovengrens, kan men de afstand bepalen waarbij de robotselkaar zullen detecteren. Hoe kleiner die grens, hoe eerder ze elkaar zullen vinden. Als de grenste groot gekozen wordt, zullen de robots botsen.

Het geval van dalende waarden is gemakkelijk op te sporen, omdat de waarden enkel doorruis wat onder de referentiewaarde gaan. Indien het regime van dalende waarden gedetecteerdwordt, herstart de robot zichzelf zoals te zien is in algoritme 4.4. Na het opstarten zal de robotopnieuw 100 metingen doen om op die manier een nieuwe referentiewaarde te bepalen. Hierdoorkrijgen we ook een nieuwe boven- en ondergrens.

De kans bestaat dat de robot tijdens deze eerste 100 metingen reeds in een ongewenst regimezit of terechtkomt en waarden opmeet die in de buurt van nul liggen. Hieruit kan hij danbesluiten om een zeer lage ondergrens te kiezen, wat niet wenselijk is. Om dit op te vangen iser een minimumwaarde voorzien voor de ondergrens.

Het regime van dalende waarden wordt geıllustreerd in figuur 4.11. Het herstarten van derobot wordt in de figuur telkens aangegeven met een rode stip. In het eerste geval starten dewaarden op een normaal niveau, worden ze op een bepaald ogenblik steeds kleiner, tot ze onderde ondergrens zakken, waarna de robot herstart.Na de herstart komt de robot opnieuw in een ongewenst regime terecht, aangeduid in het groen,

6Met dynamische willen we hier zeggen dat de waarde van de drempel niet voorgeprogrammeerd wordt.


Algoritme 4.4 Dalende waarden opvangen1: Measure 100 sensor values with EMA2: reference value = last EMA value3: lower bound = (reference value− 40)4: if (lower bound < 20) then5: lower bound = 206: end if7: upper bound = (reference value + 40)

8: repeat9: current sensor value = read new IR value()

10: if (current sensor value < lower bound) then11: Value too small ⇒ Restart robot!12: end if13: until (current sensor value > upper bound)

14: Maximum reached ⇒ Stop robot! and proceed to objective 2

waarbij de waarden al veel te klein zijn bij het herstarten van de robot en na de eerste 100waarden zijn ze dit nog steeds, waardoor de robot meteen zal herstarten. Daarna zijn de waardenopnieuw normaal.

4.3.2 Stijgende waarden opvangen

Het is veel moeilijker om een ongewenst regime van stijgende sensorwaarden te detecteren, omdathet niet te onderscheiden is van de situatie waarbij de IR-sensoren een voorwerp detecteren, tenzijde sensorwaarden echt abnormaal hoog zijn.Om dit ongewenst regime consequent te kunnen detecteren, hebben we nood aan een extra sensordie onafhankelijk van de IR-sensoren kan werken. In hoofdstuk 3 hebben we de ontwikkelingvan zo’n sensor (Sonar Turret) besproken en die wordt dan ook gebruikt om uit deze impasse tegeraken.

We beschouwen het experiment dat de robot recht op de andere robot af rijdt en dit valtuiteen in twee gevallen. Detecteert de robot een voorwerp via de IR-sensoren, dan kan hij viade Sonar Turret controleren of er echt een andere robot in de buurt staat. Is dit niet het geval,dan zal de robot herstarten en van voorafaan beginnen met algoritme 4.5.

Een extra veiligheid kan ingebouwd worden bij het herstarten, waarbij de robot in een regimekan terechtkomen met waarden die onmiddellijk veel te groot zijn. Als de referentiewaarde groteris dan 250, zou dit willen zeggen dat de robot eigenlijk al gebotst is. In dit geval zal de robotmeteen herstarten. Dat deze extra test belangrijk is, kan afgeleid worden uit figuur 4.12. Omdatde waarden voor sensor 3 steeds te groot waren, moest de robot 15 keer na elkaar herstarten,tot hij in een regime kwam met normale waarden zoals aangeduid is in het groen, rechts op defiguur. Het herstarten is te zien aan de nulwaarden op de figuur, aangegeven door rode stippen.Dit bewijst meteen ook het nut van de eerste 100 metingen waarbij pas na deze 100 metingen dereferentiewaarde vastgelegd wordt, omdat de eerste waarden duidelijk niet representatief zijn.De robot is telkens heel regelmatig na 101 metingen herstart zoals te zien is op de figuur.


Figuur 4.11: Dalende waarden bij de robot

De figuur 4.12 toont maar een geval van oplopende waarden, want het kan ook dat dewaarden rustig oplopen tot ze de bovengrens overschrijden, zoals in figuur 4.13. Het herstartenis opnieuw aangeduid met rode stippen. De waarden stijgen drie keer, maar de eerste tweekeer is er nog geen object in de buurt. Uit de figuur blijkt dat de robot dit op basis van desensorwaarden alleen niet kan achterhalen. Dit probleem is enkel op te vangen met behulp vaneen onafhankelijke sensor, zoals de Sonar Turret.

4.3.3 Bijkomende problemen

Robotdetectie vanuit verschillende richtingen

In paragraaf 4.3.1 werden dalende waarden op een algemene manier opgevangen. Voor stijgendewaarden klopt algoritme 4.5 echter enkel als de robots recht op elkaar af rijden. Het algoritmevolstond niet voor situaties waar de robots elkaar naderen vanuit willekeurige richtingen. Ditis te zien in figuur 4.14. Afhankelijk van de sensor (rood/groen) waarop het object wordtgedetecteerd, zal de richting waarin de Sonar Turret moet meten anders zijn. In het geval dateen object via de rode sensor gedetecteerd wordt, moet de Sonar Turret in de richting van derode sensor meten (links voor de robot), in het andere geval moet hij in de richting van de groenesensor (recht voor de robot) meten.

Het globale probleem is dat er eigenlijk zeer veel verschillende situaties mogelijk zijn en datelke situatie op een andere manier dient aangepakt te worden. Dit leidt tot een zeer onoverzich-telijk algoritme waarbij de kans groot is dat nog steeds situaties over het hoofd worden gezien.


Figuur 4.12: Te grote waarden bij het heropstarten van de robot

Uit experimenten is bovendien gebleken dat de Sonar Turret-metingen weer oplopen als ze tedicht (ongeveer 2 cm, wat niet zoveel verschilt van de maximum range van de IR-sensoren) bijde andere robot komen, zodat het moeilijk te achterhalen is of de robots net iets verder of netheel dicht bij elkaar staan.

Beınvloeding bij doelstelling 3

Ondanks de problemen die hierboven beschreven zijn, werd tijdens de simulaties, door hetaanbrengen van de verschillende veiligheidsmechanismen, zo’n 9 op 10 keer doelstelling 1 bereikt.Er werd dan overgegaan tot het testen van doelstellingen 2 en 3 met twee robots. Helaasbleek ook hier de beınvloeding tussen de IR-sensoren invloed te hebben op de werking van hetalgoritme. Het grote verschil met doelstelling 1 is het feit dat hier niet zo eenvoudig herstartkan worden. Dit is bijna onmogelijk, omdat de robot geen toestand kan bijhouden van voor zijnherstart en zo niet kan achterhalen waar hij zich bevond in zijn algoritme (doelstelling 1, 2, 3 of4). Het herstarten van de robot zou enkel een goede oplossing zijn als de robot in een keer in eengoed regime kon komen en daar ook in bleef. Dit is dus niet het geval, waardoor het herstarteneigenlijk geen zin heeft.

4.3.4 Bijkomende oplossingen

De nieuwe aanpak uit de voorgaande paragraaf heeft dus niet het gewenste resultaat opgeleverd.De oplossing die het meest eenvoudig is, komt van de Sonar Turret. Deze kunnen weliswaar


Figuur 4.13: Langzaam oplopende sensorwaarden

elkaar ook beınvloeden, maar de robots kunnen onder elkaar afspreken wie wanneer de SonarTurret mag gebruiken, zodat beınvloeding kan vermeden worden.

Bij de Khepera II robots kunnen de IR-sensoren niet afgezet worden, zodat deze optie nietmogelijk is. Eventueel zou in de toekomst een aparte IR-turret gebouwd kunnen worden, maaromwille van de bestaande Sonar Turret is dit eigenlijk overbodig.

Een andere oplossing zou zijn om IR-sensoren te gebruiken die elkaar niet beınvloeden,door een verschillende golflengte of codering te gebruiken. Ook dit is enkel mogelijk door deontwikkeling van een nieuwe (IR-)extensieturret.

4.4 Evaluatie

De hierboven aangehaalde oplossingen waren in het tijdsbestek van dit onderzoek niet meermogelijk. Bovendien maken de algoritmes uit hoofdstuk 5 enkel gebruik van de Sonar Turreten boekten we daar mooie resultaten mee. Er werd dan ook geopteerd om het spoor vanformatievorming met IR-sensoren te verlaten en de aandacht helemaal te richten op die metbehulp van Sonar Turrets. De IR-sensoren in de huidige configuratie zijn onbetrouwbaar, omdatze elkaar beınvloeden en met onbetrouwbare sensoren is formatievorming niet mogelijk.


Algoritme 4.5 Stijgende waarden opvangen1: Measure 100 sensor values with EMA2: reference value = last EMA value3: lower bound = (reference value− 40)4: if (lower bound < 20) then5: lower bound = 206: end if7: upper bound = (reference value + 40)

8: repeat9: current sensor value = read new IR value()

10: if (current sensor value < lower bound) then11: Value too small ⇒ Restart robot!12: end if13: if (current sensor value > 250 ) then14: Value too big ⇒ Restart robot!15: end if16: until (current sensor value > upper bound)

17: if (Distance measured with sonar > 3 cm) then18: Bogus detection ⇒ Restart robot!19: else20: Maximum reached ⇒ Stop robot! and proceed to objective 221: end if

Figuur 4.14: Bijkomende gevallen

Hoofdstuk 5

Formatievorming met de Sonar

Turret

Inhoudsopgave

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.2 Robots detecteren en formatie vormen . . . . . . . . . . . . . . . . . . 89

5.3 Formatie behouden met verschillend interactiegedrag . . . . . . . . . 94

5.4 Formatie behouden met verschillend autonoom gedrag . . . . . . . . . 99

5.1 Inleiding

In dit hoofdstuk bespreken we de algoritmes die ontwikkeld werden voor formatievorming metbehulp van de Sonar Turret. De C-code die deze algoritmes implementeert op de robot is tevinden op de bijgeleverde CD in de map ”Formation with Sonar Turret”

Aangezien deze algoritmes gebruik maken van de Sonar Turret, werken ze, om interferen-tieproblemen tussen ultrasone golven te vermijden, met een beurtensysteem waarbij tussen derobots onderling wordt afgesproken wie de volgende in de rij is die zijn Sonar Turret mag gebrui-ken. Op die manier vermijden we dat bijvoorbeeld de Sonar Turret van een robot een ultrasonepuls opvangt van een andere robot in plaats van een echo van zijn zelf verstuurde ultrasonepuls. Naast het feit dat de metingen van de Sonar Turret heel wat tijd in beslag nemen, heeftdit beurtensysteem mede tot gevolg dat de formatievorming niet meer in real-time (terwijl derobots rijden) kan gebeuren.

Dit beurtensysteem werd geımplementeerd door, telkens wanneer een robot klaar is met zijnafstandsmetingen, hem een bericht te laten versturen naar alle andere robots met de boodschapdat hij de sonar pas een volgende keer zal gebruiken als hij van alle andere robots zo’n zelfdeboodschap ontvangen heeft. Een algemeen schema van het beurtensysteem is te vinden onderAlgoritme 5.1 en onder Algoritme 5.2.

Er is dus een vaste volgorde bij de robots die om beurt de Sonar Turret gebruiken en dezevolgorde wordt doorheen het ganse algoritme behouden. Deze volgorde wordt helemaal in het

87

Hoofdstuk 5. Formatievorming met de Sonar Turret 88

Algoritme 5.1 Algemene werking van het beurtensysteem: algoritme-proces1: loop2: while !(otherRobotsReady) do3: wait4: end while5: otherRobotReady = (SIZE FORMATION − 1)6: otherRobotsReady = 07: ...8: Do 1 cycle of algorithm9: ...

10: for (1 ≤ i ≤ SIZE FORMATION) do11: if (i 6= ownID) then12: send message to robot[i] that robot[ownID] is ready13: end if14: end for15: end loop

Algoritme 5.2 Algemene werking van het beurtensysteem: luister-proces1: loop2: wait for incoming message msg from Radio Turret3: if (msg == READY-message) then4: otherRobotReady −−5: if (otherRobotReady == 0) then6: otherRobotsReady = 17: end if8: else9: ...



begin, bij het opstarten van de robots, afgesproken tussen de robots onderling. Ze doen dit doorelk afzonderlijk een willekeurig getal te genereren (m.b.v de C-functies rand() en srand(seed))en dit naar de andere robots door te sturen. Wie het grootste getal genereerde wordt de eerstein rij, diegene met het tweede grootste getal wordt de tweede in rij enz.

In de volgende paragrafen zullen we eerst een algoritme bespreken waarbij de robots vanuiteen willekeurige positie elkaar opzoeken om tot een driehoeksformatie te komen. Daarna be-spreken we twee verschillende algoritmes om de robots in een bepaalde richting te laten rijden,met behoud van deze formatie.

5.2 Robots detecteren en formatie vormen

In deze paragraaf bespreken we een algoritme dat ontwikkeld werd om de Khepera II -robotsvanuit een willekeurige startpositie elkaar te laten vinden, naar mekaar toe te laten rijden eneen driehoeksformatie te laten vormen. We zullen trachten een gelijkzijdige driehoek te vormenwaarbij de afstand tussen de middelpunten van elk paar robots ongeveer 30 cm bedraagt. Hierbijwordt enkel gebruik gemaakt van de Sonar Turret die we bespraken in hoofdstuk 3. We zulleneerst het algemene schema en de theoretische werking bespreken. Vervolgens bespreken we depraktische implementatie van het algoritme en de problemen die hierbij opdoken.


Zoals reeds besproken in de inleiding van dit hoofdstuk, kunnen de robots slechts om beurt hunsonar gebruiken om geen last te hebben van interferentie tussen de verschillende sonarmodules.Het algoritme is dan ook op die manier opgebouwd.We gaan ervan uit dat er een robot blijft staan op zijn initiele positie. Dit is geen striktevoorwaarde; men kan er voor kiezen om ook die ene robot eerst naar een bepaalde positie telaten rijden en vervolgens het algoritme te laten starten. Dit heeft echter geen invloed op hetalgoritme dat volgt.

Het algoritme begint bij deze ene robot (die we vanaf nu robot 1 noemen). De beslissingover welke robot deze taak krijgt, wordt onder de robots zelf genomen op dezelfde basis van hetwillekeurig getal dat ook vermeld werd in de inleiding van dit hoofdstuk.

Van zodra vaststaat wie robot 1 wordt, laat robot 1 aan robot 2 weten dat hij mag startenmet het zoeken van robot 1. Robot 1 wordt dan voor de rest van dit algoritme een soort vanslaaf en voert enkel opdrachten uit die hij ontvangt door communicatie met de andere twee.Robot 2 begint robot 1 te zoeken en doet dit door eerst robot 1 sonarmetingen te laten uitvoe-ren om de tien graden en dit over in totaal een hoek van 360 graden. Robot 1 beschikt danuiteindelijk over 36 opgemeten afstanden die hij doorstuurt naar robot 2.Robot 2 begint dan met dezelfde handeling en meet ook 36 afstanden over 360 graden. Aange-zien robot 2 ook over de opgemeten afstanden van robot 1 beschikt, kan hij deze vergelijken metzijn eigen opgemeten afstanden en kan hieruit proberen een conclusie te trekken over de richtingwaarin robot 1 zich bevindt. Wanneer er een opgemeten afstand blijkt te zijn die nagenoegidentiek is op beide robots, besluit robot 2 hieruit dat robot 1 in de richting te vinden is waarin


hij deze meting deed en begint hij in die richting te rijden totdat hij op een voldoende dichteafstand (ongeveer 30 cm) genaderd is van robot 1. Vervolgens laat hij aan robot 3 weten datdeze mag beginnen met robot 1 te zoeken.

Ook robot 3 zal 36 afstanden meten en vergelijken met de ontvangen data van robot 1. Ookhij probeert de richting te vinden waarin robot 1 zich bevindt en nadert in die richting robot 1.Wanneer hij robot 1 voldoende genaderd is, probeert hij zich echter ook ten opzichte van robot2 op een correcte manier te positioneren zodat de vooropgestelde formatie bereikt wordt.

5.2.2 Praktische implementatie

Een eerste stap in de praktische implementatie was het nagenoeg letterlijk omzetten van hettheoretische algoritme naar code voor de Khepera II.

Marge voor identieke afstanden

Uit de eerste tests bleek al onmiddellijk dat opgemeten afstanden door verschillende robots nooitvolledig identiek zijn. Dit kan eenvoudig verklaard worden door de beperkte resolutie die wenemen om afstanden op te meten. We meten namelijk slechts om de 10 graden, dus de kans isklein dat twee robots elkaar op dezelfde manier zullen zien. We dienen dan ook een marge in tebouwen om twee afstanden als identiek te beschouwen.

Valse detectie identieke afstanden

Het gebruik van zo’n marge vergroot echter de kans op een valse detectie van identieke afstanden.Een object (geen robot) dat op bijna dezelfde afstand staat als de te detecteren robot, heeft ookeen kans om herkend te worden als een robot. Deze situatie is niet te vermijden.We bedachten hiervoor de volgende oplossing1. Stel dat robot 2 probeert om robot 1 te detecterenen hiervoor verschillende identieke afstanden gevonden heeft. Met identieke afstanden bedoelenwe hier afstanden gemeten op verschillende robots die (ongeveer) dezelfde waarde hebben. Wezullen er dan niet onmiddellijk van uitgaan dat de eerst gevonden afstand de correcte is, maarvoor elk van de gevonden identieke afstanden een controle uitvoeren op valse detectie. Dezecontrole gebeurt door robot 2 in de gevonden richting te laten rijden over een welbepaalde afstanden de meting opnieuw te laten uitvoeren door robot 2 en robot 1. Robot 1 zal zich hierbij danook draaien in de richting waarin hij robot 2 verwacht. Deze richting zal beslist worden doorrobot 2 (uit de 36 waarden van elk van beide robots) en robot 2 zal die richting ook terugsturennaar robot 1. Robot 1 stuurt zijn opgemeten afstand dan opnieuw door naar robot 2 en diezal daaruit dan beslissen of de richting die hij gekozen had correct was. Indien de richting nietcorrect was, zal robot 2 terugkeren naar zijn initiele positie en een volgende gevonden richtinguitproberen op dezelfde manier. Dit proces herhaalt zich tot de doorgestuurde afstandsmetingvan robot 1 overeenkomt met de afstandsmeting van robot 2.

1We gebruiken hier en ook in de volgende paragrafen steeds robot 2 om het probleem uit te leggen, maar ookop robot 3 zullen dezelfde problemen opduiken en zullen we dezelfde oplossingen gebruiken.


Onnauwkeurige positiebepaling

Een probleem dat reeds beschreven werd in referentie [6, sectie 5.2] is de onnauwkeurige positie-bepaling waarover de Khepera II beschikt. In het algoritme dat we hierboven beschreven, geeftdit problemen bij het draaien over een bepaald aantal graden en bij het vooruit of achteruitrijden over een bepaalde afstand. Deze bewegingen worden geprogrammeerd met behulp van deingebouwde functie mot_new_position_2m(posLeftWheel, posRightWheel). Die laat toe omde wielen van de Khepera II een welbepaalde rotatie te laten uitvoeren. Dit zorgt in principevoor een afstand die de robot zal afleggen of, indien we voor het linker- en rechterwiel een tegen-gesteld argument meegeven, een rotatie van de robot. We kunnen echter geen rekening houdenmet het doorslippen van de wielen en dus leidt deze functie niet steeds tot het gewenste gedrag.De oplossing die we hiervoor bedachten is dat we bij het controleren van een identieke afstand,niet enkel een meting uitvoeren in de richting die we controleren, maar ook telkens 5 en 10graden links en rechts daarvan. Dit doen we zowel bij robot 1 als robot 2, zodat we uiteindelijkover tien gemeten afstanden (vijf van robot 1 en vijf van robot 2) beschikken op robot 2 die wemoeten vergelijken en op basis waarvan we beslissen of de gecontroleerde richting correct is.

Derde meting

Na de aanpassingen die we besproken hebben in de vorige paragrafen, vonden de robots elkaarreeds af en toe. Toch werden er nog enkele situaties gevonden waarin robot 2 een obstakel ver-keerd detecteerde als zijnde robot 1. Om dit te vermijden werd nog een derde meting toegevoegdwaarbij robot 2 opnieuw een bepaalde afstand verder rijdt in de richting waarin hij denkt datrobot 1 zich bevindt. Opnieuw wordt er een afstandsmeting uitgevoerd door robot 1 en 2 enstuurt robot 1 zijn afstandsmeting door naar robot 2. Robot 2 controleert dan een derde keerof deze twee afstanden identiek zijn (binnen een bepaalde marge) en enkel indien deze identiekzijn, concludeert hij dat de correcte richting gevonden is.

Ontwijkgedrag door robot 2

Waneer beide robots (2 en 3) de richting gevonden hebben waarin ze robot 1 zien, zullen zein die richting rijden tot ze robot 1 tot op een voldoende korte afstand genaderd zijn. Daarnastellen ze zich in de correcte driehoeksformatie op ten opzichte van robot 1. Wanneer we stellendat robot 1 de top vormt van de driehoeksformatie, zal robot 2 de hoek linksonder vormen enrobot 3 de hoek rechtsonder.Stel dat het verschil tussen de richting waarin robot 2 robot 1 nadert en de richting waarin robot3 robot 1 nadert te klein is, dan kan er eventueel een probleem ontstaan wanneer robot 2 enrobot 3 zich tegelijk verplaatsen naar hun uiteindelijke positie in de formatie. Daarom is er eenextra veiligheid ingebouwd in het algoritme om dit eventuele probleem op te vangen.

Eerst en vooral zullen robot 2 en robot 3 niet tegelijk robot 1 naderen, maar zullen ze ditom beurt doen en zal robot 2 hiermee eerst starten. Voor hij hieraan begint, zal hij aan robot 1vragen wat de richtingen zijn waarin hij robot 2 en robot 3 gevonden heeft. Uit deze gegevenszal robot 2 dan een beslissing nemen over het al dan niet inbouwen van een ontwijkgedrag voor


Figuur 5.1: Ontwijkgedrag door robot 2

robot 3. Als de hoek tussen robot 2 en robot 3 te klein is, zal robot 2, wanneer hij in de richtingvan robot 1 rijdt, een kwartcirkel rond robot 1 rijden (figuur 5.1) om op die manier de hoektussen hem en robot 3 te vergroten, zodat er geen probleem meer kan ontstaan als robot 3 robot1 wil naderen. De richting (wijzerzin of tegenwijzerzin) waarin de kwartcirkel afgelegd wordt,zal robot 2 afleiden uit de gegevens die hij ontving van robot 1.

Finale formatievorming

Robot 2 staat nu op een gekende afstand (ongeveer 25 cm) van robot 1. Robot 3 zal nu ook totop die afstand rijden van robot 1 en zal dan trachten robot 2 te vinden door in een cirkel rondrobot 1 te rijden tot hij robot 2 op zijn weg vind. De cirkelstraal is aangepast aan de gekendeafstand (25 cm) tussen robot 1 en 2. Als robot 3 robot 2 gevonden heeft, zet hij zich op de goedepostie zodat hij rechtsonder staat in de driehoek en als laatste de formatievorming voltooid.

Deze laatste stap in de formatievorming is te zien in figuur 5.2.

5.2.3 Resultaten

De rechtstreekse implementatie van het theoretische algoritme gaf helemaal niet het gewensteresultaat. Obstakels werden verkeerdelijk als robot gedetecteerd en de robots bevonden zich ophet einde helemaal niet in de correcte formatie. De aanpassingen die we besproken hebben in


Figuur 5.2: Laatste stap in de formatievorming

paragraaf 5.2.2 werden dan ook aangebracht en uiteindelijk werd de gewenste formatievormingbekomen.

Er zijn echter wel enkele voorwaarden verbonden aan de initiele positie van elk van derobots opdat ze met behulp van het hierboven beschreven algoritme elkaar zouden vinden enin de correcte formatie zouden komen. Ten eerste moet elk van de robots elkaar kunnen ‘zien’(m.a.w er is nood aan een Line of Sight). Dit houdt niet alleen in dat er zich geen obstakelstussen de robots mogen bevinden, maar ook dat er zich geen robot tussen de andere twee magbevinden2 (initiele lijnformatie).Een tweede voorwaarde voor de initiele positie van de robots is dat ze zich op voldoende afstandvan elkaar moeten bevinden. Tijdens de tweede en derde controle van de gevonden identiekeafstanden, rijdt robot 2/3 namelijk in de richting van robot 1 en hij controleert hierbij niet ofde ruimte voor de afstand die hij hiervoor moet afleggen wel beschikbaar is. Stel dat de robotszich te dicht in elkaars buurt bevonden bij de start van het algoritme, dan kan het gebeuren datrobot 2/3 deze afstand niet kan afleggen en het dus tot een botsing zou komen tussen robot 2/3en robot 1. Hiervoor zou een veiligheidsmechanisme (zoals we er bijvoorbeeld een zullen zien inparagraaf 5.4.2) ingebouwd kunnen worden.

De voorwaarden voor de initiele positie kunnen gerust vermeden worden met bijkomendeveiligheidsmechanismen. Zo zouden de robots helemaal in het begin elk om beurt kunnen rijden

2Robot 1 mag zich wel tussen robot 2 en robot 3 bevinden, omdat robot 2 en robot 3 beiden onafhankelijkrobot 1 zullen zoeken, maar wanneer bijvoorbeeld robot 2 zich tussen robot 1 en robot 3 bevindt, zal robot 3robot 1 niet meer kunnen vinden via afstandsmetingen.


Figuur 5.3: (links) Positie voor het uitvoeren van het formatievormingsalgoritme (rechts) Positie na hetuitvoeren van het formatievormingsalgoritme

naar een plaats waar ze voldoende ruimte rond zich hebben om het algoritme uit te voeren. Detweede voorwaarde zou dan geen probleem meer mogen vormen. Als de robots op een lijn staan,kunnen ze dit detecteren als robot 1 maar een robot kan vinden. In dat geval kan de robotdie niet gevonden werd, verder rijden tot hij uit de lijnformatie is. Ook andere oplossingen zijnmogelijk omdat geen enkele van de aangehaalde problemen van fundamentele aard is. Ze werdenniet opgelost in ons onderzoek omdat we beperkt waren in tijd en het volgende probleem wildenaanpakken, namelijk de robots in formatie houden.

Rekening houdend met de huidige beginvoorwaarden, hebben we verschillende geslaagde ex-perimenten uitgevoerd. Een voorbeeld hiervan zien we in figuur 5.3. Links zien we de startpositievan de drie robots en rechts hun positie na de uitvoering van het algoritme. We zien dat decorrecte formatie gevormd werd.

5.3 Formatie behouden met verschillend interactiegedrag

Eens de robots elkaar gevonden hebben en een driehoeksformatie gevormd hebben, willen weze natuurlijk een volgend doel geven, bijvoorbeeld een richting uit rijden waarbij deze formatiebehouden blijft. Twee algoritmes die we hiervoor ontwikkeld hebben, bespreken we in deze en


de volgende paragraaf. Deze algoritmes bestaan telkens uit twee delen. Een deel zorgt voor hethet interactiegedrag (de robots blijven in formatie). Het tweede zorgt voor het autonoom gedrag,zodat de robot nog een ander doel heeft, naast het behouden van de formatie.


In dit eerste algoritme starten de robots in een gelijkzijdige driehoek en zijn ze initieel allemaalin dezelfde richting georienteerd3 (zie figuur 5.3 rechts). Het algoritme is gebaseerd op eenzeer eenvoudig principe: elke robot controleert de afstanden tot de andere robots; de robotdifferentieert drie verschillende situaties waarbij hij telkens een ander gedrag zal vertonen:

• (Interactiegedrag) Is de afstand tot een andere robot te groot, dan zal de robot in derichting van deze te ver verwijderde robot rijden.

• (Interactiegedrag) Is de afstand tot een andere robot te klein, dan zal hij in de tegen-overgestelde richting rijden.

• (Autonoom gedrag) Zijn alle afstanden tot de andere robots binnen een bepaalde marge,dan zal de robot in een voorgeprogrammeerde richting4 rijden.

We zien dus dat het autonoom gedrag dus voor iedere robot hetzelfde is, maar slechts uitgevoerdwordt als de robot zich, binnen een bepaalde marge, in de formatie bevindt. Het interactiegedragwordt uitgevoerd wanneer de robot te ver verwijderd is van zijn positie in de formatie. Omdatde robots allemaal dezelfde orientatie hebben, dient dit interactiegedrag wel voor iedere robotop een andere manier geprogrammeerd te worden. De robot linksonder zal bijvoorbeeld rechtsvan hem en rechtsboven van hem moeten meten om de afstanden te weten tot de andere tweerobots, terwijl de andere twee robots in die richtingen geen robots detecteren.


Onnauwkeurige positiebepaling

Wanneer een robot de afstanden wil meten tot de andere twee, zal hij die metingen uitvoeren inde richting waarin hij de andere twee verwacht te staan. Dit is natuurlijk een open-loop situatieen door de onnauwkeurige positiebepaling, zou dit, zonder extra veiligheden in te bouwen, sneltot problemen kunnen leiden. Daarom hebben we voor de onderste twee robots in de formatieeen veiligheidsmechanisme ingebouwd waarbij ze, voor het meten van de afstand tot de andere,zich eerst correct positioneren ten opzichte van de andere. Dit doen ze door drie opeenvolgendemetingen te doen: een in de richting waarin ze denken dat de andere robot staat, een vijfgraden links daarvan en een laatste vijf graden rechts daarvan. De robot positioneert zich danin die richting waarin hij de minimale afstand opmat. Hierdoor zullen de onderste twee robotszich beter ten opzichte van elkaar positioneren. Ook voor de bovenste robot in de formatie

3Dit is niet geheel waar, omdat in de praktijk de bovenste robot in de driehoek omgekeerd georienteerd starten ‘vooruit rijden’ voor hem dus eigenlijk ‘achteruit rijden’ betekent. Dit is echter enkel zo omdat de robot danniet voortdurend 180 graden moet draaien om de andere twee robots te zien.

4Deze richting is in dit geval voor iedere robot dezelfde en voor de eenvoud wordt recht vooruit gekozen.


kan zo’n gedrag geımplementeerd worden, maar dit werd niet gedaan om de uitvoeringstijd vanhet algoritme niet nog meer te vergroten5; we rekenen erop dat deze robot zich correct zalpositioneren door zijn interactiegedrag.

Gelijktijdige beweging

Zoals we reeds vermeld hebben in de inleiding (paragraaf 5.1) van dit hoofdstuk, werken we steedsmet een beurtensysteem waarbij de robots elk om beurt een cyclus van het algoritme uitvoeren endaarna wachten tot de andere twee robots ook een cyclus van het algoritme uitgevoerd hebben.Stel dat een cyclus zou bestaan uit het opmeten van de verschillende afstanden (tot de andererobots), een beslissing nemen over welke beweging gemaakt zal worden en het uitvoeren van dezebeweging. Stel nu dat alledrie de robots voor hun cyclus correct in formatie staan. De robotszullen dan alledrie beslissen om hun autonoom gedrag uit te voeren, wat correct is. Er kan echtereen probleem ontstaan. Wanneer bijvoorbeeld de bovenste en de rechtse robot in de formatiehun beweging reeds uitgevoerd hebben en de linkse robot begint aan zijn metingen, zal hij derechtse robot niet meer vlak naast zich opmeten, maar rechts voor zich. Dit komt natuurlijkdoordat de rechtse robot zijn cyclus al doorlopen heeft en de beweging reeds uitgevoerd heeft.De linkse robot zal daaruit echter besluiten dat zijn initiele orientatie niet correct was en zalzich herorienteren ten opzichte van de rechtse robot (cfr. paragraaf 5.3.2: onnauwkeurige

positiebepaling). Dit is niet de correcte beslissing omdat hij hoogstwaarschijnlijk wel correctgeorienteerd stond, maar het is een gevolg van het feit dat de rechtse robot reeds een cyclusmeer uitgevoerd had.

De manier waarop dit probleem opgelost wordt, is het scheiden van enerzijds de metingenzelf en de beslissing over de beweging die genomen moet worden op basis van die metingen enanderzijds het bewegen van de robot. De metingen en het beslissen worden elk om beurt gedaanvolgens het bovenvermelde beurtensysteem, maar de robots zullen de eigenlijke beweging pasuitvoeren op het moment dat ze weten dat iedere robot zijn beweging uitvoert. Hiervoor wordtopnieuw gebruik gemaakt van het willekeurig getal waarmee de volgorde in het beurtensysteemin het begin bepaald werd (paragraaf 5.1). Door het ontvangen van boodschappen van andererobots waarin staat dat die robots klaar zijn met zijn cyclus van het algoritme, kan een (ontvan-gende) robot bepalen wanneer het weer de beurt is aan de eerste6 robot in het beurtensysteem.Op dat moment zullen alle robots hun beweging uitvoeren.

Formatie herstellen

Na tien cycli van autonoom gedrag en interactiegedrag voor elke robot, volstond het interactie-gedrag niet meer om de formatie te behouden. Daarom besloten we dat om de drie cycli eenextra algoritme moet worden uitgevoerd dat ervoor zorgt dat de formatie hersteld wordt.In dit algoritme blijft een van de robots staan, terwijl de andere twee zich na elkaar zullenherpositioneren ten opzichte van de robot die blijft staan. De praktische implementatie vandit herpositioneren gebeurt als volgt. Eerst controleert de robot of de robot waarmee hij zich

5Iedere extra sonarmeting zorgt namelijk voor aanzienlijke vertraging.6De robot die initieel, bij het opstarten van de robots, de eerste beurt kreeg.


zal herorienteren zich in de richting bevindt waarin hij die verwacht. Dit doet hij door met deSonar Turret te scannen over een hoek van 50 graden, met de richting waarin hij de andere robotverwacht als bissectrice van deze hoek. Hij positioneert zich dan in de richting waarin hij eenminimale afstand opgemeten heeft.

Daarna laten we de robot in die richting rijden tot hij op een welbepaalde afstand (ongeveer5 cm) van de andere robot staat (dit is mogelijk door uit te gaan van de afstandsmeting diegedaan werd in die richting). Vervolgens laten we de robot scannen met de Sonar Turret omde twee uiterste punten van de andere robot te zoeken7. De robot orienteert zich dan in derichting van de bissectrice van de hoek tussen deze twee uiterste punten en besluit hieruit dathij correct geherorienteerd is ten opzichte van de andere robot. Vervolgens zal de robot in dierichting achteruit rijden tot hij op de goede afstand (30 cm) staat van de stilstaande robot.

Dit volstaat voor de eerste robot die aan de beurt is, maar voor herpositionering van detweede robot is een complexer algoritme nodig. De hoek tussen de twee richtingen waarin destilstaande robot de andere ziet moet 60 graden zijn, opdat de formatie een gelijkzijdige driehoekzou vormen.Om de richtingen te achterhalen waarin de andere twee zich bevinden, zal de stilstaande robotde twee andere scannen om de bissectrice tussen hun uiterste twee punten te vinden. Als dehoek tussen die twee richtingen niet 60 graden is, geeft de stilstaande robot de opdracht aan detweede robot om zich te verplaatsen, zodat de hoek wel 60 graden wordt. Het verplaatsen vande tweede robot gebeurt in een cirkelboog rond de stilstaande robot (figuur 5.4). Pas dan magde tweede robot achteruit rijden over de goede afstand (30 cm).

Als de beide robots zich geherpositioneerd hebben, kan het normale algoritme met interactie-en autonoom gedrag weer verder uitgevoerd worden.

Ontwijken van obstakels

In het experiment reed de driehoeksformatie vooruit met een robot (robot 1) op kop. Deze robotkan de omgeving voor zich scannen met de Sonar Turret en op die manier obstakels detecteren.Als hij bijvoorbeeld een obstakel rechts detecteert, kan robot 1 beslissen om de ganse formatienaar links te laten draaien, zodat de formatie het obstakel ontwijkt.Het algoritme is zo opgebouwd dat de formatie zes richtingen uitkan, afhankelijk van de richtingwaarin het obstakel gedetecteerd werd:

• 90 graden naar links

• 45 graden naar links

• Rechtdoor (geen ontwijkgedrag)

• 45 graden naar rechts

• 90 graden naar rechts7Door telkens om de vijf graden een meting te doen en het verschil te controleren met de vorige meting,

kan bepaald worden wanneer het uiteinde van de andere robot bereikt is, namelijk op het moment dat er eenaanzienlijk verschil is tussen twee opeenvolgende metingen.


Figuur 5.4: Herpositionering van de tweede robot ten opzichte van de eerste (stilstaande) robot, zodatde gelijkzijdige driehoeksformatie hersteld wordt.

• Achteruit

Bij het draaien over 90 graden komt er een andere robot op kop (robot 3 in plaats van robot 2in figuur 5.5), zodat die robot op dat moment de omgeving opmeet en de beslissingen neemt overhet ontwijken van obstakels. Het is duidelijk dat de robot op kop een speciale positie inneemt inde formatie. Eigenlijk is hij de leider van de formatie en hoewel de rol kan doorgegeven worden,blijft er altijd een robot de leider.

5.3.3 Resultaten

Met het bestaande algoritme kan de driehoeksformatie behouden worden, maar is er wel altijdeen robot de leider. Het doel van ons onderzoek was eigenlijk om een formatie te creeren waarinde robots gelijkwaardig zijn, wat op de hierboven beschreven manier dus niet mogelijk is.Op het moment dat het ontwijken van obstakels voor de formatie zou worden getest, kwam onzepromotor met het idee om het interactiegedrag voor de robots gelijk te maken, zodat de robotswel gelijkwaardig zijn in de formatie. Dit was een zeer interessante oplossing en de focus van hetonderzoek werd dan ook meteen verlegd. We zullen dit beschrijven in de volgende paragrafen.


Figuur 5.5: Draaien van de formatie over 90 graden (de robots in lichtere kleur geven de situatie weervan voor het draaien)

5.4 Formatie behouden met verschillend autonoom gedrag


In dit tweede algoritme starten de robots opnieuw in een gelijkzijdige driehoek, maar nu hebbenze elk een verschillende orientatie. We zorgen ervoor dat elke robot naar een andere robot kijkt.Robot 1 kijkt naar (is met zijn hoofdrichting georienteerd in de richting van) robot 2, robot 2naar robot 3 en robot 3 opnieuw naar robot 1. Het interactiegedrag bestaat er dan in dat elkerobot bij elke cyclus van het algoritme zich herorienteert ten opzichte van de robot waar hijinitieel naar keek.Het autonoom gedrag is in dit algoritme voor iedere robot anders. Bij iedere robot wordt een(al dan niet verschillende) richting voorgeprogrammeerd. Dit is de richting waarin de robot elkecyclus van het algoritme over een bepaalde afstand zal rijden. Als we deze initiele, autonomerichtingen goed kiezen voor de drie robots, dan kunnen we ervoor zorgen dat de volledige formatiein dezelfde richting zal bewegen. Dit is echter geen noodzakelijke voorwaarde en we kunnen ooktotaal willekeurige richtingen geven aan de drie robots.

Aangezien in dit algoritme de autonome richting van elke robot eenvoudig kan worden aange-past, leek het ons zinvol om op die manier ook obstakelontwijking in te bouwen in het algoritme.Elke robot zal op het einde van elke cyclus kijken in zijn autonome richting of er nog voldoenderuimte aanwezig is om ook de volgende keer in die richting verder te kunnen rijden. Is dit niethet geval, dan zal de robot zijn autonome richting aanpassen zodat het obstakel kan wordenontweken.


Figuur 5.6: Uitvoering van het algoritme ”formatie behouden met verschillend autonoom gedrag” waar-bij alle robots elke om beurt een volledige cyclus uitvoeren. De rode pijlen geven het au-tonoom gedrag aan, de blauwe het interactiegedrag en de zwarte de ‘kijkrichting’ van elkerobot.


Ook in dit algoritme zullen we gebruik maken van het gelijktijdig bewegen-principe. Hierbijzullen we ervoor zorgen dat de robots hun autonoom gedrag telkens gelijktijdig uitvoeren, terwijlhet interactiegedrag en de obstakeldetectie nog steeds door elke robot om beurt zal gebeuren. Dereden waarom we dit doen is omdat de driehoeksformatie anders moeilijker te behouden is. Ditwordt onmiddellijk duidelijk uit figuren 5.6 en 5.7. Op de eerste figuur wordt de volledige cyclus(interactiegedrag, obstakeldetectie en autonoom gedrag) om beurt uitgevoerd door elke robot.We zien dat de vooropgestelde gelijkzijdige driehoeksformatie volledig verloren gaat tijdens deuitvoering van het algoritme. Dit komt omdat elke robot een cyclus achter loopt op de robotdie voor hem aan de beurt was en die door zijn autonoom gedrag zich alweer verwijderd heeftuit de formatie.In figuur 5.7 daarentegen zien we een heel andere situatie. Hierbij zullen alle robots tegelijk hunautonoom gedrag uitvoeren. Dit heeft tot gevolg dat, onder de voorwaarde dat hun autonoomgedrag in dezelfde richting gebeurt, hun interactiegedrag bijna niet zal moeten compenserenvoor het uit formatie geraken door het autonoom gedrag. We zien dan ook dat de gelijkzijdigedriehoeksformatie veel strakker behouden blijft.

Herorientatie

Bij de herorientatie controleert de robot of de robot waarmee hij zich zal herorienteren zich inde richting bevindt waarin hij deze verwacht8. Dit doet hij door met de Sonar Turret te scannenover een hoek van 50 graden, met de richting waarin hij de andere robot verwacht als bissectrice

8De andere robot kan zich in een licht verschillende richting bevinden door het uitvoeren van zijn autonoomgedrag in de vorige cyclus of door het probleem van het doorslippen van de wielen zodat de positiebepalingonnauwkeurig was.


Figuur 5.7: Uitvoering van het algoritme ”formatie behouden met verschillend autonoom gedrag” waar-bij alle robots tegelijk hun autonoom gedrag uitvoeren. De rode pijlen geven het autonoomgedrag aan.

van deze hoek. De richting van de kortste afstandsmeting vormt dan de nieuwe richting waarinde robot zich herorienteert.Na de herorientatie controleert de robot of ook de afstand tot de andere robot nog steeds binneneen bepaalde marge is. Is dit niet het geval, dan rijdt de robot in de richting van de andere robotof indien nodig, in de tegenovergestelde richting, naargelang de afstand die opgemeten werd.

Een probleem dat opdook tijdens de experimenten, is dat wanneer de robot eventueel ach-teruit moet rijden, dit niet altijd mogelijk is. Soms staat de robot in de buurt van een obstakelen kan hij niet over de volledige afstand achteruitrijden. Om dit op te vangen, pasten we hetalgoritme als volgt aan. Op het moment dat de robot achteruit wil rijden, zal hij zich nu eerstomdraaien en een afstandsmeting doen in de richting waarin hij wil rijden. Hieruit zal hij dankunnen besluiten of dit mogelijk is of niet. Blijkt dat niet mogelijk, dan zal de robot enkel rijdenover de afstand die hij ter beschikking heeft.

Herorientatie ten opzichte van twee robots

In het oorspronkelijke ontwerp van het algoritme was het de bedoeling dat elke robot zich zouherorienteren (interactiegedrag) ten opzichte van de robot voor zich9. Uit de simulaties bleekechter dat dit niet voldoende was om de correcte formatie te behouden, zeker als de autonomerichtingen van de verschillende robots niet op elkaar afgestemd waren. De driehoeksformatiewordt dan teveel uit elkaar getrokken, zodat het geımplementeerde interactiegedrag niet volstondom de formatie te corrigeren. We hebben dan het algoritme aangepast opdat elke robot zich nietalleen ten opzichte van de robot voor zich zou herorienteren, maar ook ten opzichte van de andererobot in de driehoeksformatie. Dit leidde tot veel betere resultaten, waarbij de driehoeksformatieperfect behouden bleef in elke omstandigheid.

9Zoals reeds vermeld in paragraaf 5.4.1 start elke robot georienteerd naar een andere robot in de formatie.


Vermijden van deadlock

Het obstakelontwijkgedrag houdt in dat we, telkens we een obstakel detecteren in de autonomerichting waarin we willen rijden, de autonome richting zullen aanpassen door er 90 graden bijop te tellen.

Tijdens enkele experimenten is echter gebleken dat de formatie in een hoek kan terechtkomen waarbij de robot die zich het verst in de hoek bevindt geen enkele richting kan detecterenwaarin hij voldoende ruimte voor handen heeft om zijn autonoom gedrag uit te voeren. In elkerichting waarin hij zich draait, ziet hij ofwel een muur ofwel een andere robot uit de formatie.Zonder enig veiligheidsmechanisme dat hiervoor een uitweg zoekt, zal de robot eindeloos telkens90 graden draaien, een meting doen in die richting en concluderen dat hij opnieuw 90 gradenmoet draaien, omdat er onvoldoende ruimte is. De oplossing om deze zogenaamde deadlockte vermijden is controleren of we, tijdens het aanpassen van de autonome richting, niet al 360graden gedraaid zijn. Indien we inderdaad al 360 graden gedraaid zijn, dan zullen we deze cyclusvan het algoritme voor deze robot beeindigen zonder het autonoom gedrag uit te voeren. Dekans is groot dat de andere robots uit de formatie wel een richting zullen vinden waarbij ze uitde hoek geraken en de robot die vastzat op die manier (wanneer de andere robots voldoende vande hoek verwijderd zijn) ook uit de hoek kan geraken.

Aanpassen van autonome richting bij herorientatie

Door herorientatie van een robot, veranderen we eigenlijk ook zijn autonome richting, gezienvanuit een assenstelsel dat onafhankelijk is van de orientatie van deze robot. De autonomerichting van een robot is namelijk relatief gedefinieerd ten opzichte van de orientatie van dezerobot en wanneer deze robot zichzelf herorienteert, verandert de autonome richting relatief tenopzichte van deze robot niet, maar de richting ten opzichte van het absolute assenstelsel wel. Omde autonome richting in het onafhankelijke assenstelsel toch min of meer constant te houden,moeten we dus telkens wanneer de robot zich herorienteert, deze autonome richting aanpassen.

5.4.3 Resultaten

Ook bij dit algoritme zijn enkele voorwaarden verbonden aan de omgeving opdat het algoritmecorrect zou verlopen. Zo mag de omgeving niet toelaten dat een robot achter een hoek verdwijnt(na uitvoering van zijn autonoom gedrag bijvoorbeeld) zodat de andere robots hem kwijtraken.Een voorbeeld hiervan is te zien in figuur 5.8. Robot 1 zal zijn autonoom gedrag uitvoeren inde richting van de pijl en zal op die manier robot 2 kwijtgeraken.


Figuur 5.8: Omgeving waarbij robots elkaar kunnen kwijtgeraken

Hoofdstuk 6

Conclusies en perspectieven

Inhoudsopgave

6.1 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.2 Perspectieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.1 Conclusies

Het uiteindelijke doel van dit onderzoek was algoritmes te implementeren op de Khepera II -robots die ervoor zorgen dat de robots in een welbepaalde formatie kunnen komen en ook blijven,terwijl ze zich voortbewegen in een onbekende omgeving. Om dit doel te bereiken dienden echtereerst enkele belangrijke randproblemen opgelost te worden.

6.1.1 Communicatie

Een van die randproblemen was de ontwikkeling van betrouwbare communicatie tussen de ro-bots. De Khepera II kan communiceren via twee verschillende extensieturrets.In hoofdstuk 2 hebben we eerst communicatie via de High Speed Radio Turret besproken. Dezeturret laat enkel communicatie1 toe tussen een robot en een PC en dus dienden we een volledigecontrole-eenheid op de PC te implementeren die de boodschappen van elke robot doorstuurtnaar de andere robots waarmee de PC in verbinding staat (broadcast-mechanisme). Op de PCwerd hiervoor met de programmeertaal Java gewerkt die toelaat om verschillende threads naastelkaar te laten werken wat nodig is om tegelijk berichten te kunnen ontvangen van verschil-lende robots. Verder werd ook een controlemechanisme ingebouwd dat ervoor zorgt dat alleberichten van robot naar PC en omgekeerd beantwoord worden met een acknowledgement zodatbetrouwbare communicatie kan gewaarborgd worden. Dit volledige communicatieprotocol datontwikkeld werd in het kader van deze scriptie bevat echter heel wat parameters die ingevuldmoesten worden. De perfecte parametercombinatie werd pas op het einde van dit onderzoekgevonden zodat voor het formatievormingsgedeelte van dit onderzoek niet met deze High Speed

1via een draadloze Bluetooth-verbinding

104

Hoofdstuk 6. Conclusies en perspectieven 105

Radio Turret werd gewerkt om de communicatie te verzorgen tussen de robots.In paragraaf 2.2 werd de communicatie met behulp van de Radio Turret besproken. Die laatrechtstreekse communicatie toe tussen robots, zonder dat de boodschappen langs een PC ommoeten. Aangezien hier geen controle-eenheid moest ontworpen worden om boodschappen doorte geven tussen de robots, was de implementatie een stuk eenvoudiger. Hoewel de Radio Turretstandaard al beschikt over een mechanisme om verloren boodschappen te detecteren en desgeval-lend een retransmissie van het bericht te doen, werd ook hier nog een extra controlemechanismeingebouwd waarbij, net zoals bij de High Speed Radio Turret (paragraaf 2.1), iedere boodschapbeantwoord dient te worden met een acknowledgement.

6.1.2 Sonar Turret

Een tweede belangrijk randprobleem was het gebrek aan sensoren op de Khepera II om nauw-keurige afstandsmetingen uit te voeren. Die zijn nodig om te werken vanuit het principe vanrelatieve positiebepaling, waarbij we elke robot situeren ten opzichte van de andere robots in deformatie.Een van de grote voordelen van de Khepera II -robots is echter dat ze over de mogelijkheid be-schikken om met behulp van extensieturrets hun functionaliteit uit te breiden. In het kader vandit onderzoek werd dan ook zo’n extensieturret gecreeerd die beschikt over ultrasone sensoren(SRF05-module) die toelaten om zeer precieze afstandsmetingen uit te voeren. In hoofdstuk 3werd de ontwikkeling van deze Sonar Turret uitgebreid behandeld waarbij we op het einde ookde nadelen besproken hebben, die zich vooral situeren op het vlak van snelheid. Het KNET-protocol waarmee de Khepera II communiceert met de extensieturret bleek hier een grote rol inte spelen. We hebben dan ook een mogelijkheid beschreven om de Sonar Turret te herontwerpenwaarbij het KNET-protocol niet gebruikt wordt.

6.1.3 Formatievorming

Eens deze twee belangrijke voorbereidende stappen genomen waren, kon overgegaan worden totde ontwikkeling van algoritmes voor formatievorming in dit multi-robot systeem.

In een eerste fase werd een algoritme ontwikkeld dat enkel gebruik maakt van de IR-sensorenop de Khepera II. Ondanks hun beperkte bereik tot een paar centimeter, bieden ze het voordeeldat ze heel snel en continu kunnen meten. Hierdoor kunnen de robots blijven rijden en hun ge-drag in real-time aanpassen, zodat in theorie de formatie behouden kon blijven tijdens het rijden.Er is echter gebleken dat de IR-sensoren van de verschillende robots elkaars metingen beınvloeden,waardoor hun sensorwaarden onbetrouwbaar worden. De robots kunnen bijgevolg hun gedragniet baseren op de IR-sensorwaarden; formatievorming was op die manier dus niet mogelijk.

De later ontwikkelde algoritmes maken dan ook enkel gebruik van ultrasone metingen. Dezewerden besproken in hoofdstuk 5. Naast een algoritme om de robots vanuit een willekeurigepositie in de vooropgestelde driehoeksformatie te laten komen, werden ook algoritmes ontwik-keld om hen in die formatie hun omgeving te laten verkennen. Hierbij werd ook de mogelijkheidingebouwd om obstakeldetectie en bijhorend ontwijkgedrag uit te voeren. Bij deze laatste algo-ritmes werd telkens uitgegaan van twee concurrerende systemen die werken op elke robot. Een

Hoofdstuk 6. Conclusies en perspectieven 106

systeem probeert ervoor te zorgen dat de formatie behouden blijft, terwijl het andere ervoorzorgt dat de robots hun omgeving verkennen en eventuele obstakels ontwijken.Deze twee systemen werden op twee verschillende manieren geımplementeerd. In het eerste algo-ritme zorgden we ervoor dat het gedrag om de omgeving te verkennen en obstakels te ontwijkenhetzelfde is voor elke robot. Het gedrag om in formatie te blijven verschilt dan bij elke robot.Hierdoor ligt echter wel de positie die een robot in een formatie inneemt, vast. Dit heeft totgevolg dat de robot die vooraan rijdt in de formatie een speciale functie krijgt, omdat hij bijvoor-beeld bepaalt hoe de ganse formatie een obstakel ontwijkt. Deze speciale rol kan doorgegevenworden tussen de robots, maar zal altijd door een robot uitgeoefend worden.In het tweede algoritme dat we ontwikkelden, is het net omgekeerd en is het gedrag om informatie te blijven hetzelfde voor elke robot, terwijl elke robot wel op een eigen manier de om-geving kan verkennen. De laatste aanpak zorgt ervoor dat de robots echt gelijkwaardig zijn inde formatie, zodat dit het meest interessante traject is om op verder te bouwen in de toekomst.

6.2 Perspectieven

Hoewel in dit onderzoek reeds heel wat werk werd verricht op het vlak van formatievorming, iser toch nog bijkomend onderzoek vereist om de ontwikkelde algoritmes te optimaliseren (vooralnaar snelheid) en nieuwe algoritmes te implementeren. Die zouden bijvoorbeeld kunnen toelatenom van formatie te veranderen of het aantal robots in de formatie dynamisch aan te passen. Debestaande communicatie, met de gesuggereerde uitbreidingen, biedt voldoende ondersteuningom dit te realiseren.

Om de ontwikkelde algoritmes sneller te kunnen uitvoeren, zou de Sonar Turret best geher-fabriceerd worden waarbij men het KNET-protocol ofwel vermijdt, ofwel verder optimaliseerten betrouwbaarder (en dus sneller) maakt.

Daarnaast zou het gebruik van beeldverwerking een nieuw scala van mogelijkheden bie-den waarbij robots onderscheiden kunnen worden van andere objecten en de omgeving betergeınterpreteerd kan worden.Aan de keuze van de camera moet uiteraard grondig onderzoek voorafgaan waarbij de verschil-lende mogelijkheden bekeken worden, maar wij raden op het eerste gezicht de CMUcam VisionTurret2 aan, omdat deze als enige toelaat de beeldverwerking op de extensieturret zelf te doenen niet op een afzonderlijke PC. In dat laaste geval zou de robot de beelden eerst naar een PCmoeten sturen om ze daar te laten verwerken. Dit zou een aanzienlijke vertraging introducerenen de robot minder autonoom maken dan bij de door ons voorgestelde camera.Het onderzoek kan dus verschillende richtingen uit.

2http://www.k-team.com/kteam/index.php?site=1&rub=3&upPage=108&page=17&version=EN

http://www.k-team.com/kteam/index.php?site=1&rub=3&upPage=108&page=17&version=EN

Bibliografie

[1] Michael J. B. Krieger, Jean-Bernard Billeter, and Laurent Keller. Ant-like task allocationand recruitment in cooperative robots. Nature, pages 992–995, August 2000.

[2] Soraya Kouadri Mostefaoui and Michele Courant. Collective adaptation of a heterogeneouscommunicating multi robot system. In Proceedings of the International Arab Conferenceon Information Technology, pages 1038–1044, University of Qatar, Doha-Qatar, December2002.

[3] M. Matskin. Distributed Artificial Intelligence and Intelligent Agents. Syllabus bij degelijknamige cursus, KTH, Stockholm, 2005.

[4] A. Maye and P. Bureau. High speed radio turret user manual. http://ftp.k-team.com/

khepera/documentation/KheBTManual.pdf, 2004.

[5] K-Team. Radio turret user manual. http://ftp.k-team.com/khepera/documentation/

RadioTurretManual.pdf, 1999.

[6] B. Senepart. Formatievorming in multi-robot systemen. Master’s thesis, Universiteit Gent,2005.

[7] K-Team. User manual. http://ftp.k-team.com/khepera/documentation/

Kh2UserManual.pdf, 2001.

[8] K. Thiel. Steuerung eines mobilen autonomen roboters mit selbstorganisierenden karten.Master’s thesis, Fachhochschule Konstanz, 2004.

[9] K-Team. Radio base user manual. http://ftp.k-team.com/khepera/documentation/

RadioBaseManual.pdf, 1999.

[10] K-Team. Bios manual. http://ftp.k-team.com/khepera/documentation/

KheperaBIOSRefManual.pdf, 1999.

[11] P.Bureau. Programming manual. http://ftp.k-team.com/khepera/documentation/

Kh2ProgrammingManual.pdf, 2002.

[12] Thomas Braunl. Embedded Robotics. Springer, 2003.

[13] The Institute of Electrical and Electronics Engineers. IEEE 802.3: Standard for CarrierSense Multiple Access with Collision Detection (CSMA/CD), 2002.

107

http://ftp.k-team.com/khepera/documentation/KheBTManual.pdf

http://ftp.k-team.com/khepera/documentation/KheBTManual.pdf

http://ftp.k-team.com/khepera/documentation/RadioTurretManual.pdf

http://ftp.k-team.com/khepera/documentation/RadioTurretManual.pdf

http://ftp.k-team.com/khepera/documentation/Kh2UserManual.pdf

http://ftp.k-team.com/khepera/documentation/Kh2UserManual.pdf

http://ftp.k-team.com/khepera/documentation/RadioBaseManual.pdf

http://ftp.k-team.com/khepera/documentation/RadioBaseManual.pdf

http://ftp.k-team.com/khepera/documentation/KheperaBIOSRefManual.pdf

http://ftp.k-team.com/khepera/documentation/KheperaBIOSRefManual.pdf

http://ftp.k-team.com/khepera/documentation/Kh2ProgrammingManual.pdf

http://ftp.k-team.com/khepera/documentation/Kh2ProgrammingManual.pdf

Bibliografie 108

[14] E. Franzi. Khepera bus and turret specifications. http://ftp.k-team.com/khepera/

documentation/KheperaBus.pdf, 2000.

[15] E. Franzi. K-net communication protocol specifications. http://ftp.k-team.com/

khepera/documentation/KheperaNET.pdf, 2000.

[16] K-Team. Sonar user manual. http://ftp.k-team.com/koala/sonar/SonarManual.pdf,2001.

[17] MAXIM. +5v, low-power, parallel-input, voltage-output, 12-bit dac. http://pdfserv.

maxim-ic.com/en/ds/MAX530.pdf, 1999.

[18] B. Schrauwen, M. D’Haene, D. Verstraeten, and D. Stroobandt. Framework for compactfpga implementations of spiking neurons. Technical report, Electronics and InformationSystems Department, Ghent University, Belgium, 2004.

http://ftp.k-team.com/khepera/documentation/KheperaBus.pdf

http://ftp.k-team.com/khepera/documentation/KheperaBus.pdf

http://ftp.k-team.com/khepera/documentation/KheperaNET.pdf

http://ftp.k-team.com/khepera/documentation/KheperaNET.pdf

http://ftp.k-team.com/koala/sonar/SonarManual.pdf

http://pdfserv.maxim-ic.com/en/ds/MAX530.pdf

http://pdfserv.maxim-ic.com/en/ds/MAX530.pdf

formatievorming in multi-robot systemen

Documents