Daan De Witte

Precieze controle van een omni-directionele robot

Academiejaar 2010-2011Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en Informatiesystemen

Master in de ingenieurswetenschappen: werktuigkunde-elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Begeleiders: Tim Waegeman, Francis wyffelsPromotor: prof. dr. ir. Benjamin Schrauwen

Daan De Witte

Precieze controle van een omni-directionele robot

Academiejaar 2010-2011Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en Informatiesystemen

Master in de ingenieurswetenschappen: werktuigkunde-elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Begeleiders: Tim Waegeman, Francis wyffelsPromotor: prof. dr. ir. Benjamin Schrauwen

Woord vooraf

Ik zou van dit voorwoord gebruik willen maken om mijn dank te betuigen aan iedereen die

direct of indirect heeft bijgedragen tot de ontwikkeling van deze masterproef.

Een speciaal dankwoord gaat uit naar mijn promotor prof. dr. ir. Benjamin Schrauwen en

mijn begeleiders Tim Waegeman, Francis wyffels, Ken Caluwaerts & Pieter-Jan Kindermans

die deze masterproef mogelijk maakten en mij gedurende het volledige verloop ervan met

advies hebben bijgestaan.

Verder wil ik nog Verena Heidrich-Meisner bedanken voor de aangename samenwerking in

een onderdeel van deze masterproef. En tot slot nog een dankwoord voor Lieve Verraes en

Jannick Staes voor het proeflezen van dit verslag.

Toelating tot bruikleen

De auteur(s) geeft(geven) de toelating deze masterproef voor consultatie beschikbaar te stellen

en delen van de masterproef te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder

de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de

bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

The author(s) gives (give) permission to make this master dissertation available for consulta-

tion and to copy parts of this master dissertation for personal use. In the case of any other

use, the limitations of the copyright have to be respected, in particular with regard to the

obligation to state expressly the source when quoting results from this master dissertation.

31 mei 2011

iv

Overzicht

In deze masterproef beogen we een precieze controle van een omni-directionele robot te re-

aliseren. Hiervoor ontwikkelen we een regelaar die de aansturing van de robot verzorgt op

basis van positie-informatie. In de hier beschouwde toepassing zal naast deze regelaar ook

een positiebepalingssysteem ontwikkeld worden dat samen met de regelaar een geıntegreerd

geheel vormt. Hierdoor ontstaat een autonome omni-directionele robot die op eender welke

locatie een vooropgesteld traject kan volgen.

Trefwoorden: omni-directioneel, mecanum, robot, regelaar, SLAM

v

Abstract

In this thesis we aim to realise pre-

cise control of an omni-directional ro-

bot equipped with four mecanum wheels.

More precisely we want to develop a

controller capable of steering the robot

to make it follow a predefined path. To

realise this, a controller is developed

which uses positional information co-

ming from an integrated positioning sy-

stem to control the speeds of the four

mecanum wheels.

Introduction

Much research has already been done in the

field of omni-directional robots. It appears

however that most of this research has been

focused on mechanical design. High preci-

sion path following control has yet to be tho-

roughly studied.

Some authors though have studied the con-

trol of omni-directional robots (e.g. [1], [2] &

[3]). In their findings they all mention that

due to heavy slippage it is impossible to re-

alise precise control without external positio-

nal information. Therefore an external posi-

tioning system (such as a digital camera) is

often used to monitor the robot’s movement

and thus provide feedback for the control me-

chanism.

In this thesis we used a different approach in

which we integrate a positioning system into

the control mechanism. That way the con-

troller is not depending on external sensors

and thus the robot is not limited to movement

within a restricted area which is the case in

most existing applictions.

Realisation

The used integrated positioning system is ba-

sed on the direct particle-SLAM algorithm as

developed in [4] and was adapted in such a

way that it can be run in realtime on an omni-

directional robot. In this application it uses

information from four wheel-encoders and one

laser range finder to determine the robot’s

position. One remark here is that due to

hardware limitations, the realtime calculati-

ons, needed to determine the robot’s position,

take up to 4 s.

The control part was developed in a number of

stages. Firstly a basic control mechanism was

created which uses only the kinematic mo-

del of the robot to calculate the wheel speeds

using the desired robot velocities, as can be

seen in formula 1 (the wheels are numbered

from left to right and front to back):

vi

vii

ω1 = v(vf − vs − 0.5ω) (1a)

ω2 = v(vf + vs + 0.5ω) (1b)

ω3 = v(vf + vs − 0.5ω) (1c)

ω4 = v(vf − vs + 0.5ω) (1d)

Here vf , vs and ω represent the desired for-

ward, sideways and rotational robot veloci-

ties. The factor v is used to scale the resulting

values up or down and is fixed at the begin-

ning of each execution.

Based on this initial mechanism a series of im-

proved controllers were developed. Two ma-

jor improvements were realised by adding an

extra feedback loop which controls the actual

robot speeds and by using an estimation of the

current position which dramatically shortens

the mentioned waiting time of 4 s. Further-

more, a variable scaling factor v was introdu-

ced to obtain a more accurate path following

control.

Results

We first tested the positioning system by ma-

nually controlling the robot movement. These

tests showed that the positioning system is

able to track the robot’s movement both in

static and dynamic environments. This ensu-

red us that the considered positioning system

can indeed be used as input for the developed

controller.

To test the performance of the controller we

set up a predefined path consisting of all pos-

sible combinations of movement in all three

degrees of freedom. We then assigned a score

to the controller for each part of the path.

This score consists of the summation of the

distance to the target position at all interme-

diate stages. The total (negative) summation

of these individual scores was then used to

compare the different controllers to each other

and to the maximum achievable performance.

With the final controller we achieved an aver-

age peformance which deviates only 6.8 %

from the maximum achievable performance

(compared to 40.5 % for the basic controller).

Conclusions

In this thesis we developed a controller with

an integrated positioning system capable of

steering an omni-directional robot to make it

follow a predefined path with an error of only

6.8 %. Future work may be done on impro-

ving the positioning system (for example by

removing the hardware limitations or by using

different inputs) or expanding the application

mode (for instance by using path planning al-

gorithms).

References

[1] J. A. Cooney, W. L. Xu & G. Bright (2004).

Visual dead-reckoning for motion control of a

mecanum-wheeled mobile robot. Mechatronics,

14:623-637.

[2] J.B. Song & K.S. Byun (2004). Design and con-

trol of a four-wheeled omnidirectional mobile ro-

bot with steerable omnidirectional wheels. Jour-

nal of Robotic Systems, 21(4):193-208.

[3] R. Rojas & A. G. Forster (2006). Holonomic

control of a robot with an omnidirectional drive.

Kunstliche Intelligenz, 20(2).

[4] A.I. Eliazar & R. Parr (2004). DP-SLAM 2.0.

IEEE International Conference on Robotics and

Automation, pp. 1314-1320.

Inhoudsopgave

1 Inleiding 1

1.1 Omni-directionele robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Omni-wielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Mecanum wielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Probleem- & doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Bestaande oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Experimentele opstelling 6

2.1 Randapparatuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Sensoren & actuatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Elektronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 Voeding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Geometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Afmetingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Kinematisch model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Aansturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Communicatiestructuren . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 Manuele aansturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Gonzales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Positiebepaling 15

3.1 Simultane localisatie en kaartgeneratie . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Direct Particle SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 DP-SLAM voor Gonzales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Databestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 Hardware & geometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.3 Aandrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.4 Realtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.5 Hierarchische structuur . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.6 Gevolgde traject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Bespreking eindresultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

viii

Inhoudsopgave ix

4 Regelaars 24

4.1 Regelaar I: Een klassieke aanpak . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 Het traject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.2 De regelaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Regelaar II: CMA-ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 CMA-ES leerstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Regelaar III: Tijdsvertragingen . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Situatieschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 De regelaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Regelaar IV: Foutcorrecties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 Regelaar V: Variabele snelheid . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Hoe te gebruiken 36

5.1 Verbinden met Gonzales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Indeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Uitvoering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Extra opties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Resultaten 40

6.1 Het positiebepalingssysteem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1.1 Gebruik in een statische ruimte . . . . . . . . . . . . . . . . . . . . . . 40

6.1.2 Gebruik in aangrenzende statische ruimtes . . . . . . . . . . . . . . . . 42

6.1.3 Gebruik in een dynamische omgeving . . . . . . . . . . . . . . . . . . 43

6.1.4 Tijdsduur van het positiebepalingssysteem . . . . . . . . . . . . . . . . 44

6.2 De regelaars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.1 Testprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.2 Behaalde resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Conclusies en perspectieven 53

7.1 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Perspectieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2.1 Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2.2 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A Programmacode 56

B Datasheets 57

Bibliografie 58

Hoofdstuk 1

Inleiding

Deze masterproef handelt over het controleren van een omni-directionele robot, meer bepaald

het controleren van de bewegingen ervan. We willen hier uiteindelijk een nauwkeurige traject-

controle realiseren voor een omni-directionele robot. In wat volgt zal stelselmatig uiteengezet

worden hoe dit gerealiseerd wordt. In hoofdstuk 2 wordt eerst de gebruikte opstelling ver-

duidelijkt waarna in hoofdstukken 3 en 4 de realisatie zelf wordt uiteengezet. De praktische

uiteenzetting over de werking van het geheel wordt in hoofdstuk 5 besproken en in hoofdstuk 6

worden de behaalde resultaten geanalyseerd. In hoofdstuk 7 ten slotte vatten we alles samen

en worden nog enkele vooruitzichten gegeven op mogelijke uitbreidingen en toepassingen. In

dit hoofdstuk gaan we nu eerst dieper in op de gebruikte technologie en het reeds verrichte

onderzoek in dit domein.

1.1 Omni-directionele robot

Wanneer we spreken over een omni-directionele robot bedoelen we een robot die zich in

elke mogelijke richting kan verplaatsen. Om de gedachten te vestigen beschouwen we een

horizontaal vlak waarin de robot zich vrij kan bewegen. We karakteriseren deze bewegingen

door een vast assenstelsel in te voeren waarvan de oorsprong zich bevindt op de startpositie

van de robot. Hierbij kiezen we dan de x-as volgens de initiele voorwaartse bewegingsrichting,

de positieve y-as richten we naar links en de z-as naar boven zodat een rechtshandig cartesiaans

assenstelsel bekomen wordt (zie ook figuur 1.1). De mogelijke verplaatsingen van een omni-

directionele robot zijn dan een translatie in de x- en y-richting en een rotatie rondom de

z-as.

1.1.1 Omni-wielen

Om een dergelijk rijgedrag mogelijk te maken moet een omni-directionele robot voorzien wor-

den van aandrijfmogelijkheden in elk van de drie beschouwde vrijheidsgraden. Typisch wordt

1

Hoofdstuk 1. Inleiding 2

Figuur 1.1: Het gebruikte cartesiaanse assenstelsel als referentie voor de verplaatsingen van de robot.

dit gerealiseerd door de robot van drie wielen te voorzien waarvan de assen over 120◦ verscho-

ven zijn zoals geıllustreerd is in figuur 1.2. Dit is dan ook de meest eenvoudige uitvoering die

een omni-directioneel gedrag mogelijk maakt. Bij het aandrijven van deze robot zal elk wiel

zich proberen te verplaatsen volgens zijn eigen rijrichting die dus 120◦ gedraaid is tegenover

deze van de twee andere wielen. De beweging van de robot zelf volgt dan uit de superpositie

van de verwachte verplaatsing van de drie afzonderlijke wielen. Door een juiste keuze van

de rotatiesnelheid van de drie wielen kan de robot zich dus in de drie mogelijke vrijheden

bewegen.

Figuur 1.2: Een typische uitvoering van een omni-directionele robot waarbij drie wielen gebruikt

worden met onderling over 120◦ verschoven assen.

Hoofdstuk 1. Inleiding 3

Doordat in deze uitvoering de drie wielen elk een eigen logische rijrichting hebben, zullen ze bij

translatie van de robot gedwongen worden zich volgens een richting te verplaatsen verschillend

van deze logische rijrichting. Hierdoor ontstaat een grote slip. Om dit doorslippen tegen te

gaan, onder andere om te grote wrijvingskrachten te vermijden, worden speciaal ontworpen

wielen gebruikt, omni-wielen. Figuur 1.3 toont hoe deze uitvoering ervoor zorgt dat de wielen

zowel actief, door de aandrijving, als passief, door slip, kunnen roteren.

Figuur 1.3: Actieve en passieve rotatie bij een omni-wiel.

1.1.2 Mecanum wielen

Een alternatieve methode om een gelijkwaardige bewegingsvrijheid te verkrijgen gaat uit van

een normale vier-wiel-opstelling waarbij mecanum wielen gebruikt worden. Zoals te zien is

op figuur 1.4 zijn deze opgebouwd uit een cilindrisch hoofdframe waarin langs de omtrek een

reeks kleine toncilinders zijn bevestigd. Deze kunnen vrij roteren en zijn zo gepositioneerd

dat hun rotatie-as een hoek maakt van 45◦ met de rotatie-as van het hoofdframe. Dit zorgt

ervoor dat wanneer een dergelijk wiel draait rondom de as van het hoofdframe het zich

zal verplaatsen volgens een richting die een hoek maakt van 45◦ met de logische voor- of

achterwaartse bewegingsrichting. Om dit te visualiseren zouden we de robot dus ook kunnen

voorstellen door de vier mecanum wielen te vervangen door vier normale wielen die 45◦

verdraaid opgesteld staan zoals in figuur 1.5 wordt geıllustreerd. Opnieuw zal elk wiel zich

volgens zijn eigen rijrichting willen verplaatsen en volgt de beweging van de robot uit de

superpositie van de vier verwachte verplaatsingen.

Hoofdstuk 1. Inleiding 4

Figuur 1.4: Opbouw van een mecanum wiel.

Figuur 1.5: Analogie tussen een werkelijke uitvoering met mecanum wielen (links) en een fictieve

uitvoering met gewone wielen (rechts).

1.2 Probleem- & doelstelling

Zoals hierboven reeds aangehaald werd ontstaat er een zekere slip doordat de wielen gedwon-

gen worden zich in een richting te verplaatsen verschillend van hun voorkeursrichting. Verder

kan slip ook ontstaan door een wijzigende grip van de verschillende wielen met de ondergrond

(bijvoorbeeld door ongelijke gewichtsverdeling of oneffenheden). Zoals ook in Salih et al.

(2006) aangehaald wordt ontstaat hierdoor een afwijkend rijgedrag. De werkelijke beweging

van het geheel volgt niet langer uit de superpositie van de verwachte verplaatsingen van de

afzonderlijk wielen. Hierdoor kan men ook de verplaatsing van de robot niet meer berekenen

uit de rotatie van de wielen maar moet hiervoor extra informatie gebruikt worden (zie ook

Song & Byun (2004), Rojas & Forster (2006) & Cooney et al. (2004)).

Hoofdstuk 1. Inleiding 5

Er is dus nood aan een geavanceerde besturing die hiermee rekening houdt en in staat is de

gewenste verplaatsing te realiseren. De doelstelling van deze masterproef bestaat er dan ook

in een regelaar te ontwikkelen die de gebruiker in staat stelt precieze trajectcontrole op een

omni-directionele robot uit te voeren.

Om aan trajectcontrole te kunnen doen moet er echter ook informatie beschikbaar zijn omtrent

de positie van de robot in zijn omgeving. De oorspronkelijke doelstelling vertaalt zich hierdoor

in twee deelaspecten. Enerzijds moet er een positiebepalingssysteem geımplementeerd worden

en anderzijds moet er een regelaar ontwikkeld worden die op basis van het gewenste traject

en de huidige positie de juiste aansturing verzorgt.

1.3 Bestaande oplossingen

Alhoewel omni-directionele robots reeds enkele jaren ingezet worden is er nog maar weinig

onderzoek verricht naar een accurate aansturing ervan (zie ook Watanabe et al. (1998), Dong

et al. (2009) & Liu et al. (2003)). Het grootste deel van het reeds bestaande onderzoek omtrent

omni-directionele robots focust zich vooral op het ontwikkelen van (verbeterde) mechanische

constructies en de kinematische studie ervan. Deze studies vormen dan ook meestal de basis

van reeds ontwikkelde regelsystemen. Zo gaan Watanabe et al. (1998), Song & Byun (2004)

& Liu et al. (2003) in hun regelaar uit van het kinematisch verband tussen de snelheden van

de wielen en deze van de omni-directionele robot. Dit verband wordt dan gebruikt om op

basis van de gewenste robotsnelheden de juiste rotatiesnelheden van de wielen te bepalen.

Om verder de overmatige slip en het afwijkend rijgedrag dat er uit volgt te verwerken wordt

er meestal gebruik gemaakt van externe systemen die de werkelijke positie moeten bepalen.

Meestal is dit een camera die van bovenaf de bewegingen van de robot registreert (zie bv

Rojas & Forster (2006)). Deze externe systemen zijn echter beperkt in bereik waardoor de

robot zich niet buiten een bepaalde omgeving mag begeven. Een betere oplossing bestaat erin

extra sensoren op de robot zelf te installeren. Zo wordt bijvoorbeeld in Cooney et al. (2004)

een combinatie van twee optische muizen gebruikt om de beweging van de robot te bepalen.

In deze masterproef zullen we ons toeleggen op het ontwikkelen van een geheel dat niet enkel

een regelsysteem bevat maar tevens ook een geıntegreerd positiebepalingssysteem. Op die

manier willen we een omni-directionele robot realiseren die in eender welke omgeving ingezet

kan worden.

Hoofdstuk 2

Experimentele opstelling

In hoofdstuk 1 werd reeds aangehaald dat er in deze masterproef gewerkt wordt rond een omni-

directionele robot. In ditzelfde hoofdstuk werden ook twee mogelijke realisaties uiteengezet

waarmee een omni-directioneel rijgedrag mogelijk gemaakt kan worden, namelijk aan de hand

van omni-wielen of mecanum wielen (zie secties 1.1.1 en 1.1.2). Deze laatste optie is wat

aangewend zal worden in de gebruikte opstelling. In wat volgt werken we dus steeds met een

mobiele robot voorzien van vier onafhankelijk aanstuurbare mecanum wielen zoals ontworpen

in Melange et al. (2010).

2.1 Randapparatuur

Om communicatie met en aansturing van de robot mogelijk te maken is deze, naast het

draagframe en de vier mecanum wielen, nog voorzien van de nodige randapparatuur. We

bespreken hier kort alle geınstalleerde componenten. De volledige specificaties ervan zijn

terug te vinden in bijlage B.

2.1.1 Sensoren & actuatoren

Om te beginnen worden alle wielen aangedreven door een DC motor. Typisch hebben deze

motoren een zeer hoog toerental en is er dus nood aan een reductiekast om de snelheid

van de uitgaande as voldoende laag te houden. Bij het ontwerp van de gebruikte robot zijn

echter motoren gebruikt die reeds over een ingebouwde reductiekast beschikken wat het geheel

behoorlijk compact maakt. Hiernaast zijn deze ook voorzien van een encoder die de rotatie

van het wiel tot op 0, 2◦ nauwkeurig volgt. Verder is de robot uitgerust met een Laser Range

Finder (LRF) waarmee hij een beeld van zijn omgeving kan vormen. Dit wordt gerealiseerd

door de afstand te meten tot de omgeving met een frequentie van 1 meetpunt per 0, 36◦ over

een bereik van 240◦. Ten slotte is er op het draagframe nog een reeks van zes infrarode

afstandssensoren opgesteld, drie aan de voorkant en drie aan de achterkant. Deze worden

6

Hoofdstuk 2. Experimentele opstelling 7

eigenlijk niet gebruikt aangezien de bekomen informatie reeds vervat zit in deze van de LRF,

maar ze kunnen in eenvoudige toepassingen mogelijks wel hun nut bewijzen.

2.1.2 Elektronica

Het aandrijven van de vier DC motoren gebeurt via vier H-bruggen die een PWM signaal

afkomstig van een drietal PIC microcontrollers versterken en doorgeven. Deze microcontrol-

lers staan ook in voor de communicatie met de encoders en de infrarode afstandssensoren.

De communicatie met de LRF wordt verzorgd door een minicomputer waarop het LINUX1

besturingssysteem is geınstalleerd. Het is op deze computer dat het positiebepalingssysteem

en de regelaar geımplementeerd zullen worden. De communicatie met de gebruiker ten slotte

verloopt via een netwerkkabel aangesloten op de minicomputer.

2.1.3 Voeding

Voor de voeding van dit alles kan gekozen worden tussen twee loodaccu’s van 12 V in serie

of een externe voeding die via een extra voedingskabel het vermogen tot bij de robot brengt.

Twee spanningsregelaars controleren dan de voedingsspanning voor de minicomputer, de mi-

crocontrollers en de DC motoren. Er kan echter ook gekozen worden om de minicomputer

van een afzonderlijke voeding te voorzien. Hiervoor is dan een tweede extra voedingskabel

nodig.

2.2 Geometrie

We vermelden hier eerst de belangrijkste geometrische aspecten die nodig zijn voor de kine-

matische studie van de beweging van de robot. Deze gebruiken we vervolgens bij het opstellen

van het theoretisch model dat de beweging van de robot modelleert.

2.2.1 Afmetingen

Het draagframe met de vier mecanum wielen kan als een vierkant met zijde 32 cm opgevat

worden. Dit is de afstand tussen de as van de voorste en achterste wielen alsook de afstand

tussen het midden van de linker en rechter wielen. De wielen zelf zijn 6 ” in diameter. Verder

is de LRF in het midden tussen de vier wielen opgesteld en bevindt deze zich op een hoogte

van 30 cm. Dit alles is ook duidelijk geıllustreerd in figuur 2.1 en samengevat in tabel 2.1.

2.2.2 Kinematisch model

Het kinematisch model is een theoretisch model dat het verband legt tussen de rotatie van

de wielen en de verplaatsing van de robot. Hiermee kunnen we dus theoretisch de verplaat-

1Debian 5.0.5 met Real Time Linux kernel

Hoofdstuk 2. Experimentele opstelling 8

Figuur 2.1: Geometrische afmetingen van de gebruikte robot.

Tabel 2.1: Overzicht en benoeming van de afmetingen van de gebruikte robot.

Omschrijving Symbool Waarde

Straal van de wielen r 7,62 cm

Afstand tussen de wielen (voor-achter & links-rechts) d 32 cm

Afstand tussen wiel en LRF e 22,63 cm

sing van de robot afleiden uit de rotatie van de vier mecanum wielen. Belangrijker hier is

dat we dus ook de gewenste rotatiesnelheden van de wielen kunnen halen uit de gewenste

verplaatsingsrichting van de robot zelf. Dit kinematisch model is uiteraard afhankelijk van

de hierboven vermelde geometrische afmetingen.

In wat volgt zullen de notaties uit tabel 2.2 gebruikt worden om de verplaatsingssnelheden van

de robot (in cm/s en rad/s) en de rotatiesnelheden van de wielen (in toeren per minuut) aan

te duiden. De nummering van de wielen is geıllustreerd in figuur 2.2 waarop de voorwaartse

rijrichting door de pijl wordt aangeduid.

De gebruikte zijwaartse translatiesnelheid vs is positief voor verplaatsingen naar links en nega-

tief voor verplaatsingen naar rechts gezien vanuit het standpunt van de robot. De rotatiesnel-

heid is positief voor rotaties in tegenwijzerzin indien van bovenaf bekeken. De referentiezin

voor rotatie van de wielen ten slotte komt overeen met deze die men zou verwachten bij een

voorwaarts rijdend vierwielig voertuig.

Bij de uiteenzetting van het mecanum wiel (zie sectie 1.1.2) werd reeds aangehaald dat een

dergelijk wiel zich niet enkel in de logische voor- of achterwaartse richting verplaatst maar

Hoofdstuk 2. Experimentele opstelling 9

Tabel 2.2: Gebruikte notaties in het kinematisch model.

Omschrijving Symbool Eenheid

Voorwaartse translatiesnelheid vf cm/s

Zijwaartse translatiesnelheid vs cm/s

Rotatiesnelheid ω rad/s

Rotatiesnelheid wiel 1 ω1 tpm

Rotatiesnelheid wiel 2 ω2 tpm

Rotatiesnelheid wiel 3 ω3 tpm

Rotatiesnelheid wiel 4 ω4 tpm

Figuur 2.2: Nummering van de vier mecanum wielen.

een even grote zijwaartse verplaatsing uitvoert. Door een juiste keuze van de rotatiezin van

elk wiel kunnen we dus de robot de gewenste beweging laten uitvoeren. Dit is geıllustreerd

in figuur 2.3.

Om nu de resulterende verplaatsingssnelheden van de robot uit de rotatiesnelheden van de

wielen af te leiden moeten we de bijdrage van elk wiel tot de beschouwde bewegingsrichting

in rekening brengen. Dit geeft de volgende uitdrukking voor de drie verplaatsingssnelheden:

vf =ω1 + ω2 + ω3 + ω4

4f1 (2.1a)

vs =−ω1 + ω2 + ω3 − ω4

4f1 (2.1b)

ω =−ω1 + ω2 − ω3 + ω4

4f2 (2.1c)

Hoofdstuk 2. Experimentele opstelling 10

Figuur 2.3: De mogelijke bewegingsrichtingen met bijhorende wielsnelheden.

Hierbij zijn f1 respectievelijk f2 de conversiefactoren die de rotatiesnelheden van de wielen

omzetten naar een translatiesnelheid respectievelijk rotatiesnelheid van de robot. Deze zijn

afhankelijk van de geometrie en worden als volgt bepaald:

f1 =2πr

60(2.2a)

f2 =2πr

60√

2e(2.2b)

Wat we nu eigenlijk willen, is het omgekeerde verband dat ons toelaat de gewenste wielsnel-

heden af te leiden uit de vooropgestelde verplaatsing van de robot. We kunnen dit uit het

voorgaande gemakkelijk afleiden en we vinden:

Hoofdstuk 2. Experimentele opstelling 11

ω1 =vff1− vsf1− ω

f2(2.3a)

ω2 =vff1

+vsf1

+ω

f2(2.3b)

ω3 =vff1

+vsf1− ω

f2(2.3c)

ω4 =vff1− vsf1

+ω

f2(2.3d)

2.3 Aansturing

Om nu de robot te laten rondrijden moeten we elk van de vier wielen afzonderlijk aansturen.

Dit houdt dus in dat we de gewenste rotatiesnelheid van elk wiel moeten bepalen en deze

doorgeven naar de aansturing van de motoren. Zoals reeds in sectie 2.1.2 vermeld werd komen

er een aantal onderdelen aan te pas bij het doorgeven van deze gewenste rotatiesnelheid van de

gebruiker naar de motoren. We lichten hierna eerst de communicatiestructuren toe, waarna

we de aansturing zelf verder uitwerken.

2.3.1 Communicatiestructuren

Figuur 2.4 geeft een schematisch overzicht van de communicatiestructuur tussen de verschil-

lende onderdelen. De eerste stap bij het aansturen van de motoren is het genereren van de

gewenste rotatiesnelheden van de vier wielen. Dit gebeurt door aan de hand van het be-

sproken kinematisch model de gewenste rijrichting te vertalen naar de vier rotatiesnelheden.

De bekomen snelheden worden vervolgens via de minicomputer doorgestuurd naar een eerste

microcontroller (voorgesteld door PIC1). Deze microcontroller splitst de gekregen snelheden

op (deze voor wiel 1 & 2 en deze voor wiel 3 & 4) en stuurt ze op zijn beurt door naar de twee

volgende microcontrollers (voorgesteld door PIC2a en PIC2b). Deze twee microcontrollers

staan elk in voor het aansturen van twee van de vier wielen. Ze vertalen de rotatiesnelheden

naar een PWM signaal dat via een H-brug uiteindelijk bij de motoren terecht komt.

Bij het aansturen van de motoren is er dus sprake van een eenrichtingsverkeer van de gebruiker

naar de motoren. Deze structuur kan echter ook in twee richtingen doorlopen worden. Dit

is bijvoorbeeld het geval bij het opvragen van informatie uit de encoders in de motoren.

Hierbij wordt dan door de gebruiker eerst een aanvraag verzonden die via de minicomputer

bij de eerste microcontroller terechtkomt. Vervolgens wordt deze aanvraag doorgespeeld naar

de twee ondergeschikte microcontrollers. Deze lezen dan de informatie in afkomstig van

de encoders en uiteindelijk wordt deze in de omgekeerde richting terug naar de gebruiker

verzonden.

Hoofdstuk 2. Experimentele opstelling 12

Figuur 2.4: Schematische voorstelling van de communicatiestructuur.

Hier komt echter wel een tussenstap bij kijken. De hoofdmicrocontroller zal de informatie uit

de vier encoders namelijk eerst via het kinematisch model vertalen naar verplaatsingen volgens

de drie bewegingsvrijheden van de robot en dit vervolgens doorsturen naar de gebruiker. De

programmacode die dit realiseert is terug te vinden in bijlage A.

2.3.2 Manuele aansturing

In de microcontrollers vertalen we dus de gewenste rotatiesnelheden naar PWM signalen die

aan de motoren aangelegd worden. Hiervoor kunnen we eenvoudigweg gebruik maken van

de beschikbare PID modules op de gebruikte microcontrollers. Dit werd reeds in Melange

et al. (2010) geımplementeerd. Bij deze implementatie moet de gebruiker echter de bewe-

gingssnelheden van de robot doorgeven in plaats van de vier rotatiesnelheden van de wielen.

Deze worden dan in de hoofdmicrocontroller via het kinematisch model vertaald naar de vier

rotatiesnelheden. We willen echter zelf deze vier rotatiesnelheden kunnen bepalen en passen

dus de programmacode aan. De gewijzigde versie van de code die hier gebruikt zal worden is

terug te vinden in bijlage A.

De gebruiker moet nu dus de vier gewenste rotatiesnelheden genereren. Om het manuele aan-

sturen wat eenvoudiger te maken ontwikkelen we een eerste simpele regelaar. Hierbij stellen

we een vaste snelheid in en geven we de gebruiker de keuze tussen enkele mogelijke bewegings-

Hoofdstuk 2. Experimentele opstelling 13

modi. Deze kan hij dan activeren aan de hand van het numeriek toetsenbord. Tabel 2.3 geeft

een overzicht van deze bewegingsmodi alsook de bijhorende toetsen en stuursignalen. Elke

toets stemt dus met een bepaalde beweging overeen waaraan een set van vier stuursignalen

gekoppeld is, geschaald volgens de ingestelde snelheid v.

Tabel 2.3: Numeriek toetsenbord als invoer voor manuele aansturing.

Stuursignalen

Beweging Toets ω1 ω2 ω3 ω4

Voorwaarts 8 v v v v

Achterwaarts 2 -v -v -v -v

Zijwaarts links 4 -v v v -v

Zijwaarts rechts 6 v -v -v v

Voorwaarts links 7 0 2v 2v 0

Voorwaarts rechts 9 2v 0 0 2v

Achterwaarts links 1 -2v 0 0 -2v

Achterwaarts rechts 3 0 -2v -2v 0

Rotatie links 0 -v v -v v

Rotatie rechts . v -v v -v

Stilstaan 5 0 0 0 0

Voor het bepalen van de schaalfactor v stellen we een translatiesnelheid in x- en/of y-richting

van 5 cm/s voorop. Volgens het kinematisch model komt hier een rotatiesnelheid van de wielen

van 6, 27 tpm mee overeen. Aangezien we echter enkel gehele getallen gebruiken ronden we

dit af naar 6 tpm. De translatie- en rotatiesnelheid van de robot die hiermee overeenstemt is

dan 4, 78 cm/s en 0, 15 rad/s of 8, 6◦/s. We zullen later de gebruiker toelaten de ingestelde

rotatiesnelheid indien gewenst te varieren tussen 1 en 10 tpm.

2.4 Gonzales

De werkelijke uitvoering van de hierboven beschreven robot is te zien in figuur 2.5. In wat

volgt zal naar deze robot steeds verwezen worden met de naam Gonzales.

Hoofdstuk 2. Experimentele opstelling 14

Figuur 2.5: De werkelijke uitvoering van de gebruikte robot, Gonzales.

Hoofdstuk 3

Positiebepaling

Zoals reeds eerder vermeld valt de doelstelling uiteen in twee deelaspecten, enerzijds is er

de nood aan positiebepaling en anderzijds moet er een regelaar ontwikkeld worden voor het

aansturen van Gonzales (zie sectie 1.2). In dit hoofdstuk zal de realisatie van het positiebe-

palingssysteem uiteen gezet worden. De ontwikkeling van de regelaar wordt in hoofdstuk 4

behandeld.

3.1 Simultane localisatie en kaartgeneratie

Om aan trajectcontrole te kunnen doen is er dus nood aan een positiebepalingssysteem. Met

dit systeem moet Gonzales in staat zijn zijn huidige positie te bepalen en dit terwijl hij

zich verplaatst. Deze positie-informatie is echter volkomen nutteloos zonder kennis van de

omgeving waarin Gonzales zich bevindt. We moeten dus op een of andere manier over een

kaart van de omgeving beschikken waarin we dan de positie van Gonzales kunnen bepalen.

Voor gebruik in een statische omgeving zouden we ervoor kunnen kiezen om op voorhand

deze omgeving in kaart te brengen. We kunnen deze informatie dan eenmalig inladen zodat

Gonzales deze vanaf dan kan gebruiken bij het bepalen van zijn positie. We willen echter

Gonzales in elke situatie kunnen gebruiken zonder dat deze voorkennis heeft van de omgeving

waarin hij zich bevindt. Hij moet dus niet enkel zijn positie kunnen bepalen, maar ook zelf

zijn omgeving in kaart kunnen brengen.

In sectie 2.1 vermeldden we reeds dat Gonzales uitgerust is met een LRF. Deze sensor kunnen

we gebruiken om de nodige informatie over Gonzales’ omgeving te bekomen. Het gezichtsveld

dat we hiermee verkrijgen is echter wel beperkt tot een bereik van 240◦. Gonzales kan dus

vanuit zijn initiele positie slechts een deel van zijn omgeving scannen. Ook informatie over

aangrenzende ruimtes kan hij onmogelijk vanuit zijn startpostie verkrijgen. Dit zorgt ervoor

dat het in kaart brengen van de omgeving niet op voorhand kan gerealiseerd worden, maar

geleidelijk aan moet gebeuren terwijl Gonzales zich verplaatst. Wat we hier dus nodig hebben

15

Hoofdstuk 3. Positiebepaling 16

is een positiebepalingssysteem dat simultaan de omgeving in kaart brengt en in deze kaart

dan de huidige positie bepaalt, ook wel simultane lokalisatie en kaartgeneratie of simultanous

localisation and mapping genoemd, afgekort als SLAM.

SLAM op zich is reeds uitgebreid bestudeerd in de literatuur (zie bv Durrant-Whyte & Tim

(2006a) en Durrant-Whyte & Tim (2006b)) en we kunnen hier dus gebruik maken van reeds

bestaande algoritmes. Het algoritme dat hier gebruikt zal worden is het Direct-Particle SLAM

algoritme (DP-SLAM ) ontwikkeld door Eliazar & Parr (2004). Hiervan bestaat reeds een

implementatie die vrij ter beschikking gesteld wordt door de Duke University1. Deze is

hier echter niet direct bruikbaar maar zal wel de basis vormen voor het hierna ontwikkelde

positiebepalingssysteem.

3.2 Direct Particle SLAM

We kiezen er dus voor om DP-SLAM te implementeren op Gonzales als positiebepalings-

systeem. Aangezien het ontwikkelen van het algoritme zelf geen deel uitmaakt van deze

masterproef verwijzen we voor de volledige uiteenzetting ervan naar de bijhorende literatuur.

We geven hier wel een beknopte samenvatting van de logische structuur die de basis vormt

van dit algoritme.

Indien we de belangrijkste programmacode van de beschikbare implementatie sterk zouden

vereenvoudigen krijgen we de volgende pseudocode:

** HOOG NIVEAU **

Initialiseer nieuw grid

Initialiseer nieuwe boomstructuur

Herhaal {

Haal data op {

** LAAG NIVEAU **

Initialiseer nieuw grid

Initialiseer nieuwe boomstructuur

Herhaal n keer {

Haal data op {

Schat nieuwe positie

Scan omgeving

}

Analyseer data {

Genereer deeltjes op basis van voorlopige positie

Evalueer deeltjes

Verwijder onwaarschijnlijke deeltjes

1Deze is te vinden op http://www.cs.duke.edu/~parr/dpslam/.

Hoofdstuk 3. Positiebepaling 17

Voeg overige deeltjes toe aan de boomstructuur

}

}

Zoek meest waarschijnlijke deeltje

Bepaal overeenkomstige eindpositie

Genereer overeenkomstige kaart

Geef positie en kaart door aan HOOG NIVEAU

** EINDE VAN LAAG NIVEAU **

}

Analyseer data{

Genereer deeltjes op basis van voorlopige positie

Evalueer deeltjes

Verwijder onwaarschijnlijke deeltjes

Voeg overige deeltjes toe aan de boomstructuur

}

}

Zoek meest waarschijnlijke deeltje

Genereer overeenkomstige kaart

** EINDE VAN HOOG NIVEAU **

Wat hieruit meteen opvalt is dat er gewerkt wordt op twee niveaus, een hoofdniveau en een

ondergeschikt niveau. Beide niveaus blijken ook exact hetzelfde proces uit te voeren. We

overlopen even kort dit proces.

Als we de structuur bekijken zien we dat de eigenlijke bewerkingen beginnen bij het lage

niveau. Dit niveau neemt als invoer een schatting van de verplaatsing en een scan van de

omgeving. Op basis van deze geschatte verplaatsing wordt nu eerst een voorlopige indicatie

gemaakt van waar de robot zich kan bevinden. Hierna worden een aantal deeltjes gegenereerd

die elk een mogelijke positie rond deze geschatte positie vertegenwoordigen. Deze deeltjes

worden vervolgens aan de hand van de reeds beschikbare kaart (de gridstructuur) en de scan

van de omgeving geevalueerd op hun probabiliteit. En op basis hiervan worden dan de deeltjes

met de laagste waarschijnlijkheid verwijderd. Dit principe noemt men een deeltjesfilter of ook

wel particle filter, vandaar de naam Direct Particle SLAM.

De overblijvende deeltjes worden dus bewaard en toegevoegd aan een boomstructuur. Deze

boomstructuur stelt eigenlijk het afgelegde traject volgens het desbetreffende deeltje voor.

Gemeenschappelijke takken in deze boomstructuur komen dan overeen met gemeenschappe-

lijke delen in het afgelegde traject.

Na een aantal iteraties wordt uiteindelijk de meest waarschijnlijke verplaatsing tot dan toe

bepaald alsook de hiermee corresponderende kaart. Deze informatie wordt dan als invoer

gebruikt voor het hoge niveau. Hier wordt nu de doorgegeven kaart uit het lage niveau in een

Hoofdstuk 3. Positiebepaling 18

groter geheel geplaatst volgens exact dezelfde werkwijze. Ten slotte wacht het dan op nieuwe

data afkomstig van het lage niveau. Dit proces blijft zich nu herhalen totdat een stopconditie

(bijvoorbeeld een signaal van de gebuiker of het bereiken van een bepaalde positie) bereikt

wordt waarna dan de volledige kaart van de verkende omgeving gevisualiseerd wordt.

We wijzen erop dat deze beschrijving verre van volledig is. Ze geeft echter wel op een vereen-

voudigde manier de belangrijkste stappen weer die doorlopen worden in het algoritme.

3.3 DP-SLAM voor Gonzales

We vertrekken nu vanuit de ter beschikking gestelde implementatie. Deze is echter ontworpen

voor gebruik op ATRV-Junior, een normaal vierwielig voertuig zoals te zien is op figuur 3.1.

Dit voertuig verschilt echter op een aantal structurele aspecten van Gonzales. De gebruikte

hardware, de geometrie en de aandrijving vormen hierbij de belangrijkste verschillen. Hier-

door behoort een rechtstreekse implementatie niet tot de mogelijkheden. Ook voldoet de

implementatie niet aan onze eisen op vlak van snelheid en uitvoeringsmodus.

Figuur 3.1: ATRV-Junior, de robot waarvoor de beschikbare implementatie ontworpen is.

In Melange et al. (2010) werd reeds een poging ondernomen om deze implementatie geschikt

te maken voor gebruik op Gonzales. Het resultaat blijkt echter niet te werken en we zullen

dus zelf een eigen implementatie realiseren. In wat volgt gaan we dieper in op de ondernomen

stappen bij het omvormen van de beschikbare implementatie naar een bruikbare versie voor

Gonzales.

Hoofdstuk 3. Positiebepaling 19

3.3.1 Databestanden

Om te beginnen kunnen we de implementatie niet gebruiken terwijl Gonzales rondrijdt. We

kunnen er enkel databestanden mee verwerken die informatie bevatten over het rijgedrag uit

een voorbije sessie. Zoals uiteengezet in de structuur van het algoritme bestaat deze data

uit een ruwe schatting van de verplaatsing en een bijhorende scan van de omgeving. Voor de

specifieke toepassing op Gonzales leiden we deze geschatte verplaatsing af uit de informatie

die we krijgen van de encoders. Hierbij wordt via het kinematisch model van de robot (zie

sectie 2.2.2) de verplaatsing van Gonzales in elk van de drie bewegingsvrijheden afgeleid uit

de rotatie van de vier wielen. De scan van de omgeving kunnen we gemakkelijk realiseren via

de geınstalleerde LRF.

In een eerste stap moeten we dus Gonzales dergelijke databestanden laten genereren. Deze

bestanden kunnen we dan gebruiken om de aangepaste implementatie te testen. We maken

hiervoor gebruik van de manuele aansturing zoals deze in sectie 2.3.2 besproken is. Hiermee

kan de gebruiker Gonzales manueel besturen terwijl deze de nodige databestanden aanmaakt.

Na elke sessie hebben we dan een databestand dat bestaat uit een opeenvolging van datasets.

Zo’n dataset ziet er typisch als volgt uit:

...

Odometry x y theta

Laser 726 P1 P2 P3 ... P726

...

De eerste regel bevat de geschatte verplaatsing van Gonzales (afgeleid uit de encoders). Hier

staan x en y voor de geschatte translatie in de x- en y-richting uitgedrukt in meter en theta

voor de rotatie rondom de z-as uitgedrukt in radialen. De tweede regel bestaat uit 726

datapunten die samen de scan van de omgeving voorstellen. Deze datapunten stellen de

afstand voor van de robot, of beter de LRF, tot zijn omgeving uitgedrukt in meter. Ter

illustratie zijn in figuur 3.2 een aantal van deze scans gevisualiseerd.

Figuur 3.2: Enkele voorbeelden van scans gemaakt met de LRF, de rode stip in het midden stelt

Gonzales’ positie voor.

Hoofdstuk 3. Positiebepaling 20

3.3.2 Hardware & geometrie

We hebben nu na elke sessie een databestand dat we in principe als invoer voor het algoritme

zouden kunnen gebruiken. Door het verschil in hardware en geometrie is de informatie vervat

in de databestanden van Gonzales echter verschillend van deze in de databestanden gegene-

reerd door ATRV-Junior. Dit verschil is te wijten aan de LRF en zijn positie op de robot, zie

tabel 3.1.

Tabel 3.1: De belangrijkste verschillen tussen Gonzales en ATRV-Junior.

Gonzales ATRV-Junior

Positie LRF centraal vooraan

Bereik LRF 240◦ 180◦

Aantal datapunten 726 181

De gebruikte LRF op Gonzales heeft dus een ruimer bereik alsook een hogere resolutie dan

deze op ATRV-Junior. Ook de positie op de robot is verschillend waardoor beide robots hun

omgeving anders zien. Bij Gonzales is de LRF centraal opgesteld waardoor deze samenvalt

met het rotatiemiddelpunt van de robot terwijl deze bij ATRV-Junior vooraan staat en dus

niet op het rotatiemiddelpunt. Bij pure rotatie zal dus bij Gonzales de LRF ook enkel roteren

terwijl bij ATRV-Junior de LRF naast rotatie ook een translatie uitvoert.

Nu moet het positiebepalingssysteem de positie van (het centrum van) de robot bepalen

en niet deze van de LRF. In de beschikbare implementatie moest dus eerst de geschatte

verplaatsing van de LRF afgeleid worden uit de geschatte verplaatsing van de robot. Deze

informatie kon dan door het algoritme verwerkt worden om de werkelijke positie van de LRF

te bepalen. Op basis hiervan werd dan opnieuw de positie van de robot bepaald. Voor

Gonzales kan dit vereenvoudigd worden, we kunnen hier gewoon werken met de verplaatsing

van de LRF.

3.3.3 Aandrijving

Het grootste verschil tussen Gonzales en ATRV-Junior ligt in de mogelijke bewegingsvrijhe-

den. Zo kan ATRV-Junior zich enkel voor- en achterwaarts verplaatsen volgens een rechte

of gebogen lijn, terwijl Gonzales zich in eender welke richting kan verplaatsen. Nu is de be-

schikbare implementatie enkel voorzien op deze beperkte bewegingsvrijheden en kan deze niet

omgaan met het rijgedrag van Gonzales. Het algoritme zal namelijk de geschatte verplaatsing

vertalen naar een verplaatsing volgens de hoofdrichting, een kleine zijwaartse afwijking en een

wijziging van de orientatie van de robot (rotatie rondom de z-as). Voor gebruik op ATRV-

Junior gaat het algoritme a priori uit van een hoofdrichting volgens de voor- of achterwaartse

Hoofdstuk 3. Positiebepaling 21

bewegingsrichting en zal een zijwaartse afwijking ontstaan wanneer deze een bocht maakt.

Aangezien Gonzales zich echter in elke richting kan verplaatsen komt deze hoofdrichting slechts

in bepaalde gevallen overeen met de logische voor- of achterwaartse bewegingsrichting. We

moeten het algoritme dus uitbreiden om hiermee rekening te houden. Hiervoor moeten we

uit de informatie omtrent de geschatte verplaatsing van Gonzales eerst deze hoofdrichting

afleiden. Eenmaal we deze bepaald hebben kunnen we dan de geschatte verplaatsing vertalen

naar een verplaatsing volgens deze hoofdrichting, een zijwaartse afwijking en een gewijzigde

orientatie. Deze informatie kan dan wel door het algoritme verwerkt worden om de resulte-

rende positie te bepalen.

3.3.4 Realtime

We hebben nu een bruikbare implementatie die databestanden, gegenereerd door Gonzales,

kan verwerken. De volgende stap is om deze implementatie aan te passen zodat we deze kun-

nen uitvoeren terwijl Gonzales zich verplaatst, we willen deze dus uitvoeren in realtime. Waar

via de manuele besturing eerst databestanden aangemaakt werden die dan door het algoritme

werden ingelezen moeten we nu de nodige informatie doorgeven tijdens het aansturen van de

robot. Op die manier kunnen we de positie bepalen terwijl Gonzales zich verplaatst.

We beschikken dus enerzijds reeds over een regelaar waarbij we manueel stuursignalen gene-

reren en anderzijds over een werkend positiebepalingssysteem. We combineren nu deze twee

delen tot een geheel door gebruik te maken van twee parallelle processen. In het hoofdproces

worden eerst alle communicatiekanalen geınitialiseerd waarna een zijproces wordt gecreeerd

voor het ontwikkelde DP-SLAM algoritme. Dit proces vraagt herhaaldelijk de nodige invoer-

data op via het hoofdproces en geeft op zijn beurt de exacte locatie van Gonzales terug.

Bij deze realtime implementatie behouden we echter wel de optie om databestanden te kunnen

verwerken. We zullen ook steeds tijdens elke sessie deze databestanden blijven aanmaken. Zo

kunnen we op een later tijdstip deze data nog analyseren en mogelijks herevalueren indien we

nog verdere aanpassingen maken aan het positiebepalingssysteem.

3.3.5 Hierarchische structuur

Zoals in de structuur van het algoritme is uiteengezet wordt er gebruik gemaakt van twee

hierarchische niveaus. Na een aantal iteraties op het lage niveau wordt de hier opgebouwde

kaart doorgegeven naar het hoger niveau waar deze in het groter geheel gepast wordt. Hierna

begint het lage niveau opnieuw van nul en dit blijft zich dan herhalen. Beide niveaus doen

dus eigenlijk exact hetzelfde, maar op een andere schaal.

Deze indeling in verschillende niveaus heeft echter enkele grote nadelen. Na elke iteratie

op het hoge niveau moet het lage niveau opnieuw van nul beginnen waarbij alle informatie

Hoofdstuk 3. Positiebepaling 22

over de huidige positie verloren gaat. Pas nadat de informatie overgedragen is naar het

hoge niveau kan het gevolgde traject gereconstrueerd worden. Verder zorgt deze uitwisseling

van informatie tussen beide niveaus voor een opmerkelijke vertraging van het geheel. Dit is

uiteraard niet wenselijk voor het positiebepalingssysteem dat we willen gebruiken. We kiezen

er dus voor om de opdeling in verschillende niveaus af te schaffen. Aangezien beide niveaus

exact het zelfde doen kunnen we hier gewoon het hoge niveau uitschakelen en enkel met het

lage niveau werken waarin dan alles op een continue manier gebeurt.

3.3.6 Gevolgde traject

Een laatste kleine aanpassing die gemaakt wordt, is het opslaan van het gevolgde traject. De

hierboven gerealiseerde versie houdt wel degelijk alle informatie over de omgeving bij maar

gebruikt enkel de vorige positie om de nieuwe positie te bepalen. Het is dus niet mogelijk

om het gevolgde traject te raadplegen of te visualiseren. Het kan echter wel wenselijk zijn

enerzijds voor de regelaar die we willen ontwikkelen, maar anderzijds ook voor de gebruiker

om het gevolgde traject te analyseren.

Deze laatste uitbreiding voorziet dus de nodige geheugenruimte om het gevolgde traject bij

te houden. Deze wordt ook na elke sessie samen met een volledige kaart van de verkende

omgeving gevisualiseerd en weggeschreven naar .gif bestand (zie bijvoorbeeld figuur 3.3). We

voorzien verder nog de mogelijkheid om dit visualiseren niet enkel op het einde van de sessie

te laten gebeuren, maar ook herhaaldelijk na een instelbaar aantal iteraties. Op die manier

hoeft de gebruiker niet te wachten tot het einde van de sessie om de resultaten te analyseren.

Figuur 3.3: Voorbeeld van de visualisatie van kaart en traject. De doorloopzin van het traject is

aan de hand van een graduele kleurcode kenbaar gemaakt, groen voor het begin en rood

voor het einde.

Hoofdstuk 3. Positiebepaling 23

3.4 Bespreking eindresultaat

We hebben nu via een aantal stappen de beschikbare implementatie aangepast. Het resultaat

is een realtime positiebepalingssysteem dat de exacte positie van Gonzales kan bepalen terwijl

deze zich verplaatst. Een grondige bespreking van de behaalde resultaten wordt in hoofdstuk 6

gegeven, maar we maken hier reeds een kleine bemerking. De gerealiseerde implementatie

levert wel zeer nauwkeurige resultaten op, maar ze is behoorlijk rekenintensief. Hedendaagse

computers hebben hier uiteraard geen probleem mee, maar de geınstalleerde hardware op

Gonzales is sterk beperkt in rekencapaciteit. Waar een iteratie van het algoritme maximum

0, 5 s in beslag neemt op een moderne computer duurt dit bij uitvoering op Gonzales gemiddeld

4 s. Hier moeten we uiteraard rekening mee houden bij het ontwikkelen van de regelaar.

Hoofdstuk 4

Regelaars

De regelaar die we in dit hoofdstuk willen ontwikkelen moet in staat zijn stuursignalen te

genereren op basis van de positie verkregen uit het positiebepalingssysteem. Deze stuursig-

nalen moeten ervoor zorgen dat Gonzales het gewenste traject zo nauwkeurig mogelijk volgt.

Hierbij moet de regelaar zich niet alleen baseren op het gewenste traject en de huidige positie,

maar moet deze ook rekening houden met allerlei externe invloeden die mogelijks het rijge-

drag van Gonzales kunnen beınvloeden. Enkele van deze externe invloeden zijn bijvoorbeeld

onregelmatigheden van het rijoppervlak, slijtage van de wielen, een lokaal wijzigende grip. . .

Een dergelijke regelaar kunnen we uiteraard niet in een keer ontwikkelen. Zoals bij het

aanpassen van het positiebepalingssysteem worden ook hier een aantal stappen doorlopen om

uiteindelijk de gewenste regelaar te realiseren. We vertrekken van de meest eenvoudige vorm

waarbij we dan systematisch de tekortkomingen aankaarten en deze aanpakken in een volgende

versie. Op die manier kunnen we elk van deze tekortkomingen afzonderlijk analyseren om tot

de optimale oplossing te komen. In wat volgt gaan we dieper in op elk van de doorlopen

tussenstappen. Voor de bekomen resultaten van elke stap verwijzen we naar hoofdstuk 6.

4.1 Regelaar I: Een klassieke aanpak

We kunnen reeds stuursignalen genereren op basis van de gewenste beweging (zie sectie 2.3.2).

Hierbij is het de gebruiker zelf die bepaalt hoe Gonzales zich moet verplaatsen. Wat we

echter willen is de gewenste beweging afleiden uit het te volgen traject. Hiervoor moeten we

natuurlijk wel eerst dit te volgen traject specificeren.

4.1.1 Het traject

Om het te volgen traject vast te leggen maken we gebruik van een extra invoerkanaal. Dit

doen we door een reeks instructies in een tekstbestand op te slaan en deze als invoer mee te

geven bij het starten van een sessie. Hierbij bestaat elke instructie uit de gewenste verplaatsing

24

Hoofdstuk 4. Regelaars 25

in de drie vrijheidsgraden voorafgegaan door het kenwoord Drive. De gebruikte eenheden zijn

cm en graden. Zo’n instructiebestand zou er dus bijvoorbeeld als volgt uit kunnen zien:

Drive 50 0 0

Drive 0 50 0

Drive -50 0 0

Drive 0 -50 0

Drive 0 0 180

Hiermee zouden we Gonzales in een vierkant met zijde 50 cm willen laten rijden om erna 180◦

rond zijn as te draaien. Merk op dat deze instructies gebaseerd zijn op het vaste assenstelsel

verbonden aan de omgeving zoals het in sectie 1.1 is gedefinieerd. In dit geval zou Gonzales dus

eerst 50 cm voorwaarts moeten rijden, vervolgens 50 cm naar links, erna 50 cm achterwaarts

en 50 cm naar rechts en ten slotte 180◦ draaien. Indien we het laatste commando echter eerst

hadden geplaatst zou Gonzales nog steeds volgens hetzelfde vierkant moeten rijden, maar zou

hij eraan beginnen met een andere orientatie. Gonzales zou dan eerst 50 cm achterwaarts

moeten rijden in plaats van voorwaarts. We moeten deze instructies dus eerst vertalen naar

het assenstelsel verbonden aan Gonzales vooraleer we er de juiste stuursignalen uit kunnen

afleiden.

4.1.2 De regelaar

Zoals hierboven uiteengezet werd gebruiken we een reeks instructies als invoer. Deze leggen

het te volgen traject ondubbelzinnig vast. Zo komt elke instructie eigenlijk overeen met een

bepaalde positie die Gonzales moet bereiken langsheen het traject. We willen dus nu dat

de regelaar de stuursignalen genereert die ervoor zorgen dat Gonzales zich naar deze posities

begeeft. Eenmaal hij dan bij de eerste positie is aangekomen moet hij zich naar de volgende

begeven net zolang tot alle instructies doorlopen zijn. En dit natuurlijk via de optimale route,

dit wil zeggen volgens het kortst mogelijke pad.

De meest eenvoudige manier om dit gedrag te realiseren is om de gewenste positie te verge-

lijken met de huidige positie. Uit het verschil halen we dan de nodige verplaatsing waaruit

we de gewenste bewegingsrichting kunnen afleiden. Deze bewegingsrichting moeten we dan

vertalen naar het assenstelsel verbonden aan Gonzales waarna we met behulp van het opge-

stelde kinematisch model de vier stuursignalen kunnen genereren (zie hiervoor sectie 2.2.2).

Gonzales’ resulterende verplaatsing wordt dan verwerkt door het positiebepalingssysteem dat

de nieuwe positie bepaalt. Op basis van deze positie kunnen we dan nieuwe stuursignalen

genereren en dit gaat net zo lang door tot Gonzales zijn eindbestemming bereikt. Schematisch

kan dit regelprincipe voorgesteld worden door figuur 4.1. Het superfix w duidt hier aan dat

het om een wenswaarde gaat.

Hoofdstuk 4. Regelaars 26

Figuur 4.1: Schematische voorstelling van het regelprincipe van regelaar I.

Voor het bepalen van de stuursignalen gebruiken we eigenlijk niet rechtstreeks het kinematisch

model, maar werken we via een kleine omweg. We splitsen eerst de gewenste beweging op

in een translatie en een rotatie. De gewenste translatierichting stellen we voor door een

eenheidsvector in het xy-vlak. Deze eenheidsvector stelt dan de genormeerde snelheid in x-

en y-richting voor. Ook de rotatie normeren we tot ±1. Vervolgens superponeren we de

drie bewegingsmodi waarbij we de rotatie slechts voor de helft laten doorwegen (dit om een

vlotter rijgedrag te krijgen). De bekomen stuursignalen schalen we dan achteraf met een

vaste schaalfactor afhankelijk van de ingestelde snelheid zoals dit bij de manuele aansturing

het geval was (zie sectie 2.3.2). We gebruiken de formules 2.3 dus in een licht gewijzigde vorm:

ω1 = v(vf − vs −ω

2) (4.1a)

ω2 = v(vf + vs +ω

2) (4.1b)

ω3 = v(vf + vs −ω

2) (4.1c)

ω4 = v(vf − vs +ω

2) (4.1d)

Hierbij stellen vf , vs en ω de genormeerde snelheden voor in de drie bewegingsvrijheden en v

de vooraf ingestelde rotatiesnelheid van de wielen (nog steeds standaard ingesteld op 6 tpm).

Merk op dat deze genormeerde snelheden uiteraard ook 0 kunnen zijn indien er enkel nood is

aan translatie of rotatie.

De nood aan translatie en/of rotatie wordt in deze toepassing bepaald aan de hand van twee

verschillende drempelwaarden, een eerste voor de translatie en een tweede voor de rotatie.

Deze drempelwaarden gebruiken we ook om het bereiken van een gewenste positie te karak-

teriseren. Pas indien de afstand tot de gewenste positie onder beide drempelwaarden ligt,

beschouwen we deze positie als bereikt en kan de volgende instructie worden ingelezen. Beide

Hoofdstuk 4. Regelaars 27

drempelwaarden worden ingesteld op 75 % van de gemiddelde verplaatsing tijdens een ite-

ratie van het positiebepalingssysteem. Deze gemiddelde verplaatsing bekomen we door de

ingestelde translatie- en rotatiesnelheid (zie sectie 2.3.2) te vermenigvuldigen met de gemid-

delde tijdsduur van een iteratie, deze bedraagt ongeveer 4 s.

Bij het opstellen van deze regelaar baseren we ons dus op een louter theoretisch model en dit

kan natuurlijk in een bepaalde mate afwijken van de werkelijke uitvoering. In een volgende

stap proberen we op dit vlak verbetering aan te brengen.

4.2 Regelaar II: CMA-ES

Deze regelaar werkt volgens exact het zelfde principe als regelaar I en verschilt slechts op een

enkel punt: het kinematisch model (zie ook figuur 4.2). Een nadeel aan de vorige regelaar is

namelijk dat deze op een puur theoretische basis is opgesteld en dus in zekere mate afwijkt

van de realiteit. Hierdoor zullen de gegenereerde stuurcommando’s niet altijd resulteren in

de verwachte verplaatsingen, maar kan een zekere fout optreden.

Figuur 4.2: Schematische voorstelling van het regelprincipe van regelaar II.

In deze tweede regelaar proberen we het model beter af te stemmen op de werkelijke uitvoering.

Hierdoor kunnen we met onregelmatigheden en afwijkingen in de geometrie rekening houden

en deze opnemen in een aangepast model. De methode die we hiervoor toepassen is gebaseerd

op CMA-ES of voluit covariantie-matrix adaptatie evolutionaire strategie. Het opstellen van

het aangepaste model aan de hand van deze methode kadert in een samenwerkingsproject

met de Ruhr-Universiteit in Bochum, Duitsland. Meer specifiek vormt het een onderdeel van

de doctoraatscriptie van Verena Heidrich-Meisner. De hier gebruikte evolutionaire strategie

werd voorgesteld in Hansen et al. (1995), verder ontwikkeld in Hansen & Ostermeier (2001)

& Hansen et al. (2003) en op punt gesteld in Hansen & Auger (2005). We verwijzen dan ook

naar deze literatuur voor een gedetailleerde bespreking en beperken ons hier tot een korte

uiteenzetting van de toepassing ervan in deze situatie.

Hoofdstuk 4. Regelaars 28

4.2.1 CMA-ES leerstrategie

Wat we hier dus willen realiseren is een model dat beter voldoet aan de realiteit. We vertrekken

hiervoor van het reeds eerder opgestelde kinematisch model (zie sectie 2.2.2) maar voegen een

aantal variabele parameters toe. Om te beginnen voeren we vier wielspecifieke correcties in.

Dit vertaalt zich in een extra additieve term in elk van de formules 4.1. Verder worden ook

twee multiplicatieve termen toegevoegd bij de gebruikte drempelwaarden. Deze hebben geen

invloed op het model maar kunnen wel het algemeen rijgedrag verbeteren. In het originele

model zouden de vier additieve parameters dus 0 zijn en de twee multiplicatieve gelijk aan 1.

Om nu tot de optimale waarden voor deze parameters te komen vertrekken we van 6 combi-

naties waarin we aan elke parameter een willekeurige waarde toekennen. Deze 6 combinaties

duiden we aan als de eerste generatie. We evalueren nu elk van deze combinaties en selecteren

er de drie beste uit (de gebruikte testprocedure bespreken we uitvoerig in hoofdstuk 6). Op

basis van de drie best presterende combinaties genereren we nu 6 nieuwe combinaties, die

we samen als de tweede generatie aanduiden. Ook deze worden dan geevalueerd om er op-

nieuw de drie beste uit te selecteren. Dit proces blijven we nu uitvoeren totdat na een aantal

generaties er geen merkbare verbetering meer optreedt.

Dit leerproces voeren we zowel uit in een simulatieomgeving als in de praktijk, voor de re-

sultaten ervan verwijzen we opnieuw naar hoofdstuk 6. We merken nu echter reeds op dat

met deze methode nauwelijks tot geen verbetering gerealiseerd wordt. De grootste oorzaak

hiervoor is het reeds eerder aangehaalde probleem met betrekking tot de tijdsduur van het

positiebepalingssysteem (zie sectie 3.4). We werken dit verder uit in een volgende regelaar.

4.3 Regelaar III: Tijdsvertragingen

4.3.1 Situatieschets

Om het probleem verbonden aan de de tijdsduur van het positiebepalingssysteem te verdui-

delijken beschouwen we de verschillende fases die doorlopen worden in het positiebepalings-

systeem en de regelaar:

� positiebepalingssysteem

1. Haal nieuwe informatie uit sensoren op

2. Schat de nieuwe positie

3. Bepaal de exacte nieuwe positie

� Regelaar

1. Wacht op positie-informatie

Hoofdstuk 4. Regelaars 29

2. Bepaal de afstand tot de gewenste positie

3. Vergelijk deze afstand met de drempelwaarden

4. Genereer de vier stuursignalen

Dit blijft zich dus herhalen totdat de gewenste positie bereikt is. Indien we deze twee parallelle

processen nu op een tijdsas zouden voorstellen krijgen we figuur 4.3. We kunnen hier bij de

regelaar duidelijk twee delen in onderscheiden: het wachten op informatie en het verwerken

ervan. We moeten hier echter benadrukken dat de positie die de regelaar binnenkrijgt eigenlijk

de positie is waar Gonzales zich bevond tijdens fase 1 van het positiebepalingssysteem. Zoals

reeds eerder opgemerkt in sectie 3.4 neemt een iteratie van het positiebepalingssysteem een

tijd in van ongeveer 4 s. De regelaar bepaalt dus zijn stuursignalen eigenlijk op basis van de

positie waar hij zich enkele seconden geleden bevond. We kunnen dan ook niet verwachten

dat deze stuursignalen zullen resulteren in het gewenste rijgedrag.

Figuur 4.3: Voorstelling van het tijdsverloop volgens regelaars I & II.

Verder ondervindt ook het bereiken van de eindbestemming hier hinder van. Indien Gonzales

namelijk zijn eindbestemming bereikt zal hij zich dit pas enkele seconden later realiseren. Op

dat moment is hij er echter reeds voorbijgereden en moet hij terugkeren. Dit kan dus de

oorzaak zijn van een oscillerend rijgedrag rondom de gewenste positie. Dit probleem zullen

we nu aanpakken in deze regelaar.

4.3.2 De regelaar

Beide vorige regelaars zijn dus beperkt in hun nauwkeurigheid door de tijdsvertraging tussen

het bereiken van een bepaalde positie en het bepalen ervan (zie ∆t in figuur 4.3). Om het

gewenste rijgedrag te kunnen realiseren moeten we de positie van Gonzales kennen op het

Hoofdstuk 4. Regelaars 30

moment dat we de stuursignalen genereren. Enkel deze exacte positie laat ons toe om de

juiste aansturing van de wielen te verkrijgen. Zoals hierboven vermeld duurt het echter te

lang om de exacte positie te bepalen en kunnen we deze dus eigenlijk niet gebruiken voor het

bepalen van de stuursignalen.

Als eerste oplossing hiervoor zouden we de gekende verplaatsing van Gonzales tijdens de

vorige tijdstap kunnen extrapoleren om de huidige positie te bekomen. Dit houdt echter geen

rekening met wijzigende stuursignalen. Beter is het om deze stuursignalen te vertalen naar

een verwachte verplaatsing en deze te superponeren op de laatst gekende positie. Hiervoor

moeten we dan wel de duur van een iteratie op voorhand kennen. Via het kinematisch model

vertalen we namelijk de stuursignalen, of dus de verwachte rotatiesnelheden van de vier wielen,

naar de bewegingssnelheden van Gonzales (zie sectie 2.2.2). Om hier dan een verplaatsing

uit te halen moeten we weten hoe lang Gonzales zich aan deze snelheid voortbeweegt. Het

probleem is nu dat deze tijdsduur geen constante is. Dit maakt het dus onmogelijk om een

goede schatting te maken van de huidige positie van Gonzales.

Wat we wel kunnen doen is de informatie uit de encoders gebruiken in plaats van de stuur-

signalen. Deze encoders geven niet de rotatiesnelheid, maar de hoek waarover elk wiel is

geroteerd. Via het kinematisch model kunnen we dan deze rotatie van de vier wielen vertalen

naar de verplaatsing van Gonzales. Dit is trouwens ook wat toegepast wordt in fase 2 van het

positiebepalingssysteem. Deze methode is dus niet afhankelijk van de variabele tijdsduur en

zoals reeds te zien was op figuur 4.3 is deze informatie reeds veel vroeger beschikbaar dan de

exacte positie. Indien we dit toepassen krijgen we een tijdsvoorstelling zoals deze in figuur 4.4

is geıllustreerd. Hier is dus de vertraging ∆t veel kleiner dan bij de vorige regelaars. Een

schematische voorstelling van de regelstructuur van deze regelaar is te zien in figuur 4.5.

We verwachten nu met deze methode een grote verbetering van de nauwkeurigheid van de

trajectcontrole te realiseren, wat bevestigd wordt bij de bespreking van de behaalde resultaten

in hoofdstuk 6. Optimaal is de regelaar echter nog niet. We werken namelijk met een schatting

van de huidige positie. Deze is verschillend van de werkelijke positie waardoor we nog steeds

fouten krijgen in de stuursignalen. Deze fouten zijn weliswaar veel kleiner dan in de vorige

regelaars, maar we kunnen ze niet verder reduceren. Ook fouten afkomstig van het verschil

tussen het theoretisch model en de werkelijke uitvoering kunnen we momenteel nog niet

corrigeren. Hier kunnen we echter wel iets aan doen en dit zullen we in de volgende regelaar

uitwerken.

Hoofdstuk 4. Regelaars 31

Figuur 4.4: Voorstelling van het tijdsverloop volgens regelaar III.

Figuur 4.5: Schematische voorstelling van het regelprincipe van regelaar III.

4.4 Regelaar IV: Foutcorrecties

Zoals hierboven aangehaald werd, is het in de vorige regelaars nog niet mogelijk om foutieve

stuursignalen te detecteren en bij te sturen. De enige regellus die in de vorige regelaars

aanwezig is levert ons enkel de gewenste rijrichting op basis van de gewenste positie. Uit deze

rijrichting halen we dan via het kinematisch model de stuursignalen (zie sectie 2.2.2), maar

een controle en/of bijsturing van deze stuursignalen is er dus nog niet.

In deze regelaar zullen we nu een extra regellus invoeren die instaat voor het corrigeren van

de stuursignalen indien nodig. We realiseren dit door niet enkel de gewenste positie met de

werkelijke te vergelijken, maar door ook de gewenste rijrichting, die uit de eerste regellus volgt,

te vergelijken met de werkelijke rijrichting. De afwijking ertussen kunnen we dan gebruiken als

Hoofdstuk 4. Regelaars 32

maat voor het correctiesignaal. Figuur 4.6 toont aan hoe dit zich vertaalt in de schematische

voorstelling.

Figuur 4.6: Schematische voorstelling van het regelprincipe van regelaar IV.

Om deze foutcorrectie mogelijk te maken moeten we dus wel de werkelijke rijrichting kennen.

Aangezien we het gevolgde traject bijhouden (zie sectie 3.3.6) zouden we gewoon de rijrichting

uit de laatste iteratie kunnen gebruiken. Dit gaat echter niet aangezien we door de tijdsver-

traging dan eigenlijk de werkelijke rijrichting uit de vorige tijdstap zouden gebruiken en niet

de huidige. Dit kunnen we oplossen door opnieuw gebruik te maken van de informatie uit de

encoders en met een schatting van de huidige rijrichting te werken. De informatie die we uit

de encoders krijgen is echter de afgelegde weg. Deze is natuurlijk afhankelijk van de tijdsduur

van de beschouwde iteratie. Om dit in rekening te brengen houden we de tijdsduur van elke

iteratie bij. We kunnen dan uit de geschatte afgelegde weg en de overeenkomstige tijdsduur

de geschatte verplaatsingssnelheid van Gonzales bepalen. Deze kunnen we vergelijken met de

gewenste verplaatsingssnelheid en het verschil is dan een maat voor de nodige correcties op

de stuursignalen.

Nu hebben we dus een regelaar die correctere stuursignalen genereert en deze indien nodig

nog verder bijstuurt. We zouden nu dus in staat moeten zijn Gonzales volgens de gewenste

rijrichting naar zijn eindpositie te laten rijden. Het bereiken van deze eindpositie wordt dan

gekenmerkt door het overschrijden van twee drempelwaarden zoals dit in regelaar I uiteengezet

werd (zie sectie 4.1.2).

Aangezien we een vast ingestelde rotatiesnelheid gebruiken (zie sectie 2.3.2) zal Gonzales zich

in elke stap steeds over een minimale afstand verplaatsen. Nu zal echter in de laatste stap

de resterende afstand tot de eindbestemming meestal verschillend zijn van deze minimale

afstand. Gonzales kan dus de exacte eindpositie eigenlijk niet bereiken en hierdoor moeten

we de drempelwaarden behoorlijk ruim instellen. Er zal dus steeds een blijvende fout zijn

tussen Gonzales’ positie en de gewenste eindpositie. Deze fout kan varieren tussen nul en de

ingestelde drempelwaarden. Dit willen we nu verbeteren in een volgende en laatste regelaar.

Hoofdstuk 4. Regelaars 33

4.5 Regelaar V: Variabele snelheid

De aanpassing die we in deze regelaar invoeren heeft dus als doel Gonzales dichter bij zijn

eindbestemming te laten eindigen. Hiervoor maken we gebruik van een variabele snelheid. De

waarde van deze snelheid zullen we afleiden uit Gonzales’ huidige positie en de beschouwde

eindbestemming.

Praktisch realiseren we dit door in elke stap de resterende afstand tot de gewenste positie te

vergelijken met de afstand die Gonzales in een iteratie van gemiddelde duur aflegt. Zolang de

afstand tot de gewenste positie groter is, behouden we de vaste ingestelde snelheid. Indien de

resterende afstand echter kleiner is, passen we de ingestelde snelheid aan. We doen dit door

de snelheid te herschalen volgens de verhouding van de resterende afstand tot de gemiddelde

afstand.

Aangezien we twee afzonderlijke drempelwaarden gebruiken voor het bereiken van de eindpo-

sitie voeren we hier ook twee afzonderlijke schaalfactoren in, een voor de translatiesnelheid en

een voor de rotatiesnelheid. Dit komt er dus op neer dat we de formules 4.1 in een aangepaste

vorm toepassen:

ω1 = v(ft(vf − vs)− frω

2) (4.2a)

ω2 = v(ft(vf + vs) + frω

2) (4.2b)

ω3 = v(ft(vf + vs)− frω

2) (4.2c)

ω4 = v(ft(vf − vs) + frω

2) (4.2d)

Hierbij zijn ft respectievelijk fr de ingevoerde schaalfactoren voor de translatie- respectievelijk

de rotatiesnelheid. Schematisch gezien blijft het regelprincipe dus hetzelfde als dat van de

vorige regelaar (zie figuur 4.6), maar het gebruikte model laat nu variabele snelheden toe.

Hierdoor zou Gonzales theoretisch gezien exact op zijn eindpositie moeten eindigen na de

laatste stap. Door de variabele tijdsduur van een stap verwachten we echter nog steeds een

blijvende fout die echter wel een stuk kleiner is dan bij de vorige regelaars. Dit wordt opnieuw

bevestigd door de behaalde resultaten besproken in hoofdstuk 6).

Doordat we nu Gonzales dichter bij zijn eindbestemming kunnen laten eindigen kunnen we

ook de gebruikte drempelwaarden sterk verlagen. Waar deze 75 % van de gemiddelde afstand

in een iteratie bedroeg bij voorgaande regelaars kunnen we deze hier verlagen tot twee maal

de minimale afstand in een iteratie. Deze minimale afstand halen we uit de minimale ver-

plaatsingssnelheid die op zich volgt uit de minimale rotatiesnelheid van de wielen, namelijk

1 tpm.

Hoofdstuk 4. Regelaars 34

4.6 Overzicht

In het voorgaande hebben we nu een vijftal regelaars ontwikkeld uitgaande van het meest

eenvoudige regelprincipe om dan systematisch via structurele verbeteringen tot een optimaal

eindresultaat te komen. We overlopen hier nog eens kort wat we gerealiseerd hebben.

Regelaar I vormt de fundering waarop alle volgende regelaars gebaseerd zijn. Deze gaat

enkel uit van de positie-informatie verkregen van het positiebepalingssysteem en het kine-

matisch model dat Gonzales’ bewegingen beschrijft. Dit model is op een puur theoretische

wijze opgesteld en we verwachten dus afwijkingen tegenover de realiteit. Hiervoor werd een

tweede regelaar ontwikkeld, regelaar II, die enkel op vlak van dit theoretische model verschilt

van regelaar I. Aan de hand van een evolutionaire leerstrategie (CMA-ES ) werd het model

afgestemd op de werkelijke uitvoering van Gonzales.

Hiermee werd echter geen verbetering gehaald. De reden hiervoor is dat door de tijdsvertra-

gingen in het positiebepalingssysteem de verkregen positie-informatie te laat beschikbaar is

in de regelaar. Hierdoor worden foutieve stuursignalen gegenereerd. Om hiermee rekening

te houden werd regelaar III gerealiseerd. Deze gebruikt iets minder accurate informatie die

echter wel op tijd beschikbaar is.

Om vervolgens verdere afwijkingen in de aansturing te kunnen detecteren en bijsturen ont-

wikkelden we regelaar IV. Deze beschikt over een extra regellus die naast de positiecontrole

ook bewegingscontrole uitvoert. Hierbij wordt indien nodig het model aangepast om toch de

juiste stuursignalen te verzekeren. In een laatste stap ten slotte voegden we de mogelijkheid

toe om een variabele snelheid te gebruiken in de aansturing om Gonzales dichter bij zijn

einddoel te laten eindigen.

De evolutie doorheen de verschillende regelaars kunnen we dus eigenlijk kenmerken aan de

hand van drie aspecten: de verhouding theorie vs realiteit, de aanpak van tijdsvertraging en

het niveau van de regelstructuur. Het eerste en laatste aspect kunnen we echter niet los van

elkaar beschouwen. In regelaars IV en V wordt namelijk in de regeling een aanpassing van

het model gerealiseerd. Het niveau van de regelstructuur heeft dus een zekere invloed op de

verhouding theorie vs realiteit. Tabel 4.1 geeft een overzicht van de verschillende regelaars

waarbij de drie beschouwde aspecten geevalueerd worden.

Voor de behaalde resultaten van elk van de regelaars verwijzen we naar hoofdstuk 6.

Hoofdstuk 4. Regelaars 35

Tabel 4.1: Een overzicht van de verschillende regelaars.

Regelaar Theorie vs realiteit Aanpak ∆t Regelniveau

Regelaar I * X *

Regelaar II ** X *

Regelaar III * V *

Regelaar IV *** V **

Regelaar V *** V ***

Hoofdstuk 5

Hoe te gebruiken

5.1 Verbinden met Gonzales

Vooraleer we iets kunnen uitvoeren op Gonzales moeten we eerst een verbinding opstellen

tussen de computer van de gebruiker en de computer op Gonzales. Dit doen we via het

Secure Shell protocol of SSH protocol.

Eenmaal aangemeld kunnen we dan naar de startlocatie1 navigeren waar de ontwikkelde

programmabestanden zich bevinden (de volledige programmacode is ook opgenomen in bij-

lage A). Vanuit deze locatie kunnen we het gewenste programma uitvoeren. Dit is ook de

locatie waar alle in- of uitvoer bestanden staan.

5.2 Indeling

Om het positiebepalingssysteem samen met een van de hierboven besproken regelaars te ge-

bruiken moet de gebruiker het corresponderende programma uitvoeren. Voor elke regelaar is

een apart hoofdbestand aangemaakt dat het regel-gedeelte bevat. Het positiebepalingssys-

teem en de communicatiestructuren zijn voor alle regelaars hetzelfde en de overige program-

mabestanden zijn dan ook gedeeld. Om het overzicht te bewaren worden de programmabe-

standen volgens hun hoofddoel opgedeeld in drie categorieen en in een overeenkomstige map

geplaatst:

/Slam In deze map bevinden zich de bestanden die deel uitmaken van het positiebepalings-

systeem.

/Robot Hierin zitten alle programmabestanden die instaan voor de communicatie tussen en

aansturing van de verschillende hardware onderdelen van de robot (computer, micro-

controllers, sensoren & motoren).

1/home/gonzales/Robot/Controller

36

Hoofdstuk 5. Hoe te gebruiken 37

Hoofdbestand De regelaar zelf is uitgevoerd in een enkel bestand dat tevens het hoofdbe-

stand van het geheel vormt. Voor elke regelaar is dus een verschillend hoofdbestand

aangemaakt en het is dit bestand dat de gebruiker moet uitvoeren. Deze bestanden be-

vinden zich niet in een afzonderlijke map maar op de startlocatie waar ook beide vorige

mappen te vinden zijn. Tabel 5.1 bevat een overzicht van de verschillende regelaars en

bijhorende hoofdbestanden.

Tabel 5.1: De verschillende regelaars met bijhorend hoofdbestand.

Regelaar Hoofdbestand

Manuele aansturing Gonzales.cpp

Regelaar I Gonzales-I.cpp

Regelaar III Gonzales-III.cpp

Regelaar IV Gonzales-IV.cpp

Regelaar V Gonzales-V.cpp

De aandachtige lezer heeft waarschijnlijk opgemerkt dat regelaar II hier niet is opgenomen.

Regelaar II bevat naast het positiebepalingssysteem en de regelaar namelijk ook nog een extra

deel dat instaat voor het leerproces. Hiervoor zijn extra bestanden nodig die in geen enkele

overige regelaar gebruikt worden. Het leerproces voor deze regelaar is afzonderlijk gerealiseerd

met als enige doel het gebruikte theoretisch model in regelaar I meer op de werkelijkheid af

te stemmen. Het resultaat ervan, de zes parameters (zie sectie 4.2.1), kunnen we beoordelen

door deze parameters in regelaar I te verwerken en deze dan uit te voeren.

5.3 Uitvoering

Vooraleer we de gekozen regelaar kunnen uitvoeren moet deze eerst gecompileerd worden.

Aangezien er een verschillend hoofdbestand is voor elk van de regelaars zijn er ook verschil-

lende compilatiebestanden gecreeerd. Tabel 5.2 geeft een overzicht van het te gebruiken

commando voor het compileren van elk van de regelaars.

Nadat de regelaars gecompileerd zijn, kunnen deze eenvoudigweg uitgevoerd worden met de

commando’s uit tabel 5.3.

Bij de ontwikkelde regelaars zal Gonzales na het ingeven van dit commando het ingestelde

traject beginnen volgen en zal het programma beeindigd worden na het bereiken van de laatste

gewenste positie. Bij de manuele aansturing moet de gebruiker zelf de gewenste beweging

ingeven zoals reeds in sectie 2.3.2 is besproken. Om de manuele aansturing te beeindigen

moet de gebruiker de X-toets van het toetsenbord indrukken. Dit kan ook bij de regelaars

gebruikt worden om het programma te beeindigen nog voor het traject volledig is afgelegd.

Hoofdstuk 5. Hoe te gebruiken 38

Tabel 5.2: De verschillende compilatiebestanden en -commando’s voor de ontwikkelde regelaars.

Regelaar Commando

Manuele aansturing make

Regelaar I make -f Makefile-I

Regelaar III make -f Makefile-III

Regelaar IV make -f Makefile-IV

Regelaar V make -f Makefile-V

Tabel 5.3: De commando’s voor het uivoeren van de verschillende regelaars.

Regelaar Commando

Manuele aansturing ./Gonzales

Regelaar I ./Gonzales-I

Regelaar III ./Gonzales-III

Regelaar IV ./Gonzales-IV

Regelaar V ./Gonzales-V

5.4 Extra opties

Zoals reeds eerder vermeld zijn er een aantal opties die resulteren in een gewijzigde uitvoering

van de gekozen regelaar. We overlopen eerst de verschillende opties en leggen erna uit hoe we

deze kunnen selecteren.

Om te beginnen kunnen we er bijvoorbeeld voor kiezen om tijdens de uitvoering databestan-

den aan te maken die de nodige informatie bevatten voor het positiebepalingssysteem (zie

sectie 3.3.1). Logischerwijs kunnen we er dan ook voor kiezen dit positiebepalingssysteem af-

zonderlijk uit te voeren op basis van deze databestanden. Verder kunnen we ook de standaard

bewegingssnelheid (zie sectie 2.3.2) zelf instellen indien we willen dat Gonzales zich vlugger

of trager verplaatst dan de standaard snelheid.

Een andere optie die geen invloed heeft op de werking van de regelaar maar wel op de invoer

van het traject is de volgende. Indien we Gonzales niet manueel aansturen maar een vooraf

gedefinieerd traject willen gebruiken moeten we dit traject in een tekstbestand opslaan zoals in

sectie 4.1.1 is uiteengezet. Standaard wordt dit bestand drive.log genoemd en zal de regelaar

dit traject volgen. Het kan echter handig zijn om verschillende trajecten in afzonderlijke

bestanden op te slaan. Indien we dan een van deze andere invoerbestanden willen gebruiken

moeten we dit doorgeven aan de regelaar. Deze optie stelt de gebruiker dus in staat om

Gonzales verschillende trajecten te laten volgen zonder telkens het invoerbestand te moeten

Hoofdstuk 5. Hoe te gebruiken 39

aanpassen. Uiteraard is deze optie enkel beschikbaar bij de werkelijke regelaars (I tot en met

V) en niet bij de manuele aansturing.

Een laatste optie die geselecteerd kan worden laat ons toe de regelaar te evalueren. Indien

we de regelaar willen beoordelen op zijn nauwkeurigheid kunnen we deze uitvoeren in een

testmodus. In deze testmodus zal de regelaar extra informatie opslaan omtrent het gevolgde

traject en zal de uitvoering ook in zekere mate wijzigen. De testprocedure zelf wordt verder in

detail uiteengezet in sectie 6.2.1. We vermelden hier enkel het bestaan ervan. Deze testmodus

is opnieuw enkel beschikbaar bij de regelaars zelf.

Om nu een of meerdere van de besproken opties te activeren volstaat het om simpelweg een

of meerdere extra argumenten in te geven bij het uitvoeren van de regelaar. Tabel 5.4 geeft

een overzicht van de verschillende opties en de bijhorende argumenten.

Tabel 5.4: De te gebruiken argumenten voor het activeren van de extra opties.

Argument Resultaat

-R Data voor positiebepalingssysteem opslaan in current.log

-r bestandsnaam Data voor positiebepalingssysteem opslaan in bestandsnaam

-P positiebepalingssysteem uitvoeren op basis van current.log

-p bestandsnaam positiebepalingssysteem uitvoeren op basis van bestandsnaam

-x Referentie voor rotatiesnelheid van de wielen instellen op x tpm

(x stelt hier een getal voor gaande van 1 tot 10)

-D bestandsnaam Het te volgen traject inlezen uit bestandsnaam

-E De regelaar evalueren in testmodus

Deze opties kunnen gecombineerd worden en mogen in een willekeurige volgorde ingegeven

worden. Enkel de optie om het positiebepalingssysteem afzonderlijk uit te voeren vormt

hierop een uitzondering en kan niet gecombineerd worden met andere opties. Verder zijn

zoals vermeld de laatste twee opties enkel beschikbaar bij de regelaars zelf en niet bij de

manuele aansturing.

Hoofdstuk 6

Resultaten

In dit hoofdstuk bespreken we de behaalde resultaten van het positiebepalingssysteem en de

ontwikkelde regelaars. In een eerste sectie gaan we dieper in op het positiebepalingssysteem.

Hierbij zullen we de resultaten presenteren die volgen uit het positiebepalingssysteem terwijl

we Gonzales manueel aansturen (zie sectie 2.3.2). In een tweede sectie vervolgens bespreken we

het prestatieniveau van elk van de regelaars. We zetten hier eerst de gebruikte testprocedure

uiteen waarna we de resultaten van de ontwikkelde regelaars bespreken en vergelijken.

6.1 Het positiebepalingssysteem

Zoals uiteengezet in sectie 3.3 zijn een aantal stappen ondernomen om een werkend positiebe-

palingssysteem te ontwikkelen. We zullen hier niet het resultaat na elke stap bespreken maar

gaan enkel in op het eindresultaat.

Aangezien het ontwikkelde positiebepalingssysteem volledig onafhankelijk is van de manier

waarop Gonzales aangestuurd wordt kunnen we dezelfde nauwkeurigheid verwachten bij ge-

bruik van de regelaars als van de manuele aansturing. Zoals vermeld in de inleiding van dit

hoofdstuk zullen we hier dan ook enkel de resultaten bespreken die behaald werden met het

positiebepalingssysteem bij manuele aansturing van Gonzales.

6.1.1 Gebruik in een statische ruimte

In een eerste testfase stellen we Gonzales op in een bepaalde ruimte en laten we hem rondrijden

zodat hij min of meer de volledige ruimte gezien heeft. Hierbij letten we erop dat Gonzales

de ruimte niet verlaat. We zorgen er verder ook voor dat er geen bewegende voorwerpen

aanwezig zijn. Figuur 6.1 geeft een voorbeeld van het resultaat van deze testfase.

We geven zowel het eindresultaat als enkele tussenstappen weer. Zoals in sectie 3.3.6 uiteen-

gezet werd wordt op de kaart ook steeds het gevolgde traject gevisualiseerd. Om dit traject

40

Hoofdstuk 6. Resultaten 41

aanschouwelijker te maken gebruiken we hiervoor een graduele kleurcode. Het begin wordt

gekenmerkt door een groene kleur terwijl het einde (tot dan toe) in het rood wordt weer-

gegeven. Ertussenin wordt een graduele overgang toegepast. Om echter de figuur niet te

overladen geven we hier momenteel enkel de positie weer en niet de orientatie.

Figuur 6.1: Resultaat van het positiebepalingssysteem in een statische ruimte.

Zoals dus te zien is op figuur 6.1 krijgen we als eindresultaat een behoorlijk nauwkeurige kaart.

De nauwkeurigheid van deze kaart is een maat voor de precisie van de bepaalde positie. Op

de kaart is op bepaalde plaatsen wel enige ruis merkbaar, maar deze is tamelijk beperkt en

heeft dan ook slechts een minieme invloed op de nauwkeurigheid van de positiebepaling. We

wijzen er verder nog op dat het grillige verloop van het traject volstrekt normaal is aangezien

hier nog geen enkele regelstructuur gebruikt wordt.

Hoofdstuk 6. Resultaten 42

6.1.2 Gebruik in aangrenzende statische ruimtes

Na de eerste testfase waarin Gonzales zich steeds binnen eenzelfde ruimte bevond, testen we

nu het positiebepalingssysteem bij heen-en-weer verplaatsingen tussen aangrenzende ruimtes.

Hierbij werken we nog steeds in een statische omgeving waarbij geen bewegende voorwerpen

aanwezig zijn. Figuur 6.2 geeft het resultaat hiervan weer.

Figuur 6.2: Resultaat van het positiebepalingssysteem in aangrenzende ruimtes.

We krijgen opnieuw een zeer nauwkeurige kaart van beide ruimtes. Het gevolgde traject is

ook hier gevisualiseerd aan de hand van de besproken kleurcode. Het positiebepalingssysteem

heeft dus duidelijk geen moeite om op een correcte manier verschillende ruimtes in een groter

geheel te verwerken.

Hoofdstuk 6. Resultaten 43

6.1.3 Gebruik in een dynamische omgeving

In een derde en laatste fase testen we het positiebepalingssysteem in een dynamische om-

geving. In beide vorige testen waren geen bewegende voorwerpen aanwezig. In werkelijke

situaties echter verwachten we natuurlijk wel een of meerdere dynamische objecten. Om

dit aspect in rekening te brengen plaatsen we Gonzales in een omgeving waar ook meerdere

personen zich verplaatsen. Het resultaat is weergegeven in figuur 6.3.

Figuur 6.3: Resultaat van het positiebepalingssysteem in een dynamisch ruimte.

We zien op deze figuur hoe Gonzales zich beweegt en ondertussen de omgeving in kaart brengt.

De bewegende personen zijn te herkennen aan de grijze stippen. In een eerste opname (links-

Hoofdstuk 6. Resultaten 44

boven op figuur 6.3) worden de aanwezige personen gescand en als vaste objecten weergegeven.

In hierop volgende opnames zullen deze personen als nieuwe objecten weergenomen worden

op andere posities die eerder vrij waren. Dit terwijl de eerder ingenomen posities plots vrij

komen. Dit resulteert in het vervagen van de eerder bezette posities en het ontstaan van

nieuwe stippen. Deze nieuwe stippen zijn echter lichter van kleur. De kleurintensiteit van

een positie op de kaart is namelijk gelinkt aan de waarschijnlijkheid dat deze positie bezet

is. Zo zouden, indien alle personen zich enige tijd verwijderden, de eerder ingenomen posities

uiteindelijk volledig vervagen en dus als vrije posities beschouwd worden.

We zien verder ook op deze figuur dat ondanks de vele bewegingen het positiebepalingssys-

teem er wel degelijk in slaagt om de vaste omgeving correct in kaart te brengen. Zelfs in een

dergelijke dynamische omgeving kan Gonzales dus nog steeds zijn eigen positie bepalen met

een behoorlijke nauwkeurigheid. We kunnen in wat volgt dus aannemen dat dit positiebepa-

lingssysteem voldoende nauwkeurig is om gebruikt te worden als ingang van de regelaars.

6.1.4 Tijdsduur van het positiebepalingssysteem

We bereiken dus zeer nauwkeurige resultaten op vlak van positiebepaling. Zoals we echter

reeds aanhaalden in secties 3.4 en 4.3.1 is naast de nauwkeurigheid ook de tijdsduur van

het positiebepalingssysteem een belangrijke factor. Ter bevestiging van de daar vernoemde

cijferwaarden worden in tabel 6.1 de gemiddelde, minimum en maximum tijd weergegeven

voor een iteratie van het positiebepalingssysteem. Dit zowel bij uitvoering op een moderne

computer (3, 2 GHz AMD QuadCore processor) als bij uitvoering op de minicomputer waar-

mee Gonzales is uitgerust. Bij uitvoering op Gonzales maken we verder nog een onderscheid

tussen de verschillende regelaars.

Tabel 6.1: Opgemeten tijdsduur (in seconden) voor het positiebepalingssysteem.

Uitvoermodus # metingen Gemiddelde Minimum Maximum

Moderne computer 235 0,26 0,10 0,43

Gonzales (regelaar I) 59 4,06 2,5 5,3

Gonzales (regelaar III) 74 4,23 2,2 8,0

Gonzales (regelaar IV) 72 4,15 2,4 7,1

Gonzales (regelaar V) 71 4,11 2,3 6,2

We zien dus dat de tijdsduur bij de moderne computer steeds minder dan een halve seconde

bedraagt. Op Gonzales’ minicomputer daarentegen ligt het gemiddelde voor elke regelaar

rond de 4 s, maar varieert het maximum sterk (tot zelfs 8 s). De minimum tijdsduur blijkt

voor elke regelaar iets meer dan 2 s te bedragen. Deze waarden bevestigen ook het eerder

Hoofdstuk 6. Resultaten 45

aangehaalde feit dat het positiebepalingssysteem onafhankelijk is van de aansturing en dus

het regelsysteem. De variatie op de maximum tijdsduur bij de verschillende regelaars is toe

te schrijven aan toevalligheden en het aantal beschouwde metingen.

6.2 De regelaars

6.2.1 Testprocedure

Om de verschillende ontwikkelde regelaars met elkaar te kunnen vergelijken maken we gebruik

van een vaste testprocedure die voor elke regelaar gelijk is. Bij deze testprocedure stellen we

een bepaald traject voorop waarin elke mogelijke verplaatsing voorkomt. Bij het uitvoeren

van de regelaar wordt dan een score toegekend gebaseerd op Gonzales’ positie doorheen het

traject. Om verder een gelijke omgeving in elke testsituatie te bekomen testen we de regelaars

in een lege afgesloten ruimte van 2, 40 m op 3 m. We verduidelijken hier eerst het opgestelde

traject en gaan vervolgens in op de manier waarop de score bepaald wordt.

Het traject

Aangezien we met een omni-directionele robot werken moeten we bij het testen van de rege-

laars elke mogelijke beweging in beschouwing nemen. Het opgestelde traject moet dus zeker

verplaatsingen in de drie bewegingsvrijheden bevatten. Hiervoor kunnen we verplaatsingen

volgens slechts een van de vrijheidsgraden beschouwen alsook combinaties ervan. Aangezien

er drie bewegingsvrijheden zijn, zouden we dus 7 verschillende combinaties kunnen maken

waarbij we verplaatsingen volgens een, twee of drie vrijheidsgraden beschouwen. We merken

hier echter op dat het onmogelijk is om rotatie te combineren met verplaatsing volgens slechts

1 translatierichting. Er blijven dus nog 5 mogelijke combinaties over:

� Translatie volgens de x-as

� Translatie volgens de y-as

� Translatie volgens de x- en y-as

� Rotatie rondom de z-as

� Translatie en rotatie

In het opgestelde testtraject nemen we nu elk van deze vijf mogelijkheden op. De afstanden

die we hierbij zullen gebruiken zijn 3,5 maal de afstand die Gonzales in een iteratie van

gemiddelde tijdsduur kan afleggen. We zullen Gonzales namelijk 10 iteraties de tijd geven

voor elk onderdeel van het traject. Op die manier kunnen we naast het rijden zelf ook het

gedrag rondom de eindpositie evalueren. Verder zorgen we er ook voor dat Gonzales zich

Hoofdstuk 6. Resultaten 46

voor elke bewegingsvrijheid zowel in de positieve als in de negatieve zin verplaatst. Concreet

levert dit het volgende Drive-bestand op (zie sectie 4.1.1):

Drive 67.2 0 0

Drive 0 -67.2 0

Drive -47.52 47.52 0

Drive 0 0 60

Drive 67.2 0 -60

De quotering

Om nu dus het prestatieniveau van de verschillende regelaars te kunnen analyseren zullen we

een score toekennen gebaseerd op Gonzales’ wijzigende positie tijdens het afleggen van het

traject. Zoals hierboven reeds vermeld werd stellen we voor elk onderdeel van het traject 10

iteraties ter beschikking. Na afloop van deze 10 iteraties zal Gonzales dus het volgende deel

aanvatten.

We weten echter op voorhand niet of Gonzales elk onderdeel succesvol zal afleggen. Het kan

gebeuren dat Gonzales na 10 iteraties de gewenste positie van het huidige trajectdeel nog niet

heeft bereikt. Om nu een correcte beoordeling te krijgen van het prestatieniveau mag dit de

score van het volgende trajectdeel niet beınvloeden. We moeten dus de interpretatie van het

traject hieraan aanpassen. Dit doen we door de gewenste eindpositie van elk Drive-commando

niet ten opzichte van de vorige gewenste eindpositie te bepalen maar wel ten opzichte van

Gonzales’ werkelijke eindpositie.

Elk deel van het traject kan nu los van de overige beoordeeld worden. We moeten enkel

nog het beoordelingscriterium vastleggen. De voor de hand liggende methode is om na elke

iteratie de fout tussen Gonzales’ werkelijke positie en de verwachte positie te gaan opmeten.

De sommatie van deze fouten doorheen het volledige traject kan dan als eindscore gebruikt

worden. Hoe dichter deze score dan bij nul ligt, hoe beter de regelaar presteert. Deze methode

is grafisch voorgesteld in figuur 6.4.

Figuur 6.4: Grafische weergave van de voorgestelde beoordelingsmethode.

Hoofdstuk 6. Resultaten 47

Dit vereist wel dat we de verwachte posities op voorhand kennen. Aangezien echter de tijds-

duur van een iteratie sterk varieert (zie sectie 6.1.4), kunnen we de verwachte positie na

elke iteratie niet op voorhand bepalen. We kunnen deze methode dus niet gebruiken om het

prestatieniveau op te meten.

Het volstaat echter om slechts een kleine wijziging aan te brengen in de voorgestelde methode

om toch een score te kunnen toekennen. We kunnen namelijk wel na elke iteratie de afstand

tussen Gonzales’ positie en de gewenste eindpositie bepalen. De som van deze afstanden is

dan een maat voor het prestatieniveau van de beschouwde regelaar. We zullen echter wel de

negatie van deze som gebruiken als maat zodat een hogere score overeenkomt met een betere

prestatie in plaats van omgekeerd. Om verder nog een meer genormeerde score te verkrijgen

delen we telkens de afstand tot de eindpositie door de afstand die Gonzales kan afleggen in een

iteratie van gemiddelde duur. Figuur 6.5 geeft een grafische voorstelling van deze aangepaste

beoordelingsmethode.

Figuur 6.5: Grafische weergave van de aangepaste beoordelingsmethode.

Dit is dus de methode die we zullen toepassen bij het beoordelen van de verschillende rege-

laars. Het theoretisch optimum is nu echter niet meer gelijk aan nul, maar afhankelijk van

het opgestelde traject. Zoals eerder vermeld is de afstand van elk trajectdeel 3,5 maal de

gemiddelde afstand in een iteratie. Voor de eerste vier trajectdelen waar enkel translatie of

rotatie aanwezig is, krijgen we dus een theoretisch optimum gelijk aan -8 (= -3,5 - 2,5 - 1,5

- 0,5 - 0 - 0 - ...). Voor het laatste trajectdeel waar zowel translatie als rotatie aanwezig is,

ligt het theoretische optimum op het dubbele. Het theoretische optimum voor het volledige

traject wordt dus -48.

De nauwkeurigheid van de regelaars is echter beperkt door de minimale snelheid waarmee

Gonzales zich kan verplaatsen. Aan deze minimale snelheid is namelijk ook een minimale

verplaatsing per iteratie verbonden, waardoor Gonzales zich dus niet tot op de exacte eind-

positie kan begeven. Om hiermee rekening te houden moeten we een blijvende fout toelaten

gelijk aan de helft van deze minimale verplaatsing voor zowel translatie als rotatie.

Bij het bepalen van deze minimale verplaatsing gaan we uit van de minimale rotatiesnelheid

van de wielen (1 tpm). Voor de standaard ingestelde rotatiesnelheid van 6 tpm is dus de

Hoofdstuk 6. Resultaten 48

verhouding van de minimale verplaatsing tot de gemiddelde verplaatsing gelijk aan 1/6 voor

translatie en 1/3 voor rotatie (zie factor 1/2 in de formules 4.1 voor de rotatie). Indien we nu

deze blijvende fout toevoegen aan het theoretisch optimum krijgen we een maximaal haalbare

score van -57,25. Dit is dus het streefdoel dat we voor ogen houden bij het evalueren van de

regelaars.

6.2.2 Behaalde resultaten

We beschikken nu over een testprocedure waardoor we een genormeerde score kunnen geven

aan het prestatieniveau van de verschillende regelaars. Wegens de verschillende aard van de

ontwikkeling van regelaar II vergeleken met regelaars III, IV en V zullen we eerst regelaars I

& II bespreken en vervolgens regelaars I, III, IV & V. Op het einde worden ten slotte nog de

resultaten weergegeven voor enkele andere trajecten.

Regelaars I & II

Zoals besproken in de uiteenzetting van regelaar II (zie sectie 4.2.1) is het ontwikkelen ervan

niet het resultaat van een stap maar volgt het uit de convergentie van een hele reeks stappen.

We zullen ons dan ook niet enkel beperken tot het bespreken van het eindresultaat maar gaan

ook in op de evolutie naar dit eindresultaat.

Aangezien het gebruikte leerproces zeer tijdsrovend is, voeren we het eerst uit in een simu-

latieomgeving1. In deze simulatieomgeving kunnen we handig gebruik maken van de uit-

gebreide rekencapaciteit van moderne computers en kunnen we het leerproces ongestoord

zijn gang laten gaan zonder nood aan eigen interventies. Elke doorlopen tussenstap wordt

hierbij beoordeeld zoals hierboven uiteengezet werd. De resultaten van het leerproces in de

simulatieomgeving worden weergegeven in figuur 6.6.

Zoals we verwachten ligt het initiele prestatieniveau onder dat van regelaar I. Dit niveau

stijgt echter snel gedurende de eerste 10 generaties en blijft vervolgens schommelen rond een

niveau dat net iets hoger ligt dan dat van regelaar I. Dit referentieniveau van regelaar I is het

resultaat van de uitmiddeling van een tiental testen.

Indien we nu hetzelfde leerproces toepassen op de werkelijke uitvoering van Gonzales krijgen

we de resultaten weergegeven in figuur 6.7. We beginnen opnieuw op een niveau onder dit van

regelaar I, maar de initiele stijging die merkbaar was in de simulatie blijkt echter in de praktijk

zelfs na een zestal generaties nog steeds niet voor te komen. Dit feit, alsook de zeer beperkte

verbetering die uit de simulatie volgt, kan verklaard worden door twee aspecten. Enerzijds

leunt het gebruikte model reeds zeer dicht aan bij de werkelijkheid en anderzijds is er slechts

beperkte verbetering mogelijk doordat in deze regelaar nog geen rekening gehouden wordt

1Webbots 6.3.0

Hoofdstuk 6. Resultaten 49

met de tijdsvertraging van het positiebepalingssysteem (zie sectie 4.3.1). Omwille hiervan

en door het tijdsrovende karakter van het leerproces loont het dan ook niet de moeite om

het leerproces op de werkelijke robot verder te laten doorgaan in de hoop uiteindelijk toch

verbetering waar te nemen.

Figuur 6.6: Resultaten van het CMA-ES leerproces in een simulatieomgeving.

Figuur 6.7: Resultaten van het CMA-ES leerproces in de werkelijkheid.

Hoofdstuk 6. Resultaten 50

Regelaars I, III, IV & V

We beschouwen nu ook regelaars III, IV en V. Aan de hand van de hierboven beschreven

testprocedure kunnen we het prestatieniveau van elke regelaar opmeten. Deze resultaten

kunnen we dan onderling vergelijken en toetsen aan het theoretisch haalbare optimum.

Zoals echter reeds herhaaldelijk werd opgemerkt is de tijdsduur van een iteratie variabel.

Hierdoor zal Gonzales zich bij verschillende testen van eenzelfde regelaar op verschillende

tussenposities bevinden. Hieruit volgen dus verschillende scores voor diezelfde regelaar. Om

een representatieve score te bekomen testen we elke regelaar 10 maal. Op die manier krijgen

we een beter beeld van het werkelijke prestatieniveau van de beschouwde regelaars. Figuur 6.8

geeft de opgemeten scores weer voor de regelaars I, III, IV & V.

Figuur 6.8: De opgemeten scores voor regelaars I, III, IV & V.

We zien dus dat zowel regelaars III, IV als V zeer dicht bij het theoretische optimum komen.

De variatie op de scores van regelaar V is bovendien zeer beperkt. Bij regelaars III en IV echter

merken we een behoorlijke spreiding van de opgemeten scores. Deze variatie is rechtstreeks

gelinkt aan de ingestelde waarden van de gebruikte drempelwaarden (zie secties 4.4 en 4.5).

De afstand tussen Gonzales’ eindpositie en de gewenste positie van elk trajectdeel kan namelijk

varieren tussen 0 en de ingestelde drempelwaarde. Bij regelaars III en IV moesten we deze

drempelwaarden behoorlijk ruim kiezen (75 % van de gemiddelde afstand in een iteratie)

door de vaste ingestelde bewegingssnelheid. In regelaar V echter kan deze snelheid varieren

waardoor de drempelwaarden verlaagd konden worden. Hierdoor ligt de variatie van de scores

bij regelaar V een stuk lager en is ook de gemiddelde score hoger dan deze voor regelaars III

en IV.

Hoofdstuk 6. Resultaten 51

Verder zien we ook dat de scores van regelaars III en IV zeer dicht bij elkaar aanleunen. Dit

is een bevestiging van het feit dat het gebruikte model reeds zeer dicht bij de werkelijkheid

aanleunt. Om nu toch het belang van de extra regellus in regelaars IV en V aan te tonen

introduceren we een willekeurige fout in het model. Vervolgens gebruiken we regelaar III, IV

en V om Gonzales een bepaald gewenst traject te laten afleggen en vergelijken we dit met het

werkelijke traject. Aangezien we hier louter het effect van de extra regellus willen illustreren

stellen we een eenvoudig traject op waarbij Gonzales zich 1, 5 m voorwaarts moet verplaatsen.

Het resultaat is weergegeven in figuur 6.9. We gebruiken hier nu een gewijzigde kleurcode.

Het gewenste traject wordt voorgesteld door de blauwe lijn en het gevolgde traject door de

rode stippen. Gonzales’ orientatie wordt weergegeven door de zwarte staart.

Figuur 6.9: Het gewenste en gevolgde traject volgens regelaar III (links) IV (midden) en IV (rechts).

We zien duidelijk dat regelaar IV en V de foutieve aansturing detecteren en corrigeren. Re-

gelaar III daarentegen blijft de foutieve stuursignalen genereren waardoor Gonzales slechts

naar het einde van het traject toe terug richting het gewenste eindpunt navigeert. Verder zien

we ook dat bij regelaar V Gonzales inderdaad dichter bij de eindbestemming eindigt dan bij

regelaar IV.

Enkele andere trajecten. . .

Tot slot stellen we nog een aantal aanschouwelijkere trajecten op die we Gonzales willen laten

volgen. We maken hiervoor telkens gebruiken van regelaar V. De opgestelde trajecten zijn de

volgende:

� Een Y-vorm (enkel translatie)

� Een Y-vorm (simultane translatie en rotatie)

Hoofdstuk 6. Resultaten 52

� Een vierkant (enkel translatie)

� Een vierkant (simultane translatie en rotatie)

In figuur 6.10 is telkens het werkelijk gevolgde traject gevisualiseerd alsook het vooropgestelde

traject. We gebruiken opnieuw dezelfde kleurcode als in figuur 6.9.

Figuur 6.10: Behaalde resultaten met regelaar V voor een Y-vormig traject met enkel translatie

(links boven), een Y-vormig traject met translatie en rotatie (rechts boven), een vierkant

trjact met enkel translatie (links onder) & een vierkant traject met translatie en rotatie

(rechts onder).

We zien dus dat de regelaar er goed in slaagt om de trajecten waar enkel translatie in voor

komt te volgen. Indien er echter translatie en rotatie tegelijk optreedt krijgen we een slechtere

trajectcontrole. Dit is te wijten aan het feit dat bij de combinatie van translatie en rotatie de

stuursignalen eigenlijk continu moeten varieren. Er kan echter slechts een set stuursignalen

genereerd worden per iteratie. De regelaar kan Gonzales dus maar gemiddeld om de 4 s

bijsturen, vandaar de grotere afwijking.

Hoofdstuk 7

Conclusies en perspectieven

We geven hier tot slot een korte samenvatting van het behaalde resultaat. Hiernaast lichten

we ook enkele mogelijke toepassingen en uitbreidingen toe die gebruik maken van wat hier in

deze masterproef gerealiseerd werd.

7.1 Conclusies

In een eerste deel van deze masterproef focusten we ons op het implementeren van een positie-

bepalingssysteem. Aan de hand van dit positiebepalingssysteem moest de beschouwde robot,

Gonzales, in staat zijn zijn positie te bepalen in een bepaalde omgeving alsook deze omgeving

tegelijkertijd in kaart te brengen. Dit moest gebeuren terwijl Gonzales zich verplaatste of

met andere woorden, we wilden een realtime implementatie.

We konden hiervoor gebruik maken van een reeds bestaand algoritme (Direct Particle-SLAM )

ontwikkeld door de Duke University. Aangezien dit echter ontworpen was voor gebruik op

een andere robot en verder ook niet in realtime kon uitgevoerd worden moesten een aantal

structurele wijzigingen gemaakt worden vooraleer we het konden uitvoeren op Gonzales. Het

resultaat is een positiebepalingssysteem dat erin slaagt zowel in statische als dynamische

omgevingen van verschillende afmetingen een nauwkeurige kaart van de omgeving aan te

maken en hierin Gonzales’ positie te bepalen.

In een tweede deel ontwikkelden we een regelaar die Gonzales’ aansturing verzorgt op basis

van de positie verkregen uit het positiebepalingssysteem. We gingen hiervoor uit van een

eerste relatief eenvoudige regelaar die enkel gebruikt maakt van een theoretisch model van

Gonzales’ kinematica. Vervolgens werden systematisch de pijnpunten besproken en verbeterd

in een volgende regelaar. Dit resulteerde uiteindelijk in de ontwikkeling van een reeks van vijf

regelaars. Het eindresultaat hiervan, regelaar V, is in staat om Gonzales zo aan te sturen dat

deze een voorgesteld traject met minimale afwijking kan volgen. Verder slaagt deze er ook in

om foutieve aansturingen te detecteren en te corrigeren zodat Gonzales steeds het gewenste

53

Hoofdstuk 7. Conclusies en perspectieven 54

traject blijft volgen.

Kort samengevat hebben we dus een systeem ontwikkeld dat in staat is de beschouwde omni-

directionele robot, Gonzales, in eender welke (onbekende) omgeving een vooraf gedefinieerd

traject te laten volgen.

7.2 Perspectieven

Uiteraard stopt het hier niet. Deze masterproef heeft slechts de basis gevormd op vlak van

aansturing van een omni-directionele robot. Dit kan nu verder gebruikt worden in verschei-

dene toepassingen. Verder zijn er ook nog enkele mogelijkheden tot uitbreiding van het hier

gerealiseerde systeem. We lichten eerst enkele van deze uitbreidingen toe en geven vervolgens

een aanzet tot enkele mogelijke toepassingen.

7.2.1 Uitbreidingen

Een eerste uitbreiding situeert zich op het niveau van het positiebepalingssysteem. Dit maakt

momenteel gebruik van een Laser Range Finder (LRF, zie sectie 2.1). Dit is een zeer nauw-

keurig maar ook behoorlijk duur toestel. Nu is het voor vele toepassingen wenselijk om over

een digitale camera te beschikken. Het zou dus zeer praktisch kunnen zijn om deze camera

dan ook te gebruiken als invoer van het positiebepalingssysteem. Op die manier kunnen we

het gebruik van de duurdere LRF vermijden en hebben we meteen ook visuele informatie

beschikbaar voor de gebruiker. In de literatuur werden dergelijke toepassingen reeds bestu-

deerd (zie bijvoorbeeld Davison (2003)). Rest dus nog de uitdaging om dit ook op Gonzales

te implementeren.

Een volgende uitbreiding heeft betrekking tot de geınstalleerde rekencapaciteit op Gonzales.

Zoals reeds eerder vermeld (zie sectie 3.4) is deze eerder beperkt waardoor voornamelijk het

positiebepalingssysteem beperkt is in haar snelheid. Een mogelijke optie om dit te verbeteren

is gebruik te maken van externe rekencapaciteit. We kunnen dan bijvoorbeeld de nodige

informatie uit de sensoren via het netwerk naar een externe computer zenden. Op deze

computer voeren we dan het positiebepalingssysteem uit dat veel sneller de nieuwe positie

kan bepalen. Vervolgens sturen we dan deze positie terug naar Gonzales zodat de regelaar

deze kan gebruiken bij de aansturing.

Een laatste voorstel tot uitbreiding ten slotte vinden we bij de regelaar zelf. In de hier ont-

wikkelde regelaars werd steeds uitgegaan van een theoretisch opgesteld model van Gonzales’

kinematica. In regelaar II werd dit model meer afgestemd op de werkelijkheid en in regelaars

IV en V was het mogelijk om in realtime het model bij te sturen. Als mogelijke uitbreiding

hierop stellen we nu een volledig andere aanpak voor. We kunnen namelijk aan de hand van

Reservoir Computing de regelaar zelf een model aanleren op basis van trainingsdata. Dit

Hoofdstuk 7. Conclusies en perspectieven 55

leerproces wordt uitgebreid besproken in Jaeger (2001), Jaeger (2002a) & Jaeger (2003). Jae-

ger (2002b) geeft een uiteenzetting over de implementatie ervan. Gedurende het verloop van

deze masterproef werd reeds een uitgebreide set met trainingsdata aangemaakt alsook een

kleinschalige simulatie. Dit kan mogelijks gebruikt worden als uitgangspunt voor een verdere

uitwerking hiervan.

7.2.2 Toepassingen

Tot slot beschouwen we nog enkele mogelijke toepassingen die volgen uit wat in deze master-

proef gerealiseerd werd. Een eerste toepassing volgt logischerwijs uit het omni-directionele

karakter van de gebruikte robot. Door de grotere bewegingsvrijheid van Gonzales kan deze in-

gezet worden op plaatsen waar de beschikbare ruimte voor verplaatsingen minimaal is. Door-

dat Gonzales zich in elke richting kan bewegen en ter plaatse kan draaien kan hij gemakkelijk

manoeuvreren op plaatsen waar conventionele mobiele voertuigen dit niet kunnen. Hierbij is

echter een correcte aansturing van groot belang om ongewenste contacten te vermijden.

Aangezien het systeem ook beschikt over een positiebepalingssysteem dat tevens de omgeving

in kaart brengt is een tweede voor de hand liggende toepassing het verkennen van ongekende

ruimtes. Hierbij kan men echter geen gebruik maken van een vast traject maar moet dit

traject uitgestippeld worden terwijl Gonzales de ruimte verkent.

Een andere toepassing waar het traject op voorhand niet vastligt is de volgende. Indien

Gonzales reeds over een plattegrond van zijn omgeving beschikt kan men hier enkele referen-

tiepunten op aanbrengen. Een toepassing kan dan bijvoorbeeld liggen in het plannen van het

traject van punt A naar punt B. Eenmaal dit gedaan is zorgt de hier ontwikkelde regelaar er

dan voor dat Gonzales dit traject wel degelijk ook kan afleggen.

Dit zijn uiteraard maar enkele voor de hand liggende toepassingen. De werkelijke mogelijk-

heden zijn legio en we laten het dan ook aan de geınteresseerde lezer over om zich hier verder

in te verdiepen.

Bijlage A

Programmacode

Zie bijgevoegde CD.

56

Bijlage B

Datasheets

Zie bijgevoegde CD.

57

Bibliografie

J. A. Cooney, W. L. Xu & G. Bright (2004). Visual dead-reckoning for motion control of a

mecanum-wheeled mobile robot. Mechatronics, 14:623–637.

A. J. Davison (2003). Real-time simultaneous localisation and mapping with a single camera.

Proceedings. Ninth IEEE International Conference on Computer Vision, 2:1403–1410.

X. Dong, Z. Dongbin, Y. Jianqiang & T. Xiangmin (2009). Trajectory tracking control of

omnidirectional wheeled mobile manipulators: Robust neural network-based sliding mode

approach. IEEE Transactions on Systems, Man and Cybernetics - Part B: Cybernetics,

39(3):788–799.

H. Durrant-Whyte & B. Tim (2006a). Simultaneous localization and mapping (SLAM): Part

I the essential algorithms. IEEE Robotics & Automation Magazine, 13(2):99–110.

H. Durrant-Whyte & B. Tim (2006b). Simultaneous localization and mapping (SLAM): Part

II state of the art. IEEE Robotics & Automation Magazine, 13(3):108–117.

A. I. Eliazar & R. Parr (2004). DP-SLAM 2.0. IEEE International Conference on Robotics

and Automation, pp. 1314–1320.

N. Hansen & A. Auger (2005). A restart CMA evolution strategy with increasing population

size. Congress on Evolutionary Computation, 2:1769–1776.

N. Hansen, S. Muller & P. Koumoutsakos (2003). Reducing the time complexity of the deran-

domized evolution strategy with covariance matrix adaptation (CMA-ES). Evolutionalry

Computation, 1(11):1–18.

N. Hansen & A. Ostermeier (2001). Completely derandomized self-adaptation in evolution

strategies. Evolutionary Computation, 2(9):159–195.

N. Hansen, A. Ostermeier & A. Gawelczyk (1995). On the adaptation of arbitrary normal

mutation distributions in evolution strategies: The generating set adaptation. Proceedings.

6th International Conference on Genetic Algorithms, pp. 57–64.

58

Bibliografie 59

H. Jaeger (2001). The”echo state” approach to analysing and training recurrent neural

networks. GMD-Report, (148).

H. Jaeger (2002a). Short term memory in echo state networks. GMD-Report, (152).

H. Jaeger (2002b). Tutorial on training recurrent neural networks, covering BPPT, RTRL,

EKF and the echo state network approach. GMD-Report, (159).

H. Jaeger (2003). Adaptive nonlinear system identification with echo state networks. Advances

in Neural Information Processing Systems, (15):593–600.

Y. Liu, X. Wu, J. Zhu & J. Lew (2003). Omni-directional mobile robot controller design by

trajectory linearization. Proceedings of the American Control Conference, 4(4-6):3423–3428.

W. Melange, A. De Smet & J. D’Haene (2010). Hardware ontwerp project. Ontwerp van een

Omniwheel Robot met autonome lokalisatie.

R. Rojas & A. G. Forster (2006). Holonomic control of a robot with an omnidirectional drive.

Kunstliche Intelligenz, 20(2).

J. E. M. Salih, M. Rizon, S. Yaacob, A. H. Adom & M. R. Mamat (2006). Designing omni-

directional mobile robot with mecanum wheel. American Journal of Applied Sciences,

3(5):1831–1835.

J.-B. Song & K.-S. Byun (2004). Design and control of a four-wheeled omnidirectional mobile

robot with steerable omnidirectional wheels. Journal of Robotic Systems, 21(4):193–208.

K. Watanabe, Y. Shiraishi, S. G. Tzafestas, J. Tang & T. Fukuda (1998). Feedback control of

an omnidirectional autonomous platform for mobile service robots. Journal of Intelligent

and Robotic Systems, 22(3):315–330.