Werkwijzen

Het werken met hardware als Arduino, en in minder mate Micro:bit en Lego Mindstorms is foutgevoelig. Het is daarom belangrijk om gestructureerd te werken. Het is echter niet eenvoudig om dat soort vaardigheden in lesmateriaal te vervatten. De docent kan de leerlingen hierin coachen. Het gaat onder meer om:

Over modelleren

Voordat de leerlingen een programma implementeren maken ze eerst een model van de werking van het systeem met behulp van toestandsdiagrammen. Aan de hand van het toestandsdiagram kunnen ze redeneren over de correctheid van het programma. Hierdoor kunnen ze fouten in vroeg stadium herkennen en verbeteren. Het omzetten van een toestandsdiagram naar een programma is relatief recht-toe-recht-aan. Door te werken met toestandsdiagrammen worden veel fouten voorkomen en zullen de leerlingen efficiënter werken. In praktijk zullen leerlingen vaak echter geneigd zijn om gelijk te gaan programmeren. De docent heeft een rol om de leerlingen te stimuleren eerst het model te maken alvorens te gaan programmeren.

Het maken van een toestandsdiagram is niet altijd makkelijk. Er is geen standaard route of algoritme voor het maken zo’n toestandsdiagram. Leerlingen vinden het lastig om te bepalen wat de toestanden zijn. Daarnaast maken ze soms toestandsdiagrammen die niet helemaal aan de regels voldoen. Die regels zijn op zich niet moeilijk, leerlingen zouden redelijk snel in staat moeten zijn om te bepalen of hun eigen toestandsdiagram voldoet aan de regels.

Op basis van een toestandsdiagram kun je redeneren over de werking van een systeem. Wat gebeurt er als ….? Dat kan bijvoorbeeld klassikaal, door een toestandsdiagram te laten zien (bijvoorbeeld een uitwerking van een leerling) en hierover een gesprek te voeren. 

 

Over ontwerpen

Idealiter krijgen de leerlingen de opdracht om een bepaald probleem op te lossen en daarbij zelf een oplossing te ontwerpen en een prototype te ontwikkelen. Het probleem is gegeven, de oplossing niet. Vaak echter wordt bij dit soort opdrachten (een deel van) de oplossing al gegeven. Bijvoorbeeld: bouw een auto die een lijn volgt op basis van lichtsensor. Beter zou zijn: bouw een voertuig dat automatisch naar een bepaalde plek kan rijden. Er zijn dan meerdere oplossingen mogelijk om dit probleem aan te pakken. Leerlingen kunnen deze oplossingen verkennen en vergelijken. In schoolpraktijk is dat echter vaak lastiger. De beschikbare materialen en hardware, de tijd en de expertise zijn beperkt. Het aantal haalbare oplossingsrichtingen wordt daardoor ook gelimiteerd. Daarnaast is het voor deze module belangrijk dat de oplossing wordt gezocht in de hoek van physical computing, terwijl het natuurlijk soms ook mogelijk is om oplossingen zonder physical computing te realiseren. Kijk bijvoorbeeld naar de NLT-module Technisch Ontwerpen in de Biomedische Wetenschap, waarbij leerlingen een oplossing moeten vinden voor mensen met een beperking. Hoe kan iemand die niet kan zien voorkomen dat het kopje overloopt bij het inschenken van de koffie? Daar zijn verschillende oplossingen voor te bedenken, zowel met als zonder physical computing.

 

Een ander aspect is dat leerlingen geneigd zijn om voor de eerste-de-beste oplossing te gaan zonder eerst de mogelijkheden te verkennen. Ze moeten echter leren meerdere oplossingsrichtingen te onderzoeken voordat ze een keuze maken. Dit divergeren is een belangrijke vaardigheid.

Belangrijk in het ontwerpproces is dat ze hun keuze onderbouwen. Waarom wordt voor de ene oplossingsrichting gekozen ten nadele van een andere oplossingsrichting? Specifiek voor deze module is de keuze voor bepaalde sensoren en actuatoren. Waarom wordt voor het ene type sensor gekozen? Dan is kennis over de eigenschappen van de sensor belangrijk.

Overigens hebben leerlingen vaak geen goed beeld van wat de mogelijkheden zijn. Daarom laten we de leerlingen veel voorbeelden zien van systemen/prototypen die ze in principe zelf ook kunnen maken.