Der Snake-Robot ist ein kleiner, wendiger Roboter der in einer Arena selbstständig Kugeln einsammeln soll, die von einer Person in die Arena gelegt werden. „Isst“ der Roboter eine Kugel, verlängert sich sein, „Körper“, in unserem Fall über eine immer länger werdende Kette aus aufgesammelten Kugeln. Daher kommt auch sein Name: Der Roboter spielt autonom als Schlange das Handyspiel „Snake“(Link zum Spiel)! Erkennt er eine Kugel, fährt er auf sie zu und sammelt diese dann auf. Die Kugeln sind magnetisch und so entsteht ein wachsender Schlangenschwanz am Ende des Roboters. Der Mensch übernimmt dabei die Rolle des Handys, indem er wie es, die Kugeln auf dem Spielfeld platziert.

Grundlegend besteht unser Aufbau aus zwei Teilen, dem Fahrzeug und der Arena. Das Fahrzeug kann man darstellen als den „Schlangenkopf“, der die Kugeln einsammelt. Die Arena besteht aus einer Kamera, die an dem Laptop angeschlossen ist, und einem Stativ, an der diese befestigt ist. Diese bilden die „Augen“ und das „Gehirn“ des Roboters und stehen über Bluetooth mit dem Kopf in Verbindung.

Das Fahrzeug besteht aus einer Holzplatte, an der 2 Räder mit Schrittmotoren angebaut sind. Am Ende des Kopfes befindet sich ein Stabmagnet, der die magnetischen Kugeln einsammelt. Das dritte „Rad“ bilden 2 der magnetischen Kugeln, die schon vorab an den Magneten angeheftet sind, damit sich die Schlange wie gewünscht verlängert. Auf der Oberseite befindet sich ein Akku zur Stromversorgung der Schaltung, sowie darauf festgeklettet ein Breadboard/Steckbrett mit einem Arduino Nano und einem Bluetoothmodul zur Kommunikation (Die vollständige Schaltung ist in Abbildung 13 zu sehen).

Das alles ist von einer grauen Pappschachtel umgeben, auf der zwei farbige Punkte angebracht sind.

Abbildung 2: Ein Bild von unserem Snake Roboter ohne Pappegehäuse

Abbildung 3: Ein Bild von unserem Snake Roboter mit Pappegehäuse

Die Arena besteht aus einem Tisch, an dem ein von uns gebautes Stativ aus Holz mittig mithilfe von zwei Klemmen platziert ist. So befindet sich die am Stativ angebaute Kamera zentral über der Tischplatte, die dann als Spielfeld betrachtet wird. Die Kamera ist über ein USB-Kabel mit einem Laptop verbunden, der über Bluetooth mit dem Schlangenkopf kommuniziert.

Abbildung 4: Ein Bild von der Kamera und dem Stativ

Wir haben die Aufgaben in 3 Teilbereiche zerlegt:

• Mobilität: Der Schlangenkopf soll gezielt Punkte in der Arena ansteuern. Dem entsprechend muss er sich einheitlich vorwärts bewegen und sich drehen können.

• Bildverarbeitung: Die von der Kamera aufgenommenen Bilder müssen vom Laptop über Processing verarbeitet werden. Im Bild müssen die einzusammelnden Kugeln, sowie auch Position und Richtung des Roboters erkannt werden, damit der richtige Winkel und die richtige Entfernung ausgerechnet werden kann.

• Kommunikation: Die von der Bildverarbeitung ermittelten Daten müssen an den Arduino gesendet werden, damit der Roboter weiß, wie er sich zu bewegen hat. Danach muss der Arduino von der Bildverarbeitung neue Daten anfordern.

Bewusst ausgeklammert haben wir: Der Schlangenkopf selbst ist nicht in der Lage, die Arena zu erkennen und kann somit zum Beispiel nicht Tischkanten oder ähnlichen ausweichen. Das wird auch über die Bildverarbeitung gesteuert, da die Kamera nicht über die Tischkanten hinausblickt, können keine Daten übermittelt werden die dazu führen, dass der Roboter runterfällt.

Im Handyspiel ist die Schlange außerdem konstant in Bewegung. Unsere Schlange bleibt stehen, wenn sie gerade keine Kugel sieht, um die Bildverarbeitung zu erleichtern.

Nach einer kurzen Planungsphase haben wir schnell mit der Konstruktion des Roboters begonnen. Dazu mussten wir die Steppermotoren montieren, richtig an den Arduino anschließen, und den Stabmagneten am Ende des Roboters befestigen. Es hat sich außerdem bald herausgestellt, dass die von uns vorgesehenen Stützräder eigentlich nicht nötig sind, wenn erstmal einige Kugeln am Stabmagneten hängen. Auch der unten angebrachte Trichter zum Leiten der „aufgefressenen“ Kugeln, war nicht notwendig, weil die Magneten so stark sind, dass sie sich bereits bei mehreren Zentimetern Abstand anziehen.

Das Stativ besteht aus drei Holzbalken die über zwei Klemmen an der Tischplatte festgemacht sind. Über der Tischmitte wird dann die Kamera festgeklettet. Dadurch ist der Aufbau schnell, mobil und die Kamera kann leicht nachjustiert werden.

Am Anfang der Planung gingen wir davon aus, dass der einfachste Weg zur Kugelerkennung über Infrarotsensoren wäre, die in der Nähe der Tischoberfläche messen. Nach einer Reihe von Tests hat sich allerdings herausgestellt, dass die Infrarotsensoren die kleinen Magnetkugeln überhaupt nicht wahrnehmen. Das könnte an ihrer stark streuenden Oberfläche oder an der Tischplatte liegen. Denn die Sensoren müssten, um die Kugeln zu erkennen, sehr dicht zum Untergrund montiert sein und ist der Infrarotsensor nicht optimal senkrecht montiert, wird es zu mehreren Messfehlern kommen. Außerdem waren unsere Messwerte allgemein sehr inkonsistent, weshalb wir uns nach den Tests nach einer sicheren Lösung umgeschaut haben.

Unsere Wahl fiel am Ende auf eine Kamera, deren Bilder über Processing an einem Laptop verarbeitet werden. Das spart Speicherplatz auf dem Roboter und hat zusätzlich dafür gesorgt, dass wir uns weniger Gedanken um die Hardware machen mussten, als wir die Kamera erstmals ausgewählt hatten.

Damit werden dann nicht nur die Kugeln erkannt, sondern der Roboter steuert nun auch automatisch nur die Werte der Kugeln an, die auf dem Tisch liegen. Dadurch fällt das Problem mit der Tischkante weg.

Ziel der Bildverarbeitung ist es aus dem Kamerabild der Kamera, die über der Arena hängt, die Position der zu fressenden Kugel und die genaue Position des Roboters in der Arena zu ermitteln. Die genaue Position des Roboters kann man ermitteln indem man die Position des vorderen und hinteren Endes ermittelt. Der Einfachheit wegen haben wir festgelegt, dass alles was die Kamera erfasst die Arena ist, in der der Roboter fahren darf. Dadurch muss nämlich nicht erstmal noch erkannt werden, wo sich die Arena befindet im Bild befindet.

Die 3 Positionen werden aus einem einzigen Kamerabild ermittelt. Zugriff auf dieses Bild erhält man in Processing mithilfe der Video-Library und der Klasse „Capture“. Das Bild, das man dadurch erhält, ist ein 1-dimensionaler Array aus rgb-Farbwerten (https://de.wikipedia.org/wiki/RGB-Farbraum) mit (255,255,255) als reines Weiß. Um damit besser weiterarbeiten zu können, wandeln wir dieses Array erst einmal in einen intuitiveren 2-dimensionalen Array um, sodass man jedes Pixel im Bild durch dessen Koordinaten erreichen kann.

Die Ermittlung der Positionen aus dem Bild hätte man auf verschiedene Arten realisieren können. Wir haben uns zuerst angeguckt, welche Verarbeitungsmöglichkeiten die Bibliotheken zur Bildverarbeitung in Processing bieten. Dabei passte aber keine Verarbeitungsfunktion perfekt zu unseren konkreten Anwendungsfall. Deswegen haben wir, auch weil wir Lust darauf hatten, uns dafür entschieden das Bild ohne Verwendung von Bibliotheken zu analysieren.

Normalerweise geht es bei Bildverarbeitung um das Erkennen von Formen. Unser Problem lässt sich aber auch durch das reine Finden von Farben lösen, wenn man die Arena entsprechend anpasst. Der Einfachheit halber haben wir uns für letzteres entschieden.

Um die eindeutige Erkennung auf diese Weise zu ermöglichen, sind die gesuchten Dinge (zu fressende Kugel, vorderes Ende des Roboters, hinteres Ende des Roboters) mit einer Farbe markiert, die sonst nicht im Feld zu finden sind. Außerdem sollten sich die 3 Farben möglichst stark voneinander und von den Hintergrundfarben unterscheiden. Deshalb haben wir uns für rot, grün und blau für die 3 Dinge entschieden. In der Arena sollten deswegen bestenfalls sonst nur schwärzliche, gräuliche und weißliche Farben auftreten.

Zur farblichen Markierung der Kugeln (wir haben uns für rot entschieden) haben wir die spiegelnden silbernen Magnetkugeln zunächst nur mit einem roten Klebepunkt auf dem Nordpol versehen (man hätte dabei genau so gut den Südpol wählen können). Dadurch ist die rote Markierung, sobald die Magnetkugel aufgesammelt wurde(in einer Kette ist) nicht mehr zu sehen. Die Kugeln müssen dadurch natürlich mit der roten Markierung nach oben hingelegt werden. Wegen der glatten Oberfläche konnte man die Kugeln aber nicht einmal an einen Punkt hinlegen, ohne das sie weggerollt ist. Deswegen haben wir die Kugeln zusätzlich (unter der roten Markierung) mit weißem Klebeband umwickelt, welches die Oberfläche um einiges rauer macht und den positiven Nebeneffekt hat, dass die rote Markierung deutlich heller wird. (vgl. Video 1 und 2).

Abbildung 5: Foto der Futterkugeln

Das Finden einer gesuchten Farbe im Bild haben wir am Anfang mit folgendem Algorithmus realisiert:

Das Bild wird Pixel für Pixel (von oben nach unten und dann von links nach rechts) durchlaufen. Dabei wird jeweils geprüft, ob sich die Farbe des Pixels ausreichend mit der gesuchten Farbe ähnelt. Falls das der Fall ist, wird sich dieses Pixel (genauer: die Koordinaten des Pixels) als gefundener Punkt gemerkt. Wenn es mehrere Pixel im Bild gibt, dessen Farbe sich ausreichend mit der gesuchten ähnelt, so hat der Algorithmus als Ergebnis also immer den Pixel, den er als letztes überprüft hat. (der Pixel am weitesten rechts dann unten). Zwei Farben sind sich dabei ähnlich, wenn sich die jeweiligen rot,grün und blau- Werte einzeln nicht zu stark und auch insgesamt nicht zu stark von den Werten der gesuchten Farbe unterscheiden.

Die gesuchten Punkte haben dabei leider, wegen unterschiedlichen Lichtverhältnissen und helleren und dunkleren Stellen im Spielfeld, nicht überall und immer diesselbe Farbe. Dadurch ist es(vor allem bei schlechter und unregelmäßiger Beleuchtung) unmöglich, die zugelassenen Abweichungen passend zu wählen. Setzt man sie zu hoch, können Pixel, dessen Farbe eigentlich nicht ähnlich genug ist, als gesuchte Punkte erkannt werden (wenn sie sich weiter unten rechts im Bild befinden). Wählt man die Abweichung geringer, kommt es durch kleine Veränderungen, zum Beispiel in der Beleuchtung, sofort dazu, dass gar nichts erkannt wird.

Deswegen kamen wir auf die Idee einen Farbvergleich zu schreiben, der nicht nur liefert, ob sich zwei Farben ähneln oder nicht, sondern für zwei Farben einen Wert liefert, wie ähnlich sie sich sind. Dann kann man nämlich den Bildpunkt herausfinden, dessen Farbe am stärksten der gesuchten Farbe ähnelt. Da Farben im Computer als 3-dimensionale Vektoren (die die rgb-Werte enthalten) repräsentiert sind, bot sich der euklidische Abstand dieser Vektoren als Maß der Ähnlichkeit von den Farben an. Dabei gilt je kleiner der Abstand, desto ähnlicher die Farben. Das ist leicht zu berechnen und schien ansonsten auch gut geeignet für unseren Anwendungsfall, z.B. auch weil Unterschiede in blau,grün und rot Farbwerten quadratisch in den Abstand eingehen. Weicht zum Beispiel die eine Farbe um (20/20/20) und die andere um (0/0/60) von einer gesuchten Farbe ab, so ist der Abstand der ersten Farbe zur gesuchten Farbe deutlich kleiner, als der Abstand der zweiten Farbe zur gesuchten Farbe.

Algorithmisch wird ein gesuchter Punkt im Bild also jetzt wie folgt ermittelt:

Das Bild wird Pixel für Pixel (von oben nach unten und dann von links nach rechts) durchlaufen. Dabei wird jeweils der Abstand der Farbe des Pixels zu der gesuchten Farbe ermittelt. Ist dieser kleiner als der bisher kleinste, wird dieses Pixel als das bisher am besten passende gespeichert.

Abbildung 7: Skizze zur Positionserkennung

Die von der Bildverarbeitung ermittelten Pixel-Koordinaten sagen aus an welcher Stelle im Bild sich die 3 Dinge befinden. Diese Pixel-Koordinaten werden von uns erstmal durch Multiplikation mit einem Faktor in Positions-Koordinaten umgewandelt. Der Faktor ist dabei die Höhe und Breite des Feldes(in mm) in der Arena, das ein Pixel jeweils repräsentiert. Diese Positions-Koordinaten haben den Vorteil, dass Abstände der Koordinaten, den Abständen der jeweiligen Dinge in der Arena entsprechen.

Aus diesen Positions-Koordinaten kann dann eine geeignete Route berechnet werden. Dabei haben wir drei Arten von Routen in Betracht gezogen:

1. eine einzige Kurve (durch unterschiedlich schnelles Ansteuern der Servos)

2. rechtwinkliges Fahren im Stile von Snake (2x Drehung um 90 Grad und Geradeausfahren um bestimmte Distanz)

3. Drehung auf der Stelle um bestimmten Winkel, dann Geradeausfahren um bestimmte Distanz

Die erste Art von Route schien einerseits sehr schwierig zu berechnen und umzusetzen. Außerdem könnte es damit, aufgrund unseres rechtwinkligen Feldes, passieren, dass der Roboter zwischenzeitlich aus dem Feld rausfährt. Bei der Zweiten müsste man mehrere Fallunterscheidungen machen und mind. 3 Werte an den Roboter verschicken. Die Dritte Art von Route ist zum einen sehr einfach zu berechnen und zum anderen müssen nur 2 Werte, nämlich der zu drehende Winkel und die zu fahrende Distanz, an den Roboter kommuniziert werden.

Deswegen haben wir uns für die dritte Art entschieden.

Wie wir die Route der dritten Art aus den Positionen berechnen, kann man an folgender Skizze sehen:

Abbildung 9: Skizze zur Routenberechnung

Dass die Kommunikation zwischen Processing und Arduino reibungsfrei abläuft, war ein sehr wichtiges Thema in unserem Projekt. Es muss nämlich einen regelmäßigen Datenaustausch zwischen Laptop und Arduino geben, damit das „Gehirn“ dem „Schlangenkörper“ auch sagen kann, wo er hinfahren soll. Dafür kam eine Drahtlosverbindung oder eine Kabelverbindung in Frage.

Wir wollten uns die Möglichkeit offenhalten, dass der Roboter vielleicht auch mal größere Spielfelder abfahren kann, wofür eine Kabelverbindung unpraktisch wäre. Was ebenfalls gegen eine Kabelverbindung spricht, ist, dass der Roboter sich in dem Kabel verfangen könnte. Deswegen haben wir uns für eine drahtlose Datenübertragung per Bluethoot-Modul entschieden. Bluetooth-Module sind nämlich nicht teuer und auch in der Handhabung recht unkompliziert.

Vom Programmieren her benutzt man das Bluetooth-Modul als serielle Schnittstelle zwischen Processing und Arduino. Dazu steht auf beiden Seiten die Serial.h-Bibliothek bereit. Im folgenden Diagramm ist der Ablauf der Kommunikation noch einmal kurz dargestellt:

Abbildung 10: Grafik zum Kommunikationsablauf

Wie man erkennen kann, warten Processing und Arduino immer auf das Signal des jeweils anderen, bevor sie neue Messwerte verschicken oder verarbeiten. Das ist wichtig um zu verhindern, dass die beiden Programme aneinander „vorbeiarbeiten“. Es werden nur Daten verschickt, wenn der Kopf der Schlange auch bereit dazu ist, eine neue Kugel anzusteuern.

Wenn das Processing-Programm angehalten wird, muss man momentan die Bluetoothverbindung neu starten. Das ist zwar nicht kompliziert, aber während den Tests jedoch zeitraubend. Als Lösung gibt es eine „Pause“ Funktion: Klickt man in Processing auf den Bildschirm, hört Processing auf, Daten an den Arduino zu verschicken. Nachdem der Arduino die letzte Aktion zuende ausgeführt hat, bleibt der Kopf stehen, bis durch ein erneutes Klicken die Pause wieder unterbrochen wird und Processing wieder neue Daten verschickt.

Wir haben die Art der Bewegung zuerst einfach gewählt. Und zwar bewegt unser Roboter sich nicht genau wie im Spiel Snake rechtwinklig, sondern dreht sich zuerst um den entsprechenden Winkel in die Richtung des Futters und danach bewegt er sich um die notwendige Distanz nach vorne.

Es wurde für die Steppermotoren jeweils ein Treiber und die Bibliothek Stepper.h für das Programm Arduino verwendet. Zu Beginn versuchten wir die Funktionen turn() (Drehung um gewissen Winkel) und Move() (Geradeausfahren um bestimmte Länge) zu erstellen. Für die turn() Funktion haben wir am Anfang eine formale Lösung gesucht und haben uns da an den bereits erstellten Wiki-Eintrag zu dem Thema „Navigation nach Radumdrehungen“ orientiert (siehe Abb. 11).

Abbildung 11: vereinfachte Theorie zur formalen Drehung eines Roboters (Originalseite)

Nach ein paar Tests war klar, dass das nicht die hinreichende Lösung für das Problem war und es wurde zu den Rechnungen einen nach mehreren Messungen ermittelter Faktor drauf multipliziert. Die Funktion erwartet einen Winkel von 0° bis 360° und dreht sich ab 180° gegen den Uhrzeigersinn, damit der Roboter sich minimal dreht.

Ähnlich haben wir die Move() Funktion (Der Name „move“ wird in Arduino bereits verwendet) bearbeitet, die eine Distanz in Millimeter übergeben bekommt. Da wir zwei gleich große Räder, statt zwei unterschiedlich große Räder, benutzen, ist das Problem der Ansteuerung des Roboters deutlich einfacher.

Am Anfang der Projektplanung hatten wir verschiedene Ideen, wie das Aufsammeln der Kugeln und das Verlängern des Schlangenkörpers funktionieren soll. Das Magneten dafür hilfreich sein könnten, war uns relativ schnell klar, aber unsere ersten Gedanken waren meistens relativ kompliziert. Am Ende haben wir uns entschlossen, den Aufbau so einfach wie möglich zu halten.

Nach einigem Herumprobieren mit ein paar Neodym-Magnetkugeln und einem Stabmagneten haben wir herausgefunden, dass sich die Magnetkugeln dann wie von uns gewünscht aneinanderketten, wenn man die Magnetkugeln durch ein Stück Holz vom Stabmagneten fernhält. Je weniger man die Kette dabei in ihrer Bewegung einschränkt, desto besser, denn dann richten sich die Kugeln einfach wie gewünscht im schon bestehenden Magnetfeld aus. Diese Konstruktion war schnell umzusetzen und ist einfach gehalten.

Die Magneten sind relativ stark und auch die Elektromotoren der Stepper haben ein eigenes Magnetfeld. Dadurch wird ab und zu eine Kugel mal nicht optimal angehängt und es kommt zu Verklumpungen. Insgesamt besticht der Mechanismus allerdings durch seine Einfachheit und er ist auf jeden Fall zuverlässig genug. Bei komplexeren Aufsammel-Systemen würden wahrscheinlich mehr Probleme entstehen.

Der Snake-Roboter erfüllt unsere Ansprüche. Uns war es wichtig, am Ende der Arbeitszeit einen funktionierenden Roboter zu haben. Dazu haben wir uns zunächst realistische Ziele gesetzt, aber uns auch während des Lösens der Teilprobleme darauf konzentriert nichts unnötig kompliziert zu machen.

Eigentlich(!) kann der Roboter alles, was wir in unserer Planung als „Muss“ und „Soll“ formuliert haben. Der Roboter entspricht unserem Anspruch, relativ klein und wendig zu sein.

Die drahtlose Kommunikation lässt den Schlangenkopf ohne störende Kabel durch die Arena fahren. Manchmal hakt der Start der Verbindung allerdings etwas, weil die Bluetooth-Verbindung jedes mal neu hergestellt werden muss, wenn das Processing-Programm gestoppt wird. Als Lösung dafür haben wir den „Pause“ Knopf einprogrammiert, wodurch man das Processing-Programm selbst nur noch selten stoppen muss. Möglicherweise gibt es aber noch Verbesserungsmöglichkeiten für den Ablauf der Kommunikation insgesamt, in der das Problem überhaupt nicht mehr auftritt.

Die Fortbewegung des Roboters über die Steuerungsfunktionen turn() und Move() funktionierte eigentlich immer ohne Probleme. Kurz vor Abgabefrist haben wir aber, als wir festgestellt haben, dass die Stepper gefährlich heiß liefen, am Treiber die zu hohe Stromzufuhr verringert. Danach liefen sie zwar nicht mehr heiß, aber die Steuerungsfunktionen wurden leicht ungenau. Für neues experimentelles Ermitteln der zuvor unter der alten Stromzufuhr experimentell ermittelten Werte blieb aber leider keine Zeit.

Im Moment erkennt Processing meistens die von uns gesuchten farbigen Punkte.

Bei der Erkennung der Futterkugeln gibt es mittlerweile kaum noch Probleme. Nach einigem Rumprobieren haben wir durch das weiße und rote Klebeband nämlich eine gute Lösung gefunden. Der Nachteil dieser Lösung ist allerdings, dass die Schlange aus Kugeln durch das Klebeband noch unbeweglicher geworden ist und den Roboter jetzt manchmal beim Fahren stört.

Die Farbmarkierungen auf dem Roboter wurden eigentlich immer zuverlässig erkannt. In dem Versuch, die Genauigkeit der Positionsbestimmung zu erhöhen, haben wir aber leider kurz vor dem Abgabe-Termin die farblichen Markierungen verkleinert und mit Flüssigkleber befestigt. Dadurch sind die Markierungen zu dunkel geworden, um zuverlässig erkannt zu werden. Das Problem kann man aber, wenn man die geeignete Pappe hat (wir hatten sie leider weggeschmissen) sehr schnell wieder beheben.

Die Ähnlichkeit zum Handyspiel „Snake“ hatte für uns zwar keine besonders hohe Priorität, aber könnte auf jeden Fall verbessert werden. Dabei könnte man erstmal die Art der Fortbewegung des Schlangenkörpers ähnlicher machen, indem man die Futterkugeln rechtwinklig anfährt. Eine komplette Ähnlichkeit der Fortbewegung ist aber natürlich nicht möglich, weil die Schlange im Spiel nicht an physikalische Gesetzte gebunden ist.

Dieser Abschnitt beschäftigt mit Ideen, wie man den Roboter weiterentwickeln könnte.

Bevor man dem Roboter aber neue Funktionen hinzufügt, sollte man Bestehendes stabilisieren. Dabei hätten eine stabilere Konstruktion des Roboters und eine zuverlässigere Bildverarbeitung höchste Priorität. Das Problem, dass die Bluetooth-Verbindung in bestimmten Fällen verloren geht, sollte man allerdings auch angehen.

Für eine stabilere Konstruktion des Roboters, sollten vor allem die Stepper-Motoren möglichst fest und möglichst gerade befestigt werden, damit das Fahren möglichst genau ist.

Eine zuverlässigere Bildverarbeitung könnte man kurzfristig durch eine stärkere Beachtung von Schatten im Farbvergleich erreichen. Wenn man den Roboter auch farblich gestalten und für unterschiedlichste Umgebungen tauglich machen will, führt langfristig aber nichts an einer Formerkennung vorbei. Um den Roboter mobiler zu machen kann man den Laptop mit Kamera durch ein Smartphone ersetzen (Processing-Code müsste etwas angepasst werden). Dadurch kann auch einfach als zusätzliches Gadget, eine Fernsteuerung des Roboters, hinzugefügt werden.

Insgesamt sind wir zufrieden mit unseren Ergebnissen, mit dem Umfang des Projekts und mit unserer Zusammenarbeit. Wir haben gut als Team zusammengearbeitet, jeder hat sich eingebracht und hatte klare Aufgaben. Auch wenn unser Roboter nicht direkt ein Problem in der Welt löst, löst er die Aufgabe des Snake-Spielens nach unseren Regeln. Alles in allem haben wir bei der Konstruktion des Roboters und dem Programmieren seines Verhaltens, aber auch in der Planung dieses Projektes viel neues dazu gelernt.

Unser aktueller Code ist in folgendem Github-Repository zu finden:

https://github.com/Knilz/Snake-Robot/

oder hier als Zip-Datei zum herunterladen:

snake-robot.zip

Fragen zum Projekt immer gerne an: mark-bart[ät]web.de