194 réponses à ce sujet

[Oracid]

Je pensais à un râtelier comme sur mon Shield où je connecte tous mes servos.

Comme les pins communes à n'importe quelle carte sont GND et V+, j'imaginais qu'ils pouvaient servir de connecteur sur un râtelier. 

Par contre, pour les fils longs du potard, ça peut poser problème.

Au final, tu as sans doute une idée précise dans ta tête et il vaut mieux avancer quitte à faire une nouvelle version après expérimentation.

 

Je ne comprends pas quand tu dis que le moteur est connecté en A/B et le potard en A/B/C . Ou alors, A=+, B=- et C=curseur du potard, mais ça ferait 3 fils et non 5 !

[pat92fr]

Pas de bol, ce n'est effectivement pas le cas, toutes les connexions (moteur et portard) sont indépendantes.

 

Oui, les fils longs pour le potard risquent de poser problème.

 

Oui, entre la carte et le servo, il y a 5 fils (deux pour le moteur et trois pour le potentiomètre). A/B/C ou +/-, c'est juste une convention. Ces éléments n'ont pas de polarité. Le logiciel permet de configurer le sens de rotation du potard et du moteur.

 

Pour le moment, je teste une implantation avec une carte pour trois servo, avec toute la connectique alignée sur un coté, comme un shield, mais je trouve que c'est moins compact pour le moment. Je suis à 45x25mm. Cela reste assez compact, mais il y a beaucoup de place de perdu sur la carte. Je travaille encore un peu dessus pour voir..

 

[Oracid]

Oui, entre la carte et le servo, il y a 5 fils (deux pour le moteur et trois pour le potentiomètre). 

Je ne comprends pas.

Pour alimenter le moteur, 2 fils suffisent.

Et pour le potard, un troisième fil, connecté au curseur. Non ?

[pat92fr]

A gauche, le moteur est raccordé à un pont en H de puissance, en courant commuté, à la tension de la batterie (avec inversion possible de la polarité +/- VM = +/-8.4V non régulé).

 

A droite, le potard est polarisé par une tension continue régulée filtrée; c'est une tension de référence analogique (Vadd / Vref stable à 3.3V).

 

[Oracid]

Ok, j'ai compris !

Alors, n'y aurait-il pas moyen de réunir les 2 connecteurs, cote à cote, de manière à faire un câble en nappe, vers le servo ?

La grosse capacité, est-elle absolument obligatoire dans cette taille ?

[pat92fr]

Oui, l'idée est de sortir un nappe relativement courte (5cm) de 5 fils (ou 3+2) entre la petite carte et le servo. Les courants sont faibles, le fils peut être de section réduite et ca ne va pas chauffer sur cette longueur.

 

Pour la capa, c'est effectivement surdimensionné. C'est une 220uF qui pourrait etre réduite des trois quarts. En revanche, sans capa, ca ne marche pas bien. Bizarre, les servos à ce prix n'ont en pas.

[Oracid]

En revanche, sans capa, ca ne marche pas bien. Bizarre, les servos à ce prix n'ont en pas.

A quoi sert-elle ?

[pat92fr]

Elle évite que la tension ne chute trop fortement lorsque le courant passe dans le moteur, surtout lorsqu'il est bloqué. Elle doit aussi participer à délivrer suffisamment de courant dans le moteur.

[Oracid]

On voit souvent ce type de capacité sur les ESC des drones, mais pas ceux qui sont empilés au centre avec la carte microcontrôleur.

Hobbywing skywalker 2-6s 80a ubec brushless esc with 5v/5a bec for rc airplane Sale - Banggood.com

 

Ici, sur la dernière image, on a l'impression que c'est optionnel.

30.5*30.5mm racerstar air50 3-6s 50a 4in1 esc built-in current sensor blheli_s dshot600 compatibled with airf7 lite Sale - Banggood.com

[pat92fr]

Oui, j'ai fait en sorte que la capa ce monte comme ton premier exemple. Elle est optionnelle et on peut mettre la capacité qu'on veut en fonction du besoin. C'est 10uF 16V minimum en théorie.

[Oracid]

En 10uF 16V, il y en a des petits, 100PCS 106 M 10uF ± 20% Y5V SMD Condensateur Condensateur Céramique multicouche 1206 (3216) 3.2mm×1.6mm | eBay

[pat92fr]

Exact. On peut aussi les mettre en parallèle pour augmenter la valeur C. Il faut un peu de place sur la carte. J'ai fait le choix d'un seul condensateur électrolytique déporté sur le coté de la carte, pour avoir le PCB le plus petit possible.

[pat92fr]

La version XL de ma petite carte de contrôle vient d'arriver, juste à temps !

 

Elle reprend les mêmes caractéristiques que la carte pour micro servo, avec un étage de puissance discret (Ti DRC8701 + 4x MOSFET CSD8853) bridé à 5A. Parfait pour un servo standard !

 

La carte est assemblée par JLCPCB et livrée dans l'état :

 

Hack d'un MG996R qui va me servir de cobaye pour les essais :

 

A la mise sous tension, le STM32G4 donne un signe de vie :

 

A suivre...

 

 

 

 

[pat92fr]

Sur la base de deux MG90s hackés, je construis une petite patte, facon mini pupper. Cela permettra de faire des tests, en charge, plus représentatifs d'un quadripède.

 

[pat92fr]

Pour tester deux servos, je me retrouve à coder une fonction IK, qui n'a pas l'air triviale, au premier abord. En général, le concepteur s'arrange pour rendre concentrique l'axe des servos qui commandent les articulations de la hanche et du genou. Mais pour économiser un peu de matière, et faciliter le montage, j'ai fait au plus simple d'un point de vue mécanique. Je commence à sentir que cela va payer cher en termes de calculs... 

 

On cherche à calculer les coordonnées du pied (x,y) en fonction de l'angle des servos 1 et 2 et de la longueur des segments connus (ex. : fémur, tibia, palonnier, biellette) :

 

 

Je vais donc aller me chercher une autre part de buche et méditer sur la méthode de calcul...

 

--(une heure plus tard)-- 

 

Un premier jet pour la démarche est le suivant (« ç » signifie « se calcule à partir de »). Je fais le calcul dans le sens inverse :

 

• Position de F ç Distance HF et Angle Ψ (cos/sin)
• Angle Ψ ç Angle α1 et Angle φ (somme)
• Angle φ ç Distance HF , Taille Femur et Taille Tibia  (loi des cosinus)
• Distance HF ç Taille Femur , Taille Tibia et Angle ϒ (loi des cosinus)
• Angle ϒ ç Angle θ et Angle Λ (somme)
• Angle θ ç Distance HK , Distance AK et Distance AH (loi des cosinus)
• Angle Λ ç Distance BK , Distance AB et Distance AK (loi des cosinus)
• Distance AK ç Coordonnées de K et A (distance entre deux points)
• Distance AH ç Coordonnées de A et H (distance entre deux points)
• Coordonnées de A ç Angle α2 , Position de S2 et Taille palonnier S2 (cos/sin)
• Coordonnées de K ç Angle α1 , Position de S1 et Taille Femur (cos/sin)

 

Mon pense-bête que je vais me faire tatouer dans le dos :

 

Si je ne trouve pas de démarche plus simple, cela fait beaucoup d’opérations mathématiques successives à traiter et de nombreux appels à la bibliothèque mathématique, et notamment les fonctions acos(), racine(), cos() et sin().

Le calcul temps réel sur Arduino MEGA risque de prendre un peu de temps (pas de FPU, émulation des nombres flottants sur architecture 8 bits   ).

Pour un simple test de servo, cela devrait aller. Pour un vrai robot, j'imagine qu'il ne sera pas préférable de partir sur une plateforme compatible Ardiono du genre ESP32 ou sur un µC plus performant (STM32 ou autre ARM 32 bits). Cela dit, si ca marche, je ferai le reste du robot pour la peine, car le plus dur aura été fait !

 

Je ne vois pas d'approximation possible. La distance entre l'axe des servos n'est pas négligeable. En outre, j'ai une petite démultiplication entre au niveau de la commande de genou.

 

A suivre.. 

[Sandro]

Bonjour,

j'ai une démarche plus simple, plus rapide à l'exécution, mais un peu moins précise, et plus gourmande en usage mémoire.

 

Il s'agit simplement de pré-calculer un maillage de correspondances entre les angles de tes servos et la position du pied.

Ensuite, si tu veux faire une conversion, il suffit simplement de faire une interpolation (dans la forme la plus simple, c'est une simple moyenne pondérée de nombre flottants; tu peux même faire les calculs avec des entiers en "virgule fixe" si tu veux encore gagner en rapidité d'exécution).

 

 

Ensuite, tu as le choix :

- soit tu fais tes calculs pour la cinématique directe (les calculs que tu as l'air d'envisager, et que tu appelles à tord cinématique inverse (IK)) : il s'agit de calculer (x,y) à partir de (theta1, theta2)

- soit pour la cinématique inverse (IK) : tu calcules (theta1, theta2) en fonction de (x,y) : en général, les calculs sont bien plus complexes

[pat92fr]

Oui c'est la cinématique directe que j'ai détaillé. J'étais en train de faire l'inverse en même temps. Sur un STM32, la puissance de calcul est suffisante. Mais sur une Méga, ce n'est pas le cas. Pas de bol, il n'y pas non plus bcp de mémoire la MEGA.

[Oracid]

Ce n'est pas moi, avec mon Certif, qui vais pouvoir beaucoup t'aider, mais peut-être que mes vidéos pourraient t'inspirer :

La cinématique inverse pour les nuls - Mécanique - Robot Maker (robot-maker.com)

Patte de quadrupède - mécanisme avec parallélogramme et extension - Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ... - Robot Maker (robot-maker.com)

 

- Déjà, peut-être que si S1 et S2 étaient à l'horizontal, tu verrais qu'il y a un 5 barres avec S1 et S2 comme châssis. HK et S2 A, comme fémur. AB et BK comme tibia.

- Peut-être que si AB et HK étaient d'égale longueur, cela pourrait simplifier le problème.

 

Bon, voilà, juste quelques idées, un matin de Noel.

Bon courage.

[Sandro]

Pour la cinématique directe, je crois j'ai trouvé une approche plus simple, en remplaçant la géométrie pure par de la géométrie à base de coordonnées cartésiennes.

NB : je suis partis sur un repère avec X vers la droite et Y vers le haut, et je ne me suis rendu compte qu'après coup de mon erreur. Du coup, il suffit de changer le signe pour avoir les résultats dans ton repère.

 

Il n'y a lors que 4 étapes :

1) Calculer les coordonnées de A comme S2+longueur(S2A)*vecteru_directeur(S2A)

2) Idem pour K à partir de S1

3) Calculer les coordonnées de B : pour ça, le plus simple me semble être de considérer que B se situe à l'intersection de deux cercles : celui de centre A et longueur AB, et celui de centre K et de longueur KB. On a donc un système de 2 équations à 2 inconnues.

4) BK et BF sont "proportionnels" : on en déduit F

 

Je te joins mes calculs (nb : il manque la fin de l'étape 3, mais c'est assez facile. Si tu as besoin d'aide, préviens moi)

 

 

 

 

Pour l'option de pré-calculer et de stocker des valeurs en RAM, je penses que ça peut se faire assez raisonnablement.

Si on suppose que chaque servo a une course utile de 90°, et qu'on découpe en tranches de 10°, ça fait 10 tranches.

Donc pour les 2 servos, ça fait un tableau de 10*10=100 cases. Si on y stocke des entiers 8 bits (par exemple la position en mm, éventuellement avec un offset, si ta zone de travail cartésienne fait moins de 255*255mm), alors tu n'utilises que 100 octets de RAM. Sur un total de 8ko, c'est quasiment négligeable.Et je pense que la précision avec une interpolation entre les 4 points de la grille autour du point cherché te donnera une précision suffisante. Au pire, tu doubles la densité de la grille, ce qui te faut 400 octets de RAM.

Si tu veux encore plus de précision, tu peux aussi stoker les valeurs dans la mémoire flash avec PROGMEM : là, tu as 256ko de disponible sur la méga, et d'après les infos que j'ai trouvé, une lecture ne prend que 3 cycles d'horloge.

 

Bref, je pense que sur une méga, tu peux sans problème te permettre de pré-calculer tes valeurs puis d'interpoler

 

[pat92fr]

Oui, je viens d'avoir la même idée pour la cinématique directe, puisque F,K,B sont colinéaires.

Le calcul de K est direct. Une fois B calculé, on obtient F.