27 réponses à ce sujet

[ashira]

Ce soir commence mes vacances, je me suis fait un truc pour me motiver à faire des équations mécaniques!

Voilà la chose à mettre en équation:




C'est donc 2 segments avec une masse à chaque bout et un seul moteur liant les 2 segments. J'ai choisit un servomoteur pour la simplicité de construction, mais pas sur qu'au final ce soir un bon choix. Un gyroscope et accéléromètre sont placés au bout du segment 1. Je vais aussi mesurer l'angle entre les 2 segments grâce au potar du servo. Le tout est relié au sol par 2 roulements.
A la fin dans l'idéal ce serai de faire tenir ça en équilibre vertical.

Ça risque de sortir des chapitres que j'ai vu en cours mais ce n'est pas grave, le principal c'est de s'amuser avec ça!

Voilà comment ça se tortille avec un programme vite fait



Je sais pas si on s'en rend compte, mais avec les grandes amplitudes ça a beaucoup d'inertie!

Dans un premier temps je pense essayer d'obtenir l'accélération à appliquer à la masse du haut pour compenser l'accélération de la masse du bas.

Puis de faire revenir petit à petit le segment du haut verticale.

Qu'en pensez vous ?

[Mike118]

Intéressant ! =) 

En tout cas ce qui est sûr c'est que ça sort des classiques ... Si tu veux tu peux regarder les " doubles pendules inversés " c'est pas la même configuration mais l'effet cherché et le même. ( équilibrer deux segments ) Tu auras pas mal d'équation à toi de voir pour adapter à ton cas =). 
Là comme ça je me demanderais pas mal de boulot et même de me re-pencher dans mes cours pour définir le modèle physique dynamique =) calcul du moment d'inertie etc... 
Nécessaire pour définir une loi de commande =) . 

Limite je crois que perso j'essaierais même de faire par une méthode d'apprentissage plutôt que de faire le modèle ^^ en mode crabeel de bobox ^^   d'ailleurs ça serait intéressant de comparer =) les résultats ! Bobox? Tu nous présent un bout de ton code d'apprentissage pour qu'on l'adapte au bras d'ashira ?  

[ashira]

C'est vrai la méthode par apprentissage c'est aussi intéressant! Et ça nécessite pas de modèle pour démarrer ?

Je pense que si je garde le servo je vais devoir au moins gérer sa vitesse car sinon le moindre mouvement si les segments sont en équilibre va tout déséquilibrer, et tout ça sans délais dans le programme.
Avec le programme de la video, la boucle se répète à 230Hz. Sachant que le servo est actualisé tous les 50Hz, ça me laisse un peu de marge de calcul avec la petite arduino.

[Path]

Très intéressant !! Mais si tu n'as pas de translation sur la base, tu ne vas pas être bloqué pour trouver un équilibre ?

[Mike118]

Pour l'apprentissage ça ne demande pas de modèle " dynamique " à proprement parler, comme on le ferait pour faire l'asservissement du système. 

Par contre de manière simplifié, en générale pour l'apprentissage ( et quelque soit les méthode utilisées, combinée ou non,  aléatoire, réseau de neurone, renforcement,  algorithme génétique, logique floue, etc... ) tu mets en place un " modèle " qui va avoir des entrées, ( données capteurs, position courant du servo, vitesse du servo ... ) et des coefficients pour faire un calcul avec les entrées afin de générer la consigne.  Tu n'as pas besoin de connaitre ces coefficient  car le but de l'apprentissage c'est qu'ils se règlent par eux même.... Par contre il faut que tu définisse les entrées, et définir une façon de " scorer" le résultat obtenu pour savoir si il est mieux que le précédent set ou pas etc ... 
Pour un réseau de neurone il va falloir déterminer le nombre de neurone et de couche, pour un algo génétique définir les gènes, la méthode de sélection, a méthode de filiation, les mutations aléatoires, etc... 

Après il vaut mieux chercher les explications plus détaillés sur les différentes méthode pour en savoir plus, mes cours commencent à être loin et en dehors du robot suiveur que j'ai fais en Angleterre en 2015 je n'ai pas eu l'occasion d'e ré-appliquer mes cours depuis =) 

Sinon concernant la notion d'équilibre, mon instinct me dis que si les frottement son réellement négligeable sur l'axe du bas ( grâce au roulement ) l'équilibre s'obtiendra grâce à une légère oscillation du bras... et je ne suis pas convaincu qu'un servomoteur soit la meilleur solution pour cela... Mais peut être que si ? Qui sait ! on le verra bientôt j'espère ! 



 

[ashira]

Bloqué je ne pense pas, mais ça complique^^ c'est comme se mettre sur les talons et chercher à rester en équilibre juste avec le bassin, sans faire de pas.

Ce serait bien de faire les deux, par étude dynamique et par apprentissage pour voir lequel s'en sort le mieux

J'ai des doutes aussi pour le servo. Car même si j'ai un contrôle sur la vitesse, sa résolution reste à 1° et ça ne sera peut être pas suffisant. Du coup j'avais pensé à virer l'électronique et mettre un pont en h et l'asservire. On verra bien^^

[Mike118]

En théorie pur j'ai envie de dire que si le modèle dynamique est parfaitement fait tu auras directement le meilleur résultat en paramétrant l'asservissement qui va bien =)  
Sauf que toute erreur dans le modèle : répartition des masse différentes , modèle de réponse du moteur imparfait par rapport à la réalité  etc...  va avoir un impact négatif sur l'équilibrage du système.  ( Oscillation un peu plus importante que ce qu'on aurait pu avoir avec un système parfait par exemple )
L'avantage de l'apprentissage c'est que si le modèle de l'apprentissage est bien fait, normalement le système doit converger vers un optimum qui peut être mieux que l'application de l'asservissement fonctionnant en simulation  sur le modèle théorique ,  sur le système imparfait réel. Car l'apprentissage va aussi permettre de compenser les écarts qu'on a entre le système réel et le modèle =). 
Par contre si le modèle d'apprentissage et mal réglé on peut ne jamais avoir de bon résultat ... En fait on ne sait pas trop ce qu'on va obtenir et en général par la suite ça s'utilise comme étant une " black box" qui fait son job sans qu'on puisse regarder trop ce que ça fait dedans ... alors que tu peux toujours affiner ton modèle dynamique théorique pour affiner un peu tes résultats ... 

 

Bref les deux méthodes restent intéressante et mérite d'être comparée =) 

 

Par contre si tu va pour démonter le servo et ajouter un pont en H tu commences à aller loin autant utiliser un moteur avec un encodeur directement monté dessus ^^ 

 

[ashira]

D'accord, donc si on mixe les 2 ça fait quelque chose qui fonctionne de base et qui s'améliore en continue ! Ce serait super^^

Je commence à chercher l'équation dès demain. Comme je ne pense pas trouver le bon résultat du premier coup je vais sûrement utiliser quelque chose comme matlab.

[Mike118]

Tu peux aussi essayer d'utiliser V rep éducation. C'est un simulateur physique qui te permet de modéliser te objets, leur donner un poids etc... et tu peux rajouter un moteur et écrire un script =) . 

et pour revenir au fait d'utiliser les deux tu peux faire l'étude dynamique pour obtenir la forme de la solution , ( une forme de solution mais pas forcement avec les bonnes valeurs etc... ) et te servir de cette forme pour t'aider à bien définir ton modèle d'apprentissage de manière à ce qu'il trouve les bonnes valeurs =) 

 

[Oracid]

Génial !
Je suppose que quand Mike parle d'une méthode d'apprentissage, il s'agit d'auto-apprentissage ?

[ashira]

Oui c'est bien ça, un peu comme Bobox a fait avec son crabeel!

[Oliver17]

Excellent !!!

 

Question de noob (mieux vaut paraître idiot 5 mn que toute ça vie) , quel intérêt d'avoir un moteur avec encodeur ? 

 

- Moins de jeu (voir pas du tout) ?

- Une plus grande précision ?

- Un retour d'angle ?

- ...

 

Donc par la suite, si les moteurs avec encodeurs sont intéressants, pourquoi ne pas se servir de ça pour nos montages de robots plutôt que des servomoteurs ?

 

Merci (sans vouloir polluer le post)

[ashira]

L'intérêt de lire le potar permet d'être plus précis car dans la programmation tu inquiques l'angle du servo par pas de 1 degrés. En utilisant la valeur du potar sur une arduino nano par exemple tu n'as plus 180 valeurs possibles mais 1024. Donc ça fait un pas de 180/1024 = 0.17 degrés.

Et je vais peut être avoir besoin de lire l'angle en "temps réel" pour les calculs.

[Bobox]

Si je ne me trompe pas, un servo moteur c'est juste un moteur avec un potentiometre.

La reponse est donc la difference entre un moteur+encodeur et un moteur+potentiometre.

Avec un encodeur tu as la Vitesse exacte du moteur, mais pas son angle actuel, tu ne peux que l'estimer en integrant les vitesses mesurees.

Avec un potentiomètre tu as l'Angle exacte du moteur, mais tu n'as pas sa vitesse, a nouveau tu ne peux que l'estimer, cette fois ci en derivant l'angle.

 

Donc en faite le choix dépend de la variable que tu veux la plus précise.

[Path]

Avec un encodeur, tu peux compter les pas. Avec une grosse réduction, tu as du couple et des pas plus faibles.

[Oliver17]

@ Ashira : Ok, ça j'avais pigé pour le pas à pas de 1° sur les servomoteurs, (en fait je l'ai vite remarqué en testant), et d'ailleurs c'est clair que c'est chiant cette histoire.

 

Et je vais peut être avoir besoin de lire l'angle en "temps réel" pour les calculs.

 

 

Ah ce fameux retour d'angle, le ptit fils à souder sur le potard ^^ (on y revient, on y revient).

 

 

@ Bobox : Ok, clair net précis, merci

Pour la vitesse sur un servomoteurs j'ai un collègue maker qui m'a donné un truc pour gérer ça avec le temps ^^

 

Sinon je préfère une valeur d'angle précise que le retour de vitesse. 

 

 

@ Path : Tiens justement je parlais de toi lol

 

Donc en fait j'avais une question, mais je crois que tu viens d'y répondre, je la pose quand même.

 

Ne peut on pas ajouter un potentiomètre avec l'encodeur sur un moteur pas très rapide, ce qui permet de pouvoir récupérer ces valeurs (angles) sans trop de pertes de précision ?

 

Par contre se genre de chose (moteur + encodeur) n'aidera peut être pas Ashira si la vitesse est trop importante et qu'il ne puisse pas récupérer comme il se doit le retour d'angle. ?

 

PS : juste comme ça, et donc le jeu d'un moteur + encodeur est plus important (ou moins) qu'un servomoteur. ?

 

Merci

[Path]

Pour moi, c'est moteur cc + réducteur + (potentiomètre ou encodeur). Encodeur, tu compte les pas ou tu intègre la vitesse. Potar, tu lis directement. C'est plus simple pour un angle. En fait c'est ce que bobox dit.
Avantage de l'encodeur, on peut l'asservir modulo 360 degrés.

[Mike118]

Bon je crois qu'on va devoir faire une petite fiche qui explique les différents moteurs, les avantages les incovénients etc... =) 

 

Pour en revenir avec les moteurs à encodeurs, tu va savoir de combien il se déplace à leur valeur de résolution près. ( à chaque tick d'encodeur ) ça permet donc de connaître précisément ta position relative, par rapport à la position de départ.  ( Par contre si tu t'intéresse à une position absolue , il est nécessaire de connaitre ta position de départ pour savoir où tu es exactement, d'où une phase d'initialisation par exemple si besoin , l'ajout d'un idex aussi sur l'encodeur est faisable ... Après il existe aussi de encodeurs absolu ... Ou on peut aussi utilise potentiomètre + encodeur ... . )

En mettant un encodeur avant le réducteur, tu peux avoir une très bonne résolution ( exemple 0.01 ° )  tu vas pouvoir être très précis, et contrôler un système tel que celui d'ashira avec de très faibles oscillations. 

Avec un servomoteur  ( / potentiomètre pour mesurer l'angle) un tu seras moins précis en terme de position " numérique " .... 

Je ne reviens pas sur les avantages d'un asservissement tout analogique qui dans certains cas est aussi très pratique ( voir le robot "RMAD le robot fou ", un robot suiveur en tout analogique que j'ai fait en 2012 ) 
 

[Oliver17]

Oui Mike, je veux bien une petite fiche, puis se sera un plus pour le site ^^ (pour aider les pauvres noob comme moi), ceci dis, j'avais lu des trucs sur le sujet des moteurs and co, mais, hum, ma ptite tête à du mal à retenir toutes les infos depuis que je suis inscrit sur le site ^^

 

Ok pour la résolution avec l'encodeur avant le réducteur, en effet là c'est super précis, faudrait limite faire comme Leon sur Bob5, en regardant ces photos (et si je dis pas de conneries), on voit le moteur, le réducteur, l'encodeur et le potard si je me plante pas.

Ce qui fait en théorie un super retour d'informations...(dommage pour le jeu qu'il a pu avoir).

 

http://www.robot-maker.com/forum/uploads/monthly_02_2017/post-1630-0-63903500-1487423142.jpg

 

PS : bon j'arrête mon mode troll et de polluer le post d'Ashira (je pense que j'étais tout de même dans le sujet pour bien entendu l'aider à faire sont choix entre jouer avec le potar ou l'encodeur ^^).

 

Merci

[Leon]

Ok pour la résolution avec l'encodeur avant le réducteur, en effet là c'est super précis, faudrait limite faire comme Leon sur Bob5, en regardant ces photos (et si je dis pas de conneries), on voit le moteur, le réducteur, l'encodeur et le potard si je me plante pas.

Effectivement, sur BOB5, il y avait à la fois des potentiomètre et encodeurs. Les potentiomètre pour avoir une position "absolue" sans avoir à faire de recalage à l'initialisation.

Les encodeur au cul du moteur, donc avec une résolution énorme, c'est très bien pour faire des asservissements performants, qui tournent rapidement. Un asservissement de type PID rapide a besoin d'une estimation précise de la vitesse, mise à jour en temps réel. Par exemple, pour un asservissement qui tourne à 100Hz, il faut que toutes les 10ms, il y ait eu suffisamment de "tops" pour obtenir une estimation de la vitesse.

Avec un potentiomètre, c'est quasi impossible à réaliser car la "résolution" n'est pas suffisante. Un encodeur au cul du moteur, c'est ce qu'ont tous les robots industriels, asservis avec des PID.

 

Leon.