DES WPU-KURSES - Wernher von Braun Schule

PROJEKTABSCHLUSSBERICHT 

DES WPU-KURSES 

„ROBOTER PLANEN, KONSTRUIEREN UND PROGRAMMIEREN“ 

an der Wernher-von-Braun-Schule (Neuhof) 

NXT-Räumroboter „Winterstar“ 

The Rotations (Teamnr. 2) 

Neuhof, den 18.05. 2010

Inhaltsverzeichnis 

1 DAS TEAM ............................................................................................................................... 2 

2 EINLEITUNG ............................................................................................................................ 3 

3 PROJEKTPLANUNG ............................................................................................................... 3 

4 PROJEKTABLAUF .................................................................................................................. 4 

5 PROJEKTERGEBNIS ............................................................................................................ 22 

5.1 Roboterwelt ....................................................................................................................... 22 

5.2 Roboterkonstruktion .......................................................................................................... 23 

5.3 Programmierung ............................................................................................................... 26 

6 REFLEXION ........................................................................................................................... 29 

6.1 Reflexion der Problemstellung .......................................................................................... 29 

6.2 Reflexion des Projektmanagements und der Teamarbeit .................................................. 29 

6.3 Reflexion des Projektziels ................................................................................................. 30 

7 ENTLASTUNG PROJEKTTEAM ........................................................................................... 32 

8 ANHÄNGE ............................................................................................................................. 33 

9 QUELLENVERZEICHNIS ...................................................................................................... 33 

Seite 1

1 DAS TEAM 

David Wehner 

Teamleiter 

Protokollant 

Programmierung 

Carsten Betz 

Programmierung 

Jan Staubach 

Konstruktion 

Jakob Brehler 

Konstruktion 

Seite 2

2 EINLEITUNG 

Da sich unsere Gruppe zuvor mit dem Rotationssensor beschäftigt hatte, stand natürlich fest, dass unser Projekt 

auf diesem Sensor basieren sollte. Bei den vorausgegangenen Versuchsreihen stellte sich heraus, dass 

der Rotationssensor besonders dafür geeignet war, den Roboter geradeaus fahren und in einem genau festgelegten 

Winkel drehen zu lassen. Wir überlegten uns also ein Projekt, bei dem der Roboter genau dies machen 

sollte. Ein Räumroboter, der in einem rechteckigen Raum operiert, schien dafür geeignet. Schließlich 

muss der Roboter beim Durchfahren des Raums genau geradeausfahren und sich genau drehen können, um 

sich orientieren zu können. 

Ein Räumroboter, der beim Durchfahren eines rechteckigen Raumes Teile aufnimmt und diese dann in eine 

Art Ablagecontainer befördert, weckte das Interesse aller Gruppenmitglieder. Aus dieser Idee wurde das Minimalziel, 

da in der Realität eine Art Aufräumroboter durchaus das Kaufinteresse einer größeren Kundengruppe 

wecken könnte. Die für das Minimalziel nötigen Kenntnisse für die Programmierung waren bereits beim 

Durchführen der Versuchsreihen und dem vorherigen Informatikunterricht erworben worden. Aus Sicht der 

Programmierer war das Minimalziel also überschaubar. 

Auch die Roboterkonstrukteure Jakob und Jan fühlten sich in der Lage, einen geeigneten Roboter zu bauen. 

Hierzu planten sie, eine völlig eine neue Konstruktion zu errichten. Die Fähigkeiten dafür hatten sie bereits 

beim Durchführen der Versuchsreihen unter Beweis gestellt, da sie hier schon den TriBot an verschiedensten 

Stellen erfolgreich modifizierten, was den Roboter zum Beispiel im Punkt Stabilität sehr verbesserte. 

Als erweiterte Herausforderung setzten wir uns das Ziel, dass der Roboter die Teile, die er beim Durchfahren 

des Raumes aufnimmt, anhand von bestimmten Eigenschaften wie zum Beispiel der Farbe zuordnen kann. 

Es wurde prognostiziert, dass die Erfüllung des Maximalziels nochmals besonders die Kompetenzen der Programmierer 

Carsten und David erfordert, da zum Beispiel dafür der Umgang mit einem weiteren Sensor (vermutlich 

dem Farbsensor) vorausgesetzt wird. 

3 PROJEKTPLANUNG 

Am Anfang des Projekts wurden zunächst ein Gruppenführer und ein Protokollant bestimmt. Für beide Tätigkeiten 

erklärte sich David gerne bereit. Dieser hatte nun die Aufgabe, die Aufgaben in der Gruppe zu verteilen, 

die Tagesberichte und schließlich den Projektabschlussbericht zu schreiben. 

Die Zuständigkeiten in der Gruppe wurden ebenfalls am Anfang des Projekts geklärt. Hierbei wurde die Gruppe 

in zwei Trupps aus je zwei Gruppenmitgliedern eingeteilt. Der erste Trupp wurde von Carsten und David 

gebildet. Beide machten es sich zur Aufgabe, die nötigen Programmcodes für den Roboter zu schreiben. 

Seite 3

Der zweite Trupp bestand aus Jakob und Jan. Diese bekamen die Aufgabe, den Roboter nach den Anforderungen 

des zu erfüllenden Ziels zu konstruieren. Natürlich wurde festgelegt, dass beide Trupps „Hand in 

Hand” zusammenarbeiten. 

Damit jeder wusste, was genau zu tun war, wurden in Gruppengesprächen, bei dem jedes Gruppenmitglied 

beteiligt war, festgelegt, welche Anforderungen an den jeweiligen Trupp gestellt werden. Hierbei wurde auch 

über neue Ideen und Konzepte diskutiert und teilweise sogar abgestimmt. 

4 PROJEKTABLAUF 

Dienstag, 19.01.10 

An diesem Tag haben wir den Sensor ausgewählt, mit dem wir uns in den 

nächsten Wochen beschäftigen werden. Es handelt, sich dabei um den 

Rotationssensor. Außerdem wurden organisatorische Dinge innerhalb der 

Gruppe geklärt. Außerdem wurden der Gruppenleiter und der Protokollant 

bestimmt. Für beide Angelegenheiten erklärte sich David bereit. 

Als Ziel für die nächsten Unterrichtsstunden setzten wir uns, Informationen 

über den Rotationssensor zu sammeln und Überlegungen über eine Versuchsreihe 

mit dem Sensor anzustellen. 

Freitag, 22.01.10 


Die Informatikstunde konnte auf Grund eines innerschulischen Volleyballturniers 

nicht stattfinden. 

Das primäre Ziel an diesem Tag bestand darin, dass sich alle Gruppenmitglieder 

über den Rotationssensor der NXT-Motoren informieren. Hierbei 

nutzten wir die betreffende Lektion des NXC-Tutorials, die uns Herr Dietrich 

zur Verfügung gestellt hatte. Jan demontierte währenddessen den vor dem 

neuen Unterrichtsprojekt gebauten Roboter, damit uns alle Teile umstandslos 

zur Verfügung standen. Außerdem wurden schon erste Überlegungen 

über einen Versuch mit dem Rotationssensor angestellt. Die Grundidee 

war, den Robotermotor mithilfe eines Stiftes verschieden große Winkel 

exakt auf ein Blatt Papier zeichnen zu lassen. Mithilfe dieses Versuchs 

sollte es möglich sein herauszubekommen, wie genau man mit dem Rotationssensor 

arbeiten kann. 

Für Überlegungen über den tatsächlichen Versuchsaufbau und die Versuchsdurchführung 

reichte die Zeit allerdings nicht aus. Dies setzten wir 

Seite 4

uns aber für die nächste Stunde zum Ziel. Außerdem sollte Jakob, der an 

diesem Tag erkrankt war, über den Fortlauf des Projekts unterrichtet werden. 

Freitag, 29.01.10 


Freitag, 05.02.10 


Die Informatikstunde konnte auf Grund der Zeugnisvergabe für das erste 

Halbjahr nicht stattfinden. 

Die Informatikstunde konnte auf Grund eines Studientages nicht stattfinden. 

Zu Beginn der Stunde gab uns Herr Dietrich zwei verschiedene Fragestellungen 

zum Rotationssensor. Heute versuchen, wir den Abschnitt in unserem 

vorgegebenen Tutorial "Mehr über Motoren" herauszusuchen, der uns 

bei der Beantwortung der ersten Frage "Wie hoch ist die erzielte Motorengenauigkeit 

bei einer vorgegebenen Anzahl von Umdrehungen" helfen 

soll. Hierbei konnten wir schon einiges über die Programmierung und die 

Genauigkeit des Rotationssensors herausfinden. In der nächsten Stunde 

wollen wir einige Versuche durchführen, um die Genauigkeit des Rotationssensors 

zu überprüfen. Auch genauere Ideen zu diesen Versuchen werden 

wir uns in der nächsten Stunde einfallen lassen. 

Heute wollten Carsten und David einen Versuch mit dem Rotationssensor 

durchführen. Ziel war es, den Roboter eine bestimmte Wegstrecke (in diesem 

Fall 2 m) fahren zu lassen. Nach der Ermittlung des Reifenumfangs 

konnten wir die benötigte Umdrehungszahl und den exakten Drehwinkel 

berechnen. Die errechneten Daten fügten wir dann in den Programmcode 

ein, den wir schließlich in den Roboter einspeisten. Hierbei trat das Problem 

auf, dass der Roboter die doppelte Wegstrecke abfuhr, obwohl die vorherige 

Rechnung auch nach mehreren Kontrollen korrekt erschien. Wir nahmen 

uns vor, den Grund für das Problem in der nächsten Stunde zu ermitteln. 

Währenddessen machten Jan und Jakob den Roboter fahrtüchtig, damit wir 

den Versuch ordnungsgemäß durchführen konnten. Auch installierten sie 

vorsorglich zwei Berührungssensoren, die uns eventuell bei späteren Versuchen 

nützen könnten. Allerdings konnte beim Bau des Roboters ein Problem 

bis zum Ende der Stunde nicht gelöst werden. Die Stabilität des Heckfahrwerks 

war unzureichend. Diesem Problem wollten sie sich aber in der 

Seite 5

nächsten Stunde widmen. 

Freitag, 12.02.10 

An diesem Tag hatten Carsten und David vor, das Problem mit der doppelten 

Fahrstrecke des Roboters zu Iösen. Doch schon nach kurzer Zeit fanden 

wir heraus, dass uns ein Fehler bei der Ermittlung des Radumfangs 

unterlaufen war. Zusätzlich fanden wir heraus, dass der genaue Umfang 

bereits auf jedem Rad verzeichnet ist. Nach dem Einsetzen des neuen Wertes 

in die Rechnung stimmte die Lösung. Das Problem war damit gelöst. 

Für die nächste Stunde nahmen wir uns vor, den Versuch auch in schriftlicher 

Form abzuschließen. 

Jakob und Jan verstärkten inzwischen das Heck und die bereits installierten 

Berührungssensoren des Roboters. Für die nächste Stunde nahmen sich 

beide vor, weitere Schwachstellen am Roboter zu suchen und diese zu 

beseitigen. 


Heute haben Carsten und David den Versuch, den die Gruppe in den letzten 

Stunden bearbeitet hatte, verschriftlicht. 

Danach überlegten wir uns weitere Fragen, mit denen wir uns in den nächsten 

Stunden beschäftigen werden. Die nächsten Frage, mit der wir uns 

näher befassen werden, lautet: "Hat die Reibung, die bei der Fahrt auf dem 

Boden entsteht, Auswirkungen auf die Genauigkeit des Motors" 

Derweil modifizierten Jan und Jakob nochmals das Heckfahrwerk. Dadurch 

konnte der Roboter auch kleinere Hindernisse überwinden. Zuvor blieb das 

Heckfahrwerk bei Hindernissen wie einer Kante auf dem Boden meistens 

hängen, sodass der Roboter sich festfuhr. Für die nächste Stunde planten 

sie, Carsten und David bei ihren Arbeiten mit dem neuen Projekt zu unterstützen. 

Freitag, 19.02.10 

Am heutigen Tag haben David und Jan die schriftliche Form unserer Versuchsreihe, 

der wir uns in den letzten Stunden gewidmet hatten, noch etwas 

ergänzt. Durch die endgültige Fertigstellung des Dokuments konnten 

wir unsere erste Versuchsreihe abschließen. Für die nächsten Stunden 

nahmen wir uns nun vor, eine weitere Versuchsreihe aufzustellen. Die Frage 

dazu sollte lauten: "Hat die Reibung, die bei der Fahrt auf dem Boden 

Seite 6

entsteht, Auswirkungen auf die Genauigkeit des Motors" Jakob traf bereits 

Vorbereitungen für die nächste Versuchsreihe. Er stellte sicher, dass die 

dafür eventuell nötige Demontierung eines Motors möglichst einfach sein i 

sollte. 

Carsten konnte heute auf Grund einer Sportverletzung am Schulunterricht 

nicht teilnehmen. In der nächsten Stunde wird er die Gruppe wieder tatkräftig 

bei der Arbeit unterstützen. 


Freitag, 26.02.10 


In der heutigen Stunde besprachen wir nochmals kurz unser Dokument 

über den ersten Versuch, sodass wir es nun drucken und in der Mappe 

abheften können. Danach überlegten wir uns für unseren zweiten Versuch 

die genauere Durchführung. Einerseits soll der Roboter seine Reifen dreimal 

in der Luft drehen, andererseits soll er am Boden stehen und dabei 

direkt an einer Wand die Reifen antreiben. Dadurch wollen wir herausfinden, 

ob die Reibung des Bodens irgendeine Auswirkung auf die Arbeit des 

Rotationssensors hat. Unseren Plan über die Durchführung der Versuchsreihe 

halten wir schriftlich fest. In der nächsten Stunde möchten wir den 

Versuch durchführen. 

Heute haben Carsten und David die Versuchsreihe durchgeführt und angefangen, 

diese zu verschriftlichen. Jakob und Jan assistierten uns hierbei. 

Für die nächste Stunde haben wir geplant, die schriftliche Form unserer 

zweiten Versuchsreihe abzuschließen. Außerdem wollen wir uns schon die 

ersten Gedanken über unser Projekt mit dem Roboter machen. 

Heute haben Carsten und David die schriftliche Form unseres zweiten Versuches 

beendet. Hierbei fügten wir noch den Programmcode ein und 

schrieben eine Antwort auf die Frage: "Hat die Reibung, die bei der Fahrt 

auf dem Boden entsteht, Auswirkungen auf die Genauigkeit des Motors 

Als nächstes wollen wir unsere vorläufig letzte Versuchsreihe bearbeiten, 

die die Frage "Wie genau kann sich der Roboter um einen bestimmten 

Winkel (z. B. 90 Grad) drehen" behandelt. Hierzu stellten wir bereits erste 

Überlegungen an. Konkretere Ideen werden im nächsten Tagesbericht folgen. 

Auf jeden Fall stand fest, dass wir das Programm für das exakte Be- 

Seite 7

fahren einer bestimmten Kurve sicherlich noch öfter wie zum Beispiel für 

unser späteres Projekt brauchen würden. In der nächsten Stunde werden 

wir unsere Ideen über die Durchführung unserer dritten Versuchsreihe konkretisieren. 

Jakob und Jan haben derweil nach einem Projekt gesucht, das wir nach 

den Osterferien bearbeiten werden. Eine Idee war zum Beispiel eine Putzmaschine, 

bei der der Rotationssensor dabei helfen kann, den Roboter 

genau geradeaus fahren zu lassen. In den nächsten Stunden werden die 

beiden weitere Ideen für unser Projekt sammeln. 

Während der Stunde gab es einige Komplikationen mit dem Roboter. Bei 

seiner Inbetriebnahme traten technische Probleme auf. Durch ein Versehen 

aktivierte Jan den sogenannten SAMBA-Modus über das Bricx-Command- 

Center. Dies hatte zur Folge, dass der Bildschirm des NXT-Bausteins ausfiel 

und weder auf Tastendruck noch auf Eingaben durch den Computer 

ansprach. Zusammen mit Herrn Dietrich konnte das Problem aber relativ 

schnell behoben werden, indem das Betriebsprogramm des NXT-Bausteins 

durch ein Tool von John Hansen, dem Verfasser und Verfechter von NXC, 

ersetzt wurde. 

Freitag, 05.03.10 

Heute haben sich Carsten und David mit dem Versuch, der die Frage "Wie 

genau kann sich der Roboter um einen bestimmten Winkel (z. B. 90 Grad) 

drehen" behandelt, beschäftigt. Dazu maßen wir den Radstand unseres 

Roboters, der in einem fiktiven Kreis den Radius darstellt. Durch den Radius 

können wir also nun den Umfang dieses Kreises berechnen. Der Roboter 

soll hierbei nur einen Reifen antreiben und ein Viertel des Umfangs abfahren. 

Dadurch dürfte er sich um exakt 90 Grad drehen. Dies wollen wir in 

der nächsten Stunde ausprobieren. Zusätzlich erklärte uns Herr Dietrich, 

dass ein Roboter die vorgegebene Anzahl Radumdrehungen nicht ganz 

genau umsetzen kann. Dies konnten wir mithilfe des Bricx-Command- 

Centers feststellen. Der Roboter drehte die Räder immer um ein paar Grad 

zu viel. Ein Grund dafür könnte zum Beispiel sein, dass die Räder sich auf 

Grund des Trägheitsprinzips noch weiterdrehen, obwohl der NXT-Baustein 

die Motoren bereits gestoppt hat. 

Seite 8

Jakob und Jan suchten während der Stunde im Internet weite Ideen für 

unser Projekt. Es fiel ihnen allerdings sehr schwer, geeignete Ideen zu finden, 

da sie ausschließlich Projekte fanden, die Anzahl und Art der uns zur 

Verfügung stehenden LEGO-Teile bei weitem übersteigen. Trotzdem werden 

sie in der nächsten Stunde weiter nach Ideen für das Projekt suchen. 


Heute haben Carsten und David den dritten Versuch fortgeführt. Wir notierten 

unsere Ideen und rechneten aus, um wie viel Grad sich der Reifen des 

Roboters drehen muss, damit sich der Roboter um genau 90 Grad dreht. 

Wir versuchten, die ermittelten Daten in den Programmcode einzufügen. 

Beim Abspielen des Programms trat allerdings ein unerwartetes Problem 

auf. Wie in den anderen Versuchen zuvor wollten wir auch hier die Funktion 

"RotateMotorEx" anwenden. Allerdings fanden wir heraus, dass diese Funktion 

nur für das Ansteuern von zwei Motoren geeignet ist. Wir müssen also 

nun eine andere Funktion finden. Dies wollen wir in der nächsten Stunde 

herausfinden. 

Jakob und Jan suchten derweil nach weiteren Ideen für unser Projekt. Auch 

heute fiel es ihnen auf Grund mangelnder LEGO-Teile schwer, geeignete 

Ideen für das Projekt zu finden. Zumindest konnten weitere Ideen für den 

Projektvorschlag "Putzroboter" gesammelt werden. Allerdings entschieden 

wir uns, noch weiter nach Ideen zu suchen. Dies nahmen sich Jan und 

Jakob für die nächste Stunde vor. 

Freitag, 12.03.10 

Am heutigen Tag erklärte Herr Dietrich zunächst allen Gruppen, dass bis zu 

den Osterferien eine Projektidee feststehen solle. Hierzu wies er uns auf 

den richtigen Aufbau des Projektes und dessen Management hin. Wir bekamen 

also nun den Auftrag, innerhalb der nächsten zwei Wochen einen 

Projektauftrag anzufertigen. Den Beginn der Anfertigung eines Projektauftrages 

schoben wir heute erst einmal auf, da unsere beiden Gruppenmitglieder 

Jakob und Jan erkrankt waren und deshalb an der Informatikstunde 

nicht teilnehmen konnten und auch noch keine feste Idee für das Projekt 

feststand. Außerdem benötigte unsere Versuchsreihe noch etwas Arbeit. 

Deshalb widmeten wir uns wieder dem dritten Versuch. Während Carsten 

Seite 9

versuchte, eine geeignete Funktion für den Programmcode des Roboters 

herauszusuchen, beschäftigte sich David mit den vorher berechneten Werten 

und überprüfte diese auf Fehler. Tatsächlich fand er eine Unregelmäßigkeit, 

die er in der nächsten Stunde beheben will. 

Carsten sah die Funktion "RotateMotor" als geeignet an. Zusammen mit 

David wird er den Versuch in der nächsten Stunde fortführen. 


Heute haben Carsten und David das Ergebnis unserer dritten Versuchsreihe 

korrigiert. Die vorher errechnete Lösung bezweckte, dass sich der Roboter 

um weniger als 90 Grad dreht. Dies entsprach allerdings nicht unseren 

Vorstellungen. Nach dem Überprüfen der Rechnung bemerkten beide, dass 

sie den Radstand des Roboters als Durchmesser des fiktiven Kreises verwendet 

hatten. Richtig war es allerdings, den Radstand als Radius des 

Kreises zu benutzen. Nach dem Einsetzen des neuen Wertes in die Rechnung 

und dem Erstellen eines neuen Programmcodes drehte sich der Roboter 

um exakt 90 Grad. Damit hatten wir unser Ziel erreicht. Dies war vermutlich 

auf Grund von Zeitmangel unsere letzte Versuchsreihe. Allerdings 

konnten Carsten und David die schriftliche Form der dritten Versuchsreihe 

nicht abschließen, was sie sich allerdings für die nächste Stunde vornahmen. 

Jan und Jakob fertigten heute einige Skizzen zu unserem Projekt an. Wir 

einigten uns heute tatsächlich auf einen Kehr- oder Reinigungsroboter. 

Beide überlegten sich den genaueren Aufbau des Roboters. Außerdem 

stand die Frage, ob es sich bei dem Reinigungsaufsatz um einen Besen 

oder einen Räumschild handeln sollte, im Raum. Wir einigten uns zunächst 

auf den Räumschild. Allerdings könnte sich dies natürlich im Laufe des 

Projekts noch ändern. Zudem besprachen wir auch mit Herrn Dietrich unsere 

Idee. Er gab uns zusätzliche Vorschläge für das Projekt. Zum Beispiel 

solle der Roboter fähig sein, den aufgesammelten "Abfall" in eine Art Container 

zu befördern. Diese Idee werden wir uns im Hinterkopf behalten. 

Jakob und Jan nahmen sich für die nächste Stunde vor, den Projektantrag 

ordentlich auszufüllen und den Roboter vollständig zu demontieren. 

Seite 10

Freitag, 19.03.10 

Heute haben Carsten und David die schriftliche Form unserer dritten Versuchsreihe 

komplett verschriftlicht. Das Dokument ist in der nächsten Stunde 

in unserer Projektmappe zu finden. Damit haben wir die Versuchsreihen 

abgeschlossen und damit den Grundstein für unser kommendes Projekt 

gelegt. Jan hat heute den Roboter fachgerecht demontiert und die Teile in 

den Legobaukasten einsortiert. Dadurch stellte er einen reibungslosen späteren 

Wiederaufbau des Roboters sicher. 

Jakob füllte währenddessen den Projektantrag aus. Hierbei überlegte er 

sich sowohl den Namen des Teams und den Namen des Roboters. Die 

genauen Ziele des Projektes, also Minimal- und Maximalziel, konnte er 

noch nicht notieren, da dies weitere Überlegungen benötigt. Diese Überlegungen 

wird die Gruppe in der nächsten Stunde sowohl zusammen als 

auch einzeln anstellen. 


Am heutigen Tag hat die gesamte Gruppe über das Minimal- und das Maximalziel 

unseres Projektes diskutiert. Wir konnten uns relativ schnell einigen. 

Außerdem konnte uns Herr Dietrich nochmals über die Projektziele 

beraten und uns dadurch bei deren Findung helfen. Zusätzlich besprachen 

wir mit Team 4 unsere Projekte, da auch bei diesem Team die Idee bestand, 

einen Räumroboter zu bauen. Allerdings stellten wir sehr zeitnah 

fest, dass die Details der Roboter doch im Wesentlichen unterscheiden. 

Anschließend füllten Carsten und David den Projektantrag aus. Zusätzlich 

verschriftlichten sie den Antrag nochmals auf dem Computer, da der Platz 

auf dem Formular nur sehr begrenzt war. 

Jan und Jakob bauten das Grundgerüst des neuen Roboters. Dabei bedachten 

sie schon den Einbau eines Greifarms für unser Projekt. 

Nach den Ferien werden wir mit dem Projekt beginnen. 


Heute besprach die gesamte Gruppe nochmals das Minimalziel des Projektantrags. 

Dabei wurden die Aufgaben für die nächsten Stunden vergeben. 

Jakob und Jan wurden beauftragt, den Roboter für die Anforderungen 

des Projekts vorzubereiten, während Carsten und David einen geeigneten 

Programmcode für den Roboter schreiben sollen. 

Seite 11

Da Herr Dietrich uns heute nicht unterrichten konnte, wurde er von Herrn 

Heurich vertreten. Wir stellten fest, dass dieser ebenfalls ein sehr hohes 

Wissen im Bereich der Programmierung von Robotern besaß. Daher besprachen 

wir mit Herrn Heurich ebenfalls unser Projekt. Dabei konnte er 

uns einige Tipps geben. Allerdings wies er uns auch darauf hin, dass wir 

uns, um unser Maximalziel erfüllen zu können, wohlmöglich auch mit dem 

Kompasssensor vertraut machen müssen. Darüber wollten sich Carsten 

und David in der nächsten Stunde Gedanken machen. Für die zukünftigen 

Stunden bot uns Herr Heurich bei eventuellen Rückfragen dankenswerterweise 

auch seine Hilfe an. 

Freitag, 16.04.10 

An diesem Tag unterhielt sich die gesamte Gruppe über einige Schwerpunkte, 

die mit dem Projekt in Verbindung stehen. Zum Beispiel wurde darüber 

diskutiert, ob ein Räumschild für den Roboter wirklich geeignet ist. Da 

Carsten und David als Programmierer angaben, dass der Roboter ein Stück 

rückwärtsfahren muss, suchte die Gruppe eine Alternative zu dem Räumschild, 

da dieses die eingesammelten Teile beim Rückwärtsfahren verlieren 

würde. Wir dachten über einen Auffangbehälter nach, der durch eine 

durchgehend rotierende Bürste mit aufgefangenen Teilen bestückt wird. 

Diese Bürste könnte dann mit unserem dritten Motor angetrieben werden. 

Wir überlegten auch, wie wir dem Problem, dass der Roboter beim Zurücklegen 

seines Weges durch den zu säubernden Raum von seiner Bahn abkommen 

kann, gegenübertreten sollen. 

Da die Ideen nun ausgetauscht waren und sich geeinigt wurde, bekamen 

Jakob und Jan nun den Auftrag, in der nächsten Stunde mit den Bau eines 

Roboterprototyps zu beginnen. David und Carsten werden das nächste Mal 

erstmals mit den Programmcodes beginnen. 


Nach einer kurzen Teambesprechung begannen Jan und Jakob mit dem 

Bau eines Roboterprototyps. Ihr Auftrag war es, das Grundgerüst des Roboters 

fertigzustellen. Nachdem sie das erledigt hatten, konnten sie den 

Bau der Antriebsachse für den rotierenden Besen fortsetzen. Jan brachte 

die Idee ein, die Übersetzung für die Antriebsachse durch einen Kettenan- 

Seite 12

trieb zu bewirken. Allerdings wurde darüber diskutiert, ob ein Kettenantrieb 

die Anforderungen an den Roboter erfüllen würde, da dieser Antrieb einige 

Fehler in der Stabilität aufwies. Am Ende der Stunde konnte sich die gesamte 

Gruppe auf die Kompromisslösung einigen, dass der Kettenantrieb 

zunächst bestehen bleibt, aber beim Aufweisen von weiteren Fehlern durch 

ein besseres System ersetzt wird. Für die nächste Stunde wurde geplant, 

dass Jan und Jakob den Bau des Roboters fortsetzen. David versprach 

ihnen, bis zur nächsten Stunde geeignete LEGO-Teile aus privaten Beständen 

mitzubringen, da das Projekt besondere Teile, die nicht im LEGO- 

Baukasten der Schule enthalten sind, benötigt. 

David und Carsten fingen heute an, den Programmcode unseres Minimalziels 

für den Roboter zu schreiben. Leider konnten sie die geschriebenen 

Codes am Roboter noch nicht testen, da dieser für uns noch nicht verfügbar 

war. Beim Programmieren nutzten uns bereits vorher geschriebene Programme 

wie zum Beispiel die 90°-Kurve. Der Programmcode konnte heute 

allerdings noch nicht fertiggestellt werden, da wir für die Ermittlung der Daten 

für die 180°-Drehung, die der Roboter beim Fahren gegen die Wand 

durchführen muss, den Radstand des neuen Roboters noch abmessen 

müssen. Stattdessen überlegten sich Carsten und David in Absprache mit 

Jan und Jakob, welche Spezial-LEGO-Teile für den Roboter noch gebraucht 

werden. David erklärte sich bereit, die gewünschten Teile aus eigenen 

Beständen bis zur nächsten Stunde zu beschaffen. 

In der nächsten Stunde werden Carsten und David weiter am Programmcode 

arbeiten. 

Freitag, 23.04.10 

Heute erwartete uns Herr Dietrich mit neuen Dokumenten, die für ein Gelingen 

des Projekts Voraussetzung sind. Es handelte sich hierbei um die Projektabschlussberichte, 

die am Ende des Projekts angefertigt werden müssen. 

Auch stellte uns Herr Dietrich die Abschlussberichte früherer Informatikgruppen 

zur Verfügung, um zu demonstrieren, welche Anforderungen er 

an uns stellt. Also entschieden wir uns spontan, diese Unterlagen durchzusehen. 

Während Jan und Jakob damit beschäftigt waren, die Projektabschlussberichte 

vorangegangener Gruppen zu sichten, informierten sich 

Seite 13

Carsten und David mit dem Dokument "Hinweise zum Projektabschlussbericht", 

das uns Herr Dietrich ebenfalls zur Verfügung stellte, über die wichtigsten 

Aspekte in einem Projektabschlussbericht. Außerdem baute Jakob 

den Antrieb für den rotierenden Besen nochmals um, da der mangelhafte 

Kettenantrieb heute doch als unzureichend bewertet wurde. Mit einer neuen 

Konstruktion ohne Kette bietet das gesamte System nun ein hohes Maß an 

Stabilität. Wir schlossen heute den Gebrauch des Kettenantriebs an anderer 

Stelle nicht aus. 

Nachdem Carsten und David mit der Sichtung der Dokumente fertig waren, 

kontrollierten sie den bis dahin programmierten Code des Roboters. Dabei 

fiel ihnen auf, dass sie eine falsche Schleife für das Programm benutzt hatten. 

Sie machten es sich für die nächste Stunde zur Aufgabe, den Programmcode 

weiter auszubauen. Jan und Jakob bekamen für die nächste 

Stunde die Aufgabe, den Bau des Roboters fortzusetzen. 


Heute kam leider die gesamte Klasse etwas zu spät zum Informatikunterricht, 

da uns die vorherige Lehrerin zu spät entlassen hatte. Wir begannen 

also sofort mit unserer Arbeit. 

Carsten und David nahmen nun für die 180° Drehung die nötigen Werte 

vom Roboter ab und setzten diese in die zuvor erstellte Gleichung ein. Auf 

eine Lösung kamen die beiden allerdings auf Grund des Zeitmangels noch 

nicht. Mit der Findung der Lösung werden sie aber in der nächsten Stunde 

sofort fortfahren. 

Jakob und Jan bauten heute die Antriebswelle für den rotierenden Besen 

weiter. Die Kraft musste umgelenkt werden. Dies erzielten sie durch eine 

Kardanwelle. Allerdings trat hierbei das Problem auf, dass die Kardanwelle 

bei hoher Belastungzu vibrieren anfing. In der nächsten Stunde werden sie 

also versuchen, das Antriebssystem zu verstärken. 

Freitag, 30.04.10 

Heute haben Carsten und David weiter an der Gleichung gearbeitet. Ihr 

anfängliches Ergebnis wies Fehler auf. Bis zum Ende der Stunde konnten 

sie den Fehler allerdings nicht berichtigen. Deshalb werden sie die Gleichung 

in der nächsten Stunde berichtigen und weiter ausarbeiten. Das Er- 

Seite 14

gebnis werden sie in den Programmcode einfügen und damit weiterarbeiten. 

Jan und Jakob bauten heute zwei LEGO-Radladerschaufeln, die David aus 

eigenen Beständen mitgebracht hatte, an den Roboter. Die Schaufeln sollen 

in Zukunft die aufgesammelten Teile auffangen. 

Danach diskutierten sie, ob der rotierende Besen tatsächlich für das Projekt 

geeignet wäre. Es war fraglich, ob das System mit dem Besen wirklich mit 

den verfügbaren Teilen umsetzbar wäre. Die gesamte Gruppe überlegte 

sich ein neues Konzept. Die neue Idee war es, in die Schaufeln des Roboters 

jeweils einen Dauermagneten zu fixieren. Diese Dauermagneten sollen 

dann kleine Kugeln aus Stahlwolle aufnehmen. Die Kugeln bleiben dann 

auf Grund der Magnetkraft an den Magneten hängen. Jan und Jakob werden 

in der nächsten Stunde mit dem Bau des Roboters fortfahren. Genauere 

Informationen dazu werden im nächsten Tagesbericht notiert. 

Dienstag, 04.05.10 Heute haben Carsten und David mit einer Gleichung die Daten für die 180°- 

Drehung erstellt. Diese fügten sie dann in den Programmcode für den Roboter 

ein. Danach wurde der Code noch einmal überprüft. 

Jan und Jakob überlegten heute, ob die Antriebswelle des Roboters, die 

eigentlich für den rotierenden Besen gedacht war, dessen Konzept in der 

letzten Stunde verworfen wurde, dafür verwendet werden kann, die Schaufeln 

des Roboters anzuheben und wieder herabzulassen. Dafür entwickelten 

sie ein Konzept, das aus einer Art Seilzug bestand. Zusammen mit 

Carsten und David, die ein Programm zum Test für das Konzept entwickelten, 

probierten sie den Seilzug aus. Er wies allerdings einige Fehler auf. 

Das Konzept wurde wieder verworfen. 

In einem Gruppengespräch erinnerte David des Bauteam, welche Teile am 

Roboter noch installiert werden müssen, da Carsten und David einen fertigen 

Roboter brauchen, um den Programmcode testen und wenn nötig verbessern 

zu können. Deshalb planten Jakob und Jan, den Roboter in der 

nächsten Stunde weiterzubauen. 

Freitag, 07.05.10 

Heute hat sich David mit Jan und Jakob zusammengesetzt, um mögliche 

Seite 15

Missverständnisse in den Bauplänen zu beseitigen. Dabei wurde besonders 

auf die Konstruktion, die dem Roboter hilft, während der Fahrt durch den 

Raum immer auf gerader Spur zu bleiben, eingegangen. Bestückt mit den 

neuen Informationen fingen Jan und Jakob mit dem Bau der besagten Konstruktion 

an. Außerdem behielten sie dabei den Bau der Konstruktion für 

das Hochziehen und Ablassen der Schaufel im Hinterkopf. 

Heute hat David nochmals den Programmcode überprüft und eine Endlosschleife 

eingefügt. Der Programmcode dürfte nun fertig für einen ersten 

Testlauf sein. Dies besprach David ebenfalls mit Jan und Jakob. Sie gaben 

sich mit einem Testlauf in der nächsten Stunde einverstanden, da der Roboterprototyp 

ebenfalls bald fertiggestellt sei. 

David befasste sich heute außerdem mit der Dokumentation der Projektarbeit. 

Er informierte sich nochmals über die von Herrn Dietrich bereitgestellten 

Dateien, um zu erfahren, welche Anforderungen gestellt werden. 

In der nächsten Stunde wird die Gruppe einen ersten Testlauf mit dem Roboter 

und dem Programmcode durchführen. Beide Teams (Programmteam 

und Bauteam) werden mit Hilfe der Testergebnisse Fehler am Roboter bzw. 

am Programmcode berichtigen. 

Carsten war heute krank. 


Heute haben sich Carsten und David um den Projektabschlussbericht gekümmert. 

Dabei haben sie zunächst ein Gruppenlogo entworfen und dieses 

dann in das Deckblatt eingefügt. Das Deckblatt konnte dadurch fertiggestellt 

werden. Außerdem fingen sie mit dem Inhaltsverzeichnis an und verliehen 

dem Dokument eine Grundstruktur. 

Jan und Jakob setzten heute den Bau des Roboters fort. Es ging darum, 

eine Konstruktion für das Anheben und Ablassen der Roboterschaufel zu 

bauen. Das Problem lösten sie mit einem ausgeklügelten Ketten- und Zahnradantrieb. 

Die Kraftübersetzung, die die beiden während der Stunde bauten, 

wies viel Stabilität auf.Bei einem Test konnte der Roboter ein relativ 

großes Gewicht (etwa 200 Gramm) problemlos anheben. Der Plan für diese 

Doppelstunde sah eigentlich vor, dass in der zweiten Hälfte ein Versuch mit 

Seite 16

dem Programmcode und dem Roboter durchgeführt wird. Allerdings konnte 

das Bauteam den Zeitplan leider nicht einhalten. Der Roboter konnte von 

ihnen nur teilweise fertiggestellt werden. Die Gruppe verlegte deshalb den 

ersten Testlauf des Roboters auf die nächste Stunde. 

Freitag, 14.05.10 


Auf Grund eines Feiertags entfiel für uns der heutige Unterricht und damit 

auch die Informatikstunde. 

Am heutigen Tag war geplant, einen Testlauf mit dem Roboter und dem 

Programmcode durchzuführen. Allerdings fiel schon beim ersten Abspielen 

des Programms auf, dass der Synchronisationsmodus nicht richtig funktionierte. 

Auch nachdem wir den Programmcode mehrmals überprüft hatten, 

konnten wir keinen Fehler finden. Beim Abspielen des Programms konnte 

man das eine Rad des Roboters blockieren, während sich das andere ungehindert 

weiterdrehte. Somit konnten wir nicht sicherstellen, dass der Roboter 

beim Abfahren des Programms wirklich genau geradeaus fährt. Wir 

entschieden, Herrn Dietrich bei der Fehlersuche hinzuzuziehen. Leider fand 

dieser zunächst keine Zeit für uns. Daher setzten wir spontan die Erstellung 

des Projektabschlussberichts fort. 

Als uns Herr Dietrich endlich mit dem Programmcode half, konnte er den 

Fehler finden. Nun funktionierte zwar der Synchronisationsmodus, trotzdem 

fuhr der Roboter nicht genau geradeaus. Die Gruppe plante, das Problem in 

der nächsten Stunde zu lösen. 

Freitag, 22.05.10 

Heute wollten Carsten und David den Grund finden, warum der Roboter 

trotz Synchronisation der Motoren nicht genau geradeausfährt. Dazu überprüften 

sie nochmals den Programmcode. Hier konnten sie allerdings wieder 

keinen Fehler finden. Schließlich suchten sie zusammen mit Herrn Dietrich 

den Fehler. Er wies darauf hin, dass der Fehler wohlmöglich an der 

Konstruktion des Roboters bzw. des NXT-Motors liegen könnte. Es fiel 

nämlich auf, dass ein Motor ziemlich unruhig rotierte. Ein weiterer möglicher 

Grund für das ungenaue Fahren des Roboters könnte auch sein, dass die 

Firmware, die auf dem NXT-Baustein installiert ist, den Programmcode 

nicht genau umsetzen kann. Bei den Testreihen mit dem Rotationssensor 

Seite 17

vor dem Projekt war aus Versehen der sogenannte Samba-Mode aktiviert 

worden. Hierbei musste die Firmware des Roboters neu installiert werden. 

Vermutlich handelte es sich hierbei um eine andere Version der Firmware, 

die nun die gegebenen Daten nicht genau verwerten kann. In der nächsten 

Stunde werden Carsten und David versuchen, die originale Version der 

Firmware im Internet zu finden und diese auf dem NXT-Baustein zu installieren. 

Jakob und Jan haben heute die LEGO-Teile im Baukasten sortiert 

und teilweise eine Inventur durchgeführt. 

In der nächsten Stunde werden sie sich mit der Konstruktion des Roboters 

auseinandersetzen, um einen möglichen Fehler, der den Roboter beim 

Geradeausfahren negativ beeinflusst, zu finden. 


Eigentlich war heute für Carsten und David geplant, dass sie eine neue 

Firmware für den NXT-Baustein suchen, damit der Programmcode endlich 

korrekt vom Roboter verarbeitet wird. Dies verwarfen sie heute zunächst, 

da sie bei einigen Überlegungen den Programmcode betreffend ein Problem 

feststellten. Nach der bis dahin aktuellen Version des Programmcodes 

hätte sich der Roboter beim Berühren einer Wand immer in dieselbe Richtung 

gedreht. Dies hätte dann zur Folge gehabt, dass der Roboter nur eine 

kleine Strecke des vorgegebenen Raums abgefahren hätte, anstatt nach 

jeder Wandberührung die Drehrichtung zu ändern und sich dadurch im 

Raum immer weiter fortzubewegen. Um dieses Problem zu lösen, recherchierten 

Carsten und David mit Hilfe des zur Verfügung gestellten Tutorials 

zunächst allein, wie dieses Problem zu lösen galt. Es fiel ihnen allerdings 

relativ schnell auf, dass es sich hierbei um eine sehr komplexe Aufgabe 

handelte. Deshalb bezogen sie Herrn Dietrich in ihre Überlegungen mit ein. 

Als er über das Problem aufgeklärt war, konnte er uns gleich einige Tipps 

liefern. Zum Beispiel war das Deklarieren einer Variablen im Programmcode 

notwendig, was Carsten und David anschließend umgehend vollzogen. 

Trotzdem fehlte ihnen auf Grund der Schwierigkeit des Problems der 

weitere Ansatz. Bis zum Stundenende konnte das Problem noch nicht vollständig 

gelöst werden. 

Deshalb werden Carsten und David vermutlich in der nächsten Stunde 

Seite 18

ebenfalls die Hilfe von Herrn Dietrich benötigen, um den Programmcode 

weiterzuentwickeln. Jan und Jakob versuchten heute, Schwachstellen am 

Robotermotor, der in der letzten Stunde ungewöhnliche Vibrationen erzeugte, 

zu finden. Es fiel ihnen allerdings auf, dass der Fehler hierbei nicht an 

der Konstruktion bzw. dem Aufbau des Roboters lag, sondern ausschließlich 

an dem Motor selbst entstand. Sie vermuteten, dass dieses Problem 

durch eine Materialermüdung innerhalb des Motors durch den vielen Gebrauch 

entstanden sein könnte. Bei einigen Tests bemerkten sie aber, dass 

die Auswirkungen auf die Fahreigenschaften des Roboters durch die eigenartige 

Vibration des Motors eher gering ausfallen. Genauso wie Carsten 

und David vermuteten sie, dass der Synchronisationsmodus, dessen Fehlfunktion 

ja bereits in der letzten Stunde entdeckt wurde, durch die falsche 

NXT-Firmware entsteht. 

In der nächsten Stunde werden Jakob und Jan eine Fehlersuche am Roboter 

betreiben, um Schwachstellen an der Konstruktion zu verbessern und so 

einen reibungslosen Ablauf der Tests mit dem Programmcode zu gewährleisten. 

Freitag, 28.05.10 

Am Anfang der heutigen Stunde fertigte die Gruppe jeweils ein Einzelfoto 

jedes Gruppenmitglieds an. Die Bilder der Kamera, die David zur Verfügung 

stellte, werden nun in Kürze in den Projektabschlussbericht eingefügt. 

Anschließend wendeten sich Carsten und David ihrer eigentlichen Aufgabe 

für heute zu. Es galt immer noch herauszufinden, wie der Programmcode 

verändert werden muss, damit sich der Roboter beim Berühren einer Wand 

in die jeweils richtige Richtung dreht. Die Tatsache, dass sie mit einer Variablen 

arbeiten mussten, hatten sie schon in der letzten Stunde herausgefunden. 

Allerdings wussten sie nicht genau, an welchen Stellen im Programmcode 

sie die Variablen einfügen sollten. Jonas Gömpel, ein sehr 

erfahrenes Mitglied des Informatikkurses, wurde zu den Überlegungen hinzugezogen. 

Er konnte dankenswerterweise einige sehr hilfreiche Tipps im 

Bezug auf die Arbeit mit Variablen liefern. Hiermit konnte der Programmcode 

endlich richtiggestellt werden. In der nächsten Stunde werden Carsten 

und David den Programmcode weiter ausbauen. 

Seite 19

Jan und Jakob mussten heute zunächst einen neuen Akku für den Roboter 

auftreiben. Was normal kein Problem darstellt, gestaltete sich heute schwierig, 

da kein Ersatzakku mehr zur Verfügung stand. Nach Absprache mit 

einer anderen Gruppe konnte allerdings kurzzeitig ein Akku ausgeliehen 

werden, um den neuen Programmcode zu testen. Danach fingen sie an, die 

am Anfang der Stunde gemachten Bilder auf die richtige Größe zuzuschneiden. 

Sie gaben die zugeschnittenen Bilder weiter an David, der diese 

weiterverarbeiten wird. 

In der nächsten Stunde werden Jakob und Jan eine Fehlersuche am Roboter 

betreiben. Dieses Vorhaben, welches heute schon hätte stattfinden sollen, 

wurde auf Grund des leeren Akkus und der Photographien auf die 

nächste Stunde verschoben. 


Carsten und David beschäftigten sich heute nochmals mit dem Problem, 

dass der Roboter immer noch nicht fähig ist, genau geradeauszufahren. 

Hierzu suchten sie nochmals einen Fehler im Programmcode. Sie fügten 

sämtliche Synchronisationsmodi in den Code ein, um zu testen, ob vielleicht 

hier der Fehler lag. Nach intensiver Überprüfung stellten sie allerdings fest, 

dass sich definitiv kein Fehler im Programmcode befand. Sie zogen Herrn 

Dietrich zu den Überlegungen hinzu. Dieser wies darauf hin, dass das Problem 

in der Konstruktion läge. Er gab an, dass der Grund für das instabile 

Fahren des Roboters seine Asymmetrie sei. 

Jakob und Jan wurden beauftragt, dies zu überprüfen. Währenddessen 

führten Carsten und David die Arbeit mit dem Programmcode fort. Am Ende 

der Stunde beendeten sie ihre Tätigkeit und planten, diese in der nächsten 

Stunde wiederaufzunehmen. Jan und Jakob begannen mit einer Fehlersuche 

an der Konstruktion des Roboters, nachdem diese von Herrn Dietrich 

angezweifelt wurde. Herr Dietrich meinte, dass der Roboter schief fahren 

würde, da die Gewichtsverteilung auf den Rädern zu sehr variiere. Sie 

brachten Gegengewichte an und spielten den Programmcode nochmals ab. 

Sie stellten keinen Unterschied fest. Dann wurde vermutet, dass der Fehler 

seinen Ursprung in der Art der Räder hat. Deshalb wurde diese durch Räder, 

die eine geringe Auflagefläche besitzen, ersetzt. Auch dies änderte 

Seite 20

nichts an der Situation. Schließlich wurden die Vibrationen des Roboters 

überprüft. Anscheinend lag hier der Ursprung des Problems. Die Roboterräder 

schienen sehr zu vibrieren. Bei anderen Gruppen trat das Problem 

nicht auf. Jakob und Jan fingen also damit an, die Motoren auszutauschen. 

Damit werden sie in der nächsten Stunde fortfahren. 

Freitag, 04.06.10 


Auf Grund eines Feiertags entfiel für uns der heutige Unterricht und damit 

auch die Informatikstunde. 

Am heutigen Tag haben sich Carsten und David nochmals dem Programmcode 

gewidmet. Sie mussten den Befehl "RotateMotorEx" nochmals ändern, 

da der Roboter diesen heute eigenartigerweise nicht umsetzen konnte. 

Beide entschieden sich für den Befehl "RotateMotor". Diese Funktion 

wurde schließlich einwandfrei ausgeführt. Heute fügten sie ebenfalls das 

Anheben und Ablassen der Radladerschaufel in den Code mit ein. Danach 

hatten sie vor, die einzelnen Befehle im Programmcode zu beschriften und 

zu kommentieren. Anschließend überlegten sie, wie das Programm fortgeführt 

werden könnte. Es leuchtete ihnen ein, dass der Roboter irgendwie 

erkennen musste, dass sein Weg zu Ende ist und dass er seine Arbeit deshalb 

beenden soll. Sie kamen auf die Idee, einen Lichtsensor dafür zu verwenden. 

Sie fügten die nötigen Befehle in den Programmcode ein. Nachdem 

Jakob und Jan den Lichtsensor am Roboter installiert hatten, konnten 

sie den Programmcode testen. Den richtigen Lichtwert konnten sie aus 

Zeitgründen nur ausprobieren und keine genauen Messungen durchführen. 

Allerdings war der richtige Wert relativ schnell gefunden. Auch die Kursmitglieder 

Jonas und Pascal bestätigten den Wert als richtig. Auf diese Weise 

konnte die Gruppe einen weiteren Erfolg erzielen. Durch die Einbindung 

des Lichtsensors in den Programmcode konnte das Minimalziel soweit fertiggestellt 

werden, da der Roboter sich nun durch den Raum tasten kann, 

dabei "Müll" aufsammeln kann und das Ende seiner Wegstrecke erkennt. 

Das Ende der Wegstrecke wird durch einen silbernen Aluminiumstreifen 

markiert, der das Licht des Lichtsensors sehr gut reflektiert. 

Da in der nächsten Stunde am Freitag die Abgabe des Projektabschlussbe- 

Seite 21

ichts erfolgen sollte, versprach David, nochmals den Programmcode zu 

überprüfen und die verschiedenen Funktionen zu kommentieren. 

Jakob und Jan montierten zu Anfang der ersten Hälfte Doppelstunde neue 

Reifen am Roboter, wechselten den Akku des NXT-Bausteins und bauten 

eine neue, leistungsfähigere Vorrichtung am Berührungssensor, die diesen 

noch empfindlicher machte. Anschließend bekamen sie von David den Auftrag, 

einen Lichtsensor am Roboter zu installieren. Nachdem sie dies erledigt 

hatten, wurden sie nach dem Einverständnis von Herrn Dietrich und 

David entlassen, um Schulentlassformalitäten abzuwickeln. 

Donnerstag, 10.06.10 

Freitag, 11.06.10 

Am Nachmittag dieses Donnerstags legte David eine Sonderschicht ein, da 

er als Protokollant noch einiges mit dem Projektabschlussbericht zu tun 

hatte. Dazu machte er Bilder des Roboters, um diese in den Bericht einzufügen. 

Ebenfalls nahm er einige Messwerte, wie Länge, Breite, Höhe und 

Gewicht vom Roboter ab, vom Roboter ab und fügte diese in den Projektabschlussbericht 

ein. Zusätzlich überprüfte er nochmals den Programmcode 

und kommentierte und beschriftete noch einige der Funktionen im 

Code. Schließlich setzte er das Schreiben des Projektabschlussberichts 

fort, um eine pünktliche Abgabe in der nächsten Informatikstunde zu garantieren. 

An diesem Tag wurde der Projektabschlussbericht an Herrn Dietrich zur 

Bewertung übergeben. Die gesamte Gruppe konnte das Projekt dadurch 

abschließen. 

5 PROJEKTERGEBNIS 

5.1 Roboterwelt 

Der Roboter bewegt sich durch einen rechteckigen Raum mit senkrechten Wänden. Die genaue Breite und 

Länge des Raumes ist variabel. Nur die Wände müssen eine Mindesthöhe von circa 250 mm haben, damit der 

Roboter einwandfrei arbeiten kann. Die Art der Bodenfläche ist auch bis zu einem bestimmten Grad variabel. 

Durch die geländegängige Bereifung des Roboters kann dieser nicht nur auf glattem Untergrund arbeiten, 

sondern auch auf fein gewebten Teppichen. Der Programmcode setzt allerdings voraus, dass der Boden nicht 

Seite 22

esonders hell ist. Der Roboter startet in einer Ecke des Raumes und bewegt sich parallel zur Wand. Beim 

Berühren der gegenüberliegenden Wand dreht sich der Roboter um 180 Grad, um die nächste Bahn abzufahren. 

Mit den am Roboter installierten Schaufeln wird der im Weg liegende „Müll” also von der gesamten Bodenfläche 

des Raumes beseitigt. Am Ende der Fahrtstrecke befindet sich eine Markierung aus einem Aluminiumstreifen, 

der sich am Boden befindet. Der Aluminiumstreifen reflektiert das Licht des am Roboter installierten 

Lichtsensors. So kann der Roboter feststellen, wann er seine Aktion stoppen soll. 

5.2 Roboterkonstruktion 

Der Roboter wurde von Jakob und Jan von Grund auf neu gebaut und ohne eine vorgegebene Anleitung konstruiert. 

Der gesamte Aufbau sitzt auf den zwei NXT-Motoren, welche wiederum die Antriebsräder des Roboters 

antreiben. Die Antriebsräder liegen nicht flach auf dem Boden auf, sondern sind etwas abgerundet. Diese 

Eigenschaft eignet sich sehr gut für den Roboter, da die abgerundete Reifenform einen geringen Rollwiderstand 

garantiert. Für einen guten Gripp sorgt das tiefe Reifenprofil. Dies hat den Vorteil, dass der Untergrund, 

auf dem der Roboter eingesetzt wird, sehr variabel ist. 

Seite 23

Direkt über den Motoren befindet sich der NXT-Baustein, der senkrecht und mit dem Bildschirm nach vorne in 

das Gestell eingebaut ist. Diese Bauweise verhindert, dass der Roboter zu lang oder zu breit wird. Am Kopf 

des NXT-Bausteins befindet sich der höchste Punkt des Roboters. Hier misst er eine Höhe von 200mm. 

Um seine Aufgabe, nämlich Gegenstände einsammeln, erfüllen zu können, wurden am Roboter ganz vorne 

zwei Schaufeln eines LEGO-Radladers aus eigenen Beständen montiert. Die Schaufeln haben eine Gesamtbreite 

von 160mm und bilden die breiteste Stelle am Roboter. Mit ihnen werden die Gegenstände aufgesammelt 

und aufbewahrt. Leider ließ die Anzahl der Teile in den LEGO-Baukästen nicht zu, einen rotierenden 

Besen zu bauen, der die Teile, die sich vor dem Roboter befinden, in die Schaufeln kehrt. Daher wurde entschieden, 

dass in den Schaufeln Dauermagneten installiert werden, die dann metallene Teile aufsammeln. 

Diese haften sich an die Magneten. Der Roboter kann die Schaufeln mit Hilfe der Kraft des dritten NXT-Motors 

anheben und ablassen. Dieser Motor ist am Heck des Roboters installiert. Dafür, dass die Kraft des Motors 

vom Heck des Roboters bis zu seinem Bug kommt, sorgt ein ausgeklügeltes System. Eine Antriebswelle, die 

in der Mitte der Konstruktion sogar durch zwei Kardanwellen umgelenkt wird, treibt ein Zahnradsystem an, das 

wiederum die Kraft an eine Seilwinde weitergibt. Das Windenseil ist mit den Schaufeln verbunden. Die gute 

Übersetzung des Zahnradsystems sorgt dafür, dass die Schaufeln des Roboters selbst dann angehoben werden 

können, wenn diese schwer beladen sind. Bei einem Test erwies sich, dass so ein Gewicht von mindestens 

250 Gramm problemlos angehoben werden kann. Hierbei beantwortet sich auch die Frage, warum der 

Antriebsmotor für die Schaufeln am Heck des Roboters sitzt und deshalb eine solch komplizierte Kraftübertragung 

notwendig geworden ist. Der Motor dient nämlich hierbei als Gegengewicht für das eventuelle schwere 

Gewicht der Schaufeln. Um sich orientieren zu können, wurde an der Front des Roboters ein Berührungssensor 

installiert. Dadurch weiß der Roboter, wann er gegen eine Wand gefahren ist und deshalb eine Drehung 

um 180 Grad von Nöten ist. Der Berührungssensor wurde über den Roboterschaufeln installiert. An ihm ist 

eine Art Gabel installiert, damit der Sensor noch empfindlicher auf einen Kontakt reagieren kann. Außerdem 

sitzt der Sensor mit Gabel weit vor den Roboterschaufeln, damit diese beim Berühren der Wand nicht im Weg 

stehen. Die Gabel ist der vorderste Punkt des Roboters. Der hinterste Punkt ist der Antriebsmotor für das Anheben 

und Ablassen der Schaufeln. Daraus ergibt sich die Gesamtlänge des Roboters mit 350mm. 

Kurz vor dem Ende des Projekts wurde noch ein Lichtsensor am Roboter angebracht. Dieser befindet sich vor 

dem rechten Antriebsrad und hat einen ungefähren Abstand von 10mm zum Boden. Auch das Problem mit 

den meist überlangen Kabeln, die den NXT-Baustein mit den Motoren und den Sensoren verbinden, wurde 

einfach gelöst. Der größte Teil der Kabel wurde zwischen dem NXT-Baustein und dem Unterboden des Roboters 

verstaut. Die restlichen Kabel wurden entlang der Roboterkonstruktion befestigt. Dies hat zur Folge, dass 

es keine abstehenden und störenden Kabel gibt, die den Roboter bei seiner Arbeit behindern. 

Seite 24

Seite 25

5.3 Programmierung 

Die Grundidee für den Programmcode war schnell klar. Der Roboter sollte die gesamte Fläche des Raumes 

abfahren. Beim Berühren einer Wand mittels Berührungssensor sollte sich dieser drehen und die nächste 

Bahn abfahren. Dabei war es wichtig, dass der Roboter exakt geradeaus fährt, um nicht „auf die schiefe Bahn 

zu geraten”. Da sich Carsten und David ja zuvor mit dem Rotationssensor beschäftigt hatten, konnten sie die 

Funktion „OnFwdSync” verwenden. Hierbei wird der sogenannte Synchronisationsmodus aktiviert, der die 

Bewegungen der beiden Radantriebmotoren synchronisiert. Dadurch wird sichergestellt, dass der Roboter 

exakt geradeaus fährt. Diese Funktion wurde in einer Schleife eingebaut, die dann aktiviert ist, wenn der Berührungssensor 

an der Front des Roboters nicht anschlägt. 

Als nächstes wurde sich folgender Frage gewidmet: Was passiert, wenn der Berührungssensor des Roboters 

beim Berühren einer Wand anschlägt Die Herausforderung hierbei war, dass der Roboter nach jeder Wandberührung 

die Drehrichtung wechseln musste. Hier wurde klar, dass mit einer Variablen gearbeitet werden 

muss. Die Variable x wurde festgelegt. Beim Start des Programms gilt x=0. Es wurde festgelegt, dass sich der 

Roboter nach der ersten Wandberührung nach rechts dreht. Dies wurde in einer Schleife festgelegt, die nur 

dann aktiviert ist, wenn der Berührungssensor anschlägt und x=0 ist. Nach der ersten Drehung gilt x=1. In 

einer zweiten Schleife, die nur dann aktiviert ist, wenn der Berührungssensor anschlägt und x=1 ist, wird der 

Roboter angewiesen, sich nach links zu drehen. Am Ende dieser Schleife gilt wieder x=0. Daraus folgt, dass 

der Roboter nach jeder Berührung mit der Wand die Drehrichtung wechselt. 

Wenn der Roboter gegen die Wand fährt, gibt es einen genauen Ablaufplan, den der NXT-Baustein beachten 

muss. Zuerst fährt der Roboter ein Stück zurück, damit dieser bei seiner darauffolgenden Aktion ein freies 

Bewegungsfeld besitzt. Nach dem Rückwärtsfahren dreht sich der Roboter um exakt 90 Grad in die jeweilige 

Richtung. Dies geschieht mithilfe der Funktion „RotateMotor”, bei der man einen oder mehrere Motoren anweisen 

kann, sich in einem angegebenen Winkel zu drehen. Der genaue Wert konnte anhand des Radstandes 

und des Radradumfangs berechnet werden. Den genauen Rechenweg, der hier anzuwenden war, konnten wir 

bereits während der Durchführung der Versuchsreihen herausfinden (Siehe: 2.3. Versuch 3 – 90°-Drehung). 

Nach der ersten Drehung fährt der Roboter ein Stück geradeaus, um die nächste Fahrspur zu erreichen. Danach 

folgt wieder eine Drehung um 90 Grad in dieselbe Richtung wie zuvor. Schließlich hat sich der Roboter 

um 180 Grad gedreht und steht in der neuen Fahrspur. Nun kann er wieder die Fahrspur wie gewohnt abfahren. 

Der gesamte Vorgang, nämlich das Geradeausfahren und die Drehungen nach der Wandberührung, ist mit 

einer Schleife umschrieben, die nur dann aktiviert ist, wenn der am Roboter installierte Lichtsensor feststellt, 

dass der Lichtwert des vom Boden reflektierten Lichts kleiner oder gleich 50 ist. Dies bedeutet, dass sich der 

Seite 26

Roboter auf einem eher dunklen Untergrund befinden muss. Es gibt eine weitere Schleife, die aktiviert wird, 

wenn der Lichtwert größer als 50 beträgt. Wenn dies der Fall ist, dann weiß der Roboter, dass er seine Arbeit 

beenden kann. Daraufhin werden die Motoren der Antriebsräder gestoppt und die Räumschaufeln werden 

wieder angehoben. Damit ist die Arbeit des Roboters zu Ende. 

Der gesamte Vorgang ist mit einer Endlosschleife umschrieben, damit das Programm automatisch wiederholt 

wird. 

int x; //Festlegung' der Variable x. 

task main() 

{ 

//Definition der Variable x. 

x=0; 

//Festlegung des Berührungssensors auf Eingang I. 

SetSensorTouch (S1); 

//Festlegung des Lichtsensors auf Eingang 2. 

SetSensorLight (S2); 

//Räumschaufeln befinden sich bei 

//Programmstart noch im angehobenen Zustand 

// und werden hierbei abgelassen. 

RotateMotor (OUT_A, 90, 2000) ; 

Wait (1500); 

//Schleife wird nur dann aktiviert, wenn der 

//gemessene Lichtwert kleiner oder gleich 50 beträgt. 

while (SENSOR_2

} 

Wait(100); 

//Roboter dreht sich zum 2. Mal (rechts). 

RotateMotor (OUT_B, 75, 410); 

Wait (500); 

//Ab hier gilt x=l. Ab der nächsten Wandberührung wird die 

//untere Schleife aktiviert. 

x = x+1; 

} 

//Der Berührungssensor hat angeschlagen 

//und es gilt x=l. Also wird dieser if-Zweig aktiviert. 

else if (SENSOR_1==1 && x==1) 

{ 

//Roboter fährt kurz rückwärts. 

RotateMotor (OUT_BC, 75, -100); 

Wait (500); 

//Roboter dreht sich zum 1. Mal (links). 

//410 sind die 410°, berechnet aus der 90°- 

//Drehungsfunktion. 

RotateMotor (OUT_C, 75, 410); 

Wait (500) ; 

//Roboter fährt kurz geradeaus. 

RotateMotor (OUT_BC, 75, 100) ; 

Wait(100); 

//Roboter dreht sich zum 2. Mal (rechts). 

RotateMotor (OUT_C, 75, 410) ; 

Wait (500); 

//Ab hier gilt wieder x=O. Ab der nächsten Wandberührung wird 

//wieder der obere if-Zweig aktiviert. 

x = x-1; 

} 

//Schleife wird nur dann aktiviert, wenn der 

//gemessene Lichtwert größer als 50 beträgt. 

//Hierbei passiert der Roboter 

//den Aluminiumstreifen, wobei der Roboter 

//seine Arbeit beenden soli. 

while(SENSOR_2 > 50) 

{ 

//Die Radantriebsmotoren werden abgeschaltet. 

Off (OUT_BC); 

//Die Räumschaufeln werden wieder angehoben. 

RotateMotor (OUT_A, 90, -2000); 

Wait (2500); 

} 

} 

//Der Roboter hat seine Arbeit nun vollständig beendet. 

Seite 28

6 REFLEXION 

6.1 Reflexion der Problemstellung 

Bezogen auf die Konstruktion des Roboters bestand die Herausforderung zunächst darin, ein völlig neues 

Konzept für den Bau zu entwickeln. Hierbei male sich - keinem Bauplan oder sonstiger Aufzeichnung orientiert. 

Nachdem Jakob und Jan ein-Konzept nach den Anforderungen des Projektziels entwickelt hatten, mussten 

sie den Roboter bauen. Auch dies stellte sich als große Herausforderung dar. Besonders mussten sie 

immer wieder feststellen, dass die Stabilität ihrer Konstruktion einige Mängel aufwies, die sie daraufhin aufwändig 

beheben mussten. Der Grund dafür war, dass sie den Roboter besonders leicht bauen wollten und 

deshalb einige Teile einsparten. Im Nachhinein bewerten Jan und Jakob diese Idee als unvorteilhaft, da eine 

stabile Konstruktion Grundlage für ein effektives Arbeiten mit dem Roboter ist. Bezogen auf die Programmierung 

des Quellcodes war es eine besondere Herausforderung für Carsten und David, dass das Wissen, das 

sie für das Schreiben des Programmcodes benötigten, sehr vielfältig war. Sie mussten sich nicht nur über den 

Inhalt aller vergangenen Tutorials im Klaren sein, sondern auch noch weitere Informationsgewinnung betreiben. 

Sie stellten beim Schreiben des Programmcodes besonders fest, dass der Überblick über den gesamten 

Programmcode sehr schwierig wurde, je ausgereifter er wurde. Deshalb ist es unbedingt notwendig, am besten 

jede einzelne Funktion im Code zu kommentieren und zu beschriften. 

6.2 Reflexion des Projektmanagements und der Teamarbeit 

Die eigentliche Planung des Projekts verlief sehr gut. Am Anfang wurde einige Stunden lang in der gesamten 

Gruppe darüber gesprochen und diskutiert, welche Anforderungen das Projektziel an jede einzelne Person 

stellt. Der sehr gründliche Informationsaustausch zu Beginn des Projekts erwies sich während der Arbeit als 

sehr hilfreich, da durchgehend jedes Gruppenmitglied wusste, was es zu tun hatte. Die Aufteilung der Gruppe 

in zwei Hälften erwies sich ebenfalls als sehr nützlich. Auf diese Weise konnten sich die beiden Trupps, also 

die Programmierer und die Konstrukteure, genau auf ihren Teil der Arbeit konzentrieren. Dies garantierte ein 

sehr effektives Arbeiten an den einzelnen Arbeitsbereichen. Dies bestätige sich vor allem am Ende der Projektarbeit. 

Sowohl der Programmcode als auch die Roboterkonstruktion fanden bei allen Gruppenmitgliedern 

großen Zuspruch. Das wurde auch dadurch begründet, dass immer eine reibungslose Kommunikation zwischen 

den beiden Trupps schon ab dem Beginn der Projektarbeit im Vordergrund stand. Dadurch, dass immer 

eine rege Verbindung zwischen ihnen stand, wurde nicht getrennt, sondern immer zusammen dem gemeinsamen 

Projektziel entgegengearbeitet. 

Am Anfang jeder Stunde fand ein kleines Briefing innerhalb der gesamten Gruppe statt. Hier wurden die Aufgaben 

für die jeweiligen Unterrichtsstunden verteilt. Dadurch hatte jeder genau einen Plan, was er zu tun hat- 

Seite 29

te. Wenn die Aufgaben schon früher erledigt wurden, als veranschlagt worden war, wurden sofort neue Aufträge 

verteilt. Es blieb also keine Zeit ungenutzt. Auch dies garantierte die Effektivität der Arbeit der einzelnen 

Gruppenmitglieder. 

Besondere Leistungen erbrachte vor allem der Teamleiter und Protokollant David. Mit hoher Zuverlässigkeit 

schrieb er nach jeder Informatikstunde einen durchaus ausführlichen Tagesbericht. Hier konnte man die Tätigkeiten 

der Gruppe in jeder Stunde detailliert nachlesen und sich einen genauen Eindruck über ihre Arbeit machen. 

Außerdem verfasste David bereitwillig den kompletten Projektabschlussbericht. Auch hier investierte er 

viele Arbeitsstunden, um die Ergebnisse seiner Projektgruppe anschaulich, detailliert und überzeugend zu 

präsentieren. 

6.3 Reflexion des Projektziels 

Besonders im Vordergrund der Gruppe stand die Erfüllung des Minimalziels. Vor allem am Programmcode 

lässt sich erkennen, dass der Grundgedanke des Minimalziels erfüllt wurde. Allerdings reichte die gegebene 

Zeit nicht mehr aus, um das Maximalziel erfüllen bzw. teilweise erfüllen zu können. Eigentlich wurde veranschlagt, 

dass in dem gegebenen Zeitrahmen die Arbeit am Maximalziel zumindest begonnen werden konnte. 

Die gesamte Gruppe wurde allerdings von einigen Problemen belastet, deren Ausmaße sie vorher nicht erahnen 

konnten. 

Zum einen ist das Problem zu nennen, dass der Synchronisationsmodus am Roboter nie wirklich funktionierte. 

Obwohl der Code und die Konstruktion des Roboters korrekt waren, fuhr der Roboter nicht genau geradeaus. 

Anscheinend lag der Fehler hierbei in den NXT-Motoren oder in der Firmware, mit der der NXT-Baustein arbeitete. 

Die Korrektur des Problems überstieg allerdings unsere Fachkenntnisse. Auch Herr Dietrich konnte uns 

in diesem Punkt nicht viel weiterhelfen, weshalb der Fehler nach einiger Zeit ignoriert wurde. Allerdings wurde 

dadurch die Arbeit der Programmierer Carsten und David behindert. Um den Programmcode testen zu können, 

brauchten sie einen korrekt funktionierenden Roboter. Da dies aber nicht der Fall war, konnten sie oftmals 

ihren Quellcode nicht angemessen in der Praxis testen und konnten eine Fehlersuche und Fortsetzung 

des Programmcodes oft nur theoretisch durchführen, was einen hohen Aufwand im Gegensatz zum Praxistest 

bedeutete. 

Ein weiteres Problem während der Projektarbeit waren die Fehlfunktionen an den Laptops, die eine Grundlage 

für die Programmierung der Quellcodes waren. Es kam mehrmals vor, dass ein Computervirus aus dem 

Schulserver die Software des Laptops heimsuchte und diese lahmlegte. Oft zeigten die Computer auf Grund 

schwacher Hardware keinerlei Rückmeldung, sodass ein Neustart von Nöten war. Zudem waren praktisch in 

jeder Stunde die USB-Hübe des Laptops überlastet. Solche Probleme bereiteten viel Ärger und die Behebung 

Seite 30

enötigte insgesamt gesehen sehr viel Zeit, die die Gruppe mit der eigentlichen Arbeit am Projekt hätte verbringen 

können. 

Auch den Konstrukteuren Jakob und Jan widerfuhr im Laufe des Projekts ein Problem. Obwohl sie die LEGO- 

Teile äußerst sparsam verbauten, gingen ihnen diese mit der Zeit aus. Also wurde es notwendig, die Teile von 

anderen Gruppen, die oftmals ebenfalls einen Mangel an Teilen angaben, auszuleihen. Die Suche nach passenden 

Teilen war also oft erfolglos. Deshalb mussten immer wieder neue Konzepte ausgedacht werden, was 

ebenfalls einen großen Zeitaufwand bedeutete. 

Die gesamten Zeiteinbußen sind der Grund dafür, dass das Vorhaben, das Maximalziel wenigstens zu beginnen, 

nicht eingehalten werden konnte. 

Trotzdem war das Projekt ein voller Erfolg. Hierbei konnte man nicht nur sein Fachwissen um einiges erweitern. 

Auch brachte es viel Freude, wenn man einen der vielen kleinen Schritte auf dem Weg zum Projektziel 

überwunden hatte. Die Teilerfolge ermutigten immer wieder, mit der Arbeit mit noch mehr Engagement fortzufahren. 

Eine ebenfalls wichtige Erfahrung war es, eine Projektarbeit am Beispiel eines richtigen Projekts 

durchzuführen. Dabei lernte man, dass die Arbeit im Team gut funktionieren und eine gute Kommunikation 

vorhanden sein muss, damit das Ergebnis am Ende positiv ausfällt. 

Seite 31

7 ENTLASTUNG PROJEKTTEAM 

Datum, Unterschrift (Projektleiter) 

Datum, Unterschrift (Teammitglieder) 

Datum, Unterschrift (Projektauftraggeber) 

Seite 32

8 ANHÄNGE 

• Projektauftrag 

• Projektstrukturplan (PSP) 

• Projektablaufplan (PAP) 

• Sitzungsprotokolle 

• Arbeitsprotokolle der einzelnen Teammitglieder 

• Aktennotizen 

• weitere relevante Dokumente 

9 QUELLENVERZEICHNIS 

Seite 33

DES WPU-KURSES - Wernher von Braun Schule

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?