D' abord une très bonne année à tout le monde.
après la réalisation d'un fork du vario de Sinseman(qq pages avant dans ces posts), j'avais trouvé des exemples carte arduino avec GY-86 + appli processing, et l'association d' une carte raspi ou pcDuino avec système d'exploitation me paraissait un peu lourd.
A partir des travaux de rowberg sur MPU6050 (capteur qui équipe la GY-86 + HMC5883L+ MS5611) j'ai réussi à récupérer correctement le Roll/ Pitch mais pas le yaw qui semblait n'importe quoi par rapport à une boussole.
Et je suis arrivé à la même conclusion que
redge76 . Il faut partir de quelque chose bien expérimenté, et pour moi c'était
Multiwii2.3 (qui tourne bien sur mon tricoptère avec carte Crius V1), qui offre une facilité de paramétrage et de calibration avec
MW_WinGui2.3 (EOSbandit) avec tous les filtrages possibles.
https://youtu.be/RgZM_uZCNcY
Mon système se composerait de deux boites:
une "blackBox" située au centre de gravité de l'appareil et éloigné de toute "ferraille",
composée -------> un arduino nano + GY-86 (multiWii2.3 allégé) +un arduino nano (dataLogger+ softEasyTransfer) + enregistreur SD
+ carte BlueTooth HC-05 master
Une boite avec double afficheur OLED couleur SSD1351 qui ne peut fonctionner qu'avec Teensy3.x et une librairie Optimisée SSD1351 avec "buffering"
( sans ça, ce n'était pas regardable - et s'il y a 2 écrans, il faut 2 cartes Teensy3.x) Un teensy3.x s'occupe de faire tourner l'horizon, l'autre des
données de vitesse et d'altitude, et un autre arduino nano + BlueTooth HC-05 Slave pour récupérer
les données et les envoyer en I2C au Teensy avec un temps de réponse correct (recevoir les données Bluetooth par le Teensy donne des salves
de données espacées de plusieurs secondes, et il n'y a pas de delay dans le prog).
C'est la seule façon élégante (mais riche en processeurs) que j'ai trouvé pour faire fonctionner le transfert de données.
Une fois la carte paramétrée, il faut récupérer les données à partir du port serial (étude du protocole multiwii serial), puis découverte du DataLogger et du prog. arduino réalisé par Renés (mise en place d'un enregistreur de carte micro SD) tout était "prémâché" et il y a 6 mois , j'aurais été incapable de cette réalisation.
Pour le pgm horizon, je suis parti d'un pgm en QBasic que j'ai fait tourner avec DosBox et QB45, je l'ai modifié pour afficher en 128x128, puis j'ai fait la conversion QBasic --> Arduino car il était bien structuré, et toutes les surfaces sont calculées (il reste encore des défauts d'affichage dans des cas difficiles, vol sur dos , 360° horizontal, etc... Cet appareil n'est pas destiné à un racer de voltige, mais à un ULM moins robuste à encaisser des G !
Mon idée serait de réaliser un appareil semblable au SAM-MD302, mais il faut rester humble, il ne fera pas tout ce que fait cet appareil à plus de 8000$