Annonce

Réduire
Aucune annonce.

Interfacage Xplane/Matlab

Réduire
X
 
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • Interfacage Xplane/Matlab

    Bonjour,

    Je suis débutant sous X-Plane et je souhaite réaliser mon propre pilote automatique en Matlab-SIMULINK à partir de ce que j'ai appris en cours et l'interfacer avec X-plane afin de le confronter à la réalité.

    Ma question est alors: quelqu'un peut il me renseigner sur la méthode à employer et la façon de faire pour réaliser cette interface (peut etre existe t il un exemple ou une démo sur le sujet) ?

    Je vous remercie d'avance pour votre aide qui me sera d'un grand secours.

    @+
    X-plane 8.6 /Win XP Sp2/ AMD 64 3000+/ 1Go RAM/ RADEON 9200 128Mo

  • #2
    Re: Interfacage Xplane/Matlab

    Envoyé par doudou
    ...Je suis débutant sous X-Plane et je souhaite réaliser mon propre pilote automatique en Matlab-SIMULINK ... quelqu'un peut il me renseigner sur la méthode à employer et la façon de faire pour réaliser cette interface (peut etre existe t il un exemple ou une démo sur le sujet) ?
    Salut,

    Il va falloir que tu me rafraichisse la mémoire, Simulink ça fait bien longtemps que je n'ai pas utilisé (c'était du temps où je faisais des modèles pour les bancs de test de gestion moteur).

    Donc tu fais ton modèle avec les jolies boites sur l'écran, et ensuite tu veux que des valeurs venant de X-Plane entrent dans ton modèle, et que les sorties de ton modèle aillent modifier des valeurs de X-Plane.

    Il faut donc voir comment Simulink prend ses entrées et fournit ses sorties, pour voir comment on peut connecter ça à X-Plane. Par une zone mémoire ? Par appel d'une fonction et dans ce cas quel est le format des données à passer et récupérer ? Les variables sont-elles en flottant ? En doubles ? Est-ce qu'il génère du code (similaire à autocode pour MatrixX) ?

    On verra ensuite comment on peut faire.

    PhM
    X-Plane 9.70 & 11.5r1 / W10 / AMD Ryzen 7 2700 / 8Go RAM / Sapphire R9 390 Nitro 8Go / Sapphire HD7870 GHz 2Go / Samsung LN40C530 / Oculus DK2 / LeapMotion / Saitek X56 / Thrustmaster Pendular Rudder

    Commentaire


    • #3
      Quand on veut interfacer quelque chose avec X-Plane, le mieux c'est de créer un programme avec le X-Plane Plugin SDK disponible ici :


      Daniel
      Intel I5 6500 3,2 Ghz, RAM 16 Go, GeForce GTX 960 2 Go, Linux Ubuntu 18.04
      Portable Asus Intel i5 2,8 Ghz, RAM 8 Go, GeForce 840M, Windows 8.1 64bits
      #AMD II X2 245 2,9 Ghz, RAM 8 Go, GeForce GTX 650 1 Go, Linux Ubuntu 14.04
      #AMD 64x2 5200 2,6 Ghz, RAM 4 Go, GeForce 9600 GT 512 Mo, Linux Ubuntu 10.04
      #MacBook Pro 15" 2,4 Ghz, RAM 4 Go, GeForce GT 330 M 256 Mo, Mac OS 10.6

      Commentaire


      • #4
        Bonjour,
        En effet, le principe de simulink est bien de partir de jolies boites et de créer et régler mon propre pilote.

        Ensuite l'interfaçage avec X-Plane est bien le suivant: Recevoir des données comme des attitudes, positions et vitesses et à partir de cela renvoyer des commandes de braquages des gouvernes à X-Plane afin de remplacer le joystick.

        Concernant le format d'échanges des données, il s'agirait plutot de double mais si des flottants conviennent mieux à ce type d'application je peux m'en contenter.

        Concernant le mode d'échange, j'ai tout d'abord pensé à l'éthernet mais j'ai cru lire dans un forum que pour X-Plane il fallait mieux utliser les Plugins? L'utilisation d'une zone mémoire est envisageable mais je ne m'y connais pas assez. Je suis ouvert à toutes propositions sur le sujet.

        En espérant que quelqu'un puisse m'aider dans cette aventure, je vous remercie tout de meme pour votre réactivité.

        Cordialement,
        X-plane 8.6 /Win XP Sp2/ AMD 64 3000+/ 1Go RAM/ RADEON 9200 128Mo

        Commentaire


        • #5
          oui mais justement le plug ing utilise le SDK...

          d'ailleurs il n'y as pas d'autre interface.


          :lol: :lol:
          IVAO/VATSIMF-HFCE
          mac OS 10.6.8+ Cybord 3D ch throttle 4 quadrant /mac OS 10.6.8/TS (plantronics DSP 500) /Xplane v9.70 + palonnier CH + TrackiR 5 + TrackPRO

          Commentaire


          • #6
            Si je comprends bien la comm Ethernet sous X-plane se fait aussi via un plugin développé sur la base de SDK?

            Avec vous un exemple de ce plugin ?

            Merci d'avance
            X-plane 8.6 /Win XP Sp2/ AMD 64 3000+/ 1Go RAM/ RADEON 9200 128Mo

            Commentaire


            • #7
              Envoyé par doudou
              Concernant le format d'échanges des données, il s'agirait plutôt de double mais si des flottants conviennent mieux à ce type d'application je peux m'en contenter. Concernant le mode d'échange, j'ai tout d'abord pensé à l'éthernet mais j'ai cru lire dans un forum que pour X-Plane il fallait mieux utiliser les Plugins? L'utilisation d'une zone mémoire est envisageable mais je ne m'y connais pas assez.
              Faire un plugin est effectivement incontournable, mais la manière de le faire peut varier grandement suivant le fonctionnement souhaité.
              Il reste toujours a savoir deux choses :

              A - Comment les boites Simulink vont-elles s'exécuter dans le plugin ? A cela il y a au moins deux réponses :
              1 - Simulink génère du code que l'on peut introduire dans la compilation du plugin.
              2 - On se fait le code à la main à partir des boites Simulink.

              La réponse 1 est préférable, elle évite bien des erreurs potentielles, mais là c'est toi qui va savoir si Simulink génère du code, et quel code (C serait l'idéal).

              B - Comment les valeurs sont-elles passées entre Simulink et X-Plane ? Et là aussi c'est du côté Simulink qu'il faut aller voir.
              Il va y avoir de la collecte à faire côté X-Plane pour mettre ça au format Simulink, et l'inverse avec les sorties du modèle.

              C - Je suis quasi certain que Simulink a besoin de voir son modèle tourner N fois par secondes pour que ses intégrations se fassent convenablement, quel est ce N ? Est-il imposé ?

              Accessoirement :
              D- Est-ce que tu souhaite qu'il ya ait inter activité entre le plugin et les boites Simulink ? (genre je change un paramètre dans la boite et le plugin le reçoit et l'utilise).
              E - Dans ce cas est-ce que Simulink va tourner sur le même PC que X-Plane ?

              Une petite visite sur le site MathWorks montre qu'il y a deux chose susceptible de nous interesser :

              "Real-time workshop 7.0"
              "Real-Time Workshop Embedded Coder 5.0"

              J'ai téléchargé des PDFs, je vais voir ce qu'ils racontent.

              PhM
              X-Plane 9.70 & 11.5r1 / W10 / AMD Ryzen 7 2700 / 8Go RAM / Sapphire R9 390 Nitro 8Go / Sapphire HD7870 GHz 2Go / Samsung LN40C530 / Oculus DK2 / LeapMotion / Saitek X56 / Thrustmaster Pendular Rudder

              Commentaire


              • #8
                Bonjour,

                En effet, les options RTW de simulink semblent permettre de générer du code en C à partir des boites Simulink. Je ne sais pas encore trop la forme que cela peut avoir mais je vais regarder.

                Concernant le point A): je comprends le principe tout d'abord générer du code C à partir de simulink et l'intégrer dans un plugin X-plane. Est il possible de passer par une comme éthernet au lieu d'integrer ce code dns un plugin, c'est à dire que Simulink envoie de infos à X-plane par un port ethernet et idem avec X-Plane?

                Concernant le point B), il s'agira tout de meme plutot de doubles dans la plupart des cas. Peut etre quelques entiers pour des commandes tout ou rien.

                Concernant le point C), en effet simulink devra surement tourner plusieurs fois à la seconde. Pour le moment ce N n'est pas encore imposé, mais est ce que X-plane a des contraintes de rafraichissement des données ou impose t il quelquechose ?

                Ensuite Pour D) l'interactivité entre Simulink et X-plane est à envisager dans les deux sens. Et Pour E) je pense que pour le moment Simulink et X-plane tourneront sur le meme PC.

                Merci pour l'aide
                X-plane 8.6 /Win XP Sp2/ AMD 64 3000+/ 1Go RAM/ RADEON 9200 128Mo

                Commentaire


                • #9
                  Envoyé par doudou
                  Est il possible de passer par une comme éthernet au lieu d'integrer ce code dns un plugin, c'est à dire que Simulink envoie de infos à X-plane par un port ethernet et idem avec X-Plane?
                  Théoriquement oui, mais c'est pas le mieux pour du temps réél, il y a aura des délais de transmission, pas grands si X-Plane et Simulink sont les deux seuls sur la ligne (on s'arrange pour qu'on ai pas de collisions), mais des délais quand même et ça pourrait amener des problèmes.

                  Envoyé par doudou
                  Concernant le point C), en effet simulink devra surement tourner plusieurs fois à la seconde. Pour le moment ce N n'est pas encore imposé, mais est ce que X-plane a des contraintes de rafraichissement des données ou impose t il quelquechose ?
                  Oui, les plugins sont appelés une fois à chaque rendu vidéo, donc vitesse de rafraichissement variable, donc temps d'intégration variable. Et, à scène égale, le temps de rendu vidéo est fonction de la machine. Au mieux quand je me promène entre les plateformes de forage ça tourne au dessus de 100, en région parisienne c'est entre 30 et 50 en gros. Donc si il est impératif d'avoir une fréquence plus haute que ça ou plus stable ça va être moins simple. Et bien sûr si le plugin prend deux heures à tourner, ben ça fait descendre les fps.

                  PhM
                  X-Plane 9.70 & 11.5r1 / W10 / AMD Ryzen 7 2700 / 8Go RAM / Sapphire R9 390 Nitro 8Go / Sapphire HD7870 GHz 2Go / Samsung LN40C530 / Oculus DK2 / LeapMotion / Saitek X56 / Thrustmaster Pendular Rudder

                  Commentaire


                  • #10
                    Salut !

                    Mon humble point de vue:
                    Tu crées un plugin X-Plane qui lance un second thread... je m'explique:
                    A chaque frame, xplane va appeler une fonction dans ton plugin qui doit donc être une fonciton légère et bornée dans le temps. Cette fonction a comme but d'aller ecrire dans des données d'XPlane nommées DATAREFS. C'est à ce moment que tu vas modifier les commandes à ton appareil.
                    Le second thread est un thread de communication UDP qui ouvre un port sur ta machine et attend les données. A chaque réception de donnée il bloque par un semaphore la variable qui partira dans xplane.

                    Ton programme simulink se connecte au port précédemment ouvert et y balance les données.

                    Ah, il faut penser qu'au mieux tu vas devoir mettre à jours 40 fois par seconde tes informations. Disons que tu passes 100 octets de commande à chaque fois... ca te fait que 4ko/S a echanger sur un port TCP local... y'aura pas de pb ;)

                    Avantage:
                    Tu es totalement indépendant au niveau langage.
                    Les communications par port TCP ou UDP sont des classiques donc toutes les boites à outils sont déjà dispo et tu n'as pas à réinventer la roue...

                    Inconvénient:
                    J'en vois pas


                    Tom
                    Volez bien, volez plein !
                    "THE ROTOR IS THE LIMIT!" ... Et c'est ton MFD qui doit te le dire.
                    "The flight deck is the ultimate human machine interface (HMI) application. It uses human senses of touch, hearing and sight in a safety critical situation."
                    VATSIM : F-ZBPH

                    Commentaire


                    • #11
                      Bonsoir,

                      Tout d'abord merci pour l'idée et l'aide.

                      Je crois comprendre dans le principe dans l'ensemble.

                      Ok pour la communications par port TCP ou UDP, je vais me débrouiller pour trouver ce qui convient à la fois pour simulink et pour du code en C.

                      PAr contre, le coup de la sémaphore et des deux threads dans un plugins, c'est beaucoup plus flou pour moi. Je suis vraiment débutant en la matière concernant les plugins et les threads aussi !
                      Avez vous des exemples de plugins qui realisent déja un peu près ce type de fonctionnement (plugins assurant le lancement de threads et la gestion d'une semaphore)?

                      Je vais réflechir à la fréquence de rafraichissement qu'il me faut mais en effet je ne pense pas dépasser 50hz voire 20hz pour la fréquence du pilote.



                      doudou
                      X-plane 8.6 /Win XP Sp2/ AMD 64 3000+/ 1Go RAM/ RADEON 9200 128Mo

                      Commentaire


                      • #12
                        pour le plug ing , il faut que tu créer un thread et que ce thread calcul mais aussi s'interface avec le SDK. C'est pour cela que toutes tes fonctions devront
                        être inférieur à à 1/50 fps , soit 50 Hz minimun.

                        Par contre, Matlab/simulink, je ne suis pas sur que cela sera assez réactif, il faut voir ce que cela va donner.


                        :lol: :lol:
                        IVAO/VATSIMF-HFCE
                        mac OS 10.6.8+ Cybord 3D ch throttle 4 quadrant /mac OS 10.6.8/TS (plantronics DSP 500) /Xplane v9.70 + palonnier CH + TrackiR 5 + TrackPRO

                        Commentaire


                        • #13
                          Bonsoir,

                          j'ai déjà réfléchi au problème, et en effet, Matlab par defaut ne peut recevoir la moindre information d'Xplane.
                          La méthode la plus simple consiste à produire, éventuellement, un modèle sous Simulink et de l'implanter soi-même en C++ pour créer un plugin XPlane. J'ai déjà fait ça pour un plugin "Commandes de vol électriques d'avion Airbus" (CDVE), et ça marche très bien.

                          (je pense que tu es familier avec les termes technique d'automatique, donc je ne détaille pas. Au cas où, n'hésite pas à demander des définitions si je me suis mal exprimé).

                          Les inconvénients:
                          - Xplane fonctionne comme une boite noire. Ainsi, pour le réglage de tout un tas de coefficients de ton asservissement (gains dans le retour d'état par exemple, pour réguler en boucle fermée les variables qui t'intéressent), tu devras procéder "à la main". C'est à dire en essayant, voir ce que ça donne une fois l'asservissement mis en place dans un plugin Xplane pour observer la réaction du simulateur, et corriger tes valeurs en conséquent.
                          - en gros, si on pouvait prendre un "modèle" du fonctionnement d'Xplane (en terme d'équation différentielle sur un vecteur d'état contenant un tas de variables utilisées dans le vol d'un avion), on pourrait l'introduire dans Simulink et alors mettre en place un asservissement en boucle fermée sur le système "Xplane" où les gains des correcteurs seraient calculés automatiquement. Malheureusement, comme je l'ai dit, Xplane est une "boite noire" et donc on doit tout régler en testant, en envoyant des échelons en entrées (commande sur les organes de pilotage pour les CDVE, ou consignes pour un PA).
                          - dernièrement (ça concerne surtout les CDVE, c'est moins flagrant sur le PA), même si on pouvait pondre une équation différentielle régissant un vecteur d'état X constitué de variables relatives au vol, il faut voir que les coefficients de la matrice A utilisée dans l'équation diff:
                          X' = AX + Bu où u est l'entrée
                          ces coeff de A sont fortement dépendant d'un tas de paramètres de vol (vitesse, altitude ...). Ainsi, il faudrait calculer les gains en boucle fermée (gains des correcteurs par ex, pour l'exemple des CDVE) pour toutes les valeurs possibles de V et h ... Autrement dit, tes réglages sont valables uniquement autour d'un cas de vol donné (autour duquel s'est fait la linéarisation des équations de la mécanique du vol, qui donne le système X'=AX+Bu).
                          On doit donc (dans la méthode la plus simple), pour fonctionner quelque soit le cas de vol, calculer des gains pour un échantillon de couples (V,h) (ou simplement en fonction du Mach, pour relier ces paramètres) et ensuite interpoler les gains correspondant à (V,h) quelconques à partir de ces gains échantillonnés.

                          Voilà pour la méthode de réglage d'un asservissement avec Xplane. Pour que ça fonctionne dans tous les cas de vol, il faut faire bcp de réglage d'asservissement à la main ! donc quel est l'intéret de Simulink ici, je ne sais guère, car il est surtout utile pour calculer un tas de chose automatiquement en fonction du type de réponse souhaité pour un système asservi.

                          PS: par exemple, le plugin XFCS de commandes de vol électriques Python créé par Nils ne répond pas à ces problèmes de cas de vol complexes. Il effectue par exemple une interpolation d'ordre 1 sur les gains, alors que la variété des cas de vol d'un avion de chasse en nécessiterait au moins un ordre 10 (sur mon plugin CDVE_Airbus, j'ai de l'ordre 3 et je n'en suis déjà pas satisfait). La contrepartie, c'est que son plugin est utilisable par tous, alors que celui que j'ai fait est indiffusable car trop difficile à régler (mais par conséquent, il est plus performant).
                          De même, mais ça on ne peut rien y faire, le calculs des gains des commandes de vol dépend fortement de l'avion avec lequel on les a fait. Si on change d'appareil, théoriquement tout est à refaire (voilà pourquoi le plugin XFCS est un plugin "standart" d'avion de chasse, qui marchera moyennement quelque soit l'avion. Si on veut un plugin très performant, il faut le dédier à l'avion qu'on construit).

                          Commentaire


                          • #14
                            Envoyé par pichou
                            ...La méthode la plus simple consiste à produire, éventuellement, un modèle sous Simulink et de l'implanter soi-même en C++ pour créer un plugin XPlane.
                            Je n'ai pas trouvé d'infos sassez précises sur le site de MathWorks mais mes souvenirs de MatrixX et Autocode (qui est la version N I de Simulink & Co), me disent que la version la plus simple est d'utiliser le code source généré par Simulink, ce qui évite bon nombre d'erreurs, et de le compiler avec le code du plugin.

                            Le plugin est alors en charge de donner les valeurs d'entrée venant de X-Plane au modèle, faire tourner le code et passer les valeurs de sortie à X-Plane. Il peut également gérer des communications sur ethernet, via un thread réseau comme précisé, cela permet de visualiser tout ce que l'on veut sur un autre PC. Dans ce genre là.


                            PhM
                            X-Plane 9.70 & 11.5r1 / W10 / AMD Ryzen 7 2700 / 8Go RAM / Sapphire R9 390 Nitro 8Go / Sapphire HD7870 GHz 2Go / Samsung LN40C530 / Oculus DK2 / LeapMotion / Saitek X56 / Thrustmaster Pendular Rudder

                            Commentaire


                            • #15
                              Salut,


                              Je pensais à un truc comme ca:




                              Comme ca tu es d'une part indépendant entre le plugin et le calculateur, tu peux déporter le simulateur sur un autre ordi si besoin de puissance...

                              Tom
                              Volez bien, volez plein !
                              "THE ROTOR IS THE LIMIT!" ... Et c'est ton MFD qui doit te le dire.
                              "The flight deck is the ultimate human machine interface (HMI) application. It uses human senses of touch, hearing and sight in a safety critical situation."
                              VATSIM : F-ZBPH

                              Commentaire

                              Chargement...
                              X