J’ai l’ambition de réaliser un horizon artificiel en particulier pour l’ULM de mon ami Thierry dont vous pouvez suivre l’évolution et la conception sur la page ulmminimalist 🙂
Pour mémoire un horizon artificiel est un indicateur d’attitude qui visualise les angles de tangage et de roulis de l’avion tel que celui qui est représenté ci-dessous :
Au sommaire :
Un horizon artificiel à base de Raspberry Pi
Horizon artificiel
Le capteur LSM9D1
Cet horizon pourrait être réalisé en utilisant un Raspberry Pi0, un afficheur graphique d’environ 3 pouces (7,6 cm) de diagonale et un capteur LSM9DS1.
La première étape consiste à évaluer le capteur LSM9DS1 qui sera le cœur de l’instrument, de quantifier la précision des données et d’effectuer la calibration.
Présentation du LSM9DS1
Le LSM9DS1 est un capteur à 9 degrés de liberté, c’est à dire qu’il mesure l’accélération sur 3 axes, la rotation sur 3 axes et enfin le champ magnétique, toujours sur 3 axes.
C’est un capteur très sophistiqué qui offre de multiples possibilités de mise en œuvre : déclenchement d’interruptions, mise en sommeil, bufferisation de données… Pour l’évaluation toutes ces options ne nous intéressent pas et on ne retrouvera pas ces possibilités dans le logiciel.
Montage hardware
Pour l’évaluation j’utilise un module de sparkfun : https://www.sparkfun.com/products/13284
Ce module est câblé par défaut en I2C c’est à dire qu’il suffit de relier 4 fils sur le connecteur : 0 et +3,3V ainsi que les deux fils de communication du bus I2C. J’utilise des cartes protos mais il est bien sûr possible de réaliser une connexion directe.
Prérequis logiciels
Comme j’ai une longue habitude du langage Pascal et du développement Delphi sous Windows, je vais utiliser l’IDE Lazarus. J’ai aussi choisi d’enregistrer des séquences de mesures en utilisant la base de données SQLite.
En résumé on va installer le compilateur Free Pascal fpc, Lazarus et la base de données sqlite par la séquence suivante :
sudo apt-get update sudo apt-get upgrade sudo apt-get install fpc sudo apt-get install lazarus sudo apt-get install sqlite3 libsqlite3-dev
Sur mon Rpi 3 tout c’est passé sans souci et je retrouve Lazarus dans la rubrique Programmation du Menu.
Enfin il ne faut pas oublier d’activer l’interface i2c-1 qui ne l’est pas par défaut. Il suffit de cocher l’option dans l’écran Menu >> Préférences>> Configuration du Raspberry Pi.
Le logiciel
La plupart des lecteurs de ce site ne sont sans doute pas familier avec le langage Pascal objet et Lazarus. Le but de cet article n’est pas de faire un tuto mais je vais commenter les grandes lignes du logiciel.
Les briques de base
L’accès I2C
L’unité LocalBus_Ctlr.pas assure l’accès de bas niveau au bus I2C. L’unité devra également gérer à terme le bus SPI, un début d’implémentation est dans le code. J’ai implémenté une classe générique abstraite qui permet au capteur d’accéder aux registres de façon transparente qu’on l’ait câblé en I2C ou en SPI. Dans tous les cas on dispose des fonctions de base :
- lecture d’un registre par son adresse : function GetRegisterValue(DevReg: byte): byte;
- écriture d’un registre : procedure SetRegisterValue(DevReg: byte; RegVal: byte);
- lecture d’un bloc de données : procedure GetRegistersValues(DevReg: byte; var RegsVals: array of byte);
[stextbox id= »warning » caption= »Nota »]L’unité sensor_types définit les types de données qu’on va manipuler, par exemple un vecteur (X, Y, Z) de nombres flottant en simple précision (7 à 8 chiffres significatifs ce qui est largement suffisant). La déclaration :
Int16_4IO = record
case RawInput: boolean of
True: (bytes: array[0..1] of byte);
False: (intValue: Int16);
end;
permet un accès au choix des octets (bytes) ou d’une valeur entière (intValue sur 2 octets) et nous évite le transcodage : on recopie les registres du capteur dans la table des octets et on lit directement la valeur entière sur 16 bits.[/stextbox]
Le module d’enregistrement sqlite
Cela peut sembler complexe d’utiliser une structure de base de données pour enregistrer nos mesures. Le but est de poser les bases d’un outil d’enregistrement souple et capable de gérer un volume important de données comme par exemple un enregistreur de vol. Et cela nous permet de constater tout l’intérêt des composants standards de Lazarus qui font que le codage de cette fonction ne demande que quelques dizaines de lignes.
Les fonctions
- Initalisation : constructor Create(AOwner: TComponent; ADB: string) permet de créer le fichier de base de données. J’ai créé le dossier MLogs sous /home/pi. Le fichier LSM9DS1Calibration.s3db sera créé pour l’enregistrement des mesures.
- La procédure CreateDataTable(TableDescriptor: TDataTableDescriptor): permet de créer la table d’enregistrement des données. La première colonne est obligatoirement la date/heure de l’enregistrement. On passe en paramètre la liste des noms de colonnes à créer, liste simplement constituée des noms des colonnes.
- La procédure RecordDatas(ATime: TDateTime; Datas: array of single) qui va enregistrer une ligne de données : il suffit de passer en paramètre la date/heure et la liste des valeurs.
Le module LSM9DS1
C’est le module qui va nous permettre d’accéder aux capteurs en masquant la complexité de la mise en œuvre et aussi de nous fournir des données corrigées et dans le format souhaité.
[stextbox id= »alert » caption= »Nota »]Pour le traitement de grandeur physique j’utilise systématiquement les unités SI en interne. Si besoin c’est au moment de l’affichage que je réalise la conversion d’unité pour l’affichage (Y en a qui ont essayé autrement, ils ont eu des problèmes : plantage de fusée, de sonde spatiale).[/stextbox]
Ce module permet
- L’accès en écriture et lecture des registres par leur symbole : property Register[r: TLSM9DS1_Regs]: byte read GetRegister write SetRegister;
- La lecture des données accélération, gyro, magnétique et éventuellement température en unité SI
property Acceleration: V3D_Single read GetXL;
property Gyro: V3D_Single read GetG;
property Magneto: V3D_Single read GetM;
property Temperature: single read GetTemp;
et les fonctions annexes :
- Vérification de la connexion par l’interrogation des registre WHO_AM_I
function CheckWhoAmI(var waiXL_G: byte; var waiM: byte): boolean;
- Disponibilité des nouvelles données
function DatasReady(var dXL_Ready: boolean; var dG_Ready: boolean; var dM_Ready: boolean;): boolean;
Le code de test
Une fois les modules fonctionnels le code de test devient très simple.
Initialisation
L’initialisation est réalisée dans la fonction FormCreate qui est déclenchée automatiquement à la création de la fiche du programme.
Tests de base
- contrôle WHO_AM_I
- lecture d’un registre
Mesures
Les boutons permettent la lecture et l’affichage des données :
- accélération
- gyro
- magnéto
Exemple de code
procedure TfTest.btnGyroClick(Sender: TObject);
const rad2deg: single = 180./Pi; // 57.29578
var vG: V3D_Single;
begin
vG:= AGSensor.Gyro;
eGX.Text:= Format('%f [°/s]', [vG.X*rad2deg]);
eGY.Text:= Format('%f [°/s]', [vG.Y*rad2deg]);
eGZ.Text:= Format('%f [°/s]', [vG.Z*rad2deg]);
end;
Le bouton Continu permet d’afficher les valeurs en continu sur un rythme de 2 mesures / s.
Création de la base de données
Ce bouton déclenche l’enregistrement de séries (6) de séquences de 1000 mesures des 9 axes de liberté. Entre chaque série le logiciel demande de modifier la position du capteur. Choisissez des positions dans les 3 axes de l’espace et pensez à bien caler le capteur. Le résultat est sauvegardé dans le fichier /home/pi/Mlogs/ LSM9DS1Calibration.s3db (pensez à créer le dossier). Nota : la vitesse d’acquisition est inférieure à ce qu’elle devrait être théoriquement. Il va falloir examiner où se trouve le goulet d’étranglement.
Calibration du capteur
La calibration du capteur consiste à calculer les offsets et facteurs d’échelle à appliquer pour obtenir les résultats conforme aux grandeurs physiques :
- L’accélération au repos doit être de 9,80655 en module
- Le gyro doit être de zéro sur tous les axes
- Le magnéto doit donner en module la force du champ magnétique local. Celui-ci peut être estimé par un calculateur en ligne, par exemple : http://geomag.nrcan.gc.ca/calc/mfcal-fr.php
Cette opération dépasse le cadre de cet article, et pour tout dire se révèle plus complexe que ce que j’avais pensé à l’origine : après un premier examen les valeurs brutes sont très approximatives et le calcul des coefficients doit être précis.
Pour faire ces calculs, qui restent à faire, je compte procéder en suivant les étapes suivantes :
- Reprise de la base de données sur PC. Extraction des données avec sqlitemanager (utilitaire gratuit ne nécessitant pas d’installation). Ci-dessous extraction des moyennes pour chaque série :
- Poser un système d’équations pour les calcul des 6 inconnues : 3 offsets et 3 facteurs d’échelle. Le logiciel wxMaxima (également gratuit) permet de résoudre les équations. Ci-dessous un exemple avec un système limité à 3 équations pour la recherche des offsets (ox, oy, oz).
Conclusion (forcément provisoire)
J’espère que cet article donnera des pistes à ceux qui voudrons tester des capteurs physiques Je joins le code complet du programme de test, code utilisable librement.
Il reste beaucoup à faire :
- Consolider le code, en particulier avoir une gestion des erreurs aussi exhaustive que possible avec un enregistrement dans un fichier de logs, implémenter le SPI
- Concevoir une carte d’acquisition avec ce capteur, un module GPS, un capteur de pression et une alimentation 12V (éventuellement au standard pHAT)
- Réaliser l’interface graphique
L’ULM de Thierry un projet déjà bien avancé !
Toute personne souhaitant participer au projet ou partager des résultats avec d’autres capteurs est bienvenue. Le tout sera publié sur OpenAvionics.
Rhââââ Delphi love love love (enfin jusqu’à Delphi 7, parce que les version venues après ….bof).
version »s »
ULM pas pour mi …
Côté gestionnaire SQLite je recommande SQLiteExpert, il existe en 2 versions, une « perso » totalement gratuite « limitée » (par exemple on ne peut pas scripter LUA/PascalScript) mais la version « Pro » a un type de licence particulier, elle est testable 30 jours puis au bout de 30 jours on peut soit l’acheter soit continuer à l’utiliser en mode gratuit pour usage non commercial.
http://www.sqliteexpert.com/features.html
Et sinon pour ceux qui veulent un « belle interface » (existe en version Windows mais aussi MacOS d’où le « beau ») il y a un autre « SQLiteManager » mais payant http://www.sqlabs.com/sqlitemanager4_features.php avec quelques fonctions sympathiques et originales, toutes les fonctions sont testables en version demo mais les requêtes seront limitées à 20 résultats.
L’originalité est qu’il est écrit en RealBasic un outil (payant) de développement multi-plateforme proche du renommé Xojo en 2013 qui a pas mal évolué depuis.
Mais si je parle de Xojo c’est surtout parce qu’il permet de créer des apps multiplateforme y compris Raspberry Pi 😉 maintenant le produit en lui-même je ne sais pas ce qu’il vaut ne l’ayant jamais testé.
Tout à fait d’accord avec toi sur Delphi et le reste.
Pour un cadre open source il me semble qu(il est indispensable d’avoir au moins une solution gratuite accessible à tous. C’est pourquoi je ne cite que des produits gratuits et je préfère wxMaxima à Mathematica, même en version limitée offerte sur RPi.
Exactement il faut privilégier l’Open Source et le gratuit (même si Open Source n’est pas forcément synonyme de gratuité).
Lazarus est un excellent exemple ! il faut juste régler 2 ou 3 options du compilateur si on ne veut pas qu’une simple fenêtre « hello world » ne génère un EXE de plusieurs mégas.
Bonjour,
Un beau projet et un autre langage de programmation (AMHA bien plus rigoureux que le C).
J’ai 1 interrogation « administrative » et 3 d’ordre technique (hard et soft).
Administrative : Peux-t-on monter ce que l’on veut sur un ULM, sans passer par une coûteuse certification ?
Technique 1: Un ULM est un environnement particulier, assez agressif (vibrations …). Comment va se comporter le pi, en particulier au niveau du connecteur de la carte SD ?
Technique 2: L’optimisation (cf. les récents articles sur blink et thread) est-elle prise en compte ? Par quels moyens (interruption ?).
Technique 3: La journalisation , pour un rejeu ultérieur de l’attitude de l’ULM, dans SQLite va générer de nombreuses écritures sur la carte et compromettre (rapidement?) son intégrité. Avez-vous envisagé de journaliser sur une clef USB (quitte à prévoir un verrouillage mécanique de celle-ci dont le connecteur n’est pas un modèle de fiabilité en présence de vibrations) ?.
En tout cas ça donne envie de construire un ULM rien que pour essayer ce module; Merci et bon vol.
Sylvain
Bonjour,
Merci pour ce retour.
Concernant l’aspect administratif, un ULM n’est pas certifié et son propriétaire fait ce qu’il veut… sous sa responsabilité. On trouve aussi des équipements non certifiés sur des avions qui le sont, dans la mesure où ils sont équipés du minimum d’instruments certifiés. Les équipement non certifiés sont dit de secours… C’est hypocrite mais tellement moins cher.
Pour les aspects techniques je n’ai pas toutes les réponses à ce jour. Quelques éléments :
L’environnement : le plus gros problème est la carte SD puisqu’il semble obligatoire que la phase de démarrage se fasse via la carte SD. Une solution à tester serait de fixer la carte comme on fixe des gros composants avec un pistolet à colle. Pour les capteurs ils seront sur une carte reliés à un Pi0 par soudures directes. Pour le système je ne sais pas encore. Je compte tester TinyCore mais peut-être faudra-t-il un vrai noyau temps réel.
Ce qui nous amène à l’optimisation. Le critère qui prime sur tout est la sécurité. La gestion temps réel peut amener de la sécurité en évitant des blocages mais peu aussi nuire par son complexité et l’impossibilité de tester tous les cas de figure. A réfléchir soigneusement. Sinon on peut très bien travailler avec des threads en pascal. Une fois la sécutité traitée on a effectivement intérêt à limiter la consommation. Enfin une bonne précaution est de s’assurer que la charge processeur est au maximum de 50%. Au delà c’est pour la beauté du geste mais je fais partie de cette génération qui n’aime pas gâcher.
Pour la journalisation effectivement je prévois une clé USB bloquée mécaniquement. D’après un spécialiste le connecteur USB n’est pas si mal, mais je n’ai pas d’expérience. J’ai rencontré quelqu’un qui transmet directement des données depuis son avion via un routeur wifi/4G.
Si tu as envie de construire un ULM fais-toi plaisir. Mais si c’est uniquement pour créer des instruments, il y a des tas de pilotes qui t’accueillerons les bras ouverts.
Claude.
Bonjour Claude
une info qui pourrait changer la donne pour le boot et la journalisation
Le Raspberry Pi 3 (et lui seul) peut démarrer sur une clé USB. C’est en cours de test et de développement mais c’est prometteur…
https://www.framboise314.fr/piwall-un-mur-dimages-avec-le-raspberry-pi/#comment-28821
Pour éviter les problèmes de vibrations on doit pouvoir souder la partie électronique de la clé directement sur le port USB. Un peu comme ici http://hackaday.com/2015/11/28/first-raspberry-pi-zero-hack-piggy-back-wifi/
mais en plus propre 🙂
Après il faudra voir la durée de vie d’une clé avec les écritures multiples…
bonne journée
amitiés
François
Bonjour François,
La logique pour un système embarqué serait de booter sur l’EEPROM de la carte (p)HAT.
A partir du moment où ce n’est pas figé dans le hard, si on peut booter sur une clé USB, cela devrait être possible.
Merci de me tenir au courant si tu as plus d’info.
Je me demande si tout cela ne pourrait pas se faire avec un simple ESP8266 et pour l’aspect base de données, le stockage se ferait simplement en CSV transmissible via le WIFi intégré de l’ESP soit en mode client soit en mode serveur.
Bonjour,
Merci pour cette réponse détaillée 😉
OK pour la partie administrative. Comme tu l’écris « c’est hypocrite mais tellement moins cher ». Tu remarqueras que c’est aussi vrai dans le domaine automobile. Un roulement SKF, tout ce qu’il y a de plus standard, coûte 5 fois plus cher dès qu’il est sous un blister estampillé Renault, Citroën ou autre marque 😉
Je ne pense pas nécessaire d’avoir recours à un vrai noyau temps réel. L’ULM n’est pas un missile de croisière et le pilote est un humain (le maillon faible).
Par contre, en première approche, je crois que je mettrais un Raspberry par appareil. De la sorte les contraintes d’optimisation seraient moins élevées et s’il plante, tu ne perdrais qu’un instrument.
Éventuellement, je mettrais une supervision en faisant activer un watch dog sur chaque appareil (une pin GPIO).
En tout cas c’est un bien beau projet, pluri-disciplinaire, apte à mobiliser une équipe soudée.
Bonne réalisation
Sylvain.
La carte SD n’est pas tant un problème que ça. Il y a juste quelques précautions à prendre quand on ‘embarque’. La première c’est l’alimentation. Attention par exemple à la chute de tension quand on actionne le démarreur. Je me suis fait piéger une fois pendant que le PI bootait et ça, ça ne pardonne pas … La seconde, c’est l’enregistrement des données. Il faut oublier l’écriture à la volée, ça ne marche pas ou alors pas longtemps et uniquement avec des fréquences d’acquisition très basse. J’ai essayé SQLite mais aussi MySQL et même avec de simple fichier mais toujours les mêmes problèmes d’assassinat de SD et des temps d’accès ‘lent, aléatoire et gourmand’ qui minaient ma fréquence d’acquisition (SD ou clé USB, le problème reste le même).
La solution la plus fiable que j’ai trouvé et que j’utilise, c’est de stoker mes datas dans un tableau et quand j’arrive à la limite de taille que j’ai définie, je transfert un clone de ce tableau à un thread d’enregistrement. Le thread d’enregistrement me fais l’append des données dans mon fichier et pendant ce temps mon thread d’acquisition continu son boulot en repartant sur mon tableau vidé (vous avez dit buffer ?, c’est exactement ça …).
Avec cette méthode, j’arrive à avoir des cycles d’acquisitions sur 24 IO spi (8 out, 8 in , 8 in adc) à plus de 200Hz sur un PI 0 avec seulement ~35% d’usage cpu (et moitié moins sur un PI3) en incluant bien sur le transfert temps réel des données en wifi (entre autre) et depuis, mes SD tiennent bon. Tout ça pour dire qu’un PI est très largement dans les cordes de votre projet, après, tout est question de code (je ne connais pas Lazarus, donc je ne m’avance pas la dessus) et SURTOUT de méthode 😉
Merci pour ces infos très intéressantes.
Je soupçonnait effectivement l’enregistrement d’être un goulet d(étranglement (actuellement environ 40Hz au lieu de 80) sans avoir eu le temps de tester.
Plop,
Puisque nous sommes sur le site d’un mécano aéro, je me permets ces remarques inutiles.
Un horizon artificiel sur un ULM !
L’horizon naturel ne serait-il pas suffisant ?
Ou bien ton ami Thierry prétend-il évoluer en IMC… en ULM. Il est fou (*)
Ah pardon, c’est juste pour le plaisir de le faire. Alors là, d’accord.
Un ULM avec glasscockpit… la grande classe !
__________________
(*) certes, mais un de ces merveilleux sur sa drôle de machine.
😉
Thierry est ex-pilote d’A380 et donc habitué au luxe !
Mais pourquoi pas puisque la technique et le coût des composants nous le permet.
Et oui c’est surtout pour le plaisir de le faire.
Un horizon artificiel est au contraire d’une très grande utilité pour connaître les angles d’inclinaison à ne pas dépasser en virage ! (surtout en approche, où la vitesse est réduite…)
Et sinon on a l’horizon du super pauvre avec une petite bouteille d’eau et un filet d’huile d’olive pour rendre l’horizon de l’eau visible 😉
@Claude : c’est la meilleure des raisons. Le bonheur n’est pas au bout du chemin, le bonheur est le chemin. Bon vol !
@TomDu69 : euh, je cumule modestement 300 hdv et je n’ai jamais jeté un seul regard à l’horizon artificiel. Le naturel me semble largement suffisant. Certes, je m’applique à toujours rester en VMC. Mais alors là, je conseille à tout pilote d’ULM, fusse-t-il qualifié A380, voire X-Wing Fighter, d’en faire autant !!!!!
@dodutils : LOL. J’en fais un pour mon prochain vol. J’attends de voir la tête du chef-pilote de l’aéroclub en voyant mon instrument. 😀
L’endroit n’est peut-être pas le meilleur pour débattre de l’utilité ou non de l’horizon artificiel, mais de ma formation PPL-A et de mes modeste 100 hdv je me rappelle très bien de l’enseignement de mon instructeur qui me répétait sans cesse de ne jamais dépasser telle ou telle inclinaison dans telle ou telle phase d’approche sous peine de décrochage dissymétrique et départ en vrille. Il appelait ça les inclinaisons opérationnelles :
– 1.2Vs –> 10° d’inclinaison max (19% de marge de sécurité)
– 1.3Vs –> 20° d’inclinaison max (25% de marge de sécurité)
– 1.45Vs –> 37° d’inclinaison max (30% de marge de sécurité)
A mon avis bien trop d’accidents ont été causés par une inclinaison trop importante à vitesse réduite (montée initiale et/ou approche) proche du sol …
Aprsès je veux bien croire qu’un oeil très entraîné arrive à se passer d’un h.a. mais perso j’y jette toujours un oeil quand je passe en base et en finale … 😉
Bonjour,
Faisant partie du FabLab de Vannes, un ami m’a demander si je pouvais fabriquer un horizon artificiel pour son avion (un Gaz’aile 2), je lui ai répondu oui ! Un Rpi0, un capteur compas, gyro et accélération et l’affaire est faite !!!
Grâce à ce superbe article je réalise que l’affaire est loin d’être faite, je suis certes bon en bidouille, soudure et que j’ai du bon matos au labo mais question programmation je découvre python et les lignes de code de Linux !
Bref, j’aimerais bien filer un coup de patte sur le projet horizon artificiel malgré mes faibles connaissances en programmation.
Halala ce genre d’article me fait pétiller les yeux !
A plus
Bonjour,
Je te propose de me contacter par mail perso pour échanger sur les détails. et voir comment on peut avancer ensemble.
A plus.
Okay cool !
N’ayant pas accès à ton mail je t’ai transmis le mien via sourceforge.
Au plaisir !
Je re-post ici
Je n’ai pas eu de mail via sourceforge.
Mon mail perso c’est cl.guth chez free.fr
Bravo pour le site http://makerspace56.org/ (avec une carte RPi ?)
Je n’ai pas eu de mail via sourceforge.
Mon mail perso c’est cl.guth chez free.fr
Bravo pour le site http://makerspace56.org/ (avec une carte RPi ?)
Bonjour Denis,
Je suis preneur de toute méthode simple et fiable de calibration. Je ne connais pas les différents de Levenberg.
Le but est d’obtenir le meilleur résultat dans toutes les positions. La documentation du capteur parle de la correction d’offset mais pas des facteurs d’échelle. On peut, pour aller plus loin, imaginer des corrections en x², xy, etc… reste à savoir si c’est nécessaire voire productif.
J’ai poursuivi mes essais et j’ai obtenu des résultats corrects sur la calibration en accélération en procédant de la manière suivante :
– j’oriente le capteur de façon à minimiser l’accélération sur 2 axes et avoir un maximum sur le 3ème
– je fais une série de 1000 mesures
– idem inversé
– idem sur chaque axes
– Avec les valeurs moyennes je pose les 3 équations d’égalité des modules sur chaque axes avec les 3 offsets en variables
– En reportant les offsets je peux calculer les facteurs d’échelle.
Avec les corrections j’obtiens un module correct dans toutes les positions.
Attention : pour les mesures il faut que le capteur soit bien calé et stable. Un mouvement de la main même très lent se voit sur la mesure.
Pour info voici les valeurs que je trouve (échelle 4G, offsets sur valeur brute), valable uniquement pour mon capteur :
ox= 263
oy= 138
oz= 541
kx= 0.99962144
ky= 0.99980005
kz= 0.99477046
Je suis tout à fait près à travailler sur d’autres méthodes et je peux te fournir des jeux de mesures si besoin. Mais ma priorité est de calibrer le magnéto puis de caractériser l’écart type sur les mesure, en labo et dans un environnement avion.
En te remerciant pour ton apport.
Bonjour Denis,
C’est une très bonne idée.
Je vais essayer de mettre prochainement un jeu de données en sqlite et excel sur le site OpenAvionics, ainsi que mes méthodes et résultats de calibration et les calculs d’écarts types.
Je devrais aussi recevoir incessamment un capteur de pression LPS22HB pour lequel je publierai également les données.
Bonjour Denis,
Merci, avec retard, pour ces très nombreuses références que je n’ai pas encore eu le temps d’exploiter.
Je découvre R, qui est directement interfaçable avec SQLite.
Pour le moment je fais des tests avec un capteur de pression.