Annonce

**Lami** · 27 juillet 2014, 16h58

Bonjour,

Voici une traduction qui m'est compréhensible. C'est d'une petite partie de la page « Baron-58 Cockpit Simulator - Data, info, reference » :

Data transmitted by Arduino

When using UDP DATA method, Arduino must send data to X-Plane in the same format as simulator sends them (program forms the same packets of data, i.e. [header DATA0]+[Number of the group]+[8 float Data parameters] )

When using UDP DREF method, Arduino sends data in the format: [header DREF0]+[Value in float]+[X-Plane dataref string]+[End sequence].

And, when using UDP CHAR method, data format to send is simpliest: [header CHAR0]+[keystroke].

En français ça donne :

Les données transmises par Arduino

Lorsque vous utilisez la méthode DONNÉES UDP, Arduino doit envoyer des données à X-Plane dans le même format que le simulateur les envoie (programme forme les mêmes paquets de données, c'est à dire [tête DATA0] + [Numéro du groupe] + [8 paramètres de données float] )

Lorsque vous utilisez la méthode UDP DREF, Arduino envoie des données dans le format: [tête DREF0] + [Valeur du flottant] + [X-Plane dataref chaîne] + [séquence de fin].

Et, lorsque vous utilisez la méthode UDP CHAR, le format de données à envoyer est plus simple: [tête CHAR0] + [touche].

Il y a donc aussi le type de communication « CHAR », qui pourrait bien être utile à l'occasion...

Je vais étudier tout cela avec attention.

Bon dimanche.

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

**FlyingBaldy** · 27 juillet 2014, 18h55

C'est ce que j'expliquais brièvement précédemment:

De X-Plane vers la carte Arduino
Uniquement message de type DATA : [DATA<] + [groupe 1] + [groupe 2] + ... + [groupe n]
Chaque groupe est constitué de 36 bytes comme suit : [index de 4 bytes] + [élément 1] + [élément 2] + [élément 3] + [élément 4] + [élément 5] + [élément 6] + [élément 7] + [élément 8]
L'index comprend 4 bytes :
* le premier correspond à l'index donné par X-Plane pour les données d'entrée/sortie, par exemple 3 pour les vitesses, 62 pour les jauges carburant, 67 pour les indicateurs de train d'atterrissage, etc.
* les trois suivants = 0
Chaque élément correspond à un des 8 éléments affichés par X-Plane dans le coin supérieur gauche de l'écran
Chaque élément est exprimé par une valeur en float, écrite en 4 bytes (voir conversion automatique par union.
A la base, trois types de valeur existent dans X-Plane avant conversion en float pour l'échange de données par UDP :
* float : pas de conversion
* entier (int) : conversion
* booléen (boolean) : pas de conversion

Comment lire ces données UDP venant de X-Plane?
1. on ignore les 5 premiers caractères (qui sont toujours les mêmes DATA<)
2. on lit le premier groupe de 36 bytes
3. on lit l'index (le premier byte de chaque groupe)
4. on ignore les 3 valeurs suivantes (toujours zéro)
5. on lit les valeurs de chaque élément par groupe de 4 bytes. Après lecture des 4 bytes, on déduit (par union) la valeur au format Float. Si nécessaire cette valeur est convertie en entier avec int().
6. on agit en fonction de la valeur.
7. on recommence au point 2 tant qu'il y a des données

De la carte Arduino vers X-Plane
Les messages commencent toujours par un Header/Prolouge de 5 caractères dont 4 pour le type de message, suivis d'un zéro

Message DATA
Très semblable à l'envoi par X-Plane, sauf le cinquième caractère qui doit être un zéro, ainsi que le caractère qui suit le dernier groupe d'éléments.
On a donc: [DATA0] + [groupe 1] + [groupe 2] + ... + [groupe n]+[0]
Chaque groupe est constitué d'un index en 4 bytes et de 8 valeurs en 4 bytes.
Les valeurs entières doivent être converties en float avant d'être transmises.
Si une valeur ne doit pas être modifiée, la valeur à transmettre doit être -999.
Exemple : pour éteindre l'avionique (index 106, élément 1):
Le message devrait être : [DATA0] + [106,0,0,0] + [0.0] + [-999] + [-999] + [-999] + [-999] + [-999] + [-999] + [-999]
Explication : Header + Index + Faux + Inchangé + Inchangé + ...

Les autres messages ne fonctionnent pas chez moi (tout fonctionne mais X-Plane ne tient pas compte des ordres envoyés)
Message de commande
[CMND0] + [texte de la commande] (sans [0] final?)

Message de commande par touche clavier
[CHAR0] + [touche du clavier]

Message de Dataref
[DREF0] + [valeur de la Dataref en 4bytes (=float)] + [texte de la Dataref] + [un nombre d'espaces égal à 500 moins la longueur du texte de la Dataref] + [0]

Message pour simuler un clic de souris
[MOUS0] + [position X] + [position Y]
avec position X= distance de puis la gauche de l'écran
position Y= distance de puis le bas de l'écran

Message de panne
[FAIL0] + [numéro de système au format ASCII] (par exemple "FAIL0145" pour simuler une panne du système 145)
[RECO0]+ [numéro de système au format ASCII] (par exemple "RECO0145" pour simuler la fin d'une panne du système 145)

etc, etc.

**FlyingBaldy** · 27 juillet 2014, 18h59

Envoyé par Lami Voir le message

Bonjour FlyingBaldy,

Un point positif, chez-moi ça fonctionne avec le paramètre :

Code:

  CarteEthernetUDP.write ("CMND0");

Et voici les bouts codes utilisés :
...

Code:

//*****************************************************************************
// Déclaration des variables globales.
//*****************************************************************************
// Bascule pour allumer/étindre toutes les lumières extérieures.
boolean LumieresAllumees = NON;


...

Le code fonctionne, donc X-Plane accepte la commande et agit en fonction de celle-ci?

boolean NON est refusé par mon compilateur Arduino (il n'accepte que TRUE et FALSE).

Pour le code en commun, cela va être difficile puisqu'il ne fonctionne chez moi en émission et réception qu'avec des DATA, ce qui est un peu lourd (mais ça fonctionne).

**Lami** · 27 juillet 2014, 22h15

Bonjour FlyingBaldy,

Je ne peux répondre plus pour le moment...

Code:

//*****************************************************************************
// Déclaration des constantes de base pour franciser le code source.
//*****************************************************************************
/*
Par convention, pour nommer une constante, nous utiliserons des noms écrits
tout en majuscule, en capitale, ce qui facilitera leur repérage et rendra le
code plus facilement compréhensible. Le mot devant notre nom de constante
indique à l'Arduino l'espace mémoire à réserver pour stocker cette donnée.
Après le nom de notre constante, on lui attribue sa valeur.
*/
/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « ENTREE » est l'équivalent du paramètre « INPUT ». Ce paramètre est
pour prépare l'Arduino a recevoir une tension électrique pour ce connecteur, sur
ce port de communication, sur ce "pin".
*/
const byte ENTREE = INPUT;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « ENTREE_ET_RESISTENCE_INTERNE » est l'équivalent du paramètre
« INPUT_PULLUP ». Ce paramètre est pour prépare l'Arduino en activant sa
résistance interne et a recevoir une tension électrique pour ce connecteur,
sur ce port de communication, sur ce "pin".
*/
const byte ENTREE_ET_RESISTENCE_INTERNE = INPUT_PULLUP;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « SORTIE » est l'équivalent du paramètre « OUTPUT ». Ce paramètre
est pour prépare l'Arduino a émettre une tension électrique pour ce connecteur,
sur ce port de communication, sur ce "pin".
*/
const byte SORTIE = OUTPUT;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « HAUT » est l'équivalent du paramètre « HIGH ». Ce paramètre fait
que l'Arduino maintiendra un voltage haut sur ce connecteur, soit 3.3 Volts,
soit 5 Volts, selon sa propre tension d'alimentation. En électronique, cela
correspondra aux valeurs logiques « 1 », « Oui », ou « Vrai », etc.
*/
const byte HAUT = HIGH;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « BAS » est l'équivalent du paramètre « LOW ». Ce paramètre fait
que l'Arduino maintiendra un voltage bas sur ce connecteur, soit 0 Volt. En
électronique, cela correspondra aux valeurs logiques « 0 », « Non », ou
« Faut », etc.
*/
const byte BAS = LOW;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « NON » est l'équivalent du paramètre « false », cela
correspondra aux valeurs logiques « 0 », « Non », ou « Faut », etc.
*/
const byte NON = false;

/*
Constante pour franciser le code source du programme. Ici nous définissons que
la constante « OUI » est l'équivalent du paramètre « true », cela
correspondra aux valeurs logiques « 1 », « Oui », ou « Vrai », etc.
*/
const byte OUI = true;
//*****************************************************************************

C'est dans tous mes code...

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

**Lami** · 28 juillet 2014, 05h41

Bonjour FlyingBaldy,

Un grand merci pour les détails de votre long post #92, vous dissipez beaucoup du brouillard qui me restait sur les formats des messages d'échange avec X-Plane. Je dirais même que c'est très généreux de votre part d'avoir pris le temps d'écrire tout cela. Merci !

Envoyé par FlyingBaldy Voir le message

Le code fonctionne, donc X-Plane accepte la commande et agit en fonction de celle-ci?

Oui, les lumières de roulage du train d'atterrissage avant « taxi_lights » s'allume et d’étains à la demande avec "sim/lights/taxi_lights_on" et "sim/lights/taxi_lights_off".

Ce qui, je le souhaite, vous donne espoir de résoudre le problème sur votre système et une piste de solution !

Voir ma signature pour les détails de mon système.

Pour isoler le problème, si vous pouviez exécuter le code en pièce jointe, cela pourrait peut-être aider. Il ne fait qu'allumer et éteindre le "taxi_lights" au deux secondes. Seules les adresses du réseau local sont à adapter.

Testé avec l'avion Baron 58 il y a deux minutes.

Et vous, quel avion utilisez-vous pour vos tests ?

Éventuellement, peut-être comparez nos listes des plug-ins... etc.

Fichiers attachés

taxi_lights_02.zip (2,8 Ko, 4 affichages)

**FlyingBaldy** · 28 juillet 2014, 08h07

Bonjour Lami,

Merci pour le code mais cela ne fonctionne toujours pas chez moi, c'est incompréhensible.
Je peux toutefois envoyer et recevoir grâce aux messages DATA, ce qui me permet de (quasiment?) tout réaliser.
J'utilise uniquement des avions standard de X-Plane.
Aucun plug-in installé.
J'utilise X-Plane 9 mais toutes les commandes et la majorité des Datarefs sont également applicables donc le problème réside ailleurs.

**Lami** · 28 juillet 2014, 12h49

Je suis désolé pour mon précédent massage, pour ceux qui l'auront vue, finalement, tout le message qui soulignait une erreur, en soi était une erreur.

Un point curieux attire mon attention. Malgré le fait que le code source fonction bien et permute l'allumage et l'extinction du train d'atterrissage avant avec la commande "sim/lights/taxi_lights_on" et "sim/lights/taxi_lights_off", je note dans le panneau de configuration réseau de X-Plane que le message de ces commandes semble ne pas être totalement réceptionné, si je me fie à cela « Vous avec une transmission de quelqu'un parlant à une machine maître, est IOS externe de l'adresse IP 192.168.2.14 1.7 secondes, envoi CMND. » :

Mais pour la dernière ligne, tout semble correcte « Envoi à data output à l'adresse IP 192.168.2.14 0.0 secondes, and the send was successful. ».

Est-ce que je me trompe ici, ou vous pensez la même chose que moi ?

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

**FlyingBaldy** · 28 juillet 2014, 15h43

Pour le premier, il s'agit d'un messages normal, du moins dans sa version anglaise originale:
"Got a transmission from someone talking to a master machine, is external IOS from address 192.168.1.254, x.x seconds ago, sending DATA" (ou CMD ou DREF ou ...), c'est-à-dire littéralement:
Reçu une transmission de quelqu'un parlant à une machine maître, qui est un IOS (Input Output System ?) depuis l'adresse 192.168.1.254, il y a x.x secondes, et envoyant des Données.", ou en bon français:
"J'ai reçu il y a x.x secondes, un message de Données (DATA) émis par un IOS externe, depuis l'adresse 192.168.1.254, et s'adressant à un ordinateur maître" (ici le PC sur lequel tourne X-Plane).

L'autre message est tout aussi normal (bien que mon X-Plane ne l'affiche pas, même lorsque je reçois des Données):
"Il y a x.x secondes, X-Plane a envoyé avec succès des données à l'adresse 192.168.2.14.

Quel est le problème?

**Lami** · 28 juillet 2014, 17h50

Bonjour FlyingBaldy,

Finalement, il n'y en a pas ! Je viens de retirer les pauses de 2 secondes dans le code et le résultat confirme exactement et strictement vos propos. Tout est parfaitement normal. Je me méprenais sur les délais de plus ou moins 2.0 secondes.

Comme 99% de mes commandes "CMND0" fonctionnent, mais que je bloque sur la commande « nav_com_adf_mode », je me demandais si vous aviez quelques "CMND0" qui fonctionnaient et quelles sont les autres commandes qui ne fonctionnent pas pour vous, il y en a peut-être d'autres que je pourrais tester ?

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

**FlyingBaldy** · 28 juillet 2014, 18h21

Bonjour Lami,

Si la commande « nav_com_adf_mode » bloque, c'est peut-être qu'elle n'existe pas.
Avec ce genre d'intitulé, je m'attends plutôt à devoir fournir une valeur qui indique quel est le mode.
Après vérification, il s'agit d'une Dataref (avec une valeur comprise entre 0 et 5 pour nav1,nav2,com1,com2,adf1,adf2) et non pas d'une Commande (qui n'accepte aucune valeur).

Aucune commande essayée ne passe chez moi.
Je me suis donc rabattu sur l'échange de DATA, qui me permet toutefois de nombreuses actions telles que:
* remplissage d'un réservoir à une certaine valeur.
* réglage d'une fréquence COM/NAV/ADF/... auchoix
* modification de l'heure du simulateur
* choix du cran de volet (Flap) à déployer
Et bien d'autres.

Il me reste un souci de temps de réaction qui me semble un peu long (plusieurs secondes) mais je retesterai lorsque je disposerai d'afficheurs LCD qui me permettront de supprimer la liaison série.

**thierryhl** · 28 juillet 2014, 18h48

Il me semble, (mais vous l'avez surement fait) qu'il faille supprimer ou commenter toutes les lignes Serial.print qui ralentissent énormément les transactions avec X-Plane.

**Lami** · 28 juillet 2014, 23h07

Envoyé par FlyingBaldy Voir le message

Bonjour Lami,

Si la commande « nav_com_adf_mode » bloque, c'est peut-être qu'elle n'existe pas...

Ah, là, je me fais prendre à écrire comme je comprenais l'UDP de X-Plane avant. Évidemment, il est question pour « nav_com_adf_mode » de DataRefs : Réf. :

sim/cockpit/radios/nav_com_adf_mode int y int for a multifunction receiver...0-5 for nav1,nav2,com1,com2,adf1,adf2.

Et je l'utilise avec "DREF0" :

En voici le code qui finalement fonctionne très depuis longtemps :

Code:

//*****************************************************************************
// FONCTION EnvoyerDonneesX_Plane
//*****************************************************************************
void EnvoyerDonneesX_Plane (char DonneesDeReference [], float NouvelleValeur)
{
  // Unions permettent le même emplacement de mémoire auquel on doit accéder en 
  // tant que types de données différents.
  // Dans ce cas-ci, comme des byte et lire comme float. Voir plus à :
  // http://b58.svglobe.com/data.html
  union
  {
    char ValeurFormat4Byte [4];
    float ValeurFormat1Float;
  } TemponComUDP;

  // Indique la taille de la chaine de caractère pour la DataRef.
  const int TailleDesDonnees = 500;
  const char TypeDeMessage [6] = "DREF0";
  // Recois le texte constituant le message pour les DataRefs.
  char TexteMessageX_Plane [TailleDesDonnees];

  int PositionDansLaChaine = 0;
  while (DonneesDeReference [PositionDansLaChaine])
  {
    // Tant que le caractère de fin de chaine n'est pas rencontré,
    // on transfère le caractère de la donnée de référence.
    TexteMessageX_Plane [PositionDansLaChaine] = DonneesDeReference [PositionDansLaChaine];
    PositionDansLaChaine = PositionDansLaChaine + 1;
  }
  
  for (int i = PositionDansLaChaine; i < (TailleDesDonnees - 1); i = i + 1)
  {
    // On rempli le reste de la chaine de caractère avec char (32).
    TexteMessageX_Plane [i] = char (32);
  }
  // Ajout du caractère « NULL » en fion de chaine.
  TexteMessageX_Plane [TailleDesDonnees] = char (0);
  TemponComUDP.ValeurFormat1Float = NouvelleValeur;
  
  CarteEthernetUDP.beginPacket (X_PLANE_ADRESSE_IP, X_PLANE_ADRESSE_UDP);
  CarteEthernetUDP.write (TypeDeMessage);
  for (int i = 0; i < 4; i = i + 1)
  {
    CarteEthernetUDP.write (TemponComUDP.ValeurFormat4Byte [i]);
  }
  CarteEthernetUDP.write (TexteMessageX_Plane);
  CarteEthernetUDP.endPacket ();
}
//*****************************************************************************

Mais j'oubliais l'index dans le texte de la commande. Alors, si la ligne :

Code:

  EnvoyerDonneesX_Plane ("sim/cockpit/radios/nav_com_adf_mode", float (RadiosActive));

est modifié en :

Code:

  EnvoyerDonneesX_Plane ("sim/cockpit/radios/nav_com_adf_mode[B][0][/B]", float (RadiosActive));

Tout fonctionne !

Toujours pour chercher a isoler le problème, si vous pouviez exécuter le code en pièce jointe, cela pourrait peut-être aider. Il ne fait que permuter la sélection de la radio active (de 5 à 0) avec « nav_com_adf_mode » au deux secondes. Seules les adresses du réseau local sont à adapter.

L'ami René
Tous pour un et un pour tous !
nav_com_adf_mode_01.zip

**Lami** · 28 juillet 2014, 23h35

Envoyé par FlyingBaldy Voir le message

...
Il me reste un souci de temps de réaction qui me semble un peu long (plusieurs secondes) mais je retesterai lorsque je disposerai d'afficheurs LCD qui me permettront de supprimer la liaison série.

Dans votre code, s'il y a aussi des « delay », c'est qu'il y a un problème pour un vrai code à exécuter avec X-Plane.

Pour des tests comme ce que je viens d'envoyer, ça n’a pas d'importance.

Connaissez-vous la programmation par gestion d'événement et/ou par occurrence de temps ?

Par exemple, dans le code en pièce jointe, la gestion de l'affichage et de la lecture des boutons sont faites par occurrence de temps.

Le bout de code qui fait ça est :

Code:

//*****************************************************************************
// FONCTION GererTempsAffichagesBoutons
//*****************************************************************************
void GererTempsAffichagesBoutons ()
{
  // Condition de contrôle de l'affichage par seconde pour éviter le 
  // syntillement de l'afficheur.
  TempsActuele = millis ();
  if (TempsActuele > (TempsAfficher_Precedent + TempsAfficher_Delai))
  {
    TempsAfficher_Precedent = TempsActuele;
    GererAffichages ();
    GererBoutons ();
  }
}
//*****************************************************************************

Alors, par exemple, au lieu d'afficher une valeur à toutes les boucles du « void loop () », c'est une fois toutes les 1/30 de seconde, comme le nombre d'images par seconde de nos téléviseurs.

Si vous souhaitez plus d'explication, simplement le dire.

L'ami René
Tous pour un et un pour tous !
NanoMiniTeleDeco.zip

**Lami** · 28 juillet 2014, 23h49

FlyingBaldy,

Est-ce que vous saviez que « Parfois, un dataref peut être accessible en écriture, mais seulement après avoir changé une autre configuration sim. Par exemple, vous ne pouvez "écrire" les datarefs de déviation de la surface de contrôle après avoir réglé le remplacement dataref surface de contrôle à 1. (Si vous ne définissez pas cette dérogation, X-Plane sera constamment écrire ses propres idées des positions de surface de contrôle pour les datarefs de surface de contrôle et vos modifications seront perdues.) » ?

À ce chapitre, il y a peut-être une bonne différence entre la version 9 et 10 de X-Plane !?!?!?

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

**Lami** · 29 juillet 2014, 00h16

Comme maintenant chez moi tout fonctionne (les CMND, DATA et DREF), je ne peux passer sous silence l'aide inestimable de trois mousquetaires que sont FlyingBaldy, PhM, thierryhl et DanielL !

Sans votre aide, j'aurais tout arrêté, mais grâce à vous, j'ai poursuivi et atteins mes objectifs.

Alors des GRAND MERCI aux mousquetaires, mes principaux aidant et merci aux autres que j'oublie...

MERCI, MERCI, MERCI !!!

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

Annonce

Cockpit maison avec Arduino (comment faire) ?

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire