S2 · Project: Veilige takeoff

Wat ga je maken?

±25 min

Een vliegclub laat leden zelf met de drone vliegen. Dat gaat af en toe mis: iemand stijgt op met een bijna lege accu, of geeft een afstand op waar de accu niet voor reikt. Jij schrijft het programma dat daartussen gaat zitten. Het bestand heet safe_takeoff.py en bestaat uit vier delen.

Deel A — Missieplan invoeren

Het script vraagt de piloot om drie dingen en controleert die meteen:

Zijn naam. Een lege naam is niet goed genoeg — dan weten we later niet wie er gevlogen heeft.
De afstand in centimeters die hij vooruit wil vliegen. Dat moet een geheel getal zijn van minimaal 20 en maximaal 500.
Een bevestiging. Alleen bij yes gaat de vlucht door. Of de piloot nu yes, YES of Yes typt, maakt niet uit.

Deel B — Meten

Het script leest vijf sensoren uit: de batterij, de hoogte, de temperatuur, de sterkte van het wifi-signaal en de vliegtijd die al op deze accu staat. Bij een slechte verbinding kan zo'n uitlezing mislukken; de waarde is dan None in plaats van een getal. Daar moet je script tegen kunnen.

Je wilt niet voor elke test een accu leegvliegen. Daarom bouw je een simulatiemodus: één constante bovenaan bepaalt of de waarden van de echte drone komen of uit testconstanten in je eigen bestand.

Deel C — Veiligheidschecks

De club heeft deze regels opgeschreven. Ze staan er bewust in gewone taal — welke vergelijking daarbij hoort, bepaal jij.

Check	De regel van de club
Meting	Is één van de vijf metingen mislukt, dan gaat de vlucht niet door. Een mislukte meting is geen 0 — het is helemaal geen waarde.
Batterij	Een batterij van 20% of minder is te weinig. Precies 20 mag dus niet meer vliegen.
Hoogte	De drone moet op de grond staan. Tot en met 5 cm rekenen we als "op de grond"; hoger betekent dat hij al hangt.
Temperatuur	Vanaf 60 °C is de drone te warm. Precies 60 is al te warm.
Wifi	Het signaal moet minstens 70 zijn. Daaronder is de verbinding te wankel.
Vliegtijd	Er mag niet meer dan 300 seconden op deze accu staan. Precies 300 mag nog net.
Warm én bijna leeg	Een drone van 45 °C of warmer die tegelijk 35% batterij of minder heeft, mag niet vliegen — ook niet als hij elke losse grens hierboven net haalt.

Let op die laatste regel. Die kijkt naar twee metingen tegelijk. Een drone met 50 °C en 30% batterij komt door alle checks erboven heen, en moet tóch geweigerd worden.

Deel D — Vliegmodus en opstijgen

Hoe voller de accu, hoe verder de drone mag. De batterijstand bepaalt de modus:

Batterij	Modus	Maximale afstand
tot en met 35%	ECO	100 cm
meer dan 35% tot en met 70%	NORMAL	300 cm
meer dan 70%	FULL	500 cm

Vraagt de piloot een grotere afstand dan de modus toestaat, dan gaat de vlucht niet door. Daarna print het script een checklist met een ✓ of ✗ per check, en pas dán stijgt de drone op, vliegt hij de gevraagde afstand vooruit, landt en sluit de verbinding.

User stories

Als piloot wil ik mijn vlucht vooraf opgeven en bevestigen, zodat de drone nooit per ongeluk opstijgt.
Als piloot wil ik meteen horen als mijn invoer niet klopt, zodat ik die kan verbeteren in plaats van te raden.
Als piloot wil ik dat het script alle veiligheidschecks zelf doet, zodat ik geen kritieke waarde over het hoofd zie.
Als piloot wil ik in de foutmelding de gemeten waarde én de grens zien, zodat ik weet hoe ver ik ernaast zit.
Als piloot wil ik dat de toegestane afstand meegroeit met mijn accu, zodat ik niet halverwege zonder stroom val.
Als onderhoudsmonteur wil ik na afloop kunnen zien welke check de vlucht tegenhield, zodat ik weet welk onderdeel aandacht nodig heeft.

Planning maken

Maak een bestand project_plan.md met je planning. Beschrijf:

In welke stappen je dit project aanpakt, en in welke volgorde.
Hoe lang je per stap denkt nodig te hebben.
Waar je problemen verwacht, en wat je dan doet.
Welke bibliotheek en welke methoden je nodig hebt.

Dit bestand lever je in samen met je script. In het tabblad Ontwerpen komt er nog een onderdeel bij.

Structuur uitdenken

±35 min

Nog niet typen. Eerst bepaal je de structuur. Kies je de volgorde verkeerd, dan moet je halverwege alles omgooien.

De vier zones

Constanten — elke grens uit de opdracht krijgt een naam in UPPER_CASE. Verderop in je code staat geen los getal meer.
Invoer en meting — eerst vragen wat de piloot wil, dan meten wat de drone doet.
Guards — alle checks plat achter elkaar op niveau 0.
Happy path — checklist, opstijgen, vliegen, landen, afsluiten. Ongenest, onderaan.

Je ontwerptabel

Neem deze tabel over in project_plan.md en vul hem helemaal in voordat je gaat programmeren. Dit is het denkwerk van dit project; daarna typ je je eigen ontwerp over in Python.

#	Check	Wat meet of lees je?	Grens (constante)	Foutconditie	Melding
1	Naam ingevuld	…	…	…	…
2	Afstand is een getal	…	…	…	…
3	Afstand binnen bereik	…	…	…	…
4	Bevestiging	…	…	…	…
5	Meting gelukt	…	…	…	…
6	Batterij	…	…	…	…
7	Hoogte	…	…	…	…
8	Temperatuur	…	…	…	…
9	Wifi	…	…	…	…
10	Vliegtijd	…	…	…	…
11	Warm én bijna leeg	…	…	…	…
12	Afstand past bij de modus	…	…	…	…

De kolom "Foutconditie" is de moeilijkste. In de opdracht staat wanneer iets goed is. Een guard vraagt het omgekeerde: wanneer is het fout? Let op waar de grens zelf bij hoort. "20% of minder is te weinig" en "minder dan 20% is te weinig" leveren verschillende code op, en maar één ervan klopt.

Vier ontwerpvragen

Beantwoord ze kort in project_plan.md. Ze gaan allemaal over volgorde, en daar worden de meeste fouten in gemaakt.

Waarom moet de check op een mislukte meting vóór de batterijcheck staan? Wat gebeurt er als je ze omdraait?
Waarom kan de check "afstand past bij de modus" pas ná het bepalen van de modus?
Waarom controleer je de invoer van de piloot voordat je de drone uitleest, en niet andersom?
Je hebt een check op de temperatuur én een check op "warm én bijna leeg". Welke van de twee zet je eerst, en wat is je argument?

Controleer je ontwerp op papier

Loop deze drie situaties na met je ingevulde tabel in de hand:

Alles goed: is de happy path volgens je tabel dan bereikbaar?
Alles fout: stopt het script dan bij de eerste check, en niet pas bij de laatste?
Batterij 30%, temperatuur 50 °C, verder alles goed: welke check vangt dit? Staat die in je tabel op de juiste plek?

Bouwen: stap voor stap

±100 min

Werk in zes stappen. Draai na elke stap je script en controleer het resultaat, zodat je altijd weet welke wijziging iets stukmaakte.

Stap 1 — Constanten en simulatiemodus 15 min

Zet elke grens uit de opdracht bovenaan als constante in UPPER_CASE. Voeg een constante toe die aangeeft of je in simulatiemodus werkt, plus vijf testconstanten voor de sensorwaarden.

Test: print al je constanten en controleer of elke grens uit de opdracht er precies één keer in staat.

Stap 2 — Het missieplan uitvragen 20 min

Vraag naam, afstand en bevestiging. Onthoud uit US1 · T2: input() geeft altijd een string terug. Vergelijk dus pas nadat je hebt omgezet naar het juiste type — anders vergelijk je tekst met tekst en krijg je stilletjes het verkeerde antwoord.

Test: typ 85 en daarna 9 als afstand. Vindt je programma dat 9 groter is dan 85, dan vergelijk je nog steeds strings.

Stap 3 — De invoer-guards 15 min

Schrijf de guards voor de naam, de afstand en de bevestiging. Voor "is dit wel een getal" bestaat de string-methode .isdigit(): die geeft True als er alleen cijfers in de tekst staan. Voor het bereik gebruik je één chained comparison.

Test: een lege naam, abc als afstand, 19, 501, en nee als bevestiging. Alle vijf moeten netjes stoppen; geen enkele mag crashen.

Stap 4 — Meten, echt of gesimuleerd 15 min

Lees de vijf sensoren uit. Staat de simulatiemodus aan, dan komen de waarden uit je testconstanten; staat hij uit, dan uit de drone. Schrijf daarna de guard op een mislukte meting. Let op: die waarde is None, en None controleer je niet met ==.

Test: zet één testconstante op None en draai. Zet hem daarna op 0. Die twee moeten zich verschillend gedragen — een hoogte van 0 is een prima meting, een hoogte van None is een mislukte meting.

Hier loop je tegen een ontwerpprobleem aan. Je guards sluiten straks de verbinding af voordat ze stoppen. Maar in simulatiemodus heb je nooit verbinding gemaakt — bestaat je drone-object dan wel? Los dit op zonder je guards te nesten en zonder in elke guard een extra if te zetten. Denk hierover na: een object aanmaken en er verbinding mee maken zijn twee losse regels, en ze hoeven niet allebei op hetzelfde moment te gebeuren. Schrijf je keuze op in project_plan.md.

Stap 5 — De sensor-guards 20 min

Schrijf de guards voor batterij, hoogte, temperatuur, wifi en vliegtijd, plus de samengestelde check op warm én bijna leeg. Allemaal plat op niveau 0, in de volgorde uit je ontwerptabel. Elke guard sluit de verbinding netjes af voordat hij stopt.

Test: zet je testconstanten zo dat precies één guard afgaat, en doe dat voor elke guard apart. Zes runs, zes verschillende meldingen.

Stap 6 — Modus, checklist en happy path 15 min

Bepaal met één if/elif/else-keten de modus en de bijbehorende maximale afstand, en voeg de laatste guard toe. Print dan de checklist met ✓ en ✗ — gebruik daarvoor de ternary uit US2 · T3 — en zet de happy path eronder, op niveau 0, zonder else.

Test: batterij 35 en 36, en batterij 70 en 71. Dat zijn de randen tussen de modi; controleer of de juiste modus eruit komt.

Krijg je een UnicodeEncodeError? Dan kan je terminal de tekens ✓ en ✗ niet weergeven. Dat is geen fout in je code. Kies dan zelf twee andere tekens die wel werken, bijvoorbeeld [OK] en [--]. De ternary blijft hetzelfde; alleen de twee tekens veranderen.

Startpunt

Meer geeft dit project je niet mee. De constanten, de guards en de volgorde komen uit je eigen ontwerptabel.

from djitellopy import Tello

SIMULATION = True     # True = testwaarden gebruiken, False = de echte drone

Richtlijn voor foutmeldingen

Elke guard print een melding met drie dingen erin: wat er mis is, de gemeten waarde, en de grens. Zo ziet zo'n melding eruit:

Batterij te laag: 18% (grens: meer dan 20%) — vlucht geannuleerd.

Gebruik f-strings met de echte waarden erin. Een melding als "Er is iets mis" is niet goed genoeg: daar kan de piloot niets mee.

Zo ziet een geslaagde run eruit

Naam piloot: Sam
Afstand in cm: 200
Bevestigen met yes: YES

========================================
  PRE-FLIGHT CHECK  ·  piloot: Sam
========================================
  ✓ Meting      : alle vijf de sensoren gelezen
  ✓ Batterij    : 82 %   (grens: meer dan 20)
  ✓ Hoogte      : 0 cm   (grens: 5 of lager)
  ✓ Temperatuur : 34 °C  (grens: onder 60)
  ✓ Wifi        : 90     (grens: 70 of hoger)
  ✓ Vliegtijd   : 12 s   (grens: 300 of lager)
----------------------------------------
  Vliegmodus    : FULL   (maximaal 500 cm)
  Gevraagd      : 200 cm
========================================
  STATUS        : GO — opstijgen
========================================

De opmaak mag je zelf bepalen, zolang alle checks, de modus, de gevraagde afstand en de status erin staan.

Tello APISprint 2 · Project

Methode	Wat het doet	Geeft terug
tello.connect()	Verbindt via wifi (altijd eerst)	None
tello.get_battery()	Batterijpercentage	int (0–100)
tello.get_height()	Hoogte boven de grond	int (cm)
tello.get_temperature()	Temperatuur van de drone	int (°C)
tello.get_wifi()	Sterkte van het wifi-signaal	int
tello.get_flight_time()	Vliegtijd op deze accu	int (s)
tello.takeoff()	Stijgt op	None
tello.move_forward(x)	Vliegt x cm vooruit	None
tello.land()	Landt	None
tello.end()	Sluit de verbinding (altijd als laatste)	None

Bouw op, gooi niet om. Voeg per stap één ding toe en draai daarna meteen je script. Schrijf je alle zes de stappen in één keer uit en krijg je dan een fout, dan weet je niet meer welke stap hem veroorzaakte.

Testen & testverslag

±55 min

Je script werkt pas als je het hebt geprobeerd te breken. Maak een bestand test_report.md; alles op dit tabblad komt daarin te staan.

Testen op de grens

De meeste fouten in dit soort code zitten niet in het midden, maar precies op de grens. Bij een grens van 20% test je daarom drie waarden:

net eronder — 19: hier hoort de guard zeker af te gaan;
precies erop — 20: hier zit de twijfel, en hier zit meestal de fout;
net erboven — 21: hier hoort de guard zeker níét af te gaan.

Test je alleen 5 en 80, dan lijkt je code te werken terwijl je < en <= door elkaar kunt hebben gehaald. Dat verschil merk je alleen op de grens.

1. De vaste testgevallen

Draai deze acht gevallen met je simulatiemodus aan. Vul de laatste kolom in met wat jouw script werkelijk deed. Naam en bevestiging zijn bij alle acht goed ingevuld.

#	afstand	battery	height	temp	wifi	Verwacht	Werkelijk
T1	100	80	0	30	90	Gaat door, modus FULL	invullen…
T2	100	20	0	30	90	Stopt bij de batterijcheck	invullen…
T3	50	21	0	30	90	Gaat door, modus ECO	invullen…
T4	100	80	10	30	90	Stopt bij de hoogtecheck	invullen…
T5	100	80	0	60	90	Stopt bij de temperatuurcheck	invullen…
T6	100	80	0	30	69	Stopt bij de wificheck	invullen…
T7	50	30	0	50	90	Stopt bij "warm én bijna leeg"	invullen…
T8	400	60	0	30	90	Stopt bij de afstandscheck (modus NORMAL)	invullen…

T7 is de interessantste. Batterij 30 is genoeg, 50 °C is niet te warm, en verder klopt alles. Toch hoort deze vlucht niet door te gaan. Gaat hij bij jou wél door, dan mist je samengestelde check.

2. Zes eigen testgevallen

Bedenk er zelf zes bij en zet ze in dezelfde tabelvorm in je testverslag. Eisen:

Minstens drie zijn grenswaardetests: kies een grens en test hem op alle drie de manieren hierboven.
Minstens één test de overgang tussen twee vliegmodi.
Minstens één test wat er gebeurt bij invoer die geen getal is.
Schrijf bij elk geval één zin: waarom is dit geval de moeite waard om te testen?

Gebruik het blok "Wat hoort eruit te komen?" onderaan deze pagina om te bepalen wat het antwoord hoort te zijn, vóórdat je naar je eigen uitvoer kijkt.

3. Sloop je eigen script — vangen je tests het?

Je hebt nu veertien testgevallen. Maar hoe wéét je dat die goed genoeg zijn? Door er een fout in te stoppen en te kijken of je tests hem betrappen. Dat doe je zo: maak eerst een kopie van je werkende script, want die zet je straks weer terug.

Bouw daarna deze vijf fouten in, één tegelijk. Bij elke fout draai je al je testgevallen opnieuw en noteer je welke er op stuk gaan.

#	Wat je kapotmaakt
1	Haal bij de afstand het omzetten naar een getal weg, zodat je weer tekst met tekst vergelijkt.
2	Draai bij één guard het vergelijkingsteken om: maak van "of minder" ineens "minder dan", of andersom.
3	Controleer een mislukte meting niet meer op "is er geen waarde", maar op "is de waarde leeg of nul".
4	Verwissel twee guards van plaats, zodat een check afgaat op iets dat nog niet bepaald is.
5	Zet de happy path in een `else` onder de laatste guard, in plaats van eronder op niveau 0.

Noteer per fout drie dingen in test_report.md:

Welke testgevallen faalden? Noem de nummers. Faalde er géén, dan is dat het belangrijkste resultaat van deze opdracht.
Hoe merkte je het? Crashte het script, of gaf het rustig een verkeerd antwoord?
Welk testgeval vangt hem het duidelijkst? Bestaat dat nog niet, bedenk het dan en voeg het toe aan je tabel.

Zet daarna je kopie terug en controleer dat alle testgevallen weer slagen.

Twee van de vijf zijn stille fouten. Het script crasht er niet op en geeft geen foutmelding — het geeft gewoon het verkeerde antwoord. Welke twee dat zijn, merk je vanzelf: dat zijn de fouten waar je met alleen 5 en 80 als testwaarde overheen kijkt. Schrijf in je verslag op welke twee het waren en waarom ze stil bleven.

4. Testen met de echte drone

Zet tot slot de simulatiemodus uit en draai je script met de drone aan, op een vrije plek met minstens twee meter ruimte vooruit. Noteer in je testverslag wat er gebeurde, en of dat overeenkwam met wat je simulatie voorspelde.

Eén verschil om op te letten. In simulatiemodus blijven je waarden staan. Bij de echte drone loopt de batterij tijdens het vliegen leeg. Draai je twee keer achter elkaar, dan kan de tweede run in een andere vliegmodus uitkomen dan de eerste. Dat is geen fout — noteer het.

Wat lever je in?

±15 min

Loop eerst alle criteria langs. Voldoet alles, push dan naar GitHub en stuur de link naar je docent.

📁 Bestanden in je repo

safe_takeoff.py — het hoofdscript
project_plan.md — planning, ingevulde ontwerptabel, de vier ontwerpvragen en de reflectie
test_report.md — de twee testtabellen en het verslag van de vijf ingebouwde fouten
requirements.txt — gegenereerd met pip freeze
.gitignore — bevat minimaal .venv/

Acceptatiecriteria

Deel A · invoer

Het script vraagt naam, afstand en bevestiging via input().
De afstand wordt omgezet naar een getal vóór de eerste vergelijking.
Een lege naam, een afstand die geen getal is, een afstand buiten 20–500 en een bevestiging die geen yes is, worden alle vier afgevangen — zonder crash.
YES, Yes en yes worden alle drie geaccepteerd.
Het bereik van de afstand is met één chained comparison gecontroleerd.

Deel B · meten

Er is een constante die de simulatiemodus aan- en uitzet; met die ene regel schakel je tussen testwaarden en de echte drone.
Alle vijf de sensoren worden uitgelezen.
Een mislukte meting wordt herkend met is None, niet met ==, en een waarde van 0 wordt níét als mislukt gezien.

Deel C · guards

Elke grens uit de opdracht staat als UPPER_CASE-constante bovenaan; nergens verderop staat een los getal.
Alle guards staan plat op niveau 0, achter elkaar — geen geneste if-boom.
Elke foutmelding is een f-string met de gemeten waarde én de grens erin.
Elke guard sluit de verbinding af voordat hij stopt met exit(), en dat werkt ook met de simulatiemodus aan.
De samengestelde check werkt: een drone met 50 °C en 30% batterij wordt geweigerd.

Deel D · modus en happy path

De modus wordt bepaald met één if/elif/else-keten, niet met losse if's.
De grenzen tussen de modi kloppen: 35 is ECO en 36 is NORMAL, 70 is NORMAL en 71 is FULL.
De checklist toont per check een ✓ of ✗, gemaakt met een ternary.
De happy path staat ongenest onderaan op niveau 0, zonder else.

Testen

Alle acht vaste testgevallen geven de verwachte uitkomst; de kolom "Werkelijk" is ingevuld.
Er staan zes eigen testgevallen in het verslag, waarvan minstens drie grenswaardetests, elk met een verantwoording.
Alle vijf de ingebouwde fouten zijn uitgevoerd en beschreven: welke testgevallen faalden, en welke twee fouten stil bleven.
Voor elke ingebouwde fout die geen enkel testgeval betrapte, is er een testgeval bij bedacht.
Na het terugzetten van de kopie slagen alle testgevallen weer.
Er staat een verslag van één run met de echte drone in test_report.md.

Reflectie — drie vragen

Beantwoord ze kort onderaan je project_plan.md:

Welke grens heb je tijdens het testen moeten bijstellen omdat je < en <= door elkaar had? Hoe merkte je dat?
Je hebt nu twaalf checks plat achter elkaar. Wat zou er gebeurd zijn als je ze genest had opgeschreven, zoals in US4 · T1?
Stel dat de club er morgen een regel bij verzint. Wat moet je dan aanpassen in je script, en op hoeveel plekken?

Extra — alleen als je klaar bent

±30 min

Breek elkaars script

Echte gebruikers typen niet netjes. Ze zetten een spatie voor hun antwoord, gebruiken hoofdletters, drukken per ongeluk op Enter, of typen een min voor het getal. Jouw script hoort daar niet op te crashen.

Deel 1 — maak je eigen script bestand

Probeer deze invoer zelf uit. Zorg dat er niets crasht en dat er altijd een duidelijke melding komt:

Een spatie voor of achter de afstand of de bevestiging.
YES met een spatie erachter.
Een negatieve afstand, bijvoorbeeld -50.
Een afstand met een komma of punt erin, bijvoorbeeld 1,5 of 2.5.
Enter drukken zonder iets te typen, bij elk van de drie vragen.

Denk goed na over dat negatieve getal: waarom ziet .isdigit() -50 niet als een geldig getal, en is dat hier handig of juist verwarrend?

Deel 2 — ruilen met een klasgenoot

Geef je script aan iemand anders en krijg dat van hem of haar terug. Probeer een kwartier lang dat script onderuit te halen met rare invoer. Noteer elke invoer die een crash of een verkeerde uitkomst geeft.

Zet in je eigen test_report.md twee lijstjes: wat jij bij een ander vond, en wat een ander bij jou vond. Repareer daarna wat er bij jou gevonden is.

Acceptatiecriteria

Geen enkele van de vijf invoersituaties uit deel 1 laat het script crashen.
Spaties rondom de invoer worden weggehaald voordat er iets mee vergeleken wordt.
In je testverslag staan beide lijstjes: jouw bevindingen bij een ander, en die van een ander bij jou.
Alles wat een ander bij jou vond, is gerepareerd, of je legt uit waarom je het laat staan.

Nieuwe techniek nodig? Twee kleine string-methodes: .isdigit() om te controleren of er alleen cijfers in staan, en .strip() om spaties rondom weg te halen. De rest — guards, f-strings, ternary, chained comparison, is None — ken je uit sprint 1 en 2.