140 réponses à ce sujet

[Path]

Tiens-toi droit, Pas bouger, Regarde devant toi, Ash !!

 

Si je te suis, Mike, l'asservissement polaire me servira à tourner. Je ne pourrais pas m'en passer.

On dit jamais 2 sans 3

- Vertical

- Distance

- Polaire

 

Je vois comment calculer les 3 pid unitairement.

Je ne sais pas encore comment assembler les 3.

Et Transistance non plus (ou j'ai rété un truc)

        // appliquer les commandes aux moteur
        PWMG = cmd_dist - cmd_orient;        // ça ne doit surement pas fonctionner de cette façon
        PWMD = cmd_dist + cmd_orient;

Mon intuition me dit que c'est une simple somme des 3 pids.

 

Reste ce "Locked Antiphase" qui semble sympa aussi mais pour ce matin, c'est trop pour mon petit cerveau

 

PS Et promis je mettrai Ash dans le robotscope.

... promis aussi un tuto instalaltion du raspberry avec nodeJS

[Mike118]

Il y a différentes façon de faire. 
Tout sommer, faire des boucles imbriquées, faire des boucles parallèles indépendantes avec consigne décomposées et d'autres encore...  Je connais plusieurs théories et j'en ai déjà testé quelques unes =) mais je ne saurais te dire quelle technique est la meilleur si tant est qu'il y en ait une meilleurs que l'autre.

 

Concernant le " locked antiphase " c'est un mode d'excitation des moteurs qui permet de bloquer les roues en exerçant "un couple apparent de blocage" en faisant très rapidemement changer le sens de rotation du moteur. 
Grosso modo à l'arrêt au lieu d'avoir un PWM de 0 en temps haut. On a 50 % dans un sens et 50% dans l'autre sens. et ce tellement rapidement que du coup les roues ne bouges pas.   et quand tu veux avancer tu 80% dans un sens et 20% dans l'autre par exemple ... Et pour la pleine vitesse : 100% 0% ...

Si tu n'as pas d'idées sur comment intégrer cela je te suggère d'essayer de couper un moteur et d'essayer de régler ash pour qu'il essaye de tenir l'équilibre avec un seul moteur  pour voir comment il se comporte ... puis ensuite d'essayer de l'asservir "angulairement " comme tu l'as fait pour " qu'il ne bouge plus" . 

Quelque soit la façon choisie , une bonne façon de se représenter la chose est de faire un schémas bloc faisant bien apparaître les différentes consignes, les ordres envoyés aux deux moteurs et les valeurs mesurées par les capteurs pour faire les boucles de retour, les erreurs et les correcteurs. 
Je te laisse faire quelque proposition de schémas bloc ( ce qui est dommage c'est que de mémoire, le dernier qu'avait proposé transistance était plutôt pas mal ... ) et je serais là pour en discuter

Par contre rassure toi : ta peine ne fait que commencer!

Spoiler

Et même quand tu auras enfin un robot stable qui pourra être commandé indépendamment en position en translation et en rotation, tout en tenant l'équilibre il te restera encore des étapes : l'asservissement en vitesse, la définition de trajectoire pour aller d'un point A à un point B avec optimisation en utilisant des splines etc... mais bon on en reparleras quand ash va tenir droit sans bouger

[Path]

C'est mon premier robot hein ^^.

Je vais devoir limiter le challenge si je veux aboutir  

Je serai content quand il se tiendra debout, trouvera une secteur assez large pour lui, avancer de la distance trouvée dans l'axe trouvé et recommencer.

Ceci dit, je te remercie encore de ta patience. Continuons.

 

Ce locked antiphase, ça bousille pas les moteurs à la longue ? J'ai lu quelque part qu'il ne fallait pas être trop violant dans les changements de direction. C'est des conneries ?

Le concept est très intéressant. Tu crois que j'en aurai besoin pour Ash ?

 

Sinon, pour avancer, je pansais simplement utiliser l'asservissement vertical. En modifiant l'angle de référence. C'est déconnant ?

[Mike118]

Hum ... Je n'ai jamais lu nulle part que le " Locked antiphase " était particulièrement mauvais pour les moteurs... En fait je ne m'était tout simplement jamais posé la question. Par contre après réflexion pragmatique, en mode locked antiphase tu consommes plus, du coup tes moteurs chauffent plus, et du coup techniquement oui tu dois diminuer un peu la durée de vie... Mais je n'ai jamais eu de problèmes en utilisant cette méthode ...

Pour info si jamais ça t'intéresse la première fois où j'ai utilisé ce type d'excitation c'est ici =) 

Je ne pense pas que tu sois obligé d'utiliser ce mode d'excitation des moteurs, mais j'utilise ce mode pour tout asservissement en position d'un moteur CC.  

Concernant la modification de l'angle de référence, tu parles duquel ? l'angle du "yaw" / lacet ou du " pitch "/ tangage ? 
Quoi qu'il en soit je te suggère vraiment de faire l'exercice du schémas bloc. C'est très formateur pour mettre en place ce genre d'asservissement qui mine de rien commencent à être complexe  

[Path]

 

 

pour tout asservissement en position d'un moteur CC

Je garde ça dans un coin de ma tête. Merci

 

 

[Path]

Mike, je sais pas si c'est le genre de schéma que tu attendais. Voilà ce qui me semble illustrer ce que j'ai en tête.

 

Je n'ai pas fait figurer les écrêteurs. Mais le principe est là.

Avec ce schéma, je me rend compte que pour avancer, je n'ai qu'à lui demander de parcourir une certaine distance.

Image(s) jointe(s)

• 

[Mike118]

C'est exactement ce genre de schémas que j'attendais . 

En tout cas ce qui est marrant c'est que tu te fies à un seul des deux codeurs pour savoir la distance parcourue, et que du coup tu ajuste le deuxième codeur en fonction de l'angle souhaité. 

Ce qui est " malin"  mais qui a pour conséquence de placer " le centre de ta roue liée au moteur A " a une distance donnée et non pas le " centre de ton robot "  qui est le milieur entre tes deux roues. Ce n'est pas forcément génant mais c'est mieux de le savoir. 

 

Afin de corriger cela ( si jamais tu souhaite le corrigé )  il faut comparer ta consigne en distance Ref D ( en ticks ) avec (Codeur A + Codeur B ) /2 ( en ticks ) 

et comparer ta consigne angulaire Ref P (en °)  avec ( CodeurA - Codeur B ) * K   ( en °) 

Afin de compléter ton schémas je te suggère de détailler un peu plus tes entrés et sorties ( donner des noms / spécifier les unités  / préciser les opérations si besoin  ex : K cité ci dessus s'exprime en fonction  du diamètre des roues et de la distance entre les roues  etc... )

Je peux te faire un lien avec un autre vieux projet à moi qui peut peut être t'intéresser : RMAD
 

[Path]

Sinon, je peux faire comme Transistance : la moyenne des 2 :  (codeurA + CodeurB)/2

 

J'ai modifié. Comme d'hab. Tu dois avoir raison

 

 

Edit bah si on édite en même temps ...

 

Edit 2, Merci du partage du robot fou

Modifié par Path, 13 avril 2016 - 09:34 .

[Mike118]

Sinon, je peux faire comme Transistance : la moyenne des 2 :  (codeurA + CodeurB)/2

 

J'ai modifié. Comme d'hab. Tu dois avoir raison

 

Ce n'est même pas une question d'avoir raison ou pas =) C'est une question de choix. 
Si tu décide que ce que tu veux placer dans l'espace en x ou en y sur ton robot c'est sa roue droite par exemple, et non son centre, ta précédente méthode est celle qu'il faut utiliser =) c'est juste que généralement les gens se basent sur le centre des deux roues d'un robot et pas sur une roue plus qu'une autre. 

Et oui visiblement on a édité nos messages en même temps ^^

 

[Path]

 

 

Ce n'est même pas une question d'avoir raison ou pas =)

Ne t'inquiète pas pour ça. Je ne fais que si je comprends. Je suis là pour ça.

 

En tout cas, depuis 3 mois, je prends un sacré cours ^^

 

Merci !!

 

[Path]

Je cherche un moyen pour que Ash apprenne tout seul à se tenir debout.

Pour le fun.

 

Je veux parler d'une méthode pour établir finement les constantes PID.

 

Je laisse temporairement de coté les 2 autres asservissements (polaire et distance) pour lesquels c'est moins compliqué. Moins compliqué si je ne tiens pas compte de l'oscillation et que je les gère dans un premier temps uniquement avec le P.

 

Je me concentre sur les 3 constantes PID de l'asservissement vertical.

En entrée : l'inclinaison par rapport à la verticale.

En sortie : une vitesse et une direction.

 

Au milieu, un calcul PID avec les 3 constantes tournant sur un raspberry.

 

Le robot est construit pour se poser sur ses pieds au repos avec une certaine inclinaison. Ces pieds limitent aussi les trop fortes inclinaisons pour l'empêcher de tomber.

 

Il a aussi un taux élevé d'échantillonnage du capteur inertiel pour son Kalman interne et pour choper les extrémités de l'amplitude. 

 

 

 

 

En mode apprentissage,

 

Ash pourrait surveiller son amplitude d'inclinaison. Il oscille d'avant en arrière en permanence, même faiblement. Il lui suffirait de mémoriser l'angle fait entre l'inclinaison avant et l'inclinaison arrière à chaque aller-retour.

 

Il pourrait décider qu'une combinaison PID est meilleure qu'une précédente en constatant une amplitude plus faible.

 

Pour l'aider dans sa tâche, je pourrait commencer avec des valeurs PID connues mais non optimisées.

 

Pour déterminer les 3 constantes :

• Pourquoi pas asservir le calcul du PID avec l'amplitude constatée ... Je trouve cela compliqué (ou je ne vois pas de moyen simple).
• Je peux aussi programmer ce que je fais manuellement : d'abord P, puis D, puis re P, puis I. C'est de la fainéantise de programmeur et cela dépend encore de mon algo de détermination.
• Je peux aussi faire dans le brutal et l'aléatoire pur.

La fin de l'apprentissage, est donné par une amplitude inférieure à X degrés. (X très faible à définir).

 

 

 

Le plus intelligent me semble encore la méthode du PID par l'amplitude cette fois. Mais je me sens bête là.

Faute d'idée alternative, je vais me rabattre sur la fainéantise mais je n'aurait pas forcement le meilleur triplet au final.

 

Cette méthode d'auto-apprentissage porte peut-être un nom, cela m'aiderai à googler le truc.

[R1D1]

Salut !

Tu as prononcé le mot sacré pour invoquer R1D1 : apprentissage
La première chose à faire est de bien définir le problème et le système pour savoir quoi apprendre. Ton robot mesure une erreur de position entre la verticale et son angle. Tu en déduis la commande par un correcteur PID.

Une première solution consiste à chercher ces coefficients incrémentalement. Tu peux avoir une approche par algo évolutionniste (mlot clef à chercher ): tu définis une population d'individus qui sont des triplets (p,i,d).
Tu peux ensuite évaluer chaque individu sur le robot en faisant un scénario de commande (je fixe p,i,d, j'essaie de corriger mon erreur pendant une durée fixée) et en donnant une note à l'individu. Cette note, la fitness, dépendra d'à quel point ces coefficients permettent de rester vertical, intégrer l'erreur angulaire pendant la durée de la commande me semble pas mal. Une fois chaque inidividu évalué, tu as des scores de fitness et tu peux refaire une population composée des meilleurs individus (ceux dont le score est le plus faible si fitness comme proposée). Tu peux appliquer des mutations à ces individus (proba que p,i,d subisse une faible modification), et recommencer ensuite l'évaluation de la population, etc. jusqu'à obtenir des individus qui minimisent le temps vers convergence à la verticale de l'angle du robot.
Le défaut de cette méthode est qu'elle est très longue (évaluer chaque individu, et recommencer).

Une approche différente consiste à faire de l'apprentissage supervisé : en remplaçant le correcteur PID par un algo qui apprend la relation entre erreur angulaire et commmande motrice (ce que fait ton PID mais avec certains a priori sur l'information).
Tu peux par exemple définir un réseau de neurones qui prend en entrées les commandes motrices à t-1 et l'angle mesuré, et dont les poids permettent de déduire la nouvelle commande. L'apprentissage des poids se fait de manière supervisée puisque tu connais l'angle objectif (verticale) et l'angle actuel. Voir règle de Widrow-Hopf.

Je n'ai pas trop le temps d'y penser en profondeur, donc ces idées sont peut-être foireuses, mais j'espère que ces quelques mots-clefs te permettront de te faire ta propre idée. Je suis le sujet de loin, j'essaierai de répondre dans un temps non-infini si tu te poses d'autres questions.

[Path]

Salut R1D1,

 

Merci pour ta réponse !! C'est génial que tu me parles de machine learning, Je regardais ce matin cette video de Yann Le Cun. C'est sur ces principes que j'ai pensé à avoir un mode d'apprentissage. De là à y aller avec des neurones, ...

 

 

C'est très intéressant mais très impressionnant. C'est une montagne à franchir pour mes neurones biologiques. Je n'ai encore jamais travaillé avec ces choses là.

 

Mais mettre un brin d'IA dans Ash serait encore un kiffe énorme !! Je vais creuser un peu la chose.

[R1D1]

Ah, LeCun, il est de partout en ce moment !
Il y a une série de vidéos sur les cours qu'il a donné cette année au Collège de France (voir sur le site du Collège de France). Je ne sais pas s'il y a encore des cours programmé, mais c'est normalement en accès libre (et blindé de monde).

Les outils que présente LeCun sont des réseaux de neurones profonds, donc une manière particulière de faire de l'apprentissage. Vu que ça donne des résultats impressionnants dans des problèmatiques de catégorisation des données, c'est très à la mode en ce moment.
Bon courage pour ton exploration du Machine Learning, c'est effectivement passionnant !

[Path]

Hou là, je mets le doigt dans un truc trop gros pour moi là ^^

C'est passionnant, au moins autant que Ash. Mais Ash va rester très 'con' si je puis dire. Autant que son créateur ^^

 

J'ai quand même testé des 'Hello world' pour apprendre un XOR, par exemple. 

 

J'ai utilisé cette lib pour node http://synaptic.juancazala.com/#/ toujours sur le raspberry.

Elle est simple et bien documentée. https://github.com/c...al-Networks-101

Elle est le reflet de la video plus haut ^^

 

Je vois qu'il y a moyen de mettre de l'intelligence dans le robot ^^

 

Mais je ne comprends pas tout ce que je fais. Notamment dès qu'il faut utiliser les blocks à mémoire. Je comprends les perceptrons, même multi-couches et même la rétro-propagation. Mais dès qu'il faut passer aux LSTM, je bloque. Voilà mon niveau en IA.

 

L'IA est un domaine de la robotique des plus complexes. C'est une branche parallèle dans mes recherches mais pas pour Ash. Je me connais. Si j'en mets pour la station debout, je vais vouloir en mettre partout. Et là, je par pour un trop long voyage.

 

Après, le 'cerveau' de Ash est déjà très puissant. Mais c'est de l'informatique embarquée. Pas certain que ce soit très adapté.

 

En tout cas, R1D1, tu m'as montré une de mes limites dans mon exploration de ce domaine

 

Pour le moment, je n'ai pas mieux. Je vais rester sur les PID. Ash aura "l'intelligence" de trouver son chemin en découvrant son environnement, il mémorisera peut-être cet environnement. Mais il ne s'améliorera pas seul et sera codé pour ne faire que ce qu'on lui demande ^^

 

 

[macerobotics]

Salut Path,

 

Peux t’intéresser : cours asservissement robot

[Path]

Excellente ressource, j'aime bien l'esprit Merci.

[Path]

J'ai parcouru les cours de ce site très sympa.

Pour illustrer le propos ici, cette video montre les principes d'asservissement polaire est distance.

 

 

Et avec des schémas plus formels que les miens

 

 

Plus de détails sur le double asservissement :

https://www.rcva.fr/...-dexperience/9/

 

 

Et si, Transistance était dans le vrai ^^

 

Et Transistance non plus   (ou j'ai rété un truc)

// appliquer les commandes aux moteur
PWMG = cmd_dist - cmd_orient; // ça ne doit surement pas fonctionner de cette façon
PWMD = cmd_dist + cmd_orient;

 

 

Je vais arrêter mes recherches sur les asservissements (j'en ai 3 sur les moteurs).

 

Les composants électroniques sont tous là. Ash est mécaniquement équilibré. Je crois avoir assez d'infos pour terminer le programme. En tout cas, je crois avoir compris ^^

 

Merci tout le monde ici, vous m'avez énormément aidé jusque là.

[Path]

Voilà quelques nouvelles de Ash.

 

La mécanique n'a pas changé. J'ai testé séparément les composants et terminé l'écriture du code arduino, nodejs et python. Je présenterai le code plus tard, plus en détail, quand ce sera fonctionnel.

 

Pour faciliter le développement, j'ai retiré la fonction point d'accès wifi. Le raspberry se connecte à mon wifi, ce qui m'évite de changer le point d'accès de mon téléphone à chaque test. La fonction est intéressante mais sera utile un jour si Ash doit se balader en dehors de la portée de mon wifi domestique.

 

C'est l'heure du fameux putting it all together ... L'intégration quoi ... Je galère ...

 

Dans le sujet : "Ash, tiens-toi droit !". Ou plus concrètement, juste le 1er asservissement. Celui de la vitesse par rapport à l'erreur d'inclinaison. Je m'arrange pour avoir un centre de gravité à la verticale ou en tout cas connu et fixe. Au passage, je suis toujours avec la méthode manuelle pour définir les constantes PID. J'ai mis de coté l'apprentissage des constantes.

 

Je n'arrive pas à trouver ces fameuses constantes PID.

Je lâche pas le morceau grrr ... mais 'tin ça me gonfle. ça fait 2 we presque entier que je suis sur ce petit réglage  

 

Je n'avais autant galèré avec le montage précédent. 

 

Voilà, désolé. ça fait du bien de partager ma douleur.

 

 

 

 

Après, comme je suis un malade mental, j'ai bien envie d'ajouter un 4eme asservissement pour définir l'axe du centre de gravité. Marre de sortir le fil à plomb et le niveau. Et, je voudrait bien que Ash puisse porter des choses.

 

Et ça, c'était pour la réflexion du moment.

 

++, je vous tiens au courant. ça fait trop longtemps que j'ai pas fait une tite video

[Path]

Voilà le comportement que je veux !! J'ai du mal à formaliser les choses mentalement.

 

Un pid qui régule la vitesse pour maintenir un certain angle (setpoint) et un autre pid pour définir le setpoint fonction de la vitesse. J'ai du mal à conceptualiser.

 

A priori, c'est possible, j'ai trouvé un vidéo qui le prétend. C'est à 1m que cela commence.