DIY GnuVario : variomètre opensource - openhardware Arduino

#1361

Merci pour ta réponse, simple et efficace! J’étais passé à coté des waitwhilebusy! Je vais regarder ça de plus près.

Est ce que tu ne penses pas qu’il faudrait rafraichir l’écran moins souvent? J’ai peur de la durée de vie du truc en cas de rafraichissement trop fréquent, notamment quand il fait froid.

Personnellement je ne regarde pas mon vario très souvent et si on considère un moyennage du vario ou de la vitesse sur 10 secondes, je me demande ce que les utilisateurs diraient d’un écran rafraîchit seulement toutes les 10 secondes?

#1362

10 sec me parait vraiment très long, 1 ou 2 sec pourrait être envisagé pour économisé l’écran. Effectivement j’ai lu que les écrans I-ink ne durait pas longtemps, en moyenne 3 ans pour une liseuse

#1363

Une petite photo des dernières avancées avec un écran 2.9’’. C’est joli ces écrans e-ink!

Mon aile a un souci, j’ai 10.2 de finesse à +5.5 de vario??? :bu:

J’ai pu confirmer que la charge lipo fonctionne bien. C’est compatible avec lipo > 500mah, coupure automatique du circuit à faible charge.

J’ai regardé un peu plus en détail le gnu vario, les principales différences sont:

  • pin reset pas addressable autre que par bouton poussoir
  • pas de detection de l’usb. Mais par software, ca peut se faire.
  • buzzer drivé par un transistor sans ampli. Pas compatible avec toneAC. Je drive avec tone. A voir pour le contrôle du volume. Il y assez de pins dispos pour rajouter un speaker externe.
  • pas de contrôle sur les lignes d’alimentation des différents modules car ils ont tous de toute façon un mode sleep à faible consommation.
  • GPS pas connecté directement au bluetooth.

Je bosse sur le code car le but était aussi que je devienne moins mauvais programmeur mais la majorité du code du gnu vario est facilement adaptable.
Prochaine étape, vérifier le bruit des capteurs et de l’alim.
A++

#1364

Salut,

je pense que les petites différences ne sont que des détails que l’on peut les négliger ou les contourner. Ton écran est bien organisé et les infos sont très lisible.

Je me demande si l’écran 2,9" n’est pas trop grand pour une utilisation sur les élévateurs, mais l’idée pourrait être d’avoir 2 versions, une en version portrait et une en version paysage. En portrait, grand coté sur les cotés on aurait un vario plus fin et un peu plus long, la détection pourrait ce faire en fonction du sens de calibration des accéléromètres.

Avec le code du gnuvario, il ne serait pas très compliqué d’avoir 2 organisations de l’écran

super boulot, j’ai vraiment hâte de pouvoir développer sur ton hard

#1365

Oui je suis d’accord c’est trop grand pour les élévateurs. Mais comme ca casse la finesse, vaut mieux l’avoir dans le cockpit :lol:

Il me semble que la prise est la même pour tous les écrans, donc si tu veux 1.5 ou 4 pouces, tu peux te faire plaisir!
Il va de toute façon falloir se débarrasser de cette énorme pcb sous l’écran et de son énorme connecteur et soit l’intégrer à la pcb soit utiliser un petit adaptateur.

Stay tuned.

#1366

Bonjour

Je reviens faire mon chieur :diable:

J’ai eu un peu de mal à remettre mon vario sur patte, je court-circuitais bêtement les connections dessoudées du bouton reset au lieu de court-circuiter la pin reset comme l’indiquait Prunkdump. Je comprend pas, j’ai été obligé de flasher mon variosetting à nouveau . bizarre :bang:

Mais voilà , j'ai re-telechargé la version 63.05 de JPG63 et c'est plus la même qu'avant ?? Il y a bien la fonction mute, mais c'est la présentation de Prunkdump à l’écran. J'aimais bien la présence des carrés triangles clignotant en haut pour connaître l’état de l'enregistrement. A part ça, le bug du buzzer qui sature est toujours présent.

A plus Olivier, amusez vous bien avec la nouvelle version

#1367

Salut,

il faut que tu prenne le bon variosetting.h

pour avoir mon écran il faut le #define HAVE_SCREEN_JPG63

sinon il est possible de désactiver le Mute

#1368

intéressé également par le full kit
Merci pour le travail fait et à faire !

#1369

Déjà bientôt 2 mois depuis les dernières nouvelles du développement de ma carte maison alors en voici quelques une. Pour résumer, pas de gros problème mais beaucoup de petits soucis à régler:

  • Capteur de pression trop bruité du au type d’alimentation utilisé -> mise en place d’un filtre passif.
  • Perte de signal gps avec la décharge de la batterie -> 1er redesign de l’alim.
  • Module bluetooth HC-05 vendu uniquement en version 5V. Incompatible 3.3V. Il aurait été possible de bypasser le régulateur de tension mais j’ai décidé de changer pour un module intégré à la carte.
  • Boutons connectés a des pins sans interrupt… -> remappage de la carte.
  • Connecteur batterie nécessitant de sertir des fils. J’ai jamais réussi. -> changement de connecteur.
  • Idem pour le connecteur de l’écran.
  • L’usb à gauche, interrupteur à droite, carte sd en bas… Impossible à rentrer dans une boite. -> réorganisation complète.

Aussi au menu de la nouvelle version :

  • 2ème redesign du circuit d’alim, complètement revu au final.
  • Plus de d’interrupteur général mais un bouton, ce qui porte à 4 boutons au total utilisables.
  • Miniaturisation de la pcb des écrans waveshare qui sera encore externe mais bcp plus petite.
  • Adaptation de la carte à une boite en plastique : 2 versions, une grosse pour écran 2.9’’ et une petite qui a subit une grosse cure de compactage pour écran 1.5’’.

Au final il y a tellement de changement que c’est quasiment une autre carte, alors on croise les doigts pour qu’il n’y ait pas trop de correction à apporter. C’est que le début de la saison approche !!

Les designs vont partir en fab d’ici peu, remarques ou suggestions bienvenues!

#1370

wow, bravo !
Effectivement, pas tant de temps que ça passé depuis ton dernier message, vu le boulot réalisé!

Pas vraiment une remarque, mais une question de béotien : comment fonctionne le plan de masse?
En regardant juste les images du pcb, les composants ne semblent pas y être connectés. Est-ce par-ce que le plan de masse n’est pas figuré pour améliorer la lisibilité? Autre raisons qui m’échappe?

En tout cas, encore vraiment bravo.

Puisque le fil repart, c’est un peu HS, mais j’en profite pour faire un UP sur le projet du vario à base d’esp8266 d’Hari Nair, qui a bien évolué aussi (repo du projet : https://github.com/har-in-air/ESP8266_MPU9250_MS5611_VARIO )

3 points intéressants / inspirants avec ce tout petit vario IMU+baro “audio only” doté du wifi.

  • le prix de revient : +/-20 euros. Imbattable pour la techno sans latence !
  • Configuration OTA (seuils des bips, fréquences etc), via wifi depuis son smartphone ou PC, le vario se met en point d’accès wifi pour ce mode, avec une petite page de config conviviale.
  • Le travail d’optimisation du filtre de kalman réalisé par Hari, grâce à des acquisitions haute vitesse de données réelles (avec un ESP32+IMU GPS+SD, voir son dossier dédié : https://github.com/har-in-air/ESP32_IMU_BARO_GPS_LOGGER

J’en ai monté une paire, (tout en l’air, pas de PCB, je ne joue pas dans la même cour que vous :wink:
et j’ai dessiné une petite boite custom pour impression 3D:


https://image.noelshack.com/minis/2018/09/1/1519682866-2018-02-01-22-18-51-solid-edge-v18-assemblage-vario-assy-asm.png


https://image.noelshack.com/minis/2018/09/1/1519682871-img-20180226-230403.png

Au besoin, fichiers sources des 3D et plus de photo sur mon repo : https://github.com/antoine5974/esp8266-vario-3D-printed-casing

En tout cas, cool de voir que le fil est toujours vivant, encore un peu de temps pour jouer avant le printemps !

#1371

Salut,

j’avais testé son code sur le MKZero, il fonctionnait sans problème. A voir si ce code optimisé est plus efficace que celui utilisé par notre GnuVario. Peut être que Prunk dump pourra nous éclairé. Si c’est le cas je veux bien regardé pour intégré le code d’Hari Nair afin d’avoir ce qu’il y a de mieux

#1372

Superbe boulot, félicitation.

A tu prévu un inter pour couper totalement le vario ? Pendant de longue durée sans vol, cela pourrait être intéressant afin d’éviter de vider totalement la batterie.

Sinon super idée la possibilité d’avoir soit un écran 1,54’’ (montage sur élévateurs) et un 2.9’’ pour un montage sur cockpit

Pour le boitier, je me demandais si il ne serait pas intéressant ajouter une petit plaque de plastique type rhodoïd pour protéger l’écran, mais cela veut dire qu’il ne faut pas qu’il dépassasse du couvercle

Une question, une idée du prix de fabrication par un pro de tout le PCB, fabrication et soudure ?

#1373

Si il reste quelques E/S de libre, il pourrait être intéressant de raccorder la pin RST à une sortie, ceci pourrait permettre de rebouter le MKZero, par exemple après une calibration ou autre. Et peut être la pin d’interruption du MPU sur une entrée avec interruption (fonctionnement utilisé par hari nair)

#1374

Les images sont tirées en mode routage pour plus de lisibilité. J’attache la même avec ses deux plans de masse.

Un des boutons aura deux fonctions: appui court: bouton normal, appui long, coupure du circuit d’alim. Le proc pourra aussi se suicider et tout couper.

Oui il serait bien de protéger l’écran. J’ai un kobo mini et l’écran est pas mal fragile.

La, la grosse inconnue est le prix des composants. Je pense que ça doit au final pas revenir beaucoup plus cher car les composants achetés en gros par les fabricants de pcb sont beaucoup moins chers qu’au détail. Il y aussi le nombre de cartes, le tarif par carte descend en chute libre avec le nombre commandé. De toute façon, c’est pas encore à l’ordre du jour sans un proto éprouvé à 200% parce que la moindre erreur se paie cash -> $$$$, cartes ET composants.

Il doit me rester deux pins de libre. Je peux en connecter un au reset. Pour l’autre,je n’ai pas compris? Et je n’ai plus de pin avec interrupt. J’ai pas compris pourquoi le zero à un interrupt externe sur tous ses pins et pas le mkr zero. Ca m’a fait perdre beaucoup de temps.

#1375

Avec un poussoir aura-t-on une coupure physique de la batterie ? Ce serait bien un petit inter pour tout couper physiquement (problème de plantage, éviter de vider la batterie dans le circuit de charge…)

Sur le MPU 9250, il y a une pin d’interruption qui change d’état à chaque mesure, du coup il est possible de déclencher l’acquisition des données au maximum du composant, c’est ce que fait Hari hair)

Pas grave, si il ne reste plus d’interruption le problème est réglé

#1376

J’ai remplacé le switch par un circuit donc c’est bien une coupure physique, controlé par un bouton poussoir, ou le proc.

Ok je comprends mieux. Sur la version 1.5’’, il y aura un bouton en moins donc un pin de libre avec interrupt. Je peux eventuellement le connecter au mpu.

J’ai commandé les nouveaux composants, il me reste à travailler sur le module bluetooth et je lance la fab! J’ai choisi le RN4871.

J’essaierai de faire un petit programme en temps venu pour configurer le vario OTA via bluetooth. Le wifi me parait overkill :wink:

#1377

Salut les varieux :coucou:

Je vois que ça bosse dur cet hivers même si ça parle moins :shock: Je suis pas sûr d’avoir suivi ce rythme :mrgreen:

Super boulot en tout cas FluffyClouds ! On voit même que tu as le sens de l’esthétique dans tes routages :wink: C’est vraiment au niveau des professionnels. Moi j’aurais juste le conseil d’essayer d’intégrer le connecteur pour la nappe de l’écran sur le PCB principal. C’est vraiment pénible les connecteurs filaires, ça casse et ça fait des faux contacts. De plus tu pourra souder la nappe directement sur le PCB. Autrement c’est impressionant le nombre de condos ! On voit le soucis de stabiliser tout ça !

Je viens de jetter un oeil sur le code de Hari. C’est très bien documenté :shock: Grosse leçon sur ce point ! Tous les liens et les explications sont données pour comprendre l’ensemble du code et pour monter toutes les versions possibles du vario. Pour son algo de Kalman, en fait il n’a pas été modifié depuis la première version. Ses mesures, il les as faites pour valider son modèle et choisir les paramètres qui fonctionnent le mieux. Je trouve simplement qu’il est un peu trop complexe a mon gout. Dans celui du GnuVario je travaille en dimension 2 (vitesse,acceleration) au lieu de la dimension 3 (vitesse, acceleration, jerk). Mais sur un bon microcontroleur ce n’est pas un problème puisqu’il y a de la place pour le code.

Il utilise également l’algo de Madgwick pour la combinaison 6DOF. Alors que le GnuVario utilise le DMP du MPU9250. L’algo de Madgwick est sûrement mieux. Mais encore une fois c’est tout ça en plus à faire rentrer en flash et as faire tourner sur le Microcontrolleur. Par contre l’algo de Madgwick supporte le 9DOF, ce qui peut être intéressant.

Pour la configuration par le WIFI c’est une excellente idée. J’avais dans l’idée de travailler sur une port du code pour ESP32 :

https://www.ebay.fr/itm/TTGO-MINI-Wemos-D1-ESP32-32S-WIFI-Development-Bluetooth-ESP8266-Module-CP2104/263292959071?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

Pour ceux qui ne connaissent pas cette puce est hallucinante en théorie :
-> 2 coeurs indépendants à 240Mhtz
-> 4MB de mémoire flash
-> WIFI intégré
-> bluetooth BLE intégré
-> support intégré des cartes SD
Tout ça pour 6 euros … :grat: Mais elle n’est pas supporté officiellement par Arduino. Mais le module d’intégration est Open-Source.

Autrement de mon côté je bosse sur le code et sur la version MKRZero.

  1. J’ai un schéma fonctionnel et simple pour le contrôle de l’alimentation et de la charge du vario.

  2. Je m’arrache les cheveux sur le compas et le passage au 9DOF. C’est bien moins simple que je le pensais. Mais j’ai presque abouti un code fonctionnel qui donne le nord quelque soit la position du vario.

  3. J’ai reprogrammé une procédure de calibrage entièrement de 0 à partir de ce papier :

https://www.emis.de/journals/BBMS/Bulletin/sup962/gander.pdf

L’idée c’est qu’au lieu d’avoir une procédure qui nécessite de positionner le vario dans de positions précises. Dans cette procédure, plus on a de mesures plus on s’approche du résultat optimal. Et surtout l’algorithme s’assure que le qualibrage est optimal pour la serie de points donné par les mesures. En gros on est certain qu’il n’existe pas de centre et de rayon pour la sphere qui minimise mieux l’erreur pour les points données.

J’ai aussi fait un algo pour le calibrage selon une ellipse dans le cas où les capteurs sur chaque axe n’auraient pas la même sensibilité. Mais le gain n’est pas suffisant à mon avis comparé à la complexité du calcul nécessaire. Et on ne peut pas l’intégrer au DMP (qui ne calibre pas selon une ellipse)

Je publie ça dès que c’est fiable. Avant de m’attaquer à l’afffichage de la force et de la direction du vent :mrgreen:

Allez ! Plus on est de fous plus on rit :wink:

A+

#1378

je vais faire des essais avec le code de hari sur le Mkzero, on verra ce que l’on choisira au final -

j’ai déjà programmé cette board avec IDE arduino

https://www.ebay.fr/itm/WEMOS-D1-MIINI-Lolin32-WIFI-Bluetooth-ESP32-ESP-WROOM-32-Board-CP2104-4MB-Flash/263092747338?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D2%26asc%3D20161027085944%26meid%3D20c882a968a949e6a50278da6b8b0db7%26pid%3D100623%26rk%3D3%26rkt%3D6%26sd%3D263292959071%26itm%3D263092747338&_trksid=p2047675.c100623.m-1

#1379

Dit-il! Elle est bonne…!

Yes c’est ce que je voulais faire mais la nappe de l’écran est tellement courte que ca forcait à coller l’écran sur le dos de la carte. Surement pour la prochaine version!

Super cet ESP32, je vois qu’il y a un core Arduino. Je vais éviter de trop regarder sinon je vais tout effacer et recommencer avec celui la :wink:

#1380

Merci prunkdump pour’les explications sur le filtrage.

Et apparemment tu n’as pas chômé non plus :pouce:

Concernant l’esp32, hari à fait une version de son Vario avec cette puce. (+Gps, mémoire flash, IMU, et un LCD, de résolution moyenne mais de grande taille)
Une autre grosse amélioration concerne le son, il utile un speaker de téléphone, avec un ampli et une sortie DAQ dont dispose l’esp32, la qualité du son est grandement améliorée par rapport aux buzzers piezzo.
Ça n’est pas encore publié, mais ça le sera sans doute prochainement.

Il trouve aussi cette chip extraordinaire, mais aussi très frustrante, car bien buggé et mal documentée. Quasiment inexploitable avec L’ide Arduino, et sous windows, même si des librairies commencent à sortir de ci de la… A utiliser par des experts et en connaissance de cause!

Enfin, concernant la calibration Baptiste, je ne sais pas si tu as regardé le code de hari, mais il fait la calibration en gardant le vario à plat, sans permuter les faces.

Fluffyclouds : dans le cas de l’esp8266 ou esp8285, le wifi pour le paramétrage OTA n’est pas overkill, car la puce est wifi nativement, mais n’a pas de module BT. Pour l’esp32 ou pour ton montage, ok.

Bon courage les geeks-masters!