15 réponses à ce sujet

[Hexa Emails]

Bonjour,

je viens partager et enrichir mes connaissances sur les accéléromètres (c'est la mode en ce moment donc c'est l'occasion)

je possède un wii nunchuck, contenant entre autres un accéléromètre 3 axes dont je peux récupérer les données.

Après expérimentations, il s'avère que les axes sont mis de cette manière:



(cela fait un certain temps que je l'ai fait mais je pense l'avoir fait sérieusement ^^)



Mon but serait de faire un asservissement en horizontalité du Nunchuck (en boucle fermée), en lui fixant 2 servomoteurs.



J'étais donc parti sur une formule qui traînait dans un coin de mon crâne:

le travail de la force: W=cos(alpha)*F



Mais comme souvent la théorie a été complètement détruite par la pratique: mes relevés sont très bruités!

j'applique un filtre du type: accélération = (précédente valeur d'accélération + nouvelle) /2



mais ça ne semble pas suffisant...



si quelqu'un a des conseils, des expériences dans ce domaine qu'il n'hésite pas ^^

j'ai mis dans la section algo/programmation, ce n'est pas un projet à part entière et je compte utiliser ce topic pour obtenir un petit peu d'aide sur l'asservissement, ce qui explique sa place ici ;)

merci de m'avoir lu!

[Maïck]

Je but un peut sur ta "formule" : "W=cos(alpha)*F"

Elle tombe d'où ta force ? L'angle c'est pas justement ce que tu cherche ? un travail égal à une force ??

C'est quoi que tu appelle bruité ? Ce genre de capteur ont généralement pas mal de filtre interne...

C'est pas ta boucle de régulation plutôt qui pose problème ?

[Hexa Emails]

cette formule permet de calculer le travail réel d'un force, par rapport à une direction, alpha étant l'angle entre la direction du "travail" et la direction de la force en question. Dans mon problème, F est l'accélération de la pesanteur.
F est constant, je fais varier l'angle de ma nunchuck et donc alpha, et ce qui est mesuré est le travail de l'accélération de la pesanteur sur les axes de mesure de mon nunchuck.

Je suis pas sûr d'etre plus clair... :tare:

Pour le filtrage il doit être après (soit sur la mote, soit sur la wii en elle même)
le résultat est "moins pire" en faisant une moyenne coefficentée:

accélération = 0.9*précédente valeur d'accélération + 0.1*nouvelle

Et pour l'asservissement, c'est plutôt simple, je ne vois pas comment faire :D

pour l'instant je pilote deux servos solidaires (qui dirigent une baguette dans l'espace) en faisant varier l'inclinaison de la chuck.
mais la réponse n'est pas du tout linéaire, pas sur le même intervalle... bref c'est très crade. ça vient sans doute du fait que mes accéléromètres n'ont pas la même valeur intermédiaire, pas la même sensibilité ni la même étendue de mesure d'une axe à l'autre. L'instrument de mesure parfait quoi! :(

[zeqL]

Tu peux utiliser des filtres au niveau de tes mesures comme tu le fait avec ta moyenne, mais un peu "mieux".

Le plus célèbre étant le filtre de Kalman, c'est aussi l'un des plus compliqué à mettre en oeuvre et à comprendre.
En cherchant un peu on trouve d'autres filtres plus simples à mettre en place et plus performants au niveau ressources consommées, comme le Filtre alpha beta : http://www.mstarlabs.com/control/engspeed.html#Ref1

Sinon tu peux toujours faire une moyenne avec 3 valeurs avec une pondération du style : 70-25-5 (%), enfin à toi de choisir les bonnes valeur selon l'importance que tu veux accorder aux valeurs.

[Maïck]

Ouais donc en fait tu calcul:
ax=a*Cos(alpha)

Le travail c'est W=F*d, pas de travail sans déplacement ! Toi qui pinaille sur les unités fait gaffe au lettres utilisées dans les calculs ! :p

Tu prend quoi comme "F"?? Si tu veut que ça soit linéaire il faut calculer la norme, donc autant passer par l’Arc tangente !

[Hexa Emails]

@Maïck: autant pour moi, en effet ce que je calcule n'est pas le travail, mais la projection orthogonale d'une force. en terminale S en Physique ils appelaient ça le travail d'une force, mais en sciences de l'ingénieur on l'avait vu l’année précédente comme le projeté orthogonal... Et maintenant je ne fais plus de méca, d'où mes confusions!



@zeqL: Je m'appuie uniquement sur l'accélération de la pesanteur (donc je mesure l'accélération en régime établi, pas les variations) pour déterminer l'inclinaison par rapport au sol. Si je veux atténuer les variations un filtre passe bas est donc parfait non?



En fait ma formule c'est pour essayer de trouver un rapport entre la valeur de "la projection orthogonale de la pesanteur sur l'axe de l'accéléromètre" (ma mesure quoi) et l'angle que la manette a avec le sol.



un petit exemple:

sur l'axe Z (voir photo) si accZ= -g alors la chuck est forcément droite. si accZ=0 alors la chuck est forcément à 90°.

en m'aidant de la valeur des 3 axes je devrait bien réussir à trouver l'inclinaison de la chuck par rapport au sol.

C'est sûrement une relation trigonométrique? à tout hasard avec un cos alpha :p

[zeqL]

Tu dis que tes relevés sont bruités. Le filtre de Kalman sert justement à filtrer ce bruit d'une meilleure manière qu'une simple moyenne. Et de même pour le filtre alpha beta, je t'invite à aller voir le lien, vers la fin de l'article il y a un exemple sous matlab, avec la courbe "réelle" et la courbe lissée, résultante du filtre.

Un filtre passe bas n'a rien à voir là dedans, on ne veut pas filtrer des fréquences particulières puisqu'on ne connait rien des fréquences contenant l'information.

Ensuite tu dis que tu as un mouvement crade, mais avec un asservissement type PID cela devrait être mieux, néanmoins cela demande un peu de boulot car il y a besoin de l'intégrale et de la dérivée, ce qui n'est pas facile à obtenir dans ton cas (pour la dérivée).
(Les servo moteur n'intègre pas un PID de base d'ailleurs ?)

Plus ta courbe "d'acquisition" sera lissée, plus tu améliorera (jusqu'à un certain point) la linéarité des mouvements de tes servo moteurs.
Comme on est en temps réel, on ne peut pas utiliser d'interpolation, qui t'aurait permis, après avoir fait un filtrage basique pour éliminer une partie du bruit, en sélectionnant une partie seulement des points (1 sur 2 ou sur 3) de récréer une courbe lissée (polynomiale ou spline) ou linéarisée.


Néanmoins, je ne suis pas trop sur de ce que tu veux faire exactement avec tes équations, mais quand tu dis que tes relevés sont bruités, cela veut dire quoi ?
Tu as fait un relevé à l'oscilloscope ?
Ou tes valeurs numériques ?

Sur quoi travailles-tu comme microcontroleur (ou non d'ailleurs) ? arduino ?

[Hexa Emails]

Bon c'est vrai que niveau contexte j'ai été un peu court ^^
Le chuck est connecté à mon arduino, j'obtiens des relevés tous les 10ms.

la donnée est un octet par axe (+ un octet par axe de joystick etc qui ne servent pas ici), la valeur mini est de 80 et le max de 180 à 200 (cela change beaucoup d'un axe à l'autre en plus). Ces valeurs sont obtenues sans "forcer" lors du mouvement, je ne mesure que la gravité (pas une accélération au sens mouvement de la chuck).
Quand je dis bruité, cela veut dire que les réponses varient alors que je ne change pas l'inclinaison. Quand je dis crade, c'est parce que lorsque je fait varier de façon continue l'inclinaison, la réponse est saccadée et pas du tout continue.

Un servomoteur est asservi de base oui, mais le type d'asservissement je ne sais pas (cela dépend peut etre d'une marque à une autre)

Pour l'histoire de filtre passe bas (décidément j'en dis des Cµ@%eries!) j'ai demandé sur le site de l'arduino une manière d'atténuer les variations d'une valeur numérique, et on m'a donné une moyenne pondérée en me disant que c'était un filtre passe bas. Je ne m'y connais pas en filtre numérique donc je l'ai cru sur parole.

Je pensais à un "simple" asservissement P, pour le moment je me contente de faire un règle de 3 entre ma mesure et les bornes max et min de mon accélération/ de l'angle de mon servo. donc meme d'un point de vue théorique ça ne peut pas marcher ^^

Voilà j'espère que ces précisions aideront je serait très intéressé par réaliser moi même un asservissement.

Waaah j'ai fait un sacré pavé :D

[Hexa Emails]

Me revoilà, j'ai relevé les valeurs minimum, maximum et intermédiaires (lorsque le poids est perpendicculaire à l'axe) de chancun des axes X,Y et Z.





accX
accY
accZ


mini
108
89
88


milieu
132
179*
128


maxi
160
185
190





*comme on peut le voir il y a un léger souci avec cette valeur, si on bouge légèrement la chuck cela passe à 127 (beaucoup plus acceptable) mais je n'ai pas réussi à obtenir de valeurs entre 127 et 173! en fait la réponse est non seulment pas linéaire, mais pas croissante -_-"

C'est un peu dur à explique, si je trouve le courage je démonterai le circuit (histoire de pouvoir imposer un angle précis en entrée, parce qu'avec une chuck toute ronde difficile de savoir si l'on est bien perpendiculaire) et je ferai un tableau plus précis avec des relevés tous les 10° par exemple.

[Maïck]

Non linéaire c'est normal vu que c'est une fonction sinusoïdale ! :|

Par contre tu mesure quoi là ?? Des volts ?

[Hexa Emails]

Si le capteur fonctionne comme les accéléromètres qu'on a étudié en cours, c'est une capacité qui est mesurée. Enfin en tout cas, le signal est conditionné par la chuck et je reçois ça sous la forme d'un octet (0 à 255), linéaire à la valeur d'accélération, par liaison I2C je crois.

Non linéaire Ok, mais pas monotone ça commence à devenir problématique... pour une valeur d'accélération donnée je n'aurais pas une seule possibilité en angle! Dès que j'ai le matériel je regarde si la WiiMote est plus précise. En attendant je pense me servir que de l'axe X et Z.

[Maïck]

Reste à savoir quel traitement ils ont fait derrière...

A la base il s'agit de ces capteurs: http://www.alldatasheet.com/datasheet-pdf/pdf/150893/AD/ADXL330.html

Effectivement la plupart sont basé sur une mesure de capacité pour connaitre l'accélération. Mais ils ont tous un étage de sortie qui fournit directement des mV/g, ou directement l'accélération en g par liaison série.

[Hexa Emails]

Oui c'est le problème lorsque l'on hack du matériel existant.

mais d'après ce site ce sont les données brutes qui sont envoyées.

(d'ailleurs la donnée que je reçois est sur 8 bits et non pas 10 comme indiqué sur le site; il faudrait que je vérifie dans me bibliothèque s'il s'agit d'une conversion ou d'une erreur.)



edit: après vérification je crois que en effet ma bibliothèque n'en tient pas compte (je crois que ce sera amélioré dans une version supérieure si j'ai bien compris). Mais çe ne provoque pas une grande erreur (il s'agit des 2 bits de poids faible...)

[Hexa Emails]

Mise à jour: pour me motiver j'en ai fait quelque chose "d'utile":

16_pS-vjBgQ

je sais, ma chambre est en bordel.

[miky-mike]

Pas mal du tout !

[Hexa Emails]

Merci, mais ce n'est vraiment pas difficile à faire.
(c'est pour cela qu'on trouve plein de vidéos de ce type sur youtube...)
J'ai modifié la bibliothèque "nunchuck_funcs.h", j'utilise à présent la pleine échelle de mesure (soit 10 bits, me renvoyant une valeur de 0 à 1023, au lieu d'un octet, me renvoyant une valeur de 0 à 255). Cette petite correction, en plus d'ajouter de la précision, supprime une erreur systématique de 2 bits de poids faible (un erreur comprise entre 0 et 3).
Je suis en ce moment des cours de traitement du signal, donc plus le temps avance et plus je risque d'améliorer mes résultats!