1 Lucille

Das Bild spiegelt nicht die Last-Minute Änderungen wieder. Auch die Software unterliegt ständiger Anpassungen. Die gegenwärtige Spieltaktik ist möglichst den Ball so zu umrunden, bis das gegnerische Tor, der Ball und der Roboter auf Linie liegen. Anschliessend wird der Ball geradeaus ins Tor geschoben.

2 Hardware

Das Gerüst des Roboters wurde aus Lego gebaut. Das Antriebssystem besteht aus 4 Motoren, wobei 2 Stück jeweils ein Rad ansteuert. Als vordere Stütze dienen 2 6x1 Legosteine und als hintere Stütze leistet ein kleines rundliches Legobauteil Schwerstarbeit. Das Gehirn des Roboters ist das Aksen-Board von der FH-Brandenburg.

3 Software

Die Software ist in „C“ geschrieben und arbeitet Singlethreaded. Er enthält einige lowlevel Funktionalitäten wie Listen und einfaches Memorymanagement. Der komplette Source-Code kann hier bezogen werden.

3.1 Tipps und Probleme

Tipps und Tricks sowie Probleme auf die wir gestossen sind:

• Sensorschwankungen sorgen dafür, daß kurzzeitig falsche Annahmen getroffen werden. Sie sollten deshalb vor dem Start kalibriert werden. Folgende Ursachen haben wir entdeckt.
  • Stromversorgung läßt nach
  • Sich ständig veränderte Umgebung (Standortwechsel, Reflexionen ..)
  • Gegenseitiges blenden der Sensoren
• Exaktes geradeaus fahren ist sehr schwer
• Fahrgeschwindigkeit abhängig von der Stromversorgung (störend bei der Entwicklung von Taktiken).
• Vernünftige und feste Kräfteübersetzung der Motoren auf die Räder (Zahnräder fest ineinander greifen).
• Stabiles Robotergerüst (Roboter zerlegen sich gerne durch abrupte Richtungsanderungen).
• Leicht zugängliche Tragevorrichtung (setzt stabiles Ger“ust vorraus :) ).
• Kabellage gut verstecken, da Roboter tendenzen zum Gruppenkuscheln haben.
• Leicht einsehbare Stelle des Displays (Debugging)
• Leicht zugängliches Batteriefach (Wechsel kommt sehr oft vor)
• malloc/free (in standardlib) scheint nicht zu funktionieren. (Unser Source enthält ein paar eigene lowlevel Funktionalit“aten, mostly bugfree ;))

4 Devlog

Die Logs beginnen erst nach 1-2 Arbeitsterminen und hören vor Abschluß der Arbeit, wegen Zeitmangel ;), wieder auf. Da sie jedoch hilfreich sein können, will ich sie nicht auslassen.

4.1 Christan’s Devlog

Logbuch von Christian Stachow
19.09.05
Faulheit siegt. Kein Eintrag.

26.09.05 - 27.09.05

Design:

• Es ist vorteilhaft wenn man die Kabellage nummeriert und strukturiert verbindet, denn damit verhindert man das lästige Austesten der korrekten Verbindungen.

Stützrad:

• Ein 360^o drehbares Rad haben wir als zu nachteilig betrachtet. Wenn das Rad horizontal steht dann bockt es.
• Kleine Legoteile eignen sich ebenfalls nicht als Stütze. Der Reibungswiderstand ist zu hoch, liegt wahrscheinlich an der kleinen Auflagefläche.
• Zur Zeit nehmen wir das Standardverfahren, ein Tischtennisball.

Antrieb:

• Wir haben das bisherige Modell beibehalten und benutzen 2 Motoren für jeweils ein Rad.

Antriebsräder:

• Haben noch keine guten finden können, da die Übersetzung der Motoren auf die Räder noch nicht eingebaut wurde. Mal schauen was die Zeit bringt.
• Lennard kam auf die gute Idee die Räder auszustopfen analog beim Auto. Probleme bereiten das Füllmaterial, Papier aus dem WC, da es sich nicht heterogen verteilt und so Dellen entstanden sind. Wird noch ausgebessert.

Recherche:

• Nach einiger Recherche traf ich auf den Hinweis „Kräfte Übersetzung auf die Räder von 1 zu 125“. Nahezu Zeitgleich kam auch der Hinweis von Lennard per Email :) Bin gespannt wieviel Speed man darauf holen kann.
• Habe Videomaterial des letzten Robospiels in Brandenburg angeschaut. Die Roboter wurden da Zahlreich über den Haufen gefahren. Anscheinend ist hohe Geschwindigkeit „sehr“ wichtig sowie schnelles drehen, vorwärts fahren und scannen. Das Schiessen könnte vorteilhaft sein, da selbst ein Schuss ohne Tortreffer den Gegner verwirren kann.

30.09.05

Design:

• Das Lego-Design steht nahezu fertig. Es mussten heute nur ein paar Anpassungen vorgenommen werden weil wir neue Räder und mehrere Zahnräder verwenden. Das einzige was ausbleibt ist der Stauraum für die Kabelage. Vielleicht auch eine etwas bessere Befestigung für das Aksen-Board. Der Roboter kann sich sehr ruckartig bewegen.

Stützrad:

• Wir bleiben erstmal beim Lego-Teil als Stützrad. Es ist ca 2x1 Knöpfe groß und besitzt ein 1 Knopf breites Kreuzstück und ein 1 Knopf breite Kugel. Vorteil ist der Platzersparnis, aber der Reibungswiderstand scheint ein klein wenig größer als beim Tischtennisball zu sein.

Antriebsräder:

• Wir haben heute Zahnräder mit einem grösseren Durchmesser verwendet und dadurch Geschwindigkeitsgewinn ohne spürbaren Kraftverlust erlangt. Wir waren aber gezwungen größere Reifen zu verwenden da die Zahnräder ca genauso groß waren wie die alten Reifen und so auf unserem Filzboden schleifte. Wir nutzen zur Zeit 6 große Zahnräder, 4x1 für die Motoren und 2x1 für die Reifen. 2 Motoren treiben jeweils ein 1 Rad an. Es finden keine weiteren Übersetzungen statt.

Software:

• Wir haben begonnen Kollisionserkennung für Wände zu implementieren. Tückisch dabei sind die Sharp-Sensoren, die einen gewissen Mindestabstand zum Meßobjekt benötigen. Die seitlichen Sensoren sind zur Zeit noch nicht tief genug angebracht, aber die Messungenauigkeiten scheinen keine großen Probleme zu verursachen. Ein weiteres Problem der Sensoren sind die „Mess-Spikes“ und durchgehend sich ändernde Werte bei konstanter Entfernung. Es gab ein Gauß’sches Verfahren das solche Fehler ausbügeln konnte, aber ob sich die Recherche lohnt... Das numerische Mittelmaß scheint gut genug zu sein. Man kann auch ein Verfahren ähnlich der Pivot-Suche verwenden.
• Das Reaktive Verhalten des Roboters ist abhängig vom Timing oder von „sehr“ vielen Zuständen ;) Wenn er einmal erkannt hat, das vorne sowie seitlich kein Platz vorhanden ist, dann soll er gefälligs solange drehen bis er wieder freie Bahn hat und nicht bis er vorne plötzlich etwas mehr Platz entdeckt. Sofortige Reaktionen auf Sensorwerte sind deswegen vorsichtig auszuführen. Ob ein „Scheduling“ für Aufgaben sinnvoll ist ? Jede Aktion ist dann eine Aufgabe (Command-Pattern) die n-Zeit dauern kann, z.B. „Aus Ecke ausbrechen“ bedeutet sich 400ms nach links drehen und dann schaun ob vorne frei ist und es solange wiederholen bis es zu trifft. Danach erst endet die Aufgabe oder aber die Zeit dafür ist abgelaufen.
• Ob es ein derivat für „malloc“ und „free“ gibt ? Hab keine Lust ein eigenes Speichermanagement zu entwickeln :) Dies wird nötig fürs „Scheduling“.
• Bekomme beim kompilieren eine Warnung über „7 Bytes für Stack verfügbar“ oder so ähnlich. Habe probeweise fast alle lokalen Variablen global definiert, aber es änderte nichts daran. Potentielle Fehlerquelle !
• Kalibrierung der Sensoren ist wichtig. Die Werte ändern sich anscheinend je nach Batterieverbrauch, die Information ist aus dritter Hand.