26 réponses à ce sujet

[Black Templar]

Bonjour à tous !!



J'ai commencé à bosser sur un projet que j'ai en tête depuis longtemps : la création d'une centrale inertielle !



Mes motivations :

A la base, je voulais développer un petit drone quadrimoteur qui se stabilise tout seul afin de tester quelques algorithmes d'intelligence artificielle. Tout ceci n'est réalisable que si je possède une centrale inertielle efficace qui puisse me fournir précisément l'angle, la vitesse angulaire, l'accélération, la vitesse, voir la position du drone. Donc, après avoir réfléchi au problème global sur papier (dimensionnement des moteurs, hélices, architecture électronique de puissance, de commande, asservissement etc.), je me suis penché plus en détail sur le problème de la centrale inertielle pour découvrir que ce n'est pas un problème si simple que ça, finalement.



Du coup, plutôt que de faire un drone directement, j'ai envie de créer mon module inertiel qui pourra être adapté en temps voulu sur un engin volant.



Les problématiques :

Une centrale inertielle précise, ce n'est pas si simple. Pourquoi ??

Tout d'abord, voici les capteurs permettant de réaliser une centrale inertielle :



Les accéléromètres :

Ces capteurs permettent de détecter une accélération. Jusque là, pas de problème, sauf si on considère que la gravitation terrestre est elle-même une accélération !! Du coup, le vecteur accélération détecté par l'accéléromètre est en réalité la somme du vecteur accélération de la centrale et de la gravitation terrestre.

Lorsque la centrale n'accélère pas, on peut donc en déduire l'angle d'inclinaison de la centrale en prenant en compte la gravitation. Si la centrale accélère, alors on ne peut rien en déduire (on a trop de degré de liberté)... Pas très pratique.



Les gyroscopes :

Ces capteurs permettent de détecter une vitesse angulaire, c'est-à-dire, une variation d'angle. Pour obtenir l'angle, il suffit de sommer toutes les petites variations d'angle. Le problème, c'est que l'angle obtenu dérive dans le temps du fait de lorsque l'on somme les variations d'angle, on somme aussi les petites erreurs qui finissent par devenir une grosse erreur au fur et à mesure.

De plus, le gyroscope est un capteur qui possède un défaut de taille : il dérive. C'est-à-dire que lorsqu'on laisse la centrale au repos, la valeur 0 du gyroscope change doucement avec le temps. Ce qui fait que l'on pense que la centrale bouge alors qu'en réalité, ce n'est pas le cas... Pas très pratique.



Les magnétomètres :

Je n'ai pas encore bien creusé les problèmes de ces capteurs. Je sais juste pour le moment qu'ils détectent le champ magnétique terrestre et donc permet d'indiquer le nord. Sauf qu'ils ne sont pas très précis et qu'ils sont très sensibles aux perturbations électromagnétiques... pas très pratique (surtout quand on a une alim à découpage dans les parages :/)



Le GPS :

Ce capteur fourni la position de la centrale, mais elle est dépendante des satellites lancés par les humains et ne fonctionne pas en intérieur... pas très pratique.



Voilà donc un aperçu des faiblesses de chaque capteur et donc de la difficulté à designer une centrale inertielle robuste.



Le cahier des charges

Pas grand-chose de ce côté là, à part que j'aimerais avoir un module indépendant adaptable à toute base robotique, avec une interface I2C qui permet de renvoyer les valeurs de l'accélération, la vitesse, la vitesse angulaire et l'angle d'inclinaison de la centrale (voir la position) avec une précision non encore défini.

Le traitement des données se fera dans le module lui-même sur micro-contrôleur afin que les données renvoyées soient directement exploitable.

Enfin, le module devra respecter les contraintes de l’embarqué : faible taille, faible consommation etc.



Les premières étapes

Pour le moment, je vais me préoccuper uniquement d'estimer l'accélération, la vitesse angulaire et l'angle de la centrale à l'aide d'un accéléromètre trois axes et de deux gyroscope deux axes.

J'ai reçu la semaine dernière ces trois capteurs (ADXL335, LPR530AL et LPY530AL) ainsi qu'une platine arduino (depuis le temps que je dois en commander une -_-)

J'utilise pour l'acquisition et le traitement des données, un PIC33F 128GP802 de microchip.



Pour le moment, j'ai branché l'accéléromètre au PIC et je récupère les informations via le convertisseur analogique numérique (12bits à 3.3V). J'ai codé l'arduino pour qu'elle récupère les données du PIC via l'I2C et qu'elle les envoie sur le PC en RS232. Ce qui me manque donc, c'est de coder sur le PIC la routine d’envoi des données en I2C ! (c'est le genre de truc pour lequel je sais que je vais galéré ^^)



Une fois les communications opérationnelles, je ferais donc l'acquisition des données capteurs pour caractériser les différents bruits et dérives et les comparés aux données des datasheets.



Les algorithmes de traitement et de fusion de données

Pour le moment, pour traiter, fusionner les données et estimer les paramètres de mon système (accélération, vitesse angulaire et angle), je compte utiliser un filtre de Kalman étendu ainsi qu'un filtre complémentaire afin de tester les performances de chacun et voir s'il n'y a pas moyen de coupler les algorithmes.



Applications potentielles

Comme je l'ai dit plus haut, j'aimerais bien réaliser un drone quadrimoteur utilisant la centrale inertielle. Mais j'ai aussi d'autres idées plus "simple" à réaliser comme un robot pendule inversé (pas forcement plus simple en fait, mais moins contraignant qu'un drone : si le robot tombe, je peux toujours le relever ! un drone, non XD)



Avancement du projet

Je n'ai aucune idée de combien de temps ça va me prendre. Tout dépend de ma motivation, de mon temps libre et de plein d'autres facteurs. Mais vous pouvez suivre l'évolution du projet soit sur ce post, soit sur mon blog, dans la rubrique "dossier" : http://www.ferdinandpiette.com/blog/les-dossiers/dossier-ma-centrale-inertielle/



Voila !

A bientôt !

Black Templar

[Jbot]

Salut,

En voila un beau projet ^^

Par contre je ne suis pas sur qu'avec juste tes 5axes, tu pourras déterminer l'angle x,y,z du robot, je pense qu'il manque des axes.

[robocop]

Très intéressant comme projet, coupler les données de manière cohérente semble en effet difficile ! Comment comptes-tu t'y prendre ?
Les problèmes d'intégration sont en effet compliqués...Tu peux peut-être te recaler avec un capteur de pression (puisque tu cherches à faire un objet volant) ?

[Black Templar]

[quote"Jbot"]Par contre je ne suis pas sur qu'avec juste tes 5axes, tu pourras déterminer l'angle x,y,z du robot, je pense qu'il manque des axes.[/quote]

Salut ! Pour le moment, j'ai 6 axes dont un axe redondant ! (3 axes pour l'accéléro 3D et 4 axes avec les 2 gyros 2D (donc un axe redondant))
Je pourrais en effet déterminer l'angle x et y en couplant les mesures de l'accéléromètre et des gyroscope. Pour l'angle z, ça me semble un peu plus compliqué, mais j'y réfléchit ! (à mon avis, un magnétomètre semble nécessaire pour cet axe)

[quote"robocop "]Très intéressant comme projet, coupler les données de manière cohérente semble en effet difficile ! Comment comptes-tu t'y prendre ?[/quote]
Comme je l'ai dis dans la présentation, je compte utiliser un filtre de Kalman étendu surement couplé à un filtre passe haut <1Hz sur le gyroscope pour supprimer la dérive de celui-ci.
J'ai déjà essayé de modéliser un filtre de Kalman étendu en essayant d'estimer la vitesse angulaire, l'angle, l'accélération et le biais du gyroscope, avec les données des accéléromètre et des gyroscopes pour un axe (x ou y seulement). Je me suis rendu compte que je n'ai pas assez d'information ! C'est comme si j'essayais de résoudre 2 équations à 3 inconnues... :/
Du coup, il faut que j'acquiert plus d'information soit sur l'accélération, ce qui me semble difficile, soit sur le biais. J'ai peut être une chance de m'en sortir si celui-ci évolue très lentement. Ou alors, méthode plus radicale : je le supprime en appliquant un filtre passe haut sur le gyroscope, mais si je fais ça, je vais avoir un autre petit problème : lorsque la centrale va avoir un mouvement de rotation constant pendant quelques seconde, à cause du filtre passe haut, je ne vais pas détecter cette rotation... et ça, ça peut être un problème pour détecter précisément la position de la centrale par la suite.

Ensuite, je vais me pencher sur le filtre complémentaire qui apparemment offre de bonne performance et est un très bon compromis difficulté de mise en place/performance par rapport au filtre de Kalman.

[quote"robocop "]Les problèmes d'intégration sont en effet compliqués...Tu peux peut-être te recaler avec un capteur de pression (puisque tu cherches à faire un objet volant) ?[/quote]
Un capteur de pression ?? pour quoi faire ? estimer l'altitude ??

[Astondb8-RX]

Pour un premier projet, c'est un sacré projet...
Super,
En fait je sais pour quoi mon 1er projet est un Robot à deux roues, parce que je ne serais pas capable de faire un projet comme celui-ci.

Mais je vais le suivre de près et tâcher de comprendre.

Alors Merci Black Templar, donne nous des infos au fur et à mesure de l'avancement de ce projet.

Cdlt
Tves

[robocop]

[quote"robocop "]Les problèmes d'intégration sont en effet compliqués...Tu peux peut-être te recaler avec un capteur de pression (puisque tu cherches à faire un objet volant) ?[/quote]
Un capteur de pression ?? pour quoi faire ? estimer l'altitude ??[/quote]

Oui, tu pourrais ensuite dériver l’altitude et tu aurais la vitesse selon l'axe des z. Je ne sais pas si ça marche bien en pratique...

Sinon je me renseignerais à l’occasion sur ce filtre de Kalman étendu ça à l'air amusant (en plus y'a pleins de calculs matriciels...)

[Black Templar]

[quote"robocop"]Sinon je me renseignerais à l’occasion sur ce filtre de Kalman étendu ça à l'air amusant (en plus y'a pleins de calculs matriciels...)[/quote]
Hihi ! et un converti de plus ? XD

Sinon, j'ai programmé un PIC33F pour récupérer les valeurs de l'accéléromètre et pour les envoyées à l'arduino via l'I2C. L'arduino récupère les données et les envoies sur le PC.
Sauf que ça ne marche pas et je viens de comprendre pourquoi : l'I2C du PIC est en 3.3V alors que l'arduino est en 5V :/:/

Du coup, je vais devoir convertir les signaux 5 en 3.3V et inversement... (page 10 : http://ics.nxp.com/support/documents/interface/pdf/an97055.pdf )
Il faut que je me commande des MOS-FET car je n'en ai pas sous la main :'( :'(

Je savais que j'allais avoir des problèmes avec l'I2C :D

EDIT : Voila ce qu'il me faut !! ... Mais bon, faire une commande pour 1€ de composant, c'est pas top ... ^^
http://www.sparkfun.com/products/8745

[Leon]

Interpréter des accéléromètres, gyroscopes, et magnétomètre 3D, c'est un truc que j'ai fait pour mon BOB4. Regarde le long sujet sur BOB4 sur le forum d'en face, je décris un peu ce que j'ai fait sur la centrale inertielle.

Leon.

[Black Templar]

Oui !! j'ai déjà lu tout ton post ^^
D'ailleurs, je vais en profiter pour te poser quelques question !! :)

Quelle méthode utilises-tu pour faire la fusion de données ainsi que l'estimation des paramètres ?? Tu as dit que tu as développé toutes les méthodes toi-même, mais en quoi consistent-elle ??

Deuxième petite chose, quand, dans ton poste du 10 Août 2010, tu dis :
[quote"Léon"]En fait, en vol, il y a beaucoup de vibrations, les mesures sont très bruitées. J'ai donc du filtrer un maximum dans le logiciel. Comment faire? Tout d'abord, il faut multiplier la fréquence des mesures. J'arrive à faire 120 mesures accéléro et gyro par seconde (6 données à mesurer à chaque fois) comtre 50 initialement et 60 mesures de capteur magnétique par seconde. Pas mal, non? Je filtre toutes ces mesures avec des filtre passe bas (1° ordre) de temps de réponse ~100ms. C'est le filtre numérique le plus simple possible. Une fois filtrées, les informations sont beaucoup plus exploitables, moins bruitées, et conservent une dynamique suffisante pour suivre les mouvements du drone.[/quote]
ça veut dire que tu appliques un filtre passe bas de 10Hz aussi aux gyroscopes ?? Pourquoi ça ? Sur les accéléromètres, je veux bien car les bruits sur l'accélération linéaire sont important. L'accéléromètre ne travaille bien qu'en basse fréquence. Par contre, pour le gyro, c'est l'inverse, ça travaille bien en haute fréquence, mais c'est en basses fréquence que ça marche moins bien (dérive) ??
Les gyroscopent oscillent dont tant que ça en vol ? (j'ai pas encore testé les gyro, j'en suis aux accéléro pour le moment) Donc tu utilises les informations du gyro comprissent entre 0 et 10Hz ?


Dernière petite chose sur le post du 25 Juillet 2010 :
[quote"Léon"]En vol, les capteurs se prennent vraiment beaucoup de vibrations, c'est assez gênant. J'ai bidouillé 2 ou 3 trucs très utiles pour la centrale inertielle: détection "drone posé au sol" (tous accéléros et gyro neutres) qui permet de connaitre précisément l'offset (erreur continue) des capteurs; quand les consignes de roulis ou de tangage sont neutres en vol, on fait tendre l'angle correspondant vers zéro. Ca permet de compenser les erreurs d'angle "long terme". [/quote]
Tu as donc appliqué un filtre passe haut sur les gyroscopes en faisant ça ! Du coup, pourquoi avoir court-circuiter les condo du filtre passe haut intégré au gyro sparkfun ??


En tout cas, un grand bravo pour ton projet !! ça marche rudement bien :D
++
Black Templar

[Leon]

[quote"Black Templar"]Quelle méthode utilises-tu pour faire la fusion de données ainsi que l'estimation des paramètres ?? Tu as dit que tu as développé toutes les méthodes toi-même, mais en quoi consistent-elle ??[/quote]Pour la fusion de données, c'est assez simple. Je calcule en permanence l'orientation et la position à partir des données des 3 accéléros et des 3 gyro. Je fais ça toutes les 50ms. Et dès qu'une information en provenance de capteur fiable mais lent est détectée (sonar pour la position et magnéto pour l'orientation), alors je recale légèrement vers la grandeur fiable. Je recale en même temps les positions et les vitesses. Mais pas de 100% de l'erreur constatée. Non, seulement 30 à 60% selon les données. Ca fait quelque chose qui converge bien, et qui en plus est réactif aux évolutions rapides.
Je me sert aussi des mesures "fiables et lentes" pour recaler l'offset des capteurs "rapides" (accéléros, gyros)... mais ça ne fonctionne pas très bien.

[quote"Black Templar"]ça veut dire que tu appliques un filtre passe bas de 10Hz aussi aux gyroscopes ?? Pourquoi ça ? Sur les accéléromètres, je veux bien car les bruits sur l'accélération linéaire sont important. L'accéléromètre ne travaille bien qu'en basse fréquence. Par contre, pour le gyro, c'est l'inverse, ça travaille bien en haute fréquence, mais c'est en basses fréquence que ça marche moins bien (dérive) ?? [/quote]En fait, le plus important n'est pas le filtre passe bas, mais c'est surtout le sur-échantillonnage. Je ne fait les calculs 3D (trigo) que toutes les 50ms, mais je fait des mesures toutes 8ms. Initialement, j'appliquais un filtre passe bas, comme je le disais, mais par la suite, je me suis rendu compte que ça n'était pas bon. En fait, toutes les données brutes ne sont pas utilisées telles quelles dans l'asservissement, mais elles sont toutes "intégrées": vitesse angulaire->angle , et accélération -> vitesse. Du coup, plutôt qu'un filtre passe bas, il est beaucoup plus logique de faire l'intégration toutes les 8ms. Les gros calculs trigos ne sont effectués que toutes les 50ms. Le sur-échantillonnage apporte vraiment de la précision. Il faut, je pense, le pousser au maximum.

Il faut bien comprendre que quand on cherche à asservir une position, un angle, c'est bien les composantes "basses fréquences" qui sont les plus importantes, surtout avec un engin comme le mien qui a une dynamique lente.

[quote"Black Templar"]Tu as donc appliqué un filtre passe haut sur les gyroscopes en faisant ça ! Du coup, pourquoi avoir court-circuiter les condo du filtre passe haut intégré au gyro sparkfun ?? [/quote]Oui, j'applique bien un filtre passe haut en faisant ça... mais uniquement dans certaines situations rares, quand je suis sur et certain que le drone ne bouge pas! Quand je suis certain que le drone est posé au sol (puissance moteur faible, et mesure d'altitude très basse). Ca explique donc l'intérêt d'avoir supprimé le filtre passe haut du module Sparkfun. Le filtre passe haut du module était vraiment catastrophique. Par exemple, après avoir bougé le module d'une dizaine de degrés, l'angle interprété bougeait puis revenait quasiment à zéro. Ca montre bien que c'est la composante continue, basse fréquence, du signal d'un gyro ou d'un accéléro, qui est la plus importante.

Leon.

[Black Templar]

Merci pour ces explications !

[quote"Léon"]Pour la fusion de données, c'est assez simple. Je calcule en permanence l'orientation et la position à partir des données des 3 accéléros et des 3 gyro. Je fais ça toutes les 50ms.[/quote]

Mais justement, comment fusionnes-tu l'information des accéléro et des gyro pour estimer l'angle ??
Un filtre complémentaire ?? Un filtre de Kalman ?? Une moyenne ?? Une moyenne pondéré ?? Autre ?

[Leon]

Les 3 angles ne sont déterminés QUE par les gyro, et aussi par le magnéto 3D pour l'angle de lacet (yaw). Je me suis inspiré (inspiré seulement) des algos de DCM, en simplifié. Simplifié, car je peux faire des approximations. Je sais que le robot ne prendra jamais plus de 30° d'angle de roulis et de tangage (sinon, il est en train de se crasher), donc ça simplifie énormément les choses.
http://gentlenav.googlecode.com/files/DCMDraft2.pdf

Les accéléros NE peuvent PAS servir à déterminer les angles, c'est impossible. Ca peut fonctionner pour un robot arrêté, ou alors dont on connait la dynamique. Par exemple, si on sait que la vitesse du robot est assez constante, on peut déduire l'angle de roulis et de tangage des accéléros.

Mais pour un robot qui vole, c'est impossible! L'accélération est perturbée par plein d'autres choses que juste l'inclinaison du robot. De plus, sur un quadri-rotor "idéal", théorique, en l'absence de frottements, et en considérant qu'il n'y a pas de vent, et que la force de poussée des hélices est toujours dans l'axe vertical du robot... et bien les accélérations longi et latérale sont en théorie tout le temps égales à 0! Je t'invites à bien réfléchir à la dynamique d'un quadri pour comprendre ça. Ca montre bien que tu ne peux pas les exploiter pour déduire des angles.

Leon.

[Black Templar]

Salut !
Merci pour les explications.

Sinon, je ne suis pas d'accord. Tu peux utiliser les accéléromètres pour en déduire les angles en les couplant avec les gyroscopes même si le robot à une accélération propre !!
J'ai déjà simulé ça sous MatLab à l'aide d'un filtre de Kalman étendu. Et la seule contrainte pour que ça marche, c'est qu'il faut connaitre ou annuler la dérive des gyroscopes !! C'est là dessus que je suis en train de plancher en ce moment !

++

[Leon]

[quote"Black Templar "]Sinon, je ne suis pas d'accord. Tu peux utiliser les accéléromètres pour en déduire les angles en les couplant avec les gyroscopes même si le robot à une accélération propre !! [/quote]Tu peux m'expliquer le principe de ton truc? Parce que là, j'ai vraiment de gros doutes.
Est-ce que tu es d'accord sur le fait qu'un quadri-rotor idéal=théorique voit des accélérations longi et latérale tout le temps nulles, quelle que soit son inclinaison? Si tu es d'accord avec ça, ça devrait suffire pour te convaincre que les accélérations ne servent en rien à déterminer les angles, pour un tel engin!
Un quadri idéal est constamment en "chute libre" sur ses axes longi et latéral, en fonction de l'inclinaison. Donc sur les axes longi et latéral, il ne voit aucune accélération. Zero tout le temps. C'est logique, vu qu'aucune force n'est générée selon l'axe longi et l'axe latéral. Les seules forces sont les 4 forces (des 4 hélices) orientées verticalement. C'est comme un mobile qui glisse sans frottement sur un plan incliné.

En pus, tu le dis toi même dans la présentation du sujet:
[quote"Black Templar"]Lorsque la centrale n'accélère pas, on peut donc en déduire l'angle d'inclinaison de la centrale en prenant en compte la gravitation. Si la centrale accélère, alors on ne peut rien en déduire (on a trop de degré de liberté)... Pas très pratique. [/quote]

Leon.

[Black Templar]

[quote"Leon"][quote"Black Templar "]Sinon, je ne suis pas d'accord. Tu peux utiliser les accéléromètres pour en déduire les angles en les couplant avec les gyroscopes même si le robot à une accélération propre !! [/quote]Tu peux m'expliquer le principe de ton truc? Parce que là, j'ai vraiment de gros doutes.
Est-ce que tu es d'accord sur le fait qu'un quadri-rotor idéal=théorique voit des accélérations longi et latérale tout le temps nulles, quelle que soit son inclinaison? Si tu es d'accord avec ça, ça devrait suffire pour te convaincre que les accélérations ne servent en rien à déterminer les angles, pour un tel engin!
Un quadri idéal est constamment en "chute libre" sur ses axes longi et latéral, en fonction de l'inclinaison. Donc sur les axes longi et latéral, il ne voit aucune accélération. Zero tout le temps. C'est logique, vu qu'aucune force n'est générée selon l'axe longi et l'axe latéral. Les seules forces sont les 4 forces (des 4 hélices) orientées verticalement. C'est comme un mobile qui glisse sans frottement sur un plan incliné.[/quote]

En effet, je suis d'accord qu'un quadri idéal lorsqu'il est est stabilisé ne possède aucune accélération. D'ailleurs dans ce cas, on peut donc utiliser les accéléromètre pour en déduire l'angle du quadri (la gravitation étant une accélération)

[quote"Leon"]En pus, tu le dis toi même dans la présentation du sujet:
[quote"Black Templar"]Lorsque la centrale n'accélère pas, on peut donc en déduire l'angle d'inclinaison de la centrale en prenant en compte la gravitation. Si la centrale accélère, alors on ne peut rien en déduire (on a trop de degré de liberté)... Pas très pratique. [/quote][/quote]

En effet, en prenant toutes les contraintes des accéléro et des gyro, on a un trop grand degré de liberté pour en déduire quoique ce soit (On se ramène à un problème à 2 équations, 3 inconnues en gros). Mais il suffit que l'on connaisse l'évolution du biais du gyro pour supprimer une inconnue et ainsi pouvoir utiliser les gyroscopes et les accéléromètres conjointement pour estiver l'angle et l'accélération du drone.

[Leon]

[quote"Black Templar"]En effet, je suis d'accord qu'un quadri idéal lorsqu'il est est stabilisé ne possède aucune accélération. D'ailleurs dans ce cas, on peut donc utiliser les accéléromètre pour en déduire l'angle du quadri (la gravitation étant une accélération)[/quote]Je crois qu'on ne se comprend pas. Ce que je veux dire, c'est qu'un quadri "idéal" (se déplaçant sans frottement), qu'il soit stabilisé OU NON, n'est soumis à AUCUNE accélération latérale et longitudinale. Quand je parle d'accélération latérale et longitudinale, je me place bien dans le repère du quadri, pas dans le repère "terre". Pas de force latérale et longi, donc pas d'accélération (F=M.A). C'est vrai dans n'importe quelle situation: qu'il soit stable, ou qu'il fasse de grosses accélérations, des translations rapides, etc... Tu as bien réfléchi à la dynamique du quadri, et l'équivalence avec un mobile sans frottement sur un plan incliné? L'orientation du plan variant bien évidemment selon l'orientation du quadri. Stabiliser un quadri en longi et latéral, et le faire aller là où on veut, c'est exactement comme stabiliser un mobile sans frottement (ou une petite bille) sur un plan incliné en faisant varier l'inclinaison de ce plan, donc l'inclinaison du quadri.

[quote"Black Templar"]En effet, en prenant toutes les contraintes des accéléro et des gyro, on a un trop grand degré de liberté pour en déduire quoique ce soit (On se ramène à un problème à 2 équations, 3 inconnues en gros). Mais il suffit que l'on connaisse l'évolution du biais du gyro pour supprimer une inconnue et ainsi pouvoir utiliser les gyroscopes et les accéléromètres conjointement pour estiver l'angle et l'accélération du drone.[/quote]Si tu connais le biais (offset) des gyro, alors tu n'as besoin que des gyro pour déterminer l'angle. Les accéléros ne sont d'aucune utilité pour déterminer les angles.

Leon.

[Black Templar]

Salut !

Je réagirais sur la première partie du message Lundi (là, je part pour le WE sans accès internet) mais en effet, je n'avais pas bien compris ce que tu voulais dire.

[quote"Leon"]Si tu connais le biais (offset) des gyro, alors tu n'as besoin que des gyro pour déterminer l'angle. Les accéléros ne sont d'aucune utilité pour déterminer les angles.[/quote]
Si, c'est utile ! Si tu n'utilises que les gyros et que tu intègres les vitesses angulaires, tu auras inévitablement une dérive ! (même si tu sur échantillonnes).
En fusionnant avec le les données de l'accéléromètre, ça te permet de corriger cette dérive :)

++

[Esprit]

Je me rends compte que je suis nule part dans mon utilisation de ma centrale inertielle... *Siffle*

[Black Templar]

[quote"Leon"][quote"Black Templar"]En effet, je suis d'accord qu'un quadri idéal lorsqu'il est est stabilisé ne possède aucune accélération. D'ailleurs dans ce cas, on peut donc utiliser les accéléromètre pour en déduire l'angle du quadri (la gravitation étant une accélération)[/quote]Je crois qu'on ne se comprend pas. Ce que je veux dire, c'est qu'un quadri "idéal" (se déplaçant sans frottement), qu'il soit stabilisé OU NON, n'est soumis à AUCUNE accélération latérale et longitudinale. Quand je parle d'accélération latérale et longitudinale, je me place bien dans le repère du quadri, pas dans le repère "terre". Pas de force latérale et longi, donc pas d'accélération (F=M.A). C'est vrai dans n'importe quelle situation: qu'il soit stable, ou qu'il fasse de grosses accélérations, des translations rapides, etc... Tu as bien réfléchi à la dynamique du quadri, et l'équivalence avec un mobile sans frottement sur un plan incliné? L'orientation du plan variant bien évidemment selon l'orientation du quadri. Stabiliser un quadri en longi et latéral, et le faire aller là où on veut, c'est exactement comme stabiliser un mobile sans frottement (ou une petite bille) sur un plan incliné en faisant varier l'inclinaison de ce plan, donc l'inclinaison du quadri.[/quote]

Parfaitement d'accord pour un quadri idéal. On parle bien ici, d'accélération propre au quadri.

[quote"Leon"]Est-ce que tu es d'accord sur le fait qu'un quadri-rotor idéal=théorique voit des accélérations longi et latérale tout le temps nulles, quelle que soit son inclinaison? Si tu es d'accord avec ça, ça devrait suffire pour te convaincre que les accélérations ne servent en rien à déterminer les angles, pour un tel engin! [/quote]

En effet pour l'accélération propre du quadri. Le problème, c'est que la gravitation est elle aussi une accélération. Du coup, si le quadri est incliné, on aura une projection de l'accélération gravitationnel sur les axes x et y :):)
Si le quadri est incliné de 30° autour de x, l'accéléromètre sur l'axe y verra une accélération non nul qui aura pour valeur -sinus(30°)*9.81 mètre par seconde !

Néanmoins, ce que tu viens de me dire m'a fait réaliser quelques petits trucs qui pourront m'être utiles lorsque je vais essayer de modéliser tout ça ! J'ai plus qu'à faire des tests :D

[quote"Esprit"]Je me rends compte que je suis nule part dans mon utilisation de ma centrale inertielle... *Siffle*[/quote]
???
J'attends toujours de voir comment Magellan vas s'y prendre pour se stabiliser tout seul :) :p

[Esprit]

Il est pas encore prêt de se tenir en équilibre tout seul si tu veux mon avis... Ça viendra, mais j'ai encore pas mal de boulot.