Geradeaus laufen / Laufen im Labyrinth (NAO)

Aufgabe

Unsere primäre Aufgabe ist es den NAO Roboter zunächst einmal das geradeaus Laufen bei zu bringen. Auf lange Sicht ist es unser Ziel den NAO durch ein Labyrinth laufen zu lassen.

Planung

Etappen:

1. geradeaus laufen
2. um Ecken gehen
3. durch ein beliebiges Labyrinth gehen

Geradeaus laufen

Das grundlegende Problem bei diesem Punkt ist, dass der NAO von Natur aus nicht geradeaus geht, sondern immer in einem Bogen.

Unsere Lösung dieses Problems ist, dass wir das Sonar als Orientierungshilfe nutzen. Dabei wird jeweils der Abstand zu den Wänden verwendet um zu verhindern, dass der NAO diese umrennt.

Um auf das Sonar zu starten, kann man entweder die schon vordefinierte Version von Aldebaran verwenden oder muss sich selbst etwas "zusammenscripten".

Um auf das Sonar zugreifen zu können bzw. dieses zu starten, muss man folgenden Code verwenden:

        #starten des Sonars
        ip = "127.0.0.1"
        port = 9559

        sonarProxy = ALProxy("ALSonar", ip, port)
        sonarProxy.subscribe("MyApplication")

Um dann auf die Werte des Sonars zu zugreifen, verwendet man einen Proxy namens "ALMemory". Mit diesem kann man nun auf die 10 Werte, die das Sonar speichert, zugreifen.

        memoryProxy = ALProxy("ALMemory", ip, port)
        memoryProxy.getData("Device/SubDeviceList/US/Right/Sensor/Value")

Die Werte werden alle 0.1 Sekunden erneuert. Dabei ist zu beachten, dass nur der erste Wert brauchbar ist, da jeder weitere Wert Messfehler etc. enthält.

Sonar Spezifikation:

NAO V5

• Frequency: 40kHz

• Resolution: 1cm-4cm (depending on distance)

• Detection range: 0.20 m - 0.80 m

• Effective cone: 60°

Während der NAO sich vorwärts bewegt muss nun konstant überprüft werden, ob er zu nahe an einer Wand ist bzw. ob er sich verstärkt einer Wand annähert. Sollte er viel zu nahe an einer Wand sein, so muss er sich auf der Stelle drehen, so dass er sich darauf wieder von dieser Wand entfernt. Während der NAO nun weiter läuft werden die Sonar-Werte über die Differenz dieser verglichen. Sollte diese Differenz zu klein werden so soll der NAO zunächst über eine gewisse Strecke hin sich um 40° drehen und danach wiederum um 20° in die entgegengesetzte Richtung. Im folgenden ist unsere Realisierung über das Blueprint-System zu erkennen. Dabei hat jede Box Inputs und Outputs, wobei die Outputs mit den Inputs verbunden werden können. Dadurch können Signale bzw. Daten zwischen den einzelnen Boxen ausgetauscht werden und lösen dann die jeweilige Methode in der Box aus. Eine Box kann dabei auch weitere Unterboxen haben, welche dann weitere Operationen vornehmen.

Das Sonar in der äußersten Box kontrolliert wie oben bereits beschrieben, ob der NAO sich zu nah an einer Wand befindet. Ist dies der Fall so wird die Walk Box beendet und der NAO dreht sich auf der Stelle. Danach wird Sonar und Walk neu gestertet. Unsere Walking-Box besteht aus einer weiteren Box Sonar und zwei Move-To Boxen. Die Move-To (1) Box lässt den NAO vorwärts laufen. Wird eine Zahl zur Move-To Box gesendet so dreht der Nao sich noch zusätzlich um 40°, woraufhin er sich noch einmal um 20° in die andere Richtung dreht. All das geschieht beim Laufen. Dadurch wird an sich erst einmal verhindert, dass er zuschnell gegen eine Wand läuft.

Die Box Sonar besteht aus ein paar mehr Boxen. Dabei werden in SonarL und SonarR erst einmal Sonarwerte für 1s gesammelt und der Mittelwert gebildet. In Difference wird nun die Differenz der Mittelwerte gebildet. Ist die Differenz groß genug so wird ein Ping gesendet, ansonsten wird die Drehrichtung (Definiert durch -1 bzw. 1) weiter an die Cooldown Box gesendet. Ist der Cooldown gleich 0, so wird die Move-To Box in der Oberbox mit einer Zahl aktiviert, wodurch der NAO sich jetzt dreht.

Die Probleme die uns bei der Entwicklung dieser Methodik trafen, war der Wirkungsbereich des Sonars. Wir sind davon ausgegangen, dass sich die beiden Wirkungsbereiche der Sonare nicht überschneiden, sondern beide schräg vom NAO weggehen würden. Uns fiel dann nach einiger Zeit auf, dass der Wert des rechten Sonars während der NAO in seiner Startposition steht, einen Wert größer 0.8 besitzt. Dies kann man gut am folgenden Diagramm erkennen.

Das linke Sonar liefert brauchbare Werte, während die Werte des rechten Sonars unbrauchbar sind. Aus diesem Grund haben wir uns darauf geeinigt, dass falls der Wert größer als 0.8 ist, dass dieser auf 0.8 gesetzt wird. Dadurch kann man die Differenz der Mittelwerte besser verwenden.

Nachdem wir nun all das gemeistert haben, konnten wir uns zu unserer nächsten Aufgabe begeben.

Um Ecken gehen

Als erstes haben wir getestet, ob der NAO überhaupt Lücken in einer Wand erkennt, wenn er während des "geradeaus Laufens" an dieser vorbei läuft. Dabei erkannten wir, dass sich die Werte kaum veränderten, d.h. er würde an jeder Lücke einfach vorbei laufen, was zu einem Problem werden würde, wenn wir ein beliebiges Labyrinth aufbauen würden. Wir setzten uns zunächst das Ziel, dass der NAO erst einmal erkennen sollte, wenn er vor einer Wand steht, ob es sich um eine Sackgasse handelt oder ob er sich an einer Abzweigung befindet. Dazu beenden wir zunächst die "Geradeaus Laufen"-Operation und bildeten eine Box für diesen Fall. In dieser Box richtet der NAO sich zunächst an der Wand vor der er steht aus, sodass er sie orthogonal anschaut. Hierbei hatten wir zunächst ein paar Flüchtigkeitsfehler in unserem Python-Code, der dadurch entstanden ist, dass wir Python vor diesem Projekt kaum verwendet hatten. Nachdem wir dieses Problem beseitigt haben, richtet sich der NAO nun zwar an der Wand aus, aber es passiert ab und zu, dass er sich zu der Ecke hindreht und erkennt, dass der linke Sonar-Wert ungefähr dem rechten entspricht, was wir als Indiz für eine gute Ausrichtung verwendet haben. Würde der NAO sich nun um 90° drehen um zu Überprüfen, ob eine Wand auf der rechten bzw. auf der linken Seite vorhanden ist, so würde er noch Teile der Seiten Wand erkennen und dies so interpretieren, dass auf dieser Seite eine Wand steht. Um dies zu verhindern und kleinere Fehler von zu großen Drehungen zu vermeiden, legten wir einen kleineren Winkel für die Drehung fest.

Nach dem der NAO sich an der Wand ausgerichtet hat, testen wir rechts bzw. links, ob Wände vorhanden sind. Diese Prozedur kann man durch das folgende Struktogramm beschreiben.

Nachdem diese Etappe nun auch geschafft ist, können wir nun zu den ersten Tests in einem kleinen Labyrinth übergehen. Dabei ist zu beachten, dass bei Einmündungen kleinere Probleme auftreten können, nämlich dass der NAO durch das plötzliche verschwinden der Seiten Wand die gegenüberliegende Wand erkennt und somit manchmal die Wand umlaufen kann. Soweit funktioniert das Laufen innerhalb eines "Labyrinths", welches nur aus Abzweigungen, Sackgassen und einzelnen Einmündungen. Die Problematik, die sich bei Einmündungen noch auftut, ist, dass der NAO, wenn die Wege, die bei der Einmündung nach links und rechts führen, Sackgassen sind, nicht mehr von diesen beiden Wegen, außer durch Zufall, abkommt, da er jetzt zwischen den beiden Endpunkten hin und her pendelt. Dies tritt dadurch auf, dass wir den NAO bisher nur dafür ausgelegt haben, dass dieser nur abbiegt, wenn er vor einer Wand steht.

Übersicht Nao Programm

Zusammenfassend kann man das Verhalten des Naos mit dem folgenden Zustandsdiagramm beschreiben.

Dabei kann man die einzelnen Unterteilungen unseres Programms hier sehen.

• 

  Main Programm

• 

  Geradeaus gehen

• 

  Äußerste Boxen der Corner Box

• 

  Ausrichten an der Wand vor dem Nao, sodass er sie frontal anschaut

• 

  Testen, ob Wände neben ihm sind. Entlang gehen des ersten freien Wegs

Ausblicke

Als nächstes Ziel wäre es eine Möglichkeit zu finden, die es dem NAO ermöglicht Lücken in den Wänden zu finden und so weiter Abzweigungen abgehen zu können. Des Weiteren müsste man den NAO das Labyrinth noch kartographieren lassen, damit dieser nicht im Kreis läuft, sondern auch neue Wege finden lässt. Dies könnte man zum Beispiel dadurch realisieren, indem der NAO nach einer gewissen Distanz ein neues Stück des Weges zu seiner Karte hinzufügt. Dabei kann man diese Karte durch folgendes UML - Diagramm realisieren.

Um dann aus dem Labyrinth zu finden, kann man durch Überprüfen der bereits schon erstellten Felder testen, ob man im aktuellen Feld schon gewesen ist. Ist dies der Fall kann man anhand eines Algorithmus den schnellsten Weg zur letzten getätigten Abbiegung finden und den Weg dorthin gehen. Von dort an geht der NAO dann den nächsten Pfad bis er das Ziel, also den Ausgang, gefunden hat. Die Problematik, die sich bei einem beliebigen Labyrinth noch stellt, ist, dass die Sonare keinen Unterschied erkennen lassen, wenn der NAO an einer Wand mit einer Lücke vorbei laufen würde, d.h., dass dieser im Augenblick aus keiner Einmündung mit zwei Sackgassen hinaus käme, da er nur innerhalb der geraden Strecke bleiben würde und nur durch Zufall in die Lücke aus der Strecke käme. Dieses Problem könnte man durch eine zusätzliche Unterstützung durch die Kameras realisieren, da man durch die Verarbeitung der Bilder die Lücken viel besser erkennen kann, als durch das Sonar, welches hier nur nutzbar wäre, wenn man den NAO sich immer wieder zur Wand hindrehen lassen würde um zu prüfen, ob eine Lücke in der Wand vorhanden ist. Bei Letzterem würde sich aber wiederum durch schlechte Positionierung des NAOs das Problem auftun, dass er die Seitenwände erkennt und somit keine Lücke "entdecken" würde. Des Weiteren stellt sich noch die Herausforderung der Realisierung der Streckenabschnitte, welche in der "Map" gespeichert werden sollen, weil man noch einer gewissen Distanz erst einen neuen Abschnitt erstellen darf, d.h., dass man durch Ungenauigkeiten in der Bewegung zu viele Abschnitte und man so bestimmt Problemfälle wie das richtige Finden eines Weges hat.

Protokoll

25.01.2016

- Brainstorming

- Planung des Projekts

Probleme:

- Genauigkeit der Sensoren

- Abfrage der Sensoren

01.02.2016

- Testen der Sensoren und Herausfinden des Zugriffs auf die gemessenen Werte

- Abfrage und Kontrolle der Sensoren

15.02.2016

- Abfrage der Entfernung des Gegenstands und anschließende Differenzbildung

18.02.2016

-NAO läuft nun vorwärts und verarbeitet soweit die Sonarwerte. Sobald er bei der Verarbeitung auf einen kritischen Wert kommt, dreht er sich entsprechend und läuft weiter.

Das Problem dabei ist, dass sich der kritische Wert immer so ändert, dass er sich stets nach links dreht, wenn er vor einer Wand steht, und dann wieder nach rechts und so weiter und so fort.

Außerdem ist der Drehwinkel noch etwas zu groß und wenn er noch ansatzweise in der Mitte läuft, fängt er schon an sich zu drehen.

22.02.2016

- NAO läuft gerade aus und läuft meistens nicht gegen Wände

- Nächstes Ziel: NAO soll stehen bleiben, wenn eine Wand vor ihm ist und nicht gegen Wände laufen.

März 2016

- Nao bleibt vor einer Wand stehen -> nutzbar zum Abbiegen bei Ecken

- Zu Häufiges laufen gegen die Seitenwände, d.h. es muss eine besseres Abfangen gelingen, sodass der Nao die Wände umläuft.

-> rechtzeitiges Stoppen des Laufens, falls der Nao zu nahe an einer Wand ist

-> abändern der Drehwinkel um den Nao mehr in der Mitte zu halten

11.04.2016

Implementierung eines Algorithmus,...

...der den NAO daran hindert Wände umzulaufen. Misst er auf einer Seite eine Distanz von weniger als 0.4m so soll er auf der Stelle sich um ca. 40° drehen

...der den NAO beim Laufen in der "Mitte" hält, also sobald die Differenz der beiden Sonarwerte zu groß wird, geht er eine Strecke von 0.2m bei der er sich um 40° von der näheren Wand wegdreht, daraufhin läuft der diese Strecke erneut und dreht sich dabei um ein Drittel dieses Werts in die entgegengesetzte Richtung

14.04.2016

- NAO bleibt nun sehr gut innerhalb der Wände und stößt nur noch sehr selten einzelne Wände um

18.04.2016

Ziel: NAO soll um Ecken laufen bzw. Kreuzungen erkennen - Problem: NAO erkennt nicht, dass eine Lücke in der Wand ist und läuft daran vorbei -> bisherige Lösung: Kreuzung aus drei Schnittstellen, er läuft direkt auf eine Wand zu, testet, ob recht eine Wand ist; wenn ja wird die linke Seite getestet, ist dort auch eine Wand geht er in die Richtung, aus der er kam, zurück.

21.04.2016

- NAO läuft nun auch um Ecken

Problem: -er könnte aus Versehen denselben Weg zurück laufen, aus dem er kam, obwohl es sich nicht um eine Sackgasse handelt

-wenn er durch eine Drehung zu dem Eckpunkt zweier Wände gerichtet ist, erkennt er dies nicht richtig und läuft diese um

-da der NAO bei einer Distanz von ungefähr 0.4m stehen bleibt, steht er nicht in der Mitte des nächsten Ganges

Lösungsansatz:

-der NAO stellt sich zunächst so zur Wand, auf die er zuerst zugelaufen ist, sodass er annäherungsweise orthogonal zu ihr gerichtet ist

-durch einen etwas kleineren Drehwinkel wird dafür gesorgt, dass er ungefähr in die Mitte der Wandlücke schaut, d.h. er rennt keine Ecken mehr um

-durch kurzzeitiges rückwärts laufen steht er ungefähr in der Mitte