Projektdokumentation NIBObee 4 ever

Transkript

1 Projektdokumentation NIBObee 4 ever Stiegler Philipp Höchtl Bernhard (IC09B085) (IC11B067) FH Technikum Wien Bachelor of Science Information and Communication Systems and Services Embedded Systems Engineering BIC-4 (SS2012)

2 Ausgangssituation Da bereits letztes Jahr mit der Roboterplattform Nibobee gearbeitet wurde, war die Hardware bereits fertig aufgebaut. Außerdem waren bereits folgende Module an die Nibobee angeschlossen und funktionsbereit: BTM-222 Bluetooth Kommunikation HS-55 Server mit Software PWM SRF-08 Ultraschall Entfernungsmesser Darauf aufbauend werden nun folgende Problemstellungen bearbeitet: PID Regler als Linienfolgealgorithmus Auswertung der Wegstrecke über Odometrie Rekonstruktion der Strecke am Computer

3 Laufender Fortschrittsbericht PID-Regler Zuerst wurde die Aufgabenstellung PID-Regler bearbeitet. Dabei traten jedoch einige Probleme auf. Da die Akkuspannung doch erheblich schwankt, vor allem wenn die Batterien durch die Motoren voll belastet wird, musste ein sehr enger PD-Regler verwendet werden, um den Roboter trotzdem auf der Linie zu halten. Außerdem musste vor jedem neuen Test eine Kalibrierung der Liniensensoren vorgenommen werden. Die Referenzwerte für die Sensoren werden bereits von der Standardlibrary in das EEPROM geschrieben und für die Messung herangezogen. Der P Regler: int p_regler(int signal, double Kp) { int yp = (int) signal * Kp; return yp; } Der D Regler: int d_regler(int signal, double Kd) { int e = signal - yd_old; yd_old = signal; int yd = e * Kd; return yd; } Auf den I Anteil wurde nach den PD Tests bewusst verzichtet, da dieser langsame Regler wenig dazu beitragen könnte den Roboter auf der Strecke zu halten. Dies war die hauptsächliche Erkenntnis aus diesem Test. Der PD Regler kann zwar sehr genau einer Strecke folgen, aber zu enge Kurven verursachen immer ein unkontrolliertes Verhalten. Deswegen wurde zur Optimierung des Algorithmus eine Finite State Machine herangezogen und diese wurde mit dem PD Regler kombiniert. Die FSM unterscheidet folgende Stati: online, left_offset, right_offset, right_offline, left_offline Im Status online wird der Kurs ausschließlich mit dem PD Regler korrigiert. Sobald ein zu großer Offset entsteht steuert die FSM konstant gegen und schaltet den PD Regler aus. Dadurch ist es möglich, wenn die Linie verloren ist, festzustellen in welche Richtung massiv gegengesteuert werden muss um die Linie im Offline Status wiederzufinden. Dadurch konnten beide Vorteile in einem Algorithmus vereint werden.

4 Hier das Kernstück des Algorithmus als STD dargestellt: Das STD wird wie folgt interpretiert: l,m,r sind die zurückgelieferten Werte der Phototransistoren. <> zeigt an ob in der Transition der Wert größer oder kleiner als die im Code gesetzte LINELOSTTHRESHOLD ist Die Übergänge auf sich selbst wurden der Übersichtlichkeit halber nicht parametrisiert. Verbesserung gegenüber der ersten Version ist, dass nun auch im State offset der PID-Regler zum Einsatz kommt. Dafür musste lediglich eine kleine Anpassung der Statetransistions vorgenommen werden. Von den offset States kann jetzt nur noch in den online oder in den offline State der entsprechenden Seite gewechselt werden, davor war quasi jeder Status möglich. Dadurch ist sichergestellt, dass der Roboter entsprechend richtig reagiert und im offline Fall auf die richtige Seite gegenlenkt. Damit wird dieser Teil der Aufgabe vorerst abgeschlossen.

5 Ultraschall Radar Unser Lektor hatte erfreulicher Weise eine tolle Idee und Zwischenaufgabe. Mit dem Ultraschallmodul ist es möglich ein kleines Radar umzusetzen. Damit nicht zuviel Energie in die grafische Aufbereitung investiert werden musste, wurde die Grafik auf ASCII Ausgabe beschränkt. Um die gemessenen Werte dann auch in eine Grafik umsetzen zu können benötigt man eine Umrechnungsformel. Als Ansatz wurde der WinkelWinkelSeiten Satz gewählt. Da bereits durch die Messung die Seite c, durch die Servostellung der Winkel Alpha und da es sich um ein rechtwinkeliges Dreieck handelt der Winkel Gamma bekannt sind, können die restlichen Größen des Dreiecks problemlos berechnet werden. Beta = 180 Gamma Alpha a = c * sin(alpha) b = c * cos(alpha)

6

7 Nun ist es möglich diese Größen skaliert in eine ASCII Grafik umzuwandeln. An diesem Beispiel sieht man sehr eindrucksvoll, dass bereits drei der im Bild ersichtlichen Stifte in einer Entfernung von 60cm gut erkannt werden können. Leider lassen sich wegen des Streuungsverhaltens des Ultraschallmoduls aber keine feineren Abbilder erstellen. Aus der nachstehenden Grafik ist ersichtlich, dass das Modul über 30 Grad Streuung aufweist. Dadurch wird punktgenaues Abtasten quasi unmöglich. Mit der Radarimplementierung stößt allerdings der Standard ATMEGA16 Chip bereits an seine Grenzen, da das Radar Array in dem die Messpunkte gespeichert werden bereits 600 Bytes des 1k großen SRAMs des Chips belegt und damit nicht mehr genug Platz bleibt, um alle Funktionen parallel betreiben zu können. Deswegen wurde das weiter unten beschriebene Tuning Kit bestellt und verbaut.

8 Wegstreckenrekonstruktion mittels Odometrieauswertung Grundsätzlich ist die Odometriekonstruktion bei diesem Roboter sehr gut ausgeführt. Dadurch, dass die Odometriesensoren (Phototransistoren) in einem fast geschlossenem Getriebekasten verbaut sind, gibt es sehr wenig Störeinflüsse. Ausserdem wurde hier kein Schwarz-Weiß Farbrad Ansatz gewählt, sondern es wurden Bohrungen in einem Zahnrad angebracht und diese Ticks werden abgezählt. Das bringt eine wesentliche Verbesserung gegenüber dem bekannten und oft in Studentenprojekten verwendeten Roboter Asuro. Die Odometrie ist z.b. in der Bluetoothsteuerung verwendet, um ein möglichst gerades Fahrverhalten zu erzeugen. Probleme macht allerdings die Umrechnung für eine Linienrekonstruktion. Als Ansatz wurde Folgendes gewählt: Die Odometriedaten können als Normalvektoren an die Reifen angelegt werden, da der Radstand und der Umfang des Rades bekannt sind. Danach kann die x Koordinate des neuen Mittelpunktes berechnet werden: (Odo1 Odo2) / 2 = neu Leider wird es mit der Y Koordinate und auch mit der neuen Ausrichtung des Roboters wesentlich schwieriger. Selbst wenn die Koordinaten berechnet werden können wäre das Ergebnis schätzungsweise ungenau. Da E-Kompass Module bereits sehr preiswert zu bekommen sind, wurde auf diese Alternative geschwenkt. Die Wahl fiel primär auf das Modul HDMM01 welches über die I2C Schnittstelle anzusteuern ist. Weiters wurde noch das Modul DSPC01 mitbestellt. Falls die Zeit reicht, wird ein Vergleich der beiden Module angestrebt In einem zweiten Schritt wurde nun die Wegstrecke mittels der Odometriedaten ausgewertet. Da der Roboter für eine volle Umdrehung genau 128 Ticks der Odometrie auslöst kann leicht auf die Winkeländerung je Tick rückgerechnet werden (360/128). Danach wird diese Angabe mit einer einfachen Vektorberechnung als Polarkoordinaten interpretiert und mit einer Berechnung analog der E-Kompass Berechnung ins karthesische Koordinatensystem übergeführt.

9 Resümee ist, dass die Odometrieauswertung wesentlich leichter zu implementieren war, da die Funktion bereits in der Standardlibrary vorhanden ist. Außerdem ist diese Implementierung bei weitem weniger störanfällig.

10 E-Kompass Das E Kompass Modul HDMM01 wird über die I2C Schnittstelle angesteuert. Da diese bereits für das SRF08 Modul ausprogrammiert war, konnte der Kompass sehr schnell in die Software integriert werden. Allerdings traten hier ernsthafte Probleme wegen der schwankenden Versorgungsspannung auf. Die Werte driften sehr stark. Um diesem Problem entgegen zu wirken wurde der Roboter mit einem Spannungsregler ausgestattet um die Eingangsspannung konstant zu halten. Die Wahl viel auf einen klassischen L78S05 Regler. Weiters wurde die Stromversorgung auf Lipo Akkus (2-Zellen) umgestellt, da der Spannungsüberschuss von 4 Batteriezellen doch sehr gering war und wahrscheinlich sogar ein LowDrop Regler damit Probleme gehabt hätte. Mit dieser Maßnahme wurden alle Messdaten des Roboters weitestgehen stabilisiert, auch wenn sich ein minimaler Drift auch damit nicht vermeiden lässt. Der E-Kompass liefert karthesische Koordinaten die man zur Weiterverarbeitung zuerst zum Nullpunkt im karthesischen Koordinatensystem verschiebt und danach mittels des 4-Quadranten Arkustangens (atan2) in einen Winkel umrechnet. Das Problem dabei ist der doch noch vorhandene Drift der Werte. Die Minimal und Maximalwerte der x und y Koordinate des Kompass müssen jedes Mal neu erfasst werden. Dafür wurde eine Funktion programmiert, mit der sich der Roboter langsam im Kreis dreht und Minimalwert und Maximalwert ermittelt. Daraus werden dann die Verschiebung vom 0-Punkt im karthesischen Koordinatensystem und der Skalierungsfaktor für eine Darstellung von -180 bis 180 berechnet.

11 Wegstreckenrekonstruktion mittels E-Kompass Zur Rekonstruktion der Strecke wurden nun die Daten des E-Kompass und die Daten der Odometrie sowie der Linienfolgealgorithmus gekoppelt. Um möglichst geringe Fehler zu produzieren und viele Messpunkte zu ermitteln vergehen maximal 5 Ticks an der Odometrie bis eine Messung vorgenommen wird. Für die Vektorlänge wird folgende Berechnung herangezogen: if (odo_left < odo_right) { vector = odo_left + (odo_right) /2; } else { vector = odo_right + (odo_left) /2; } Dadurch errechnet man immer ca. 2/3 der Gesamtvektorsumme. Diese wird dann zusammen in ein Polarkoordinatensystem gesetzt und in das karthesische Koordinatensystem umgerechnet. x = (vector) * (cos(m_pi * grad_last / 180.0)); y = (vector) * (sin(m_pi * grad_last / 180.0)); Danach werden zu den alten Koordinaten die neuen Koordinaten addiert. Um die Daten auf dem Computer auszuwerten wurden im ersten Schritt die Koordinaten über Bluetooth ausgegeben und im Programm putty mitgeloggt um anschließend die Daten an gnuplot weiterzureichen. Hier ein Beispiel einer ausgewerteten Wegstrecke. Das größte Problem war eine Hantelbank der Firma Energetics Typ Power Bench 380 Plus welche direkt neben der Fahrstrecke platziert war. Diese beeinflusste den E-Kompass derart, dass ein gleichbleibender Fehler auf der x-achse erkennbar war und dadurch angenommen wurde, dass es sich um einen Berechnungsfehler handelte. Nachdem der Code mehrmals durchsucht wurde und kein Fehler gefunden werden konnte, wurde beschlossen die Umgebung von allen Störfaktoren zu befreien. Danach konnte die Linie mit nur noch sehr geringem Fehler rekonstruiert werden. Ein weiteres Problem war die Verzögerung durch die Messungen des EKompass und der Berechnungen. Dadurch verlor der Roboter öfters die Linie. Deswegen wird der Roboter nun für die Messung, Berechnung und Übertragung

12 angehalten. Leider besteht weiterhin eine Ungenauigkeit die aller Wahrscheinlichkeit nach auf äußere Störeinflüsse zurückgeführt werden kann. Tuning Kit Umbau Das Tuning Kit beinhaltet zwei neue ICs, einen neuen Quartz und einen Kondensator. Hier ein Vergleich der Komponenten: ATmega16 -> ATmega1284 FLASH: 16 kb 128 kb RAM: 1 kb 16 kb EEPROM: 0,5 kb 4 kb Freq: 20 MHz 15 Mhz ATtiny44 -> ATtiny84 FLASH: 4 kb 8 kb RAM: 0,25 kb 0.5 kb EEPROM: 0,25 kb 0,5 kb Freq: 20 MHz 15 Mhz Durch diesen Umbau ist es möglich, die Radarfunktion parallel zu allen anderen Funktionen zu betreiben. Platz für jede Menge erweiternden Code ist wieder gegeben. Um mit diesem neuen Chip arbeiten zu können musste die Nibobee Library auf die aktuelle Version upgedatet werden, da die Libs erst hier auch auf den neuen Chip gelinkt sind. Außerdem muss der Chiptyp in AvrStudio angepasst werden und die richtigen Libs müssen im Projekt hinzugefügt werden.

13 Multimediale Aufzeichnungen Videos der umgesetzten Lösungen:

14 Zeittafel Datum Thema PS HB Zeit PD-Regler 8h Ultraschall Radar 8h Lieferung Nibobee Ultraschall Radar Aufbau Hardware Odometrieauswertung Grafikausgabe Evaluierung (gnuplot) 4h E-Kompass Implementierung 8h Daten für Linienrekonstruktion über BT Erstellung Videos Bestellung Tuning Kit Umbau Tuning Kit / Liposaver 4h Umbau Tuning Kit / Liposaver 1h Aufbau Hardware Streckenrekonstruktion mittels Odometrie Fehlerbehebung Hardware + Tests Anpassen Dokumentation 8h 2h 4h 2h 4h 1h 8h 4h 1h