Projektbasiertes Lernen mit Arduino: 4-wöchige Beispieleinheit

Projektbasiertes Lernen mit Arduino ist eine Unterrichtseinheit, in der die Schülerinnen und Schüler den Stoff nicht nach einem Lehrervortrag lernen, sondern während sie versuchen, ein echtes Problem zu lösen. Der Ablauf hat fünf Phasen: Du stellst eine Leitfrage, die Teams recherchieren das Problem und entscheiden, was sie messen, sie bauen mit Arduino einen Prototyp, sie testen und verbessern ihn im Schulhaus und präsentieren zum Schluss ihre Ergebnisse vor echtem Publikum. Die Leitfrage der Beispieleinheit in diesem Beitrag lautet: "Wie können wir an unserer Schule ein Problem mit Energie, Wasser, Lärm oder Raumluft messen und davor warnen?" In vier Wochen wählt jedes Team eines dieser Probleme, misst es mit einem Sensor, baut ein funktionierendes Gerät, das beim Überschreiten eines Schwellenwerts warnt, und macht der Schule mit den gesammelten Daten einen Vorschlag.

Unten findest du alles, was du morgen in den Unterricht mitnehmen kannst: einen Wochenplan der Einheit, den Ablauf Stunde für Stunde mit Abschlussfragen, vier Problemszenarien mit Startprojekten in BlueGrays, eine Materialliste, Teamvertrag und Rollen, die Prototyp-Schleife mit Vorlage für das Testprotokoll, Kriterien für Zwischenkontrolle und Abschlusspräsentation, typische PBL-Fallen und eine Checkliste. Alle Beispiele gehen von derselben Annahme aus: Sagen wir, du hast eine Klasse mit 24 Schülerinnen und Schülern, zwei Unterrichtsstunden pro Woche (2 × 40 Minuten) und sechs Teams zu je vier Personen. Suchst du einen Plan, der Fähigkeiten der Reihe nach aufbaut, passt der 8-Wochen-Plan für Robotik und Programmierung besser, für ein kurzes, intensives Programm der 5-tägige Arduino-Workshop. Diese Einheit funktioniert am besten danach, wenn die Klasse schon eine LED zum Leuchten gebracht und einen Sensor ausgelesen hat.

Was ist projektbasiertes Lernen und was unterscheidet es von einer Projektaufgabe?

Im klassischen Ablauf wird zuerst der Stoff erklärt und danach ein Projekt vergeben, mit dem die Klasse zeigt, was sie gelernt hat; das Projekt ist der Nachtisch, nicht die Mahlzeit. Beim projektbasierten Lernen dreht sich die Reihenfolge um: Das Projekt ist der Unterricht. Die Schülerinnen und Schüler lernen analogRead(), Schwellenwerte oder Mittelwertbildung genau in dem Moment, in dem sie sie zur Lösung brauchen. Arduino passt gut dazu, weil es die reale Welt in Zahlen verwandelt: Ein LDR misst das Licht im Flur, ein Schallsensor den Lärm in der Mensa, ein DHT11 die Temperatur im Klassenzimmer. Prototypen sind billig und in Minuten geändert; ist ein Schwellenwert falsch, änderst du eine Zahl im Code und lädst neu hoch. So passt die Schleife "ausprobieren, messen, verbessern", das Herz von PBL, in eine einzige Unterrichtsstunde. Die Tabelle fasst den Unterschied zusammen:

Die Leitfrage: ein Satz, der die ganze Einheit trägt

Die Leitfrage hängt vier Wochen lang im Klassenzimmer, und jede Stunde knüpft an sie an: "Wie sind wir dem heute nähergekommen?" In dieser Einheit ist die gemeinsame Frage absichtlich weit gefasst, damit sich jedes Team ein eigenes Stück herausnehmen kann: "Wie können wir an unserer Schule ein Problem mit Energie, Wasser, Lärm oder Raumluft messen und davor warnen?" Aufgabe der ersten Woche ist es, diese weite Frage auf die eigene Teilfrage des Teams einzugrenzen. "Energieverschwendung an der Schule" ist keine Teilfrage; "Wie viele Minuten bleibt in der leeren 7b während der Pause das Licht an, und wen warnen wir wie?" ist eine. Die Antwort auf eine gute Teilfrage beginnt mit einer Zahl und endet mit einem Gerät. Bevor du die Teilfrage eines Teams freigibst, prüfe sie an diesen sechs Kriterien:

• Echt: Jemand an der Schule hat dieses Problem wirklich, und das Team kann sagen, wer: die Aufsicht, das Schulpersonal, das Mensapersonal oder die Klassensprecherin.
• Messbar: Ein vorhandener Sensor macht das Problem zu einer Zahl: Licht, Lautstärke, Bodenfeuchte, Temperatur oder Abstand.
• Lokal und eng: Es gibt einen Ort und ein Zeitfenster; nicht "die Schule", sondern "Flur im 2. Stock, Mittagspause".
• Offen: Die Antwort ist nicht ja oder nein; die Frage fragt "wie", "wann" oder "wie viel".
• Passt in 4 Wochen: Die Lösung verlangt keinen Eingriff in die 230-V-Installation, keinen Zugang zum Schulnetz und keine Budgetfreigabe.
• Endet mit einer Warnung: Das Gerät misst nicht nur stumm; ab einem Schwellenwert meldet es sich per LED, Summer oder Display.

Eine 4-wöchige Einheit für projektbasiertes Lernen

Der Plan umfasst 8 Unterrichtsstunden: zwei pro Woche, jeweils 40 Minuten. Die Wochen folgen den fünf PBL-Phasen, aber zwischen Recherche und Prototyp gibt es keine dicke Mauer; in Woche 2 grenzt ein Team vielleicht noch sein Problem ein, und in Woche 3 kann eine neue Messung eine neue Recherchefrage aufwerfen. Wichtig ist, dass am Ende jeder Woche das Ergebnis aus der Tabelle vorliegt. Auch deine Rolle ändert sich von Woche zu Woche: Am Anfang bist du die Person, die fragt, in der Mitte der Coach und am Ende diejenige, die das Publikum in den Raum holt.

Die folgende Tabelle zeigt denselben Plan Stunde für Stunde. Die letzten 3 Minuten jeder Stunde gehören der Abschlussfrage; das Team schreibt seine Antwort in einem Satz unten ins Testprotokoll. Diese Antworten sind der Einstieg in die nächste Stunde und zugleich der Nachweis des Prozesses in der Abschlusspräsentation. Begrenze Mini-Inputs auf 10 Minuten; alles Längere frisst die Arbeitszeit der Teams, und die Einheit wird unbemerkt wieder zum Frontalunterricht.

4 Problemszenarien und ihre Startprojekte in BlueGrays

Erwarte nicht, dass die Teams ihren Code bei null beginnen; bei PBL ist das Ziel, das Problem zu lösen, nicht ein Programm ab der ersten Zeile zu schreiben. Für jedes Szenario gibt es in BlueGrays ein fertiges Startprojekt mit Schaltplan, Bauteilliste und Code; das Team baut es auf, versteht es und passt es an sein Problem an. Die kostenlosen Projekte in der Tabelle sind für alle offen, für die Premium-Projekte brauchst du Premium. Bei sechs Teams sollten höchstens zwei Teams dasselbe Szenario wählen. Messen zwei Teams im selben Szenario an verschiedenen Orten, bekommst du in den Präsentationen sogar einen Vergleich.

Sei in zwei Punkten von Anfang an ehrlich zu deiner Klasse. Erstens ist der KY-038 kein Schallpegelmesser: Er macht aus der Schwankung, die das Mikrofon aufnimmt, eine Zahl zwischen 0 und 1023. Das Team kann nicht sagen "die Mensa hat 85 dB", aber es kann sagen "in der Mittagspause liefert die Mensa viel höhere Werte als ein leeres Klassenzimmer" und den Unterschied in Zahlen zeigen; für PBL reichen vergleichende Daten. Wie der Sensor reagiert und wie du ihn einstellst, steht im Beitrag zum Schallsensor KY-038. Zweitens misst ein DHT11 Temperatur und Luftfeuchtigkeit, aber nicht, wie stickig die Luft ist; in einem geschlossenen Raum steigt vor allem das Kohlendioxid. Das Raumluft-Team kann seinen Lüftungsvorschlag auf Temperatur und Feuchte stützen und in der Präsentation sagen, dass der nächste Schritt eine CO2-Messung ist. Für die Sensoren der Energie- und Wasser-Teams erklären die Beiträge zum LDR-Lichtsensor und zum Bodenfeuchtesensor die Kalibrierung ausführlich.

Materialliste: 6 Teams + 1 Ersatzset

Teamvertrag und Rollen

Hat in einem Vierer-Team nicht jede Person eine Aufgabe, erledigt die schnellste alles und die anderen schauen zu. Am einfachsten verhinderst du das mit vier Rollen und wöchentlichem Wechsel: 4 Wochen, 4 Rollen, alle übernehmen jede Rolle einmal. Eine Rolle heißt nicht "ich mache nur das", sondern "ich stehe dafür gerade". Die Code-Verantwortliche schreibt nicht als Einzige Code, erklärt aber in dieser Woche der Klasse, was der Code tut. Den Vertrag schreibt das Team in der ersten Stunde selbst; du machst nur die folgenden Punkte zur Pflicht und gibst ihn nach vier Unterschriften frei.

• Unsere Teilfrage: .................................................. (ein Satz, ein Ort, eine Zeit)
• Unser Erfolgskriterium: Wenn .................. über .................. steigt, warnt unser Gerät mit ...................
• Rollen (Woche 1): Projektleitung ........, Schaltung ........, Code ........, Daten und Dokumentation ........ Jede Woche rücken die Rollen um eine Person weiter.
• Entscheidungsregel: Wenn wir uns nicht einigen, messen wir zuerst; gibt es keine Messung, entscheidet die Projektleitung und schreibt die Entscheidung ins Testprotokoll.
• Hilferegel: Bevor wir zur Lehrkraft gehen, schauen wir in den Schaltplan, in den Abschnitt Code verstehen des Projekts und fragen ein Teammitglied.
• Fehlen: Wer eine Stunde verpasst, liest in der nächsten Stunde das Testprotokoll und ist in 2 Minuten wieder auf Stand; seine Aufgabe übernimmt in dieser Woche jemand anderes.
• Unterschriften: .............. .............. .............. ..............

Die Prototyp-Schleife: die kleinste funktionierende Version

PBL-Einheiten scheitern am häufigsten daran, dass Teams die ersten zwei Wochen damit verbringen, das perfekte Gerät zu entwerfen. Die Regel ist einfach: Am Ende von Stunde 4 braucht jedes Team eine kleinste funktionierende Version. Sie kann drei Dinge: den Sensor auslesen, den Wert im Serial Monitor anzeigen und eine einzige LED einschalten, wenn der Wert einen Schwellenwert überschreitet. Kein Gehäuse, kein Display, kein WLAN; aber sie liefert echte Daten und lässt sich testen. Für das Lärm-Team heißt das, im Code von Lichtstärke messen mit LDR eine if-Abfrage und eine LED zu ergänzen. Für das Energie-Team ist Nachtlicht mit LDR fast schon diese Version; nur die Logik wird umgedreht: Die LED leuchtet nicht bei Dunkelheit, sondern wenn das Licht an ist, und die Frage "Ist der Raum leer?" kommt in der nächsten Version mit dem PIR dazu. Jede weitere Version bringt genau eine Änderung und kommt ins Testprotokoll:

1. Version 0, Messen: Der Sensor wird ausgelesen und der Wert einmal pro Sekunde in den Serial Monitor geschrieben. Das Team sieht, wie sich der Wert mit Hand, Licht, Geräusch oder Wasser ändert.
2. Version 1, kleinste funktionierende Version: Ein geschätzter Schwellenwert und eine LED. Wird die Schwelle überschritten, leuchtet die LED. Diese Version wird bei der Zwischenkontrolle in Stunde 4 gezeigt.
3. Version 2, Kalibrierung: Nach den Messungen vor Ort wird die Schwelle aus Daten statt aus einer Schätzung gewählt, zum Beispiel in der Mitte zwischen dem Wert im leeren Klassenzimmer und dem Wert in der Pause.
4. Version 3, stabile Warnung: Pendelt der Wert um die Schwelle, flackert die LED. Abhilfe schafft der Mittelwert der letzten 10 Messungen oder zwei getrennte Schwellen fürs Ein- und Ausschalten.
5. Version 4, für die Nutzer gebaut: Die Warnung richtet sich nach der betroffenen Person: in der Mensa ein dreifarbiges Licht, das alle sehen, im Klassenzimmer ein kleines LCD auf dem Lehrertisch. Gehäuse und Platzierung kommen in dieser Version.

Kriterien für Zwischenkontrolle und Abschlusspräsentation

Für allgemeine Kriterien wie Schaltung, Code, Verständnis, Fehlersuche und Dokumentation kannst du das Hauptraster aus dem Beitrag Bewertungsraster für Arduino-Projekte unverändert übernehmen. In einer PBL-Einheit reicht es, drei Kriterien zu ergänzen; sie messen, was eine Projektaufgabe nicht misst, diese Einheit aber eigentlich vermittelt. Die Zwischenkontrolle findet in Stunde 4 statt und schaut nur auf die Problemdefinition und die kleinste funktionierende Version; ihr Zweck ist, die Richtung zu korrigieren, nicht zu benoten. In der Abschlusspräsentation werden alle drei Kriterien bewertet. Ein herausragender Prototyp kann nach der Einheit auch auf einen Wettbewerb oder eine Schulmesse; Themenideen findest du im Beitrag mit Projektideen für Wettbewerbe.

• Problem (30 Sekunden): Die Teilfrage und ein Satz der befragten Person, der das Problem beschreibt.
• Messung (45 Sekunden): Wo, wann und wie oft ihr gemessen habt; eine einzige Tabelle oder ein Diagramm.
• Live-Demo (45 Sekunden): Das Gerät überschreitet vor dem Publikum die Schwelle und warnt. Halte als Reserve ein kurzes Demovideo bereit.
• Versionen (30 Sekunden): Eine Entscheidung aus dem Testprotokoll: "Wegen dieser Messung haben wir die Schwelle geändert."
• Vorschlag (30 Sekunden): Ein konkreter Vorschlag an die Schule (wo, wie viele Geräte, wer kümmert sich) und was ihr mit einer Woche mehr tun würdet.
• Fragen (2 Minuten): Die Lehrkraft oder das Publikum richtet die Frage an ein Teammitglied ihrer Wahl; deshalb muss jede Person jeden Teil erklären können.

Wobei hilft BlueGrays in dieser Einheit?

• Startprojekt mit dem Projektfinder: In Stunde 2 beantwortet das Team drei Fragen: bei "Was möchtest du bauen?" Messen und erfassen, als Board Arduino Uno / Nano und als Erfahrung in den meisten Klassen "Ich habe schon ein paar Projekte gebaut". Neben dem besten Treffer kann im Ergebnis auch ein kostenloses Aufwärmprojekt erscheinen, das mit denselben Bauteilen startet. Mehr dazu im Beitrag zum Projektfinder.
• Code verstehen statt kopieren: Den Code des Startprojekts zu kopieren und weiterzumachen, bringt bei PBL nichts, denn das Team wird diesen Code ändern. Der Reiter Code verstehen zeigt zuerst die Zusammenfassung "Was macht dieser Code?", dann die Erklärung Schritt für Schritt und zum Schluss eine Aufgabe Probier es selbst, die genau eine Änderung verlangt. Bei kostenlosen Projekten ist er für alle offen, bei Premium-Projekten mit Premium. Wie du ihn nutzt, zeigt der Beitrag Code verstehen.
• Bauteile planen mit Werkstatt › Teile (Premium): Trägst du die Teile aus dem Klassenschrank mit ihrer Anzahl in Werkstatt › Teile ein, zeigen die Listen Machbare Projekte und Projekte mit fehlenden Bauteilen, welches Szenario heute starten kann und wofür du bestellen musst. Mehr dazu im Beitrag Arduino-Projekte mit vorhandenen Bauteilen.
• Dein eigenes Beispielprojekt: Vor der Einheit kannst du ein Szenario selbst bauen und über Lernen > Forum > Neuer Beitrag in der Kategorie Anleitung teilen: Füge Fotos der Schaltung hinzu (bis zu 5 Bilder), setz deinen Code mit Code hinzufügen ein und verknüpfe die passenden fertigen Projekte. Der Beitrag erscheint in der Sprache, in der du ihn schreibst; seinen Link schickst du mit Teilen in die Klassengruppe. Fertige Projekte gibst du genauso mit Teilen auf der Projektseite weiter. Die Schritte stehen im Beitrag Unterrichten mit eigenem Projekt.
• Premium-Zugang für die Klasse: Für Premium-Startprojekte wie Intelligente Bewässerungsstation und für Werkstatt › Teile braucht nicht jede Person ein eigenes Abo; die einmaligen, nicht automatisch verlängerten Lehrer-Pakete, die Schülerinnen und Schüler ohne Kreditkarte einlösen, erklären wir im Beitrag Premium-Codes für die ganze Klasse.

Wisse auch, was die App nicht kann: BlueGrays hat keine Klassenverwaltung, kein Dashboard, das der Lehrkraft den Fortschritt der Teams zeigt, und keine Aufgabenverteilung. Problemkarte, Teamvertrag und Testprotokoll bleiben auf Papier oder in einem gemeinsamen Dokument deiner Schule. Die App trägt die Seite "Wie baue ich das, was macht der Code, welches Teil fehlt?"; die Seite "Warum diese Schwelle, wem nützt es?" ist die Arbeit des Teams und deine. Diese Aufteilung passt ohnehin zu PBL: Das Denken bleibt im Team, nicht auf dem Bildschirm.

Typische PBL-Fallen und Lösungen

Checkliste vor der Einheit

• Die Leitfrage steht auf einem Plakat und hängt im Klassenzimmer.
• Die 4 Szenariokarten (Problem, möglicher Sensor, Startprojekt) sind für jedes Team kopiert.
• Alle 7 Sets sind gezählt; jeder Sensor wurde einmal getestet und liefert Werte im Serial Monitor.
• Arduino IDE und Board-Treiber sind auf den Rechnern installiert, die USB-Kabel getestet.
• Die Startprojekte öffnen sich auf den Handys oder Tablets der Klasse; wenn Premium-Projekte genutzt werden, sind die Codes verteilt.
• Problemkarte, Teamvertrag und Testprotokoll sind für jedes Team ausgedruckt.
• Die Schulleitung hat Schulrundgang und Messungen vor Ort erlaubt; Messzeiten für Mensa, Flur und Schulgarten stehen fest.
• Das Publikum der Abschlusspräsentation (Schulleitung, Schulpersonal, eine andere Klasse) ist eingeladen und hat einen Termin.
• Die Tabelle mit den PBL-Kriterien ist für die Zwischenkontrolle (Stunde 4) und den Abschluss (Stunde 8) ausgedruckt.

Das eigentliche Produkt dieser Einheit ist nicht das Gerät, sondern die Gewohnheit "Erst messe ich, dann entscheide ich"; das Gerät liegt als Beleg dafür auf dem Tisch. Beim ersten Durchlauf musst du nicht alle vier Szenarien öffnen; mit zwei Szenarien und sechs Teams lernt die Klasse dieselbe Schleife. Wenn du die Startprojekte vor dem Unterricht einmal selbst aufbauen möchtest, lade dir die BlueGrays-App herunter und probiere Nachtlicht mit LDR mit Schaltplan, Code und den Schritten in Code verstehen aus.