Cockpit maison avec Arduino (comment faire) ?

[Lami]

Bonjour Thierry,

Merci pour ton aide !

De mémoire et de compréhension, si je ne me trompe pas, tout ce que tu fais avec Teensy, je le fais présentement avec Arduino et la carte Ethernet (voir mes derniers codes sources poste #38 de la présente discussion). Est-ce que je me trompe ?

Car là, je souhaite par exemple récupérer les données de X-Plane pour afficher sur un écran LCD, les fréquences des radios. Tu peux faire ce genre de chose avec Teensy en mode DFU --> Joystick-USB ?

Pour ce qui est du « PULLUP for setting "High" when pin open (LOW when on the GND). », cela reste nébuleux pour ce qui est d'une différence ou pas entre GND (mise à la terre) et courant négatif (-).

L'ami René
Tous pour un et un pour tous !

[PhM]

...Est-ce que vous pourriez m'expliquer dans vos mots ce que veux dire « PULLUP for setting "High" when pin open (LOW when on the GND). »,...

C'est relatif à quoi cette question ? Un port d'arduino ? D'autre chose ? D'où vient la phrase que tu mentionnes ?

PhM

[PhM]

... il y a ce que j'appelle le tordage de bits, don je connaît et comprend le principe de fonctionnement, mais je ne paître pas du tout cette technique, genre :

union
{
    char ValeurFormat4Byte[4];
    float ValeurFormat1Float;
} TemponComUDP;

C'est là où se révèle la limite du "hacking", à un moment il faut acquérir la connaissance pour comprendre ce que l'on fait.

Une union défini comment les données vont pouvoir être utilisées. Dans l'exemple donné TemponComUDP peut être lu comme un flottant ou bien un tableau de quatres octets.

• TemponComUDP.ValeurFormat1Float accède à un flottant.
• TemponComUDP.ValeurFormat4Byte[0] accède au premier octet.
• TemponComUDP.ValeurFormat4Byte[1] accède au deuxième octet.
• TemponComUDP.ValeurFormat4Byte[2] accède au troisième octet.
• TemponComUDP.ValeurFormat4Byte[3] accède au quatrième octet.

Tout dépend de ce que l'on souhaite faire avec les données dans TemponComUDP.

PhM

[PhM]

...Car là, je souhaite par exemple récupérer les données de X-Plane pour afficher sur un écran LCD, les fréquences des radios. Tu peux faire ce genre de chose avec Teensy en mode DFU --> Joystick-USB ?...

Tu peux le faire en mode tout fait soi-même : un plugin lit les valeurs dans X-Plane, envoie un paquet UDP, qui est reçu par un arduino ou n'importe quoi d'autre connecté au réseau et qui affiche ça sur ce que tu veux. C'est ce que j'avais fait pour "ressusciter" DLG_Cockpit qui utilise les UDPs "à la Austin" et qui donc avait cessé de fonctionner en v10.

PhM

[FlyingBaldy]

Bonjour Lami,

Je vois dans tes différents posts que tu poses de nombreuses questions relatives à de nombreux domaines (fonctionnement d'un moteur, programmation Arduino, programmation plug-in...) et en français.
je ne vais pas pouvoir répondre à tout, en tout cas pas avant lundi mais voici déjà quelques indices, en complément des réponses déjà fournies par PhM.

Le problème c'est qu'il y a plusieurs types de boutons Ignition, je le découvre dans le fichier « DataRefs.txt », en tombent sur les lignes suivantes :

sim/cockpit2/engine/actuators/igniter_on int[8] y boolean Igniter, on or off.
sim/cockpit2/engine/actuators/auto_ignite_on int[8] y boolean De-ice switch, 0 or 1. De-ice - auto-ignition. This switch turns on a continuous ignition source in the engine to automatically relight it if there is a flameout.
sim/cockpit2/engine/actuators/ignition_on int[8] y enum 0 = off, 1 = left, 2 = right, 3 = both
sim/cockpit2/engine/actuators/ignition_key int[8] y enum 0 = off, 1 = left, 2 = right, 3 = both, 4 = starting

Il y a plusieurs variables pour gérer l'allumage parce qu'il existe plusieurs types de moteurs:
sim/cockpit2/engine/actuators/igniter_on :
Pour moteur à turbine à gaz : turboréacteur, turbopropulseur, turbomoteur (hélicoptère...). Dans un tel moteur, l'allumage ne doit se faire qu'au démarrage. Une fois que le moteur tourne de manière autonome, on arrête le démarreur et l'allumage (je peux fournir plus d'explication sur la raison).

sim/cockpit2/engine/actuators/auto_ignite_on :
Pour moteur à turbine à gaz : dans certaines conditions défavorables (météo ou poussières volcaniques), le risque existe de voir un des moteurs s'arrêter. Pour faciliter et accélérer le redémarrage, on laisse l'allumage fonctionner en permanence (tant que cette commande est activée)

sim/cockpit2/engine/actuators/ignition_on :
Pour moteurs à piston sans démarreur (un aide fait tourner l'hélice à la main) : par redondance, les circuits sont doublés (2 bougies apr cylindre, double circuit, double magnéto). Le fonctionnement normal est OFF (coupé) ou BOTH (les deux circuits en fonctionnement), mais il est vital de pouvoir tester chaque circuit (dynamo) séparément. L'interrupteur permet donc de ne sélectionner qu'une des deux magnétos (gauche ou droite) pour ces tests.

sim/cockpit2/engine/actuators/ignition_key :
Pour moteurs à piston avec démarreur : avec position START de démarrage, c'est-à-dire le moteur électrique qui va entraîner le moteur à piston (comme sur une voiture). La position START est temporaire et est relâchée une fois que le moteur tourne. Il paraît donc raisonnable que X-Plane n'accepte pas qu'on lui impose une valeur pour cette variable.

Il faut donc réaliser un programme Arduino en fonction de l'avion (et du moteur) que l'on cherche à simuler.
Ne pas vouloir faire un programme générique (c'est possible mais il faut suffisamment de connaissances dans les différentes disciplines évoquées : avion, propulsion, langage C, Arduino, plugin).

[FlyingBaldy]

Pour ce qui est du code source lui-même, il y a ce que j'appelle le tordage de bits, don je connaît et comprend le principe de fonctionnement, mais je ne paître pas du tout cette technique, genre :

union
{
char ValeurFormat4Byte [4];
float ValeurFormat1Float;
} TemponComUDP;

Pour compléter l'explication de PhM, l'intérêt d'une variable "union" est de pouvoir traiter un même objet de deux façons différentes:
L'objet est "TemponComUDP"
On y accède :
* soit sous forme de caractères via le nom "ValeurFormat4Byte" qui est un vecteur de 4 caractères
* soit sous forme de flottant via la variable "ValeurFormat1Float"
Comme ce sont deux représentations d'un même objet, modifier une des représentations modifie simultanément l'autre représentation (modifier la valeur du FLOAT modifiera automatiquement sa représentation hexadécimale en caractères et vice versa)).

Il ne faut par exemple pas faire de conversion de type (CHAR > FLOAT ou FLOAT > CHAR).
Sans "union", il faudrait lire les caractères successivement envoyés par X-Plane, puis les assembler par quatre, puis les convertir en une valeur FLOAT.
Avec "union", il suffit de lire les caractères et le résultat est directement accessible sous forme de FLOAT (nombre réel avec virgule flottante).

[FlyingBaldy]

Bonjour Thierry,

J'ai regardé ça avec attention.

Mon d'analyser me porte à penser que ce code est pour un unique modèle d'avion et cockpit maison, et je n'y trouve rien pour ce qui nous intéresse.

Mais ça lecture ne fut pas inutile et il n'y a pas de hasard, le mot anglais « fallingEdge » m'a fait penser au mot « fêlure » et cela m'a mi sur une piste.

Effectivement, je conseille fortement de ne réaliser un programme "que" pour un avion précis (ou un type d'avion ou d'hélicoptère précis).

"Falling edge" n'a pas de rapport avec fêlure mais signifie "front descendant (voir figure d'un post précédent).
En binaire, les valeurs peuvent être "0" ou "1" (ou encore "Bas" ou "Haut"). Lorsqu'un signal passe du "0" à "1", on a un "front montant" (Rising edge). Lorsque le signal passe de "1" à "0", il s'agit d'un "front descendant" (Falling edge).

Est-ce que vous pourriez m'expliquer dans vos mots ce que veux dire « PULLUP for setting "High" when pin open (LOW when on the GND). », et dans ce contexte, est-ce qu'il y a une différence pour la carte Arduino entre GND (mise à la terre) et courant négatif ? En électricité, il y a bien une différence entre le fils négatif et le fils de la mise à la terre, non ?

Une très brève introduction à l'électronique digitale s'impose.

L'électronique analogique (variation continue de tension) présente deux défauts:
* la perturbation de l'information lors de sa transmission (la tension lue à la sortie du capteur varie lors de sa transmission par effet de résistance, perturbations magnétiques...).
* il est difficile d'effectuer des calculs avec des tensions

L'électronique digitale/numérique permet de corriger ces deux inconvénients:
* Avant la transmission, la tension est convertie en un nombre sous forme binaire (notre système décimal est basé sur 10 chiffres de 0 à 9, le système binaire sur deux chiffres 0 et 1).
la valeur "0" correspond à la masse. La valeur "1" à une tension de référence (5V, 3V3, 12V...). Il n'y a pas besoin de tension négative puisque l'électronique digitale se satisfait de deux états.
Lors de la transmission, même une déformation importante du signal ne faussera pas la lecture (exemple, si le récepteur (Arduino par exemple) lit un signal de 3.5V, il comprendra qu'il s'agit de la valeur "1" et pas de la valeur "0").
On bénéficie en plus de la possibilité d'ajouter des chiffres de vérification (checksum), qui sont calculés au départ en fonction des nombres transmis. Le récepteur refait le calcul sur base des nombres reçus. S'il détecte un écart, cela signifie qu'il y a eu un problème de transmission.
* Le système digital est naturellement adapté aux calculs.

Si le récepteur reçoit un signal de 3V ou plus (exemple), il sait qu'il reçoit une valeur "1".
Si le récepteur reçoit un signal de 1V ou moins (exemple), il sait qu'il reçoit une valeur "0".
Que se passe-t-il si une broche n'est pas raccordée ("laissée en l'air")? Le récepteur ne sait pas comment considérer l'information.
Il est donc de bonne pratique d'imposer une valeur lorsqu'une broche n'est pas raccordée, par exemple :
« PULLUP for setting "High" when pin open (LOW when on the GND). » que l'on pourrait traduire par :
"Tirer le signal vers le haut pour qu'il soit au niveau "HAUT" lorsque la broche n'est pas raccordée (niveau BAS lorsqu'elle est raccordée à la masse)"
Cela veut dire que chaque broche non raccordée est en fait raccordée à la tension de référence (5V par exemple).

Est-ce que dans X-Plane il y aurait une fonction de retour d'information en cas d'absence d'un objet dans un cockpit. Est-ce que je pourrais interroger X-Plane pour connaître le type ou le nombre d'options pour d'une composante de cockpit ?

Je pense que non parce que cela est fonction de l'avion modélisé.
Il faut adapter le programme Arduino et le plug-in éventuel à l'avion (ou hélicoptère) tel qu'il a été modélisé par le concepteur (Laminar ou autre).

Autre question, mais connexe; je ne maîtrise pas la récupération des données de X-Plane par l'Ethernet UDP. Alors est-ce que tu connais une personne francophone qui travaille avec la communication Ethernet UDP et X-Plane, et idéalement Arduino ?

C'est que je m’apprête à reproduire l'affichage avec l'Arduino sur écran LCD, GLCD ou TFT de par exemple les fréquences radios (NAV1, NAV2, COM1, COM2, ADF1, ADF2), les paramètres du FMS (vitesse air, altitude cible, la V/S, le cap, etc.).

Je vais commencer mes expérimentations lundi.
Le site du Baron58 est une excellente base. J'attends avec impatience son plug-in pour Arduino mais une des références données par Djetdail offre déjà une solution assez complète.
La structure d'un programme d'interface Ethernet pour Arduino est disponible sur le site officiel http://arduino.cc/en/Reference/Ethernet et http://arduino.cc/en/Tutorial/UDPSendReceiveString.

Le plus difficile est d'obtenir des informations fiables sur les données fournies par X-Plane.
PhM m'a déjà aidé en me signalant que les répertoires de l'installation de X-Plane contenaient des fichiers de référence (je les avais trouvés sur internet sans me rendre qu'ils étaient déjà installés) mais il subsiste, à mon sens, un mauvais suivi de ces références.
J'utilise comme référence la version "officielle" datée du 29 mai 2014 (http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html) mais je ne suis pas convaincu qu'elle soit complète et correcte.

[Lami]

C'est relatif à quoi cette question ? Un port d'arduino ? D'autre chose ? D'où vient la phrase que tu mentionnes ?

PhM

Bonjour PhM,

Merci pour ton aide et c'est pas parce que je ne l'écris pas dans chacune de mes réponses que je ne le pense pas à chaque fois !

Cela vient des exemples du site Web « Arduino Cockpit Simulator » (ex. : Using Arduino analog inputs for the buttons array) :

...
void setup()
{
  DataRef[500] = char(0);  // "end of string" char  for DREF 
  // Didital Pins ( ## 4, 10, 50, 51, 52, 53 ,54 can not be used - reserved for Ethernet, CD, SPI) 
  for (int i = 0; i < 50; i++)
    pinMode(i, INPUT_PULLUP);// PULLUP for setting "High" when pin open (LOW when on the GND)
  pinMode(13, INPUT); 
...

Et la traduction avec Google donne « PULLUP pour la mise en "haut" lorsque la broche ouverte (BAS lorsque le GND) » et le tous me fait me poser des questions.

C'est de la curiosité et de la soif de connaissance de ma part.

L'ami René
Tous pour un et un pour tous !

[Lami]

C'est là où se révèle la limite du "hacking", à un moment il faut acquérir la connaissance pour comprendre ce que l'on fait.

Une union défini comment les données vont pouvoir être utilisées. Dans l'exemple donné TemponComUDP peut être lu comme un flottant ou bien un tableau de quatres octets.

• TemponComUDP.ValeurFormat1Float accède à un flottant.
• TemponComUDP.ValeurFormat4Byte[0] accède au premier octet.
• TemponComUDP.ValeurFormat4Byte[1] accède au deuxième octet.
• TemponComUDP.ValeurFormat4Byte[2] accède au troisième octet.
• TemponComUDP.ValeurFormat4Byte[3] accède au quatrième octet.

Tout dépend de ce que l'on souhaite faire avec les données dans TemponComUDP.

PhM

C'est ce que je comprenais, mais je n'ai jamais moi-même défini ce genre de structure, mais j'utilisais celles faites par d'autres.

Mais avec ton exemple, cela devient plus clair, je viens de piger un truc là, concernant la manière de l'utiliser et du pourquoi des « [x] ». Et bien encore merci PhM !

Que personne n'oublie que c'est en forgeant que l'on devient forgeron...

L'ami René
Tous pour un et un pour tous !

[Lami]

Tu peux le faire en mode tout fait soi-même : un plugin lit les valeurs dans X-Plane, envoie un paquet UDP, qui est reçu par un arduino ou n'importe quoi d'autre connecté au réseau et qui affiche ça sur ce que tu veux. C'est ce que j'avais fait pour "ressusciter" DLG_Cockpit qui utilise les UDPs "à la Austin" et qui donc avait cessé de fonctionner en v10.

PhM

J'en conviens, c'est l'idéal !

Oh ! En regardant pour savoir ce que c'est que « DLG_Cockpit », je découvre, si je comprends bien que tu es le père du fabuleux « XHSI - projet open source pour construire des instruments de simulateur d'avion de haute fidélité pour X-Plane », WOW !

Alors, si c'est bien le cas, il faut être honnête là, on ne peut pas tous être des prodiges de la programmation et de la simulation en aéronautique. Dès comme toi, dans le monde il n'y en a pas plus de 1000, alors il faut être empathique pour ceux qui n'ont pas tes capacités !

Ouf, merde, ton XHSI, c'est un petit bijou que j'utilise depuis des années !!!

Il y avait pas 13 Jésus, mais 1 Jésus et 12 apôtres dans l'histoire...

Sois un peu empathique pour les débutants !

OK, j'arrête !

Et toi qui disais que l'Open Source c'était pas bon !!! OK, OK, j'arrête !

Je passe une demande à mon ami PayPal, pour un 20 $ CAD dès la fin de mes présentes réponses.

L'ami René
Tous pour un et un pour tous !

[PhM]

... si je comprends bien que tu es le père du fabuleux « XHSI - projet open source pour construire des instruments de simulateur d'avion de haute fidélité pour X-Plane »

Non, tu as mal compris, ce n'est pas moi. Je disais simplement que j'avais rendu de nouveau utilisable DLG_Cockpit.

PhM

[Lami]

Bonjour FlyingBaldy,

Merci pour ton aide et comme pour PhM, c'est pas parce que je ne l'écris pas dans chacune de mes réponses que je ne le pense pas à chaque fois !

Bonjour Lami,
...
Il y a plusieurs variables pour gérer l'allumage parce qu'il existe plusieurs types de moteurs:
...
Il faut donc réaliser un programme Arduino en fonction de l'avion (et du moteur) que l'on cherche à simuler.
Ne pas vouloir faire un programme générique (c'est possible mais il faut suffisamment de connaissances dans les différentes disciplines évoquées : avion, propulsion, langage C, Arduino, plugin).
...

Merci pour tous ces détails, j'en connaissais, mais pas autant sur tous les types de moteur. Ça va être utile.

Ma question était plus dans le sens de « Vous, comment vous vous y prendriez pour faire un code pour justement un module générique pour la gestion de tous les types de démarreurs ? ».

Je dirais donc que la question reste entière. Mais les exemples que vous me donnerez me serviront aussi pour tous les autres équipements qui ont plusieurs variantes, par exemple les modules de radios, les AP, les éclairages extérieurs, etc.

Je suis très bon dans le recyclage, un bon exemple pour un type d’instrument et je pourrai l’appliquer à tous les autres types d’instruments.

Vous m'en donnez un et je vous en retournerai dix.

N'oubliez pas ma devise (voir sous ma signature) !

L'ami René
Tous pour un et un pour tous !

[Lami]

Pour compléter l'explication de PhM, l'intérêt d'une variable "union" est de pouvoir traiter un même objet de deux façons différentes:
L'objet est "TemponComUDP"
On y accède :
* soit sous forme de caractères via le nom "ValeurFormat4Byte" qui est un vecteur de 4 caractères
* soit sous forme de flottant via la variable "ValeurFormat1Float"
...

Oui, il y a le plus petit dénominateur commun, l’octet et il y a les boîtes de transport (par 1 ou par 4, etc.) ou l'on pourrait dire aussi deux d'identités ou deux mots de passe !

L'ami René
Tous pour un et un pour tous !

[Lami]

Effectivement, je conseille fortement de ne réaliser un programme "que" pour un avion précis (ou un type d'avion ou d'hélicoptère précis).

"Falling edge" n'a pas de rapport avec fêlure mais signifie "front descendant (voir figure d'un post précédent).
En binaire, les valeurs peuvent être "0" ou "1" (ou encore "Bas" ou "Haut"). Lorsqu'un signal passe du "0" à "1", on a un "front montant" (Rising edge). Lorsque le signal passe de "1" à "0", il s'agit d'un "front descendant" (Falling edge).

Ah, là, il y a de la brume qui se dissipe !

Une très brève introduction à l'électronique digitale s'impose.
...
Que se passe-t-il si une broche n'est pas raccordée ("laissée en l'air")? Le récepteur ne sait pas comment considérer l'information.
Il est donc de bonne pratique d'imposer une valeur lorsqu'une broche n'est pas raccordée, par exemple :
« PULLUP for setting "High" when pin open (LOW when on the GND). » que l'on pourrait traduire par :
"Tirer le signal vers le haut pour qu'il soit au niveau "HAUT" lorsque la broche n'est pas raccordée (niveau BAS lorsqu'elle est raccordée à la masse)"
Cela veut dire que chaque broche non raccordée est en fait raccordée à la tension de référence (5V par exemple).

Là aussi, il y a de la brume qui se dissipe, mais je vais relire quelques fois, parce j'ai encore un peu de brume dans ce coin-là !

...
Je pense que non parce que cela est fonction de l'avion modélisé.
Il faut adapter le programme Arduino et le plug-in éventuel à l'avion (ou hélicoptère) tel qu'il a été modélisé par le concepteur (Laminar ou autre).

C'est vrai que c'est prétentieux de ma part de vouloir faire le gros truc complet. Comme je commence dans le domaine, je devrais peut-être m'efforcer de faire moins, mais de faire mieux !

...
Je vais commencer mes expérimentations lundi.
Le site du Baron58 est une excellente base. J'attends avec impatience son plug-in pour Arduino...

Moi aussi !

... mais une des références données par Djetdail offre déjà une solution assez complète.
La structure d'un programme d'interface Ethernet pour Arduino est disponible sur le site officiel http://arduino.cc/en/Reference/Ethernet et http://arduino.cc/en/Tutorial/UDPSendReceiveString.

Le plus difficile est d'obtenir des informations fiables sur les données fournies par X-Plane.
PhM m'a déjà aidé en me signalant que les répertoires de l'installation de X-Plane contenaient des fichiers de référence (je les avais trouvés sur internet sans me rendre qu'ils étaient déjà installés) mais il subsiste, à mon sens, un mauvais suivi de ces références.
J'utilise comme référence la version "officielle" datée du 29 mai 2014 (http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html) mais je ne suis pas convaincu qu'elle soit complète et correcte.

Je vais regarder ça avec attention, merci de les ramener ! Et re-merci à Djetdail !

L'ami René
Tous pour un et un pour tous !

[Lami]

Non, tu as mal compris, ce n'est pas moi. Je disais simplement que j'avais rendu de nouveau utilisable DLG_Cockpit.

PhM

Alors, toutes mes excuses à tous !!!

Le don va tout de même être très bien investi !

L'ami René
Tous pour un et un pour tous !