Puissance de l'arduino Uno

mpu6050 kalman filter arduino drone sur google ça te donne quoi?

Pour commander mon drone, j'utilise un MPU6050 avec son DMP (Digital Motion Processor) ; il y a une bibliothèque pour ça.

Je ne sais pas si ce DMP est similaire à un filtre de Kalman qui prend en compte les erreurs de son gyro (3 axes) et de son accéléro (3 axes) ou un filtre d'un autre genre. Le tout est que :

  • Après une phase de calibration, on récupère les biais gyro (dérive) et accéléro (décalage) et on les injecte dans le programme
  • Les calculs sont faits dans le MPU6050 : donc rien à programmer,
  • Les données qui en ressortent (yaw, pitch et roll) sont d'une propreté époustouflante. Je me sers de ces données pour contrôler les axes de mon drone via des PD (I pas franchement nécessaire).

NOTA : peut-être un coup de chance : après avoir calibrer mon MPU6050, je le laisse immobile sur ma table et je relève la dérive angulaire en cap. Quelle n'a pas été ma surprise de constater que cette dérive correspondait à la rotation de la terre (15 °/h) 8) . C'est-à-dire que mon MPU6050 n'avait pratiquement pas de dérive propre. Ça doit quand même être un coup de chance.

Cordialement.

Pierre

Je me demande quand même si, dans le cas du drone, l'expérimentation et l'usage pratique n'a pas permis de simplifier au maximum les calculs.

Par exemple en remplaçant tout une flopée de calculs pointus et très abstraits (j'ai vu passer dans les posts précédents du calcul formel, de la mécanique analytique de haut vol avec des Lagrangiens etc ...) par des algorithmes bien plus simples et nettement moins gourmands en "ressources machine" mais presque aussi efficaces.... pour une situation donnée bien précise.

Pour prendre un exemple perso beaucoup plus simple, mais dans le même esprit, j'utilise pratiquement systématiquement des CTN pour mes mesures de températures.

La caractéristique résistance tension d'une CTN n'est pas linéaire, c'est un bout d'exponentielle et on pourrait déduire la température avec le calcul correspondant. Par bonheur la courbure de la courbe R = f(T) ou T est la température peut-être en partie compensée par la courbure inverse de la courbe V= f(R) quand on met la CTN dans un diviseur de tension .... En partie mais pas complètement.

Alors pour mes bricoles, je dis que l'ensemble est linéaire, mais par morceaux et il me suffit de couper l'intervalle en deux morceaux pour que cela colle à peu près. (Concrètement je divise l'intervalle 0-25°C en deux intervalles 0-15°C et 15°C-25°C)

Serge .D

Bon, c'est une réflexion perso, je suis peut-être complètement à coté de la plaque)

Bonjour Serge, Je ne pense pas que tu sois à coté de la plaque. J'ai aussi utilisé des thermistances "linéarisées". Certes il est impossible d'avoir une précision au 1/10 ème de degré mais avec un réseau "résistance série et parrallèle" et un tableur il est possible d'obtenir une courbe qui ondule autour d'une droite et pour bien des applications de compensation en tempéraure c'est amplement suffisant.

En électronique sans calculateur la linéarisation par morceau est très utilisée et cela fonctionne. La présence d'un micro fait oublier "les choses simples".

aligote: Bon, c'est une réflexion perso, je suis peut-être complètement à coté de la plaque)

Tu n'es pas à côté de la plaque: on a fait voler des trucs avec des asservissements implantés dans des calculateurs moins puissants qu'un ATmega328, sans parler de l'époque où les calculateurs étaient analogiques.

Les méthodes classiques utilisent donc très largement les simplifications par linéarisation.

3Sigma: Tu n'es pas à côté de la plaque: on a fait voler des trucs avec des asservissements implantés dans des calculateurs moins puissants qu'un ATmega328, sans parler de l'époque où les calculateurs étaient analogiques.

Les méthodes classiques utilisent donc très largement les simplifications par linéarisation.

C'est bien ce que je pensais :

Pour une régulation (de type PID ou non) il est préférable d'avoir une correction (en Electronique on dit contre-réaction) rapide même moyennement précise plutôt que très précise mais lente, donc avec retard donc trop tard.

Serge .D

aligote:
… Pour une régulation (de type PID ou non) il est préférable d’avoir une correction (en Electronique on dit contre-réaction) rapide même moyennement précise plutôt que très précise mais lente, donc avec retard donc trop tard. …

Dans les asservissements, temps de réponse et précision ne sont pas antinomiques, au contraire.

Par ailleurs, il faut s’entendre sur ce qu’est la précision : elle a deux aspects :

  • dynamique : c’est l’erreur de suivi, elle est liée au gain proportionnel. Plus le gain est élevé, plus cette erreur est minime,
  • statique : c’est l’erreur obtenue alors que plus rien n’évolue. En général, un contrôle intégral annule cette erreur.

Pour ce qui est de la rapidité de réponse, celle-ci est aussi liée au gain : plus le gain est élevé, plus le temps de réponse est court.

Mais tout ceci a un revers : la stabilité. Celle-ci se met à décroître dès lors que le gain dépasse un certaine valeur. Il en va de même si le contrôle intégral est trop fort.

On retrouve une certaine stabilité en ajoutant un contrôle dérivé qui, par la même occasion procure un léger gain de temps de réaction.

Ce qu’il faut retenir : pour un système donné, il y a un optimum a atteindre et un seul qui est un compromis obtenu par les réglages P, I et D. A cet optimum, la rapidité et les précisions (dynamiques et statiques) sont les plus grandes que l’on puisse obtenir.

On peut faire mieux (pas beaucoup) et c’est rapidement au détriment de la stabilité.

Un petit exemple sur un asservissement de vitesse (ceux qu’on règlent dans un premier temps sur un drone).

  • Les courbes Asst_Vit_01 montrent l’évolution de l’erreur finale lorsqu’on augmente la gain : celle-ci se réduit, mais la stabilité se dégrade (sur-oscillations)
  • Dans les courbes Asst_Vit02, j’ai simplement rajouté un contrôle intégral. On voit que l’erreur final tend vers zéro
  • Dans les courbes Asst_Vit_03 j’ai rajouté un contrôle dérivé qui redonne de la stabilité à l’ensemble.

Dans chacun de ces jeux de courbes, on voit que le temps minimum de réponse (premier passage du signal au niveau 1) est de l’ordre de 0.15 s et est obtenu pour un gain élevé et donc pour une bonne précision.

Cordialement.

Pierre

ChPr:

Dans les asservissements, temps de réponse et précision ne sont pas antinomiques, au contraire.

Désolé, on ne s’est pas bien compris, je ne pensais pas à cela, je voulais dire qu’appliquer une correction un peu approximative mais calculée rapidement pouvait être préférable à prendre beaucoup de temps pour calculer une correction précise mais obsolète.

Serge .D

Je ne comprends pas en quoi une correction serait obsolète ? Obsolète par rapport à quoi ? Cordialement.

Pierre.

ChPr: Je ne comprends pas en quoi une correction serait obsolète ? Obsolète par rapport à quoi ? .........

Si la mesure très rapide de position amène a une correction après un temps de calcul trop long, la correction déduite serait obsolète. ( au moment ou sort le résultat du calcul, la position n'est déjà plus la même)

Serge .D

Dans quelle situation vous placez-vous ? Je suppose que vous parlez de la mise au point en temps réel d'un drone.

Moi, je parle d'optimisation d'un système, assis tranquillement derrière mon bureau avec un logiciel de simulation.

Cordialement.

Pierre.

ChPr: Dans quelle situation vous placez-vous ? Je suppose que vous parlez de la mise au point en temps réel d'un drone.

Moi, je parle d'optimisation d'un système, assis tranquillement derrière mon bureau avec un logiciel de simulation.

Cordialement.

Pierre.

Il ne nous reste plus qu'a rassembler nos infos devant une bière au bar !

Serge .D

Généralement quand on est nul on cherche la solution la plus simple (en tout cas pour moi-même).

Le BNO 055 embarque une IMU et un ARM qui s'occupe d’exécuter un filtre de kalman, l'utilisateur à juste besoin de récupérer les données en angle d'euler ou quartenions.

Que demande le peuple ?

Le MPU6050 aussi, mais ça reste un Kalman de fusion de données avec hypothèse d'accélération nulle.

-Standby: ... Le BNO 055 embarque une IMU et un ARM qui s'occupe d’exécuter un filtre de kalman, l'utilisateur à juste besoin de récupérer les données en angle d'euler ou quartenions.

Que demande le peuple ?

Le MPU 9250 fait la même chose. En produit fini sur PCB, il apparaît un peu moins cher. Consultant les caractéristiques, le BNO 055 semble un peu meilleur.

Cordialement.

Pierre

3Sigma: Le MPU6050 aussi, mais ça reste un Kalman de fusion de données avec hypothèse d'accélération nulle.

Comme vous me l'aviez fait remarquer il y a quelques temps, j’utilisais improprement le terme de Kalman pour le MPU5060 (idem MPU9250).

En ce qui concerne le BNO 055, je ne vois pas non plus ce terme dans sa description, il est indiqué :

"By integrating sensors and sensor fusion in a single device, the BNO055 eases the integration process for customers".

A titre de curiosité, sur quelle documentation vous basez-vous pour dire que pour le MPU6050, les hypothèses sont d'accélération nulle ?

Cordialement.

Pierre

Quand je dis "accélération nulle", je veux dire que l'hypothèse est que le mobile qui porte l'IMU ne subit pas d'accélération externe. Je ne me base sur aucune documentation mais sur la logique: comme, pour réaliser ces calculs d'orientation, l'IMU ne connaît pas l'accélération externe que pourrait subir le mobile, le plus logique est de considérer qu'elle est nulle.

Quelqu'un va forcément répondre que l'accéléro mesure les accélérations, mais dans le contexte de ce "Kalman", l'objectif est d'obtenir des mesures d'orientations mieux filtrées que les mesures brutes. Pour ça, on utilise le calcul d'orientation réalisé avec l'accéléromètre et on fusionne avec les mesures de vitesse angulaire du gyro. Mais pour que les orientations estimées par l'accéléro soient correctes, il ne faut pas qu'il y ait d'accélération longitudinale externe (provoquée par les moteurs), sinon on est strictement incapable de savoir si l'accélération mesurée par l'accéléro provient d'un changement d'orientation ou provient de la poussée d'un moteur.

La fusion de capteur accéléro / gyro fait donc nécessairement l'hypothèse qu'il n'y a pas d'accélération externe car s'il y a des processeurs intégrées dans les IMU, il n'y a pas encore de boule de cristal. Ensuite, celui qui utilise une IMU peut très bien réaliser un vrai Kalman, qui, à partir d'un modèle dynamique du mobile, sera capable de faire la différence entre l'accélération due à l'orientation et l'accélération due à la poussée des moteurs. Et on aura dans ce cas une estimation de l'orientation qui sera correcte, même dans les phases où le mobile subit une accélération externe.

Mais bon, tout ça conduit sans doute à s'arracher les cheveux un peu pour rien. Avec un vrai Kalman les choses sont meilleures, mais est-ce bien indispensable ? Ce qui est fait sur les drones montre que non, ce n'est pas indispensable, a priori, dans le cas général. C'est pour ça qu'une bonne solution peut être de démarrer avec des choses simples (les sorties précalculées de ces IMU modernes, par exemple) et de passer à des choses plus performantes mais plus compliquées si nécessaire.

Merci 3Sigma pour ces explications claires.

Dans mon drone, j'utilise les informations fusionnées d'un MPU6050.

3Sigma: ... dans les IMU, il n'y a pas encore de boule de cristal. ...

Mais un calcul peut montrer qu'une accélération externe a été subie car dès lors son module a changé. Peut-être que lanalyse de chacune des composantes permet-elle d'estimer le vecteur d'accélération externe ? Ce ne sont là que quelques divagations ;)

Cordialement.

Pierre

ChPr: Mais un calcul peut montrer qu'une accélération externe a été subie car dès lors son module a changé. Peut-être que l'analyse de chacune des composantes permet-elle d'estimer le vecteur d'accélération externe ? Ce ne sont là que quelques divagations ;)

C'est faisable en théorie si les mesures ne sont pas bruitées.

Comme vous me l'aviez fait remarquer il y a quelques temps, j'utilisais improprement le terme de Kalman pour le MPU5060 (idem MPU9250).

En ce qui concerne le BNO 055, je ne vois pas non plus ce terme dans sa description, il est indiqué :

Il faut justement regarder ce qu'il y a derrière le terme "sensor fusion".

FusionLib provides orientation information in form of quaternion or Euler angles. The algorithm fuses the sensor raw data from 3-axis accelerometer, 3-axis geomagnetic sensor and 3-axis gyroscope in an intelligent way to improve each sensors output. This includes algorithms for offset calibration of each sensor, monitoring of the calibration status and kalman filter fusion to provide distortion-free and refined orientation vectors. Since Bosch Sensortec 9-axis fusion software is developed together with the sensor hardware, optimized performance in terms of dynamics and immunity to distortion effects is achieved. Direct access to the Bosch sensor hardware allows the user to set use-case specific operation modes regarding data rates and noise thresholds. The solution provides a ready-to-use advanced 9-axis sensor fusion system which reduces the complexity for customers and helps in rapid development of advanced sensor applications.

https://www.bosch-sensortec.com/bst/products/motion/fusionlibsoftware/overview_fusionlibsoftware