Aller au contenu


Photo
- - - - -

Asservir en vitesse un robot 4 roues avec un accelerometre


  • Veuillez vous connecter pour répondre
19 réponses à ce sujet

#1 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 03 mars 2019 - 03:00

Saluuut ! 

Je suis en 2ieme année de classe préparatoire scientifique, et j'ai décidé pour mon tipe de fabriquer un robot sous forme de voiture télécommandée ( 4 roues motrices et qui utilise le principe de la différentiel de puissance pour changer de direction ), il est contrôlé par une carte Raspberry Pi, voulant l'asservir en vitesse, je me suis procuré un  "MPU-6050 3 axes Gyroscope + module d'accéléromètre" .

C'est mon prof encadrant qui m'a conseillé de l'utiliser pour mesurer la vitesse à partir de l’accélération ( en intégrant ), mais je sais vraiment pas comment je peux écrire un programme qui me permettrait de faire ça et est ce que ça va vraiment marcher ? Si vous avez des modèles de programmes sur lesquelles je peux me baser pour écrire le mien ça serait sympa aussi.

Merci :) 



#2 Microrupteurman

Microrupteurman

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 210 messages
  • Gender:Male
  • Location:Aquitaine,Gironde

Posté 03 mars 2019 - 03:17

Salut, je suis, j'aimerais comprendre comment calculer une accélération avec un accéléromètre, qui pour moi, mesure simplement un angle....

 
Page Facebook : https://www.facebook...appartelier2.0/
Page Twitter :  https://twitter.com/2Appartelier (bateau seulement)
Boutique Robot-Maker : https://www.robot-ma...er-20/produits/

Besoin d'une impression 3D grand format ? Contactez moi !
 


#3 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 03 mars 2019 - 04:51

Alors plusieurs choses : 

Une accélération sert à mesurer l'accélération du robot une fois intégré donné bien une vitesse à l'erreur statique près. 
=> On peut se servir de l'accélération pour avoir une idée de la vitesse linéaire du robot. 

 

Un accéléromètre peut aussi être utilisé pour déterminer l'angle d'inclinaison en regardant la direction de l'accélération de la pesenteur ( gravité ) mais ce n'est pas ce qui va nous intéresser dans ce cas. 

Un gyromètre donne une vitesse angulaire 
=> On peut s'en servir pour avoir une idée de la vitesse angulaire du robot. 

En combinant les deux informations tu peux avoir une idée de la vitesse de chacun de tes deux moteurs... 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#4 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 03 mars 2019 - 08:05

Oui voila moi je compte intégrer l'acceleration pour trouver la vitesse 



#5 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 04 mars 2019 - 07:18

Bonjour,

quelques informations supplémentaires :

- un accéléromètre mesure l'accélération dans le référentiel du robot, du coup si tu veux connaître la vitesse dans le référentiel terrestre, tu vas devoir changer de référentiel (pour ça tu aura besoin de mesurer les vitesses de rotations grâce au gyroscope (qui est inclus)

- en plus de mesurer l'accélération, le gyromètre mesure aussi l'accélération de la pesanteur (g) : tant que tu es sur un support horizontal et que ton accéléromètre n'est pas penché, ça pose pas de problème (tu ne lis l'accélération qu'en x et y, pas en z), dans le cas contraire ça devient compliqué

- Un accéléromètre à 2 types d'erreurs : des offsets (dus à des imperfections du capteur et/ou au fait que ton capteur non soit pas monté parfaitement droit sur ton robot et/ou au fait que ton sol ne soit pas parfaitement horizontal) et des erreurs aléatoires. Les premières te donnent une erreur en vitesse qui croit proportionnellement au temps (mais tu peut t'en débarrasser en calibrant ton capteur, à condition que la surface sur laquelle tu roule soit bien planaire) ; les secondes te donnent une erreur croissant comme la racine carré du temps, mais tu ne peut pour ainsi dire rien faire contre (sauf en rajoutant d'autres capteurs). Donc tout dépend de la durée pendant laquelle tu veux contrôler ainsi la vitesse de ton robot : pendant une courte durée ça ira bien, sur une longue durée c'est mort (sauf si tu couple avec d'autres informations, par exemple arrêter le robot, ce qui permet de remettre à 0 la vitesse et donc l'erreur).

 

Est-ce que tu pourrais nous en dire plus sur l'utilisation prévue de ton robot? (durée d'utilisation (entre 2 arrêts), type de terrain, précision souhaitée/nécessaire, ...)?

Car selon les réponses, l'utilisation d'un accéléromètre peut être une solution satisfaisante ou être complètement hors de question (sauf si tu veux utiliser un accéléromètre à 100 000€ et écrire un programme qui pourrait faire l'affaire d'un TIPE à lui tout seul).

 

bonne soirée

Sandro


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#6 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 04 mars 2019 - 08:21

Merci pour ta réponse Sandro

 

Bonjour,

quelques informations supplémentaires :

- un accéléromètre mesure l'accélération dans le référentiel du robot, du coup si tu veux connaître la vitesse dans le référentiel terrestre, tu vas devoir changer de référentiel (pour ça tu aura besoin de mesurer les vitesses de rotations grâce au gyroscope (qui est inclus)

- en plus de mesurer l'accélération, le gyromètre mesure aussi l'accélération de la pesanteur (g) : tant que tu es sur un support horizontal et que ton accéléromètre n'est pas penché, ça pose pas de problème (tu ne lis l'accélération qu'en x et y, pas en z), dans le cas contraire ça devient compliqué

- Un accéléromètre à 2 types d'erreurs : des offsets (dus à des imperfections du capteur et/ou au fait que ton capteur non soit pas monté parfaitement droit sur ton robot et/ou au fait que ton sol ne soit pas parfaitement horizontal) et des erreurs aléatoires. Les premières te donnent une erreur en vitesse qui croit proportionnellement au temps (mais tu peut t'en débarrasser en calibrant ton capteur, à condition que la surface sur laquelle tu roule soit bien planaire) ; les secondes te donnent une erreur croissant comme la racine carré du temps, mais tu ne peut pour ainsi dire rien faire contre (sauf en rajoutant d'autres capteurs). Donc tout dépend de la durée pendant laquelle tu veux contrôler ainsi la vitesse de ton robot : pendant une courte durée ça ira bien, sur une longue durée c'est mort (sauf si tu couple avec d'autres informations, par exemple arrêter le robot, ce qui permet de remettre à 0 la vitesse et donc l'erreur).

 

Est-ce que tu pourrais nous en dire plus sur l'utilisation prévue de ton robot? (durée d'utilisation (entre 2 arrêts), type de terrain, précision souhaitée/nécessaire, ...)?

Car selon les réponses, l'utilisation d'un accéléromètre peut être une solution satisfaisante ou être complètement hors de question (sauf si tu veux utiliser un accéléromètre à 100 000€ et écrire un programme qui pourrait faire l'affaire d'un TIPE à lui tout seul).

 

bonne soirée

Sandro

Merci pour ta réponse Sandro, en fait mon robot ressemble à une voiture télécommandée que je contrôle à partir d'une interface graphique, il est équipé d'un capteur ultrason qui sert à mesurer la vitesse de n'importe quelle cible proche de lui ( dans l idéal ça devrait ressembler à un radar-mobile ), avec un camarade de classe on est entrain d'essayer d'écrire un programme qui lui permettra de reproduire une trajectoire prédéfinie. Du coup l'accéléromètre devrait me permettre  de mesurer la vitesse du robot que je compte asservir pour une vitesse plus précise et aussi pour lui permettre de garder la même vitesse dans le cas d'une pente .... ( petite pente ). Je pense que le calcul de la vitesse se fera surement sur des petites périodes donc ça posera pas de problème pour ça , par contre pour le reste avec les informations que je t'ai donné qu'est ce que t'en penses stp ? 



#7 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 04 mars 2019 - 10:20

Donc si je comprends bien, tu poudrais suivre une trajectoire au sol : si c'est bien ça, alors c'est encore plus compliqué car tu intègre pas une fois mais deux fois tes erreurs, donc si tu ne fais pas de calibration, tu as une erreur de position en t² (sinon en t^(3/2) si je me trompe pas).

 

Si en plus tu as des pentes alors soit tu fais les intégrations en 3D (et là ça devient très très moche), ou alors tu cumule super vite des erreurs.

Prenons l'exemple d'une pente de 1° : sur l'axe vertical, tu as la gravité, donc 9.81 m/s². Vue que tu es penché de 1°, tu as une erreur de da=sin(1°)*9.81 = 0.17 m/s² sur l'accélération. Du coup ton erreur sur la vitesse est dv=da*t : au bout d'un 6 secondes, tu as une erreur en vitesse de plus de 1 m/s (ce qui est probablement plus que la vitesse maximale de ton robot), et ton erreur en position est dx=0.5*da*t² (soit 1m en 3.5 secondes). A noter que même si tu retourne sur du plat, ton erreur de vitesse reste, donc ton erreur en position croit encore (même si c'est plus que proportionnellement au temps).

Bref, il y a de fortes chances que ça ne fasse pas l'affaire.

 

Après, il y a des astuces qui pourraient permettre d'améliorer un peu les choses, mais même comme ça ça reste assez moyen :

- supposer que si l'accélération ne change pas pendant plus que dt, c'est que tu es sur du plat (car il te faut moins que dt secondes pour parcourir ta plus longue pente) : du coup, si tu connais ta vitesse sur le plat, tu peut remplacer ta vitesse calculée par la vitesse "nominale"

- juste détecter si le capteur est penché, et essayer de calculer la pente et d'adapter la commande des moteurs en conséquence (commande en boucle ouverte)

- avancer par petits à coups (vu les calculs ci-dessus, je dirais pas plus d'une seconde à chaque fois), pour remettre la vitesse à 0 à chaque fois que tu t'arrête

 

Une "solution" serait de combiner avec un autre capteur qui te donne une information éventuellement plus bruité mais qui se cumule moins, et ensuite de fusionner ces données (dans ce cas tu peux regarder du coté des filtres de Kalman). En gros, il te faut un capteur qui te donne dans l'idéal la position, ou au moins la vitesse, même si c'est de manière imprécise. Si tu rajoute des objets fixes, tu peux peut-être te servir du capteur infrason (d'ailleurs, s'en est un qui mesure les distances (effet doppler?) ou un plus classique qui calcule les distances?

 

Mais globalement, sauf si le but de ton projet est de faire de la navigation avec un accéléromètre, ou que tu ne veux pas rouler plus que 1-2 secondes (éventuellement un petit peu plus si ton sol est parfaitement plat et que tu es prêt à faire une calibration avant chaque usage), je te déconseille d'utiliser un accéléromètre pour la navigation (certainement pas sans un autre capteur, en combinaison ça peut donner de bon résultats mais au prix d'un effort important).

 

A ta place, si le but est de te déplacer pendant des durées pas trop longues, alors je te conseillerais de regarder du coté des encodeurs (je te mets les 2 premiers liens que j'ai trouvé qui expliquent un peu plus ce que c'est : https://www.robot-maker.com/shop/blog/32_Utilisation-des-encodeurs.html et https://www.generati...botique-mobile/ ). En gros c'est un dispositif qui mesure de combien a tourné une roue, ce qui te permet de connaître facilement ton déplacement (tu cumule aussi des erreurs mais beaucoup plus lentement) et ta vitesse (l'erreur sur la norme de ta vitesse n'augmente pas, par contre la direction si, car tu cumule des erreurs sur ton orientation en racine carre du temps). Il y a 2 types d'encodeurs : ceux qui sont directement intégrés au moteurs, et ceux qui sont séparés (dans quel cas tu peux toi même les relier à tes roues (souvent via un petit axe qui sort exprès à l'arrière de certains moteurs), ou alors à des roues qui ne servent qu'à ça). Tu as des encodeurs avec tout type de résolution (en général entre 1/10 de tour et 1/1000 voir mieux).

Avec un bon encodeur (enfin 2, vu qu'il en faut 1 de chaque coté), et une bonne mécanique (il faut s'assurer que la roue reste toujours en contact avec le sol sans glisser), j'ai déjà réussi à avoir moins d'un mètre d'erreur après plusieurs minutes. Après, un bon encoder, il faut compter aux alentours de 50€ pièce (et il en faut 2).

 

Après, si tu veux que je te conseille mieux, je vais avoir besoin de connaître vraiment précisément ton cahier des charges:

- vitesse de ton robot (à peu près)

- durée d'utilisation que l'utilisateur ait à lui re-donner sa vrai position ou le replacer à un endroit connu

- possibilité ou pas de s'arrêter très souvent (idéalement plusieurs fois par seconde) pour savoir qu'on est à vitesse 0

- distance à parcourir

- précision souhaitée

- budget disponible

- temps que tu es prêt à consacrer à cet asservicement

 

Bonne soirée

Sandro

 

PS : @Mike118 :  C'est moi ou tu n'as aucun encodeur non monté sur un moteur dans la boutique?


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#8 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 04 mars 2019 - 11:30

Donc si je comprends bien, tu poudrais suivre une trajectoire au sol : si c'est bien ça, alors c'est encore plus compliqué car tu intègre pas une fois mais deux fois tes erreurs, donc si tu ne fais pas de calibration, tu as une erreur de position en t² (sinon en t^(3/2) si je me trompe pas).

 

Si en plus tu as des pentes alors soit tu fais les intégrations en 3D (et là ça devient très très moche), ou alors tu cumule super vite des erreurs.

Prenons l'exemple d'une pente de 1° : sur l'axe vertical, tu as la gravité, donc 9.81 m/s². Vue que tu es penché de 1°, tu as une erreur de da=sin(1°)*9.81 = 0.17 m/s² sur l'accélération. Du coup ton erreur sur la vitesse est dv=da*t : au bout d'un 6 secondes, tu as une erreur en vitesse de plus de 1 m/s (ce qui est probablement plus que la vitesse maximale de ton robot), et ton erreur en position est dx=0.5*da*t² (soit 1m en 3.5 secondes). A noter que même si tu retourne sur du plat, ton erreur de vitesse reste, donc ton erreur en position croit encore (même si c'est plus que proportionnellement au temps).

Bref, il y a de fortes chances que ça ne fasse pas l'affaire.

 

Après, il y a des astuces qui pourraient permettre d'améliorer un peu les choses, mais même comme ça ça reste assez moyen :

- supposer que si l'accélération ne change pas pendant plus que dt, c'est que tu es sur du plat (car il te faut moins que dt secondes pour parcourir ta plus longue pente) : du coup, si tu connais ta vitesse sur le plat, tu peut remplacer ta vitesse calculée par la vitesse "nominale"

- juste détecter si le capteur est penché, et essayer de calculer la pente et d'adapter la commande des moteurs en conséquence (commande en boucle ouverte)

- avancer par petits à coups (vu les calculs ci-dessus, je dirais pas plus d'une seconde à chaque fois), pour remettre la vitesse à 0 à chaque fois que tu t'arrête

 

Une "solution" serait de combiner avec un autre capteur qui te donne une information éventuellement plus bruité mais qui se cumule moins, et ensuite de fusionner ces données (dans ce cas tu peux regarder du coté des filtres de Kalman). En gros, il te faut un capteur qui te donne dans l'idéal la position, ou au moins la vitesse, même si c'est de manière imprécise. Si tu rajoute des objets fixes, tu peux peut-être te servir du capteur infrason (d'ailleurs, s'en est un qui mesure les distances (effet doppler?) ou un plus classique qui calcule les distances?

 

Mais globalement, sauf si le but de ton projet est de faire de la navigation avec un accéléromètre, ou que tu ne veux pas rouler plus que 1-2 secondes (éventuellement un petit peu plus si ton sol est parfaitement plat et que tu es prêt à faire une calibration avant chaque usage), je te déconseille d'utiliser un accéléromètre pour la navigation (certainement pas sans un autre capteur, en combinaison ça peut donner de bon résultats mais au prix d'un effort important).

 

A ta place, si le but est de te déplacer pendant des durées pas trop longues, alors je te conseillerais de regarder du coté des encodeurs (je te mets les 2 premiers liens que j'ai trouvé qui expliquent un peu plus ce que c'est : https://www.robot-maker.com/shop/blog/32_Utilisation-des-encodeurs.html et https://www.generati...botique-mobile/ ). En gros c'est un dispositif qui mesure de combien a tourné une roue, ce qui te permet de connaître facilement ton déplacement (tu cumule aussi des erreurs mais beaucoup plus lentement) et ta vitesse (l'erreur sur la norme de ta vitesse n'augmente pas, par contre la direction si, car tu cumule des erreurs sur ton orientation en racine carre du temps). Il y a 2 types d'encodeurs : ceux qui sont directement intégrés au moteurs, et ceux qui sont séparés (dans quel cas tu peux toi même les relier à tes roues (souvent via un petit axe qui sort exprès à l'arrière de certains moteurs), ou alors à des roues qui ne servent qu'à ça). Tu as des encodeurs avec tout type de résolution (en général entre 1/10 de tour et 1/1000 voir mieux).

Avec un bon encodeur (enfin 2, vu qu'il en faut 1 de chaque coté), et une bonne mécanique (il faut s'assurer que la roue reste toujours en contact avec le sol sans glisser), j'ai déjà réussi à avoir moins d'un mètre d'erreur après plusieurs minutes. Après, un bon encoder, il faut compter aux alentours de 50€ pièce (et il en faut 2).

 

Après, si tu veux que je te conseille mieux, je vais avoir besoin de connaître vraiment précisément ton cahier des charges:

- vitesse de ton robot (à peu près)

- durée d'utilisation que l'utilisateur ait à lui re-donner sa vrai position ou le replacer à un endroit connu

- possibilité ou pas de s'arrêter très souvent (idéalement plusieurs fois par seconde) pour savoir qu'on est à vitesse 0

- distance à parcourir

- précision souhaitée

- budget disponible

- temps que tu es prêt à consacrer à cet asservicement

 

Bonne soirée

Sandro

 

PS : @Mike118 :  C'est moi ou tu n'as aucun encodeur non monté sur un moteur dans la boutique?

Merci encore pour ces explications :)

Pour la vitesse du robot je dirai que c'est environ 2.5m/s ou quelque chose comme ça, et pour la durée d'utilisation je pourrai me limiter pour l'instant à une durée d'environ 10-15 secondes vu que mon projet n'est qu'un prototype. Et oui j'avoue que pour les encodeurs ça coûte qd même assez cher, je préféré utilisé uniquement mon accéléromètre. Du coup, dans le cas ou le sol est parfait c'est a dire 0 pente 0 conditions défavorables, est ce que l’accéléromètre peut quand même me permettre de mesurer la vitesse du robot ? Et dans ce cas la précision est de combien? 



#9 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 05 mars 2019 - 12:17

2.5m/s, c'est très rapide pour un robot amateur (en général les robots amateurs c'est plutôt 0.1 à 0.3 m/s). En soit il suffit de mettre des moteurs assez puissants et avec un faible rapport de réduction, mais ensuite pour contrôler la trajectoire et éviter de rentrer dans un obstacle/mur, ça devient compliqué (tu traverse une pièce en 2-3 secondes). C'est sensé être un robot d'extérieur sur une grande surface (cours de récrée ...) ou d'intérieur? Dans le second cas, je te te conseille de diviser la vitesse au moins par 10 dans un premier temps (voir plus).

 

Dans des conditions totalement idéales, 0 pente, capteur parfaitement aligné, aucun bruit sur le capteur, résolution infinie, ... tu pourrais en théorie avoir une précision infinie. Mais seulement dans le pays des Bisounours. Dans la pratique, il me semble que le plus poussé dans la matière soit l'armée américaine, qui semblerait-il est en train de mettre au point des missiles inter-continentaux basés sur des accéléromètres pour ne plus être dépendant du signal GPS qui pourrait être brouillé : on parle là d'une précision de l'ordre de quelques mètres/dizaines de mètres sur un parcours de l'ordre de 10 000km. Par contre on parle d'accéléromètres qui pèsent plusieurs kg et coûtent des centaines de milliers d'euros voir des millions.

Dans la pratique, je pense que tu as au moins 1° de non alignement (pente du terrain ou capteur pas tout à fait horizontal). Du coup (en reprenant les calculs du post précédent), au bout de 10 secondes, tu aurait une errer de dv=da*t=0.17*10=1.7m/s et une erreur en position dx=0.5*da*t²=8,5 m  (et encore, je pense que tu aura plus que 1°).

Si tu achète une plaque extra plate, que tu la mets exactement à l’horizontal à l'aide d'instruments de précision, et que tu calibre ton capteur pour compenser le non alignement, alors tu arrivera peut-être à 0.1° (et encore, seulement si ton robot est super bien conçu pour que le capteur ne penche absolument pas pendant le déplacement). Dans ce cas, au bout de 10 secondes, tu aurais une erreur environ 10 fois plus petite (pour des angles aussi petit, le sinus est quasi proportionnel à l'angle (quasi égal si tu te mets en radiants)). du coup, da=0.017 m/s², dv=da*t=0.17 m/s au bout de 10s, et dx=0.5*da*t² = 0.85 m

 

Après, en pratique, je doute que tu parvienne ne serait-ce qu'à atteindre les 1°.

 

 

Je pense que la seule solution viable avec un accéléromètre est de faire 2-3 seconde grand max (quitte à aller très vite(mais du coup c'est dur de faire un asservissement, car l'inertie du robot devient non négligeable)).

 

A savoir, que si tu te contentent de mesurer la vitesse que tu obtiens pour différentes commandes, je pense que tu peux obtenir moins de 20% d'erreur (à condition de ne pas accélérer trop brutalement). Du coup, si par exemple tu te déplace à 0.2 m/s, ton erreur est dv=0.04 m/s, et ton erreur en position est dx=dv*t = 0.4 m au bout de 10 s : tu obtiens probablement de meilleurs résultats si tu te contente de mesurer la vitesse pour différentes commandes envoyées au moteur que si tu essaye de mesurer ta vitesse avec un accéléromètre.

 

 

EDIT : en gros, je pense qu'utiliser l'accéléromètre pour ton projet est une mauvaise idée. Ou alors il faut te lancer dans la version 3D qui est vraiment dégueux, et ce avec une calibration très poussée. Je suis en train de travailler sur un projet où j'essaye d'utiliser un accéléromètre sur des durées beaucoup plus longues, mais j'ai suivit un cours de 4h/semaine pendant un semestre qui en gros ne parlait presque que de comment exploiter un accéléromètre de manière optimale (j'ai pris ce cours juste pour mon projet), et ma calibration prend environ 20 minutes, et même comme ça je ne suis absolument pas convaincu que mon projet va marcher.


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#10 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 05 mars 2019 - 01:54

 

PS : @Mike118 :  C'est moi ou tu n'as aucun encodeur non monté sur un moteur dans la boutique?

 

En effet je vends essentiellement des moteurs avec codeurs pour favoriser l'apprentissage de la gestion des codeurs pour le déplacement des robots mobiles. 
Par contre j'ai des produits en stock qui ne sont pas encore affiché sur la boutique donc faut pas hésiter à demander si vous avez des demandes spécifiques. 
 

 

2.5m/s, c'est très rapide pour un robot amateur (en général les robots amateurs c'est plutôt 0.1 à 0.3 m/s). En soit il suffit de mettre des moteurs assez puissants et avec un faible rapport de réduction, mais ensuite pour contrôler la trajectoire et éviter de rentrer dans un obstacle/mur, ça devient compliqué (tu traverse une pièce en 2-3 secondes). C'est sensé être un robot d'extérieur sur une grande surface (cours de récrée ...) ou d'intérieur? Dans le second cas, je te te conseille de diviser la vitesse au moins par 10 dans un premier temps (voir plus).

 

 

2.5m/s en effet c'est très rapide pour un robot d'intérieur ... Après on parle de vitesse de pointe, rien n'empêchera le robot d'avancer plus doucement en intérieur et d'aller plus vite lorsque le trajet sera dégagé ...  0,5m/s à 1m/s c'est déjà de bonnes vitesses de pointes. 

c'est la vitesse de pointe que permet d'atteindre ce moteur avec codeur => . Voir cette discussion 

 

 

 

Dans la pratique, je pense que tu as au moins 1° de non alignement (pente du terrain ou capteur pas tout à fait horizontal). Du coup (en reprenant les calculs du post précédent), au bout de 10 secondes, tu aurait une errer de dv=da*t=0.17*10=1.7m/s et une erreur en position dx=0.5*da*t²=8,5 m  (et encore, je pense que tu aura plus que 1°).

Si tu achète une plaque extra plate, que tu la mets exactement à l’horizontal à l'aide d'instruments de précision, et que tu calibre ton capteur pour compenser le non alignement, alors tu arrivera peut-être à 0.1° (et encore, seulement si ton robot est super bien conçu pour que le capteur ne penche absolument pas pendant le déplacement). Dans ce cas, au bout de 10 secondes, tu aurais une erreur environ 10 fois plus petite (pour des angles aussi petit, le sinus est quasi proportionnel à l'angle (quasi égal si tu te mets en radiants)). du coup, da=0.017 m/s², dv=da*t=0.17 m/s au bout de 10s, et dx=0.5*da*t² = 0.85 m

 

Après, en pratique, je doute que tu parvienne ne serait-ce qu'à atteindre les 1°.

 

 

 

Je pense que tu es allé un peu vite dans tes calculs... 
Tu n'as pas une erreur de 8.5m au bout de 10 secondes non... 

De ce que j'ai compris tu as calculé le résultat théorique de la vitesse et de la distance parcourrue en ligne droite en 10s pour un robot qui commence à t = 0s à  vitesse nulle avec une accélération constante de  0,17 m/s². 

Donc dans ce cas précis oui au bout de 10 secondes le robot a en théorie parcourrue 8.5m est se trouve lancé à une vitesse 1,7m/s. 
Mais on ne parle pas ici d'erreur ... 

 

Sinon c'est que j'ai mal compris la relation entre l'angle de 1° dont tu parles et l'erreur dans la mesure d'accélération que tu supposes à 0,17m/s² ?... 

 

Revenons sur le cas théorique de l'accélération constante à 1,7m/s ... 

Supposons maintenant une erreur de 0,02 sur "l'accélération constante" . 
avec accélération comprise entre 0,15  et  0,19 m/s² . 
0,5 * 0,15 * 10 * 10  = 7,5 m 
0,5 * 0,19 * 10 * 10 = 9,5m 

Donc avec une grosse erreur de plus de 20% sur la mesure on a un écart de +- 1m sur la mesure estimée... 

Et avec 20% on est très très large sur l'erreur ... 

 

Ce que je recommande c'est de faire un banc de test sur une echelle graduée de plus 1m. 

Tu mets un chariot mobile dessus avec l'accéléromètre et tu le déplaces à la main en estimant la position via l'accéléromètre. 
Tu le déplace d'avant en arrière pendant 10s et tu t'arrêtes à un point donné et tu fais en sorte d'arrêter le programme affichant la vitesse estimée et la position estimée.
Mesure l'écart entre ta position au début et à la fin en réel par rapport à ce que ton estimation avec accéléromètre donne.

Et pour la vitesse normalement tu dois obtenir une vitesse quasi nulle ... ( normale tu seras à l'arrêt ) mais  comme il peut y avoir un peu d'erreur elle peut ne pas etre parfaitement nulle ... 

Le problème avec avec la mesure via accéléromètre c'est justement ce " quasi nul pas parfaitement nul "... 

Alors que ton robot ne se déplace pas, si les erreurs liées à l'accéléromètre te disent que le robot se déplace un petit peu, l'erreur de position va grandir au fur et à mesure alors que ton robot ne bouge pas... 

Donc si ton robot fait une pause d'1h par exemple il pourrait croire qu'il a très légèrement dérivé pendant tout ce temps alors qu'il n'en est rien ... 
D'où l'importance de savoir quand on bouge et quand on est à l'arrêt pour eviter de changer la position et d'ajouter de l'erreur quand on est à l'arrêt...
 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#11 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 05 mars 2019 - 07:33

Bonjour,

je ne pense pas m’être trompé, en tout cas pas sur le point que tu soulèves.

Par contre je n’ai eut-être pas assez détaillé.

Un accéléromètre mesure l’accélération moins la gravité (g).

 

Considérons un accéléromètre idéal (ie pas de bruit, pas d’offset) mais penché de 1° (soit car il est monté un petit peu de travers, soit car le sol est en très légère pente). Supposons pour simplifier que le robot avance en ligne droite selon x (avant) et que la pente est dans le plan xz (1° vers le haut).

 

Notons A_réel la grandeur A telle qu’elle est réellement, A_est la valeur de A estimée, dA l’erreur sur A (dA=A_est-A_réel).

 

Si l’accéléromètre est parfaitement alligné, alors on a ax_est=ax_réel, az=+g

Si maintenant on tourne l’accéléromètre de 1°, on a ax_est=cos(1°)*ax_réel – sin(1°)*g et az_est=cos(1°)*g+sin(1°)*ax_réel. A noter que notre accélération estimée correspond à celle qu’on mesure avec l’accéléromètre.

 

Cos(1°)=1 (ou presque), mais sin(1°)=0,017

Donc ax_est=cos(1°)*ax_réel – sin(1°)*g = ax_réel – 0,017*g = ax_réel – 0,17 m/s²

donc d(ax) = ax_est-ax_réel=-0,17 m/s²

 

Ensuite, soit on peut faire tout le calcul avec cette erreur de 0,17 m/s² (qui n’est de « seulement » 2 % de g, mais c’est déjà énorme) : c’est ce que j’ai fait avant et ou on obtient les 8,5m d’erreur en 10s.

Ou alors on peut faire les calculs avec ax_est et comparer avec ceux effectuer avec ax_réel : c’est ce que je vais faire si-dessous pour te convaincre :

Supposons la position et vitesse initiale parfaitement connu à t=0 : x(0) et v(0)

 

Cas idéal (on fait les calculs avec les valeurs réelles) :

ax(t)=ax_réel(t)

v_réel(t)=v(0)+intégrale(ax_réel(t))

x_réel=x(0)+v(0)*t + intégrale(intégrale(ax_réel(t))

 

Cas avec les valeurs mesurées

ax(t)=ax_est(t)=ax_réel(t) – 0,17 m/s²

v_est(t)=v(0)+intégrale(ax_réel(t)) – 0,17 * t

x_est(t)=x(0)+v(0)*t + intégrale(intégrale(ax_réel(t)) – 0,5*0,17*t²

 

Donc l’erreur en position est dx(t)=x_est(t)-x_réel(t)= - 0,5*0,17*t²

Pour t=10 s, on a donc bien dx(t=10s)=-0,5*0,17*10²=8,5 m

 

 

Le seul moyen de se débarrasser de cet horrible erreur de pente est soit de garantir qu’il n’y en a pas (ce qui nécessite un sol hyper plat et une conception mécanique parfaite), soit de passer en 3D pour pouvoir calculer la pente et la compenser.

 

 

 

Pour avoir une idée concrète de l'erreur, même pas la peine de déplacer l'accéléromètre, il suffit de poser le robot (immobile) à plusieurs endroits et lire la valeur de l'IMU sur les axes x et y : si c'est parfaitement 0 c'est bon, mais dès que c'est un tout petit peu à coté, tu cumule de l'erreur en en t²


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#12 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 05 mars 2019 - 08:04

Par rapport à la vitesse oui peut etre que c'est beaucoup, mais c'est un robot d’extérieur donc c'est normal, mais du coup si je persiste à utiliser accéléromètre pour déterminer la vitesse, et et si je diminue la durée d'utilisation et si je fais en sorte de savoir quand est ce qu'il est en arrêt et quand est ce qu'il bouge est ce que l erreur sera toujours importante ?   



#13 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 05 mars 2019 - 08:32

Si tu fais en sorte de savoir quand ton robot est à l'arrêt pour en profiter pour "recalibrer tes mesures" fournie avec l'accéléromètre tu pourras réduire l'erreur. 

Pour en revenir sur la remarque de sandro. 

=> Il est nécessaire de calibrer ton accéléromètre quand tu es à l'arrêt avant de commencer l'acquisition. 

Pour calibrer Il suffit d'éliminer toutes les " erreurs statiques " sur les 3 axes  dont celles liées à la gravitée. 

 

Si tu n'élimines pas les erreurs statiques tu peux avoir 8.5m d'erreur comme calculé par Sandro voir beaucoup plus ... 

 

Exemple simplifié pour un cas en sol plat :  

Si robot à l'arrêt : 
offset_x = brute_accel_x;

offset_y = brute_accel_y;

offset_z = brute_accel_z, 

Si robot en mouvement : 
accel_x = brute_accel_x - offset_x;

accel_y = brute_accel_y - offset_y;

accel_z = brute_accel_z - offset_z;

 

En faisant en sorte d'alligner Y ou X dans le sens du déplacement en regardant que cet axe tu sauras l'accélération lié à ta vitesse en ayant lerreur statique d'éliminée. 

 

 

 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#14 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 06 mars 2019 - 07:48

En fait pour le gyroscope qui est intégré avec l'accéléromètre il mesure la vitesse de rotation de quoi ? Je me demande si on peut l'utiliser pour mesurer la vitesse du robot ? 



#15 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 06 mars 2019 - 08:20

Il mesure la vitesse de rotation du robot sur ses différents axes. 
Si le robot se déplace en parfaite ligne droite, sans pente ni virage ( en supprimant l'erreur liée à la rotation de la terre ) les vitesses de rotations mesurées doivent rester nulles sur tout les axes =)


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#16 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 06 mars 2019 - 11:25

Bonsoir,

du coup, je suis aller faire quelques tests avec un accéléromètre (monté sur un arduino), sur le sol de ma chambre (cf image en pièce jointe). Je suis aller le poser à 6 endroits différents (qui correspondent aux plateaux). Les pics correspondent au moment où je déplace l'accéléromètre. A noter que les plusieurs lignes horizontales lors des plateaux sont du au bruit du capteur et/ou au vibrations du sol (à noter que j'ai pas cherché à adapté le calibre pour l'optimiser pour une mesure en statique). Ce bruit pourrait être éliminé en moyennant  plusieurs valeurs successives (vue que je mesure à 100Hz, je peux largement me le permettre).

 

Comment faut-il interpréter ces résultats :

- on remarque que la moyenne des plateaux est environ -0.2 m/s² : cela correspond au fait que le capteur n'est pas horizontal (il est pas monté très droit, sur y c'est plutôt -0.8m/s²), et/ou que le capteur a un offset (c'est sur qu'il en a un, mais probablement pas assez pour expliquer l'erreur sur y, probablement pas non plus toute celle sur x) et/ou que le sol de ma chambre est globalement en pente. A noter que cette erreur peut être compensée (l'offset_x vaut environ la moyenne des 6 plateaux)

- on remarque aussi des écarts de l'ordre de 0.05 m/s² entre cette moyenne des 6 plateaux et les plateaux individuels. Cette "erreur" là vient probablement du fait que le sol de ma chambre n'est pas à 100% plat. Cette erreur là ne peut pas être compensée en restant en 2D (si tu veux pouvoir la compenser, il faut utiliser le gyromètre pour connaître ton orientation en 3D pour ensuite corriger cette erreur).

 

Donc si on suppose que tu calibre ton capteur, et que ton sol est aussi plat que celui de ma chambre, alors il te restera une erreur de l'ordre de da=0.05 m/s².

Du coup dv=0.05 * t et dx=0.5*0.05*t²

Donc à t=10s, tu aurais dv=0.5 m/s et dx = 2.5 m (et à t=15s, dv=0.75 m/s et dx = 5.6m). Est-ce que ça te conviens? A toi de nous le dire, mais probablement pas.

 

A noter qu'en pratique se pose un problème similaire en y et en orientation, donc ce sera probablement encore pire.

 

 

Une autre solution consiste à faire de petites durées puis t'arrêter pour réinitialiser la vitesse avant de reprendre.

Supposons que tu t'arrêtes à chaque fois au bout de T secondes, et que tu fasse N de ces trajets.

Pour un trajet : dv(T)=0.05*T et dx(T)=0.5*0.05*T²

L'erreur en vitesse ne se cumulera pas entre les parcours, par contre les erreurs en positions continueront à se sommer (mais moins vite) :

dx(N*T)=N*dx(T) si les erreurs sont systématiques, ou dx(N*T)=racine(N)*dx(T) si les erreurs sont indépendantes. Je pense qu'en pratique tu sera quelque part entre les deux.

 

Supposons que tu veuilles rouler un temps t (on ne compte pas le temps passé à l'arrêt). Tu doit alors le faire en N=t/T étapes.

Ton erreur sera donc comprise entre dx(t)=(t/T)*dx(T)=0.5*0.05*T*t et dx(t)=racine(t/T)*dx(T)=0.5*0.05*T^(3/2)*t^(1/2)

Si on prend T=1 (tu t'arrête au bout d'une seconde) et t=10, alors tu es entre dx=0.25m et dx=0.08m

Si on prend T=2 (tu t'arrête au bout de 2 secondes) et t=10, alors tu es entre dx=0.5m et dx=0.22m

 

Là pour le coup, on se rapproche de quelque chose de plus acceptable (à toi de nous dire si ça peut faire l'affaire ou non)?

 

Attention, plusieurs points peuvent empirer le résultat :

- si ton robot roule à 2.5 m/s en extérieur, il risque de parcourir une distance assez importante, augmentant le risque que la pente change un peu

- en extérieur, le sol est souvent moins plat qu'en extérieur

- à cette vitesse, tu risque d'avoir des vibrations dans le robot, qui risquent de rajouter du bruit (je sais pas si c'est négligeable ou pas)

- là j'ai pris que en x, mais tu as la même chose en y (du coup pour l'erreur totale tu multiplie par racine carrée de 2)

- et surtout, j'ai supposé que le robot allait bien droit : si tu commence à tourner, tu doit le prendre en compte dans les calculs (le changement de référentiel de celui du robot vers le référentiel lié au sol). Pour cela il faut utiliser ton gyro, mais lui aussi à des erreurs. Le gyro de donne la vitesse de rotation, que tu intègre pour obtenir ton angle de rotation. Si tu as une erreur de 1° sur la direction dans lequel tu avance, et que tu avance 10m, tu te retrouve décalé de dy=sin(1°)*10m=0.17m

 

 

Si j'ai bien compris, tu as déjà ton accéléromètre/gyro? Si c'est le cas, alors je te suggère de faire un test similaire à celui que j'ai fait (ie prendre ton capteur, le poser à divers endroit au sol, et mesurer les valeurs d'accélération ET celles du gyro, sur les 3 axes). Je te conseille de mesurer en continu, et de laisser ton capteur posé pendant 10 secondes à chaque endroit : on identifie ensuite très facilement sur le graphique quand est ce qu'il bouge ou pas.

Avec ces données, il sera possible d'estimer les erreurs que tu peux espérer atteindre avec ton robot en utilisant l'accéléromètre. Si tu as besoin d'aide pour les interpréter, n'hésite pas à demander.

 

 

 

Sinon, est-ce que ton robot est déjà construit? Les pièces sont-elles déjà commandées? Si oui, est-ce que tu pourrais envoyer des photos (en particulier des roues et des moteurs)?

Je te demande cela en pensant à une forme artisanale et très bon marché d'encodeurs : tu prends une LED et une photodiodes que tu mets fasse à fasse, et entre les deux tu fais passer une "roue" avec des trous, et tu mesure le temps entre 2 passages de trous. Sachant que la roue peut soit être celle que tu utilise déjà (si c'est une roue à rayons ou qu'elle a des trous ou que tu peux en percer), soit un simple disque en carton que tu attache d'une manière ou d'une autre à l'axe (ce qui peut être plus ou moins facile/difficile selon comment est construit ton robot).

Ce ne sera pas super précis, mais l'erreur en vitesse ne se cumulera pas sans avoir à t'arrêter. A noter qu'il te faudra aussi 4 résistances (ça ton labo de physique en a très probablement en stock). Il est aussi possible qu'il te faille un moyen de convertir le signal analogique de la photodiode en un signal binaire (ie soit un comparateur, soit un convertisseur analogique numérique, soit un clone d'arduino (tu en pour 6€ sur la boutique)). Mais probablement en testant un peu tu peux te passer de cette conversion et envoyer le signal analogique directement sur une pin numérique du raspberry pi qui la considérera comme 0 si elle est en dessous d'un certain seuil et comme 1 si elle est au dessus (et c'est la seule chose qui nous intéresse). Si ça passe sans convertisseur, alors tu en as pour moins de 10€, il est même possible que ton labo ait déjà tout en stock (à noter qu'une photorésistance ou un phototransistor peut remplacer la photodiode).

 

Bonne soirée

Sandro

 

 

 

Fichier(s) joint(s)

  • Fichier joint  accel_x.jpg   25,63 Ko   0 téléchargement(s)

Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#17 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 07 mars 2019 - 10:03

Petit lien qui peut aider  éventuellement aider : 
Accéléromètres et Applications 
 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#18 Survivor9898

Survivor9898

    Membre

  • Membres
  • 14 messages

Posté 09 mars 2019 - 11:17

Bonsoir,

du coup, je suis aller faire quelques tests avec un accéléromètre (monté sur un arduino), sur le sol de ma chambre (cf image en pièce jointe). Je suis aller le poser à 6 endroits différents (qui correspondent aux plateaux). Les pics correspondent au moment où je déplace l'accéléromètre. A noter que les plusieurs lignes horizontales lors des plateaux sont du au bruit du capteur et/ou au vibrations du sol (à noter que j'ai pas cherché à adapté le calibre pour l'optimiser pour une mesure en statique). Ce bruit pourrait être éliminé en moyennant  plusieurs valeurs successives (vue que je mesure à 100Hz, je peux largement me le permettre).

 

Comment faut-il interpréter ces résultats :

- on remarque que la moyenne des plateaux est environ -0.2 m/s² : cela correspond au fait que le capteur n'est pas horizontal (il est pas monté très droit, sur y c'est plutôt -0.8m/s²), et/ou que le capteur a un offset (c'est sur qu'il en a un, mais probablement pas assez pour expliquer l'erreur sur y, probablement pas non plus toute celle sur x) et/ou que le sol de ma chambre est globalement en pente. A noter que cette erreur peut être compensée (l'offset_x vaut environ la moyenne des 6 plateaux)

- on remarque aussi des écarts de l'ordre de 0.05 m/s² entre cette moyenne des 6 plateaux et les plateaux individuels. Cette "erreur" là vient probablement du fait que le sol de ma chambre n'est pas à 100% plat. Cette erreur là ne peut pas être compensée en restant en 2D (si tu veux pouvoir la compenser, il faut utiliser le gyromètre pour connaître ton orientation en 3D pour ensuite corriger cette erreur).

 

Donc si on suppose que tu calibre ton capteur, et que ton sol est aussi plat que celui de ma chambre, alors il te restera une erreur de l'ordre de da=0.05 m/s².

Du coup dv=0.05 * t et dx=0.5*0.05*t²

Donc à t=10s, tu aurais dv=0.5 m/s et dx = 2.5 m (et à t=15s, dv=0.75 m/s et dx = 5.6m). Est-ce que ça te conviens? A toi de nous le dire, mais probablement pas.

 

A noter qu'en pratique se pose un problème similaire en y et en orientation, donc ce sera probablement encore pire.

 

 

Une autre solution consiste à faire de petites durées puis t'arrêter pour réinitialiser la vitesse avant de reprendre.

Supposons que tu t'arrêtes à chaque fois au bout de T secondes, et que tu fasse N de ces trajets.

Pour un trajet : dv(T)=0.05*T et dx(T)=0.5*0.05*T²

L'erreur en vitesse ne se cumulera pas entre les parcours, par contre les erreurs en positions continueront à se sommer (mais moins vite) :

dx(N*T)=N*dx(T) si les erreurs sont systématiques, ou dx(N*T)=racine(N)*dx(T) si les erreurs sont indépendantes. Je pense qu'en pratique tu sera quelque part entre les deux.

 

Supposons que tu veuilles rouler un temps t (on ne compte pas le temps passé à l'arrêt). Tu doit alors le faire en N=t/T étapes.

Ton erreur sera donc comprise entre dx(t)=(t/T)*dx(T)=0.5*0.05*T*t et dx(t)=racine(t/T)*dx(T)=0.5*0.05*T^(3/2)*t^(1/2)

Si on prend T=1 (tu t'arrête au bout d'une seconde) et t=10, alors tu es entre dx=0.25m et dx=0.08m

Si on prend T=2 (tu t'arrête au bout de 2 secondes) et t=10, alors tu es entre dx=0.5m et dx=0.22m

 

Là pour le coup, on se rapproche de quelque chose de plus acceptable (à toi de nous dire si ça peut faire l'affaire ou non)?

 

Attention, plusieurs points peuvent empirer le résultat :

- si ton robot roule à 2.5 m/s en extérieur, il risque de parcourir une distance assez importante, augmentant le risque que la pente change un peu

- en extérieur, le sol est souvent moins plat qu'en extérieur

- à cette vitesse, tu risque d'avoir des vibrations dans le robot, qui risquent de rajouter du bruit (je sais pas si c'est négligeable ou pas)

- là j'ai pris que en x, mais tu as la même chose en y (du coup pour l'erreur totale tu multiplie par racine carrée de 2)

- et surtout, j'ai supposé que le robot allait bien droit : si tu commence à tourner, tu doit le prendre en compte dans les calculs (le changement de référentiel de celui du robot vers le référentiel lié au sol). Pour cela il faut utiliser ton gyro, mais lui aussi à des erreurs. Le gyro de donne la vitesse de rotation, que tu intègre pour obtenir ton angle de rotation. Si tu as une erreur de 1° sur la direction dans lequel tu avance, et que tu avance 10m, tu te retrouve décalé de dy=sin(1°)*10m=0.17m

 

 

Si j'ai bien compris, tu as déjà ton accéléromètre/gyro? Si c'est le cas, alors je te suggère de faire un test similaire à celui que j'ai fait (ie prendre ton capteur, le poser à divers endroit au sol, et mesurer les valeurs d'accélération ET celles du gyro, sur les 3 axes). Je te conseille de mesurer en continu, et de laisser ton capteur posé pendant 10 secondes à chaque endroit : on identifie ensuite très facilement sur le graphique quand est ce qu'il bouge ou pas.

Avec ces données, il sera possible d'estimer les erreurs que tu peux espérer atteindre avec ton robot en utilisant l'accéléromètre. Si tu as besoin d'aide pour les interpréter, n'hésite pas à demander.

 

 

 

Sinon, est-ce que ton robot est déjà construit? Les pièces sont-elles déjà commandées? Si oui, est-ce que tu pourrais envoyer des photos (en particulier des roues et des moteurs)?

Je te demande cela en pensant à une forme artisanale et très bon marché d'encodeurs : tu prends une LED et une photodiodes que tu mets fasse à fasse, et entre les deux tu fais passer une "roue" avec des trous, et tu mesure le temps entre 2 passages de trous. Sachant que la roue peut soit être celle que tu utilise déjà (si c'est une roue à rayons ou qu'elle a des trous ou que tu peux en percer), soit un simple disque en carton que tu attache d'une manière ou d'une autre à l'axe (ce qui peut être plus ou moins facile/difficile selon comment est construit ton robot).

Ce ne sera pas super précis, mais l'erreur en vitesse ne se cumulera pas sans avoir à t'arrêter. A noter qu'il te faudra aussi 4 résistances (ça ton labo de physique en a très probablement en stock). Il est aussi possible qu'il te faille un moyen de convertir le signal analogique de la photodiode en un signal binaire (ie soit un comparateur, soit un convertisseur analogique numérique, soit un clone d'arduino (tu en pour 6€ sur la boutique)). Mais probablement en testant un peu tu peux te passer de cette conversion et envoyer le signal analogique directement sur une pin numérique du raspberry pi qui la considérera comme 0 si elle est en dessous d'un certain seuil et comme 1 si elle est au dessus (et c'est la seule chose qui nous intéresse). Si ça passe sans convertisseur, alors tu en as pour moins de 10€, il est même possible que ton labo ait déjà tout en stock (à noter qu'une photorésistance ou un phototransistor peut remplacer la photodiode).

 

Bonne soirée

Sandro

 

 

 

 

Bonjour, merci d'avoir pris le temps de faire une expérience pour m'éclaircir les choses =) 

Pour la vitesse j'ai essayé de trouver un ordre de grandeur et je me suis rendu compte que je l'avais surestimé , en fait c'est plutôt environ 1m/s. 

Et oui on a déjà construit notre robot ( binôme ) d'ailleurs je te mets des photos juste en dessous. Vu que mon robot représente une sorte de prototype, normalement dans le cadre de mon tipe, je ne suis pas obligé d'avoir quelque chose de très sophistiqué, normalement la mesure de la vitesse devrait me permettre de l'asservir et donc d'appliquer une partie de notre programme de SI dans la pratique. Donc c'est vraiment l'apport scientifique qui est important pour moi. Hier j'ai essayé de faire une mesure avec l’accéléromètre juste pour avoir une idée de son fonctionnement, j'ai pu remarquer qu'on pouvait choisir le nombre de mesures effectuées par unité de temps, mais du coup je voulais savoir quand on met par exemple 1 mesure tous les 5 secondes, est ce que ca mesure l’accélération à l'instant t = 5s , t= 10s, t=15s etc ou est ce que ca fait une sorte de moyenne des 5 premières secondes pour la première valeur puis une moyenne de de t=5s à t=10s pour la 2ieme valeur etc  ? 

Ensuite est ce que c'est normal que ça affiche des valeurs super grandes ? genre de l ordre de 1000 des fois pour une accélération, je suppose que c'est parce qu’il n'est pas calibré c'est ça ? Si c'est le cas comment je peux le calibrer ?

Enfin vu que mon but n'est pas l'accélération mais la vitesse, pour intégrer faut-il utiliser une simple méthode des trapèzes ? ou est ce que c'est plus dur que ça ?

 

 

53711553_423657468396520_787023594164060

 

 

 

Petit lien qui peut aider  éventuellement aider : 

Accéléromètres et Applications 
 

 J'arrive pas à accéder au lien :/ ( page introuvable )



#19 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 963 messages
  • Gender:Male
  • Location:Anglet

Posté 09 mars 2019 - 11:32

Le lien a été corrigé. 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#20 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 260 messages
  • Gender:Male

Posté 09 mars 2019 - 04:37

Bonjour,

 

Merci pour la photo. Est-ce que tu penses que tu pourrais aussi m'ajouter une photo d'une roue vue de coté? (si l'alternative d'un encodeur fait maison t'intéresse potentiellement, sinon pas la peine).

 

Pour les 1 mesures toutes les N secondes, je penses que c'est les valeurs à l’instant t, pas une moyenne (d'après la datasheet (https://www.invensen...-Datasheet1.pdf, voir p13), tu peux ajouter un filtre passe bas, mais avec une fréquence de coupure entre 5 et 260 Hz, donc aucune chance que ce soit ça pour toutes les 5 secondes (0.2Hz) sauf si en plus t'as un passe bas numérique dans ton programme).

 

De toute façon, en listant l'accélération toutes les 5 secondes, tu n'arriveras à rien (imagine que tu es à l'arrêt à t=0s, puis tu roule pendant 4.5s et puis tu t'arrête : tu ne te rendrais même pas compte que tu as bougé!!!). Il faut au contraire lire l'accéléromètre aussi souvent que possible (je te conseille de lire au moins à 100 Hz : plus tu lis souvent, moins tu as de temps entre deux lectures, et mieux tu approxime ta vitesse/position).

 

Pour les valeurs que tu lis, probablement normal, car l'unité est probablement pas le m/s², pour la simple raison que travailler avec des nombres à virgule est peu pratique pour les capteurs, du coups ils utilisent des unités qui permettent de renvoyer un entier.

Si tu regardes la datasheet page 13, tu verra qu'en fonction du choix de la plage de mesure (AFS_SEL), tu as une correspondance entre la valeur et l'accélération (donné dans la partie "Sensitivity Scale Factor") :

 

AFS_SEL=0   16384 LSB/g

AFS_SEL=1   8192   LSB/g

AFS_SEL=2   4096   LSB/g

AFS_SEL=3   2048   LSB/g

 

Si par exemple tu choisis une plage de mesure de +-2g (la plus petite, que je te conseille car tu ne vas probablement pas accélérer à plus de 9.81m/s²), ce qui correspond à AFS_SEL=0, alors tu as 16384 LSB/g, ce qui veut dire qu'une accélération de 1g (ie 9.81m/s²) correspond à une valeur de 16384.

Donc pour obtenir ta vitesse en m/s², tu doit multiplier ton nombre par g=9.81 et diviser par 16384.

 

Si tu as une plage differente de AFS_SEL=0, alors tu prends a valeur correspondante.

Un bon moyen de vérifier que tu as pas fait d'erreur, c'est de mesurer l'accélération sur les 3 axes (avec le capteur immobile), de convertir pour chaque axe, et d'en prendre la norme : tu dois obtenir g=9.81m/s² à peu de chose près

 

A noter que si tu ne vas pas lire directement le capteur, mais que tu passes par une librairie, alors il faut vérifier si celle-ci fait des conversions ou pas.

 

 

Sinon,  pour l'intégration, je suppose que ce qui t'intéresse, c'est la vitesse du robot dans le référentiel du sol?

Si c'est bien ça, alors tu ne peux pas intégrer directement les accélérations en x et en y, car ils correspondent aux axes et y du référentiel lié au robot (du coup tu serais oublié de rajouter toutes les forces d'inerties dues au fait que c'est un référentiel non galiléen).

La solution la plus simple est de projeter l'accélération dans le référentiel du sol, puis de faire l'intégration dans celui-ci, qui est galiléen. Ce coup-ci, une intégration par trapèze est très bien (à condition d'utiliser un delta_t assez petit, d'où mon conseil de mesurer au moins à 100Hz (delta_t=0.01s)).

Pour pouvoir projeter tes accélérations, tu dois connaître l'orientation de ton robot, ce que tu peux faire en intégrant (trapèze) la vitesse de rotation autour de l'axe vertical (gyro).

 

Voici un pseudo code :

NB : toutes les variables sont supposées être en unités du système international

NB : je te mets un pseudo code avec le méthode des rectangles (ie j'utilise juste la valeur courante) pour plus de simplicité, mais l'idéal est de l'adapter pour la méthode des trapèzes.

NB : j'ai supposé que les fonctions pour lire la valeur de l'accéléromètre ou du gyroscope se chargent à la fois de prendre en compte les effets de la calibration (à effectuer au préalable) et de la conversion vers les unites du système u=internationnal)

 

t_precedent=temps_courant();   //lire le temps courant (depuis le lancement du programme)

alpha=0;    // angle du robot dans le référentiel du sol

a_x_s=0;   //accélération selon l'axe x du référentiel lié au sol

a_y_s=0;   //accélération selon l'axe y du référentiel lié au sol

v_x_s=0;   //vitesse selon l'axe x du référentiel lié au sol

v_y_s=0;   //vitesse selon l'axe y du référentiel lié au sol

x_s=0;   //position selon l'axe x du référentiel lié au sol

y_s=0;   //position selon l'axe x du référentiel lié au sol

 

boucle_inifine :

  t=temps_courrant();

  dt=t-t_precedent;

  alpha=alpha + dt*lire_gyro_z();  //intégrer la vitesse de rotation autour de l'axe z

  a_x_r=lire_acceleration_x();   //lire l'accélération selon l'axe x du référentiel de l'accéléromètre

  a_y_r=lire_acceleration_y();   //lire l'accélération selon l'axe y du référentiel de l'accéléromètre

  a_x_s=cos(alpha)*a_x_r - sin(alpha) * a_y_r;   //changement de référentiel : rotation

  a_y_s=sin(alpha)*a_x_r + cos(alpha) * a_y_r;   //changement de référentiel : rotation

  v_x = v_x + dt * a_x_s;   //intégrer la vitesse en x

  v_y = v_y + dt * a_x_y;   //intégrer la vitesse en x

  x = x + dt * v_x_s;   //intégrer la position en x

  y = y + dt * v_y_s;   //intégrer la position en y

  t_precedent=t;  //sauvegarder le temps

  //si besoin attendre ou faire autre chose

fin de la boucle

 

Bonne journée

Sandro


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.





0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users