Scratch

One Robot per Kid

26 August 2015 | Beat Döbeli Honegger | Scratch

Eigentlich habe ich trotz allgemeinen Urlaubs um mich herum grad keine Zeit für Blogpostings, aber (Standardbegründung für Blogpostings:) da ich bereits mehrfach danach gefragt worden bin:

Ich habe bei Kickstarter das mBot-Projekt unterstützt und nun letzte Woche 2 mBots erhalten:

mbot.jpg

Es handelt sich um einen auf einem Arduino-Board (Biblionetz:w02431) aufbauenden Roboter (Biblionetz:w00801) mit Abstandssensoren, Mikrofon, Helligkeitssensoren für Striche am Boden, IR-Empfänger,LEDs etc. der entweder mit einer Arduino-Entwicklungsumgebung oder mit einer abgewandelten Scratch-Umgebung programmiert werden kann. Die Programmierung kann per USB-Kabel oder je nach bestelltem Modul per Bluetooth oder WLAN vorgenommen werden.

Bei Kickstarter hat ein Roboter $49 inkl. Versand von China in die Schweiz gekostet, im regulären Verkauf sind nun 75$ fällig. Angesichts dieses Preises steht darum auch unbescheiden das Motto One Robot per Kid (in Anlehnung an One Laptop per Child (OLPC) (Biblionetz:w02041)) auf der Innnenseite jeder mBot-Schachtel.

Viel Erfahrung mit dem Roboter habe ich noch nicht. Bisher kann ich erst sagen, dass der Aufbau durch einen Siebenjährigen unter Beobachtung eines Erwachsenen in 30 Minuten problemlos verläuft (n=1-Studie):

mbot2.jpg


Lieber Beat, für die Schule suche ich schon lange nach einer günstigen Robotik Plattform, von der man sich ggf. auch einen Klassensatz leisten kann. Die mBots klingen da ziemlich gut. Allerdings möchte ich eine graphische Programmiersprache höchstens für den Einstieg nutzen. Meine Frage daher: Weisst du ob es schwierig ist, den mBot in eine nicht-graphische Umgebung einzubinden? Ich glaube, ich habe mal einen Screenshot mit einer Processing-IDE gesehen, finde aber nirgends genauere Informationen.

-- Main.NicolasRuh - 18 Aug 2015

Lieber Nicolas, der mBot besteht aus einem Arduino-Board, d.h. du kannst problemlos mit der Arduino-IDE programmieren. Meine Rückfrage: Warum willst du nicht bei der graphischen Programmiersprache bleiben?

-- Main.BeatDoebeli - 20 Aug 2015

Weil es mir eigentlich darum geht, Programmieren im Sinne von "Code schreiben" einzuführen, so dass ich später zu anderen, nicht graphischen Sprachen überwechseln kann. Ein zweiter Grund ist der, dass meine SchülerInnen mit ähnlichen Umgebungen (z.B. Enchanting) in früheren Projekten recht schnell an die Grenzen dessen gestossen sind, was sich zumindest mit dieser Umgebung machen lässt - was aber mit Code nicht schwierig wäre.

-- Main.NicolasRuh - 26 Aug 2015

Sphero SPRK

07 August 2015 | Beat Döbeli Honegger | Informatik, Scratch
Bereits vor einiger Zeit habe ich mir eine fernsteuerbare Kugel namens Sphero gekauft unter dem Vorwand, deren Eignung als Einfachstroboter für die Einführung ins Programmieren testen zu wollen. Beim Sphero handelt es sich um einen in eine wasserdichte Kugel eingeschlossenen, per Bluetooth gesteuerten Roboter, der über Motoren zur Fortbewegung, LEDS zur zum Leuchten und eingem Gyroskop für die eigene Lage- und Bewegungserknnung verfügt.

sphero-01.jpg

Dazu gibt es eine ganze Palette an Apps für iOS und Android, mit dem sich die Kugel fernsteuern und Augmented-Reality-Spiele spielen lassen. Bereits seit längerem gibt es auch eine App, mit der sich die Kugel programmieren lässt, in einer Art Basic-Dialekt. Die App wirkt aber nicht sehr attraktiv und eigentlich nicht wirklich für die Einführung ins Programmieren.

sphero-0w.jpg

Nun scheinen aber die Hersteller den Education-Markt entdeckt zu haben und bieten unter dem Titel Sphero SPRK (schools - parents - robots -kids) einerseits eine durchsichtige Spezialversion (damit man auch sieht, wie die Technik funktioniert) und andererseits eine graphische Programmierumgebung für iOS an , mit der sich schon eher etwas Einführendes machen lässt. Und selbstverständlich wird auch entsprechendes Unterrichtsamterial angeboten, um auf den MINT/STEM-Zug aufspringen zu können:

sphero-02.jpg

An und für sich eine coole und attraktive Sache. Bei Unterrichtsmaterial von Hardwareherstellern muss man einfach immer kritisch fragen, ob es die Hardware für die vermittelten Kompetenzen wirklich braucht oder die Vermittlung mindestens attraktiver macht - oder ob es einfach ums Verkaufsargument "Unser Produkt lässt sich in allen Fächern einsetzen" geht.

Was mir gefällt: Der Preis von ca. 130 $/Euro/Franken ist für eine Schule finanzierbar, es sind auch Ausleihsets von Mediotheken o.ä. denkbar und die Geräte lassen sich mit Smartphones und Tablets steuern und programmieren, welche die Schülerinnen und Schüler privat bereits besitzen und die Kugel fasziniert, wenn man sie so über den Boden flitzen sieht.

Eher kritisch ist aus meiner Sicht bei Sphero, dass Programmierbefehle eingesetzt werden, die sich sonst nirgends nutzen lassen (im Gegensatz beispielsweise zu einem Lego WeDo oder einem mBot, der sich mit Scratch programmieren lässt, das auch ohne diese Hardware-ERweiterung nutzbar ist). Zudem schient der Sphero nich sehr präzis steuerbar zu sein, was dann Erfolgserlebnisse beim Programmieren etwas dämpfen dürfte - aber mit einer Schulklasse ausprobiert habe ich es noch nicht (Erfahrungsberichte gerne als Kommentar unten!).

Insgesamt ein aktuelles Beispiel dafür, dass derzeit eine Flut von MINT/STEM-Material auf den Markt kommt, was zwar einerseits erfreutlich ist, für Schulen allerdings die Bewertung und Auswahl erschwert. Darum unter anderem unser Versuch einer Kategorisierung von Programmier-Lernumgebungen unter http://www.programmingwiki.de/Lernumgebungen

P.S.: Sphero wird kommende Woche auch in Amsterdam an der Scratch2015AMS anzutreffen sein.

,

soeben ist das Programm der Scratch-Conference 2015 (http://www.scratch2015ams.org/ 12.-15.8.15) online gestellt worden, siehe http://www.scratch2015ams.org/dates/ Faszinierend und überwältigend ist dabei aus meiner Sicht das 17seitige Workshopprogramm PDF-Dokument !

Das Themenspektrum umfasst weit mehr als Scratch (Biblionetz:w02030), es geht um physiscal computing, computer science unplugged (Biblionetz:w02379), makerlabs (Biblionetz:w02491), arduino (Biblionetz:w02431), technisches Gestalten, STEAM (Biblionetz:w02428), etc.. Daneben werden aber auch spannende Weiterentwicklungen im Umfeld von Scratch/Snap! (Biblionetz:w02279) präsentiert und - angesichts der aktuellen Bemühungen, Informatik in die (Grund-)Schule zu bringen sehr relevant - Erfahrungsberichte aus vielen Ländern präsentiert, wie Scratch/Programmieren in den Unterricht gebracht wurde.

Da wird sehr viel Erfahrung an kreativer Vermittlung von Informatik zusammenkommen!

Ich fange an zu überlegen, wie ich mich für die Konferenz aufteilen könnte:

scratch-workshop-clone.jpg

Beta-Version von Scratch 2.0 online (Update)

13 May 2013 | Beat Döbeli Honegger | Scratch
Endlich ist es soweit: Seit heute ist die Betaversion der Programmierumgebung Scratch 2.0 unter http://scratch.mit.edu online!

Scratch 2.0 from ScratchEd on Vimeo.

Die wesentlichsten Neuerungen von Scratch 2.0:

  • Player und Editor online als Flash-Programm:
    • kein Java-Player mehr, aber auch keine iOS-Kompatibilität
    • keine lokale Installation mehr nötig, alles im Browser
  • Prozeduren in Form von eigenen Blöcken (Build your own Blocks, BYOB)
  • Netzvariablen: Daten lassen sich in der Cloud speichern und gemeinsam nutzen
  • Cloning: Objekte können sich selbst klonen
  • Bewegungserkennung mit Webcam
  • mehr... , Biblionetz:w02030

Zugegebenermassen ein Streit unter Experten - aber die Frage, welche Programmiersprache sich denn für die Schule eignet, bewegt die Gemüter seit Jahren. Während Aussenstehende erst die Frage geklärt haben möchten, ob Programmieren überhaupt zur Allgemeinbildung gehört (Biblionetz:f00114), ist dies für Informatik-Didaktiker klar.

Weniger klar ist dagegen, mit welcher Programmiersprache dies geschehen soll. In der Ausgabe 168 der Zeitschrift Login (Biblionetz:b04641) ist ein lesenswerter Artikel von Eckart Modrow, Jens Mönig und Kerstin Strecker erschienen, bei dem mir einzig der Titel missglückt zu sein scheint:

Eckart Modrow, Jens Mönig, Kerstin Strecker
Wozu Java? PDF-Dokument
Plädoyer für grafisches Programmieren
(Biblionetz:t13629)

Im Artikel argumentieren die AutorInnen, dass in Deutschland die Schülerinnen und Schüler meistens beim "Schreiben" der Programme die Motivation verlieren würden:

Sehen wir uns die schon mehrfach zitierte 80%-Ausstiegsquote im Informatikunterricht an, dann tritt die nur auf, wenn die Schülerinnen und Schüler „Programme schreiben“ müssen. Mit den anderen Themenbereichen des Informatikunterrichts gibt es meist keine Schwierigkeiten. Keine Schwierigkeiten gibt es in der Regel auch mit dem Finden eigener Ideen zur Lösung der (möglichst selbst) gestellten Probleme. Die treten erst „beim Schreiben“, also beim Kodieren auf. Der Zyklus „Lösungsidee > Formulierung der Idee > Test > Änderung der Lösungsidee > … wird durch Kodierungsprobleme unterbrochen. Die meisten Schülerinnen und Schüler bleiben beim Kodieren stecken, nicht beim (hier weiter gefassten) Programmieren. Brauchen wir aber überhaupt Code? Ist der Begriff „Programme schreiben“ nicht eigentlich überholt?

Der Artikel favorisiert dann grafische Programmiersprachen (Biblionetz:w02287), da diese keine Kodierungshürde aufweisen würden und verweist u.a. auf LabView als professionelle visuelle Programmiersprache, mit der unter anderem das südafrikanische Großteleskop SALT gesteuert werde.

Auch das Vorurteil, mit grafischen Programmierumgebungen wie Scratch (Biblionetz:w02030) könne man anspruchsvolle Konzepte der Informatik gar nicht vermitteln, versucht der Artikel zu widerlegen. Während sich Scratch durchaus eigne, um auch anspruchsvolle Konzepte der Physik zu modellieren (Bsp. Federpendel), sei insbesondere der Scratch-Ableger Build-your-own-Blocks (BYOB) (Biblionetz:w02279) so mächtig, dass sich auch ein universitärer Informatikgrundkurs allein mit dieser Programmiersprache umsetzen lasse, wie Berkeley mit der Informatikvorlesung CS10 im Rahmen des APCurriculums (AP Principles 2010) beweise.

Der Artikel versucht diese Mächtigkeit auch mit Beispielen aufzuzeigen, die mich durchaus ans Informatikstudium erinnern:

Das Beispiel illustriert kurz die weitergehenden Möglichkeiten des Systems, hier die „Lambdafizierung“ von BYOB-Strukturen, die es gestattet, diese wahlweise als Code oder Daten zu interpretieren.
Die BYOB-Listen lassen sich trivialerweise als Schlangen oder Stapel nutzen. Geschachtelte Listen bilden Bäume, Dictionaries, Graphen usw. Im Bereich der Datenstrukturen gib es hier keinerlei Beschränkungen.

Spätestens bei der Lambdafizierung wird niemand mehr von einer Kindergartensprache reden...

Der Artikel schliesst mit folgenden Fragen:

  1. Worin besteht der bildende Wert textbasierter Programmierung, also der Möglichkeit, Syntaxfehler machen zu können, wenn inhaltlich alle informatischen Konzepte, aber auch Standardanwendungsbereiche und –aufgaben mit BYOB als Werkzeug implementiert werden können? Ist die damit verbundene Frustrationsrate gerechtfertigt, hat Syntax ihren eigenen Wert?
  2. Ist der zu beobachtende Trend „weg von der Programmierung“ inhaltlich begründet oder ein Resultat der Probleme im Programmierunterricht? Soll er beibehalten oder vielleicht gestoppt, sogar wieder umgekehrt werden, wenn jetzt geeignetere Werkzeuge dafür zur Verfügung stehen? Um nicht missverstanden zu werden: Programmieren wird hier immer noch als Synonym für „selbstständiges produktorientiertes Problemlösen“ benutzt, nicht für „Kodieren“!
  3. Auf welcher Beschreibungsebene ist zu arbeiten? Algorithmen können natürlich als BYOB-Blöcke vorgegeben werden, bearbeitbar sind sie in dieser Form allerdings nur am Computer. Soll und kann auf „papiergeeignete“ Notationsformen umgestiegen werden, wenn Syntaxeigenheiten keine Rolle mehr spielen, korrekte Syntax in diesem Zusammenhang keinen eigenen Wert mehr hat?
  4. Ist Informatikunterricht nur realitätsnah, wenn echte Produktionssysteme wie Java, Python, … im Unterricht benutzt werden? Braucht der Informatikunterricht Ausbildungswerkzeuge ähnlich wie die Naturwissenschaften, die auch fast ausschließlich Gerätschaften benutzen, die man außerhalb der Schule kaum findet.

Der Artikel liefert für mich weitere Argumente zur Wahl von Scratch als Programmiersprache in der Schule. Weitere, im Artikel nicht genannte Argumente sind für mich:

  • Die Scratch-Umgebung erlaubt das Einbinden und Erstellen von eigenen Bildern und Tönen und eröffnet damit weitere - nicht von Anfang an algorithmische - Zugänge zum Thema Programmieren / Informatik.
  • Dieses Einbinden eigener Bilder, Töne & Fotos erhöht die Motivation von Schülerinnen und Schülern, die Programmierumgebung auch in ihrer Freizeit zu verwenden.
  • Mit der Einbindung von Sensoren und Aktoren des Robotiksets Lego-!WeDo werden die Schranken des Bildschirms und Computers gesprengt, Informatikprojekte reichen damit in die reale physische Welt hinaus, auch das ein Motivationsfaktor.
  • Während mit BYOB eine Erweiterung gegen oben zur Verfügung steht, bietet der App-Inventor (siehe auch Wikipedia) von Google für Android-Geräte eine Erweiterung in die reale Geräteprogrammierung, indem damit Adnroid-Geräte programmiert werden können. Ich stelle mir das sehr motivierend vor, wenn Kinder ihre eigenen Spiele und Gadgets für ihr Tablet oder ihr Mobiltelefon programmieren können...
  • Scratch ist kostenlos für Windows, Mac und Linux verfügbar und wird vom MIT aktiv weiter entwickelt. ,

Kontakt

  • Beat Döbeli Honegger
  • Plattenstrasse 80
  • CH-8032 Zürich
  • E-mail: beat@doebe.li