Der folgende Beitrag befasst sich nicht direkt mit den sonst hier üblichen Themen des 3D-Drucks oder der entsprechenden Bearbeitung. Der Druck einzelner Teile und gewisse Elektronikbasteleien werden aber auch Inhalt sein. Für einen Flugsimulator wird eine Hardwaresteuerung auf Basis eines Arduino Mega 2560 konstruiert und gebaut. Die dafür notwendige Programmierarbeit wird erklärt und ein Gehäuse wird geruckt.

Irgendwann reifte der Gedanke bei meiner Frau und mir, dass man ja mal einen Flugsimulator ausprobieren könnte. Die Idee dazu kam aus der vorgelagerten Idee unsere uralte Playstation mit einem Rennspiel mal wieder zu aktivieren.

Nach einer kurzen Recherche blieben als Kandidaten X-Plane und der Microsoft Flight Simulator übrig. Soweit ich die Beschreibungen im Netz verstanden habe, sind beide technisch absolut ausgereift und unterscheiden sich nicht wesentlich. Die Ausrichtung scheint aber beim Microsoft Flight Simulator eher auf den schnellen Erfolg ohne viel Aufwand ringsherum zu liegen, während X-Plane eher für eine vollständige und realitätsnahe Flugerfahrung mit allen Randbedingungen zu stehen scheint. Schreibt gerne in den Kommentaren, ob das so zutrifft.

Die Entscheidung fiel auf X-Plane. Die konstenlose Testversion war schnell installiert und lief auf meinem doch schon etwas betagten Rechner in vernünftiger Auflösung und Detailierung.

Eine NVIDIA GeForce GTX 1070 Ti (auch schon recht betagt) sorgt für die Ausgabe auf einem 140cm-Display. Das Steuern über eine CAD-Maus, machte nicht wirklich Spaß. Deshalb kam dann auch recht schnell eine Steuerung von Logitech G Saitek dazu. Logitech ermöglicht dem Enthusiasten durchaus, ein realitätsnahes Cockpit mit schönen Komponenten aufzubauen. Der Haken daran: Sehr teuer, – selbst gebraucht auf ebay und Ähnlichen. Die Schalter und Regler direkt in der Simulation auf dem Bildschirm zu bedienen ist auch keine gute Lösung. da dann die Sicht durch das Cockpit sehr eingeschränkt wird.

Die X-Plane Software wurde lizensiert und damit standen dann unzählige Flugzeugmuster und „die ganze Welt“ an Flugplätzen zu Verfügung. Um das Problem mit den Cockpit-Elementen in den Griff zu kriegen, gibt es für den Bastler eine sehr interessante Schnittstellenlösung: Air Manager. Auch vom Air Manager gibt es eine kostenlose Testversion. 

Jetzt kommen wir langsam zum Punkt! Air Manager erlaubt es, via selbstgebautem Zubehör auf die Flugsimulation zuzugreifen. Umgekehrt versorgt die Flugsimulation den Air Manager mit allen Informationen aus der Instrumentierung um beispielsweise eigene Displays aufzubauen. Das kann vom 7-Segment-Display bis hin zum vollwertigen TouchScreen-Monitor alles sein. Die Anbindung, zumindest, wenn Selbstbauhardware zu Einsatz kommt, geschieht beispielsweise über einen bzw. bis zu 16 Arduinos.

Die Dokumentation zum Air Manager würde ich als hervorragend bezeichnen. Ein sehr umfangreiches Wiki erklärt nahezu alles, was man brauchen könnte und zeigt zudem noch Beispiele. So habe ich mich dem Thema angenähert und kam recht schnell zum Erfolg.

Der Arduino, der Typ ist übrigens ziemlich egal und Clones funktionieren zumindest bei mir auch problemlos, wird über ein in Air Manager eingebautes Tool mit einer eigenen Firmware beschrieben. Der Vorgang wird nur einmalig ganz am Anfang durchgeführt. Alles Weitere erfolgt jetzt nur noch in der Programmierumgebung, die aber sehr einfach und logisch aufgebaut ist. LUA kommt hier zum Einsatz.

Will man beispielsweise einen Pushbutton eines Instruments im Flugzeug mit einem realen Button bedienen, wird der entsprechende Button einfach zwischen GND und einem logischen PIN am Arduino geschaltet. In der Programmierumgebung für das betreffende Instrument wird nun der Button bekanntgemacht und mit einer Routine, die in der Regel schon vorhanden ist, verbunden.

Ich habe das für den Autopilot mal umgesetzt:

Die weißen Flächen sind alles Buttons. Rechts befindet sich ein Drehknopf und außerdem ist die hier schwarze Fläche normalerweise im Betrieb mit Informationen gefüllt. Das Instrument wird von Air Manager zur Verfügung gestellt. Bevor man nun eigenen Code einfügt, sollte das Instrument dupliziert (Clone) werden, damit der Code auch erhalten bleibt. Dann kann man schon mit der Anbindung loslegen.

Auf der rechten Seite sieht man den Anfang des Programmcodes für das Instrument. Ganz am Ende füge ich jetzt die Anweisungen zur Einbindung des Arduinos und seiner angeschlossenen Hardwarebuttons an.

Man kann schon deutlich erkennen, dass das recht trivial abläuft, sobald man die „Spielregeln“ verstanden hat.

button_api = hw_button_add("ARDUINO_MEGA2560_B_D47", api_callback)

Ob man den Rückgabewert der Funktion nun noch braucht oder nicht: Ich habe ihn mal in der Variablen button_api aufgefangen, nutze ihn aber nirgends.

Die Definition der Anbindung beginnt mit dem eigentlichen Befehl für das anzubindende Element. Das kann ein Button, ein Schalter, ein Poti, etc. sein. Hier ist es ein Button: hw_button_add

Die Hardware wird jetzt bekanntgemacht. In meinem Fall ist das ein Arduino_MEGA_2560 auf Kanal B. Der Kanal wird bei der oben beschriebenen Initialisierung des Arduino festgelegt. Hinzu kommt noch der PIN. In diesem Fall ist das D47.  Der gesamte String ist vordefiniert. Dazu gibt es  auch Informationen im Wiki:

Interessant ist dabei, dass fast bei jeder Hardware die PINs D00 und D01 nicht nutzbar sind.

Im letzten Teil der Definition steht dann der Name der Routine, die aufgerufen wird, wenn der Button betätigt wird: api_callback. Die Routine muss natürlich definiert sein. Bei den Instrumenten im Air Manager ist das natürlich schon vorhanden.

Im obigen Bild sieht man ein Beispiel für die aufgerufenen Routinen. Hier wird dann der eigentlich gewünschte Befehl an die Simulation abgesetzt. Für X-Plane sind das die xpl-command-Anweisungen, für Flight Simulator ist es die fs2020-event-Anweisung.

Übrigens kann man neben dem Push-Event (Drücken des Buttons) auch das Release-Event (Loslassen) ausnutzen. Die entsprechende Anweisung wird einfach an die Definition angehängt und ruft eben die entsprechende zweite Routine auf. Das sähe beispielsweise so aus:

button_api = hw_button_add("ARDUINO_MEGA2560_B_D47", push-event, released_event)

In meinem Beispiel habe ich auch noch einen Rotary-Encoder für die Erhöhung bzw. Reduzierung der Höhe benutzt. Hardware-mäßig ist ein Rotary-Encoder ein Drehregler, der einzelne Pulse übermittelt und dann auch noch die Drehrichtung mitgibt. Dafür lautet der Befehl:

hw_dial_add("ARDUINO_MEGA2560_B_D4", "ARDUINO_MEGA2560_B_D3", "TYPE_1_DETENT_PER_PULSE", 1, 10, small_dial_callback)

Die Definition fängt mit hw_dial_add an. Der Anschluss ist zweiteilig, aber nach dem gleichen Prinzip wie beim Button. Da zwei PINs angeschlossen werden muss das eben auch zweimal angegeben werden. Danach folgen drei rein technische Definitionen, die sich um den Encoder-Typen, den Multiplikator und die Entprellung kümmern. Das sollte man anhand des Wiki ermitteln und ggfls. ausprobieren. Zum Schluss kommt wieder der Aufruf der entsprechenden Routine.

Auch wenn das Beispiel aufgrund der flugtechnischen Abhängigkeiten recht komplex aussieht, so kommt es eigentlich nur auf die Auswertung von direction an, was übrigens bei der Definition (s.o.) gar nicht mit angegeben wird. direction kennt nur die Werte 1 und -1.

Mein Hardware-Aufbau sieht aktuell noch sehr einfach aus. Später soll daraus noch eine ordentliche Konsole werden. Jetzt ist mir aber noch aufgefallen, dass im Zusammenhang mit dem Autopilot noch die Einstellung des Heading und die Nachjustage der Richtung im dazugehörigen Insturment notwendig ist. Dazu baue, verdrahte und codiere ich noch zwei weitere Rotary-Encoder auf dieses Board.

Ich werde weiter berichten …

Fast vergessen, worüber ich auch Anfangs gestolpert bin. Der Autopilot ist nur bedienbar, wenn die Simulation auch tatsächlich läuft!