RoboCup German Open Magdeburg Tag 3

So, heute war ein sehr erfolgreicher Tag. Heute morgen haben wir zuerst den Roboter ausführlich getestet: Es gab kein einziges Problem. Im ersten Wertungslauf haben wir uns dann allerdings mit den Lichtsensoren wieder in einem Speed Bump verfangen, was einen Eingriff zu Folge hat, sonst hat alles recht gut geklappt. Danach haben wir dann die Lichtsensoren anders positioniert. Nun können wir die meisten Speed Bumps gut und zuverlässig überfahren, im zweiten Lauf ist der Roboter allerdings trotzdem an einem Bump hängen geblieben, wir sind zeitlich nur ganz knapp ausgekommen, haben aber alle sechs Opfer erkannt.

In der Gesamtwertung der Vorrunden (2 besten von 4 Läufe) sind wir nun auf dem 2. Platz, allerdings sind der dritte und der vierte Platz nur wenige Punkte von uns entfernt. Das Finale morgen um voraussichtlich 12:40 wird also seeehr spannend, wir denken aber, dass mit etwas Glück alles klappt. So sieht unser Roboter übrigens momentan aus:

Für unser Plakat haben wir übrigens die volle Punktzahl bekommen, das wird aber wahrscheinlich nicht viel zur Sache tun.

 

 

 

 

 

 

Hier nun die versprochenen Fotos der anderen Ligen:

RoboCup German Open Magdeburg Tag 1+2

So, wie versprochen hier der Artikel:
Gestern sind wir pünktlich in Magdeburg angekommen. Zuerst haben wir bei einer allseits bekannten Fastfoodkette Mittag gegessen. Danach ging es dann sofort zum Messegelände, wir waren so ziemlich die ersten.

Dort haben wir uns dann erstmal einen kleinen Überblick verschafft: Echt riesig da. Für uns aber das reinste Paradies: Roboter, so weit das Auge reicht. 😀 Morgen gibt es dann noch ein paar mehr Fotos von den einzelnen Ligen (Soccer und Rescue).
Jedenfalls haben wir dann erstmal den Roboter getestet. Das sah erst ganz gut aus, wir haben immer weiter perfektioniert.
Noch zu Hause haben wir übrigens noch einen weiteren Sensor hinzugefügt, da es sonst Probleme beim Ausweichen der Sackgassen gab:

Heute hatten wir dann 2/5 Läufe:  Der erste verlief ok (YouTube Video folgt in Kürze). Wir haben sechs mal ein Opfer erkannt, davon zwei Fehlerkennungen, also insgesamt vier Opfer richtig erkannt (Für ein erkanntes Opfer gibt es 20 Zusatzpunkte, für eine Fehlerkennung werden 5 Punkte abgezogen). Außerdem haben wir auf Grund eines schief festgeklebten Speed Bumps einen Eingriff kassiert. Sonst können wir aber recht zufrieden sein. Es gibt ein Team, das definitiv besser ist, als wir. Die anderen (vielleicht 30%) sind ähnlich gut, der Rest ist schlechter. nebenbei ein Bild der hier verwendetetn Rescue Arena: Es gibt keine obere Ebene. Das ist eigentlich ganz gut.
Zwischen dem ersten und den zweiten Lauf haben wir dann eine Opfer-Fehlerkennung-Erkennung programmiert. Manchmal heizen die Opfer durch die Wand durch, es wird auf der gegenüberliegenden Seite des eigentlichen Opfers also ein Opfer erkannt. Das Problem konnte größtenteils durch eine simple if-Abfrage geregelt werden. Danach haben wir versucht, unsere Rampenerkennung zu verbessern: Wir berechnen nun den Durchschnittswert des Beschleunigungssensors über ein paar Messungen. Die Rampe lässt sich nun (bis jetzt) mit einer 100%igen Wahrscheinlichkeit erkennen. Das hat folgenden Sinn: Sobald wir oben an der Rampe angekommen sind, ist der Lauf beendet, wir haben also keine Chance, die Opfer zu finden, die wir bis dahin noch nicht gefunden haben. Wenn wir die Rampe erstmal erkannt haben, können wir noch auf der Rampe drehen, das Labyrinth in die andere Richtung durchfahren und so die restlichen Opfer identifizieren. Das bringt uns natürlich nur weiter, wenn wir möglichst wenig Fehlerkennungen haben. Aber wir sehen positiv auf die kommenden Läufe. 😀 Somit hat sich übrigens auch das Auswählen, ob wir links herum oder rechts herum das Labyrinth lösen, erledigt.

Hier noch der Plan,nach dem die Wertungsläufe stattfinden. Wir sind Startnummer 1.

Hier noch eine kurze Info zur Gesamtwertung:

Alles Teams im Rescue haben in der Vorrunde […] vier […] Läufe. Der schlechteste Lauf wird gestrichen. Am Finaltag führen die Teams dann noch einen Lauf durch. Für diesen Finaltag qualifizieren sich ca. 2/3 aller Teams.

Entscheidend für das Endergebnis ist die Summe aus dem Ergebnis des besten Vorrundelaufs und dem Resultat des Finallaufs. Das bedeutet, dass für ein optimales Endresultat in der Vorrunde ein Superlauf und dann im Finale ein toller Lauf gelingen muss.

 

Morgen Abend beim sogenannten Social Event werden dann erste Ergebnisse verkündet. Wind gespannt! Natürlich versuchen wir weiterhin, Euch via Twitter über aktuelle Dinge zu informieren. 😉

Perfektionierung des Wallfollowers

Nachdem wir am Wochenende noch einen (also den vierten) Infrarotentfernungssensor an den Roboter gebaut haben, hatten wir gestern die Gelegenheit, am Testparcours in der Schule den Roboter ausführlich zu testen. Die letzten Fehler wurden behoben und Feineinstellungen getroffen. Der Roboter funktioniert nun nahezu perfekt (bis auf ausnahmen, aber es muss in der Programmierung ja ein Mittelwert gefunden werden, damit alles halbwegs funktioniert – sonst würde eine Situation perfekt funktionieren und die andere gar nicht). Naja, wir denken , dass wir nun ausgezeichnet vorbereitet sind. Nur im unmöglichsten Fall (und der kann eintreten, wie in Hannover gesehen 😀 )  kann etwas schief laufen (besonders an den Sackgassen…). Aber wir sehen positiv in Richtung Magdeburg!
Donnerstag geht es dann los: um 07:45 müssen wir in Osnabrück am HBF sein. Mittags werden wir dann in Magdeburg ankommen und diŕekt zum Messegelände fahren, um die Roboter nochmal testen zu können. Der eigentliche Wettbewerb ist dann von Freitag bis Sonntag. Tagsüber werden wir twittern, dann wahrscheinlich noch jeden Abend eine Kurzzusammenfassung des jeweiligen Tages auf dem Blog schreiben.

Was uns aufgefallen ist – soweit wir wissen, sind wir das einzige Team, das einen Blog hat und das auch alle möglichen Infos über den Roboter ins Internet stellt. Schade… Falls es da draußen doch noch andere Teams gibt, schreibt gerne einen Link in die Kommentare!

Dritter Entfernungssensor für Wallfollower

Heute war der letzte Schultag vor den Ferien, nächste Woche Donnerstag geht es los nach Magdeburg. Wir sind alle aufgeregt! 😀

Eigentlich gibt es dafür aber keinen Grund. Wir haben jetzt einen dritten IR Entfernungssensor zu unserem Roboter hinzugefügt, der die linke Wand überwacht. Wir können jetzt ganz einfach im Setup Menü des Roboters einstellen, ob der Roboter der linken oder der rechten Wand folgen soll (Das hat folgenden Hintergrund: Der kürzeste Weg ist normalerweise immer, der rechten Wand zu folgen. Dabei kommt der Roboter natürlich nicht in alle Ecken des Labyrinths, das ist aber eigentlich die Kernaufgabe (also die Opfer zu finden). Manchmal sind die Opfer eben so angeordnet, dass man die meisten nur finden kann, wenn man der rechten Wand oder der linken Wand folgt. Das können wir dann wie gesagt vor dem Wettbewerb ganz einfach im Parcours einstellen.).
Hier ein Foto des (wahrscheinlich) endgültigen und aktuellen Roboters, mit dem wir auch in Magdeburg antreten werden:

Jetzt müssen wir also nur noch Feinheiten einstellen. Den Watchdog werden wir vorerst nicht implementieren, das Risiko, dass danach alles schief läuft, ist zu hoch (wir haben nicht mehr genug Zeit zum ausführlichen Testen). Wahrscheinlich bauen wir auch noch einen Schieber für Zahnstocher, da müssen wir aber auch nochmal gucken, wie wir das zeitlich hinkriegen.

Rampenerkennung und Benutzeroberfläche

Auch dieses Wochenende waren wir nicht untätig. Wir haben zwei wichtige Dinge an unserem Roboter geändert, und zwar haben wir eine vernünftige Rampenerkennung und eine Benutzeroberfläche zum Einstellen diverser Sensorwerte direkt am Roboter hinzugefügt.

Bis jetzt haben wir die Rampe mit einem Beschleunigungssensor erkannt (zumindest haben wir das versucht). Problem war, dass der Beschleunigungssensor eben Beschleunigungen misst (wenn man den Sensor neigt, werden diese Werte nur verfälscht, weshalb man ihn auch als Neigungssensor benutzen kann, allerdings nur, wenn das Objekt still steht). Da unser Roboter aber auch beschleunigt (wenn er also schneller wird), kommen bei eben diesen Beschleunigungen am Beschleunigungssensor die selben Werte raus, als wenn der Roboter auf der Rampe steht.
Letzten Montag haben wir uns dann in der großen Firma getroffen, um zu besprechen, wie man diese (und auch andere Probleme, dazu gleich mehr) lösen kann und wir sind zu dem Ergebnis gekommen, dass man einfach die Höhe unter dem Roboter messen kann und so die Rampe erkennen könnte, da die Rampe ja höher ist, als der normale Boden unter dem Roboter. Jedenfalls misst ein weiterer Sharp Infrarotentfernungssensor jetzt vorne am Roboter die Bodenhöhe, so können wir jetzt sehr zuverlässig die Rampe erkennen. Hier ein Foto:

Und hier eine Gesamtansicht unseres aktuellen Roboters:

Auf der neuen Benutzeroberfläche können wir die wichtigsten Werte (Schwellwert Temperatursensor links, Temperatursensor rechts, Rampensensor, Lichtsensor links, Lichtsensor rechts) einstellen. Für die Benutzeroberfläche haben wir uns entschieden, um Zeit vor einem Wettkampf zu sparen und da so eine Benutzeroberfläche zuverlässiger ist, als irgendwelche Werte am Computer ins Programm zu schreiben und dieses dann zu übertragen. Jetzt sieht man am Roboter selbst dann genau den Wert, den man gerade zum jeweiligen Sensor einstellt. Die Werte werden dann in ein EEPROM übertragen, sodass die Werte auch bestehen bleiben, wenn man den Roboter ausschaltet. Im Programm am Computer kann man schnell in einer Zeile verrutschen und so den falschen Wert einstellen, besonders wenn man nervös ist. Hier ein paar Fotos:



Probleme, die es jetzt noch zu lösen gilt, sind:

  1. Die Fehlerkennung von Wänden während des Lösens des Labyrinths (anscheinend ist der Infrarotentfernungssensor defekt)
  2. Es kann vorkommen, dass Zahnstocher als Hindernis im Labyrinth liegen. Wenn sich diese in der Kette unseres Roboters verfangen, ist der Lauf im Prinzip gescheitert, da unser Roboter sich dann ausschaltet (was auch gut so ist, da sich sonst das Getriebe zerstören würde). Wir müssen also irgendwie einen Schieber bauen, der die Zahnstocher weg schiebt
  3. Manchmal stürzt der Roboter ab, wenn er oft hintereinander die Fahrtrichtung ändern muss, da die Motoren dann sehr viel Strom ziehen, was den Mikrocontroller dann zum Absturz bring. Wir werden einen sogenannten Watchdog einprogrammieren: Der Roboter muss vom Hauptprogramm ständig eine Variable aktualisieren, wenn das nicht passiert (wenn der Roboter eben abstützt), wird ein Neustart durchgeführt.

Das sind aber Kleinigkeiten, die wir sicherlich bis zu den German Open, die vom 30. März bis zum 01. April in Magdeburg stattfindet,  lösen können.

Es läuft!

Fortschritte! Endlich! Nach einigen Problemen mit den Wärmesensoren können wir diese nun super auslesen und auswerten. Das war schon eine komische Sache… Die RP6 I2C Library war nicht kompatibel mit den Sensoren, was auch daran liegt, dass die Library interruptbasiert und dementsprechend sehr komplex und schwer zu verstehen ist. Mit Hilfe von roboternetz.de konnten wir die Library dann abändern, dass wir die Sensoren auslesen konnten, allerdings gab es dann Probleme mit der Fortbewegung des Roboters, teilweise hat sich das Programm auch aufgehangen, wenn die Sensoren ausgelesen wurden und der Roboter sich gleichzeitig um die Fortbewegung kümmern musste. Nach einigem Hin und Her und nachdem wir schon sehr viel Zeit in die Sache gesteckt haben, haben wir uns dafür entschieden, eine ganz andere I2C Library zu benutzen, mit der letztendlich auch alles klappt. Hier ein aktuelles Foto von unserem Roboter:

Außerdem haben wir schon ein paar Probleme in unserem Wallfollower Algorithmus entdeckt, wir müssen sie nur noch beheben. Das ist aber schnell erledigt.