pat92fr

Pour moi, la longueur du robot est égale ou légèrement supérieure à la somme de la longueur du tibia et du fémur. Du coup, ca donne une indication de la garde au sol que je retiens (un peu supérieure à la longueur du tibia).

Ca permet de courir avec cette extension :

(désolé pour la pub Uni)

Pour le ratio entre la longueur et la largeur, je dirais environ K = 1.5 à 2 (ie. longueur = K x largeur). Comme je n'ai pas d'algorithme de stabilité, je ne sais pas augmenter ce ratio comme certains robots commerciaux et courir avec pieds qui se rapprochent d'une ligne (à l'extrème comme les chats).

Bravo Oracid. 2m/s avec un quadrupède XL en Lego, c'était pas gagné !

De toutes nos observations, on constate qu'une vitesse angulaire élevée des actionneurs (servo ou autre) aux articulations, notamment hanches/genoux, et une faible inertie des pattes, sont décisives pour obtenir une marche rapide. Réduire la masse totale du robot, et positionner le Cg le plus bas possible, sont aussi des facteurs de réussite (stabilité, accélération). La résistance des matériaux Lego atteint sa limite avec cette version XL, et il serait certainement possible d'aller plus loin avec d'autres matériaux. 

Il doit y avoir un gisement de gain de performance dans l'allure du robot. Aujourd'hui, on est limité à une forme très particulière du trot, sans phase de suspension avec des pieds qui peuvent même glisser sur le sol en phase de swing. Si on parvenait à réaliser un véritable trot avec une phase de suspension, les vitesses atteintes seraient intéressantes. Il faudrait non seulement conserver la vitesse de rotation des pates, mais parvenir à augmenter la force d'appui au sol, en fin de phase de stance pour donner l'impulsion nécessaire au "décollage". Il faut un (dos) châssis suffisamment rigide pour que cette impulsion déplace le centre de gravité de robot vers le haut et l'avant, et pas juste déformer le corps du robot au niveau des hanches. 

Avec des matériaux très rigides, de bons servos, et un moyen de reproduire des tendons pour absorber les chocs, voire restituer un peu d'énergie et surtout préserver les engrenages des servos....quitte à ce que cela ne fonctionne qu'à une seule vitesse optimisée. Faudrait un peu de temps !

Ce matin, j'ai profité d'une petite éclaircie pour faire quelques tests.

 

Dans Servo.h, j'ai modifié REFRESH_INTERVAL  3300

Avec un writeMicroseconds(1700) , une longueur d'itération à 15mm, un pas de 200mm, un Y = 15 et un garrot à 355mm, j'ai obtenu :

 

                     10m en 5,5 secondes

 

J'ai fait le test 3 fois, ce qui pour moi le valide. Mais, il faut relativiser car je suis à califourchon sur le quadrupède, pour éviter qu'il ne se renverse.

 

J'ai également testé avec REFRESH_INTERVAL  5000, mais je n'ai pas noté d'amélioration notable, par rapport à une valeur de 10000.

Maintenant, pour faire mieux, je peux revenir à une longueur d'itération à 10mm en diminuant la valeur du  writeMicroseconds(). L'allure sera plus souple.

Ou alors, j'augmente la longueur d'itération à 20mm avec un mouvement plus saccadé, mais plus rapide.

 

Mais la pluie revient . . .

On dirait bien que ta carte Arduino offre un bon niveau de performance et tient bon avec un REFRESH_INTERVAL petit. Est-ce que tu sais contrôler la fréquence PWM des sorties servo de ta carte Arduino, avec un analyseur numérique ou un oscilloscope pour valider le bon fonctionnement dans cette configuration de la bibliothèque Servo ?

Au passage, le réglage "ultime" serait de 3031 (avec une petite marge) puisque tes servos acceptent une fréquence PWM de 330Hz d'après les caractéristiques énoncées sur le site que tu as envoyé.

Ensuite, tu devrais harmoniser ton implémentation. Idéalement, ton algorithme de marche doit envoyer une consigne de position, à chaque nouvelle impulsion PWM, afin de profiter de la cadence des servos et de la bibliothèque Servo. Si tu ne respectes pas cette synchronisation, tu risques d'avoir plus de difficultés à faire le lien entre tes paramètres de configuration et leurs effets sur les performances réelles du robot.

Je t'invite à faire une itération de ton calcul de marche toutes les 3031 microsecondes (ou une fois sur deux à la rigueur) . On a déjà évoqué la façon de coder la boucle loop() avec une telle contrainte temps réelle. C'est facile. Tu remplaces do_action par ton calcul de la position des servos et par les appels writeMicroseconds(). tu auras certainement quelques ajustement à faire pour retrouver le comportement actuel de ton robot.

unsigned long previousTime = micros(); 
long timeInterval = REFRESH_INTERVAL*2; 
unsigned long counter = 0; 

void setup() { }

void loop() {
  unsigned long currentTime = micros(); 
  // Enter the If block only if at least 3031micros has passed since last time
  if (currentTime - previousTime > timeInterval) {
    // do action
    previousTime = currentTime;
    ++counter;
  }
}

Il se peut que la carte Arduino ne soit pas assez puissante pour tenir une telle cadence pour piloter les servos à 330Hz et exécuter tes calculs de démarche à la cadence de 165Hz. On avisera. Tu peux facilement vérifier si la cadence est tenue en affichant dans la console serie la valeur "counter*1000/millis()". Ca doit retourner 165 (Hz). Si ca retourne une valeur inférieure, et bien il faudra juste ajuster REFRESH_INTERVAL pour trouver la bonne valeur qui assure une synchronisation correcte entre tes calculs et les servos.

Patrick.

La fonction writeMicroseconds() permet de régler la longueur des impulsions PWM vers les servos. Mes ces impulsions ne sont envoyées que toutes les 20ms par le processeur avec Arduino/Servo.

Les servosacceptent un délai de l'ordre de 3.3ms (330Hz). Tu peux donc ajuster la valeur de la bibliothèque servo : 

#define REFRESH_INTERVAL    20000     // minimum time to refresh servos in microseconds 

Tester une valeur inférieure, 10000, 5000, 3300 et voir !

En cas de chocs, choisir un modèle de servo disposant d'engrenages robustes, en acier par exemple. Si le choc est trop important, les engrenages cassent, ou les roulements ou le boitier. Un servo même intelligent n'est pas fait pour encaisser des chocs violants ou répétés. Pour limiter le risque de casse, ou de fatigue à force de chocs répétés, il faut installer un mécanisme de sauve-servo.

Un quadrupède avec sauve servo intégré aux pattes : Petoi Bittle.

Les servo intelligents (Feetech, Dynamixel) offrent une capacité de limitation de courant/couple. Ce mécanisme est efficace en cas d'effort important avec une relative longue constante de temps. Cela ne permet pas de préserver le servo en cas de choc (constante de temps très courte). L'asservissement n'est pas assez rapide (électronique et logiciel interne). Du point de vue mécanique, l'énergie du choc est absorbée par les engrenages, pas par le moteur ou sa carte de contrôle. C'est le probleme des servos avec un rapport de réduction élevé... il faut passer sur un actionneur de type "quasi direct drive" pour mieux encaisser les chocs.

Patrick.

This one ! I have got two devices, both charging two batteriy packs. 

I have used this battery for the TRR for 12V servo : https://www.amazon.f...product_details

The overall current should be less than about 3 x STALL_CURRENT with a 12 DOF quadruped, but the power supply must be able to support inrush/peak current (start up sequence, touch down torque..). Do not use switched BEC or DC/DC converter between battery and servo.

Good luck !

Thank you TNERA.

About coaxial :

+ Design

+ Assembly

+ Lightweight

+ Straight math/kin.

- Larger robot body

Et en mode DLVV ! C'est non négociable ! Faut du spectacle et des grosses pénalités en jeu ! 

En tout cas même si j'étais pas venu en mode compète  ( comme les années passées   ) le fait qu'on ait fait de gros progrès avec la voiture ( on est quand même passé de 1min 45 à 1min ) ça me donne envie de pousser un peu pour vraiment essayer de titiller la première place de pat sur les roulants.... Je suis sûr que je peux faire en sorte de me rapprocher de pat à quelques secondes ( au lieu d'un peu plus d'une dizaine actuellement ) donc pat regarde des rétroviseurs je suis toujours derrière mais je me rapproche!  

Allez, je te laisse choisir le châssis et le LIDAR, et on se retrouve sur la ligne de départ de la prochaine édition !  :-)

J'allais dire la même chose à Oracid et son quadrupède, la concurrence se rapproche....

Je signe tout de suite, mais on perdrait tout le monde ou presque, tu ne crois pas ?

En fait, il y a deux types de circuit :

- F1teenth (bordures)

- Donkey Car (ligne, plots)

La seconde me semble beaucoup plus difficile, surtout dans les conditions de la TRR, c'est à dire avec la lumière naturelle.

Patrick.

Merci pour vos retours, les liens, les docs et les descriptions détaillées sur ce forum sont vraiment de qualité. Je ferai tout pour participer la fois prochaine, mon robot Imaginarium à turbine a des choses à montrer je pense

 

Si je vous dis que pour la prochaine, on décide de supprimer la ligne blanche au centre, ça vous fait peur ?

Vivement le retour du roulant à turbine(s) !

D'accord pour supprimer la ligne, car le suivi de la ligne est de toute façon trop hasardeuse (lumière du jour, reflets).

Oracid : une solution simple est de suivre la bordure, avec l'aide d'un lidar directif placé à droite ou à gauche du robot. C'est moins cher qu'une HuskyLens et plus fiable.

Patrick.

Il reste un dernier détail auquel VFH ne répond pas de manière théorique. 

Que faire lorsque le robot se trouve en difficulté, c'est à dire lorsque l'algorithme ne trouve aucun gap et donc ne produit aucune consigne de direction ?

Dans une situation "impossible", la réponse a été donnée par le robot lui-même vendredi après-midi pendant les essais libres, en coupant à travers les piétons situés au milieu de la piste, lorsque l'espace entre ces piétons et les bordures est faible ou insuffisant pour faire passer le robot !

Mais, si on écarte les solutions impossibles, il reste les situations où le robot a glissé et s'est trop rapproché d'un obstacle, dans la zone de distance inférieure aux 50 cm dans mon cas. L'histogramme ne donne aucun gap et l'algorithme se termine sans donner de direction.

Mon astuce est tirée de mes robots suiveurs de ligne. Dans ces robots, lorsqu'on perd la ligne, on braque la direction du coté où on a détecté la ligne pour la dernière fois... et on patiente ! Le plus souvent, on récupère la ligne et la course continue.

Sur "Blizzard", j'applique la même technique. Il braque les roues à fond du coté de la dernière consigne de direction calculée..... et pour tout le reste, il y a le parechoc à roulettes ! :-)

Patrick.

A hauteur du second piéton, le scan donne l'histogramme suivant :

On a deux gaps à 50 cm et un enchainement de gaps plutôt dans l'axe.

Le gap rouge sélectionné est le candidat se trouvant dans l'axe du robot. Et la direction choisie au final, est celle qui correspond au gap le plus éloignée de la série.

Ainsi, la trajectoire du robot est pratiquement en ligne droite, avec juste assez de décalage sur la gauche pour ne pas rouler sur les pieds du piéton. 

Une fois le piéton passé, on voit que le robot cible le gap au dessus de la tête du chat.

L'histogramme redevient trivial :

Voila.... l'algorithme est assez efficace et demande peu de calculs pour trouver une solution acceptable. 

Passons aux cas relatifs à la DLVV, et commençons par une map venue de l'enfer :

 map005obs.bmp   11,44 Mo   68 téléchargement(s)

Et faisons mouliner la simulation sur 12 secondes, départ arrêté :