75 réponses à ce sujet

[Thot]

Merci pour vos retours. En effet, mon objectif est toujours de rester dans la philosophie des recherches de TU Delft, de travailler en bipédie passive. Ca signifie que quand le robot se retrouve sur un pied, c'est un pendule inversé dont il faut plus ou moins contrôler la dynamique.

L'autre point de la philosophie de ce labo est de mener une recherche parallèle entre simulation et prototype.

Le prototype montre des choses que le simulateur ne montre pas, on améliore donc le simulateur qui montre des possibilités supplémentaires qui permettent de construire un autre prototype, etc.

 

Concernant le simulateur que j'ai fait, il s'agit d'une feuille de calcul simple avec un robot assimilé à un point de masse ponctuelle relié au sol par deux pendules. Le décalage que je décris plus haut est en fait pas lié au fait que le pied gauche ne décolle pas quand je raccourcis la jambe gauche. En effet tout le poids est dessus donc il ne décollera pas. Mais par contre, dans le cas d'un robot avec buste ponctuel, le pied droit ne devrait pas décoller.

En regardant la vidéo un peu plus il apparait en fait qu'en pliant la jambe gauche, le haut du corps, qui a une inertie non négligeable, se met à tourner. Cette rotation du haut du corps emporte avec elle la jambe droite qui se lève. Le haut du corps perturbe donc la dynamique de la marche.

Dans la prochaine version du simulateur, j'intègrerai cette inertie du haut du corps.

 

Dans la première vidéo, juste après que le robot se lève, je fais un mouvement lent où je transfère le poids le plus près possible du pied gauche pour pouvoir lever le pied droit. Puis je lâche tout en laissant les dynamiques naturelles se balancer jusqu'à ce qu'il n'y ait pas assez d'énergie... chute.

 

Je vais donc tenter d'utiliser ce "bug" pour lever la jambe pour avancer au lieu de sagement transférer les poids. Ca va faire une démarche un peu western mais bon, si ça tombe pas...

[Thot]

Une vidéo qui montre toutes les étapes du lancement de la dynamique

1 - le robot se lève

2 - le robot déplace son poids vers le pied d'appui gauche

3 - le robot entre dans une boucle conditionnée par les appuis sous les pieds et la vitesse de rotation vers la droite ou la gauche mesurée par le gyro. (Machine à état fini)

 

et le script utilisé pour ce "débroussaillage"

 

[Oliver17]

Excellent, vivement le jour ou j'arriverai à ça

Enfin....

 

 

Mais le pousse pas comme ça, sinon il va s'énerver ^^ lol

[Thot]

Sandro à dit :

(Si tu veux faire de la marche plus dynamique, il faut regarder le ZMP (Zero moment point) à la place du centre de gravité)

 

 

 

Pour le ZMP, ça reste malheureusement une solution valable pour les robots avec mécanique précise donc chère, avec les pieds plats équipés de capteurs d'efforts. Mon but est de faire avec une mécanique pas trop chère, même si je l'avoue, mon robot doit couter déjà dans les 1500€ avec des "moteurs tombés du camion".

J'ai tout de même serré les asservissement PID au max pour avoir un bon suivi d'angle. Mais on le voit sur les vidéos, il y a une flexibilité qui est là et un balancement naturel avec lequel il faut malheureusement travailler.

[Sandro]

Pour les capteurs de forces, tu en trouve à moins de 2€ sur aliexpress.

 

Sinon, dans ta simulation actuelle, est-ce que tu prends en compte l'écart entre les deux hanches? car je pense ça joue un rôle important dans le levé des jambes.

 

 

Un autre critère intéressant (en simulation) pour les robots à pâtes (bipède ou plus) est de voir si la marche converge vers un cycle limite (c'est à dire que les pas deviennent de plus en plus semblables au fil du temps, et qu'en cas de légère perturbation, on revient à la même démarche). Si tel n'est pas le cas, alors tu as une marche "chaotique", donc un fort risque de finir par tomber (sauf si à chaque pas tu simule la dynamique pour savoir comment te rattraper).

Pour tester si tu as un cycle limite, tu peux par exemple tracer la vitesse angulaire en fonction l'angle pour chacune des articulations : si tu as un cycle limite, alors ta courbe se rapprochera de plus en plus du cycle limite (ie d'une coube fermée).

NB : pour initier la marche, il faut parfois passer par un contrôle différent et/ou laisser le temps au robot de se stabiliser : il est donc normal qu'au tout début on soit loin du cycle limite

[R1D1]

J'ai peut-être déjà posté ce genre de choses, mais la question du simulateur est bien résumée ici: https://hal.inria.fr...518764/document

[Thot]

Bon, ça y est, la course est faite, mais je n'ai pas envie de ranger le robot !! pleins de tests, pleins de bugs, de trucs qui marchaient bien et deux vidéos de travail (merci oracid!!!)

Autre chose, qui est pour moi très importante, le robot a fait rire et sourire. Surtout quand il se gamelle et qu'il bugge. C'est aussi un axe de travail important.

Le but était pour moi de tenir le plus longtemps possible le cycle limite en poussant un peu vers l'avant. Comme je n'avais pas de contrôle en lacet, le robot n'allait pas droit. J'ai fait un moment dans les stands une période où le robot a marché pendant 3 minutes avant de tomber sur le sol pavé.

 

La suite va être de fiabiliser les contacts sous les pieds avec les capteurs de force de ce type là (deux sous chaque pied) (merci sandro !!!) : https://www.gotronic...635-5-17599.htm

puis commencer à monter le centre de gravité un peu plus haut que maintenant en contrôlant un peu plus la dynamique.

 

[Oliver17]

Je le trouve excellent ton robot, même si il n'a pas réussi à faire la course, j'imagine bien tout le boulot accomplis

Et ce genre de capteur pour le poids pourrait être intéressant, non ?

 

https://fr.aliexpres...rchweb201603_52

[Oracid]

Il manque pas grand chose...

[Thot]

Enfin les vacances pour avancer sur e-bunny. J'ai acheté les capteurs d'effort que vous m'aviez conseillé.

Ils sont assez longs (8cm de long) j'ai pris un calibre de 5kg qui me semble raisonnable. Il faut maintenant construire un pied, en mettre un à l'avant puis l'arrière, placer électronique sur le pied dans une petite boite et changer le moteur de la cheville pour un moteur débrayable.

Pour l'électronique, il y a 6 broches E+,E-,A+,A-,B+,B-, donc deux canaux de lecture. Je peux mettre les deux capteurs du pied sur la même platine.

Enfin, récuperer les données du circuit sur la Raspberry Pi, en direct ou via une arduino ?

[Mike118]

Oui tu peux utiliser deux capteurs sur une platine. 
Par contre c'est long comme acquisition. 
Il y a une lib arduino pour cette platine.

[Thot]

Ah oui en effet, c'est long ! ça vaut le coût de passer à 1 platine pour chaque point d'appui. L'occasion de tout passer sur Arduino côté capteur.

[Thot]

Voici l'intégration mécanique des capteurs de force. Du coup, ça fait un pied tout en acier.

Après d'un point de vue élec, malheureusement, je vais être obligé de mettre 4 platines sinon, les acquisitions vont être longues (10Hz par défaut mais on peut passer à 80Hz, 10Hz c'est limite quand un pas dure moins de 500ms)

 

[Oracid]

Les deux capteurs ne se trouvant pas sur le même plan, ne penses-tu pas que la longueur du bras de levier est différente entre la bascule à l'avant et la bascule à l'arrière ?

[Thot]

Si, il va y avoir une différence de bras de levier mais de toute façon, les capteurs étant différents aussi, il va y avoir aussi une calibration à faire. Peut-être que la calibration aura pour objectif de centrer le point d'appui.

Mais ce design a l'inconvénient de vachement glisser. Les têtes de vis, c'est pas top.

Il n'y a pas à réfléchir plus longtemps, il faut que je mette des chaussures, c'est l'idéal. Je l'avais fait pour les anciens robots.

[Thot]

L'acquisition des cellules de lecture de poids se fait par des amplificateurs pour ponts de wheatstone : HX711

L'acquisition des mesures, adaptées à de la mesure de poids est par défaut de 10Hz. Pour un bipède, c'est pas bon du tout.

Sur la platine que j'ai achetée, un accès est disponible à la patte "RATE" de la puce HX711. Elle permet de passer en théorie à une acquisition à 80Hz.

Après essai, je confirme que j'arrive bien à 80Hz d'acquisition de la force ce qui est vachement cool !!

 

Pour l'occasion, j'ai essayé deux autres choses :

- Arduino Nano Every : au top :-)

- des câbles fins en silicone. Les fils de câblage classique ont tendance à fatiguer à la torsion. C'est notamment pourquoi la plupart des câbles de multimètres sont en silicone pour être plus résistant à la torsion. Je confirme. En revanche, ces câbles sont très peu résistants à la traction. Si on tire dessus, ils cassent direct. Il faut bien les fixer en position et mettre du mou. C'est étrange à manipuler ces fils en silicone. Vous avez déjà essayé ?

[Mike118]

80 Hz c'est pas mal ! =) 

Tu m'as appris un truc là =) J'avais jamais fais attention à cette broche "rate" =)

[Thot]

Une première étape d'assemblage... Ca fait quand même chelou.

 

[Thot]

Au passage, voici le dépôt concernant les pieds de l'équipe Rhoban https://github.com/Rhoban/ForceFoot
 

[Thot]

Deux nouvelles reflexions sur la marche par rapport à la dernière course.

La première sur le pied. Cela a été le gros soucis. Une visite de l'anatomie du pied permet de voir que ce n'est pas juste un sac de peau avec des petits os.
En gros, c'est une struture a 3 points d'appui. Il y a une arche intérieure qui prend tout le poids, lié directement a l'articulation de la cheville, le talon et de l'autre côté de la voute plantaire.
Et un arche extérieure qui prend peu d'appui, relié au talon par une articulation sous la cheville dans le talon (subtalaire). Ca fait une sorte de fourche. Si l'appui extérieur est trop appuyé, ca veut dire qu'on est en déséquilibre vers l'extérieur !
Cette structure de fourche permet de naturellement mettre le pied à plat pour eviter de glisser.
Comment faire ce truc en acier ?

Ensuite, un zoom sur les «central pattern generator». C'est un contrôle qui génère un mouvement rythmique, cyclique, fonction de capteurs.
Il se trouve que des structures comme celles ci regissent notre marche a nous.
Un contrôle donc archi-simple qui se déforme fonction de l'environnement.
Ca correspond à l'algo que j'ai mis en place l'an dernier.
Faire simple, mais tester, tomber, tomber et tomber.