Über die Ackermann Geometrie und die neue Kommunikationsschnittstelle

Dieser Artikel befasst sich mit der angekündigten Optimierung der Datenübertragung zwischen RController (dem Steuerungsrechner) und RMaster (dem ODroid-SOC am Rover), sowie der neuen Berechnung der Radstellungen für eine saubere Manövrierbarkeit. Die hier vorgestellten Optimierungen lösen die beobachteten Probleme aus dem letzten Demonstrationsvideo, wie man auch im nächsten Video erkennen können wird.

Probleme mit der alten Lenkung

Bei der letzten Testfahrt war die Lenkung noch naiv implementiert: Die vorderen Räder standen parallel zueinander in die jeweilige Lenkrichtung geneigt und die hinteren machten das Gegenteil. Dies funktionierte für die ersten Tests gut, jedoch ergaben sich schnell Probleme mit diesem Ansatz, die schnelle Lenkmanöver verhinderten. Es war nicht möglich, schnelle Kurven zu fahren, ohne immer jeweils zwei Räder am Boden schleifen zu lassen, was unsere Manövrierfähigkeit stark einschränkte und den minimalen Kurvenradius sehr groß hielt.

Alte Lenkung

Zum Glück gibt es aber Methoden um diese Schwierigkeiten vollständig zu umgehen, allen voran die von Georg Lankensperger erfundene Achsschenkellenkung welche auch als Ackermann-Geometrie (vom Engländer Rudolph Ackermann patentiert) bekannt ist. Mit diesem Ansatz setzt man sämtliche Räder auf gedachte Kreisbahnen, welche dem gewünschten Lenkwinkel relativ zu ihren Abständen vom Zentrum des Rovers entsprechen.

Realisierung der Ackermann Geometrie

Dieser alternative Lenkansatz ist etwas aufwendiger zu implementieren als die alte Lenkung, was sich allerdings durch die Architektur der Roversoftware in Grenzen hält. Die gesamte zusätzliche Komplexität versteckt sich im Regulation Kernel, welcher die neuen Radstellungen für jeden Lenkausschlag mittels kurzen trigonometrischen Formeln in für RBreakout am Arduino verständliche Servo-Kommandos umsetzt. Als Beispiel der umgerechneten Lenkwinkel (nicht realitätsgetreu, da die Lenkung intern noch weiter angepasst wird bevor sie weitergeschickt wird) dient die folgende Grafik. Die X-Achse stellt den Lenkausschlag dar, während die Y-Achse den jeweiligen Ausschlag jedes einzelnen Servos repräsentiert.

Dieser angepasste Regulation Kernel wurde danach auf den ODroid übertragen, um sich beim starten direkt an die zentrale orchestrierende Softwarekomponente, RMaster, zu verbinden. Ändert man den gewünschten Lenkwinkel, rechnet dieser optimierte Kernel die Kommandos in praktische Lenkausschläge um, die genau auf den gewünschten Kreisbahnen liegen. Diese Änderung kann man im nächsten Bild des Rovers mit Lenkausschlag auch sehr gut erkennen.

Neue Lenkung.

Mit diesen optimierten Radausschlägen kann VERNER nun engere Kurven bei höheren Geschwindigkeiten verlässlich halten. Außerdem ist die Lenkgenauigkeit stark gestiegen, da man jede Bewegung des Rovers besser vorhersagen und somit im Kopf auch besser planen kann, wie sich das Fahrzeug genau bewegen soll. Die Übersetzung zwischen Joystickausschlägen und der Lenkung fühlt sich sehr direkt an und man kann das gesamte Fahrwerk mehr belasten. Die neuen Fähigkeiten dieser verbesserten Berechnungen kann im nächsten Demo-Video betrachtet werden.

Verbesserungen in der Datenübertragung

Die Übertragung zwischen Steuerungs-PC (also der RController-Software) und dem Rover (RMaster-Programm) läuft in der jetzigen Konfiguration über WLAN. Der Netzwerk-Stack stellt verschiedene Möglichkeit der Übertragung zur Verfügung, allen voran TCP Streams und UDP Datenfragmente. Früher wurde der Rover vollständig über einen TCP-Stream gesteuert, was viele Vorteile bietet gegenüber der Verwendung unverlässlicher UDP-Protokolle. Beispielsweise können über den TCP-Stream keine Befehle in der falschen Reihenfolge ankommen oder gar ganz verschwinden, was bei UDP durchaus häufig passiere.

In der sehr zeitkritischen Anwendung bei VERNER müssen diese Vorteile allerdings gegen den großen Nachteil der unverlässlichen Übertragungszeit gerechnet werden. Wurde beispielsweise eine Nachricht verloren, wartet der Rover bis ein Timeout ausgelaufen ist, bis nachgefragt wird, wo der Befehl geblieben ist, woraufhin die Nachricht erst ein weiteres Mal übertragen wird. Steuert man gerade auf ein Hindernis zu, können diese kurzen Timeouts zu einem großen (und gefährlichen) Problem heranwachsen: Neue Steuerungsbefehle kommen nicht an, obwohl die alten doch eigentlich bereits egal wären!

Dies wurde durch einen Hybridansatz aus einer Mischung von TCP und UDP stark verbessert. Der Steuerungs-PC bestimmt nun, welche Nachrichten auf welche Weise übertragen werden. Wird Reliable gewählt, wird weiterhin TCP verwendet. Falls stattdessen bei einem Befehl angegeben wird, dass die Befehle unreliable sein können, weil sie so oft gesendet werden und nur ihre schnelle Ankunft zählt (Befehle wie Geschwindigkeit und Lenkwinkel), wird UDP verwendet. Nachrichten über UDP erhalten einen erweiterten Nachrichtenkopf, der eine Nachrichtennummer und eine Clientnummer kodiert, die von RMaster verwendet werden, um eventuell verspätet eintreffende Fragmente direkt fallen zu lassen und sich rein auf die wichtigeren, aktuellen Nachrichten fokussiert.

Mit dieser Optimierung der Übertragungstechnik lässt sich der Rover nun schnell und ohne Abbrüche steuern, was ihn zu einem sehr verlässlichen Fahrzeug werden lässt. Manöver bei höheren Geschwindigkeiten sind hiermit kein Problem mehr und auch schlechte Verbindungen, wie beispielsweise WLAN mit vielen Störsignalen, lassen sich bewältigen. Eine Demonstration dieser neuen Sicherheit bietet das kommende Video!