Cockpit maison avec Arduino (comment faire) ?

[FlyingBaldy]

je n'ai pas regardé le code en détail mais je me demande si le problème ne vient pas d'un trop grand nombre de données transitant par les messages UDP.
Les messages sont limités à 500 caractères (hors entête de 5 caractères pour le type de message DAT, DREF, CMND...).
Pour chaque type de données, il y a 36 octets = 9 groupes de 4 octets:
* un groupe pour le type de données
* huit groupes pour les données

Dans le code MegaRadiosPA_14, on compte 13 groupes (sans les groupes 104 et 118 qui posent problème).
La longueur du message UDP (hors entête) de X-Plane est donc de 13*36=468 octets < 500 octets.

En ajoutant les groupes 104 (XPNDR) et 118 (PA), on arrive à 15 groupes de 36 octets = 540 > 500 octets.
Ceci dit, j'ignore comment X-Plane agit lorsqu'on lui demande d'envoyer plus de 13 groupes de données.
Envoie-t-il deux messages (un de 13 groupes et un de 2 groupes)?

Pour voir si mon idée est correcte, il suffit de désélectionner deux groupes quelconques dans X-Plane et de voir si Arduino affiche bien tous les autres sur les LCD.

Cela n'explique toutefois pas le lien avec le problème de télécommande.

[Lami]

Bonjour FlyingBaldy,

J'ai des problèmes avec mon ordinateur, ce qui me retarde pour tester cette hypothèse qui est des plus brillante comme idée !

Dès que j'ai un système opérationnel, je vous reviens (aujourd'hui, j'espère) !

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

[FlyingBaldy]

Autres idées en vrac:
Dans le post #106, je vois que le taux de messages UDP est réglé à 99.9 messages par seconde (coin inférieur droit de l'écran de configuration).
Si X-Plane envoie deux messages (un de 13 éléments puis un de 2 éléments), cela veut dire qu'il envoie environ 200 messages par seconde.
Ce taux me paraît élevé. Je pense qu'il vaudrait mieux un taux d'émission par X-Plane inférieur au taux de lecture dans le code Arduino de façon à ne rien rater.

Le traitement des rebonds est une excellente idée.
En principe on ne modifie qu'un bouton/encodeur à la fois, mais la gestion du rebond ajoute une poignée de millisecondes, ce qui ralentit la boucle (40ms de délai de rebond cela limite le taux à 25/s sans rien faire d'autre dans la boucle!).
Il doit être possible de déterminer dans le code une variable qui enregistre soit la longueur réelle d'une boucle, soit le nombre de boucles par seconde, et vérifier que cela reste dans certaines limites.

[Lami]

Bonjour FlyingBaldy,

je n'ai pas regardé le code en détail mais je me demande si le problème ne vient pas d'un trop grand nombre de données transitant par les messages UDP.
Les messages sont limités à 500 caractères (hors entête de 5 caractères pour le type de message DAT, DREF, CMND...).
...
En ajoutant les groupes 104 (XPNDR) et 118 (PA), on arrive à 15 groupes de 36 octets = 540 > 500 octets.
...

BRAVO, c'est probablement la bonne et plus qu'hypothèse maintenant !

J'ai donc affaire à une âme généreuse, doublé d'un esprit de génie pour la programmation informatique !!!

BRAVO, BRAVO, MERCI, MERCI !

...
Ceci dit, j'ignore comment X-Plane agit lorsqu'on lui demande d'envoyer plus de 13 groupes de données.
Envoie-t-il deux messages (un de 13 groupes et un de 2 groupes)?
...

Avec l'ensemble des symptômes lorsqu'il y a plus de 13 groupes, il semblerait que X-Plane ne vérifie rien et envoi tout en une fois.

...
Cela n'explique toutefois pas le lien avec le problème de télécommande.

En partie ! Cela expliquerait que l'Arduino déborde au niveau de ses objets mémoires et comme cette mémoire devient corrompue au fils des boucles de traitements, tout part en vrille, l'affichage, le traitement des signaux de télécommande, des boutons, etc.

Il faudrait demander confirmation pour le maximum de 13 groupes, mais c'est en anglais que ça se passe chez l'Éditeur Laminar Research et Austin Meyer !!!

Si le tout est confirmé, j'ai un sérieux problème, car je n'en suis qu'à peu près à 60 % des besoins pour mon cockpit générique.

Un grand MERCI pour tout FlyingBaldy !

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

[Lami]

Autres idées en vrac:
Dans le post #106, je vois que le taux de messages UDP est réglé à 99.9 messages par seconde (coin inférieur droit de l'écran de configuration).
...

Une autre très bonne hypothèse ! J'ai déjà remis les valeurs par défaut dans la journée, pour les paramètres réseau, 20 pour « transmissions multijoueurs... » et 40 pour « transmissions externes visuel/cockpit... » et je vais tester pour le taux de messages UDP.

Vous m'impressionnez par votre génie et compréhension de l'informatique, votre sens du détail, votre mémoire ...

Encore un grand merci pour votre aide !

Je reviens avec mes observations pour le taux de messages UDP.

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

[Lami]

Autres idées en vrac:
Dans le post #106, je vois que le taux de messages UDP est réglé à 99.9 messages par seconde (coin inférieur droit de l'écran de configuration).
...
En principe on ne modifie qu'un bouton/encodeur à la fois, mais la gestion du rebond ajoute une poignée de millisecondes, ce qui ralentit la boucle (40ms de délai de rebond cela limite le taux à 25/s sans rien faire d'autre dans la boucle!).
Il doit être possible de déterminer dans le code une variable qui enregistre soit la longueur réelle d'une boucle, soit le nombre de boucles par seconde, et vérifier que cela reste dans certaines limites.

Rebonjour FlyingBaldy,

Après plusieurs tests, il semble que la valeur du taux de messages UDP n'est pas en cause dans les bogues.

Le temps d'une boucle complète de « Loop » prend entre 60 et 75 millisecondes, que l'UDP soit réglé à 99.9 ou à 20.0. Je laisse l'UDP à la valeur par défaut de 20.0 / secondes. Le tout en utilisant télécommande et encodeurs.

En voici le code source principal :

//*****************************************************************************
// FONCTION loop = Boucle sans fin = coeur du programme.
//*****************************************************************************
void loop ()
// La fonction loop() s'exécute sans fin en boucle aussi longtemps que
// l'Arduino est sous tension.
{
  // Ici les instructions à exécuter par le programme principal.
  TempsDepart = millis ();

  CodeSituation = 99;
  GererTempsAffichagesBoutons ();
  RecevoirDonneesX_Plane ();
  GererAffichages ();
  GererBoutons ();
  GererBoutonTeleCommande ();
  GererEncodeurs ();

  LCD_2.setCursor (13, 3);
  LCD_2.print ("       ");
  LCD_2.setCursor (13, 3);
  TempsEcart = (millis () - TempsDepart);
  LCD_2.print (TempsEcart);
}
//*****************************************************************************

Et les nouvelles variables :

// Valeurs pour la gestion du temps dans les boucles de contrôle en milliseconde.
unsigned long TempsDepart             = 0;
unsigned long TempsEcart              = 0;

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

[FlyingBaldy]

... esprit de génie pour la programmation informatique !!!

C'est gentil mais largement exagéré. Mes connaissances sont moyennes en informatique.

Je pensais à un nouvel essai:
Nous nous limitons à 500 caractères dans le message UDP parce que c'est la valeur indiquée dans la page "mode d'emploi" de X-Plane ("Sending data to X-Plane" strDIM is 500).
Pourquoi ne pas essayer de donner une dimension plus importante à la variable "PaquetUDP_Donnees", par exemple 1000 (ou au moins x*36 avec x le nombre de groupes de données à envoyer par X-Plane)?

Une autre méthode consiste à définir la taille de "PaquetUDP_Donnees" de manière dynamique après avoir lu le message et la taille réelle du message par "parsePacket".

Si cela ne fonctionne pas, il faudra se résoudre à utiliser les toutes dernières créations de Vlad Sychev (B58) qui vient de créer un Plugin dynamique pour transmettre les valeurs désirées hors liaison UDP (donc sans limitation)?
Voir le nouveau site arduino.svglobe.com. Je veux bien traduire en partie mais après avoir testé l'augmentation de taille de PaquetUDP_Donnees.

Je croise les doigts.

[Lami]

Bonjour FlyingBaldy,

Encore un grand merci pour votre aide qui m'est d'une valeur inestimable, car j'étais vraiment bloqué par ce problème !

Je vais tester la taille des "PaquetUDP_Donnees" en réception de manière dynamique.

Je vais aussi regarder de près le plug-in de Vlad Sychev.

Je reviens avec mes observations de tout cela.

Si vous testez le plug-in, faites-nous-en part.

Je verrais bien un nouveau fils de discussion sur le sujet et un lien ici pour le souligner. Je le ferai une fois le produit essayé, s'il n'y a toujours pas de sujet à son sujet.

Encore un grand merci !

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

[Lami]

Rebonjour FlyingBaldy,

J'ai testé la taille des "PaquetUDP_Recu" en réception de manière dynamique.

Et j'ai la joie de confirmer que nos hypothèses étaient les bonnes « Les messages sont limités à 500 caractères (hors entête de 5 caractères pour le type de message DAT, DREF, CMND...). », « il semblerait que X-Plane ne vérifie rien et envoi tout en une fois. ».

Peut-être que la limite de 500 est en réception pour X-Plane et non pas en émission de la part de X-Plane, c'est ce que démontrent les faits ?

Je reçois des paquets de 617 octets avec toutes mes options activées et je traite le tout de manière dynamique pour ne plus avoir ce genre de problème.

Le temps d'une boucle complète de « Loop » prend maintenant avec un paquet UDP de 617 octets, entre 65 et 80 millisecondes à traiter, le tout en utilisant télécommande et encodeurs. Je laisse l'UDP à la valeur par défaut de 20.0 / secondes pour le moment.

J'ai aussi la joie d'annoncer que je n'ai plus de bogue !

Encore un grand merci !

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

[FlyingBaldy]

Bravo, bravo!

Je retiens de tout ce travail les points suivants :
* il est possible d'utiliser la liaison UDP avec succès.
* le code utilisé a le grand avantage sur les codes de Vlad Sychev de gérer le rebond. En revanche il ne permet peut-être pas de gérer des entrées analogiques très réactives telles que des axes de commandes de vol (yoke) car le temps de boucle est probablement trop long (selon Vlad Sychev, la durée de ses boucles est de l'ordre de 2 à 3 millisecondes). Il faut choisir entre rebonds et rapidité. Je préfère toutefois cette solution et laisser la gestion des axes par USB.

Encore toutes mes félicitations pour la qualité du code.

[Lami]

Bonjour FlyingBaldy,

Merci pour le « Bravo, bravo », mais sans votre aide, je n'y serais pas arrivé !

Alors, les bravos et félicitations sont pour tout le monde, le partage et la collaboration ont prouvé une fois de plus, leur efficacité !!!

Encore un grand merci !

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

[Lami]

Bonjour,

Il y a du nouveau très prometteur sur le site Web Arduino Cockpit Simulator - (http://svglobe.com/), une bibliothèque pour l'IDE Arduino :

X-Plane I / O bibliothèque pour Arduino --- (version actuelle - 1,0 / Sept. 01,2014)

À voir absolument !

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

[soran]

Bonjour,

Il y a du nouveau très prometteur sur le site Web Arduino Cockpit Simulator - (http://svglobe.com/), une bibliothèque pour l'IDE Arduino :

X-Plane I / O bibliothèque pour Arduino --- (version actuelle - 1,0 / Sept. 01,2014)

À voir absolument !

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

Je suis d'accord avec toi, A voir absolument !

Quel boulot! et surtout quelles perspectives pour les gens qui souhaitent réaliser un simu ou des fois de simples fonctions sur de vrais boutons sans trop de connaissances et trop de moyens .

Je suis ce projet régulièrement , et vraiment c'est très prometteur. A suivre.........

[Lami]

Bonjour Soran,

J'ai finalement résolu les problèmes que j'ai rencontrés avec la lecture de neuf (9) encodeurs pour une carte Arduino Mega (solution en déportant sur CI externe : Nano ou Tiny85 ou Tiny84 avec communication i2c la lecture des encodeurs # 5 à 9).

Et dès cette fin de semaine, je vais commencer a passer mon code source à la moulinette pour utiliser la nouvelle bibliothèque de « Arduino Cockpit Simulator ».

J'en déposerai ici une version, lorsque cela sera fait pour les 3 écrans LCD 4x20, les 9 encodeurs, les 12 interrupteurs et la douzaine de boutons du cockpit générique, le tout sur une carte Mega R3 et une carte Nano R3 en communication i2c.

[FlyingBaldy]

Bonjour Lami,

Quels sont les problèmes rencontrés avec les encodeurs (boucle de lecture trop longue, mauvais contacts...)?