Viele, kleine Verbesserungen

Dieses Wochenende haben wir genutzt, um unser Programm mal etwas aufzuräumen und generell die Programmteile etwas zusammenzufügen. Im laufe der Zeit haben wir immer mal ein paar kleinere Teile z.B. von der Rampenerkennung oder dem Algorithmus zum Wiedereinsetzen eingebaut, was wir am Wochenende nun zu einem ganzen Teil zusammengeflickt haben. Hier eine kleine Liste, was genau wir verändert haben:

  1. Struktur (C-/Headerdateien): Unser Programm ist, wie es sich für jedes große Projekt gehört, in zahlreiche, einzelne Dateien aufgespalten, jede Datei für eine bestimmte Aufgabe (je nachdem, wie komplex die Aufgabe ist). Wir haben für die Zeilenkamera eine eigene Datei, für den Labyrinthlösealgorithmus und die Kartenzeichnung eine, für das Display mehrere etc. Diese Dateien sind miteinander verknüpft, sie bauen aufeinander auf (jede Datei hat noch eine eigene „Interface”-Datei, in der steht, auf welche Variablen und Unterprogramme andere Dateien zugreifen können). Da wir sowas zum ersten Mal machen und wir keine richtige IDE, die das normalerweise übernimmt, sondern einen Texteditor mit Syntaxhighlighting nutzen, war das Ganze nicht von Anfang an 100%ig sauber, was auch dazu geführt hat, dass wir Standard-C-Bibliotheken nicht richtig einbinden konnten, was wiederum zu wilden, nicht nachvollziehbaren Fehlermeldung beim Kompilieren geführt hat, weshalb wir das Ganze deshalb etwas aufgeräumt haben. Nun funktioniert das Einbinden von beliebigen Bibliotheken wieder 100%ig.
  2. Datenstrukturen: Wir haben die Übersichtlichkeit bzw. die Verständlichkeit weiter verbessert, indem wir einige neue Datenstrukturen eingeführt haben. Besonders, wenn es von einigen Dingen mehrere im Roboter gibt mit gleichen Eigenschaften, zum beispiel die Motoren oder die Temperatursensoren, ist das sinnvoll. Zuvor hatten wir Variablen die z.B. speed_l oder enc_r hießen. Zusammengefasst haben wir das Ganze mit Variablen, die nun mot.l.speed.to (Sollgeschwindigkeit des linken Motors) oder mot.r.enc (Encoder des linken Motors) heißen.
  3. Pointer: Pointer sind für uns recht neu, wir nutzen sie in unserem RoboCup Projekt bewusst erst seit Beginn dieser Saison. Durch der Nutzung von Pointern konnten wir die Dauer eines Hauptschleifendurchlaufs um 5 ms verbessern und liegen nun bei 16 – 18ms.
  4. Algorithmus zum Wiedereinsetzen: Algorithmus kann man das vielleicht nicht ganz nennen, aber gewissermaßen ist es das schon: Angenommen, der Roboter verfährt sich, weil er irgendwo hängenbleibt und die Karte stimmt nicht mehr. Damit die Karte nicht völlig zerstört wird, kann man für einen Punktabzug bei einem Wertungslauf eingreifen und den Roboter an eine neue Position setzen (alternativ würden wir ihn einfach machen lassen, er fährt dann mehr oder weniger zufällig umher und kann noch Opfer finden und startet irgendwann neu, muss man dann abwägen, was innvoller ist), die neue Position darf ihn dabei mitgeteilt werden. Problem ist dann nur der recht „dumme“ Algorithmus, den der Roboter zum Lösen des Labyrinths nutzt, der auf Markierungen in der Karte basiert. Damit der Roboter sich nach einem Eingriff nicht nur an einer neuen Position befindet, sondern auch an der Stelle mit dem Erkunden des Labyrinth weitermacht, müssen die Markierungen bis zu dem Zeitpunkt bzw. der Stelle rückgängig gemacht werden bzw. die danach ignoriert werden. Dazu speichert der Roboter einfach auf jeder Fliese eine fortlaufende Nummer, wenn die Position geändert wird, wird automatisch die Nummer auf der Fliese übernommen und alle Markierungen, die sich auf Fliesen mit einer höheren Zahl befinden, ignoriert. Theoretisch funktioniert das, praktisch muss das noch intensiv am Testparcours in verschiedenen Situationen getestet werden.
  5. Rampe: Dazu können wir noch nicht so viel sagen. Die Rampe soll sich dieses mal an jeder beliebigen Stelle befinden können (letztes Jahr haben wir die Rampe einfach anhand der Position des Roboters erkannt, was den Roboter besonders nach einem Neustart sehr unflexibel macht). Das Einzeichnen und Bewältigen der Rampe funktioniert auch, wenn der Roboter in der unteren Ebene des Parcours gestartet wird, allerdings noch nicht, wenn er oben gestartet wird (also als erstes eine Rampe nach unten gefahren werden muss und nicht nach oben; das ist wichtig, wenn der Roboter in der oberen Hälfte des Parcours neustarten sollte). Das werden wir auch weiter am großen Testparcours testen.
  6. Und wieder einmal haben wir die Fahrfunktionen des Roboters verbessert. Bei der Geradeausfahrt von einer Fliese wird nun, wenn sich unmittelbar hinter dem Roboter eine Wand befindet sich erst von der Entfernung her diese angepasst, genau so, wenn sich unmittelbar vor dem Roboter eine findet (dann entsprechend, nachdem bereits eine Fliese gefahren wurde). Das ist wichtig, damit Ungenauigkeiten, die beim Drehen des Roboters auf der Stelle aufgetreten sind ausgebessert werden.

Soweit, so gut. Morgen wird getestet, mal sehen, wie es aussieht.