Zulassungsarbeit V9.0 - RobInfun

Vermittlung von informatischen 

Grundkonzepten der Realschulbildung 

anhand einer robotergesteuerten 

Lagerverwaltung 

Schriftliche Hausarbeit 

(überarbeitete Fassung) 

im Fach Didaktik der Informatik 

vorgelegt von 

Markus Weber 

Angefertigt am 

Lehrstuhl für Programmiersysteme 

Didaktik der Informatik 

Friedrich-Alexander Universität Erlangen-Nürnberg 

Betreuer: Prof. Dr. T. Brinda Beginn: 01.06.08 

B. Wiesner Abgabe: 01.10.08

SELBSTSTÄNDIGKEITSERKLÄRUNG 

III 

Selbstständigkeitserklärung 

Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer 

als der angegebenen Quellen angefertigt habe und dass die Arbeit in 

gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen 

hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle 

Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche 

gekennzeichnet. 

Erlangen, den 30.09.2008 

___________________________ 

Markus Weber

IV 

ZUSAMMENFASSUNG 

Zusammenfassung 

Die vorliegende Staatsexamensarbeit ist in drei Hauptteile gegliedert: In eine 

Literaturrecherche zum Thema Roboter in der Bildung, den Entwurf einer robotergesteuerten 

Lagerverwaltung mit LEGO MINDSTORMS NXT (mit Unterrichtsumsetzung) 

und eine abschließende Zusammenfassung mit Schlussfolgerungen 

und persönlichen Erfahrungen des Autors. 

In der Literaturrecherche werden zuerst mehrere Beispiele für graphische Entwicklungsumgebungen 

beschrieben. Diese stehen exemplarisch für diejenigen 

Umgebungen, mit denen viele der Robotersysteme programmiert werden. Im 

Anschluss stellt der Verfasser verschiedene Quellen vor, in denen Roboter zu 

Bildungszwecken eingesetzt werden. Hierbei wird versucht, ein möglichst breites 

Spektrum der Bildungsbereiche abzudecken. Angefangen bei Roboterprojekten 

für Grundschüler werden anschließend Roboterprojekte der Sekundarstufe, 

Arbeiten einzelner Schüler und Projekte mit schulrelevantem Inhalt vorgestellt. 

Diese Recherche beinhaltet außerdem eine Quelle zu Lernanalysen 

und weitere Quellen zu Roboterprojekten für den Hochschulbereich. Anhand 

der referenzierten Literaturquellen wird versucht, charakteristische Probleme, 

Grenzen und Möglichkeiten der Roboter als Medium für Unterrichtssituationen 

herauszuarbeiten. 

Beim Entwurf der robotergesteuerten Lagerverwaltung versucht der Autor, die 

gewonnenen Ergebnisse aus den vorangegangenen Quellen mit einfließen zu 

lassen. Ziel dieses Abschnitts ist es, ein Roboterprojekt zu entwickeln, dass mit 

seinem modularen Aufbau unterschiedliche Konzepte von informatischen 

(Schul-)Bildungsplänen (diverse Lehrpläne von Schulen und die Bildungsstandards 

des Fachs Informatik für Realschulen) vereint. Die enthaltenen Unterrichtsthemen 

der Lagerverwaltung (Module) sind diesen Bildungsplänen zugeordnet. 

Lehrkräfte können damit auch Teile des Gesamtprojekts „Lagerverwaltung“ 

mit ihren Klassen für den Unterricht nutzen. Der Autor hat für eines dieser 

Module eine exemplarische unterrichtsmethodische Umsetzung im Rahmen 

eines Projekts für Realschulen entwickelt. Hierzu hat er einen umfangreichen 

Projektplan erstellt und davon eine Unterrichtseinheit detailliert ausgearbeitet. 

Lehrkräfte können das Konzept als Vorschlag oder Handreichung für den Informatikunterricht 

mit Robotern verstehen. Die vorgestellte robotergesteuerte 

Lagerverwaltung muss von den Lehrkräften noch auf die spezifische Unterrichtssituation 

angepasst werden. 

Auf der beiliegenden DVD sind Videos zu dem Projekt, die entwickelten Programme 

der Robotereinheiten und weitere Zusatzinformationen für die Leser 

frei zugänglich. Speziell programmierte Setup- und Softwareroutinen erlauben 

eine einfache Übertragung der entwickelten Programmmodule auf andere 

Rechnerarbeitsplätze.

ABSTRACT 

V 

Abstract 

This document consists of three main parts: one source research (about robots 

in education), the draft of an automatic (robot-controlled) warehouse with LEGO 

MINDSTORMS NXT Robots (with a detailed plan for school lessons) and a final 

summary with personal conclusions and an experience report of the author. 

In the source research first several examples of graphic development environments 

are described. These environments stand exemplary for those which are 

mostly used to program robot systems. After that, a description of different science 

articles (in which robots are used for educational purposes) is following. 

The author tried to give the reader an overview of the whole educational spectrum 

with various robotic projects. Robot projects for pupils of the primary 

school are presented subsequently and some robot projects of the secondary 

school are following. Projects with school relevant contents are shown after the 

work of individual pupils. In addition this research contains a source to learning 

analyses and further articles of university robotic projects. The writer worked out 

characteristic problems, borders and possibilities of the robots as a medium for 

learning situations. 

Those won results from the preceding source research have influenced the draft 

of the automatic (robot-controlled) warehouse. The goal of this section is to develop 

a robot project that has highly modular structure. It should also be anchored 

in the education plans of computer science (e.g. various curricula of 

schools and the education standards of computer science for six-form high 

schools). The different modules of the robot-controlled warehouse have been 

assigned to these education plans. Instructors or teachers can thereby also use 

parts of the overall project for teaching at school. The author has developed an 

exemplary instruction-methodical elaboration for one of these modules. This 

elaboration is realised in a project for six-form high schools. It contains an extensive 

plan of the project. The author also provided detailed instructions to one 

subunit of the project. 

Teachers can use the concept as a proposal or a handbook for robot introduction 

lessons in computer science courses. The draft of the automatic (robotcontrolled) 

warehouse has to be adapted on the specific instruction situation by 

the instructors or teachers, of course. 

The enclosed DVD is containing videos of the project, the developed programs 

of the robot units and further additional information (free accessible without any 

commercial license). Some particularly programmed software setups permit the 

simple transfer of the contained data to other personal computers.

VI 

INHALTSVERZEICHNIS 

Inhaltsverzeichnis 

SELBSTSTÄNDIGKEITSERKLÄRUNG 

ZUSAMMENFASSUNG 

III 

IV 

ABSTRACT 


V 

VI 

1 EINLEITUNG - 1 - 

1.1 MOTIVATION - 1 - 

1.2 ZIELSETZUNG - 1 - 

2 ROBOTER IN DER BILDUNG - 2 - 

2.1 ÜBERSICHT ROBOTERSYSTEME FÜR DIE BILDUNG - 2 - 

2.2 GRAFISCHE PROGRAMMIERUMGEBUNGEN - 4 - 

2.2.1 BEISPIELE VON ROBOTERPROGRAMMIERUMGEBUNGEN - 4 - 

2.2.2 GRAPHISCHE PROGRAMMIERSOFTWARE ZUR SPIELE-ENTWICKLUNG - 7 - 

2.2.3 BEWERTUNG UND DIDAKTISCHER KOMMENTAR - 8 - 

2.3 WISSENSCHAFTLICHE ARBEITEN ZUR VERWENDUNG VON ROBOTERSYSTEMEN IN 

DER BILDUNG - 9 - 

2.3.1 ROBOTER UND ROBOTIK IN DER GRUNDSCHULE - 9 - 

2.3.2 BEWERTUNG UND DIDAKTISCHER KOMMENTAR - 9 - 

2.3.3 ROBOTERGESTÜTZTE VERMITTLUNG INFORMATISCHER KONZEPTE DER 

SEKUNDARSTUFE - 10 - 

2.3.3.1 FACHÜBERGREIFENDE KONZEPTE - 10 - 

2.3.3.2 BEWERTUNG UND DIDAKTISCHER KOMMENTAR - 13 - 

2.3.3.3 ALGORITHMENMODELLIERUNG UND WEITERE KONZEPTE - 15 - 


2.3.3.5 ROBOTERSYSTEME AN AUßERSCHULISCHEN LERNORTEN - 25 - 


2.3.4 EINSATZ VON ROBOTERN IM HOCHSCHULBEREICH - 30 - 

2.3.4.1 LERNANALYSEN - 30 - 


2.3.4.3 BEISPIELHAFTE ROBOTIKPROJEKTE - 31 - 


2.3.4.5 ÜBERTRAGUNG EINES DER UNIVERSITÄTSPROJEKTE AUF SCHULISCHEN 

INFORMATIKUNTERRICHT - 40 - 

2.4 ZWISCHENZUSAMMENFASSUNG DER ERWORBENEN KENNTNISSE AUS DER 

LITERATURRECHERCHE - 41 -


VII 

2.4.1 CHANCEN DES ROBOTEREINSATZES IM BILDUNGSBEREICH - 41 - 

2.4.2 PROBLEME DES ROBOTEREINSATZES - 42 - 

3 ENTWURF EINER ROBOTERGESTEUERTEN LAGERVERWALTUNG - 43 - 

3.1 EINORDNUNG IN DIE BILDUNGSPLÄNE - 43 - 

3.1.1 MIT ROBOTERN VERMITTELBARE INHALTE IN AUSGEWÄHLTEN LEHRPLÄNEN - 43 - 

3.1.2 ROBOTERGEEIGNETE THEMEN IN DEN BILDUNGSSTANDARDS INFORMATIK FÜR 

DIE SEKUNDARSTUFE I - 45 - 

3.2 MOTIVATION DES SZENARIOS LAGERVERWALTUNG - 47 - 

3.2.1 INFORMATISCHE KONZEPTE DER LAGERVERWALTUNG - 48 - 

3.3 SKIZZE DES GESAMTKONZEPTS - 51 - 

3.3.1 ALLGEMEINE BESCHREIBUNG DES SZENARIOS - 51 - 

3.3.2 VERWENDETE ROBOTEREINHEITEN UND TECHNISCHE REALISIERUNG - 52 - 

3.3.3 DIDAKTISCHE ABSTRAKTION UND REDUKTION - 55 - 

3.4 EXEMPLARISCHE UNTERRICHTSMETHODISCHE UMSETZUNG - 56 - 

3.4.1 GROBE UNTERRICHTSPLANUNG FÜR EIN PROJEKT DER ROBOTERGESTEUERTEN 

LAGERVERWALTUNG - 57 - 

3.4.2 DETAILLIERTER ENTWURF DER UNTERRICHTSEINHEIT „ARBEIT MIT DEM 

ROBOTERSYSTEM“ - 61 - 

3.4.2.1 ANGENOMMENE VORKENNTNISSE DER SCHÜLER - 61 - 

3.4.2.2 FACHLICHE ZIELSETZUNGEN – LERNZIELE FÜR SCHÜLER - 61 - 

3.4.2.3 AUSFÜHRLICHE STUNDENPLANUNG ZUR UNTERRICHTSEINHEIT - 62 - 

4 ZUSAMMENFASSUNG MIT SCHLUSSFOLGERUNG - 66 - 

4.1 RESÜMEE ÜBER ERWORBENE ERKENNTNISSE - 66 - 

4.1.1 MÖGLICHKEITEN DER ROBOTERSYSTEME FÜR DEN UNTERRICHT - 67 - 

4.1.2 GRENZEN DER ROBOTERSYSTEME IM UNTERRICHT - 67 - 

4.2 PERSÖNLICHE ERFAHRUNGEN U. SCHLUSSFOLGERUNGEN DES AUTORS - 68 - 

ANHANG A: INFORMATIONEN ZUR BEILIEGENDEN DVD - 70 - 

ANHANG B: BEZUGSQUELLEN U. INTERNETADRESSEN - 71 - 

ANHANG C: UNTERRICHTSMATERIALIEN - 74 - 

ABBILDUNGSVERZEICHNIS - 80 - 

TABELLENVERZEICHNIS - 81 - 

LITERATURVERZEICHNIS - 82 -

KAPITEL 1: EINLEITUNG - 1 - 

1 Einleitung 

„Als Dr. Isaac Assimov in den vierziger Jahren des zwanzigsten Jahrhunderts 

die Geschichte zu „I, Robot“ schrieb und darin robotische Grundgesetze entwickelte, 

ahnte er noch nicht, wie die Entwicklung der Robotik in den folgenden 

Jahrzehnten voranschreiten würde.“ 1 

Heutzutage sind Robotersysteme, die immer noch diesen Gesetzen Folge leisten, 

in vielen Bereichen der Logistik und Automation längst Alltag geworden. 

Bereits Jugendliche können sich mit dem von LEGO entwickelten MIND- 

STORMS-System in der Programmierung und dem Bau von Robotern üben. 

Seit längerem werden diese Systeme auch in vielen Schulen zu Bildungszwecken 

verwendet. Diese Arbeit soll eine Möglichkeit aufzeigen, wie Robotersysteme 

in der schulischen Informatikausbildung eingesetzt werden können. 

1.1 Motivation 

Als Lehramtsstudent der Informatik hatte der Autor im Laufe seines Studiums 

vielfältigen Kontakt zu unterschiedlichen Modellen und Modellierungstechniken, 

um informatische Inhalte schülergerecht zu vermitteln. Wie bei dem Studienfach 

Informatik berechtigterweise zu erwarten ist, waren diese Modelle größtenteils 

diverse Programme, rechnergestützte Simulationen und Vergleichbares. 

Aus persönlichem Interesse heraus befasste sich der Verfasser schon früh mit 

dem Thema Robotik und MSR-Techniken 2 . Gerade die Möglichkeit, heutige 

Robotersysteme zur Modellierung informatischer Abläufe und Inhalte in der 

Schule zu benutzen, und damit ein „greifbares“ Modell einzusetzen, war besonders 

faszinierend. 

Bei dem Einsatz solcher Systeme muss sich der Lehrer aber immer Kritikpunkten 

stellen: „Spielerei mit Robotern ohne fachlichen Bezug“ oder „hoher Mehraufwand 

bei der Stundenorganisation“ sind hierfür nur zwei Beispiele. Sich gerade 

mit diesen Kritikpunkten im Rahmen einer wissenschaftlichen Arbeit zu 

beschäftigen und dabei auch die Modellstärken der Robotersysteme zu untersuchen, 

waren ebenfalls Grundmotivation für diese Arbeit. 

1.2 Zielsetzung 

In den folgenden Kapiteln möchte der Autor die Ergebnisse einer Literaturrecherche 

anhand von ausgewählten Publikationen und Veröffentlichungen zum 

Thema „Roboter in der Bildung“ vorstellen. 

Mit Hilfe dieser Roboterprojekte sollen exemplarisch informatische Bildungsinhalte 

dargestellt werden, die sich für die Vermittlung mit Robotersystemen eignen 

könnten. 

Nach einer Einordnung dieser Inhalte in Bildungspläne für das Fach Informatik 

wird der Verfasser noch ein mögliches Unterrichtskonzept für die Realschule 

beschreiben, und dazu eine exemplarische Unterrichtsmethodische Umsetzung 

aufzeigen. 

1 http://www.x-technik.at/magazin/ausgaben/2007/AT-012007.pdf, Seite 18 (zuletzt aufgerufen 

am 30.09.08) 

2 Messen, Steuern, Regeln

- 2 - 

KAPITEL 2: ROBOTER IN DER BILDUNG 

2 Roboter in der Bildung 

2.1 Übersicht Robotersysteme für die Bildung 

Um dem Leser einen Überblick zu verschaffen, hat der Autor diejenigen Robotersysteme 

in Tabelle 1 zusammengefasst, die sich nach seiner Meinung für 

den Unterricht an Bildungsinstitutionen eignen. 

Aus dieser Tabelle können folgende Informationen entnommen werden: 

- Eine Abbildung des Robotersystems, seine Bezeichnung und dessen Hersteller 

(entspricht in den meisten Fällen auch der Bezugsquelle). 

- Die Ausstattung hinsichtlich Motoren, Sensoren und Schnittstellen. Mit diesen 

Informationen können z.B. die möglichen Freiheitsgrade des Systems 

(s. Motorenanzahl) eingeschätzt werden. Die Sensorenanzahl kann ebenfalls 

helfen diese Möglichkeiten einzuschätzen. Für Schulen kann die Art der 

Schnittstellen eine interessante Information darstellen. Die serielle Schnittstelle 

verliert zunehmend an Bedeutung (z.B. bei Laptops) und bei manchen 

Robotersystemen wurde das bereits durch den Einbau von USB-Schnittstellen 

berücksichtigt. Bei Infrarot oder Bluetooth-Schnittstellen muss hingegen 

der organisatorische Rahmen bedacht werden, damit es im Schulalltag 

zu keinen Interferenzen oder Störungen bei der Übertragung kommt. 

- Die Art der Programmierung, deren Niveau und von Systemseite unterstützte 

Programmiersprachen. Dies kann helfen, die Systeme für den jeweiligen 

Bildungsbereich einzuordnen. 

- Weitere Kennzeichen des Systems wie Bausatzart, die vom Hersteller angegebene 

Aufbauzeit und Informationen zu unterschiedlichen Aufbauarten 

(Varianz). Die Bausatzart könnte hauptsächlich für die unterschiedlichen 

Schularten interessant sein. So könnten zum Beispiel Berufsschulen durchaus 

Interesse an einem Bausatz zum Löten haben, da sie hiermit auch 

handwerkliche Fähigkeiten vermitteln könnten. Als knapper Einstieg in die 

Robotik würde sich hingegen ein System anbieten, das schneller und ohne 

Vorkenntnisse aufgebaut werden kann (oder ein Komplettsystem). 

Ausführlichere Informationen zu den Systemen sind im Anhang B: Bezugsquellen 

u. Internetadressen nachlesbar. 

Der Autor begründet seine Auswahl der Robotersysteme wie folgt: 

- Die vorgestellten Systeme beinhalten größtenteils graphische Entwicklungsumgebungen, 

mit denen eine Programmierung ohne umfassende Vorkenntnisse 

erfolgen kann (Zugänglichkeit für Programmierunerfahrene). 

- Zu vielen der angeführten Systeme gibt es Internetforen und Sekundärliteratur, 

mit der sich Lehrkräfte auf den Unterricht vorbereiten können (Hilfesysteme 

und zusätzliche Literatur). 

- Die Kosten der Systeme liegen zwischen 50 EUR (z.B. Scribbler) und 200 

bis 300 EUR (je nach Ausstattung) und sind auch für Schulen finanzierbar. 

- Mit der Ausstattung an Sensoren und Motoren können einfache und komplexe 

Bewegungsabläufe programmiert werden (Flexibler Aufbau und Programmierung). 

- Die Systeme sind auf mehreren Bildungsniveaus (s. Literaturrecherche) einsetzbar 

(Zukunftsrelevanz).

KAPITEL 2: ROBOTER IN DER BILDUNG - 3 - 

Robotersystem 

Hersteller 

Abbildung 

Motoren, Sensoren 

und Schnittstellen 

Programmierart, 

-niveau u. -sprache 

Kennzeichen 

des Systems 

Asuro 

8 Sensoren 

2 Motoren 

Textbasiert 

Bausatz zum 

Löten, Schrauben 

(DLR u. 

Arexx) 

Seriell (RS-232) u. 

Infrarot (IR) 

Fortgeschritten 

C 

60 Min Aufbauzeit 

wenig Varianz 

Boe-Bot 

(Parallax 

9 Sensoren 

6 Motoren 

Textbasiert 

Fortgeschritten 

Bausatz zum 

Löten und 

Schrauben 

2-3 h Aufbauzeit 

u. Inex) 

RS-232 

Basic Stamp 

kaum Varianz 

Ma-Vin 

9 Sensoren 

2 Motoren 

Graphical User Interface 

(GUI) 

Bausatz klicken 

& stecken 

(Roboshop) 

Universal Serial Bus 

(USB) Schnittstelle 

Einsteiger 

Ma-Vin Robotics Lab 

- 4 - 


2.2 Grafische Programmierumgebungen 

Da die Zielgruppe (Jugendliche ab acht Jahren) der vorgestellten Robotersysteme 

meist nicht über Programmierkenntnisse verfügt, sind viele dieser Systeme 

mit einer grafischen Programmierumgebung GUI (Graphical User Interface) 

ausgestattet. 

Diese Umgebungen sind meist intuitiv bedienbar und erlauben die Erstellung 

funktionsfähiger Programme durch die Komposition verschiedener Symbole 

über „Drag&Drop“ Bedienung. Der Benutzer muss sich über Syntax und Programmbefehle 

der Programmiersprache keine Gedanken mehr machen. 

Gerade aus diesen Gründen eignen sich solche Entwicklungsumgebungen gut 

für den Einstieg in die Programmierung und liefern die Basis für den Umgang 

mit Programmiersprachen. Nachfolgend werden exemplarisch einige Roboterprogrammierumgebungen 

(RPU) betrachtet. 

2.2.1 Beispiele von Roboterprogrammierumgebungen 

LEGO MINDSTORMS Software 

Das Robotersystem LEGO MINDSTORMS RCX wurde im Herbst 1998 erstmals 

in den USA einer breiten Öffentlichkeit vorgestellt. Die Roboter Baukästen 

sind in unterschiedlichen Ausführungen mit jeweils eigener Software erhältlich. 

Aus der Sicht des Autors könnte man in der Realschule das „Robotics Invention 

System“ (RIS) sinnvoll einsetzen. 

Die Programmieroberfläche von RIS 2.0 (Abbildung 1), der aktuellen Softwareversion, 

zeichnet sich durch eine große Übersichtlichkeit der Bedienelemente 

und Funktionen aus. Eine Einführung in die Bedienung ließe sich in der Schule 

wahrscheinlich innerhalb einer Unterrichtseinheit realisieren. Die Module sind 

strukturiert angeordnet und farblich abgegrenzt, was Anfangsschwierigkeiten 

verringert. 

Abbildung 1: LEGO Robotics Invention Software


Als Nachfolger des RCX Systems stellte LEGO das NXT Robotersystem vor. 

Den - speziell für den schulischen Einsatz entwickelten - LEGO MINDSTORMS 

NXT Education Baukästen liegt die „LEGO NXT Education Software“ 

(Abbildung 2) bei. 

Das GUI dieser Software ist umfangreicher und beinhaltet auch Aufbau- und 

Programmieranleitungen zu Beispielrobotern. Die Entwicklung von Programmen 

kann in unterschiedlichen Anforderungsniveaus (mit Hilfe von drei Buttons unten 

links) erfolgen, von denen jedes dem Benutzer eine eigene Modulpalette 

liefert. Speziell dieses Feature könnte nach der Meinung des Autors zu Problemen 

in der Unterrichtspraxis führen, da man für komplexere Programme zwischen 

den Paletten wechseln muss. Zudem stellt die Software hohe Anforderungen 

an die Computerleistung (z.B. Arbeitsspeicherbedarf >800 MB bei längerer 

Bearbeitung umfangreicherer Programme). Sie offenbarte bei längerer 

Nutzung auch einige Bugs (z.B. unkontrollierte Programmabstürze). 

Bei der NXT Education Software läuft das Programm des Roboters linear ab 

und wird sequentiell abgearbeitet. Der Benutzer muss die unterschiedlichen 

Module auswählen und sie hintereinander auf die „Programmspur“ ziehen. Bei 

den angewählten Modulen erscheinen die zugehörigen Funktionalitäten unterhalb 

der Programmspur. Sie sind leicht verständlich und eröffnen viele Möglichkeiten 

der Programmierung. Eine weitere interessante Eigenschaft ist die 

Zusammenfassung beliebiger Programmteile zu „eigenen Blöcken“, die dann in 

anderen Programmen beliebig verwendet werden können. Dies macht Programmteile 

wieder verwendbar und erleichtert dem Lehrer die Differenzierung 

im Unterricht. Er kann komplexe Programmteile als eigenen Block zusammenfassen 

und nur dessen Funktionalität erklären, ohne auf Programmierdetails 

einzugehen. 

Die Bedienung des NXT Roboters erfolgt über ein Tastenfeld, dessen Symbole 

den Schülern von Multimediasoftware her bekannt sein dürften. Positiv hervorzuheben 

ist die ausführliche Kontexthilfe, mit der sich auch Schüler selbstständig 

einarbeiten können, die neue Kommentarfunktion und die grafisch überarbeiteten 

Einzelmodule, sowie die bebilderten Anleitungen und Beispielvideos. 

Abbildung 2: LEGO NXT Education Software

- 6 - 


„Tangible Programmierung“: Tern und Quetzal für LEGO MINDSTORMS 

Tangible Programmiersprachen ([09] u. [10]) stellen eine Weiterentwicklung der 

GUI Programmierumgebungen dar und sind teilweise noch in der Entwicklung. 

Ziel dieser Entwicklung ist, die physikalische Repräsentation der Sprachkonstrukte 

durch Bausteine (bei Quetzal, Abbildung 3) oder Holzpuzzleteilen (bei 

Tern, Abbildung 4). Die Programmentwicklung erfolgt über realitätsbezogene 

Interaktionen und ist weitestgehend rechnerunabhängig (der Lehrer ist somit 

nicht mehr an den Computerraum gebunden). Bei diesen Systemen wird das 

fertige Programmkonstrukt meist fotografiert und das Bild an eine Analysesoftware 

übergeben. Diese Software identifiziert zuerst Programmstrukturen mit 

Hilfe der Strichcodes auf den Bausteinen und generiert anschließend automatisch 

den Programmcode für einen Roboter. 

Abbildung 3: Quetzal Bausteine 

Abbildung 4: TERN Puzzleteile 

Bei Tern wird das generierte Programm in einer Simulation (Roboterszenario 

mit festgelegten Welten, vergleichbar mit den Welten des Roboters „KARA“ 3 ) 

dargestellt. Quetzal erzeugt Maschinencode des RCX Bausteins und dient damit 

der Steuerung eines RCX Roboters. Neben der Darstellung von Variablen, 

Endlosschleifen, können auch optionale Programmverzweigungen erstellt und 

Programmteile zu Methoden zusammengefasst werden. Mit Quetzal sind Sensoren 

darstellbar, die über Eingänge an den Bausteinen auch geändert werden 

können. 

Die Umgebungen wurden laut [09] mit neun Schülern der 1. und 2. Klasse in 

einem einwöchigen Projekt („Dinosaurs and Robots“) evaluiert. Nach einer Einleitung 

arbeiteten die Schüler selbstständig mit Quetzal und Tern. Alle Schüler 

dieser Altersstufe konnten Programme erstellen, einige Vorhersagen treffen und 

Fehler erkennen. Das Roboterverhalten konnten im Vorfeld nicht alle Schüler 

vorhersagen, manche hatten die Ablaufssequenzen nicht vollständig verstanden. 

Wegen dieser Ergebnisse wird das Projekt momentan noch weiterentwickelt. 

Von den Entwicklern ist eine weitere Evaluation mit Schülern der 5. – 8. Jahrgangsstufe 

geplant. 

3 http://www.swisseduc.ch/informatik/karatojava/kara/materialien.html (zuletzt aufgerufen am 

30.09.08)


2.2.2 Graphische Programmiersoftware zur Spiele-Entwicklung 

Der folgende Beitrag ([19]) ist beim Wettbewerb für Unterrichtsbeispiele 2007 in 

Siegen mit dem ersten Preis ausgezeichnet worden. In dieser Quelle wird von 

R. Romeike ein kreativer Einstieg in die Programmierung durch die Gestaltung 

von Animationen und Spielen beschrieben. Als didaktische Basis seines Konzepts 

dienen R. Romeike die informatischen Bildungsstandards. 

Der Autor stellt in seiner Veröffentlichung das Programm „SCRATCH“ 4 

(Abbildung 5) vor, welches einen imperativen Ansatz zur objektorientierten Programmierung 

verfolgt. „SCRATCH“ ist eine grafische Entwicklungsumgebung, 

bei der Programme (Skripte) für Objekte (Sprites) geschrieben werden, die deren 

Attribute verändern. Die „Sprites“ können Botschaften versenden und damit 

andere Objekte steuern. Die Anweisungen und Kontrollstrukturen werden von 

dem Benutzer als bunte Bausteine zu komplexeren Programmen zusammengefügt. 

Zielgruppe der Programmentwickler von „SCRATCH“ waren vorerst Grundschüler, 

die Software könnte aufgrund ihrer intuitiven Herangehensweise an die objektorientierten 

Prinzipien auch für die Sekundarstufe I und II oder für Einstiegskurse 

an Universitäten interessant sein. 

Abbildung 5: Arbeitsoberfläche von SCRATCH 

R. Romeike entwickelte zu „SCRATCH“ eine 12-stündige Unterrichtssequenz, 

die er mit einem Grundkurs der 11. Klasse an einem Gymnasium durchführte. 

Ziele dieser Einheit waren beispielsweise die „Entwicklung eines grundlegenden 

Programmierverständnisses“, „Beschreibung, Analyse und Darstellung von Al- 

4 http://scratch.mit.edu (zuletzt aufgerufen am 30.09.08)

- 8 - 


gorithmen“, „Entwurf und Implementierung von SCRATCH Programmen“ und 

die Entwicklung verschiedener „Prozesskompetenzen“. 

Die Teilschritte der Unterrichtssequenz sind in Tabelle 2 zusammengefasst. 

Thema der 

Unterrichtseinheit 

Einführung in 

Programmoberfläche 

Algorithmen und 

Ereignisbehandlung 

Interaktivität: 

Reaktion auf Benutzereingaben 

Methoden, 

Botschaften, 

Variablen, Berechnungen 

Mini-Projekt 

Leistungskontrolle 

Teilschritte 

Einführungstutorial: 

Beispiel für einen Animationsfilm 

Algorithmenthematisierung 

Bedingungsbaustein „Wenn“ als 

Ereignis-Auslöser 

gemeinsame Erarbeitung von Möglichkeiten 

der Benutzerinteraktion 

Verhaltensweisen von Objekten 

über Methoden, Kommunikation 

untereinander; lokale/globale Variablen 

und Rechenoperationen 

eigene Programmentwicklung eines 

komplexeren SCRATCH Spiels 

Abfrage theoretischen Wissens und 

praktischer Kompetenzen 

Schülerarbeitsaufträge 

Entwurf eines Animationsfilms 

(freie Themenwahl) 

Beispielskript erweitern; 

„Wenn“ Bedingungen einfügen, 

Skript vergrößern 

Animation des eigenen 

Namens mit interaktiver Steuerung 

Animation einer Tanzgruppe; 

Tänzer ändern Bewegungen 

nach Tanzlehrerkommando; 

Zählerstände, Tonwiedergabe 

Entwicklung eines Spiels (Einsatz 

aller gelernten Konzepte) 

Tabelle 2: Teilschritte zur Unterrichtssequenz mit SCRATCH 

Die Erfahrungen von R. Romeike waren durchweg positiv. Seine Schüler arbeiteten 

motiviert und engagiert mit dem Programm und stellten kreative Lösungen 

vor. Die Motivation ging sogar soweit, dass sie das Programm zu Hause installierten, 

oder bis in die Pausen an ihren Skripten arbeiteten. 

R. Romeike möchte in Zukunft auf dem Erreichten aufbauen und plant, seinen 

Schülern weiterführende Konzepte mit SQUEAK 5 zu vermitteln. 

2.2.3 Bewertung und didaktischer Kommentar 

Der Einsatz grafischer Programmiersoftware kann den Einstieg in die Programmierung 

erheblich erleichtern. Sprachkonvention und –syntax müssen bei 

den grafischen Entwicklungsumgebungen nicht beachtet werden. Die Grundfunktionen 

sind mit der Bausteinsymbolik auch jüngeren Nutzern zugänglich. 

Speziell in der Schule kann sich der Lehrer so auf die Vermittlung der Programmiergrundprinzipien 

und –strukturen konzentrieren. Die Schule kann durch 

den Einsatz solcher Software ihrem Allgemeinbildungsauftrag besser nachkommen. 

Die erlernten Grundkonzepte stellen die Basis für die Syntax einer 

Hochsprache. 

Ein Nachteil dieser Umgebungen ist ihr höherer Bedarf an Systemressourcen, 

was aber mit der rasanten Rechnerentwicklung wahrscheinlich nicht zu stark ins 

Gewicht fallen wird (vorausgesetzt, dass die Rechnerausstattung der Schulen 

dies ermöglicht). 

5 http://www.squeak.org/ (zuletzt aufgerufen am 30.09.08)


2.3 Wissenschaftliche Arbeiten zur Verwendung von Robotersystemen 

in der Bildung 

2.3.1 Roboter und Robotik in der Grundschule 

Der Roboterhund AIBO in der Primarstufe 

Die Quelle [02] beschreibt zwei Projekte der Sony Entertainment Roboter Gruppe, 

die den Roboterhund AIBO (Abbildung 6) mit entwickelt hat. Der AIBO wurde 

von Fachpersonal in der Programmiersprache C++ mit den zwei folgenden 

Verhaltensmustern ausgestattet und im Realversuch getestet. 

In der Funktion als „Geschichtenerzähler“ las AIBO die Geschichte einer Grundschülerin 

ihrer ganzen Klasse vor. Die Geschichte wurde im Tonstudio aufgenommen 

und mit unterschiedlicher Betonung (durch Lautstärkenregulierung), 

Gestik und Körpersprache des Roboters untermalt. 

Entgegen anfänglicher Befürchtungen hatte AIBO die uneingeschränkte Aufmerksamkeit 

der ganzen Klasse. Die Schüler folgten begeistert seinem Vortrag. 

„AIBO als Zuhörer“ hörte ausgewählten Grundschülern beim Lesen-Üben zu. In 

den Lesepausen lobte AIBO die Grundschüler. Seine Bewegungen und die 

Sprachausgabe blieben allerdings auf diese Pausen beschränkt, um Störungen 

durch AIBO zu minimieren. Das Ende des Textes kommentierte AIBO mit Tänzen 

und Spielen. 

Der Realversuch zeigte Probleme in den Algorithmen zur Geräuscherkennung 

(Lesepausen wurden falsch gedeutet, Mädchenstimmen teilweise schlecht erkannt). 

Die Schüler sahen AIBO insgesamt als Gesprächspartner an, ihr Drang 

mit dem Roboterhund zu spielen, war gering. 

Abbildung 6: Sony AIBO 

2.3.2 Bewertung und didaktischer Kommentar 

Diese Veröffentlichung zeigt die Einsatzvielfalt heutiger Robotersysteme. Ihr 

Einsatz kann bereits in der Grundschule außerhalb des Informatikunterrichts 

erfolgen. In diesem Stadium ist die Erforschung der unvoreingenommenen Interaktion 

zwischen Mensch und Maschine möglich. Eine elterliche Entlastung 

bei Hausaufgabenbetreuung und Übungsphasen durch zukünftige und besser

- 10 - 


ausgereifte Robotersysteme ist vorstellbar, allerdings wird bis zur Marktreife 

wahrscheinlich noch einige Zeit vergehen. 

Die Ergebnisse des Realversuchs zeigen, dass Robotersysteme in dieser Altersstufe 

in den Unterrichtsphasen der Motivation und Vertiefung erfolgreich 

einsetzbar sind. 

Aufgrund der aktuell hohen Preise leistungsstarker Robotersysteme (AIBO ca. 

5000 EUR 6 ) sind diese nur einem eingeschränktem Käuferkreis zugänglich und 

für den Bildungsbereich zu kostspielig. 

Die Programmierung ist bei den vorgestellten flexiblen menschlichen Verhaltensmustern 

zudem noch nicht ausgereift und nur durch Fachpersonal zu bewältigen. 

Es ist vom jetzigen Stand der Technik noch ungewiss, ob umfassendere 

Lehraufgaben (z.B. Korrektur von Lesefehlern) zukünftig von Robotern 

geleistet werden können. 

Der AIBO wird laut Sony 7 nicht mehr hergestellt und ist nur noch im Restbestand 

bei ausgewählten Roboter-Shops im Internet oder gebraucht zu beziehen. 

2.3.3 Robotergestützte Vermittlung informatischer Konzepte der Sekundarstufe 

Die Entwicklung von „Eingebetteten oder so genannten Embedded Systemen“ 

und Robotersystemen ist in den letzten Jahren stark vorangeschritten. Dies 

kann zur Folge haben, dass der Einsatz solche Systeme auch in den Bereichen 

der schulischen Bildung zunehmen wird. Der Autor hat für die vorliegende Arbeit 

Quellen zu diesem Einsatz recherchiert und sie in die Kategorien Fachübergreifende 

Konzepte, Algorithmenmodellierung/weitere Konzepte, und Robotersysteme 

in außerschulischen Lernorten eingeteilt. 

2.3.3.1 Fachübergreifende Konzepte 

Unterrichtserfahrungen zur Einführung in die Objektorientierung mit Robotern 

von LEGO MINDSTORMS 

Die Literaturquelle [04] beschreibt eine Unterrichtsreihe von Ruth Dietzel und 

Tim Rinkens. Hier wurden die objektorientierten Konzepte „Vererbung“ und „Ereignis“ 

mit LEGO MINDSTORMS Robotern vermittelt und untersucht, ob die 

Begriffsbildung von „Objekt“ und „Klasse“ mit den Robotern erleichtert werden 

könnte. 

Als zusätzlicher Untersuchungsgegenstand wurden zwei Programme von Tim 

Rinkens („RCXDirectMode“ 8 und „RCXDownload“ 9 ) für die Laufzeitumgebung 

LEJOS 10 auf ihre Eignung für den Einsatz in der Schule getestet. 

6 http://www.robotstore.de/seiten/shop/index.php?tpl=double (zuletzt aufgerufen am 30.09.08) 

7 http://de.wikipedia.org/wiki/Aibo (zuletzt aufgerufen am 30.09.08) 

u. http://support.sony-europe.com/aibo (zuletzt aufgerufen am 30.09.08) 

8 Programm zur direkten (An-)Steuerung des RCX Roboters über eine Kabelverbindung 

9 Programm zum direkten Überspielen der LEJOS Programme auf den RCX Baustein 

http://rcxtools.sourceforge.net/d_home.html (zuletzt aufgerufen am 30.09.08) 

10 Software für LEGO RCX, nutzt die objektorientierte Sprache JAVA zu Programmierung 

http://lejos.sourceforge.net/index.php (zuletzt aufgerufen am 30.09.08)


Die beteiligten Schüler der Untersuchung hatten bis zu diesem Zeitpunkt nur 

(Anwendungs- und Programmier-) Vorkenntnisse für die listenorientierte Sprache 

LOGO 11 . 

Die Unterrichtsreihe wurde mit 16 Schülern der Jahrgangsstufe 10 eines Differenzierungskurses 

Informatik an einem Gymnasium durchgeführt und umfasste 

nach einer Einführung insgesamt sechs handlungsorientierte Phasen. 

Zuerst sollten die Schüler einen Roboter konstruieren, der fahren kann und zwei 

Sensoren hat. Diese Aufgabe wurde in einer Gruppenarbeit zu fünf Schülern 

realisiert, bei der die Schüler zusätzlich die Selbstorganisation und Aufgabenteilung 

(Materialverantwortlicher, Sprecher, Konstrukteur) übten. Die Probleme 

dieser Aufgaben zeigten sich darin, dass die Konstruktion über Versuch und 

Irrtum sehr zeitaufwendig war und es zu Abspracheproblemen in den Gruppen 

kam (problematische Gruppengröße). Die Lehrer stellten die Roboter schließlich 

nach drei Unterrichtsstunden selbst fertig. 

Im Anschluss erfolgte zur Zwischenmotivation ein Funktionstest der Roboter mit 

Hilfe des Programms „RCXDirectMode“. 

Die nächste Phase war eine (mögliche) Einführung der objektorientierten Programmierung. 

Die Schüler beschrieben ihren Roboter mit verschiedenen Merkmalen 

(Aufbau, Mechanik, Funktionen) so genau wie möglich und stellten ihn 

den anderen vor. Die vier Roboterbeschreibungen bildeten die Basis für den 

Objektbegriff „Roboter“. Die Lehrer führten die Begriffe Attribut und Dienst ein 

und gaben eine Schablone mit Beschreibungskriterien vor. Nach einer Modifikation 

der vorherigen Schülerbeschreibungen wurde der Klassenbegriff und die 

UML Darstellung aus neuen Beschreibungen erarbeitet. 

In der anschließenden Phase sollten die Schüler ein Testprogramm für LEJOS 

dekonstruieren und mit „RCXDownload“ auf ihre Roboter übertragen und testen. 

Die Dekonstruktion umfasste Aufgaben wie Analyse und Kommentierung 

des Beispielprogramms und Modifikation der Nachrichtenmeldungen des RCX 

Bausteins. Diese Phase sollte die Festigung der erarbeiteten Begriffe sicherstellen. 

In der vierten Phase wurde das Vererbungskonzept erarbeitet und realisiert. Die 

Schüler sollten ihren Roboter ein Quadrat fahren lassen. Sie erhielten von den 

Lehrkräften hierfür zwei Beispielprogramme (eine Klasse für Vor- und Rückwärtsbewegung 

und eine zur Rechts-Links Drehung). Die Vererbung der Methoden 

aus den Klassen „Gehe Vor“ und „Gehe Links“ zur Klasse „Gehe Quadrat“ 

wurde gemeinsam unter Anleitung durch die Lehrkräfte vorgenommen und 

anschließend getestet. 

In der vorletzten Phase führten die Lehrer die Ereignisbehandlung ein. Bei der 

Problemstellung „Roboter soll selbstständig durch ein Labyrinth fahren“ lernten 

die Schüler den Tastsensor kennen. Zuerst sollten die Schüler die Aufgaben 

und das Verhalten des Tastsensors algorithmisch formulieren und ihn danach in 

vorgegebene UML Diagramme einbauen. Seine Funktion wurde anschließend 

in einem Labyrinth getestet. In der Abschlussproblemstellung „Roboter kann 

einer Linie folgen“ übten die Schüler den Transfer vom Tastsensor auf einen 

Lichtsensor. 

11 http://matroid.optimath.de/logomain.html (zuletzt aufgerufen am 30.09.08)

- 12 - 


Die letzte Phase sollte die erarbeiteten Begriffe und Strukturen abschließend 

sichern. Eine komplexere Quellcodeanalyse der Schüler zeigte gutes Grundverständnis 

über Objektorientierung und sicheren Umgang mit den gelernten 

Fachbegriffen. 

Die Autoren bewerteten den Einsatz des Robotersystems in ihrer Unterrichtsreihe 

als ausbaufähigen Versuch, um informatische Konzepte zu vermitteln. 

Die Robotersysteme waren (laut [04]) sehr motivationsfördernd für die Schüler, 

die sich nicht von den neuen Konzepten einer unbekannten Programmiersprache 

abschrecken ließen. Die Realmodellexistenz durch den Roboter erleichterte 

der Klasse die Abstraktion zur modellorientierten Programmierung. Auch die 

grundlegenden Konzepte der Ereignisbehandlung ließen sich leichter vermitteln. 

Die zugehörige programmtechnische Umsetzung und Quellcodeentwicklung 

erwies sich als sehr komplex und wurde von den Lehrern vorgegeben. 

Die eingesetzte Software „RCXDirectMode“, „RCXDownload“ und „LEJOS“ 

wurde intuitiv richtig von den Schülern angewandt und bedient. 

Zugänge zur Informatik mit MINDSTORMS Robotern 

Der Artikel „Zugänge zur Informatik mit MINDSTORMS – mit LEGO Robotern in 

der Sek. I spielerisch ein Informatiksystem entdecken und gestalten“ ([15]) der 

Fachzeitschrift „Log In“ fasst die Ergebnisse von Lehrveranstaltungen aus drei 

Semestern der Arbeitsgruppe (AG) “Didaktik der Informatik“ der Uni Paderborn 

zusammen. In dieser AG erarbeiteten Lehramtsanwärter die Bedeutung des 

Themas Roboter für den Informatikunterricht der Sekundarstufe I. 

In vielen gymnasialen Lehrplänen der Klasse 10 bietet sich das Thema „Messen, 

Steuern und Regeln“ für die Gestaltung mit Robotern an. Hierzu sind vier 

Schwerpunkte für den Unterricht aufgelistet. Erstens der Einsatz von Robotern 

und die automatisierte Produktion mit ihren resultierenden gesellschaftlichen 

Auswirkungen. Zweitens die Problemalgorithmisierung von elementaren Algorithmen 

zum Steuern und Regeln. Drittens die Informationsverarbeitung und 

deren Übermittlung mit Hilfe von Infrarot-Codierung und Parallelprozessverarbeitung. 

Und abschließend die Vermittlung von Modellierungstechniken mit 

Robotern als autonome eingebettete Systeme. 

Im Anschluss an theoretische Vorüberlegungen wird in der Quelle noch eine 

Unterrichtseinheit „Basketball“ skizziert, bei der ein handgesteuerter (interaktiver) 

Roboter einen Ball in einen Korb am Rande eines Spielfeldes werfen muss. 

Die Einheit hat folgende Ziele: 

- Einführung in elementare Techniken des (objektorientierten) Modellierens 

- Fragen der gesellschaftlichen Auswirkungen des Robotereinsatzes 

- Ein Informatiksystem als eingebettetes System kennen lernen und einen 

Einblick in die interdisziplinäre Verflechtung des Faches bekommen 

- Erlernen des Umgangs mit (visuellen) Entwicklungsumgebungen 

- Entwickeln von elementaren Steuerungsalgorithmen 

- Codierung von Algorithmen in einer einfachen Programmiersprache 

- Mittels Konstruktion und Dekonstruktion von Software Zugänge zu Problemen 

der Softwareentwicklung gewinnen


Die Unterrichteinheit ist in folgende acht Phasen unterteilt: 

Nr. 

1 

2 

3 

4 

Thema 

Themeneinführung (Film, etc.); Vorführung eines LEGO Roboters; 

Erkunden der Mechanik und der Aufgabenstellung „Basketball“ 

Modellierung wesentlicher Aspekte des Gesamtsystems: 

Festlegen der Roboterfunktionen und des Roboterumfeldes 

Einführung in die Entwicklungsumgebung; Erkunden der Motorfunktionen, Sensorrückmeldungen 

und der Handsteuerung des Robotermodells 

Analyse der interaktiven Steuerung; Fixierung von Steuerbefehlen; Dekonstruktion der 

Benutzeroberfläche „Robot Control Center (RCC)“ 

5 Optional: Bau eines problembezogenen Roboters (außerhalb des Unterrichts) 

6 

Entwicklung elementarer Steueralgorithmen in Abhängigkeit der verwendeten Technik; 

Kontrollstrukturen; (evtl. Einüben objektorientierter Sichtweisen) 

7 Arbeit mit dem RCC Interface: Programmieren, Testen, Verbessern der Algorithmen 

8 Ergebnispräsentation: Vergleich und Analyse der unterschiedlichen Lösungen 

Tabelle 3: Phasen der Unterrichtseinheit Basketball 

Die Autoren berichten in der Quelle auch von ihren praktischen Erfahrungen mit 

altershomogenen und –heterogenen Schülergruppen der Jahrgangsstufen 5-10. 

Die altersheterogene Gruppe von 16 Schülern führte in zwei Kompaktveranstaltungen 

die Unterrichtseinheit „Basketball“ durch und untersuchte weitere 

Problemstellungen mit dem MINDSTORMS Robotics Invention System (RIS) 

als Entwicklungsumgebung. Das Bauen der Roboter hatte hohe motivationale 

Wirkung und speziell die Mädchengruppe war besonders engagiert in Mitarbeit 

und Design ihres Roboters. 

Bei den altershomogenen Gruppen stellten die Autoren nur wenige Unterschiede 

bei Konstruktion der Mechanik und Stabilität fest. Große Unterschiede ergaben 

sich hingegen bei der Algorithmenerstellung, Effizienz und Leistungsfähigkeit. 

Diese Unterschiede sind wahrscheinlich durch größeres Vorwissen begründet 

und könnten mit differenzierenden Aufgaben kompensiert werden. 

2.3.3.2 Bewertung und didaktischer Kommentar 

Die Quelle [04] beschreibt, wie man mit Robotersystemen die Objektorientierung 

im Informatikunterricht einführen kann. In dieser Publikation wird das Problem 

des Zeitverlustes durch den Zusammenbau von MINDSTORMS Robotern 

durch Schüler deutlich. Für die Quellcodeanalyse wurde auf vorgegebene Programmbeispiele 

zurückgegriffen, so dass die Objektorientierungskonzepte 

größtenteils (je nach Art und Umfang der Modifikationsaufgaben für die Schüler) 

ohne Syntaxprobleme vermittelt werden konnten. 

Eine derartige Einführung stellt allerdings neben dem Zeitfaktor für die Unterrichtsplanung 

auch an die Robotersysteme spezifische Anforderungen, die nicht 

alle Systeme aus dem Überblick in Kapitel 2.1 erfüllen. Ein entscheidendes Kriterium 

ist eine für den Unterricht geeignete (Programmier-) Software, welche 

auf einer objektorientierten Sprache basieren muss. Derzeit bietet das LEGO 

MINDSTORMS ein dazu geeignetes Werkzeug (LEJOS). Eine objektorientierte 

Modellierung mit Beispielprogrammen zur Softwaredekonstruktion und Implementierung 

ist folglich mit LEGO MINDSTORMS (RCX und NXT) möglich.

- 14 - 


Wird hingegen auf die Quellcodeanalyse und Implementierung verzichtet, müssen 

die Robotersysteme ein weiteres Kriterium erfüllen, um die Objektorientierung 

modellieren zu können. Ihr Aufbau muss so variabel gestaltet werden können, 

dass sich aus unterschiedlichsten Robotertypen (z.B. Linienverfolger, Labyrinthlöser, 

Bagger, Lichtsucher, etc.) gemeinsame Objektattribute ableiten 

lassen. Hiermit könnten die Schüler einzelne Roboterobjekte zu Roboterklassen 

zusammenfassen und somit objektorientierte Konzepte vermittelt bekommen. 

Hierfür geeignete Robotersysteme könnten gemäß der Tabelle 1 das ROBO- 

BOX System, der BOE BOT und der MA-VIN sein. 

Das Scribbler-System ist in seinem Aufbau wahrscheinlich nicht variabel genug, 

um dieses Kriterium zu erfüllen. Eine Einführung in die Objektorientierung mit 

diesem System würde eventuell „zu konstruiert“ ablaufen. Die Kennzeichen der 

Objektorientierung könnten u. U. für die Schüler nicht deutlich genug gezeigt 

werden. Das System würde dabei wahrscheinlich, trotz seiner motivierenden 

Wirkung, nicht den schüler- bzw. adressatengerechten Transfer des Konzepts 

erleichtern können. 

Aus [15] wird deutlich, dass heutige Robotersysteme dem Lehrer die Möglichkeit 

geben, die Interdisziplinarität des Fachs Informatik darzustellen. Bei diesen 

eingebetteten Systemen gibt es immer eine wechselseitige Abhängigkeit der 

Effizienz von mechanischen Komponenten, Softwareprodukt und verwendeter 

Hardware. Eine funktionsfähige Programmkonstruktion bei Robotersystemen 

schließt immer eine gründliche und problembezogene Mechanik-Entwicklung 

mit ein. Die Robotersysteme bieten dem Lehrer hier die Möglichkeit, auf anschauliche 

Weise Kooperationsfelder der Informatik, Mechatronik und der Ingenieurswissenschaften 

zu zeigen. Modellieren im Informatikunterricht kann durch 

Beschreibung und Gestaltung von Technik des Roboters und der technischen 

Struktur des Einsatzumfeldes erfolgen. Die verwendete Software modelliert die 

Algorithmenentwicklung, Codierung und Implementierung. 

Der offensichtliche Nachteil der MINDSTORMS Roboter ist der bereits in Quelle 

[04] erwähnte Zeitverlust beim Roboterbau. Als Lösung schlagen J. Magenheim 

und seine Kollegen vor, die Montage in Kleingruppen am Nachmittag vorzunehmen 

oder den Nachbau anhand fertiger oder selbst erstellter Roboterbaupläne 

12 . Der Verfasser hat jedoch die Erfahrung gemacht, dass die softwaregestützte 

Erstellung von Bauplänen sehr langwierig und arbeitsintensiv sein kann. 

Der Autor dieser Arbeit hat sich selbst intensiv mit dem Eigenbau von Robotermodellen 

beschäftigt und hat auch versucht, fertige Baupläne auf neue Problemstellungen 

zu übertragen. Der zeitliche Aufwand ist bei beiden Varianten 

nicht zu unterschätzen. Aufbauanleitungen für Roboter findet man im Internet 

zu genüge 13 . Leider sind diese Anleitungen manchmal fehlerhaft oder müssen 

angepasst werden (Problem mangelnder Teile aus Spezialbaukästen). Der Lehrer 

müsste, um die Realisierbarkeit und den Zeitbedarf einschätzen zu können, 

12 Freeware zur Erstellung von Bauplänen unter 

http://ldd.lego.com/ (zuletzt aufgerufen am 30.09.08) 

http://www.lm-software.com/mlcad/ (zuletzt aufgerufen am 30.09.08) 

13 http://www.oreilly.de/catalog/lmstormsger/anleitungen/index.html (zuletzt aufgerufen am 

30.09.08) 

http://www.mindstormsforum.de/ (Kategorie Baupläne) (zuletzt aufgerufen am 30.09.08) 

http://www.lego-in-der-schule.de/lego-learning-blog-1/neu-lehrerhandbuch-lego-mindstormseducation-nxt 

(zuletzt aufgerufen am 30.09.08)


die Modelle vorher einmal aufbauen. Dies hat zur Folge, dass der Zeitbedarf 

vom Unterrichtsgeschehen in die Vorbereitungsphase verlagert wird. 

Der Einsatz von Robotersystemen hat laut [15] eine weitere praktische Vorraussetzung, 

die sich ebenfalls auf den Zeitbedarf auswirken kann. „Entdeckendes 

und Selbstgesteuertes“ Lernen sollte eine etablierte Unterrichtsform im 

Informatikunterricht sein. Schüler müssten bereits Erfahrungen hinsichtlich 

Selbstorganisation, verantwortungsvollem Umgang mit Materialien und Gruppenarbeit 

gemacht haben. 

Dann könnten Robotersysteme starke motivationale Komponenten (Spaß am 

spielerischen und entdeckenden Lernen eines Robotersystems) haben und die 

mediale Qualität des Lernprozesses fördern (Schüler erhalten direkte visuelle 

Rückkopplung ihrer Problemlösungen). 

2.3.3.3 Algorithmenmodellierung und weitere Konzepte 

Modellierung von Sortieralgorithmen mit Robotersystemen 

Die Quelle „Sorting out Sorting through Concretization with Robotics“ ([12]) beschreibt 

eine Realisierung und Visualisierung des Bubblesort-Algorithmus durch 

LEGO MINDSTORMS Roboter. 

Hierzu wurde in einem Robotermodell (Kontrolleinheit) der Bubblesort Algorithmus 

implementiert. Dieser Roboter sollte ein gespeichertes Array von Zahlen 

sortieren. Bei jedem Vergleich der Zahlen des Arrays wurden von der Kontrolleinheit 

zwei zusätzliche Roboter aktiviert. Sie übermittelte an die anderen Roboter 

die (Variablen-) Werte des Arrays und die Array-Positionen der zu sortierenden 

Zahlen (linke und rechte Rolle). Die anderen Roboter nahmen ihre Positionen 

ein und verglichen ihre Werte über den Infrarotport. Je nach zugewiesenem 

Wert und Position (Rolle) tauschten die Roboter ihre Positionen selbstständig 

und sendeten eine Nachricht an die Kontrolleinheit. Diese quittierte die 

Meldungen und änderte die Positionen der Arraywerte gemäß den erhaltenen 

Meldungen. Nach Komplettsortierung des Arrays beendete die Kontrolleinheit 

das Programm und versetzte die zwei anderen Roboter wieder in den Standby 

Zustand. Dieses Vorgehen ist schematisch in Abbildung 7 und Abbildung 8 dargestellt. 

Abbildung 7: Ablaufschema einer Sortierung

- 16 - 


Abbildung 8: Kommunikation zwischen Kontrolleinheit und Robotern 

Der Realversuch ist mit fünf 13 bis 15 jährigen Schülern eines Computerclubs 

durchgeführt worden. Nach einer theoretischen Analyse der Vorkenntnisse 

wurde ein meist intuitiver und algorithmenfreier Sortiervorgang durch die Schüler 

durchgeführt. Anschließend präsentierten die Roboter den Bubblesort- 

Algorithmus. Mit einer Vorhersage des Roboterverhaltens auf vier neue Situationen 

zeigten die Schüler ihr Verständnis. Abschließend sortierten sie beispielhaft 

einige Kisten nach dem gezeigten Algorithmus. 

Als Ergebnisse stellten die Autoren fest, dass die Schüler mit großem Interesse 

und hoher Aufmerksamkeit der Bubblesort-Präsentation durch die Roboter folgten. 

Das Verhalten konnten alle Schüler bei drei Situationen komplett richtig 

vorhersagen, bei einer Situation lagen zwei Schüler falsch. Die Beschreibung 

und Verbalisierung des Algorithmus gelang zwei Schülern komplett richtig, einem 

teilweise und den letzten beiden nur vage. Der eigene Sortiervorgang nach 

Algorithmus konnte von allen richtig durchgeführt werden. 

Roboterprojekte „STEP“ und „P2W“ für High School Schüler 

In der Publikation [06] berichten die Autoren Goldman, Eguchi und Sklar von 

ihren Erfahrungen bei den Projekten „Science and Technology Entry Program“ 

(STEP) und „Playing2Win“ (P2W) vom New Yorker Sommer Ferienprogramm 

2003. 

STEP 14 dauerte fünf Wochen, in denen sich zwei Klassen zu jeweils zwölf 

Schülern zweimal pro Woche in 90-minütigen Einheiten trafen. An einem Tag 

der offenen Tür, am Programm-Ende, wurden die Ergebnisse den Eltern präsentiert. 

P2W 15 fand im Anschluss als sechswöchiges Programm statt. Hier arbeiteten 

ca. 20 Schüler in zwei Klassen zweimal pro Woche in je 120 Minuten- 

Einheiten. 

14 http://www.highered.nysed.gov/kiap/step/step.htm (zuletzt aufgerufen am 30.09.08) 

15 http://www.playing2win.org - im Aufbau - (zuletzt aufgerufen am 30.09.08)


In den Kursen wurde das LEGO MINDSTORMS RCX System mit Licht- und 

Tastsensor sowie die zugehörige Robolab-Programmiersoftware (RL) verwendet. 

Zusätzlich bekamen die Schüler die Handbücher „Tipps und Tricks zu RL“ 

und „Cheat Sheet“ (Iconübersicht der Programmiersprache) als weiteres Arbeitsmaterial 

(beide von der Universität Columbia 16 entwickelt). Zudem wurden 

eigene Magnettafeln zur Visualisierung der RL-Programme für den Unterricht 

durch die beteiligten Lehrer entwickelt (ähnlich den von LEGO entworfenen „RL 

Icon Magnets“ 17 ). 

Die beiden Projekte gliederten sich in drei Phasen, die Konstruktion, Programmierung 

und Anwendung. 

In der ersten Phase sollten die mechanischen und technischen Hintergründe 

von Designprinzipien vermittelt werden. Die Schüler bauten dazu zwei LEGO 

Modelle, ein Go-Kart und einen Roboter (Abbildung 9). Sie sollten in dieser 

Phase die Unterschiede zwischen manuell- und maschinengesteuerten Fahrzeugen 

erkennen. Als mathematischer Lehrstoff wurden Berechungen und statistische 

Auswertungen der Reichweite bei der freien Fahrt des Go-Karts von 

einer Rampe aus vermittelt. 

Abbildung 9: Gokart und Roboter 

In der Phase der Programmierung fand die Vermittlung verschiedener Programmierkonstrukte 

(z.B. Schleifen, Prozesssteuerung von Abläufen, Eventmanagment, 

etc.) statt. Sie war unterteilt in die Bereiche: Basisprogrammierung 

und die Programmcodeentwicklung zu Tast- bzw. Lichtsensoren. Die Schüler 

veränderten vorgegebene Programmkonstrukte und passten sie in Gruppenarbeit 

an modularisierte Wettbewerbsszenarien an. 

In der letzten Phase sollten die erworbenen Erkenntnisse in einem Abschlusswettbewerb, 

der „Cup Challenge“ (Roboter muss weiße Plastikbecher aus einer 

markierten Arena schieben) angewendet werden. Die Aufgaben für die Schülergruppen 

waren die selbstständige Entwicklung und der Test von Algorithmen 

zur Problemlösung. 

Die Publikation beinhaltet zwei Abschlussuntersuchungen, in denen die Mentoren 

und die Teilnehmer zu ihren Erfahrungen befragt wurden. 

16 http://tip.columbia.edu/index.php?option=com_content&task=view&id=18&Itemid=41 (zuletzt 

aufgerufen am 30.09.08) 

17 http://www.legoeducation.com:80/store/detail.aspx?CategoryID=159&by=9&ID=356&c=1&t=0 

&l=0 (zuletzt aufgerufen am 30.09.08)

- 18 - 


Als Mentoren für die High School Schülergruppen arbeiteten studentische Hilfskräfte. 

Diese verfügten über geringe Lehrerfahrungen mit Schülern dieser Altersgruppe. 

Sie stellten gravierende Unterschiede in Wissen und Motivation bei 

den Schülern fest und waren deshalb gezwungen bei schweren Problemen 

Schritt für Schritt Anleitungen zu geben. Der Hauptkritikpunkt der Studenten 

waren die großen technischen Probleme bei der eigenen Einarbeitung und die 

Umsetzung der Aufgabenstellungen. Sie äußerten den Wunsch eines Intensiv- 

Workshops durch geschultes Personal vor den „STEP“ und „P2W“ Kursen. 

Die Teilnehmer wurden in einem Anfangs- und Abschluss-Interview zu ihrem 

Stand der mathematischen Fähigkeiten, Problemlösekompetenzen und mathematisch 

naturwissenschaftlichen Interessenlagen befragt. Hierbei konnte eine 

leichte Korrelation zwischen Computernutzungshäufigkeit (auch außerhalb der 

Bildung, z.B. Computerspiele) und Fähigkeiten zur Bearbeitung von informatischen 

Problemstellungen festgestellt werden. Die Autoren vermuteten außerdem 

noch leichte Hemmungen im Umgang mit dem PC in dieser Altersstufe. 

Am Ende der Projekte wurden ein gestiegenes Selbstbewusstsein und der Abbau 

der Anfangshemmungen im Umgang mit informatischen Problemstellungen 

deutlich. Diese Entwicklung führten die Autoren auf die mit den Robotersystemen 

bearbeiteten Aufgabenstellungen zurück. Aufgrund der Größe der Untersuchungsgruppe 

ist eine solche Schlussfolgerung statistisch wahrscheinlich 

nicht haltbar und wenig repräsentativ. 

Robotergestützte Vermittlung algorithmischer Grundkonzepte 

Ausgangspunkt der Literaturquellen [24] und [25] war der - in allen Unterrichtsfächern 

- oft thematisierte Mangel an Problemlösekompetenz von Schülern. 

Schülerinnen und Schüler sind demnach zu wenig in der Lage, ungewohnte 

Aufgabenstellungen zu verstehen, sich Lösungsstrategien zu überlegen und 

diese zu verfolgen. T. Brinda und B. Wiesner entwickelten mit Studenten an der 

Universität Erlangen-Nürnberg eine Unterrichtssequenz, die als Möglichkeit zu 

verstehen ist, Lernende mit dem Strukturieren von Handlungsabläufen (als Teil 

von Problemlösestrategien) vertraut zu machen. 

Die Schülerinnen und Schüler sollten nach der Unterrichtssequenz folgende 

Lernziele erreicht haben. Die Schüler: 

- wissen, was Roboter sind und verstehen, dass ihr Verhalten von einem Programm 

gesteuert wird. 

- wissen, dass Sensorwerte benutzt werden, um Programmabläufe zu steuern. 

- kennen die Grundstrukturen Sequenz, Wiederholung, Verzweigung und können 

sie zur Lösung von Aufgaben verwenden. 

- kennen den Algorithmusbegriff als Handlungsablauf und können einfache Aktionen 

in Struktogrammform 18 beschreiben. 

Die entwickelte Unterrichtssequenz wurde in acht Teile unterteilt, für die sieben 

bis neun Doppelstunden vorgesehen waren. Diese Sequenz wurde in dieser 

Form (Tabelle 4) zum ersten Mal im Schuljahr 2006/07 in der 9. Jahrgangsstufe 

einer Erlanger Realschule im Rahmen eines Studienbegleitenden Praktikums 

erprobt. An diesem Praktikum waren insgesamt 14 Schüler (vier Mädchen und 

zehn Jungen), zwei Betreuer und drei Studierende beteiligt. 

18 http://de.wikipedia.org/wiki/Struktogramm (zuletzt aufgerufen am 30.09.08)


Nr. Thema 

1 

2 

3 

4 

5 

6 

7 

8 

Einführung in das Projekt und Bau des Roboterfahrzeugs: 

Definition d. Roboterbegriffs, erster Kontakt zu LEGO MINDSTORMS, Fahrzeugbau 

Strategie zum Lösen eines Problems: 

Modellieren eines vorgegebenen Ablaufs mit Hilfe vorgegebener (elementarer) Anweisungen, 

Begriffseinführung (Befehlssatz, Anweisung, Sequenz u. Wiederholung) 

Bedingte Handlungen: 

Einbau eines Lichtsensors; Aufgabenmodellierung u. –programmierung, Lichtwertgesteuerte 

Abläufe, Begriffseinführung: bedingte Anweisung u. Verzweigung 

Bedingte Wiederholungen: 

Modellieren und Programmieren einer Aufgabe, in der ein Ablauf so lange wiederholt 

wird, bis eine Bedingung eintritt, Einführung des Begriffs „bedingte Wiederholung“ 

Abläufe grafisch darstellen: 

Darstellen von Abläufen mit Struktogrammen 

Strategie zum Verlassen eines Labyrinths: 

Strategien zum Finden eines Wegs aus einem Labyrinth, Modellieren und Programmieren 

eines entsprechenden Algorithmus, Definition des Algorithmusbegriffs 

Übungszirkel: 

Wiederholen und Festigen der vorherigen Lernziele in einem Übungszirkel 

Ergebnispräsentation und Zusammenfassung: 

Präsentationserstellung (Optional als Hausarbeit) 

Tabelle 4: Teile der Unterrichtssequenz 

Die Schüler waren für das Material selbst verantwortlich und bauten Roboter 

nach einer Anleitung auf. Als zentrale Problemstellung sollten die Roboter mit 

Hilfe algorithmischer Grundstrukturen (bedingte Anweisungen, Wiederholungen) 

selbstständig den Weg durch ein vorgegebenes Labyrinth (Abbildung 10) 

finden. 

Abbildung 10: Verwendetes Labyrinth beim Labyrinthlöse-Algorithmus 

Der Leistungsstand der Lernenden wurde über mehrere Ebenen geprüft: 

- Eine benotete Stegreifaufgabe 19 

- Die Schlusspräsentation und ein Bookletbeitrag 

- Die Qualität der Unterrichtsbeiträge und die praktische Arbeit im Team 

- Die Anzahl der richtig bearbeiteten Übungsaufgaben im Übungszirkel 

19 http://algo.robinfun.de/ue3/stegreifaufgabe.pdf (zuletzt aufgerufen am 30.09.08)

- 20 - 


Vier Wochen nach Ende des Praktikums wurde die Schülergruppe schriftlich zu 

der Sequenz befragt. Die Ergebnisse dieser Fallstudie 20 veranlassten die Autoren 

zu folgern, dass „mit der vorliegenden Konzeption ein gut geeigneter handlungsorientierter 

Zugang zum Verständnis algorithmischer Grundstrukturen gefunden 

wurde“. 

Beispiele der Schülerbefragung (Quelle [25]): 

- „Ich fand es gut, dass außer Roboter programmieren auch noch Informatikwissen 

durchgenommen wurde.“ 

- „Mit LEGO könnten die Aufgaben ruhig noch kniffliger werden.“ 

- „Durch den Unterricht mit den Robotern hat sich meine Einstellung zum 

Fach Informationstechnologie (IT) verbessert.“ 

In Zukunft planen B. Wiesner und T. Brinda eine Online Befragung von Lehrkräften 

zur Nutzung von Robotern im Informatikunterricht (IU) der Sekundarstufe 

1 durchzuführen. Danach soll eine Mustersequenz mit Begleitforschung folgen 

und der Robotereinsatz auf andere Themenbereiche des IU erweitert werden. 

Robotik in der Sekundarstufe I 

In der Quelle [22] beschreibt die Autorin Anja Tempelhoff ihre Erfahrungen, die 

sie an einer Berliner Realschule mit „Roberta“ Kursen ([22] S.31 ff.) gemacht 

hat. A. Tempelhoff absolvierte in einem regionalen „Roberta“ Zentrum eine 

Ausbildung zur Kursleiterin für „Roberta“ Kurse. Sie stellte in ihrem Informatikunterricht 

immer wieder fest, dass Mädchen und Jungen sehr unterschiedliche 

Herangehensweisen an informatische Probleme verfolgen und Mädchen augenscheinlich 

weniger begeisterungsfähig für das Fach Informatik sind. Aus 

diesem und ähnlichen Gründen führte sie (in Zusammenarbeit mit dem Regio- 

Zentrum der Berliner Humboldt Universität) mit Mädchen der neunten Klasse 

einen „Roberta“ Kurs durch. 

Der Kurs umfasste acht Stunden und die Teilnehmerinnen hatten vorher keinerlei 

Programmiererfahrungen gesammelt. Ihre Computertechnikvorkenntnisse 

waren sehr unterschiedlich und beschränkten sich meist auf Anwenderwissen 

der Textverarbeitung und auf Internetsuchmaschinen oder Chatfunktionen im 

Internet. Die Autorin wechselte im Kurs bewusst zwischen Erarbeitungsphasen 

und Präsentationsphasen ab, damit alle Teilnehmerinnen an den Fortschritten 

der unterschiedlichen Gruppen teilhaben konnten. 

Die Mädchen bauten ihre Roboter in Gruppen nach einer Anleitung auf. In dieser 

Phase musste A. Tempelhoff ihre Schülerinnen intensiv betreuen und ihnen 

häufig Hilfestellungen geben. Zur Programmierung der Roboter schreibt sie, 

dass ihre Schülerinnen zuerst sehr ungerichtet, spielerisch und selbstentdeckend 

vorgegangen sind. Erst nach einem Test der Programme mit den Robotern 

entwickelten sie Strategien und planten die folgenden Programmänderungen 

strukturierter. 

20 http://algo.robinfun.de/fallstudie.php (zuletzt aufgerufen am 30.09.08)


Die Gruppen arbeiteten an altersgerechten Aufgabenstellungen wie der Entwicklung 

zeitlich programmierter Handlungsabläufe, oder der Entwicklung einer 

Choreographie, bei der die Roboter Töne wiedergaben und „tanzten“. 

Aus dem Kurs entstand an der Hugo-Gaudig-Schule eine Roboter AG (Arbeitsgemeinschaft), 

deren Team schon diverse Erfolge bei Wettbewerben erreicht 

hat. So nahmen sie an der ersten deutschen Meisterschaft für Robotertechnik 

(RobocupJunior 21 ) in der Kategorie „RoboDance“ 22 teil und qualifizierten sich 

dabei für die Weltmeisterschaften in Japan. Bei dem „RoboDance“ Wettbewerb 

geht es darum, mit einer Gruppe und frei gestalteten Robotern eine Tanzchoreographie 

zu entwickeln und diese natürlich programmtechnisch möglichst geschickt 

umzusetzen. Die Mädchengruppe der neunten Klasse wurde sogar zum 

Tag der offenen Tür im Bundeskanzleramt eingeladen und durfte dort ihren Robotertanz 

präsentieren [22]. 

Die Autorin plant in Zukunft mit weiteren „Roberta“ Projekten noch mehr Mädchen 

für Robotertechnik begeistern zu können und mit neuen Teams an die 

vergangenen Erfolge bei Wettbewerben anzuknüpfen. Sie gibt in der Quelle an, 

der festen Überzeugung zu sein, dass „Roboter hohe intrinsische Motivation bei 

Mädchen auslösen und das Interesse an dem Fach Informatik steigern können“. 

Eine robotergesteuerte Legostein-Sortiermaschine 

Die vorliegende Maturaarbeit ([03]) wurde 2008 von Pascal Dessarzin am Deutschen 

Gymnasium Biel erstellt. In ihr beschreibt der Schüler den Bau eines Roboters 

(Abbildung 11), der LEGO Bausteine greifen und nach Farben sortiert in 

unterschiedliche Behälter ablegen kann. 

Der Roboter steuert hierbei einen Greifarm, der Steine von einem festgelegten 

Ort aufnimmt und diese dann vor einer Webcam positioniert. Die Bilddaten der 

Webcam werden von einem angeschlossenen Computer ausgewertet und je 

nach erkannter Farbe unterschiedliche Bewegungsabläufe an den Roboter gesendet, 

der den Stein schließlich ablegt. Eine ähnliche Kombination von Webcam, 

Computer zur Datenverarbeitung und Steuerung eines RCX-Robotersystems 

wird noch ab Seite 37 (Quelle [21]) beschrieben. 

Abbildung 11: Sortiermaschine der Maturaarbeit 

21 http://www.robocup-german-open.de/ (zuletzt aufgerufen am 30.09.08) 

22 http://www.robocup-german-open.de/de/leagues/junior/robodance (zuletzt aufgerufen am 

30.09.08)

- 22 - 


P. Dessarzin besuchte vor Erstellung der Arbeit einen Fakultativkurs zur Robotik 

und verfügte so über umfangreiches Vorwissen über den Bau und die Programmierung 

(LEGO RIS) von LEGO MINDSTORMS Robotern (RCX System). 

Der Schüler erläutert in seiner Arbeit ausführlich seine Schritte zur Ideenfindung 

beim Aufbau des Roboters und zur Lösung der mechanischen Probleme beim 

Bewegungsablauf der „Sortiermaschine“. Er beschreibt umfassend, welche verschiedenen 

Konzepte er im Zuge der Arbeit entwickelt hat und welche sich 

schließlich als annehmbare Lösungsmöglichkeit herauskristallisiert haben. 

Zur Programmierung des Roboters nutzte er die Software „Vision-Command- 

Centre“ 23 , mit deren Hilfe es ihm möglich war, Farberkennungsfelder zu definieren 

und entsprechende Programm-Aktionen auf Farbwerte folgen zu lassen. 

Neben einem Kapitel zu allgemeinen Problemen und Tipps zum Nachbau enthält 

die Arbeit auch einen Vergleich zu robotergesteuerten Montagesystemen. 

Zum Abschluss stellt P. Dessarzin ein robotergesteuertes Medikamentenlager 

inklusive automatischer Kommissionierung und Verwaltung vor. 

Robotersysteme zur Verwaltung RFID gekennzeichneter Waren 

In diesem Abschlussbericht einer Infomatikprojektgruppe [23] wird ein halbjähriges 

Projekt beschrieben, mit dem die Gesamtschule Haspe in Hagen am VDE 

Technikpreis 2007 teilgenommen hat. 

In dieser Gesamtschule werden im Informatikunterricht die Themen „Grundlagen 

der Maschinensteuerung“ (durch Konstruktion u. Programmierung von LE- 

GO MINDSTORMS Robotern) und „Datenschutz und Urheberrecht“ behandelt. 

RFID Chips (Radiofrequenz, also berührungslose Identifikation von Objekten 

per Funk 24 ) werden seit 2005 in deutschen Reisepässen verwendet, worin Datenschützer 

ein mögliches Sicherheitsrisiko sehen. Die Informatikgruppe wollte 

ein Projekt entwickeln, bei dem die o. g. Themen für den Informatikunterricht 

verknüpft werden. Den Schülern sollten die Grenzen und Risiken der RFID- 

Technik vermittelt werden. 

Sechs Schüler der neunten Klasse und ihr Lehrer entwickelten mit der FH Südwestfalen 

und der ETH Zürich ein selbstfahrendes Robotersystem, das RFID 

gekennzeichnete Waren verwalten kann (Abbildung 12). 

Abbildung 12: Roboter mit RFID Schreib/Leseeinheit und Kettenantrieb 

23 http://artdecom.mesh.de/projekte/werkzeuge/software/microcomputersensorik_familie/lego/ 

mindstorms-vision-command-frameset.html (zuletzt aufgerufen am 30.09.08) 

24 http://de.wikipedia.org/wiki/RFID (zuletzt aufgerufen am 30.09.08)


Die Projektgruppe entschied sich nach einer Analyse der möglicher Systeme 

(Vergleich von Asuro, LEGO MINDSTORMS und CT-Roboterbausatz) für das 

LEGO MINDSTORMS RCX System. Im Anschluss wurden die Sensorik thematisiert, 

ein Roboter konstruiert und gebaut. Die Schüler löteten anschließend 

einen RFID-Tagfinder-Bausatz (zur Erkennung sich in der Nähe befindlicher 

Transponder) und einen Bausatz für die RFID-Lese-und-Schreibeinheit zusammen. 

Bei der Komposition der Einzelmodule zu einem funktionsfähigen Gesamtsystem 

musste die Projektgruppe verschiedene Schnittstellenkompatibilitäten 

herstellen (z. B. RCX-Microcontroller und RS232-Schnittstelle der Lese- 

Schreib-Platine umlöten u. anpassen). 

Die Programmierung des Systems erfolgte in „Not Quite C“ (NQC – einem Dialekt 

der Hochsprache C) mit grafischer Oberfläche „Bricx Command Center“ 25 , 

die Projektdokumentation mit Hilfe des Projektplanungstools „Gantproject“ 26 . 

Die Schüler arbeiteten erstmalig mit der Software und hoben im Anschluss deren 

Benutzerfreundlichkeit positiv hervor. 

Der Projektgruppe gelang es bei der Abschlusspräsentation die Funktionsfähigkeit 

von Tagfinder und Robotersystem zu zeigen. Im zur Verfügung stehenden 

Zeitrahmen gelang es aufgrund der Systemunterschiede nicht, die Informationen 

des Transponders mit der Lese-Schreibeinheit in den RCX Baustein einzulesen. 

Beim VDE Technikpreis erreichte die Gesamtschule Haspe mit diesem Projekt 

eine Platzierung unter den ersten zehn. 


Die Algorithmenmodellierung durch Robotersysteme kann die Möglichkeit bieten, 

Programmabläufe schülergerecht zu visualisieren. 

In der Quelle [12] dienen die Roboter mit ihrem Verhalten als interessantes und 

neuartiges Modell für Sortiervorgänge. Schüler können sich bei der Betrachtung 

auf das Verständnis des Algorithmus konzentrieren und ihn abhängig von der 

Programmkomplexität unter Umständen auch abwandeln. Dadurch, dass der 

Roboter für Schüler eventuell interessant und spannend ist, kann die Schüleraufmerksamkeit 

entsprechend hoch sein. Es könnten deshalb auch komplexere 

Abläufe von Robotern modelliert werden, ohne dass sich die Schüler ablenken 

lassen. Die konstante Aufmerksamkeit könnte ein nachhaltigeres und umfassenderes 

Verständnis der Algorithmen bewirken. Die Attraktivität des Robotersystems 

könnte außerdem die Verständnisblockaden bei komplexeren Aufgabenstellungen 

für Schüler verringern. 

Die Quelle “Using educational Robots to engage inner City Students with technology” 

[06] zeigt eine Möglichkeit auf, wie Schüler in zeitlich begrenzten Ferienprogrammen 

Zugang zu Robotersystemen bekommen können. Die Schüler 

nahmen freiwillig aus Interesse für die Roboter an den Kursen teil. Die LEGO 

Roboter waren in den Projekten aber nur Medium zur Vermittlung von informatischen 

Grundkenntnissen und –fertigkeiten. Die Schüler konnten die Zusammenhänge 

zwischen den Fächern Mathematik (s. beschriebene Berechnungen 

und Statistikerstellung bzw. -auswertung), Physik (mechanische Prinzipien) und 

25 http://bricxcc.sourceforge.net/ (zuletzt aufgerufen am 30.09.08) 

26 http://ganttproject.biz (zuletzt aufgerufen am 30.09.08)

- 24 - 


Informatik (Programmierung) erfahren. Das Lernen von Fachwissen erfolgte 

hierbei außerhalb schulischen Notendrucks und geschah von den Schülern unbemerkt 

bei der Bearbeitung der Aufgaben. Der Erfolg in Hinblick auf Motivation 

und Abbau von Hemmungen ließe sich in einer Roboter AG als Anfängerkurs 

für leistungsschwache Schüler oder als Einstiegsunterrichtsreihe auf die Schule 

übertragen. 

In den Quellen [24] und [25] „Robotergestützte Vermittlung algorithmischer 

Grundkonzepte“ wurde speziell auf die Vermittlung von Konzepten der Algorithmik 

Wert gelegt. Der Robotereinsatz fand im Rahmen des normalen Informationstechnologie-Unterrichts 

(IU) statt, und unterlag deshalb anderen Bedingungen. 

Der Zeitfaktor und die Einbettung der Inhalte in den Lehrplan mussten 

berücksichtigt werden. Die Roboter wurden aus Zeitgründen nach Anleitung 

aufgebaut, die Schüler konnten ihre Roboter also nicht frei entwickeln. Deswegen 

könnte man erwarten, dass die Schüler weniger motiviert bei der Sache 

waren, da der individuelle Konstruktionsprozess durch Schüler nur nach Anleitung 

erfolgte. Die Ergebnisse der abschließenden Fallstudie widerlegten aber 

diese Befürchtungen. Für Schüler scheint allein das Medium „Roboter“ motivierend 

zu wirken. Diese Quelle lässt die Schlussfolgerung zu, dass eine Unterrichtsgestaltung, 

die aus Aufgaben mit und ohne Roboterbezug (und instruktinalen 

und entdeckenden Phasen mit Robotern) besteht, ähnlich motivierend wirken 

kann wie ein reines Roboterprojekt (mit geringerer fachlicher Verzahnung). 

A. Tempelhoff geht in [22] ebenfalls auf das Problem des Zeitbedarfs der Roboterkonstruktionen 

ein. Obwohl ihre Kursteilnehmerinnen die Roboter nach einer 

Anleitung aufbauten, beanspruchte diese Phase wesentlich mehr Zeit als geplant 

war. Sie gibt einen interessanten und nach Meinung des Verfassers bisher 

besten Lösungsvorschlag für das Problem. Ihre Idee ist, den Schülern Anleitungen 

zum Roboterbau zu geben und zudem nur diejenigen Bauteile zur Verfügung 

zu stellen, die für den Bau dieser Roboter notwendig sind. Die Vielfalt der 

MINDSTORMS-Baukästen kann nach Erfahrung des Verfassers das Suchen 

eines bestimmten Bauteils sehr frustrierend gestalten. Diese Vorsortierung der 

Bauteile müsste jedoch in der Unterrichtsvorbereitung durch den Lehrer vorgenommen 

werden. 

Die „robotergesteuerte Legostein-Sortiermaschine“ [03] von P. Dessarzin ist 

nach Meinung des Autors sehr gut für ein Informatikschulprojekt geeignet. Der 

Schüler entwickelte ein leicht modularisierbares Projekt mit niedrigem Materialaufwand 

und stellte anschauliche praktische Bezüge her. 

Robotersysteme eignen nach den Beschreibungen in [23] sehr gut um Unterrichtsthemen 

zur Maschinensteuerung anschaulich zu vermitteln. Für Maschinensteuerungen 

oder allgemein speicherprogrammierte Steuerungen (SPS 27 ) 

gibt es neben den Robotern auch weitere Lernsysteme (s. Siemens LOGO 28 ). 

Solche Systeme sind aber bei weitem nicht so anschaulich wie ein Robotersystem, 

das direkte Verhaltens-Änderungen als Rückmeldung geben kann. Außerdem 

sind sie nach Meinung des Verfassers dieser Arbeit technisch zu anspruchsvoll 

für den Schuleinsatz. Bei der Quelle wurde versucht mittels technischer 

Modifikationen das Robotersystem zur Verwaltung von Waren mittels 

27 http://de.wikipedia.org/wiki/Speicherprogrammierbare_Steuerung (zuletzt aufgerufen am 

30.09.08) 

28 http://de.wikipedia.org/wiki/Logo_(Steuerung) (zuletzt aufgerufen am 30.09.08)


RFID zu nutzen. Hier wurde ein weiterer Nachteil der Robotersysteme deutlich: 

Ihre Funktionsvielfalt kann nur bedingt durch technische Veränderungen erweitert 

werden. Dazu bedarf es eines umfassenden Wissens zur Hauptplatine des 

RCX Bausteins und der Schaltungs- und Chiptechnik. Ob und wieweit solches 

Wissen in schulischen Rahmen überhaupt vermittelt werden kann und sollte ist 

nach Meinung des Autors sehr fraglich. Dies mag bei technischen Ausbildungsrichtungen 

noch gerechtfertigt sein, aber bei Schulen mit allgemeinbildendem 

Auftrag sind solche Kompetenzen zu fachspezifisch. Inzwischen gibt es für das 

LEGO-MINDSTORMS-NXT-System außerdem ein fertiges RFID-Standard- 

Modul 29 , so dass sich damit Unterrichtsthemen zu RFID ohne technische Umbauten 

realisieren lassen. 

2.3.3.5 Robotersysteme an außerschulischen Lernorten 

Das Projekt „Roberta“ 

Im September 1999 wurde von der Bundesregierung das Programm „Innovation 

und Arbeitsplätze in der Informationsgesellschaft des 21. Jahrhunderts" beschlossen, 

indem gefordert wurde, dass „Frauen gleichberechtigt an der Entwicklung 

und Gestaltung der Informationsgesellschaft zu beteiligen“ seien. 

Das Interesse für technische Fächer und Berufe ist auch in jüngerer Zeit bei 

Mädchen deutlich geringer als bei Jungen (Frauenanteil im 1. Fachsemester 

technischer Studienfächer im WS 2005/2006 in Informatik und Maschinenbau 

ca. 17%, in Elektrotechnik 9% 30 ). Aus diesem Grund wurde das Projekt „Roberta“ 

(Abbildung 13; Quellen: [16],[17],[18] und [19]) vom Fraunhofer Institut für 

angewandte Systeme (AIS) ins Leben gerufen, dass in außerschulischen Kursen 

mit LEGO MINDSTORMS Robotern gezielt die Faszination der Mädchen 

für technische Fächer fördern sollte. Damit hoffte man dem geschlechterspezifischen 

Ungleichgewicht in Anfängerzahlen bei den technischen und informatischen 

Studiengängen entgegenzuwirken. Das Projekt wurde vom Bundesministerium 

für Bildung und Forschung (BMBF) gefördert (Fördersumme ca. 1,23 

Mio. Euro) und war befristet von November 2002 bis März 2007. 

Es wurden eine Zentralstelle und insgesamt 15 (Stand: Januar 2007 – laut 

Quelle [19], vier weitere in Planung) regionale Zentren aufgebaut und vernetzt. 

Aufgabe der Zentralstelle war die bundesweite Bereitstellung und Aktualisierung 

von Lehr- und Lernmaterial. Die Unterstützung von Lehrkräften, Ausbildern sowie 

Erziehern, aber auch interessierten Schülern und Studenten sollte durch 

spezielle Schulungs- und Beratungsprogramme von den regionalen Zentren 

geleistet werden. 

Abbildung 13: Logo des „Roberta“ Projekts 

29 http://www.codatex.com/index.php?en_RF_ID_Sensor-1 (zuletzt aufgerufen am 30.09.08) 

http://dienxteebene.blogspot.com/2008/01/rfid-sensor-fr-den-nxt.html (zuletzt aufgerufen am 

30.09.08) 

30 Statistisches Bundesamt 2006

- 26 - 


Kennzeichen der entstandenen „Roberta“-Kurse waren der Einsatz speziell für 

Mädchen entwickelter Lernumgebungen und –szenarien und eine möglichst 

gendergerechte Vermittlung der Lerninhalte. Die anfangs ausschließlich für 

Mädchen konzipierten Kurse konnten problemlos auch mit Jungen durchgeführt 

werden. Die Grenze für einen „Roberta“-Kurs wurde schließlich auf einen Mädchenanteil 

von mindestens 50% festgesetzt. Bundesweit wurden bis Sommer 

2005 mehr als 200 „Roberta“ Kurse mit über 2.600 Teilnehmern, davon 75% 

Mädchen, von über 200 geschulten „Roberta“ Kursleitern durchgeführt 31 . 

Im Laufe des Projekts „Roberta“ wurden eine Material-Reihe entwickelt, die aus 

insgesamt sieben Bänden besteht (Abbildung 14). Die Bände sind modular aufgebaut 

und können je nach Anforderungsprofil zu Lernsequenzen kombiniert 

werden. In Anhang B wurden Buchbeschreibungen und weiterführende Zusatzinformationen 

zusammengefasst. Bei den regionalen „Roberta“-Zentren können 

sich Schulen Roboterkästen ausleihen oder auch auf eine Simulatorsoftware 

(Abbildung 15) zurückgreifen. 

Abbildung 14: Materialien zu „Roberta“ 

Abbildung 15: RobertaSim Simulatorsoftware 

In den „Roberta“-Kursen wurde sehr oft die Erfahrung gemacht, dass Mädchen 

manchmal weniger bereit sind sich mit informatischen Themen auseinanderzusetzen, 

solange sie keine praktische Relevanz erkennen. Zum Beispiel stellten 

die Beobachter fest, dass Jungen sich begeistert in die Funktion der Sensoren 

31 Bildungsbericht 2006-II http://www.bmbf.de/de/6492.php (zuletzt aufgerufen am 30.09.08)


einarbeiteten, wohingegen Mädchen erst wissen wollten, welche Aufgaben die 

Sensoren bewältigen können und wie man sie praktisch verwenden könnte. Bei 

der Entwicklung der Materialien wurde deshalb bewusst darauf geachtet, sinnvolle 

Fragestellungen zu erarbeiten, die über die pure Präsentation der Möglichkeiten 

des Robotersystems hinausgehen. 

Wie auch bereits in [22] von A. Tempelhoff festgestellt, ist eines der Hauptergebnisse 

aus dem „Roberta“-Abschlussbericht das mangelnde Selbstvertrauen 

von Mädchen für die Bewältigung informatischer Probleme. Das „Roberta“- 

Team stellte fest, dass Mädchen ihre eigenen technischen Kompetenzen selbst 

dann unterbewerten, wenn sie objektiv bessere Ergebnisse als vergleichbare 

Jungengruppen ablieferten. 

Das Paderborner LEGO Hochregallager 

Das LEGO-MINDSTORMS-Hochregallager ([13] und [14]) wurde im Rahmen 

eines Informatik-Lernlabors der Universität Paderborn von J. Magenheim und 

seinem Team entwickelt. Theoretischer Hintergrund dieses Labors ist die „systemorientierte 

Didaktik“, in der die zentrale Aufgabe der Informatik in der Gestaltung 

von Informatiksystemen gesehen wird. 

Das Lernlabor umfasst die Inhaltsmodule „Warenwirtschafts-System Schulkiosk“, 

das „LEGO MINDSTORMS Hochregallager“, ein „Strategiespiel Ursuppe“ 

und die „Online Redaktion“. 

Das Hochregallager (Abbildung 16) besteht aus zwei Hochregalen, einer Fahrstrasse 

und einer Laderampe sowie zehn RCX-Bausteinen (mit geänderter 

Firmware für die objektorientierte Sprache LEJOS). Die RCX-Steine übernehmen 

die Steuerung von zwei Regalförderfahrzeugen, zwei autonomen Transportfahrzeugen, 

zwei Übergabestationen und eines ferngesteuerten Gabelstaplers. 

Die Infrarot-Kommunikation untereinander wird über „Time-slots“ organisiert. 

Für das Regallager wurde eine Simulatorsoftware (Abbildung 16) entwickelt. 

Abbildung 16: MINDSTROMS Hochregallager und Simulatorumgebung 

Das LEGO-Hochregallager dient in dem Lernlabor hauptsächlich der Systemdekonstruktion, 

um Steuerung von Transport- und Lagerungsprozessen zu analysieren 

und das erworbene Wissen auf die Entwicklung einer automatischen 

Kommissionierstation (Abbildung 17) zu übertragen.

- 28 - 


Abbildung 17: Automatische Kommissionierstation 

Die Teilnehmer sollen im Lernlabor Kompetenzen kognitiver Art (z.B. Sprachund 

Designkonstrukte, Java-Programmiersprache, Modellbeschreibungssprachen, 

Kommunikationsprotokolle, u.ä.), fachmethodischer Art (z.B. Vorgehensmodelle 

der Softwaretechnik, Methoden des Softwareentwurfs, Problemlösestrategien), 

sozialkommunikativer Art (z.B. Umgang mit virtuellen Lernumgebungen, 

Ergebnispräsentation, kooperatives Lernen) und normativ-bewertender 

Art (z.B. Qualität von Entwürfen und Softwaredesign, Folgenbetrachtung bei 

Design und Entwurfsentscheidungen) erwerben. 

Die Fachgruppe Didaktik der Informatik hat eine Lernsequenz (Tabelle 5) entwickelt, 

die im Sommersemester 2003 mit Studenten getestet wurde. 

1 

2 

3 

4 

Produktionsauftrag an virtuelle Firma: 

Erstellung einer Kommissionierstation (Beispiel arvato Bertelsmann 32 ) 

Erkundungen zur Funktionalität des Hochregallagers mit fertiger LEGO Umsetzung 

und Flash Animationen (bzw. Simulatorumgebung 33 ) 

Modellieren der vorliegenden Software der Systems mit „Class Responsibilities 

Collaborators 34 “ (CRC) Karten, Transfer auf UML Diagramme 

Erkunden einer vorgegebenen Modellierung, Vergleich mit eigenem Modellierungsentwurf, 

Diskussion der unterschiedlichen Konzepte 

5 Re-engineeringauftrag zur Veränderung der vorliegenden Software 

6 Untersuchung des Gesamtsystems (zweiter Re-engineeringauftrag) 

7 Transfer exemplarischer Lösungsansätze auf ein neues Aufgabenszenario 

8 

Modellierung der zu entwickelnden Kommissionierstation mit dem Softwareentwicklungstool 

„Together Control Center“ (mit Plugin für MINDSTORMS) 35 

9 Arbeitsteilige Softwareimplementierung, Test und Optimierung 

10 Reflexion über Produktqualität, Lernprozess und Schwierigkeiten 

Tabelle 5: Struktur der Lernsequenz 

32 http:/www.arvato.de (zuletzt aufgerufen am 30.09.08) 

33 http://ddi.uni-paderborn.de/software/lego-mindstorms-simulator.html (zuletzt aufgerufen am 

30.09.08) 

34 http://www.opfro.org/index.html?Components/WorkProducts/DesignSet/ClassResponsibility 

CollaboratorCard/ClassResponsibilityCollaboratorCard.html~Contents (zuletzt aufgerufen am 

30.09.08) 

35 http://ddi.uni-paderborn.de/de/software/mindstorms-tools.html (zuletzt aufgerufen am 

30.09.08)


Den Studenten standen für diese Lernsequenz neben 10 MINDSTORMS Erfindersets 

(mit 10 zusätzlichen RCX Steinen) die Baupläne aller LEGO Modelle 

(PDF und MLCAD 36 ) sowie MPEG-Videos und Flash-Animationen zu Hochregallagerabläufen 

des LEGO-Modells und des Unternehmens Arvato-Bertelsmann 

zur Verfügung. Sie hatten außerdem Zugriff auf Klassen- und Objektdiagramme, 

den kompletten und kommentierten Java Quellcode zur Modellsteuerung 

und Hintergrundinformationen zu Java-Programmierung, Entwurfsmethoden, 

das fachliche Vorgehen und Lagerlogistik. 

Die Autoren berichten in der Publikation, dass die Studentengruppen mit hoher 

dauerhafter Motivation und großem Engagement alle Module des Lernlabors 

erfolgreich absolviert haben. Die vorher erworbenen Kenntnisse in Softwaretechnik 

und Java Programmierung konnten erheblich vertieft werden. Der hohe 

zeitliche Aufwand beim Roboteraufbau könnte durch detailliierte Vorgaben reduziert 

werden. Die Autoren äußerten aber dazu die Befürchtung, dass darunter 

die Motivation leiden würde. 

Das Lernlabor ist in seiner jetzigen Ausarbeitung laut J. Magenheim noch nicht 

als Einstiegskonzept geeignet, da die didaktische Verzahnung mit Selbst-Lernphasen 

noch aussteht. Schülergruppen haben aus diesem Grund das Hochregal 

nur im Rahmen von Erkundungen kennen gelernt. Eine Arbeitsphase mit 

einer Leistungskurs-Gruppe ist in Planung. 


Die vorangegangene Beschreibung zum Projekt „Roberta“ lässt den Autor 

schließen, dass im Zuge dieses Projektes für Lehrkräfte eine große Sammlung 

an Material für Schulprojekte und zum Selbststudium entstanden ist. Lehrkräfte, 

die sich vor dem Unterricht mit Robotersystemen fürchten, oder sich einen solchen 

nicht zutrauen, können mit diesen Materialien ihre Ängste abbauen. Eine 

Fortbildung zum „Roberta“-Kursleiter stellt schließlich nur das Maximum der 

Möglichkeiten dar. 

Das Lernlabor mit Hochregallager von J. Magenheim hat nach Ansicht des Verfassers 

dieser Arbeit sehr viel Potential für den Unterricht an einem außerschulischen 

Lernort. Es ist in seinem Aufbau einem realen Hochregallager, wie sie in 

großen Speditionen und Lagerhäusern verwendet werden, nachempfunden. Die 

bestehenden Aufgabenstellungen für Studenten müssten auf Schulniveau angepasst 

und beispielsweise noch mit einer Filmvorführung eines real existierenden 

Hochregallagers erweitert werden. Bei einer geschickten didaktischen Verzahnung 

mit den bestehenden Lehrplänen könnte diese Gesamtkonstellation 

einen sehr lehrreichen Schulausflug mit Universitätsbesuch ergeben. Die Didaktikgruppe 

um J. Magenheim könnte zudem Unterrichtsmaterialien zur anschließenden 

Nachbereitung im Schulalltag entwickeln, damit die erworbenen Kenntnisse 

auch aufgearbeitet und gesichert werden. Die bereits entwickelten Animationsprogramme 

und Filmdateien könnten an Schulen, die keine Robotersysteme 

besitzen, die Realmodelle ersetzen. 

Ein weiterer außerschulischer Lernort für Robotersysteme ist das „TUMLab“ 37 

des deutsche Museums 38 in München. Hier können sich Privatpersonen oder 

36 http://www.lm-software.com/mlcad (zuletzt aufgerufen am 30.09.08) 

37 http://www.zll.ze.tum.de/registration/ekurs/AK_list_ekurs.php (zuletzt aufgerufen am 

30.09.08)

- 30 - 


Lehrer mit Schulklassen zu kostenpflichtigen Roboterkursen anmelden. Diese 

Kurse sind jedoch sehr technisch angelegt. Sie vermitteln nach eigener Erfahrung 

des Autors meist nur einen Überblick der technischen Möglichkeiten ohne 

fachliche Bezüge zu irgendeinem Lehrplan. Der Verfasser ist der Meinung, dass 

diese Art von Kursen dennoch eine interessante Alternative zu Einführungsstunden 

in die Robotik darstellt. Durch die Anwesenheit von Fachpersonal und 

dem breiten Angebot an Robotersystemen (verschiedene MINDSTORMS Roboter 

bis hin zu einer robotergesteuerten Fertigungsstrasse) können Schüler 

einen großen allgemeinen Überblick über Roboter bekommen. Nach Absolvierung 

eines solchen Kurses könnte der Lehrer in der Schule die erworbenen 

Kenntnisse aufarbeiten und in einem anschließenden Schulprojekt mit fachlichen 

Inhalten verknüpfen. 

2.3.4 Einsatz von Robotern im Hochschulbereich 

Universitäten setzen Robotersysteme seit langem auf unterschiedlichste Weise 

in Bereichen der Forschung, Entwicklung und Bildung ein. 

Nach der Vorstellung von Ergebnissen aus einer Lernanalyse zum Einsatz von 

Robotern werden in diesem Kapitel verschiedene Roboterprojekte beispielhaft 

vorgestellt und deren Übertragbarkeit auf den schulischen Bereich erörtert. 

2.3.4.1 Lernanalysen 

Quantitative Analysen der Lernfortschritte beim Einsatz von Robotern in 

Einführungskursen 

Die Veröffentlichung [05] von Barry S. Fagin ist eine Untersuchung der Lernfortschritte 

beim Einsatz von Robotern im Vergleich zur traditionellen Stoffvermittlung. 

Bei einer Militär-Akademie der US Airforce wurden 39 Computer Science 

(CS) Kurse mit der traditionellen Methode und neun CS Kurse ausschließlich 

mit dem Robotersystem LEGO MINDSTORMS durchgeführt. 

Die Stoffgleichheit der Gruppen wurde im Vorfeld sichergestellt. Wegen der Robotersystemgrenzen 

wurden kritische Stoffinhalte bei der Robotergruppe auf die 

Standardweise vermittelt. Beide Gruppen wurden von einer Person unterrichtet, 

was den Einfluss durch die Lehrperson minimierte. Die Neigungen (Computer 

Science oder Computer Engineering) der Gruppenmitglieder wurden bei der 

abschließenden statistischen Auswertung berücksichtigt (Fisher Irwin Test 39 ). 

Am Ende der Seminare fanden neben statistischen Untersuchungen durch 

Fachpersonal und dem Vergleich der Examensergebnisse auch ausführliche 

Umfragen in den Roboterkursen statt. 

Die Ergebnisse der Umfragen spiegelten die Examensergebnisse der Robotergruppe 

wieder, welche durchgängig schlechter waren als bei der Referenzgruppe. 

Die Studenten bemängelten die Anzahl der Roboter und den zusätzlichen 

Zeitaufwand bei der Programmierung. Weitere Kritikpunkte gingen z. B. vom 

„Alles oder Nichts Lernen mit Robotern“ (Roboter erleichtern entweder die Vermittlung 

oder sie erzeugen Probleme, die eine Vermittlung der Lerninhalte ü- 

38 http://www.deutsches-museum.de/information/jugend-im-museum/try-it/2007-you-tried-it-all/ 

(zuletzt aufgerufen am 30.09.08) 

39 http://de.wikipedia.org/wiki/Exakter_Test_nach_Fisher (zuletzt aufgerufen am 30.09.08)


berdecken und erschweren) über „Isolation der Robotergruppe“ (gegenüber den 

Standard CS-Kursen) bis hin zur Aussage „Roboter sind unwichtige Spielerei“. 

B. Fagin gibt im Rückblick auf die Probleme in den Kursen noch diverse Verbesserungsvorschläge. 

Studenten könnten die zeitaufwendigen Programmierund 

Testphasen zu Hause abarbeiten und eine Simulator-Software (große 

Freeware Auswahl 40 ) zur frühen (Roboterunabhängigen) Fehlererkennung nutzen. 

Der Unterschied zwischen Lehrpersonen der Roboter- und Standardabteilung 

sollte durch gezielte Schulungen zum Ausgleich des Erfahrungsrückstandes 

(der Lehrpersonen der Robotergruppen) minimiert werden. 


Die Untersuchung von Fagin zeigt die Probleme beim Einsatz von Robotersystemen. 

Das in den Examensprüfungen geforderte Theorie- oder Faktenwissen 

konnte sich schlechter mit Robotern vermitteln lassen, als mit traditionellen 

Methoden. Als Konsequenz muss festgehalten werden, dass Robotersysteme 

nicht dazu geeignet sind um (Fach-)Unterricht komplett zu ersetzen. Wenn Robotersysteme 

dosiert in bestimmten Phasen des Unterrichts eingesetzt werden, 

können sie den Unterricht gezielt unterstützen. Diese Erkenntnis taucht in den 

anderen Literaturquellen immer wieder auf. 

Das Curriculum des Schulunterrichts beinhaltet neben Faktenwissen eine Reihe 

von zusätzlichen Kompetenzen, die sich gut mit Robotersystemen vermitteln 

lassen. Problemlösestrategien, Teamfähigkeit, Präsentation, Wertung und Metakompetenzen 

sind hierfür Beispiele. 

Fagins Untersuchung gibt keine Information darüber, ob dieses Wissen bei den 

Studenten der Roboterkursen besser ausgeprägt war als bei den Studenten der 

Vergleichsgruppe. Examensprüfungen auf Faktenwissen können solche zusätzlichen 

Kompetenzen nur teilweise abprüfen. 

2.3.4.3 Beispielhafte Robotikprojekte 

Kombination von LEGO MINDSTORMS Robotern und Web Cam zu autonomen 

Fahrzeugen 

In der Quelle [21] beschreiben Daniel E. Stevenson und James D. Schwarzmeier 

ein Projekt, das sie mit CS Studenten an der University of Wisconsin 

durchgeführt haben. 

Bei diesem Projekt wurde eine Logitech Quickcam Pro mit VideoCapture Software 

auf ein LEGO MINDSTORMS Robotersystem mit zwei Motoren montiert. 

Der Live Stream der Webcam ist anschließend über ein USB Kabel auf einen 

Steuerungsrechner übertragen worden. Dort fanden eine Umwandlung der Videodaten 

(Splitten der Frames und Formatänderungen), Bildanalysen (Bildumwandlungsalgorithmen, 

Gegenstands- und Fahrbahnerkennung) und Steuerbe- 

40 LEGO MINDSTORMS Simulator: 

http://ddi.uni-paderborn.de/software/lego-mindstorms-simulator.html (zuletzt aufgerufen am 

30.09.08) 

RPU mit Simulatorsoftware “Microsoft Robotics Studio”: 

http://www.computerbild.de/programme/Microsoft-Robotics-Studio_422773.html (zuletzt aufgerufen 

am 30.09.08)

- 32 - 


fehlsgenerierungen (Verhaltswahl über Befehlsinterface und LEGO Übersetzer) 

für den Roboter statt. Die Steuerbefehlsübermittlung erfolgte über eine zweite 

USB-Kabelverbindung zu einem Infrarot Interface, das die Daten an den RCX 

Baustein des Roboters übermittelte. Der Roboter ist in Abbildung 18 dargestellt. 

Abbildung 18: Aufbau des Roboters mit Kamera und Infrarotmodul 

Die Studenten entwickelten die notwendigen Algorithmen, die zusammen mit 

dem verwendeten Equipment ein autonomes Bewegungsverhalten des Roboters 

(im Radius der USB Kabelverbindung) in einer Kontrollumgebung mit vorgegebenen 

Straßenbahnmarkierungen ermöglichte. 

Das Roboterverhaltensrepertoire umfasste im Wesentlichen drei Verhaltensweisen 

(ausführliche Algorithmenbeschreibungen sind in der Quelle zu finden). 

Der Roboter konnte sich zwischen zwei Linien geradeaus bewegen, Kurskorrekturen 

vornehmen und durfte dabei keine Begrenzung überfahren. Das “Kurvenfahren“ 

ohne die Linie zu schneiden war ebenfalls möglich. Nur beim letzten 

Verhalten, Gegenständen auszuweichen war das Linienübertreten erlaubt. 

Als problematisch erwies sich das sehr komplexe Steuerungsverhalten der Robotermotoren. 

Das „Kurven fahren“, welches über die Änderung der Rotationsgeschwindigkeiten 

der beiden Einzelmotoren realisiert wurde, endete oft mit 

unvorhersehbarem Verhalten. Der Bildanalysealgorithmus war zu komplex um 

von den Studenten entwickelt zu werden. Deswegen stellten die Betreuer teilweise 

die Bildanalysesoftware zur Verfügung. 

D. Stevenson und J. Schwarzmeier fassten folgende Ergebnisse zusammen. 

Die Motivation der Studenten war generell sehr hoch, obwohl der Hauptteil der 

Studentenarbeit (bei der Algorithmenentwicklung zur Bildanalyse) sehr schwer 

und zeitintensiv war. Es entwickelte sich eine reale Projektatmosphäre mit all 

ihren Problemen. Die Studenten mussten häufig Problemlösestrategien entwickeln, 

erproben, bewerten und modifizieren. Der erfolgreiche Projektabschluss 

stellte einen Balanceakt zwischen Algorithmenkomplexität und deren Aufwand 

bzw. Genauigkeit dar. 

Webbasierte Steuerung eines Robotersystems 

In der Publikation [01] beschreibt Judith Challinger von der California State University 

die Entwicklung eines Graphischen User Interfaces für Roboter mit 

Client und Server-Architektur um Roboter vom Internet aus zu steuern. 28 CS 

Studenten und zwei Fernlehrgangstudenten sollten mit Hilfe der objektorientierten 

Entwicklungsumgebung „Java Swing API“ ein Interface für den


KHERPERA Roboter (Abbildung 19) entwickeln, das die folgenden Kriterien 

erfüllt. Die Ansteuerung via Internet (max. eine Verbindung zu Clients) sollte 

verschiedene, möglichst genaue Steuerungsmöglichkeiten für den Roboter ermöglichen 

und in einem Simulationsfenster die Aktionen der Benutzer zeigen. 

Abbildung 19: KHERPERA Roboter 

Um dies zu ermöglichen, installierte die Universität einen Server mit einer seriellen 

Verbindung zum KHERPERA (ständige Kommunikation zur Statusabfrage 

zwischen Server und Roboter mit Timeout für Client-Connection). Die 

Studenten implementierten ihre GUI Steuerung auf einem vorgegebenen Clientinterface 

und testeten ihre Funktionalität anschließend via Internet mit dem 

KHERPERA am Server. 

Von der Autorin wurden mehrere Probleme identifiziert. Die beschränkten Nutzungszeiten 

des Servers (lief nur tagsüber) und deren gerechte Aufteilung zum 

Testen der Testinterfaces gestaltete sich schwierig. 

Endlosschleifen und Software Bugs erzeugten beim Roboter teilweise chaotisches 

und „selbstzerstörerisches“ Verhalten, was die permanente Anwesenheit 

eines Betreuers erforderte (manueller Reset). Die aufwendige Software zum 

Logging-Managment erzeugte diverse Sicherheitsprobleme und öffnete Lücken 

in das Uni-Netzwerk. 

In der Reflexion führt J. Challinger die Tatsache, dass alle Studenten die Aufgabenstellung 

gemeistert haben, auf die hohe Grundmotivation (trotz vieler zeitintensiver 

Rückschläge bei Entwicklung) durch das Robotersystem zurück. 

In der Quelle ist ein detaillierter Fragenkatalog zum Kursende für die Studenten 

veröffentlicht. Beispiele hiervon sind in Tabelle 6 zusammengefasst. Insgesamt 

waren die Studenten, trotz des höheren Arbeitspensums im Vergleich zu normalen 

Laborstunden, sehr zufrieden mit dem Roboterkurs. 

Frage 

Wie motivierend war die Roboteraufgabenstellung als Sie sich entschieden 

haben diesen Kurs zu belegen? 

Wie angemessen war das Schwierigkeitsniveau der Aufgabenstellung? 

Wie effektiv war die Roboteraufgabe, um Ihnen die Vermittlung von 

mehr Wissen über graphische Benutzeroberflächen und deren Implementierung 

zu erleichtern? 

Wie sehr hat Ihnen das Roboter System den Einstieg in die Bearbeitung 

der komplexen Aufgabenstellungen erleichtert? 

Ergebnis 

74% oberes Drittel 

(sehr motivierend) 


(angemessen) 


(angemessen) 


(gut) 

Tabelle 6: Exemplarische Fragen und Antworten der Evaluation

- 34 - 


Für die Zukunft plant J. Challinger den Einsatz eines Robotersimulators (wie 

bereits in der Quelle [05] vorgeschlagen), der den Studenten mit Hilfe einer lokalen 

Serversoftware (Simulierung der Serverschnittstelle) zur Verfügung gestellt 

wird. Dieser Simulator würde den Organisationsaufwand und die Serverlaufzeiten 

verringern und Sicherheitsprobleme vermeiden. Die erweiterbare Architektur 

des KHERPERA (Videoschnittstelle, Greifarm, Audiomodule, Steuerungsschaltungen, 

etc.) lässt ihrer Meinung nach seinen Einsatz variabel und 

ermöglicht unterschiedlichste Aufgabenszenarien für CS-Kurse. 

Erfahrungsberichte zum Einsatz von Robotern 

In der Quelle „The Use of Robots in the Undergraduate Curriculum: Experience 

Reports“ [08] werden von verschiedenen Professoren Erfahrungsberichte zum 

Einsatz von Robotersystemen im universitären Bereich zusammengefasst. 

Clare Congdon vom Colby College in Waterville vermittelte in einem CS-Kurs 

„Explorations with Robots“ Problemlösestrategien und Algorithmenaufbau. Die 

Studenten entwickelten eigene Robotersysteme aus Standardteilen und programmierten 

sie in C. Der Kurs war unterteilt in Übungsaufgaben (z.B. Roboterposition 

in definiertem Gebiet halten, Linien folgen, ein Hindernis umfahren, 

etc.) und Abschlussprojekte (z.B. Fangen-spielende Roboter, Tischtennisbälle 

aufsammeln und an Ausgangspunkt bringen oder Objekte in einem vorgegebenen 

Areal finden und Zielposition einem anderen Roboter mitteilen). 

Die Ergebnisse waren, dass der Zugang zur Programmiersprache den Studenten 

leichter fiel, Problemlösungen in kooperativer Zusammenarbeit entwickelt 

wurden und die Studenten begeistert und engagiert mitarbeiteten. 

Barry S. Fagin von der US Airforce Academy in Colorado Springs versuchte in 

Roboterkursen (mit ca. 10% der Academy-Studenten) die Vermittlung von Problemlösestrategien, 

elementaren Programmieraufgaben (z.B. Variablen, Wiederholungen), 

Problemzerlegung und die kritische Bewertung von Problemlösestrategien. 

Er stellte fest, dass informatische Grundstrukturen der Programmierung durch 

den Praxisbezug bei Problemstellungen gut vermittelbar sind, aber mäßige 

Klausurergebnisse (Kapitel 2.3.4.1 ff.) auftraten. Die Herangehensweise der 

Studenten zur Lösung von gegebenen Problemen mit den Robotersystemen 

soll in Zukunft genauer analysiert werden. Die Airforce Academy will damit ihre 

Aufgabenstellungen in den Roboterkursen dauerhaft verbessern. 

Deborah Hwang hat an der University of Evansville ein interdisziplinäres LEGO 

Projekt für Studienanfänger (der Studiengänge „Electrical Engineering“, „Computer 

Engineering“ u. „Computer Science“) durchgeführt. Die Ziele des Kurses 

waren eine Einführung in fundamentale Computer Konzepte und die Programmiersprache 

C, sowie die Beobachtung und Schulung von interdisziplinärem 

Teamverhalten. Sie wurden größtenteils mit befriedigendem Ergebnis erreicht. 

Frank Klassner der Villanova University in Philadephia versuchte mit der Programmiersprache 

Not Quite C (NQC) diverse Konzepte (Reflexion, Bewertung 

und selbstorganisiertes, zielgerichtetes Problemlösen) mit der Entwicklung eigener 

Roboterprojekte zu vermitteln. Seine Studenten untersuchten die Grenzen 

des Robotersystems und nahmen mit ihren Roboterentwicklungen an einem 

Abschlusswettbewerb („Capture the Ball Competition“ – Roboter müssen 

Bälle fangen) teil.


Interdisziplinäre Entwicklung von autonomen Fahrzeugen 

Die Autoren berichten in der Veröffentlichung [07] über einen interdisziplinären 

Kurs der Columbia University, bei dem insgesamt 30 Studenten höheren Semesters 

aus unterschiedlichsten Fachrichtungen (Biologen, Informatiker, Ingenieure, 

E-Techniker) Roboter entwickelt haben. 

Der Kurs verfolgte mehrere pädagogische Ziele. Zuerst sollten mit der praktischen 

Entwicklung eines Embedded Systems die Transferleistungen der Studenten 

verbessert werden. Bei der reinen theoretischen Entwicklung werden oft 

Umgebungs- und Rahmenbedingungen außer Acht gelassen, was dazu führt, 

dass Studenten meist an so genannten „Wissensinseln“ arbeiten und eine Vernetzung 

der Theorien kaum trainiert wird. 

Zum anderen sollte der Kurs Kontakt zu Problemen der realen Umgebung ermöglichen 

und zur kooperativen Teamarbeit bei der Entwicklung interdisziplinärer 

Lösungen anleiten. Diese Zusammenarbeit stand im Mittelpunkt, da die Aufgaben 

so ausgewählt wurden, dass sie nicht von Einzelpersonen aus einer 

Fachrichtung lösbar waren. Die Studenten sollten ihr Robotersystem zuerst 

entwickeln und anschließend gründlich bewerten (um ihr kritisches Denken zu 

verbessern). Sie sollten im Vergleich mit anderen Lösungen erkennen, dass es 

in der Realität nicht nur eine richtige Lösung gibt, sondern meistens Varianten 

mit unterschiedlichen Vor- und Nachteilen. 

Der Roboterbau erfolgte in Dreiergruppen (min. ein Student Programmierer und 

einer aus dem Ingenieurbereich). Die Gruppen erhielten einen Roboter Selbstbausatz 

bestehend aus einem LEGO-Set, Sensorbauteilen, Entwicklungsplatine 

und diversen Elektronikbauteilen zum Schaltkreisbau. 

Die Roboterentwicklung wurde in vier Stadien unterteilt (Tabelle 7) und der Designprozess 

(Mechanik und Software) durchgängig von den Studenten mit einem 

persönlichen Handbuch dokumentiert. 

Nr. 

(1) 

(2) 

(3) 

Stadien der Roboterentwicklung 

ä 

Entwicklung einfacher mechanischer Maschinen (Mini Lektionen) 

Sensoriksystem entwickeln 

(polarisiertes Licht suchen, schwarze und weiße Eier finden) 

Parallelprozessmodellierung bei Überwachung der Sensoren auf fahrender autonomer 

Plattform mit komplexeren Algorithmen (Wegfolgen, Hindernissen ausweichen 

und Lichtfolgen) 

(4) Kombination von Fahrzeug und Sensoriksystem zu einem Embedded System 

Tabelle 7: Phasen der Roboterentwicklung 

Im Anschluss an diese Phasen wurden die Gruppen neu gebildet, um eine 

Neuorientierung der Teammitglieder (Flexibilität im Team) zu garantieren. Die 

neuen Gruppen traten in einem großen Abschlusswettbewerb – dem „Egg hunt“ 

(Eiersuchende Roboter) gegeneinander an. Sie mussten hierbei neue Roboterdesigns 

entwerfen, Verhaltensstrategien algorithmisieren, die Designs umsetzen, 

bewerten und modifizieren. Die Roboter wurden im Anschluss vor der ganzen 

Kursgruppe präsentiert. 

In einer großen Veranstaltung (auf dem ganzen Campus bekannt) traten jeweils 

Gruppen mit zwei Robotern in einem vorgegebenen Areal (Abbildung 21) ge-

- 36 - 


geneinander an. Die Studentengruppen zeigten dabei kreative Roboterumsetzungen 

(Abbildung 20) sowie Strategienvielfalt (z. B. blocken, stehlen, suchen). 

Abbildung 20: Beispielroboter 

Abbildung 21: Arena „EGG Hunt Wettbewerbs“ 

Die zentralen Ziele des Kurses (Integration der verschiedenen Wissenschaftsdisziplinen, 

Aufgabenstellungen zu Problemen der Realität, interdisziplinäres 

Teamwork und die Schulung von kritischen und kreativen Denken) wurden laut 

den Autoren in dem Kurs erreicht. Für die Zukunft planen sie die Entwicklung 

einer Sprachsteuerung, die beim „EGG Hunt“ Wettbewerb ein Eingreifen per 

Zuruf ermöglicht und damit die Robotertaktik im laufenden Wettbewerb variabel 

geändert werden kann. 

Steuerung eines LEGO MINDSTORMS NXT Roboters mit dem Kontroller 

der Spielekonsole Nintendo Wii 

Die folgenden Projekte wurden mit Studenten in einem Vertiefungskurs zur Prozessdatenverarbeitung 

an der FH Wiesbaden mit Prof. Dr. Linn durchgeführt 

[11]. Die Studenten arbeiteten an zwei Teilprojekten, einem MINDSTORMS 

NXT Roboter der selbstständig Linien folgt und diese aufzeichnet sowie einer 

Steuerung des Roboters mit Hilfe einer Nintendo WiiMote. 

Die Programmierung des Linienverfolgers erfolgte in NXC 41 (Not eXactly C). Die 

beteiligten Studenten hatten bereits Grundlagen der Sprache C gelernt und sollten 

diese auf die C-ähnliche Sprache übertragen. Bei der Entwicklung des Algorithmus 

zur Linienverfolgung traten jedoch einige Probleme auf. Der Roboter 

war mit nur einem Lichtsensor ausgestattet und konnte deshalb nicht unterscheiden, 

ob er sich rechts oder links neben der Linie befand (problematisch bei 

der Unterscheidung von Links- und Rechtskurven). Das Problem wurde durch 

eine zweifarbige Linienführung (Abbildung 22) gelöst, mit der der Roboter (bei 

konstanten Lichtverhältnissen) die Orientierung behielt. Als Erweiterung des 

Teilprojekts wurde die gefahrene Strecke vom Roboter in einer Datei aufgezeichnet 

und anschließend in einem Programm visualisiert. Hierzu speicherte 

der NXT während der Fahrt die jeweilige Winkelstellung der Räder und die dazugehörige 

Zeit. Die anschließende mathematische Umrechnung dieser Werte 

41 http://bricxcc.sourceforge.net/nbc/ (zuletzt aufgerufen am 30.09.08)


und deren graphische Darstellung (Abbildung 23) bereitete den Studenten e- 

benfalls Probleme. 

Abbildung 22: Aufbau der Kurve 

Abbildung 23: Visualisierte Daten 

Das zweite Teilprojekt hatte das Ziel, den NXT durch Bewegungen der Wiimote 

(Kontroller der Nintendo-Wii-Spielekonsole) zu steuern. Geplant war eine Direktverbindung 

von der Wiimote zum NXT über Bluetooth. Es war den Studenten 

aber nicht möglich, eine derartige Verbindung aufzubauen (Der Bluetoothstack 

des Roboters unterstützt nicht das nötige Protokoll für diese Art der 

Kommunikation). Stattdessen setzten die Studenten ein Mac Laptop als “Bluetoothproxy” 

(Abbildung 26) zur Befehlsübermittlung ein. In dieser Konfiguration 

war es den Beteiligten möglich, die Ansteuerungsbefehle der Wiimote für den 

NXT Roboter in Fahrbefehle umzusetzen. Die Studenten generierten hierzu aus 

dem Koordinatensystem der Wiimote (Abbildung 24) einen Zustandsautomat 

(Abbildung 25) dessen Zustände mit Fahrkommandos verknüpft wurden. 

Abbildung 24: Koordinatensystem der 

Wiimote 

Abbildung 25: Zustandsautomat der Wiimote 

Abbildung 26: Bluetooth Proxy

- 38 - 


Zur softwaretechnischen Umsetzung kombinierten die Studenten die Applikationen 

„Wiiremoteframework“, „Rubycocoa“, „Ruby“ und „Ruby-nxt“ 42 zu einem 

funktionsfähigen Gesamtkonzept. Die Quelle beinhaltet auch eine Schritt-für- 

Schritt-Anleitung, so dass dieses Teilprojekt leicht nachgebaut werden kann. 

Die Wiimote-Steuerung des Roboters ließ sich mit diesen Softwarekomponenten, 

der Mac Programmierumgebung und der objektorientierten Skriptsprache 

„Ruby“ erfolgreich und relativ einfach implementieren. Ohne diese komfortablen 

Frameworks, die das Auslesen der Wiimote und das Steuern des NXT Roboters 

ermöglichten, wäre gemäß [11] die Aufgabe erheblich komplizierter geworden. 

Die hardwarenahe Programmierung aktueller Komponenten (NXT u. Wiimote) 

und die Integrierung von bestehenden Frameworks zu einem funktionsfähigen 

Gesamtsystem empfanden die Studenten als sehr spannend und abwechslungsreich. 

Der NXT Roboter hat nach [11] durch seine modulare Bauweise 

genügend Potential um weitere interessante Aufgaben der Prozessdatenverarbeitung 

zu erfüllen. 

2.3.4.4 Bewertung und Didaktischer Kommentar 

In der Quelle [21] wird beschrieben, wie sich einfache Robotersysteme, wie 

LEGO MINDSTORMS durch entsprechende Anbauten zu autonomen Fahrzeugen 

erweitern lassen. Diese Umsetzung bildet einerseits die Basis und stellt 

andererseits den Übergang zu komplexeren Aufgabenstellungen (Bsp. DARPA 

Ralley 43 ) aus dem Bereich der autonomen Fahrzeuge dar. Studenten können 

mit den kostengünstigen Robotersystemen Lösungen und Strategien entwickeln, 

die sich dann auf größere Probleme übertragen lassen. 

Robotersysteme ermöglichen neben der Algorithmisierung von Abläufen auch 

den unmittelbaren Test der Problemlöseverfahren. 

Zur Lösung zweier Probleme von [21] würde der Verfasser dieser Arbeit Folgendes 

vorschlagen. Zur Verbesserung des Bewegungsablaufs können drei 

Motoren (bei RCX und NXT der MINDSTORMS Reihe möglich) eingesetzt werden. 

Hier würde ein Motor nur Lenkbewegungen steuern. 

Um den eingeschränkten Bewegungsradius des Roboters zu vergrößern, bietet 

sich der Einsatz von Video Funksystemen 44 oder WLAN Kameras 45 an, die inzwischen 

auch relativ kostengünstig zu erwerben sind. Das LEGO NXT System 

bietet außerdem die Steuerung über Bluetooth an. Der kombinierte Einsatz dieser 

Vorschläge würde dem Roboter komplett autonomes Verhalten im Senderadius 

der Bluetooth-Verbindung ermöglichen. 

Das in der Quelle [01] beschriebene Projekt zeigt, wie die von einem Robotersystem 

erzeugte Motivation das freiwillige Engagement erhöht. Diese Motivation 

ermöglichte das höhere Arbeitspensum als in Vergleichskursen und erleichterte 

die Lösung von komplexen Aufgabenstellungen. Sie spiegelt die Ergebnisse 

der Untersuchungen in dem Abschnitt „Qualitative und quantitative Lernanalysen“ 

wieder. Selbst ein in seinem Aufbau so schlichtes Robotersystem wie der 

KHERPERA kann eine solche Motivation erzeugen. 

42 genaue Versionshinweise und Internetquellen für die Programme sind in [11] angegeben. 

43 http://en.wikipedia.org/wiki/DARPA_Grand_Challenge (zuletzt aufgerufen am 30.09.08) 

44 http://www.acwsoft.de/acw_funk3.html#THM2400R (zuletzt aufgerufen am 30.09.08) 

45 http://www.hitecsecurity.de/wlan+kamera-s.html (zuletzt aufgerufen am 30.09.08)


Für den Einsatz im Unterricht kann das Projekt modifiziert und übertragen werden 

(s. Folgekapitel). Die Quelle kann als Anstoß für eine Schülerdiskussion 

dienen, bei der Risiken und Möglichkeiten eines über das Internet steuerbaren 

Roboters besprochen werden (Arbeiterschutz bei gefährlichen, gesundheitsschädlichen 

Berufen, Folgen für die Gesellschaft, Sicherheitsaspekte, etc.). 

Quelle [08] ist ein Beispiel dafür, dass Roboter erfolgreich in CS-Kursen der 

Universität eingesetzt werden, um Probleme zu algorithmisieren, Problemlösestrategien 

und Software mit der Programmiersprache C zu entwickeln. Die Strategien 

und die Software wurden praktisch angewendet, bzw. auf ihre Lösungstauglichkeit 

hin getestet und abschließend von den Studenten selbst bewertet 

und evaluiert. Die Evaluation der eigenen Ansätze zur Problemlösung und die 

Erörterung der Grenzen des entwickelten Softwaresystems unterstützten die 

Studenten bei der Ausprägung ihrer fundierten, fachlichen Meinung und bei der 

Entwicklung kritischen Denkens. 

Die in [08] beschriebenen Übungsaufgaben könnten problemlos in der Schule 

mit dem Robotersystem LEGO MINDSTORMS NXT umgesetzt werden. 

Das entdeckende Lernen mit Robotersystemen kann in der Zusammenarbeit 

von Schülern mit unterschiedlichsten Anlagen (Computerfreak als Programmierfachmann, 

haptische Lerntypen als Roboterbauer, Mädchen als kreative Designer 

- interdisziplinäres Projekt) den Klassenverband stärken und die Integration 

von Außenseitern erleichtern. Praktisches Lernen mit Robotern kann die altbekannten 

Methoden des Lernens bereichern und Schüler zur Mitarbeit aktivieren. 

Die Quelle [07] zeigt, dass ein Robotersystem mit vielen Freiheitsgraden die 

kreative Lösungsentwicklung unterstützt und erleichtert. Die Entwicklung von 

Selbstbau-Robotern und deren Programmierung als Embedded System zur Lösung 

komplexer Aufgabenstellungen ist ein großer Aufgabenbereich in der heutigen 

Industrie. Die Studenten wurden in diesem Kurs in praxisnaher Weise auf 

die Berufwelt vorbereitet. 

Das hohe Engagement ist einerseits auf das Robotersystem zurückzuführen, 

welches sofortiges Feedback für die entwickelten Lösungen lieferte. Andererseits 

steigerte das Wettkampfszenario den persönlichen Ehrgeiz. 

Die Quelle „Steuerung eines LEGO MINDSTORMS NXT Roboters mit dem 

Kontroller der Nintendo Wii“ gibt ebenfalls ein Beispiel für die Motivation, die 

Robotersysteme bei Lernenden erzeugen können. Im beschriebenen ersten 

Teilprojekt (den Linienfolger) wäre es für die Studenten sicher ein „Leichtes“ 

gewesen, die bestehende Hardware um einen weiteren Lichtsensor zu erweitern 

(Diese Option wurde in der Quelle nicht eindeutig ausgeklammert). Dennoch 

stellten sich die Studenten der Herausforderung, die Aufgabe mit gegebener 

Hardware zu lösen. Ihre Lösung mit der zweifarbigen Linie wirkt zwar auf 

den ersten Blick nicht sonderlich kompliziert, die zugehörige Software für den 

Algorithmus ist aber sicher nicht so einfach. Der Autor stand bei der Entwicklung 

der Lagerverwaltung vor einem ähnlichen Problem (Entwicklung einer 

möglichst flüssigen und fehlerresistenten Linienverfolgung) und wählte die Lösung 

mit zwei Lichtsensoren. Hierfür entwickelte er einen relativ einfachen Algorithmus 

zur parallelen Verarbeitung beider Messwerte (Softwarelösung s. beiliegende 

DVD). Diese Lösung entstand nach einigen Fehlversuchen mit einem 

Lichtsensor, bei dem die Bewegungen des Roboters stets sehr ruckartig und 

nicht flüssig waren. Das Problem der möglichst genauen Bewegung lösten die 

Studenten aus [11] mit Hilfe komplizierter mathematischer Operationen und ei-

- 40 - 


nem sehr komplexen Algorithmus. Auch für das zweite Projekt zeigten die Studenten 

hohes Eigenengagement. Insgesamt wurden fünf unterschiedliche Programme 

und Frameworks verwendet. Die Studenten mussten sich folglich in 

alle beteiligten Softwaremodule einarbeiten und auch noch ihre gewonnenen 

Programmier-Kenntnisse auf den NXC Dialekt übertragen. 

2.3.4.5 Übertragung eines der Universitätsprojekte auf schulischen Informatikunterricht 

Bei der Auswahl der Literaturquellen im vorherigen Kapitel versuchte der Autor, 

den Schwerpunkt auf schulische Projekte zu legen was aber aus Gründen des 

Überangebots an Literaturquellen für den Hochschulbereich nur teilweise gelang. 

Zudem muss erwähnt werden, dass der Robotereinsatz an Schulen sehr 

oft auf den Themenbereich der Algorithmik beschränkt ist und sich deshalb 

größere Überschneidungen ergeben hätten. 

Da manche der beschriebenen Roboterprojekte von Hochschulen mit einiger 

Fantasie leicht auf schulisches Niveau „herunter-transformiert“ werden können, 

möchte der Verfasser den Lesern hierfür ein Beispiel geben. Das beschriebene 

Studentenprojekt aus [01] ließe sich nach Meinung des Autors auf folgende 

Weise in den Informatikunterricht übertragen. 

Hiefür müsste eine Installation eines MINDSTORMS-Systems mit zugehöriger 

Schnittstelle zur Internetkommunikation an einer ausgewählten Schule erfolgen. 

Wenn in dieser Schule die technischen, finanziellen und sicherheitsrelevanten 

Vorraussetzungen gegeben sind, könnten andere Schulen auf das System über 

das Internet zugreifen. Damit würden zwar die finanziellen, personellen und 

räumlichen Belastungen von einer Schule geleistet, andere Schulen (mit geringeren 

Möglichkeiten) könnten aber beispielsweise eine einmalige Gebühr zahlen 

und das System im Rotationsverfahren mitnutzen. In diesem Fall wäre allen 

Schulen ein Robotersystem zugänglich und alle Schüler könnten davon profitieren. 

Die Installation eines geeigneten Servers und der passenden Software 

müsste hier allerdings von Spezialfirmen vorgenommen werden. Aufgrund der 

Sicherheitsproblematik und zur Sicherstellung der Funktionalitäten des Robotersystems, 

der Internetschnittstelle und des dauerhaften Supports bei Problemen 

ist diese Verantwortung und der damit verbundene Arbeitsaufwand nicht 

einem Informatiklehrer der Schule zuzumuten. Ein verantwortlicher Lehrer an 

der Schule sollte aber die Verteilung und die Organisation der Nutzungszeiten 

durch andere Schulen übernehmen. 

Diese Variante hat zudem den Vorteil, dass Schüler auch außerhalb der Unterrichtszeiten 

auf dieses System zugreifen könnten. Für die Planung von Aufgaben 

oder gemeinsamen Problemstellungen und die Vermittlung von Theoriewissen 

würde die Unterrichtszeit verwendet. Eine Realisierung durch die Schüler 

würde in deren Freizeit vorgenommen. 

LEGO hat für diese Variante bereits die freie Einstiegssoftware „WEBBrick“ 

entwickelt. Laut den Beschreibungen auf der Homepage, ist es mit diesem Programm 

möglich, die Steuerung eines MINDSTORMS Roboters auf jeder beliebigen 

Homepage 46 zu implementieren. Die Software ist frei in ihrer Interfacesteuerung 

und –funktionalität modifizierbar. Durch den hohen Programmierauf- 

46 http://popbubble.com/Lego/WebBrick/ (zuletzt aufgerufen am 30.09.08)


wand ist sie allerdings nach Meinung des Verfassers nur für den heimischen 

Gebrauch oder überschaubare Szenarien tauglich. 

2.4 Zwischenzusammenfassung der erworbenen Kenntnisse 

aus der Literaturrecherche 

2.4.1 Chancen des Robotereinsatzes im Bildungsbereich 

Die in den Quellen vorgestellten Robotersysteme können durch ihre variable 

Programmierung in einem breiten Bildungsbereich zur Modellbildung eingesetzt 

werden. Die vorgestellte „Tangible Programmierung“ könnte bereits in der Primarstufe 

Grundkonzepte spielerisch vermitteln. Die Konzepte könnten durch die 

grafischen Entwicklungsumgebungen in der Sekundarstufe vertieft und erweitert 

werden. Dies könnte eine ausreichende Basis für textbasierte Programmierung 

in Hochsprachen während einer universitären oder beruflichen Ausbildung ermöglichen. 

Dieser ganze Ausbildungsprozess könnte, neben anderen Methoden 

und Modellen, durch Robotersysteme begleitet werden. 

Der variable Roboteraufbau kann eine Anpassung auf unterschiedliche praktische 

Anforderungen ermöglichen. In den vorgestellten Literaturquellen wurden 

einerseits Komplettsysteme softwaretechnisch modifiziert (Sony AIBO oder das 

RCX System bei der Modellierung des Sortieralgorithmus). Andererseits können 

Robotersysteme durch unterschiedliche Realisierung ihres Aufbaus diverse 

Aufgaben bewältigen (LEGO MINDSTORMS RCX System zur Sortierung von 

Legosteinen o. zur Verwaltung RFID-gekennzeichneter Waren). Hier liegt eine 

der Stärken eines Embedded Systems, die Varianz von Soft- und Hardware. 

In der Recherche wurde dem Autor deutlich, dass heutige Robotersysteme objektorientierte, 

algorithmenbasierte und zustandsorientierte Modellierung ermöglichen. 

Dem Verfasser ist kein anderes System (Soft- oder Hardware) bekannt, 

das all diese Modellierungsmöglichkeiten bietet. Für Schulen kann sich 

daraus die Konsequenz ergeben, dass finanzielle Mittel gespart werden können. 

Mit der Anschaffung eines Robotersystems können unter Umständen Lizenzgebühren 

für andere Modellierungssoftware wegfallen, da diese Modellierungen 

alle mit einem Robotersystem realisierbar sind. 

In den meisten vorgestellten Quellen war davon die Rede, dass Lernende mit 

großem Eifer und Motivation bei der Lösung der Aufgabenstellungen mit Robotern 

arbeiteten. Dies ist nach Meinung des Verfassers der momentan größte 

Vorteil beim Einsatz dieser Systeme gegenüber herkömmlichen Medien. Robotersysteme 

für die Bildung einzusetzen, ist im Vergleich zu älteren Methoden 

und Medien (z.B. Schulprojekt oder der Computer) ein relativ junger Zweig der 

Informatikbildung. Solange diese Systeme nicht zum Alltag der Lernenden gehören 

(wie z.B. der Computer), können sie eine Faszination ausstrahlen, die 

hohe intrinsische Motivation erzeugt. Als Folge wollen die Lernenden sich freiwillig 

mit dem System beschäftigen, es verstehen, seine Funktionen erweitern 

oder mit ihm auch komplexere Aufgabenstellungen lösen. Die beschriebenen 

Quellen zum Projekt „Roberta“ ([16] bis [19] und [22]) können den Leser darauf 

schließen lassen, dass auch Mädchen mit geringen technischen Interessen diese 

intrinsische Motivation spüren. Dies könnte ein Grund für die Wettbewerbserfolge 

der „Roberta“-Mädchengruppen von A. Tempelhoff sein (s. S. 20).

- 42 - 


2.4.2 Probleme des Robotereinsatzes 

Als Hauptproblem des Robotereinsatzes in Bildungsbereichen führen viele 

Quellen den Zeitbedarf der Roboterkonstruktionsphase an. Diese Phase weg zu 

lassen ist nach Meinung des Verfassers keine gute Idee, da sie für Schüler 

hoch motivierend ist. In den Quellen wurden unterschiedlichste Ansätze vorgeschlagen, 

vom Bau der Roboter in der Freizeit bis hin zum Nachbau nach Anleitung. 

Der Autor dieser Arbeit hat diese Ansätze zu einem kombiniert und hält 

folgendes Vorgehen für eine akzeptable Lösung des Problems: 

- Die Lehrkraft sollte möglichst einfache Roboterkonstruktionen auswählen 

und komplexe Modelle außen vor lassen (größte Zeitersparnis). 

- Für diese Konstruktionen müsste eine möglichst umfassende und leicht 

nachvollziehbare Aufbauanleitung erstellt oder gefunden werden (Minimierung 

des Betreuungsaufwandes). 

- Diese Anleitung müsste einmal mit den vorhandenen Baukästen durch die 

Lehrkraft aufgebaut werden (s. Konstruktionsmängel beheben, Modell vereinfachen 

und Sonderteile identifizieren). 

- Den Schülern werden nur die Bauteile zur Verfügung gestellt, die sie für das 

jeweilige Modell auch brauchen (kein Teilesuchen mehr). 

- Die Schüler arbeiten in maximal fünf Gruppen (s. Betreuungsaufwand) und 

mit jeweils höchstens vier Teilnehmern (s. Abspracheprobleme). 

Dieser zugegebenermaßen sehr hohe Organisations- und Vorbereitungsaufwand 

könnte sich auf Dauer amortisieren, wenn die Lehrkraft die Roboterprojekte 

strikt modular aufbaut. Dieses Vorgehen erleichtert die Wiederverwendbarkeit. 

Dies wurde bei den „Roberta“-Materialien und dem anschließend folgenden 

Lagerverwaltungsprojekt berücksichtigt. Der modulare Aufbau wird 

durch die vorgestellten Robotersysteme unterstützt und ist leicht realisierbar. 

In vielen Quellen wurde die Notwendigkeit einer Simulation der Roboterumgebungen 

erwähnt. Dies erleichtert die praktische Realisierung von Programmtestläufen 

und spart wiederum Zeit. Für dieses Problem kann der Verfasser keinen 

universellen Lösungsvorschlag geben. Hier kommt es auf das entsprechende 

Szenario an, ob freie Simulationen im Internet das Gewünschte leisten 

können. 

Die bereits in Kapitel 2.3.3.1 vorgestellten Probleme der Leistungsermittlung 

lassen sich vielleicht am Besten durch eine Kombination von instruktionalen 

und praktischen Unterrichtsphasen mit entsprechend gestalteten Prüfungsszenarien 

lösen. In den instruktionalen Phasen kann der Lehrer Fachwissen einfliesen 

lassen und mit Schülern erarbeiten. Die Schüler übertragen ihr erworbenes 

Wissen in den Praxisphasen auf neue Problemstellungen, was wiederum 

den Transfer schult. Eine Bewertung kann bei Roboterprojekten in mehreren 

Teilen erfolgen. Mündliche Noten zum Umgang mit den Material (ziel- und problemorientiert 

oder spielerisch ungerichtet), der Arbeit in der Gruppe (Sozialkompetenz) 

und der Qualität der Unterrichtsbeiträge (Fachliche Beiträge) können 

eine Möglichkeit sein. Bei schriftlichen Leistungserhebungen sollte nach Meinung 

des Verfassers darauf geachtet werden, dass neben dem fachlichen auch 

prozeduales Wissen (z.B. Entwurf von Handlungsstrategien oder Beschreibung 

von Softwareentwicklungsprinzipien) abgefragt wird.

KAPITEL 3: ENTWURF EINER ROBOTERGESTEUERTEN LAGERVERWALTUNG - 43 - 

3 Entwurf einer robotergesteuerten Lagerverwaltung 

Im folgenden Kapitel wird ein Unterrichtskonzept mit Robotern als Medium zur 

Vermittlung informatischer Inhalte dargestellt. 

Es werden verschiedene Lehrpläne für Realschulen und die aktuellen Bildungsstandards 

auf die Einsatzmöglichkeiten von Robotern im Informatikunterricht, 

hin untersucht. 

Anschließend ist das Gesamtkonzept einer „robotergesteuerten Lagerverwaltung“ 

(LV) skizziert, d. h. das Szenario und informatische Konzepte der LV 

werden beschrieben und auf die technische Realisierung (Roboteraufbau und 

deren Funktionalität) wird eingegangen. 

In der folgenden exemplarischen Unterrichtsumsetzung ist ein grober Unterrichtsplan 

zum Gesamtkonzept „Lagerverwaltung“ im Rahmen eines Schulprojekts 

zum Thema „Bluetooth Übertragung“ einer Realschule aufgeführt. Diesem 

Gesamtplan folgt eine beispielhafte, detaillierte Ausarbeitung einer Unterrichtseinheit 

des zuvor beschriebenen Gesamtprojekts. 

3.1 Einordnung in die Bildungspläne 

3.1.1 Mit Robotern vermittelbare Inhalte in ausgewählten Lehrplänen 

Konkrete Systeme, sei es nun Hard- oder Software, sollten laut dem Kenntnisstand 

des Autors (aus diversen Didaktikveranstaltungen seines Lehramtsstudiums) 

hauptsächlich als Medium, weniger als Ausgangspunkt didaktischen Handelns 

dienen. 

In Tabelle 8 sind die Themengebiete unterschiedlicher Lehrpläne tabellarisch 

zusammengefasst. Die angeführten Referenznummern dienen dem Verfasser 

der vorliegenden Arbeit dazu, in den Folgekapiteln Rückbezüge zu erstellen. 

Aus der Tabelle ist ersichtlich, dass im Bundesland Hamburg Roboter als 

Schwerpunkthema zehn explizit erwähnt werden. Die dazu angeführten Themen 

(Analyse und Grundlagen von Robotersteuerungen, Algorithmen der Roboter 

und Mensch und Technik) können durch eine ausführliche Bearbeitung 

der in Tabelle 10 aufgeführten Module der Lagerverwaltung größtenteils abgedeckt 

werden. Die Schwerpunktthemen neun (Prozessdatenverarbeitung) und 

vier (Kommunikation) sind (bei entsprechender Ausarbeitung) ebenfalls durch 

die LV abgedeckt. 

Wie bereits auf Seite 26 angeführt, ist es mit entsprechenden Roboter- 

Systemen auch möglich, SPS-Steuerungen zu modellieren. Aus diesem Grund 

hat der Verfasser auch die „Messen, Steuern und Regeln“-Themenbereiche 

(MSR) von Hauptschulen, Gymnasien und polytechnischen Schulen mit in die 

Tabelle 8 aufgenommen. Die Lagerverwaltung kann dieses Unterrichtsthema 

nur teilweise modellieren, hierfür müssten Robotermodelle verwendet werden, 

die Abläufe rein durch Auswertung von Messwerten steuern und regeln. 

Im Lehrplan der bayerischen Realschulen werden Robotersysteme nicht explizit 

erwähnt. Hier wären einzelne Themen alternativ zu den altbekannten Medien 

(Simulationssoftware u. ä.) auch mittels Roboter vermittelbar. In Tabelle 10 

kann der Leser hierzu Anregungen finden.

- 44 - 

KAPITEL 3: ENTWURF EINER ROBOTERGESTEUERTEN LAGERVERWALTUNG 

Ref.- 

Nr. 

Lehrplanquelle 

Schulform 

Jahrgangsstufe 

Themabezeichnung 

Inhalte und Erläuterung 

LP 

1-1 

Rahmenplan 

für das 

Wahlpflichtfach 

„Informatik“ 

in 

Hamburg 

Haupt- und 

Realschule 

Schulformund 

Jahrgangsübergreifender 

Aufbaukurs 

nach verbindlichem. 

Grundkurs 47 

Informatische 

Leitlinien zum 

Schwerpunktthema 

10 

„Roboter“ 

- Analyse von Robotersteuerung 

- Grundlagen der 

Robotersteuerung 

- Roboteralgorithmen 

- Roboter im Alltag 

- Mensch und 

Technik 

LP 

1-2 

Informatische 



9 

„Prozessdatenverarbeitung“ 

- Analyse von PVL 

(Prozessdatenverarbeitungsanlagen) 

- Grundlagen PVL 

- PVL im Alltag 

- computergesteuerte 

Herstellung u. 

Produktionsabläufe 

LP 

1-3 

informatische 



4 

„Kommunikation“ 

- kein expliziter 

Roboterbezug 

- modellhafte Signal- 

und Datenübertragung 

bei 

Robotern 

- Grundlagen der 

Kommunikation 

und Kommunikations-Dienste 

LP 

2-1 

Lehrplan der 

Realschule 

Bayern 

Realschule 

(4-stufig bzw. 

6stufig) 

Informatik 8.2 

Algorithmische 

Grundelemente 

und ihre Umsetzung 

Vermittlung der 

Strukturen mit grafischen 

Entwicklungsumgebungen 

von Robotern 

LP 

2-2 

Informatik 8.4 

Prozeduren und 

Funktionen in 

einer Programmiersprache 

Wichtigkeit der 

Modultechnik mit 

Roboterprogrammentwicklung 

zeigen 

LP 

2-3 

Zustandsorientierte 

Modellierungen 

Robotergesteuerte 

Automaten neben 

Simulationen 

LP 

2-4 

Objektorientierte 

Modellierung 

Roboter (versch. 

Ausführungen) als 

Objekte mit gemeinsamen. 

Attributen, 

unterschiedlichen 

Funktionen 

LP 

2-5 

Netzwerke 

Netzwerke kommunizierender 

Robotereinheiten 

LP 

3 

Lehrplan 

mehrer Bundesländer 

Hauptschule, 

Gymnasium 

polytechn. S. 

diverse Klassen 

Messen, Steuern 

u. Regeln (MSR) 

MSR Prinzipien mit 

Robotern verdeutlichen 

Tabelle 8: Übersicht Roboterbezüge ausgewählter Lehrpläne 

47 Verbindlicher Grundkurs mit Pflichtthemen „Grafik“ und „Textdokumente“


3.1.2 Robotergeeignete Themen in den Bildungsstandards Informatik für 

die Sekundarstufe I 

Ref. 

Nr. 

Themen 

der 

BS 

Schüler/-innen 

der Klassen 5 

bis 7 

mögliche Umsetzung 

durch Roboter 

Schüler/-innen 

der Klassen 8 

bis 10 

mögliche Umsetzung 

durch 

Roboter 

BS 

1-1 

BS 

1-2 

Algorithmen (ALG) 

(Inhaltsbereich) 

lesen u. verstehen 

Handlungsvorschriften 

für 

das Arbeiten mit 

Informatiksystemen 

interpretieren 

Handlungsvorschriften 

korrekt 

u. führen sie 

schrittweise aus 

Vorhersage des 

Roboterverhaltens 

bei gegebenen 

Algorithmus 

Abarbeiten eines 

ALG durch einen 

Roboter, Schüler 

deuten zugehöriges 

Programm 

lesen formale 

Darstellungen 

von ALG u. 

setzen sie in 

Programme um 

Erarbeitung und 

Implementierung 

eines ALG zum 

Labyrinthlösen 

verwenden 

Variablen und 

Wertzuweisungen 

Variablengesteuerter 

Roboter, 

Wertzuweisung 

durch Roboter o. 

Anfangseingabe 

BS 

1-3 

entwerfen Handlungsvorschriften 

als Text / mit 

formalen Darstellungsformen 

Entwurf der ALG 

mit graphischer 

Entwicklungsumgebung 

u. Test mit 

Robotermodell 

entwerfen, 

implementieren 

und beurteilen 

Algorithmen 

ALG-Entwurf in 

Gruppen für einen 

Roboter, 

Effizienzvergleich 

beim „Livetest“ 

BS 

1-4 

entwerfen und 

testen einfache 

Algorithmen 

ALG-Entwurf für 

gegebenes Roboterfahrzeug 

modifizieren / 

ergänzen 

Quelltexte von 

Programmen 

nach Vorgaben 

Verbesserung 

und Optimierung 

gegebener Roboterprogramme 

BS 

2-1 

BS 

2-2 

Modellieren u. Implementieren 

(Prozessb.) 

untersuchen bereits 

implementierte 

Informatiksysteme 

beobachten die 

Auswirkungen 

von Änderungen 

am Modell 

Dekonstruktion 

eines gegebenen 

Roboterszenarios 

Abänderung eines 

gegebenes Robotersystems 

(Modellierung 

e. Alltagsproblems) 

beeinflussen 

das Modellverhalten 

durch 

zielgerichtete 

Änderungen 

beurteilen das 

Modell, die 

Implementierung 

u. Werkzeuge 

kritisch 

Verbesserung 

eines gegebenen 

Roboteraufbaus 

kritischer Vergleich 

unterschiedlicher 

Umsetzungen 

von 

Linienverfolgern 

BS 

3-1 

BS 

3-2 

Strukturieren u. Vernetzen 

(Prozessb.) 

zerlegen Sachverhalte 

durch 

Erkennen u. Abgrenzen 

von 

Bestandteilen 

erkennen Reihenfolgen 

bei 

Handlungsabläufen 

Dekonstruktion 

eines Roboterprogramms 

anschließende 

Modulbildung 

Optimierung von 

Programmabläufen 

von Robotern 

planen Arbeitsabläufe 

und 

Handlungsfolgen 

erstellen netzartige 

Strukturen 

erstellen Handlungsplan 

für 

einen Roboter 

zur Problemlösung 

netzartige Aufgabenverteilung 

auf 

mehrere Roboter 

BS 

4-1 

BS 

4-2 

Kommunizieren / Kooperieren 

(Prozessb.) 

kooperieren in 

Zusammenarbeit 

bei der Bearbeitung 

einfacher 

informatischer 

Probleme 


arbeitsteiliger 

Gruppenarbeit 

Gruppenarbeit zu 

theoretischen Hintergründen 

u. praktischer, 

Lösung 

einer Roboteraufgabenstellung 

Gruppen lösen 

unterschiedliche 

Roboteraufgaben 


Projektarbeit 

bei der Bearbeitung 

eines 

informatischen 

Problems 

dokumentieren 

Projektablauf u. 

-ergebnisse 

Projektarbeit mit 

Robotern 

(z.B. LV Module 

aus Tabelle 10) 

Aufbereitung des 

Projekts für Tag 

der offenen Tür 

Tabelle 9: Übersicht robotergeeignete Themen in den Bildungsstandards der Informatik

- 46 - 


Für Tabelle 9 hat der Verfasser Themen der Bildungsstandards Informatik (BS) 

für die Sekundarstufe I zusammengefasst, bei denen seiner Meinung nach Roboter 

im Unterricht einsetzbar sind. Bei den Inhaltsbereichen wurde die Algorithmik 

genauer betrachtet. Aus den Prozessbereichen, dem prozedualem Wissen, 

sind Beispiele aus der „Modellierung und Implementierung“, „Strukturierung 

und Vernetzung“ sowie der „Kommunikation und Kooperation“ aufgeführt. 

Die Spalte Ref. Nr. dient wie in Tabelle 8 dazu, einfache Bezüge in späteren 

Kapiteln zu ziehen. In den Spalten zur „möglichen Umsetzung durch Roboter“ 

hat der Autor Impulse und seine Ideen stichpunktartig formuliert. Am Beispiel 

von BS2-2 wird der Verfasser diese Ideen weiter ausformulieren, um dem Leser 

eine bessere Vorstellung zu ermöglichen: 

Schüler/-innen der Klassen 5 bis 7 sollen laut den vorliegenden Bildungsstandards 

die Auswirkungen von Änderungen am Modell beobachten. Dies könnte 

mit Hilfe eines Robotersystems geschehen, das eine Straßenbahnlinie (s. Alltags- 

und Lebensweltbezug der Schüler) modellhaft präsentiert. Die Schüler 

erarbeiten hierfür einen Zustandsautomat, der die zeitgesteuerten Zustände 

„Fahre“, „stoppe an Haltstelle“ und „Warte an Haltestelle“ besitzt. Die Lehrkraft 

könnte zur Modellierung einen Roboter bauen, der auf einer gerade Strecke mit 

vier Haltestellen fährt. Das zugehörige Programm wäre sehr kurz und durch den 

zeitabhängigen Wechsel der Zustände nur für eine spezifische Strecke geeignet. 

Eine mögliche Aufgabe der Schüler könnte die Streckenänderung (Verlauf 

– s. Straßenbauarbeiten oder zusätzliche Haltestellen) oder der Einbau von a- 

kustischen Signalen (s. Durchsage der Haltestellen - Erweiterung des Zustands 

„stoppe an Haltstelle“) sein. Außerdem könnten die Schüler einen weiteren Zustand 

„stoppe an roter Ampel“ einbauen, der beispielsweise durch das Überfahren 

einer schwarzen Linie mit Hilfe des Lichtsensors ausgelöst wird. Mit diesen 

Änderungen im Zustandsautomat würden die Schüler leicht die Auswirkungen 

am Modell beobachten können. Die zugehörige Implementierung könnte unter 

Anleitung des Lehrers in Gruppenarbeit ablaufen. 

Bei Schüler/-innen der Klassen 8 bis 10 ist in den BS angeführt, dass ein Modell, 

seine Implementierung und die verwendeten Werkzeuge kritisch beurteilt 

werden sollen. Hierzu könnten die Schüler mehrere Roboter zur Linienverfolgung 

vergleichen und bewerten. Der Lehrer könnte die Roboter in ihrem Aufbau 

und der Programmierung stark variieren. Möglich wären folgende Roboter: 

- ein kleiner Roboter (modelliert Sportwagen) mit hoher Geschwindigkeit, 

dessen Lichtsensor alle drei Sekunden zur Stellungskorrektur abgefragt wird 

- ein mittlerer Roboter (modelliert Familienfahrzeug) mit mittlerer Geschwindigkeit, 

der Lichtsensorwerte jede Sekunde abfragt u. die Stellung korrigiert 

- ein großer Roboter (modelliert einen LKW) mit Ladefläche und niedriger Geschwindigkeit, 

der seine Stellung ständig nach Lichtsensorwerten korrigiert 

Mit Hilfe unterschiedlicher Umsetzung der Programmierung (einmal links entlang 

einer Linie fahren oder das Linienfolgen durch ständiges Zick-Zack- 

Fahren) könnten die Schüler diese drei Modelle hinsichtlich ihres Programmieraufwandes 

und der Algorithmeneffizienz vergleichen. Zudem könnte die Programmierung 

hinsichtlich Speicherplatzbedarf und Rechenleistung (gemessen 

an der Dauer der Kompilierung) untersucht werden. Feste Bedingungen (z.B. 

Motorgeschwindigkeit) könnten beim Versuch der Optimierung modellbedingte 

Abhängigkeiten zeigen.


3.2 Motivation des Szenarios Lagerverwaltung 

Grundmotivation des Szenarios war die Entwicklung eines Konzepts mit hoher 

Modularität, in dem mehrere Konzepte der Informatikbildung mit Robotern vermittelbar 

sind. Beispiele solcher Module können Bluetooth (BT) Kommunikation, 

codierte Nachrichten, Algorithmisierung von Abläufen, Sensorikaufgaben, Prozessdatenverarbeitung 

mit Robotern, oder ähnliches sein. Eine genaue Auflistung 

der in der Lagerverwaltung vorkommenden Module und informatischer 

Konzepte kann in Tabelle 10 nachgelesen werden. 

Die Gliederung des Szenarios in möglichst viele in sich geschlossene Module 

soll es Informatiklehrern ermöglichen, das Szenario an vielen Stellen des Informatikunterrichts 

einzusetzen. Hierzu kann die Videodatei der Lagerverwaltung 

(auf der beiliegenden DVD) einerseits als motivierender Unterrichtseinstieg und 

andererseits als Ausblick auf das Gesamtkonzept dienen. Lehrkräfte können 

dann mit ihren Schülern ein Modul des Gesamtprozesses für ihren Unterricht 

aus dem Kontext nehmen und dieses anschließend nachbilden. Damit versucht 

der Autor variable Lernpfade der im Szenario enthaltenen Konzepte zu ermöglichen. 

Ein Folgeeffekt dieser Überlegungen ist, dass das Konzept nicht ausschließlich 

auf eine Jahrgangsstufe oder Schulform festgelegt ist. Lehrer können 

mit Hilfe der Module zudem innerhalb einer Klasse auf die unterschiedlichen 

Vorkenntnisse und Leistungsniveaus der Schüler eingehen (Differenzierung). 

Für den bayerischen Realschulunterricht werden von der Lagerverwaltung die 

Lehrplanbereiche 2-1 bis einschließlich 2-5 abgedeckt. Die robotergeeigneten 

Abschnitte der Bildungsstandards für Realschulen (Tabelle 9) kann die LV bei 

geschickter Modulwahl (Tabelle 10) ebenfalls erfüllen. 

Neben der Rechtfertigung von Seiten der Bildungspläne kann die LV Realschülern 

einen Ausblick auf die heutige Lagerorganisation und die spätere Berufswelt 

bieten. Automatische Lagerverwaltungssysteme werden bei vielen Großkonzernen 

(z.B. BMW: Ersatzteillager, REWE: Versandlager mit Elektropalettenbahn) 

eingesetzt und sind ein fester Bestandteil heutiger Logistik 48 . Der Lehrer 

kann mit solchen Hintergrundinformationen seinen Schülern die praktische 

Relevanz des LV-Projektes verdeutlichen. Werden die Strukturen und Funktionsprinzipien 

der LV auf reale logistische Unternehmen übertragen, können 

Diskussionen zum Thema „Soziale und Arbeitsorganisatorische Folgen“ angeregt 

werden, was die Allgemeinbildung der Schüler fördern kann. 

Die Lagerverwaltung hat primär das Ziel, informatische Inhalte zu vermitteln. 

Für diese Funktion fungiert sie als Medium für den Unterricht. Des Weiteren 

können mit der LV informatische Vorgehensweisen (z.B. Dekonstruktion und 

Modellierung von Prozessen, Strukturierung von Aufgaben und arbeitsteilige 

Aufgabenbewältigung) vermittelt werden. Da sich die Module der LV nach Meinung 

des Autors sehr gut für Projekte eignen, kann sie dazu genutzt werden 

den Schülern die Vorteile, Notwendigkeit und praktische Relevanz solcher informatischer 

Grundgedanken begreifbar zu machen. 

48 http://logistics.de/logistik/offerer.nsf/anbieter/s0090-ssi-schaefer-noell-gmbh (zuletzt aufgerufen 

am 30.09.08) 

http://www.lapis-darmstadt.de/index.php?id=6 (zuletzt aufgerufen am 30.09.08)

- 48 - 


3.2.1 Informatische Konzepte der Lagerverwaltung 

In Tabelle 10 sind die informatischen Konzepte der Lagerverwaltung zusammengefasst 

und den jeweiligen Bildungsplänen zugeordnet. Der Verfasser hat 

bei den jeweiligen Konzepten die notwendige Hardware und die benötigten 

Programmmodule mit angegeben. 

In der Spalte „benötigte Hardware von der LV u. evtl. Nachbau durch S.“ ist jeweils 

beschrieben, welche Robotereinheiten die Schüler (S) nachbauen können. 

Der Roboterbau kann mit den Anleitungen der DVD erfolgen. Die Lehrkraft 

sollte nach Meinung des Verfassers diesen Nachbau wie im Kapitel 2.4.2 beschrieben 

organisieren (kleine Gruppen, nur notwendige Bauteile bereitstellen 

etc.). 

Die Spalte „benötigte Software der LV u. notwendige Modifikation d. Lehrers“ 

gibt an, welche Programmmodule benötigt werden. Da der Autor nicht alle Konzepte 

bis ins Detail ausgearbeitet hat, müssen Lehrkräfte an manchen Modulen 

noch Modifikationen vornehmen. Dies betrifft beispielsweise die Konzepte A2, 

A3 und die Prozessdatenverarbeitung. Wenn wie bei A2 vorgeschlagen, ein 

Robotermodell aus dem Gesamtkontext genommen wird, sind größere Änderungen 

an den Programmmodulen notwendig. Da die Robotereinheiten untereinander 

BT-Nachrichten austauschen, fungieren diese Nachrichten zeitgleich 

als Kontrollstruktur (die BT-Nachricht ist Auslöser für folgende Programmteile). 

Wenn diese BT-Nachrichten nicht empfangen werden, bleibt der Roboter in 

Wartestellung. Lehrkräfte müssen deshalb in A2 und allen weiteren Szenarien, 

in denen nur ein Robotermodell Verwendung findet, die BT-Auslöser durch feste 

Wartezeiten ersetzen. 

In der letzten Spalte von Tabelle 10 skizziert der Autor stichpunktartig seine 

Vorstellungen einer unterrichtsmethodischen Umsetzung. Hierbei handelt es 

sich um eine Ideensammlung, die noch entsprechend ausgearbeitet und didaktisch 

begründet werden muss. Eine detaillierte Ausarbeitung einer unterrichtsmethodischen 

Umsetzung wird im Kapitel 3.4 zu einem weiteren Modul, der 

„Bluetooth Kommunikation“ erfolgen. Im Konzept A2 und der „Übermittlung von 

Nachrichten“ wird auf die im Anhang aufgeführten Unterrichtsmaterialien Arbeitsblatt 

(AB) 4 und 3 verwiesen. AB 4 beinhaltet eine Geschichte, die den Gesamtablauf 

der LV beschreibt. Für das AB 4 sind im folgenden Absatz weitere 

Erläuterungen dargestellt (ähnliche Erklärungen zum AB 3, ab Seite 64). 

Im AB 4 wird ein Paket mit der Post (s. „Lebenswelt-Nahe“ Aufgabenstellung für 

S.) transportiert und über diverse Stationen abgeliefert. Ziel dieses ABs ist, 

dass Schüler die Videodatei genau analysieren und die Elemente der Geschichte 

den jeweiligen Abläufen im Video zuordnen und zu einem Sequenzdiagramm 

zusammenfassen. Mit dieser Aufgabe sollen die Schüler ihre Abstraktionsfähigkeit 

steigern, ihr Textverständnis verbessern und den Transfer der Grundlagen 

von Sequenzdiagrammen auf ein neues Problem üben. Diese sehr vielseitige 

Aufgabenstellung ist nach Meinung des Autors erst am Ende des Themenbereichs 

Sequenzdiagramme zu bewältigen. 

Ergänzende Bemerkungen zur Tabelle 10: 

{1} in den Bildungsstandards Informatik für Realschulen sind Teile dieser Konzepte 

im Inhaltsbereich „Sprachen und Automaten“ aufgeführt 

{2} Hier trifft der Inhaltsbereich „Information und Daten“ zu

Informatisches 

Grundkonzept 

Algorithmisierung 

(A1) 

Grundelemente v. 

Ablaufstrukturen 

(A2) 

Beschreibung u. 

Strukturierung von 

Handlungsabläufen 

(A3) 

Prozeduren und 

Funktionen 

(A4) 

Variablenkonzept 

Bildungsplanbezug 

LP 2-1 

LP 1-1 

BS 1-1 

BS 1-2 

BS 1-3 

LP 1-1 

LP 2-2 

BS 1-4 

BS 3-1 

BS 3-2 

LP 2-3 

BS 1-2 

benötigte Hardware 

von der LV u. evtl. 

Nachbau durch S. 

Roboter mit Basischassis 

zur Linienverfolgung 

Bluetoothsignalgesteuerte 

Motoren 

bei der LV 

Zwei NXT Bausteine 

Annahme (Sender) 

und Fahrer (Empfänger) 

ein Robotermodell 

(Modell X) nachbauen 

(zur leichteren 

Beschreibung u. Ablaufvisualisierung); 

ein Robotermodell 

nachbauen (Lagerist 

oder Stapler, deren 

Programme sind am 

übersichtlichsten) 

ein NXT Baustein mit 

vier Tastern 

benötigte Software der 

LV u. notwendige Modifikation 

d. Lehrers 

Linienverfolgung als Sensorwert 

bedingte Wiederholung, 

„RobLinien.rbt“ 

BT Einzelmodule der 

Programme, z.B. 

„BTFahrLosSend.rbt“ 

Lagernummernempfang 

als wertgesteuerte Verzweigung 

im Modul 

„BTLagerNrWart.rbt“ 

Modifikation der Programmmodule 

des Modells 

X von Lehrkraft; 

Bluetooth Auslöser durch 

Wartezeit ersetzen 

die Module auflösen und 

ein großes Programm 

generieren; Ausgewählte 

Module abändern (den 

Quellcode so modifizieren 

dass sie nicht mehr funktionieren) 

[1] ProgrammStart.rbt 

[2] TasterAbfrageVar.rbt 

Vorschlag zur unterrichtsmethodischen Umsetzung 

mit den Schülern die Grundlagen für wertgesteuerte Abläufe erarbeiten; 

Linienverfolgungsmodul analysieren; 

Linienverfolger bauen und eigene Prozeduren mit bedingten Wiederholungen 

entwickeln; 

Grundlagen der BT Übertragung erarbeiten; in den Programmmodulen 

die BT Signalen als bedingte Auslöser suchen; unterschiedliche 

Roboteraktionen mit BT Signale auslösen; Adressierung und 

Fehlersicherheit diskutieren 

Programmmodul „BTLagerNrWart.rbt“ des Fahrers dekonstruieren 

und seine Funktionen mit BT gesteuerter bedingter Verzweigung 

erarbeiten, Abänderung und Nachbau mit zwei NXT Bausteinen 

Sequenzdiagramm für das Verhalten der einzelnen Robotereinheiten 

anhand des Videos und der Geschichte 

(Anhang C – Arbeitsblatt (AB) 4) entwickeln; 

Entwickeln eigener Abläufe, Umbau und Anpassung des 

Modells X für neue Abläufe; Erarbeiten der Abhängigkeit von Softu. 

Hardware); Ausblick weitere embedded Systeme 

mit den Schülern das Video genau analysieren (auf sich wiederholende 

Abläufe achten)* und das Verhalten des Roboters algorithmisch 

beschreiben; den Schülern zeigen wie das Gesamtprogramm 

ohne Module aussieht (Umfang und Übersichtlichkeit); 

Quellcode durch Generierung von Prozeduren und Funktionen 

vereinfachen (s.*); in Partnerarbeit die Funktionsfähigkeit der ausgewählten 

Module wiederherstellen lassen u. am Robotermodell 

testen. 

Mit den S. Grundlagen zu Variablen erarbeiten (Datentyp, Wertebereich, 

etc.), variablenabhängige Begrüßung ([1]) und variablengesteuerte 

If-Kaskaden ([2]) untersuchen 


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

-------

zustandsorientierte 

Modellierung 

LP 2-4 

{1} s. oben 

Ein Robotermodell 

(am besten Stapler – 

lässt sich am einfachsten 

zustandsorientiert 

modellieren) 

Hauptprogramm und 

Module des Modells 

gemeinsame Erarbeitung der Grundlagen zustandsorientierter 

Modellierung mit einfachen Automatenmodellen; S. erstellen mit 

Hilfe des Videos ein Zustandsmodell des Staplers (Beispielzustände: 

warte auf Fahrer-Nachricht; empfange Paket; verlade 

Paket; Fahre; etc.); anschließende Umstrukturierung der Programmmodule 

nach Zuständen und Erweiterung der Bildschirmausgaben 

(Zustandsanzeige); Test mit nachgebautem Staplermodell 

Netzwerke BS 3-2 

Übermittlung von 

Nachrichten 

LP 1-3 

{2} s. oben 

vier NXT Bausteine 

mind. zwei NXT Bausteine 

mehrere Programmmodule 

die BT Nachrichten 

übermitteln (Namentlich 

von den restlichen Modulen 

durch die Bezeichnung 

BT…..rbt abgegrenzt) 

Das Client-Server-Prinzip und die Grundlagen zu Netzwerken auf 

herkömmliche Weise erarbeiten; Mit den 4 NXT ein BT-Netzwerk 

aufbauen (Anhang C – AB 3) und als weiteren Typ von Netzwerken 

nach bestimmten Merkmalen (Adressierung, Nachrichtenaustausch) 

untersuchen; Master-Slave Aufbau von NXT Netzwerken 

mit Client-Server vergleichen 

Mit den NXT Bausteinen ein BT-Netzwerk aufbauen (Anhang C – 

AB 3) und Nachrichten über BT übermitteln lassen 

Grenzen der Übermittlung (Reichweite, Störungen) zeigen und 

sicherheitstechnische Aspekte untersuchen (evtl. versuchen die 

Nachrichten mit BT-Funktion von Handys oder mit PC abzufangen; 

die gewonnen Erfahrungen mit BT-Übermittlung mit anderen 

Übertragungswegen vergleichen 

Codierung von Informationen 

LP 1-3 

{2} s. oben 

Text Nachrichten mit unterschiedlichen Kryptographiemethoden 

(Caesar oder Zahlencode) codieren, über BT-Netzwerk versenden 

und anschließend decodieren lassen 

Parallelprozessdatenverarbeitung 

LP 1-2 

kein BS 

Bezug 

Robotermodell Fahrer 

oder Lagerist (s. 

implementierte Linienverfolgung) 

RobLinien.rbt 

(von L. mit zusätzlichen 

Bildschirmausgaben, den 

Sensorwerten erweitert) 

die parallele Abfrage beider Lichtsensorwerte zur Linienverfolgung 

mit dem Modell untersuchen (Steuerung der Wiederholungssequenzen 

über Boolean-Variablen), ist durch bereits implementierte 

Lichtwertanalyse leicht möglich; 

Erkenntnisse auf ähnliche Problemstellungen übertragen 

Informatisches 

Grundkonzept 

Bildungsplanbezug 

benötigte Hardware 

von der LV u. evtl. 

Nachbau durch S. 

benötigte Software der 

LV u. notwendige Modifikation 

d. Lehrers 

Vorschlag zur unterrichtsmethodischen Umsetzung 

Tabelle 10: Informatische Konzepte u. Modulbezug zur Lagerverwaltung


3.3 Skizze des Gesamtkonzepts 

3.3.1 Allgemeine Beschreibung des Szenarios 

Bei der robotergesteuerten Lagerverwaltung wird ein von Robotern gesteuertes 

Lagersystem modelliert. Solche Systeme werden beispielsweise bei Hochregallagern, 

in Postverteilstationen und automatischen Kommissionierstationen verwendet. 

Mit insgesamt vier Robotereinheiten, welche über Bluetooth (BT) kommunizieren 

und sich gegenseitig Kommandos geben, wird bei der LV ein Paket 

(Abbildung 27) von einer Annahmestelle bis zu einem Lagerplatz transportiert. 

Die Robotereinheiten fahren dabei sensorgesteuert eine markierte Strecke ab 

(Abbildung 28). 

Bei der robotergesteuerten Lagerverwaltung kommen in diesem Entwurf insgesamt 

vier LEGO MINDSTORMS education Basissets (LEGO Nr. 9797) und vier 

Ergänzungssets (LEGO Nr. 9648) zum Einsatz. 

Abbildung 27: Transportbox 

Abbildung 28: Streckenführung 

In dem Szenario wurde als Basischassis ein einfach gebauter Linien verfolgender 

Roboter (sehr wenig Bauteile – Aufbau in ca. 15 Minuten 49 => Zeitersparnis) 

eingesetzt, der je nach Anforderungen mit Zusatzanbauten versehen wurde. 

Ein Nachbau im Rahmen eines größeren Roboterprojektes ist mit den auf der 

DVD beiliegenden Aufbauanleitungen als Fotoserie und dem eingesetzten 

kommentierten Quellcode möglich. 

49 zum Vergleich: 

der in der LEGO Software beschriebene Linienverfolger mit Aufbauanleitung besteht aus deutlich 

mehr Bauteilen; für seinen Aufbau benötigte der Autor über 30 Minuten.

- 52 - 


3.3.2 Verwendete Robotereinheiten und technische Realisierung 

Insgesamt werden folgende Robotereinheiten verwendet: 

1. Die „Annahme“ (Abbildung 29): 

Hier wird das Paket angenommen und einer der vier möglichen Lagerplätze im 

Regal über den Druck der Tastsensoren eins bis vier festgelegt. Diese Lagerplatznummer 

wird anschließend über BT an den „Fahrer“ übermittelt. Das Paket 

wird danach über motorbetriebene Förderbänder zum „Lagerist“ transportiert 

und fällt dort in die bereitliegende Auffangvorrichtung. 

Abbildung 29: „Roboter Annahme“ 

2. Der „Lagerist“ (Abbildung 30): 

Dieser Roboter sendet nach dem Eintreffen des Pakets eine BT-Nachricht an 

den „Fahrer“, dass er ein Paket abholen kann. Er wartet auf eine BT-Nachricht 

die der „Fahrer“ beim Erreichen des Übergabepunktes sendet und folgt dann 

selbst einer markierten Linie zum Treffpunkt. Wenn beide Roboter am Übergabepunkt 

angekommen sind, wird der „Fahrer“ vom „Lagerist“ „eingewiesen“ und 

ein Druckkontakt löst die motorisierte Übergabe (Überwurfvorgang, bei dem das 

Paket um 180° gedreht wird) aus. Nach Abfahrt des „Fahrers“ begibt sich der 

„Lagerist“ in seine Ausgangsposition zurück. 

Abbildung 30: „Roboter Lagerist“


3. Der „Fahrer“ (Abbildung 31): 

Dieser Roboter wartet am Startpunkt auf eine Nachricht (die Lagerplatznummer) 

von der „Annahme“ und auf die Nachricht über ein eingetroffenes Paket 

vom „Lagerist“. Hat er beides erhalten, fährt er einer Linie folgend zum Übergabepunkt. 

Hier wartet er auf die Ankunft des „Lageristen“ und rangiert zurück bis 

sich die beiden Roboter berühren. Nach erfolgter Übergabe nimmt er seine ursprüngliche 

Linienverfolgung wieder auf und fährt bis zum „Stapler“. An diesen 

übergibt er anschließend das Paket (Muldenkipperähnlicher Klappvorgang bei 

dem die Ladevorrichtung motorgesteuert nach unten gefahren wird) und die 

Regalplatznummer. Abschließend kehrt er wieder zu seinem Startpunkt zurück. 

Abbildung 31: „Roboter Fahrer" 

4. Der „Stapler“ (Abbildung 32): 

Der „Stapler“ wartet auf das Paket vom „Fahrer“. Hat dieser das Paket abgeladen, 

fordert er die Lagerplatznummer mit einer BT Nachricht an. Hat er diese 

Information vom „Fahrer“ über BT erhalten, steuert er das entsprechende Regal 

an. Die Lagernummer wird dabei solange mit einer Lichtsensorgesteuerten 

Zählvariable verglichen, bis das Ziel erreicht ist. Hier wird das Paket (mit einem 

gabelstaplerähnlichen Bewegungsablauf) abgelegt und der „Stapler“ kehrt zur 

Ausgangsposition zurück. 

Abbildung 32: „Roboter Stapler“

- 54 - 


Aufgrund der Lichtempfindlichkeit der verwendeten Lichtsensoren ist für den 

reibungslosen Ablauf eine vorherige Kalibrierung ratsam. In dem verwendeten 

Quellcode wird der Benutzer über Textausgaben auf den NXT Bausteinen 

(Abbildung 33) von „Fahrer“ und „Lagerist“ durch diesen Prozess geleitet. Die 

NXT Bausteine zeigen auch Textmeldungen zu ihrem jeweiligen Zustand oder 

Status während des Gesamtprozesses an. Damit diese Kalibrierung möglichst 

selten durchgeführt werden muss, wurde eine Neustartfunktion nach drei erfolgreichen 

Durchläufen implementiert. Bei einem Neustart bleiben die zuvor eingestellten 

Kalibrierungswerte erhalten. 

Da diese Textmeldungen im Unterrichtsalltag nicht von allen Schülern einsehbar 

wären, wurden zusätzliche Sounddateien eingebettet, mit denen die Roboter 

Aktionen und ihre Kommunikation untereinander ankündigen. 

Der Programmcode der einzelnen Roboter kann mit der beiliegenden DVD eingesehen 

und selbst ausprobiert werden. Aufgrund der Komplexität und des Umfangs 

der Programme wurden diese ebenfalls in Module (insgesamt ca. 85) gegliedert, 

welche unabhängige Funktionseinheiten darstellen. Jedes Modul ist 

kommentiert und seine Arbeitsweise skizziert (Abbildung 34 und Abbildung 35). 

Da der Speicherplatz der NXT Bausteine sehr beschränkt ist, müssen vor dem 

Herunterladen der Roboterprogramme vorinstallierte Demodateien und Animationen 

gelöscht werden. Eine ausführliche Anleitung und entsprechende Sicherungskopien 

der zu löschenden Dateien stehen dem Leser ebenfalls auf der 

DVD zur Verfügung. 

Abbildung 33: Beispiele für Textausgaben auf NXT LCD 

Abbildung 34: 

Programmmodule 

Abbildung 35: Beispiel für Codekommentierung


3.3.3 Didaktische Abstraktion und Reduktion 

Für den Schuleinsatz wurde die LV an diversen Stellen didaktisch reduziert und 

abstrahiert. Bei der Entwicklung wurden folgende Funktionalitäten realer Lagerverwaltungssysteme 

nicht berücksichtigt: 

- Kennzeichnung und Identifikation der Waren mit Barcodes oder RFID Chips. 

- Speicherung der Lagerposition in einer globalen Datenbank. 

- Die Ausgabe von Waren. 

- Die Anzahl der Lagerpositionen und Waren wurde auf drei beschränkt. 

- Der Transport unterschiedlicher Waren ist nicht möglich (Waren, dürfen ein 

bestimmtes Gewicht nicht überschreiten und müssen in die einheitliche 

Transportkiste passen). 

- Die Wege der Roboter wurden minimiert (Gesamtfläche der Streckenführung 

ca. 3 m²). 

- Die Transportbox wird nur an drei Stellen von den Robotern übergeben. 

- Die Mechanik wurde so einfach wie möglich gehalten. 

- Das System ist zwar selbststeuernd, jedoch nicht zu 100% fehlerresistent. 

- Die verwendeten Programme wurden hinsichtlich Soundausgaben minimiert. 

Die beschriebene Reduktion hatte neben Beschränkungen des Robotersystems 

(Hardware und Softwaretechnischer Art) folgende Gründe: 

- Das System sollte nicht in mit Funktionalitäten überfrachtet werden. 

- Es sollten Vergleiche zwischen zentral gesteuerten und dezentral gesteuerten 

Verwaltungssystemen möglich sein. 

- Der Gesamtablauf sollte nicht länger als zehn Minuten dauern, um Unterrichtszeit 

bei der Videopräsentation zu sparen. 

- Schüler sollten Robotereinheiten teilweise nachbauen können. 

- Die Schüler sollten die Grenzen des Robotersystems erfahren. 

Die didaktische Abstraktion, also die Zuordnung von Begriffen zu realen Komponenten 

wurde folgendermaßen vorgenommen: 

- Die Roboternamen wurden hinsichtlich ihrer Hauptfunktionalität vergeben 

(z.B. Roboter „Annahme“ nimmt das Paket vom Menschen an). 

- Der Begriff „Modul“ erfüllt zweierlei Funktionen: 

⇒ Programm-/Softwaremodul als Unterprogramm, Prozedur bzw. Funktion 

⇒ Unterrichtsmodul als Unterrichtsthemen oder –Sequenzen 

- Bei den Softwaremodulen wurde die Namensgebung der Hauptfunktion angepasst 

(Lichtsensorkalibrierung am Eingang 1 im Modul „LichtKalib1.rbt“). 

- Die Softwaremodule (eigene Blöcke) sind vom Autor in der LEGO MIND- 

STORMS Education Software mit grafischen Symbolen versehen worden, 

die ebenfalls auf ihre Funktion hindeuten (Abbildung 34). 

Durch diese Abstraktion ist das Gesamtprojekt leichter zu strukturieren und zu 

beschreiben. Werden die aufgeführten Bezeichnungen (also die aus der Funktion 

des Roboters/Softwaremoduls generierten Namen) im Unterricht verwendet,

- 56 - 


können die Schüler den Beschreibungen leichter folgen, da der Begriff selbsterklärend 

ist. Außerdem ist der Verfasser dieser Arbeit der Meinung, dass Informatiklehrer 

eine möglichst konsistente Namensgebung bei Computerdateien 

vorleben sollten. Der Autor hat bereits mehrmals die Erfahrung gemacht, wie 

viel Unterrichtszeit beim Suchen oder Sortieren verloren gehen kann, wenn Dateien 

mit Standardnamen versehen wurden (Bsp. "Digicam": Bild01.jpg bis 

Bild26.jpg). Schüler sollten deshalb während des gesamten Informatikunterrichts 

Strukturierungsprinzipien vermittelt bekommen. 

3.4 Exemplarische unterrichtsmethodische Umsetzung 

Im Lehrplan der bayrischen Realschule ist im Fach Informationstechnologie im 

Modul Multimedia (Unterpunkt: „I5“) die Durchführung eines Projekts (Umfang 

ca. 20 Unterrichtsstunden) vorgesehen 50 . Die Schüler sollen mit Hilfe informationstechnischer 

Mittel und Arbeitstechniken ein Projekt verwirklichen und dokumentieren. 

Als Legitimation dieses Projekts dienen die in den Lehrplänen zuvor 

beschriebenen Themen LP 1-1, 1-2, 1-3, 2-2, 2-4 und 2-5 aus Tabelle 8. Durch 

eine Realisierung mit Hilfe der Projektmethode verfolgt der Verfasser für die 

beteiligten Schüler neben den fachlichen Inhalten weitere Ziele: 

- Förderung der Selbstorganisation und Selbstverantwortung der Schüler. 

- Schüler arbeiten produktorientiert und es entsteht ein vorzeigbares Produkt. 

- Es sollen viele Sinne einbezogen und kognitive, motorische sowie affektive 

Kompetenzen erworben werden 

- Das gemeinsame Lernen und Arbeiten im Projekt soll den sozialen Umgang 

der Schüler untereinander verbessern. 

- Die Auseinandersetzung und Arbeit mit verschiedenen Fachbereichen soll 

die Interdisziplinarität 51 fördern. 

Das folgende Projekt zur „BT Kommunikation“ besteht aus den Modulen A1 und 

A2 der Algorithmik und der Nachrichtenübermittlung aus Tabelle 10. Die Einordnung 

in die Bildungspläne ist mit LP2-1, LP1-3, BS 1-1, BS1-2, BS1-3 und 

den Inhaltsbereich „Information und Daten“ der BS gesichert. Diese breite Absicherung 

durch die Bildungspläne und die gute Verzahnung mit der LV waren 

die Hauptgründe für die Wahl dieses Moduls. 

Die im Folgekapitel dargestellte Unterrichtsplanung weicht bei manchen Ausführungen 

von der Idealvorstellung der Projektmethode ab. So arbeiten die 

Schülergruppen nicht strikt arbeitsteilig, es gibt keine Gruppe, die sich ausschließlich 

Programmieraufgaben widmet. Eine solch strenge Gruppeneinteilung 

hätte zur Folge, dass es auch eine Roboterbaugruppe gibt. Dies würde 

den restlichen Schülern das Vergnügen des Roboterbaus vorenthalten und 

Stress bzw. Neid in der Klasse aufkommen lassen. Aus diesen Gründen erfolgte 

eine gemischte Gruppenbildung. Der Autor bezieht sich im Folgenden auf die 

von Frey 52 beschriebenen Projektmethodenphasen. 

50 Lehplanentwurf für bayerische Realschulen mit flexibler Stundentafel (ab 2008 gültig) 

http://www.realschule.bayern.de/lehrer/materialien/it/it2008/?id=2248 (zuletzt aufgerufen am 

30.09.08) 

51 http://de.wikipedia.org/wiki/Interdisziplinarität (zuletzt aufgerufen am 30.09.08) 

52 http://www.seilnacht.com/projekt.html#4 (zuletzt aufgerufen am 30.09.08)


3.4.1 Grobe Unterrichtsplanung für ein Projekt der robotergesteuerten Lagerverwaltung 

Für das LV-Projekt hat der Verfasser folgende organisatorische Rahmenbedingungen 

festgelegt: 

- Als Zeitrahmen für das Projekt sind insgesamt 24 Schulstunden (Doppelstunden 

(DS) à 90 Min) vorgesehen. 

- Es nehmen 15 Schüler (9. Klasse einer Realschule) und die Lehrkraft teil. 

- Der Unterricht findet im Computerraum mit 15 Rechnerplätzen inklusive Internetanschluss 

(zur Informationsrecherche) statt. 

- Der Klasse stehen insgesamt zehn LEGO-NXT-Bausteine, mehrere LEGO 

MINDSTORMS Education Basissets und Ergänzungssets zur Verfügung. 

Die 15 Schüler sind in fünf Gruppen mit jeweils drei Schülern eingeteilt. Während 

der Arbeit am Projekt übernehmen die Schüler folgende Rollen: 

- Gruppenleiter und -sprecher: 

Er fungiert als Hauptansprechpartner des Lehrers, muss die Gruppe lenken und 

organisieren, nimmt an den Gruppenleitersitzungen am Stundenanfang teil und 

teilt seiner Gruppe die Ergebnisse der Besprechung mit. Aufgrund der hohen 

Anforderungen sollte diese Rolle von einem sehr guten Schüler besetzt werden. 

- Materialbeauftragter: 

Dieser Schüler ist für die Materialien zuständig. Er holt am Stundenanfang die 

Roboterbaukästen bzw. -modelle, überprüft sie auf Vollständigkeit und räumt 

das Material wieder auf. Der Materialbeauftragte sollte außerdem über sehr gute 

Programmierkenntnisse verfügen. 

- Dokumentar: 

Diese Rolle dient der Dokumentation der Gruppenarbeit. Der Schüler führt das 

Gruppentagebuch und beschreibt darin aufgetretene Probleme, deren Lösung 

und hält Aufgabenergebnisse fest. Dieser Schüler könnte der fachlich 

schwächste der Gruppe sein, seine Begabungen könnten eher in den Geisteswissenschaften 

liegen. 

Die Schüler wurden hinsichtlich ihrer Qualifikationen bewusst so eingeteilt, damit 

ein möglichst gleichartiges Niveau aller Gruppen sichergestellt wird. Die 

verbleibenden Unterschiede der Gruppen kann der Lehrer mit unterschiedlichen 

Aufgabenstellungen (weitere Differenzierung) beheben. 

Die Schülerbewertung ergibt sich neben dem Abschlusstest aus Folgendem: 

- Individuelle Bewertung der Gruppenleiter in den Gruppenleitersitzungen 

(Gesprächsbeteiligung, Qualität der Beiträge, Fachsprache, etc.). 

- Individuelle Bewertung der Dokumentare mit dem Tagebuch (Gestaltung 

und Aufarbeitung der Einträge, fachliche Richtigkeit). 

- Individuelle Bewertung der Materialbeauftragten mit den entwickelten Programmen 

(Programmierleistung und Materialorganisation). 

- Gruppenbewertung aufgrund des Gesamteindrucks des Gruppentagebuchs 

(Qualität der Einträge, Umfang und Art der Beschreibungen). 

- Allgemeine Bewertung der Arbeitweise der Gruppe im Vergleich zu anderen 

(Arbeitsorganisation, Sozialer Umgang, Aufgabenteilung, etc.).

- 58 - 


DS- 

Nr. 

01 

02 

03 

04 

05 

Projektphase 

Projektinitiative 

mit Projektskizze 

Projektplanung 

Arbeit am Projekt 

Unterrichtseinheit Stundeninhalt Stundenablauf 

Einführung in Robotersysteme 

und Projektmethode 

fachliche Grundlagen 

Arbeit mit dem Robotersystem 

Video der Lagerverwaltung 

technische Hintergrundinformationen 

zum LEGO MIND- 

STORMS NXT System 

organisatorische Rahmenplanung 

des Projektes 

Entwicklung eines 

Projektplanes 

Möglichkeiten und 

Kennzeichen der 

Nachrichtenübertragung 

Bluetooth- 

Kommunikation und ihr 

Einsatz 

Roboterbau nach Anleitung 

- Lehrer zeigt seinen Schüler das Video der LV 

- Er gibt technische Hintergrundinformationen (Motoren, Programmierung 

und Sensoren) d. NXT Robotersystems 

- L. stellt einige Module für ein Unterrichtsprojekt aus der Lagerverwaltung 

(Tabelle 10) vor 

- L. u. S. einigen sich auf das Modul „BT Kommunikation“ 

- L. u. S. erarbeiten gemeinsam eine Projektskizze vom Modul „BT 

Kommunikation“ 

- Gruppeneinteilung u. Schülerrollen mit ihren Aufgabenbereichen 

- Offenlegung der Bewertungskriterien 

- Beschreibung der Funktion und des Aufbaus des Gruppentagebuchs 

mit Beispieleintrag 

- Entwicklung des Projektplanes 

S.-Gruppen recherchieren im Internet und Literatur aus der Schulbücherei 

verschiedene Möglichkeiten der Nachrichtenübertragung, 

Kennzeichen, Geschichte und Details zur technischen Realisierung 

Jede Gruppe hat ein eigenes Recherchethema, z.B.: 

- Akustische Nachrichtenübertragung mit Telefon und Handys 

- E-Mail, der Brief des 20.Jahrhunderts 

- Funknachrichten in Hobby und Beruf u.ä. 

S.-Gruppen arbeiten an folgenden Fragestellungen 

- Welche Geräte können über BT miteinander kommunizieren? 

- Was sind die Grenzen von BT (Reichweite, Bandbreite o.ä.)? 

- Wie können die NXT Roboter über BT kommunizieren? 

- Welche Art von Informationen können bei den NXT Robotern ü- 

bermittelt werden (Texte, Zeichen oder Zahlen)? 

S.-Gruppen bauen jeweils eigene Robotermodelle nach Anleitung auf 

(1) Modell, dass sich raupenartig fortbewegen kann 

(2) Modell, dass mit einem Arm (motorengesteuert) winkt 

(3) Modell, dass seinen Kopf (den Ultraschallsensor) neigt 

(4) Modell, dass im Kreis fährt 

(5) Modell, dass mit einem Greifarm Bälle wirft 

- 58 - KAPITEL 3: ENTWURF EINER ROBOTERGESTEUERTEN LAGERVERWALTUNG 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

06 

07 Programmentwicklung 

08 

09 

10 

DS- 

Nr. 

Fixpunkt 

Einführung in grafische 

Entwicklungsumgebung 

Projektabschluss 

Projektphase 

Reflexion und Ausblick 

Unterrichtseinheit 

Implementierung und 

Test der Programme 

Möglichkeiten und 

Grenzen der Roboter 

Projektreflexion und Abschlusstest 

Gesamtproduktpräsentation 

Stundeninhalt 

Die S.-Gruppen .. 

… sammeln erste Erfahrungen mit der Bedienung der grafischen 

Entwicklungsumgebung (Material Anhang C, AB 1 u. 2) 

… dekonstruieren u. analysieren vorgegebene LV-Programmmodule 

... testen relevante Funktionalitäten für ihr Robotermodell 

… fangen an Algorithmen und Programmbeschreibungen für 

anstehende Programmentwicklung zu formulieren 

Der L. erarbeitet mit den Schülern gemeinsam die Kennzeichen der 

BT-Übertragung in der LV und ihre Bedeutung für die Ablaufsteuerung 

Die S.-Gruppen … 

… bauen ein BT-Netzwerk aus ihrem Robotermodell und einem 

weiteren NXT-Baustein auf (Material Anhang C, AB 3) 

… einigen sich auf zu übertragende BT Nachrichten 

… bauen in ihre Programmbeschreibungen die jeweilige Verbindungs- 

(Adressen) und Mailboxnummern ein 

… einigen sich darauf welche, wie viele und wie sie die Programme 

implementieren wollen 

Die S.-Gruppen … 

… implementieren ihre Programme 

… testen sie mit dem Netzwerk aus 2 NXT-Bausteinen 

… suchen Parallelen der Ablaufsteuerung der LV u. ihrer Umsetzung 

(zusätzl. Material: Video u. Hauptprogramme mit Untermodulen) 

Die Schüler diskutieren mit der Lehrkraft über … 

… weitere Möglichkeiten der BT-Steuerung 

… ihre Lösungen und der BT-Steuerung in der LV 

L und S erarbeiten gemeinsam wie sie alle ihre Modelle über den 

Rechner mit BT-Signalen steuern können (erarbeiten Gesamtprodukt) 

gemeinsame Reflexion über den Projektverlauf und das Produkt 

Stegreifaufgabe zur Überprüfung auf Erreichen der Lernziele 

Stundenablauf 


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 

Tabelle 11: Grobe Stundenplanung des Projekts "BT Kommunikation


Die in Tabelle 11 beschriebene Grobplanung der Stunden im Projekt kann bereits 

als Ergebnis der Projektplanung angesehen werden. Im Anschluss wird 

der Verfasser die Stundenorganisation von Tabelle 11 begründen. 

Während der „Arbeit am Projekt“ (DS 03 bis 08) sind die Stunden so organisiert: 

Am Anfang findet jeweils eine zehnminütige Sitzung der Gruppenleiter mit dem 

Lehrer statt. Hier werden Informationen und die jeweiligen Ergebnisse der 

Gruppen ausgetauscht. Für Lehrer (L) ist diese Phase sehr wichtig, da sie in Ihr 

feststellen können, wenn Schüler (S) vor großen Problemen stehen. Diese können 

sie im Anschluss durch Modifikation der Aufgabenstellungen oder durch 

kurze lehrerzentrierte Unterrichtsphasen lösen. In dieser Zeit kann der Materialbeauftragte 

die Materialien holen, sie auf Vollständigkeit überprüfen und die 

Rechner starten. Der Dokumentar kann die Zeit nutzen um die Abschlussnotizen 

der letzten Stunde auf einem DIN A5 Blatt strukturiert aufzubereiten. Dieses 

Blatt wird vom Materialbeauftragten fünf Mal kopiert und an die restlichen Gruppen 

verteilt. In den nächsten fünf bis zehn Minuten teilt der Sprecher seiner 

Gruppe die Ergebnisse und den Stand der anderen Gruppen mit, die Gruppenmitglieder 

können seine Ausführungen auf den DIN A5 Blättern ergänzen. Die 

folgenden 60 bis 65 Minuten Arbeiten die Schülergruppen gemeinsam an den 

jeweiligen Aufgabenstellungen. Die letzten zehn Minuten einer Doppelstunde 

werden vom Dokumentar dazu genutzt, Abschlussnotizen (Was wurde wie erreicht, 

wie ist der momentane Stand der Gruppe) der Stunde zu formulieren. 

Der Gruppenleiter kann ihm dabei helfen und sich Notizen für die nächste Besprechung 

machen. Der Materialbeauftragte der Gruppe räumt das Material auf, 

fährt die Rechner herunter und verteilt Ausdrucke an seine Gruppenmitglieder. 

Die DS 1 u. 2 dienen der Organisation des Projekts und geben den Schülern 

einen Einblick dessen, was sie erwartet. DS 3 u. 4 untermauern das Projekt mit 

fachlichem Hintergrundwissen und stellen die Basis für selbstständige Arbeit in 

den Folgestunden. Der Lehrer kann die Schülergruppen einerseits durch die 

Aufgabenstellungen lenken, andererseits kann der Lehrer falls er bei den Besprechungen 

Mängel feststellt, durch kurze lehrerzentrierte Phasen Wissenslücken 

ausgleichen. Außerdem können die Schüler in DS 4 (bei geschickter und 

breiter Aufgabenstellung) ihr Allgemeinwissen verbessern. In DS 5 arbeiten die 

Schüler praktisch mit den Robotermodellen. Der hardwarebezogenen DS 5 folgt 

mit DS 6 (durch das Arbeiten mit der Entwicklungsumgebung) der Softwarebezug. 

Die Schüler bekommen von der Lehrkraft hierfür die Arbeitsblätter 1 u. 2 

aus Anhang C. Der „Programmleitfaden zur LEGO MINDSTORMS Edu NXT 

Software“ (Arbeitsblatt 1) gibt den Schülern eine Übersicht der Symbole und 

deren Bedeutung. Dieses Arbeitsblatt hat Verfasser mit Hilfe der Literaturquelle 

[29] erstellt. Es soll Schülern hauptsächlich den Einstieg und die Bedienung 

erleichtern. Die „Anleitung zur Programmentwicklung“ (Arbeitsblatt 2) ist eine 

Schritt-für-Schritt-Anleitung zur Erstellung des ersten Roboterprogramms. Dieses 

Arbeitsblatt soll speziell unsicheren und schwächeren Schülern Anfangshemmungen 

nehmen. In der DS 7 sollen die Schüler mit dem Arbeitsblatt 3 

„Einrichtung eines Bluetooth-Netzwerkes zwischen oder mehreren NXT- 

Bausteinen“ (mit Hilfe von [28] und [29] erstellt) ein BT-Netzwerk aufbauen. Da 

dies nicht gerade einfach ist, sollte der Lehrer das AB 3 mit der Klasse einmal 

durchgehen und die Einrichtung des Netzwerks vorführen. Nachdem die Netzwerkfunktion 

erfolgreich eingestellt wurde, klären die Schüler Details der BT- 

Einstellungen (Adresse und Mailboxnummer) und entwickeln strukturiert ihre 

Programme. In der folgenden DS 8 werden diese Programme implementiert


und mit einem BT-Netzwerk getestet. Falls die Gruppen noch Zeit haben, können 

sie die LV mittels dem Video und den Programmmodulen tiefer analysieren. 

In der DS 9 erfolgt als geplanter Fixpunkt eine gemeinsame Reflexion über erreichte 

Ziele und den Projektverlauf. Der Lehrer kann an dieser Stelle mit den 

Schülern erarbeiten, wie die BT-Signale vom Rechner aus an alle NXT-Roboter 

gesendet werden können. Hiermit kann ein Gesamtprodukt erarbeitet werden. 

Die DS 10 markiert den Projektabschluss. Hier kann der Lehrer das geplante 

Gesamtprodukt präsentieren (Das Senden der BT-Nachrichten vom Rechner 

aus an alle NXT-Bausteine ist von Schülern wahrscheinlich nicht zu bewältigen). 

Abschließend wird mit einer Stegreifaufgabe erreichtes Wissen geprüft. 

3.4.2 Detaillierter Entwurf der Unterrichtseinheit „Arbeit mit dem Robotersystem“ 

Die DS 6 der Projektphase „Arbeit mit dem Robotersystem“ (Tabelle 11) wird im 

folgenden Kapitel genauer ausgearbeitet. Die anderen DS dieser Phase (DS 5: 

„Bau der Roboter“; DS 7: „Programmentwicklung“ und DS 8: „Implementierung 

u. Programmtest“), wurden aus Gründen des Umfangs dieser Arbeit bewusst 

ausgelassen. Ihre Stundenbeschreibung würde erstens sehr dürftig ausfallen, 

da die Schüler hauptsächlich praktisch arbeiten und zweitens müssten hierfür 

weitere Aufbauanleitungen zu den fünf beschriebenen Robotern erstellt werden. 

Der Autor ist zudem der Meinung, dass diese Unterrichtseinheit die interessanteste 

Phase des Projekts ist und die S. leicht Parallelen zur LV ziehen können. 

3.4.2.1 Angenommene Vorkenntnisse der Schüler 

Für den detaillierten Entwurf werden folgende Schülerkenntnisse vorausgesetzt: 

- Sie verfügen über praktische u. theoretische Erfahrungen zu grundlegenden 

algorithmischen Strukturen (Kontrollstrukturen, Schleifen u. Variablen). 

- Sie haben ihren Roboter in der Gruppe aufgebaut u. kennen das LV-Video. 

- Sie haben bereits andere grafische Entwicklungsumgebungen (z.B. 

„SCRATCH“) gesehen und teilweise damit gearbeitet oder kennen Robotersimulationen, 

wie z.B. „KARA“. 

3.4.2.2 Fachliche Zielsetzungen – Lernziele für Schüler 

In diesem Kapitel beschreibt der Verfasser seine fachlichen Zielsetzungen für 

das vorgestellte Gesamtprojekt und die Unterrichtseinheit. 

Ref- 

Nr. 

GZ 1 

Grobziele des Gesamtprojektes – die Schüler sollen … 

... gemeinsam in Arbeitsteilung und in Selbstverantwortung Aufgaben 

bearbeiten. 

Bezug auf 

Bildungspläne 

BS 4-1 

BS 4-2 

GZ 2 ... Algorithmen (Handlungsvorschriften) entwickeln u. testen. LP 2-1 BS 1 

GZ 3 

GZ-4 

GZ-5 

... das Zusammenspiel und die Abhängigkeiten von Hard- und 

Software bei Bau eines Robotermodells praktisch erfahren und 

beurteilen können. 

... grafische Entwicklungsumgebungen zum programmieren 

kennen lernen sowie. Beispielprogramme bewerten/analysieren, 

... Bluetooth Nachrichten (in einem Netzwerk aus mind. zwei 

NXT Bausteinen) versenden und mit ihnen Programmereignisse 

auslösen können. 

Tabelle 12: Übersicht der Grobziele des Projekts 

LP 1-1 

LP 1-2 

BS 2-2 

LP 2-1 BS 2-2 

LP 2-5 

LP 2-1 

LP 1-3 

BS 3-1


Für die Unterrichtseinheit Nummer 6 wurden aus Tabelle 12 weitestgehend o- 

perationalisierte Feinziele abgeleitet. In Tabelle 13 sind diese Feinziele den jeweiligen 

Grobzielen zugeordnet. 

Ref- 

Nr. 

Feinziele - die Schüler sollen … 

Bezug auf 

Grobziele 

FZ 6-1 ... die Funktionen eines NXT Programms beschreiben können. GZ 4 

FZ 6-2 

... die Bedienung grafischer Entwicklungsumgebungen mit Hilfe 

der LEGO MINDSTORMS Edu Software an Beispielen üben. 

GZ 4 

FZ 6-3 ... Handlungsvorschriften für ihre Robotermodelle formulieren. GZ 2 

FZ 6-4 

... selbst entwickelte Programme in Abhängigkeit von der Entwicklungsumgebung 

beschreiben können. 

GZ 2 u. 4 

FZ 6-5 ... anderen Schülern ihre Ergebnisse präsentieren können. GZ 1 

FZ 6-6 

... lernen, mit empfindlichen Materialien verantwortungsbewusst 

umzugehen und ihre Aufgaben arbeitsteilig zu organisieren. 

GZ 1 

Tabelle 13: Übersicht der Feinziele der Unterrichtseinheit 

In Tabelle 14 hat der Autor eine Einordnung der zuvor beschriebenen Lernziele 

nach der Taxonomietabelle von Anderson und Krathwohl 53 vorgenommen. Da 

sich die Lernziele aber nicht trennscharf in einem Bereich einsortieren lassen, 

treffen die angrenzenden Bereiche meistens ebenfalls zu. 

Erinnern Verstehen Anwenden Analysieren Bewerten 

Faktenwissen X X GZ 2 GZ 2 X 

Begriffliches 

Wissen 

Verfahrensorientiertes 

Wissen 

Metakognitives 

Wissen 

X FZ 6-1 

X FZ 6-2 

FZ 6-1 

GZ 5 

FZ 6-2,3 

(u. 1) 

GZ 2,5 

(u. 1) 

FZ 6-4 

GZ 4 

FZ 6-3 

GZ 2 (u. 1) 

FZ 6-4 

GZ 4 

GZ 3 u.4 

X X X X GZ 3 u.4 

Tabelle 14: Taxonomietabelle nach Anderson u. Krathwohl 

(Er-) Schaffen 54 

3.4.2.3 Ausführliche Stundenplanung zur Unterrichtseinheit 

Für die Ausarbeitung der DS 6 hat der Autor in Tabelle 15 folgende Abkürzungen 

verwendet: 

L = Lehrer S = Schüler AB = Arbeitsblatt 

PA = Partnerarbeit EA = Einzelarbeit GA = Gruppenarbeit 

UG = Unterrichts 

gespräch 

OH 

= Overheadprojektion 

BT 

= Bluetooth 

53 http://www.pri.univie.ac.at/workgroups/studienziele/index.php?m=D&t=info4&c=show& CE- 

WebS_what=Taxonomie-Tabelle (zuletzt aufgerufen am 30.09.08) 

54 Der Bereich „Erschaffen“ ist als höchste Kompetenzstufe mit keinem vorherigen Lernziel abgedeckt. 

Für diesen Bereich könnten Lernziele aus den DS 5: „Bau der Roboter“ und DS 7: 

„Programmentwicklung“ zutreffen.


Lernziele 

FZ 

6-6 

01 

10 Min 

02 

5 Min 

03 

5 Min 

04 

5 Min 

Nr. / 

Zeitbedarf 

Unterrichtszeit 

/ 

Phase 

0:10 

Einstieg 

0:15 

0:20 

Sicherung 

I 

0:25 

Einführung 

I 

Inhalt- und Ablaufplanung 

- Sitzung der Gruppenleiter mit L.: 

Gruppenleiter stellen Ergebnisse der 

letzten Stunde kurz vor, beschreiben 

Probleme und Lösungen. L. bekommt 

Einblick in Details, kann bewerten 

- Dokumentare erstellen DIN A5 Zusammenfassungen 

aus den Abschlussnotizen 

der letzten Stunde 

- Materialsammler holen die Robotermodelle, 

USB Kabel, schalten Rechner 

ein, verteilen die neuen Aufgabenblätter 

und kopieren die DIN A5 

Zusammenfassungen 

Gruppengespräch der Einzelgruppen 

(Wissensabgleich) 

Gruppenleiter beschreiben die Ergebnisse 

aus Sitzung, die anderen Mitglieder 

machen sich ergänzende Notizen 

auf Zusammenfassungen 

L. sichtet die Zusammenfassungen 

ergänzt Wichtiges aus Sitzung, erstellt 

OH-Folien 

Sozialform 

Gespräch 

EA 

EA 

GA 

Medien 

Notizen der 

Ergebnisse 

zur vorherigen 

DS 

DIN A5 

Zusammenfassung 

DIN A5 

Zusammenfassungen 

aller Gruppen 

Lehrer bespricht seine Ergänzungen 

mit der Klasse, korrigiert evtl. Fehler UG OH Folien 

- Besprechung der anstehenden Aufgaben 

(-blätter) AB 1 u. 2 

- Vorführung: Schritt für Schritt Anleitung 

zur Programmerstellung (AB2) 

durch Lehrer 

- L verteilt erste Aufgabe, zeigt sie 

kurz mit Beamer: 

A1: Analyse und Dekonstruktion eines 

Beispielprogramms mit Beschreibung 

der Funktion im Tagebuch 

UG 

OH Folien 

AB 1 u. 2 

Beamer 

Beispiel.rbt 

(auf DVD) 

FZ 

6-1 

05 

15 Min 

0:30 

Erarbeitung 

I 

Gruppen bearbeiten mit dem Programm 

Beispiel.rbt die Aufgabe A1. 

L. betreut die Gruppen abwechselnd, 

gibt Hinweise oder Hilfestellungen 

GA 

Rechner 

und 

Beispiel.rbt 

06 

5 Min 

0:35 

Einführung 

II 

L verteilt zweite Aufgabe, zeigt den 

Robot Educator mit Beamer: 

A2: Arbeit mit Einsteigerbeispielen 

der LEGO MINDSTORMS Education 

Software (Robot Educator) 

Nachbau von NR. 1 (Klang abspielen); 

2 (Display verwenden) und 3 

(vorwärts fahren mit Motoren) 

UG 

Beispiele f. 

Einsteiger 

in der 

Software 

Tafel (für 

Aufgabenstellung) 

Beamer 

FZ 

6-2 

07 

15 Min 

0:50 

Erarbeitung 

II 

Gruppen arbeiten mit dem Robot 

Educator, lesen die jeweiligen Aufgabenbeschreibungen 

u. schauen die 

Programmieranleitungen an, schreiben 

ihre Erfahrungen ins Tagebuch 

L. unterstützt bei Problemen 

GA 

Rechner 

Robot 

Educator 

AB 2


FZ 

6-5 

08 

10 Min 

0:60 

Präsentation 

L. wählt eine Gruppe aus und lässt 

sie ihre Erfahrungen vor der Klasse 

beschreiben und präsentieren 

die restliche Klasse kann ihre Erfahrungen 

ergänzen; 

L. korrigiert Fehler 

UG u. Zwischenpräsentation 

09 

5 Min 

0:65 

Einführung 

II 

L gibt ein Beispiel für eine Algorithmenbasierte 

Planung von Programmen 

und verteilt letzte Aufgabe 

A3: Grundgedanken für Programme 

zu dem Robotermodell der Gruppe 

sammeln, seine gewünschten Funktionen 

beschreiben, Algorithmen mit 

den kennen gelernten Symbolen der 

Software entwickeln 

UG 

Tafel (für 

Aufgabenstellung) 

FZ 

6-3 

6-4 

10 

20 Min 

0:85 

Erarbeitung 

II 

Gruppen fangen an, Algorithmen und 

Programmbeschreibungen für spätere 

Programmentwicklung zu formulieren. 

GA 

Rechner 

Gruppentagebuch 

FZ 

6-6 

11 

5 Min 

0:90 

Abschluss 

Gruppen erledigen Abschlussarbeiten 

Dokumentar erstellt Abschlussnotizen 

Gruppenleiter hilft ihm und notiert sich 

relevantes für die Sitzung 

Materialbeauftragter räumt den Roboter 

weg, fährt Rechner herunter und 

verteilt evtl. noch Ausdrucke an Gruppenmitglieder 

GA PA u. 

EA 

- 

Lernziele 

Nr. / 

Zeitbedarf 

Unterrichtszeit/ 

Phase 

Inhalt- und Ablaufplanung 

Sozialform 

Medien 

Tabelle 15: Stundenplanung der Einheit „Arbeiten mit dem Robotersystem“ 

In Tabelle 15 ist die detaillierte Stundenplanung der DS 6 beschrieben. Der 

Stundenablauf wurde so organisiert, dass es zu mehreren Wechseln der Sozialformen 

und Methoden im Unterricht kommt. So wird zum Beispiel nach jeder 

Aufgabenstellung von „Gruppenarbeit“ auf die Sozialform „Unterrichtsgespräch“ 

gewechselt. Mit diesen Wechseln möchte der Autor einen monotonen Unterricht 

vermeiden. 

Die Schüler wechseln auch oft die Arbeitsweise, so müssen sie zum Beispiel im 

Abschnitt 04 ein bestehendes Programm untersuchen und seine Funktionen 

verbalisieren, wohingegen sie im Abschnitt 07 selbst Programme nach einer 

Anleitung entwickeln können. Die Sicherung der Ergebnisse aus den Gruppenarbeiten 

erfolgt in der ausgearbeiteten DS hauptsächlich mit dem Gruppentagebuch 

der Schüler. Die Schüler arbeiten laut dem Projektplan bereits die vierte 

Unterrichtsstunde mit diesem Tagebuch, so dass die Einträge sicher das fachlich 

Relevante widerspiegeln. In den Gruppenarbeitsphasen kann der Lehrer die 

Schüler dabei beobachten, wie sie ihre Einträge gestalten. Sollten er dabei gravierende 

Fehler bemerken, kann er in den darauf folgenden Unterrichtsgesprächen 

sofort darauf eingehen. 

Die Schüler sollen in dieser Doppelstunde den Umgang mit der grafischen Entwicklungsumgebung 

lernen. Die angegebenen Arbeitsblätter können Ihnen dabei 

helfen. Außerdem dienen sie als Referenz für die weitere Entwicklung von 

Programmen in den Folgestunden. Da das Projekt in einer neunten Klasse ei-


ner Realschule abgehalten wird, sind die Sprache und die Formulierungen in 

den Arbeitsblättern dem Schüleralter entsprechend angepasst. 

In der Unterrichtstunde kommt mit dem „Robot educator“ (Abbildung 36) eine 

Programmfunktion der LEGO MINDSTORMS Education Software zum Einsatz. 

Der „Robot educator“ vereint Kurzfilme, Aufgabenbeschreibungen (Abbildung 

37) Aufbauanleitungen (Abbildung 39) und Programmieranleitungen (Abbildung 

38) von unterschiedlichen NXT Robotern. 

Die Programmbedienung und den Aufruf des „Robot educators“ sollte der Lehrer 

aus Altersgründen den Schülern einmal mit Hilfe des Beamers vorführen. 

Der Autor hat den “Robot educator“ aus mehreren Gründen in die Unterrichtsplanung 

mit aufgenommen. Seine Umsetzung ist ansprechend (Grafisch hochwertig) 

und die Bedienung (Multimediatasten mit Play, Vor-, Zurückspulen und 

Pause Funktion) sehr einfach gestaltet, was die selbstständige Einarbeitung 

erleichtert. Die S. können sich mit Hilfe der Bedientasten auch einzelne Schritte 

erneut ansehen. Dies ist beispielsweise bei einer Beamer-Präsentation durch 

den Lehrer nicht möglich. Sie haben außerdem auf jedem Rechnerplatz (bei 

dem die Education Software installiert ist) Zugriff auf den “Robot educator“. In 

den Gruppen können deswegen alle Schüler mit dem “Robot educator“ arbeiten 

und persönliche Erfahrungen sammeln. 

Als Hausaufgabenstellung für diese Doppelstunde bietet sich eine genauere 

Ausarbeitung der algorithmischen Beschreibungen von Aufgabe A3 an (damit 

hat der Lehrer auch noch einen zeitlichen Puffer für die Stundenplanung). 

Abbildung 36: „Robot Educator“ der Entwicklungsumgebung 

Abbildung 37: Aufgabenbeschreibung mit 

Videodateien im „Educator“ 

Abbildung 38: Programmieranleitungen 

des „Educators“ 

Abbildung 39: Schritt für Schritt Bauanleitungen 

des „Educators“

- 66 - KAPITEL 4: ZUSAMMENFASSUNG MIT SCHLUSSFOLGERUNG 

Das Erreichen der Lernziele könnten Lehrkräfte (neben dem im Projektplan beschriebenen 

Abschlusstest) auf folgende Art und Weise prüfen und sicherstellen 

(die beschriebenen Zeitabschnitte beziehen sich auf Tabelle 15): 

FZ 6-1: 

Hier könnte der L. im Zeitabschnitt 06 einzelne S. spezielle Programmfunktionen 

der „Beispiel.rbt“ Datei beschreiben lassen. 

FZ 6-2: 

Die bearbeiteten Programme des „Robot Educators“ (im Zeitabschnitt 07) können 

dem L. helfen, dass Erreichen dieses Lernziels sicherzustellen. Hierzu 

müssten die S. ihre Programme auf einem Netzlaufwerk speichern (Dateiname 

generiert sich aus Gruppen- und Aufgabennummer). Der L. kann diese Programmdateien 

im Nachhinein sichten. 

FZ 6-3 u.FZ 6-4: 

Die Algorithmenbeschreibung aus Zeitabschnitt 10 könnten von den Schülern 

mit dem Rechner verfasst werden. Der Materialbeauftragte kann am Ende der 

Stunde Ausdrucke dieser Dateien erstellen und sie seinen Gruppenmitgliedern 

geben. Die verwendete Software sollte über eine ausreichende Versionskontrolle 

verfügen. Mit dieser kann der L. neben der Ergebnisbewertung auch den 

Weg zur Lösungsfindung einsehen. 

FZ 6-5: 

Dieses Lernziel kann der L. durch gezielte (Verständnis-) Fragen an die Dokumentare 

und Materialveranwortlichen nach dem Zeitabschnitt 02 prüfen. Wenn 

diese S. die Fragen richtig beantworten können, hat der Gruppenleiter das FZ 

6-5 zumindest gut erreicht. In der DS 6 können alle S. der Gruppe ihre Präsentationsfähigkeiten 

im Abschnitt 08 (evtl. mit Vortragsfolien) zeigen. 

FZ 6-6: 

Im Zeitabschnitt 01 könnten die Gruppenleiter zum Klima in der Arbeitsgruppe 

befragt werden, um eventuelle Ungerechtigkeiten bei der Arbeitsverteilung festzustellen. 

In diesem Zeitabschnitt kann der L. auch einschätzen, ob die restlichen 

Gruppenmitglieder ihre Rollen auch arbeitsteilig übernehmen. Wenn alle 

S. konsequent und ernsthaft arbeiten und der L. in dieser Zeit nicht eingreifen 

muss, um die Arbeitseinteinteilung zu übernehmen, ist das FZ 6-6 zumindest 

teilweise erfüllt. Den zweiten Teil des FZ 6-6 (der verantwortungsvolle Umgang 

mit den Materialien) kann der L. während der GA Phasen beobachten. Eine 

Kontrolle der Materialien nach Stunden-Ende kann ihm zusätzlichen Einblick 

geben. 

Diese Vorschläge können den L. bei der mündlichen Notenfindung und der Bewertung 

unterstützen. Sie führen nicht zu einer „fertigen“ Notenstufe, sondern 

geben dem L. nur einen Einblick. Der L. sollte die genauen Notenkriterien (evtl. 

Bewertungsbögen) vorher mit den S. durchsprechen, damit sie vorbereitet sind. 

4 Zusammenfassung mit Schlussfolgerung 

4.1 Resümee über erworbene Erkenntnisse 

Das abschließende Kapitel dieser Arbeit wird ein persönliches Resümee des 

Verfassers sein. Dieser Teil ist natürlich durch subjektive Erfahrungen und 

grundsätzliche Einstellungen gekennzeichnet und wird deshalb nur bedingt 

fachlich neutral bleiben können.

KAPITEL 4: ZUSAMMENFASSUNG MIT SCHLUSSFOLGERUNG - 67 - 

4.1.1 Möglichkeiten der Robotersysteme für den Unterricht 

Robotersysteme können - wie bereits an mehreren Stellen dieser Arbeit beschrieben 

- auf Schüler hoch motivierend wirken. Diese Motivation kann sich 

auf die Grundeinstellung zum Fach Informatik positiv auswirken und eine erhöhte 

Leistungs- und Lernbereitschaft zur Folge haben. Speziell für Mädchen kann 

dies laut den Ergebnissen der Literaturquellen dazu führen, dass Hemmungen 

und Vorurteile abgebaut werden und ihr Interesse für informationstechnische 

Berufe geweckt wird. 

Robotersysteme sind durch ihren grundsätzlichen Aufbau als „Embedded System“ 

neben ihrer Programmierung auch an ihre Mechanik gebunden. Dies gibt 

den Lehrkräften die Möglichkeit, die Fächer Mathematik, Informatik und Physik 

sinnvoll zu verknüpfen. Roboterprojekte können im Fächerverbund übergreifend 

entwickelt werden (z.B. Bau eines Roboters, der ein Dreieck abfährt und dabei 

die Winkel ausgibt). Dadurch kann es zu einer effektiveren Verbindung von 

Fachwissen kommen oder die Schüler erkennen die praktische Relevanz von 

zuvor „trockenem“ Fachwissen. 

Robotersysteme, die der Algorithmenmodellierung dienen, leisten auf den ersten 

Blick dasselbe wie eine herkömmliche Computersimulation (s. Roboter Karol). 

Ihr primärer Vorteil ist jedoch, dass sie die Abläufe „begreifbarer“ darstellen 

können. Schüler sehen wie sich ihr Roboter verhält und müssen nicht das Verhalten 

eines Programms akzeptieren. Robotersimulationen haben im Gegensatz 

dazu, andere Vorteile: sie sind billiger, leichter und schneller zu installieren 

und im Internet für jeden zugänglich. Nach Meinung des Verfassers sollte Informatikunterricht 

versuchen, beide Medien sinnvoll ergänzend einzusetzen. Es 

ist nach dessen Ansicht nicht ratsam jede Simulation durch ein Robotermodell 

zu ersetzen, da damit oft mit „Kanonenkugeln auf Spatzen geschossen“ würde. 

Durch die gemeinsame Gruppenarbeit an Roboterprojekten können die Schüler 

im Informatikunterricht leicht überfachliche Kompetenzen erwerben. Teamarbeit 

und Kooperation, Aufgabenteilung und –organisation, Selbstverantwortung und 

Präsentation der Ergebnisse sind nur einige Schlagworte hierzu. Diese Fähigkeiten 

können die Schüler leicht während der Projekt- bzw. Gruppenarbeit mit 

einem Robotersystem erlernen. Werden Roboter im Informatikunterricht eingesetzt, 

ist die Gruppenarbeit auch meist die einzig praktikable Unterrichtsform (s. 

Materialaufwand und breites Anforderungsprofil für Roboteraufgaben). 

4.1.2 Grenzen der Robotersysteme im Unterricht 

Möchte eine Lehrkraft Robotersysteme in ihrem Unterricht verwenden, so muss 

sie nach Meinung des Autors folgende Grenzen der Robotersysteme beachten. 

Ein solches Robotersystem ist als Zusammenspiel von Mechanik, Programmierung 

und grundsätzlichem Aufbau nur so stark wie sein schwächstes Glied. Eine 

perfekte Mechanik (z.B. mittels einer ordentlich überdachten Aufbauanleitung 

verwirklicht) kann nur funktionieren, wenn deren Programmierung auch 

von den beteiligten Schülern bewältigt wird. Umgekehrt kann eine gute softwaretechnische 

Umsetzung an einem einfachen mechanischen Problem scheitern. 

Solche Schwächen können den Unterrichtsverlauf drastisch beeinflussen 

und die Zeitplanung verwerfen. Lehrkräfte können dem nur entgegenwirken, 

wenn sie sich im Vorfeld wirklich ausgiebig mit den Robotersystemen beschäftigt 

haben.

- 68 - KAPITEL 4: ZUSAMMENFASSUNG MIT SCHLUSSFOLGERUNG 

Als weiteres Problem beim Einsatz von Robotersystem im Unterricht sieht der 

Verfasser dieser Arbeit die altersbedingte Reife der beteiligten Schüler bzw. 

deren Erziehungsstand. Der praktische Einsatz solcher empfindlichen Systeme 

mit ihren unzähligen Bauteilen setzt einen verantwortungsvollen Umgang mit 

den Materialien voraus. Schüler, die den klassischen Frontalunterricht gewöhnt 

sind, werden sich schwer tun in Teamarbeit gemeinsam Lösungen zu erarbeiten 

und das Material in entsprechender Weise zu behandeln. Lehrkräfte sollten 

nach Meinung des Autors ihre Schüler langsam an eine solche Unterrichtsform 

heranführen und ihnen auch die Materialkosten nicht vorenthalten. 

Aufgrund der Faszination, die die Robotersysteme auf Schüler ausüben können, 

kann ein weiteres Problem auftreten: das Abschweifen auf technische Einzelheiten 

ohne fachliche Relevanz. Gerade weil die Systeme auf manche Schüler 

hoch motivierend wirken, besteht die Gefahr, dass das Fachliche beim Unterrichtseinsatz 

in den Hintergrund rückt. Dieser Gefahr könnte eine Lehrkraft 

durch gezielten Wechsel von fachlichen und praktischen Phasen entgegenwirken. 

4.2 Persönliche Erfahrungen u. Schlussfolgerungen des Autors 

Bei der praktischen Entwicklung der robotergesteuerten Lagerverwaltung konnte 

der Autor dieser Arbeit fast alle in der Literaturrecherche beschriebenen 

Probleme am eigenen Leib erfahren. Die Schwierigkeiten beim Aufbau eigener 

Robotermodelle lagen hier meist im Detail und waren sehr zeitintensiv (Bsp. 

Robotereinheit Stapler: insgesamt acht Varianten gebaut, erst beim letzten 

konnten Funktionsmängel minimiert werden). Selbst die augenscheinlich einfache 

Übertragung eines Realmodells (s. Stapler oder Fahrer mit LKW Laderampe) 

auf einen Roboter erwies sich als sehr schwer. Der Autor musste feststellen, 

dass die LEGO-Technik Bausteine nur nach einiger Übung zu sinnvollen 

Baugruppen zusammengefügt werden konnten. 

Der Autor würde mit diesen Erfahrungshintergrund und seinen Erkenntnissen 

aus der Literaturrecherche Schüler nur Roboter nach einer Anleitung aufbauen 

lassen. Bei der intuitiven Entwicklung von Robotermodellen kam er zu oft an 

einen Punkt, wo Kleinigkeiten geändert werden mussten (z.B. das Ersetzen eines 

kleinen Zahnrades durch ein größeres zur besseren Kraftübertragung). Bei 

solchen Änderungen musste meistens das Gesamtmodell zerlegt werden. Außerdem 

riefen anfangs kleinere Änderungen meist Kaskaden von zusätzlichen 

Anpassungen des Gesamtmodells hervor. Dies würde Schüler nur unnötig frustrieren 

und dient nicht der Vermittlung von wesentlichen Inhalten. 

Trotz dieser Erfahrungen würde der Autor sich gerne weiter mit den Möglichkeiten 

der Robotersysteme beschäftigen und weitere Unterrichtskonzepte für Robotersysteme 

entwickeln. Die von den Robotern ausgehende Motivation und 

Faszination hilft auch einem Erwachsenen solche Rückschläge wegzustecken. 

Abschließend betrachtet, empfindet der Autor Robotersysteme als interessantes 

und (noch) neuartiges Medium für den Informatikunterricht. Mit diesem Medium 

kann man seiner Meinung nach die Motivation (intrinsisch und extrinsisch) 

sowie die Lernbereitschaft der Schüler steigern. Wichtig ist jedoch (wie bei allen 

Medien), dass sich der Lehrende vorher ausgiebig mit der Sache auseinandergesetzt 

hat, sie nur dosiert und geplant einsetzt und den Schülern begleitend 

zur Seite steht. Unter diesen Vorraussetzungen könnten heutige Robotersysteme 

den Unterricht bereichern und bei entsprechender Einbettung in den Bil-

KAPITEL 4: ZUSAMMENFASSUNG MIT SCHLUSSFOLGERUNG - 69 - 

dungsplan den Schülern auch fachliche Grundprinzipien auf anschauliche und 

begreifbare Weise vermitteln. 

Damit die vorgestellte robotergesteuerte Lagerverwaltung diesen Anspruch erfüllen 

kann, sollten Lehrkräfte noch die Aufbauanleitungen schülergerecht gestalten 

und die vorgestellten Robotereinheiten hinsichtlich ihrer Stabilität für den 

„rauen“ Schulalltag verbessern. Der Autor ist der Meinung, dass in [28] und [29] 

hierzu sehr hilfreiche Tipps und Tricks für den praktischen Aufbau von LEGO 

MINDSTORMS NXT Roboter zu finden sind. Diese beiden Bücher halfen ihm 

sehr bei der Entwicklung der Robotereinheiten der LV. Weitere Ideen der Verbesserung 

können Lehrkräfte in [27] finden. Dieses Buch ist zwar ursprünglich 

für das RCX System geschrieben worden, dennoch sind die darin enthaltenen 

Konstruktionsprinzipien auf NXT Roboter übertragbar. Als Weiterentwicklung 

könnte sich der Autor einen Umbau des Fahrgestells der LV-Roboter vorstellen. 

In [27] sind dazu verschiedene Möglichkeiten beschrieben. Gekoppelte Antriebe 

(bei denen ein Motor durch geschickte Zahnrad-Übersetzungen zwei Bewegungsabläufe 

zeitgleich ausführt) oder Schneckengetriebe sind nur zwei Beispiele 

möglicher Verbesserungen. Ähnliche Informationen allgemeiner Art sind 

in [26] zu finden.

- 70 - ANHANG A: INFORMATIONEN ZUR BEILIEGENDEN DVD 

Anhang A: Informationen zur beiliegenden DVD 

Dieser Arbeit liegt eine DVD bei, auf der folgende Daten hinterlegt sind: 

- Installationsroutinen der Dateien 

- Videodateien zur Lagerverwaltung 

- Aufbauanleitungen zu den verwendeten Robotern der Lagerverwaltung 

- Programme der NXT Robotereinheiten 

- Software zur Streckenerstellung für Lichtsensorgesteuerte Linienverfolger 

- Die verwendete Strecke in unterschiedlichen Dateiformaten 

- Eine Dateiversion der vorliegenden Arbeit 

- Unterrichtsmedien zur Arbeit und aus dem Internet 

- Eine Kurzpräsentation des Lagerverwaltungsprojekts 

- Eine Übersicht von Weblinks zu unterschiedlichen Robotersystemen 

Nach dem Einlegen der DVD sollte das Hauptprogramm (Abbildung 40) automatisch 

starten, das in seiner Oberfläche einem NXT Baustein ähnelt und dessen 

Menu über die NXT Tasten bedient wird. In jeder Unterkategorie des Verzeichnisbaums 

ist eine eigene Setuproutine (Abbildung 41) hinterlegt, mit der 

die Daten auf einem Rechner lokal installiert werden können. Beim Aufruf der 

Daten aus dem Programm heraus wird Standardsoftware angesteuert (z.B. Videowiedergabe 

mit Windows Mediaplayer). Sollte dieser Aufruf Fehlermeldungen 

erzeugen, müssen die Dateien über die Setupfunktion aufgerufen werden. 

Nach erfolgreichem Setup sind Verknüpfungen im lokalen Startmenu angelegt. 

Abbildung 40: Hauptprogramm 

Abbildung 41: Setuproutine 

Die implementierte Software unterliegt folgenden Beschränkungen: 

- Die Software ist nur für Windows XP entwickelt und läuft nicht unter Windows 

Vista oder anderen Betriebssystemen. 

- Die deutsche MINDSTORMS Education Software Ver.1.1 ist Vorrausetzung. 

- Software zur Bildbetrachtung, PDF Reader und zur Wiedergabe von Präsentationen 

sollte vorinstalliert sein.


Anhang B: Bezugsquellen u. Internetadressen 

1. Materialien zum Projekt „Roberta“ 

Nr. Titel Beschreibung Zusatzinfos 

1 

2 

3 

4 

5 

Grundlagen 

und 

Experimente 

Der 

Simulator 

RobertaSim 

Programmieren 

mit Java 

und C 

Themen 

und 

Experimente 

Anleitung zur 

Schulung von 

Kursleitern 

- Grundlagen Planung/Durchführung von Kursen 

- didaktische Hinweise auf gendergerechte Gestaltung 

- Einführung in die Robotik (Thema „Ameisen“) 

- Vorstellung von Bauteilen/Technik (MINDSTORMS) 

- Bauanleitungen und Literaturhinweise 

- Experimente, Tipps und Tricks zur Problemvermeidung 

bei „Roberta“ Kursen 

- Simulatorsoftware für LEGO MINDSTORMS Roboter 

(Robotics Invention System 2.0 Serie) 

- Programmierung virtueller Robotern mit RIS u. NQC 

- Echtzeitdarstellung des Roboterverhaltens 

- Bedienung eines virtuellen Roboters möglich 

- vollgraphische Animation (Abbildung 13) 

- Ergänzung der Programmiermöglichkeiten Java u. C 

- Installationsanleitungen f. Programmierumgebungen 

- Erläuterung von Umgang mit der 

Programmierumgebung 

Seitenzahl: 

376 Seiten 

ISBN: 

3-8167-7034-7 

Preis: 

64,20 € 

Seitenzahl: 

48 Seiten 

ISBN: 

3-8167-7035-5 

Preis: 

26,75 € 

Seitenzahl: 

88 Seiten 

ISBN: 

3-8167-7036-3 

- Besonderheiten der Umgebungen und Sprachen Preis: 

16,05 € 

- ergänzende Themen 

(„Bienen“, „Gangarten“ und „Labyrinth“) 

- Grundlage für Planung längerer „Roberta“ Kurse 

- hilft bei der Auswahl und Vorbereitung von Themen 

- speziell für „Roberta“ Schulungsleiter 

- Unterstützung für Schulungsvorbereitung 

- Ziele und Inhalte einer „Roberta“ Schulung 

- Grundsätze des Roberta Projekts 

- Beschreibung der Zertifizierungsprozesse von 

„Roberta“ Regio-Zentren/„Roberta“ Schulungsleitung 

Seitenzahl: 

140 Seiten 

ISBN: 

3-8167-7037-1 

Preis: 

26,75 € 

Seitenzahl: 

44 Seiten 

ISBN: 

3-8167-7038-X 

Preis: 

26,75 € 

6 

7 

„Roberta“ im 

Rettungsdienst 

You can 

Dance! 

- setzt Kenntnis von Band 1 voraus 

- von den anderen Bänden unabhängig 

- enthält Tipps, Hinweise und Anregungen für die 

Konstruktion und die Programmierung von Robotern, 

für den RoboRescue-Wettbewerb 55 

- Aufbaubeschreibung einer Rescue Arena 

- Regeln und Internet-Adressen zum Wettbewerb 

- setzt Kenntnis von Band 1 voraus 

- von den anderen Bänden unabhängig 

- Vorbereitung für RoboDance Wettbewerbe 56 

- Aufgaben, Beispiele und Erfahrungsberichte von 

„Roberta“ Dance Teams 

Seitenzahl: 

60 Seiten 

ISBN: 

3-8167-7207-2 

Preis: 

9,00 € 

Seitenzahl: 

54 Seiten 

ISBN: 

3-8167-7312-5 

Preis: 

11,99 € 

55 http://www.smart-girls.info/Smart-Girls/RoboCupJunior/RoboRescue (zuletzt aufgerufen am 

30.09.08) 

56 http://www.smart-girls.info/Smart-Girls/RoboCupJunior/RoboDance (zuletzt aufgerufen am 

30.09.08)

- 72 - ANHANG B: BEZUGSQUELLEN U. INTERNETADRESSEN 

2. Robotersystem „Asuro“ 

URL Bezugsquelle Asuro: 

http://www.science-shop.de/roboter?gclid=CKr08pHP7ZUCFRdatAod8S81Xg 

3. Robotersystem „Boe Bot“ 

URL Bezugsquelle Boe Bot: 

http://www.zerko.ch/parallaxshop/robots/50150395e3100821a.php 

URL interessante Downloads zum Boe Bot: 

http://www.pcwelt.de/downloads/fun_more/77524/boe_bot_von_parallax/ 

URL Roboter Boe Bot in Elektor: 

http://elmicro.com/de/robokurs.html 

URL zur Programmiersprache Basic Stamp: 

http://www.emesystems.com/BS2index.htm#math 

4. Robotersystem „Ma-Vin“ 

URL Bezugsquelle Ma-Vin: 

http://www.generalrobots.de/product_info.php/info/p313_MA-VIN-Robot-kit.html 

5. Robotersystem „LEGO MINDSTORMS RCX” 

URL Bezugsquelle für Schulen: 

http://www.technik-lpe.info/shop.html 

6. Robotersystem „LEGO MINDSTORMS NXT” 

URL Bezugsquelle für Schulen: 

http://www.technik-lpe.info/shop.html 

7. Robotersystem „Robobox” 

URL Bezugsquelle Robobox: 

http://robosavvy.com/store/product_info.php/cPath/21/products_id/353?osCsid= 

056c7ae41e49572ebb0e7702d524d16d 

8. Robotersystem „Scribbler“ 

URL Bezugsquelle Scribbler: 

http://www.elexp.com/tst_8136.htm 

9. URLs verschiedener Robotershops 

http://robosavvy.com/ 

http://www.active-robots.com/


http://www.nodna.com/xtc/index.php 

http://www.hs-robots.com/ 

http://www.robot-electronics.co.uk/ 

http://www.robotstore.de/seiten/shop/index.php?tpl=double 

http://www.shop.robotikhardware.de/shop/catalog/index.php 

http://www.robotshop.ca/home/index.html 

http://www.totalrobots.com/ 

http://www.solarbotics.com/robot_kits/ 

10. URLs zur grafischen Entwicklungsumgebungen 

Entwicklungsumgebungen für Roboter: 

http://www.ulrich-mueller.de/schuler.htm 

Entwicklungsumgebung KIMM: 

http://www.kimm.uni-luebeck.de/oem/methoden-werkzeuge/mmikonische/content-2.html 

Entwicklungsumgebung LOGO: 

http://www.medien.ifi.lmu.de/fileadmin/mimuc/mmi_ws0405/uebung/essays/Frie 

derike.Otto/Logo.html 

Entwicklungsumgebung Microsoft Robotics Studio (systemübergreifend): 

http://www.roboticsconnection.com/t-microsoftroboticsstudio.aspx 

Entwicklungsumgebung Puck: 

http://ddi.cs.uni-potsdam.de/InformaticaDidactica/Kohl2006 

Tangible Sprachen: 

http://www.eecs.tufts.edu/~mhorn01/index.html 

11. interessante URLs zum Thema Robotik und Schule 

private Seite zum Thema Robotik (verschiedene Projekte): 

http://elmicro.com/de/robotik.html 

Roboter School Wiki: 

http://schoolcomputing.wikia.com/wiki/Robotics#Robotics_Software 

Robotics-in-education Web log: 

http://educationguru.wordpress.com/robotics-in-education/ 

Mega Giant Robotics: 

http://robotics.megagiant.com/teachers.html 

Diese Weblink-Sammlung ist im Laufe der Literaturrecherche entstanden und 

mit Links der Literaturquellen [26],[27],[28] und [29] ergänzt worden. Die aufgeführten 

Webseiten wurden zuletzt aufgerufen am 30.09.08.

- 74 - ANHANG C: UNTERRICHTSMATERIALIEN 

Anhang C: Unterrichtsmaterialien 

Arbeitsblatt 1: Programmleitfaden zur LEGO 

MINDSTORMS Edu NXT Software 

Verfügbare Funktionspaletten: 

Palette 

„Normal“ 

Palette 

„Vollständig“ 

Palette 

„Benutzerdefiniert“ 

Block Konfiguration:


relevante Programmicons: 

Bewegung 

Aufnehmen/ Wiedergabe 

Warte auf „Druck“ Warte auf „Licht“ Warte „Zeiteinheit“ Stopp 

Sende BT Nachricht 

Klang Anzeige Motor 

Reset Motor Text Kalibrierung Dateizugriff 

Empfange BT 

Nachricht 

NXT Tasten Tastsensor Lichtsensor 

Schleifen: Schalter: NXT Bedienfeld:


Arbeitsblatt 2: Anleitung zur Programmentwicklung 

Bevor du mit dem Programmieren beginnen kannst: 

Starte die Programmoberfläche der LEGO MINDSTORMS Education Software, 

in dem du auf folgendes Symbol auf deinem Desktop klickst: 

Öffne ein neues Programm, in dem du auf folgendes Symbol klickst: 

Nach Erledigung der Aufgaben: 

Speichere dein erstelltes Programm durch Drücken auf das Diskettensymbol 

unter deinem Vornamen ab: 

Verbinde jetzt den NXT Baustein und deinen Rechner mit dem bereitliegenden 

USB Kabel.


Öffne das NXT Auswahl Fenster: 

Verbinde deinen angeschlossenen NXT Baustein mit der Software, in dem du 

ihn aus der Liste auswählst und auf verbinden klickst: 

Lade das Programm durch Druck auf die PLAY Taste in den NXT Baustein: 

Das Programm startet automatisch oder beginnt mit dem Druck auf die rote 

NXT Taste!


Arbeitsblatt 3: Einrichtung eines Bluetooth Netzwerkes 

zwischen mehreren NXT Bausteinen 

Die Roboter fungieren als unabhängige Objekte, die sich in einem Bluetooth- 

Netzwerk zusammenschließen und danach untereinander Nachrichten austauschen 

können. 

Ein Bluetooth Netzwerk mit vier NXT Bausteinen ist so aufgebaut: 

Merke: 

Slave Einheiten können sich nicht direkt 

Bluetooth Kommandos zusenden! 

In solchen Fällen muss 

die Nachricht erst an den Master ü- 

bermittelt werden. Er kann sie im Anschluss 

neu senden und an den Empfänger 

weiterleiten 

Damit du ein Netzwerk aufbauen kannst, musst du zuerst sicherstellen, dass 

alle beteiligten Bausteine ihre Bluetooth-Funktion eingeschaltet haben. 

Du musst folgendes bei allen vier Bausteinen einstellen: 

(01) Schalte den NXT Baustein ein! 

(02) Wechsle in das Menu „Bluetooth“! 

(03) Hier kannst du die Bluetooth-Funktion 

aktivieren (On/Off). 

Wähle einen Masterbaustein aus und lass ihn nach Bluetooth Geräten suchen: 

(04) Lege einen Master NXT Baustein fest! 

(05) Aktiviere in seinem Menu „Bluetooth“ die Funktion ! 

(06) Warte ein bisschen bis der Master NXT die restlichen Bausteine findet! 

Schließlich musst du den gefundenen NXT Geräten eine Adresse geben: 

(07) Folgendes musst du NUR beim Master NXT einstellen! 

(08) Rufe im Menu „Bluetooth“ die Funktion auf! 

(09) Jetzt werden alle gefundenen SLAVE Geräte angezeigt. 

(10) Wähle die Geräte nun nacheinander aus: 

bestätige deine Auswahl mit der roten Taste 

und gib Ihnen eine feste Adresse (Ch1 - Ch4) 

nach jeder Zuweisung sollte dieses Bild erscheinen! 

Der Kanal (Ch) ist jetzt die Adresse des SLAVE-NXT. Wenn du ihm eine Nachricht 

per Bluetooth übermitteln willst. musst du diese Nummer als Verbindungsadresse 

angeben!


Arbeitsblatt 4: Geschichte zur Lagerverwaltung 

Ziele: 

1. Textverständnis 

2. Transfer der Geschichte 

3. Identifikation der beteiligten Elemente 

4. Zuordnung der Aktion 

Herr Müller aus Nürnberg macht sich an einem sonnigen Montagmorgen auf 

den Weg in die Stadt, um seinem Enkel Timo eine ganz besondere Freude zu 

machen. Er hat nämlich in 2 Tagen Geburtstag, und wird 10 Jahre alt. Nach 

langem Suchen findet Opa Müller endlich das passende Geschenk, einen 

Spielzeugroboter. Da sein Enkel Timo in Düsseldorf lebt, und der schon etwas 

gebrechliche Herr Müller sich nicht mehr auf die lange Reise machen kann, 

möchte er ihm das Geschenk per Express zuschicken. Am besten noch heute, 

denn die Zeit drängt. 

Herr Müller bringt das Geschenk zum nächstgelegenen Postamt in Mögeldorf. 

Die nette Postbeamtin Sylvia Weiß hilft ihm, das Geschenk einzupacken, und 

kümmert sich um eine schnellstmögliche Abholung des Paketes. Sie ruft im Lagerbüro 

Nürnberg der Post an, und gibt den Express- Auftrag an den LKW Fahrer 

Bruno Schmidt weiter. Dieser ist gerade auf seiner Tour durch Nürnberg, 

und kann das Paket in einer Stunde abholen. Herr Müller ist überglücklich, dass 

das Geschenk für seinen Enkel heute noch abgeholt wird, und somit noch 

rechtzeitig zu Timos Geburtstag. Strahlend verlässt er die Post und macht sich 

auf den Heimweg. 

Genau eine Stunde später kommt Bruno am Postamt Mögeldorf an und ruft 

Sylvia im Büro an, dass er da ist und sie im das Paket bringen kann. Postbeamtin 

Sylvia nimmt das Express-Paket von Herrn Müller, läuft zur Laderampe und 

begrüßt Bruno. Der hat heute erst seinen zweiten Arbeitstag, und ist deshalb 

noch etwas unerfahren mit dem LKW. Die hilfsbereite Sylvia weist Bruno deshalb 

an die Laderampe der Post ein. Sylvia übergibt Bruno das Paket, verabschiedet 

sich und wünscht ihm eine gute Fahrt. Bruno gönnt sich eine kurze 

Pause und macht sich eine Dose Cola auf. Gerade als er losfahren wollte, klingelt 

es bei ihm am Handy und Sylvia ist dran. Herr Müller hat sich bei der 

Hausnummer seines Enkels verschrieben. Sie gibt ihm die richtige Nummer 

durch, Bruno notiert sich diese und startet seinen LKW. 

Nach einer längeren Fahrt ist Bruno endlich beim Hauptpostamt in Düsseldorf 

angekommen. Dort übergibt er das Expresspaket mit der Adresse und der richtigen 

Hausnummer an den Postboten Meier. Der erfahrene Postbote schwingt 

sich auf sein Rad und übergibt wenig später das Paket dem glücklichen Geburtstagskind. 

Aufgabenstellung: 

Lies dir die Geschichte in Ruhe einmal durch und starte im Anschluss die Video-Datei 

"Lagerverwaltung.avi" an deinem Rechnerarbeitsplatz. Nachdem du 

dir diese Datei einmal angesehen hast, kannst du mit deinem Banknachbarn 

versuchen, die Abläufe im Video mit der Geschichte zu verbinden. Danach 

sollst du ein Sequenzdiagramm (mit den Namen und Elementen der Geschichte) 

entwickeln, das den Ablauf im Video möglichst genau wiedergibt!

- 80 - ABBILDUNGSVERZEICHNIS 

Abbildungsverzeichnis 

Abbildung 1: LEGO Robotics Invention Software...........................................- 4 - 

Abbildung 2: LEGO NXT Education Software................................................- 5 - 

Abbildung 3: Quetzal Bausteine.....................................................................- 6 - 

Abbildung 4: TERN Puzzleteile......................................................................- 6 - 

Abbildung 5: Arbeitsoberfläche von SCRATCH.............................................- 7 - 

Abbildung 6: Sony AIBO................................................................................- 9 - 

Abbildung 7: Ablaufschema einer Sortierung...............................................- 15 - 

Abbildung 8: Kommunikation zwischen Kontrolleinheit und Robotern.........- 16 - 

Abbildung 9: Gokart und Roboter.................................................................- 17 - 

Abbildung 10: Verwendetes Labyrinth beim Labyrinthlöse-Algorithmus ......- 19 - 

Abbildung 11: Sortiermaschine der Maturaarbeit.........................................- 21 - 

Abbildung 12: Roboter mit RFID Schreib/Leseeinheit und Kettenantrieb.....- 22 - 

Abbildung 13: Logo des „Roberta“ Projekts.................................................- 25 - 

Abbildung 14: Materialien zu „Roberta“........................................................- 26 - 

Abbildung 15: RobertaSim Simulatorsoftware..............................................- 26 - 

Abbildung 16: MINDSTROMS Hochregallager und Simulatorumgebung ....- 27 - 

Abbildung 17: Automatische Kommissionierstation.....................................- 28 - 

Abbildung 18: Aufbau des Roboters mit Kamera und Infrarotmodul............- 32 - 

Abbildung 19: KHERPERA Roboter.............................................................- 33 - 

Abbildung 20: Beispielroboter......................................................................- 36 - 

Abbildung 21: Arena „EGG Hunt Wettbewerbs“...........................................- 36 - 

Abbildung 22: Aufbau der Kurve..................................................................- 37 - 

Abbildung 23: Visualisierte Daten................................................................- 37 - 

Abbildung 24: Koordinatensystem der Wiimote...........................................- 37 - 

Abbildung 25: Zustandsautomat der Wiimote..............................................- 37 - 

Abbildung 26: Bluetooth Proxy.....................................................................- 37 - 

Abbildung 27: Transportbox.........................................................................- 51 - 

Abbildung 28: Streckenführung....................................................................- 51 - 

Abbildung 29: Roboter "Annahme“...............................................................- 52 -

TABELLENVERZEICHNIS - 81 - 

Abbildung 30: Roboter „Lagerist“..................................................................- 52 - 

Abbildung 31: Roboter "Fahrer"....................................................................- 53 - 

Abbildung 32: Roboter "Stapler“...................................................................- 53 - 

Abbildung 33: Beispiele für Textausgaben auf NXT LCD.............................- 54 - 

Abbildung 34: Programmmodule..................................................................- 54 - 

Abbildung 35: Beispiel für Codekommentierung...........................................- 54 - 

Abbildung 36: „Robot Educator“ der Entwicklungsumgebung......................- 65 - 

Abbildung 37: Aufgabenbeschreibung mit Videodateien im „Educator“........- 65 - 

Abbildung 38: Programmieranleitungen des „Educators“.............................- 65 - 

Abbildung 39: Schritt für Schritt Bauanleitungen des „Educators“................- 65 - 

Abbildung 40: Hauptprogramm.....................................................................- 70 - 

Abbildung 41: Setuproutine..........................................................................- 70 - 

Tabellenverzeichnis 

Tabelle 1: Robotersysteme für die Bildung.....................................................- 3 - 

Tabelle 2: Teilschritte zur Unterrichtssequenz mit SCRATCH........................- 8 - 

Tabelle 3: Phasen der Unterrichtseinheit Basketball....................................- 13 - 

Tabelle 4: Teile der Unterrichtssequenz.......................................................- 19 - 

Tabelle 5: Struktur der Lernsequenz............................................................- 28 - 

Tabelle 6: Exemplarische Fragen und Antworten der Evaluation.................- 33 - 

Tabelle 7: Phasen der Roboterentwicklung..................................................- 35 - 

Tabelle 8: Übersicht Roboterbezüge ausgewählter Lehrpläne.....................- 44 - 

Tabelle 9: Übersicht robotergeeignete Themen in den Bildungsstandards der 

Informatik......................................................................................................- 45 - 

Tabelle 10: Informatische Konzepte u. Modulbezug zur Lagerverwaltung...- 50 - 

Tabelle 11: Grobe Stundenplanung des Projekts "BT Kommunikation.........- 59 - 

Tabelle 12: Übersicht der Grobziele des Projekts.........................................- 61 - 

Tabelle 13: Übersicht der Feinziele der Unterrichtseinheit...........................- 62 - 

Tabelle 14:Taxonomietabelle nach Anderson u. Krathwohl..........................- 62 - 

Tabelle 15: Stundenplanung der Einheit „Arbeiten mit dem Robotersystem“- 64 -

- 82 - LITERATURVERZEICHNIS 

Literaturverzeichnis 

[01] Challinger, Judith: Efficient Use of Robots in the Undergraduate Curriculum. 

In: Technical Symposium on Computer Science Education Proceedings 

of the 36th SIGCSE technical symposium, ACM, St Louis, 2005, pp. 436- 

440 

[02] Decuir, John D.; Kozuki, Todd; Matsuda, Victor; Piazza, John: A Friendly 

Face in Robotics: Sony’s AIBO Entertainment Robot as an Educational Tool. 

In: ACM Computers in Entertainment, Volume 2, Issue 2, ACM, New York, 

April 2004, Artikel 04 

[03] Dessarzin, Pascal: Die Sortiermaschine. Deutsches Gymnasium Biel, Matura 

Arbeit, Biel, 2008, URL: http://www.dgb.ch/unterricht/maturaarbeiten/ 

DessarzinPascal/Maturaarbeit.pdf (zuletzt aufgerufen am 30.09.08) 

[04] Dietzel, Ruth; Rinkens, Tim: Eine Einführung in d. Objektorientierung mit 

MINDSTORMS Robotern Erfahrungsbericht aus dem Unterricht. In: Informatikunterricht 

und Medienbildung, INFOS 2001, Informatik und Schule, Gesellschaft 

für Informatik, Paderborn, September 2001, S. 193-199 

[05] Fagin, Barry S.; Merkle Laurence: Quantitative Analysis of the Effects of 

Robots on Introductory Computer Science Education. In: ACM Journal on 

Educational Resources in Computing, Volume 2, Issue 4, ACM, New York, 

Dezember 2002, Artikel 02 

[06] Goldman, Rachel; Eguchi, Amy; Sklar, Elizabeth: Using educational Robots 

to engage inner City Students with technology. In: International Conference 

on Learning Sciences, Proceedings of the 6th internat. Conference on 

Learning sciences, International Society of the Learning Sciences, Santa 

Monica, 2004, pp. 214-221 

[07] Goldman Rachel; Eguchi, Amy; Skar, Elizabeth: Using Autonomous Robotics 

to teach Science and Engineering. In: International Conference on 

Learning Sciences, Proceedings of the 6th international conference on 

Learning sciences, ACM, Santa Monica, 2004, pp. 214-221 

[08] Goldweber, Michael; Congdon, Clare; Fagin Barry; Hwang, Deborah; 

Klassner, Frank: The Use of Robots in the Undergraduate Curriculum: Experience 

Reports. In: Technical Symposium on Computer Science Education, 

Proceedings of thirty-second SIGCSE technical symposium on CS-Ed. 

ACM, Charlotte, 2001, pp. 404-405 

[09] Horn, Michael S.; Jacob, Robert J.K.: Designing Tangible Programming 

Languages for classroom Use. In: Tangible and embedded interaction Proceedings 

of the 1st international conference on Tangible and embedded interaction, 

ACM, Baton Rouge, Februar 2007, pp. 159-162 

[10] Horn, Michael S.; Jacob, Robert J. K.: Tangible Programming in the classroom 

with TERN. In: Conference on Human Factors in Computing Systems, 

CHI '07 extended abstracts on Human factors in computing systems, ACM, 

San Jose, April 2007, pp. 1965-1970 

[11] Isakandar, Hendry; Seith, Alexander; Tran, Trung und Nicolin, Stefan: LE- 

GO MINDSTORMS NXT WiiMote – Anwendungen der Prozessdatenverarbeitung. 

URL: http://www.informatik.fh-wiesbaden.de/~linn/vpdv07/nxt/ 

download/Dokumentation.pdf (zuletzt aufgerufen am 30.09.08)

LITERATURVERZEICHNIS - 83 - 

[12] Lopez, Javier; Myller, Niko; Sutinen, Erkki: Sorting out Sorting through 

Concretization with Robotics. In: Proceedings of the working conference on 

advanced visual interfaces, ACM, Gallipoli, 2004, pp. 377-380 

[13] Magenheim, Johannes: Informatik Lernlabor - Systemorientierte Didaktik in 

der Praxis. In: Informatische Fachkonzepte im Unterricht, INFOS 2003, 10. 

GI-Fachtagung Informatik und Schule, Lecture Notes in Informatics (LNI) 32 

GI 2003, Gesellschaft für Informatik, Garching, September 2003, S. 13-31 

[14] Magenheim, Johannes; Scheel, Olaf: Zugänge zur Softwaretechnik. In: 

LOG IN 1/2005, Log In Verlag, Berlin, Heft 134, S. 39-44 

[15] Magenheim, Johannes; Reinsch, Thorsten; Hirsch, Michael: Zugänge zur 

Informatik mit MINDSTORMS – mit LEGO Robotern in der Sek. I spielerisch 

ein Informatiksystem entdecken und gestalten. In: LOG IN 20/2000, Log In 

Verlag, Berlin, Heft 02, S. 01 – 16 

[16] Müllerburg, Monika; Börding, Josef; Theidig, Gabriele; Petersen, Ulrike: 

Informatikausbildung, Roboter und Mädchen. In: Informatik 2005 – Informatik 

LIVE! GI-2005: Workshop "Roboter in der Informatikausbildung", Gesellschaft 

für Informatik, Bonn, 2005, pp. 143-147 

[17] Müllerburg, Monika; Börding, Josef; Theidig, Gabriele; Petersen, Ulrike: 

Mit Robotern spielend lernen: Das Projekt Roberta. In: VDI-Tagungsbericht 

1841, Robotik 2004. Leistungsstand, Anwendungen, Visionen, Trends, 

Fraunhofer Institut für intelligente Analyse- und Informationssysteme, Düsseldorf, 

Juni 2004, S. 393-400 

[18] Petersen, Ulrike; Theidig, Gabriele; Börding, Josef; Leimbach, Thorsten; 

Flintrop, Björn: Roberta Abschlussbericht. URL: http:/www.iais.fraunhofer.de 

/fileadmin/images/pics/Abteilungen/AR/PDF/Abschlussbericht_Roberta_200 

7-11-21.pdf (zuletzt aufgerufen am 30.09.08), Fraunhofer Institut für intelligente 

Analyse- und Informationssysteme, Sankt Augustin, November 2007 

[19] Romeike, Ralf: Animationen und Spiele gestalten. In: LOG IN 4/2007, Log 

In Verlag, Berlin, Heft 146, S. 36 – 44 

[20] Schütz, Ute; Becker Sven: Fraunhofer IAIS: Roberta – Lernen mit Robotern. 

URL: http://www.iais.fraunhofer.de/roberta.html (zuletzt aufgerufen am 

30.09.08) 

[21] Stevenson, Daniel E.; Schwarzmeier, James D.: Building an Autonomous 

Vehicle by Integrating LEGO MINDSTORMS and a Web Cam. In: Technical 

Symposium on Computer Science Education, Proceedings of the 38th SIG- 

CSE technical symposium, Session: MINDSTORMS: robotics and beyond, 

ACM, Covington, 2007, pp. 165-169 

[22] Tempelhoff, Anja: Robotik in der Sekundarstufe I – Möglichkeiten und 

Probleme der Unterrichtspraxis. In: LOG IN 1/2005, Log In Verlag, Berlin, 

Heft 134, S. 23 – 29 

[23] Trabhardt, H.; Informatikprojektgruppe: Entwicklung eines selbstfahrenden 

Robotersystems zur Verwaltung von RFID gekennzeichneten Waren. Gesamtschule 

Haspe, Hagen, 2007, URL: http://www.technikpreis-vderheinruhr.de/_data/Projektbericht__Gesamtschule_Haspe.pdf 

(zuletzt aufgerufen 

am 30.09.08)

- 84 - LITERATURVERZEICHNIS 

[24] Wiesner, Bernhard: Algorithmische Grundstrukturen mit einem Robotersystem. 

URL: http://algo.robinfun.de/index.html (zuletzt aufgerufen am 

30.09.08) 

[25] Wiesner Bernhard; Brinda, Torsten: Erfahrungen bei der Vermittlung von 

Grundkonzepten der Algorithmik mit einem Robotersystem. URL: 

http://www.die.informatik.uni-siegen.de/infos2007/vortragsfolien/p5/wiesner 

_brinda_infos2007.pdf (zuletzt aufgerufen am 30.09.08) 

[26] Allgemeine Informationen zur Robotik 

Gruber, Robin; Grewe, Jan: Mehr Spaß mit Asuro Band I u. II. DLR School 

Lab, Arexx Intelligence Centre, Pfaffenhofen, Januar 2005 

[27] Informationen zu MINDSTORMS RCX u. Programmierung 

Nogat, Markus L.; Knudsen, Jonathan B.: Das inoffizielle Handbuch für LE- 

GO MINDSTORMS Roboter. O’Reillly Verlag, Köln, 2000 

[28] Basiswissen zum Roboteraufbau 

Astolfo, Dave; Ferari, Mario; Ferari, Guido: Building Robots with LEGO 

MINDSTORMS NXT – The ultimate Tool for MINDSTORMS Maniacs. Syngress 

Publishing, Inc., Burlington, 2007 

[29] Informationen zu LEGO MINDSTORMS NXT 

Boogaarts, Martijn; Daudelin Jonath A.; Davis, Brian L.; Kelly, Jim; Levy, 

David; Morris, Lou; Rhodes, Fay; Rhodes, Rick; Scholz, Matthias P.; Smith 

Christopher R.; Torok, Rob: The LEGO MINDSTORMS NXT Idea Book – 

Design, invent and build. No Starch Press, Inc., San Francisco, 2007

Zulassungsarbeit V9.0 - RobInfun

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?