Aller au contenu


Leon

Inscrit(e) (le) 19 juil. 2009
Déconnecté Dernière activité août 08 2018 06:09
****-

#79519 Prototype robot humanoïd

Posté par Leon - 23 février 2017 - 06:58

Je sens qu'il va me falloir beaucoup de popcorn pour suivre ce sujet...

 

Au fait, comment as-tu déterminé que les servomoteurs sélectionnés faisaient respectivement 5, 15 et 30W?

 

Leon.




#78833 Et vous votre atelier ressemble à quoi ?

Posté par Leon - 03 février 2017 - 09:38

Ouch, un oscillo à 800€. Joli bébé.

 

Voici mon expérience de bidouilleur en ce qui concerne les alims et autres oscillo:

 

1) Alim de labo avec réglages et mesures courant-tension : je n'en n'ai JAMAIS eu! J'utilise des blocs secteurs : 5V fixe 2A, 12V fixe 3A, 7 à 24V réglable 70W. Bien sur, ça dépend énormément de ce qu'on bidouille. Si on bidouille des montages analogiques de puissance, ou des montages de puissance, une alim de labo peut être utile, mais ça n'est pas indispensable. Pour faire du dépannage d'équipement en panne, ça peut être utile (piéger des courts circuits en limitant le courant). Pour des montages numériques exclusivement (= ce que bidouillent 90% des gens ici), une alim de labo perfectionnée ne sert pas à grand chose.

 

2) Oscillo : j'ai un oscillo USB (2 entrées 40MHz de bande passante, 200€). Mais un oscillo n'est nécessaire que pour des montages analogiques. Or, les roboticiens bidouillent principalement du numérique. Et dans ce cas, un oscillo ne sert pas à grand chose. Je l'utilise pour des montages radio principalement.

 

3) Analyseur logique : là par contre, c'est un outil quasi indispensable pour débugger des montages en électronique numérique, espionner un port SPI, etc... J'ai un Zeroplus 16032 : analyseur logique USB 100MHz 16 voies, acheté 100€ il y a 8 ans.

 

Dans tous les cas, pour nous les bidouilleurs, je pense qu'on a tout à gagner à utiliser des outils de mesure en USB (oscillo, analyseur logique): ça prend moins de place, c'est moins cher, et l'interface sur grand écran est très pratique. Je n'y vois que des avantages.

 

Leon.




#76447 Et vous votre atelier ressemble à quoi ?

Posté par Leon - 19 novembre 2016 - 07:51

Personnellement, je n'ai jamais eu d'espace dédié à mes bidouilles.
Donc je veux montrer ici qu'il est parfaitement possible de bidouiller énormément dans ces conditions, et d'aller assez loin!
 
Je n'aime pas le désordre, et je n'ai pas la surface nécessaire dans mon appartement. Je n'ai pas envie de pourrir mon salon avec tout ce bazar. Si j'avais un "bureau" dédié, une pièce dédiée, ça serait certainement différent. J'avoue que je suis parfois jaloux quand je vois certains amis bidouilleurs, mais ça ne me bride pas.

Et puis j'aime bien travailler avec le juste nécessaire, c'est une philosophie "minimaliste" que tout le monde n'applique pas, chacun ses choix.
 
Du coup, j'ai 2 espaces pour bidouiller (pas de photo, désolé) :
 
* cave aménagée avec un petit établi fixe, fait avec de vieux meubles de cuisine. Cette partie sert exclusivement à la mécanique (pas que robotique) : perceuse à colonne, étau, et tous les outils de base... Je n'y passe pas tant de temps que ça, mes bidouilles sont essentiellement électroniques.

Petite remarque en passant : je vois les imprimantes 3D se multiplier autour de moi, et je n'adhère pas du tout au concept, je n'en vois vraiment pas l'intérêt par rapport à des outils classiques qui permettent de faire énormément de choses.
 
* mon bureau, au milieu du salon, c'est le lieu des bidouilles électroniques et programmation. Un bureau de 80cm de large seulement. C'est là que je passe le plus de temps. Je sors uniquement le matériel dont j'ai besoin à un instant T : fer à souder (gros, petit, fer à air chaud), composants, oscillo USB, analyseur logique USB, programmateur, documentation, etc... Le matériel prend beaucoup de place dans les placards (15 ans d'accumulation), mais peu sur le bureau. Au final, les bidouilles électroniques prennent peu de place si on est bien organisé. Bien sur, parfois ça déborde un peu autour du bureau, mais ça reste rare et parfaitement gérable. Et je range tout soigneusement après chaque séance de travail.
 
Sinon, allez voir aussi le bureau de Seb, qui a carrément une pièce dédiée (sans fenêtre malheureusement).
https://www.robotips.../sebastien.caux

bureau_seb.jpg

 
Leon.




#71758 Moteur pas à pas Nema 17 [testé par ashira]

Posté par Leon - 03 juillet 2016 - 07:35

Salut Oracid.

Quelques éléments de réponse:

 

* dans quel cas un moteur pas à pas est plus adapté qu'un motoréducteur à courant continu ou un servo?

si tu as besoin d'une grande précision de positionnement, d'une grande résolution, d'une très bonne répétabilité. C'est pour cela que ces moteurs sont très utilisés dans les machines à commande numérique. Si tu n'as pas besoin de cette très bonne précision de positionnement, alors un moteur pas à pas ne servira strictement à rien!

 

 * performances poids/puissance/rendement

Clairement, les moteurs pas à pas ont un rendement plus mauvais que les moteurs à courant continu ou les brushless. Donc un moteur pas à pas consommera plus, et chauffera plus, pour la même application.

En plus, à puissance identique, ils sont plus lourds, plus encombrants.

Pour un outil à commande numérique amateur (imprimante 3D, fraiseuse/tour à commande numérique), ces contraintes ne sont absolument pas gênantes.

Mais dans une application embarquée sur un robot mobile, il faut faire attention.

J'avais fait un petit robot mobile à moteurs pas à pas qui fonctionnait très bien cependant, car il était léger, avec des moteurs légers, et une autonomie assez faible.

Attention, dès qu'on vise des puissances un peu élevées (à partir de quelques dizaines de watt), la taille, la consommation, et le prix d'un moteur pas à pas s'envolent. Et dans ce cas, un moto-réducteur asservi, à courant continu, devient rapidement plus économique.

 

* facilité de mise en oeuvre

Déjà, avec des drivers moteur pas à pas modernes, c'est beaucoup plus simple qu'avant : il suffit d'injecter 2 signaux : step et direction, et c'est tout.

Pour la complexité, ça dépend de quelle application tu vises. Je dirais que c'est plus complexe qu'un servomoteur.

Mais en général, les moteurs pas à pas ne remplacent pas un simple servomoteur de modélisme (un servomoteur est infiniment moins précis), mais plutôt un moteur à courant continu ou brushless asservi (avec un asservissement PID, retour d'état par codeur). Et dans ce cas, le moteur pas à pas est infiniment plus simple à mettre en oeuvre qu'un moteur asservi, car il n'y a pas l'asservissement à gérer (dans le microcontrôleur), et il n'y a quasiment rien à régler : juste le courant du régulateur, et c'est tout.

C'est bien pour ça qu'ils sont massivement utilisés en amateur, là où les applications industrielles utilisent des moteurs asservis plus performants.

Pour finir, les 2 familles "moteur pas à pas" et "moteur courant continu/brushless asservi par codeur" n'ont pas de connaissance de leur "position absolue", contrairement à un servomoteur de modélisme. Donc il faut y rajouter soit un potentiomètre (si pas besoin d'une très grande précision absolue), soit des contacteurs de butée (pour une très grande précision absolue). Donc c'est une complexité supplémentaire!

 

Leon.




#70539 Arduino, je me lance.

Posté par Leon - 29 mai 2016 - 07:03

Pour les communications depuis un processeur central (Raspberry-Pi) vers les périphériques, il faut vraiment étudier toutes les solutions.

Typiquement, multiplier les connexions USB, et les convertisseurs USB-Série, comme le propose Mike, ça me semble une assez mauvaise idée.

 

Pour un réseau partagé entre 1 maitre et des esclaves, tu peux utiliser:

* si tes périphériques se branchent en USB, un hub USB

* port série asyncrhone :

    - en liaison point à point, c'est, de loin, le plus simple à utiliser et à débugger

    - pour faire 1 maitre et plusieurs esclave, avec 1 seul port série côté maitre, il y a plusieurs solutions à bidouiller. Pour plus de détails, demande moi. Ca nécessite de bidouiller au niveau soft, et d'inventer / adapter le protocole de communication (rien d'infaisable).

        + en anneau type token ring

        + en étoile avec 1 canal maitre vers esclave, et un canal partagé de retour;

        + en étoile avec 1 seul canal partagé par tout le monde.

* I2C : très pratique, mais assez limité en nombre d'adresses. Attention aux niveaux de tension 3 ou 5V. Comme c'est un bus partagé, le débit est limité par le périphérique le plus lent.

* SPI : c'est l'idéal. C'est très souple, et de plus en plus de périphériques utilisent ça. Je ne sais pas si l'Arduino est compatible SPI esclave (pour le PicBasic, c'est non). On peut monter à des débits élevés (10Mb/s ou plus pour certains périphériques). Mais c'est un peu plus complexe à mettre en oeuvre, il faut mettre les mains dans le cambouis. Même si c'est un bus partagé, le débit n'est pas limité par le périphérique le plus lent, et le maitre peut adapter son débit à chaque esclave.

* un mélange de tout ça selon les périphériques. C'est très souvent ce qu'on est obligé de faire.

 

Attention, beaucoup de ces réseaux ont des contraintes de distance. A toi de voir si tu veux regrouper toute ton électronique à un seul endroit de ton robot ou non.

 

Leon.




#68834 Robot-chat & synchronisation coude+épaule

Posté par Leon - 10 avril 2016 - 02:54

Pour le réglage du PID, il y a plein de cours qui trainent sur Internet. La méthode empirique est, de loin, celle qui fonctionne le mieux.

Pour régler, on règle d'abord kP, puis kD, puis kI.

 

Méthode pragmatique (il existe des méthodes empiriques beaucoup plus détaillées sur la toile) que j'applique.

* kP (avec kD et kI forcés à zéro): avec juste kP, tu dois converger "rapidement" face à un échelon, mais sans oscillation, en autorisant un petit dépassement de consigne dans certaines situations, en fin de mouvement. Dans tous les cas, ne pas chercher la perfection. Il est normal d'avoir des écarts avec la consigne (erreur d'offset). Rester le plus loin possible d'un kP qui provoque des oscillations.

* kD : avec Kp et kD activés : tu dois obtenir une bonne réactivité dans toutes les conditions, et annuler les dépassements de consigne en "fin de mouvement". L'idéal est de régler avec une rampe rapide, et non avec un créneau. ATTENTION : cette partie dérivée a besoin d'un capteur très précis. Un potentiomètre bas de gamme avec une micro-linéarité merdique empêchera d'obtenir de bons résultats. Le codeur au cul du moteur est encore une fois la solution optimale. Un potentiomètre de précision peut donner de bons résultats aussi.

* kI : les 3 coefs activés. On va chercher à compenser les erreurs "constantes", erreurs d'offset. Il faut régler pour avoir à la fois une compensation correcte des erreurs d'offset, avoir une réactivité suffisante face aux changements de configuration du système (transition patte posée/en l'air), tout en restant très en dessous des valeurs de kI qui amènent à des oscillations. C'est ce kI qui va permettre une différence d'effort entre la montée et la descente de la patte, ou entre patte posée/patte levée.

 

Un bon réglage s'adaptera naturellement à toutes les situations : jambe levée, jambe posée, mouvement vers le haut ou vers le bas. Une fois que ça fonctionne, c'est magique.

 

Et encore une fois, attention à un truc hyper important : le PID ne permet d'obtenir un résultat correct que si la consigne est atteignable! Si tu demandes une vitesse plus rapide que celle que ne savent fournir tes moteurs, dans certaines situations de vie (patte posée), alors ça fonctionnera très très mal. Pareil si les moteurs ne sont pas assez puissant pour juste porter la bestiole.

 

Je te conseille fortement de ne pas te contenter d'un oscillo pour observer le suivi de consigne. Si tu as un microcontrôleur et un moyen de communication entre ce microcontrôleur et un PC (câble de débug, port série), alors tu peux tout transmettre en temps réel au PC.

Perso, quand je règle un PID, je me fait un scénario de test avec 2 ou 3 mouvements représentatifs, et je stocke TOUTES les courbes résultantes avec les différents réglages de coef. Ca permet réellement de comprendre ce qu'il se passe en consultant toutes les courbes.

Il me faut en général une vingtaines de tâtonnements successifs, donc une vingtaines de courbes. C'est long, mais c'est nécessaire.

 

Leon.




#67492 Atlas Next Gen - Boston Dynamics

Posté par Leon - 24 février 2016 - 12:05

Ca vient juste de paraitre, Boston Dynamics montre enfin la première version complète, autonome, de leur robot bipède ATLAS.

Pour moi, c'est vraiment le tout premier bipède "grandeur réelle", qui soit crédible : il est capable d'évoluer en condition réelle, et non juste en laboratoire. Et ça change tout !

Après, j'ai bien conscience que ce n'est qu'un film marketing, mais l'exploit est bien là.

 

A mon avis, c'est un grand moment dans l'histoire de la robotique humanoide!

 

Bien sur, il ne faut pas se tromper, tout cela est financé par l'industrie de l'armement... Donc je n'adhère pas du tout. Mais je salue l'exploit!

 

 

Leon.




#64420 transformer 24v 20 A en 440V

Posté par Leon - 26 avril 2015 - 08:37

Une question pour leon: Si la tension a un signal carré mais non alternatif, comme 12v-0v, est ce qu'un transfo 50/60hz accepte de travailler a plus haute fréquence ?

Non. C'est le noyau du transfo qui détermine la fréquence de travail. Et un transfo 50Hz n'acceptera jamais de travailler à une fréquence beaucoup plus élevée.
La forme du signal en entrée (carré ou sinusoidal) n'a rien à voir dans l'affaire. De plus, certains transfos acceptent mal d'avoir une composante continue en entrée.

 

Leon.




#64185 robot suiveur personne

Posté par Leon - 12 mars 2015 - 06:36

j'aimerais faire un modéle d'un robot bagagiste aideur surtout pour les personnes agés ,c'est mon projet d fin d'etudes,juste un modéle,un robot du petite taille avec un port-clé ..j'ai pensée de choisir deux servomoteurs 12v,2 capteurs gyroscopique acclérometre,deux module bluetooth hc-05 et bien sur une carte arduino.

le probléme : comment varier le vitesse du robot  pour que sera adapté avec le vitesse du personne ? 

je pense que le choix du batteries est interessant..aussi le choix d'une carte du puissance ,un collégue me conseille d'utiliser un pont en H et un driver au lieu de L298

je commencerais bientot de realiser mon carte,pour cela j'aimerais savoir vos opinions concernant la carte du puissance et merci d'avance  :D  

Si tu utilises des servomoteurs de modélisme modifiés en guise de moteurs de propulsion, alors tu n'as pas besoin de pont en H pour les commander. Modifié = permettant une rotation continue à plus de 360° = suppression des butées et déconnexion mécanique du potentiomètre. Recherche ça sur Google.

Pour commander ton servomoteur Il te suffit d'injecter un signal servo classique dans tes servos. Tout l'étage de puissance restera dans le servo, tu n'as pas besoin de pont en H, donc pas besoin de L298N.

 

Sinon, c'est quoi un robot "avec port clé"?

 

Leon.




#64173 robot suiveur personne

Posté par Leon - 11 mars 2015 - 07:38

Où est le rapport entre le fait que le robot soit "suiveur de personne" et le choix de la carte de puissance?

 

Leon.




#63976 Dimensionnement d'une batterie

Posté par Leon - 26 février 2015 - 07:50

C'est ça, C est le taux maxi de décharge. C'est le courant maxi que peut débiter ta batterie sans broncher, y compris de façon répété, sans trop que ça la détruise. Au delà, le fonctionnement de ta batterie n'est plus garanti (vieillissement accéléré).

Par contre, le rendement de la batterie à ce courant de décharge maxi, sera en général assez mauvais. Bien plus mauvais que pour une décharge à 1C par exemple.

 

Leon.




#63615 Dimensionnement d'une batterie

Posté par Leon - 01 février 2015 - 08:02

La seule méthode fiable pour dimensionner correctement les batteries, c'est de mesurer les courants.

Dès qu'on parle de moteurs, d'engrenages, si on ne fait que des estimations papier et simulation, il est facile de se tromper d'un facteur 2, 3, ou 4! En effet, il est très difficile d'estimer les frottements à l'intérieur d'un réducteur, l'effet des forces radiales/axiales sur le frottement. Et puis même si des courbes des moto-réducteurs sont fournies, elles n'étudient pas forcément les points de fonctionnement qui nous intéressent.

 

Donc il faut essayer de mesurer le courant des composants du robot, et surtout  "en situation" : un moteur qui fait avancer un truc qui ressemble au robot, à la masse cible du robot, à vitesse normale (avec une électronique temporaire radiocommandée par exemple), un WiFi qui débite un peu de data, etc...

 

L'idéal est donc d'expérimenter, avec tous les composants du robot, et d'acheter la batterie en tout dernier, une fois qu'on a fait ces mesures. Mais ça n'est pas forcément faisable au tout début d'un projet.

Donc si ça n'est pas faisable dans le temps imparti, et bien on retourne à la case "estimation papier". Et dans ce cas, tu as tout intérêt à sur-dimensionner d'un facteur au moins 2!

 

Dans tous les cas (estimation ou mesure), il faut multiplier l'ampérage moyen consommé par l'autonomie (en heures) que tu veux obtenir, pour la capacité de la batterie en A.h.

Mais attention, dès que tu descend en autonomie cible, le rendement de la batterie diminue, car la batterie verra beaucoup de courant par rapport à sa petite capacité. Je dirais qu'en dessous de 20min d'autonomie cible, il faut s'en préoccuper, et sur-dimensionner encore un peu plus. De combien? Difficile à dire...

Même combat si la batterie doit fournir des courants "pointe" : très fort courant pendant plusieurs secondes seulement (actionneur puissant). Dans ce cas, il faut aussi regarder (en plus de la capacité de la batterie) le courant maxi qu'est capable de débiter la batterie.

 

Et bien évidemment, tous les courants sont mesurés à la tension de la batterie. Donc si tu fais des mesures ou si tu lis de la doc, toujours ramener les courants consommés en tension batterie. Par exemple, si une carte WiFi est alimentée sous 5V, et que tu mets un convertisseur 12V->5V à découpage en amont, vu que [ P=U x I ] est conservé (à >90%) dans un convertisseur à découpage, le courant sous 12V sera:

courant_12V = courant_5V x 5V / 12V / 0.9

 

Leon.




#62602 supprime

Posté par Leon - 16 novembre 2014 - 06:14

Visiblement, même si Ambroise ne fréquente plus trop ce forum, il continue à travailler sur ce projet.

 

http://romeorobot.blogspot.fr/2014/11/creation-des-hanche.html

 

Leon.




#62540 calibanproject

Posté par Leon - 15 novembre 2014 - 12:01

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.




#60465 Robot qui écrit un mot sur une feuille

Posté par Leon - 05 avril 2014 - 03:40

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.