Motionplattform zur Simulation von G-Kräften

Motion Platformen können entweder mit 3 oder mit 6 Freiheitsgraden (Beinen) gebaut werden.

3 Freiheitsgrade erlauben nur drei der sechs, in der Grafik gezeigten Bewegungen. Somit können nur die rotatorischen Bewegungen genutzt werden. Diese eignen sich zwar gut um dauerhafte G-Kräfte zu simulieren, jedoch können keine Stöße (z.B. Kollisionen) simuliert werden. Da die Simulation der Bewegung mit 6 Freiheitsgraden um einiges realistischer ist, wurde dieser Ansatz gewählt.

Es gibt zwei Möglichkeiten die Motion Platform zu bewegen :

• Motoren gemeinsam mit einem Exzenter (Hebel)
• Pneumatik/Hydraulik/elektrische Linearaktoren

Pneumatik und Hydraulik wurden ausgeschlossen, da beide einen Kompressor benötigen, der in einem Innenraum eine große Lärmbelästigung bedeuten würde, während Linearaktoren entweder zu langsam oder zu teuer sind.
Zu Beginn des Projekts wurden Implementierungen von Plattformen mit Motoren analysiert um Eckdaten wie die Länge der Exzenter sowie die Kräfte und Geschwindigkeit der Motoren zu ermitteln. Für eine realistische Simulation sollten die Beine ihre Länge um 20cm in beide Richtungen verändern können. Die Bewegung von der minimalen auf die maximale Länge sollte innerhalb einer Sekunde abgeschlossen sein. Aufgrund dieser Anforderungen wurde eine Exzenterlänge von 20cm gewählt. Aus der Geschwindigkeitsanforderung wurde eine Motorgeschwindigkeit von 30RPM abgeleitet. Da durch die Bewegung der Plattform Kräfte von bis zu einem Kilonewton entstehen können, werden Motoren mit einem Drehmoment von 200Nm benötigt. Da die geforderte Drehzahl jedoch relativ gering ist können Getriebe gemeinsam mit einem schnelleren schwächerem Motor genutzt werden. Um die Rückwirkung der Platform auf die Motoren, durch schnelles Abstoppen oder langes Stillstehen, zu minimieren eignen sich hier Schneckengetriebe am besten. Mit einer Übersetzung von 1 zu 100 würde ein Motor mit 20Nm und bis zu 3000RPM benötigt. Bei diesen Kräften ist es wichtig, dass der Ausgang des Getriebes einen Flansch bietet um die rotatorische Energie bestmöglich von der Achse abnehmen zu können. Weiters ist darauf zu achten, dass der Ausgang des Lagers mit einem Axiallager versehen ist, da durch den Exzenter ebenfalls Kräfte in diese Richtung wirken.
Die Plattform sollte mithilfe von Aluprofilen und gefrästen Teilen gebaut werden, die Exzenter würden ebenso aus Aluminium gefräst.

Für das Testen der Anwendung wurde eine Modellplattform entwickelt, welche sich mechanisch möglichst maßstabsgetreu an die Spezifikation der späteren Plattform hält. Um möglichst schnell ein Proof of Concept zu erzielen, wurde zunächst ein recht simples Modell bestehen aus einer Metallplatte als Basis und einer Holzplatte als Plattform konstruiert. Die anfangs verwendeten Servomotoren wurden dabei lediglich mit Kabelbindern an der Basis befestigt und wurde über eine selbst gelötete Platine mit Strom versorgt.

Die zweite Version der Modellplatform ist bereits ein maßstabsgetreuer Aufbau. Ziel dieser Plattform war es Exzenter und Stangenlängen sowie erreichbare Winkel zu überprüfen. Diese Platform wurde in Fusion360 modelliert und mit einem Prusa i3 MK3 aus PLA gedruckt. Die Servo Motoren wurden direkt in einem gedruckten Slot fixiert. Die Exzenter wurden ebenfalls 3D gedruckt und direkt an den Metallkopplungen der Servos fixiert.

Eine dritte etwas größere Version wurde hauptsächlich für den Tag der offenen Tür entworfen. Diese ist etwas modularer aufgebaut, da die Druckfläche des Prusa i3 MK3 diese Größe nicht mehr in einem Stück drucken kann. Weiters besitzt diese Plattform Öffnungen für die Kabel der Servos, sodass diese nicht mehr außen geführt werden müssen, und eine Schürze unter der die Steuerplatine versteckt werden kann. Zusätzlich wurde eine abstrahierte Version des Simulators anstelle des Dreiecks, das zuvor bewegt wurde, gedruckt. Da diese jedoch zu schwer für die kleinen Servos war, wurden diese durch größere ersetzt. Der Modulare Aufbau der Plattform erlaubte einfaches Austauschen der Motoren ohne die Plattform komplett neu drucken zu müssen.

Unterstützte Rennsimulationen/Spiele

Da die Simulation von Bewegungen nur möglich ist wenn Bewegungsdaten ausgelesen werden können, ist es essenziell mehrere vielfältige Anwendungsbereiche zu unterstützen. Wir haben uns auf den Motorsport eingeschränkt, es ist aber durch den modularen Aufbau leicht möglich auch Flugsimulationen oder ähnliches anzubinden. Um trotz der Einschränkung auf den Motorsportsektor nicht zu Disziplinen abhängig zu sein und für jeden Hobby-Rennfahrer etwas zu bieten, ist die Plattform für die folgenden drei Simulationen-/Spiele-Typ.

ProjectCars und ProjectCars 2

ProjectCars und sein Nachfolger ProjectCars2 bieten optisch atemberaubendes Rennfahren mit zahlreichen verschiedenen original modellierten Fahrzeugklassen und Strecken. Obwohl dieses Spiel zwar eher als Mischung zwischen Simulation und Spiel gilt, sind viele wichtige Aspekte des Rennsports, wie Schadenssimulationen, Temperatursimulation der Reifen, Benzinverbrauch und Wettereinflüsse sowie Tag- und Nachtwechsel mitsimuliert. Das meiste Renngeschehen spielt sich jedoch auf dem Asphalt ab, da das Reifen- und Gripmodell nicht hundertprozentig realistisch ist.

Assetto Corsa

Assetto Corsa ermöglicht es dem Fahrer wie in ProjectCars2 in viele Straßen- und Rennwägen seine Runden zu drehen, das Spiel baut aber statt zahlreichen Strecken und Fahtzeugen eher auf ein realistisches Reifenmodell und extrem realistische Fahrdynamik auf der Rennstrecke. Assetto Corsa ist deswegen eher für die fortgeschritteneren Hobbyrennfahrer geeignet, welche mehr Wert auf akkurate Simulation, als optische Effekte und Vielfalt legen.

Dirt Rally und Codemasters Spiele

Dirt Rally im Gegensatz zu den anderen Beiden Simulationen ist das perfekte Spiel für jeden Offroad Enthusiasten, der schon immer davon geträumt hat einmal bei einer Rally mit seinem Co-Pilot über schwierige meist dreckige und verwinkelte Wege zu rasen. Hier wird großteils im Gelände mit originale Rally-Ikonen Gas gegeben.
Außerdem ist es mit der Schnittstelle von Dirt Rally möglich auch den Nachfolger Dirt Rally 2 und alle anderen Spiele des Herstellers Codemasters zu verwenden. Zu diesen anderen Spielen zählt unter anderem die Formel 1 Kultserie des Herstellers mit der neusten Version 'F1 2019'.

Konzept zum auslesen der Daten

Grundsätzlich verwenden wir zwei Konzepte mit denen Daten aus den jeweiligen Simulationen ausgelesen werden können: Shared Memory und UDP. Da diese die gängigsten Varianten sind, ist es möglich mit wenig Aufwand auch weitere Simulationen/Spiele mit der Plattform kompatibel zu machen.

Shared Memory API

Bei dieser Form der API erzeugt die Simulation einen Shared-Memory-Bereich, der in unserer Datenverarbeitung geöffnet werden kann. Dadurch hat das Programm direkten Zugriff auf alle Parameter der Simulation. Um jedoch die Felder und den Aufbau dieses Bereichs korrekt identifizieren zu können, wird eine Schnittstellendefinition von Hersteller der API benötigt, welche meist nur schwer oder nicht vorhanden für private Kunden erhältlich ist.
Im Fall von ProjectCars2 ist diese Schnittstelle jedoch öffentlich zugänglich, was sehr effizientes Auslesen aller Fahrdaten ermöglicht. Die Synchronisation des gemeinsamen Speicherbereichs wird über eine Variable erreicht, welche auf einem ungeraden Wert steht solange die Simulation die Daten bearbeitet.

UDP API

Die meisten Simulationen/Spiele bieten ein UDP API, wobei die Simulation den UDP-Server-Socket erzeugt und auf Anfrage des Clients, also der Positionsberechnung Datenpackete mit Fahrdaten sendet. Diese Form der API ist weit verbreitet, da eine solche API unabhängig von Plattform, Architektur und Programmiersprache des Clients ist. Ein wesentlicher Nachteil jedoch ist die zusätzliche Latenz, welche durch das Ver- und Entpacken von UDP Packeten zustande kommt. Zusätzlich können nur die Daten ausgelesen werden, die vom Hersteller für den Versand in fixen UDP Packetstruckturen vorgesehen worden sind.
Ein wesentlicher Vorteil ist jedoch, dass sich der Client nicht am selben Host befinden muss und die Datenauswertung somit auch auf einem anderen Rechner stattfinden kann. Dadurch kann der Simulationsrechner entlastet werden.
Solche eine UDP API wird von den Spielen Dirt Rally und Assetto Corsa verwendet.

Generell muss man bei der Berechnung zwischen zwei möglichen Systemen unterscheiden:
System A => ein System ohne Servomotoren, bei dem lediglich davon ausgegangen wird, dass sich die Beinlänge beliebig verändern kann. Die Beine sind zwischen den Ankerpunkten der Top- bzw. der Base-Plattform fixiert.
System B => ein System mit Servomotoren, wie in der Mechanik beschrieben. Eine Beinlängenänderung wird über die Variation der Servomotorwinkel erzielt.

Initializing Routine: diese Routine wird einmal bei der Initialisierung des Gesamtsystems aufgerufen. Hier werden einige Konstanten basierend auf der gewählten Plattform-Architektur und -Dimensionen berechnet.
Platform Dimension: Ausmaße der Stewart-Plattform. Diese beinhalten die Höhe der Plattform, die Anbringhöhe der Servomotoren, die Länge der Konnektoren zwischen Motor und den Plattformbeinen, die Beinlängen der Platform und den Radius der Top- bzw. Base-Plattform

Base Anchor Points: Hier werden die Ankerpunkte der Beine auf der Base-Plattform berechnet. Dies geschieht unter der Annahme, dass System A vorliegt
Top Anchor Points: Hier werden die Ankerpunkt der Beine auf der Top-Plattform berechnet. Dies geschieht unter der Annahme, dass System A vorliegt
Initial Leg Vectors: Beinvektoren in der Ruhelage des Systems, d.h. Base- und Top-Plattform stehen parallel zueinander
Body Points: Projektion der Ankerpunkte der Top-Plattform auf die Base-Plattform. Dies hat den Hintergrund, dass wir die Base-Plattform als Referenz-Koordinatensystem verwenden-.
Angular Calculations: einige Winkelberechnungen, um von den Winkeln aus System A, die sich aus rein aus den Beinlängen ergeben, auf die Winkel auf System B zu schließen
Mapping Function: die obigen Winkelberechnungen können dazu verwendet werden, eine lineare Approximation (y = a*x+b) zwischen den Winkeln, die aus den Beinlängen resultieren und den Winkeln der Servomotoren zu erstellen

Calculation Routine: diese Routine wird regelmäßig (basierend auf der Frame Rate der Signalquelle) aufgerufen und berechnet die Winkel der Servomotoren basierend auf den Bewegungedaten aus der API
Game API: Signalquelle des Systems. Hieraus werden Informationen wir xyz-Beschleunigung, Orientierung im Raum, Winkelgeschwindigkeiten etc. für die Berechnung der Servowinkel entnommen
Location and Agular Data: Hier werden die Informationen aus der Spiel-API auf die 6-DOF umgerechnet: Potition des Schwerpunkts der Top-Plattform (x,y,z) und Rotation der Top-Plattform in drei Achsen
Rotation Matrix: Rotationsmatrix, mit deren Hilfe die Body-Points auf eine 3-dimensionale Plattform mit der gewünschten Neigung (aus "Location and Angular Data") transformeirt werden
Position Matrix: Matrix mit der die x,y,z-Koordinaten der Plattform abgebildet werden
Leg Lengths: Beinlängen die aus den gewünschten Plattform-Positionen und der Plattform-Orientierung resultieren
Servo Angle Approxim.: mit Hilfe der Mapping Function werden die Beinlängen auf einen Servowinkel abgebildet

High Level Synthese beschreibt die Technik aus einem C/C++ Quellcode einen HDL Quellcode zu erstellen. Die Schwierigkeit besteht darin den ursprünglichen Code auf HLS fähigen Code zu transformieren. Diese Transformation ist nötig, da auf der Hardware keine Ressourcen dynamisch allokiert werden können und alle Blöcke bereits zur Kompilierzeit bekannt sein müssen.
Wir haben uns für HLS entschieden, da wir auf Grund des hohen Rechenaufwands und der geringen Latenzzeiten viele Vorteile der parallelen Abarbeitung auf einem FPGA profitieren können. Um möglichst schnell die Datenverarbeitung in Hardware zu realisieren, ist die Wahl auf High-Level-Synthese gefallen, wodurch direkt C-Code in Hardwarebeschreibungen übersetzt werden.

Xilinx HLS

Der Hersteller Xilinx liefert für seine Entwicklungsumgebung Vivado Werkzeug zum Erstellen von HLS Projekten mit. Ein Projekt kann durch ein einfache TCL-Datei beschrieben werden.

Modell

Um mit begrenzten Ressourcen auf einem FPGA eine äquivalente Implementierung der Bewegungsplattform zu realisieren, wurde High-Level-Synthese gewählt. Die Beschreibung des äquivalenten C++ Modells mit den vorhandenen Armadillo Bibliotheken musste in "statischen" C-Quellcode konvertiert werden. Armadillo bietet Funktionen um Matrizen zu berechnen. Die verwendeten Funktionen mussten neu implementiert werden, da alle verwendeten Datentyp auf Fixkomma Varianten umgebaut werden mussten, um Ressourcen zu sparen, aber gleichzeitig die benötigte Präzision zu erreichen. Ressourcen zu sparen war auf unserer verwendeten Zielplattform essenziell, da wir nur ein kleines FPGA zur Verfügung hatten.

HLS Bibliotheken

Für eine ressourcenschonende Implementierung bietet der Hersteller Xilinx spezifische Bibliotheken an. In der Implementierung des Modells wurde die Mathematik Bibliothek verwendet, um Funktionen wie Sinus und Kosinus darauf abzubilden.

Architektur

Als Vorlage für das Design wurde folgende Architektur verwendet. Der IP-Core sollte mittels Memory-Mapped Interface ansprechbar sein, um die Daten für die Berechnung zu liefern. Das Prozessor System nimmt die Daten von der Ethernetschnittstelle anhand des vorhandenen MQTT Protokolls entgegen und gibt diese über den AXI-Bus an den Motion IP-Core weiter. Die PWM-IP aktualisiert anhand der berechneten Werte kontinuierlich die 6 PWM-Ausgänge und somit auch die Position der Servomotoren.

Probleme

- HLS-Constraints nicht funktional -> Schleifen sparten meist mehr Ressourcen
- Code muss unnötig "unleserlich" geschrieben werden um Ressourcen zu sparen
- teilweise Inkompatibilitäten zwischen der Linux und Windows Version von Vivado
- eine neuere Version des Werkzeuges verbraucht wesentlich mehr Ressourcen bei gleichem Quellcode

Ergebnisse

Funktional kann die Synthese mit begrenzten Mitteln einfache Designs realisieren, da auch die Plattform HLS sehr gut unterstützt. Da ausreichend Dokumentation und Tutorials vorhanden sind, erzielten wir schnell erste Erfolge und mussten uns nur noch um bessere Effizienz unserer Verarbeitung kümmern. Da die MiniZed Plattform von Avnet nur wenig Ressourcen anbietet, ist das Board auslastungstechnisch nahe des Limits.

Qt Visualisierung

Im Zuge des Debuggings der Modellplattform war es notwendig, die Bewegungsdaten aus dem Spiel mit den echten Bewegungen der Plattform zu vergleichen. Da sich die Daten jedoch mit 60 Herz aktualisiert werden und eine Unterbrechung der Berechnung, um die aktuellen Werte auszulesen, die Bewegung der Plattform verfälschen würde, wurde eine Qt Anwendung geschrieben, welche die relevanten Werte visualisiert. Die Daten werden dabei über MQTT von der Berechnung gesendet und von der Qt Anwendung empfangen. Konkret wurden, wie in der Grafik zu sehen, vier Liniendiagramme verwendet um die Beschleunigung, die Winkelgeschwindigkeit, die Orientierung des Fahrzeugs sowie die Benutzereingaben anzuzeigen. Im Zuge des Tages der offenen Tür wurde zusätzlich noch eine Bestenlistenfunktion implementiert. Die Rundenzeiten werden dabei ebenfalls über MQTT übertragen.

C# Visualisierung

Die zweite Version der Visualisierung ist im Zuge der Lehrveranstaltung SAV (Softwarekonzepte und angewandte Visualisierung) und konzentriert sich, im Gegensatz zur Qt Implementierung, mehr auf die Anzeige jener Daten, die für den Benutzer interessant sind. Die Daten werden dabei, gleich wie bei der Qt Version, über MQTT übertragen und mittels WPF visualisiert. Dabei wurde, wie in der Grafik unten zu sehen, mehr auf die Visualisierung der relevanten Daten für den Benutzer geachtet. Im linken unteren Bereich der Applikation werden die aktuellen Benutzereingaben wie Gas- und Bremspedalstellung sowie der aktuelle Lenkeinschlag angezeigt. Daneben werden die farblich visualisierten Reifentemperaturen und der aktuelle Treibstoff angezeigt. Die beiden Diagramme darüber dienen zusätzlich zur Analyse der gefahrenen Runden. In der oberen Hälfte werden die Daten, welche von der MQTT Schnittstelle empfangen wurden, direkt angezeigt und aktualisiert. Diese Daten werden, nach dem Beenden einer Runde, in eine CSV Datei gespeichert und können statisch im unteren Diagrammbereich angezeigt werden. Dabei werden die Werte von Gas, Bremse, Lenkung sowie aktueller Gang und Geschwindigkeit visualisiert.

Visual Studio

Microsoft Visual Studio war unser Hauptwerkzeug zum entwickeln der Software und wurde verwendet um das Datenauslesen aus den Spiele APIs zu implementieren(C++) und die Motorpositionen zu berechnen(C++).
Außerdem wurde Visual Studio eingesetzt um die C# Visualisierung der Fahrdaten zu entwickeln.

MATLAB Simulink

Um Simulationen der Stewart-Plattform mit verschiedenen Geometrien und Dimensionen durchzuführen, wurde MATLAB Simulink eingesetzt.

Vivado

Vivado war das Tool unserer Wahl für die High-Level-Synthese für das Minized Board von Avnet, welches mit einem Xilinx FPGA ausgestattet ist. Dabei wurde die komplette Berechnung der Motorpositionen erfolgreich ins FPGA ausgelagert, was viel Rechenleistung und die Verwendung eines separaten Microcontrollers in der Plattform spart.

Fusion360

Fusion360 ist ein CAD Programm, welches verwendet wurde um die Modellplattform dreidimensional zu modellieren und später mit Hilfe von 3D-Druck zu fertigen. Mit Fusion360 wurden bis auf die Servos und alle mechanischen Befestigungsteile, wie Schrauben und Muttern, alle Teile der Plattform konstruiert.

QT-Creator

Der QT-Creator wurde eingesetzt um die erste Version der Fahrdaten-Visualiserung zu entwickeln. Aufgrund von Synergien mit einem anderen Unterrichtsfach und größerem Wissen im Bereich C# und WPF wurde ab Version 2 auf Visual Studio umgestellt.

uVision

Um die Ansteuerung der sechs Servos in der Plattform zum bewerkstelligen, welche von einem STM32 M0 übernommen wird, wurde uVision von Keil verwendet.

Slic3r PE

Nachdem die 3D-Modelle von Fusion360 nicht direkt gedruckt werden können, wird eine Übersetzung auf Drucker-Code benötigt. Dafür wurde der Slic3r PE von Prusa verwendet, da auch auf einem Prusa 3D-Drucker gedruckt wurde.

KiCad

KiCad wurde verwendet um eine Platine zu designen, welche alle nötigen Pins des Microcontroller Boards und des MiniZed FPGA Boards enthält und somit die Ansteuerung und Versorgung der Servos für beide Hardware Varianten bietet.

GitLab

Als Versionierungssoftware wurde GitLab verwendet, welches auch gleichzeitig zum Organisieren des Teams, zum Planen des Projekts und zum Issue-Tracking verwendet wurde.