|
|
AutopilotLast update: 2011-07-15 (Added new information on OD and capbutton)
[Bearbeiten] ÜberblickDiese Seite beschreibt das Projekt Autopilot. Der Autopilot ist primär für Wasserfahrzeuge entwickelt worden, lässt sich vermutlich aber mit allen (langsamen) Objekten verwenden. ... Seite noch im Aufbau ... [Bearbeiten] ToDos für den Code im SVN
[Bearbeiten] AufbauDer Autopilot besteht aus mindestens 3 Teilen:
Optional gibt es als zusätzliche Einheiten:
[Bearbeiten] FunktionsweiseIn diesem Abschnitt wird die Funktionsweise des Autopiloten beschrieben. Hierbei handelt es sich in erster Linie um das Grundprinzip, also die Zusammenhänge zwischen den einzelnen Modulen, und weniger über die Funktionsweise irgendeines Autopiloten. Es gibt, global gesehen, 3 Teilbereiche des Autopiloten:
[Bearbeiten] Aquisition / DatenaufnahmeDie Daten für die Regelung des Autopiloten werden etwas kompliziert ermittelt. Bei Wasserfahrzeugen aus Stahl besteht häufig das Problem, dass ein Magnetkompass keine Zuverlässigen Werte ohne komplizierter, manuell durchzuführender Kompensation liefern kann, da der Stahl das Erdmagnetfeld beeinfluss. In diesem Autopiloten wird die Ausrichtung des Fahrzeugs deswegen mithilfe eines gyroskopischen Sensor (Drehbewegungssensor) und einem GPS-Signal gemacht. Die Drehbewegung (also upm) werden integriert, was dann den Winkel angibt. Mithilfe des GPS-Signals wird nun zum einen Festgestellt, wo Vorne/Norden ist und zum anderen, ein Offsetfehler in der Drehbewegung, der sich ansonsten wie ein wegdriften des Winkels bemerkbar macht, korrigiert. Hierzu wird aus dem Gyro-Signal des Drehbewegungssensors das theoretische GPS-Signal errechnet. Die Differenz zum tatsächlich erhaltenen GPS-Signal wird daraufhin verwendet, um den Offset des Gyro-Sensors zu steuern. Diese Regelschleife benötigt etwa 2-3 Minuten um eine brauchbare Genauigkeit zu liefern, ist anschließend dafür aber unabhängig vom Magnetfeld (Stromleitungen in der Nähe) und Wellen. Momentan wird für diese Messung ein Ein-Achs-Sensor genutzt, der bei schräglage eine gewisse Abhängigkeit des Ausgangssignals von der Rollbewegung hat. Um diesen Umstand zu unterbinden, könnte man mehrere Achsen in Verbindung mit einem Beschleunigungs-(Lage-)Sensor verwenden. [Bearbeiten] RegelungDie Regelung besteht aus einem normalen PID-Regler mit unterschiedlichen, nichtlinearen Regelbereichen für kleine und große Abweichungen. Zur besseren kontrollierbarkeit, gerade bei großen Kursänderungen, sind diverse Begrenzungen eingebaut. Desweiteren wird ein neuer Sollkurs nicht sofort vollständig übernommen. Vielmehr wird der Sollkurs, den der Regelalgorithmus als Eingang erhält, langsam an den Sollkurs, den der Benutzer einstellt, herangeführt. Dies führt zu einer konstanten Drehgeschwindigkeit und verhindert großes Übersteuern der Regelstrecke. [Bearbeiten] SteuerungDie Steuerung der Richtung des Fahrzeugs geschieht mit Hilfe eines Ruderlagensensors und einem PWM-Regler mit Umpolung. Die Differenz zwischen tatsächlicher Ruderlage (vom Sensor) und dem Sollwert (aus der Regelung) wird über einen Filter mit dem Motor verknüpft. Durch die Filterung ist ein langsames Anlaufen und Abbremsen des Motors möglich. [Bearbeiten] einadrige KommunikationDie Haupteinheit und die Steuereinheit sind über ein dreiadriges Kabel miteinander verbunden. Diese Kabel hat Versorgung, Masse und Daten als Belegung. Über die Datenleitung wird ein bidirektionales Busprotokoll gefahren, auser mehrerlei Gründen. Zum einen, ist es so möglich, die Verbindung mit nur drei Adern vorzusehen, wofür z.B. ein herkömmliches Verlängerungskabel reicht. Zum anderen wird durch das Busprotokoll gewährleistet, dass auch mehr Controleinheiten angeschlossen werden können. Warum nicht auf den UART der AVRs zurückgegriffen wird, hat mit dem Protokoll zu tun (siehe weiter unten). Die Kommunikation läuft auf einem einadrigen Kabel, das an beiden Enden nur mit dem jeweiligen Mikrocontroller verbunden ist. Eine extra Treiberschaltung gibt es nicht. [Bearbeiten] Hardware Layer (suart.c)Der Hardwarelayer heisst suart (Software Universial Serial Asynchronous Receiver and Transmitter) und wurde ursprünglich in Anlehung an den UART konzipiert. Die Übertragung läuft immer in Längen von 9 Bit ab, einem Startbit ("0") und 8 Datenbits (kann durch ändern von DATALEN verändert werden). Die Bits werden nach dem differentiellen Manchestercode versendet. Eine "1" als eine Änderung des Zustandes der Leitung in der Mitte der Bitperiode und eine "0" als eine Änderung am Beginn und in der Mitte der Bitperiode. Durch das Starten mit einer "0" erhält der Empfänger also zwei Übergänge wobei der Abstand genau einer halben Bitperiode entspricht. Somit kann sich der Empfänger darauf synchronisieren und den Takt zurückgewinnen. Dies gewährleistet, dass Sender und Empfänger nicht zuvor schon auf der selben Frequenz eingestellt sein müssen. Eine Baudratenschwankung (z.B. durch Temperaturschwankungen beim Verwenden des RC-Oszillators) sind unkritisch. Sind alle Bits versendet worden, wird die Leitung in den Pullup- oder Tristate-Zustand geschaltet, so dass sich ihr Zustand nicht ändert. Der sendende Teilnehmer darf nach 1 oder 2 Bitperioden ein neues Byte beginnen, ein empfangender Teilnehmer darf erst nach 3 Bitperioden ein Byte beginnen zu versenden. Dies ermöglich das Versenden ganzer Pakete, ohne dass die Pakete durch andere Teilnehmer unterbrochen werden. Für dieses sehr einfache Protokoll kann ein einzelner IO-Pin des AVRs verwendet werden, durch die Verwendung des ICP kann die Zeitmessung genauer gemacht werden, was den Prozessor und die Richtlinien für die anderen Interrupts entspannt. Eine Übertragungsrate von 10kBit/s erzeugt eine durchschnittliche Prozessorlast von ca. 10%. [Bearbeiten] Paket Layer (atp.c) VERALTETDer Paketlayer atp (Advanced Transmission Protocol) beinhaltet folgende Funktionalitäten: Daten können von einem Knoten zu einem anderen geschickt werden, ohne dass dabei Daten verloren gehen oder verändert werden. D.h. es gibt eine Antwortnachricht, eine Checksumme und einen Datenzähler. Damit sich sendender und empfangender Knoten über die Datenzählerstände einig sind, gibt es einige Nachrichten zur Synchronisierung. Es ist darauf zu achten, dass nicht versehentlich Lock-Ups enstehen, sich zwei kommunizierende Knoten also gegenseitig blockieren. Der Paket Layer des ATP unterstützt Punkt-zu-Punkt Verbindungen, die nach einem gegenseitigen Synchronisieren Pakete in Reihenfolge und bestätigt mit mehreren Wiederholungen zustellen. Zusätzlich gibt es seit Rev. 10 Broadcast Pakete, die von einem Knoten ausgesandt werden können und von allen anderen empfangen werden können. Hierbei gibt es kein Reihenfolge und keine Bestätigung/Nachsendung bei Kollision. Kollisionen können durch den CRC dennoch erkannt werden und das Paket wird in einem solchen Fall verworfen. Da das ATP recht schwierig so zu konzipieren ist, dass es nachweislich Lock-Up frei ist, könnte man über eine Neuimplementation (ggf. mit anderen Programmiertechniken) nachdenken. [Bearbeiten] Packet Layer Version 2 (atp2)Die zweite Version des Packet Layers sollte einige Limitierungen der ersten Version ersetzten. Zum einen, war es bisher nicht möglich durch eine einfache Methode die Objekte des CLI auf dem Bus erreichbar zu machen, ohne große Routinen mit viel if-then-else-Konstrukten zu schreiben, zum anderen ist es für einen Knoten nicht möglich, mit mehreren anderen Knoten gleichzeitig zu kommunizieren. Letzteres lag an der Sequenznummernvergabe und dem initialen Aushandeln beim Wechseln auf den entsprechenden Partnerknoten. Die Version 2 hat dies nun verändert, in dem es strenggenommen ausschließlich Broadcast-Pakete gibt und die Sequenznummern nicht ausgehandelt sondern nur zurückgesetzt werden:
Die Addressierung erfolgt über den nächsten Layer der Verarbeitung. Dieser war im alten Protokoll das ci-Modul (Control Interface), welches die Daten an die Kontrolleinheit verschickte. Nun gibt es das OD-Module (Object Dicitionary), welches alle Objekte eines Knotens verwaltet. [Bearbeiten] Application Layer (OD-Modul, aktuell)Das Object Dictionary besteht im Kern aus der Datei od_objects.h, welche die nötigen Macros für das Anlegen von Objekten enthält. Die Objekte sind analog zu den alten CLI-Objekten gekennzeichnet durch einen Namen, einen Identifier (16 Bit, neu), eine Beschreibung (optional) und einem Speicherbereich mit assoziiertem Typ. Der Speicherbereich gibt an, wo das Objekt im RAM steht, der Typ, welchen Typs es ist. Als Schnittstellen zum Programm gibt es nun mehrere Module:
[Bearbeiten] Application Layer (ci.c) (alte Version vor Rev. 57)Auf der paketorientierten Grundlage des ATP wird die Kommunikation durch einfache Array realisiert: das erste Byte im Array spezifiziert den Typ von Paket. Hier gibt es welche, die die LEDs an der Controlleinheit steuern (CI_LIGHT_OFFSET + LED Nr.) oder den Alarmgeber an der Controlleinheit einschalten (CI_CONTROL_ALARM) oder der Haupteinheit mitteilen, dass eine Taste gedrückt wurde (CI_BUTTON_OFFSET + Taster Nr.). Danach folgen unterschiedliche Zahl von Bytes mit unterschiedlicher Bedeutung. Bei den LED-Meldungen folgt ein Byte mit dem Status (Off, On, Blink und Flash), bei den Taster-Meldungen eines mit dem Status des Tasters (Click, Press, Dbl Click). Der Master versendet seine Nachrichten nacheinander, wobei maximal alle 10 Millisekunden eine Nachricht versandt wird. Dadurch gibt es keine Überlauf des Sendepuffers. Die Statemachine dafür ist in main/interface/ci.c untergebracht (c_main). Wurden von Master Daten empfangen, wird durch den ATP-Layer die Funktion ci_input aufgerufen und darin behandelt der Code die entsprechenden Aktionen. Die Controlleinheit versendet ihre Daten, wenn ein Button-Event aufgetreten ist (dann wird die button_event in main.c aufgerufen). Empfängt die Controll-Einheit ein Paket, wird es in der atp_callback_rx in control/config/atp_hw.h behandelt und entpsrechend die Taster gesetzt. [Bearbeiten] Kapazitive Taster für KontrolleinheitZur besseren Verträglichkeit mit Umwelteinflüssen (Regen, etc.) wurden die mechanischen Taster durch kapazitive Taster ersetzt. Diese erkennen das auflegen des Fingers auf eine Plexiglasplatte, ohne dass die Plexiglasplatte dafür durchbohrt werden muss. Allein durch die Kapazitätsveränderung der Unterseite der Plexiglasplatte wird die Erkennung realisiert. Der Aufbau benötigt auf der Unterseite der (maximal 8mm starken) Plexiglasplatte Kupferflächen in der Größe von mindestens 20x15mm, die an den Controller und einen Widerstand angeschlossen werden. In der momentanen Version sind hierfür Federn in die Platine eingelötet, die gegen diese Kupferflächen auf der Plexiglasplatte aufliegen. Die Federn lassen sich leicht aus Kupferdraht, Silberdraht etc. biegen (2-3 Umdrehungen auf ca. 7mm Durchmesser mit beiden Enden radial abstehend). Diese Taster funktionieren nur mit der zweiten Version des Controlboards (control2.brd, control2.sch). Aufgrund der sehr geringen Signalstärke der kapazitiven Veränderung (ca. 1-5% der Gesamtkapazität) sind die Taster nicht sehr robust. Die Messungen der Kapazität müssen sehr häufig vorgenommen werden und über große Zeiten gemittelt werden um eine Erkennung eines Tastendrucks durchzuführen. Um zu verhindern, dass Tastendrücke durch Umwelteinflüsse (Wasserflächen, etc) falsch erkannt werden, sind pro Bedientaste zwei Flächen realisiert von denen die eine die andere umgibt. Nur wenn auf der inneren eine Veränderung erkannt wird und die äußere unverändert bleibt, wird ein Tastendruck gewertet. Troz dieser Auswertung ist es nicht zuverlässig möglich, durch die 8mm starke Plexiglasplatte Tastendrucke zu erkennen. Nach ca 3 Monaten Betriebszeit der Tasten haben sich die Eigenschaften verändert und führen zu fehlerhaftem Verhalten. An einer Verbesserung wird gearbeitet. [Bearbeiten] Aufbau des QuellcodesZur leichten Portierbarkeit auf eine andere Platine (unterschiedliche Anschlüsse) oder andere Peripherie (andere Ansteuerung) oder gar einen anderen Controller ist der Quellcode in zwei Teile geteilt, deren Teilung man nicht ohne eine kleine Erläuterung erkennen kann. Für die einzelnen Module gibt es vier Dateien (nicht zwangsläufig immer alle):
Diese Dateien sind nun alle in dem Quellverzeichnis wie folgt organisiert (Ausschnitt aus documentation.txt): autopilot ist das Wurzelverzeichnis
Wenn ein Modul nun auf eine andere Hardware eingestellt werden soll, so muss lediglich die hwdatei des Moduls verändert werden. Hat man unterschiedliche Prozessoren, so muss entsprechend das neue config_xxxx und hw_xxxx Verzeichnis angelegt werden und gefüllt werden wie auch das Makefile entsprechend den neuen Bedingungen angepasst werden. Ist dies geschehen, kann der Code durch Umschalten der Variablen TARGET=atmega644p für ein anderes Board compiliert werden. [Bearbeiten] NachbauDer Nachbau des Autopiloten ist nicht schwierig, wenn man folgende Ratschläge beachtet:
[Bearbeiten] Schritt 1: Hauptplatine (main.brd)Es führt leider kein Weg an einem Gyrosensor vorbei, d.h. den sollte man sich zulegen, auch wenn er in MEMS gefertigt nicht für lau zu haben ist. Je nach Gehäuse empfehle ich auch gleich einen aufgelöteten (z.B. Entwicklungsboard) zu kaufen. Der Verwendete ADIS16250 von Analog Devices funktioniert gut und der Quellcode ist schon für diesen vorhanden. Der Gyrosensor wird mit einem Kabel an einen der SPI-Steckplätze auf der Hauptplatine verbunden. Je nach Steckplatz ergibt sich dann ein anderes Mapping für die Chip-Select-Leitung, d.h. es muss ggf. die Datei config/course_hw.h angepasst werden (Zeile #define COURSE_CREATE ..., siehe auch hw/adis16250.h) Die anderen SPI-Steckplätze bleiben frei, es können später Beschleunigungssensoren (z.B. ADIS16003) verwendet werden, hierzu gibt es im Quellcode aber noch keine Verwendung. Der Ruderpositionsgeber (SV9) ist ein Potentiometer, dessen beide äußeren Enden an die Versorgung angeschlossen werden und dessen Spannung am Abgriff gemessen wird. Je nach Widerstand des Potentiometers muss hier ggf. Vorsicht mit der Spannung geboten sein (bei den 5k die ich habe, ist es problemlos) Die übrigen Bestückungsteile sind nicht von Besonderheiten geprägt. Die galvanische Trennung bei den seriellen Schnittstellen sollte gerade beim GPS unbedingt beibehalten werden! [Bearbeiten] Schritt 2: Leistungsplatine (driver_fet.brd)Diese Platine ist für die Umsetzung der elektrischen Signale aus dem AVR in starke Versorgung für die Stellelemente notwendig. Je nach Geschmack, kann diese 3-lagige (2Lagig + 2 isolierte Drahtbrücken) Platine in 35um oder 70um hergestellt werden. Die Leiterbahnbreite beträgt 4.4mm, den maximalen Strom kann man leicht ausrechnen: für die 35um Kupferauflage gibt es bei 10A eine Erwärmung um 30°C, was ich für vertretbar halte. Die vielen Klemmen entlang der längeren Seite sind alternativ zu den Transistoren gedacht, z.B. für große Transistorgehäuse oder für mit Kabeln angeschlossene Transistoren. An die 3er-Klemme "X7" kann ein Signalgeber (Tröte, Licht, etc.) angeschlossen werden, das durch die Software des Autopiloten z.B. bei großen Kursabweichungen o.ä. betätigt werden kann. Dieser Anschluss ist ein Open-Drain-Anschluss, die Masseleitung trägt also die Schaltinformation! [Bearbeiten] Schritt 3: Haupteinheit zusammenstellenDie beiden in Schritt 1 und Schritt 2 hergestellten Schaltungen können nun in ein Gehäuse gebaut werden. Es eignet sich ein Gehäuse mit Eurokarten Einschub (Nut), das an der Rück- und Vorderseite Anschlüsse bzw. Kühlfläche bietet. Ich habe alles (inkl. Gyrosensor und 2 Beschleunigungssensoren in Euro-Gehäuse II von Reichelt bekommen). In die Frontseite kamen dann ein Ausschnitt für den Programmierstecker und die LEDs der Hauptplatine sowie der weiteren Steckanschlüsse (RS232 SV5 und SV7, 1-Drahtverbindung an SV8, Rudergeber an SV9). Die Befestigung der Europlatinen (main.brd und driver_fet.brd) sollte kein Probem darstellen, ein Rand ist extra freigelassen für die Halterung in einer Nut. Der Gyrosensor sollte auch befestigt werden, z.B. durch direktes Aufstecken einer Platine oder durch Festschrauben. Er sollt so befestigt werden, dass die Achse senkrecht steht, wenn das Gehäuse an seinem endgültigen Ort montiert ist. Auf das Gehäuse lohnt es sich dazu, auch eine Aufschrift "This Side Up" oder Ähnliches anzubringen. [Bearbeiten] Schritt 4: Kontrolleinheit (control.brd)Zur Bedienung des Autopiloten muss man die Kontrolleinheit aufbauen und mit der Haupteinheit durch ein dreiadriges Kabel verbinden. Die Platine kann einfach aufgebaut werden. An den Anschluss X3 werden 6 LEDs angeschlossen, Anode aller LEDs an Pin 7 und Pin 1-6 eine LED mit Kathode. Die Taster werden ähnlich verbunden: alle Taster mit einem Anschluss an Pin1 von X2 und je Taster den anderen Anschluss an die anderen Pins 2-7. An X1 wird das dreiadrige Kabel zur Haupteinheit angeschlossen und an X4 kann ein Alarmgeber angeschlossen werden (z.B. Signalgeber), für den es in der Software momentan aber noch keine Funktionsverknüpfung gibt. Je ein Taster und eine LED sind zusammengehörig und sollten so auch in das Gehäuse entsprechend eingebaut werden. Es empfiehlt sich ein wasserfester Einbau. Der Transistor und der Spannungsregler brauchen nicht gekühlt zu werden. [Bearbeiten] Ressourcen[Bearbeiten] QuellcodeDer aktuelle Sourcecode und Schaltplan lässt sich herunterladen unter: oder direkt durch SVN auschecken oder im Browser anschauen: Known-to-be-working Revisions im SVN:
[Bearbeiten] Schaltplan   Der aktuelle Schaltplan liegt im SVN. [Bearbeiten] ToDos* Artikel vervollständigen * common/body.mk: info-Target: auch .h Dateien mitzählen (Quellcodezeilen etc) ;-) * Kurzen Artikel zum Terminal schreiben [Bearbeiten] History2011-07-15 Added new information on OD and capbutton 2010-11-23 Added new version of ATP2 and OD 2010-04-27 SVN Repository populated 2010-04-21 initial page |