Charlie Echo

[Je me réponds mais c'est pour aider la postérité...] Erreur principale : j'ai activé le mode Angle dès le décollage (le bouton était activé avec le pré-arm). Comme je veux un drone stable, je trouvais ça plutôt bien. Mais manifestement, lors du décollage, le mode Angle m'empêche de réduire les gaz. Donc le mode Angle sera optionnel. Ca fait que je contrôle mieux les moteurs au décollage. Ensuite, (avec des tests sans hélices, en écoutant les moteurs), j'ai l'impression que le drone "retient" la vitesse des moteurs lors du décollage, donc ça devient des vitesses minimales, et il semble impossible de redescendre en-dessous, sauf en mettant les gaz à 0, ce qui ralentit les moteurs au minimum (5%) d'un coup. Je crains de devoir tester dehors, maintenant, pour en avoir le cœur net...

Aha, ton décollage rapide pourrait ressembler au mien, sauf que le mien ne s'arrête pas tout seul (probablement un problème de seuil). Si les hélices sont à l'envers, je pense que ça pousse le drone vers le sol. Donc je pense que le tien n'a pas ce problème. Le tien semble également tourner sur lui-même, ce qui peut signifier un mauvais équilibrage des moteurs ; un moteur frotte ? Tu devrais enlever les hélices et essayer de monter les gaz doucement, pour voir ce qu'il se passe. D'ailleurs, tu l'as configuré avec BetaFlight ou iNav ou autre chose ?

Après 2 semaines d'attentes de mes livraisons, je ré-ouvre ce vieux sujet, avec des Screenshots de la config de mon nouveau drone. Quelle est mon erreur ??? Merci pour vos éclairages ! En complément d'info : -dans la configuration, j'ai feature -FW_LAUNCH (donc Autolaunch = off ???) - quand je recommence un test sans hélices, j'ai ceci : quand j'arme, les moteurs se mettent à 5% (par réglage) quand je bouge un peu les gaz, les moteurs se mettent à une vitesse plus rapide (style 1500 sur l'échelle qui va de 1000 à 2000), quelle que soit ma commande. Quand je bouge la puissance doucement, la vitesse des moteurs reste à 1500. quand je dépasse la commande de 1500, les moteurs accélèrent et quand je réduis, ils redescendent, mais leur "minimum" semble être 1500. Impossible de mes mettre plus bas... En vidéo, ça donne ça :

Yep, j'ai choisi INav parce que ça semblait populaire et très similaire à Betaflight, et qu'on peut apparemment définir des missions. Pour Ardupilot, je n'ai pas vraiment creusé, mais en effet, ça peut couvrir mes besoins... Ca n'est pas vraiment pour de la livraison. J'ai besoin que le drone conserve une direction constante (qu'il bouge "en crabe") et ça semblait faisable sous INav. Bref, je vais creuser...

Je pourrai faire des screenshots... quand j'aurai reconstruit un drone... Parce que mon premier bébé est resté coincé dans son arbre 😭 (mes bêtises me coûtent 100 balles, heureusement qu'il était minimaliste, sans GPS etc...)

Bonne idée ; mais ça n'est pas strictement ça. On peut régler la vitesse "à l'armement", et j'ai mis 5%. Ensuite, quand je monte la vitesse doucement, ça va un peu plus vite, et encore plus vite... Mais le drone tolère de tourner à 6%, 7%, ... Je me dis que, peut-être, quand il décolle, la manette est tellement faible (style 1100 -entre 1000 et 2000-) que je ne peux pas redescendre. Si on enlève les paramètre non-pertinents, ceux qui parlent de motor ou de launch sont les suivants : Ceux-ci, par défaut, je suppose que c'est standard : set motor_pwm_rate = 16000 (mais c'est 480 dans Betaflight...) set motor_pwm_protocol = DSHOT300 set motor_poles = 14 Ceux-ci pourraient expliquer un comportement ; par exemple, 3 secondes pour décoller et ensuite se poser des questions ? (mais ça signifie que, si on a un toit, on va forcément le cogner...) : set nav_overrides_motor_stop = ALL_NAV set nav_fw_soaring_motor_stop = OFF set nav_fw_launch_motor_delay = 500 set nav_fw_launch_spinup_time = 100 set nav_fw_launch_end_time = 3000 set nav_fw_launch_velocity = 300 set nav_fw_launch_motor_delay = 500 set nav_fw_launch_accel = 1863 set nav_fw_launch_max_angle = 45 set nav_fw_launch_detect_time = 40 set nav_fw_launch_idle_motor_delay = 0 (Ce sont des paramètres par défaut, donc je n'ai pas touché...)

Bonjour, J'ai un problème avec un drone qui semble monter sans s'arrêter, de façon hyper rapide et incontrôlable. Ma question : où est mon erreur ??? J'ai bidouillé un Quad pour transporter une charge utile de 2 kg, avec : des moteurs d'un Hexo+ que j'avais en stock (j'ai très peu de caractéristiques sur ces moteurs) https://hexoplus.com/fr/ un cadre... un stack SpeedyBee F405 V4 tout neuf un récepteur FrSky Archer Plus RS tout neuf J'ai mis INAV, parce que ça me semble plus adapté que Betaflight (je veux réaliser du pilotage par GPS). En premier test, j'ai mis 4 kg sous mon drone, et j'ai lancé la machine pour voir si elle les soulevait. J'arme, les moteurs tournent doucement ; je monte un tout petit peu les gaz, et les moteurs accélèrent peu à peu, tout seuls, et finalement, le drone bouge. Dès que le drone bouge, le FC accélère tout seul vivement les moteurs, comme si il se disait "c'est bon, je mets la gomme". Le poids étant un peu trop lourd, le drone a déplacé les 4 kg sans vraiment décoller. Deuxième test, j'ai enlevé le poids et j'ai mis le drone dehors : le but était de le faire décoller et de voir si il était pilotable. J'arme, les moteurs tournent doucement. Je pousse un tout petit peu les gaz : les moteurs accélèrent un peu, puis un peu plus, et le drone décolle, et il met la gomme (un peu comme avant) ; mais en 1 ou 2 secondes, le drone se retrouve à 40 mètres (vraiment), verticalement. Je coupe les gaz, mais le drone continue apparemment à monter, toujours verticalement. Je désarme, et le drone tombe (et reste dans un arbre, à 20 mètres...) Donc : quelle est mon erreur ??? Peut-on spécifier une vitesse maxi des moteurs ? Est-ce un signe que le baromètre était HS ? Merci pour vos idées !

Oui je sais... Mais justement, le FC dit probablement à l'OSD : "affiche le nombre de satellites en haut à gauche, puis affiche les coordonnées à droite". Si une étape plante, ça peut planter la suite... Par exemple, ça pourrait planter si le nombre de satellites est 0, ou si l'altitude est négative, ou je-ne-sais quel cas temporairement erroné / incomplet que l'OSD ne saurait pas gérer. D'où l'idée de jouer avec l'ordre dans lequel le FC donne les instructions à l'OSD, pour que ça plante le plus tard possible. Pour trouver les bugs logiciels, il n'y a pas 50 solutions, en fait. Il faut trouver LA étape qui fait planter la suite.

Essayons alors comme ça : - le GPS est bien connecté (sinon il ne donnerait rien) - le GPS envoie des infos au FC au format NMEA ; les lignes NMEA donnent plus ou moins d'infos, et ça se complète peu à peu (certaines trames donnent le fix et le nombre de satellites ; d'autres le fix et l'altitude ; etc.) - le FC décrypte probablement le format NMEA, et il envoie les infos à l'OSD. Je pense que le FC envoie à l'OSD l'image vidéo, et précise "place le texte Latitude à tel endroit sur l'écran". Et l'OSD affiche. Donc : soit le FC a un bug, soit l'OSD a un bug. "Un bug", ça peut être le fait de dire "si une info n'est pas bonne, j'arrête tous les affichages". A essayer : - rétrograder le FC (déjà proposé) - essayer de modifier l'ordre d'affichage des champs de l'OSD ; je ne suis pas sûr de la façon de faire, mais il y a forcément marqué quelque part "mets la latitude à gauche et la longitude à droite". Il faut modifier cet ordre, pour mettre les champs "problématiques" tout au début (auquel cas le risque est que rien ne s'affiche, et on saura...) ou tout à la fin (auquel cas le problème sera presque résolu). C'est peut-être dans la config textuelle de Betaflight. - jouer avec la config du GPS (cf le post épinglé sur le sujet) ; une solution pourrait être de ne prendre qu'un réseau de satellites... - simuler le GPS avec un Arduino : enregistrer pendant quelques minutes les trames reçues, et les "rejouer" dans un ordre ou dans un autre (en gérant le champ "heure"), pour voir ce qu'il se passe

et sont un peu contradictoires. Le premier point semble dire "les infos GPS sont là, mais on ne les affiche pas". Le deuxième point dit "les infos GPS ne sont pas là". (Pour ce que j'en comprends, l'OSD est juste un afficheur d'info. Il ne va pas empêcher le drone de décoller...) Je penche plutôt pour un problème de fix GPS, surtout si ton GPS est un peu ancien : on a perdu l'habitude d'attendre (Avec un BN 880, il me faut parfois 3 minutes avant d'avoir mon fix, quand l'horizon n'est pas très dégagé...)

Yep... J'ai bien l'impression que c'est en effet un fil déconnecté en interne, mais ça me semblait tellement improbable... Plus qu'à le changer (mais... c'est de la récupération, il n'est plus commercialisé... donc j'ai peur de devoir changer les 4...). Je vais aussi voir si ce ne sont pas les fils eux-mêmes qui ont un problème (suite à des torsions) : au point où j'en suis, je peux les couper à ras et les prolonger, pour essayer. Bref, j'aurai découvert les symptômes d'un fil déconnecté / désoudé. Merci @Motard Geek pour ton aide !

Le bruit sur la table, c'est un autre moteur posé, connecté en parallèle, qui a le même comportement (et qui n'a pas été vissé). Il s'allume et s'éteint en même temps, strictement. ESC : c'est une carte 4-en-1. Les 3 autres moteurs sont ok. Mais si je déconnecte l'un des fils des moteurs ok, j'ai ce type de comportement. Donc il y a probablement un fil déconnecté quelque part. Pour compléter, j'ai utilisé un oscilloscope pour sonder les 3 lignes des moteurs. J'envoie ici une photo de l'oscillo, pour un moteur "sain" et pour un moteur "malade". (La différence est assez claire...) Donc l'ESC envoie bien, sur les 3 fils, des infos, mais dans le cas "malade", les infos sont brouillées. Je finis par me demander si le moteur n'a pas, en interne, un fil déconnecté (?!?), puisque les soudures sont connectées.

Bonne idée. Elle est là :

Bonjour, J'ai un problème de moteur : il tourne... comme dans la vidéo (la vidéo est dans le zip, sinon je ne peux pas la charger ici...) Il tourne 1/2 seconde, il s'arrête 1/2 seconde, il tourne 1/2 seconde... (Il ne fait pas de bruit particulier ; le bruit, c'est un autre moteur en parallèle, qui a le même comportement). Ca semblait fonctionner avec un autre moteur (que j'ai flingué avec une vis mal positionnée qui a dû abîmer une bobine..) donc je pense que l'ESC est en bon état. L'ESC semble détecter le problème : il s'arrête après quelques secondes. Si je mets 2 moteurs en parallèle, les deux ont le même comportement en même temps, donc le moteur semble ok. Les soudures ont l'air solides, car quand je tire (légèrement) sur le fil, ça résiste (et je les ai déjà de-soudées et re-soudées). Donc : tout va bien, mais ça ne va pas... Ca évoque quelque chose à quelqu'un ? Merci !

C'était un problème de version ISRM : j'ai dû passer à la 2.10, et ça marche. (C'est assez peu documenté, cette histoire, en fait, ce problème de version). Pour les personnes qui ont un problème similaire : aller sur le site de FrSky télécharger la dernière version du firmware de l'émetteur de la télécommande le mettre sur une carte MicroSD placer la carte dans la télécommande, allumer la télécommande lire la carte (Menu_long puis Page) appliquer le firmware redémarrer la télécommande et ça devrait marcher. Et pour répondre à @cachecache (c'est gentil de m'avoir écouté... je me sentais seul...), c'était un problème d'appairage (je crois. La 1e étape de "register and bind" qu'on trouve décrite partout, et où tout se passe facilement...)

Bonjour, J'ai un RX tout neuf (Archer RS), une Taranis X9 lite d'occasion (juste un peu utilisée pour du simulateur, donc elle n'a pas fait ses preuves...), et je n'arrive pas à les Register. Je pense que ça importe peu, mais j'ai comme FC un SpeedyBee F405 v4 J'ai suivi les procédures : - mon RX affiche ses deux LEDS rouge et vert qui signifie "Status = Register" - ma X9 lite fait le bip-bip horrible qui dit qu'elle est en mode "register". Mais elle affiche "Attente". et rien ne bouge. Je peux démarrer l'un puis l'autre, ou l'autre puis l'un, ça ne change rien. Quel peut être le problème ? A défaut, est-ce que quelqu'un connaît la manière dont ça fonctionne : est-ce que le Rx écoute sur une fréquence spécifique, et la télécommande émet ? (surtout : quelle est cette fréquence : j'ai plein de matos pour tester ça...) Merci pour vos idées ! Tous les tutos disent "ça marche facilement", donc quand ça coince, on est perdu...

Pour info (si quelqu'un se pose la question un jour prochain...), je m'oriente vers : - un modem 4G / uart (40 euros en Chine, et un abonnement mobile en France) - l'envoi de données en MQTT vers un serveur, à partir de ce modem - la récupération des données en MQTT par mon PC. Pour le dire autrement, comme je n'ai pas de solution Tx+Rx sous la main, et que la latence n'est pas un gros problème, je bidouille un Tx et j'utilise les réseaux mobiles classiques : ça divise par 2 le problème.

Pas forcément par le FC, mais ça serait idéal. Si je "vois" quelque chose au sol, je pourrai m'en approcher et "regarder mieux". Donc si c'est via le FC, je peux automatiser. Sinon, je peux voir ça sur mon "écran" et gérer ça à la main. La version actuelle enregistre les données à partir de la puce externe qui les collecte. Je réfléchis à ajouter une puce qui envoie les données en WiFi vers un PC. Ca serait déjà mieux. Encore mieux, je reprends les matériels existants (VTX, VRX) et je les bidouille, parce qu'une grosse partie de la fiabilité sera gérée. Encore mieux, donc, j'intègre ça au FC.

Bonjour, Je débute en drones, parce que j'ai un besoin bien spécifique : je souhaite, à partir d'un drone volant à quelques mètres, faire des mesures du sol (avec une électronique perso) et les envoyer en temps réel. C'est un peu comme une télémétrie, sauf que je dois envoyer plein d'infos (plusieurs dizaines de ko / seconde), donc c'est trop lourd pour les "télémétries" classiques. C'est un peu comme envoyer une image vidéo, sauf que ce sont des mesures spécifiques : il ne s'agit pas de brancher une caméra, ni, à l'arrivée, de décoder le flux vidéo. Mais si j'arrivais à utiliser le "transport vidéo" pour envoyer d'autres infos, ça serait idéal. Est-ce ce que ce sujet évoque quelque chose à quelqu'un ? Peut-être que je pourrais trouver une "carte vidéo open-source" pour la bidouiller à la fois à l'émission (sur le drone) et à la réception ? Merci pour vos éclairages !