Mechatronic System Design

MECHATRONIC SYSTEM DESIGN MSD
Andy Van Wesemael
Dries Fransen
Michiel Vanderhoydonck
Promotoren
Ing. Vincent Claes XIOS Hogeschool Limburg
Ing. Steven Palmaers XIOS Hogeschool Limburg
Ing. Gwen Vanheusden XIOS Hogeschool Limburg
Ing. Dimitri Janssens XIOS Hogeschool Limburg
Dhr. Tristan Fransen XIOS Hogeschool Limburg
Bachelorproef academiejaar 2011-2012
Professionele Bachelor
Elektromechanica
Elektronica ICT
Toegepaste Informatica

MECHATRONIC SYSTEM DESIGN [4]
Dankwoord
Graag willen wij in dit dankwoord iedereen bedanken die ons rechtstreeks of onrechtstreeks
hebben geholpen bij het verwezenlijken van onze studies en uiteindelijk ook deze stage en dit
eindwerkproject.
Wij willen graag onze bedrijfspromotoren Ing. Vincent Claes en Ing. Steven Palmaers bedanken
voor de kans om ons te laten meewerken aan dit project. Zij hebben er tevens voor gezorgd
dat we vanaf dag één zonder problemen met de geschikte software konden beginnen werken.
Ook willen we hun bedanken voor de vlotte communicatie en de bereidheid om ons verder te
helpen in de materie als we met een vraag zaten. Dankzij hun kregen we de kans om deel te
nemen aan de Mechatronicabeurs in Veldhoven, deze beurs bleek zeer interessant te zijn om
ideeën op te doen voor dit project.
Verder willen wij onze interne promotoren bedanken om ons bij te staan tijdens dit project en
onze vooruitgang op te volgen. Steeds konden wij terecht bij hun voor nuttige feedback.
Tot slot bedanken we al onze docenten die ons de nodige kennis hebben toegebracht
doorheen de jaren aan de XIOS Hogeschool Limburg.

INHOUD
DANKWOORD 4
ABSTRACTEN 8
LIJST MET GEBRUIKTE AFKORTINGEN EN SYMBOLEN 11
LIJST VAN GEBRUIKTE FIGUREN EN TABELLEN 12
1 INLEIDING 14
1.1 Voorstelling bedrijf 15
2 MECHATRONIC SYSTEM DESIGN 16
2.1 Hightech Mechatronica 16
2.2 Onderzoeksprobleem 17
2.3 Uitdagingen 18
3 TOOLS 20
3.1 SolidWorks 20
3.1.1 Motion Study 20
3.2 LabVIEW 21
3.2.1 Softmotion 22
3.3 Eclipse 24
3.3.1 Software Development Kit 24
3.3.2 Android Development Tools 24
4 MECHANISCH DESIGN 25
4.1 Robot 26
4.2 Mecanum wielen 27
4.2.1 Werking 27
4.2.2 Ontwerp 30
4.2.3 Kinematisch analyse 31
4.2.4 Krachten vector analyse 35
4.2.4.1 Voorwaartse beweging 36
4.2.4.2 Zijwaartse beweging “Strafing” 37
4.2.4.3 Diagonale beweging 38
4.2.5 Nadelen 38
4.3 Implementatie 39

4.3.1 Motion Study 39
4.3.2 Implementatie Softmotion en LabVIEW 41
4.3.2.1 Toevoegen van de SolidWorks assembly 41
4.3.2.2 Toevoegen van assen 42
4.3.2.3 Motion profiles in LabVIEW 42
4.3.2.4 Steering frame in LabVIEW 44
4.3.2.5 Webservice 46
4.3.3 Beperkingen 48
5 ELEKTRONICA DESIGN 50
5.1 Programmaplatform 50
5.2 Sturing motoren 50
5.3 Sensoren 51
5.4 Printed Circuit board 51
5.4.1 National Instruments MultiSim en UltiBoard 51
5.4.2 Printed circuit board 52
5.5 Voeding 54
5.6 Router 55
5.7 IPcam 55
5.8 LabVIEW program sturing motoren 56
5.8.1 Doelstellingen 56
5.8.2 Uitwerking 56
6 INFORMATICA DESIGN 61
6.1 Android 61
6.1.1 Wat is Android? 61
6.1.2 De filosofie 61
6.1.3 Het Ontwerp 62
6.1.4 Application Programming Interfaces 63
6.2 Sensoren 65
6.2.1 Gyroscopen 66
6.2.1.1 Het Coriolis effect 66
6.2.2 Accelerometers 68
6.3 Sensor Fusion 69
6.3.1 De Kalman-Filter 69
6.3.2 Balansfilter 70
6.3.3 Het probabilistisch netwerk 71
6.4 De Dempster-Shafer Theorie 72
6.5 Design en Implementatie 74
6.5.1 Google Nexus S 74
6.5.2 Touch 75

6.5.3 RESTful webservice 78
6.5.4 Motion 79
6.5.5 Vision 84
7 PROJECT MANAGEMENT 88
8 CONCLUSIE 89
8.1 Mogelijke uitbreidingen 89
9 BIJLAGEN 90
9.1 Bijlage 1: Motion Study 90
9.2 Bijlage 2: Robot 91
9.3 Bijlage 3: LabVIEW programma simulatie 92
9.4 Bijlage 4: Datasheets 94
9.5 Bijlage 5: Projectmanagement 103
10 BIBLIOGRAFIE 107

Abstracten
Elektromechanica
In het PWO-project Mechatronic System Design (MSD) moet een multidisciplinair team
bestaande uit een student pba elektronica-ict, een student pba elektromechanica en een
student toegepaste informatica een mechatronische virtualisatie en realisatie uitvoeren.
De studenten werken een virtueel model van een robot uit door gebruik te maken van
SolidWorks, (CAD/CAM, Mechanische tekening) LabVIEW voor de embedded software en een
iPhone/Android applicatie voor het controleren/besturen van de robot. Verder moeten er
enkele sensoren geïmplementeerd worden waarvan de meetwaardes in een database
bijgehouden worden. Nadat deze virtualisatie uitgevoerd is moeten de studenten deze robot
in de praktijk opbouwen.
De grote uitdaging binnen de mechatronicasector is geïntegreerde virtualisatie (in alle
deelfacetten). Via deze weg kan men komen tot één virtueel prototype van een systeem
waarbij de kansen op verkeerde interpretatie van de systeemvereisten en problemen op
systeemniveau geminimaliseerd kunnen worden alvorens er veel geld uitgegeven is binnen het
ontwikkelingsproces.
Het gedeelte voor elektromechanica bestaat erin om het robotdesign te tekenen in
SolidWorks. Dit design zal worden gebruikt om de robot virtueel te laten werken op de
computer. Deze virtualisatie zal verkregen worden door een koppeling tussen SolidWorks en
LabVIEW. Verder moeten er enkele sensoren geïmplementeerd worden waarvan de
meetwaardes in een database bijgehouden worden. Samenwerking en communicatie met de
andere studenten in deze multidisciplinaire opdracht is essentieel voor het welslagen van het
project.

Elektronica-ICT
Als onderdeel van mijn laatste jaar in de opleiding professionele bachelor Elektronica-ICT heb
ik een stage voltooid aan XIOS Hogeschool Diepenbeek.
In september 2011 werd er in XIOS Hogeschool Diepenbeek een nieuw PWO-project gestart,
dit project draagt de titel Mechatronic System Design, of afgekort, MSD. Mechatronica is een
term die verschillende vakgebieden samenvoegt, namelijk Elektromechanica, informatica en
Elektronica. Het project heeft een looptijd van drie jaar en tijdens het project zal er elk jaar een
toepassing worden uitgewerkt die wordt aangestuurd met een mobiele applicatie. Deze
toepassing zal eerst virtueel worden opgebouwd, waarna de applicatie ook echt wordt
gebouwd. Het project dat gebouwd wordt, zal ook een project zijn dat in real-life gebruikt zal
worden, aangezien het een project is dat door de industrie aangeleverd werd.
De bedoeling is dat de student informatica een applicatie schrijft die op een mobiel toestel
gedraaid zal worden, waardoor er een robot bestuurd kan worden. In dit geval zal de applicatie
voor Android geschreven worden.
De elektromechanicastudent zal de robot tekenen in SolidWorks, met deze tekening zal het
virtuele gedeelte getest worden. Later zal hij er ook voor zorgen dat al de componenten netjes
op de robot gemonteerd zullen worden.
De student uit de richting elektronica, in dit geval ben ik dat, zorgt er op zijn beurt voor dat al
de nodige componenten gezocht worden. Verder moet ik er ook voor zorgen dat er een
printplaat ontworpen wordt, waarmee de motoren van de robot aangesloten worden en de
verschillende sensors mee uitgelezen kunnen worden.
Tenslotte moet ik nog een programma schrijven in LabVIEW waarmee de motoren
aangestuurd worden via de applicatie op het mobiele toestel en de sensorwaarden
omgerekend worden naar de bijbehorende afstanden zodat ook deze doorgestuurd kunnen
worden naar de mobiele applicatie.

Toegepaste Informatica
Binnen de XIOS Hogeschool Limburg is in september 2011 een nieuw PWO-project gestart,
namelijk MSD wat staat voor Mechatronic System Design. Mechatronica omvat de combinatie
van elektronica, elektromechanica en informatica. Tijdens het project, dat een looptijd heeft
van drie jaar, zal eerst gewerkt worden aan de bouw van een virtueel prototype, dat door
middel van een mobiele toepassing kan bestuurd worden. Vervolgens zal een fysieke opstelling
gebouwd worden. Ook zal de nodige aandacht uitgaan naar een multidisciplinaire benadering
om het resultaat te realiseren. Dit alles zal gebeuren door een concrete case, aangeleverd door
de industrie.
Binnen de stage wordt een kleinere case uitgewerkt volgens dezelfde principes, namelijk een
robot op wielen waarop een videocamera gemonteerd is.
In de eerste fase wordt door de student Elektromechanica in SolidWorks een model van de
robot gebouwd, de student Elektronica-ICT bouwt het besturingsalgoritme en de student
Toegepaste Informatica bouwt een mobiele toepassing om dit virtueel model aan te sturen.
Concreet zal de mobiele toepassing geschreven worden voor het Android platform.
De communicatie tussen de controller en de robot zal gebeuren door middel van RESTful
webservices. Om de besturing eenvoudig te maken wordt gebruik gemaakt van de sensoren
aanwezig in het toestel zoals de accelerometer.
Tot slot wordt de robot effectief gebouwd en wordt de proefopstelling uitvoerig getest.

Lijst met gebruikte afkortingen en symbolen
API Application Programming Interface
CAD Computer Aided Design
EA Elektronica
EM Elektromechanica
FPGA Field-programmable gate array
GUI Graphic User Interface
IC Integrated Circuit
IDE Integrated Development Environment
IO Input/Output
JIT Just In Time
LV LabVIEW
MJPEG Motion Joint Photographic Expters Group
MSD Mechatronic System Design
NI National Instruments
sbRIO Single-board reprogrammable input/output
PCB Printed Circuit Board
PWM Pulse Width Modulation
PWO Projectmatig Wetenschappelijk Onderzoek
SDK Software Development Kit
SW SolidWorks
TI Toegepaste Informatica
URI Uniform Resource Identifier
VI Virtual Instrument
VM Virtual Machine

Lijst van gebruikte figuren en tabellen
Figure 2-1: Schematisch overzicht disciplines Mechatronica...................................................... 16
Figure 2-2: Logo Hightech Mechatronica 2012........................................................................... 16
Figure 3-1: Eclipe Logo ................................................................................................................ 24
Figure 4-1: Basisplatform rover 5................................................................................................ 25
Figure 4-2: CAD-tekening robot .................................................................................................. 26
Figure 4-3: Mecanum-wiel met 6 centraal gemonteerde rollers ................................................ 27
Figure 4-4: Opstelling mecanumwielen bovenaanzicht .............................................................. 28
Figure 4-5: Left strafing............................................................................................................... 28
Figure 4-6: Diagonaal beweging met mecanum wielen ............................................................. 29
Figure 4-7: Zijaanzicht mecanumwiel (cirkel).............................................................................. 30
Figure 4-8: Contact rollers met grond......................................................................................... 31
Figure 4-9: Contact rollers met grond, gebruikt voor de kinematische en krachten analyse ..... 32
Figure 4-11: Krachtenvectoren mecanumwiel ............................................................................ 35
Figure 4-12: Voorwaartse beweging krachtenanalyse ............................................................... 36
Figure 4-13: Strafing krachtenanalyse ........................................................................................ 37
Figure 4-14: Diagonale beweging ............................................................................................... 38
Figure 4-15: Virtueel model rover 5 ............................................................................................ 39
Figure 4-16: Motion Study........................................................................................................... 39
Figure 4-17: SolidWorks assembly in LabVIEW project............................................................... 41
Figure 4-18: Axis Manager Softmotion ....................................................................................... 42
Figure 4-19: Softmotion function blocks ..................................................................................... 43
Figure 4-20: Creëren van mecanum steering frame ................................................................... 44
Figure 4-21: Snelheid steering frame  individuele snelheid wielen ......................................... 45
Figure 4-22: Variables en webservice in LV project..................................................................... 46
Figure 4-23: Variables VI............................................................................................................. 47
Figure 4-24: Webservice URL mapping ....................................................................................... 47
Figure 4-25: Volledig LabVIEW project........................................................................................ 48
Figure 4-26: SolidWorks error ..................................................................................................... 49
Figure 5-3: Printplaat motorsturing en uitlezing sensoren ......................................................... 53
Figure 5-4: Schema gaatjesprint 7805 ........................................................................................ 54
Figure 5-8: Voorbeeld programma sturing motoren................................................................... 58
Figure 5-10: Aparte signalen van optische encoders .................................................................. 60
Figure 5-11: Samengevoegde signalen ....................................................................................... 60
Figure 6-1: Android logo.............................................................................................................. 61
Figure 6-2: Android System Architecture .................................................................................... 62
Figure 6-3: Sensor Platform InvenSense...................................................................................... 65
Figure 6-4: Structuur Gyroscoop ................................................................................................. 66
Figure 6-8: Structuur CMOS-MEMS Chip..................................................................................... 68
Figure 6-9: Kalman-filter ............................................................................................................. 70
Figure 6-10: Voorstelling probabilistisch netwerk binnen het project ........................................ 71
Figure 6-11: Google Nexus S ....................................................................................................... 74
Figure 6-12: Schematische voorstelling touch control ................................................................ 75
Figure 6-13: Control robot movement with smartphone............................................................ 79

Tabel 1: Aansluiting motoren op sbRIO-9602 ............................................................................. 57
Tabel 2: Sturingen uitgangen per richting................................................................................... 57

1 Inleiding
De stage die we afgewerkt hebben tijdens het derde trimester van dit schooljaar bestond uit
het PWO-project ‘Mechatronic System Design’. Dit is een drie jaar durend project waarin elk
jaar een student uit de richting Toegepaste Informatica, Elektromechanica en Elektronica-ICT
samen een project, dat gegrepen werd uit een situatie in real-life, tot een goed einde moeten
brengen.
De bedoeling van dit project is dat er een virtueel gedeelte uitgewerkt wordt en een fysiek
gedeelte, zodat het product zowel virtueel als fysisch gebruikt kan worden.
In het project waarvoor dit jaar gekozen werd, moesten we een robot laten rondrijden
aangestuurd via een smartphone. De student Elektromechanica moest daarom de robot
tekenen in SolidWorks, waardoor deze virtueel in beweging gebracht kan worden door gebruik
te maken van het programmeerprogramma LabVIEW. Verder zal hij ook nog een systeem
bedenken waarmee we alles op de robot kunnen bevestigen. De student Toegepaste
Informatica schrijft een Android applicatie zodat een gebruiker via een smartphone de robot
virtueel en reëel kan laten rijden. De student Elektronica-ICT, ontwierp de nodige elektronica
om de motoren te sturen en de sensors op de robot uit te lezen.
Figure 1-1: Interactie tussen de studenten

1.1 Voorstelling bedrijf
Deze negen weken stage vonden plaats op het Technologiecentrum in Diepenbeek, waar één
van de onderzoeksinstituten van de XIOS Hogeschool Limburg gevestigd is, in samenwerking
met de Katholieke Hogeschool Limburg.
In het Technologiecentrum, een gebouw met een totale oppervlakte van 4330 vierkante
meter, worden zeven onderzoeksinstituten ondergebracht. Die leveren in hoofdzaak diensten
aan kleine en middelgrote bedrijven in Limburg en omgeving. Voor de KHLim gaat het om
ACRO (automatisering robots en machines). De XIOS Hogeschool Limburg bezorgt onderdak
aan EMAP (geautomatiseerde plaatbewerking), NuTec (nucleaire technieken),
Onderzoeksgroep Bouwkunde (stabiliteit bouwconstructies en materiaalgebruik in de bouw)
en het VerpakkingsCentrum (ondersteuning verpakkingsproblematiek industrie). Ook de
Technologiepool, een soort helpdesk voor bedrijven met niet-specifieke technologische
vragen, kent zijn thuisbasis in het Technologiecentrum en hier hebben wij onze stage voltooid.
Figure 1-2: Technologiecentrum

2 Mechatronic System Design
Dit project kadert, zoals de naam al doet vermoeden, binnen de mechatronicasector.
Mechatronica is een technische discipline waarbinnen onder andere mechanica, elektronica,
informatica en regeltechniek centraal staan.
Figure 2-1: Schematisch overzicht disciplines Mechatronica
Het doel van mechatronica bestaat erin om een oplossing te ontwikkelen voor industriële
automatiseringen. Het spectrum aan kennis van de verschillende disciplines maakt dat
mechatronici een goed overzicht van een project onderhouden en een gecoördineerde
samenwerking binnen de betrokken disciplines kunnen bieden.
2.1 Hightech Mechatronica
Om een idee te krijgen van hoe mechatronici te werk gaan en welke mogelijkheden deze
discipline voortbrengt op de arbeidsmarkt planden onze promotoren een uitstap naar de
jaarlijkse Hightech Mechatronicabeurs in Veldhoven, nabij Eindhoven in Nederland.
Figure 2-2: Logo Hightech Mechatronica 2012
Naast verschillende standen en werkstations waar de bedrijven hun nieuwste technologieën
toonden was er ook de kans om heel wat interessante sessies bij te wonen. Hier werd een
heldere kijk gegeven op hoe bedrijven hun innovaties realiseerden. De visie over wat de studie
inhoudt kwam uiteraard ook aan bod. Zo bracht prof. K. Buys van de Katholieke Universiteit
Leuven een uiteenzetting over de doelen en mogelijkheden van de Ethercat-technologie.

2.2 Onderzoeksprobleem
In de mechatronicasector streeft men naar een multidisciplinaire aanpak van het begin van
een project. In combinatie met mechanica, informatica en elektronica proberen we een
product of machine te ontwikkelen met betere prestaties en tegen een interessantere prijs.
De grote uitdaging in deze sector is de geïntegreerde virtualisatie. Via deze weg komen we tot
één virtueel prototype van een systeem, waarbij de kansen op misinterpretatie van de
systeemvereisten worden geminimaliseerd.
Het ontwerpproces doorloopt de volgende stappen:
 Probleemanalyse, opstellen van de benodigdheden
 Iedere afdeling (EM, EA, TI) werkt apart aan de volgende processen:
o Uitwerken deelontwerp
o Realiseren deelontwerp
o Testen deelontwerp
 Totale systeemintegratie
LabVIEW, Matlab/simulink
Vmware, Eclipse
SolidWorks
Control
Design
Mechanical
Design
Embedded
hardware/
Software Codesign
System
Specification
Prototype
Prototype
Prototype
Virtual
Prototype
Multisim, Spice
Electrical
Design
Prototype
Figure 2-3: Mechatronics design parallel approach

De stap naar virtualisatie en simulatie voordat het fysiek prototype wordt gelanceerd, heeft als
voordeel dat men er in een vroeg stadium het gedrag van de machine kan simuleren en testen.
Zo kan men vroegtijdig fouten opsporen en oplossen, aangezien aanpassingen aanbrengen
tijdens de fysische opbouw meer kosten zal teweegbrengen.
2.3 Uitdagingen
Een mechatronica gebaseerde aanpak kan de risico’s verlagen die geassocieerd worden met
machine design en op die manier voldoen aan de volgende, voornaamste uitdagingen
waarmee machine ontwerpers de dag van vandaag worden geconfronteerd.
Machine ontwerp proces is serieel en traag
Bij een typisch machineontwerp gaat men eerst het mechanische ontwerp tekenen en
bouwen; daarna zal het controle- en elektrisch systeem geïmplementeerd worden op de
machine en zal men beginnen met de eerste test-run op het fysieke model. Het nadeel van
deze methode is dat er tijdens dit testen meestal aanpassingen moeten worden aangebracht,
wat kan leiden tot vertragingen en oplopende kosten. Dit risico kan men verlagen door al
vroeg in het proces control en elektrische engineers in te schakelen. Daarom lost een
mechatronica gebaseerde aanpak dit probleem op door eerst een virtueel prototype te maken
alvorens de fysieke machine te bouwen.
Communicatie tussen klant en het design team
De vraag van de klant verwerken en hiervan een geschikt design voor de machine ontwerpen
kan een lang en ingewikkeld proces zijn. Slechte communicatie met de klant kan leiden tot een
ongeschikt design, waar nog veel aanpassingen aan moeten gebeuren. Hierdoor zal de prijs
ook stijgen. Door een virtueel model te creëren kan het team de klant tonen hoe de machine
zal functioneren voordat er daadwerkelijk aan een fysiek model gewerkt wordt.
Physical
Prototype
Manufacturing
Test System
Design
Manufacturing
Support
and service
Sustaining
Engineering
Virtual
Prototype
Vervolg figuur 2.1

Motion profile controle vereist het fysiek testen van de machine
Het debuggen van motion profiles op de werkelijke machine kan riskant zijn. Onderdelen
kunnen ongewenst met elkaar in contact komen en daardoor beschadigd raken, wat leidt tot
stilstand en verhoogde kosten voor nieuwe onderdelen. Door de integratie van motion profiles
gegenereerd in LabVIEW met een 3D-CAD-model van de machine in SolidWorks kan het team
mogelijke botsingen detecteren in het virtuele prototype. Door deze foutjes aan te passen en
het motion profile te fine-tunen kunnen we mogelijke botsingen aan de werkelijke machine
vermijden.
Nauwkeurig dimensioneren van motoren
Door de complexiteit van motoraandrijvingen kan het kiezen van een motor met optimale
grootte, kost, gewicht en prestatie voor een bepaalde toepassing zeer uitdagend zijn. Een te
kleine motor kan bv. leiden tot oververhitting, slechte regeling enz. Als een motor daarentegen
te groot is zal hij onnodig gewicht en kosten aan de machine toevoegen. Door gebruik te
maken van virtueel machine prototype zal de keuze van een gepaste motor vlotter verlopen.
Met LabVIEW en SolidWorks kan het team makkelijk het benodigde koppel bepalen voor het
aandrijven van de machine met het gewenste motion profile.

3 Tools
In dit project wordt op kleinere schaal een mechatronica robotopstelling gebouwd.
De volgende tools worden hiervoor gebruikt:
 NI LabVIEW
 SolidWorks
 Android ontwikkelingsoftware (Eclipse)
3.1 SolidWorks
Om het mechanisch ontwerp te realiseren, wordt er beroep gedaan op het 3D CAD
tekenprogramma SolidWorks. Met SolidWorks worden alle onderdelen van de robot als parts
getekend, om ze nadien in één assembly te gieten. Deze assembly wordt in het project
gebruikt om de beweging van de robot te simuleren. Een assembly verkrijg je door 2
onderdelen te positioneren, relatief ten opzichte van elkaar. Dit gebeurt met zogenoemde
“Mates”. In deze Mates kunnen we bepalen of een specifiek onderdeel mag bewegen of niet
(zoals de assen van de wielen).
De premium versie van SolidWorks die ons ter beschikking is gesteld, is in staat om
verschillende bewegingen, krachten, contacten, motoren e.d. te simuleren. Dit onderdeel van
SolidWorks heet SolidWorks Motion Simulation en hiermee kan men verschillende Motion
Studies aanmaken om zo de gewenste onderdelen te simuleren, zoals de wielen op de robot
laten draaien, die in contact staan met de ondergrond.
In combinatie met LabVIEW wordt de gewenste snelheid en beweging van de wielen
gesimuleerd. Deze koppeling tussen LabVIEW en SolidWorks wordt gerealiseerd door de
Softmotion software van LabVIEW (zie 3.2.1 Softmotion voor verdere informatie).
3.1.1 Motion Study
In bijlage 1 ziet u een voorbeeld van een Motion Study in SolidWorks. De Motion Study biedt
vele mogelijkheden om het design te laten werken als een fysiek model.
Zo kunnen we zwaartekracht toevoegen aan het model en een 3D-contact tussen de wielen en
de ondergrond simuleren. Ook het bewegen van de wielen kan gesimuleerd worden: dit kan
door de 4 assen apart als motor te laten functioneren. Aangezien we bij het 3D contact de
wrijving tussen de 2 componenten (grond en wielen) hebben kunnen specifiëre, zal de motor
vooruit bewegen (of achteruit, roteren enz.: dit is afhankelijk van de draaizin die je aan de
motoren wilt geven).

3.2 LabVIEW
Met LabVIEW wordt de embbeded software voor de robot geschreven.
LabVIEW is een grafische programmeeromgeving. Het programma dat hierin wordt geschreven
communiceert met de motoren, sensoren e.d. die op de robot zijn gebouwd. Ze wisselen data
uit en aan de hand daarvan wordt de robot in de gewenste richting bewogen en met de
gewenste snelheid.
LabVIEW is een programma ontwikkeld door National Instruments. Het is een zeer uitgebreid
programma waarmee bijna alles mogelijk is. Het maakt gebruik van de taal G en is een
grafische programmeeromgeving. Het voordeel aan een grafische programmeeromgeving is
dat dit een beter zicht geeft op het verloop van het programma, daardoor wordt het ook
makkelijker om het programma te debuggen. Het programma werkt hoofdzakelijk met twee
vensters, dit zijn het front panel en het block diagram. Het front panel is het scherm dat de
uiteindelijke gebruiker van het programma te zien zal krijgen. Dit wordt ook wel eens de GUI
genoemd. Hierop kunnen verscheidene knoppen en tekstboxen ingevoerd worden, waardoor
het mogelijk wordt voor de gebruiker om waardes of tekst in te voeren. Verder kunnen hier
ook tekstboxen en meters geplaatst worden, waardoor de gebruikers waardes en tekst
gegenereerd door het programma eenvoudig kunnen aflezen.
Het block diagram wordt gebruikt om het eigenlijke programma in te voeren. We hebben
reeds vermeld dat het om een grafische programmeeromgeving gaat, en dit wil zeggen dat het
programma voornamelijk zal bestaan uit met elkaar verbonden blokjes met elk hun eigen
functie. Naargelang de features die geïnstalleerd werden samen met de installatie van
LabVIEW zullen er hier ook meer blokken en functies ingevoegd kunnen worden. Met LabVIEW
is het mogelijk om je programma te laten uitvoeren in de volgorde die je zelf wil, en op
tijdstippen die zelf bepaald kunnen worden. Het programma voorziet wiskundige functies,
digitale logica en zelfs tekstbewerking is mogelijk. Indien nodig kunnen de waarden in een
Excelbestand geplaatst worden, zodat ze in mooie tabellen gegoten kunnen worden. Het grote
voordeel van deze programmeeromgeving is dat het in veel verschillende werelden thuis is.
Hiermee wordt bedoeld dat het in elke toepassing wel gebruikt kan worden. Voor veel
toepassingen zitten er zelfs al kant en klare blokken tussen, die enkel nog aangesloten en juist
afgesteld moeten worden op de toepassing en dan onmiddellijk gebruikt kunnen worden. Dit
heeft het voordeel dat je niet altijd vanaf nul moet beginnen.

Dat deze programmeeromgeving zo eenvoudig in gebruik is, is niet de enige reden waarom het
gebruikt werd. Het programmeerplatform dat gebruikt wordt, de sbRIO, is een product van
National Instruments, het wordt voornamelijk geprogrammeerd met LabVIEW. Om de FPGA en
Real-Time componenten van de sbRIO te gebruiken is het wel nodig om deze plug-ins ook te
installeren op de pc waarop het programmeergebeuren plaatsvindt, en ook al de drivers die
nodig zijn voor de ondersteuning van de sbRIO.
3.2.1 Softmotion
De Softmotion software van LabVIEW zorgt ervoor dat we de Motion Study van SolidWorks
kunnen aansturen.
LabVIEW zorgt voor de Motion Control Signals voor iedere gespecificeerde as in de SolidWork
robot assemby. In totaal zijn er 4 assen die aangestuurd worden via LabVIEW (4 wielen). En als
tegenprestatie stuurt SolidWorks de actuele snelheid en positie gedurende de simulatie terug
naar LabVIEW. Door deze feedback-informatie van SolidWorks te gebruiken kunnen we het
gewenste controle algoritme toepassen.
Door gebruik te maken van NI Softmotion software om uw design te simuleren met werkelijke
motion profiles kunnen we de mechanische dynamiek van het design simuleren, waaronder
massa en wrijving effecten, cyclustijden, prestaties van afzonderlijke componenten,… en dit
allemaal zonder een fysiek onderdeel te specifiëren en dit te connecteren met een
daadwerkelijk controle algoritme.
Positie en snelheid
Motion Control Signals

Enkele typische toepassing van de NI Softmotion software:
 Motion trajectory design
Het bouwen van verschillende motion profiles met een reeks sequentiële of
gelijktijdige bewegingen bestaande uit meer assige rechtlijnige bewegingen, contour
bewegingen, boog bewegingen,…
 Visualisatie
Door het animeren van de SolidWorks assembly met de motion profiles en timing logic
die je hebt geprogrammeerd in LabVIEW kan je snel de haalbaarheid van het gehele
conceptueel design controleren
 Detectie botsingen
Deze feature controleert eventuele botsingen in het design ontwerp of zorgt voor de
nodige vergrendelingslogica om deze botsingen te voorkomen
 Time studies
Berekenen van cyclustijd van de machine of design
 Bepaling motor, aandrijving
Calculeren van de motorkoppel en snelheidsgrafieken voor de motion profiles

3.3 Eclipse
3.3.1 Software Development Kit
Eclipse is een software ontwikkelingstool, geschreven in Java die meerdere programmeertalen
ondersteunt. Binnen het MSD project wordt Eclipse gebruikt omdat het als geïntegreerde
ontwikkelomgeving voor de Java programmeertaal dient. In het Android hoofdstuk kan u lezen
dat de Dalvik VM Java bytecode vertaalt naar zijn eigen dex-code, wat Eclipse ideaal maakt.
Daarnaast is het uiteraard ook mogelijk om het standaardpakket uit te breiden aan de hand
van plug-ins.
Figure 3-1: Eclipe Logo
3.3.2 Android Development Tools
Een van de plug-ins ontwikkelt voor Eclipse die we gaan gebruiken is die van Android. Dankzij
deze plug-in, ADT genaamd, kan de ontwikkelaar snel van start gaan met een nieuw Android
project. De ontwikkelaar kan via XML snel een GUI definiëren en deze verder programmeren.
Bovendien biedt de ADT een XML editor waar je naast het vormen van je UI, door simpelweg
te werk te gaan met drag & drop, ook je resultaat kan bekijken zonder heel je programma
nodeloos te laten runnen. Tot slot voorziet men nog de Android Device Manager, hiermee kan
je virtueel een Android toestel nabootsen in een emulator.

4 Mechanisch design
Figure 4-1: Basisplatform rover 5
Het robotplatform waarvoor gekozen werd is de Rover 5 van Sparkfun Electronics. Voor dit
project werd er gekozen voor de versie met vier motoren en vier quadrature encoders.
Dit platform wordt uitgebreid met mecanum wielen (i.p.v. de rupsbanden) een IP-camera, een
router voor de verbinding met het netwerk, batterijen en enkele naderingssensoren.
Door gebruik te maken van een Single-Board Rio (meegeleverd bij het basisplatform) van
National Instruments bestaande uit een real-time processor, een FPGA-module en analoge en
digitale I/O kunnen we de motoren sturen en de sensoren inlezen. Deze sbRIO wordt
geprogrammeerd d.m.v. LabVIEW. Verder wordt er voor de sturing van de 4 motoren een op
maat gemaakte circuitboard vervaardigd dat de juiste spanning en stroom naar deze motoren
zal sturen. De quadrature encoders ingebouwd in de behuizing van de motoren zorgen ervoor
dat de snelheid waarmee de wielen kunnen draaien uitgelezen wordt. Later in deze scriptie zal
u meer kunnen lezen over de juiste werking van deze encoders.
De robot zelf bestaat volledig uit kunststof. Dit zorgt ervoor dat de robot zonder batterijen en
andere toebehoren ook niet zo heel veel weegt en door de juiste aansturing van de motoren
toch nog een redelijke snelheid kan behalen. Volgens de datasheet van de robot zou deze in
onbeladen vorm een snelheid van ongeveer 1 km per uur moeten halen. De robot wordt
echter geladen met bovengenoemde onderdelen. Dit heeft een aanzienlijk gewicht
toegevoegd aan de robot waardoor de effectieve snelheid uiteindelijk toch een stuk lager lag.
Dit alles wordt goed bevestigd door een frame dat uitgetekend werd op SolidWorks.

4.1 Robot
Zoals eerder al verteld werken we met het basisplatform Rover 5. We moeten er voor zorgen
dat alle onderdelen mooi op het platform kunnen worden geplaatst. Daarom worden alle
stukken eerst getekend op SolidWorks. Als alle onderdelen getekend zijn kan er gekeken
worden hoe ze het best op de robot geplaatst worden en kunnen er bevestigingen getekend
worden voor de ophanging van alle onderdelen.
Figure 4-2: CAD-tekening robot
In bijlage 2 kunt u de 3D tekening met alle onderdelen bekijken.

4.2 Mecanum wielen
Conventionele wielen zijn mechanisch zeer simpel en zijn eerder beperkt in hun beweging.
Daarom is er in dit project besloten om met mecanumwielen te werken, omdat dit wiel in alle
richtingen (omni-directioneel) kan bewegen. Het mecanumwiel is gebaseerd op het principe
van een centraal wiel met een aantal “rollers” geplaatst in een hoek (45° in ons geval) rond de
omtrek van het wiel. Deze rollers kunnen vrij ronddraaien in deze opstelling. De centrale
bevestiging zoals in onderstaande figuur heeft als voordeel dat enkel de rollers contact maken
met het oppervlak en het wiel nooit de grond zal raken.
Figure 4-3: Mecanum-wiel met 6 centraal gemonteerde rollers
4.2.1 Werking
Om de omni-directionele beweging te verkrijgen, zijn de wielen geplaats op de robot volgens
figuur 3-4. Zoals je ziet vormen de rollers op de mecanumwielen een kruis als je ze van
bovenad bekijkt. Om snelheidsberekeningen uit te voeren en krachten-vectoren te bepalen,
bekijken we echter het contact tussen de wielen en de grond en dan kijken we naar de
onderste helft van de wielen.
Afhankelijk van de draairichting van de motor zullen de wielen altijd een voorwaartse kracht
of een achterwaartse kracht produceren, alsook een inwaartse of uitwaartse kracht
veroorzaakt door de 45° verdraaide rollers. Afhankelijk van de combinatie van deze krachten
kan de robot bewegen in elke mogelijke richting.
Roller

Figure 4-4: Opstelling mecanumwielen bovenaanzicht
Zijdelings bewegen links & rechts (strafing)
Als men de beweging op figuur 4-5 wil verwezenlijken moet men de wielen aan de linkerkant
naar elkaar toe laten draaien en de wielen aan de rechterkant van elkaar weg. De wielen
moeten tegen dezelfde snelheid bewegen zodat er geen slip optreedt bij het naar links
bewegen.
Figure 4-5: Left strafing
12
3 4

Diagonaal bewegen
Wilt men echter diagonaal bewegen dan moet men zoals aangegeven in figuur 4.6 het voorste
wiel en het diagonaal tegenovergestelde achterste wiel tegen eenzelfde snelheid laten
bewegen, terwijl het andere paar wielen tegen een andere snelheid draait. Om perfect 45°
diagonaal te bewegen, moet de snelheid van 1 paar diagonale wielen nul zijn (zoals aangeduid
in figuur 4-6).
Figure 4-6: Diagonaal beweging met mecanum wielen
In punt 3.4.4 kan u aan de hand van een krachtenanalyse de beweging beter leren begrijpen.
Natuurlijk kan je ook gewoon roteren rond het middelpunt, vooruit en achteruit rijden.
Aangezien de wielen zich in deze beweging gedragen als een gewoon conventioneel wiel wordt
hier verder niet op ingegaan.

4.2.2 Ontwerp
Als je ervoor wil zorgen dat de beweging van de robot zonder schokken gepaard gaat moeten
de mecanumwielen een perfecte cirkel vormen. Om de zogeheten “bump-less” (zonder
schokken) mecanumwielen te creëren moet er aan deze 2 voorwaarden voldaan worden:
 Het contactoppervlak van de rollers moet overlappen.
 Het contactoppervlak van de roller moet steeds overeenstemmen met de straal van
het wiel.
Figure 4-7: Zijaanzicht mecanumwiel (cirkel)
Het contactoppervlak laten overlappen, kan makkelijk worden verkregen door de mecanum
wielen lang genoeg te maken, zodat de overgang van de ene roller naar de andere mooi op de
omtrek aansluit.
Om ervoor te zorgen dat het profiel van de roller steeds het contact oppervlak met dezelfde
straal raakt moet de roller een speciale vorm hebben. Het profiel van de roller heeft namelijk
een parabolische vorm. Aangezien het in SolidWorks perfect mogelijk is om een functie in te
geven die daarna de parabool voor mij tekent, ga ik op zoek naar de geschikte formule. De
formule wordt in de vorm van y=r-ax^2 geschreven, waarbij y de straal is van de roller op een
afstand x van het middelpunt van de roller. De straal r van de roller is gegeven, zodat er nu nog
enkel een waarde voor a berekend moet worden.

Berekening van a:
R = straal van het mecanumwiel
r = straal van de roller in zijn middelpunt
L= lengte van de roller
Gebruik volgende berekeningen om “a” te vinden:
D=R-r
√ ( )
√ ( )
√
4.2.3 Kinematische analyse
Om dit te analyseren moet je je voorstellen dat de bovenste helft van het mecanumwiel (wiel
nummer 1 als voorbeeld) transparant is en er enkel contact gemaakt wordt met de onderste
helft van het wiel. Het patroon op figuur 4-8 toont het contact dat de rollers maken met de
grond in die voorstelling. Als je nu de opstelling van dit wiel 1 vergelijkt met de opstelling in
figuur 4-4, dan zie je dat de richting is omgedraaid.
Figure 4-8: Contact rollers met grond
1
Chassis
Motor-as

Inverse kinematic oplossing
Om de snelheid van de wielen te bepalen, wordt eerst de totale beweging van de robot
gedefinieerd en met die gegevens kunnen we de snelheid van elk wiel bepalen.
Uiteindelijk verkrijgen we een vergelijking om de hoeksnelheid van de 4 onafhankelijke wielen
te berekenen die nodig is om een gewenste snelheid en rotatie van de robot te verkrijgen.
Figure 4-9: Contact rollers met grond, gebruikt voor de kinematische en krachten analyse
1 wiel
Vectoriële aanpak: ⃗ ⃗⃗⃗⃗ ⃗⃗⃗ ⃗
Scalaire aanpak:
12
43
Figure 4-10: Snelheden 1 wiel vectorieel

Zoals vooraf gezegd moet je vanaf de onderkant de rollers
bekijken (figuur 4-8).
Om de snelheid van het wiel te bepalen wordt
deze opgesplitst in 2 componenten.
Snelheid parallel met het wiel en snelheid parallel met de
roller.
Roller
Snelheid oplossen in componenten parallel en loodrecht
t.o.v. de roller aslijn.
De loodrechte snelheid kan verworpen worden.
|⃗⃗⃗⃗⃗| ⃗ ̂
̂ ̂ (
√
̂
√
̂)
√ √
Eenheidsvector û is niet hetzelfde voor elk wiel
Wiel
Gebruik de component parallel t.o.v. roller aslijn (berekend in
het vorig puntje) en los deze op in een component parallel
t.o.v. het wiel en loodrecht t.o.v. de roller.
Aangezien de hoek tussen ⃗⃗⃗⃗⃗ en ⃗⃗⃗⃗⃗ 45° bedraagt, kunnen
we |⃗⃗⃗⃗⃗⃗| direct berekenen.
|⃗⃗⃗⃗⃗|
|⃗⃗⃗⃗⃗|
√ (
√ √
)

Voorbeeld
Als voorbeeld zullen we de snelheid van wiel 3 op figuur 3-10 berekenen.
√
̂
√
̂
|⃗⃗⃗⃗⃗⃗⃗⃗| √ (
√ √
)
Op dezelfde wijze kan nu de snelheid van de 3 andere wielen berekend worden:
|⃗⃗⃗⃗⃗⃗⃗⃗|
|⃗⃗⃗⃗⃗⃗⃗⃗|
|⃗⃗⃗⃗⃗⃗⃗⃗|

4.2.4 Krachten vector analyse
Om de beweging van de robot beter te leren begrijpen kan je het best werken met
krachtvectoren. Door de aanwezigheid van de rollers worden er extra krachten ontwikkeld die
zorgen voor de omni-directionele beweging.
Figuur 4-11 geeft het onder aanzicht weer van wiel 1 dat in contact staat met de grond en de
krachten die daardoor worden verkregen. De vectoren in deze voorstelling zijn getekend bij
een voorwaartse beweging van het wiel. Resulterende kracht Fc kan opgedeeld worden in de
voorwaartse kracht van het wiel zelf (Ff) en een zijwaartse kracht (Fs).
Figure 4-11: Krachtenvectoren mecanumwiel
De groen vector Fc is de reactiekracht van de vloer op de onderkant van de mecanum roller die
in contact is met de vloer. We nemen aan dat er geen wrijving is op de assen van de rollers

4.2.4.1 Voorwaartse beweging
Zoals eerder vermeld hebben we 2 krachten die door het mecanum wiel gecreëerd worden
Bij een voorwaartse beweging nemen we aan dat de 4 wielen in dezelfde zin en aan dezelfde
snelheid draaien. De voorwaartse kracht Ff is dus gelijk bij de 4 wielen. We nemen aan dat we
een constante snelheid hebben waardoor Ff gelijk moet zijn aan . Waarbij “T” het
aandrijfkoppel aan het mecanum wiel is, en “R” de straal van het wiel
Als we figuur 4-12 bekijken kan je zien dat de zijwaartse kracht Fs op wiel 1 tegengewerkt word
door een tegenovergestelde kracht door wiel 2 van dezelfde grootte waardoor de resulterende
kracht nul is. Hetzelfde geld voor de wielen 3 en 4. De enig overblijvende kracht is de kracht Fs
in de draairichting van de wielen.
Figure 4-12: Voorwaartse beweging krachtenanalyse
Fs
Ff
Fc
14
3 2
frontback

4.2.4.2 Zijwaartse beweging “Strafing”
Bij de zijwaartse beweging wordt enkel de draairichting van de wielen veranderd. Wiel 1 en 4
draaien van elkaar weg en wiel 3 en 2 draaien naar elkaar toe. Het koppel voor de wielen blijft
hetzelfde als de voorwaartse beweging. Hier wordt Ff gecompenseerd door een kracht van
dezelfde grootte maar in tegengestelde zin, dit maal spreken we over de wielen 1/4 en de
wielen 2/3.
Nu zien we dat de kracht Fs bij elk wiel in dezelfde richting wijst, en door de 45° verdraaide
rollers zal deze kracht Fs even groot zijn als Ff.
Daarom kan je besluiten dat snelheid van de robot bij een zijwaartse beweging en een
voorwaartse beweging even groot zal zijn.
Figure 4-13: Strafing krachtenanalyse
Fs
Ff
Fc
4
3 2
1
frontback

4.2.4.3 diagonale beweging
We nemen aan dat we de robot 45° diagonaal willen laten bewegen
Om dit te verkrijgen worden wielen 1 en 3 aan hetzelfde koppel aangedreven terwijl wiel 2 en
4 aan een ander koppel. In dit geval is het koppel van wiel 2 en 4 nul omdat we een beweging
45° willen verkrijgen.
Zoals je kunt zien op figuur 4-14 hebben we geen tegenwerkende krachten. Fs en Ff worden bij
elkaar opgeteld en de resulterende kracht is 45° gericht en we verkrijgen diagonale beweging.
Figure 4-14: Diagonale beweging
4.2.5 Nadelen
Ondanks de veelzijdigheid van het standaard mecanumwiel zijn er ook een paar nadelen aan
verbonden, die de efficiëntie van het wiel reduceren. De rollers van het wiel brengen een deel
van de motorkracht over in een kracht die loodrecht of onder hoek t.o.v. de motorkracht staat.
Hierdoor verliest men een groot deel van de kracht in een bepaalde richting dankzij de
resulterende kracht van de rollers. Een goed voorbeeld hiervan is wanneer we een diagonale
beweging willen realiseren, hierbij zorgen de rollers van de niet draaiende wielen een remming
die die motor moet overwinnen
Verder zijn de wielen conceptueel redelijk complex en hebben ze minder duwkracht bij
zijdelingse beweging. Je hebt ook natuurlijk 4 motoren nodig om ieder wiel apart aan te sturen
Fs
Ff
Fc
3
1
2
4
frontback

4.3 Implementatie
In dit gedeelte zal er toegelicht worden hoe er tewerk is gegaan met de verschillende tools die
doorheen het stageproject gebruikt werden voor het gedeelte van de virtualisatie van de robot
in SolidWorks m.b.v. een sturing via LabVIEW.
Vooraleer het fysiek ontwerp van de robot gebouwd werd, is er een virtueel model getekend
van het platform op SolidWorks.
Om de SolidWorks solver in de Motion Study zo min mogelijk te belasten, d.w.z. veel parts en
verschillende assemblies, is het design voor de robot enkel getekend met de mecanum wielen.
Zie figuur 4-15 voor het gebruikte model voor de simulatie
Figure 4-15: Virtueel model rover 5
4.3.1 Motion Study
In de Motion Study van SolidWorks wordt er gedefinieerd welke onderdelen een bepaalde
beweging moeten ondergaan m.a.w. we bepalen hoe de robot zal reageren in de omgeving.
De tabbladen onderaan figuur 4-16 zijn verschillende motion studies. Je kan er verschillende
maken elk met de gewenste instellingen.
Figure 4-16: Motion Study

Gravity
Met behulp van deze optie voegen we zwaartekracht aan het SW model toe. Hierdoor zorgen
we dat het model tegen de vloer wordt geduwd. We stellen de zwaartekracht in de Y-richting
van het XYZ assenstelsel van het referentieframe zo wordt er altijd een kracht boven en
loodrecht op de robot uitgeoefend.
We moeten er wel voor zorgen dat er een vlak aanwezig is waarop de robot kan rijden. Dit kan
gebeuren door een extra part in de assembly te voegen en deze dan vast te zetten om te
voorkomen dat deze ook naar beneden valt
3D contact
Met deze functie zorgen we voor een 3D-contact tussen de geselecteerde onderdelen om te
voorkomen dat de onderdelen elkaar penetreren tijdens de beweging. In dit geval zijn dat de
rollers op de mecanum wielen en het vlak waarop de robot rijdt. Eens we deze onderdelen
hebben gespecifieerd kunnen we een gewenste wrijving tussen deze onderdelen instellen. Zo
kan men waardes voor de dynamische en statische wrijving instellen. Een andere functie
binnen dit 3D-contact zijn de elastische eigenschappen. Hierin specifiëren we de stijfheid,
demping en penetratie van de onderdelen die in contact met elkaar komen te staan.
Motor
De laatste instelling om de robot te laten bewegen is de functie “motor” binnen de Motion
Study. In deze functie kan je kiezen tussen een roterende motor of een lineaire motor.
Natuurlijk kiezen wij hier voor een roterende motor aangezien we de draaiende beweging van
de motoren moeten simuleren. We specifiëren 1 motor per as in de assembly, dus in totaal
hebben we 4 motoren. Binnen deze optie kan je ook het type beweging selecteren
(verplaatsing, constante snelheid, ...). Wij kiezen hier voor de optie verplaatsing aangezien we
bij de simulatie via LabVIEW deze instelling moeten gebruiken. Bij verplaatsing wordt een
gewenste hoekverplaatsing van de motor in een bepaalde tijd ingesteld.

4.3.2 Implementatie Softmotion en LabVIEW
Voordat we beginnen met het LabVIEW programma te schrijven met de gewenste motion
profiles moeten we bepaalde informatie van de SolidWorks assembly doorsturen naar het
LabVIEW project zoals: het toevoegen van de SolidWorks assembly en de motorassen gebruikt
in de Motion Study van SolidWorks
4.3.2.1 Toevoegen van de SolidWorks assembly
Eens het virtueel model getekend is in SolidWorks kunnen we deze tekening toevoegen in het
LabVIEW project. Als je verschillende motion studies in SolidWorks hebt gemaakt kan je de
gewenste Motion Study kiezen om toe te voegen aan het project. Zoals je ziet in figuur 4-17
worden automatisch de motoren die we hebben bepaald in de SolidWorks Motion Study
toegevoegd aan het project
Figure 4-17: SolidWorks assembly in LabVIEW project

4.3.2.2 Toevoegen van assen
Als we de motoren van de SolidWorks assembly willen simuleren moeten we deze motoren
koppelen aan de Softmotion software, dit doen we door het toevoegen van NI Softmotion
axes. Deze axes worden gebruikt voor het sturen van de Softmotion function blocks in het LV
programma. In figuur 4-18 zien we de axis manager waar we de 4 assen toevoegen die
gebruikt zijn in SolidWorks. Bij “Bound Hardware” in de axis manager zie je de
corresponderende motoren die in de SolidWorks Motion Study zijn gebruikt.
Figure 4-18: Axis Manager Softmotion
Eens deze assen zijn toegevoegd moeten er nog wat instellingen aangepast worden. Aangezien
in deze simulatie de assen niet gekoppeld zijn met werkelijke hardware is er niet veel
configuratie nodig. Nadat de simulatie is opgesteld kan je gemakkelijk deze instellingen
aanpassen zodat ze werken met de definitieve hardware.
4.3.2.3 Motion profiles in LabVIEW
In LabVIEW creëren we motion profiles om de SolidWorks assembly te simuleren, dit door
middel van de Softmotion function blocks. De function blocks die voor het project zijn gebruikt
om de motoren aan te sturen zijn de straight line move, een read status block en een stop
move block
Op figuur 4-19 kan je de gebruikte blocks bekijken. Zie bijlage 3 voor het LabVIEW programma
dat gebruikt is voor de simulatie.

Figure 4-19: Softmotion function blocks
Motion Resource
De verschillende assen die we in het begin van het LabVIEW project hebben aangemaakt
worden in het LV programma gebruikt om het juiste function blokje aan te spreken
Stop Move
Met de stop move kunnen we de huidige beweging van de motor-as stoppen d.w.z. wanneer
de execute input van het blokje “true” wordt zal de motor-as stilgelegd worden. Je kan in de
opties van het function blokje bepalen op welke manier de as stilgelegd word (onmiddellijk,
vertraagd, as uitschakelen)
Straight-Line Move
Deze function block voert een lineaire beweging uit op een as die we hebben gebruikt in het
project. De lineaire beweging kan gebaseerd zijn op positie of snelheid. In het programma is er
gebruik gemaakt van een snelheid gebaseerde beweging.
Bij deze beweging zal de as bewegen aan een opgegeven snelheid tot er een Stop Move wordt
uitgevoerd, een bepaalde limiet is bekomen of als men de as aan een andere snelheid wil laten
draaien. De draaizin van de as wordt bepaald door het teken (positief of negatief) van de
opgegeven snelheid
Read
Deze functie leest de status en verschillende data van de assen uit de SolidWorks simulatie
wanneer deze assen in beweging zijn. Enkele gegevens die uitgelezen worden in het
geschreven programma zijn: de actuele snelheid in graden per seconden en de positie in
graden. Verder kunnen we ook de gegenereerde koppel van de as lezen uit de SolidWorks
simulatie en nog enkele parameters zoals het aantal gegenereerde stappen voor de as.

4.3.2.4 Steering frame in LabVIEW
Een belangrijk onderdeel bij de mecanum wielen is de juiste sturing van de wielen in de juiste
richting en snelheid. Dit kan allemaal via de robotics module van LabVIEW gerealiseerd
worden. Met de juiste function blocks kunnen we de snelheden van de 4 wielen bepalen
wanneer we de robot in een gewenste richting willen sturen.
In bijlage 3 kan u op het block diagram de gebruikte function blocks bekijken
Eerst specifiëren we het stuurframe van de robot met mecanum wielen. We voegen 4 wielen
toe (1) met de gewenste straal (29mm) en overbrengingsverhouding (1 in ons geval). Deze
wielen bundelen we in een cluster (2) en sturen ze naar het mecanum steering frame blokje
(3). Bij het mecanum steering frame blokje specifiëren we nog de afstand (breedte en lengte)
tussen de 4 wielen (22cm op 17 cm).
Figure 4-20: Creëren van mecanum steering frame
1
3
2

Daarna specifiëren we een snelheid in het middelpunt van het steering frame door middel van
3 inputs: lateral, forward en angular velocity (1). Deze 3 snelheden converteren we naar 4
individuele snelheden voor de mecanum wielen d.m.v. het blokje “apply steering frame
velocity to wheels” (2). De 4 snelheden van de wielen (3) worden uitgedrukt in radialen per
seconden. Aangezien de input velocity van het straight-line move blokje (zie figuur 4-19)
snelheden in graden per seconde leest, wordt dit in het programma geconverteerd in graden
per seconden. Deze omzetting is als een sub VI in het LV programma geschreven om het
programma compact te houden.
Figure 4-21: Snelheid steering frame  individuele snelheid wielen
Ten laatste het blokje “steering frame picture” (5) zorgt ervoor dat we een afbeelding kunnen
genereren die het steering frame visualiseert. Deze afbeelding geeft vectoren weer in welke
richting en snelheid de wielen van de robot draaien. Zie bijlage 3 front panel voor deze
afbeelding.
1
2
3
5

4.3.2.5 Webservice
Webservices in LabVIEW geeft ons de mogelijkheid om met het LV programma te
communiceren op afstand over het netwerk/internet. De communicatie in dit eindwerk
gebeurd d.m.v. een android gsm.
De android applicatie spreekt de gegenereerde URL aan via een http GET methode.
Om deze URL te genereren gaan we als volgt tewerk:
 Bepalen van de inputs die de VI sturen
 Aanmaken van shared variables
De inputs die we gebruiken voor de VI te sturen zijn de 3 snelheden die de beweging van het
robot frame bepalen, en dit zijn: lateral, forward en angular velocity.
Van deze 3 inputs maken we een Variable in het LV project en stoppen ze in een Library zoals
je kunt zien in figuur 4-8
Figure 4-22: Variables en webservice in LV project
Vervolgens maken we een VI programma genaamd “variables” waar we de aangemaakte
Library met Variables in plaatsen en er een control op aansluiten (zie figuur 4-9). Deze controls
zullen aangestuurd worden door de URL die we later gaan genereren. Maar eerst moeten we
deze 3 controls connecteren met het aansluitpaneel in het LabVIEW programma zodat de
juiste URL wordt gegenereerd.
De variables die in het LabVIEW project zijn aangemaakt worden ook in het hoofd programma
gebruikt. Als je kijkt naar figuur 4-21 (1) worden deze 3 inputs vervangen door de 3 variables
die we hebben aangemaakt. Zo zal de URL deze inputs aanspreken met een waarde die
opgegeven is in de URL

Figure 4-23: Variables VI
De Web Service wordt geconfigureerd vanuit de “Build Specifications” in het LabVIEW project
(zie figuur 4-8). Hier bepalen we de naam voor de Web Service en de VI programma’s die
opgenomen moeten worden in de URL mapping. In dit geval wordt de VI “variables” gebruikt
die je kunt zien in figuur 4-8. De reden waarom de inputs gedeeld worden door 1000 is omdat
er geen kommagetallen in een URL kunnen worden geschreven
Een voorbeeld van de genereerde URL kan je bekijken op figuur 4-10
Figure 4-24: Webservice URL mapping
Als we nu ons LabVIEW programma willen aanspreken via het netwerk met een URL. Moeten
we deze als volgt formuleren:
http://localhost:8080/WebService/variables/500/0/500
De 3 inputs op het einde van de URL bepalen de waardes die naar het LabVIEW programma
gestuurd worden.
IP adres of naam computer
Poort
Naam Web Service
URL Mapping
URL Mapping Inputs (forward velocity)
(angular velocity)
(lateral velocity)

Figure 4-25: Volledig LabVIEW project
4.3.3 Beperkingen
Doorheen het project ben ik enkele problemen tegemoet gekomen die zorgde voor wat
beperking in de simulatie van de robot. Eén van die problemen was de omnidirectionele
beweging van de mecanum wielen.
Voor ik met het besturingsalgoritme in LabVIEW ben gestart vroeg ik me af of het mogelijk was
de omnidirectionele beweging in de Motion Study van SolidWorks te verkrijgen.
Maar dit bleek niet vanzelfsprekend te zijn. Na al de juiste parameters in te stellen zoals
3Dcontact, zwaartekracht en de motoren in de juiste richting te laten draaien bewoog de robot
nog steeds niet in de juiste richting. Na wat contact op verschillende forums en één
studiebureau lag de fout waarschijnlijk aan een beperking van SolidWorks zelf. In SolidWorks
wordt er gewerkt met rigid bodies waardoor er enkel een lijn of punt contact met het raakvlak
maakt. Waarschijnlijk is de resulterende krachtvector in de Motion Study fout waardoor de
robot niet in de gewenste richting beweegt.
Een ander probleem waar ik te maken had was tijdens het aansturen van de robot in
SolidWorks door het LabVIEW programma. Vanaf het moment dat de robot contact met de
ondergrond maakt, kreeg ik met een solver error van SolidWorks te maken (zie figuur 4-26)

Figure 4-26: SolidWorks error
Aanvankelijk dacht ik dat deze error werd veroorzaakt door een te complexe assembly van
SolidWorks of door de mecanum wielen en hun speciale vorm. Maar nadat ik de wielen
veranderde naar een normaal rond wiel en de assembly had vereenvoudigd kreeg ik nog
steeds dezelfde error, ook nadat ik de opgesomde puntjes in figuur 4-26 had aangepast.
Uiteindelijk heb ik besloten om robot vast te zetten in de SW omgeving en het 3D-contact en
gravity weg te laten vallen. Met deze opstelling heb ik geen problemen ervaren en kon ik de
wielen simuleren met de juiste snelheid en richting via het LabVIEW programma.

5 Elektronica design
5.1 Programmaplatform
Als programma-platform werd de sbRIO-9602
van National Instruments gekozen. Dit platform
werkt met een Real-Time processor en een
Spartan 3 FPGA. sbRIO staat voor single-board
reprogammable input/output. Dit wil zeggen dat
het programma dat draait op de FPGA altijd
opnieuw geprogrammeerd kan worden. Digitale
input/output betekent dat de input of output enkel uit bits kan bestaan. Dit wil zeggen dat als
we de motoren op een verschillende snelheid willen laten draaien, we PWM nodig zullen
hebben. Een ander voordeel aan de sbRIO, is dat deze een ethernetpoort heeft, en deze
volledig te programmeren en te besturen is via ethernet. Door het gebruik van een draadloze
router kunnen we dan verbinding maken met het toestel om het te programmeren. Als het
toestel eens geprogrammeerd is, kunnen we via een smartphone ook contact maken met de
router en de juiste coördinaten meegeven zodat de robot kan gaan rijden of sensorwaarden
uitgelezen kunnen worden.
De voeding voor deze printplaat moet tussen 19 en 30 volt liggen. Daarom hebben we gekozen
om drie LiPo-batterijen van 7,4 volt in serie te schakelen, zodat we op 22,2 volt uitkomen.
5.2 Sturing motoren
De rover 5 heeft vier motoren die op vol vermogen elk een stroom trekken van ongeveer één
ampère. Volgens de specificaties van de motoren zouden ze dan een snelheid moeten halen
van ongeveer 1 km/u. De motoren worden aangestuurd door middel van PWM-signalen. Dit
wil zeggen dat ze een signaal binnenkrijgen in de vorm van een blokgolf. De frequentie van
deze blokgolf zal altijd gelijk blijven, maar de duty-cycle van de motoren zal aangepast worden
aan de snelheid of de richting die de robot moet volgen. De duty-cycle is het percentage van
de tijd waarin de uitgang hoog is, en dus een signaal naar de motoren zal sturen. Door dit
percentage aan te passen zal de motor sneller of trager gaan draaien. Doordat al de motoren
apart aan te sturen zijn, is het mogelijk om de robot een bepaalde richting mee te geven. Dit
kan door hem gewoon opzij te laten gaan, maar dit kan ook door hem een bocht te laten
maken. Hoe dit juist zal gebeuren, zal later nog uitgelegd worden, bij de uitleg over het
programma in LabVIEW. Het programma dat in LabVIEW geschreven wordt, zal geüpload
worden naar de sbRIO, maar deze kan niet voldoende vermogen leveren om de vier motoren
Figure 5-1: National Instruments sbRIO-9602

op vol vermogen te laten draaien. Daarom werd er ook een extra PCB ontworpen die het
signaal omzet in een bruikbaar signaal voor de motoren.
Buiten deze motoren worden er nog twee extra motoren toegevoegd waarop elk een sensor
geplaats wordt.
5.3 Sensoren
In de robot zitten ook een aantal sensoren. Het robotplatform zelf werd geleverd met vier
quadrature encoders. Met deze is het mogelijk om de snelheid van elk wiel afzonderlijk uit te
lezen. Zo kan de snelheid van de robot berekend worden als hij recht vooruit of achteruit rijdt.
Als de robot een rare beweging maakt, kan men door deze sensoren ook kijken welke motor
niet het juiste aantal omwentelingen per minuut maakt.
Verder wordt de robot ook nog uitgerust met twee ultrasonische sensors waarmee de afstand
van een muur of ander project aangegeven kan worden. Indien de robot te dicht bij een object
komt, kan de robot automatisch gestopt worden. Zo wordt het onmogelijk om een aanrijding
met de robot te maken.
5.4 Printed Circuit board
5.4.1 National Instruments MultiSim en UltiBoard
Voor het ontwerpen van de printplaat werd er gekozen om gebruik te maken van de
programma’s MultiSim en UltiBoard van National Instruments. MultiSim is een programma
waarmee de schema’s die nodig zijn voor het ontwerpen van de printplaat getekend kunnen
worden. De schema’s die getekend worden in MultiSim worden dan geëxporteerd naar
UltiBoard. In UltiBoard is het mogelijk om de componenten op een printplaat te zetten en de
verbindingen tussen de verschillende componenten te maken door middel van de koperen
banen die men kan tekenen. Dit bestand wordt dan omgezet naar een bruikbaar bestand voor
de freesmachine die op de XIOS Hogeschool in Diepenbeek aanwezig is. De reden dat ik voor
deze programma’s gekozen heb, is omdat het de programma’s zijn waarmee we op school
hebben leren werken. Het nadeel aan het laten frezen van printplaten op school is dat de
printplaten die op school gemaakt worden van een niet zo goede kwaliteit zijn en de
copperbottom en coppertop niet met elkaar verbonden zijn, waardoor het moeilijk wordt om
componenten zoals IC’s te solderen.

5.4.2 Printed circuit board
Voor het aansturen van de motoren en het uitlezen van de sensoren is er een extra printplaat
nodig, omdat de sbRIO niet genoeg vermogen kan leveren om de motoren te laten draaien.
Bij het ontwerpen van de printplaat moest er rekening gehouden worden met enkele zaken. Zo
is de stroom die aan de motoren geleverd worden ongeveer één Ampère, dit wil zeggen dat de
banen van de printplaat breed genoeg moeten zijn om deze stroom te kunnen vervoeren.
Verder moet er op de printplaat ook gewerkt worden met verschillende spanningen, omdat de
H-brug voor de motoren een spanning vragen van vijf volt als spanning voor de logica en de
motoren pas hun maximum leveren met een spanning van zeven volt. De sensoren op de robot
leveren een signaal met een spanning van vijf volt, maar de spanning op de IO-poorten van de
sbRIO mag maar 3,3 volt bedragen. Deze IO-poorten kunnen een spanning van vijf volt aan,
maar er werd geopteerd van veilig te werken, zodat bij een afwijking van deze waardes er geen
schade kan aangebracht worden aan de sbRIO. Aangezien de sbRIO een vrij duur platform is en
de leveringstijden van dit platform nogal kunnen variëren, werd er ook gekozen om tussen
elke ingang en uitgang een galvanische scheiding te bouwen. Dit werd gedaan door er een
optocoupler tussen te plaatsen. Bij het kiezen van de componenten die op de printplaat
geplaatst moesten worden, werd er gekeken naar wat er al voor handen was en voor de rest
ook naar een goed evenwicht tussen prijs en kwaliteit.
Voor het aansturen van de motoren
werd er gekozen voor de L298 dubbele
H-brug. Deze H-brug bevat de nodige
logica om twee motoren apart aan te
sturen. Deze component heeft vier
inputs en outputs en twee enable-
ingangen.
De uitgangsspanning van deze H-brug ligt op minstens de ingangspanning vermeerderd met
twee en halve volt en mag maximum zevenenveertig volt zijn. Dit maakt deze H-brug ideaal
voor onze motoren.
Als optocoupler hebben we gekozen voor de Avago Technologies ACPL-847-000E. Dit is een
standaard-optocoupler met 4 verschillende kanalen. Hij werkt met vier verschillende leds en
vier aparte transistors. Dit geeft het voordeel dat je met één behuizing vier signalen met een
Figure 5-2: L298 H-brug

verschillende uitgangsspanning galvanisch kan scheiden. Op de printplaat is ook een 7833 te
vinden, deze wordt gebruikt om de spanningen van de sensoren om te zetten van vijf volt naar
3,3 volt. Dit is nodig omdat de ingangen van de sbRIO afgesteld zijn op een spanning van 3,3
volt. Ten laatste zijn er ook nog enkele weerstanden en condensators te vinden op de
printplaat. De weerstanden worden gebruikt om de stromen die door de leds van de
optocouplers gaan te beperken tot de maximum toegelaten stroom die de leds aankunnen.
Voor de ingangen van vijf volt zijn dit weerstanden van 750 Ohm en voor de ingangen van 3,3
volt zijn dit weerstanden van 390 Ohm. De condensators worden gebruikt voor de
ontkoppeling van de H-bruggen, zodat deze bij piekstromen de andere elektronica niet zullen
hinderen, deze hebben een waarde van 100 nano Farad. Hieronder is een afbeelding van de
printplaat te vinden.
Figure 5-3: Printplaat motorsturing en uitlezing sensoren
Er werd ook nog een tweede printplaat ontworpen, deze dient om de nodige
voedingsspanning van vijf volt voor de eerste printplaat, sensoren, router en webcam aan te
voeren. Deze printplaat bevat vier keer een 7805 met de nodige headers en condensatoren
voor de aansluitingen en de ontkoppeling van de in- en uitgangen. Deze printplaat werd op
een demoprint gemaakt. Hier werd een aparte printplaat voor gemaakt, omdat er in het begin
geopteerd werd om één omvormer die voor al de verschillende onderdelen vijf volt zou
leveren. Deze werd weggelaten omdat deze omvormer vrij duur was en de printplaat
goedkoper is. Een afbeelding van het schema dat gebruikt werd voor het ontwerpen van de
gaatjesprint kan je hieronder terugvinden.

Figure 5-4: Schema gaatjesprint 7805
5.5 Voeding
Aangezien het de bedoeling is dat de robot vrij
kan rondrijden zonder het gebruik van kabels
moet al de elektronica gevoed worden met
batterijen. De sbRIO moet gevoed worden met
een spanning tussen negentien en dertig volt,
de motoren mogen een maximum-spanning
van ongeveer zeven volt binnenkrijgen en de
sensoren, router en webcam werken allemaal
op een spanning van vijf volt. Daarom hebben we gekozen voor drie LIPO-batterijen van 7,4
volt die elk een capaciteit hebben van 2200 mAh. Hierdoor kunnen we gewoon de spanning
voor de motoren aftakken van een batterij, door de batterijen in serie te zetten kan de
spanning voor de sbRIO ook bereikt worden en de spanning voor de printplaat voor de
omzetting naar vijf volt kan ook afgetakt worden van een batterij.
Figure 5-5: Lipo 2200 mAh batterij

5.6 Router
Zoals hierboven reeds vermeld moet de robot
draadloos kunnen rondrijden. Daarom zijn we
op zoek gegaan naar een compacte draadloze
router die klein genoeg is om op de robot te
plaatsen. Dit is een zeer moeilijke opdracht,
aangezien de minimum-afmetingen voor een
router altijd groter bleek te zijn dan de
afmetingen van de robot. Daarom zijn we op
zoek gegaan naar een WiFi-bridge met
twee ethernetpoorten, zodat de sbRIO en
IPcam hierop aangesloten kon worden. Deze waren zeer moeilijk te vinden, en als deze al
gevonden werden, kostten deze gewoonlijk enorm veel geld. We hebben dan toch gekozen
voor een gewone router, en onze keuze is gegaan naar de D-Link Gigabit draadloze ethernet N-
router N300. Dit is een compacte router met ondersteuning voor het IEEE802.11b/g/n
protocol, dus deze ondersteunt ook de signalen die de smartphone uitzend.
5.7 IPcam
Tijdens het rondrijden met de robot willen we graag
een beeld van de omgeving waarin de robot rondrijdt
op het scherm van de smartphone te zien krijgen. Dit
omdat het dan ook mogelijk is om de robot vanuit
een andere ruimte te besturen zodat men hem ook
kan gebruiken in ruimtes waarin men zelf niet kan of
mag komen.
We hebben hiervoor eerst enkele test uitgevoerd met
een IPcam die in de school nog te vinden was.
Aangezien we hier geen beelden via een URL konden
bekijken en dit toch wel nodig was om de beelden in
dezelfde applicatie te bekijken als waarmee de robot bestuurd wordt zijn we opzoek gegaan
naar een andere IPcam. Hier is onze keuze opnieuw gegaan naar een IPcam van D-Link,
namelijk de DCS-930L. Dit is een vrij compacte IPcam, met een ingebouwde WiFi-antenne en
een RJ-45 poort, waardoor de IPcam ook met een kabel aan de router gekoppeld kan worden.
Figure 5-6: D-Link DIR-652 router
Figure 5-7: D-Link DCS-930L IP-cam

5.8 LabVIEW program sturing motoren
5.8.1 Doelstellingen
Vooraleer men begint met het programmeren van de robot, is het zeer belangrijk van de juiste
doelstellingen van het programma vast te leggen. Hierin moet juist beschreven staan wat de
robot moet doen wanneer hij een bepaalde invoer krijgt. Verder moet er ook feedback
gegeven worden aan de gebruiker van het programma, dit zijn de waardes die door de
verschillende sensoren worden waargenomen en ten laatste moet de robot ook kunnen
reageren op de waardes die hij binnenkrijgt, zoals een ultrasoon sensor die aangeeft dat de
robot zich zeer dicht bij een object bevindt, moet er voor zorgen dat de robot tot stilstand
gebracht wordt.
5.8.2 Uitwerking
Vooraleer de sensors van de robot degelijk gebruikt kunnen worden, moet de de robot in
beweging gebracht worden, dit is het eerste deel van het programma. De robot heeft vier
motoren, die elk in twee richtingen bediend kunnen worden. Dit wil zeggen dat er acht
uitgangen op de sbRIO nodig zijn om de robot te laten bewegen. Hier kunnen er echter maar
vier van tegelijk een waarde doorgeven aan de printplaat van de motorsturing. Dit is omdat
een motor niet vooruit en achteruit kan draaien in één keer. Om het ontwikkelen van het
programma simpel te houden om mee te beginnen werd er eerst een testomgeving gecreëerd.
Deze bestond uit een front panel met vier knoppen die elk een richting aangeven en een
invoerveld voor de duty cycle van het PWM signaal, deze bepaalt de snelheid van de motoren
en dus ook van de robot. Later wordt dit dan omgezet naar de besturing met de smartphone
die deze waardes zal doorgeven aan het programma.
In het block-diagram werd een standard state machine sjabloon ingevoegd. Van hieruit wordt
het eigenlijke programma geschreven. De state machine bestaat uit vijf states: vooruit,
achteruit, links, rechts en stop. Door een knop in te drukken op het front panel kan dus een
richting gekozen worden die de robot zal volgen. Daardoor komt de robot in de
overeenkomstige state, waarin de juiste motoren de juiste waarde meekrijgen. Een tabel
waarin beschreven staat welke motor welke aan welke uitgang hang, vind je op de volgende
pagina.

Motor 1 +
-
Port0/DIO6
Port0/DIO7
Motor 2 +
-
Port0/DIO4
Port0/DIO5
Motor 3 +
-
Port0/DIO2
Port0/DIO3
Motor 4 +
-
Port0/DIO0
Port0/DIO1
Tabel 1: Aansluiting motoren op sbRIO-9602
Hieronder kan je vinden welke uitgangen een hoog(H) of laag(L) signaal aangeboden krijgen
om er voor te zorgen dat de robot een bepaalde richting uit zal gaan.
Stop Vooruit Achteruit Links Rechts
Port0/DIO0 L H L L H
Port0/DIO1 L L H H L
Port0/DIO2 L H L H L
Port0/DIO3 L L H L H
Port0/DIO4 L H L H L
Port0/DIO5 L L H L H
Port0/DIO6 L H L L H
Port0/DIO7 L L H H L
Tabel 2: Sturingen uitgangen per richting
Met de instellingen zoals ze in de bovenstaande tabel beschreven zijn, zal de robot enkel
rechtlijnige bewegingen maken, dit wil zeggen dat de robot geen bochten zal maken. Als de
robot bochten moet maken zullen de motorsnelheden aangepast moeten worden, zodat de
motoren niet allemaal even snel draaien. Er dient wel toegevoegd te worden dat de robot
enkel op deze manier kan bewegen als er mecanumwielen op gemonteerd staan. Als er
standaardwielen op de robot gemonteerd zijn, kan de robot enkel draaien als de wielen aan
één kant geblokkeerd zouden worden, de robot draait dan rond zijn as en zal niet zijwaarts
bewegen.
Verder zijn er ook nog twee soorten sensoren op en in de robot. De eerste soort sensoren zijn
de sensoren die we zelf toegevoegd hebben, de Parallax Ping))) sensoren. Deze moeten er voor
zorgen dat de robot gestopt wordt indien er een object te dicht bij de robot komt. De sensor
heeft daarvoor vijf volt en een blokpuls nodig. De blokpuls moet vanuit LabVIEW uitgestuurd

worden, en wordt door middel van de ultrasoon-sensor uitgezonden. Zodra deze blokgolf een
object raakt wordt deze teruggekaatst richting de robot. Doordat de blokgolf met enige
vertraging terug aankomt bij de sensor kan men de afstand afleiden. De afstand van de sensor
tot een object is immers evenredig met de vertraging van de puls. Het is wel belangrijk om
weten dat de puls die ontvangen wordt de afstand tot aan het object twee keer heeft moeten
afleggen. Dit alles zal geregeld worden door LabVIEW zelf, aangezien de gekozen sensor in
LabVIEW al voorkomt als blok die ingevoegd kan worden in het programma. In het programma
wordt geprogrammeerd dat de state van het programma automatisch naar de stopstate gaat
als de robot zich binnen een bepaalde afstand van een object bevindt. De robot zal dan enkel
nog in de andere richtingen kunnen bewegen. Hieronder is een afbeelding van het
voorbeeldprogramma dat werd geschreven om het sbRIO-platform te testen. De input van dit
programma wordt gegeven door vier knoppen, vooruit, achteruit, links en rechts. Als geen van
de knoppen geactiveerd zijn, zal de robot stoppen. De snelheid van de robot wordt
aangegeven door een numerieke invoer van het type fixed point. Dit geeft dan een
percentage. Als er een toestand geactiveerd wordt, wordt deze waarde gekopeld aan de
overeenkomstige output door middel van het PWM-blokje, dat de waarde omzet in een
pulserende golf. Deze pulserende golf wordt door middel van de paarse blok die de digitale
input en output op de sbRIO representeert naar de sbRIO gestuurd.
Figure 5-8: Voorbeeld programma sturing motoren

In de motoren van de robot zijn er ook nog
quadrature encoders aanwezig. Deze geven de
snelheid en de richting van de motoren aan.
Deze encoder bevat een wiel met daarop twee
verschillende kleuren vlakken op. Deze vlakken
in twee verschillende kleuren worden gebruikt
om een verschil tussen een hoog en laag signaal
aan te maken. Dit signaal wordt aangemaakt
door twee optische sensoren, die op een
bepaalde afstand staan, zodat ze twee signalen
genereren die negentig graden uit fase liggen.
Door slechts gebruik te maken van een van de twee signalen, kan men de snelheid van een
motor uitlezen. Dit kan door gewoon de frequentie van dit signaal te gebruiken. Indien men de
snelheid van de robot zelf wil berekenen, kan dit door de snelheid van de motoren door
middel van de omtrek van de wielen om te zetten naar een snelheid in meter per seconde. Wil
men echter ook de richting van de motoren kennen, dan moeten beide sensoren in de motor
gebruikt worden. Als men de som neemt van de waardes die doorgegeven worden vanuit de
sensoren, en de uitkomst van deze sommen komen in de volgorde 0,1,3,2, dan zullen de
motoren in een richting draaien. Komen de uitkomsten van deze sommen in de volgorde
0,2,3,1, dan zullen de motoren in de andere richting draaien. De richting waarin de motoren
draaien als er een bepaalde volgorde van waardes wordt doorgestuurd hangt af van de
volgorde waarop de motoren en sensoren aangesloten zijn. Als de doorgegeven waardes in
een andere volgorde doorgegeven worden, wil dit zeggen dat de sensoren te traag reageren,
waardoor er geen juiste informatie doorgegeven wordt. Er werd door middel van een
testopstelling ook gekeken naar het signaal dat er op de uitgangen gegenereerd werd. Deze
testopstelling bestond uit een stroombron waarop een motor werd aangesloten. Daarna
werden ook de sensoren van een motor aangesloten en het signaal werd gemeten met een
digitale oscilloscoop. Hieronder is een afbeelding te vinden van het signaal dat gemeten werd.
Een tweede afbeelding geeft de faseverschuiving van negentig graden aan, wanneer de
signalen van de twee optische encoders in de motor samengevoegd worden.
Figure 5-9: Output quadrature encoders en EXOR-
signaal

Figure 5-10: Aparte signalen van optische encoders
Figure 5-11: Samengevoegde signalen

6 Informatica Design
6.1 Android
Figure 6-1: Android logo
6.1.1 Wat is Android?
Android is een besturingssysteem voor mobiele toestellen zoals tablets, smartphones, … Het
wordt ontwikkeld door de Open Handset Alliance, geleid door Google en een aantal andere
bedrijven.
De OHA is een consortium van een 86-tal hardware-, software- en telecomproducenten; ze
zetten zich in voor het creëren van open standaarden voor mobiele toestellen.
6.1.2 De filosofie
Google opteerde voor een open-source aanpak en bracht de Android-code uit onder een
Apache-licentie. Deze aanpak valt echter niet te verwarren met het free-software concept
waar de gebruiker zonder beperkingen de software kan bestuderen en wijzigen. Het idee
bestaat erin dat een groep bedrijven met dezelfde noden en behoeften de krachten bundelt
ter implementatie van een gedeeld product.
Daarnaast laat men toe dat elk participerend bedrijf het concept op zijn eigen manier aanpast
en bijstelt. Dit leidt onherroepelijk tot onverenigbare implementaties wanneer de bedrijven
zich niet aan bepaalde regels houden. Om dit te voorkomen werd het Android Compatibility
Program tot stand gebracht, dat aangeeft wat de maatstaven zijn om compatibel te zijn met
het besturingssysteem.
Hoewel het uit verschillende subprojecten bestaat, leeft er een strikt projectmanagement.
Android is en blijft een enkel product en de intentie is dan ook dat hardware producenten het
besturingssysteem zoals het is importeren op hun toestel; speciale distributies komen dus niet
voor.

6.1.3 Het Ontwerp
De Android kernel is gebaseerd op die van Linux en werd verder uitgebreid en aangepast op
het vlak van architectuur door Google. De kernel handelt allerhande core-services af zoals
hardware drivers, proces- en geheugenbeheer enz.
Alle middleware, libraries en API’s zijn geschreven in C/C++, deze draaien bovenop de kernel.
Zo handelt de Surface Manager het beheer van displays af en ondersteunt het Media
Framework het afspelen van audio en video.
De Android Runtime wordt gevormd door enerzijds de Core Libraries en anderzijds de Dalvik
Virtual Machine. De Core Libraries voorzien de meeste funtionaliteit en hoewel de
ontwikkeling in Java gebeurt, is de Dalvik VM, die een register gebaseerde werking heeft, geen
Java VM die stack-georiënteerd werkt. Om alsnog code te realiseren zal de Java-bytecode
geconverteerd worden naar een instructieset voor de Dalvik VM.
Na de conversie zal deze zelfs kleiner zijn in formaat dan het Java-Archive bestand hoewel ze
van dezelfde klasse afgeleid werden. Hierdoor is het dus niet langer vereist voor de
ontwikkelaar om de hardware aan te spreken via de C-laag.
Sinds Android versie 2.2 bevat de Dalvik-VM een Just-In-Time compiler; deze laat een meer
dynamische manier van compileren toe. De bytecode wordt veelal in secties ingelezen en
omgezet naar machinecode. Dit optimaliseert de prestaties en verlaagt het low-level memory
management.
Verder is er nog het Application Framework dat bestaat uit Java klassen die gebruikt worden
bij het ontwikkelen van een Android applicatie. De Application Layer voorziet op zijn beurt API-
libraries die gebruik maken van de resources uit het Application Framework.
In de volgende afbeelding verkrijgt u een duidelijker beeld van de architectuur.
Figure 6-2: Android System Architecture

6.1.4 Application Programming Interfaces
Wanneer we iets gaan schrijven binnen Android dienen we ons te houden aan een deftige
aanpak. Om dit te kunnen doen, is het verstandig om te kijken naar de verschillende systeem-
versies en met welk API-niveau deze overeen komen.
Het API-niveau is een waarde die de API op een unieke manier representeert. Dit is nodig om
een goed zicht te hebben op de compatibiliteit van een API en de versie van een Android-
platform
Voor het schrijven van het sensorgedeelte van de controller in Android maken we gebruik van
het android.hardware package. Dit package voorziet ondersteuning voor tal van hardware
features zoals die van de camera en sensoren.
Binnen dit package gaan we te werk met de sensorgerichte klassen:
 Sensor: deze representeert een sensor
 SensorEvent: deze klasse representeert een sensorEvent en bevat informatie zoals het
type, de tijdsintervallen en de data.
 Sensor Manager: deze klasse laat de programmeur de sensoren van het toestel
aanspreken.
Ook zal de gebruiker het robotplatform kunnen aansturen aan de hand van een op aanraking
gebaseerde controller. Deze manier werd gerealiseerd door het aan te passen van een
standaard Android View klasse. Alle functionaliteit bevindt zich binnen het android.view
package.
Binnen dit package maken we gebruik van de volgende klassen:
 View: deze klasse vormt het fundament voor interface componenten en zorgt voor het
afhandelen van events.
 MotionEvent: erft over van android.view.InputEvent en beschrijft de staat van de
beweging die uitgevoerd werd.
 OnTouchListener: door van deze interface gebruik te maken kan de programmeur
informatie verkrijgen op het gebied van de handelingen die zich afspelen inzake
aanraking op de smartphone.

Voor de camera-implementatie werd er naast een resem aan java.io klassen ook gewerkt met
het android.graphics package en een aantal klassen uit het org.apache package.
Voor het realiseren van de input:
 InputStream: Een abstracte klasse die wanneer deze overgeërfd wordt, de inputbytes
leest en doorgeeft.
o ByteArrayInputStream: bevat een interne buffer die de bytes, gelezen uit een
stream, bevat.
 BufferedInputStream: voegt de mogelijkheid om invoer te bufferen
toe. Om de interne array waar de data wordt opgeslagen te beheren
worden er markeer en reset methoden voorzien.
 DataInputStream: deze klasse staat de applicatie toe om Java
datatypes van een onderliggende stream in te lezen op een hardware
onafhankelijke manier.
Voor het tekenen van de verkregen data:
 Bitmap: objecten van deze klasse voorzien de mogelijkheid om afbeeldingen digitaal op te
slaan.
 Canvas: objecten van deze klasse voorzien de mogelijkheid om op te tekenen.
 Color: deze klasse voorziet standaard kleuren maar geeft ook de mogelijkheid voor eigen
implementatie zoals RGB waarden.
 Paint: deze klasse voorziet tal van methoden die je standaard pen, die dient om op een
Canvas object te tekenen, aanpast.
Om connectie te maken met de stream-url:
 HttpResponse: deze interface handelt het ontvangen en interpreteren van een aanvraag
af en toont het door de server afgeleverde bericht.
 AuthScope: deze klasse representeert de authenticatie, die bestaat uit de hostnaam, het
poortnummer, het gebied en het authenticatieschema.
o UsernamePasswordCredentials: Deze klasse vult het authenticatieschema aan
met de nodige velden zoals gebruikersnaam of wachtwoord.
 HttpGet: Een object van deze klasse omschrijft de methode die informatie door middel
van een URI opvraagt.
 DefaultHttpClient: Met deze klasse creëer je een cliëntobject waarmee je connecties kan
beheren.

6.2 Sensoren
Sensoren zijn kunstmatige zintuigen die van elektronische, biologische of virtuele aard kunnen
zijn. Met behulp van de informatie die de sensoren opleveren trachten we onze processen aan
te sturen op een zo goed mogelijke manier.
Een aantal sensoren, vooral de gyroscopen, accelerometers en kompassen zijn in toenemende
mate vertegenwoordigd in tal van consumentgerichte elektronische producten. Applicaties die
gebruik maken van deze sensoren, richten zich op het ontwikkelen van bijvoorbeeld de user
interface, augmented reality, gaming, beeldstabilisatie en navigatie.
In de komende topics gaan we dieper in op de verschillende fasen die nodig zijn om ruwe data
gebruik te maken voor onze applicatie. De volgende afbeelding geeft een duidelijk overzicht
van de structuur die doorlopen dient te worden om dit te realiseren.
Figure 6-3: Sensor Platform InvenSense

6.2.1 Gyroscopen
Een gyroscoop is eigenlijk een soort van tol, die door zijn eigenschap, namelijk het behouden
van een draaiing, tracht zich te verzetten tegen de verandering van zijn stand. Hierdoor kan je
hem perfect gebruiken voor oriëntatie. Enkele praktijkvoorbeelden waar een gyroscoop als
richtinstrument wordt gebruikt zijn vliegtuigen en schepen.
Figure 6-4: Structuur Gyroscoop
Binnen de elektronische wereld is het echter niet altijd mogelijk om een gyroscoop van
mechanische aard te implementeren. Daarom werd er op chipniveau een gyroscoop
ontwikkeld die aan de hand van vibraties zich kan oriënteren met behoud van nauwkeurigheid
en die bovendien goedkoper is dan een conventionele gyroscoop.
6.2.1.1 Het Coriolis effect
De gyroscoop met vibrerende structuur werkt ongeveer zoals de halters van tweevleugelige
insecten. Er wordt gebruik gemaakt van een fysische eigenschap, met name het Coriolis effect
dat de afbuiging van de baan van een voorwerp bepaalt op een roterend systeem.
Bekijk het volgende voorbeeld:
Situatie 1:
Een projectiel wordt geworpen van rood naar
blauw op een draaibaar platform. In
stilstaande toestand zal het projectiel de gele
pijlen volgen.
Wanneer het platform tegenwijzerzin draait
zal het projectiel de groene pijlen volgen en
dus rechts afbuigen. De curve die het projectiel
volgt zal van kikkerperspectief niet veranderen
maar zal, omdat het platform draait, zijn
eindpunt, blauw, niet bereiken.
Figure 6-5: Worp projectiel vanuit middelpunt platform

Situatie 2:
Een projectiel wordt geworpen van rood
naar blauw op een draaibaar platform.
Wanneer het platform tegenwijzerzin draait
zal het projectiel de groene pijlen volgen en
dus rechts afbuigen.
De gele pijlen beschrijven de curve die het
projectiel zal volgen, bekeken vanuit een
kikkerperspectief. Opnieuw bereikt het
projectiel zijn eindpunt blauw niet.
Situatie 3:
Wanneer we een projectiel van de ene rand
van het platform rood naar de andere rand
blauw werpen merken we dat hoewel het
projectiel een rechte curve geel bij stilstand
zou afleggen, deze rood volgt en naarmate
het projectiel verder vliegt een sterkere
afwijking groen van zijn pad ondervindt.
Figure 6-6: Worp vanaf rand platform
Figure 6-7: Worp van rand tot rand platform

6.2.2 Accelerometers
Om te weten wat een accelerometer doet zullen we eerst acceleratie of versnelling even onder
de loep moeten nemen. Acceleratie bespreekt de verandering in snelheid in een tijdsinterval.
In formule:
De acceleratie wordt weergegeven in (m/s)/s of m/s².
De sensoren waarmee acceleratie gemeten wordt kunnen van verschillende aard zijn. Als
voorbeeld bespreken we hier een piëzoelektrische sensor.
Piëzoelektrische materialen zijn stoffen die onder invloed van druk een lading krijgen, de
piëzoelektrische lading. Omdat versnelling een kracht uitoefent (eerste wet van Newton) kan
een dergelijke druk door acceleratie teweeggebracht worden. Door de verkregen lading te
meten kunnen we de versnelling kwantificeren.
Binnen de toepassing wordt er getracht een beweging waar te nemen zoals dit al wordt
gedaan om de oriëntatie van het toestel van landscape naar portrait om te vormen afhankelijk
van de positie van het toestel. Op basis van de verkregen data kunnen we een controller
uitwerken die afhankelijk van de houding van het toestel door de gebruiker, het robotplatform
dat we onwikkelen stuurt en versnelt.
Vele fabrikanten van micro-elektromechanische systemen, beter gekend als MEMS, voorzien al
heel wat goedkope oplossingen met tal van geïntegreerde sensoren zoals de gyroscoop en de
accelerometer.
Figure 6-8: Structuur CMOS-MEMS Chip

6.3 Sensor Fusion
Om deze sensoren correct te hanteren dient de ontwikkelaar kennis te hebben van tal van
wiskundige bewerkingen, zoals de rotatiematrix. Onderliggend zullen de algoritmen van Sensor
Fusion de data van de sensoren combineren, waardoor ze accurater en completer zijn dan
wanneer we de sensoren individueel zouden bekijken.
Bij het opzoekwerk naar de implementatie hiervan kwamen we uit op een blog genaamd:
”Thousand Thoughts” door Paul Lawitzki. Naast de algemene uitleg van de sensoren biedt hij
ook een goede basis aan voor het maken van de aansturing van ons robotplatform.
Sensor Fusion maakt gebruik van tal van methoden en algoritmen zoals de Kalman filter, een
probabilistisch netwerk en de Dempster-Shafer Theorie, die hieronder meer in detail zal
worden besproken.
6.3.1 De Kalman-Filter
De gegevens die van sensoren komen bevatten ruis. Om deze ruis te onderdrukken gebruiken
we de Kalman-filter.
Stel dat we het hebben over een grootheid, X. We zullen nooit een exacte meting verkrijgen
maar wel een gemiddelde ̂. Om aan te geven op welk tijdstip we meten, noteren we ̂ . Als
we een schatting maken voor een meting op tijdstip k, met informatie uit tijdstip l, noteren we
dit ̂ | .We gebruiken dezelfde notatie voor de probabiliteit P in plaats van een grootheid X.
De stand van de filter wordt vertegenwoordigd door twee variabelen: ̂ | , de staat geschat
op tijdstip k gegeven de waarneming t op tijdstip k. ̂ | , de covariantiematrix die een maat
van de nauwkeurigheid van de geschatte stand aangeeft.
De vergelijking van de Kalman-Filter kan opgesplitst worden in twee fasen. De voorspellende
fase past de schatting van de toestand op een vorig tijdstip toe op die van het huidige tijdstip.
Hoewel dit een schatting is van het huidige tijdstip bevat deze schatting geen informatie van
de meting van ditzelfde tijdstip. In de updatefase wordt de huidige schatting gecombineerd
met de observatie van het meettoestel om de schatting te verfijnen.
Deze twee fases alterneren om voorspellingen tot de volgende geplande observatie van het
meettoestel. De data die hieruit voortloopt wordt vervolgens geïntegreerd in de volgende
updatefase.

Figure 6-9: Kalman-filter
Dit is echter niet noodzakelijk. Als een observatie niet beschikbaar is, mag de updatefase
overgeslagen worden en worden er meerdere voorspellingen gedaan. Ook als meerdere
onafhankelijke observaties op eenzelfde moment beschikbaar zijn, zullen er meerdere updates
worden uitgevoerd, meestal met verschillende observatiematrices.
6.3.2 Balansfilter
Hoewel de Kalman-filter het theoretisch meest ideale resultaat oplevert, kost hij tamelijk veel
processortijd, vooral door de complexiteit van het algoritme.
Om dit probleem op te lossen maken we gebruik van een complementaire filter. Deze filter
maakt gebruik van integratie, een Low-Pass Filter en een High-Pass Filter.
De integratie wordt gebruikt om een meting van de plaats te halen uit de meting van de
versnelling.
De Low-Pass Filter heeft als doel om enkel veranderingen op lange termijn te tonen en filtert
die van korte termijn eruit.
De High-Pass Filter laat signalen van korte tijdsduur binnen maar filtert signalen die gedurende
een lange tijd gelijkmatig blijven.

6.3.3 Het probabilistisch netwerk
Om bepaalde data te realiseren dienen we probabilistisch te redeneren, we willen namelijk de
kansverdeling modelleren. Een probabilistisch netwerk is zo een grafische voorstelling van een
statistisch model. Dit soort netwerken is hiërarchisch in die zin dat elementen vaak van elkaar
afhangen. Een ziekte hangt bijvoorbeeld af van symptomen.
Het netwerk bevat een gerichte graaf, de bladeren beschrijven de meting van de sensoren, alle
knopen zijn statistische variabelen. Alle knopen waar pijlen samenkomen, zijn statistische
variabelen die berekend worden uit de oorsprong van de pijlen. De volledige graaf modelleert
dus de afhankelijkheid van de statistische variabelen.
In ons geval kunnen we een volgend netwerk beschrijven:
Figure 6-10: Voorstelling probabilistisch netwerk binnen het project

6.4 De Dempster-Shafer Theorie
De Dempster-Shafer theorie is een wiskundige manier van bewijzen. Deze manier laat toe om
bewijzen van verschillende oorsprong te combineren en vervolgens gradaties van kans te
hechten aan het bewijs door middel van een geloofsvergelijking. Wat we hiermee exact
bedoelen definiëren we later.
De theorie stelt de vraag van interesse voor elke mogelijkheid van een universum. De
wiskundige gradaties van geloof hangen proportioneel af van de mogelijkheid; hoe sterk ze
verschillen hangt af van de relatie tussen de vragen.
Binnen de Sensor Fusion gedachte hanteren we twee ideeën. We trachten de gradatie van het
geloof in de ene vraag op basis van subjectieve probabiliteit in relatie met de verwante vraag
te verkrijgen. Daarnaast combineren we de mate van het geloof op basis van onafhankelijke
bewijsmiddelen.
In essentie hangt de mate van het geloof hoofdzakelijk af van het aantal antwoorden
gerelateerd aan de vraag en de subjectieve kans op elk antwoord. Uiteraard dragen de regels
van combinatie bij tot de weergave van de gegevens uit de algemene veronderstellingen.
Het kader van Shafer laat toe om voorspellingen voor te stellen in intervallen, begrensd door
twee waarden, met name geloof en plausibiliteit.
Hierin geldt echter het volgende: geloof ≤ plausibiliteit.
Het Universum van gebeurtenissen , deelverzamelingen van , P( )
Elke deelverzameling heeft een massa m( ):
m: P( ) [0;1]

De massafunctie voldoet aan een voorwaarde die gelijkt op de wet van de totale kans:
∑
Hieruit worden twee functies P( ) [0;1] afgeleid die we zien als een grenswaarden van een
interval voor de kans omdat we deze laatste niet exact weten. Deze grenzen noemen we het
geloof en de plausibiliteit.
Het geloof, bel, wordt gevormd door de som van de massa’s van alle subgroepen van een
hypothese:
bel(A) =
∑
|
drukt de voorkeur uit naar een bepaalde propositie gebaseerd op de elementen die erin
aanwezig zijn. Verder gedraagt dit zich zoals we verwachten en varieert het geloof tussen
0 en 1. Ook is de totale som van alle geloofswaarden gelijk aan 1.
De plausibiliteit, pl, wordt berekend door 1 te verminderen met de som van alle massa’s
waarvan de intersectie met de hypothese geen elementen bevat:
pl(A) =
∑
|
Dit vormt de een begrenzing gebaseerd op de elementen uit het universum waarmee de
definitie van geloof geen rekening houdt.
De volgende tabel geeft een voorbeeld dat de lezer kan narekenen om vertrouwd te worden
met de gebruikte formules.
Hypothese Massa m Geloof Plausibiliteit
Geen (noch A noch B) 0 0 0
A 0.2 0.2 0.5
B 0.5 0.5 0.8
Een van beide (A of B) 0.3 1.0 1.0

6.5 Design en Implementatie
6.5.1 Google Nexus S
Voor deze stage kreeg ik de Nexus S ter beschikking, een smartphone ontwikkelt door
Samsung in opdracht van Google. Dit toestel kwam in december 2010 op de markt en werd in
hoofdzaak voor het testen op de wereld gezet. De Nexus S beschikt daardoor over veel high-
end-hardware. Zo beschikt het toestel over een 1GHz processor met één kern met een
werkgeheugen van 512MB.
Enkele specificaties van deze smartphone die het design van de controller bepalen zijn de
gyroscoop, de accelerometer en het magnetisch kompas.
Figure 6-11: Google Nexus S

6.5.2 Touch
Aangezien de smartphone over een beperkt aantal knoppen beschikt en dus hoofdzakelijk op
basis van schermaanraking werkt leek het nuttig om hierop verder te werken. Traditionele
oude controllers werken met pijltjes die corresponderend met hun richting informatie
doorgeven. Om het besturen van het robotplatform wat aangenamer te maken ontstond dan
ook het idee om een soort stuurknuppel of joystick na te bootsen, die je met je vinger kan
bedienen.
Figure 6-12: Schematische voorstelling touch control
De snelheid en de richting worden bepaald door de positie (X&Y) van de vinger te vergelijken
met het middelpunt van de controller.

In het volgende stukje code kan u zien hoe dit gerealiseerd wordt. Hierbij zijn x en y de
verkregen coördinaten van de vinger op het scherm en is Directions een opsomming van alle
mogelijke richtingen.
public String createInfo(int x,int y){
if(x==0&&y==0){
d = Directions.NOTHING;
}else{
if(y<-15){
if(x>15){
d = Directions.TOPRIGHT;
}else if(x<-15){
d = Directions.TOPLEFT;
}else{
d = Directions.TOP;
}
}else if(y>15){
if(x>15){
d = Directions.BOTRIGHT;
}else if(x<-15){
d = Directions.BOTLEFT;
}else{
d = Directions.BOT;
}
}else{
if(x>15){
d = Directions.RIGHT;
}else if(x<-15){
d = Directions.LEFT;
}else{
d = Directions.NOTHING;

Het volgende codegedeelte tracht op te volgen wat de vinger uitvoert en vervolgens
communicatie met de RESTful webservice legt. Hierbij zijn webX en webY afgestelde
coördinaten ter communicatie met het LabVIEW gedeelte en is d een richting uit de opsomming
van mogelijke richtingen.
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
updatePosition(x, y);
oldx =x;
oldy =y;
break;
case MotionEvent.ACTION_MOVE:
updatePosition(x, y);
if((Math.abs(x-oldx)>5)||(Math.abs(y-oldy)>5)){
new Thread(new Runnable() {
public void run() {
String s = ws.executeGet(d, webX, webY);
}
}).start();
oldx =x;
oldy =y;
}
break;
case MotionEvent.ACTION_UP:
updatePosition(-1,-1);
touch = false;
new Thread(new Runnable() {
public void run() {
String s = ws.executeGet(Directions.NOTHING, 0, 0);
}

Mechatronic System Design

Recommended

Recommended

More Related Content

Similar to Mechatronic System Design

Similar to Mechatronic System Design (20)

More from Vincent Claes

More from Vincent Claes (20)

Mechatronic System Design