Crash avec Horus X12 en FrTX V1.5.05

Bonsoir.
Aujourd'hui en fin d'après midi et après 3 vols sans histoire, j'ai crashé mon jet sur panne radio.
Pendant un tonneau lent, l'avion étant à moins de 200 m de moi, j'ai perdu les commandes et l'avion s'est enfoncé doucement jusqu'au sol. Je n'ai pas eu le temps de noter si la turbine est passée au ralenti avant l'impact ou pas, donc je ne sais pas si le fail safe s'est déclenché.
La liaison HF était doublée : module interne de l'Horus X12 + Rx X6R et module externe R9M + Rx R9. Le R9 fonctionnait sans télémétrie et puissance 200 mW. Les 2 Rx étaient reliés par S-Bus à une RB20.  Un test de porté réalisé ce matin turbine tournante avait montré en mode test de portée que la liaison était encore parfaite à 150 m (le X6R décrochant à 50 m).
Le modèle est totalement détruit. Des 2 Rx, on n'a retrouvé qu'un morceau de boitier du X6R.

Je soupçonne un bugg au niveau du Tx, donc de la version 1.5.05 du firmware FrTx, que j'avais flashé il y a 2 jours afin d'exploiter les paramétrages du Rx R9 :
- Quand j'ai regardé mon Tx juste après le crash, l'affichage de la photo de mon modèle avait été remplacée par l'image par défaut "Horus X12S"
- j'avais programmé une annonce vocale de la tension Tx sur un inter et quand j'ai voulu la vérifier, l'appel de la fonction ne marchait plus.
- dans les logs, il y a plusieurs bizarreries :
* le premier vol de cet après midi est enregistré avec le nom d'un autre modèle totalement différent. Pourtant ce vol là s'est bien passé.
* les positions des manches J1, J2, J3, J4 durant le vol du crash sont totalement incohérentes, J1 et J2 étant même toujours à 0.

Une fois éteint et rallumé, le programme semble fonctionner normalement, l'image du modèle est à nouveau affichée. La tension est de 7,2v et je l'ai laissé fonctionner 15' sans problème.

Michel.

Ben je suis bien malheureux pour toi car perdre ce type de modèle est vraiment douloureux. Je ne veux pas en rajouter mais je salue ton courage pour avoir réagit aussi vite au travers de ce post qui donne l'alarme sur cette version. Reste à savoir, si c'est possible, ce qui c'est réellement  passé et si la version est effectivement en cause.

Ça m'attriste d'avoir de si mauvaises nouvelles. Visiblement, tu as beaucoup de données sur cet incident, j'espère que ça permettra de débusquer ce qui s'est passé.

C'est une nouvelle désolante car en plus il n'y avait aucun signe avant coureur et toutes les vérifications semblent avoir été réalisées. J'espère que tu trouveras le fin mot de cette mésaventure.

Il est difficile d'incriminer telle ou telle partie de la chaîne de commande, à commencer par moi. C'est pourquoi je dis "Je soupçonne".
Pour ce qui est du pilote, je suis sûr de moi à 99,99 %. J'ai déjà fait des centaines, (peut-être des milliers) de tonneaux lents après 25 ans de compète F3A et 35 ans de pilotage. Et j'ai largement eu le temps d'essayer de corriger la trajectoire, et même couper les gaz sans que le modèle ne réagisse.
Ensuite, il y a cette MàJ du FW que j'ai faite 2 jours avant. Ça peut bien sûr être une coïncidence, d'autant plus que j'avais eu un blocage momentanée la semaine dernière avec l'ancienne version et qui a motivé le doublage de la liaison HF par l'adjonction d'un module R9M + Rx R9 en 868 Mhz, et donc la MàJ du FW pour l'exploiter. Mais les symptômes ne sont pas les mêmes. Il me semble bien que la turbine est restée à fond jusqu'à l'impact. Donc cette fois-ci, il n'y a pas eu de passage en failsafe (que j'avais réglé sur mise au ralenti). C'est comme si les récepteurs recevaient toujours des signaux valides, mais que ceux-ci étaient bloqués.
Et puis le defaut d'affichage, la fonction readbatterie HS et les logs des vols d'hier qui ont vraiment de grosses anomalies alors que ce n'est pas le cas de tous ceux des vols d'avant la màj, c'est ce qu'on appelle un "faisceau d'indices".

Le modèle est totalement détruit.

"Très Beaucoup" semble-t-il mon Garenne...  

Coyotte

ps: Le clin d'oeil  porte sur ma réponse et non l'état du zinc qui m'afflige tout autant que vous tous...

Ceci dit,
Le faisceau de présomptions de Michel me semble cohérent.
L'une des questions qui se posent après une telle tragédie est de savoir si c'est le hardware qui a dysfonctionné ou si c'est FrTx qui est en cause.
Je suis conscient que la réponse sera difficile déterminer... (Si tant est que ce soit même possible)

Coyotte

Triste nouvelle, désolé pour toi.

Si tu as des logs bizarres, tu peux surement essayer de reproduire cela avec un autre modèle en simulant des sessions de vols ??

Bonjour Eric.
Je viens de faire une simulation avec le programme du modèle crashé et avec un autre. Dans les 2 cas, les logs n'ont pas les anomalies des logs d'hier, en particulier la position de J2 (les gaz) qui dans le vol du crash était toujours à 0.
Il y a vraiment eu une m... pendant le vol d'hier, et à priori non reproductible systématiquement.

Bonjour Michel79,

Triste d'apprendre cette mauvaise nouvelle :-( Heureusement que la casse est limitée au modèle...

Pour avoir partagé également ce genre d'expérience malheureuse, il est primordial de comprendre ce qui s'est passé. On trouve toujours et dès fois le temps de recherche est assez long. De toute manière on ne peut pas revoler en n'ayant pas compris et corrigé les causes d'un crash.

J'ai une Taranis X9d+ et OpenTx 2.2.1 et là s'arrête les différences avec ton matériel. J'utilise également des RB (pas le RB20) et couples de X8R et R9 depuis quelques mois. Tout fonctionne correctement et le seul problème que j'ai rencontré a été la perte d'un circuit de réception suite au débranchement d'un connecteur JR au niveau d'un RB (maintenant je sécurise le tout avec des points de colle chaude). Je vais prochainement mettre en service un jet avec RB20 et R9 & RX8R-Pro et je suis très à l'écoute de tous les problèmes publiés.

Il semblerait que tu aies eu un problème intermittent (c'est les plus difficiles à trouver) au niveau de ton émetteur soit matériel ou logiciel. Il est possible que ton modèle se soit mis en "failsafe" selon ta programmation. Je suppose que la configuration a été spécifiées et testées pour les deux récepteurs.

Comme voie de recherche annexe, je remonterai ton accident chez FrSky (on ne sait jamais). En attendant de savoir ce qui s'est passé, je ne volerais plus avec ta Horus (il est fort possible que le problème se situe à ce niveau).

Bon courage dans tes recherches et au plaisir de te relire.

Philippe

Bonjour Philippe.
Oui, les failsafe avaient été programmés et testés sur les 2 Rx. Mais je n'ai pas l'impression que le failsafe se soit déclenché car la turbine est restée à fond jusqu'au bout alors que le failsafe était programmé sur ralenti. C'est comme si l'emetteur continuait à envoyer des ordres, mais ceux ceux-ci étaient figés.
J'ai informé FrSky de l'incident par le formulaire de contact et ouvert un incident sur https://github.com. Je suis déjà en échange avec un développeur.
Moi, j'ai eu plusieurs pbs depuis 1 an que j'utilise la Horus :
- lors du deverminage sur un multi kevlar/ carbone avec un X8R, antennes à l'intérieur mais hors de la partie carbone, passage en failsafe momentanée lors d'un tonneau 4 facettes, à 150 m de moi. Je suis passé en double Rx : X6R+X4R à l'exterieur du fuso +RB16. Plus de pb. Test de portée réel à la limite visuelle (au moins 700 m) : RAS
- 3 mois plus tard sur un Warbird electrique tout bois avec X8R : passage en failsafe momentané à 100 m de moi, lors d'un large virage. Les logs ont montré un trou de 1 s et un début de chute de tension Rx juste avant. J'ai augmenté de 1 V la tension de mon alim principale et changé l'AQ de mon alim de secours. Pas d'autre pb depuis.
- la semaine dernière, sur le jet, en double Rx X4R + X6R + RB16, passage momentané en failsafe à 150 m de moi (la turbine s'est arrêtée car j'avais programmé le failsafe gaz sur arrêt).

Michel.

Bonjour,

Juste pour information, les incidents cités sont récents ou non ?
car on peut se demander s'il y a un rapport entre la version actuelle de FrTx (1.5.05) et ton constat.  
Le version précédente présentait-elle aussi ce genre d'anomalies?

Celui de la semaine dernière date... d'une semaine . J'étais en V1.5.04.
Les autres sont anciens et j'étais en V1.4.xx

A force d’étudier les logs, j'ai au moins éclairci le mystère des "bizarreries" des données enregistrées : position des manches toujours à 0, nom du modèle et date ne correspondant pas sur une partie des lignes, ...
En fait le fichier est nommé "05-27.csv". Comme je n'ai jamais effacé les logs de la carte SD, ce fichier contient les données du 27 Mai 2018, donc Dimanche dernier, mais aussi celles du 27 Mai 2017. Et ce jour là, j'avais volé avec un petit P51 (c'était même les tout premiers vols d'essai avec la Horus). Comme ce modèle n'avait pas le même nombre de capteurs que le jet, il n'y a pas le même nb de colonnes et donc un décalage des données.
Ceci compris, il s'avère que les positions des manches et les sorties PPM des vols du jet sont tout à fait cohérentes. Dans les 2 dernières lignes on voit que les gaz passent de plein ralenti à un debut d’accélération, et le manche d'aileron du neutre à une action en roulis. Ça correspond bien la remise de gaz après la figure d'extremité, et le début du tonneau au cours duquel j'ai perdu le contrôle. On voit qu'à ce moment là le RSSI était à 54 db, la tension Rb1 à 7,1v et la tension Rb2 à 6,4 v, conformes à mes paramétrages.

Je sais bien que moins on met d'électronique dans la chaîne et plus on réduit le risque de panne mais tu n'as pas pensé à mettre un régulateur de tension avant le RB 20 ?

L'entrée 1 était alimentée par un AQ lipo 2S via le BEC Pro Castel Création 20A réglé à 7,1 v et l'entrée 2 directement par un AQ NiMh 5S justement pour que secours soit sans électronique. Sur les logs, on voit qu'à la dernière ligne, le 1 fournissait  0,58A et le secours un courant constant de 0,03A, donc il y avait une "microfuite" du secours,  dû je suppose à la résistance de la diode qui ne peut pas être infinie.

Et je reste persuadé que le pb ne vient ni de la reception ni de la liasion HF, mais directement de l'emetteur du fait des anomalies d'affichage et de la fonction ReadBattery qui ne fonctionnait plus (il y en avait peut-etre d'autres). Je regrette de ne pas avoir eu l'idée de faire un check plus complet et en particulier regarder le monitoring.

je pensais que les 2 alim devaient être parfaitement identiques en tension et en capacité, que l'une n'était pas en secours de l'autre mais qu'elles travaillaient en alternance en fonction de la tension résiduelle

Si tu mets 2 alim identiques, oui, elle travaillent en alternance et se dechargent de manière synchrone en dehors de tout problème. Mais je préfère depuis longtemps mettre un "gros" AQ  en principal et un "petit" AQ en secours avec une tension inférieure. Ainsi, en l'absence de pb, le secours ne se décharge pas et il suffit de recharger le principal à chaque séance. Tous mes modèles sont alimentés ainsi depuis plusieurs années.

Michel79 a écrit:Et je reste persuadé que le pb ne vient ni de la réception ni de la liasion HF, mais directement de l’émetteur du fait des anomalies d'affichage et de la fonction ReadBattery qui ne fonctionnait plus (il y en avait peut-etre d'autres).

De ce que tu nous décrit, avec des changement de nom de modèle, voir peut-être de programme, c'est aussi le sentiment que j'ai ; un bug directement au niveau du CPU ou de sa RAM ou autre élément critique, qui fait que la radio fait un peu de la bouillie de données.
Un autre élément qui m'incite à penser ça, c'est que si le Failsafe n'a pas déclenché, c'est bel et bien que la partie transmission de données était toujours vivante.

Michel79 a écrit:
Je regrette de ne pas avoir eu l'idée de faire un check plus complet et en particulier regarder le monitoring.

Ne te blâme pas pour ça, il n'y a que les "ykafaukon-fallait faire autrement" du lendemain qui peuvent le savoir !
De ce que tu nous décris, tu as tout mis en oeuvre pour avoir une machine fiable, même la Nasa avec des vérification bien plus poussées a rencontré des accidents.

Hello Michel79,

- Installé dans ton jet le jour du crash était un RB20 ou un RB16 ?
- Pourrais-tu brièvement m'en dire un peu plus sur la fonction ReadBattery ?
- Comment est réglé la non propagation des perturbations électrique de la pompe à kéro sur la partie contrôle (alimention séparée ou ...) ?

Par sécurité sur mon jet, j'ai deux circuits électrique : un pour le contrôle (doublé) et un autre pour la pompe (simple). J'ai pris cette (bonne pour moi) habitude car j'ai fait mes expériences dans le monde de la propulsion à essence (allumage électronique).

D'avance je te remercie pour ton retour

Cdt

Philippe

Bonjour Phillipe.
Le jour du crash c'est la RB20 qui etait dans l'avion.
La fonction ReadBatterie est simplement une fonction spéciale et que j'avais assignée à un inter. Quand je basculais l'inter, j'avais l'annonce vocale de la tension d'alim du Tx (car l'affichage sur écran n'était pas facilement accessible). Donc après le crash, cette fonction ne fonctionnait plus, comme si elle etait bloquée ou déprogrammée. Et de là à penser qu'il y avait d'autres fonctions plus primordiales dans le même cas, il n'y a qu'un pas... que je franchi.
Selon les derniers échanges, les développeurs qui étudient mon pb pensent qu'il peut y avoir eu un reboot pendant le vol. Ils vont essayer de le reproduire (mais à mon avis, c'est pas gagné !)
Pour ce qui est de l'isolement electrique pompe/radio, c'est simple, il n'y en a pas. En fonctionnement normal, l' AQ principal alimente à la fois la turbine (et donc la pompe, puisque sur la VT80 tout est intégré) et la radio via un BEC 20A réglé à 7,2v.
Ça peut paraître osé, mais j'ai une expérience très différente de la tienne : a part ce jet, tous mes modèles sont électriques (cf ma signature) et sur ces modèles, l'AQ de propulsion alimente à la fois le moteur brushless et la radio via un bec. On est donc exactement dans la même configuration, à ceci près qu'un moteur brushless de plus de 3000 W devrait bien plus perturber la radio que le petit moteur de la pompe (lui aussi brushless). Or depuis 3 ans que j'utilise ce système sur mes 3 plus puissants modèles, aucun pb constaté. Et d'ailleurs cette solution a fait école dans notre club si bien que ce sont au moins 7 ou 8 modèles de 6S à 12S qui volent ainsi sans aucun souci. Bien entendu, il y a quand même un circuit de secours en cas de défaillance de l'alim principale, mais en l'absence de défaut sur le principal, il ne sert pas.

Hello Michel79,

Merci pour ton retour d'informations. J'ai compris que tu sembles convaincu que c'est le Tx qui pose problème (et tu as peut-être raison) mais j'ai pour habitude de prendre une vision plus globale. Le crash (excepté les dysfonctionnement remarqués dur le Tx) pourraient également provenir du module RB20. Je ne le mettrai pas trop tôt hors de l'équation.

En ce qui concerne les circuits électrique, je parlais plutôt d'un circuit séparé pour ne pas polluer la réception avec des piques de tension pouvant provenir du module d'allumage (haute tension). Dans le cas d'un ESC, en principe les piques sont de moindres intensités et atténués fortement par l'ESC. Un moteur "classique" génère des perturbations "naturelles". A ma connaissance, tous les moteurs de pompe à kéro sont de type "classique". C'est pour cette raison que je ne préfère pas prendre de risque (bien qu'il existe des pompes certifiées sans parasites") et je sépare les alimentations.

Courage dans tes investigations et à la prochaine.

Cdt.

Philippe