182 réponses à ce sujet

[pat92fr]

Pour moi, les 4 pattes bougent en meme temps. Ce n'est qu'un déphasage. La période et la phase sont indépendantes.

[Oracid]

C'est curieux. Tu n'as pas de temps de pause dans les routines IK ? A quel rythme tu envoies les consignes aux servos ?

Si, si, la dernière instruction dans la cette fonction, c'est delayMicroseconds(Speed);

Tu peux voir le code de ma dernière vidéo, ici, https://github.com/o.../FourBarQuad525

 

Pour moi, aussi, les 4 pattes tournent en même temps et sont déphasées.

Mais je garde la main sur les valeurs qui sont dans un tableaux.

C'est un peu lourdingue, mais efficace.

[pat92fr]

Oui, ca fait bien 448ms le cycle. C'est pas mal du tout. Je doute que tu puisses aller bcp plus vite d'ailleurs.

 

Mais, le code que tu as testé à 112ms devait aller 4 fois plus vite que la normale, puisque tu n'utilisais qu'une seule patte (et donc un seul appel à IK() par itération).

 

En effet, la durée de pause, à chaque itération dépend du nombre de fois que tu appelles IK(), puisque le sleep() se trouve dedans.

 

Tu pourrais mettre une seule pause (4ms environ), par itération (dans ta boucle dans forward), et retirer celle qui se trouve dans IK. C'est plus logique de déplacer tous les servos de manière synchrone, puis de faire une pause.

 

Comme tu as déjà calculé les positions (x,y) dans un tableau, tu pourrais gagner du temps, en calculant les angles de chaque servo pour chaque itération, soit hors du robot, soit dans la fonction setup().

 

Patrick.

[Oracid]

Mais, le code que tu as testé à 112ms devait aller 4 fois plus vite que la normale, puisque tu n'utilisais qu'une seule patte (et donc un seul appel à IK() par itération).

Je ne comprends pas ce que tu veux dire.
 

Tu pourrais mettre une seule pause (4ms environ), par itération (dans ta boucle dans forward), et retirer celle qui se trouve dans IK. C'est plus logique de déplacer tous les servos de manière synchrone, puis de faire une pause.

C'est un choix. A mon avis, cela ne changerait pas grand chose, mais à tester.
 

Comme tu as déjà calculé les positions (x,y) dans un tableau, tu pourrais gagner du temps, en calculant les angles de chaque servo pour chaque itération, soit hors du robot, soit dans la fonction setup().

Oui, ça, j'y avais pensé, bien sûr. Si la vitesse de l'Arduino était un facteur qui ralentissait la cinématique, il faudrait le faire, mais ce n'est pas le cas. C'est la vitesse des servos qui est le principal frein.
Et puis, j'anticipe toujours. Si tu es dans une situation où tu ne connais pas les positions, tu devras bien faire les calculs à la volée.
Ce serait le cas avec un quadrupède évolué qui réagirait en fonction du terrain. A mon avis, il est donc préférable de s'habituer à faire les calculs à la volée.

 

Avec l'Arduino, l'une des choses qui est très impactant pour la vitesse, c'est de faire des Print de debug pendant le cycle. C'est pour cette raison que je les mets en commentaire.

 

[Oracid]

Voici la V8 qui est identique à la V6,https://www.robot-ma...apide/?p=111830, mais en baissant le Stride de 5mm. Les Overlays et le Stride se retrouvent donc sous l'axe X, sous le plancher. En toute logique, j'ai également baissé le garrot de 170mm à 160mm.

 

Le résultat est identique à la V6 qui était le recorde absolu, mais avec une meilleure ligne droite, sans doute à cause du garrot plus bas, à 160mm.

 

Je retiens donc la V8 comme référence.

 

Cliquez moi.

 

[pat92fr]

Bien ! Garrot plus bas, veut dire que le Cg est plus proche du sol ?

 

Lorsque tu déplaces une jambe, tu appelles une fois sleep() par itération.

Lorsque tu déplaces les 4 jambes, tu appelles quatre fois sleep par itération.

J'en déduis que le déplacement d'une jambe devrait être quatre fois plus rapide que le déplacement de quatre jambes.

 

En mettant un seul sleep() dans ta boucle principale, tu contrôleras plus finement le temps de pause (meilleure résolution) et donc ca te permettrait peut etre d'optimiser un peu mieux la vitesse d'exécution.

 

Tu testeras la courbe négative pour le stride comme la trajectoire issue de ROS::CHAMP ?

 

Patrick.

[Oracid]

C'est pas sleep(), https://www.arduino.cc/reference/en/ 
Ok, je vais tester ça.

Tu testeras la courbe négative pour le stride comme la trajectoire issue de ROS::CHAMP ?

Comprends pas ! C'est quoi ROS::CHAMP ?

[pat92fr]

Dans Arduino, ca s'appelle delayMicroseconds().

 

La trajectoire définit par ROS::CHAMP est celle-ci ===>  

 

Tu as une hauteur négative pendant la phase stance, avec une légère courbure vers le bas.

[Oracid]

Oui, c'est la V1, https://www.robot-ma...apide/?p=111808. Je ne l'ai pas testé, car je suis parti sur ton mouvement, mais ok, je vais faire ça.

 

En attendant, j'ai testé le delayMicroseconds() dans le Forward. Et bien désolé, mais c'est moins bon.

Je pense que c'est peut-être plus compliqué que prévu. Ton raisonnement est bon, mais malheureusement pas validé par le test.

Peut-être que mécaniquement, le fait de faire une micro pause après le petit pas d'une patte, permet de désamorcer la petite contrainte de la position précédente de la patte suivante.

Ici, avec des pas d'environ 5mm, cela ne se voit pas, mais supposons que le pas soit de 2cm (chose que j'ai faite), les 8 servos seraient en mouvement  simultanément avec une grande violence.

 

Bon, disons que c'est un problème à analyser plus en détail.

[pat92fr]

Quand tu n'as qu'un seul delay() dans la fonction forward(), tu mets bien un délai 4x supérieur à ce que tu avais initialement dans ta fonction IK() ?

 

En fait, tu as toujours une petite pause entre chaque patte, meme lorsque tu n'as qu'un seul delay() dans forward(=, car tu alternes les calculs et le changement de position.

 

Le test est néanmoins intéressant !

 

De mon coté, je code un peu différemment :

- A l'initialisation, je programme un TIMER qui se déclenche à intervalle régulier (ex. 100Hz).

- A chaque déclenchement du TIMER, j'appelle une fonction qui fait deux choses principales :

1 ) Calculs Ik (sans bouger les pattes) pour définir la nouvelle consigne des servos,

2) Déplacement de tous les pattes en fonction de la nouvelle consigne calculée.

- La boucle principale du programme reste vide.

 

Tous les servos sont synchronisés et je règle ma cadence en Hz (ex. 100Hz) .

Le temps des calculs doit bien sur rester inférieur à la période ainsi définie (ex. : 10ms).

 

C'est codé comme ca en général. Voir le code de ROS::CHAMP par exemple.

 

Alors pourquoi ce n'es pas optimale sur ce quadrupède ? Pas facile de l'expliquer ! Peut être une explication électrique : lorsque tous les servos bougent en même temps, l'appel de courant est plus fort et si tu passes par un BEC, il a peut etre du mal à fournir toute le courant. J'y crois moyennement !

 

Attention, sur ta , tu n'as pas de courbure pendant la phase de stance. C'est entre les deux overlays qu'il faut ajouter la courbure vers le bas.

 

Patrick.

[Oracid]

Oui, bien entendu, j'ai multiplié le delay par 4.

Ta manière de faire est bien, aussi. Il doit y avoir pas mal de méthodes.

Je ne connais pas ROS::CHAMP, je ne sais pas de quoi il s'agit.

 

Voici le mouvement de la V9. Le mouvement est asymétrique. J'ai monté le Swing à 35mm, sinon les courbures n'étaient très . . . courbes.

Dis moi si tout va bien? J'espère tester demain.

 

Cliquez moi.

[pat92fr]

https://github.com/chvmp/champ

 

Un ensemble de composants logiciels pour l'environnement ROS qui permet de contrôler un quadrupède sans à avoir à développer. Ca peut tourner sur une Raspberry Pi.

 

Ca pourrait donner quelque chose comme cela :

 

En rouge : Swing

En noir : Stance

 

La durée Swing doit identique à la durée de Stance.

 

Patrick.

[Oracid]

La durée Swing doit identique à la durée de Stance.

Non, là, la durée du Swing ne sera pas identique à celle du Stance ! Mais je pense que cela n'a aucune importance, cela dépend d'où tu commences à appeler cela un Stance.

Je fais une nouvelle version et tu me dis ce que tu en penses.

Je croyais que la courbe du bas s'appelait un Stride.

 

Merci pour le lien, je vais regarder ça.

[pat92fr]

justement, j'ai coloré le diagramme pour te montrer où commence et où finit les deux phases. C'est la zone noire qui doit etre en contact. Les deux petites zones rouges du bas, sont l'overlay (une phase transitoire)

 

Si les durées ne sont pas identiques, il se peut que tu n'ais pas d'overlay. Lorsque deux pattes touchent le sol, deux autres se lèvent immédiatement. C'est moins stable. Moins performant.

 

Regarde ta propre démarche, il y a un court instant pendant le lequel tes deux pieds sont en contact avec le sol. C'est ca l'overlay. C'est un faible pourcentage (5 à 10%) tu temps total de la foulée (stride).

 

Patrick.

[Oracid]

V9-2

Et, comme ça ?

 

Cliquez moi.

[pat92fr]

Bien, pour la courbure. Y-a-plus qu'à tester !

 

Essaie de regarder pour les histoires de durée. Ca peut jouer. Sous pyBullet, l'overlay apporte un gain significatif sur 4BQ3 (+10% vitesse).

[pat92fr]

Voila, tu vois que 10% du stride ("Double support"), les deux pieds touchent.

 

Essaie de faire la même chose, avec les 4 pattes. 

 

[Oracid]

Test de la V9-2.

Catastrophique ! Le Quad se renverse à l'arrière dès le démarrage.

A vrai dire, je m'en doutais. Quand j'ai fait des mouvements asymétriques, c'est toujours la partie à l'arrière qui était la plus longue.

Je vais donc faire une translation de l'ensemble du mouvement sur X de 20mm.

[Oracid]

Voilà la V9-3.

Elle est identique à la V9-2, mais avec une translation de 20mm sur X+ de l'ensemble des points.

 

Cliquez moi.

 

[Oracid]

Test de la V9-3.

Ce mouvement n'apporte rien, c'est une régression.