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.

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