Aller au contenu


Photo

Caliban Midi - E-Bunny

bipède Toulouse robot race

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

#41 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 24 juillet 2020 - 11:02

Impossible de trouver l'énergie de s'y remettre pendant le confinement... mais les chaleurs estivales m'ont remotivées, tant mieux !

L'occasion d'upgrader e-bunny avec les capteurs d'effort sous les pieds pour une version II.

La version I avait une Raspberry Pi avec le gyroscope branché direct en I²C, les capteurs de contact sous les pieds (des switch) et le dispositif de départ (un switch ILS avec un aimant).

Pour cette version, j'ai décidé de reporter la partie capteurs sur une Arduino Nano every avec donc 4 capteurs d'efforts sous les pieds, le gyroscope MPU6050, le switch de départ et une sortie de contrôle de LED NeoPixel.

Le but étant de voir l'état des capteurs en un coup d'oeil via les LED NeoPixel sur le robot sans forcément utiliser le PC.

Cela permet aussi de plonger un peu plus sur la manière de travailler avec un duo Raspberry Pi/Arduino.

Voici le code de la carte capteur : https://github.com/T...on/shoeFirmware

Que je recopie dessous. J'essaie de mettre toute la doc dans le code lui-même, sans artifice. Les PINOUT d'Arduino en ASCII Art, c'est vachement pratique !!

C'est une première version en mode "voir si ça marche", reste à mettre au propre.

#include "HX711.h"
#include <MPU6050_tockn.h>
#include <Wire.h>
#include <Adafruit_NeoPixel.h>
#define NUM_LEDS 11
#define NEOPIXEL_PIN 5

/*
Description :
Ce firmware a pour rôle de récuperer les valeurs de l'ensemble des capteurs sur demande
via port série quand la lettre "A" est demandée.
La réponse est envoyée en format json.
Voici le schema électrique de la carte :
                      +-----+
         +------------| USB |------------+
         |            +-----+            |
         | [ ]D13            MISO/D12[ ] |    
         | [ ]3.3V           MOSI/D11[ ]~|   
         | [ ]V.ref     ___    SS/D10[ ]~|   
 RB_DOUT | [ ]A0/D14   / N \       D9[ ]~| LF_DOUT
  RB_SCK | [ ]A1/D15  /  A  \      D8[ ] | LF_SCK
 RF_DOUT | [ ]A2/D16  \  N  /      D7[ ] | LB_DOUT
  RF_SCK | [ ]A3/D17   \_0_/       D6[ ]~| LB_SCK
     MPU | [ ]A4/D18/SDA           D5[ ]~| NEOPIXEL
     MPU | [ ]A5/D19/SCL           D4[ ] |   
         | [ ]A6                   D3[ ]~|   
         | [ ]A7                   D2[ ] | ILS  
         | [ ]5V                  GND[ ] |     
         | [ ]RST                 RST[ ] |   
         | [ ]GND                 RX1[ ] |   
         | [ ]Vin                 TX1[ ] |   
         |                               |
         |                               |
         | NANO EVERY                    |
         +-------------------------------+
*/         

//Description des I/O et declarations
//Lecteurs de force sous les pieds
// capteur droit avant (jaune)
const int FOOT_RF_DOUT_PIN = 16;
const int FOOT_RF_SCK_PIN = 17;
// capteur droit arrière (noir)
const int FOOT_RB_DOUT_PIN = 14;
const int FOOT_RB_SCK_PIN = 15;
// capteur gauche avant (rouge)
const int FOOT_LF_DOUT_PIN = 9;
const int FOOT_LF_SCK_PIN = 8;
// capteur gauche arrière (bleu)
const int FOOT_LB_DOUT_PIN = 7;
const int FOOT_LB_SCK_PIN = 6;

//Bouton ILS pour démarrage
const int ILS_PIN = 2;

// declaration des capteurs de force
HX711 foot_rf;
HX711 foot_rb;
HX711 foot_lf;
HX711 foot_lb;

// declaration du MPU
MPU6050 mpu6050(Wire);

Adafruit_NeoPixel pixels(NUM_LEDS, NEOPIXEL_PIN, NEO_GRB + NEO_KHZ800);

// declaration des variables
long force_rf=0;
long force_rb=0;
long force_lf=0;
long force_lb=0;
int  ready_rf=0;
int  ready_rb=0;
int  ready_lf=0;
int  ready_lb=0;
int test = 0;

void setup() {
  pixels.begin();
  pixels.clear();
  pixels.setBrightness(50);
  pixels.setPixelColor(5, pixels.Color(255, 0, 0));
  pixels.show();
  pinMode(ILS_PIN, INPUT);
  Serial.begin(115200);
  Serial1.begin(115200);
  Wire.begin();
  mpu6050.begin();
  mpu6050.calcGyroOffsets(true);
  pixels.setPixelColor(5, pixels.Color(0, 0, 255));
  pixels.show();
  foot_rf.begin(FOOT_RF_DOUT_PIN, FOOT_RF_SCK_PIN);
  foot_rb.begin(FOOT_RB_DOUT_PIN, FOOT_RB_SCK_PIN);
  foot_lf.begin(FOOT_LF_DOUT_PIN, FOOT_LF_SCK_PIN);
  foot_lb.begin(FOOT_LB_DOUT_PIN, FOOT_LB_SCK_PIN);
  pixels.setPixelColor(5, pixels.Color(255, 255, 0));
  pixels.show();
}

void loop() {
  // lecture des capteurs
  mpu6050.update();
  if (foot_rf.is_ready()){
    force_rf = -(foot_rf.read()-89287)/1000;
    ready_rf = 1;
  }else{
    ready_rf = 0;
  }
  if (foot_rb.is_ready()){
    force_rb = -(foot_rb.read()+41736)/1000;
    ready_rb = 1;
  }else{
    ready_rb = 0;
  }
  if (foot_lf.is_ready()){
    force_lf = -(foot_lf.read()-124089)/1000;
    ready_lf = 1;
  }else{
    ready_lf = 0;
  }
  if (foot_lb.is_ready()){
    force_lb = -(foot_lb.read()-17528)/1000;
    ready_lb = 1;
  }else{
    ready_lb = 0;
  }

  // led
  pixels.clear();
  if(force_rf+force_rb+force_lf+force_lb>40){
    pixels.setPixelColor(10*(force_rf+force_rb)/(force_rf+force_rb+force_lf+force_lb), pixels.Color(0, 0, 150));
  }
 
 
  if(Serial1.available()>0){
    char c = (char)Serial1.read();
    //Serial.println(c);
    if(c=='B'){
      if(test == 0){
        test = 1;
      }else{
        test = 0;
      }
    }
    if(c=='A'){
      // envoyer le json
      Serial1.print("{\"RF\":{\"F\":");
      Serial1.print(force_rf);
      Serial1.print(",\"S\":");
      Serial1.print(ready_rf);
      Serial1.print("},\"RB\":{\"F\":");
      Serial1.print(force_rb);
      Serial1.print(",\"S\":");
      Serial1.print(ready_rb);
      Serial1.print("},\"LF\":{\"F\":");
      Serial1.print(force_lf);
      Serial1.print(",\"S\":");
      Serial1.print(ready_lf);
      Serial1.print("},\"LB\":{\"F\":");
      Serial1.print(force_lb);
      Serial1.print(",\"S\":");
      Serial1.print(ready_lb);
      Serial1.print("},\"GYR\":{\"X\":");
      Serial1.print(mpu6050.getGyroX());
      Serial1.print(",\"Y\":");
      Serial1.print(mpu6050.getGyroY());
      Serial1.print(",\"Z\":");
      Serial1.print(mpu6050.getGyroZ());
      Serial1.print("},\"ANG\":{\"X\":");
      Serial1.print(mpu6050.getAngleX());
      Serial1.print(",\"Y\":");
      Serial1.print(mpu6050.getAngleY());
      Serial1.print(",\"Z\":");
      Serial1.print(mpu6050.getAngleZ());
      Serial1.print("},\"ILS\":{\"S\":");
      Serial1.print(!digitalRead(ILS_PIN));
      Serial1.print("}}\n");
    }
  }
  if(test == 1){
    pixels.setPixelColor(0, pixels.Color(150, 0, 0));
  }
  pixels.show();
  delay(10);
}

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


#42 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 29 juillet 2020 - 08:29

Voici ce que ça donne pour l'instant

 


  • Oracid et Forthman aiment ceci

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


#43 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 30 juillet 2020 - 06:35

ça avance !

Faut que tu sois près pour janvier . . .



#44 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 30 juillet 2020 - 09:43

ça avance !

Faut que tu sois près pour janvier . . .

Oui...

J'ai galéré sur certains trucs assez relou :

- Pour la carte Arduino Nano, on voit en bas à droite le port série RX/TX dispo, et sur la majorité des schéma, il est écrit RX/TX ou au mieux RXD/TXD. Je pensais que c'était le Serial du port UART0 mais en fait non, c'est celui du UART1, le UART0 étant réservé au port USB. C'est pratique mais encore faut-il le savoir.

- Ceci complété par le fait qu'en copiant mon ASCII Art de l'Arduino Nano Every, j'ai inversé RX et TX (qui sont donc RX1 et TX1)

- Enfin, c'est la première fois que j'utilise du Neopixel sous forme de bande. Je n'avais pas fait attention au sens, et c'est important !

sens_neopixel.jpg

- C'est rageant sachant que tout le reste (capteurs de pression, IMU, communication série montée à 25Hz) a très vite fonctionné. L'Arduino Nano Every est une très bonne carte.

 

Le robot est vraiment différent de l'an dernier, les nouveaux pieds en acier sont beaucoup plus robustes, sur les chevilles, j'ai mis des moteurs MX-28 afin de pouvoir les mettre en "roue libre".

La LED bleue du centre donne un rapport d'équilibre entre gauche et droite c'est une variable qui s'appelle xbalance.

Si xbalance = 0, tout l'appui est sur le pied droit (pied gauche en l'air), si xbalance = 1 tout l'appui est sur le pied gauche (pied droit en l'air).

Et j'ai maintenant toutes les valeurs intermédiaires !!

 

Pour l'équilibre avant/arrière, pour l'instant je fixe la position de la cheville de façon à avoir 20% du poids à l'avant et 80% sur le talon. Cela correspond à un couple faible sur l'axe de la cheville. Ainsi, avec les élastiques, en position debout, les moteurs ne fournissent quasiment aucun couples alors que je monte à quasiment 50cm de hauteur.

 

Enfin, on voit sur les côtés des pieds des sortes d'ailettes. Il faut voir ça comme des "roulettes" comme au vélo. Le mieux est que ça ne touche pas mais si ça touche, le robot tombe vers l'extérieur et est rappelé au centre naturellement pour éviter de tomber.


  • Oracid aime ceci

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


#45 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 30 juillet 2020 - 01:14

Enfin, on voit sur les côtés des pieds des sortes d'ailettes. 

Si un jour, je fais un bipède (pour l'instant je réfléchis), je commencerais par faire un portique sur roues avec avance automatique.

Le portique devrait détecter l'avancement du bipède et avancerait avec lui. Si le bipède chute, un capteur de pression sur les cables qui le retiennent ferait arrêter le portique.

Fastoche . . .



#46 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 30 juillet 2020 - 04:04

J'ai adapté l'algorithme de l'an dernier avec un centre plus haut et l'utilisation de la force sous les pieds :-) on passe à l'avance !!

 


  • Oracid et Little french kev aiment ceci

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


#47 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 30 juillet 2020 - 08:26

Il y a du mieux ! Bravo.



#48 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 31 juillet 2020 - 08:14

Si un jour, je fais un bipède (pour l'instant je réfléchis), je commencerais par faire un portique sur roues avec avance automatique.

Le portique devrait détecter l'avancement du bipède et avancerait avec lui. Si le bipède chute, un capteur de pression sur les cables qui le retiennent ferait arrêter le portique.

Fastoche . . .

Pour avoir fait différents portiques dont un manège, quand il s'agit de tester le robot suspendu les pieds dans le vide pour voir si les capteurs sont bien reliés ou encore si le moteur droit a le bon signe, c'est pratique. En dynamique, ça devient un perturbateur du mouvement pendulaire. Le robot va jamais droit. c'est frustrant.

Avoir un robot qui peut s'étaler de tout son long sans dégâts est un gros plus de design, le rattraper avec les mains permet aussi de ressentir plus la dynamique et comprendre plus vite. Voir le robot en train de tomber en vidéo au ralenti est aussi très instructif.

 

Justement, en regardant à nouveau la dernière vidéo au ralenti, l'an dernier, je levais la jambe droite que si la jambe gauche venez tout juste de toucher le sol (gràce au switch dans le talon). La jambe gauche n'avais donc pas le temps de se poser. Sur cette vidéo, je ne lève la jambe droite que si 80% du poids total est sur la jambe gauche. Ca change beaucoup de choses et stabilise par la même occasion la chute vers l'avant ou l’arrière.

L'autre condition est que si j'ai levé la jambe gauche et que je tombe vers la gauche assez vite, j'étends la jambe gauche pour reprendre appui.


  • Oracid aime ceci

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


#49 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 15 août 2020 - 10:49

En visionnant la vidéo au ralenti, en prenant du recul, on voit un mouvement de balancement qui n'est pas encore bien maitrisé.

Les apéros permettent des découvertes intéressantes  :P  On peut observer un objet qui est capable de marcher : la boite de Pringles. Si vous avez un tube à poster, c'est encore mieux. Vous l'écartez de son équilibre et vous laissez tomber.

Voici ce que ça donne (bizarre de faire une vidéo de ça :-) )

Je me rends compte qu'en ayant ce mouvement en tête, on comprend encore mieux la dynamique de la marche.

On voit que le mouvement pendulaire se calme par lui-même, l'énergie que l'on donne au début en écartant la boite de son équilibre se dissipe à la fois dans les frottements de l'air (négligeable) mais aussi dans les chocs que l'on entend sur la table à chaque "pas".

On voit aussi que si la boite est plus petite, la dissipation d'énergie est plus forte.

On voit que si on donne trop d'énergie au départ, la boite bascule de l'autre côté.

Cette sorte de "pendule de Pringles" est très intéressant. Faire un robot bipède dynamique consiste à équiper ce pendule de Pringles de capteurs/moteurs de façon à ce qu'il marche indéfiniment et qu'il avance.

 

A la lumière de ces observations, je suis en train d'équiper mon robot de ROS, et tant qu'à y être, pour apprendre et tester (j'en ai besoin professionnellement), j'installe ROS2. Jusqu'à présent, j'avais un script python qui tournait mais je n'avais pas moyen d'enregistrer les variations des capteurs, de les visualiser sur une interface et là ça me manque pour comprendre.

Sous ROS1, les tutoriaux étaient assez pauvres. Sous ROS2, ils ont fait ça beaucoup mieux : https://index.ros.or...ros2/Tutorials/

Sous Raspberry Pi, j'ai testé d'installer ROS2 sur Raspbian, c'est galère. J'ai donc testé d'installer la version "serveur" de Ubuntu Focal sur Raspberry Pi 3. Par dessus ça, l'installation de ROS2 Foxy a été rapide.

L'installation de ROS a souvent été un gros soucis, c'est tellement imposant qu'on se retrouve à avoir du mal à compiler un moteur de Deep Learning, Open CV, Collada... alors qu'on sait pertinemment qu'on en aura jamais besoin, voire qu'on ne comprend pas à quoi ça sert. Mais maintenant, en deux coups de sudo apt-get, c'est réglé.

Le noyau Linux de Ubuntu Focal sur la Raspberry Pi posait un petit soucis de stabilité mais il a été résolu.

La Raspberry Pi faisait un freeze complet au bout de 1 ou 2 minutes de lancement de ROS2.

 

J'ai pu créer les nodes d'interface pour l'Arduino, les Dynamixel et un node (encore en travaux) pour envoyer les infos vers un serveur node js qui héberge une page contenant juste un dessin vectoriel.

La page web ne fonctionne pas encore...

 

Enfin, pour l'Arduino, j'ai utilisé la librairie MPU6050_tocken pour lire les angles et vitesses de rotation, il s'avère que cette librairie me fait planter l'arduino à des moments que je ne comprend pas... Je vais passer à nouveau sur la librairie classique MPU6050 sachant que j'ai besoin des accelerations, des vitesses du gyro et des angles retournés par le calculateur de fusion (DMP) intégré dans le MPU6050 de très bonne qualité.

 

Reculer pour mieux sauter...


  • Oracid aime ceci

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


#50 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 11 septembre 2020 - 01:06

Un ami plutôt balèse en méca, ayant vu ma dernière version de jambes en profilé en L a voulu me développer de nouvelles jambes en profilé Beam et avec des roulements. Autant dire que le jeu est quasi éliminé :-) Et avec l'élastique, cette fois-ci, il tient debout vraiment tout seul.

 

IMG_20200911_135018.jpg

IMG_20200911_134324.jpg


  • R1D1 et macerobotics aiment ceci

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


#51 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 11 septembre 2020 - 01:27

Je pensais que tu connaissais ce type de profilé. Oui, c'est du costaud, mais c'est lourd !



#52 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 12 septembre 2020 - 01:38

Je pensais que tu connaissais ce type de profilé. Oui, c'est du costaud, mais c'est lourd !

Oui, je connaissais mais j'ai pas forcément pris le temps de concevoir un tel dispositif. Le robot passe de 2kg à 2.3kg avec ce profilé. Après, le poids est compensé par l'elastique donc c'est plus un soucis d'inertie... premiers tests demain :)


  • Oracid aime ceci

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


#53 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 20 septembre 2020 - 09:59

Comme on dit, "reculer pour mieux sauter"...

Au niveau de l'avancement, cela a surtout été de la mécanique. J'en ai profité, suite à quelques demandes, pour faire la liste du matériel nécessaire et mettre à dispo les pièces imprimées 3D de mon ami :

https://github.com/T.../Lapin-hardware

Le jeu est quasi-éliminé, c'est pas mal. Le robot pèse 2.3kg au lieu de 2.0kg auparavant. Le système "mousse + elastique de cuisine" sous les pieds fonctionne très bien et évite de partir en vrille. Enfin, l'élastique de cuisine qui compresse le parallélogramme compense entièrement le poids du robot.

 

J'ai refait le câblage aussi.

 

En premier lieu, j'avais essayé d'installer ROS2 sur Raspberry Pi 3B+. Cela implique d'installer Ubuntu-server sur la RPi3B+ pour avoir l'installation de base de ROS2. Mon retour est que la stabilité n'est pas encore au rendez-vous avec des crashs intempestifs à plusieurs moments. Pour travailler, c'est "très limite".

A priori, cela semble être lié à Ubuntu sur RPi qui souffre de stabilité mais aussi de réactivité. Je n'ai pas d'interface graphique mais quand on manipule quoditiennement une Raspbian de base, c'est trop lent.

Enfin, j'ai eu un "fatal crash" après un simple appui sur "TAB" pour faire de l'auto-complétion en Python3, impossible de récupérer le système en mode (initramfs)

 

ROS2 est sur le papier et dans les faits un gros plus pour faire un standard certifiable, mais pas encore sur Raspberry Pi, ce qui est dommage pour tester des trucs, et c'est à cause de Ubuntu. Un travail est en cours cependant puisque le turtlebot3, maquette utilisant ROS2 est sur cette configuration(RPi3 ou 4), ne fonctionne pas très bien encore.

 

Bref... à la base, il faut faire marcher un robot, il ne faut pas s'en rajouter encore => je suis repassé sur Raspbian avec mon code en Python3 (A voir si je fais du ROS1 mais j'ai pas envie)

 

Deuxième gros soucis, l'utilisation du MPU6050. Pour les besoins de recherche de dynamique, j'ai besoin de la vitesse de rotation mais aussi de l'angle absolu par rapport à la verticale du robot. J'ai donc voulu utiliser le module DMP de l'IMU qui est sensé donner un angle en fusionnant gyroscope et accéléromètre. Et bien j'ai beaucoup de mal à faire fonctionner ça, même avec les codes d'exemple, ça peut partir en sucette très vite (pourtant je fais gaffe à la calibration) ou alors passer l'I²C à l'état bloquant dans l'Arduino Nano Every de manière intempestive, chose que je n'ai jamais vu dans d'autres Arduino.

Je doute à plusieurs endroits :

- soit la gestion de l'I²C est chelou dans l'Arduino Nano Every (vous en avez déjà utilisé ?)

- soit la stabilité du DMP du MPU6050 est hasardeuse (pourtant avec les drones...)

- soit il y a un détail qui m'échappe

 

Deux solutions, soit je fais ma propre fusion mais elle sera à plus faible taux d'échantillonnage, ce qui me chagrine à cause des chocs, soit je passe avec une autre centrale inertielle qui m'a l'air plus utilisée : le BNO055 de Bosch (déjà commandée)

 

Avoir une base de travail électronique/informatique sur ce type de robot est un sacré boulot au final (avec le peu de temps que je peux y consacrer...)


  • Oracid , Mike118 et macerobotics aiment ceci

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


#54 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 04 octobre 2020 - 09:42

J'ai continué à travailler sur l'utilisation du MPU6050, exploré le web, et je suis tombé sur ce forum de discussion qui traite du blocage intempestif du MPU6050. Ce post en particulier, du concepteur de la librairie Arduino principale du MPU6050 montre que le MPU6050 est dans certains cas en violation du standard I²C, et devient bloquant. Refusant de modifier le lib I²C, il préconise d'utiliser d'autres produits (le MPU6050 commence à dater).

Par expérience, quand on ne lit que les valeurs brutes du gyroscope ou de l'accéléromètre, ça tient la route. Pour la lecture des angles absolus, c'est difficilement utilisable sur le long terme.

 

MAIS, j'ai reçu l'autre IMU, le BNO055 de Bosch. Je lui ai dessiné un instrument de torture afin de savoir s'il tiendra le coup :diablo: Un pendule.

dispo_pendule.jpg

 

Ce qui m'intéresse avec ce capteur, c'est d'avoir la position angulaire du pendule ainsi que sa vitesse angulaire à 100Hz. La précision doit permettre de calculer l'énergie cinétique du pendule et l'énergie potentielle de pesanteur du pendule. En faisant la somme, j'obtiens l'énergie totale qui doit rester constante dans le cas idéal, ou décroitre s'il y a des frottements. Et ce, si possible, pendant une journée entière.

La figure qui permet d'analyser un pendule est ce que l'on appelle le "plan de phase", on trace la vitesse de rotation du pendule (rapporté à la période du pendule) en fonction de son angle. Cela doit faire des cercles ou un spirale en cas de frottements. Voici la figure quand je lache le pendule quasi à la verticale :

pendulum.png

 

Cela montre d'abord que la physique c'est beau quelques fois et que le bruit du capteur est vraiment très faible. Le signal est vraiment très propre !!

J'ai pu jouer avec très longtemps, et même en perturbant la calibration du gyro au départ, au bout de 10s d'immobilité, il corrige automatiquement le biais.

Je suis vraiment étonné de la qualité du capteur (serait-ce la bon cette fois-ci ?)

 

Si on plonge dans la logique du pendule, son niveau d'énergie correspond au rayon du cercle dans le plan de phase. On voit donc le rayon diminuer proprement jusqu'à zero (sqrt(theta²+(thetapoint/w0)²)

 

On va donc pouvoir l'intégrer et le gérer en parallèle des capteurs de force sous les pieds.

 


  • Oracid et Mike118 aiment ceci

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


#55 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 12 octobre 2020 - 07:59

Faut aimer ça la robotique, mais quand ça veut pas...


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


#56 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 12 octobre 2020 - 08:22

Les difficultés augmentent notre espérance.  :)


  • Thot aime ceci

#57 R1D1

R1D1

    Modérateur et Membre passionné

  • Modérateur
  • PipPipPipPipPip
  • 1 211 messages
  • Gender:Male
  • Location:Autriche

Posté 13 octobre 2020 - 12:42

(Un peu de HS, mais j'ai aperçu dans la vidéo un robot Qbo, tu pourrais nous faire un retour d'expérience dans un autre sujet si tu as du temps ?)


  • Thot aime ceci
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#58 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 15 novembre 2020 - 03:58

Pour tester, j'ai acheté 10m de caoutchouc utilisé pour faire des frondes. C'est un tube en caoutchouc naturel, creux. L'adhérence d'un tel tuyau est très bonne et la tension de l'élastique très forte (ici, 1kg de tension implique +50% d'éllongation). Une matière intéressante et facile à assembler.

Si on attache deux brins ensembles avec un serflex, il est impossible de faire glisser l'un sur l'autre puisque le tuyau s'écrase.

 

feet.jpg


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


#59 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 769 messages
  • Gender:Male

Posté 15 novembre 2020 - 07:24

L'objectif, c'est de faire un patin, ou un ressort de rappel ?



#60 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 15 novembre 2020 - 07:37

A l'origine, c'était pour remplacer l'élastique de cuisine avec quelque chose de plus costaud. Mais vu l'adhérence, ca va aussi être un anti-patin.


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






Aussi étiqueté avec au moins un de ces mots-clés : bipède, Toulouse robot race

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

0 members, 0 guests, 0 anonymous users