Publié le 6 août 2016 - par

Evaluation du LSM9DS1, un capteur 9 degrés de liberté

LSM9DS1_250pxJ’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 :

Un horizon artificiel à base de Raspberry Pi

 

VMS_Artificial_Horizon

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.

lsm9ds1_axesC’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

module sparkfunCe 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.

LSM9DS1_2

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.

ConfigPi

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);
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.

Le module d’enregistrement sqlite

sqlite370_bannerCela 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é.

 

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).

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.

testduLSM9DS1

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  :

calibration

  • 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).

equations

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
ulm

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.

Sources

Share Button

31 réflexions au sujet de « Evaluation du LSM9DS1, un capteur 9 degrés de liberté »

  1. Dodutils

    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é.

    Répondre
    1. Claude GUTH Auteur de l’article

      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.

      Répondre
      1. Dodutils

        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.

        Répondre
  2. S.POURRE

    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

    Répondre
    1. Claude GUTH Auteur de l’article

      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.

      Répondre
      1. François MOCQ

        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…
        http://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

        Répondre
        1. Claude GUTH Auteur de l’article

          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.

          Répondre
          1. Dodutils

            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.

  3. S.POURRE

    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.

    Répondre
  4. Bud 'Robert' Spencer

    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 😉

    Répondre
    1. Claude GUTH

      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.

      Répondre
  5. zeb

    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.
    😉

    Répondre
    1. Claude GUTH

      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.

      Répondre
    2. TomDu69

      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…)

      Répondre
  6. zeb

    @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. 😀

    Répondre
    1. TomDu69

      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 … 😉

      Répondre
  7. Paolo

    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

    Répondre
    1. Claude GUTH

      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.

      Répondre
  8. Denis Brion

    Il y a quelque chose qui me chagrine:
    vous estimes 3 offsets et 3 facteurs d’echelle avec un système de 6 équations à 6 inconnues , déduites, si j’ai bien compris, de rotations de capteurs. Mais il y a peut être plus de 6 positions utilisbles des capteurs (ex : 3 axes orientés vers le haut, puis vers le bas ->6 un des deux axes restant est orienté vers l’Est, puis vers l’Ouest -> 2*x; j’ai trouvé 24 possibilités recouvrant les côtes d’un cube, en ne connaissant que les angles droits; le monde physique est peut être encore plus continu) Le système d’équation serait alors surdeterminé, mais permet de s’affranchir de bruit (main qui tremble, parasitage electrique/magnétique, revendications du constructeur le cas échéant) si on estime au sens des moindres carrés (pour des accéléromètres, minimiser :
    somme (((mx*gx+ox) ¨2 + (mx*gy+oy) **2 + (mx*gz+oz) **2) – 9.81**2)*2)

    Cette minimisation %mx, my,mz et ox, oy, oz peut être confiée à un algorithme d’optimisation (j’ai été très satisfait , pour des problèmes différents de Levenberg Marqurd sous python/scipy et R, et il est porté un peu partout -gnuplot, octave : – tous ces logiciels fonctionnent à leur rythme sur RPi- https://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm#Implementations)

    L’avantage que je vois est double :

    a) on peut être rassuré par rapport à une solution exacte et
    (b) on peut exploiter l’ensemble de ses points (vous évoquez un stockage de 1000 points; tirer 6 points pour avoir une solution exacte en omet beaucoup)

    L’inconvénient est que ces algorithmes sont plus lents, sans que le temps de convergence (si on ne limite pas le nombre d’itéartions- soit garanti -les disqualifiant bien évidemment pour du temps réel (même si on peut s’arranger, en partant d’une valeur pas trop absurde, pour qu’il n’y ait que 10 ou 20 itérations) – qu’un calcul exact, et que l’on doit investir du temps dans de l’apprentissage nouveaux logiciels

    J’espère que vous n’avez pas sciemment omis de présenter cette solution classique au sens des moindres carrés (dans un souci louable de clarté ou parce qu’elle vous a déçu après essais)

    Répondre
    1. Claude GUTH

      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.

      Répondre
  9. Denis Brion

    Merci pour les chiffres : il semblerait que ST livre des accéléromètres pré étalonnés, et que les voies horizontales (qui servent à se promener sur terre) soient presque parfaites – à 4 pour 10000 près, ce qui est inférieur IIRC à la variabilité entre les pôles et l’equateur liée à la force centrifuge….)
    Ceci semble cohérent avec les essais que j’ai fait de calcul d’erreur quadratique moyenne sur Arduino (et un autre capteur) : l’eqm (approximée par la racine carrée de moité de la moyenne des carrés des différences entre deux mesures successives, ce qui permet de ne pas trop risquer de débordements même avec des processeurs très réduits) etait toujours plus grande sur l’accéléromètre vertical. J’étais comme vous (peut être même plus) géné par les hésitations de la main . Naturellement, généraliser une opinion à partir d’un ou deux cas particuliers est un peu hâtif.

    L’idée de mettre à la disposition de tout le monde (et pas seulement de moi, qui aurai une charge de travail considérable d’ici octobre, rendant des interprétations utilisables aléatoires) est une bonne idée; peut être devriez vous enregistrer aussi (si vous n’y avez pas pensé) les températures…. (les accéléromètres, selon la doc, ont une sensibilité faible à ce paramètre; la doc ne spécifie pas ce qu’il en est des axes magnétiques). Par contre, les modalités sont compliquées (on ne peut pas remplir les cases commentaires avec 1000 lignes de *.csv/*json (R, python et plein d’autres logiciels lisent ces formats très bien), ce qui pourrait sembler ennuyeux.

    Pour les axes magnétiques, j’ai cru comprendre que les téléphones sophistiqués -qui ont une boussole- font un « étalonnage » assez semblable au vôtre (qui est recommandé par le constructeur ) , par recherche du max et du min sur un axe horizontal (le téléphone est tourné à la main). Je n’ai pas vu de choses choquantes par rapport à l’orientation d’une rue et à un pointage manuel (mais les compas de marine, où les utilisateurs sont plus exigeants que moi, sont compensés pour que les bouts de ferraille qui remplissent un bateau ne faussent pas la direction…. ce qu’aucun constructeur electronique ne peut faire)

    Répondre
    1. Claude GUTH

      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.

      Répondre
  10. Denis Brion

    Bonjour Claude,
    Ceci serait très bien si vous arriviez à mettre en ligne un jeu de données sur Openavionics (je suppose que c’est le site que vous liez dans votre article). Il y a quelques petites remarques qui peuvent simplifier la vie :
    des exports excel (séparés par des « ; » si vous utilisez des notations décimales françaises) se lisent très bien avec R (l’interface excel natif/R est difficile à mettre en oeuvre : à chaque fois, ça me prend une heure sous GNUlinux) , et très vraisemblablement avec python (une adaptation simple du script python dans http://www.varesano.net/blog/fabio/ellipsoid-sphere-optimization-using-numpy-and-linalg -consistant à donner comme argument à split ‘;’ /’,’ au lieu de l’option par defaut devrait suffire).
    la sensibilité à la température des capteurs est analysée dans http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4187052/ -même si des accéléromètres mis dans une montre de poignet sont moins susceptibles d’être soumis à des changements de température, ils pouvaient le detecter- et dans http://www.vectornav.com/support/library/calibration
    Il semblerait que les magnetomètres soient beaucoup plus sensibles à la température que les accéléromètres (du moins sur des technologies assez anciennes) pouvant introduire une erreur de tangage/roulis de 4 degres (si la tempéraure varie entre 0 et 40 C, gamme « raisonnable » pour un ULM) selon vectornav…
    La grande variété d’utilsation (detecter si quelqu’un (vache, puma, être humain) est immobile; combler les trous du GPS pour les voitures; avionique) fait que beaucoup de gens ont développé des algorithmes de calibration, les plus rapisdes possibles (parfois profitant des moments d’immobilité et faisant l’hypothèse que la gravité/le champ magnétique terrestre sont de norme constante et connue pour un point donné, ce quelle que soit l’orientation : une vache somnolente n’essaye pas d’optimiser les conditions d’étalonnage….) : Bonnet, Bassompierre et al. www-ist.cea.fr/publicea/exl-doc/200900000986.pdf « Calibration methods for inertial and magnetic sensors « en ont comparé quelques unes et ont trouvé que l’algorithme de Merayo résistait bien à des petites erreurs (il est itératif, et a priori non adapté à du temps réel). A noter que cet algorithme est disponible, sous une forme non iterative , pour R, dans http://rpackages.ianhowson.com/cran/RAHRS/man/svd.calibration.html qui lie à l’original sous matlab/octave … (il recherche 9 coefficients, dont 3 découlent d’une non orthogonalité, 3 autres sont un facteur d’échelle et le reste des offsets : cette non orthogonalité des axes est considérée comme ayant des effets négligeables, me semble-t-il, pour des capteurs modernes)
    PS : j’espère que je n’ai pas fait apparaître une préférence pour R -dont j’ai l’habitude- : python+numpy et octave (clone de matlab) sont vraisemblablement plus populaires et les développeurs de bibliothèques dans l’un de ces trois langages de scripting se tiennent au courant de ce qui se fait de « mieux » ailleurs….

    Répondre
    1. Claude GUTH

      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.

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Complétez ce captcha SVP * Time limit is exhausted. Please reload CAPTCHA.