Home | Logboek: 9 feb | 16 feb | 23 feb | 1 mrt | 8 mrt | 15 mrt
Logboek
Maandag 23 februari 2004
Dagplanning
Voormiddag:
- Draden ontwarren en labelen
- De bewegende (slechte) rail herbekijken
- Grondplaat herbekijken
- Het bewegen van de pen doen werken
- Bouwteam: huidige code bekijken zodanig dat ze gewend raken met de programmeertaal
(om later eventueel mee te kunnen programmeren)
- Programmeerteam: Nagaan of het programma waar we vorige keer mee geëindigd
waren, werkt
Namiddag:
- De plotter figuren proberen te laten tekenen
- Bouwteam kan mee programmeren (is uiteindelijk niet gebeurd)
- De grootte van een stap van de stappenmotor berekenen en dit nagaan
in de praktijk
Realisaties
- De grondplaat is momentaal verwijderd want die was niet mooi vlak. Daardoor
trok het de hele constructie een beetje scheef. Volgende week zal de plotter
gemonteerd worden op een houten plank.
- Het witte tandwiel is even verplaatst naar het mechanisme
van de pen, maar zorgde daar voor te veel speling. Momenteel is het dus
gewoon zoals ervoor.
- De draden zijn allemaal losgemaakt en vervolgens netjes gebundeld
teruggestoken.
- Het bouwteam heeft het huidige programma gelezen
en de zaken die onduidelijk waren, zijn uitgelegd door het programmeerteam.
- Het programma is verder uitgebreid zodanig dat de plotter een
rechthoek kan tekenen. Er zijn voor een cirkel en lijnstuk al procedures
maar die werken nog niet naar behoren. Eens Cirkel echter werkt, zijn
we ook in staat (dankzij de huidige structuur van de procedure Cirkel)
om veelhoeken te tekenen. Cirkel kan bovendien ook makkelijk uitgebreid
worden naar Ellips en dan hebben we eigenlijk alle basisgeometrische figuren.
- Het op en neer bewegen van de pen zorgde vorige week
nog voor problemen, maar nu werkt dit (op vlak van software) goed.
- Het huidige programma is qua code iets compacter, wat een voordeel
is met de beperkte geheugenruimte van de PowerBrick (32 KB). Dit heeft
wel wat tijd gekost (zie ook verder).
- Claire en Lieselotte zijn reeds begonnen met het
schrijven van het verslag.
Berekening van een stap
1 stap = 7,5° = 0,13 rad
1 Lego-unit = 0,8 cm
- voor een tandwiel met 8 tandjes: straal = 0,5 units
> afstand = 0,065 units
> per stap: 0,052 cm
- voor een tandwiel met 16 tandjes : straal = 1 unit
> afstand = 0,13 units
> per stap: 0,104 cm
- voor een tandwiel met 24 tandjes : straal = 1,5 units
> afstand = 0,195 units
> per stap: 0,156 cm
De afgelegde afstand hangt af van het tandwiel dat we op de motoras bevestigen.
Bij het controleren van de berekeningen met de plotter bleek er een factor 4 verschil te zitten. De reden was snel gevonden: een stap in het programma komt eigenlijk overeen met 4 stappen in de praktijk.
Problemen (al dan niet opgeloste)
- Bij het tekenen van rechthoeken bleek er nogal wat speling op de pen
te zitten, waardoor de hoeken afgerond werden. Ook de pen ging niet voldoende
omhoog bij het teruggaan naar de oorsprong. We hebben dit allemaal opgelost
en rechthoeken tekenen gaat nu vrij vlot.
- Cirkels en lijnen tekenen geeft momenteel nog volgende problemen:
- Met de bekomen resolutie blijkt het moeilijk om schuine lijnen en cirkels mooi te tekenen.
- De berekening punten cirkel is blijkbaar niet helemaal correct
- Bewegen in de vier richtingen zorgt voor een lang stuk code dat moeilijk te vereenvoudigen is
Bekomen inzichten
- Het tekenen van basisfiguren blijkt ingewikkelder dan oorspronkelijk
gedacht. De moeilijkheid zit niet zo zeer in het uitvoeren op zich, maar
om in mooie code een mooi resultaat op papier te zetten.
De rechthoek tekenen is relatief eenvoudig: vraag de gebruiker de begincoördinaten,
breedte en hoogte van de rechthoek. Vervolgens tekenen we de vier zijden
door telkens de juiste assen te laten tekenen.
Een schuine lijn wordt getekend door de twee motoren telkens één
voor één kleine stapjes te laten nemen.
Ook het tekenen van een cirkel hanteert hetzelfde principe, maar daar
veranderen het aantal stapjes gedurende de beweging. Dit geeft echter
nog niet het gewenste resultaat.
- In de huidige opstelling kunnen de lichtsensoren beschadigd geraken bij een eventueel falen van de software. Het is "good practice" om met zoiets rekening te houden en de sensoren zo te plaatsen dat ze geen contact kunnen maken met de opstelling.
To do
- Het programma laten controleren op "out of bound"-fouten
- De lichtsensoren verplaatsen
- Een manier vinden om de bik stevig vast te maken, want momenteel gebruiken
we hier een gewoon stukje kleefband voor.
- De variabelen in het begin van het programma allemaal op nul zetten
(we denken dat hierdoor onverklaarbare onregelmatigheden met PowerBrick
opgelost kunnen worden)
- Verder de basisfiguren uitwerken
Discussies in de groep
Discussies in de groep
Er is een soort van meningsverschil binnen de groep op vlak van programmeerstijl. Thomas wil liever ineens "proper" object-georiënteerd programmeren terwijl Kenny en Jan liever eerst een eventueel "niet-propere" snel werkende code schrijven en daarna de code wat opkuisen. Iedereen is akkoord dat er in de oorspronkelijke code een aantal zaken enorm lastig waren tijdens het programmeren (doordat we de poorten en sensoren locaal definiëren moeten we deze bij elke procedure-aanroep meegeven als parameter).
De eerste dag van het project hadden we dus een stuk niet-propere code die werkt, en die hebben we op dag 1 of 2 herschreven met behulp van klasses. Deze code werkte niet onmiddellijk en we hebben dan in eerste instantie geprobeerd om deze wel te doen werken (naar Thomas zijn zin), een beetje tegen de zin in van Kenny. We zijn nog steeds niet zeker of de gebruikte taal BrickC goed overweg kan met klasses, aangezien we hiermee verscheidene malen op problemen stootten. Thomas geeft wel degelijk toe dat er hierdoor heel wat tijd is verloren, maar is nog steeds overtuigd van het nut van propere code reeds tijdens de ontwikkelfase van een procedure en niet pas nadat ze werkt.
Bij het begin van de derde dag (vandaag) hebben we geprobeerd om de niet-helemaal-propere, werkende code een beetje in te korten op een iets properdere manier (maar zonder objecten/klasses). Ook dit werkte niet onmiddellijk, en daar hebben we alweer een heel klein beetje tijd verloren, maar dit keer heeft Thomas sneller beseft dat zijn methode niet echt efficiënt was gezien de beperkte tijd, en is in hoofdzaak doorgegaan met het werkende programma. Omdat we vandaag echter een laptop bijhadden en omdat Jan ondertussen mee was gaan programmeren heeft Thomas op de laptop getracht om de werkende code toch properder te schrijven. Ditmaal werkte de propere code wel en vervolgens hebben Kenny en Jan verder geprogrammeerd in een gedeeltelijk properder programma. Thomas is dan verder gegaan met het properder maken van de code en tegen het einde van de dag is er een propere werkende code ontstaan, waar iedereen tevreden over is.
Het compromis van (desnoods vuil) programmeren om iets werkend te krijgen en simultaan iemand die de code proper maakt, blijkt vrij goed te werken en is zeker geen bijkomend tijdverlies, aangezien je toch niet met meer dan twee personen op één computer kan werken.