Mouvements non sollicité des servos

Bonjour, après plusieurs années de tranquillité avec ma X12S et également un très grand nombre de vols, me revoilà replongé dans une phase plus sombre...

Depuis quelques jours, des mouvements non sollicités se produisent au sol et en vol sur certains modèles. Les modèles concernés sont tous équipés se RB ainsi que deux récepteurs (2,4 gHz & 868 mHz) avec une solution de retour télémétrique basée OpenXsensor / Arduino. Je n'en suis pas encore certain, mais le problème pourrait bien provenir de l'installation du retour télémétrique (ce qui est nouveau pour moi cette année). Beaucoup de valeurs sont retournées comme températures, RPM, AccX/Y/Z, Heading, GPS, Alt, Vario, ...) Je vais prochainement retenter un vol en désactivant le retour télémétrique pour voir si le problème vient de là.

Question :

 - est-ce que quelqu'un aurait constaté ce problème après avoir implémenté une solution de retour télémétrique basée OpenXsensor ?
 - je suis entrain de penser que cela pourrait être un problème de charge au niveau du débit des données à retourner (récepteur ou émetteur)

Je prends volontiers toute idée qui pourrait être en lien avec ce problème.

Merci de votre retour

P.S. Je n'observe aucun problème sur les aéronefs à simple circuit de transmission et qui n'ont pas la solution de retour télémétrique OpenXSensor embarquée.

J'ai un problème similaire de mouvements erratiques qui se produisaient de façon arbitraire.
Au final, le problème venait d'un câble sectionné sur l'un des manches.

Merci de ta réponse mais, dans mon cas, le problème ne provient pas de là. Tous mes aéronefs, exceptés ceux avec RB & openXSensor/Arduino, ne présentent pas de problème.

C'est effectivement ce que tu as écris. Je me disais que cela ne coûtait rien de quand même vérifier.
Dans tous les cas, je suis sec. J'ai pas d'idée. Désolé.
Tiens nous au courant si ta piste "trop de données télémétries" est concluante.

Bonjour,

Ça le fait à chaque fois ou pas toujours ?

Sur un modèle simple, le mouvement erratique (tac) des servos ou d'un servo est souvent provoqué par un bec trop faible.

Dans ton cas il y a une box donc je suppose que tu alimentes directement ta box avec deux accus 2S et là on a 5A par sortie donc cette piste est à éliminer.

si tu as plusieurs capteurs de télémétrie, essaies de tous les débrancher pour vérifier et si ça fonctionne bien rebranche les 1 par 1 pour trouver le coupable. Combien consomme en ampères ton openXsensor ?

Ca le fait très régulièrement (presque tous les vols) et la réaction en vol est différente en fonction des modèles. Les amplitudes sont faible à modérées (mais visibles surtout sur les aéronefs pointus) et de courtes durées (1/2 seconde env.).

Les RBs sont effectivement alimentés en LiFe donc pas de soucis d'alimentation.

Jusqu'en 2021, je volais exclusivement avec des capteurs FrSky et je n'avais pas de problème. Maintenant j'ai un mixe FrSky et OpenXsensor-Arduino. J'ai prévu une séance de vol pour revenir à la situation d'avant (100% FrSky) pour être certain que le problème provient bien de là. Tous mes capteurs sont connectés sur l'Arduino, donc je dois découpler tous les capteurs à la fois.

Si cela provient bien des capteurs "maison", alors je vais devoir m'attaquer à la cause (ça ne va pas être de la tarte). J'espère pouvoir bénéficier de l'expérience d'autrui pour m'aider à comprendre et implémenter la solution (j'y tiens à mes capteurs !)

Je retournerai régulièrement l'état de mes investigations.

Belle journée et merci à tous

Hello,

Si tu arrives à la conclusion que c'est un capteur OpenXsensor qui pose problème, il faudra les tester un par un (en espérant que c'est un capteur particulier qui pose problème et pas le mise en commun de plusieurs.

Est-ce que tu as récemment ajouté un capteur particulier ?
Comme je comprends les choses tu sembles avoir un grand nombre de capteurs.
Tu pourrais essayer de voler avec un, puis deux, puis trois,... capteurs jusqu'à ce que le problème se repose.
(D'un autre côté, s'il se repose, tu es tranquille...   )

Coyotte

J'ai rajouté tous les capteurs en une seule fois. Ils sont branché sur l'Arduino qui est connecté sur le SP.

Dans un premier temps, je vais tous les supprimer pour être certain que le problème vient bien de là. Je ne vais pas "m'amuser" à les remettre les uns après les autres car je ne veux pas prendre de risques inutiles. Soit je comprends exactement d'où vient le problème et je le corrige (ou j'abandonne la solution) ou soit je monte un avion de test et l'utilise comme cobaye. J'avais dans l'idée de mettre un capteur à la fois et ainsi déterminer celui ou ceux qui pose (ent) problème (s)

Je reste encore dans le doute de savoir ou le bas blesse : coté récepteur, RB ou l'émetteur. J'ai pu tracer ce qui me semble être un indice qui pourrait tendre à pointer l'émetteur (log des consignes de contrôle des commandes).

Cause météo, je n'ai pas pu faire avancer mes tests en pratique. Par contre, j'ai un peu avancé dans une supposition théorique basée sur les valeurs des logs et le déroulement des vols.

 - je rencontre le problème que si les conditions RB + Arduino sont présentes et que l'Arduino fonctionne correctement (pas hang)
 - le problème se présente déjà lorsque je branche deux capteurs de température et un RPM
 - les logs démontrent des anomalies de tension RB1 ou/et RB2 (la tension chute assez fortement) lors des vols ou le problème a été constaté
- lors d'un vol, l'Arduino a du se bloquer (valeurs restées constantes durant le vol) et le problème n'est pas apparu

C'est comme si le RB n'apprécie pas le fait qu'il y a un Arduino dans la boucle SP. Je vais tester demain si cela peut être simulé par une charge relativement élevée de la boucle SP.

Question aux amis de la solution Arduino : est-ce que quelqu'un a essayé de le connecter sur la boucle SP d'un RB ?

Verdict : le problème ne provient pas de la consommation électrique liée à l'Arduino.

Pour arriver à cette conclusion, j'ai mesuré la charge à la sortie du SP du RX8R Pro. Le récepteur est connecté avec un R9 via un RB10. l'Arduino consomme env. 20 mA et la chaîne complète (+ 4 x FLVSS) env. 50 mA. Pour savoir ce qu'il se passait si la consommation augmentait, j'y ai rajouté env. 100 mA et rien ne c'est passé. Au niveau de la variation de la tension du SP, on passe de 5.74 V à env. 5.70 V

J'attends des jours meilleurs (météo) pour effectuer une série de vols sans Arduino pour être plus ou moins certain que le problème vient bien de là.

Belle journée à tous

J'ai profité de cette belle journée pour effectuer quelques vols avec un de mes aéronefs qui a rencontré le problème.

 - vols 1 à 3 sans l'arduino -> ras
 - vol 4 avec l'arduino mais sans sondes -> ras
 - vol 6 avec l'arduino et deux sondes de température -> ras
 - vol 7 avec l'arduino, deux sondes température et RPM -> ras

Tout fonctionne sans aucun problème !

Aucune logique n'explique la source potentielle du problème et je ne peux plus le reproduire sur au moins un aéronef. Je vais tenter avec un autre qui a rencontré le problème selon une séquence similaire. Entre temps, j'ai fait une multitude de vols (avions/hélicos) sur des appareils a un canal de communication (1 x 2.4 gHz) et tout c'est très bien passé.

Un point que j'aimerais soulever : j'ai placé l'optocoupleur pour la mesure RMP à proximité de l'arduino. est-ce juste ou faudrait-il plutôt l'installer à proximité du CDI ?

Tous mes avions avec capteurs multiple basé Arduino et deux chemins de communication fonctionnent à nouveau sans aucune perturbation des commandes de vol. Mystère ! C'est un vrai plaisir de savoir un peu ce qui se passe dans mes avions. Tous les capteurs retournent des valeurs "crédibles" et c'était intéressant de les connaître pour moi.

Merci pour ce fil d'investigation que j'ai suivi avec attention.

Bon, je viens de mettre le dernier avion (Yak54 2,7 m 116ccm) qui est pourvu d'une solution "à problème" (problème maintenant totalement disparu sur les avions qui présentaient le problème au début de l'année... ???) et c'était le folklore dans les airs. J'ai malgré tout réussi à le poser correctement et je constate que, même au sol, toutes les commandes bougent à plus ou moins faible amplitude régulièrement lorsque les deux circuits (2.4 gHz & 868 mHz) sont actifs. Je constate que si seul un des deux circuits est actif, alors les mouvements parasites disparaissent.

Vraiment très étrange et n'inspire pas confiance du tout. Mettre au tas un avion de cet taille serait très dommageable et je pense dans l'immédiat de le voler que sur un des deux circuits (2.4 gHz)

Absolument aucune logique ne me permet de savoir ce qui se passe. Je suspecte le RB mais je ne peux pas le prouver. Les avions qui ont (ou ont eu le problème) sont équipés de RB10, RB & RB20 C'est depuis que j'ai pourvu les avions de capteurs basé Arduino que je rencontre le problème. Même déconnectés (chaîne SPort coupée), le problème perdure. OpenTx voit toujours les références des capteurs mais pour lui, ils sont débranchés. Et pourquoi sur deux de mes avions le problème s'est résolu de lui-même ???

C'est à rien n'y comprendre ...

Belle saison à tous et j'aspire à retrouver une certaine sérénité en vol

J'ai volé hier et aucun problème n'est à signaler si je vole sur un circuit unique (2.4 gHz).

Jai remarqué (en analysant les signaux SBus du récepteur en 868 mHz) qu'il sortait de la "salade" lorsque les deux modules HF de l'émetteur sont actif ! Je ne sais pas si c'est la cause de mon problème mais c'est parfaitement anormal. Je me souviens qu'une version d'OpenTx avait des soucis quand les deux modules étaient actifs.

Est-ce que quelqu'un se souvient du problème d'OpenTx ? et est-ce que quelqu'un constate également le phénomène quand les deux circuits sont actifs ?

Oui, j'ai eu ça aussi. Il me semble qu'on en avait parlé ensemble d'ailleurs.
Solution rb20 avec RX8R et R9M mini fonctionnait très bien avant changement de version opentx (2.3.10 ou 11 ?) Salade dans les servos et du coup j'avais tout changé pour un résultat identique... c'est en remettant la version précédente que tout est rentré dans l'ordre.
Il y a donc bien une version opentx qui foire si le module interne est activé en même temps que le module externe en mode R9M.

Mon cas est un peu différent. J'ai placé un traceur de trames SBus sur le récepteur qui est en 868 mHz et constaté que toutes les voies font les folles ! Si je disable le 2.4 gHz ou que je le met en "faible portée", tout redevient calme ??? J'ai également reproduit le même problème avec un autre module externe ainsi qu'un autre récepteur. C'est comme si le module ISRM perturbait le module externe (R9M)

Comme à l'habitude, qui se donne la peine de chercher fini par trouver !

En ce qui concerne les voies folles sur la sortie SBus du récepteur en 868 mHz, j'ai trouvé qu'il y avait une fuite au niveau de l'antenne sur le module R9M. Cette fuite engendrait un bruit fort désagréable au niveau du HP et permettait également aux ondes électromagnétique émises par le module ISRM de venir perturber la transmission en 868 mHz. Lorsque je réduisais la puissance de sortie du ISRM, les ondes électromagnétique ne perturbaient pas suffisamment celles émises par le R9M. J'avais certes prouvé que le module R9M n'était pas défectueux mais je n'avais pas pensé à changer son antenne ...

Maintenant je vais continuer à investiguer si cela à avoir avec le problème que j'essaie de résoudre. Il pourrait bien exister une relation avec la salade envoyée par le canal en 868 mHz qui a peut-être un peu perturbé le comportement de mes RBs ?

Affaire à suivre mais je pense que suis sur la bonne piste.

La lumière est à nouveau au rendez-vous  Fuite il y avait bien mais c'était le module qui la produisait finalement. J'ai remplacé le module R9M par un R9M 2019 (en prévision du passage en ACCESS) De plus, pratiquement plus aucun ronflement (à 25 mW) au niveau du haut-parleur. Je pense enfin pouvoir voler sereinement cet été

Bons vols à tous

Entre-temps, j'ai un peu étudié comment a évolué Ethos. Même s'il se rapproche des fonctionnalités de OpenTx, le fait qu'il ne supporte pas le protocole ACCST en 868 mHz au niveau de son module interne me pose problème.

Bravo pour cette recherche !
Les joies de l'électronique et informatique combinées...

Merci mon lapin préféré

Effectivement pour résoudre certains types de problèmes, il faut avoir plusieurs cordes à son arc...

Belle journée à toi qui m'a permis de progresser rapidement dans le monde idéal d'OpenTx (Ethos a encore un bon bout de chemin à faire avant qu'un jour j'envisage ma conversion (snif))

Cordialement

Bien d'accord. Disons que c'est un hobbit dans notre hobbit !

Merci beaucoup pour les compliments !
En ce qui me concerne j'aime trop OpenTX pour utiliser un autre OS. Mais bon, il n'y a que les imbéciles qui ne changent pas d'avis !