Arduino gebruiken op de motor

Gixxer-harry

MF veteraan
4 jun 2006
3.244
1
Gasselte
Ik ben op het net de Arduino tegen gekomen en ik heb er eentje besteld want er zijn vast heel veel leuke dingen mee te maken voor op de brommert
Kennen jullie dit en doen jullie er ook leuke dingen voor de motor mee?
 
Waarom zou je voor embedded een andere taal dan C willen gebruiken?

Nee, hij bedoelt waarschijnlijk meer voor de PC applicatie die ik ooit nog is wil gaan maken, om dat matrixbord te gaan besturen.. Nu kan ik hem gewoon via seriële verbinding besturen door via een terminalprogramma er karakters heen te sturen, 'k' voor dat kruis, 'p' voor groene pijl etc. en kan de LEDs ook dimmen via PWM, aangezien die LEDs anders nogal verblindend zijn en kan ook door er een 's' heen te sturen heb de status (welk symbool aan is) uit teruglezen, maar voor het mooie zou ik dat eigenlijk eens via een UI programma'tje willen doen.. :P

Als ik hem aanzet, is hij trouwens standaard geconfigureerd dat hij gewoon alle symbolen gedimd één voor één afgaat, maar daar stopt hij mee als je vanaf de PC wat stuurt. Dus je kan hem ook gewoon aan de muur hangen :P
 
Tenminste, is OO daar makkelijker voor, of kan je een simpel programmatje met 4 knoppen en een paar statustekstjes dat als je op een knop drukt een karakter via de seriële poort uitspuugt en daarna terugleest welk symbool nou aan is (ook gewoon wat karakters teruglezen) ook makkelijk in een ander soort taal maken? Of is daar gewoon een kant en klaar klik en sleep programma voor? :P
 
Tja, het kan op allerlij mogelijke manieren..

Zo simpel kan het met python:

import time
import serial
# configure the serial connections (the parameters differs on the device you are connecting to)
ser = serial.Serial(
port='/dev/ttyUSB1',
baudrate=9600,
parity=serial.PARITY_ODD,
stopbits=serial.STOPBITS_TWO,
bytesize=serial.SEVENBITS
)

ser.open()
ser.isOpen()

print 'Enter your commands below.\r\nInsert "exit" to leave the application.'

input=1
while 1 :
# get keyboard input
input = raw_input(">> ")
# Python 3 users
# input = input(">> ")
if input == 'exit':
ser.close()
exit()
else:
# send the character to the device
# (note that I happend a \r\n carriage return and line feed to the characters - this is requested by my device)
ser.write(input + '\r\n')
out = ''
# let's wait one second before reading output (let's give device time to answer)
time.sleep(1)
while ser.inWaiting() > 0:
out += ser.read(1)

if out != '':
print ">>" + out

Serial RS232 connections in Python | Varesano.net

Maar ook bijvoorbeeld autoit, is het simpel te doen:
Serial com-port communication with autoIt
 
Ben aan het zoeken naar het originele C programma wat erin zit.. Maar begint er steeds meer op te lijken dat ik die kwijt ben B| '( Zitten geloof ik 1,2 of 3 laptops tussen onderhand... Waarvan er 1 een kapotte HDD had (eigen schuld, boos worden en klap op je laptop geven is niet bevordelijk voor de levensduur van je HDD :')), dus heb wel een aantal dingen geback-upped, maar waar en wat.. :+
 
Even beter lezen, dit gaat over een applicatie die op de PC gaat draaien. Simon zegt graag weer eens iets met OO te willen doen, maar dan als applicatie die de chars naar de embedded hardware over de serial gaat sturen.

Ah oke, duidelijk :). Overigens zou mijn eerste keuze dan c++ zijn, met Borland als compiler ;). Geen lompe .net rommel, maar 1 executable die alleen hetgene bevat wat echt nodig is.
 
Ah oke, duidelijk :). Overigens zou mijn eerste keuze dan c++ zijn, met Borland als compiler ;). Geen lompe .net rommel, maar 1 executable die alleen hetgene bevat wat echt nodig is.


Ben ik helemaal met je eens, is al teveel bloated crap in de digitale wereld.

He, bah; BlueJ is net zo erg als Java, maar dan met zijwieltjes!
 
Aangezien testen op een brandstof-motor niet heel erg handig is, toch maar een test opstelling gemaakt. Een electromotor (stofzuigermotor) aangedreven door een variac.

Het aluminium plaatje zit een magneetje op, het magneetje triggered de hallsensor. De arduino verzorgt de vonk, wat te zien is met het LEDje (zelfde timing als de vonk). Door het stroboscoop effect van het flikkerende ledje kun je dus de timing van de ontsteking zien.

Uiteraard is de timing geheel instelbaar etc.

Filmpje:
http://tinypic.com/player.php?v=2ew028l&s=6
 
Hey leuke projecten *O*
Zelf zit ik nog in de experimenteer-fase om de functies van de processoren en het programmeren onder de voet te krijgen.

Ik heb bewust gekozen om een niveau "lager" te gaan zitten dan de Arduino programmeer-omgeving. Dus C/C++ met de Win-AVR + Studio6. Aanrader, werkt perfect. Ik heb ook vooral de voordelen van de Atmel-Dragon programmer leren kennen: het debuggen met debug-wire of JTAG is soms echt wel handig. En toen ik een chip verkl##t had door een domme fout waardoor de toegang via ISP-flashen werd geblokkeerd, bood de Dragon de mogelijkheid om als high-voltage programmer de chip te cleanen en de fuse-bits te resetten. Ideaal.

Arduino projekten zijn erg leuk om snel wat aan de praat te krijgen en om voor weinig een mooi board. Mijn doel is meer om de hardware te leren begrijpen en zelf ook de hardware te knutselen. Ik wil ook vrijer zijn om zelf m'n microcontrollers te kiezen. Vaak kijk ik wel in de source code van bv. Arduino projekten om te zien hoe zij het opgelost hebben. Meestal erg goed, maar soms wil je meer, bv. een 16-bit timer gebruiken ipv 8-bit. Met de Atmel datasheets en voorbeelden lukt dat ook snel, zelfs voor een leek als ik.

Mijn knutselprojecten:
- Servo-tester
- Servo-mixer voor modelvliegen
- Regelbare DC motoraansturing + led-lampen voor m'n pa's model huisjes / watermolen
- Datalogger met smeersysteem a-la McCoi. De snelheids- en afstandsdata komt van het GPS signaal en niet van de motor. Hiermee ben ik nog niet ver, ik wacht nog op de GPS module. Ik heb al wel een simpel met de hand-instelbaar systeem dat op tijd werkt, misschien dat ik die eerst eens ga uitproberen.
- Toekomst: Variometer voor zweefvliegen en 3-assen gestabiliseerde besturing voor modelvliegtuigen (MultiWii board)
 
Hey allemaal, ik meld me hier ook even. Ik was gisteren aan het zoeken naar of ik een Yamaha R6 km-teller op mijn Div uit 95 kan bouwen, en het probleem was vooral dat mijn motor nog een mechanische tellerkabel heeft. Dus ik heb besloten dat ik zelf een elektrische teller erbij ga bouwen, ik heb altijd al een project voor een arduino gezocht wat redelijk simpel is zodat ik het af kan maken en een mooi resultaat biedt zodat ik het af wil maken, de R6 teller is namelijk vet cool. De arduino moet als speedohealer gaan dienen.

Dus, ik heb alvast geshopt:



En een hall effect sensor:



Ik moet nog even zien te ontdekken bij welke frequentie van pulsen de teller van de R6 welke snelheid aangeeft in km/h, en hopelijk is dat inderdaad een lineair verband, en dan moet het redelijk eenvoudig zijn om het signaal van die hall-sensor als die op een goede plek zit om te vormen.

Als dat dan werkt dan heb ik nog wel wat vervolgplannen. Het lijkt me sowieso handig om hem rijdend te kunnen calibreren. Het leek me wel een goede optie om de knoppen van de toeter en de starter te gebruiken als inputs, waarbij de starter knop wanneer de motor al loopt dient als 'enter calibration mode' knop en vervolgens de twee knoppen kunnen worden gebruikt voor het omhoog en omlaag bijstellen van de omrekenfactor. Zo kun je heel eenvoudig naast een auto met GPS gaan rijden die hem op cruise control zet en je speedo precies afstellen.

Later wil ik ook de toerenteller aansluiten op de arduino en een gear indicator maken, inderdaad met de verhouding tussen de twee (moet kunnen). En nog later wil ik de boel wel gaan loggen naar een sd kaartje, maar misschien moet dat eerder omdat ik toch wat output wil hebben.

Wat ik nog wel moet doen is een schakeling om de arduino heen bouwen om de 12v sensors en zo goed als input te kunnen gebruiken en misschien in hardware iets doen met de onvermijdelijke ruis/contactdender, en als ik de starterknop wil gebruiken moet ik natuurlijk ook de startmotor als output kunnen gebruiken. Mijn kennis daarover gaat niet veel verder dan 'transistors', dus als iemand tzt daarmee zou willen helpen zou dat geweldig zijn. Solderen kan ik wel en ik heb nog wel van die gatenbordjes met eilandjes voor het prototype.

Nu ga ik even een informele spec maken van wat ik hierboven heb gespauwd en dan de dev omgeving klaarmaken, jullie zien mij hier nog wel terug :9




Ben ik weer, ik heb het volgende bedacht als eerste versie. De kalibreermodus gebruikt niet meer de starter knop want die wordt afgekoppeld als de motor niet in z'n vrij staat, dus dat is vervelend. In plaats daarvan gebruik ik het groot licht als input, dus met die pass-knop kun je ook wat. Nadeel is dat het groot licht wel aan gaat als je dat indrukt, maar je moet ook niet in het verkeer gaan kalibreren.

eDu1EUp.gif


Als iemand aanwijzingen heeft voor de nodige transistors, weerstanden en andere dingen die missen dan roep ze maar!

Het idee is dat de hele kalibreermodus met een jumper of zekering die je normaal thuis laat (S3) ingeschakeld kan worden zodat je er niet in komt tijdens gewoon gebruik. Verder gebruikt het een relais (RY2), als daar geen stroom op staat blijft alles verbonden zoals het origineel is. Pas als je het groot licht (S2) een paar seconden ingedrukt houdt gaat het relais om, waarbij de toeter (S1) en het groot licht indicatie lampje (LS1) worden onderbroken zodat je S1 en S2 als inputs kan gebruiken en dat LS1 gaat knipperen om aan te geven dat je aan het kalibreren bent. Na een paar seconden geen input gaat hij weer uit deze modus.

In normale modus is er alleen de input uit de Hall effect sensor en de output naar de R6 teller. Hiervoor lijkt me het volgende loopje wel voldoende:

67KJWJr.png
 
Laatst bewerkt:
Heb je niet 2 signalen nodig om de snelheid te bepalen: positie van de versnelling en signaal van de ontsteking/hallsensor? Voor de kalibratie zou ik een kabel met schakelaar maken die je er aan kunt hangen. Als het goed is doe je het maar 1x. In het programma test je dan of je in kalibratie of rij-modus zit door bv. te kijken of de schakelaar tijdens het opstarten van de µC ingedrukt is.

Maar de vraag is of je dit überhaupt nodig hebt. Als je weet hoeveel pulsen de hallsensor per toerental geeft, dan hoef je alleen nog maar de overbrenging te weten (bekend) van je motor. Even de oscilloscoop eraan hangen en je weet het.

Dan kun je de transistoren voor de ingaande signalen weglaten. Een weerstandje(s) is voldoende. Wat voor signaal heeft je digitale speedo nodig? Is het een analoog signaal? Als je voldoende pinnen vrij hebt kun je er ook een sjiek display aan hangen waar je zowel snelheid, toerental als gear-indicator op kunt aangeven. Wil je toch nog grote stromen kunnen sturen dan zou ik een FET gebruiken met weerstandje aan de gate. Bv. een IRL24 of de oer-oude BUZ11.

Al hoewel ik ook nog redelijk leek ben, heb ik begrepen dat kwa programmeren geadviseerd wordt dit zoveel mogelijk via interrupts te doen en zo veel mogelijk 8 bit integers te gebruiken. Vaak heb je floats helemaal niet nodig. Om de periode tussen 2 pulsen te meten is triggeren op bv. een stijgende flank wel het handigste (INT0 poort) waarna de timer/counter op 0x00 wordt gezet en weer wordt uitgelezen op de 2e interrupt op poort INT0.
 
Heb je niet 2 signalen nodig om de snelheid te bepalen: positie van de versnelling en signaal van de ontsteking/hallsensor? Voor de kalibratie zou ik een kabel met schakelaar maken die je er aan kunt hangen. Als het goed is doe je het maar 1x. In het programma test je dan of je in kalibratie of rij-modus zit door bv. te kijken of de schakelaar tijdens het opstarten van de µC ingedrukt is.

De sensor zal op het wiel zitten, in tegenstelling tot bij de R6 daar zit hij in het blok. Dat van het kalibreren is inderdaad wel een goede overweging, dat maakt het sowieso een stuk simpeler.

Maar de vraag is of je dit überhaupt nodig hebt. Als je weet hoeveel pulsen de hallsensor per toerental geeft, dan hoef je alleen nog maar de overbrenging te weten (bekend) van je motor. Even de oscilloscoop eraan hangen en je weet het.

Dat is ook zo, alleen ik heb geen scoop :P Ik weet wel hoe ik de snelheid bereken uit de pulsen van de sensor want dat is de omtrek van het wiel, en wat de teller aangeeft bij wat voor input is ook binnen makkelijk te testen...

Dan kun je de transistoren voor de ingaande signalen weglaten. Een weerstandje(s) is voldoende.
Dus tussen de hall-sensor en de arduino een weerstandje? Hoeveel Ohm?

Wat voor signaal heeft je digitale speedo nodig? Is het een analoog signaal?
Ik heb geen idee, ik neem aan dat de speedo (die van een R6 komt) direct op de hall-sensor van de R6 zit dus dat zullen wel pulsen zijn. Ik moet nog even kijken of dat met gewone 5v werkt of dat het echt 12v moet zijn.

Als je voldoende pinnen vrij hebt kun je er ook een sjiek display aan hangen waar je zowel snelheid, toerental als gear-indicator op kunt aangeven.
Ik heb al zo'n nokia schermpje erbij besteld voor 5 euro, die wil ik wel als gear-indicator gebruiken en misschien de tijd of zo. Voor toerental vind ik een gewone naald eigenlijk veel gaver :P

Wil je toch nog grote stromen kunnen sturen dan zou ik een FET gebruiken met weerstandje aan de gate. Bv. een IRL24 of de oer-oude BUZ11.
FET met weerstand aan de gate. Got it.
Al hoewel ik ook nog redelijk leek ben, heb ik begrepen dat kwa programmeren geadviseerd wordt dit zoveel mogelijk via interrupts te doen en zo veel mogelijk 8 bit integers te gebruiken. Vaak heb je floats helemaal niet nodig. Om de periode tussen 2 pulsen te meten is triggeren op bv. een stijgende flank wel het handigste (INT0 poort) waarna de timer/counter op 0x00 wordt gezet en weer wordt uitgelezen op de 2e interrupt op poort INT0.
Volgens mij heeft de nano maar 2 interrupts maar dat is dus genoeg, wel een beter idee. Alles als integers doen zal ook wel lukken.

Ik overweeg op dit moment om het zelfs direct met een AVR te doen ipv een arduino omdat ik nog AVRs heb liggen, maar ik heb geen programmer dus tot nu toe schiet ik daar nog niks mee op.
 
Ah ok gewoon direct op het wiel dus, dat had ik verkeerd begrepen. Ik dacht dat je de pulsen voor de ontsteking wilde gebruiken. Dan heb je dus maar 1 puls/omwenteling en hoef je voor de snelheid alleen nog maar de afstand/omwenteling te weten.

Je hebt Hallsensoren in verschillende uitvoeringen, maar het gemakkelijkste is er een te nemen met een transistor uitgang, bv. TLE 4935L. Dan is het alleen nog maar een weerstandje en evt condensatoren om het signaal nog iets strakker te krijgen. In de datasheets staan wel voorbeelden. De McCoi gebruikt, geloof ik, een reed relais.

Naast de INTx heb je zeker nog meer interrupt poorten (PCINTx), die kun je ook nog gebruiken, maar die triggeren op pin-switch, niet op flanken. Dan moet je dus nog even checken of je pin hoog of laag is. Met INTx heb je wat meer mogelijkheden.

Met GCC in Arduino heb ik geen ervaring, maar wat ik begrepen heb is de basis gewoon een bootloader. Misschien heeft iemand hier ervaring?
 
Cool, dat klinkt wel goed. De sensor die ik had besteld heeft ook een LED dus dat is sowieso handig testen, en iemand had in een review gezet dat hij een mooi scherpe puls gaf en goed werkte met een arduino, dus dat is al goed denk ik. Ik ben vandaag bezig geweest met een AVR programmer in elkaar zetten maar die werkt (nog) niet, rotzooi :9
 
Laatst bewerkt:
Bedenk wel dat bij hogere snelheden je puls korter wordt. Als je niet vaak genoeg sampled, dan ga je dus precisie verliezen op hogere snelheden.

De rolomtrek van een 120/70ZR17 band is ongeveer 1884mm.

300km/u is 83,333333 meter per seconde, of 83333mm/sec. Dat is dan dus 44 pulsen per seconde (83333/1884).

1km/u is 0,27777 meter per seconde, of 278mm/sec. Dat is dan dus 0,147 omwentelingen per seconde.

Ga je nu de tijd tussen twee pulsen meten, dan is dat op 300km/u dus 0,0227 seconden. Op 1km/u is het 6,8027 seconden.

Stel nu dat je samplet op 10000hz, dan heb je een resolutie voor het meten van je omwentelingen 0,0001 seconde.

Op 300 km/u, heeft je teller dan de waarde 0,0227/0,0001 = 227.

Maar op 1 km/u heeft je teller de waarde 68027.

Dus: met een 8-bits teller kom je er niet. En met een 16-bits teller kun je helaas niet op 0,0001 seconde nauwkeurig tellen omdat je dan boven de 65535 uit komt.

Naja, mo een lang verhaal kort te maken. Doe de berekeningen. :) Gebruik een spreadsheet om het inzichtelijk te maken.

Overigens is dit bij een kilometerteller niet zo heel kritiek, hoger dan 300km/u hoef je toch niet te tellen. Bij een toerenteller wordt het allemaal veel kritieker, omdat je dan over max. 40.000 pulsjes per seconde praat. Maar min. 500 pulsjes per seconde. De getallen worden dan erg groot.
 
Er zijn globaal twee manieren om het aantal omwentelingen per tijdseenheid te meten:

1. De tijd tussen twee pulsjes meten. Start een teller, lees die bij iedere puls uit en reset hem weer.
2. De frequentie van de pulsjes meten. Neem een vaste tijd, en meet hoeveel pulsjes er voorbij komen binnen die tijd.

Dit is logisch: f=1/t => t=1/f

Het grappige is dat de nauwkeurigheid bij beide manieren van meten exact tegengesteld verloopt. De 1e manier is nauwkeurig voor lange tijden tussen de pulsen. De 2e manier is nauwkeurig voor meer pulsen in de tijd van meten, dus kortere tijden tussen de pulsen.

Het is dus voor de hand liggend om beide manieren van meten te implementeren, en een omslagpunt te berekenen waarbij je de voorkeur geeft aan de waardes van de ene manier of van de andere manier, al naar gelang de hoeveelheid pulsen per tijdseenheid.

Edit:

Ja, ik ben dus een beetje bezig met een digitale toerenteller die een beetje fatsoenlijk nauwkeurig is. :)
 
Laatst bewerkt:
Ik heb ook nog gedacht om een mechanische toerenteller te simuleren (metaalblokje aan veertje en een ronddraaiend magneetje die hem meer of minder meeneemt al naar gelang de snelheid van de ronddraaiende kabel).

Maar dat gaat helaas niet werken direkt op een microcontroller. Want op een gegeven moment moet je toch iets gaan digitaliseren, en dan krijg je weer die nauwkeurigheidsproblemen.

Het zou wel nog mogelijk moeten zijn met een 'integrator', een schakelingetje waarvan de uitgang lineair stijgt al naar gelang de hoeveelheid pulsen aan de ingang. In feite meet dat ding het oppervlak onder de puls (integratie).

Maar verder dan dat heb ik er niet over nagedacht. Ik denk dat het sowieso weer een probleem gaat worden van resolutie. Je moet een spanning meten, dat doe je met een DAC, en die moet hele kleine spanningsverschilletjes gaan meten. Op een motorfiets krijg je waarschijnlijk zo veel storing dat het niet zo veel zin meer heeft om te meten.

Volgens mij is de methode uit mijn voorgaande posting nog het beste. Voor kilometertellers misschien niet zo belangrijk, maar ik zie jullie straks al toeren willen tellen. ;)
 
Laatst bewerkt:
Ik wil zeker ook toeren gaan tellen als ik dit werkend heb :P Bedankt voor het verhaal, het gedeelte van je getallen schalen en goed kiezen en zo had ik zo niet 1-2-3 bedacht totdat ik ging kijken waarom het niet werkt. Wat storing betreft, hopelijk is dat redelijk in de hand te houden door het digitale spul te scheiden van de gewone electra. Ik heb een DC-DC converter gekocht, ik bekijk nog even hoe goed die is maar als het goed is is dat wel 5.00 V of in ieder geval stabiel.

Voor de nauwkeurigheid van de snelheid ben je sowieso ook erg afhankelijk van andere dingen. We gaan er nu vanuit dat je band 100% cirkelvormig is en een vaste omtrek heeft, maar afhankelijk van spanning en belading en misschien ook snelheid zal dat ook wel millimeters afwijken. Garbage in garbage out. Het zal niet veel zijn, maar het heeft geen nut om je snelheid op 3 decimalen nauwkeurig te tonen.

Ik ben straks wel blij als die teller werkt, dan ga ik verder en uiteindelijk heb ik gewoon een 5" scherm als dashboard met de tellers erop en een grafiek van mn snelheid, hoe goed ik schakel, waar de flitsers staan, etc :P
 

Pulsen tellen in een vaste tijd lijkt me niet handig, dan moet je veeeel te lang wachten voor een beetje resolutie, ook al rijd je 300kmh: bij 44 pulsen/s en een resolutie van 1kmh moet je 300/44 ~7s wachten... Beter: puls-breedte of periode meten.

Meerdere magneten is zeker een aanrader om bij lagere snelheden wat sneller de teller te kunnen updaten. Dus meerdere pulsen per omwenteling. Ik geloof dat het vaak zo'n stuk of 4 pulsen/omw. zijn(?)

Met een 8bit timer/counter is de min/max snelheid wel af te dekken lijkt me: periode 23ms - 3.6s ~ factor 160, gaat lukken. Alleen de resolutie van 1kmh op 300kmh niet. Met 16bit gaat het zeker lukken.

Als je aan de grenzen stoot van de 8bit timer, dan kun je nog denken aan de volgende opties:
1. Begin pas bij bv. 10kmh te tellen, dat doen commerciele tellers ook, en stopt wat eerder (is 300kmh op een R6 nodig?)
2. Of je schakelt de timer pre-scaler om vanaf een bepaald bereik
3. Of je gebruikt een teller-variabele zodat de timer meerdere keren draait. Niet de mooiste oplossing, maar daarmee kun je van milliseconden tot dagen meten. Interrupt routine kan extreem kort gehouden worden zodat dit niet merkbaar is.
 

Pulsen tellen in een vaste tijd lijkt me niet handig, dan moet je veeeel te lang wachten voor een beetje resolutie, ook al rijd je 300kmh: bij 44 pulsen/s en een resolutie van 1kmh moet je 300/44 ~7s wachten
... Beter: puls-breedte of periode meten.

Meerdere magneten is zeker een aanrader om bij lagere snelheden wat sneller de teller te kunnen updaten. Dus meerdere pulsen per omwenteling. Ik geloof dat het vaak zo'n stuk of 4 pulsen/omw. zijn(?)

Met een 8bit timer/counter is de min/max snelheid wel af te dekken lijkt me: periode 23ms - 3.6s ~ factor 160, gaat lukken. Alleen de resolutie van 1kmh op 300kmh niet. Met 16bit gaat het zeker lukken.

Als je aan de grenzen stoot van de 8bit timer, dan kun je nog denken aan de volgende opties:
1. Begin pas bij bv. 10kmh te tellen, dat doen commerciele tellers ook, en stopt wat eerder (is 300kmh op een R6 nodig?)
2. Of je schakelt de timer pre-scaler om vanaf een bepaald bereik
3. Of je gebruikt een teller-variabele zodat de timer meerdere keren draait. Niet de mooiste oplossing, maar daarmee kun je van milliseconden tot dagen meten. Interrupt routine kan extreem kort gehouden worden zodat dit niet merkbaar is.
Volgens mij gooi je iets door elkaar :?
 
Terug
Bovenaan Onderaan