194 réponses à ce sujet

[pat92fr]

Concernant tes vidéos.

Le Palm Size, c'est le kit Petoï ou c'est de ta conception ?

Le 5 barres fonctionne très bien, j'aimerais bien en savoir plus. Un kit ?

Pour le 12 DOF, je ne pense pas que ce soit un problème de rigidité, mais plutôt un problème de poids ou/et de cinématique. Un kit également ?

 

Le robot 'palm size' est ma dernière réalisation. C'est ma première réalisation avec un objectif de légèreté, mettant en oeuvre des micro servos. C'est un robot entièrement imprimé en 3D en PLA et pour sa conception je me suis inspiré du dernier robot de Petoi (Bittle). L'auteur de ce dernier est au courant de ma réalisation et il suit mes avancées (il a une bonne, voire immense, longueur d'avance !). Le mien n'est pas aussi performant. Au delà de la programmation, mes pièces ne sont pas en plastique injecté comme le Bittle. J'utilise des servo MG90s que je vais remplacer par des MG92B. Bittle utilise des servo modifiés, produits par un industriel chinois selon le cahier des charger de Petoi. Mon projet de MG92B modifié est vraiment dédié à l'amélioration de ce petit robot

 

 

Au sujet de mon robot "5-bar", c'est l'une de mes meilleurs réalisations. La démarche au trot est venue immédiatement. J'ai affreusement copié sur tes propres réalisations ! Il est usiné en plaque d'époxy de 2mm. Toutes les articulation sont sur roulement à billes. Le corps comprend deux flancs en époxy et des couples usinés en nylon (noir). Il est un peu lourd comme la plupart de mes réalisations (1.6Kg).

Il n'avance pas très vite car les servos sont assez lents et les jambes trop courts. J'avais prévu une amélioration en m'inspirant encore de tes recherches en cinématique et en mécanique 5-bar. J'ai abandonné temporairement ce projet pour faire avancer le robot octopod baptisé Octopat !

Il met en oeuvre 8 servo standard de 20kg.cm distribués par HobbyKing.

[pat92fr]

Le robot "12-DOF" est encore une réalisation perso. Des heures d'impression pendant le confinement. Je voulais tenter l'entrainement direct des servos au niveau des articulations. Tu as raison, le problème n'°1 est effectivement le poids avec 2.2kg sur la balance. Le couple des servo est trop juste. La cinématique du mouvement des pieds n'est pas respectée. Le manque de rigidité aggrave problème. Quel échec !

 

Au sujet des servo, j'ai appris une petite règle simple. Le couple maximum (STALL) du servo doit être égale à environ 5 fois le couple nécessaire à la démarche du robot. C'est une bonne marge. 

 

Par exemple, un servo de 20kg.cm peut supporter un effort réel de 4kg.cm. Avec un entrainement direct sans démultiplication, et un fémur ou un tibia de 10 cm de long, cela fait un maximum de 400g de charge par patte. Au trot, il y a deux pieds au sol minimum, ça fait un robot de 800gr avec un montage en série des servos. En fait, ça doit pouvoir faire un peu plus car l'incidence du fémur ou du tibia va jouer sur le couple. C'est pour cela qu'on recommande des servos de 35Kg pour un quadrupède d'environ 1.6kg.

 

Avant le robot "12-DOF", il y a un premier modèle avec un entrainement démultiplié, toujours des servos en série. Encore une conception personnelle. Tout imprimé en 3D. J'ai abondonné tres tot le projet apres les premiers pas du robot. Ce qui m'a inquiété, c'est le bruit des servos sous le poids du robot (2.5kg). J'aurais peut etre du persévérer avec ce modèle de robot, car avec la démultiplication et sa rigidité, il était plus performant que mon second "12-DOF" (ci-dessus).

 

Pour tous ces projets, j'ai utilisé les mêmes servo standards et les mêmes outils de calcul de trajectoire de patte. Je programme tous les robots en ayant vérifié le couple et la vitesse de rotation des servos pendant tout le cycle cinématique de la démarche du robot. 

 

J'ai même simulé les performance sur un circuit que tu connais, bien avec un moteur 3D et physique (Bullet Physics).

Exemple de simulation avec Octopat :

https://youtu.be/MzaqUgacYcg

 

Lorsque la mécanique suit, les pieds ne dérapent quasiment pas, preuve que l'algorithme est plutôt bien conçu.

 

Au final, c'est le robot "5-bar", avec des servos en parallèle (5-bar) qui a le mieux fonctionné, avec une vitesse et un couple assez élevé.

 

A suivre.

Patrick.

[Oracid]

Tout ceci est vraiment très bien. N'hésite pas à me copier, c'est précisément le but que je recherche.

 

La vitesse et la puissance sont 2 paramètres présents dans les servos Lego.

Les servos Lego sont vraiment très bien. Par exemple, ils peuvent être utilisés en rotation continu ou en angle.

Ils peuvent faire plusieurs tours, à l'infini, le nombre de tours étant donné en paramètre. Ils peuvent être utilisé comme capteur d'angle.

 

Je pense qu'il faut avoir une réflexion globale sur le type d'actionneur adapté à la robotique.

[Mike118]

Bonjour,

 

Je viens de recevoir un complément de réponse de la part de FeeTech. Le support confirme qu'il est possible d'alimenter leur micro servo en 2S.

 

 

C'est plutôt une bonne nouvelle. Si jamais mon projet échoue, un plan B existe !

 

Il me semblait bien que j'avais déjà eu cette confirmation mais je dois dire que tu m'avais mis le doute ... 

 

 

En tout cas sympas toutes ces vidéo youtube que tu viens de poster ! Je me disais bien que tu en étais loin d'en être à tes premières réalisations Mais bon sans passer par la case présentation difficile de savoir  

En effet le robot palm size ressemble pas mal au robot petoi =) 

[pat92fr]

Pour la boucle d’asservissement, tu connais peut être Odrive. Je vais essayer de reproduire le même algorithme. Il permet de faire un contrôle en position, vitesse et courant.

C'est clairement sur-dimensionné pour un micro servo, mais si on peut le faire, je vois pas pourquoi on se priverait.

https://docs.odriver...om/control.html

 

Les actionneurs à base de moteurs brush-less reductés, sont certainement la meilleure solution. Encore un peu cher pour le moment. Le réducteur à pignon ou à courroie peut se fabriquer avec une imprimante 3D. Voir les OpenDog de James Bruton (https://www.youtube....h?v=esQAom1P5uI).

 

Je pense que la rotation continue nécessite un capteur de type encodeur. Il semble possible de remplacer le potentiomètre par un encodeur magnétique dans un servo standard.  Certains ont essayés avec un certain succès :

https://www.robotsho...d-servo/12999/5

https://hackaday.io/...agnetic-encoder

Ce dernier est vraiment bien réalisé. Je connais bien les produits AMS et ils sont faciles à mettre en oeuvre.

 

Dans un micro servo, il faut voir. Le volume est nettement plus faible et le plus souvent l'axe de sortie et l'axe du portard sont une seule et meme pièce. Difficile de retirer le potard dans ces conditions. C'est peut être possible. Je n'ai pas ouvert de MG92B. Faudrait décortiquer ce servo.

 

Sinon, il faut fixer le capteur à l’extérieur du servo, directement sur les bras/jambes, mais on s'éloigne alors de l'idée de départ qui est de modifier un servo et pouvoir remplacer sans changer la mécanique du robot un servo ordinaire en un servo modifié.

 

Patrick.

[pat92fr]

 

En tout cas sympas toutes ces vidéo youtube que tu viens de poster ! Je me disais bien que tu en étais loin d'en être à tes premières réalisations Mais bon sans passer par la case présentation difficile de savoir

 

 

Oui, merci et désolé pour le manque de présentation.   On s'est rencontré à la TRR2019, et à la Maker Faire 2019 à Paris. On a discuté par téléphone en début d'année, encore au sujet d'une histoire de servo pour mon premier quadrupède. Je travaille dans la même boite que Pascal. J'ai promis d'équiper mon octopod avec Vigibot. Et j'étais dans l'équipe Carré 92 à la TRR 2019, où on a fait courir le roulant "Neunoeil" ! 

 

Apres toutes ces réalisations, je reste franchement débutant dans le domaine des multi-pattes. Les calculs et les simulations ne remplacent pas l'expérience ! Mais je persévère ! Je suis pas prêt de battre Oracid et son 4BQ2 ou encore le GorillaBot de Sebastian à la prochaine TRR2021 ...  

 

A suivre.

Patrick.

 

La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Si la pratique et la théorie sont réunies, rien ne fonctionne et on ne sait pas pourquoi. < Un certain A.E. !

[Oracid]

Je suis en contact avec Sebastien  Coddington, https://www.robot-ma...pedes/?p=110937, j'ai fait une petite analyse de la cinématique de son quadrupède que je vais essayé d'appliquer au mien.

 

Aujourd'hui, je pense être encore le plus rapide, mais au train où vont les choses, je pense que Sebastian ou toi, vous allez me battre à plate couture avant la TRR de janvier.

Au dessus de 1kg, vous ne me battrez pas, en dessous, peut-être . . .

J'essayerai de faire une vidéo, peut-être dans un gymnase avec un parquet en bois.

 

Pour revenir au servo, ce serait peut-être intéressant de faire une carte non intégré au servo, mais qui pourrait commander 12 servos, individuellement. Seul, le potentiomètre resterait dans le servo.

[Mike118]

 

Oui, merci et désolé pour le manque de présentation.   On s'est rencontré à la TRR2019, et à la Maker Faire 2019 à Paris. On a discuté par téléphone en début d'année, encore au sujet d'une histoire de servo pour mon premier quadrupède. Je travaille dans la même boite que Pascal. J'ai promis d'équiper mon octopod avec Vigibot. Et j'étais dans l'équipe Carré 92 à la TRR 2019, où on a fait courir le roulant "Neunoeil" ! 

 

Apres toutes ces réalisations, je reste franchement débutant dans le domaine des multi-pattes. Les calculs et les simulations ne remplacent pas l'expérience ! Mais je persévère ! Je suis pas prêt de battre Oracid et son 4BQ2 ou encore le GorillaBot de Sebastian à la prochaine TRR2021 ...  

 

A suivre.

Patrick.

 

 

Je vois très bien qui tu es et sur le principe je vous dois toujours un coup à boire à toi et ton collègue! Je commençais à supposer que c'était toi Mais je n'en étais pas sur à 100% Je ne savais pas que tu avait autant avancer sur ton (tes)  quadrupède(s) C'est cool de te voir ici!

 

Moi je suis convaincu que tu vas faire un super challenger dans la catégorie multipatte !
Oracid en tremble déjà tellement qu'il a déjà décidé de ne pas participer ! ( joke  bien entendu   mais en référence à un message qu'il a posté Thot =/  vu qu'il pourra sans doute pas participer...)

Moi de mon côté j'ai tellement de projet différents en court que je ne sais même pas si je vais participer à la TRR ... Mon robot Ratler n'est pas sorti de son sac de rangement depuis mon dernier run à toulouse ... Je pense que j'essayerais quand même de faire le déplacement ... Mais bon je garantit rien ... 

Toi du coup je suppose que tu as prévu d'attaquer la course avec à minima un quadrupède en plus de noeneil cette année! C'est cool !   ( bon je vais m'auto modérer et m'arrêter là pour pas trop " pourrir ton sujet " et éviter de trop dériver ) 

Bref hâte de voir la suite

[pat92fr]

Pour revenir au servo, ce serait peut-être intéressant de faire une carte non intégré au servo, mais qui pourrait commander 12 servos, individuellement. Seul, le potentiomètre resterait dans le servo.

 

C'est une solution tout à fait envisageable. En termes de niveau d'intégration et de poids, c'est probablement la meilleure solution.

 

Dans un premier temps, je vais fabriquer une petite carte 'externe' pilotant un seul servo, afin de valider le concept.

 

Ensuite, on peut imaginer décliner la solution en plusieurs facteurs de forme en fonction du besoin, pour piloter un seul servo, 3, 8 ou même 12 servos par exemples. 

 

Le seul point technique qui m'inquiète est l'intégrité de signal analogique du potard. Ma crainte est que les fils du potard récupèrent les perturbations des fils moteurs, rendant la mesure de position bruitée. Ce n'est qu'une supposition, je ferai des mesures.

[pat92fr]

Juste une idée en passant.

 

Avec un asservissement maison, situé à l'extérieur des servo, il est possible de faire fonctionner deux servos en tandem. Doubler un servo coute 10g supplémentaires, deux fils, et une biellette pour relier les palonniers. Au final le couple est doublé pour coût très faible.

 

Avec des servos d'origine, ce n'est probablement pas facile d'obtenir un bon fonctionnement en tandem car le moindre écart de calibration risque d'endommager les servos ou d'être contre productif.

 

Avec des servos modifiés, c'est facile. Les moteurs sont mis en parallèle. Seul le potentiomètre d'un des deux servos est utilisé pour l'asservissement en position. Une seule carte de contrôle suffit.

 

J'ignore si cela peut être utile à un robot.

 

Attention les yeux, je ne suis pas très fort en dessin à main levée :

'M' : connexions du moteur

'P' : connexions du potard

[Oracid]

Il me semble que le doublage des servos est quelque chose qui se fait en modélisme, à vérifier.

Cela est tout à fait envisageable dans le montage du 4 barres tel que tu l'as fait, en bleu.

Il suffit de mettre un servo à coté de l'autre et de coupler les palonniers comme sur ton dessin.

 

Le principe de l'électronique déporté sur une même carte est en quelque sorte déjà utilisé sur les drones.

La carte au format de la carte processeur, s'empile avec des entretoises. Elle comprend les 4 ESC et l'alim.

 

Au final, c'est peut-être un bon plan.

[pat92fr]

Oui tu as raison, sur les gros modèles (direction de gros buggy, gouvernes des gros avions).

 

Tu as des photos de ce type d'empilement ?

[Oracid]

Tu as des photos de ce type d'empilement ?

Voici 2 liens où tu trouveras ce que l'on appelle des Combos, c'est à dire un empilement d'une carte processeur (STM32 en général), une carte ESC et une carte de distribution de la tension.

https://www.studiosp...2_1256.html#top

https://www.studiosp.../esc-c1875.html

 

Le marché du drone est très évolué par rapport à celui de la robotique, cela en raison de l'énorme marché du drone comparé au marché quasi inexistant de la robotique. 

[Thot]

Super boulot, ce sujet est passionnant ! On se rend compte qu'en robotique, on en est toujours aux bases du moteur et que ça évolue de jour en jour vers plus de couple pour moins de place et qui dure le plus longtemps possible sans cramer, et les makers y sont pour beaucoup.

 

Étant un utilisateur du petit XL-320, il y a aussi peut-être des idées à piquer de leurs côté. Mais aussi des idées à ne pas repiquer. Notamment le capteur de température. C'est même général avec les autres Dynamixel, le capteur de température est toujours loin du moteur. Ca permet d'éviter de cramer lors des efforts modérés prolongés, ou quand la température extérieure est élevée.

L'autre soucis c'est la protection de couple par la mesure de courant qui s'active de manière intempestive avec difficulté de ré-activer le servomoteur quand tout va mieux.

 

Amuse-toi bien !

[pat92fr]

Merci Thot.

 

Ça me rassure ce que tu dis sur les XL-320. J'ai des AX-12/18 et j'ai le même problème le couple ! Finalement, je suis obligé de mettre a limite de couple au maximum.

 

Je note de placer le capteur de température sur le moteur (sinon ça ne sert pas à grand chose en effet).

 

A suivre.

[Thot]

Merci Thot.

 

Ça me rassure ce que tu dis sur les XL-320. J'ai des AX-12/18 et j'ai le même problème le couple ! Finalement, je suis obligé de mettre a limite de couple au maximum.

 

Je note de placer le capteur de température sur le moteur (sinon ça ne sert pas à grand chose en effet).

 

A suivre.

Perso, je désactive la protection de couple et "je fais attention..."

[pat92fr]

Bonsoir,

 

Voici quelques photos du démontage d'un micro servo MG92b. Tout se démonte, y compris le moteur et le potard. C'est pas si mal fait pour le prix ! Comme ce servo est neuf, je n'ai pas tenté de démonter le potard. Une autre fois peut être. Du coup, je n'ai pas pu voir le second roulement à billes. Ce MG92b est vraiment le micro servo que je cherche à hacker pour en faire un servo "intelligent" adapté aux petits robots multipattes.

 

Dernière nouvelle, les premiers prototypes de la carte électronique sont en fabrication. Cette première carte est assez dense, au format 20x20mm :

- A droite, le connecteur d'entrée (alimentation + bus de communication serie half-duplex compatible Dynamixel et Feetech)

- A gauche, le connecteur vers le servo hacké (moteur, potard, et bus d'extension I2C pour un éventuel capteur de T°C à coller au moteur et/ou un encodeur quadrature magnétique en remplacement du potard)

- En haut, le connecteur de programmation et des points de tests.

- Dessous, deux LEDs : une alarme pilotée par logiciel + une autre alarme 'matérielle' pilotée directement par le driver moteur (signal FAULT).

 

Je croise les doigts pour qu'aucune erreur ne se soit glissée dans le schéma et l'implantation/routage. 

 

Puisque les PCB ne vont arriver que dans deux semaines, j'avance sur la partie logicielle. Je ferai une petite vidéo de l'asservissement en position et en vitesse la semaine prochaine.

 

A suivre,

Patrick.

Image(s) jointe(s)

• 
• 
• 
• 
• 
• 
• 
• 
• 

[Oracid]

C'est quoi le CI sur la carte ? Peux-tu nous donner le schéma complet ?

Est ce toi qui va souder ? A moins que l'implantation soit prévu en plus du PCB ?

 

Il y a peut--être un moyen de faire un circuit plus gros que celui d'origine.

Imaginons le servo posé sur une table, l'axe orienté vers le haut. L'idée, c'est d'occuper toute la base du servo en refaisant le capot du bas par impression 3D. De cette manière, tu aurais une surface d'environ 18mm x 9mm. 

Une alternative serait de ne pas toucher au servo lui-même et de coller un nouveau volume contenant l'électronique et les connecteurs, sous le servo.

Souvent, une plus grande hauteur du servo n'impacte pas le montage.

L'important, ce n'est pas le volume du servo, mais le poids.

[pat92fr]

Oui, les premières cartes seront soudées à la main ou en refusion. J'ai demandé le pochoir pour le TOP. La principale difficulté est la soudure du pad thermique du DRV.

 

Voici la schématique ! Il s'agit principalement d'un tandem STM32G4 + Ti DRV8876 (ou DRV8874).

 

Je prends tes idées pour l'intégration dans le servo ! On peut effectivement augmenter le volume sous le moteur, imprimer un capot 3D, et je suis complètement d'accord sur le poids.

 

Pour le RUN2, si tout se passe bien, il me semble possible de reprendre les mêmes IC, mais dans des boitiers plus petits pour gagner en encombrement. Je pense que 18x9 est faisable dans ces conditions, avec un fabriquant de PCB capable de faire le montage des CMS. Le DRV8876 est un composant assez récent, tous les fabricants de PCB ne l'ont pas dans leur bibliothèque de composants. Je ferai un devis en temps utile.

 

Il est également envisageable de faire une carte pour piloter un groupe de plusieurs servos.

 

Dans un robot façon 5-bar, les servos sont groupés par deux. Faire une carte pour un couple de servos, collée à l'arrière des servos, est peut etre une solution intéressante. Ca fait un taille de 24x22 mm environ.

 

A suivre, 

Patrick.

Fichier(s) joint(s)

•  MyServo.pdf   190,29 Ko   123 téléchargement(s)

[Oracid]

J'ai demandé le pochoir pour le TOP. La principale difficulté est la soudure du pad thermique du DRV.

Que veux tu dire ?

 

Quelques remarques. Sur ton PCB, je vois :

- un gros CI, ça doit être le STM32.

- A sa droite, il y a un petit CI, noté U2, l'alim donc, noté U2 TPS76333 sur le schéma.

- sur le PCB, je ne vois pas le CI noté U4 NC7WZ241 sur le shéma, je suppose que c'est un buffer vers un UART, non ?

- vers le bas, il y un emplacement vide pour un CI à 16 broches, noté U1, alors que le DRV8876PWPR est noté U3 dans le schéma, et qu'il a 18 broches !