Eindverslag
IPROJ1 - Project BOM Projectgroep D224
18 april 2007
Eindverslag
IPROJ1 - Project BOM Projectgroep D224
18 april 2007
Uitvoerende partij Ivan Vriezen Thien Nguyen Marcel Okhuijsen Dennis Tessels Joost van Weenen
1187377 1182635 1142584 1182787 1179489
Projectinformatie Groep Klas Vak Tijd Instelling Opleiding Begeleidende docenten
D224 EV6 IPROJ1 Semester 6, blok 1 Hogeschool Utrecht Elektrotechniek Ing. J.F. van der Bent Ing. D. Dijkstra
Documentinformatie Uitvoering Revisie Datum
Eindverslag 0 18 april 2007
Inhoudsopgave 1 Inleiding
I
9
Techniek
10
2 Analyse en ontwerp
11
2.1
Opdrachtomschrijving . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1
Specificaties robotplatform . . . . . . . . . . . . . . . . .
11
2.2.2
Omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2.3
Code en gebruik systeem-middelen . . . . . . . . . . . . .
16
2.2.4
Derde partij . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Algemene voorwaarden . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3
3 Realisatie 3.1
3.2
20
Mechanica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.1
Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.2
Docking . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.3
Bom-demontage . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.4
Controle bom-deactivatie . . . . . . . . . . . . . . . . . .
26
3.1.5
Camera en verlichting . . . . . . . . . . . . . . . . . . . .
29
Elektronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2.1
De voeding . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.2
Infrarood detectie . . . . . . . . . . . . . . . . . . . . . .
31
3
IPROJ1 - Project semester 6, blok 1
3.3
3.4
18 april 2007
3.2.3
Schakelcircuit voor centraal slot motoren . . . . . . . . .
32
3.2.4
De werking van het schakelcircuit . . . . . . . . . . . . . .
32
3.2.5
Aansturing toeter
. . . . . . . . . . . . . . . . . . . . . .
32
3.2.6
Aansturing omvormer . . . . . . . . . . . . . . . . . . . .
33
3.2.7
Accu meter . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.8
EMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3.1
Programmeren . . . . . . . . . . . . . . . . . . . . . . . .
38
3.3.2
IP-interface en globaal software ontwerp . . . . . . . . . .
39
3.3.3
Docking en disarm . . . . . . . . . . . . . . . . . . . . . .
53
Software tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
3.4.1
Revision Control . . . . . . . . . . . . . . . . . . . . . . .
61
3.4.2
LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4 Resultaten en conclusies
82
4.1
Gehaalde doelstellingen . . . . . . . . . . . . . . . . . . . . . . .
82
4.2
Niet gehaalde doelstellingen . . . . . . . . . . . . . . . . . . . . .
83
4.3
Niet onderzocht . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5 Evaluatie
II
85
5.1
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.2
Eindresultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
Projectmatig
87
6 Organisatie, werkwijze en methodiek
88
6.1
Projectgroep . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.2
Opdrachtgever . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.3
Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.4
Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
7 Proces
93 4
IPROJ1 - Project semester 6, blok 1
18 april 2007
7.1
Specifieke planning . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.2
Daadwerkelijke tijdsbesteding . . . . . . . . . . . . . . . . . . . .
97
7.2.1
Urenstaten . . . . . . . . . . . . . . . . . . . . . . . . . .
97
7.2.2
Totale tijdsbesteding . . . . . . . . . . . . . . . . . . . . .
97
7.2.3
Uitvoering . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
8 Evaluatie 8.1
99
Peer reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
8.1.1
review door Ivan Vriezen
99
8.1.2
review door Thien Nguyen . . . . . . . . . . . . . . . . . . 103
8.1.3
review door Marcel Okhuijsen . . . . . . . . . . . . . . . . 103
8.1.4
review door Dennis Tessels . . . . . . . . . . . . . . . . . 104
8.1.5
review door Joost van Weenen . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . .
9 Literatuur
107
10 Verantwoording
108
III
Bijlagen
109
A Urenstaten
110
B Code
118
B.1 Netwerkcommando evaluatie . . . . . . . . . . . . . . . . . . . . . 118 B.2 iDrive() functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 C LATEX documenten
120
C.1 Usepackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 C.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 D Schema’s
122
5
Lijst van figuren 3.1
Trechter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2
Grijper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3
Eenvoudige centreerder. . . . . . . . . . . . . . . . . . . . . . . .
22
3.4
Zwenkbare centreerder.
. . . . . . . . . . . . . . . . . . . . . . .
23
3.5
Lego armen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.6
Kabels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.7
Infrarood ontvanger. . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.8
Beweegbare draadloze camera. . . . . . . . . . . . . . . . . . . .
28
3.9
Schema van de voeding . . . . . . . . . . . . . . . . . . . . . . . .
30
3.10 Schema van de IR-detector . . . . . . . . . . . . . . . . . . . . .
31
3.11 Schema van het schakelcircuit voor een motor . . . . . . . . . . .
32
3.12 Schema van transistorschakeling voor de toeter . . . . . . . . . .
33
3.13 Relaties tussen hardware en software componenten . . . . . . . .
37
3.14 Flowchart van de globale opbouw van de code . . . . . . . . . . .
41
3.15 Flowchart van de initialisatie van de hardware . . . . . . . . . . .
42
3.16 Flowchart van de initialisatie van de robot . . . . . . . . . . . . .
43
3.17 Flowchart van de opbouw van de robot lus . . . . . . . . . . . . .
44
3.18 Flowchart van de functie waarin netwerkcommando’s worden afgehandeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.19 Flowchart van het aansturen van de LED’s . . . . . . . . . . . .
47
3.20 Flowchart van het aansturen van het LCD-display . . . . . . . .
48
3.21 Flowchart van de docking-procedure code . . . . . . . . . . . . .
54
3.22 Flowchart van de disarm code . . . . . . . . . . . . . . . . . . . .
56
6
IPROJ1 - Project semester 6, blok 1
18 april 2007
3.23 Numpadindeling op een toetsenbord . . . . . . . . . . . . . . . .
57
3.24 Richtingen die overeenkomen met de numpad toetsenindeling. . .
57
3.25 Werking van de iDrive() functie . . . . . . . . . . . . . . . . . . .
58
3.26 Flowchart van de motorcode . . . . . . . . . . . . . . . . . . . . .
58
3.27 Globale werking van smoothcontrol . . . . . . . . . . . . . . . . .
59
3.28 Op snelheid komen van de robot vanuit stilstand. . . . . . . . . .
60
3.29 Repository uitchecken. . . . . . . . . . . . . . . . . . . . . . . . .
67
3.30 Repository url opgeven. . . . . . . . . . . . . . . . . . . . . . . .
68
3.31 Overzicht van de bestanden die opgehaald worden. . . . . . . . .
68
3.32 Aangepaste bestanden zijn te herkennen aan het rode uitroepteken. 69 3.33 Commit 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
3.34 Commit 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
3.35 Wiki van webapplicatie Trac . . . . . . . . . . . . . . . . . . . . .
72
3.36 Repository weergave van Trac . . . . . . . . . . . . . . . . . . . .
73
3.37 Code weergave van Trac . . . . . . . . . . . . . . . . . . . . . . .
73
4.1
84
Het eindproduct . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1 Schema van de test A/D-converter schakeling . . . . . . . . . . . 122 D.2 Schema van de complete A/D-converter schakeling . . . . . . . . 123
7
Lijst van tabellen 3.1
Jumper standen voor programmeren ARM-board . . . . . . . . .
39
3.2
Meetwaarden netwerk-interrupts . . . . . . . . . . . . . . . . . .
51
6.1
Projectleden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
7.1
Fase specificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
7.2
Fase 1 - Start project . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.3
Fase 2 - Ontwerpen en realiseren van de docking-procedure . . .
95
7.4
Fase 3 - Ontwerpen en realiseren van het bomdemontage-systeem
96
7.5
Fase 4 - Ontwerpen en realiseren netwerk-functionaliteit . . . . .
96
7.6
Fase 5 - Oplevering . . . . . . . . . . . . . . . . . . . . . . . . . .
97
7.7
Urenstaat totaal . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
A.1 Urenstaat week 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.2 Urenstaat week 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.3 Urenstaat week 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.4 Urenstaat week 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.5 Urenstaat week 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 A.6 Urenstaat week 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.7 Urenstaat week 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8
Hoofdstuk 1
Inleiding Hier volgt het eindverslag behorende bij de realisatie van het ingenieursproject 1 (IPROJ1). Dit document bevat de technische totstandkoming van het eindproduct en de beheersing van de kwaliteit. Als eindproduct dient er een op afstand bestuurbare robot gerealiseerd te worden. Deze dient in staat te zijn om binnen een bepaalde tijd een aantal vooraf beschreven bommen onschadelijk te maken. Dit gebeurd in een donkere ruimte met obstakels. De realisatie van het project geschiedt in het eerste lesblok van semester 6 vanuit het vak IPROJ1. Hierbij hebben de begeleidende docenten de rol van opdrachtgever. Oplevering van de tot stand te brengen producten zal geschieden in de activiteitenweek. Hierbij moet aan al de vooraf gestelde eisen van de opdrachtgever worden voldaan. Het hoofddoel van het project is dat er geleerd wordt hoe een microcontrollersysteem kan communiceren met de gebruiker, sensoren, actuatoren en interfaces. Verder is een belangrijk aspect dat bij het projectmatig werken alles in de praktijk wordt gebracht wat in voorgaande jaren is geleerd. Het webadres van de versiebeheersoftware is http://bom.team-fonzie.net/. Op de voorpagina staan de notulen en voortgangsrapportages. Alle code-versies en bestanden kunnen hier ingezien worden. Voor vragen en verdere informatie over het project en/of de documentatie gelieve contact op te nemen met de projectleider; de heer I. Vriezen. Dit kan via het e-mailadres
[email protected], of telefonisch via het nummer 06-51471751.
9
Deel I
Techniek
10
Hoofdstuk 2
Analyse en ontwerp 2.1
Opdrachtomschrijving
De doelstelling van het project is het realiseren van het eindproduct. Vanuit de vooraf geleverde projectdocumentatie en communicatie met de opdrachtgevers is er vastgesteld dat het volgende eindproduct gerealiseerd moet worden: Als eindproduct dient er een op afstand bestuurbare robot gerealiseerd te worden. Deze dient in staat te zijn om binnen een bepaalde tijd een aantal vooraf beschreven bommen onschadelijk te maken. Dit gebeurd in een donkere ruimte met obstakels.
2.2
Eisen
Het product dient te worden gerealiseerd aan de hand van de in dit hoofstuk beschreven specificaties en opgelegde eisen.
2.2.1
Specificaties robotplatform
De specificaties van het robotplatform: • Er wordt gebruikt gemaakt van het robot-platform dat is geleverd bij de start van het project. • Het robotplatform bevat o.a. een behuizing met door twee electromotoren aangedreven rupsbanden, een accu, een IC-board voor de motoraansturing en een Hogeschool Utrecht ARM-board versie 2.31 . • Het robotplatform mag opgebouwd worden met o.a. Mecano-onderdelen. 1 Specificaties van het ARM-board versie 2.3 inclusief de datasheet van de CPU staan vermeld op de website http://www.electronicengineering.nl/bent/ onder ARM omgeving
11
IPROJ1 - Project semester 6, blok 1
18 april 2007
• De accu is een loodaccu met de volgende specificaties: – Merk: Panasonic – Spanning: 12V – Capaciteit: 7.2Ah/20HR – Cycle use: 14.5V-14.9V (25℃) – Initial current: minder dan 2.88A – Standby-use: 13.6V-13.8V (25℃) • Er dient gebruik te worden gemaakt van een accu die voldoet aan deze specificaties. • De maximale afmetingen van het complete robotplatform zullen niet meer bedragen als: 80cm x 50cm x 50cm (l x b x h). • Het complete robotplatform zal niet meer wegen dan 20kg. De robot zal de volgende functionaliteit bevatten: • De robot kan op afstand bestuurd worden. • Op de robot zal een infrarood webcam gemonteerd worden. • De webcam zal het beeld via een draadloze netwerkverbinding uitsturen. • Op de robot zal verlichting gemonteerd worden voor de webcam, zodanig dat de bestuurder genoeg van de omgeving ziet om de bommen te lokaliseren en de robot te besturen.2 • De robot zal in staat zijn om een autonome dockingprocedure3 te doorlopen. • De robot zal in staat zijn om de in dit document gespecificeerde bommen te demonteren. Naast de primaire functionaliteit zal de robot de volgende additionele functies bevatten: • Indicator van de beschikbare accu-capaciteit: – Een indicatie van de beschikbare capaciteit van de accu zal worden weergegeven. – De weergave zal alleen mogelijk zijn als er geen actuatoren worden gebruikt. Deze keuze is gemaakt omdat het vermogen dat de actuatoren gebruiken de meting van de accuspanning zal beinvloeden. – De weergave zal, afhankelijk van de nog te ontwerpen interface op het robotplatform, worden weergegeven d.m.v. LED’s en / of het display. 2 De 3 De
specificaties van de verlichting zullen worden opgeleverd in de 4e hoofdfase dockingprocedure is gespecificeerd op pagina 13.
12
IPROJ1 - Project semester 6, blok 1
18 april 2007
– Nadat de robot is opgestart zal een indicatie van de beschikbare capaciteit van de accu worden weergegeven. – De indicatie van de beschikbare capaciteit van de accu zal verstuurd worden over de draadloze netwerkverbinding en weergegeven aan de eindgebruiker, indien de projectgroep telecommunicatie hieraan meewerkt. – De accuspanning zal worden geijkt voor een grotere accuratesse van de weergave van de beschikbare capaciteit. • ”Smooth control”: – De bediening van de robot zal worden vereenvoudigd door een soepele overgang tussen verschillende snelheden en bochten. – De robot zal in staat zijn om bochten rijdend te kunnen nemen. – De robot zal in staat zijn om stilstaand te draaien. – De robot zal niet gelijk stoppen, maar de snelheid geleidelijk laten afnemen. – De robot zal niet maximaal accelereren, maar de snelheid geleidelijk laten toenemen. De dockingprocedure bestaat uit de volgende chronologische stappen: • De robot wordt op afstand richting een bom bestuurd, de bestuurder van de robot kan het beeld van de webcam gebruiken om omgeving van de robot te bekijken. • De robot dient zo recht mogelijk4 voor de voor- of achterzijde van de bom te worden gepositioneerd. • Vervolgens kan er door de bestuurder op afstand een commando worden verstuurd waardoor de robot begint met de autonome docking-procedure. • De robot zal proberen de bom zelfstandig te demonteren. • Nadat de bom is gedemonteerd zal de robot de bom loskoppellen, en tussen de 10 en 80cm afstand nemen van de bom. • De autonome dockingprocedure is voltooid, de besturing wordt overgedragen aan de bestuurder. Er zijn voorwaarden verbonden aan de positionering van de bom voor het uitvoeren van de dockingprocedure. Functionaliteit en voorwaarden van de docking-procedure: • De autonome dockingprocedure kan worden geannuleerd door de bestuurder. De robot zal dan stoppen met rijden. 4 Zie
de functionaliteit en voorwaarden van de docking-procedure op pagina 13
13
IPROJ1 - Project semester 6, blok 1
18 april 2007
• Indien de robot de bom niet correct vastkoppeld dient de autonome dockingprocedure geannuleerd te worden door de bestuurder, vervolgens kan de bestuurder de robot opnieuw positioneren en de autonome dockingprocedure opnieuw starten. • De robot zal tijdens de autonome dockingprocedure tot het moment dat de bom gekoppeld is aan het robotplatform nog bestuurbaar zijn. De besturing zal minder gevoelig reageren dan wanneer de robot niet in de autonome dockingprocedure zit. • Een bom dient met de onderkant op het onderliggende vlak gepositioneerd te staan. (Met andere woorden: rechtop) • Een bom dient van de voor- of achterzijde bereikbaar te zijn. • Een bom mag niet met de voor- of achterzijde bij een afgrond staan. • Afhankelijk van de ondergrond en de afstand tussen de robot en bom, kan het nodig zijn de robot bij te sturen. • Voor de autonome docking-procedure dient de robot ten opzichte van de bom zodanig gepositioneerd te staan dat er aan de volgende voorwaarden voldaan wordt: – Er mogen geen opstakels staan tussen de robot en de bom. – Het midden van de voorkant van de robot dient niet meer dan 6cm naar links of rechts af te wijken van het midden van de bom, gemeten vanaf het moment dat de bom en robot contact maken. – De horizontale hoek tussen de robot en bom mag niet meer bedragen dan 10 ◦ . – De robot en bom dienen op hetzelfde vlak te staan, de verticale hoek tussen de robot en bom mag niet meer bedragen dan 2 ◦ .
2.2.2
Omgeving
Specificatie van de omgevingsfactoren: • De robot functioneerd tot een luchtvochtigheid van 95%, onder de voorwaarde dat er geen condensatie optreedt. • De robot functioneerd tussen de 0℃ en 40℃. • De robot dient te worden opgeslagen tussen de -20℃ en 70℃. • De robot functioneerd op een hoogte tussen de -100m en 3000m. • De robot is in staat om bommen te demonteren als de sensor(en) van de infrarood-LED detectieschakeling niet meer dan 500 Lux licht ontvangen, de infrarood-LED zelf en verlichting van de robot buiten beschouwing gelaten. 14
IPROJ1 - Project semester 6, blok 1
18 april 2007
• De voedingsspanning van de accu dient niet meer dan 15% te fluctueren, en de spanning dient minimaal 10V te bedragen. • De robot is niet waterbestendig. De eindtest is de omgeving waarin de robot dient te opereren. De eindtest dient aan de volgende specificaties te voldoen: • De minimale afmetingen van de ruimte zijn 5x8 m2 . • Er bevinden zich drie bommen in de ruimte, deze bommen voldoen aan de specificaties zoals vermeld in dit hoofdstuk. • Vanaf het begin van de test duurt het minimaal 580 seconden (9:40 minuten) voor de bommen niet meer demonteerbaar zijn. • De test is voltooid op het moment dat alle bommen zijn gedemonteerd. • Er mag niemand in de ruimte aanwezig zijn om te helpen. • De robot wordt op afstand bestuurd vanaf een willekeurige plek op aarde. • Met de gespecificeerde maximale afmetingen van de robot5 dient het mogelijk te zijn de eindtest te voltooien. De robot is ontworpen om een specifiek type bom uit te schakelen. Een bom dient aan de volgende specificaties te voldoen: • De behuizing is gebaseerd op een metalen brievenbus. • De kleur is wit. • De achterkant is gedefinieerd als de zijde met het grootste oppervlak, het deksel van de bom zit aan de bovenzijde. • Er bevindt zich een knipperende infrarood-LED aan de bovenzijde van de bom. – De LED bevindt zich precies in het midden van de deksel op de bom, met een maximale afwijking van 0,5cm in zowel de breedte als lengte. – De LED zal indien de bom is geactiveerd sneller pulseren naarmate de tijd vorderd. – De LED dient het licht zodanig uit te sturen dat het recht boven de LED valt te detecteren. – De intensiteit van het licht dat de LED uitstuurt dient minimaal 80% van de intensiteit te zijn van de LED in de testbom. – De LED dient van hetzelfde type en model te zijn als in de testbom6 . 5 Zie 6 De
pagina 12 voor de specificatie van de maximale afmetingen. testbom is het testmodel dat beschikbaar wordt gesteld vanaf week 2.
15
IPROJ1 - Project semester 6, blok 1
18 april 2007
– De minimale en maximale frequentie waarmee de LED pulseert zal niet meer dan 20% afwijken van de frequenties die de test bom uitstuurd. – De duty cycle van de puls wijkt niet meer dan 20% af van de LED in de testbom. • Aan de zijkanten van de behuizing zijn twee schakelaars van het type SPST gemonteerd. – De schakelaars zitten op een hoogte van 10cm vanaf de onderkant van de onderkant van de bom, met een maximale afwijking van 0,5cm. – De schakelaars zitten precies tussen de voorkant en achterkant van de bom in, met een maximale afwijking van 0,5cm. – De schakelaars zijn in verticale richting gemonteerd. Een schakelaar kan dus naar boven of naar beneden wijzen. – De schakelaars dienen niet meer dan 5 ◦ af te wijken, ten opzichte van een rechte lijn vanuit het midden van de onderkant naar het midden van de bovenkant van de zijkant van de bom. – Het bewegende deel van schakelaars dient minimaal 5mm uit te steken. – De schekelaars dienen van hetzelfde type en model te zijn als in de testbom. – Door de schakelaar om te schakelen verwisseld de aan-stand in de uit-stand of vice versa. • De bom is uitgeschakeld indien beide schakelaars in de uit-stand staan. • Wanneer de bom is uitgeschakeld, zal de IR-led binnen 200ms uitgeschakeld zijn. • Het is niet duidelijk of de schakelaars in de aan- of uit-stand staan als de bom is geactiveerd. • Het gewicht van bom is tussen de 2,0kg en de 5,0kg. • De afmetingen van de behuizing van de bom dienen niet meer dan 0,3cm af te wijken van de testbom.
2.2.3
Code en gebruik systeem-middelen
• De code voor het ARM-board zal worden geschreven in de programmeertaal C. • Voor iedere geschreven functie zal documentatie worden opgeleverd die voldoet aan de eisen zoals gespecificeerd in hoofdstuk 3.1 van het document Projectverslag eisen 7 . 7 Het document Projectverslag eisen is meegeleverd bij de kick-off documentatie van het project.
16
IPROJ1 - Project semester 6, blok 1
18 april 2007
– Er dient o.a. beschreven te worden wat de functie doet, wat de belasting op de hardware is, en welke afhankelijkheden er zijn van andere functies. • Bij het ontwerpen en schrijven van software zal zo behoudend mogelijk omgegaan worden met het gebruik van het aantal processor-instructies, RAM en ROM van het ARM-board. Het gebruik van deze middelen zal verantwoord worden. • De CPU, RAM, ROM en I/O-poortenvan het ARM-board mogen volledig gebruikt worden voor de realisatie van het product, op voorwaarde dat het gebruik van de capaciteit verantwoord wordt. • Er dient geen netwerkverkeer te worden gestuurt naar het robotplatform dat niet bedoeld is voor het opvragen van informatie of het besturen van de robot. • Bij het opstellen van het dataoverdracht-protocol zal rekening worden gehouden met de limieten en belasting op de hardware van het robotplatform. • De opzet en aanpak van de code zal beschreven worden is het softwareontwerp verslag. Dit document zal ook de geschatte hoeveel CPU-instructies, RAM, ROM en I/O van zowel het totale software-ontwerp als de functies die in het ontwerp beschreven staan afvangen. • De code zal geschreven worden voor een ARM7TDMI-S processor met de volgende specificaties: – Model LPC2106 van fabrikant Philips. – 128 kb flash geheugen. – 64 kb statisch RAM
2.2.4
Derde partij
Een deel van het eindproduct zal gerealiseerd worden door een projectgroep bestaande uit studenten van dezelfde klas als onze projectgroep, die de specialisatie communicatie-technologie volgen. Projectgroep communicatie technologie: • De projectgroep communicatie-technologie is verantwoordelijk voor de werking van de webcam, onze projectgroep zal de webcam monteren. • De projectgroep communicatie technologie is verantwoordelijk voor een werkende IP-functionaliteit. Echter, onze projectgroep is verantwoordelijk voor het functioneren van de code en hardware aan de kant van het robotplatform. • De projectgroep communicatie-technologie is verantwoordelijk voor het weergeven van het beeld van de webcam en eventuele andere vereisde informatie aan de bestuurder van de robot. 17
IPROJ1 - Project semester 6, blok 1
18 april 2007
• De projectgroep communicatie-technologie is verantwoordelijk voor het ontwikkellen van de gebruikersinterface voor het besturen van de robot. • De projectgroep communicatie-technologie en onze projectgroep zullen gezamelijk een dataoverdacht-protocol opstellen. De projectgroep communicatietechnologie dient het protocol exact te implementeren zoals gespecificeerd zal worden in het dataoverdacht-protocol. • De projectgroep communicatie-technologie is verantwoordelijk voor de specificaties van de door hun opgeleverde producten. Onze projectgroep is niet aansprakelijk voor eventuele conflicten tussen de door de projectgroep communicatie-technologie opgegeven specificaties en de specificaties in dit document. Producten van de projectgroep communicatie-technologie kunnen zorgen dat een aantal specificaties in dit document niet meer geldig zijn.
2.3
Algemene voorwaarden
Voor het project zijn de volgende randvoorwaarden vastgesteld: Samenstelling en uitvoering • Het project zal worden uitgevoerd door vijf studenten. • Elk individu binnen de projectgroep is verantwoordelijk voor de realisatie van het project in zijn totaliteit. • In de lesweken 2 t/m 7 is er op dinsdag overleg met de opdrachtgever. • Van de vergaderingen die in een lesweek worden gehouden wordt een wekelijkse rapportage opgesteld in de vorm van een notule. • Er worden wekelijkse voortgangsrapportages opgesteld en bijgehouden voor het bewaken van de te besteden uren. • Deze voortgangsrapportages worden wekelijks gepresenteerd aan de oprachtgever. • De projectgroep dient te allen tijde bereikbaar te zijn, het zij via e-mail of telefonisch. • De projectleider fungeert als contactpersoon naar de opdrachtgever / begeleidende docenten. Realisatie • Het project dient te worden uitgevoerd in semester 6 blok 1, binnen 7 lesweken en een activiteitenweek. • Aanschaf van projectgerelateerde hardware verloopt via de labbeheerder; de heer Udo van Heteren. 18
IPROJ1 - Project semester 6, blok 1
18 april 2007
• Het budget is vastgesteld op een maximum van rond de EUR 150. • De projectgroep heeft de beschikking over een eigen projectlokaal op Oudernoord 370. • In dit projectlokaal zijn vier computers met internetverbinding beschikbaar. • Er wordt gewerkt op de locaties Oudenoord 370 en Oudenoord 700. • Elk projectlid zal rond de 140 uur besteden aan het totale project. Oplevering • Het project zal in zijn geheel worden opgeleverd in de activiteitenweek van blok 1. • De oplevering zal omvatten: – Een robot die voldoet aan de gespecificeerde eisen. – Een eindpresentatie. – Een demonstratie in de vorm van een wedstrijd. – Technische systeem documentatie. – Een uitvoerig projectverslag, deze bevat zowel een technisch als projectmatig gedeelte. – Een teamrapport. • Elk projectlid zal individueel als extra opdracht een printplaat ontwerpen met een pakket waarmee schema’s kunnen worden getekend en een layout kan worden ontworpen. Tijdens de derde of vierde week wordt er een extra college gegeven over een dergelijk pakket. • Na het succesvol afsluiten van het project ontvangt elk projectlid 5 ECTS.
19
Hoofdstuk 3
Realisatie 3.1 3.1.1
Mechanica Functionaliteit
De basis voor het eindproduct vormt het robotplatform. Dit platform is uitgebreid met de volgende functionaliteit: • De robot kan koppellen aan een bom. • Er is een methode ontwikkeld om de op de bom bevestigde schakelaars om te kunnen zetten. • Een controle of de bom is uitgeschakeld, aan de hand van de op de bom bevestigde IR-led. • Een camera met verlichting. • Een indicatie van de beschikbare accu-capaciteit. De aanpak om deze functionaliteit te realiseren is beschreven in de volgende paragrafen. Er is ook beschreven welke methoden zijn overwogen en er is verantwoord waarom bepaalde keuzes zijn genomen.
3.1.2
Docking
Probleemstelling De bommen dienen zo snel mogelijk gedemonteerd te worden. Daarom is het van belang dat er weinig tijd hoeft te worden besteed met het positioneren van de robot ten opzichte van de bom. Positionering is noodzakelijk om de op de bom bevestigde schakelaars om te kunnen schakelen en de op de bom bevestigde IR-led uit te lezen. 20
IPROJ1 - Project semester 6, blok 1
18 april 2007
Mogelijke oplossingen De volgende oplossingen zijn bedacht: • Trechter • Grijper • Eenvoudige centreerder • Zwenkbare centreerder Trechter De trechter bestaat uit twee schuine vlakken zoals weergegeven in figuur 3.1. Hiermee wordt de bom naar het midden geschoven wanneer de robot naar voren rijdt. Het voordeel van dit ontwerp is dat het eenvoudig te implementeren is. Een groot nadeel is echter dat de bom eenvoudig in een dwarse positie kan worden verschoven, waardoor het lastig wordt de bom te demonteren.
Figuur 3.1: Trechter.
Grijper De grijper bestaat uit een vaste arm en een draaibare arm met haak, zoals weergegeven in figuur 3.2. De draaibare arm met haak schuift de bom op zijn plek en houd deze opgesloten tijdens de bom-demontage. Het nadeel van deze oplossing is dat er maar aan een kant mag worden afgeweken van de inrijhoek. Ook is deze oplossing ingewikkeld omdat de arm met een actuator moet worden aangedreven. Eenvoudige centreerder De eenvoudige centreerder is een systeem dat de bom recht en in het midden van de robot schuift, dit systeem is eenvoudig gehouden omdat dit de betrouwbaarheid ten goede komt. Het systeem bestaat uit twee draaibare armen die de bom naar het midden van de robot schuiven, de 21
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.2: Grijper. armen worden in positie gehouden door een elastiek en een beweegbare draad. Dit is weergegeven in figuur 3.3. Door de voorwaartse kracht van de robot te gebruiken zijn er geen extra actuatoren nodig. Bij het schuiven maakt het ook niet uit of de bom of de robot nu schuift. Een praktijktest heeft een probleem opgeleverd. De bom kan namelijk snel omvallen. Dit probleem is opgelost door de kracht die op de bom wordt uitgeoefend op een lager punt te richten en twee kleine haakjes aan de uiteinden van de armen te plaatsen zodat de bom niet om kan vallen.
Figuur 3.3: Eenvoudige centreerder.
Zwenkbare centreerder De zwenkbare centreerder is gebaseerd op idee van de eenvoudige centreerder. De verandering is dat het hele mechaniek nog eens zwenkbaar is door middel van twee scharnierpunten, zoals weergegeven in fi22
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.4: Zwenkbare centreerder. guur 3.4. Dit is bedacht, omdat het centreren bij de eenvoudige centreerder gebaseerd is op het schuiven van de bom of robot en dat zou bij dit ontwerp niet meer nodig zijn. Echter een nadeel van dit ontwerp is dat het niet simpel te construeren is, en dat de werking niet volledig betrouwbaar is omdat het zwenkbare deel ook van de bom af zou kunnen draaien.
Gekozen oplossing: Eenvoudige centreerder Bij de keuze voor de oplossing is er rekening gehouden met de haalbaarheid en de betrouwbaarheid. Er is besloten om in het ontwepr gebruik te maken van de eenvoudige centreerder. Het maakt namelijk niet uit of de bom of de robot schuift als de bom gecentreerd wordt voor de auto. Ook zijn er bij deze oplossing geen actuatoren nodig en zijn er eenvoudig schakelaars aan te koppelen waar informatie uit af te lezen is. De twee armen komen tegen de zijkant van de bom aan, wat mogelijkheden biedt voor het het monteren van het bomdemontagesysteem aan de armen.
Uitwerking De uiteindelijke oplossing die gekozen is, wordt voor een groot deel opgebouwd uit meccano. De meccano constructie wordt voorop de robot geplaatst. Deze constructie bestaat onder ander uit scharnierpunten bestaande uit twee ’M6’ bouten en moeren. Op deze scharnierpunten worden twee platte, lange platen vastgemaakt in de vorm van een ’L’. Door een elastiek worden de twee L-vormige platen open gehouden. De maximale openingshoek van deze constructie wordt bepaald door een flexibele draad. Aan het uiteinde van de platte lange platen, zijn twee hoeken verbonden. Wanneer de bom met deze constructie eenmaal is ingesloten, kan de bom bijna niet meer omvallen ongeacht de aanrijdsnelheid van de robot. Door twee schakelaars achter de L-vormige constructie te plaatsen, kan er worden gedetecteerd of de bom is ingesloten en of deze correct is 23
IPROJ1 - Project semester 6, blok 1
18 april 2007
gepositioneerd.
3.1.3
Bom-demontage
Probleemstelling Op de bom zijn twee schakelaars aanwezig die onafhankelijk van elkaar geschakeld dienen te worden. De schakelaars zijn geplaatst op circa tien centimeter hoogte, aan de zijkant, in het midden van de bom. De schakelaars kunnen alleen omhoog of omlaag geschakeld worden. Er dient een systeem te worden ontwikkeld dat deze schakelaars kan omzetten.
Mogelijke oplossingen • Lego armen • CD-lade • Kabels
Lego armen Met LEGO kan een F-vormige arm die naar boven en beneden kan schuiven worden gerealiseerd, zoals weergegeven in figuur 3.5. Hierbij wordt een tandwiel aan een electromotor bevestigd, het tandwiel schuift een kartelvormige strip naar boven en beneden. Een nadeel van deze oplossing is dat deze arm lastig is te integreren met meccano. De LEGO-constructie zou ook vrij groot worden, en er is een kans dat de LEGO niet sterk genoeg is.
Figuur 3.5: Lego armen.
24
IPROJ1 - Project semester 6, blok 1
18 april 2007
CD-lade Het idee was om met het bewegingsmechanisme van een CD-rom speler de schakelaars te bedienen. Bij deze methode wordt ook de F-vormige arm gebruikt. Wanneer de cd-rom speler naar buiten schuift, schuift ook de F-vormige arm naar beneden of naar boven om de schakelaars te bedienen. Het nadeel van dit mechanisme is dat de sterkte van de cd-rom speler niet voldoende zal zijn om de schakelaars over te halen, en het uitschuiven gebeurd over een te grote afstand. De cd-rom speler neemt ook veel ruimte in beslag op het robotplatform.
Kabels Zie figuur 3.6 voor het schema van dit systeem. De besturing van dit systeem werkt door het aantrekken en duwen van remkabels. Aan het begin van elke kabel wordt een motor bevestigd die de kabel kan aantrekken of wegduwen. Dit proces wordt aangedreven door een motor die kan samentrekken en wegduwen. Aan de andere kant van de kabel wordt een schuifsysteem bevestigd, waaraan dezelfde F-vormige arm uit de vorige oplossing bevestigd wordt. De arm kan alleen omhoog of naar beneden geschoven worden.
Figuur 3.6: Kabels.
Gekozen oplossing: Kabels Bij de uiteindelijke keuze, wordt er rekening gehouden met de grootte, de complexiteit, de geleverde kracht en hoe sterk de constuctie in elkaar zit. Aan de hand hiervan valt de keuze op de oplossing met de kabels. Bij deze oplossing is de gebruikte hoeveelheid ruimte beperkt, omdat slechts de twee motoren op het robotplatform gemonteerd moeten te worden. De kabels nemen amper plaats in en deze kunnen desnoods getrimd worden. De complexiteit van het kabelmechaniek is gering, er zijn slechts twee standen, namelijk trekken en duwen. Dit wordt gerealiseerd met twee motoren die onafhankelijk van elkaar kunnen werken. Doordat de constructie eenvoudig is gehouden, is deze relatief sterk.
Uitwerking De motoren die kunnen samentrekken en weg duwen zullen worden gebouwd van twee centrale deurvergrendelings-motoren uit een auto. Deze motoren hebben 25
IPROJ1 - Project semester 6, blok 1
18 april 2007
een rechtlijnige uitslag van twee centimeter en zijn zeer krachtig. Ook is de ruimte die deze motoren innemen het meest beperkt. De connectie van motoren naar F-vormige armen zal gebeuren via rem kabels, hierbij bestaat de kans dat de remkabels te flexibel zijn. Dit probleem is op te lossen door de binnenkabel aan het begin en uiteinde te vertinnen waardoor extra stugheid ontstaat. Om van de rechtlijnige beweging van de remkabels tot de stevig te monteren F-vormige armen te komen worden twee ijzeren pijpjes die in elkaar schuiven gebruikt. Dit systeem zal voor de geleiding zorgen zodat de armen niet weg gedrukt kunnen worden, en dus niet naast de schakelaars zullen bewegen, maar deze echt zullen omhalen.
3.1.4
Controle bom-deactivatie
Probleemstelling Aan de bovenkant, in het midden van de bom, bevindt zich een infrarood LED. De LED zal steeds sneller knipperen naar mate de tijd verstrijkt. De bom gaat af wanneer de LED volledig aan staat. De bom is ontmanteld wanneer de LED niet meer knippert. De bom bevindt zich in een donkere kamer. Om te controleren of de bom is gedeactiveerd, dient er een systeem te worden bedacht dat het licht van de LED kan detecteren.
Mogelijke oplossingen • Infrarood ontvanger • Beweegbare draadloze camera
Infrarood ontvanger Zie figuur 3.7. De infrarood ontvanger wordt hoog (30 cm vanaf het robotplatform) en voorop de robot geplaatst. Wanneer de bom is gelokaliseerd en vastgeklemd door de auto, dan staat de infrarode ontvanger precies boven de infrarode LED. Hiermee kan er gecontroleerd worden of de LED nog knippert of lang uit staat. Er kleven echter nadelen aan deze oplossing. Een daarvan is dat de infrarood ontvanger zeer dicht bij de LED dient te staan (het liefst bovenop), om te kunnen detecteren of de LED uit of aan staat. Een ander nadeel is de gevoeligheid van de infrarood ontvanger, de omgeving mag hierdoor weinig of geen (dag)licht bevatten zodat de ontvanger niet benvloed wordt.
Beweegbare draadloze camera Zie figuur 3.8. De Camera wordt hierbij hoog geplaatst, ter hoogte van de infrarood LED. Omdat de camera op een redelijk hoge positie wordt geplaatst, kan deze dienen als een oog voor de bestuurder. Infrarood signalen die vanuit de LED komen, kunnen door de camera geregistreerd worden en als witte stippen in het beeld verschijnen. De bestuurders kunnen hierdoor zien waar de bom zich ongeveer bevindt en of de bom aan of uit is. 26
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.7: Infrarood ontvanger.
Gekozen oplossing: Beide
Aan de hand van de bovenstaande oplossingen, kan er niet gekozen worden voor ´e´en van die oplossingen. De keuze is duidelijk: Er wordt gekozen voor beide oplossingen. Deze keuze is gemaakt omdat beide oplossingen elkaar aanvullen. De infrarood detector is gevoeliger voor gewoon licht en deze moet dichtbij de LED staan om te detecteren. Maar daar heeft de camera geen last van, deze kan al op een redelijk verre afstand infrarood signalen oppikken en deze is minder/niet gevoelig voor gewoon licht. 27
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.8: Beweegbare draadloze camera.
Uitwerking Wanneer de robot een kamer binnenkomt, kan de bestuurder via beweegbare camera de robot navigeren. De bestuurder kan via de camera zien of er een bom in de buurt is, doordat er een wit stipje gaat flikkeren. Doordat de camera niet alleen als een infrarood detector werkt, maar ook als navigator en oog van de bestuurder, kan deze op sommige momenten niet op de LED richten, maar bijvoorbeeld op het navigeren van de volgende route of een visueel systeemcontrole doen. Bij het ontmantelen van de bom komt de infrarood detector in werking, deze neemt nu de detectiefunctie van de camera over en geeft een signaal af aan het arm bord wat hieruit kan opmaken of de bom uit geschakeld is. 28
IPROJ1 - Project semester 6, blok 1
3.1.5
18 april 2007
Camera en verlichting
Probleemstelling Er zal een draadloze camera en verlichting gemonteerd worden op de robot. Het zicht van de camera zal worden gebruikt door de bestuurder van de robot om te navigeren. De positie van de camera dient zo gepositioneerd te zijn dat de bestuurder goed zicht heeft op de omgeving, en het type verlichting moet genoeg licht geven om in een donkere ruimte de omgeving te kunnen zien.
Mogelijke oplossingen verlichting • Een 5x5 array van LED’s. Het voordeel van LED’s is dat deze relatief weinig energie nodig hebben. De led’s worden in een bundel geplaatst zodat deze bij elkaar meer licht geven. • Een bouwlamp. Deze bestaat uit een lamp van 60 tot 250 Watt. De bedoeling hierbij is dat de lamp naar voren wordt gericht en wordt gebundeld voor een gefocuste straal. • Een tl-lamp, deze lamp zal de vorm hebben van een looplamp zoals veelal wordt gebruikt door auto-monteurs.
Oplossing Positionering van de camera De camera zal hoog op de robot worden gemonteerd. Hierdoor zal er over lage opstakels gekeken kunnen worden. De camera kan ook ronddraaien, door de camera hoog te positioneren zal de camera minder hinder ondervinden van constructies die op het robotplatform zijn geplaatst. De camera zal ook aan de achterkant van de robot worden gemonteerd. Hierdoor is het overzicht op de docking-procedure beter.
3.2
Elektronica
De gebruikte elektronica bevat veelal basis onderdelen waardmee reeds in voorgaande projecten is gewerkt. Doordat deze keer het project meerdere deelschakelingen met zich meebrengt, is het van belang de deelschakelingen goed op elkaar af te stemmen. Het op elkaar afstemmen vergt extra kennis van deze basis schakelingen. In dit verslag wordt verder niet ingaan op de basis begrippen, er wordt slechts aangeven welke delen van de schakeling zijn aangepast met welk doel. In dit project zijn de volgende deelschakelingen gebruikt: • De voeding • Infrarood detectie 29
IPROJ1 - Project semester 6, blok 1
18 april 2007
• Schakelcircuit voor centraal slot motoren • Aansturing 12V toeter • Aansturing omvormer • Accu meter. In de volgende paragraven zullen deze schakelingen stuk voor stuk worden besproken.
3.2.1
De voeding
Omdat er bij dit project veel zware 5 Volt verbruikers worden gebruikt is er een zware voeding nodig. De verbruikers bestaan uit: de webcam, het wireless acces point, IR-detector, 5 chakel-relais en een aansturing voor de toeter. Omdat nu nog niet alle verbruiken bekend zijn wordt de te leveren stroom geschat op 7.5 Amp`ere. Dit vermogen is niet te leveren met een standaard 7805 regulator IC. Daarom is de schakeling gebruikt zoals weergegeven in figuur 3.9.
Figuur 3.9: Schema van de voeding De werking van de voeding is als volgt: het regulator IC zal proberen om de 5 Volt aan de uitgang te handhaven. Bij geen belasting zal hierdoor bijna geen stroom (rond de 5 mA) lopen door de weerstand R1 en zal de transistor Q1 blijven sperren. Op deze manier werkt het voedings IC normaal zoals we gewend zijn. Bij een zeer zware belasting zal er door weerstand R1 een spanningsval ontstaan en deze spanningsval zal transistor Q1 open gestuurd worden en gaan werken als een bypass zodat het voedings IC niet zwaar belast wordt. Door de 30
IPROJ1 - Project semester 6, blok 1
18 april 2007
keuze van R1 zo te nemen dat de stroom door het voedings IC (bij maximale belasting) niet boven zijn maximaal toelaatbare stroom uit komt zal de schakeling goed blijven werken. Wel dient er rekening te worden gehouden met het kiezen van een weerstand dat deze het aantal Watt dat erin gedissipeerd wordt wel aan kan en dat transistor Q1 de te schakelen stroom aan kan. Vergeet ook de koeling niet voor het regulator IC en transistor omdat deze veel vermogen moeten dissiperen. De ingang van de voeding mag niet lager zijn dan 7 Volt. De uitgang van het IC (dus de voeding) zal 4 % afkunnen wijken van 5 Volt en werkt in een omgevingstemperatuur tussen 0 tot 125 graden C.
3.2.2
Infrarood detectie
Om te zien of een bom is uitgeschakeld moet er gekeken worden naar een infrarood led. Als de bom op scherp staat zal de led knipperen en als de bom uitgeschakeld is zal de led ook uit zijn en blijven. Omdat de frequentie van de knipperende infrarood led niet bekend is wordt er alleen gekeken of de led korte tijd aan is geweest, als dit zo is stuurt de schakeling een 1 uit. Door een reset puls 0 kan een nieuwe meting gestart worden. Nu zal de schakeling zolang als er geen infrarood licht gemeten wordt een 0 uitsturen. Figuur 3.10 toont het schema van de IR-schakeling.
Figuur 3.10: Schema van de IR-detector De werking van de infrarood detector is als volgt: Fotodiode D1 staat in sper richting geschakeld en laat bij totale duisternis geen stroom lopen maar naarmate er meer licht op valt gaat er meer stroom lopen. Hoe groter de stroom door de transistor T1 hoe lager de plus ingang op de comperator. Als het Voltage van de plus ingang van de comperator onder het Voltage van de min ingang komt zal de uitgang 0 worden. Met deze 0 wordt de SR-latch geset en blijft een 1 uitsturen totdat deze weer wordt gereset met een 0 door de processor. Waar men op moet letten bij de comperator is dat de uitgang een open collector is. Hierdoor kan men met een pullup weerstand de uitgang voorzien van iedere gewenste spanning. De min ingang wordt ingesteld met de potmeter, hiermee is dus het niveau in te stellen waarbij de schakeling detecteert. De comperator wordt gevoed tussen +5 Volt en 0 Volt. Het ingangsverschil mag maximaal + en 15 Volt van de voedingspanning afwijken. De SR-latch werkt bij een temperatuur tussen 0-70 C met een voedingspanning van maximaal 5.5 Volt. De voeding mag ongeveer 10% fluctueren. 31
IPROJ1 - Project semester 6, blok 1
3.2.3
18 april 2007
Schakelcircuit voor centraal slot motoren
Om de schakelaars van de bom te bedienen worden centraal slot motoren gebruikt. Deze motoren draaien van uiterste stand tot uiterste stand, als de motor bij zijn uiterste stand is aangekomen zal de stroom door de motor enorm toenemen. Om te voorkomen dat door deze piekstroom het schakelcircuit kapot kan gaan is er voor een mechanische oplossing gekozen, namelijk met relais. Onderstaand schema toont het ontworpen schakelcircuit voor een motor: Figuur 3.11 toont het ontworpen schakelcircuit voor een motor.
Figuur 3.11: Schema van het schakelcircuit voor een motor
3.2.4
De werking van het schakelcircuit
Door gebruik te maken van twee relais zijn er in totaal vier standen mogelijk, twee rust standen, linksom en rechtsom. Verder worden de relais door een transistor bekrachtigd en is een blus diode geplaatst over de spoel ter voorkoming van piek spanningen bij het uitschakelen van de transistor. De transistors werken op een omgevingstemperatuur van 0-70 C. De basisstroom mag maximaal 200 mA zijn.
3.2.5
Aansturing toeter
De gebruikte toeter beschikt over een +12 Volt schakeldraad. Echter de arm processor biedt maximaal 3.3 Volt. Om toch de toeter aan te kunnen sturen is de transistorschakeling gebruikt zoals weergegeven in figuur 3.12. De werking van de transistor schakeling is als volgt: Zolang het Voltage op de basis van transistor T7 lager is als 0.5 Volt zal deze geen stroom laten lopen door zijn collector. Hierdoor zal transistor Q2 ook geen stroom kunnen voeren en de schakeldraad van de toeter ook niet worden bekrachtigd. Wanneer T7 wel een basis stroom gaat voeren zal deze de basis stroom van Q2 verzorgen. Door de 32
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.12: Schema van transistorschakeling voor de toeter versterking in stroom van beide transistoren zal Q2 zeker in verzadiging treden, en de schakeldraad van de toeter dus een +12 Volt signaal aanbieden.
3.2.6
Aansturing omvormer
De gebruikte omvormer voorziet de aangebrachte verlichting van de juiste voedingspanning. Omdat deze omvormer veel vermogen vraagt (MAX 30A) is hier ook voor een relais oplossing gekozen. De werkelijke stroom die de omvormer vraagt licht rond de 6 Ampere. Om deze stromen te kunnen leveren is voor een extra grote accu gekozen. Verder zijn hier geen nieuwe aspecten in beeld gekomen om rekening mee te houden.
3.2.7
Accu meter
De accuspanningsmeter bestaat uit een acht bits AD-converter (type adc0804lcn) en een PIC(type 16f628) en een lcd-scherm(4x20). De AD-converter: De test opstelling van de AD-converter wordt in bijlage D.2 weergeven. De AD-converter werkt op 5 Volt DC gelijkspanning en is enkelvoudig gevoed, de voeding mag ongeveer tien procent fluctueren met een maximale spanning van 6.5 Volt DC bij 25 C. Bij de voedingsspanning staat een condensator geschakeld naar de 0 Volt. Dit is ter voorkoming dat er rimpels op de ingangsspanning ontstaan. De AD-converter wekt het best tussen 0C TOT 70C, bij een afwijkende omgevingstemperatuur zal de AD-converter onnauwkeurig of niet werken. De AD-converter staat in deze opstelling in free-running mode, dit betekent dat de AD-converter automatisch sampeld en klokt. Dit wordt volbracht door de CLKR te verbinden met de CLKIN met daartussen een weerstand van 10k en 33
IPROJ1 - Project semester 6, blok 1
18 april 2007
een condensator van 150pF naar de 0 Volt. De weerstand en de condensator zorgen voor een RC-tijd. Aan de hand van de volgende formule kan de klok frequentie worden uitgerekend: Bron: datasheet adc0804lcn De uitkomst van rekensom is hierbij 606 kHz, dit komt aardig in de buurt van de typical waarde, dat 640 kHz is. In de situatie waarbij de AD-converter wordt gebruikt is de afwijking acceptabel, omdat er niet zo snel de batterijspanning hoeft te worden weergeven. De globale werking van de AD-converter gaat als volgt: De CS en de WR zijn laag, dan is de AD-converter in reset modus, de INTR wordt hierbij hoog gemaakt. Wanneer de WR hoog wordt, dan begint de conversie. Bij elk bit wordt een klokpuls gegenereerd, in totaal komt bij elke conversie acht pulsen mee. Wanneer de conversie klaar is, dan wordt de INTR laag gemaakt. Dit gebeurt door de CS laag te maken en te verbinden met de RD. De output van de AD-converter wordt in de test opstelling gesimuleerd met LEDs. Aan de hand van de LEDs, beginnend bij DB0-DB7 met DB0-DB3 de LSB-bits, kan men het Voltage bepalen met de volgende formule: : (Binaire waarde van de LED 0 s 256 ) * Vin+ De LEDs, een tot zeven, kan worden gezien als een binair getal 11111111, wanneer alle LEDs aan zijn. Dit correspondeert met het decimaal getal 256 (28 ). De momentane Voltage kan berekend worden, door de binaire waarde van de LEDs die op dat moment aan staan in te vullen in de formule. Bij deze opstelling is Vin+ even hoog als de voedingsspanning. De wisselende spanning dat op de Vin+ staat, wordt gesimuleerd door een regelbare weerstand R10. De weerstand is gekozen op 250k, maar kan ook veel lager liggen. Voor de testopstelling is dit niet zo van belang. Voor een goede output mag de Vin+ maximaal 50mV hoger liggen dan de voedingsspanning. Voor de ingang VREF/2 is een spanningsdeler geplaatst die 2.5 Volt DC moet geven, dit is gedaan, omdat de VREF/2 wanneer aangesloten, altijd de helft van de Vin+ is. In het bijlage D.2 staat de gehele schakeling van de accu spanningsmeter afgebeeld. De twee toegevoegde elementen zijn de PIC16f628 en de LCD-scherm. De PIC heeft twee verschillende functies. De PIC zorgt voor het aansturen van de lcd-scherm, op dit scherm wordt de accuspanning aangegeven in gehele decimale getallen. De PIC werkt op een spanning van 3 tot 5 Volt DC, met een consumptie van kleiner dan 2mA op 4MHz. De PIC zorgt ook voor de extra inputs, omdat de Armtarget onvoldoende input over heeft voor deze toepassing. De poorten RA0-RA7 wordt gebruikt voor de output van de AD-converter, dit is gedaan omdat poort RA5 alleen als input mag worden gebruikt. De poorten RB0-RB6 zijn voor de aansturing van de LCD-scherm. Poort RB7 is teruggekoppeld naar de AD-converter in poort WR. Van poort RB7 krijgt de AD-converter een puls om een conversie te be¨eindigen en het vervolgens te tonen op het LCD-scherm. Aan ingang WR van de AD-converter staat een weerstand geschakeld naar de 0V. Dit is een pulldown weerstand dat ervoor zorgt dat WR ook daadwerkelijk nul Volt DC is wanneer niks mee wordt gedaan. Deze weerstand is klein gehouden omdat er bij een hoge waarde geen stroom meer kan lopen. De Vin+ bij de AD-converter wordt hier niet meer gesimuleerd met een variabele weerstand, maar met een spanningsdeler. De spanningsdeler moet van 15V DC, 5V DC maken.
34
IPROJ1 - Project semester 6, blok 1
18 april 2007
Het lcd-scherm wordt gevoed met 5 Volt DC aan vdd1. De variabele weerstand wordt gekoppeld aan vdd2 en ingang IN naar de 0 Volt. De weerstand zorgt voor het contrast van het LCD-scherm. De LCD-scherm heeft slechts vier datalijnen, terwijl de PIC acht bits aan data doorstuurt. Dit wordt opgelost door de PIC twee keer te laten uitsturen.
3.2.8
EMC
Bij de gebruikte schakelingen worden er vrijwel geen hoog frequente signalen uitgestuurd. Dus naar alle waarschijnlijkheid zullen we geen emc uitstuur regels overschrijden.De door ons maximale uitgestuurde spanning varieert van 3.3 Volt DC tot 12.5 Volt DC. Tevens zijn bijna alle gebruikte transistoren gesperd of in verzadiging gestuurd waardoor zij stukken langzamer worden en vele malen minder gevoelig zijn voor signalen van buiten af. Om de voeding stabiel te houden wanneer er grote stromen geschakeld worden zijn er bij de verbruikers die een stabiele voeding nodig hebben ontkoppel condensatoren geplaatst. Verder is er geen rekening gehouden met EMC bij ons ontwerp. 35
IPROJ1 - Project semester 6, blok 1
3.3
18 april 2007
Software
De code voor het project is geschreven in de programmeertaal C. De code bevat in grote lijnen de volgende functionaliteit: • Er worden netwerkcommando’s ontvangen voor aansturing van de robot. • Er wordt een motor-board aangestuurd om de robot te besturen. • Er wordt data van sensoren verwerkt en actuatoren en verlichting aangestuurd, ten behoeve voor het docken en disarmen van bommen. De functionaliteit voor de netwerkverbinding is reeds geimplementeerd door een projectgroep van een voorgaand project aan de Hogeschool Utrecht. Deze code bevat ook drivers voor aansturing van de hardware van het ARM-board. Tevens is beknopte voorbeeldcode geleverd voor aansturing van het motor-board. Een overzicht tussen de hardware en software componenten, en de verscheidene lagen die zijn aangebracht in de software is weergegeven in figuur 3.13.
36
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.13: Relaties tussen hardware en software componenten
37
IPROJ1 - Project semester 6, blok 1
3.3.1
18 april 2007
Programmeren
Compilen en debuggen Installatie Instructies om de compiler en debugger te installeren onder Microsoft Windows: • Pak ARM ip.zip uit • De dir ARM ip verplaatsen naar de dir driverspackage • Verplaats de driverspackage naar bijvoorbeeld c:\driverspackage • Download en installeer: (dit bevat toolchain, gcc, debugger) – http://www.yagarto.de/download/openocd/openocd-2007re131-setuprc02.exe – http://www.yagarto.de/download/yagarto/yagarto-bu-2.17 gcc-4.1.1c-c++ nl-1.14.0 gi-6.5.5.exe • Tools.zip uit de bijgeleverde ARM ip.zip uitpakken in Program Files\yagarto\bin\ • openocd-pp.exe hernoemen naar openocd.exe in Program Files\openocd2007re131\bin\ • make.exe kopieren van Program Files\openocd-2007re131\utils\bin\ naar c:\driverpackage\ • Voer install giveio.bat uit in Program filesvopenocd-2007re131\drivers\parport Compileren Door in de command prompt make te typen in de dir driverspackage wordt de code gecompileerd. Dit commando heeft hetzelfde effect als het commando make all typen. Het is aanbevolen om voor de eerste maal compileren of als er een header bestand is gewijzigd, het commando make clean uit te voeren. Dit commando verwijderd alle object bestanden, waardoor alle code bij het volgende make commando overnieuw gecompileerd wordt. Debuggen Debuggen via JTAG kan met het commando make debug. Zorg ervoor dat de parallelle kabel verbonden zit. Zie verderop in dit document voor de jumper standen op het ARM-board. Zorg dat in de makefile de volgende optie is ingesteld: MEM
= RUN_FROM_RAM
Nadat het commando make debug is uitgevoerd zal Insight opstarten. Dit programma is een grafische user interface voor de GNU debugger. Met de debugger kan een programma instructie voor instructie worden doorlopen. Er kunnen breakpoints worden ingesteld, geheugenadressen en regiisters kunnen worden uitgelezen.en de code kan zowel als C-code en assembly instructies worden bekeken en doorlopen. 38
IPROJ1 - Project semester 6, blok 1
18 april 2007
ROM programmeren Om de code in het ROM op te slaan, dient de volgende optie in de makefile ingesteld te worden: MEM = RUN_FROM_ROM Er wordt vervolgens een bestand met een .hex -extensie aangemaakt. Dit bestand kan met de PHILIPS ARM flash util worden geprogrammeerd. De correcte jumper standen staan verderop in dit verslag vermeld.
Instellingen ARM-board voor programmeren In tabel 3.1 staan de standen voor de jumper van het ARM-board vermeld voor het programeren en uitvoeren van programma’s. Via JTAG naar ROM flashen is onbetrouwbaar. Hiervoor is altijd een RS232 verbinding gebruikt. Methode Via RS232 naar ROM Via JTAG naar RAM Programma in ROM uitvoeren
Stand jumper 1 2 don’t care 1
Stand jumper 2 2 1 don’t care
Tabel 3.1: Jumper standen voor programmeren ARM-board
3.3.2
IP-interface en globaal software ontwerp
Er wordt gebruik gemaakt van bestaande code voor de aansturing van de netwerkkaart. De software bevat o.a. de volgende functionaliteit: • Drivers voor de netwerkkaart, inclusief ISA en SPI. • TCP/IP stack • Telnet • Drivers voor de aansturing van de hardware van ARM-board v2.3
Aanpassingen IP-interface De netwerkcode is volledig functionerend. Enkele aanpassingen zijn echter gemaakt: • Het ARM-IP systeem draait nu op interrupt basis i.p.v. event-driven. • De telnet functionaliteit is aangepast voor het ontvangen van commando’s voor aansturing van de robot. 39
IPROJ1 - Project semester 6, blok 1
18 april 2007
Het ARM-IP systeem is event-driven. Dit houdt in dat het standaard een oneindige loop uitvoert waarbij continu wordt gekeken of er nieuwe taken zijn om uit te voeren. Deze taken omvatten het uitlezen van de netwerkkaart en timers. De oneindige lus is herschreven naar een eindige lus, en wordt regelmatig met een interrupt aangeroepen. Dit gaf de mogelijkheid om i.p.v. de oneindige lus van het ARM-IP systeem de robotcode in een oneindige lus uit te voeren. Een alternatief zou zijn om de robotcode event driven te maken, en enkele functies eventueel met een interrupt aan te roepen. Het was echter relatief eenvoudig om de netwerkcode op interrupt basis te laten werken. De telnet functionaliteit is gestript van de oorspronkelijke functionaliteit, deze zou storen met het protocol dat gebruikt wordt om commando’s te versturen over het netwerk. Bij elk ontvangen karakter wordt nu een functie aangeroepen die de netwerkcommando’s voor de aansturing van de robot afhandeld. De netwerkfunctionaliteit van de telnet applicatie bevat alle functionaliteit die vereist is. Er is dus geen noodzaak om een eigen IP-applicatie te schrijven. Ontwerp code De globale opbouw van de code is weergegeven als flowchart in figuur 3.14. • De hardware initialisatie is weergegeven als flowchart in figuur 3.15. • De initialisatie van de robotcode is weergegeven als flowchart in figuur 3.16. • De opbouw van de robot lus is weergegeven als flowchart in figuur 3.17. De robot lus controleerd of er een nieuw commando is binnengekomen en of een toets is ingedrukt. De controle of een nieuw commando is binnengekomen bestaat in feite uit het controleren van een variabele. Het commando wordt in de variabele gezet wanneer een commando op de netwerkkaart wordt ontvangen. Er wordt met een interrupt regelmatig gecontroleerd of er een nieuw netwerkcommando is ontvangen. Het inlezen van de toetsen kan worden uitgeschakeld met een define. Het uitlezen van het toetsenbord staat standaard gedeactiveerd. Deze keuze is gemaakt omdat het uitlezen van de toetsen de netwerk-interface reset. Dit levert een korte vertraging op. De oorzaak van dit probleem ligt bij gedeelde I/O-lijnen tussen de toetsen en netwerkkaart..
40
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.14: Flowchart van de globale opbouw van de code
41
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.15: Flowchart van de initialisatie van de hardware
42
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.16: Flowchart van de initialisatie van de robot
43
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.17: Flowchart van de opbouw van de robot lus
44
IPROJ1 - Project semester 6, blok 1
18 april 2007
Afhandeling netwerkcommando’s Er is afgesproken dat alle telnet commando’s per karakter worden verstuurd. De telnet applicatie bevat een functie die bij elk ontvangen karakter wordt aangeroepen: static void getchar(struct telnetd_state *s, u8_t c) Oorspronkelijk schreef deze functie de ontvangen karacter in een buffer. Dit buffer werd vervolgens gecontroleerd om te kijken of er een commando in zat. Al deze functionaliteit is eruit gehaald. Het enige wat deze functie nu doet is de volgende functie aanroepen: void robot_command_received(unsigned char c) Deze functie handeld alle binnenkomende netwerkcommando’s af. De opbouw van deze functie is weergegeven als flowchart in figuur 3.18.
Figuur 3.18: Flowchart van de functie waarin netwerkcommando’s worden afgehandeld
Informatie versturen Er zijn functies geschreven voor het weergeven van informatie voor een aantal hardware componenten op het ARM-board: • Buzzer 45
IPROJ1 - Project semester 6, blok 1
18 april 2007
• LED’s • LCD-display • UART • Telnet Buzzer De buzzer functie wordt gebruikt om piepjes te genereren. Aansturing van de functie gebeurd met code die bijgeleverd is met de ARM-IP software. De volgende functie wordt gebruikt voor het aansturen van de buzzer: void robot_send_buzzer(unsigned short puls,unsigned short time) { buzzer_put(PLL_MUL * puls, PLL_MUL * time); } Hierbij kan met het eerste argument de frequentie worden bepaald, en met het tweede argument de tijd hoe lang die piep duurt. LED’s De LED’s delen I/O-poorten met de netwerkkaart. Daarom wordt tijdens het aansturen van de LED’s de netwerkkaart uitgeschakeld, en de LED’s overnieuw geinitialiseerd. Het argument is de waarde die binair zal worden weergegeven met de LED’s. De opbouw van de functie is als flowchart weergegeven in figuur 3.19 void robot_send_leds(const unsigned short state) { __disable_nic led_init(); led_put(state); __enable_nic }
46
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.19: Flowchart van het aansturen van de LED’s
47
IPROJ1 - Project semester 6, blok 1
18 april 2007
LCD-display Het LCD display en de netwerkkaart delen I/O-pinnen. Daarom wordt tijdens het aansturen van het LCD-display de netwerkkaart uitgeschakeld, en het LCD-display overnieuw geinitialiseerd. Voor de netwerkinterrupt weer wordt ingeschakeld wordt de netwerkkaart weer werkend gezet. Het argument is een ASCII string dat op het display verschijnt. void robot_send_lcd(const char *str) { __disable_nic lcd_init(); lcd_cursor_off(); lcd_put(str); isa_init(DEVICE); __enable_nic }
Figuur 3.20: Flowchart van het aansturen van het LCD-display
48
IPROJ1 - Project semester 6, blok 1
18 april 2007
UART De UART is een betrouwbare manier om te debuggen. De UART wordt met interrupts aangestuurd. Het commando om naar de UART uit te sturen verschilt niet van het commando dat gebruikt wordt door de ARM-ip software. Voor de overzichtelijkheid wordt wel een define gebruikt: #define robot_send_rs232 print void print(char *fmt, ...); Telnet Deze functie kan een verscheidenheid aan soorten variabelen versturen, waaronder strings, characters en integers. Een probleem met het versturen van data over telnet is dat eerst de sessie moet worden achterhaald. Omdat deze functie slechts gebruikt wordt om tijdens een netwerk-interrupt een acknowledge terug te sturen indien dit wordt gevraagd, kan de pointer van de huidige sessie gebruikt worden. De pointer wordt gekopierd, waarna een bestaande telnet functie wordt aangeroepen met de pointer en te versturen data als argumenten. void robot_send_telnet(char *str1, char *str2) { struct telnetd_state *s; s = (struct telnetd_state *)uip_conn->appstate; telnetd_output(s, str1, str2); } Netwerkkaart interrupts uitschakelen Het kan soms nodig zijn om de netwerkkaart tijdelijk te deactiveren. In de robotcode wordt dit gedaan wanneer code niet onderbroken mag worden, of hardware I/O-lijnen deelt met de netwerkkaart. Om de netwerkkaart interrupt te deactiveren kan de volgende code worden gebruikt: __disable_nic
Om de netwerkaart interrupt weer in te schakelen kan de volgende code worden gebruikt: __enable_nic
Deze code fragmenten refereren naar de volgende defines: #define __disable_nic vic_disablechannel(VIC_CH_TIMER0); #define __enable_nic vic_enablechannel(VIC_CH_TIMER0); De interrupt van de netwerkkaart zit verbonden aan timer 0. Bovenstaande code schakeld het kanaal van timer 0 aan of uit in de VIC1 . 1 Vectored
Interrupt Controller
49
IPROJ1 - Project semester 6, blok 1
18 april 2007
Netwerk-interrupt timing Interrupts per seconde De ARM-IP software draaide oorspronkelijk in een oneindige lus. Deze code is aangepast om op interrupt basis te werken. De volgende code roept een interrupt handler2 aan waarmee de aangepast ARM-ip routine wordt aangeroepen: /* ipstack.c */ #define NIC_INT_SEC 50 timer0_init((PLL_MUL * FOSC)/(NIC_INT_SEC), 0, ip_intHandler); Met de define NIC INT SEC kan worden ingesteld hoevaak per seconde de functie ip intHandler wordt aangeroepen, onafhankelijk van de PLL-multiplier en de kloksnelheid van de oscilator. Het eerste argument van de functie is om de hoeveel klokinstructies de timer een interrupt genereerd. Bij het instellen van NIC INT SEC dient het volgende in overweging te worden genomen: • Het aantal interrupts per seconde is niet gelijk aan het aantal data-pakketten per seconde dat kan worden ontvangen. In ´e´en interrupt kunnen meerdere data-pakketten worden afgehandeld. Dit komt doordat de netwerkkaart een buffer bevat waar meerdere data-pakketten inpassen. Wanneer de functie ip intHandler wordt aangeroepen worden alle data-pakketten in het buffer uitgelezen. • Het aantal interrupts per seconde is gelijk aan het aantal data-pakketten dat per seconde wordt verstuurd. • De processortijd die een netwerk-interrupt gebruikt, zonder dat er data wordt verzonden of ontvangen. Dit wordt in de volgende paragraaf nader gespecificeerd.
Processortijd netwerk-interrupts Er is onderzocht hoeveel processortijd een netwerk-interrupt gebruikt. De volgende scenarios zijn interessant om te onderzoeken: • Er wordt geen data ontvangen of verstuurd. • Er wordt 1 karakter ontvangen per interrupt. • Er worden meerdere karakters ontvangen per interrupt.
Onderzoeksmethode 2 Interrupt
handler: Een functie die wordt aangeroepen nadat een interrupt optreedt.
50
IPROJ1 - Project semester 6, blok 1
18 april 2007
• Timer 0 roept elke seconde de functie int ipHandler aan. Deze functie roept de functie aan waarin de netwerkcode wordt afgehandeld. Vervolgens stelt deze functie in dat weer een nieuw interrupt afgehandeld kan worden. • Aan het begin en eind van deze functie wordt een I/O-pin respectievelijk hoog en laag gemaakt. Deze pin is verbonden aan een oscilloscope. Met de oscillocope wordt gemeten hoe lang de I/O-pin hoog blijft. • Met een telnet sessie worden karakters verstuurd. • Meerdere data-pakketten per seconde wordt getest door een toets op het toetsenbord ingedrukt te houden. Het toetsenbord staat ingesteld om 30 karakters per seconde te versturen. • Elke test wordt 10 keer herhaald. De laagste waarde wordt genoteerd. • De tijd die het kost om een interrupt af te handelen is niet meegenomen. Gevonden meetwaarden De gevonden meetwaarden staan vermeld in tabel 3.2 Aantal karakters per interrupt 0 1 30
Interrupt tijd 405 us + 1 us 3,86 ms 5,68 ms
Tabel 3.2: Meetwaarden netwerk-interrupts
Conclusie Zonder dat er data verstuurd wordt duurt de interrupt maximaal 406 us. Dit betekend dat bij een instelling van 50 interrupts per seconde, er 50 ∗ 406us = 20, 3ms processortijd per seconde wordt verbruikt. Dit is 2% van de processortijd. De processortijd om ´e´en karakter uit te lezen is 3,86ms. De processortijd per extra karakter kan met de meetwaardes worden benaderd, als er wordt uitgegaan van een lineare toename in tijd: Extra tijd per karakter =
5, 68 − 3, 86 = 63us 30 − 1
De totale processortijd per interrupt kan dus met de volgende formule worden uitgerekend: Tijd per netwerk-interrupt(us) = 406 + karakters per seconde ∗ 63
(3.1)
Voorwaarde: karakters per seconde > 0. Als 30 karakters per seconde wordt beschouwd als het maximale aantal karakters per seconde dat kan worden ontvangen, dat is de maximale processorbelang voor afhandeling van netwerk-interrupts: 51
IPROJ1 - Project semester 6, blok 1
18 april 2007
Karakters per seconde ∗3, 86 ms +( interrupts per seconde − karakters per seconde )∗0, 41 = (30 karakters ∗ 3, 86 ms ) + (50 − 30) ∗ 0, 41 ms = 124 ms De maximale processorbelasting voor de afhandeling van interrupts bij een instelling van 50 interrupts per seconde is dus 124 ms. Dit komt neer op ongeveer 13% van de processortijd. Bestands-indeling De hieronder vermelde bestanden zijn belang voor essentiele instellingen, of bevatten code die specifiek van belang zijn voor dit project. • project.h – Algemene instellingen, zoals EEPROM uitschakelen. • main.c: – Initialisatie – Bevat main lus ∗ Roept de usercode aan. • user.c – Initialisatie van de netwerkkaart. – Bedoeld voor code van de gebruiker ∗ Roept de robotlus aan • robot.c – Bevat de code voor aansturing van de robot – Bevat de uiteindelijke main lus • ARM ip/ipstack.c – Bevat de code voor afhandeling van netwerk • ARM ip/uip/uipopt.h – Instellen IP-adres, submask, gateway en MAC-adres • ARM ip/apps/telnetd/telnetd.c – Bevat de code voor afhandeling telnet
52
IPROJ1 - Project semester 6, blok 1
3.3.3
18 april 2007
Docking en disarm
Docking-procedure De docking-procedure code is weergegeven als flowchart in figuur 3.21. Voor de dockingsprocedure wordt naast de I2 C lijnen ook gebruik gemaakt van 2 extra I/O-lijnen. Voor deze I/O-lijnen worden P31 en P30 van het ARM-board gebruikt. Hierbij zijn P30 en P31 ingesteld als input. In het IODIR register wordt ingesteld welke pinnen input en welke output zijn. Bitten 30 en 31 worden gecleared om ingesteld te worden als input. Het is mogelijk de docking procedure te onderbreken. De functie die de docking procedure afhandeld voert slechts enkele instructies uit waarna de functie wordt beeindigt. De functie dient continu aangeroepen te worden. De docking procedure wordt geannuleerd door deze functie niet meer aan te roepen. Wanneer de docking niet onderbroken wordt, wordt er gekeken naar de stand van de knoppen die zich op P30 en P31 bevinden om te bepalen welke actie utigevoerd dient te worden. Wanneer slechts een van de standen is ingedrukt betekend dit dat een van de armen volledig gesloten is. De robot zal vervolgens bijsturen zodat de bom goed vastgezet kan worden.bot op beweegt. Wanneer alleen P30 hoog is zal de robot naar links bij sturen, als P31 hoog is zal de robot naar recht bijsturen. Wanneer beide schakelaars niet zijn ingedrukt zal de robot naar voren rijden. Wanneer beide schakelaars wel zijn ingedrukt zal de robot geleidelijk stoppen en de disarm functie aangeroepen.
53
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.21: Flowchart van de docking-procedure code
54
IPROJ1 - Project semester 6, blok 1
18 april 2007
Disarm De disarm code is weergegeven als flowchart in figuur 3.22. Voor de disarm functie worden 8 IO lijnen gebruikt. Op de ARM worden daar P29, P22, P23, P26, P27 en P16 voor gebruikt. Van deze lijnen is alleen P27 input. Dit houdt in dat in het IODIR register alleen bit 27 gecleared dient te zijn, de andere bitjes worden op 1 ingesteldt. Voor de aansturing van de armen worden P23, P22, P16 en P29 gebruikt. Deze zijn als volgt ingedeeld: • -P23 stuurt de rechter arm omhoog • -P22 stuurt de rechter arm omlaag • -P29 stuurt de linker arm omhoog • -P16 stuurt de linker arm omlaag Voor het uitlezen van de IR-detectie worden 2 I/O-lijnen gebruikt, namelijk P27 en P26. P27 wordt gebruikt voor het detecteren van IR-LED en P26 fungeert als reset voor de SR-latch. Zodra begonnen wordt aan de disarm functie worden commando’s van buitenaf. De verlichting wordt uitgezet indien deze aanstond, Vervolgens worden beide armer omhoog gezet gevolgd door een reset voor de SR-latch. Daarna wordt er gekeken of de IR-LED nog aan is. Als de IR-LED uit is, dan wordt de verlichting weer aangezet indien deze reeds aanstond voordat er met de disarm begonnen werd. Daarna gaat de robot toeteren en kunnen er weer commando’s worden ontvangen Als de IR-LED nog aan is, zal ´e´en arm van stand wisselen. Daarna zal er weer een reset komen voor de SR-latch en wordt weer getest wat de toestand van de IR-LED is. Als na vijf maal testen de IR-LED nog steeds aan staat, dan gaat de verlichting weer aan indien deze voor de disarm functie aanstond, en kan de robot weer commando’s ontvangen. Indien de disarmprocedure is mislukt, kan deze overnieuw worden geactiveerd voor een nieuwe poging de bom te ontmantellen.
55
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.22: Flowchart van de disarm code 56
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.23: Numpadindeling op een toetsenbord
Figuur 3.24: Richtingen die overeenkomen met de numpad toetsenindeling. Motoraansturing Volgens ons eisenblad moet er een smoothcontrol geimplementeerd worden bij de motoraansturing. Dit houd in dat er geleidelijk van richting veranderd moet worden. Om dit voor elkaar te krijgen houden we per motor een signed interger array bij. Aan de hand van het teken kan afgeleid worden of de motor voor of achteruit moet draaien. De motoraansturing is in 2 stukken te verdelen. Als eerste het gedeelte dat evalueert welk commando er via de netwerkinterface binnen is gekomen. Vervolgens word de functie aangeroepen die waarden in de array plaatst die corresponderen met die richting. De richtingen komen overeen met de 9 numpadtoetsen zoals te zien op figuur 3.23 Komt het cijfer acht binnen dan moet er vooruit gereden worden en het cijfer een komt overeen met achteruit. Het tweede gedeelte dat moet worden uitgevoerd is het berekenen van de richting en snelheid waarmee de motoren aangestuurd moeten worden. Dit word gedaan door middel van de iDrive functie en deze is te vinden in bijlage B.2. Als eerste berekend deze functie de gemiddelde waarde van beiden array’s. Vervolgens word gekeken of de gemiddelde waarde negatief is of positief. Als deze negatief is moet de motorrichting op achteruit ingesteld worden. Als laatste word de motor aangezet met de gemiddelde snelheid van de array. Was dit een negatief 57
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.25: Werking van de iDrive() functie
Figuur 3.26: Flowchart van de motorcode
getal dan zal deze eerst geinverteerd worden door een vermenigvuldiging met -1. Een overzicht van de iDrive functie is te zien op figuur 3.25 en de flowchart van de motoraansturing is te zien op figuur 3.26. Er word gebruik gemaakt van een timer die op gedefineerde intervallen kijkt wat de laatste waarde is die via de netwerkinterface binnenkwam. Vervolgens worden de corresponderende functie aangeroepen die de juiste waarden aan beide array’s toegevoegd. Deze kan ook meerdere malen uitgevoerd worden. Hierdoor zal er bijvoorbeeld sneller gedraaid worden. Daarna worden de motoren aangestuurd. De grootte van de array’s zijn te snel te veranderen door gebruik te maken van definities. Ook de snelheid van de timer is door middel van een definitie aan te passen. Hiermee kan effectief de snelheid en nauwkeurigheid waarmee de smoothcontrol werkt aangepast worden. De timerfunctie is te vinden in bijlage B.1 In figuur 3.28 is de werking van het smoothcontrol filter beter te zien. De beginsituatie is stilstand. Daarna word 6 maal de functie iForward() aangeroepen. Na iedere keer word de gemiddelde snelheid berekend. Er is dus te zien dat de snelheid langzaam word opgevoerd naar de maximale waarde. Voor elke richting hebben we verschillende waarden gekozen die aan beide array’s 58
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.27: Globale werking van smoothcontrol
59
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.28: Op snelheid komen van de robot vanuit stilstand.
60
IPROJ1 - Project semester 6, blok 1
18 april 2007
toegevoegd worden. Deze zijn allemaal gerelateerd aan vooraf gedefineerde snelheden voor de linker en rechter motor. De functie iForward() zal bijvoorbeeld voor de linker en rechter motor +80 aan de array’s toevoegen terwijl iBackward -80 toevoegd. Door voor de linker en rechter motor aparte definities te kiezen kunnen we eventuele afwijkingen wegwerken door de maximale snelheid van een van de motoren net iets hoger te kiezen.
3.4 3.4.1
Software tools Revision Control
Waarom Revision Control gebruiken Hiermee kunnen verschillende versies van eenzelfde tekstbestand bijgehouden worden. Het wordt het meest toegepast in bedrijfstakken die zich met softwareontwikkeling bezighouden. Er zijn verschillende argumenten om deze software te gebruiken bij de ontwikkeling van programma’s. In het geval van revision control3 software die uitgaat van een server-client model is er altijd een centraal punt waar de source-code opgeslagen word. Hier is altijd de laatste versie te vinden. Daarnaast is het mogelijk om verschillende revisies van een tekstbestand met elkaar te vergelijken. Hierdoor kunnen ontwikkelaars snel zien welke delen zijn veranderd sinds de laatste keer dat er aan het document gewerkt is. Er kan met meerdere ontwikkelaars aan hetzelfde bestand gewerkt worden. Op het moment dat de ontwikkelaar zijn aangebrachte veranderingen door wil voeren zal deze vergeleken worden met de centraal opgeslagen versie. In het geval dat er iemand anders tussendoor bewerkingen heeft aangebracht zal gekeken worden of de veranderingen elkaar overlappen, deze situatie heet een conflict. Is dit het geval dan moeten de ontwikkelaars in overleg met elkaar beslissen welke veranderingen uiteindelijk doorgevoerd worden. Op het moment dat de veranderingen elkaar niet overlappen zal men niet merken dat er met meerdere personen tegelijk aan het bestand word gewerkt. Deze techniek heet Version Merging. Als men niet wil dat er met meerdere ontwikkelaars tegelijk aan hetzelfde bestand word gewerkt kan er gebruik gemaakt worden van File Locking. Deze techniek blokkeert het bestand op het moment dat er iemand aan werkt. Dit voorkomt dat er tegelijkertijd aan eenzelfde stuk code gewerkt wordt. Het nadeel is dat op het moment dat een file te lang “locked“ is naar de zin van andere ontwikkelaars, ze manieren gaan zoeken om het systeem te omzeilen. Als dat gebeurdt kan dat tot serieuze problemen leiden. Dit is dan ook niet een werkmethode die de voorkeur heeft. 3 Ook bekend als “Version Control“, ”Source Control” of “(Source) Code Management (SCM)“
61
IPROJ1 - Project semester 6, blok 1
18 april 2007
Voorbeelden van Revision Control software Hieronder staan verschillende voorbeelden van de meest gebruikte revision control software en voor welke besturingssystemen deze beschikbaar zijn. Subversion is een van de bekende open-source revision control pakketten. Het is ontworpen als opvolger van het alom bekende CVS en geschikt voor een groot scala aan besturingssystemen, waaronder Windows, Linux, Solaris en Mac OS X en derivaten. Er zijn geen kosten verbonden aan het gebruik van dit pakket en is voor de onderstaande platformen beschikbaar: • Windows • Linux • Mac OS X Dit is ook het pakket dat we tijdens het project hebben gebruikt en daarom word dit pakket hierna uitgebreider besproken. CVS betekend Concurrent Versions System en is een zeer populair versiebeheersysteem in de open-source wereld. Het maakt gebruik van een serverclient architectuur waarbij de server als centrale opslag dient en elke client een kopie lokaal opgeslagen hebben. Subversion is ontworpen als opvolger voor CVS en probeert de tekortkomingen van dit pakket aan te pakken. Er zijn geen kosten verbonden aan het gebruik van dit pakket en is voor de onderstaande platformen beschikbaar: • Windows • Linux • Mac OS X Visual Source Save is een programma ontwikkeld door Microsoft om samen te werken met Visual Studio. De voordelen van dit programma zijn dat het relatief makkelijk te gebruiken is. Verschillende ontwikkelaars zijn echter kritisch over dit programma omdat dat volgens hen traag werkt binnen grotere projecten. Verder is het mogelijk het programma vastloopt tijdens het doorvoeren van veranderingen. Als dit gebeurt kan de database achter het programma corrupt raken waardoor werk verloren gaat. Visual Source Save 2005 zou deze problemen aan moeten pakken. Desondanks adviseert Microsoft grotere ontwikkelteams om over te stappen op hun nieuwe vlaggenschip genaamd ”Team Foundation Server”. Visual Source Save is alleen beschikbaar voor het Windows besturingssysteem. Team Foundation Server is ontwikkeld door Microsoft als Professioneel pakket in gebruik met de ontwikkelomgeving Visual Studio en is alleen beschikbaar voor het Windows besturingssysteem. De aanschafkosten zijn op moment van schrijven ongeveer 2800 euro. Het is dan ook gericht op de grotere bedrijven waarbij de kosten van een licentie minder zwaar vallen. Subversion Wat is Subversion 62
IPROJ1 - Project semester 6, blok 1
18 april 2007
Waarom gebruik maken van Subversion Installatie van Subversion onder Linux Eerst moet Subversion geinstalleerd worden.4 Installatie kan met bereiken door het volgende commando in de console in te typen: sudo aptitude install subversion Vervolgens moet men ergens op het bestandsysteem een zogenaamde repository maken. Eerst navigeert men naar de map waar de repository opgeslagen moet worden. Het is handig om alle repositorys bij elkaar op te slaan. Hierdoor zijn ze makkelijk terug te vinden en het is handig voor de configuratie van Trac.5 In mijn geval heb ik besloten om de repositorys in /var/svn op te slaan. Allereerst maken we deze map aan en vervolgens cree¨eren we daarin een repository genaamd “iproj1”. sudo mkdir /var/svn cd /var/svn sudo svnadmin create iproj1 sudo chown -R root:www-data iproj1 sudo chmod -R 777 iproj1 De map iproj1 zou het er nu als volgt uit moeten zien: drwxrwxrwx 2 root www-data 4096 2006-11-10 14:56 conf drwxrwxrwx 2 root www-data 4096 2006-11-10 14:56 dav drwxrwxrwx 5 root www-data 4096 2007-01-30 14:59 db -rwxrwxrwx 1 root www-data 2 2006-11-10 14:56 format drwxrwxrwx 2 root www-data 4096 2006-11-10 14:56 hooks drwxrwxrwx 2 root www-data 4096 2006-11-10 14:56 locks -rwxrwxrwx 1 root www-data 229 2006-11-10 14:56 README.txt Dit is de database waar alle tekstbestanden later in opgeslagen en bijgehouden worden. De groepsrechten zijn op www-data gezet. Hierdoor heeft de webserver, genaamd Apache2, straks toegang tot de repository. De reden hiervoor is dat anders Trac later niet werkt. Nu moeten we ergens de opzet van de repository cree¨eren en deze importeren. In sectie 3.4.1 word uitgelegd hoe deze er ongeveer uit moet komen te zien. Het is niet verplicht om deze structuur aan te houden maar het is een goede gewoonte en kan op het moment dat het project groeit moeite besparen. Voor nu nemen we aan dat de repository uit de mappen “branch“, “tags“ en “trunk“ bestaat. We maken deze dus aan met behulp van de console: 4 De installatie methode gegeven is specifiek voor de Debian distributie van Linux en zijn derivaten zoals onder andere Ubuntu. 5 Trac is Wiki en bug tracking systeem voor software ontwikkeling dat ook gebruik maakt van Subversion.
63
IPROJ1 - Project semester 6, blok 1
18 april 2007
sudo mkdir -p /tmp/repos/branch sudo mkdir -p /tmp/repos/tags sudo mkdir -p /tmp/repos/trunk cd /tmp/repos/ svn import file:///var/svn/iproj1 \ --message "Dit is de eerste import" Vervolgens is de volgende tekst te zien als alles gelukt is. Adding trunk Adding branches Adding tags Nu moet de repository nog toegangkelijk worden gemaakt voor de buitenwereld. Voor het importeren van de eerste bestanden hebben wij, zoals te zien, gebruik gemaakt van het file protocol. Er zijn echter nog meer protocolen waarmee subversion benaderd kan worden. Enkele voorbeelden hiervan zijn: file, http, http+ssl. Aangezien het erg makkelijk is om met behulp van apache2 de repository via het http protocol aan de buitenwereld beschikbaar te maken hebben wij voor deze manier gekozen. Hiervoor moet Apache2 op de server geinstalleerd worden en geconfigureerd worden. Daarnaast zijn de gegevens voor het project niet van levensbelang dus hebben we ssl encrypty achterwege gelaten. Alleereerst moet apache geinstalleerd worden met ondersteuning voor subversion. Dit kan op de onderstaande manier6 : sudo aptitude install apache2 libapache2-svn Vervolgens moet Apache2 nog geconfigureerd worden om de repository via http aan te bieden. Dit kan door de volgende tekst toe te voegen aan het bestand /etc/apache2/sites-available/default.
DAV svn # any "/svn/foo" URL will map to a repository /var/svn/foo SVNParentPath /var/svn Hierna moet Apache herstart worden: sudo /etc/init.d/apache2 restart Nu is de repository als het goed is te bezoeken via www.domein.nl/svn/repositorynaam. Nu kan echter iedereen op het internet veranderingen aanbrengen in de repository en dat is niet de bedoeling. Er zal dus een vorm van authentificatie 6 De installatie methode gegeven is specifiek voor de Debian distributie van Linux en zijn derivaten zoals onder andere Ubuntu.
64
IPROJ1 - Project semester 6, blok 1
18 april 2007
toegepast moeten worden. Dit is te bereiken door gebruik te maken van de console applicatie htpasswd. htpasswd -cm /etc/svn-auth-file harry New password: ***** Re-type new password: ***** Adding password for user harry htpasswd -m /etc/svn-auth-file sally New password: ******* Re-type new password: ******* Adding password for user sally Hierna moet Apache2 nog verteld worden dat deze gebruik moet maken van authenticatie. Hiervoor passen we de eerder aangebrachte veranderingen in /etc/apache2/sites-available/default weer aan.
DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /etc/svn-auth-file Require valid-user Uiteraard moet Apache2 nu weer herstart worden op de via de al eerder genoemde methode. Houd er rekening mee dat de gebruikers nu toegang hebben tot alle repositorys die zich in de map /var/svn bevinden. Aangeraden word om svnbook.red-bean.com te bezoeken. Hier staat een uitgebreid boek met alles over de installatie en het beheer van Subversion. Dit boek is in html of pdf vorm te lezen.
Subversion repository structuur Aangezien we tijdens dit project gebruik hebben gemaakt van Subversion zal ik de structuur van de repository verduidelijken. Een typische Subversion repository structuur maakt gebruik van 3 mappen. Namelijk “branches“, “tags” en “trunk“. In de trunk bevindt zich altijd de laatste revisie van de broncode. Alle veranderingen worden dus ook in de trunk doorgevoerd. Op het moment dat je een stabiele versie van je programma uit wil brengen is het enige wat je moet doen de versie die zich op dat moment in de trunk bevind kopieeren naar de map ”tags”. Zolang iedere ontwikkelaar er zich aan houd dat er absoluut geen veranderingen worden aangebracht in de map tags zal je altijd een kopie hebben van hoe het programma op dat moment was. Hiermee kan je dus effectief bepaalde versies “bevriezen”. 65
IPROJ1 - Project semester 6, blok 1
18 april 2007
Een branch is een kopie van de trunk op een gegeven moment met daarin kleine veranderingen aangebracht. Stel je voor dat een bedrijf een document heeft geschreven. Bijvoorbeeld een handleiding. Op een dag vraagt een andere divisie binnen het bedrijf om dezelfde handleiding met daarin wat kleine veranderingen aangebracht. Op dat moment cree¨er je een branch door de inhoud van de trunk te kopie¨eren. Het concept houdt in dat branch onafhankelijk is van de trunk maar wel dezelfde geschiedenis deelt. Op het moment dat er in de trunk een typefout ontdekt word is het zeer waarschijnlijk dat deze in de branch ook bestaat.
Windows TortoiseSVN client Wat is TortoiseSVN TortoiseSVN is een subversion client voor Windows. Het programma intergreerd in de Windows shell en bied van hieruit toegang tot de functies van Subversion.
Waarom gebruik maken van TortoiseSVN TortoiseSVN biedt een gemakkelijke interface om samen te werken met een Subversion repository. Hierdoor hoeft de gebruiker geen CLI commando’s te kennen. Verder is het programma door zijn intergratie in de Windows shell erg makkelijk in gebruik. Installatie van TortoiseSVN TortoiseSVN kan van het internet7 gedownload worden. De installatie is simpel en stelt geen ingewikkelde vragen aan de gebruiker. Als dit klaar is moet de computer herstart worden.
Gebruik van TortoiseSVN Als men wil beginnen met Subversion te gebruiken binnen een project moet men alleereerst een paar basis handelingen onder de knie hebben. 1. Checkout maken van het project. 2. Bestanden toevoegen aan het project. 3. Veranderingen committen naar de server. Een checkout maken van een project wil zeggen dat je een kopie maakt van de bestanden op je eigen computer. Hierbij word echter ook informatie zoals het revisienummer gedownload. Een checkout maak je als volgt. Ga eerst naar de map waar je je project neer wil zetten. Klik vervolgens op de rechtmuisknop en selecteer de optie ”Checkout”. Dit is ook te zien op figuur 3.29. Daarna krijgen we een scherm voor ons waar we de url opgegeven worden waar de repository zich bevind. Dit scherm is te zien op figuur 3.30 Als de server is geconfigureerd volgens paragraaf 3.4.1 dan is www.domein.nl/svn/ repositorynaam de url die opgegeven dient te worden. Het is ook mogelijk om 7 http://tortoisesvn.net/downloads
66
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.29: Repository uitchecken.
een eerdere revisie van het project uit te checken door dit expliciet op te geven. De laatste revisie word altijd de HEAD revisie genoemd. Als nu op OK word geklikt worden de desbetreffende bestanden van de repository gedownload. Op figuur 3.31 is het scherm te zien dat dan volgt. Hier is te zien welke bestanden er zijn gedownload en wat de revisie is. Als er een foutmelding optreed zal dit ook in dit scherm te zien zijn. Als we nu in de verkenner kijken dan zien we een map met de bestanden uit de repository. Dit kunnen allerlei bestanden zijn. Ook plaatjes en Word documenten. Het voordeel van tekstbestanden is echter dat deze gelezen kunnen worden en bij elke revisie alleen de veranderingen opgeslagen worden. Op het moment dat subversion een binair bestand toegestuurd krijgt kan hij alleen maar kijken of dat deze anders is ten overstaande van de versie die hij al bezit. Is dit het geval dan zal hij het complete bestand opslaan. Hierdoor kan de repository grootte erg snel oplopen als men bijvoorbeeld 10 revisies van 15MB grootte word bestanden heeft. Merk op dat er een vinkje staat bij elk bestand in de map. Dit vinkje geeft aan dat het bestand niet veranderd is sinds de laatste checkout. Op het moment dat een bestand aangepast is zal deze voorzien worden van een rood uitroep teken. Zie figuur 3.32 voor een voorbeeld van een repository waarin 1 bestand is aangepast. Op het moment dat men tevreden is met de aanpassingen moeten deze gecommit worden. Dit houd in dat de veranderingen teruggeschreven worden worden in de repository. Dit gaat als volgt. Selecteer het bestand (Of de map waar de bestanden in staan), rechtsklik, en druk op commit. Voorbeeld is te zien op figuur 3.33. Daarna volgt een scherm waar men een log mee kan geven aan de commit. Het is handig om hier te vermelden wat er is aangepast in de bestanden en vooral waarom dit is gedaan. Dit is te zien op figuur 3.34. Met deze informatie zou het mogelijk moeten zijn om gebruik te maken van Subversion als Version 67
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.30: Repository url opgeven.
Figuur 3.31: Overzicht van de bestanden die opgehaald worden.
68
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.32: Aangepaste bestanden zijn te herkennen aan het rode uitroepteken.
Figuur 3.33: Commit 1 Control systeem. Trac Wat is Trac Waarom gebruik maken van Subversion Installatie van Trac Eerst moet Subversion geinstalleerd worden.8 Installatie kan met bereiken door het volgende commando in de console in te typen: 8 De installatie methode gegeven is specifiek voor de Debian distributie van Linux en zijn derivaten zoals onder andere Ubuntu.
69
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.34: Commit 2
70
IPROJ1 - Project semester 6, blok 1
18 april 2007
sudo apt-get install trac sudo mkdir /var/lib/trac sudo chown www-data:www-data /var/lib/trac
ServerAdmin webmaster@localhost ServerName trac.example.com DocumentRoot /usr/share/trac/cgi-bin/ Options Indexes FollowSymLinks MultiViews ExecCGI AllowOverride All Order allow,deny allow from all Alias /trac "/usr/share/trac/htdocs" SetEnv TRAC_ENV "/var/lib/trac" DirectoryIndex trac.cgi ErrorLog /var/log/apache2/error.trac.log CustomLog /var/log/apache2/access.trac.log combined # To use CGI scripts outside /cgi-bin/: # AddHandler cgi-script .cgi sudo a2dissite default sudo a2ensite trac sudo /etc/init.d/apache2 reload
AuthType Basic AuthName "Trac" AuthUserFile /etc/apache2/dav_svn.passwd Require valid-user sudo sudo sudo sudo sudo sudo
mkdir mkdir mkdir mkdir mkdir mkdir
/var/lib/svn /var/lib/svn/YourProjectNameHere /tmp/YourProjectNameHere /tmp/YourProjectNameHere/branches /tmp/YourProjectNameHere/tags /tmp/YourProjectNameHere/trunk 71
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.35: Wiki van webapplicatie Trac
sudo svnadmin create /var/lib/svn/YourProjectNameHere sudo svn import /tmp/YourProjectNameHere file:///var/lib/svn/YourProjectNameHere -m " sudo rm -rf /tmp/YourProjectNameHere sudo chown -R www-data /var/lib/svn/YourProjectNameHere sudo chown -R www-data /usr/share/trac sudo apache2 -k restart sudo mkdir /var/lib/trac sudo trac-admin /var/lib/trac/YourProjectNameHere initenv sudo chown -R www-data /var/lib/trac/YourProjectNameHere Als er zich problemen voordoen kan de offici ele site bezocht worden voor een oplossing. http://trac.edgewall.org/wiki/TracOnUbuntu.
3.4.2
LATEX
Wat is LATEX LATEX is een systeem om tekst vorm mee te geven. Het is in 1984 ontworpen door Leslie Lamport. Het word ook wel omschreven als WYMIWYG9 . Het doel van LATEX is om de schrijver zich de laten concentreren op de tekst en het 9 What
You Mean Is What You Get
72
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 3.36: Repository weergave van Trac
Figuur 3.37: Code weergave van Trac
73
IPROJ1 - Project semester 6, blok 1
18 april 2007
programma zich met de opmaak bezig te laten houden. Het houdt zich bezig met de paginaopmaak, positionering van plaatjes, tabellen en titeling. Hoe het er dan uiteindelijk uit komt te zien wordt door het systeem bepaald. Het voordeel hiervan is dat de layout uniform is. Daarnaast zijn niet alle mensen even bedreven om de boodschap die ze willen overbrengen goed leesbaar op te schrijven. Zo is onderzocht dat een goed leesbare regel gemiddeld 60 characters bevat. LATEX houdt hier van te voren rekening mee door aan de zijkant ruime marges te kiezen. Een ander groot voordeel is dat doordat men zich op de tekst concentreert en niet op de layout, men met een simpele tekstverwerk al toekan. Bij Windows zou bijvoorbeeld het kladblok al voldoen en bij Linux Vi.
74
IPROJ1 - Project semester 6, blok 1
18 april 2007
Platform onafhankelijk LATEX tekstverwerkers zijn voor vele verschillende platformen beschikbaar. Enkele platformen waarvoor een tekstverwerkers beschikbaar is zijn onder andere: • Windows (alle versies) 1. LyX 2. Texmaker 3. TeXnicCenter 4. Xemacs • Linux 1. Kile 2. LyX 3. Texmaker 4. Xemacs • Mac OS X 1. iTeXMac 2. LyX 3. Texmaker 4. TeXshop 5. Xemacs Zoals al eerder gezegd kan LATEX in ieder basaal tekstverwerkingsprogramma geschreven worden. Het is alleen nodig om de tekst uiteindelijk te compileren zodat er een document uitrolt. Dit maakt het mogelijk om met LATEX te werken op ieder besturingssysteem waar een compiler voor beschikbaar is. Aangezien de originele bestanden in de vorm van platte tekstdocumenten worden opgeslagen is het mogelijk om revision control toe te passen. Hierdoor wordt het mogelijk om wijzigingen bij te houden en ongedaan te maken en om met meerdere mensen tegelijk aan het document te werken. Dit kan voordeel opleveringen wanneer er met veel mensen op niet al te snelle computers gewerkt moet worden. Het uiteindelijke document kan dan op commando lokaal gecompileerd worden of automatisch door de server van het revision control systeem. De verslagen die hiermee geschreven worden zijn mooier en consistenter van opzet dan Word verslagen. Zeker in groeps- en projectverband kan dit schelen aangezien de opmaak door de computer bepaald word en niet door de persoon die de tekst geschreven heeft. Dit kan de eindverantwoordelijke van het document weer tijd schelen. 75
IPROJ1 - Project semester 6, blok 1
18 april 2007
Wiskundige en scheikundige formules Een van de grote speerpunten van LATEX is de zeer goede ondersteuning voor formules. Dit maakt dat het een zeer geliefd pakket is bij betastudenten. Vroeger kostte het ontzettend veel geld om documenten met wiskundige formulens netjes te laten opstellen. Vandaar dat wiskundige formules in een LATEX document binnen 2 dollartekens staan. 3 = 62 moet bijvoorbeeld als volgt getypt worden. $ 3 = \frac{6}{2} $ Dit was een vrij simpel voorbeeld en is geen duidelijke demonstratie. De volgende tekst getypt in LATEX zal in het uiteindelijke document de formule eronder opleveren. Uiteraard is ook hier alles achter een % teken commentaar. \[ % Dit is ook een manier om wiskundige formulens aan te geven. \pi = \sqrt{6\sum_{n=1}^{\infty}\frac{1}{n^2}} = \left(\int_{-\infty}^{+\infty}e^{-x^2}\,dx\right)^2 \] % Dit geeft het einde van de formule aan.
v u ∞ Z +∞ 2 u X 1 −x2 t = e π= 6 dx n2 −∞ n=1 Preamble Een LATEX bestand bestaat uit een zogenaamd preamble- en document gedeelte. In de preamble staat de informatie over het document. Welke verschillende pakketen er gebruikt moeten worden om de functionaliteit uit te breiden en hoe de kop- en voettekst eruit komt te zien bijvoorbeeld. Het principe van een verslag schrijven blijft hetzelfde bij het gebruik van andere verwerkers. Door dit te lezen zou men snel aan de slag moeten kunnen op Windows, Linux of Mac OS. In een standaard Tex document staat hetvolgende: \documentclass[a4paper,10pt]{report} % Title Page \title{} \author{}
\begin{document} \maketitle
76
IPROJ1 - Project semester 6, blok 1
18 april 2007
\begin{abstract} \end{abstract} \end{document} De documentclass zegt iets over het document. In dit geval dat het standaard lettertype 10 points groot is en het papierformaat A4 is. Verder word er in de opmaak mee rekening gehouden dat dit een report is. Vervolgens kan de titel en de auteur worden opgegegeven. Deze informatie word gebruikt door het commando maketitle. Dit commando maakt automatisch een voorpagina aan waarop de datum, titel en auteur vermeld is. Met abstract word de samenvatting bedoeld. Tussen begin en het einde kan dus de tekst voor de samenvatting worden geschreven. Deze komt direct na de titelpagina en is bedoeld om de lezer een korte samenvatting van het verslag te geven. Hierdoor weet de lezer of het verslag voor hem interessant genoeg is om verder te lezen. Om extra functionaliteit toe te voegen kan gebruikt worden gemaakt van het commando usepackage. \usepackage[dutch]{babel} \usepackage{graphicx} \usepackage{listings} \usepackage{fancyhdr} \usepackage{multicol} \usepackage{url} \usepackage{amssymb} \lstset{language=C} Met het pakket babel kan een andere taal dan engels geselecteerd worden. Dit heeft een aantal gevolgen. • De hoofdstukken aangegeven met Hoofdstuk in plaats van Chapter. • De figuren worden aangegeven met Figuur in plaats van Figure. • De bijlagen worden aangegeven met Bijlage in plaats van Appendix. • De datum word in het Nederlands weergegeven. • etc... Het graphicx pakket zorgt ervoor dat er gebruik kan worden gemaakt van plaatjes en voor programmeurs is er het pakket listings. Hiermee kan er tot op zekere hoogte gebruik gemaakt worden van syntax highlighting. Met fancyhdr kan de kop- en voettekst van de pagina aangepast worden. Dit moet vervolgens nog wel gedefinieerd worden voordat het daadwerkelijke document begint. In dit verslag word gebruik gemaakt van de volgende opmaak: 77
IPROJ1 - Project semester 6, blok 1
18 april 2007
\pagestyle{fancy} \lhead{IPROJ1 - Project semester 6, blok 1} \rhead{\today} Dit geeft aan dat in de linkerbovenhoek “IPROJ1 - Project semester 6, blok 1 “ word geplaats en rechtsbovenin de datum. Het multicol pakket geeft de mogelijkheid tot het gebruiken van meerdere kollommen per pagina. Hier kan op de volgende manier gebruik van worden gemaakt: \begin{multicols}{2} Hier komt de tekst. \end{multicols} Hier heb ik 2 kollommen gedefinieerd. Alle tekst hiertussen geplaatst zal in 2 kollommen opgedeeld worden. Dit is onder andere handig voor woordenlijsten en als je veel korte stukken tekst hebt. Met het pakket url kan snel gedefineerd worden dat een regel een hyperlink is. Hiermee word de regel cursief gedrukt en voorkom je dat deze afgebroken word als deze niet op de regel past. \url{http://www.ditiseenurl.nl} Het laatste pakket is voor wiskundig gebruik. Hierdoor kunnen verschillende wiskunde letters gebruikt worden. Hieronder heb ik er een aantal neergezet. • C • I • R • R1 • Rm • T • Z De volgende 2 commando’s hebben betrekking tot de paragrafen. Op het moment dat er een lege regel tussen tekst staat zal LATEX dit zien als een nieuwe paragraaf. Het maakt niet uit hoeveel lege regels dit zijn. \parindent=0in \parskip = 1.8ex Parindent geeft aan dat er bij elke nieuwe paragraaf niet ingesprongen moet worden. Parskip geeft aan hoeveel ruimte er vertical tussen de verschillende paragrafen staat. 78
IPROJ1 - Project semester 6, blok 1
18 april 2007
Document structuur Een document is in meerdere stukken te verdelen. Dit zijn allemaal tekstbestanden met LATEX commando’s. Er is altijd 1 hoofdbestand te gedefinieerd. Dit bestand zal gecompileerd worden en van hieruit zullen alle andere bestanden ingevoegd worden tijdens het compileren. Dit word gedaan met behulp van het commando “input“. In dit geval bestaat het document onder andere uit de volgende bestanden. • documentatie.tex (master document) • hardware.tex • software.tex • subversion.tex • ... Ze staan niet allemaal aangegeven maar als gekeken word naar bijlage C.2 dan is te achterhalen welke het allemaal zijn. Hierdoor is het dus makkelijker om een document in verschillenden stukken op te delen. Op het moment dat er een compleet hoofdstuk niet nodig is hoeft de input regel alleen even gecomment te worden met behulp van het % teken. Deze kunnen makkelijk in het document toegevoegd worden door gebruik te maken van input in het hoofdbestand. Hoofdstukken en Paragrafen In LATEX is het niet nodig om de hoofdstukken en paragrafen zelf te nummeren. Dit word automatisch gedaan tijdens het compileren. De schrijver hoeft zich hier niet druk om te maken ook al besluit hij later de tekst compleet van volgorde te veranderen. Het enige dat hij moet doen is aangeven dat een regel de titel van een hoofdstuk of paragraaf is. Dit kan op de volgende manier gedaan worden: \chapter{Hier komt de titel van een hoofdstuk} \section{Hier komt de titel van een paragraaf} \subsection{Hier komt de titel van een subparagraaf} Door vervolgens ergens in het document het commando tableofcontents te plaatsen wordt daar tijdens het compileren de index gegenereerd. Hetzelfde is te doen voor tabellen en figuren. LATEX kan hier automatisch lijsten van genereren. Hierin wordt het tabel of figuur nummer gegeven. Ook word er automisch het pagina nummer bij geplaatst. Ik heb hier geen voorbeeld van geplaatst omdat deze simpelweg voorin dit verslag te vinden zijn. Voetnoten, Labels en Referenties Voetnoten zijn binnen een LATEX extreem makkelijk te gebruiken. Op het punt in de tekst waar je een voetnoot wil plaatsen zet je simpelweg de volgende tekst. 79
IPROJ1 - Project semester 6, blok 1
18 april 2007
Dit is een zin met een voetnoot.\footnote{Voetnoot uitleg} Dit levert hetvolgende op: “Dit is een zin met een voetnoot.10 “ Verder kan er gebruik gemaakt worden van labels en referenties. Aan hoofdstukken, paragrafen, tabellen of plaatjes kan een zogenaamd label worden gehangen.
\chapter{Dit is een hoofdstuk} \label{chap:hoofdstuk} \begin{figure} \centering \includegraphics[width=12cm,bb=0 0 524 319]{test.png} \caption{Figuur onderschrift.} \label{img:test} \end{figure} \begin{table} \begin{center} \begin{tabular}[center]{lr} rij 1.1 & rij 1.2 \\ rij 2.1 & rij 2.2 \\ \end{tabular} \caption{Tabel onderschrift.} \label{tab:rijoverzicht} \end{center} \end{table}
Ik heb hier voorbeelden van labels geplaatst. Bij een hoofdstuk, plaatje of een tabel. Hieraan kan vervolgens op de volgende manier gerefereerd worden:
Ik refereer hier aan hoofdstuk \ref{chap:hoofdstuk}. Zie figuur \ref{img:test} voor een plaatje van ... De gegevens staan in tabel \ref{tab:rijoverzicht}...
Tijdens het compileren zullen deze referenties automatisch vervangen worden door de corresponderende nummers. Het voordeel hiervan is dat het makkelijk is om de volgorde van het document achteraf te veranderen. De nummers worden namelijk bij het compileren opnieuw bepaald. Om het mezelf makkelijk te maken houd ik een systeem aan voor de naamgeving van de labels. De namen worden in het geval van plaatjes vooraf gegaan door img: waarmee ik het engelse woord image bedoel. Tabellabels worden vooraf gegaan door tab: en chap: geeft een hoofdstuklabel aan (chapter ). Hierdoor is snel uit te zoeken waaraan gerefereerd word. Kile maakt het zijn gebruikers extra makkelijk door een complete lijst van labels weer te geven zodra er gebruik word gemaakt van ref. 10 Voetnoot
uitleg
80
IPROJ1 - Project semester 6, blok 1
18 april 2007
Lijsten Lijsten kunnen op de volgende manier gebruikt worden. Ook hier weer heeft Kile extra functies waardoor ze makkelijker zijn in het gebruik. Ik zal hier telkens de tekst geven die in het document geplaatst word en daaronder het resultaat wat dat oplevert. \begin{itemize} \item optie 1 \item optie 2 \end{itemize} • optie 1 • optie 2 \begin{enumerate} \item optie 1 \item optie 2 \end{enumerate}
1. optie 1 2. optie 2 \begin{description} \item[Hier] komt tekst \item[Hier] komt tekst \end{description}
Hier komt tekst Hier komt tekst Hopelijk hebben wij hiermee genoeg uitleg gegeven zodat degene die ermee wil proberen te werken direct aan de slag kan. Verder zijn er ontzettend veel websites te vinden met uitleg. Hierop kan nog veel meer informatie gevonden worden. Hetgeen dat in dit document staat is een minimum basis om ermee te kunnen werken.
81
Hoofdstuk 4
Resultaten en conclusies De primaire functie van de robot is gerealiseerd. Door een defect component is er tijdens de demonstratie echter niet voldaan aan de eisen, de oorzaak hiervan is nader gespecificeerd in het hoofdstuk evaluatie.
4.1
Gehaalde doelstellingen
De robot voldoet aan de volgende eisen die zijn gesteld in de specificaties: Robotplatform: • Afmetingen kleiner dan 80cm x 50cm x 50cm (l x b x h) • Gewicht lager dan 20kg. • De camera is gemonteerd, en kan het beeld via een draadloze netwerkverbinding uitsturen. • De robot kan op afstand worden bestuurd. • De robot kan bommen ontmantellen1 . Smooth control: • Volledig geimplementeerd. De buffer-grootte van het MAF-filter en de duur van het filter zijn instelbaar. Docking procedure: • Volledig geimplementeerd. 1 Tijdens
de demonstratie was dit door een defect component niet gehaald
82
IPROJ1 - Project semester 6, blok 1
18 april 2007
Omgevingsfactoren: • De robot is in staat om bommen te demonteren wanneer de lichtsensor 500 Lux licht ontvangt.
4.2
Niet gehaalde doelstellingen
De volgende eisen die zijn gesteld in de specificaties zijn niet gehaald: Indicator van de beschikbare accucapaciteit:: • De accuspanning wordt gemeten, de aansturing van het display waarop dit wordt weergegeven is echt niet gelukt door problemen met de lookuptable in de PIC-microcontroller die het display aan dient te sturen. Dit onderdeel functioneerd dus niet.
4.3
Niet onderzocht
Van de volgende eisen is niet onderzocht of het eindproduct aan de specificaties voldoet: Omgevingsfactoren: • Luchtvochtingheid. • Temperatuur waarin de robot functioneerd en opgeslagen kan worden. • De hoogtes waarop de robot functioneerd. • Fluctuatie van de voeding.
83
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur 4.1: Het eindproduct
84
Hoofdstuk 5
Evaluatie 5.1
Software
Rijrichting van robot instellen Een van de problemen die we tijdens het programmeren tegen kwam was dat de motor niet achteruit wilde rijden. We stelden de richting van de motor in met de putmot functie uit het i2c.c bestand. We konden de oorzaak hiervan niet achterhalen en ook het compileren gaf geen foutmelding. Toen we de motorcode voor het eerst onder ogen kregen hebben we met de definties ldir, rdir lspeed en rspeed gerommeld. We waren in de veronderstelling dat we deze weer op de juiste waarde terug hadden gezet en omdat de motor bijna helemaal werkte hebben we hier niet meer aan gedacht. Helaas bleek hier wel de fout in de schuilen. De definties van ldir en rdir waren niet correct. Hierdoor had het geen zin om de putmot functie te gebruiken voor het instellen van de richting. Dit aangezien de 0 of 1 niet naar de juiste registers geschreven werd. We hebben hier best veel tijd aan besteed omdat de compiler hier geen fout voor genereerde aangezien het correcte C code was. Na het goedzetten van de ldir en rdir definities werkte de motoraansturing prima.
Motor en LED initialisatie Een ander probleem waar we mee te maken kregen was dat de LEDs niet goed werkten. Ze gaven niet de juiste waarde aan en reageerden pas op de toetsen na het indrukken van de reset knop. Dit was niet het gedrag wat we verwachten. Na een dag puzzelen kwamen wij erachter dat dit te maken had met de motorinitialisatie. Aangezien de motoren en de LEDs gebruik maken van eenzelfde IO verbinding. De oplossing bleek uiteindelijk dus dat op het moment dat je de LEDs wil 85
IPROJ1 - Project semester 6, blok 1
18 april 2007
gebruiken je deze als laatste geinitialiseerd moet hebben. Dit betekend dus simpelweg dat de LEDs na de motor geinitialiseerd moeten worden. Als je daarna de motor weer aan wil sturen moet je deze als laatste initialiseren. I/O-lijnen lijken niet te werken Op een gegeven moment wilden we de robot besturen aan de hand van sensoren. Deze hadden we aangesloten op poort 22 en 23. De poorten kregen we niet aan de praat door de juiste bits in te stellen van het PINSEL1 register. De poorten bleven op output staan. We hadden echter over het hoofd gezien dat de poorten hoger dan 15 gebruikt werden voor de JTAG-interface. Dit betekend dat de JTAG-interface utigeschakeld dient te worden voor er van deze poorten gebruik kan worden gemaakt.
5.2
Eindresultaat
De primaire functie van de robot is gerealiseerd. De robot is in staat om draadloos bestuurd te worden en bommen te ontmantellen. Tijdens de demonstratie werkte de primaire functie van de robot echter niet naar behoren: ´ en van de motoren om de schakelaars om te zetten is de dag voor de • E´ demonstratie doorgebrand. Er is op de dag van de demonstratie nog een nieuwe motor van een ander type gehaald bij een auto-sloopbedrijf. Deze had echter een minder ver rijkende uitslag dat het vorige model. Hierdoor klikte de schakelaar niet altijd om. De code is nog aangepast om de disarmprocedure te blijven doorlopen totdat de bom ontmanteld is, waardoor ade bommen alsnog ontmanteld konden worden. Uiteindelijk bleek de motor niet te werken, doordat de gebruikte relais het vermogen dat de motor trok niet aankonden. Het relais moest elke keer nadat de motot werd gebruikt vervangen te worden, waardoor er met slechts ´e´en schakelaar bommen gedemonteerd konden worden. • De motoraansturing van de robot heeft het begeven. De oorzaak hiervan is onbekend.
86
Deel II
Projectmatig
87
Hoofdstuk 6
Organisatie, werkwijze en methodiek 6.1
Projectgroep
De uitvoering geschiedt d.m.v. het in groepsverband en projectmatig werken van vijf studenten. De projectgroep betaat uit: Projectlid Ivan Vriezen Thien Nguyen Marcel Okhuijsen Dennis Tessels Joost van Weenen
Student nr. 1187377 1182635 1142584 1182787 1179489
E-mailadres
[email protected] [email protected] [email protected] [email protected] [email protected]
Telefoon nr. 06-51471751 06-50548160 06-38701276 06-23129457 06-27237753
Tabel 6.1: Projectleden De projectleden zijn te allen tijde bereikbaar via de in tabel 6.1 vermelde emailadressen en telefoonnummers. Elke student volgt de opleiding Electrotechniek aan de Hogeschool Utrecht, met als specialisatie embedded systems. Binnen de projectgroep zal elk individu verantwoordelijk zijn voor de realisatie van het op te leveren product. De uitvoerende partij is dus de gehele projectgroep. Voor de uitvoering van het project heeft de heer I. Vriezen de rol als projectleider. De taakomschrijving van de projectleider is het managen van de projectgroep, de voortgang bewaken, de begeleidende docenten / opdrachtgever op de hoogte houden van de voortgang en het voorzitten van vergaderingen. De projectleider is ook verantwoordelijk voor het controleren en representatief maken van de documentatie. De rol van notulist wordt vervuld door de heer J. van Weenen. 88
IPROJ1 - Project semester 6, blok 1
18 april 2007
In principe is er ´e´en aanspreekpunt binnen de projectgroep voor contact en externe communicatie met de begeleidende docenten / opdrachtgever, namelijk de projectleider: de heer I. Vriezen
6.2
Opdrachtgever
De opdrachtgevers en tevens begeleidende docenten zijn de heren Franc van der Bent en Don Dijkstra, beide werkzaam aan de Hogeschool Utrecht. De heer Franc van der Bent begeleid de studenten met de specialisatie embedded systems en daarmee dus ook onze projectgroep. Hier volgen de bijbehorende contactgegevens:
6.3
Naam Functie Kantoor Telefoonnummer E-mailadres Instelling Vakcode
: : : : : : :
Franc van der Bent Docent Oudenoord 370, kamer D221 030-2388547
[email protected] Hogeschool Utrecht, faculteit natuur & techniek IPROJ1
Naam Functie Kantoor Telefoonnummer E-mailadres Instelling Vakcode
: : : : : : :
Don Dijkstra Docent Oudernoord 370, kamer D306 030-2308069
[email protected] Hogeschool Utrecht, faculteit natuur & techniek IPROJ1
Werkwijze
Samenvatting; hoofdpunten van de werkwijze: • De opgedane kennis wordt intern uitgewisseld. • Er kan elke projectdag vergaderd worden, de notulen worden dagelijks bijgewerkt. • Alle projectleden dragen medeverantwoordelijkheid voor het gehele project. • Er zijn kwaliteitsnormen voor de verslagen. • Er wordt versiebeheersoftware gebruikt waarmee de voortgang kan worden gevolgd door medeteamleden. • De kwaliteit van het eindproduct wordt gewaarborgd door een modulaire opbouw en een testproces. 89
IPROJ1 - Project semester 6, blok 1
18 april 2007
Kennisoverdracht:
• De opgedane kennis wordt binnen de projectgroep uitgewisseld door het intern opleveren van verslagen en presentaties.
Vergaderingen:
• Er kan op elke dag dat de projectgroep bijeen is vergaderd worden, met een minimum van ´e´en maal per week.
• De dagelijks ingebrachte punten, besluiten en actiepunten worden door de notulist verwerkt in de wekelijkse notulen.
• De notulen van de huidige week wordt op elke dag dat er vergaderd is bijgewerkt en is door elk projectlid te bezichtigen door gebruik te maken van de versiebeheer-software. Agendapunten kunnen hier ook worden geplaatst, zodat projectleden zich kunnen voorbereiden en alvast een visie op elk punt kunnen bedenken.
Gezamelijke verantwoordelijkheid:
• Binnen de projectgroep zal elk individu verantwoordelijk zijn voor de realisatie van het op te leveren product.
• Elk projectlid denkt actief mee en observeerd de medeteamleden en de projectgroep als geheel, op de gebieden van taakverdeling, voortgang, inbreng, houding en het projectmatige en technisch-inhoudelijke vlak.
90
IPROJ1 - Project semester 6, blok 1
18 april 2007
Verslaglegging: • Alle verslagen die niet bedoeld zijn voor intern gebruik zullen voldoen aan de eisen zoals gespecificeerd in het bij de kick-off van het project geleverde document ”Projectverslag Eisen”. • Alle verslagen zullen worden gecontroleerd door de projectleider. • Gedurende het project zullen interne verslagen worden opgeleverd voor gebruik in het projectverslag of de systeemdocumentatie. • Er zal gebruikt gemaakt worden van versiebeheer-software voor de geschreven software, waarbij kan worden achterhaald welk projectlid verantwoordelijk is voor welk deel van de code en de voortgang door de medeteamleden kan worden gevolgd. Samenwerking met een projectgroep communicatie-technologie: • Een deel van het eindproduct zal worden gerealiseerd door een projectgroep uit onze klas met de specialisatie communicatie-technologie. • Onze projectgroep zal afspraken maken over de specificaties van een dataoverdrachtprotocol met ´e´en van de projectgroepen communicatie-technologie en een projectgroep met dezelfde opdacht als die van onze projectgroep. Projectleider: • De projectleider houdt de voortgang van project en het functioneren van de projectgroep in de gaten, tevens op individuele basis. • De projectleider houdt de begeleidende docenten / opdrachtgever op de hoogte van de voortgang. • De projectleider is in de begin- en eindfase van het project hoofdzakelijk bezig met het projectmatige aspect. Tussen de begin- en eindfase in besteed de projectleider naast de doorlopende projectmatige taken tijd aan het technische aspect van het project. Kwaliteit: • De kwaliteit van het eindproduct wordt gewaarborgd door een modulaire opbouw en een testproces. Het eindproduct wordt opgebouwd in modules. Van elke module zal getest worden of deze aan de gespecificeerde eisen voldoet voordat deze in het systeem geplaatst wordt. Na toevoeging van de modules zal er een systeemtest gehouden worden voor het totale systeem. Hierbij worden de gemeten resultaten vergeleken met de gespecificeerde eisen van het systeem. • Indien blijkt dat de testresultaten niet voldoen aan de gespecificeerde eisen, zal er onderzocht worden waardoor dit komt en waarom dit een probleem is. Vervolgens zal bepaald worden met welke aanpak het probleem verholpen kan worden.
91
IPROJ1 - Project semester 6, blok 1
18 april 2007
Taakverdeling: Hardware
: Thien Nguyen : Dennis Tessels
Software
: Marcel Okhuijsen : Ivan Vriezen : Joost van Weenen
Projectmatig aspect
: Ivan Vriezen : Joost van Weenen (ondersteunend)
6.4
Strategie
Bij het voorbereiden, realiseren, monitoren en beheersen van dit project zal een werkwijze worden gehanteerd die beschreven staat in het dictaat Introductie Projectmatig werken 1 . Er wordt iteratief gewerkt vanuit opgestelde fasen, welke beschreven staan in het hoofdstuk Planning.
1 Dit
document is geschreven door Michiel Scager, zie de literatuurlijst voor meer informatie.
92
Hoofdstuk 7
Proces De realisatie van het project besloeg zeven lesweken en een activiteitenweek. Het product zal in zijn totaliteit in de activiteitenweek worden opgeleverd, hierdoor zal praktisch gezien het gehele eindproduct in zeven lesweken gerealiseerd moeten worden. Bij de realisatie van dit project is gebruik gemaakt van fasering in vijf hoofdfasen, welke elk opgedeeld zijn in twee of drie fasen. In tabel 7.1 is deze indeling schematisch weergegeven. In de volgende paragraaf staat de specificatie van de activiteiten vanuit dit schema. Hoofdfase Fase 1 - Start project Fase 2 - Ontwerpen en realiseren van de docking-procedure (Autonoom koppelen van de robot aan de bom) Fase 3 - Ontwerpen en realiseren van het bomdemontage-systeem (Autonoom demonteren van de bom) Fase 4 - Ontwerpen en realiseren netwerk-functionaliteit Fase 5 - Oplevering
Fase specificatie Definitie fase Vooronderzoek fase Definitie fase Analyse en ontwerp fase Test en realisatiefase Definitie fase Analyse en ontwerp fase Test en realisatiefase Definitie fase Analyse en ontwerp fase Test en realisatiefase Evaluatie fase Presentatie / demonstratie fase
Tabel 7.1: Fase specificatie De studielast van IPROJ1 bedraagt vijf ECTS per projectlid, oftewel 140 klokuren. Dit is onderverdeeld in zeven lesweken van 18 klokuren per week en een activiteitenweek van 14 klokuren. Voor de gehele projectgroep komt dit neer op 90 klokuren per lesweek en 70 uur in de activiteitenweek. In de lesweken zijn negen klokuren per week ingeroosterd voor het project, de overige uren worden buiten de ingeroosterde uren besteed. In totaal wordt er door de gehele projectgroep 700 uur besteed. 93
IPROJ1 - Project semester 6, blok 1
18 april 2007
NB. In de specifieke planning zijn de onderstaande wekelijkse projectmatige activiteiten niet opgenomen:
• Vergaderingen.
• Notulen opstellen en inleveren voor specifieke weekplanningen.
• Voortgangsrapportages opstellen.
De activiteiten in de specifieke planning worden gekoppeld aan ´e´en of meerdere groepsleden met een aantal te besteden uren. Dit zal worden bijhehouden d.m.v. de voortgangsrapportages.
7.1
Specifieke planning
Hier volgt een beknopte specifieke planning, waarbij een algemene voortgang en mijlpalen zijn vermeld. De uren staan vermeldt in de meest rechtse kolom. Fase 1 - Start project Week 1. Definitie fase Ori¨entatie op het product. Welke eisen en randvoorwaarden zitten er aan het product?
Activiteiten Inleiding opdracht. Bestuderen documentatie. Ori¨entatie. Infrastructuur (PC’s, versiebeheer-software). Planning week 1 opstellen. Taakverdeling opstellen. Globale planning opstellen. Code bestuderen en platform aansturen. Bestuderen I2 C protocol. Concept ontwerp mechatronica opstellen . Concept eisenblad opstellen. Concept Plan van Aanpak opstellen. Mijlpaal: Mijlpaal: Mijlpaal: Mijlpaal:
Globale planning Concept eisenblad Concept Plan van Aanpak Ontwerp mechatronica
Tabel 7.2: Fase 1 - Start project
94
5 10 12 5 1 2 5 12 3 9 6 10
IPROJ1 - Project semester 6, blok 1
18 april 2007
Fase 2 - Ontwerpen en realiseren van de docking-procedure Week 2. Analyse en ontwerp fase (docking-procedure) Er wordt een compleet ontwerp opgesteld voor de dockingprocedure.
Activiteiten Overleg opdrachtgever. Plan van Aanpak revisie 2. Eisenblad. Specifieke planning opstellen. Voorstel software-ontwerp opstellen. Aanzet code voor docking-procedure. Aanzet hardware docking-procedure. Ontwerpen schema sensoren docking-procedure. Mijlpaal: Mijlpaal: Mijlpaal: Mijlpaal:
3. Test en realiserende fase (docking-procedure) De docking-procedure wordt gerealiseerd, tevens zal worden onderzocht of het product voldoet aan de eisen.
Rapportage: Eisenblad. Rapportage: Plan van Aanpak. Specifieke planning. Rapportage: Voorstel software-ontwerp.
Overleg opdrachtgever. Realisatie code docking-procedure . Realisatie hardware docking-procedure. Systeem test docking-procedure. Aanzet code bom detector. Aanzet ontwerpen hardware bom detector. Onderdelen bestellen/regelen voor bomdemontage. Ontwerp en uitwerken dataprotocol Overleg met andere groepen over dataprotocol Mijlpaal: Realisatie docking-procedure. Mijlpaal: Afsluiting tweede fase project.
Tabel 7.3: Fase 2 - Ontwerpen en realiseren van de docking-procedure
95
2 6 4 6 20 2 30 4
2 10 18 8 8 28 4 8 2
IPROJ1 - Project semester 6, blok 1
18 april 2007
Fase 3 - Ontwerpen en realiseren van het bomdemontage-systeem Week 4. Analyse en ontwerp fase (bom-demontagesysteem) Er wordt een compleet ontwerp opgesteld voor het bomdomontagesysteem.
Activiteiten Overleg opdrachtgever. Revisie eisenblad. Ontwerp en realisatie aansturing console. Ontwerp bomdemontage. Aanzet hardware bomdemontage. Aanzet code bomdemontage. Ontwerp en uitwerken dataprotocol Overleg met andere groepen over dataprotocol
2 2 8 6 28 30 4 2
Mijlpaal: Outline presentatie. 5. Test en realiserende fase (bom-demonstagesysteem) Het bom-demonstagesysteem wordt gerealiseerd, tevens zal worden onderzocht of het product voldoet aan de eisen.
Overleg opdrachtgever Realisatie hardware bomdemontage Realisatie code bomdemontage Systeem test bomdemontage Bestuderen en aanzet code van netwerkkaart Extra opdracht: Print ontwerpen.
2 10 10 8 32 20
Mijlpaal: Realisatie autonome bomdemontage Mijlpaal: Afsluiting derde fase project
Tabel 7.4: Fase 3 - Ontwerpen en realiseren van het bomdemontage-systeem Fase 4 - Ontwerpen en realiseren netwerk-functionaliteit Week 6. Analyse en ontwerp fase (netwerk-functionaliteit) Er wordt een compleet ontwerp opgesteld voor de netwerkfunctionaliteit.
Activiteiten Overleg opdrachtgever. Realiseren code voor aansturing via netwerk. Revisie eisenblad. Ontwerp en realisatie indicator accu-capaciteit. Ontwerp en realisatie verlichting IR-camera. Monteren hardware van CT-groep. Extra opdracht: Print ontwerpen.
2 28 2 16 10 4 20
Mijlpaal: Realisatie primaire functie van de robot. Mijlpaal: Realisatie accuspanningindicator. 7. Test en realiserende fase. (netwerk-functionaliteit) Het complete systeem wordt gerealiseerd, tevens zal worden onderzocht of het product voldoet aan de eisen.
Overleg opdrachtgever. Ontwerp en realisatie ”smooth control”. Onderzoek EC. Systeemtest robot. Aanzet projectverslag opstellen. Aanzet voorbereiden presentatie. Mijlpaal: Rapportage: EC-test. Mijlpaal: Presentatie af. Mijlpaal: Afsluiting vierde fase project.
Tabel 7.5: Fase 4 - Ontwerpen en realiseren netwerk-functionaliteit
96
2 12 40 8 14 10
IPROJ1 - Project semester 6, blok 1
18 april 2007
Fase 5 - Oplevering Week 8. Activiteitenweek Evaluatie en presentatie fase De realiserende fasen zijn afgesloten met als resultaat de oplevering van het gehele eindproduct. De evaluatie staat ook centraal.
Activiteiten Voorbereiden presentatie. Projectverslag opstellen. Teamrapportage opstellen (evaluatie). Presentatie en demonstratie (beoordeling). Mijlpaal: Oplevering.
Tabel 7.6: Fase 5 - Oplevering
7.2 7.2.1
Daadwerkelijke tijdsbesteding Urenstaten
Voor elke lesweek zijn urenstaten opgemaakt. Uren die gemaakt zijn in overige weken zijn bij de urenstaten van de voorgaande week inbegrepen. De uren die gemaakt zijn in de eerste projectweek zijn bij de uren van de activiteitenweek toegevoegd. De urenstaten zijn toegevoegd als bijlagen: Week Lesweek Lesweek Lesweek Lesweek Lesweek Lesweek Lesweek
7.2.2
1 2 3 4 5 6 7
Tabel Tabel Tabel Tabel Tabel Tabel Tabel Tabel
A.1 A.2 A.3 A.4 A.5 A.6 A.7
Totale tijdsbesteding
De totale tijdsbesteding is opgesomd in tabel 7.7. Voor de activiteitenweek is een schatting gemaakt, omdat de oplevering van dit eindverslag tijdens de activiteitenweek gepland staat. Er is een totale tijdsoverschrijding gemaakt van rond de 40 uur. Een tweede constatering is dat er ook significate verschillen zitten tussen de uren per projectlid.
7.2.3
Uitvoering
Tijdens de uitvoering van de planning zijn er een aantal problemen ontstaan. 97
25 10 10 25
IPROJ1 - Project semester 6, blok 1
Activiteit Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Activiteitenweek Project totaal
Ivan 23 21 18 23,5 17 29 22,5 30 184
Thien 16 20,5 16 9,5 13,5 11 16,5 30 132
18 april 2007
Marcel 15 12,5 13 16 21 9 12,5 30 129
Dennis 21 20,5 18 13 19 18,5 26,5 30 167
Joost 15 15 17,5 11,5 22 6,5 8,5 30 126
Totaal 90 89,5 82,5 73,5 92,5 74 86,5 150 738
Gepland 90 90 90 90 90 90 90 70 700
Tabel 7.7: Urenstaat totaal • Een aantal deadlines en mijlpalen zijn niet gehaald. • Projectleden declareren uren niet of te laat in. • Een aantal activiteiten werden verplaatst naar andere weken. Een aantal deadlines en mijlpalen zijn niet gehaald. Dit betrof metname activiteiten gerelateerd met de motorcode van de robot. De deadlines zijn hiervoor verschoven. Deze achterstand op de planning is gedurende het project niet weggewerkt. Een aantal activiteiten werden verplaatst naar eerdere weken. De achterstand kan dus deels gerelativeerd worden. Om te zorgen dat de motorcode op tijd af zou komen, is besloten dat de projectleider de netwerkcode alleen zou programmeren. Hierdoor hadden de heren M. Okuijsen en J. van Weenen meer tijd om de motorcode op tijd af te krijgen. Uren werden niet of te laat gedeclareerd. De notulen werden ook vaak te laat uitgewerkt. Dit maakte het lastiger om de voortgang van het project te bewaken. Een aantal activiteiten zijn verschoven van lesweek: • Het afspraken van een communicatie-protocol met andere projectgroepen was vervroegd naar de tweede lesweek. • De les printontwerp was verplaatst naar week 5. • De EC-test is verplaatst naar de activiteitenweek. Deze problemen gecombineerd zorgde voor een vervaging tussen de fasen, waardoor deze niet iteratief zijn doorlopen.
98
Omschrijving
Schatting
Hoofdstuk 8
Evaluatie 8.1
Peer reviews
Elk projectlid zal een peer-review houden over de andere projectleden. Het doel hiervan is om een inzicht te geven van de individuele prestaties ven elk projectlid, en een indruk te geven van het team.
8.1.1
review door Ivan Vriezen
Thien Nguyen Kan ik minder goed beoordelen dan de ander projectleden omdat ik niet direct met hem heb samengewerkt. Positief: • Kan onverstoord doorwerken waar anderen snel afgeleid zijn. Negatief: • Zeer passief. Als hij niets te doen heeft zal hij niet vragen of hij zich nuttig kan maken. Taken moeten gedelegeerd worden. • Gebrek aan assertiviteit: Tijdens een vergadering of discussie zegt hij zelden wat. Marcel Okhuijsen Positief: • Blijft altijd kalm en heeft een positieve instelling. 99
IPROJ1 - Project semester 6, blok 1
18 april 2007
• Kan goed anderen assisteren. Negatief: • Geen systematische aanpak. Probeert problemen op te lossen door willekeurig te testen. Dit kost veel tijd, waardoor deadlines niet gehaald worden en uiteindelijk geen analyse van het probleem is gemaakt. • Documentatie. Ook na continu erop gewezen te worden houdt hij geen documentatie bij van zijn bevindingen. Verslagen zijn kort en wat slordig.
Dennis Tessels Positief: • Gedreven. Is bereid een grote inspanning te leveren en veel tijd in het project te steken. • Heeft zelfstandig het overgrootte deel van de hardware gerealiseerd. • Scherp in het achterhalen van de oorzaak van een technisch probleem. Negatief: • Schriftelijke vaardigheden. Joost van Weenen Positief: • Assertief. Raadpleegt docenten en kan zeer gedreven in zijn. • Schriftelijke vaardig. • Interesse en kennis van software. Doordat hij bijvoorbeeld gebruikt maakt van versiebeheer-software en bepaalde bestandsformaten kan ik effectief met hem samenwerken. Negatief: • Eigen verantwoordelijkheid. Heeft de neiging om anderen de schuld te geven: Klaagt bijvoorbeeld dat de voorbeeldcode niet duidelijk genoeg i.p.v. dankbaar te zijn dat er voorbeeldcode is, of dat hij zelf moet vragen of een optionele extra les kan doorgaan i.p.v. dat het wordt medegedeeld. • Als het slecht gaat met een taak krijgt het hele team dit te weten, kan negatieve invloed hebben op stemming van het team. 100
IPROJ1 - Project semester 6, blok 1
18 april 2007
Reflectie Ik had bij de start van het project de ambitie om het project professioneel aan te pakken. Ik schat dat een student die goed kan programmeren, zoals ik zelf, alle code voor het project in twee tot maximaal drie weken kan afronden. Dit komt mede doordat de bijgeleverde IP-stack code van hoogwaardige kwaliteit was en er voorbeeld motorcode was bijgeleverd. Als de hardware eenvoudig wordt gehouden zou dit in ongeveer vier of vijf weken gerealiseerd kunnen worden. Doordat dat hoeveelheid te verrichte werk mee valt, vond ik dat er genoeg tijd was om het project kwalitatief goed uit te voeren: • Code en hardeware – Modulair werken, elke module volledig testen. – Volledige documentatie voor elke software functie. – Onderzoek naar de gebruikte resources van elke software functie. • Projectmatig – Gefaseerd werken, iteratief door fases heenlopen. – Methodes om de kwaliteit en voortgang te bewaken. – Analyisch en systematisch te werk gaan. Ik heb mijn uiterste best gedaan om een goed Plan van Aanpak te schrijven, Daarin heb ik beschreven hoe ik de hiervoor genoemde onderwerpen wou realiseren. In de praktijk constateerde ik echter dat bij andere projectleden een aantal van de volgende punten: • Er niet gestructureerd werd gewerkt. Er werd bij wijze van spreken aan wat knopjes gedraait tot op een gegeven moment iets werkt. • Er werd geen documentatie bijhouden. Uren en notulen kwamen soms weken te laat binnen, terwijl ik altijd mail voor de uren en er vrijwel dagelijks aan herinner bij achterstand. • Er werd weinig belang gehecht aan deadlines. Ik zou mijn taakomschrijving als projectleider eerder kwalificeren als politieagent dan als de persoon die de kwaliteit en voortgang van het project bewaakt. Het gevolg van de hiervoor vermelde punten was dat het werk uitliep. De hardware iiep op schema, maar de software raakte steeds verder vertraagd. ik overwoog twee oplossingen: • Al het programmeerwerk overnemen. Als ik hier op tijd mee zou beginnen zou het voor mij geen extra tijd kosten. 101
IPROJ1 - Project semester 6, blok 1
18 april 2007
• De programmeurs de rest van het project de tijd geven, door zelf alle andere code te programmeren. Dit hield metname de netwerkcode in. Uiteindelijk heb ik gekozen voor de laatste optie. Voor een taak waar ik zelf dacht dat het de programmeurs maximaal drie weken zou kosten, en waar ik voor de zekerheid vijf weken voor had ingepland, zijn uiteindelijk alle lesweken besteed. Terwijl de code niet meer is dan een aantal I/O-pinnen aansturen en ´e´en functie voor de motoraansturing. Er zijn wel een aantal problemen geweest, maar de meeste zouden door gestructureerder werken en analyseren slechts een klein obstakel vormen. Als projectlid heb ik al mijn taken naar behoren en op tijd uitgevoerd. Als projectleider, en als projectlid van een projectgroep met een gezamelijke verantwoordelijkheid , heb ik gefaald op de volgende onderdelen: • Ik heb als projectleider de taak om te zorgen dat deadlines gehaald worden. Toen dit niet gebeurde had ik geen ruimte voor uitstel moeten geven, maar maatregelen moeten nemen. • Om te zorgen dat uren op tijd ingeleverd worden, heb ik de maatregel genomen dat iedereen aan het eind van de dag de gemaakte uren mailt. Na een aantal weken hielden mensen zich hier niet aan, dit had ik niet moeten laten lopen. • Ik heb mondeling tegen personen herhaald dat er beter gedocumenteerd dient te worden, en er op een andere methode gewerkt dient te worden. Ik had dit zwart-op-wit moeten doen, en concrete criteria moeten geven. Dit zou projectleden meer duidelijkheid geven. • Op het einde van het project was mijn hoofddoel het werkend krijgen van het eindproduct, de kwaliteitseisen heb ik daarvoor deels laten vallen. Ik had al vroeg in het project het gevoel dat op de methode waarmee gewerkt werd er problemen zouden kunnen ontstaan. Ik had de problemen dus kunnen anticiperen en maatregelen kunnen nemen. • Ik zou de volgende keer een logboek bijhouden van de voortgang van het project, de knelpunten en de acties die ik er tegen ga nemen. • Ik ben doorgaans in projecten de hoofdprogrammeur die de belangrijkste en lastigste code schrijft, en deeltaken delegeerd. Dit had ik ik dit project ook kunnen doen om meer controle te hebben op de voortgang. Dit is het eerste project op school dat ik serieus ben begonnen met hoge ambities. Op het laatst heb ik echter nog hard moeten werken om het eindproduct alleen al werkend te krijgen. Ik ben teleurgesteld dat het ik niet heb kunnen waarmaken waar ik naar streefde. Het is een harde les van de realiteit, maar ik heb vertrouwen dat ik met de lessen die ik geleerd heb het volgende project meer succes heb om mijn ambities waar te maken. 102
IPROJ1 - Project semester 6, blok 1
8.1.2
18 april 2007
review door Thien Nguyen
Algemene indruk Het algemeen beeld dat ik heb van het team is dat er een goedwerkend teamverband is tussen de teamleden. Iedereen kan goed met elkaar opschieten in professionele sfeer, maar ook in een vrienden sfeer.
Ivan Vriezen ik vind Ivan een hardwerkend, overzichtelijk projectleider die professionaliteit hoog in het vaandel heeft. Hierdoor is het prettig om met hem te samen te werken, omdat hij altijd druk bezig is met het project.
Marcel Okhuijsen Marcel kan soms lui overkomen, maar wanneer hij aan het werk is levert hij ook wat op. Dit is prettig omdat je zeker weet dat je iets hebt.
Dennis Tessels Dennis is een harde werker die alles ervoor heeft om het project te laten lukken. Hierdoor kan hij was gestressed overkomen, omdat hij per se iets af wilt hebben.
Joost van Weenen Joost wilt altijd betrokken worden aan alles in het project, hij is vaak nieuwsgierig naar nieuwe dingen. Maar wanneer hij met iets niet mee eens is, dramt hij zijn ideen vaak door, ook al klopt niet.
8.1.3
review door Marcel Okhuijsen
Ivan Vriezen Was eigenlijk de enigste die een goed overzicht had over wat er gebeurde en speelden binnen het project. Was erg met de planning bezig en mensen eraan te herinneren wanneer de deadlines waren, dit was in sommige gevallen best nodig, anders gebeurde er niet zoveel. m.a.w een goede projectleider.
Thien Nguyen Thien was een beetje stil. Wanneer hij ergens mee bezig was hoorde je hem er nauwelijks over. Hij gaf uit zichzelf weinig feedback over hoe het ging. Deze 103
IPROJ1 - Project semester 6, blok 1
18 april 2007
kreeg je wel zodra je daarom vroeg. Maar hij deed wel de dingen waarvan besloten is dat thien die moest gaan doen.
Dennis Tessels Dennis is veel met hardware bezig geweest, maar hij probeerde wel te snappen waar de software mensen mee bezig waren. Zodanig dat daar de hardware zo aangesloten kon worden zoals de software mensen het willen. Er vond daarover goed overleg plaats en dennis is een goed aanspreekpunt voor hardware dingetjes.
Joost van Weenen Lied veel van zich horen, vooral wanneer hij het ergens niet mee eens was. Dan koste het veel moeite om hem weer wat stiller te krijgen.Dit was soms best irritant.Verder is Joost veel met documentatie bezig geweest en dat het hij best goed gedaan. Ook verzorgde hij de notulen van elke vergadering.
Reflectie Ik heb in het begin samen met joost veel tijd gestoken in het aansturen van de motoren en het uitlezen van I/O. Op het gebied van documentatie en logboek bijhouden was een extra zetje wel nodig, anders kon je er lang op wachten.
8.1.4
review door Dennis Tessels
Ivan Vriezen Ivan is een harde werker en heeft het team voor zover mogelijk goed kunnen aansturen. zijn werkwijze is om alles zo correct mogelijk uit te voeren en hij heeft een uitstekende inzet getoond. Alles is te bespreken met ivan als er maar een motivatie of argument bij aangeleverd wordt. Hij heeft een hekel aan half werk en moet zich vaak inhouden om werk niet uit handen te nemen. kortom ik heb een zeer prettige samenwerking gehad met ivan als teamlid.
Thien Nguyen Thien is een stille werker waar ik lekker mee kon samen werken. Hij kon mij op de momenten wanneer ik geen zin had in het project motiveren om toch weer aan de gang te gaan. Zijn menig zal hij niet snel uit zichzelf geven maar als je er om vraagt wel. Ook is hij een doorzetter, als een klus geklaard moet worden klaart hij hem of het nou leuk is of niet. Kortom ook met Thien heb ik een zeer prettige samenwerking gehad als teamlid. 104
IPROJ1 - Project semester 6, blok 1
18 april 2007
Marcel Okhuijsen Marcel heeft een instelling die soms iets te makkelijk is, Hij is heel handig in het uitzoeken van registers en instellingen. Maar het bekommentariseren van zijn code laat hij regelmatig achterwegen waardoor soms dubbel werk gedaan moet worden. Als je hem weet te motiveren gaat hij er ook vol tegenaan maar zonder motivatie doet hij liever andere dingen, En laat hij zich makkelijk meeslepen. Verder heb ik met plezier samen dingen uitgezocht met marcel dus ook hier een prettige samenwerking.
Joost van Weenen joost heeft zeer snel zijn mening klaar over alles wat maar iets tegen zit. en spuit dit zonder enig argument. Als er dan iets niet mee zit komt dit altijd door iets of iemand anders maar nooit door hemzelf. naar mijn mening is joost veel bezig met dingen die niet van groot belang zijn voor het project. Onder andere linux en SVN. Soms was hij ook weinig op school en werkte dan thuis, hierdoor twijfelde ik wel eens aan zijn inzet. Ook omdat hij snel tevreden is met het bereiken van resultaten. Ondanks enige wrijving tussen mij en joost heb ik wel prettig met hem samengewerkt en was hij een aanvulling voor ons team.
Reflectie Bij dit project heb ik voor het grootste deel met plezier samen gewerkt in onze groep. Ik ben daarbij vooral verantwoordelijk geweest voor de hardware en heb mischien teveel aandacht geschonken aan het leuk maken van de robot. Verder kan ik zeer slecht tegen ongegrond commentaar, en laat ik hierdoor soms de motivatie om het project te laten slagen wegnemen. Ik vond het lastig om alles op tijd af te krijgen, vooral omdat er vele tegenslagen waren naarmate het project vorderde.
8.1.5
review door Joost van Weenen
Algemene indruk Over het algemeen vond ik de het project wel aardig verlopen. Niet alles verliep vlekkeloos en ieder projectlid kan denk ik wel een punt binnen het project noemen waar zijn werk niet volgens plan ging maar dit is normaal binnen een project. In mijn eigen geval had dat voornamelijk met de motoraansturing te maken aangezien ik hier het meeste mee bezig ben geweest. Een voorbeeld hiervan is de verkeerde definitie waarden voor ldir en rdir waardoor de richting van de motoren niet veranderd kon worden. Verder heb ik enkele meningsverschillen met Ivan gehad over hoe gedeelten van het project uitgevoerd moesten worden maar deze zijn uiteindelijk opgelost. Hieronder volgt de induvidu ele evaluatie. 105
IPROJ1 - Project semester 6, blok 1
18 april 2007
Ivan Vriezen Ivan heeft in het project (denk ik) het meeste werk gedaan van alle teamleden. Ik heb een paar keer een flink meningsverschil gehad maar hier zijn we uiteindelijk uitgekomen binnen de projectgroep. Verder geen specifieke op of aanmerkingen Thien Nguyen Thien was stil op de momenten aan het begin van het project waar we aan het brainstormen waren over mogelijke oplossingen terwijl hier alle idee en en meningen welkom zijn. Marcel Okhuijsen Met Marcel heb ik veel samengewerkt en we konden elkaar vaak aanvullen. Verder geen specifieke op of aanmerkingen. Dennis Tessels Dennis heeft heel af en toe de neiging om dingen op zijn eigen vertrouwde manier aan te willen pakken. Als voorbeeld noem ik een schema willen tekenen in paint.
106
Hoofdstuk 9
Literatuur Voor het uitvoeren en realiseren van het project zullen o.a. de volgende bronnen gebruikt worden: • Internet • Kernighan, B. e.a. (2003). C handboek. Schoonhoven: Academic Service. ISBN: 90-6233-488-1 • Furber, S. (2003). ARM system-on-chip architecture. Groot-Brittani¨e: Addisson Wesley. ISBN: 0-201-67519-6 • Introductie Projectmatig Werken, dictaat, Michiel Scager, Hogeschool Utrecht, 2006 • Introductie Projectmatig Werken, modulewijzer, Michiel Scager, Hogeschool Utrecht, 2006 Eveneens wordt er gebruik gemaakt van informatie vanuit de volgende ondersteunende vakken binnen de opleiding electrotechniek aan de Hogeschool Utrecht; • PGCSN1, Computer systemen en netwerken • PCPRG1, C voor embedded systems 1 • PCPRG1, C voor embedded systems 2 • KCPST2, Computersystemen 2 • KSWOO1, Software C en OO 1 • KSWOO2, Software C en OO 2 • KDSGB1, Digitale signaalbewerking 1 • IDSIG2, Digitale signaalbewerking 2
107
Hoofdstuk 10
Verantwoording Deze rapportage is opgesteld door: Ivan Vriezen
Het technische gedeelte over de hardware is opgesteld door: Dennis Tessels Thien Nguyen Het technisch gedeelte van de docking en disarm procedure is opgesteld door: Marcel Okhuijsen Het technisch gedeelte over de motoraansturing is opgesteld door: Joost van Weenen
108
Deel III
Bijlagen
109
Bijlage A
Urenstaten
110
IPROJ1 - Project semester 6, blok 1
18 april 2007
Activiteit Vergaderen Inleiding opdracht Ori¨entatie Eisenblad opstellen Infrastructuur
Ivan 1 1 3 4 1
Thien 1 1 3 1 1
Marcel 1 1 3 1 1
Dennis 1 1 3 1 1
Joost 1 1 3 1 2
Totaal 5 5 15 8 6
Globale planning opstellen Bestuderen I2C protocol. Code bestuderen robot platform. Opbouwen en testen robot platform Concept PvA opstellen Aanzet opbouw schakelsysteem Administratieve werkzaamheden
2
-
-
-
-
2
-
3
1
-
-
4
-
-
6
-
6
12
-
5
-
5
-
10
8
0,5
0,5
0,5
0,5
10
-
-
-
8
-
8
3
0,5
0,5
0,5
0,5
5
23 23
16 16
15 15
21 21
15 15
90 0 90
Totaal Vorige weken Project totaal
Tabel A.1: Urenstaat week 1
111
Gepland
Omschrijving
Brainstormen PC’s, versiebeheersoftware
Uren, mailen, projectmatige documentatie, etc 90 0 90
IPROJ1 - Project semester 6, blok 1
Activiteit Vergaderen Plan van Aanpak Eisenblad Verslag hardware docking procedure Opbouwen en testen robot platform Uitlezen toetsen arm-bord. Compileren motorcode. Code voorstel. Aanzet code docking-procedure Aanzet hardware docking-procedure Administratieve werkzaamheden
Totaal Vorige weken Project totaal
18 april 2007
Ivan 2 14 2 -
Thien 1 2 12
Marcel 1 2 -
Dennis 1 2 12
Joost 1 2 -
Totaal 6 22 2 24
Gepland
-
5
-
5
-
10
30
-
-
3
-
-
3
-
-
-
-
8
8
-
-
4 2
-
3 -
7 2
-
-
-
-
-
-
3
0,5
0,5
0,5
1
5,5
5
21 21
20,5 20,5
12,5 12,5
20,5 20,5
15 15
89,5 0 89,5
90 0 90
Tabel A.2: Urenstaat week 2
112
Omschrijving
20 2
Uren, mailen projectmatige documentatie, etc
IPROJ1 - Project semester 6, blok 1
Activiteit Vergaderen Overleg projectgroepen Dataprotocol opstellen Revisie PvA Bestuderen code Code dockingprocedure Opstellen codevoorstel Koppeling leds/keys aan motoraansturing aansturen ARMtarget Testen camera Onderdelen regelen Revisie verslag technische aanpak Toeter regelen en testen Schakelingen bedenken Administratieve werkzaamheden
Totaal Vorige weken Project totaal
18 april 2007
Ivan 2 2
Thien 1 -
Marcel 1 -
Dennis 1 -
Joost 1 -
Totaal 6 2
4
1,5
1,5
1,5
1,5
10
4 3 -
-
2
-
8
4 3 8
-
-
-
-
6
6
-
-
8
-
-
8
-
2
-
-
-
2
-
2 2 7
-
2 4 2
-
4 6 9
-
-
-
1
-
1
-
-
-
6
-
6
3
0,5
0,5
0,5
1
5,5
5
18 18
16 16
13 13
18 18
17,5 17,5
82,5 0 82,5
90 0 90
Tabel A.3: Urenstaat week 3
113
Gepland
Omschrijving Afspraken dataprotocol
Uren, mailen, projectmatige documentatie, etc
IPROJ1 - Project semester 6, blok 1
18 april 2007
Activiteit Vergaderen Overleg projectgroepen definitieve Plan van Aanpak Compileren en bestuderen netwerkcode Controleren PvA Motoraansturing Bediening motoraansturing Koppeling sensoren aan ARM-board Verbeteren codevoorstel Pin-indeling ARMboard Eagle-software installeren Metingen testbom Schakelaar-sensoren monteren Mechanisme maken voor schakelen Schema’s IRdetectie en schakelmechanisme Camera testen Schroefdraad tappen Onderdelen regelen Administratieve werkzaamheden
Ivan 2 1,5
Thien 1,5 -
Marcel 1,5 -
Dennis 1,5 -
Joost 1,5 -
Totaal 8 1,5
4
-
-
-
-
4
10
-
-
-
-
10
1,5 1 -
-
7 4
-
4 2,5
1,5 12 6,5
-
-
3
-
-
3
-
-
-
-
2
2
0,5
3,5
-
3
-
7
-
-
-
1
-
1
-
-
-
0,5 2
-
0,5 2
-
-
-
2
-
2
-
2
-
-
-
2
-
1 -
-
0,5 1
-
1,5 1
3
1 0,5
0,5
1 0,5
1,5
2 6
6
Totaal Vorige weken Project totaal
23,5 23,5
9,5 9,5
16 16
13 13
11,5 11,5
73,5 73,5
90 0 90
Tabel A.4: Urenstaat week 4
114
Gepland
Omschrijving
Afspraken data protocol
Uren, mailen projectmatige documentatie, etc
IPROJ1 - Project semester 6, blok 1
Activiteit Vergaderen Overleg projectgroepen Les printontwerp Compileren netwerkcode op linux Update netwerkcode Outline presentatie Codevoorstel Onderzoek eagle Realiseren accuspanningsindicator 5V voeding realiseren IR-detectie realiseren Steunen voor actuatoren Onderdelen regelen Realiseren code docking-procedure I/O-aansturing werkend krijgen Code netter gemaakt Probleem opgelost met initialisatie Code simuleerbaar dmv keys Administratieve werkzaamheden
Totaal Vorige weken Project totaal
18 april 2007
Ivan 2 1
Thien 1,5 -
Marcel 1,5 -
Dennis 1,5 -
Joost 1,5 -
Totaal 8 1
2 2
2 -
2 -
2 -
2 -
10 2
6
-
-
-
-
6
0,5 0,5 -
3 6,5
-
-
2 -
0,5 2,5 3 6,5
-
-
-
8,5
-
8,5
-
-
-
2
-
2
-
-
-
3
-
3
-
-
1 3
1 -
2
2 5
-
-
6
-
6
12
-
-
1
-
1
2
-
-
4
-
4
8
-
-
2
-
2
4
3
0,5
0,5
1
1,5
6,5
6
17 17
13,5 13,5
21 21
19 19
22 22
92,5 92,5
90 0 90
Tabel A.5: Urenstaat week 5
115
Gepland
Omschrijving Afspraken dataprotocol
Uren, mailen, projectmatige documentatie, etc
IPROJ1 - Project semester 6, blok 1
Activiteit Vergaderen Documentatie docking procedure Eagle Ontwerpen accuspannings detectie Repareren robot Code bomontmantelen Onderdelen regelen I/O arm-board en schakeling koppelen Realiseren bomdemontage schakelaars Code telnet commando’s Debugger geinstalleerd Motoraansturin geport naar nieuwe netwerkcode Achterhalen storing ARM-board Onderzoek invloed shared I/O op NIC Code voor aansturen interface armboard Motoraansturing Meting interrupt tijden NIC Administratieve werkzaamheden
Totaal Vorige weken Project totaal
18 april 2007
Ivan 2 -
Thien 1,5 -
Marcel 1,5 -
Dennis 1,5 -
Joost 1,5 3,5
Totaal 8 3,5
-
3 3
-
5 1
-
8 4
-
2 -
7
-
-
2 7
-
1 -
-
1 6
-
2 6
-
-
-
3
-
3
8
-
-
-
-
8
1
-
-
-
-
1
2
-
-
-
-
2
2
-
-
-
-
2
4
-
-
-
-
4
4
-
-
-
-
4
1 2
-
-
-
-
1 2
3
0,5
0,5
1
1,5
6,5
6
29 29
11 11
9 9
18,5 18,5
6,5 6,5
74 74
90 0 90
Tabel A.6: Urenstaat week 6
116
Gepland
Omschrijving
Uren, mailen projectmatige documentatie, etc
IPROJ1 - Project semester 6, blok 1
18 april 2007
Activiteit Vergaderen Eagle Onderzoek NIC Robot-code porten naar netwerkcode Realiseren accuspanningsdetectie Verslag acsupanningsdetectie Documentatie latex en subversion Docking/disarm code Documentatie docking/disarm Opbouwen neon, omvormer accu en print Opbouwen webcam en draadloze verbinding Testen dockingprocedure robot Diodes om accu’s tegelijk te laten opladen. Steunen voor schakel-mechinisme Documentatie motorboard Administratieve werkzaamheden
Ivan 1,5 5 12
Thien 1 -
Marcel 1 4 -
Dennis 1 4 -
Joost 1 -
Totaal 5,5 8 5 12
-
11
-
-
-
11
-
4
-
-
-
4
-
-
-
-
6
6
-
-
2
-
-
2
-
-
5
-
-
5
-
-
-
8
-
8
-
-
-
3
-
3
1
-
-
1
-
1
-
-
-
1,5
-
1,5
-
-
-
3
-
3
-
-
-
4
-
-
3
0,5
0,5
1
1,5
6,5
6
Totaal Vorige weken Project totaal
22,5 22,5
16,5 16,5
12,5 12,5
26,5 26,5
8,5 8,5
88,5 88,5
90 0 90
Tabel A.7: Urenstaat week 7
117
Gepland
Omschrijving
Uren, mailen, projectmatige documentatie, etc
Bijlage B
Code B.1
Netwerkcommando evaluatie
void robot_smoothcontrol_intHandler(void) { if(smoothcontrol_enabled) { switch(global_command_direction) { // Handel hier commands af case ’1’: iLeftBackward(); break; case ’2’: iBackward(); iBackward(); iBackward(); break; case ’3’: iRightBackward(); break; case ’4’: iLeft(); break; case ’5’: iStop();break; case ’6’: iRight(); break; case ’7’: iLeftForward(); break; case ’8’: iForward(); iForward(); iForward(); break; case ’9’: iRightForward(); break; default: iStop();break; } } iDrive(); timer1_clearint(); // clear interrupt flags }
B.2
iDrive() functie
int iDrive(void) { //BEGIN BLOK 1 - Berekenen van de gemiddelde waarden. 118
IPROJ1 - Project semester 6, blok 1
18 april 2007
int i = 0; sSpeedLeft = 0; sSpeedRight = 0; for(i = 0; i<MAXARRAYSIZE; i++) { sSpeedLeft += asSnelheid[0][i]; sSpeedRight += asSnelheid[1][i]; } sSpeedLeft = sSpeedLeft / MAXARRAYSIZE; sSpeedRight= sSpeedRight / MAXARRAYSIZE;
//BEGIN BLOK 2 - Instellen van de motorrichting. if(sSpeedLeft < 0) { motor_commando(mot,ldir,chk,1); motor_commando(mot,ldir,chk,1); sSpeedLeft = sSpeedLeft * (-1); } else { motor_commando(mot,ldir,chk,0); motor_commando(mot,ldir,chk,0); } if(sSpeedRight < 0) { motor_commando(mot,rdir,chk,1); motor_commando(mot,rdir,chk,1); sSpeedRight= sSpeedRight* (-1); } else { motor_commando(mot,rdir,chk,0); motor_commando(mot,rdir,chk,0); } //BEGIN BLOK 3 - Aansturen van de motor met de juiste waarden. motor_commando(mot,speedl,chk,sSpeedLeft); motor_commando(mot,speedl,chk,sSpeedLeft); motor_commando(mot,speedr,chk,sSpeedRight); motor_commando(mot,speedr,chk,sSpeedRight); return 0; }
119
Bijlage C
LATEX documenten C.1
Usepackage
\usepackage[dutch]{babel} \usepackage{graphicx} \usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{fancyhdr} \usepackage{multicol} \usepackage{url} \usepackage{listings} \usepackage{textcomp} \usepackage{multirow}
C.2
Input
\begin{document} \input{titelpagina} \input{samenvatting} \input{voorwoord} \input{woordenlijst} \listoffigures \listoftables \tableofcontents \input{inleiding} \input{opdracht} \input{hardware} \input{software} \input{subversion} \input{latex} 120
IPROJ1 - Project semester 6, blok 1
18 april 2007
\input{problemen} \input{dankwoord} \input{bijlagen} \end{document}
121
Bijlage D
Schema’s
Figuur D.1: Schema van de test A/D-converter schakeling
122
IPROJ1 - Project semester 6, blok 1
18 april 2007
Figuur D.2: Schema van de complete A/D-converter schakeling
123
