Project: Modulaire Drone Console

In sprint 4 bestuurde je de drone live met het toetsenbord. De vliegclub wil nu ook missies: een vaste reeks opdrachten die de drone zelf afvliegt, bijvoorbeeld een rondje door de zaal met een foto op elke hoek. Een missie gaat pas de lucht in als de console hem gecontroleerd en doorgerekend heeft. Jij bouwt die missiemodus — niet als één lang script, maar als een klein project van modules.

Deel A — De missie

Een missie is een lijst met tekstregels in missions.py. Elke regel is één stap:

Hoofdletters en extra spaties maken niet uit:   FORWARD   100 is hetzelfde als forward 100. Opstijgen en landen staan niet in de missie; dat doet de console zelf.

Deel B — Elke regel controleren

Klopt een regel niet, dan noemt de console het regelnummer en de reden. Hij stopt niet bij de eerste fout: alle foute regels komen in beeld. Een missie met één of meer foute regels vliegt niet. Een lege missie ook niet.

De teksten mag je zelf kiezen, zolang het regelnummer, de waarde en de grens erin staan.

Deel C — Doorrekenen vóór het opstijgen

Is elke regel goed, dan rekent de console de hele missie door zonder te vliegen. Hij houdt bij waar de drone is en welke kant hij op kijkt.

• Het startpunt is (0, 0, 0): x is links–rechts, y is voor–achter, z is de hoogte boven het opstijgpunt. Bij de start wijst de neus naar voren: dat is 0°.
• forward vliegt in de kijkrichting. Na cw 90 kijkt de drone naar rechts, dus gaat forward daarna in de x-richting. back, left en right draaien mee.
• De drone blijft in de zaal: x en y liggen van -300 tot en met 300 cm.
• De hoogte ligt van 0 tot en met 200 cm.
• Komt de drone ergens buiten die grenzen, dan wordt de missie afgekeurd, met het nummer van de eerste stap waar dat gebeurt.

Daarnaast schat de console het accuverbruik:

De missie mag alleen de lucht in als de geschatte accu aan het eind minstens 20% is. Precies 20 mag nog. Vóór het opstijgen print de console: de afstand, het aantal gedraaide graden, het aantal foto's, de eindpositie, het hoogste punt, het geschatte verbruik en de geschatte eindaccu.

Deel D — Vliegen

• In config.py staat SIMULATION. Staat die op True, dan is er geen drone: de startaccu komt uit config.py, opstijgen en landen kosten meteen 10%, en elke stap kost het geschatte verbruik plus SIM_EXTRA_DRAIN. Met die laatste bootst je een accu na die sneller leegloopt dan je berekening.
• Met de echte drone meet je de accu na elke stap. Bij photo sla je het huidige camerabeeld op, met het stapnummer in de bestandsnaam.
• Is de accu na een stap onder de 15% en komen er nog stappen, dan breekt de console af: hij landt en slaat de rest over. Na de laatste stap hoeft er niets afgebroken te worden.
• De drone landt altijd, ook als er iets misgaat.
• Van elke stap komt een regel in het logboek: een lijst met een dictionary per stap. Daarin staan het stapnummer, het commando, de waarde, de status (uitgevoerd of overgeslagen) en de accu na die stap.

Deel E — Het rapport

Na de landing print de console:

• de naam van de missie, en of hij voltooid is of afgebroken na stap …;
• hoeveel stappen er zijn uitgevoerd, van het totaal;
• de afstand, de graden en het aantal foto's van de uitgevoerde stappen;
• de eindpositie, en of de drone boven het startpunt geëindigd is;
• de accu bij de start en aan het eind, en het werkelijke verbruik naast het geschatte — met één cijfer achter de komma.

Deel F — De projectstructuur

• Modules bevatten alleen definities: importeren geeft geen uitvoer.
• Functies die controleren of rekenen, printen niets — ze geven hun uitkomst terug. Alleen main.py en je testbestand printen.
• main.py bevat geen def en draait alles achter if __name__ == "__main__":.
• Er staat nergens global. Wat een functie verandert, komt terug via return — tenzij het een lijst is die de functie bewust vult, en de naam van de functie dat zegt.
• Elke grens en elk verbruik staat één keer, in config.py.

Wat oefen je?

User stories

• Als clublid wil ik een missie als simpele tekstregels schrijven, zodat ik geen Python hoef te kennen om een route te plannen.
• Als clublid wil ik bij een foute regel precies zien welke regel het is en waarom, zodat ik hem zelf kan verbeteren.
• Als veiligheidsverantwoordelijke wil ik dat een missie die buiten de zaal komt, te hoog gaat of te veel accu kost niet opstijgt, zodat er niets tegen de muur of het plafond vliegt.
• Als piloot wil ik dat de drone halverwege landt als de accu sneller leegloopt dan berekend, zodat hij nooit uit de lucht valt.
• Als bestuurslid wil ik na elke missie het geschatte en het werkelijke verbruik zien, zodat we de schatting kunnen verbeteren.
• Als ontwikkelaar wil ik de controles en berekeningen testen zonder drone, zodat ik fouten vind aan mijn bureau in plaats van in de lucht.

Planning maken

Maak een bestand project_plan.md. Beschrijf in welke stappen je dit aanpakt, hoelang je per stap denkt nodig te hebben, waar je problemen verwacht, en welke functies je zonder drone kunt testen. In het tabblad Ontwerpen komt er nog een functietabel bij.

Dit project heeft meer functies dan je tot nu toe in één keer geschreven hebt. Wie meteen begint te typen, zet ze in de verkeerde module of laat ze twee dingen tegelijk doen. Ontwerp daarom eerst op papier.

Je functietabel

Neem deze tabel over in project_plan.md en vul hem in vóór je programmeert. Je mag functies toevoegen of samenvoegen — als elke functie maar één ding doet.

Vijf ontwerpvragen

Schrijf je antwoorden in project_plan.md. Ze bepalen samen hoe je project eruitziet.

1. Richting zonder vier if-ketens. forward, right, back en left zijn allemaal "de kijkrichting plus een aantal graden". Hoe gebruik je dat, zodat je niet vier keer bijna dezelfde code schrijft? Welke tabel (dictionary) hoort daarbij in config.py? Tip: de rest bij delen houdt een hoek tussen 0 en 359 — (270 + 180) % 360 is 90.
2. Wat geeft je controle terug? De aanroeper moet weten óf een regel klopt, waaróm niet, en — als hij klopt — welk commando en welk getal erin staan. Hoeveel waarden zijn dat, en hoe pak je ze uit bij de aanroep?
3. Eén accuformule. Het doorrekenen en de simulatie gebruiken allebei het verbruik per stap. Waar staat die formule, en hoe zorg je dat hij maar op één plek staat?
4. Wie importeert wie? Een module die djitellopy of cv2 importeert, kun je alleen testen als die bibliotheken geïnstalleerd zijn. Welke modules houd je daarom vrij van die imports? Teken de importpijlen tussen je acht bestanden: er mag nergens een pijl heen én terug lopen.
5. Wat bestaat er na de lus? Bij het doorrekenen wil je de eerste stap onthouden waar het misgaat, en het hoogste punt. Welke startwaarde geef je die variabelen, en waar zet je ze: vóór de lus of erin? Denk aan US4 · T3.

Controleer je ontwerp op papier

Neem de missie die onderaan deze pagina al ingevuld staat. Schrijf per stap op wat de positie en de kijkrichting zijn. Vergelijk daarna met het blok onderaan. Doe hetzelfde met back 200, cw 180, forward 250: waar staat de drone na de derde stap?

Bouw eerst alles wat geen drone nodig heeft. Pas in de laatste stap gaat de drone aan. Test na elke stap: met een paar regels in test_mission.py of in de Python-shell.

Startpunt

Meer geeft dit project je niet mee.

# config.py
SIMULATION = True        # True = zonder drone, False = de echte drone
SIM_START_BATTERY = 80   # startaccu in simulatie (%)
SIM_EXTRA_DRAIN = 0      # extra accuverlies per stap in simulatie (%)

Zo ziet het eruit

Afstand      : 400 cm
Gedraaid     : 360°
Foto's       : 0
Eindpositie  : (0, 0, 0)
Hoogste punt : 0 cm
Accu geschat : 30.0% verbruik, eind 50.0%
Goedgekeurd — opstijgen

Missie       : Vierkant
Status       : voltooid
Stappen      : 8 van 8 uitgevoerd
Afstand      : 400 cm, gedraaid 360°, foto's 0
Eindpositie  : (0, 0, 0) — boven startpunt: ja
Accu         : 80% → 50.0% (verbruikt 30.0%, geschat 30.0%)

De opmaak mag je zelf bepalen, zolang alles uit deel C en deel E erin staat.

Maak een bestand test_report.md; alles op dit tabblad komt daarin te staan.

1. Je testbestand

Dit keer test je niet alleen met de hand. Je schrijft test_mission.py: een bestand dat je functies aanroept en de uitkomst vergelijkt met wat je verwacht. Daar heb je geen nieuwe techniek voor nodig. Schrijf één eigen hulpfunctie die een naam, een uitkomst en een verwachting krijgt, laat zien of het klopt, en die meetelt hoeveel tests er slaagden.

• Het bestand draait met python test_mission.py, zonder drone en zonder dat djitellopy of cv2 geïmporteerd wordt.
• Er staan minstens 15 checks in.
• Elke grens wordt van beide kanten getest: 19 en 20 cm, 500 en 501 cm, 45 en 90 graden, 300 en 301 cm in de zaal, 200 en 201 cm hoogte, 19 en 20% eindaccu.
• De kijkrichting wordt getest na cw én na ccw, ook als hij "rond" gaat (270 + 180).
• Minstens één check kijkt naar een melding: staat het regelnummer erin?
• Een mislukte test zegt wat er verwacht werd en wat eruit kwam. Aan het eind staat een regel als 15 van 15 tests geslaagd.

2. De vaste testgevallen

Draai deze tien missies in simulatie en vul de laatste kolom in. "Vierkant" is vier keer forward 100 en cw 90.

3. Vijf eigen testgevallen

Bedenk er vijf missies bij en zet ze in dezelfde tabelvorm in je verslag. Eisen:

• Eén missie eindigt precies op de muur (300 cm), één net erover.
• Eén missie begint met ccw 90 en vliegt dan vooruit: klopt het teken van x?
• Eén missie komt via draaien terug boven het startpunt, en maakt onderweg minstens twee foto's.
• Eén missie laat de accu pas bij de laatste stap onder de 15% zakken. Breekt je console dan af?
• Schrijf bij elk geval één zin: waarom is dit geval de moeite waard?

Controleer je verwachting met het blok onderaan deze pagina, vóór je naar je eigen uitvoer kijkt.

4. Sloop je eigen code — vangen je tests het?

Maak een kopie van je werkende project en bouw deze vijf fouten in, één tegelijk. Draai bij elke fout je testbestand én de tien vaste testgevallen opnieuw.

Noteer per fout: welke vaste gevallen falen, welke checks in je testbestand falen, en of het script crasht of stil een fout antwoord geeft.

5. Vliegen met de echte drone

Zet SIMULATION op False en vlieg, met minstens twee meter vrije ruimte rondom en een volle accu. Vlieg T1 en één eigen missie met minstens twee foto's. Noteer in je verslag:

• het geschatte en het gemeten verbruik, en hoeveel ze verschillen;
• of de drone echt boven het startpunt eindigde, en zo niet, hoe ver ernaast;
• wat je aan de verbruikscijfers in config.py zou veranderen, en waarom.

Kies één uitbreiding. Elke optie laat merken wat je modules waard zijn: als je ontwerp goed is, hoef je niets te kopiëren.

Optie A — Terug naar huis

Voeg een commando home toe. De console rekent uit hoe de drone vanaf zijn huidige positie en kijkrichting terugkomt boven het startpunt, en voegt die stappen zelf aan de missie toe. Gebruik je bestaande functies voor draaien, bewegen en controleren.

• Na home eindigt de doorrekening op x = 0 en y = 0, vanaf elke positie en elke kijkrichting
• De toegevoegde stappen worden net zo gecontroleerd als gewone stappen (afstand 20–500)
• Er staan minstens vier checks voor home in je testbestand

Optie B — Missie en live besturing in één console

Koppel je live console uit sprint 4 aan dit project. Met een toets start de piloot een missie uit missions.py; daarna neemt de piloot het weer over met het toetsenbord.

• De live besturing gebruikt dezelfde functies voor positie en logboek als de missiemodus
• Na een missie klopt de positie nog als de piloot daarna handmatig verder vliegt
• In je verslag staat welke code uit sprint 4 je kon hergebruiken en welke je moest ombouwen

Optie C — De schatting verbeteren

Vlieg drie verschillende missies en schrijf per stap het gemeten verbruik op. Pas daarna de verbruikscijfers in config.py aan en laat zien dat de schatting beter wordt.

• In je verslag staat per missie het geschatte verbruik vóór en ná je aanpassing, naast het gemeten verbruik
• Je hebt alleen config.py aangepast — geen enkele andere module
• Je legt uit waarom een schatting nooit precies klopt