Aller au contenu


Photo

Modification d'un (micro) servo pour robot à pattes


  • Veuillez vous connecter pour répondre
194 réponses à ce sujet

#121 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 25 décembre 2020 - 01:01

- 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.

 

Merci.

 

AB et HK sont différents mais c'est une biellette, je peux ajuster pour égaliser, et vérifier si cela simplifie ! En fait, "H.K.B.A.S2" forme un problème 5-bar.

 

Je ne peux pas mettre les deux axes de servos sur la même ligne horizontale, car je veux que le femur puisse remonter le plus possible, presque à l'horizontale.

IMG20201225125923.jpg

 

J'avoue que je n'ai pas monté les servos dans le bon sens. Les pattes de fixation des deux servos devraient être fixées en haut et en bas, et non à droite et à gauche. Je me suis un peu précipité au moment de la conception.



#122 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 25 décembre 2020 - 02:39

Merci du coup de main Sandro, c'est la bonne méthode pour la cinématique directe.

Résoudre une équitation du second degré sera toujours plus rapide que les calculs trigonométriques.

 

FKmicroleg.PNG

 

Pour l'intersection, je vais devoir réviser un peu ! http://math.15873.pagesperso-orange.fr/IntCercl.html

On doit pouvoir trouver du code toute fait en cherchant un peu je suis sûr.

 

Patrick.



#123 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 25 décembre 2020 - 02:56

Et pour la cinématique inverse, je trouve un mix entre trigo et vectoriel :

 

IKmicroleg.PNG

 

Il ne reste plus qu'à coder !

 

A suivre.



#124 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 25 décembre 2020 - 05:56

Je crois que tu as fait une petite étourderie sur la deuxième ligne de "calculs": c'est HF et pas HK que tu déduit de la norme de (x,y) ; HK, c'est une constante


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#125 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 25 décembre 2020 - 09:08

Bien vu ! Merci pour votre aide.  :thank_you:

 

Finalement, j'ai changé de repère pour avoir l'axe X dans le sens de l'avance du robot, Z à la verticale, orienté vers le haut et Y transversal au robot.

Ca me paraissait plus logique si je réutilise ce code pour un quadrupède complet !

 

Pour tester mes formules, je choisis de manière arbitraire une position (x,z) du pied, et je fais tourner ma fonction IK() pour en déduire l'angle des servo S1 et S2 (alpha1,alpha2).

Puis, à partir des angles des servos ainsi obtenus, je fais tourner FK() et je m'attends à retrouver exactement la position initiale (x,z) du pied !

Au passage, je prends quelques mesures sur la patte réelle pour vérifier que les angles et les coordonnées sont bons ! 

 

Voici les résultats et les performances sur MEGA, avec une première implémentation de la cinématique en C. Je joins monde code source. Pour l'implémentation de l'intersection, j'ai recopié sans chercher à comprendre la page web dont j'ai copié le lien dans un message précédent. J'ai juste ajouté un fonction de tri pour prendre la bonne intersection. Je ne cherche pas non plus à empêcher ou capturer l'exception de division par zéro, car cela ne peut pas arriver dans mon cas d'emploi particulier.

 

CaptureArduinoIKtest.PNG

 

Ca veut dire que pour un quadripède, je peux viser une consigne au moins par période de 10ms, peut être moins si le reste du code économise le CPU. C'est tout à fait honorable pour une si petit microcontrôleur.

 

Maintenant, il me faut définir une trajectoire de pied, si possible qui prend en entrée la vitesse d'avance du robot, pour faire un test complet de ma patte et de mes deux MG90s hackés.

 

A suivre !

 

Fichier(s) joint(s)



#126 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 26 décembre 2020 - 04:16

Pour définir la trajectoire du pied, je commence par estimer la zone atteignable. 

 

Avec mathplotlib sous Python, j'affiche en bleu l'ensemble des coordonnées (x,z) atteignables par le pied en tenant compte des débattements des servos et des contraintes mécaniques.

A cet effet, j'utilise ma fonction de cinématique directe avec quelques précautions (capture les exceptions mathématiques, notamment de la fonction d'intersection de deux cercles).

L'axe Z est représenté en noir. La démarche doit être centrée par rapport à cet axe.

Je trace en rouge la zone rectangulaire qui pourrait délimiter une trajectoire du pied pour l'exécution d'une démarche.

 

FootGaitSpace.png

 

Je trouve qu'avec ma micro jambe, la longueur de pas (stride) est de l'ordre de 6 cm (il faut laisser de la marge pour l'overlap de début et de fin de stance).

La hauteur de pas est de l'ordre de 2.0cm (il y a de la marge pour remonter plus en cours de swing au centre).

En position de repos, le pied se situe à (x z) = (0.0 -7,5 cm) environ.



#127 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 26 décembre 2020 - 09:09

Bonsoir,

pourquoi est-ce que tu dis que le rectangle doit impérativement être centré autour de l'axe des z?

Si ton rectangle vas plus vers la droite, alors le "milieu" du pas sera plus vers la droite, et alors?

 

Par exemple, si tu marches à quatre pattes sans poser les genoux, tes pieds sont toujours derrière tes hanches, mais ça ne t'empêche nullement d'avancer


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#128 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 26 décembre 2020 - 09:28

Non, il n'est pas nécessairement centré. Tu as raison, il serait possible de le déplacer dans une zone avec plus de marge par rapport aux limites de la mécanique.

 

Toutefois, est-ce qu'en prenant une démarche centrée par rapport à la verticale passant par la hanche, cela ne devrait-il pas réduire les efforts sur les servos ?

 

En outre, j'ai toujours en tête la cinématique de certains quadrupèdes (façon boston) dont la foulée mesure la longueur du tibia (le point le plus en avant), plus la longueur du fémur (le point le plus en arrière) et les deux membres ont une longueur assez similaire. J'ai même l'impression que le centre de la trajectoire du pied se décale un peu vers l'arrière lorsque la démarche est rapide.

 

téléchargement.jpg

 

Bon, il ne faut pas trop rêver... ce n'est pas avec deux micro servo que j'arriverai à ce résultat !  :mellow:

 

J'ai modifié la mécanique de cette micro patte :

- le fémur reste à 6cm,

- le tibia passe à 7cm (+1),

- la biellette diminue à 6cm (soit même longueur que le fémur)

- les bras de levier sont réduits et homogènes, donc ratio de 1:1 entre le servo qui commande le genou et l'articulation du genou.

 

IMG20201226205235.jpg

 

J'obtiens l'espace suivant et une zone intéressante pour la démarche avec une foulée qui peut atteindre 8 cm avec encore un peu de marge pour les overlap :

 

FootGaitSpace2.png

 

Maintenant, j'attaque la trajectoire du pied. J'essaie avec une courbe de Bézier pour changer. Il parait que c'est comme çà qu'il faut faire !

 

Patrick.



#129 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 26 décembre 2020 - 09:49

Pour la trajectoire du pied, je prends en compte :

- la vitesse d'avance (m/s)

- le temps de cycle = 360ms (arbitraire)

- la hauteur de stance = 3mm (arbitraire) ==> cela donne une légère courbure vers le bas

- la hauteur de swing = 2cm (arbitraire)

 

La trajectoire de stance est obtenue par une fonction trigonométrique. La trajectoire du swing par une courbe de Bézier et des points de contrôles (noirs)

 

A la vitesse d'avance de 0.33m/s (1.2km/h), j'obtiens, après quelques ajustements des points de contrôle, une jolie trajectoire, légèrement montante vers l'avant pendant le swing :

 

Figure_Gait_033mps.png

 

La vitesse d'avance du Cg est parfaitement régulière, y compris aux transitions entre stance et swing.

 

La rotation des servo semble harmonieuse !

 

Figure_Pos_033mps.png

 

Si on inspecte la vitesse de rotation des servos, il y a quelques accidents, mais on est dans les limites d'un MGxx :

 

Figure_Vel_033mps.png

 

Quand à l'accélération, je laisse tomber, je ne comprends pas vraiment pourquoi cela dépasse 10.000 deg/s² avec de telles variations. Au delà de 8kdps/s, le servo ne suivra pas, c'est sur, la trajectoire sera lissée par la force des choses...

 

Figure_Acc_033mps.png

 

Du coup, je sors ma MEGA et je fais tourner le code à vide :

STANCE :
Temps de calcul de la trajectoire : 212us
Temps de calcul de la cinématique inverse (IK) : 1720us
Temps d'émission de la consigne aux servo Hip et Knee : 1216us (2x emission successives, TODO : utiliser sync write)
Temps de récupération des positions réelles, vitesses et courants des servos Hip et Knee : 3064us


SWING :
Temps de calcul de la trajectoire : 24664us 
Temps de calcul de la cinématique inverse (IK) : 1532us 
Temps d'émission de la consigne aux servo Hip et Knee : 1120us (2x emission successives, TODO : utiliser sync write)
Temps de récupération des positions réelles, vitesses et courants des servos Hip et Knee : 2904us 

Et la c'est le drame ! Bézier à 11 points de contrôle sur MEGA, ca ne passe pas. Trop de calculs (factoriels, sommes, etc).

 

Difficile de tout précalculer, puisque la position des points de contrôle dépend de la foulée qui dépend de la vitesse. Je pourrai peut-être tabuler une partie des factoriels. Pas de bol !

 

Je continue les tests comme cela, ca n'ira pas à 0.33m/s, c'est sur ! Je commence à chercher un M5Stack ou une Nucléo STM32 pour la suite ...

Fichier(s) joint(s)

  • Fichier joint  bezier.zip   410 octets   70 téléchargement(s)


#130 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 27 décembre 2020 - 02:23

Cela faisait longtemps que j'avais un M5Stack Fire IoT sur mon bureau, inerte. Je veux persévérer dans la démarche à base d'une courbe de Bézier, alors je le branche.

 

IMG20201227131151.jpg

 

Bien sûr, il faut un TTLinker entre le M5Stack et les servos pour piloter cette liaison série sur un fil (half-duplex). Le petit module permet aussi de brancher directement le Lipo 2S pour alimenter les servos en 8.4V.

 

Le M5Stack Fire est un module construit autours d'un ESP32, le petit module Wifi/Bluetooth qui embarque un microcontrôleur d'Espressif Systems, avec plein de périphériques (SPI, I2C, UART, ADC, DAC, PWM, etc). l'ESP32 intègre deux cœurs microprocesseurs 32 bits cadencés à 240Mhz.  Le M5Stack intègre aussi une Flash de 16M et une RAM de 4M, une IMU 9 axes, un écran , des LEDs, des touches, un microphone, un haut parleur, et une batterie rechargeable. Seul regret, il n'y a pas de FPU matérielle pour accélérer mes calculs en flottant.

 

M5stackFire.jpg M5stackFire2.jpg

Il est livré avec deux liftarm, car la base du M5Stack est compatible Lego Technic.

 

Le M5Stack se programme en C/C++ Arduino et en Python (non testé). Mon code Arduino se porte sans difficulté majeure.

Le seul problème que j'ai rencontré, est que le port d'extension C du M5Stack, initialement réservé à la liaison UART utilisateur, est utilisé par le boitier mémoire interne spécifique du module Fire.

Il faut jouer avec le pin-muxing de l'ESP32 pour sortir son UART2 sur le port d'extension B du M5Stack, initialement réservé à l'I2C. La liaison série supporte un débit de 1Mbps sans difficulté.

// GROVE C port is TX:GPIO17 RX:GPIO16 not usable on Fire !
// Remap UART2 TX:GPIO26 RX:GPIO36 to GROVE B port
#include <M5Stack.h>
#define GPIO_PIN26 26
#define GPIO_PIN36 36
HardwareSerial ServoSerial(2);
ServoSerial.begin(1000000, SERIAL_8N1,GPIO_PIN36,GPIO_PIN26);

Le M5Stack dispose d'un port USB (type C) mappé sur l'UART0, qui fonctionne aussi à 1Mbps, permettant ainsi d'afficher des traces/debug à haut débit, sans trop pénaliser l'exécution du code.

Le temps de compilation dans l'environnement Arduino est correct.

 

Le module M5stack Fire pèse 63g avec sa batterie Lipo. On peut lui ajouter un module 12 servo à 18g ou un 16 servo à 28g. Les modules ont un connecteur Lipo au format standard respectivement XT30 et XT60 et un BEC intégré (pour le microcontrôleur seulement, pas pour les servos). Pour piloter les servo, il faut une batterie externe en plus de celle intégrée dans le M5Stack. Par contre, il doit etre possible de la retirer en présence d'une batterie externe.

 

Le M5Stack Fire est donc une solution un peu lourde, pour un petit robot. En effet, c'est à comparer avec une Arduino MEGA de 36g, un shield servo de 20g. En revanche, pour le poids, le M5Stack offre beaucoup de fonctionnalités toutes intégrées (pas de fils pour ajouter une IMU, un écran, etc) et le Wifi/BT pour la connectivité !

 

A noter qu'il existe toute une gamme de M5Stack et certainement des plus léger que la version Fire. La toute nouvelle version StickC Plus ne pèse que 15g, avec pratiquement tout autant de fonctionnalités que le Fire ! Il existe aussi un module pour faire de l'IA couplée à une caméra (modèle StickV) ...

M5Stick.jpg

 

Donc, je poursuis mes tests avec le M5Stack, en sachant que ca doit continuer à fonctionner avec une Arduino MEGA, mais avec des performances inférieures pour les calculs de Bézier.

Je finirai par trouver une solution pour optimiser le calcul de la démarche. Pour l'instant, c'est la carte micro servo que je veux finir de tester ! 

 

A suivre...

 



#131 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 27 décembre 2020 - 02:58

Les premiers résultats de performance avec le M5Stack arrivent ! Le gain est énorme par rapport à MEGA, sur les fonctions mathématiques, et cela devient compatible d'une démarche cadencée à 5ms.

Temps de calcul de la trajectoire (Bezier&Trigo): 368us
Temps de calcul de la cinématique inverse (IK) : 93us
Temps transmission de la consigne de position et des limites en vitesse, courant et PWM aux servo Hip et Knee : 979us
Temps transmission du retour position, vitesse, courant et PWM des servo Hip et Knee : 2429us

Maintenant, c'est la communication avec les servo qui se traine un peu et c'est valable aussi bien pour le M5 que pour la MEGA ! C'est donc mon code. J'ai deux optimisations possibles.

 

1) la première consiste à transmettre les consignes aux deux servo en un seul message, et sans attendre d'acquittement.

Dans mon code Arduino, j'utilise la fonction write du protocole de communication. Il faut donc deux appels, un par servo. En plus, le servo acquitte cette commande avec un éventuel code d'erreur.

Je fais donc évoluer mon code pour utiliser la fonction sync write du protocole de communication. Un seul message, contenant toutes les consignes de tous les servos, suffit et les servos ne l'acquitte pas.

 

Illustration avant/après :

 

Protocol2 Sequences-write vs sync write.png

 

2) la seconde consiste à récupérer toutes les données feedback en un seul message par servo.

Dans mon code Arduino, j'utilise la fonction read du protocole de communication. Mais je récupère les informations une à une, et pour les deux servo successivement.

Je fais donc évoluer mon code pour utiliser la fonction read en mode burst. Un seul message, demandant toutes les informations utiles, pour chaque servo. L'acquittement renvoyé par le servo contient alors toutes les valeurs demandées.

 

Illustration avant/après :

Protocol2 Sequences-burst read.png
 

Le résultat final est le suivant. Le temps d'émission des consignes et de récupération des informations de feedback (position réelle, vitesse, coutant, pwm) est plus que divisé par deux.

Temps de calcul de la trajectoire (Bezier&Trigo): 313us
Temps de calcul de la cinématique inverse (IK) : 73us
Temps transmission de la consigne de position et des limites en vitesse, courant et PWM aux servo Hip et Knee : 380us
Temps transmission du retour position, vitesse, courant et PWM des servo Hip et Knee : 1304us

Dans le cas d'un quadripède, le temps d'émission des consignes ne va pas augmenter beaucoup même si cela est en partie proportionnel au nombre de servo (taille du message contenant toutes les consignes). En revanche, pour le feedback, il faudra multiplier ce temps par le nombre de servo (compter 5ms pour 8 servos).

 

Note : Une optimisation consiste à récupérer le feedback de deux ou trois servo à chaque itération. il faut alors 4 itérations pour obtenir un feedback complet au prix d'une légère latence (20ms)... certainement acceptable.

 

Note : ma petite carte ne supporte pas encore la fonction sync read. qui permettrait encore de gagner un peu plus de temps pour le feedback. Ce serait une amélioration intéressante. Un peu complexe à développer au premier abord.

 

A suivre !



#132 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 27 décembre 2020 - 06:19

Ca commence à marcher... sur une patte, sans aucune charge, à petite allure (0.1m/s) ! Le feedback des servos permet de comparer les trajectoires attendue et réelle.

 

01-Footnoload.PNG

 

Pareil pour la position des servos :

 

01-Hip-noload.PNG

01-Knee-noload.PNG

 

On peut jeter un œil à la vitesse de rotation :

 

01-Vel-noload.PNG

 

et au courant moteur :

 

01-Current-noload.PNG

 

Toutes ces oscillations signifient qu'il y a un gros réglage PID à faire... cela dit, à vide, ce n'est pas forcement les bonnes conditions pour les régler. Je vais faire un test en charge.

 

A suivre.



#133 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 27 décembre 2020 - 06:49

Je mets en charge la patte, en l'approchant d'un sol lisse, de telle sorte qu'elle s'appuie et glisse sur cette surface pendant la phase de stance. 

 

02-Foot-loadedCapture.PNG

 

La phase de stance est compressée à cause de la collision avec le sol.

 

Le courant augmente dans le moteur en phase de stance, et il présente les mêmes défauts qu'à vide, trop d'oscillations !

 

02-Current-loaded.PNG

 

Bien, c'est le réglage des PID qui est à adapter. Il va me falloir un outil qui permette de les régler tout en pilotant les servos pour réaliser la trajectoire de pied.

 

Au passage, on notera que le courant dans les servos n'est pas tout à fait identique entre celui du genou et celui de la hanche. Ce montage mécanique de patte, n'est pas parfaitement parallèle. La hanche prend toujours plus chère (répartition 2/3 hanche vs 1/3 genou), contrairement à une patte en 4/5-bar. Mais, c'est quand même mieux réparti qu'un mécanisme de patte où les servos sont en série. En outre, l'inertie de la patte reste très faible.

 

A suivre...



#134 Thot

Thot

    Habitué

  • Membres
  • PipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse
  • Interests:Artiste Roboticien, prendre les dernières techno et les mettre sur scène... telle est ma devise.
    Gestuelle et conscience artificielle.
    Bipédie et quadrupédie

Posté 27 décembre 2020 - 07:17

J'étais en retard, ça a bien avancé ! passionnant !

Tu cherchais un test en dynamique, qui peut-être peut t'aider à régler les PID. Calculer la réponse fréquentielle du système. Soit du moteur pur, soit de la patte.

Tu fais faire un cercle à ta patte et tu regardes la trajectoire à différentes fréquences. Idem pour le moteur pur.

Tu peux tracer le diagramme de Bode avec la phase et le gain.

Tu pourras voir à quelle fréquence ton système est à opposition de phase et à quelle fréquence le moteur décide de plus bouger, ça va trop vite.


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#135 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 27 décembre 2020 - 07:28

Merci Thot !

 

Intéressante cette technique. Et bien, je vous dirai ce que cela donne dans les jours à venir ! Ca permettra de contrôler la géométrie de la mécanique aussi...

 

Sans le retour d'information, ces premiers résultats seraient certainement moins préoccupants. Pour me rassurer, je me dis qu'après tout, ce n'est qu'un micro servo d'entrée de gamme. C'est pas le top des actionneurs qu'on peut régler à la perfection. Mais, comme je ne suis plus très loin du but, j'essaie de terminer proprement, et de trouver les bon réglages. Je ferai peut etre mieux de passer sur les MG92b d'ailleurs.

 

Je vais commencer à faire des essais avec la carte en version XL pour servo standard. Je m'attends à un meilleur asservissement au final. Enfin, j'ai espoir !

 

Patrick.



#136 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 27 décembre 2020 - 09:13

Très intéressant, tout ça !

 

C'est horrible, la différence entre la consigne et le résultat avec contact du sol.

Intéressante, la comparaison entre un mécanisme parallèle et ce mécanisme décalé. Sur les Cheetahs et autre SpotMini, les moteurs sont bien au niveau du châssis, et une courroie relie le genou.

Attention au MG92B, j'ai eu une mauvaise série de 10. Ici, je n'ai pas eu de problème,   https://fr.aliexpres....31256c37oLHCo6

 

Je ne connaissais pas, ils ont l'air super, les M5Stack !



#137 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 28 décembre 2020 - 07:44

Cela m'a tracassé toute la nuit . . .

 

Le feedback des servos permet de comparer les trajectoires attendue et réelle.

 

Quel capteurs utilises-tu pour la position du pied sur le sol ? Intensité ?



#138 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 28 décembre 2020 - 10:31

La position réelle du pied est calculée à l'aide de la fonction de cinématique directe, en récupérant périodiquement la position courante (i.e. l'angle de rotation) de chaque servo.

La position courante du servo est retournée par la petite carte, en utilisant simplement le potentiomètre du servo. C'est cette position courante qui est utilisée pour l'asservissement en position effectué par la carte.

 

CaptureAsservissementScématique7.PNG

 

Mon code Arduino fait ceci à chaque période de temps de 10ms (en code simplifié) :

// calcul de la position du pied (x,y) en fonction du temps
gait(t,x,y);
// calcul des consignes d'angles des servo (a1,a2) à partir de (x,y)
ik(x,y,a1,a2)
// émission consigne d'angle vers servos
servo.setPosition(1,a1);
servo.setPosition(2,a2);
// feedback angles courants des servos
real_a1 = servo.getPosition(1);
real_a2 = servo.getPosition(2);
// calcul de la position réelle du pied (real_x,real_y) à partir des angles courants
fk(real_a1,real_a2,real_x,real_y);
// envoie vers le pc pour tracer
serial.print(x,y,real_x,real_y);

Est-ce que c'est plus clair ?

 

 

 



#139 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 28 décembre 2020 - 11:18

Je comprends, mais là tu as la position du servo et non de l'extrémité de la patte.

Avec les jeux mécaniques, la différence peut être importante.

J'ai beaucoup utilisé mon banc de test, https://www.robot-ma...e-et-extension/, pour tester un mouvement ou un mécanisme. A chaque fois, même sans charge, le dessin était différent de la consigne.  De plus, avec ce banc de test, je ne pouvais pas tester avec une charge. 

Alors, j'avais imaginé, mais pas réalisé, un banc de test qui prenait en compte la charge. Pour cela, une patte suspendue à une potence devait faire avancer un tapis roulant, puis j'ai eu l'idée de supprimer le tapis roulant et de mettre une roulette à l'extrémité de la patte. Pour la charge, il suffit de placer un poids sur la potence qui peut monter et descendre librement sur un rail.

Arrivé là, on a toujours pas le capteur du mouvement réel de l'extrémité de la patte. Alors, j'avais imaginé mettre un point rouge ou blanc sur cette extrémité. Puis je filmais avec une caméra quelconque. Avec un logiciel de montage vidéo, je jouais avec l'intensité des couleurs pour ne voir que ce point rouge ou blanc. En accélérant la vidéo, on devait voir apparaitre la forme du mouvement. Puis je prenais une photo de mon écran.

A mon avis, il est impératif d'avoir une vision réelle du mouvement.

Je ne sais pas si j'ai été très clair.



#140 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 28 décembre 2020 - 11:41

Oui, je vois. Tu as raison.

 

Il y a une différence à cause du jeu. Mais la patte est rigide (fémur et tibia ABS) et j'ai mis des roulements à billes au genou. Le jeu peut venir du servo (trés faible sur ma série) et de la fixation sur le palonnier (hanche surtout). Si je déplace l'extrémité du pied de l'ordre de 3mm par de légères pressions, je détecte les variations de position et de vitesse de rotation dans l'outil. J'en déduis que l'erreur d'estimation de la trajectoires réelle doit etre de l'ordre de 3mm maximum.

 

CaptureJeu.PNG






0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users