182 réponses à ce sujet

[pat92fr]

Ok. La trajectoire ne semble pas symétrique. Si on prend le point de référence, à l'intersection entre le sol et la vertical au niveau de l'axe du fémur, tu devrais avoir un débattement en +X et en -X identique ?

[Oracid]

Je ne pense que ce soit un problème de symétrie ou d'asymétrie, c'est simplement que l'arrière ne touchant pas le sol, ce mouvement n'apporte rien de mieux que les précédents et même nous fait régresser.

 

Je vais tester ces mouvements en "Chapeau Chinois" que j'avais étudiés, il y a quelques temps. https://www.robot-maker.com/forum/topic/12207-gato-mon-petit-quadrupede/?p=99572 et  https://www.robot-ma...rupede/?p=99625

Comme la courbe du "chapeau de gendarme" fonctionne très bien, je me dis qu'il serait intéressant de revenir sur un peu sur ces mouvements naturels.

[Oracid]

Suite aux derniers échanges sur l'intérêt d'un mouvement courbe, je me suis souvenue que j'avais déjà étudié des mouvements de ce type fait avec le logiciel Linkage.

Ce logiciel ne permet pas vraiment l'utilisation de servo mais de moteur. Cela impose des mouvements rotatifs générés, par exemple, par des manivelles.

Ce type de dispositifs génèrent des mouvements "naturels". https://www.robot-ma...rupede/?p=99625

 

J'ai repris ici, ce mouvement que j'appelle "Chapeau Chinois". Et bingo ! Le résultat est vraiment excellent et se rapproche du score de la V6, https://www.robot-ma...apide/?p=111830

 

La grosse différence de la V6 qui a la forme d'un "Chapeau de Gendarme" et de la V10-1 qui a la forme d'un "Chapeau Chinois", c'est la forme de la courbe du "Swing".

Dans un "Chapeau Chinois", la courbure, les courbures suivent le mouvement naturel des servos, comme montré dans ma vidéo. On peut donc supposer que la vitesse des servos est plus grande pour faires ces courbes.

 

Voici le "Chapeau Chinois", la V10-1. 

 

Cliquez moi.

[pat92fr]

Je connais Linkage et il n'est malheureusement d'aucune aide pour simuler un mouvement à base de servo. Dommage 

 

Quel était la réaction avec une courbure pendant le stance ?

[Sandro]

Bonjour,

bravo pour toutes tes expériences!

 

Du coup, ça m'a fait un peu réfléchir a ton problème. Voici quelques pistes auquelles j'ai pensé:

1) Est-ce que la durée entre chaque point est bien constante? Si oui, alors tu peux probablement augmenter légèrement l'écart entre les points en mode "swing". En effet, un moteur DC (comme ceux contenus dans les servos) vont d'autant plus vites qu'ils ont peu de couple à fournir : ils devraient donc pouvoir aller un peu plus vite en swing qu'en stance.

 

2) Est-ce que tu penses que tu arriverais facilement à ajouter ta cinématique inverse dans le tableau excel? Si oui, je penses que ça pourrait être intéressant d'avoir les positions angulaires et les vitesses des deux servos d'une patte. Pourquoi? Car a priori, il est difficile d'estimer la vitesse de chaque servo pour une vitesse du bout de la patte.

2.1) Ainsi, si tu as une vitesse V en bout de patte, il est possible que tu ais une vitesse de rotation Vth=0 pour un servo et Vth=Vth_max pour l'autre (dans quel cas, tu peux difficilement aller plus vite), mais il est aussi bien possible que les deux servos soient en dessous de leur vitesse max, dans quel cas il devrait être possible d'augmenter (proportionnellement) la vitesse des deux servos sur ce segment.

2.2) Si tu vois que la vitesse du servo 1 est forte avant T0 et que celle du servo 2 est faible pendant ce même temps, et qu'après T0 la tendance s'inverse, alors tu peux envisager d'avoir une période de recoupement (où les deux servos ont une vitesse relativement élevée) : ça changera un peu la trajectoire, mais si ce changement n'est pas problématique, alors tu peux gagner du temps

 

3) Si tu arrives à mesurer le courant fournit par un servo (par exemple avec une toute petite résistance entre la masse et l'alim négative du servo), alors tu peux voir l'évolution du courant au court d'un cycle : si le courant est faible à l'instant T, c'est que le servo ne force pas, et qu'on peut donc voir s'il peut aller plus vite (s'il n'est pas déjà à vitesse max)

 

4) Si tu es prêt à souder un fil directement sur le potentiomètre du servo (ou d'acheter un servo avec ce fil en plus ou un servo "intelligent"), alors tu peux vérifier si le servo atteint la position désirée dans le temps impartit : si oui, tu peux essayer d'accélérer le segment correspondant

 

 

Pour l'allure même de la trajectoire :

5) Minimiser les variations de hauteur du centre de masse du robot est probablement une bonne idée (à chaque fois qu'on monte le centre de masse, il faut fournir de l'énergie, et je penses qu'on ne récupère qu'une petite partie de cette énergie). Après, en soit, ton but ne semble pas être d'économiser la batterie mais d'aller au plus vite, donc c'est peut-être moins pertinent (mais si on peut utiliser la puissance fournie pour avancer plutôt que pour faire monter le robot, je penses qu'on y gagne quand même)

6) Même si les petits servos moteurs ont très peu d'inertie, un changement de vitesse n'est pas instantané : à priori, j'aurais donc tendance à croire que des "coins" (comme les extrémités gauche et droites et hautes de ton chapeau chinois) ne soient pas optimales. Il vaudrait eut-être mieux lisser un peu la courbe si c'est possible (mais je penses pas que ça ait un effet significatif)

[Oracid]

Quel était la réaction avec une courbure pendant le stance ?

Je ne comprends pas ta question, le Stance est parfaitement rectiligne, à part les extrémités.

J'ai d'autres tests en réserve, basés sur ce Chapeau Chinois. Je m'y attèle de suite.

 

Merci Sandro, je comprends tes questions et tes conseils. Les points que tu soulèves sont très pertinents. La plupart du temps, il m'est difficile d'y répondre, mais je sais que Pat92fr s'y intéresse de très près.

 

1 - non, la durée entre chaque point n'est certainement pas constante. J'ai fait une multitude de mouvements et de tests, et en particulier avec des écarts allant jusqu'à 20mm entre 2 points. Ce n'est pas forcément une bonne idée car le servo décrira toujours une courbe entre ces 2 points, ce qui peut allonger notablement le parcours entre ces points. Un servo par définition trace une courbe. Par ailleurs, plus les points sont éloignés et moins le mouvement est souple. Il faut tester.

J'ai beaucoup travaillé avec mon banc de tests, https://www.robot-ma...rupede/?p=99471, et là, on voit très bien, par le dessin, quel est le mouvement et la vitesse des servos. Pour voir la vitesse et le dessin résultant d'un mouvement, il est préférable de l'exécuter lentement. Puis en augmentant la vitesse, on s'aperçois que le servo n'a pas le temps d'atteindre la consigne. Rien ne vaut une évaluation avec un banc de tests, mais attention, là on n'a pas le poids du robot et la réalité du sol.

2 - J'imagine que c'est possible, mais malheureusement je n'ai aucune connaissance en VisualBasic pour Excel.

2.1 à 4 - J'attendrai que Pat92fr face ses propres tests et apporte ces réponses, s'il le désire.

5 - Oui, là le but, c'est d'aller le plus rapidement possible, sur 10m, quoiqu'il en coute. Rendez-vous à Toulouse, à la prochaine TRR.

6 - Lisser la courbe, en haut ? Et bien, non, justement, car ce sommet est justement le point le plus éloigné sur X qu'il peut atteindre le plus rapidement. Evidemment, une étude, hors de ma portée, sur le rayon de la courbe, et donc la hauteur de ce point, pourrait apportée une grande amélioration.

[pat92fr]

Je pensais à une V9-2, symétrique pour éviter que le quad ne se renverse.

[pat92fr]

1) Est-ce que la durée entre chaque point est bien constante? Si oui, alors tu peux probablement augmenter légèrement l'écart entre les points en mode "swing". En effet, un moteur DC (comme ceux contenus dans les servos) vont d'autant plus vites qu'ils ont peu de couple à fournir : ils devraient donc pouvoir aller un peu plus vite en swing qu'en stance.

 

2) Est-ce que tu penses que tu arriverais facilement à ajouter ta cinématique inverse dans le tableau excel? Si oui, je penses que ça pourrait être intéressant d'avoir les positions angulaires et les vitesses des deux servos d'une patte. Pourquoi? Car a priori, il est difficile d'estimer la vitesse de chaque servo pour une vitesse du bout de la patte.

2.1) Ainsi, si tu as une vitesse V en bout de patte, il est possible que tu ais une vitesse de rotation Vth=0 pour un servo et Vth=Vth_max pour l'autre (dans quel cas, tu peux difficilement aller plus vite), mais il est aussi bien possible que les deux servos soient en dessous de leur vitesse max, dans quel cas il devrait être possible d'augmenter (proportionnellement) la vitesse des deux servos sur ce segment.

2.2) Si tu vois que la vitesse du servo 1 est forte avant T0 et que celle du servo 2 est faible pendant ce même temps, et qu'après T0 la tendance s'inverse, alors tu peux envisager d'avoir une période de recoupement (où les deux servos ont une vitesse relativement élevée) : ça changera un peu la trajectoire, mais si ce changement n'est pas problématique, alors tu peux gagner du temps

 

3) Si tu arrives à mesurer le courant fournit par un servo (par exemple avec une toute petite résistance entre la masse et l'alim négative du servo), alors tu peux voir l'évolution du courant au court d'un cycle : si le courant est faible à l'instant T, c'est que le servo ne force pas, et qu'on peut donc voir s'il peut aller plus vite (s'il n'est pas déjà à vitesse max)

 

4) Si tu es prêt à souder un fil directement sur le potentiomètre du servo (ou d'acheter un servo avec ce fil en plus ou un servo "intelligent"), alors tu peux vérifier si le servo atteint la position désirée dans le temps impartit : si oui, tu peux essayer d'accélérer le segment correspondant

 

 

Pour l'allure même de la trajectoire :

5) Minimiser les variations de hauteur du centre de masse du robot est probablement une bonne idée (à chaque fois qu'on monte le centre de masse, il faut fournir de l'énergie, et je penses qu'on ne récupère qu'une petite partie de cette énergie). Après, en soit, ton but ne semble pas être d'économiser la batterie mais d'aller au plus vite, donc c'est peut-être moins pertinent (mais si on peut utiliser la puissance fournie pour avancer plutôt que pour faire monter le robot, je penses qu'on y gagne quand même)

6) Même si les petits servos moteurs ont très peu d'inertie, un changement de vitesse n'est pas instantané : à priori, j'aurais donc tendance à croire que des "coins" (comme les extrémités gauche et droites et hautes de ton chapeau chinois) ne soient pas optimales. Il vaudrait eut-être mieux lisser un peu la courbe si c'est possible (mais je penses pas que ça ait un effet significatif)

 

Bonsoir Sandro,

 

Tes remarques sont très pertinentes. Tu as déjà réalisé un robot de ce type ?

 

1) Très juste ! D'autant plus qu'il faut aller plus vite en swing qu'en stance.

2) J'avais simuler 4BQ3 en python et pyBullet. J'avais cherché à estimer la vitesse de rotation des servos pendant la course, pour vérifier que les limites du servos sont bien prises en compte. Il faudrait que je mette à jour l'outil pour le nouveau robot d'Oracid. C'est assez instructif de voir les phases du cycle qui demandent le plus de vitesse et/ou d'accélération. La balle est dans mon camp, mais je souhaite finir mon projet de hack micro-servo avant. Sous Excel, c'est certainement possible. Oracid, tu penses pouvoir le faire ? Tu veux de l'aide ?

3 et 4)  Cela correspond à mon projet de hack de micro servo. J'espère arriver au bout. Avoir un retour d'information du servo, c'est presque indispensable pour optimiser la démarche.

5) La légère courbure au niveau du stance va effectivement générer plus d'effort sur les servos, mais si cela peut réduire la contrainte de vitesse en phase de swing, c'est peut etre une solution à explorer. Faut tester et mesurer ! Ca parait plus logique de maintenir le centre de gravité à la même hauteur pendant toute la marche. Mais dans la vraie vie, notre centre de gravité oscille pendant la marche, il doit y avoir une bonne raison !

6) Sur un MG90s, l'accélération maximale est de l'ordre 12000 degrés/s². Les changement de vitesse et de sens de rotation ne peuvent pas être instantanés. A prendre en compte. Ca rejoint le point 2).

 

Patrick.

[Oracid]

Voici mon dernier test, le Chapeau Chinois V11-1

J'ai explosé mon record à 370cm en 5s, soit 13.51s pour 10m.

 

Le mouvement semble bizarre, il est la fusion d'un Chapeau Chinois et de la base de mon mouvement en parallélogramme.

J'ai baissé le garrot à 150mm.

 

 

[Sandro]

Bonsoir,

Pour reprendre les différents points suite à vos réponses:

1) @Oracid : je crois qu'on s'est mal compris sur ce point : je viens de jeter un coup d'oeil sur ton code, et entre chaque point, intervalle de durée semble bien être le même (ie tu as une valeur fixe pour ton sleep).

Du coup, tu attends toujours la même durée pour effectuer un "segment". Hors un segment où tu ne forces pas devrait à priori aller plus vite qu'un segment où tu forces (à longueur égale) : si tu veux rester avec un intervalle de temps fixe entre deux commandes, alors je te suggère d'augmenter la longueur du segment parcourut dans cet intervalle si celui-ci est facile.

Si par exemple actuellement, avec ton pas de temps d'environ 4*500µs= 2ms, tu parcours 1cm pendant ce temps (ie entre 2 points de ton graphique), alors tu peux par exemple essayer si tu ne peux pas faire des segments de 1.2cm en phase de swing

 

2) Pas besoin de visual basic pour faire la cinématique inverse pour un cas aussi "simple" que le tient : tu as des formules exactes, donc il suffit de recopier ces formules dans excel, avec une colonne par variable intermédiaire. Si tu penses que c'est trop compliqué pour toi, je peux te le faire (sur libre office calc (que tu devrais pouvoir ouvrir directement dans excel, probablement sans problème) ou sur google sheet (tableur en ligne)). Pour obtenir la vitesse (approximative), on peut simplement faire la différence entre deux positions succéssives, divisé par l'interval de temps

 

3 et 4) c'est sur qu'un servo tout instrumenté est une solution idéale. Après, si @oracid tu as deux servos en rab, il sufffit de souder un fil a l'intérieur et on a un feedback analogique de la position (qu'on peut brancher sur un pin analogique de l'arduino)

 

5) Pour le fait de garder le centre de masse à hauteur constante, c'est surtout un critère pertinant pour l'énergie. Pour la vitesse, j'en sais rien. Dans la vraie vie, il me semble que sur les allures de marche (ie il y a toujours une jambe au sol), le centre de masse est assez stable chez la plupart des animaux (essaye de marcher en baissant significativement ton centre de masse à chaque pas pour voir). Après, sur des marches plus dynamiques (trot ou galop), la problématique est tout autre : il y a une phase de "vol" où aucune patte ne touche le sol : si on veut pouvoir voler loin à chaque bond, alors il faut monter suffisamment haut. Par contre, là, on utilise la magie des tendons, qui fonctionnent comme des élastiques, permettant d'absorber une bonne partie de l'énergie à atterrissage et de la restituer au décollage (d'ailleurs, il me semble que les amputés avec des prothèses en "ressort" sont extrêmement bon en course de vitesse).

 

6)@Oracid : je ne suis pas sur de comprendre ta réponse. Que tu ne veuilles pas changer les points à x=+-80, je comprends, vu que ça réduirait la longueur du pas. Par contre, je ne ne comprends pas l'importance du point x=0 y=30

 

 

Tu as déjà réalisé un robot de ce type ?

Non, j'ai jamais réalisé un robot à pattes (enfin sans si on compte mon robot de spéléo qui a 8 "pattes" avec une roue sur chacune).

En revanche, dans mes études de robotique, j'ai eut deux cours sur ces thématiques : l'un sur la locomotion bio-inspirée (surtout basé sur des oscillateurs basés sur des neurones("central pattern generator")), et un second sur les robots à pattes. Si vraiment il y a intérêt, je peux scanner les slides imprimés que j'ai annoté (pour le second cours, peut-être que ça devra attendre Noël, je ne l'ai pas retrouvé rapidement, du coup peut-être qu'il est chez mes parents). Ou alors je peux vous transmettre les coordonnées du professeur qui a donné ces deux cours et qui pourra peut-être vous transmettre les slides en couleur. NB : les deux cours sont en anglais.
 

[pat92fr]

Bonjour Sandro,

 

Au sujet des slides, ca m'intéresse beaucoup.

 

Patrick.

[Oracid]

Merci pour ton aide, Sandro.

Ici, il s'agit d'un quadrupède, le plus simple possible, avec des moyens à ma portée. Je pense que tu surestimes mes capacités.

Je suis certain, par contre, que Pat92fr sera intéressé par tes propositions et surtout n'hésite pas continuer à les soumettre, ici.

 

1 - Mon code est basé sur une boucle (Forward() par exemple) qui exécute la commande des servos "simultanément". Ce type de mouvement est tel que, pendant qu'une patte exécute une partie du mouvement, une autre patte exécute une autre partie. C'est ce que j'appelle un mécanisme perpétuel qui ne tient pas compte de son environnement.

Dans ce contexte, c'est bien le pas le plus lent qui sert de métronome et détermine la vitesse, indépendamment de la valeur du Sleep. Et il est impératif, pour que les mouvements de toutes  les pattes restent synchrone, que le Swing ait la même durée que le Stride.

 

2 - C'est hors de ma portée, mais Pat92fr serait peut-être intéressé.

 

3 et 4 - J'ai déjà fait cela, ça fonctionne assez bien. Mais je préfère attendre que Pat92fr avance dans son projet. Si cela reste simple d'utilisation, et surtout, si j'en ai l'utilité, je pourrais utiliser ce type de carte dans un quadrupède plus évolué ou un bipède. Pour mon quadrupède actuel, où j'hésite même à mettre des capteurs de distance, cela me semble disproportionné.

 

5 - Hors de ma portée.

 

6 - Comme je l'ai dit au point 1, c'est le pas le plus lent qui donne le tempo. Mais où se niche t-il ? Difficile à dire. Si on a la possibilité d'améliorer la cinématique, quelque soit  l'endroit, il ne faut surtout pas s'en priver, car c'est le mouvement global qui va donner la vitesse du Quad.

Jusqu'à présent, je faisais des belles figures, très symétriques, comme un rectangle ou un parallélogramme. Donc, je ne me posais pas de question, le Swing et le Stride était strictement identique.

Mais ici, si on commence à faire des figures avec des doubles saltos dans le Swing, il est important de ne pas trainer en route. L'idée, (dixit Pat92fr), c'est d'aller le plus haut possible pour que la patte se soulève. Hors, le point le plus haut se situe souvent au centre. Je me suis donc souvenue que j'avais fait des essaies dans ce domaine qui pouvait fonctionner. Et effectivement, ça marche très bien. Mais attention, dans ce cadre de recherche de la vitesse.

 

Remarque. L'idée de soulever une patte en lui donnant une valeur haute en Y, est une vue de l'esprit. Au contraire, le Quad va s'affaisser sur cette patte.

Pour soulever une patte, il faut abaisser la patte opposée, en diagonale. Et pour abaisser cette patte, il faut lui donner une valeur haute en Y.

C'est complètement contre-intuitif !

[Oracid]

Aujourd'hui, je n'ai pas réussi à reproduire le score d'hier.

Donc, je corrige, mon score est de 360cm en 5s, avec un garrot à 150mm, avec le Chapeau Chinois V11-1

[Sandro]

Bonsoir,

du coup, je t'ai fais un tableau excel (en pièce jointe) pour calculer la position et la vitesse approximative (différence de position divisée par le temps), en me basant sur ta fonction de cinématique inverse.

 

NB :

- j'ai pas une trajectoire complète, donc à toi de compléter le tableau vers le bas

- les figures sont sous le tableau (il y en a 3 : la trajectoire (qui correspond à ce que tu faisais déjà), la trajectoire angulaire des deux servos, et une approximation de leur vitesse)

- si tu veux une vitesse "absolue" des servos, tu devra ajuster le paramètre dt (en haut) : il s'agit de la durée entre deux points successifs (les 2ms correspondent au cas idéal où seul les delay ralentiraient le code)

- Attention, j'ai pas vérifié les calculs : donc fait un ou deux calculs avec ta fonction de cinématique inverse pour vérifier que je n'ai pas fais d'étourderies

 

Si tu as besoin d'aider ou si quelque chose n'est pas clair, n'hésites pas à demander.

 

 

PS : tu utilises mal le mot clef "static" dans ta fonction de cinématique inverse :

- static sert à ce souvenir de la valeur d'une variable d'un appel à une fonction à l'appel suivant, avec initialisation seulement la première fois. Par exemple :

void compter()
{
   static int n=0;
   n=n+1;
   Serial.println(n)
}

void loop()
{
    compter();
}

vas afficher les entiers 1,2,3, ... (au lieu de toujours 1 si tu enlèves le mot clef static)

 

Dans ton cas, tu voulais probablement utiliser "const" à la place de static (const signifie que la "variable" ne changera jamais de valeur (ce qui permet au compilateur de mieux optimiser, et de t'avertir si par mégarde tu cherches à modifier la "variable")

Fichier(s) joint(s)

•  FourBarQuad525.zip   16,19 Ko   83 téléchargement(s)

[Oracid]

Je ne sais pas quoi dire. Je suis impressionné. Un grand merci Sandro.

Je m'y mets dès demain. Je vais finir de saisir les données.

Après, il faudra que tu m'expliques comment interpréter tout ça.

 

Merci pour le coup du static, effectivement, c'était bien const que je voulais utiliser.

Super, l'idée de mettre le fichier dans un .zip.

[Sandro]

Avec plaisir.

 

En fait, le plus dur, c'est d'avoir les formules exactes de la cinématique inverse (parfois c'est tellement compliqué qu'on abandonne et qu'on procède par approximations successives à partir de la cinématique directe : dans ce cas, on sera assez bloqué ensuite pour utiliser excel).

Une fois qu'on a des formules exactes, il suffit de les recopier dans excel (qui comporte toutes les fonctions mathématiques usuelles), avec une colonne par variable intermédiaire. Certes, ça fait beaucoup de colonnes (et les formules ne sont pas très lisibles sous excel), mais ça se fait sans trop de difficulté.

Ici, là seule petite "difficulté" était le "if(e<0) S=-S", mais excel gère aussi les "Si", donc pas de problème.

Si par contre il commence à y avoir des boucles ou de la récurrence, alors c'est à peu près mort pour utiliser excel.

 

 

Par contre, s'il te plait, avant d'envisager d'utiliser les résultats, vérifie les valeurs de S1 et S2 pour une ou deux valeurs (ie regarde si ta fonction Arduino donne le même résultat). Vu que les formules Excel sont très indigestes, il est bien possible que j'ai laissé passé une étourderie (j'en ai fait au moins une que j'ai détecté car j'essayais de calculer des acos de nombres plus petits que -1, mais peut-être qu'il en reste d'autres).

 

 

Pour l'interprétation, il faudra voir en fonction de la courbe obtenue. Mais globalement, l'idée est que si sur un segment la vitesse des deux moteurs est lente, alors ce segment peut probablement être plus long (ie on peut le parcourir à une vitesse plus élevée). Inversement, là où les vitesses sont les plus élevées, il faut se méfier, c'est un des endroits où le risque est le plus élevé que les servos n'arrivent pas à suivre la consigne.

NB : cette analyse reste forcément biaisée, vue qu'elle ne tient pas en compte le couple à fournir, mais ça donne déjà des indications.

 

Je te propose qu'on en discute plus en détail quand tu aura un premier graphe des vitesses (nb : il ne sert à rien sans les deux autres, car sinon on ne voit pas à quelle partie du cycle ça correspond).

N'hésite pas à poster le fichier excel (dans un zip, car directement ça ne marche pas) en plus des figures, comme ça on pourra le modifier directement.

[Oracid]

Super !  Je m'y mets tout de suite.

Tu sais que tu peux utiliser mon programme sans servos, sans quadrupède, sans rien.  https://github.com/o...Bar525-1-V1.ino

Si cela t'intéresse, il te suffit de commentariser la ligne 47.

Dans la partie Debug (ligne 137 à 143), tu peux afficher l'ensemble des variables, ou simplement voir les angles des servos avec la ligne 143.

 

Sais-tu que tu peux envoyer tes données directement de l'Arduino vers Excel ?

Voici 2 vidéos qui expliquent comment faire avec 2 principes différents. Il y en a plein d'autres.

 

[Oracid]

Il doit y avoir un petit problème. Je ne trouve pas les mêmes valeurs d'angles S1 et S2.

Malheureusement, ce matin, je n'ai plus beaucoup de temps pour rechercher.

Voici le Debug de mon programme et ton fichier Excel.

Je n'ai pas réussi à zipper les fichiers, alors voici un lien vers GoogleDrive.

 

https://drive.google...QIe?usp=sharing

[Sandro]

Bonjour,

pour ton programme, je m'en suis déjà bien servi pour avoir les formules de cinématiques inverses.

Je sais que j'aurais pu utiliser une partie de ton programme pour tester, mais lors de mon premier message j'étais encore au bureau et je commençais à avoir bien faim, lors du second je commençais à avoir bien sommeil : du coup je n'ai pas fais cette étape de vérification (si tu veux que je m'en occupe, je peux, mais ce ne sera que ce soir ou peut-être même demain soir).

 

Pour l'envoi direct des données d'arduino à excel, je savais pas. mais ça ne me sert pas à grand chose, vue que je n'utilise pas excel (mais libre office) et que très rarement windows. Du coup, ce que je vais, c'est Ctrl+A puis Ctrl+C dans le moniteur série pour tout copier, puis je colle dans un fichier .txt que je renomme ensuite en .csv. Ensuite, il suffit d'importer le .csv depuis quasiment n'importe quel tableur (Excel, libre office calc, ...)

 

 

EDIT : je viens de voir ton message ci-dessus, que tu écrivais en même temps que moi le mien.

Du coup, je vais voir si j’arrive à trouver mon erreur, soit pendant la pause de midi si j'ai le temps, ou ce soir

[Oracid]

Désolé, c'est de ma faute, je n'avais plus exactement les mêmes paramètres en entrée.

Je te remets le lien avec le fichier Résultats.txt modifié, https://drive.google...QIe?usp=sharing

 

Voici une version du programme complètement expurgée de tout ce qui n'est pas nécessaire. Je n'ai gardé que la patte avant/droite.

Un Debug identique à ton fichier Excel permet de comparer les calculs.

Tu n'as juste qu'à lancer ce programme tel quel.

 

// FourBar525-1-V1 Version pour Sandro - 01/12/2020
#include <Servo.h>
unsigned long temp=0, start=0;
int Speed=550;                         // Speed determines le speed 
const int nb=8;                         // Number of servos
Servo Srv[nb];                          // Servos table
int OnOff[nb]={1,1,1,1,1,1,1,1};        // Servos table on/off
 
int FRLS=0, FRRS=1, FLLS=2, FLRS=3, BRLS=4, BRRS=5, BLLS=6, BLRS=7;
//***************** Correction for 90° LS and RS servos position     **************************************
// servos      FRLS  FRRS  FLLS  FLRS  BRLS  BRRS  BLLS  BLRS modify these values according to your servos
int Err[nb]={   0,    6,    0,    7,    0,    10,    12,   1    };  
//*********************************************************************************************************
 
// 29/11/2020 - symetric Chapeau Chinois V10-1 - Ay=150, a1=104, c1=88, Speed=500, 360cm
int FRx[]= { 80, 75, 70, 65, 60, 55, 50, 45, 40, 35, 30, 25, 20, 15, 10,  5,  0, -5,-10,-15,-20,-25,-30,-35,-40,-45,-50,-55,-60,-65,-70,-75,-80,    -80,-75,-70,-65,-60,-55,-50,-45,-40,-35,-30,-25,-20,-15,-10, -5,  0,  5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80};
int FRy[]= {  0, -5,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10,-10, -5,  0,      0,  1,  2,  3,  4,  5,  6,  7,  8, 10, 12, 14, 16, 18, 21, 25, 30, 25, 21, 18, 16, 14, 12, 10,  8,  7,  6,  5,  4,  3,  2,  1,  0};
 
int lgTab = sizeof(FRx)/sizeof(int);
         
void  setup() {
  Serial.begin(9600);
  int a=50;
  // Servos angle initialization
  if(OnOff[FRLS]){ Srv[FRLS].attach(2); Srv[FRLS].write(    a+Err[FRLS]); } // FR Front Right leg - LS Left   Servo
  if(OnOff[FRRS]){ Srv[FRRS].attach(3); Srv[FRRS].write(180-a+Err[FRRS]); } // FR Front Right leg - RS Right  Servo
 
  Forward();
}
 
void loop() {
}
 
void Forward(){
  for(int i=0;i<lgTab;i++){
    InverseKinematics(FRx[i],FRy[i],FRLS,FRRS);
  }
}
 
void InverseKinematics(int Px, int Py, int LS, int RS){
  const float A1x=0, A1y=145, A2x=0, A2y=145;                   // Values of servos positions
  const float a1=104, c1=88, a2=104, c2=88;                     // Values of leg sizes lengths
 
  float d=A1y-Py, e=Px;                                   // Calculation of inverse kinematics
  float b=sqrt((d*d)+(e*e));                              // Calculation of inverse kinematics
  float S=acos(d/b);  if(e<0)S=(-S);                      // Calculation of inverse kinematics
  float A12=acos(((b*b)+(c1*c1)-(a1*a1))/(2*b*c1));       // Calculation of inverse kinematics
  float A22=acos(((b*b)+(c2*c2)-(a2*a2))/(2*b*c2));       // Calculation of inverse kinematics
  float A11=(PI/2)-A12+S;                                 // Calculation of inverse kinematics
  float A21=(PI/2)-A22-S;                                 // Calculation of inverse kinematics
  int S1=round(A11*57.296);                               // left servo angle in degree
  int S2=round(180-(A21*57.296));                         // right servo angle in degree
 
// DEBUG
  Serial.print("\n Px=");Serial.print(Px);Serial.print("\t\tPy=");Serial.print(Py);
  Serial.print("\t\td=");Serial.print(d);Serial.print("\te=");Serial.print(e);
  Serial.print("\t\tb=");Serial.print(b);Serial.print("\t\tS=");Serial.print(S);
  Serial.print("\t\tA12=");Serial.print(A12);Serial.print("\t\tA22=");Serial.print(A22);
  Serial.print("\t\tA11=");Serial.print(A11);Serial.print("\t\tA21=");Serial.print(A21);
  Serial.print("\t\tS1=");Serial.print(S1);Serial.print("°\t\tS2=");Serial.print(S2);Serial.print("°");
 
  
  if ( b>(a1+c1) ){
    Serial.print("\n\t Target point Px=");Serial.print(Px);Serial.print(" Py=");Serial.print(Py);Serial.print("\t b=");Serial.print(b);Serial.print(" > ");
    Serial.print(a1+c1);Serial.print(" is too long. Target impossible to reach   !!!!!");
    return;
  }
  if (S1+Err[LS]<0){
    Serial.print("\n\t Position to reach : Px=");Serial.print(Px);Serial.print("  Py=");Serial.print(Py);Serial.print("\t angle S1<0° is not reachable   !!!!!");
    return;
  }
  if (S2+Err[RS]>180){
    Serial.print("\n\t Position to reach : Px=");Serial.print(Px);Serial.print("  Py=");Serial.print(Py);Serial.print("\t angle S2<0° is not reachable   !!!!!");
    return;
  }
  if (S1+Err[LS]>120){
    Serial.print("\n\t Position to reach : Px=");Serial.print(Px);Serial.print("  Py=");Serial.print(Py);Serial.print("\t angle S1>140° is not reachable   !!!!!");
    return;
  }
  if (S2+Err[RS]<60){
    Serial.print("\n\t Position to reach : Px=");Serial.print(Px);Serial.print("  Py=");Serial.print(Py);Serial.print("\t angle S2<40° is not reachable   !!!!!");
    return;
  }
//  Serial.print("\t executed command");
  if (OnOff[LS]) Srv[LS].write(S1+Err[LS]);   // set target Left servo position if servo switch is On
  if (OnOff[RS]) Srv[RS].write(S2+Err[RS]);   // set target Right servo position if servo switch is On
  delayMicroseconds(Speed); 
}