Ja, man kann Robotik allein mit einem Computerraum unterrichten. Wer mit großen Klassen, knappen Budgets oder wenigen Unterrichtsstunden zu tun hat, für den ist der Einstieg über die Simulation sogar nicht bloß ein Kompromiss, sondern häufig die didaktisch bessere Wahl. Wer einer Klasse mit vierzig Achtklässlern am ersten Tag echte Hardware in die Hand drückt, verbringt erfahrungsgemäß vierzig Minuten damit, Kabel zu entwirren, verschwundene AA-Batterien zu suchen und gescheiterte Bluetooth-Kopplungen zu beheben — für tatsächliches informatisches Denken bleiben exakt null Minuten.

Simulation ist allerdings kein perfekter Ersatz für praktisches Ingenieurhandwerk. Wer ohne Hardware wirksam unterrichten will, muss genau wissen, wo die Grenzen eines Simulators verlaufen.

Was sich überträgt: die Stärken der Simulation

Ein guter Simulator ist ein hervorragendes Werkzeug, um die kognitive Hälfte der Robotik zu vermitteln. Die hier erworbenen Fähigkeiten lassen sich ohne jeden Qualitätsverlust auf physische Systeme übertragen:

• Steuerungslogik: Der Kern der Robotik ist das Treffen von Entscheidungen. Verschachtelte Schleifen, Verzweigungen (if-then-else) und Zustandsautomaten funktionieren in einer virtuellen Umgebung genauso wie auf einem echten Mikrocontroller.
• Sensorik-Theorie: Simulatoren bringen Lernenden bei, in Sensorschwellen zu denken. Einen virtuellen Roboter so zu programmieren, dass er anhält, wenn ein Ultraschallsensor weniger als 20 Zentimeter misst, vermittelt exakt dieselbe mathematische Logik, die verhindert, dass ein echter Roboter gegen die Klassenzimmerwand fährt.
• Schnelles Iterieren: Im Simulator dauert Kompilieren und Ausführen zwei Sekunden. Macht ein Lernender einen Fehler, setzt er die Simulation zurück und probiert es sofort erneut. Diese enge Rückkopplung fördert Experimentieren und Fehlersuche, während echte Hardware wegen langsamer Upload-Geschwindigkeiten oft fünf Minuten zwischen dem Schreiben des Codes und dem Ergebnis liegen lässt.

Was den „Reality Gap“ nicht überwindet

„Reality Gap“ nennen Robotikerinnen und Robotiker den Unterschied zwischen simulierter Umgebung und physischer Welt. Wer nur im Simulator programmiert, verpasst mehrere harte, aber unverzichtbare Lektionen über reales Ingenieurwesen:

• Reibung und mechanische Toleranzen: Im Simulator fährt der Roboter perfekt geradeaus, wenn beide Motoren auf 50 % Leistung stehen. In der Wirklichkeit sind keine zwei Gleichstrommotoren identisch. Einer ist immer etwas schneller, die Reifen haften unterschiedlich, das Chassisgewicht ist ungleich verteilt — und der Roboter zieht zur Seite.
• Umgebungsrauschen: Simulatoren arbeiten unter sterilen Bedingungen. In der Realität übersteuert Sonnenlicht durch das Klassenzimmerfenster die Infrarot-Liniensensoren und macht sie blind. Ein staubiger Boden lässt die Antriebsräder durchdrehen und verfälscht die Encoder-Berechnungen.
• Elektrik und Verkabelung: Ein Simulator leidet nie unter einem lockeren Jumperkabel, einer kalten Lötstelle oder einem Spannungseinbruch der Batterie, der den Mikrocontroller jedes Mal zurücksetzt, wenn die Motoren viel Strom ziehen.

Die Realität südafrikanischer Klassenzimmer

An südafrikanischen Schulen fällt die Entscheidung für die Simulation oft aus infrastrukturellen und nicht aus didaktischen Gründen. Simulatoren lösen drei unserer hartnäckigsten Probleme im Unterricht:

• Die Kostenhürde: Ein brauchbarer physischer Robotik-Baukasten kostet zwischen R1,500 und R4,000. Einen Computerraum für eine Klasse mit 40 Lernenden auszustatten, erfordert eine Anschaffung von mindestens R30,000 (bei einem Verhältnis von 1:4 zwischen Lernenden und Geräten). Simulatoren, von denen viele kostenlos sind und im normalen Webbrowser laufen, senken diese Anfangsinvestition auf null.
• Load-Shedding und Batteriepflege: Physische Roboter hängen an Akkus (Li-Ion, LiPo oder NiMH). Dutzende Akkus während des rotierenden Load-Shedding geladen zu halten, ist ein administrativer Albtraum. Und werden die Roboter über die dreiwöchigen Winterferien ungeladen im Lagerraum gelassen, können die Akkus vollständig degradieren und teuren Ersatz nötig machen. Ein Computerraum am Schulgenerator oder ein Laptopwagen mit einfacher USV umgeht diesen Wartungszyklus vollständig.
• WPA2-Enterprise-WLAN: Die meisten Schulnetze setzen auf Sicherheitsprotokolle für Unternehmen, die Benutzername und Passwort verlangen. Gängige Bildungs-Mikrocontroller (etwa der ESP32 oder der Raspberry Pi Pico W) unterstützen WPA2-Enterprise ab Werk nicht ohne Weiteres, was das drahtlose Aufspielen von Code für die IT-Verantwortlichen der Schule zum technischen Albtraum macht. Browserbasierte Simulatoren umgehen das komplett, weil sie lokal auf dem Client laufen.

Wie man ein Quartal aufbaut: der hybride Fahrplan

Am wirksamsten unterrichtet man Robotik nicht, indem man sich zwischen Simulation und Hardware entscheidet, sondern indem man beides nacheinander einsetzt. Ein ganzes Quartal lässt sich so anlegen, dass 80 % der Arbeit im Computerraum stattfinden und am Ende eine kurze, wirkungsvolle Aufgabe an echter Hardware steht.

Hier eine bewährte Struktur für ein zehnwöchiges Quartal:

Mit dieser Abfolge muss man nur einen Bruchteil der Hardware kaufen (vielleicht 5 statt 20 Baukästen), weil sich die Lernenden die echten Roboter in den letzten Wochen teilen können. Da ihr Code im Simulator logisch bereits fehlerbereinigt wurde, geht die Zeit an der echten Hardware für echte technische Probleme drauf — Sensorkalibrierung, durchdrehende Räder — und nicht für Syntaxfehler.

Damit dieser Übergang nahtlos gelingt, haben wir Canvas entwickelt, unseren browserbasierten Programmiereditor, und dazu SheenVerse, unsere virtuelle Simulationsumgebung. Mit diesen Werkzeugen schreiben Lernende Code, der sofort in einer 3D-Simulation im Browser läuft und sich anschließend mit einem einzigen Klick auf echte Hardware laden lässt — der Weg vom Bildschirm zum Silizium wird so reibungslos wie möglich.