Autopilot

by Clemens Helfmeier

Last update: 2011-07-15 (Added new information on OD and capbutton)

Überblick

Diese 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 ...

ToDos für den Code im SVN

• CRC16 richtig implementieren.
• (r164) capbutton Bibliothek noch etwas robuster machen: Drücken besser erkennen
• (r164) control/hw_atmega644p/led Bibliothek: flackern beseitigen - könnte mit volatilen Variablen zusammenhängen

Aufbau

Der Autopilot besteht aus mindestens 3 Teilen:

• der Haupteinheit: Diese beinhaltet die "Intelligenz" des Autopiloten, die elektrischen Komponenten. Hier laufen auch alle Informationen zusammen.
• die Kontrolleinheit ist in einer gut erreichbaren und vom Steuerstand aus sichtbaren Kiste mit einigen Tastern und LEDs die die Bedienung übernimmt. Sie kommuniziert mit der Haupteinheit über eine bidirektionale einadrige Verbindung.
• die physikalische Steuereinheit in Form eines Motors oder ähnlichem, das die Ausgaben der Haupteinheit in tatsächliche Aktion umsetzt. Dieser Teil ist in diesem Projekt nicht beinhaltet, stattdessen wird ein altes Gebrauchtstück eines defekten Autopiloten verwendet.

Optional gibt es als zusätzliche Einheiten:

• ein Terminal, welches Informationen anzeigen kann und u.U. später auch weiter Funktionalität wie Aufzeichnung oder Einstellung des Kurses erlaubt.

Funktionsweise

In 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:

• Aquisition, also Dateneingabe
• Regelung, also der eigentliche Autopilot Regelalgorithmus
• Steuerung, also Datenausgabe

Aquisition / Datenaufnahme

Die 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.

Regelung

Die 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.

Steuerung

Die 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.

einadrige Kommunikation

Die 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.

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%.

Paket Layer (atp.c) VERALTET

Der 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.

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:

• Broadcast-Pakete: Alle Knoten empfangen alle Pakete und geben sie an den nächsten Layer weiter, der daraufhin entscheidet, ob das Paket für diesen Knoten war oder nicht. War es für diesen Knoten, versendet der ATP2-Layer ein Acknowledgement, war es nicht für diesen Knoten, wird das Paket ignoriert.
• Sequenznummern: Die Sequenznummern werden vom Sender erzeugt. Bei jedem Paket welches er versendet (es gibt keinen Empfänger da es Broadcast-Pakete sind), inkrementiert er seine eigene Sequenznummer. Hat die eigene Sequenznummer einen bestimmten Wert überschritten, so wird sie alsbald möglich zurückgesetzt. Dies geschieht indem ein entsprechendes Paket 2x auf dem Bus übertragen wird.
• Empfangsseitige Auswertung der Sequenznummer: Ist ein Paket empfangen worden, so schaut der Empfänger in seinem Speicher nach, ob er für diesen Sender schon eine Sequenznummer gespeichert hat. Ist dies der Fall, wird überprüft ob die neue Sequenznummer größer ist, als die gespeicherte und das Paket entsprechend entweder gewertet oder als Duplikat eingestuft. Sollte keine Sequenznummer vorhanden sein, so wird das Paket akzeptiert und die Sequenznummer gespeichert. Wird ein Sequenznummern-Rücksetzpaket empfangen, so wird das entsprechende Sender-Sequenznummern-Paar aus dem Speicher des Empfängers (und damit aller Empfänger, da Broadcast) gelöscht.
• Bestätigungspakete (Acknowledgements) werden vom entsprechenden Empfänger versendet, wobei das Feld original_sender mit dem Empfänger des Ack-Paketes gefüllt wird (also dem Sender des zugehörigen Datenpaketes). Es wäre zwar auch möglich, das sender Feld umzudeklarieren, wenn es in einem Ack-Paket auftritt, allerdings hat man so die Möglichkeit auch mehrere Acknowledegments abzuwarten/einzufordern. Wird vom Sender kein Acknowledgement emfangen, so wird das Datenpaket erneut übertragen, insgesamt 5 mal (konfigurierbar).

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.

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:

• od_cli: Verbindet das Objektverzeichnis mit dem Command-Line-Interface. In dieses Modul sind große Teile des Inhalts aus dem alten CLI-Modul geflossen. Über die Kommandozeile lassen sich Objekte lesen, schreiben, ausführen und anzeigen.
• od_cli_addons: Befehle, die das Arbeiten mit dem CLI vereinfachen werden als Objekte implementiert (z.B. ls, lsr, etc.)
• od_packetbus: das Paketbus-Modul macht die Objekte eines Knotens auf dem ATP2 Bus erreichbar. Durch die generische auslegung kann dieses Modul recht klein sein und trozdem alle Objekte abdecken. Es werden Operationen wie Lesen, Schreiben und kombiniertes Lesen und Schreiben unterstützt. Durch die Auslegung von ATP2 und od_packetbus kann jedes Objekt von jedem Knoten, der an den Bus angeschlossen ist, geschrieben oder gelesen werden, ohne wissen zu müssen, welcher Knoten das Objekt besitzt.
• od_storage: Objekte in den EEPROM und liest ihn beim Neustart des Controllers wieder aus. Lässt auch zu, Objekte, die nicht im lokalen Knoten gespeichert sind, im EEPROM abzulegen (noch nicht ausreichend getestet).

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.

Kapazitive Taster für Kontrolleinheit

Zur 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.

Aufbau des Quellcodes

Zur 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):

• eine Quellcodedatei, in der der Inhalt des Moduls steht, z.B. also die Funktion, die das Modul bereitstellt. In dieser Datei werden keine hardwarespezifischen Funktionen genutzt.
• eine Headerdatei, die von anderen Teilen des Codes eingebunden wird und die die Schnittstelle, die das Modul bereitstellt, beschreibt (Prototypen). Auch hier werden keine hardwarespezifischen Funktionen genutzt.
• eine Configurationsdatei, die das Modul konfiguriert, also z.B. besagt, wie groß ein Puffer/Speicher oder sonstiges in dem Modul ist, ob etwas aktiviert ist oder nicht, was für Koffizienten genutzt werden, etc...
• eine hwdatei (Hardwaredatei), in der beschrieben ist, welche Hardware und/oder anderen Module das Modul braucht. Beispielsweise also die RS232-Anbindung an das "debug" Modul, das seinen Debuggingoutput über RS232 versendet.

Diese Dateien sind nun alle in dem Quellverzeichnis wie folgt organisiert (Ausschnitt aus documentation.txt):

autopilot ist das Wurzelverzeichnis

• terminal Hier sind die Quellcodedateien für das "Terminal" drinnen, welches aber noch absolut unvollständig und nicht funktionsfähig ist.
• main Hier sind die Dateien für den Autopiloten drin, also dem Teil, der die eigentlich Intelligenz beinhaltet.
  • config_* Hier sind die Dateien drin, die die einzelnen Module des Autopiloten "konfigurieren". z.B. in cli_conf.h steht drin, dass das CLI (Command Line Interface, die Serielle zum PC) einen Eingangspuffer von 16 Byte hat und eine maximale Zeilenlänge von 160 Zeichen. Weiterhin steht in den *hw.h Dateien drin, auf welche Hardwaremodule jedes einzelne Modul zurückgreift. Also z.B. findet sich in rudder_hw.h die Information, dass der Ruderpositionsrückmelder an den ADC0 und ADC1 Eingang angeschlossen ist.
  • hw_* In diesem Verzeichnis finden sich die benötigten Peripheriemodule als c-Code. Also Code für Timer, Uart, Einlesen der Drehsensoren, des NMEA codes etc.
  • filter Hier gibt es verschiedene Implementationen von Filtern, eine Auswahl.
  • input In diesem Verzeichnis sind alle Dateien drin, die die erzeugen und aquirieren (also z.B. der Abgleich von GPS-Kurs zum Gyrosensor-kurs).
  • interface Hier gibt es Dateien, die irgendwie ein Interface des Autopiloten darstellen, das CLI, das CI (Control Interface).
  • output Alle Ausgabeteile des Autopiloten, momentan nur das Ruder
  • pilot In diesem Verzeichnis findet sich der Regelreis des Autopiloten, also der Teil der den Piloten darstellt.
  • misc Hier findet sich das, was in keines der vorherigen passt.
• control Hierin befindet sich (ähnliche Struktur wie bei main) der Code für die Kontrolleinheit des Autopiloten, das ist die Kiste im Cockpit, wo man normalerweise draufdrückt um den AP zu bedienen.
• common In diesem Verzeichnis sind Dateien drin, die in mehreren Unterverzeichnissen genutzt werden, also main, control oder terminal. In den jeweiligen Unterverzeichnissen sind dann nur symbolische Verknüpfungen (Symbolic Links) gesetzt, so dass der Code nur einmal geschrieben und gewartet werden muss. Das stellt sicher, dass überall der selbe (möglichst fehlerfreie) Code drin ist. Weiterhin ist es nicht nötig den Code doppelt zu pflegen.

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.

Nachbau

Der Nachbau des Autopiloten ist nicht schwierig, wenn man folgende Ratschläge beachtet:

• Die mechanischen Aufbauten kann man leicht gebraucht kaufen (Trödel, Ebay, ...)
• Die Verwendung eines GPS ist für diesen Autopiloten notwendig.
• Verwendet man das hier vorgeschlagene Platinenlayout, kann man den Quellcode 1:1 übernehmen. Sonst fällt eine kleine Anpassung der Dateien in hw/ und config/ an, die aber auch selbsterklärend sein sollt, dank ausreichend Kommentaren im Code, siehe auch Aufbau des Quellcodes

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!

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!

Schritt 3: Haupteinheit zusammenstellen

Die 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.

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.

Ressourcen

Quellcode

Der aktuelle Sourcecode und Schaltplan lässt sich herunterladen unter:

• SVN Repository als GNU Tarball

oder direkt durch SVN auschecken oder im Browser anschauen:

• svn://mikrocontroller.net/autopilot

Known-to-be-working Revisions im SVN:

• r164: Control und Main Code läuft, Autopilot bedienbar, Autopilot steuert korrekt.

Schaltplan

Der aktuelle Schaltplan liegt im SVN.

ToDos

* Artikel vervollständigen
* common/body.mk: info-Target: auch .h Dateien mitzählen (Quellcodezeilen etc) ;-)
* Kurzen Artikel zum Terminal schreiben

History

2011-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