Autopilot

by Clemens Helfmeier

Last update: 2010-04-21 (initial page)

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

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.

Steuerung

Die Steuerung der Richtung des Fahrzeugs geschieht mithilfe 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:

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

Paket Layer (atp.c)

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.

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, als 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-1.3.3 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 kann 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

Schaltplan

Der aktuelle Schaltplan liegt im SVN.

ToDos

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

History

2010-04-27 SVN Repository populated
2010-04-21 initial page