Betaflight 2.5.3

Encore une nouvelle version !? Oui, cela avance très vite du côté de Betaflight ! Nous avons à peine fait le tour de la 2.4.1 (c’est à revoir ici), que la version 2.5.3 est déjà en ligne. Cette nouvelle version « 2.5 » n’est pas qu’une simple mise à jour, Boris y a ajouté un certain nombre de nouveautés, et comme à son habitude, il peaufine également les fonctionnalités existantes.

Passons à la vitesse supérieure…

La volonté affichée dans cette nouvelle version, c’est d’augmenter la vitesse de traitement des données. Et le moins que l’on puisse dire, c’est que Boris y arrive avec brio ! Le looptime ne cesse de descendre, et les algorithmes ont encore été optimisés pour supporter ces vitesses toujours plus folles. Un grand travail a été fait sur l’utilisation du processeur dans cette version. Pour quel résultat ? Et bien avec une « simple » Naze32 rev5, il est maintenant possible de faire tourner les algorithmes de vol à 4khz (ce qui correspond à un looptime à 250) sans que la carte ne sature. En version 2.5.3, on observe entre 11% et 18% d’utilisation du processeur sur une Naze32, alors que dans les versions précédentes, si vous tentiez la même opération, le processeur saturait et il n’était même pas possible d’armer les moteurs ! Sur certaines F3 (la LUX de Lumenier et la Cyclone de Motolab), on peut même descendre le looptime à 125, ce qui nous donne une fréquence de rafraîchissement de 8khz ! Et à quoi cela sert-il me direz-vous… Il en ressort comme « impression » en vol, une plus grande fluidité, tout en ayant le sentiment que votre machine est « collée » à vos sticks. Le moindre mouvement sur les sticks, et l’ordre est immédiatement transmis à la carte de vol. Cela se ressent notamment lorsque l’on passe d’un looptime de 1000 à 500, et encore de 500 à 250… Au delà, c’est moins perceptible voir… imperceptible !

[ASTUCE] Dans cette version 2.5, plus besoin d’aller dans le CLI pour régler la vitesse du looptime, vous pouvez passer par l’interface graphique (GUI – Onglet Configuration) pour cela, d’autant qu’en passant par l’interface, s’il y a besoin de désactiver des fonctionnalités – sur la Naze32, il faut notamment désactiver le baromètre (BARO) et les accéléromètres (ACC) – cela se fera automatiquement. Mettez simplement la valeur du looptime souhaitée (500 par exemple) et cliquez sur « Save and Reboot », il désactivera automatiquement les fonctions nécessaires suivant votre carte de vol. Et lorsque vous repasserez le looptime à 1000, il les réactivera tout seul également.

Multishot et Oneshot42 supportés…

Boris ne s’est pas arrêté là. Conscient que l’on arrive à la limite du Oneshot125 sur les ESC actuels, il a rajouté dans cette version le support du Oneshot42 (disponible sur les ESC KISS 24A par ex.) – 3 fois plus rapide que le oneshot125 – ainsi que le Multishot, donné pour être 10 fois plus rapide que le Oneshot125 ! Et il a adapté le code pour en simplifier l’utilisation. Comment ? Prenons un exemple : si vous activez un looptime à 125 sur une LUX, en restant en Oneshot125, les ordres donnés aux ESC/moteurs seront automatiquement limités à 4khz, car au-delà, le Oneshot125 sature, ce qui se traduit en général par des désynchronisations d’un ou des moteurs. Le code adapte donc la vitesse de communication entre la carte et les ESC en fonction du protocole utilisé (Oneshot125, Oneshot42 ou Multishot).

[INFO] Toutes les cartes F3 ne sont pas logées à la même enseigne ! En effet, une donnée rentre maintenant en ligne de compte, c’est le type de BUS utilisé entre le GYRO et le processeur de ces cartes – « I2C » versus « SPI ». Le bus SPI, implémenté, entre autres, sur la LUX et la Cyclone, permet de monter plus haut en fréquence – jusqu’à 8khz – et ces cartes F3 en bus SPI pourront donc atteindre des vitesses plus élevées, tout en utilisant plus de fonctionnalités simultanément que leurs consœurs en bus I2C. On le voit dans cette version 2.5 de Betaflight, une SPRacingF3 montre ses limites quand on atteint les 4Khz, là où une LUX peut monter à 8khz sans sourciller.

MultiWii 2.3, le retour…

Dans cette version 2.5, Boris réintroduit un autre « PID Contrôleur » (PIDC) – le MultiWii 2.3 (MW23) – en plus du LUXFLOAT et REWRITE. Il devait l’être à titre expérimental au départ, notamment pour sa gestion du Yaw qui est meilleure qu’en REWRITE et LUXFLOAT, mais au vu des retours (positifs) des différents pilotes et de Boris lui-même, ce PIDC MW23 pourrait bien devenir le préféré de beaucoup de pilotes !

[ASTUCE] Attention, si vous voulez tester ce PIDC MW23, n’utilisez pas les valeurs par défaut qui sont données dans l’interface, elles sont beaucoup trop élevées ! Vous pouvez utiliser, comme point de départ, les valeurs suivantes, qui seront ensuite à adapter sur le terrain, en fonction de votre machine :

• ROLL : 2.5 / 0.020 / 20
• PITCH : 3.5 / 0.025 / 25
• YAW : 6.5 / 0.045 / 0
• Rates (pitch, roll et yaw) : 0.70
• RC Rate à 1.0
• RC Yaw expo : 0.20

Le WIKI s’enrichit…

Depuis quelques semaines, un WIKI a été mis en place pour Betaflight. Nous vous le conseillons, car il regorge d’astuces glanées au milieu des centaines de pages du post RCGroups de Betaflight. Il est en langue anglaise, mais même pour ceux qui ne maîtrisent pas cette langue, il vous permettra, par exemple, de retrouver facilement certaines commandes du CLI, spécifiques à Betaflight, et en particulier les valeurs possibles pour une commande donnée.

Ce WIKI est accessible en suivant ce lien.

Deux commandes CLI pour le diagnostic…

Dans les dernières versions de Betaflight, pour aider au diagnostic, 2 nouvelles commandes, à taper dans le CLI, sont mises à votre disposition :

« Status » : cela vous donnera une vue « simple » de votre carte, tant en termes d’utilisation processeur que des composants utilisés. Rendez-vous dans l’onglet CLI, tapez simplement « status », et validez la commande. Les informations s’afficheront alors à l’écran, ce qui vous permettra de vérifier, en fonction de ce que vous avez activé dans la configuration, que le processeur de votre carte n’est pas utilisé à 100% (saturation).

« Tasks » : le code de Betaflight est organisé en « tâches ». Une pour gérer les ordres reçus de votre radio par exemple, une autre pour gérer la stabilisation, une pour le beeper, une encore pour la batterie, etc… La commande « tasks », à taper dans le CLI, vous donnera des informations sur les temps d’exécution de ces tâches, vous pourrez ainsi utiliser ces informations pour diagnostiquer l’origine d’un problème, ou copier et coller ces valeurs sur un forum pour que l’on vous aide à en trouver l’origine.

Les autres nouveautés…

Parmi les autres nouveautés, on pourra noter l’implémentation du transpondeur sur la F3Mini (la F3Mini était déjà supportée mais sans cette fonctionnalité), l’ajout d’une nouvelle commande « beeper » qui remplace la commande « beeper_off_flags », et l’amélioration de la lecture des données venant des accéléromètres (pour ceux qui utilisent les modes stabilisés).

[ASTUCE] depuis la version 2.5.0, la commande beeper_off_flags a été remplacée par la commande « beeper » qui permet d’activer ou de désactiver le beeper dans certaines situations. Vous pourrez retrouver les différents valeurs possibles sur cette page du WIKI, au paragraphe « set beeper_off_flags / New in V2.5.0 Final ».

Vous pourrez retrouver la liste complète des nouveautés sur la page des « Releases » de Betaflight.

[ATTENTION] Dans cette version 2.5.3, la commande min_check a été passée par défaut à 1040 (1100 auparavant). Si vous n’avez pas réglé votre radio (via les fins de courses des voies) pour envoyer un signal allant exactement de 1000 à 2000, vous ne pourrez sans doute pas armer vos moteurs. Pensez bien à régler les valeurs min et max (et neutre) de chacune des voies et inter sur votre radio.

Faut-il passer sur cette version ?

Vous l’aurez remarqué, les versions de Betaflight défilent. Nous n’avons même pas le temps de tester une version, qu’une autre (voir plusieurs) sont déjà en ligne ! On est en mode « itératif » ou « expérimental » et Boris compte sur les testeurs et leurs retours d’expériences sur ces différentes versions (et en tient compte !). Résultat ? les versions évoluent – dans le bon sens – très vite, et il semblerait que l’imagination de Boris soit sans limite quant aux fonctionnalités à ajouter, car pour une version où l’on se dit : « ca y est, qu’est ce qu’il pourrait bien rajouter maintenant ? », il revient quelques jours plus tard avec d’autres nouveautés et optimisations… Au final, il faut juste arriver à faire le tri dans ces versions, pour en retirer LA version « stabilisée » pour nos prochaines sessions de vols.

Nous ne le rappelons donc jamais assez : Betaflight porte bien son nom « Beta ». Utilisez ces versions en connaissance de cause.

Oui…

Cela étant dit, et après avoir testé ces versions 2.5.x, la 2.5.3 apparaît comme une version aboutie, très agréable et très saine en vol, utilisable sur l’ensemble de nos machines. Je vous conseille de commencer avec un looptime à 500 (2khz) – Pas la peine d’aller chercher tout de suite les limites de vos cartes en voulant descendre plus bas – et vous apprécierez, vous aussi je l’espère, la fluidité en vol, et une machine bien verrouillée sur l’ensemble des axes (une fois réglée bien entendu…). J’ai particulièrement apprécié les sensations en vol avec cette version – sur un QAV210 et un QAV250, l’un avec une LUX de Lumenier, l’autre avec une Naze32 rev5 – que ce soit en mode « freeride » ou en mode « circuit/course ».

[ASTUCE] Pour rappel, sur une Naze32, dès que vous voudrez descendre en dessous de 1000 en valeur de looptime (500, 375, 250, 125), vous ne pourrez plus utiliser les modes stabilisés, ni de LED, ni d’OSD, etc… Cette carte n’a plus assez de puissance, à ces vitesses, pour gérer autre chose que le vol en mode ACRO (mais dans ce mode, elle le fait encore très bien !).

Télécharger la version 2.5.3…

Comme pour toutes les versions de Betaflight, vous pourrez télécharger le fichier correspondant à votre carte de vol à partir de cette page et passer par « Cleanflight Configurator » (sous Chrome) pour la flasher et configurer le tout.