Déporter les instruments de vol sur un autre écran ?

[EPDR400]

Bonjour.

Un membre du forum a un beau simulateur:

http://nsm08.casimages.com/img/2014/02/07//14020703372613590711963636.jpg

Comment faire pour créer un écran séparé d'instruments de bords? Un glass cockpit avec des instruments traditionnels oui :-)

Je sais faire disparaitre le cockpit des écrans principaux en changeant la vue, mais je n'ai pas trouvé comment déporter les instruments sur un troisième écran 15 pouces de récup (GEforce 210 de la carte mère, perf pitoyables mais peu importe).

Merci!

Christophe.

[Daniel_L]

Les instruments séparés ne sont pas dans X-Plane mais dans une application liée.
Il y a différents produits sur le marché comme Panel Builder (http://simplugins.com/html/products.html), FsXPand (http://www.cockpitsolutions.com/), flightSimPanels (https://github.com/dmolin/flightSimPanels), Instrument Panel Designer (http://www.fly.elise-ng.net/instrumentpaneldesigner), et probablement d'autres.

Daniel

[coyote60]

Je passe par PanelBuilder, vraiment très simple à utiliser avec un deuxieme pc en réseau.

[EPDR400]

Merci Coyote60 !

Je vais essayer ta solution et me faire un "calculateur d'instrumentation" avec une vieille zotac mini-itx d'origine embedded (atom N270, double sortie écran et alim 12V).

Merci à tous de vos conseils.

Christophe.

[coyote60]

Oui, pas besoin d'un gros pc.
Pour créer les panels c'est un peu plus long car il faut paramétrer parfois, mais c'est très intéressant au finale, presque un jeu dans le jeu.
Bon vol

[EPDR400]

Bonjour.

Je viens d'aller voir le site de Panel Builder, c'est bien mais... c'est sous Windows.

Et comme il n'est pas question que j'achète un OS de microsoft pour y mettre mes instruments de vol, je vais explorer d'autres pistes en attendant!

J'ai cru lire qu'il existe un système déporté par réseau en JAVA, donc à priori disponible sur un OS libre. Il faut que je me souvienne où j'ai bien pu lire ça!

Et si ce n'est pas suffisant, je m'attaquerai à l'API de Xplane pour exporter par LAN ou COM les valeurs d'instruments et les gérer avec un calculateur externe.

Déformation professionnelle oblige :-)

Merci encore.

Christophe.

[EPDR400]

Bonjour.

Je m'auto-réponds, puisque je viens de découvrir que Xplane n'a besoin d'aucun module supplémentaire pour exporter par UDP des valeurs d'instruments! Merci Austin, merci, merci... (ad lib) :-)))

Puisqu'il est vraiment facile d'interfacer un micro contrôler AVR (atmel) avec un réseau Ethernet, je vais m'attaquer dans peu de jour à un premier instrument matériel extérieur et je vous tiendrai au courant.

Ou même un raspberry pi avec une piface, j'ai recu un sample l'année dernière et je ne savais pas trop quoi en faire... bref je ne sais pas dans quoi j'ai mis la main mais le bras est déjà en train d'y passer :-)))

Christophe.

[PhM]

...Je m'auto-réponds, puisque je viens de découvrir que Xplane n'a besoin d'aucun module supplémentaire pour exporter par UDP des valeurs d'instruments! Merci Austin, merci, merci... (ad lib) :-)))....

C'est tout le contraire, pas merci Austin. Le meilleur exemple est DLG Cockpit, un petit truc fait pour la v9 en utilisant les paquets UDP de X-Plane, et qui ne marche plus du tout grâce à Austin. J'ai d'ailleurs fait un plugin pour le ressusciter en v10.

Ces paquets UDP peuvent changer à n'importe quelle révision, et obliger à refaire l'application, merci Austin. Le seul composant stable est le SDK de Sandy et Ben, justement parce qu'il est hors de portée d'Austin.

Donc si c'est pour un truc à utilisation personnelle et que refaire ce qu'Austin casse ne te dérange pas c'est ok. Si c'est pour mettre à disposition des autres et souhaiter qu'ils puissent l'utiliser sans soucis, ben c'est toi qui va avoir des soucis.

PhM

[EPDR400]

Bonjour PhM.

> C'est tout le contraire, pas merci Austin. Le meilleur exemple est DLG Cockpit, un petit truc fait pour la v9 en utilisant les paquets UDP de X-Plane, et qui ne marche plus du tout grâce à Austin. J'ai d'ailleurs fait un plugin
> pour le ressusciter en v10.

Je remercie simplement l'auteur d'avoir pensé à exporter et importer simplement (packets UDP) les données instrumentales.

Dans la pratique je ne me suis pas encore penché techniquement sur le contenu du flux et sur la grammaire utilisée.

Y'a-t-il des specs publiées sur ce flux UDP, peut-on utiliser du RI fait par d'autres ou dois-je commencer à sniffer tout ce qui sort pour essayer d'en découvrir le plus possible ?

Je suis dans une démarche opensource: je commencerai pour moi, j'irai jusqu'à mes limites de temps ou de compétence, et je partagerai sur le mode "caveat emptor" :-)

Quel est le SDK dont tu parles?

Christophe.

[Daniel_L]

...
Je m'auto-réponds, puisque je viens de découvrir que Xplane n'a besoin d'aucun module supplémentaire pour exporter par UDP des valeurs d'instruments! Merci Austin, merci, merci... (ad lib) :-)))
...

Comme l'a dit PhM, la sortie UDP d'origine d'X-Plane c'est pas top car ça change et ça oblige à refaire pas mal de choses. Le Plugin SDK est bien plus stable.
Si tu veux des données en réseau envoyées par X-Plane de façon stable, regarde le plugin SCS :

http://cross-simulator.com/download.php

Il y a aussi des bibliothèques C, Java et Python pour aller avec.

Daniel

[Daniel_L]

Dans mes liens au dessus il y a flightSimPanels qui est sur Linux, et Open Source.

Sinon le plugin SDK pour X-Plane c'est là : http://www.xsquawkbox.net/xpsdk/mediawiki/Main_Page

Daniel

[EPDR400]

Bonjour Daniel.

Ma démarche est de déporter des instruments d'une façon relativement simple et réaliste, en affiché dans un premier temps puis en matériel par la suite.

Si quelqu'un l'a déjà fait, je ne vais pas réinventer l'eau chaude et j'utiliserai joyeusement ce qui sera disponible pour l'usage que je veux en faire: du loisir en marge du pilotage réel.

Utiliser SCS pour retomber dans du CAN sur Ethernet serait se tromper de cible: il me faudrait développer des instruments externes compatibles CAN Aerospace, ce qui semble bien au dessus de mes compétences et du temps que je veux y mettre.

Si je comprends que l'UDP native de Xplane est trop instable pour y mettre quoi que ce soit sans risquer de tout devoir redévelopper au gré des changements de version, et qu'à l'autre extrémité il y a le CAN Aerospace, alors il reste une voie intermédiaire :

Celle de développer un plugin qui permettra d'exporter et d'importer avec un protocole stable et simple les instruments et données de vol.

Et comme je dois être le 1000ème à me poser la question, beaucoup de travail a déjà du être fait dans le domaine :-)

Un milieu entre le désordre que vous me décrivez de l'UDP natif, et l'exigeance du CAN Aerospace qu'il sera difficile d'intégrer dans un instrument à base de microcontroleur perso.

Il faudra donc que je parte des sources d'un plugin réseau existant et que j'y réfléchisse en simplifiant les choses...

Pour ne rien cacher j'imagine déjà qu'avec quelques arduino ou ATMEGA pilotant des servos ou des steppers on doit se rapprocher d'un cockpit réaliste ;-)

Christophe.

[Daniel_L]

On peut trouver des instruments tout faits mais c'est cher et l'interfaçage c'est pour Windows seulement.

http://www.flightillusion.com/

Sur le forum il y en a qui se sont intéressé aux cartes Arduino mais ça fait un moment qu'on n'en entend plus parler.

Daniel

[EPDR400]

Bonjour Daniel.

Dans un premier temps je vais utiliser un troisième écran pour mes instruments, ce serait trop long sans voler.

Dans un second temps je vais tenter le "beau et peu cher" libre de tout OS et de tout fabriquant:

- Une couche protocolaire simplifiée mais pérenne du côté Xplane avec un plugin d'entrée-sortie instrumentale. Il va falloir que je me remette au C et ça risque de prendre du temps :-)

- Une implémentation matérielle simple avec port COM: virtuel (Prolific et équivalents) ou port COM: physique ou UDP, ainsi l'on pourra adresser des instruments avec ou sans stack IP.

Stay tuned :-)

Christophe.

[Daniel_L]

Ce soir j'essaye FlightSimPanels (https://github.com/dmolin/flightSimPanels) sous Linux Ubuntu mais je n'ai pas encore réussi à le faire tourner à cause de dépendances de modules Grunt.

En même temps je regarde les fichiers. Ce qui est bien c'est que beaucoup de choses sont en texte. Un exemple dans le fichier index.js de src/services/measures/attitude :
xtype: "17", //this is the instrument panel number, as sent by the server
17 c'est la ligne dans l'écran Data Input & Output qui correspond à Pitch, Roll et Headings, ce qu'il faut pour l'horizon artificiel. Avec ce système, si Austin décale une ligne ce sera plus facile à corriger que d'attendre une recompilation par l'auteur.

Daniel