Roboter-AG am Gymnasium Damme

Schon lange kein Artikel mehr – das hat auch seine Gründe. Eine Reise zur WM nach Mexiko will schließlich vorbereitet sein – und die Vorbereitung hat es in sich. Besonders die Sponsorensuche. Momentan haben wir allerdings schon (auch dank unserer Lehrer und unserer Eltern) ca. 70% des nötigen Betrages zusammen, wir sehen also positiv in Richtung WM, die letzten 30% schaffen wir locker.

Vorbereitet werden muss natürlich auch der Roboter. Am Roboter machen wir momentan nur Firmware Updates (das hört sich voll cool an ). Wir sind dabei, eine Lack of Progress Erkennung und eine Temperatur/Entfernungs Kompensation zu programmieren. Für die Lack of Progress Erkennung wird ein Entfernungssensor über einen längeren Zeitraum abgefragt, wenn sich der Wert dabei nicht ändert, muss der Roboter hängen geblieben sein. Dazu haben wir uns allerdings einen digitalen Sensor angeschafft, da das Rauschen beim analogen Sharp Sensor einfach zu stark ist.
Damit die Temperatur/Entfernungskompensation für die Opfer vernünftig funktioniert, brauchen wir Temperatursensoren mit einem geringeren Öffnungswinkel (momentan 90°, bald 35°). Problem ist, dass der Roboter bei großer ENtfernung zum Opfer sowohl auf der Rückseite als auch auf der Vorderseite aufgrund der großen Öffnungswinkels und des dadurch durchschnittlich berechneten Temperaturwerts kein Temperaturunterschied bei gleicher Entfernung auf Vorder- und Rückseite eines Opfers feststellen lässt. Unsere Gleichung funktioniert bei geringen Entfernungen aber 1A – Dadurch sind wir einen riesen Schritt weiter.
Außerdem programmieren wir unser Programm da wo möglich auf State Machines um, da ein Schleifendurchlauf ansonsten ca. 200ms benötigen würde (dank den State Machines nun 5ms). Unsere Hauptschleife hat mittlerweile allerdings auch schon unglaubliche 1000 Zeilen Code…

Fotos des aktuellen Roboters folgen.

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…).

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.