Leon

Re-bienvenue, Fabien ! Ca c'est du come-back!

 

Oui, moi aussi, je suis toujours présent sur ce forum, mais vraiment en pointillés. J'attends de voir comment cette communauté évolue.

 

Je ne ferais pas de commentaire sur tes coups de gueule, je crois que tu sais déjà ce que j'en pense.

 

Sinon, il faut quand même que je te remercie une nouvelle fois : c'est grâce à Thot et à toi que j'ai eu l'idée de me lancer dans l'étude de la marche bipède. C'est vous 2 qui m'avez refilé le virus. Je n'en suis qu'au tout début des travaux, mais ça s'annonce passionnant!

 

Pour finir, je suis agréablement surpris de voir que vous fabriquez un humanoïde taille bambin, car tu ne jurais que par des humanoïdes taille adulte il y a quelques années. Bonne chance dans la continuation de l'aventure. J'ai toujours du respect pour ceux qui arrivent à entreprendre et à vivre de leur passion.

Et j'attends avec impatience de voir les premiers pas d'un de vos robots.

 

Leon.

J'y arrive pas.

Dur, dur. Il y a toujours des moments de doute sur un tel projet; des moments où on se demande pourquoi on s'est lancé, je suis en plein dedans. Mais je vais quand même persévérer.

J'ai donc remis le robot libre en 3D. Mon dieu, que c'est complexe!
Ca fait plusieurs séances de travail que je me bat pour essayer de le faire marcher de manière stable. J'ai essayé plusieurs stratégies. Certaines idées m'ont pris du temps à mettre en équation puis à coder... avant de me rendre compte que ça ne pouvait pas marcher. J'ai essayé plein de paramètres, car comme pour BOB4, il y a une grande quantité de paramètres à régler dans le code. Rien n'y fait, ça ne fonctionne pas. Il fait 4 ou 5 pas grand maximum, et PAF!
Ca n'en reste pas moins un projet passionnant.

Est-ce que je ne me suis pas lancé dans un défi trop grand? La suite au prochain numéro.
http://www.youtube.com/watch?v=TAjClRLkq6A


Leon.

Je me pose une question existentielle, concernant toutes ces demandes de projets "scolaires" sur les forums : les profs ne sont-ils en théorie pas les personnes les mieux placées pour aider? Mettre sur la bonne voie, donner des conseils, ré-orienter un projet mal démarré? En tout cas, ça se passait comme ça à mon époque. Demander de l'aide à un prof n'était pas du tout mal vu, bien au contraire!

Leon.

Bonjour, j'ai une question qui me trotte dans la tête depuis pas mal de temps.

En matière d'odométrie et d'asservissement (distance, position et cap) la quadrature de phase est elle vraiment indispensable ?

Parceque bon, pour l'exemple, si je dis à mon robot d'avancer de 80cm, je vois pas l'intérêt du signal de sens puisque je le connais déjà ! (ben oui je lui dis d'avancer donc je connais le sens de rotation pour chaque roue ) Et du coup c'est pareil pour tout les cas, que le robot tourne à droite, à gauche ou recule.

Pourriez vous m'aiclairer svp ?

La question était parfaitement claire pour moi dès le début, bien formulée. Je vais apporter un éclairage différent.

En fait, ça dépend de ce que tu veux faire. Si tu veux faire un robot réellement asservi en distance, position, cap, comme tu le dis, où l'odométrie est la principale source d'information sur la position (en 2D) du robot, alors avoir des codeurs en quadrature est quasiment indispensable, mais dans certains cas, on pourrait s'en passer.
Ca dépend de plusieurs choses : du type d'asservissement que tu utilises, de la localisation des encodeurs, etc...

Tout d'abord, maintenir l'information position 2D d'un robot avec 2 odomètres (droit-gauche), ça nécessite clairement de ne "perdre" aucun top sur chacune des roues, et de n'en compter aucun en plus. C'est surtout critique en orientation, calculée avec l'écart d'avancement droite-gauche. A basse vitesse, et surtout lors de phases d'inversion de sens des moteurs, il est indispensable de connaitre le sens. Avec juste 1 seule information par roue, tu vas forcément te tromper d'1 pas au moins à l'inversion de sens, dans certaines situations. Fais-toi des chronogrammes montrant à la fois la vitesse d'1 roue et le signal d'1 encodeur, pour comprendre.
Et il faut se rappeler que les erreurs se cumulent dans le temps. Il ne faut donc faire aucune erreur, ne compter aucun top en trop ou en moins, pour maintenir une estimation d'orientation correcte. Sinon, au bout de plusieurs manoeuvres, l'erreur sera trop grande. C'est ce que j'ai expérimenté avec mes robots BOB2 et BOB3.

Ensuite, un vrai asservissement de type proportionnel, ou proportionnel-dérivé, ou PID, peut inverser très rapidement le sens de marche du moteur. Et dans ce cas, sans information de sens, à basse vitesse, tu ne sais pas dans quel sens tourne le moteur. L'inversion de sens est particulièrement critique. Un tel asservissement ne donne pas juste comme commande au moteur de s'arrêter une fois la position de consigne atteinte, l'asservissement continue après. Je suis en train de me bidouiller des motoréducteurs asservis (asservissement performant), et le maintien en position immobile est "actif" : autour de la position de consigne, je peux avoir ~100 oscillations par secondes, 100 périodes ou j'oscilles de +1 pas à -1 pas d'encodeur autour de cette position. Ces oscillations sont normales. L'encodeur étant côté moteur en amont du réducteur, ces micro oscillations (1/4 de tour côté moteur) ne se voient pas du tout en sortie de réducteur. Et on imagine bien que faire un tel asservissement nécessite de détecter le sens.

On pourrait peut-être se passer de connaitre le sens dans certains cas: si tu as un robot avec des moteurs très démultipliés, dont les motoréducteurs ont beaucoup de frottement, sur lequel tu fais des pauses avant d'inverser le sens de rotation d'un moteur (donc sans asservissement classique proportionnel par ex), et sur lequel ton encodeur est côté moteur (en amont du réducteur), alors tu peux sans doute te passer de la détection du sens (par quadrature). Mais ça sera un robot plutôt lent à priori.

Leon.

Et sinon tu pouvait aussi t'enlever les doigts du #### et faire des recherches...

Monsieur RBOT99, attention! Tu as quand même un lourd passif sur ce forum, et je pense que tu es très mal placé pour faire ce genre de commentaire.

Leon.

Skyhack, pourquoi tant de haine? />
Merci de ne pas utiliser mon sujet pour attaquer Ambroise.
Je trouve le projet d'Ambroise intéressant, et il nous a montré qu'il avait beaucoup de talent, vu la qualité de sa réalisation par rapport aux moyens mis en oeuvre... La main, la tête, c'est quand même fort bien réalisé. Même si je doute un jour que son robot réussisse à marcher, ce projet est intéressant. Lui, au moins se bouge le derrière, et avance sur une réalisation concrète, contrairement à d'autres.

Il y a de la place pour tout le monde sur ce forum. Tout le monde n'a pas les mêmes aspirations que toi en robotique, et c'est très bien comme ça. Certains se focalisent sur la théorie, d'autres sur les réalisations concrètes, artistiques, d'autres sur l'aspect philosophie. Merci de respecter les autres.

Fin du hors sujet. Si tu as des remarques à faire sur mon projet, n'hésites pas. Sinon, merci de passer ton chemin.

Leon.

Salut à tous, et bonne année 2014!

Voilà, je ressort le projet de bipède qui me trotte dans la tête depuis pas mal de temps. C'est donc un projet de bipède à "marche dynamique".
Finalement, je lui ai mis des pieds (ça ne sera donc pas un échassier). Mais des pieds cylindriques, ce qui fait l'économie d'un servo par pied. 8 servos pour un tel bipède, c'est peu.




Pour l'instant, j'étudie ça en simulation. J'ai aussi construit un bipède réel pour avoir du concret, avec des pièces Lynxmotion, avec, mais avec des servos peu puissants, donc ce robot bipède ne marchera jamais réellement, sauf peut-être suspendu à un long élastique pour "diminuer son poids", et donc tester les algos. C'est plus sympa de voir du concret bouger, la simulation a ses limites. Dans la vidéo, le robot réel que je tiens dans les bras essaye juste de maintenir ses pieds au même endroit et à l'horizontale, quelle que soit son inclinaison (mesurée avec le gyro).

Tout est programmé en C++, que ce soit le robot réel ou le robot simulé. Le code est conçu pour être portable de la simulation vers le robot réel (mêmes fonctions, mêmes variables, même réccurence de tâches, etc...). Je peux aussi utiliser la simulation pour jouer ou re-jouer ce que le robot réel fait. Le robot simulé est alors une simple marionnette suspendue dans les airs qui imite tous les mouvements du robot réel, y compris son inclinaison.
Dans la vidéo, vous verrez aussi une vue que j'ai programmé avec SFML, et qui montre en 2D la position cible et réelle des pieds, vu de dos et vu de dessus. C'est très utile pour comprendre ce que fait le programme.

Le sujet est très complexe. Le principe? C'est du ZMP, mais recalculé en dynamique. Le robot est équipé d'un gyroscope et connait donc son inclinaison à tout moment. Il essaye de se maintenir droit, et estime la position à laquelle il devra poser le pied pour ne pas tomber. Bref, c'est de l'asservissement bourrin.

Les idées dans ma tête sont assez claires, mais même en simulation, passer à la réalisation, c'est très complexe. J'ai du mal à tout formaliser, tout mettre en équations, et j'avoue que mon cerveau ne fonctionne plus aussi bien qu'à 20 ans. C'est beaucoup de calculs trigo 3D, des transformations dans tous les sens, et surtout, il faut une réactivité énorme! Un tel robot perd l'équilibre en une fraction de seconde. Encore un bon sujet bien costaud. Je ne suis pas certain que je puisse aboutir à quelque chose, mais qui ne tente rien n'a rien!

Si la simulation donne quelque chose, alors je me lancerai dans la réalisation d'un robot concret. J'en rêve depuis longtemps, c'est devenu une obsession! Mais la complexité du projet me fait peur.





Leon.

Je me permet de réagir là dessus. C'est bien beau les math, mais il faut connaitre la physique qui se cache derrière. Or, tu ne nous dit absolument rien de tes capteurs. De quel type de capteur s'agit-il?

Certains capteurs sont performants pour estimer des vitesses/mouvements rapides, mais dérivent rapidement. C'est le cas des accéléros.
D'autres capteurs savent estimer une vitesse/position fiable dans sur un temps relativement long, mais ne donnent rien de fiable sur les variations "court terme". Je pense aux GPS par exemple.

Si c'est ton cas, alors il faut changer de stratégie à mon avis, et passer à du vrai traitement du signal, avec des filtres simples (passe haut, passe bas, passe bande), ou plus complexes (khalman) mais ça peut être rapidement une usine à gaz.

Pour finir, tu dis que tes informations sont fiables. Mais si c'était le cas, aurais-tu vraiment besoin de 2 sources d'information différente? Si c'était le cas, il te suffirait de prendre les infos uniquement du capteur le plus rapide.

Leon.

Pour les régulateur si vous avez des références moins cher je suis preneur =) ( De préférence des régulateur à découpage comme le tsr ^^ )

Personnellement, j'ai pris l'habitude de faire mes régulateurs à découpage avec des composants. Parce qu'il y a plus de 10 ans, il était quasiment impossible de trouver des régulateurs DC-DC tout fait à tarif abordable. En composant discrets, on arrive à ~5€ ou 6€ TTC pour un régulateur de 3A(contre tes 7€ HT).
Par exemple, j'ai récemment profité d'une promo Sélectronic pour me faire un petit stock de LM2576.

Sinon, une bonne source de régulateurs DC-DC à découpage, pas trop cher, ça se trouve du côté des fournisseurs de modèles réduits. Voici un exemple:
http://www.hobbyking.com/hobbyking/store/__15212__HobbyKing_Micro_UBEC_3A_5v.html

Leon.

Salut!

Comme je viens de finir mon robot scribe, j'ai repensé à ton défi!

Voici donc une vidéo qui montre le résultat.


Rappel : la description du robot scribe est ici:
http://www.robot-maker.com/forum/topic/8690-robot-scribe-version-2/

Leon.

Bonjour à tous,

J'ai constaté ces derniers temps des problèmes pour accéder à Robot-Maker.com.
Depuis une connexion Free, je n'arrive pas à me connecter. Apparemment, les serveurs DNS de Free ne connaissent pas "robot-maker.com".

J'ai été obligé de changer les serveurs DNS à la main pour pouvoir me connecter.

Est-ce que je suis le seul à avoir constaté ces problèmes? D'où est-ce que ça vient? Est-ce que ça sera corrigé prochainement?

Leon.

maintenant pour répondre à ta question, comme tu débutes je te conseille d'acheter un kit mais certainement pas de le faire toi même!

Je ne suis pas du même avis. Je n'ai jamais acheté de "kit", même quand j'ai débuté la bidouille électronique puis robotique. Passer par l'achat de kits n'est absolument pas indispensable.

Si on est suffisamment débrouillard, il est possible de s'en sortir. Pour débuter, il est préférable de bien se renseigner avant de se lancer. Et surtout, il ne faut pas viser trop complexe pour un premier projet.

Pour un robot bipède ultra simple, on peut s'inspirer du célèbre "toddler" de Parallax.
http://www.parallax.com/dl/docs/books/edu/toddler.pdf

Leon.

J'ai beaucoup de remarques.

Principe général:
Sans PWM, tu ne pourras pas moduler la puissance des moteurs. Or, c'est assez indispensable si tu veux gérer des déplacements finement. Du tout ou rien dans des moteurs de déplacement, c'est insuffisant, à mon avis. Rien que le fait d'orienter le robot précisément nécessite de moduler la puissance des moteurs. Et puis c'est indispensable pour ceux qui veulent expérimenter des asservissements (PID). Ne pas gérer le PWM, c'est limiter énormément le robot.

Les codeurs: comment comptes-tu décoder (=exploiter) les codeurs de roue? En général, ça se décode soit par interruptions, soit avec un compteur/décompteur. Mais là, si tu veux procéder par "polling" (=lectures périodiques des Entrées), à mon avis, ça ne fonctionnera pas. En tout cas, je n'ai jamais vu ça. Il faudrait que tu interroges très régulièrement, et à fréquence très élevée. Tout dépend de la résolution des codeurs et de la vitesse du robot; mais même avec une résolution raisonnable, on atteint vite 500 ou 1000 tops par seconde. Donc il faudrait que tu interroges 2 fois plus vite que ça (pour ne louper aucun top, théorème de Shanon). Et interroger via une RPi (qui aura d'autres choses à faire) 2000 fois par seconde, ça me semble très ambitieux.

Bref, si j'étais toi, je repartirai de zéro. Pourquoi ne pas mettre un microcontrôleur pour faire l'interface entre la RPI et le reste? C'est quand même beaucoup plus flexible. Un petit microcontroleur qui génèrerai le PWM, lirait les E/S analogiquest et numériques, et surtout lirait par interruption les codeurs.

La carte:
Pourquoi interfacer un MCPxx par I2C et l'autre par SPI? Il existe des versions qui s'interfacent de la même façon (SPI ou I2C). Et les 2 types de bus I2C ou SPI permettent de partager plusieurs périphériques. C'est plus facile en I2C.

Mettre des résistances "pull up" (sur les EN-A et EN-B du L298 est dangereux. Si problème de configuration, en cours de programmation, ou autre, ça va forcer la puissance dans les moteurs, et donc faire avancer le robot tout seul. Il faut privilégier des pull-down.

Tu as fait beaucoup d'erreurs pour interfacer le L298, relis calmement l'intégralité du Datasheet.
* La logique du L298 s'alimente en 5V impérativement, alors que tu l'alimentes en 3.3V. D'ailleurs, pourquoi ne pas mettre un régulateur sur la carte?
* Tu as inversé VS et VSS. VS c'est l'alim puissance, et VSS c'est l'alim logique.
* Les résistances de mesure de courant (sense) ne sont pas reliées à la masse. Et elles sont reliées avec des pistes fines, alors qu'elles voient de la puissance.
* Tu as relié les résistances de mesure de courant sur des entrées/sorties tout ou rien. Quel est l'intérêt? A la rigueur sur des entrées analogiques, mais via un amplificateur opérationnel. Honêtement, on peut très bien s'en passer! Et directement relier "sense A et B" à la masse. C'est ce que je faisais sur BOB3.
* Il faut impérativement rajouter au moins 1 condo de puissance (chimique ou tantale) à côté du L298.

Il faut impérativement rajouter des condos de découplage à côté de l'alim (logique et puissance) de chaque composant. En général, on mets des petits céramiques 100nF.

Pourquoi faire des pistes aussi étroites? C'est très risqué. Il faut privilégier les traces plus grosses.

Plan de masse : A priori, ça ne sera pas gênant, vu que ça reste un montage relativement basse fréquence. Ca deviendra gênant si tu mets un microcontroleur, par exemple. Un plan de masse ne doit pas aller partout. Il ne doit pas aller là où il n'est relié à rien, et où il ne boucle pas avec lui même. Sinon, les bouts de plan de masse qui ne sont reliés que d'un côté vont faire "antenne". Exemple : le "T" que fait le plan de masse sur le haut du MCP23017 doit être enlevé intégralement, la masse doit s'arrêter à connecter les broches 10 et 18 de ton MCP23017.

Leon.

Je passe près de 6ou 7 heures par jour à lire des tutos des topics inscrit à de nombreux forum il n'y a guerre qu'ici ou je suis concideré comme un "puis de science" je plaisante bien sur mais pas complètement.

6 à 7h par jour à consulter les forums? Tu dors, la nuit, Yves?

Desolé d'être aussi franc. Mais si ce forum ne se remet pas en question il va stagner autour des mêmes sujets avec les quelques anciens qui finissent bien sur par maîtriser ces quelques sujets (suiveur de lignes, capteur Sharp, capteur US, télécommande IR, pont en H pour pilotage de moteurs cc)
Voilà l'étendue des sujets maîtrisés par le forum

Vous me trouvez dur ?

Oui, je te trouve un peu dur. C'est totalement vrai que le niveau moyen a baissé. C'est indéniable. Par contre, on voit toujours par ci par là des sujets intéressants sortir du lot (tondeuse autonome filoguidée). Alors, oui, ces projets intéressants sont noyés dans la masse des débutants qui viennent pour faire un projet standard.

Pour avoir à une époque pas mal trainé sur différents forums dédiés à l'informatique, je peut te garantir que les nouveaux qui prétendent détenir la science infuse et qui donnent des conseil défiant toute logique il n'y en as pas qu'ici.

Il n'y en n'a pas qu'ici, je confirme. C'est bien ce que je voulais montrer avec mes exemples de recherches d'infos sur des forums "Linux" et "programmation en C".

Le problème ici à mon avis, j'en ai d'ailleurs parlé dans un autre topic c'est le fait qu'il y ai eu trop de débutant en trop peu de temps alors que pendant le même temps pas mal de piliers du forum s'en sont allé.

Cette fuite des "pilliers" a une explication rationnelle, c'est à mon avis une conséquence, et non une cause de la baisse de niveau.
Je rappelle que lors de la passassion de pouvoir, le nouveau proprio du forum (Sébastien) a clairement dit qu'il voulait faire de ce forum un forum dédié aux débutants! C'est réussi! Et les personnes ayant des sujets complexes étaient invitées explicitement à se diriger vers le forum d'en face (=forum Caliban, un forum avec 1 post tous les 2 jours en moyenne). Les 2 posts sur le sujet ont été effacés par ce nouveau propriétaire, ça partait en couille trop rapidement. Cette prise de position m'avait assez surprise à l'époque, je ne comprends toujours pas!

Et vu le positionnement commercial du forum, j'ai peur que ça n'ailles pas en s'améliorant

Honêtement, pour l'instant, le forum n'est pas positionné commercialement. Le forum continue à vivre sa vie. Ses nouveaux propriétaires ne s'y intéressent pas du tout. Un forum à orientation commerciale, c'est un forum centré sur 1 ou 2 marques qui font la pub pour leur produits. Ca n'est pas du tout le cas ici.

Leon.

Attention, le but de ce message n'a pas seulement pour objectif de répondre à ta question. Je veux aussi montrer que quand on cherche au bon endroit, on trouve l'info.

La formule de Black Templar est bonne. Il suffit de l'appliquer.

Pour trouver les caractéristiques de tes LEDs, certains sites marchand les donnent. Mais tu peux assez facilement généraliser. Par exemple, une LED standard (il existe un tas de "non standard") d'une certaine couleur et d'un certain diamètre aura en général une caractéristique donnée. Si tu n'es pas certain des caractéristiques, il faut essayer de penser que le courant admissible est plus faible, pour éviter de griller ta LED.
Attention, la tension varie avec la couleur, mais pour la même couleur, la tension est (quasiment) la même.

http://www.selectronic.fr/led-orange-1.html
ça dit :
VF = 2,0 V @ 10mA

Donc on applique R = (Ualim - Uleds) / I
Ca donne:
R = (5V - 2V) /0.010A = 300 Ohm

Après, pour débuter, c'est bien de se faire un petit stock de résistances "standard", et étalées de 100 Ohm à 10kOhm par exemple.

Leon.