Autopilot im Eigenbau - ein Baubericht

[Joerg Pauly]

Hallo, zusammen,

ich habe für mein Schiff einen Autopiloten entworfen, der auch in Binnengewässern das Schiff auf Linie halten kann und überdies die Möglichkeit bietet, über eine Kabel- oder Funksteuerung das Schiff manuell zu steuern.

Zur Zeit bin ich gerade dabei, das System zu bauen und die Software dafür zu entwickeln.

Habt Ihr Interesse an einem Baubericht?

[Hardy20]

Zitat von Joerg Pauly

Habt Ihr Interesse an einem Baubericht?

Ja bitte, haben wir!

[Emma]

Zitat von Joerg Pauly

Habt Ihr Interesse an einem Baubericht?

Jo, bitte!

[NotMe]

Zitat von Joerg Pauly

Hallo, zusammen,

ich habe für mein Schiff einen Autopiloten entworfen, der auch in Binnengewässern das Schiff auf Linie halten kann und überdies die Möglichkeit bietet, über eine Kabel- oder Funksteuerung das Schiff manuell zu steuern.

Zur Zeit bin ich gerade dabei, das System zu bauen und die Software dafür zu entwickeln.

Habt Ihr Interesse an einem Baubericht?

Hier, ich.

[Fritz682]

kommen lassen , bitte

[Joerg Pauly]

Ziel des Projektes:

Ein AP, der auch in Binnengewässern mithilfe der Software WinGPS5Pro entlang der Wasserstrassen navigieren kann.
WinGPS5Pro verfügt zusammen mit den ANWB-Karten über ein Wasserstrassen-Netz, mit dessen Hilfe man es wie ein Navi für Autos nutzen kann. Angabe von Start- und Zielpunkt, und das Programm findet eine Route.
Die einzige Problematik hierbei: Die Linien des Netzes verlaufen immer ziemlich genau in Fahrwasser-Mitte, wo man nichts zu suchen hat.
Was also, wenn es einen AP gäbe, dem man auftragen kann, sich immer "X" Meter rechts oder links neben der Linie zu halten?

Mir ist kein im Handel erhältliches System bekannt, das das vermag... von der Unwilligkeit, eine vierstellige Summe dafür auszugeben, mal ganz abgesehen...

Also selber bauen!

Als Grundlage dient hier ein Mikrocontroller-System des Typs "C-Control Pro". Dieses System ist in mehreren Ausbaustufen erhältlich. Für meinen Zweck schien das "C-Control Pro 128 Application Board" am zweckmäßigsten, da es ein 2x8-Zeichen-Display und eine Wähltastatur gleich mitbringt.

Ebenso wird ein Entwicklungssystem mitgeliefert, welches sich sehen lassen kann. Programmiert wird in "CompactC", einem abgespeckten C-Dialekt, oder in BASIC. Meine Software wurde in CompactC entwickelt. Als oller C++-Hacker mag ich die C-Syntax nun mal...

Was brauchen wir sonst noch?

Ein AP muss wissen, wo sein Ruder steht. Nur dann kann er es zielgerichtet fahren.
Ein Ruder-Sensor muss her.
Diese Aufgabe übernimmt ein Lineares 47k-Dreh-Potentiometer. Linear deshalb, weil dann in der Mitte ziemlich genau der definierbare Nullpunkt liegt.
Es wird mit 5V beaufschlagt und der Schleifer wird mit einem der Analog-Digital-Wandler (Port F) verbunden. Dieser Wandler (ADC) hat eine Auflösung von 10 Bit, kann also 1024 Schritte ausgeben. Für eine Auswertung von -100% (Bb) bis +100% (StB) reicht das ganz bequem.

Natürlich benötigen wir einen Stell-Motor.
Da unsere Rudersteuerung auf Seilzügen basiert, tut hier ein Getriebemotor gute Dienste. Für unser Vorhaben empfiehlt sich ein 12V/8A-Motor mit Schneckengetriebe.

Damit ergibt sich ein weiteres Erfordernis:
Dem Controller darf man bei 5V maximal 20mA entziehen, sonst gewöhnt er sich das Rauchen an. Es muss also eine Leistungs-Verstärkung her, am besten in Form einer H-Brücke. Diese läßt sich mit MOSFETs sehr schön realisieren. Welche genau, muss noch errechnet werden.

Im einfachsten Fall kann man auch Relais-Paare verwenden. Aber auch die brauchen mehr als 20mA bei 5V, um anzuziehen. Hier helfen NPN-Transistoren weiter, die bei 5V an der Basis das Relais vom Kollektor zum Emitter nach GND durchschalten.

Paare deshalb, weil der Motor komplett umgepolt werden muss. Schaltet man also jeweils ein rechts-gepoltes und ein links-gepoltes Paar, so kann nichts passieren. Man muss nur bei der Entwicklung der Software für den Controller darauf achten, dass niemals beide Paare zusammen anziehen können. Das würde nämlich einen Kurzschluss verursachen, der nur Unannehmlichkeiten zur Folge hat...

Damit lässt sich das Ruder schonmal anfahren. Über die manuell zu betätigende Kupplung machen wir uns später Gedanken...

WinGPS ist in der Lage, diverse NMEA-Sätze an den AP zu übermitteln. Bevor wir uns damit beschäftigen, welche Informationen wir wie verarbeiten, sollten wir diese Sätze zunächst mal empfangen können.

NMEA-Schnittstellen basieren auf RS232, also der alten seriellen Schnittstelle. Diese musste auf beiden Seiten gleiche Parameter aufweisen.
Für NMEA-Daten ist der Standard 4800 Baud, 8N1.

Damit initialisiert man die Schnittstelle des Microcontrollers. Wichtig ist, dass sie im Interrupt-Modus arbeiten muss, sonst friert das ganze System ein, solange keine Daten empfangen werden.


Spätestens jetzt sollte klar sein, dass man ohne Multithreading nicht weiter kommt.
Der Rudersensor muss auch während eines Ruderlage-Befehls ständig Daten senden können. Währenddessen muss die COM-Schnittstelle ständig auf neue NMEA-Sätze überprüft werden, die es zu parsen gilt, und mit deren Daten neu gerechnet werden muss. Und dann haben wir ja auch noch das Bedien-Panel, wo wichtige Daten geändert werden können...

---

Im nächsten Beitrag entschlüsseln wir die NMEA-0183-Datensätze, anhand derer unser AP errechnet, wie er das Ruder fahren muss.

[Joshua Slocum]

Heftiges mit den Armen winken um größtes Intresse an der Sache zu bekunden.

Gruß Robin

[Achko]

Zitat von Joerg Pauly

Ein Ruder-Sensor muss her.
Diese Aufgabe übernimmt ein Lineares 47k-Dreh-Potentiometer. Linear deshalb, weil dann in der Mitte ziemlich genau der definierbare Nullpunkt liegt.
Es wird mit 5V beaufschlagt und der Schleifer wird mit einem der Analog-Digital-Wandler (Port F) verbunden. Dieser Wandler (ADC) hat eine Auflösung von 10 Bit, kann also 1024 Schritte ausgeben. Für eine Auswertung von -100% (Bb) bis +100% (StB) reicht das ganz bequem.

Hallo Jörg,

Vielleicht ein Tipp? Statt Poti kann man auch sowas hier verwenden (s.Anhang).
Die Dinger kosten zwar ca. 40 Euro (Industrie-Sensorik!), sind aber absolut zuverlässig (verschleissfrei) und präzise (driftfrei).
In meiner Firma (Sondermaschinenbau) laufen diese Teile in rauhester Industrie-Umgebung (Schmutz,Feuchtigkeit,..)
seit Jahren fehlerfrei. Normale Poti's (Draht oder Kohle) werden bei uns nicht mehr verwendet.
Diese Winkelsensoren gibt es in den unterschiedlichsten Größen und Bauformen.

[Joerg Pauly]

Hallo, Achim,

Zitat von Achko

Vielleicht ein Tipp? Statt Poti kann man auch sowas hier verwenden (s.Anhang).

Die kannte ich noch nicht...

Meine Potis sind jetzt schon verbaut, drum lass ich sie erstmal drin, aber sollten sie mal den Löffel reichen, weiß ich bescheid.

Vielen Dank für den Tipp!

[T-Technik]

Hallo Jörg,

da stimme ich Achim voll zu, keine Potis zu verwenden .
Der Stellmotor würde sonst bestimmt oft ins Flattern kommen .
Weitere Gründe sind ja genannt .


Am besten voll digital ermitteln u. das gleich mit einer Reset-
oder 0-Punkt-Kontrolle .


Ansonsten spannendes Thema u. Vorhaben !!!

Werde es gerne verfolgen .


Grüße : TOMMI

[Fishaholic]

Ich hätte den Vorschlag gemacht Hall Sensoren für die Ruderlage zu nehmen, aber das Teil aus den Link von oben sieht auch interessant aus. Zudem ist das Poti ja schon verbaut.
Machst Du das ganze als open source zum Nachbauen für jeden und teilst auch den Code zum Anpassen und nachbrennen?

[Achko]

Zitat von Fishaholic

Ich hätte den Vorschlag gemacht Hall Sensoren für die Ruderlage zu nehmen

Hallo Steffen,

schuuuups, das Teil aus den Link ist ein Hall-Sensor !

Zitat von Fishaholic

Zudem ist das Poti ja schon verbaut.

Joerg spricht in seinem Beitrag im Plural -> Poti's. Ich gehe einfach mal davon aus, daß er die Sensorik aus
Sicherheitsaspekten 2-kanalig ausführt und somit auch eine Störung (mechanisch wie elektrisch) sofort erkennen und signalisieren kann.
Ist vermulich nicht unwichtig, wenn man auf einem schmalen Fluß mit "Autopilot" fahren möchte?

[Joerg Pauly]

Zitat von Achko

Hallo Steffen,

schuuuups, das Teil aus den Link ist ein Hall-Sensor !



Joerg spricht in seinem Beitrag im Plural -> Poti's. Ich gehe einfach mal davon aus, daß er die Sensorik aus
Sicherheitsaspekten 2-kanalig ausführt und somit auch eine Störung (mechanisch wie elektrisch) sofort erkennen und signalisieren kann.
Ist vermulich nicht unwichtig, wenn man auf einem schmalen Fluß mit "Autopilot" fahren möchte?

Genau so ist es:
Vorgesehen sind 2 Potis, die gegeneinander abgeglichen werden. Wird eine (noch zu ermittelnde) Toleranzschwelle überschritten, steigt das System mit einer lauten Warnung aus.

Zitat von Fishaholic

Machst Du das ganze als open source zum Nachbauen für jeden und teilst auch den Code zum Anpassen und nachbrennen?

Ich hatte vor, das System nach einer ausgiebigen Testphase als Bauanleitung zu veröffentlichen.
Aufgrund schlechter Erfahrungen mit Patentjägern habe ich den Quellcode unter meine eigene Lizenz gestellt, werde ihn also nicht als Ganzes veröffentlichen. Aber Images der Firmware stelle ich Interessierten gerne zur Verfügung; bzw. brenne ich sie auf eine C-ControlPro128-Unit, die man mir zuschickt.

Meine Parser-Routinen haben sich gerade schwer bewährt, nur noch Kleinkram muss nachgebessert werden.
Am Samstag gibt es dann den Beitrag darüber, wie man NMEA-Daten auseinander pflückt... ;)

[Joerg Pauly]

Bei der Analyse der Daten fällt sofort auf:
NMEA-0183-Sätze werden im ASCII-Format übertragen; also im Klartext!

Welche Sätze es gibt und wie sie aufgebaut sind, kann man hier nachlesen:
http://www.nmea.de/nmea0183datensaetze.html

Im NMEA-Netz wird zwischen "Talkern" und "Listenern" unterschieden. Eine simpele USB-Maus ist definitiv ein reiner Talker, sie kann nur senden. Für sie wird unter Windows ein virtueller COM-Port eingerichtet, unter dem die Navigations-Software die NMEA-Sätze der Maus empfangen kann. Die Software tritt der Maus gegenüber also als Listener in Aktion.

Der AP wird nun über eine weitere (virtuelle) COM-Schnittstelle angeschlossen. Diese COM-Schnittstelle ist dann der Talker für den AP, der der Listener ist.

Bei der Navi-Software beziehe ich mich auf WinGPS von Stentech, und zwar die Version 5Pro. Andere Produkte können sich erheblich unterscheiden, vor allem was den Output an den AP angeht.

Im Navi-System kann man diverse Satz-Formate an- und abwählen. Hier gilt es nun zu bestimmen, welche Informationen ich brauche und in welchen Sätzen sie enthalten sind.

Der AP ist in der Lage, die Sätze APB, BWC, BOD, RMC, und XTE auszuwerten; was aber nicht heißen soll, dass man sie alle senden muss. Es ist sogar zweckmäßig, die Anzahl der Formate auf drei zu begrenzen.
NMEA-Daten werden nämlich im Sekundentakt aktualisiert. Schaut man sich die Länge gewisser Sätze an und legt dann zugrunde, dass bei einer Standardeinstellung von 4800 Baud pro Sekunde 600 ASCII-Zeichen übertragen werden können, kann man sich leicht vorstellen, wie schnell es auf der Schnittstelle zum Stau kommen kann...

Für meine persönliche Installation habe ich die Schnittstelle auf 19.200 Baud getaktet; einfach um sicher zu gehen, dass nichts verloren geht...

Es gilt nun, den Datenstrom in einen Puffer zu schreiben, bis das LF (Ascii 13) auftaucht. Mit CR+LF wird jeder NMEA-Satz abgeschlossen.
Mit den Zeichen an Stelle 4-6 lässt sich nun bestimmen, um welchen Satz es sich handelt.
Dann wird der Satz in Teil-Strings zerlegt, indem man jeweils von Komma bis Komma liest und die Einzelwerte in eine eindimensionale Matrix schreibt.
Anhand des Satz-Formates kann man nun zielgerichtet die Werte herauslesen, mit denen man rechnen möchte.

Mein AP benötigt dazu folgende Werte:

float xte; //Track-Abweichung in Metern, negativ = links
float dtw; //Distance to Waypoint in Metern
float btw; //Bearing to waypoint, Basis 360°
float htw; //recommended Heading to Waypoint, rechtweisend
float tog; //Track over Ground, rechtweisend
float tts; //Track to Steer, rechtweisend (Kurs der Plan-Linie)
float cts; //Course to Steer, rechtweisend
float xta; //Track Angel, Winkel TOG<>CTS, negativ = links
float sog; //Speed over Ground, km/h

WinGPS sendet z.T. andere Einheiten, so kommt der XTE z.B. in NM und SOG wird in kt angegeben. Dies wird schon beim Parsen der Daten umgerechnet.

Ebenso wird XTE in Verbindung mit "Direction To Steer" angegeben, die 'L' oder 'R' sein kann. Damit kann man nicht rechnen...

Sind wir aber z.B. 25 m neben der Linie und müssten nach rechts steuern, dann sind wir links versetzt. Alles, was links ist, ist negativ, also wird der XTE-Wert in diesem Fall einfach negiert. Damit lässt sich rechnen!

Und genau mit dieser Rechnerei befasse ich mich jetzt, denn alle Daten, die ich dafür brauche, habe ich jetzt.

Fortsetzung folgt...

[Achko]

Hallo Jörg,

alles sehr spannend !

Richtig neugierig aber bin ich auf deinen Software-Regler fürs Ruder. Vermute mal daß hier >80% deines Programmier-Aufwandes stecken werden.
Und dann kommt noch die Zeit die Reglerparameter an Dein Schiff anzupassen....

Viel Erfolg beim Umsetzen !

[Fishaholic]

Hätte mir den Link wohl genauer ansehen sollen, mir es aber auch denken können. Was solls denn sonst sein ;)

Viel Erfolg und Geduld bei der Arbeit! Ich werde es gespannt weiter verfolgen!

Willst Du Dich auf die Kartendaten und damit auf die GPS Tracks verlassen, oder integrierst du einen interupt per Echolot Tiefenalarm? Die meissten haben doch glaube ich auch NMEA Format...
... Wenn du schon mal dabei bist :p

[Joerg Pauly]

Hallo, Achim,

Zitat von Achko

Richtig neugierig aber bin ich auf deinen Software-Regler fürs Ruder.

Der ist vom Entwurf her schon fertig und hat sich auch in Simulationen bisher sehr bewährt.

Ich habe bemerkt, dass man sich dem Ganzen von zwei Seiten nähern muss, nämlich von der Seite, von der die Daten kommen, und von der, die den physischen Ausschlag gibt.

Das ganze System muss eh in voneinander nahezu unabhängige Segmente (aka: Threads) unterteilt werden.

Da sich ein Schiff auch während der Ausführung des Ergebnisses einer Berechnung bewegt, können sich die dieser Berechnung zugrunde liegenden Daten ändern. Schon die Bewegung des Schiffes muss dem Rechnung tragen, indem das die Bewegung verursachende Element (normalerweise Du oder ich, jetzt aber der VoyagerAutohelm) von vornherein die Bewegung - und damit die sich ändernden Daten - berücksichtigt.

Es gibt keinen Computer, der die Präzision und die Schnelligkeit eines organischen Gehirnes erreichen kann.

Was er wohl kann, ist, aufgrund von unanfechtbaren Daten Aktionen aufgrund von einfachen Berechnungen durchzuführen. Bei der Formulierung dieser Algorhytmen muss man sein eigenes, menschliches, Reaktionsvermögen analysieren... was schon schwierig ist...

Nein, man könnte es auch gleich als unmöglich bezeichnen.

Wäre es adaptierbar, bräuchten heutige Kfz keinen Fahrer mehr...

Das funktioniert auf See und in der Luft, weil die Gefahr einer Begegnung recht gering ist.
Aber selbst dort gibt es die automatische Kommunikation zwischen den Verkehrsteilnehmern:

In der Luft nennt man das System "TCAS",
auf dem Wasser heißt es "AIS".

Es ist eine Frage der auswertenden Software, wie sie auf Alarme reagiert.

Viel Erfolg beim Umsetzen !

Besten Dank!!!

[Joerg Pauly]

Zitat von Fishaholic

Willst Du Dich auf die Kartendaten und damit auf die GPS Tracks verlassen, oder integrierst du einen interupt per Echolot Tiefenalarm? Die meissten haben doch glaube ich auch NMEA Format...
... Wenn du schon mal dabei bist :p

Ja, richtig, es gibt Echolote mit NMEA-Ausgang.

Aber neben dem Wassersport, der für mich eine Weiterführung alter Familien-Traditionen bedeutet (ich bin auf Schiffen aufgewachsen) bin ich auch noch Pilot und Fluglehrer, und damit steht für mich eines ganz klar im Focus:

Niemals darf man sich auf Technik verlassen! Sie mag noch so gut sein, sie mag noch so angepasst und ausgefeilt sein, aber sie kann jederzeit versagen.

Jede Technik, die den Verantwortlichen entlastet, muss überwacht werden. Auf Schiffen gibt es dafür die "Watch-Men", die früher "Wach-Offiziere" genannt wurden, im Cockpit eines Flugzeuges erledigt das die Flight Deck Crew, bestehend aus Captain und First Officer (aka: Co-Pilot).

Wer einen Autopiloten unbeaufsichtigt werkeln lässt, geht ein unkalkulierbares Risiko ein, denn jedes - auch mehrfach redundante - System kann sich unbemerkt verabschieden.

Darum arbeitet der VoyagerAP nur aufgrund der GPS-Daten, die ihm vom Navigationsrechner angedient werden. Die Verantwortung liegt jedoch nach wie vor beim Skipper.

Fahrwasser haben keine definierte konstante Breite.
Ein Tiefenmesser kann nicht sagen, ob es auf StB oder Bb tiefer ist.
Das ist m.E. auch nicht Sinn der Sache. Im Grunde hat der VoyagerAP gar keinen tieferen Sinn...; ich wollte nur wissen, ob ich sowas bauen kann...

Wenn er mir aber erlaubt, auch mal von der Haspel weg zu gehen, ohne den Blick auf's Wesentliche zu verlieren, dann nimmt er mir Arbeit ab. Genau so arbeiten die APs der großen Pötte, und genau so arbeiten die APs von Verkehrs-Flugzeugen. Die erfüllen genau diesen einen Zweck; sie wollen den Cpt. nicht ersetzen, sondern entlasten.

[wolfgang_]

Zitat von Joerg Pauly

Wenn er mir aber erlaubt, auch mal von der Haspel weg zu gehen, ohne den Blick auf's Wesentliche zu verlieren, dann nimmt er mir Arbeit ab. Genau so arbeiten die APs der großen Pötte, und genau so arbeiten die APs von Verkehrs-Flugzeugen. Die erfüllen genau diesen einen Zweck; sie wollen den Cpt. nicht ersetzen, sondern entlasten.

Wobei das Maß der Entlastung mit der Gewässergröße drastisch abnimmt. Auf großen Gewässern (z.B. See) könnte der AP längere Zeit autark arbeiten, hingegen auf engen Flüßen wohl eher nicht. Ich fahre häufig auf der Mosel, wenn dann noch ein größerer Pott kommt und die Freizeitskipper umher fahren, da würde ich das Steuer keine Sekunde aus den Augen lassen.

Außerdem stelle ich mir das mit dem Versatz von der Mitte der Fahrrinne hier schwierig vor, da die Fahrrinne stellenweise schmal ist.

Aber trotzdem interessantes Projekt, werde weiter verfolgen und bin auf erste Ergebnisse gespannt.
Hast du mal überlegt als Controller einen Atmel mit Bascom einzusetzen? Die sind deutlich preiswerter als die C-Control, die ja eigentlich nur ein modifizierter Atmel ist.

[Fishaholic]

Und wäre für den "Laien" einfacher nachzubrennen. Hat sich aber ja eh erledigt, das Problem mit Patentjägern kann ich gut verstehen. Um die Programmierkenntnisse beineide ich Dich, ich tu mir schon schwer nem Atmega kleien Aufgaben erledigen zu lassen.

[soenke]

Für alle, die C-Control nicht mögen und Open Source lieben:
http://www.boote-forum.de/showthread.php?t=40410
bzw.
http://www.mikrocontroller.net/articles/Autopilot

Vielleicht hast Du, Jörg, ja Lust, Dich da ist dranzuhängen. Könnten alle von profitieren.

[sumsum]

Hallo Joerg,

es lässt sich einrichten, auf einem Gewässer "entlang" zu fahren. Ich habe das mit meinem Autopiloten bis zu 20min hinbekommen, allerdings nur mit danebensitzen, damit er auch schön artig ist . Da meiner geradeaus fährt ging es natürlich auch nur auf einem Kanal, allerdings ist das Abfahren mehrerer GPS-Punkte unproblematisch, so dass ich auch erwarte, dass er eine Route abfahren können müsste.

Schöne Grüße,
Clemens

[Joerg Pauly]

Zitat von soenke

Für alle, die C-Control nicht mögen und Open Source lieben:
http://www.boote-forum.de/showthread.php?t=40410
bzw.
http://www.mikrocontroller.net/articles/Autopilot

Vielleicht hast Du, Jörg, ja Lust, Dich da ist dranzuhängen. Könnten alle von profitieren.

Ich liebte Open Source, habe mich an vielen Projekten beteiligt und auch eigene betrieben..., bis zu dem Tag, als mir die Nutzung eines von mir selbst entwickelten Programmes unter Androhung drakonischer Strafen untersagt wurde. Jemand hatte einfach aus den Quellen die GPL-Vermerke entfernt und es als sein geistiges Eigentum erfolgreich schützen lassen; und dieser Jemand stellte es dann so dar, als hätte ich proprietäre Quellen zu Unrecht mit meinem Copyright-Vermerk versehen und unter die GPL gestellt. Seit dem verdient dieser Jemand mit diesem System gutes Geld, und ich habe nicht mal mehr das Recht, dies zu beklagen, durfte sogar noch Schadenersatz leisten.

Seitdem stelle ich nützliche Software, die ich entwickele, zwar jederman zur Nutzung zur Verfügung, halte aber die Quellcodes unter Verschluss, dafür bitte ich einfach um Verständnis.

Sei's drum, Shit happens...

Meine Ruder-Ansteuerung erfährt gerade eine grundlegende Rund-Erneuerung, da ich mit Hilfe eines absoluten Elektronik-Profis die Treiber-Hardware auf eine neue Basis gestellt habe. Hiervon ist natürlich auch die Software-Seite betroffen. Die Anpassungen sind in vollem Gange, denn eine Leistungs-H-Brücke will vernünftig angesteuert werden.

Ich bin gerade selber total gespannt, was dabei rauskommt...

[sumsum]

Hallo Jörg,

das finde ich aber sehr ärgerlich! Es ist doch eine Frechheit, wenn einem etwas "vor der Nase weggenommen" wird und man nichts dagegen tun kann. Mich würden die genaueren Umstände dazu nur zu gerne interessieren.

Ich hoffe, dass das bei einem Projekt an dem viele Personen mitarbeiten weniger wahrscheinlich ist, oder was meinst Du?

Schöne Grüße,
Clemens

[Joerg Pauly]

Wie gesagt, ich darf mich dazu öffentlich nicht äußern, und mittlerweile ist der Zorn verraucht. Aber die Lehre bleibt.

Nun denn, die Frage, wie man mit einem PWM-Port, der bei 5V nur mit 20mA belastet werden darf, einen 12V-5A-Motor ansteuert, ist beantwortet.
Das Geheimnis ist eine H-Brücke mit drei-stufigem Treiber.



Kurz zur Erklärung:
Über je einen PNP- und zwei NPN-Transistoren werden je ein N-Type- und ein P-Type-MOSFET durchgesteuert, die dann von Vcc über den Motor nach GND durchschalten.

Diese Schaltung kann mit einer Periode von 1 kHz umgehen, was ein sehr sanftes Anfahren und eine sehr feine Regelung des Motors ermöglicht.

Nebenbei: das Poti für die Ruderlagen-Erkennung habe ich durch einen Hall-Sensor mit 105° Drehwinkel ersetzt. Dadurch wird auch die Mechanik vereinfacht, denn dieser wird jetzt einfach vom Steuerseil über einen Hebel angelenkt.

Auf der Software-Seite wird es spätestens nach Einbau des Ruder-Triebes nötig werden, die Steuerung einzumessen.

Wir müssen wissen:
- welchen Ruderlagen-Wert haben wir bei Vollausschlag Backbord?
- welchen Ruderlagen-Wert haben wir bei Vollausschlag Steuerbord?
- welchen Ruderlagen-Wert haben wir bei Neutralstellung?

Diese Werte können dem System über das Bedienfeld mitgeteilt werden.
Dazu gibt es ein Menü "Settings" -> "Rud.Val.", und hier die drei Punkte ">>>Stb", "Bb<<<" und ">>>0<<<".
Man ruft z.B. ">>>Stb" auf, dreht das Ruder voll nach Steuerbord und betätigt dann die #-Taste. Der Wert wird daraufhin im EEPROM gespeichert.
Hat man gleiches mit Neutral und Bb gemacht, liegen dort drei Werte. Genau genommen liegen dort zwei Strecken, nämlich Voll-Bb nach Neutral und Neutral nach Voll-Stb. Diese werden nun einfach zur Basis 100 umgerechnet, und schon hat man eine Skala, nach der der AP arbeiten kann, ohne sich mit den Roh-Daten lange zu beschäftigen.

Die Software definiert die Ruderlagen jeweils in % pro Seite und bedient sich einer Stufen-Tabelle, nach der in Abhängigkeit zur Kursabweichung der Soll-Ausschlag bestimmt wird. In Verbindung mit der Ruderlage ergibt sich ein positiver (StB) oder negativer (Bb) Wert, der direkt auf die Geschwindigkeit, auf die der Stellmotor gebracht wird, Einfluss hat.

Auf diese Art setzt der AP die Goldene Regel der Kleinstmöglichen Ausschläge um:

Große Kursabweichung = großer Ruderausschlag, und umgekehrt.
Großer zurückzulegender Ruderweg = schnelle Ruderbewegung, und umgekehrt.

Diese ganzen Berechnungen laufen aber parallel weiter, und dadurch kann der AP die Antwort des Schiffes direkt umsetzen.
Nähert sich das Ruder seiner Soll-Position, wird es langsamer.
Wird die Kursabweichung kleiner, nimmt der AP den Ausschlag zurück,
Nähert sich das Schiff der geplanten Linie, verkürzt der AP den Winkel und schwingt in einem weichen Bogen in die Kurslinie ein.

Die dazu benötigten Algorythmen sind recht eingängig und gar nicht mal so umfangreich.
Der Witz besteht darin, dass die Software nicht einen Korrekturbefehl sequenziell abarbeitet, sondern dynamisch auf die sich ständig ändernden Daten der GPS-Quelle und der eigenen Sensoren reagiert.

Vorraussetzung dafür ist eine MCU, die Multithreading erlaubt. Ein Programmteil ist nur damit beschäftigt, die NMEA-Daten aus der GPS-Quelle zu lesen und die Werte in die globale Daten-Matrix zu schreiben.
Ein anderer erzeugt aus den Daten der Matrix pausenlos neue Einstiegs-Werte für den Ruder-Steller.
Der widerum bekommt laufend den aktuellen Ruderstand, vergleicht ihn mit der Soll-Lage und errechnet daraus die Motor-Ansteuerung.

Das ganze passiert alle 10 ms.
D.h. 100 mal pro Sekunde steht der AP vor einer völlig neuen Situation. Die Physik will, dass sich diese Situation von der vorherigen nur geringfügig unterscheidet, was zur Folge hat, dass die Aktionen des AP immer sehr feinfühlig ausfallen.

Hat man nicht gerade einen brutalen ZickZack-Kurs mit Kurssprüngen von kurz unterhalb 180° programmiert, wird man schon genau hinsehen müssen, um überhaupt die Aktionen des AP wahrzunehmen.