Aller au contenu


Photo
- - - - -

Hector

VL53L0X Odomètrie RPLIDAR A2 Arduino Due

219 réponses à ce sujet

#201 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 05 août 2018 - 05:40

Ouais, merci. Je n'avais pas trouvé le code finalisé avec le sujet que vous avez fait avec Mike.

 

Je me suis posé cette question la première fois en javascript (là, j'ai juste fait la même chose qu'en JS) :

 

Moi j'ai choisi de mémoriser les données finalisées donc j'attend que le prochain header soit dispo pour lire les 84 octets (les 16 cabins et le prochain header) et traiter la trame en une seule boucle. Sur les 128 octets au total du buffer RX, j'attend donc qu'il soit rempli à 65%.

 

Toi, si tu as un seul octet de dispo à la lecture, tu le prends et tu mémorise les données avant la compensation. On ne peut appliquer la compensation d'angle qu'à partir du moment où le header suivant est arrivé. Ce qui t'oblige à repasser sur les 32 mesures à postériori pour appliquer la compensation. C'est un choix qui se respecte. Il est optimisé pour minimiser la quantité d'octets que tu laisse dans le buffer RX. En plus de cette optimisation, je sais que tu passe par une interruption pour lire le RX.

 

Pour choisir une approche ou l'autre, ce qui peut aider, c'est la taille du buffer.

 

D'où ma question plus haut : tu connais la taille de ton buffer sur le PIC32 ?

Tu trouve ça dangereux pour la perte des trames d'attendre un remplissage à 65% ?



#202 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 05 août 2018 - 06:08

Je voulais un driver qui se suffit a lui même car d'origine j'ai un FIFO UART hardware de 8 octets de profondeur.

 

Le portage de l'API Arduino pour PIC32 s'appelle ChipKit et la dedans ils ont mis une salopperie de while(1) bloquant le temps que ça se vide, pendant la transmission !!!! j'ai crié au scandale chez les développeurs, et après une quantité astronomique d'échanges avec Matt (je pense le meilleur dev du projet ChipKit) voir https://github.com/c...core/issues/326on a fini par réussir à fiabiliser le truc (j'en ai chié) ça fait pas très longtemps que j'avais des corruptions d'un octet de temps en temps.

 

Maintenant j'ai un FIFO "illimité" via interruptions qui exploite correctement le FIFO hardware de 8 octets,en TX et en RX sur les 6 UARTs. Je pourrais gratter 1% de CPU en passant en DMA mais a quoi bon... C'est du code non portable je préfère maximiser le générique

 

65% du FIFO de 128k aucun problème si le code temps réel est bien fait et ne le laisse pas atteindre 100%


Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#203 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 05 août 2018 - 11:56

Je ne connais pas la taille du buffer hardware sur la Due. Il ne doit pas être bien gros. Je comprends que tu aies préféré les interruptions à l'ajout d'un buffer software.

Je posterai quand j'aurai fais des tests plus avancés.



#204 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 06 août 2018 - 01:05

Euh c'est grâce aux interruptions levées par rapport à l'état du FIFO hardware que tu peux ajouter un plus gros buffer software derrière ! et c'est ce que j'ai fait:)

 

Après il est possible de le faire full hardware en configurant le module DMA qui permet des écritures directement en RAM sans passer par le CPU.

 

Versus comme je fais avec mon processus logiciel de bête copie de variables qui se trouve dans une interruption et qui est exécuté par le CPU.


Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#205 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 08 août 2018 - 07:27

Voilà un retour après les premiers essais.

 

Avec ma méthode : pas d'interruption sur le RX. J'attend la dispo sur le port série des 84 octets de la trame avant de les lire. Le temps de traiter la trame, à la boucle d'après, le buffer RX s'est rempli à environ 50 octets. Et c'est stable.

 

Ce chiffre, je l'obtient avec peu de choses dans le traitement. Mémorisation d'un tour complet et juste la transformation des coordonnées polaires en cartésiennes. Rien d'autre.

 

Si je rajoute le scheduler, le chiffre témoin monte vite et dépasse la taille max du buffer RX. (et perte de données) Le scheduler, c'est pas adapté.

 

Si je veux sortir les données sur un autre port série, je dépasse aussi le buffer. Que ce soit au fil de l'eau ou par paquets, c'est pareil. Mais je suis presque sûr que c'est l'IDE en java qui ralenti le tout.

 

Idem en voulant afficher les points sur mon petit ecran oled. Là, je suis sûr que le dispositif i2c est trop lent. 

 

Bref, le parser du lidar tient dans un arduino due. Oui. Je n'arrive pas encore à obtenir des infos de debug. Et, il y a peu de marge pour le code du SLAM, si je veux le faire en simultané. 

 

https://github.com/P.../Hector-Due.ino

 

Je lâche pas le morceau. J'attaque une lecture alternée (start - stop - start ...) avec une machine à états. Il me faudra aussi re-synchroniser la lecture des trames.



#206 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 09 août 2018 - 02:17

Vu que tu parles de conversion du polaire en cartésien je te colle la totalité de du driver qui la comprend ainsi que le calage des array[0] au Theta zéro du lidar. Tu parles aussi de pb d’ordonnancement de mon côté j'ai au pire une seule "méta"cabine à traiter en integermaths ce qui ne foire pas l'ordonnancement. Je suis curieux de voir ton avancement.

 

cos16() et sin16() fonctions qui exploitent une lookup de 16 bits de taille sur 16 bits d'amplitude directement en mémoire flash pour les maths integer.

#define PI16 0x8000
#define PISURDEUX16 0x4000
#define UN16 0x8000

const uint16_t sinTable16[] {
 0x8000, 0x8003, 0x8006, 0x8009, 0x800C, 0x800F, 0x8012, 0x8015, 0x8019, 0x801C, 0x801F, 0x8022, 0x8025, 0x8028, 0x802B, 0x802F,
 0x8032, 0x8035, 0x8038, 0x803B, 0x803E, 0x8041, 0x8045, 0x8048, 0x804B, 0x804E, 0x8051, 0x8054, 0x8057, 0x805B, 0x805E, 0x8061,
... sinus ...
 0x7F9E, 0x7FA1, 0x7FA4, 0x7FA8, 0x7FAB, 0x7FAE, 0x7FB1, 0x7FB4, 0x7FB7, 0x7FBA, 0x7FBE, 0x7FC1, 0x7FC4, 0x7FC7, 0x7FCA, 0x7FCD,
 0x7FD0, 0x7FD4, 0x7FD7, 0x7FDA, 0x7FDD, 0x7FE0, 0x7FE3, 0x7FE6, 0x7FEA, 0x7FED, 0x7FF0, 0x7FF3, 0x7FF6, 0x7FF9, 0x7FFC, 0x8000
};

int16_t sin16(uint16_t angle) {
 return sinTable16[angle] - UN16;
}

int16_t cos16(uint16_t angle) {
 return sin16(PISURDEUX16 - angle);
}

lidarsx[j] et y[i] // Cartésiennes dans le plan du ROBOT

 

lidarsCartex[j] et y[i] // Cartésiennes dans le plan de la CARTE après filtrage des points qui sont DANS le robot !!!

 

pointOdometrie.x et .y // Odométrie absolue et corrigée du robot (sortie de boucle de correcteur d'estimation).

void readLidar() {
 static bool init = false;
 uint8_t current;
 static uint8_t n = 0;
 static uint8_t checksum;
 static uint8_t sum = 0;
 static uint16_t startAngleQ6;
 bool start;
 static uint16_t diffAngleQ6;
 static uint16_t oldStartAngleQ6 = 0;
 int32_t diffAngleTotalQ6;
 int32_t angleBrutQ6;
 static int32_t oldAngleBrutQ6;
 int32_t angle;
 static uint8_t deltaAnglesQ3[NBMESURESCABINES];
 static uint16_t distances[NBMESURESCABINES];
 static uint8_t m = 0;
 static uint8_t s = 0;
 static uint16_t j = 0;

 if(!up) {
  init = false;
  return;
 }

 while(RXLIDAR.available()) {
  current = RXLIDAR.read();

  switch(n) {

   case 0:                                                                             // Début de réception de l'en-tête
    if(current >> 4 == 0xA) {
     checksum = current & 0xF;
     n = 1;
    }
    break;

   case 1:
    if(current >> 4 == 0x5) {
     checksum |= current << 4;
     n = 2;
    } else
     n = 0;
    break;

   case 2:
    sum ^= current;
    startAngleQ6 = current;
    n = 3;
    break;

   case 3:
    sum ^= current;
    startAngleQ6 |= (current & 0x7F) << 8;
    start = current >> 7;                                                              // Fin de réception de l'en-tête
    if(start)
     TXDEBUG.println("start");

    if(!init) {                                                                        // Ne pas calculer sans cabines
     init = true;
     n = 4;
     break;
    }

    diffAngleQ6 = startAngleQ6 - oldStartAngleQ6;                                      // Calculer l'angle entre deux mesures de référence
    if(oldStartAngleQ6 > startAngleQ6)
     diffAngleQ6 += UNTOURQ6;

    diffAngleTotalQ6 = 0;
    for(uint8_t i = 0; i < NBMESURESCABINES; i++) {

     angleBrutQ6 = (oldStartAngleQ6 + diffAngleTotalQ6 / NBMESURESCABINES) % UNTOURQ6; // Calculer l'angle non compensé
     diffAngleTotalQ6 += diffAngleQ6;

     if(oldAngleBrutQ6 > angleBrutQ6) {                                                // Détection du passage par zéro de l'angle non compensé
      lidarReady = true;
      lidarsx[j] = MESURENULLE;
      lidarsy[j] = MESURENULLE;
      lidarsCartex[j] = MESURENULLE;
      lidarsCartey[j] = MESURENULLE;
      j = 0;
     }
     oldAngleBrutQ6 = angleBrutQ6;

     if(distances[i]) {                                                                // Si la lecture est valide
      angle = angleBrutQ6 - (deltaAnglesQ3[i] << 3);                                   // Calculer l'angle compensé
      angle = angle * 65536 / UNTOURQ6;                                                // Remise à l'échelle de l'angle

      // Passage du plan du lidar au plan du robot
      lidarsx[j] = POSITIONLIDARX + distances[i] * sin16(angle) / UN16;                // Enregistrement cartésien
      lidarsy[j] = POSITIONLIDARY + distances[i] * cos16(angle) / UN16;

      if(lidarsx[j] > POSITIONSROBOTXMAX || lidarsx[j] < POSITIONSROBOTXMIN ||
         lidarsy[j] > POSITIONSROBOTYMAX || lidarsy[j] < POSITIONSROBOTYMIN) {         // Si la lecture est hors du robot

       // Passage du plan du robot au plan de la carte
       lidarsCartex[j] = pointOdometrie.x + (lidarsx[j] * cos16(theta16) - lidarsy[j] * sin16(theta16)) / UN16;
       lidarsCartey[j] = pointOdometrie.y + (lidarsx[j] * sin16(theta16) + lidarsy[j] * cos16(theta16)) / UN16;

       if(j < NBMESURESMAX - 1)                                                        // Si il reste de la place dans les tableaux
        j++;
       else
        lidarReady = false;
      }
     }

    }
    oldStartAngleQ6 = startAngleQ6;

    n = 4;
    break;

   default:                                                                            // Début de réception des cabines
    sum ^= current;
    switch(m) {
     case 0:
      deltaAnglesQ3[s] = (current & 0b11) << 4;
      distances[s] = current >> 2;
      m = 1;
      break;
     case 1:
      distances[s] |= current << 6;
      m = 2;
      break;
     case 2:
      deltaAnglesQ3[s + 1] = (current & 0b11) << 4;
      distances[s + 1] = current >> 2;
      m = 3;
      break;
     case 3:
      distances[s + 1] |= current << 6;
      m = 4;
      break;
     case 4:
      deltaAnglesQ3[s] |= current & 0b1111;
      deltaAnglesQ3[s + 1] |= current >> 4;
      m = 0;
      s += 2;
      if(s == NBMESURESCABINES) {
       if(sum != checksum) {
        TXDEBUG.println("checksum");
        init = false;                                                                  // Ne pas faire les calculs pour ces cabines
       }
       n = 0;
       s = 0;
       sum = 0;
      }
      break;
    }
    break;

  }
 }

}

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#207 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 09 août 2018 - 11:15

Merci !!

 

Oui, pour la synchronisation, comme tu lis octets par octets, le fait de commencer avec la comparaison des 2 valeurs sync1 et sync2 qui arrivent en début de trame, comme son nom l'indique, ça synchronise tout seul. :)

De mon coté, comme je vais alterner analyse des trames et calculs, la synchro va être simple : ce sera vidage du buffer et redémarrage du scan.

 

Pour la détection de l'angle 0, j'ai fait comme toi : comparer l'angle précédent et le nouveau. Mais j'ai rencontré un pb.

Ma première idée :

if(lastAngle > currentAngle) {
	//Serial.print("Revolution. Top index : ");
	//Serial.println(scanIndex);
	scanIndexTop = scanIndex;
	scanIndex = 0;
	//display.clearDisplay();
}
lastAngle = currentAngle;

Ici les angles sont compensés. Cette comparaison me donnait un nombre de mesures par tour de 10 à 150. J'ai compris que la compensation peut changer l'ordre des mesures. Et oui. 0,9° entre 2 mesures en moyenne et en théorie. Et une compensation qui peut aller jusqu'à qq degrés en plus ou en moins.

 

J'ai corrigé le test comme ceci pour avoir le nombre attendu de mesures par tour, soit 400 mesures. 

if(lastAngle - currentAngle > 300) {

Là, je suis sûr que la différence, n'est pas lié à une compensation.

 

Comme j'ai pas compris ce que tu faisais avec diffAngleTotalQ6, difficile de comparer les 2. Je comprends juste que si ça fonctionne, ton test de passage à 0 doit être avant la compensation. Mais ta façon de compenser ne semble pas correspondre à celle qui est dans la doc. En fait, j'ai pas du tout compris comment tu appliques la compensation.



#208 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 09 août 2018 - 01:01

La moindre ligne de mon code est commentée, tout est simple et c'est la parfaite synthèse de la doc ! L'implémentation du driver d'origine est absolument abominable ils ont fait du MAUVAIS boulot même si ça marche c'est pas très logique et porte a confusion. la détection du passage par zéro se fait sur l'angle non compensé à l'aide d'un simple copie de l'ancienne valeur : oldAngleBrutQ6 > angleBrutQ6.

Dit moi exactement ce que tu comprends pas dans mon code et je t'expliquerais. Je suis allé au bout de la logique même de cet algo j'ai rien de fait au pif dedans.

l'empilement des diffAngles dans un total comme ceci :
diffAngleTotalQ6 += diffAngleQ6;
permet d'éviter la division pourrie et toutes les manipulation ésotériques que t'as dans l'implémentation d'origine.

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#209 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 09 août 2018 - 01:18

Je sais que t'as rien au pif ^^ D'où mes questions ;) Et merci pour tes réponses !!

Je me dis simplement que si tu prends le theta 0 avant la compensation, tu auras peut-être une valeur inférieure à 0 aprés la compensation. Mais ce n'est pas important.

Et oui je comprends mieux ton cumul. Ça remplace la division ça me plait ^^

Merci du partage !!

#210 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 09 août 2018 - 01:25

Exactement et si t'as une valeur qui repasse sous zéro après compensation tu t'en tape vu qu'un top départ valide à déjà été donné avant la compensation et que cette compensation négative est la pour rattraper un trop d'avance sur la réalité de la mesure ! 😂

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#211 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 10 août 2018 - 06:30

J'ai posé une machine à états comme j'aime.

Juste pour avoir le nuage de points sur le petit écran OLED. Tous ça pour ça :) Le kiffe !!

 

IMG_4389.jpg

 

 

https://github.com/P...ster/Hector-Due



#212 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 13 août 2018 - 01:21

Comme le driver du lidar semble tenir sur l'arduino Due, je continue.

Il y a de la marge en CPU, assez j'en suis sûr pour les 4 interruptions des roues codeuses. Et je ne ferai rien d'autre pendant l'analyse des trames du lidar. Le programme alterne acquisition des données du lidar, calcules du SLAM, pilotage des roues et ainsi de suite.

 

En tout cas, cet arduino Due va simplifier mon Hector drastiquement. Voilà donc ma nouvelle cible :

 

Hector.001.png.001.png

 

J'ai commencé à dessiner un boitier un peu plus propre que mes précédentes plaques de plexy.

 

Sans titre.png

 

Sans titre.png



#213 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 13 août 2018 - 06:15

Calculs du SLAM ? Permet moi d'en douter. Sauf si tu prends ce qu'on a fait avec Mike mais c'est pas tt a fait du SLAM

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#214 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 13 août 2018 - 06:37

C'est pour voir si tu suivais .... (sifflote) ... En effet , je ne crois pas que la carte entière de mon appart tienne dans l'arduino. J'ai récupéré toute latitude pour transférer les données à un tiers avec le fonctionnement en alternance. Dans un premier temps, je veux travailler sur un SLAM plus local. J'ai de la marge. J'en suis qu'à 8% de la mémoire avec un tour de scan. Après, par SLAM, j'entend un truc qui sera forcement un truc à « ma sauce ». C'est mon exploration qui continue.



#215 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 13 août 2018 - 07:33

En tout cas je suis curieux de voir comment tu vas résoudre le problème de la localisation sans être influencé par notre travail Mike et moi ! Un des graal en robotique ! avec ce qu'on a fait ton robot serait parfaitement geolocalisé dans une maison même géante et avec une seule puce 32 bits, donc l'arduino, sachant que t'as un FPU dessus (CORTEX M3 OU M4 ?) et pas nous sur le PIC32.

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#216 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 13 août 2018 - 11:33

Une technique simple serait de représenter la map sur un quadrillage pour réduire la quantité dinfo à mémoriser et simplifier les calculs. J'ai bon ?
C'est ce que font les jeux video.

#217 Serveurperso

Serveurperso

    Membre passionné

  • Membres
  • PipPipPip
  • 417 messages
  • Gender:Male
  • Location:Paris
  • Interests:Systèmes/Réseaux/Dev/Hardware/RF/Optique/Lasers...

Posté 13 août 2018 - 12:09

Oui et ça s'appelle une grille d'occupation est c'est une technique bien connue. ce qui s'affiche sur ma page en est une, construite par le navigateur. mais uniquement pour le visuel, dans le robot on en a pas (encore) fait avec jojo, on bosse en vectoriel sans mémorisation de quoi que ce soit ! mais on va l'ajouter pour augmenter l'intelligence de nos robots par la suite.

Make your own raspberry robot, control it over the internet in FPV mode with super low latency and securely share access on it to your friends with Vigibot.com! You are welcome to test our robots now!
https://www.vigibot.com(100% free, no ads)


#218 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 13 août 2018 - 03:52

Comme l'a dit pascal, aujourd'hui on a de la localisation dans une carte connue, avec point de départ connu. 

Il reste deux problèmes non implémentés pour le moment mais sur lequel je me remet à bosser ( déménagement presque fini )  qui sont : 
=> localisation dans une carte connu sans point de départ connu = implémentation d'un algorithme de monte carlo ou similaire ( à exécuter uniquement si on est perdu, contrairement à un algo de slam basé sur du monte carlo en continu) 

=> Mapping à partir d'un point connu. = Ajout des donnés à la carte. 

Mon but est de faire quelque chose de différent des techniques de SLAM actuelles, pour faire ce que je défini comme étant du DLAM : Differential Localisation And Mapping ou encore du ALAM Asynchronus Localisation And Mapping. 

 

Mais bon le plus important c'est d'avoir une localisation la plus fiable possible. Car à moins de changer le robot d'endroit tous les 4 matins la carte restera la même et il est facile de spécifier une bonne fois pour toute la carte au robot ...

 

L'usage d'une grille d'occupation est très utilisée par les technique de SLAM et c'est en général une bonne approche =) ( ce qui explique pourquoi c'est largement utilisé ;) ) mais j'essaye d'être plus "fin" dans mon approche, en mettant en place différents outils pour différents problèmes plutôt que de tout miser sur un outil qui marche très bien pour certaines choses et moins bien pour d'autres.

 

Typiquement, je pense essayer à l'occasion d'utiliser du gridmap pour de l'évitement local afin de remplacer l'évitement actuel ... Mais bon à voir ce que ça " coûte " par rapport à ce que ça "apporte " . Le but étant d'avoir un robot assez réactif et intelligent =) 

 

 

Au fait tu es sur que tu veux pas connecter ton robot à notre " cloud " ? :P 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#219 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 14 août 2018 - 12:26

Réponse au sujet de la connexion de Hector à un service externe : http://www.robot-maker.com/forum/topic/4937-projet-vigibot-le-robot-controle-facilement-par-internet-pour-tous-par-vigirobotics-tele-presence-surveillance-et-plus-encore/?p=98337



#220 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 26 août 2018 - 10:37

Voilà la petite mise à jour du sujet. Hector est plus mon sujet d'exploration de l'odométrie qu'un projet de robot bien définit. L'exploration évolue aussi sur le SLAM. La preuve en est la liste des posts montrant le fil des évolutions. Il y en a tellement que je fais ce petit résumé. On est après les vacances où j'ai pris un peu de recul loin de mon atelier.

 

La 1ère idée de novembre 2016 : 3 roues. 1 folle et 2 roues sur moteur CC avec encodeurs. La tourelle était composée de 2 VL53L0X et d'un servo. Raspberry + arduino. Le châssis en profilés d'alu.

 

Le servo ne me permettait pas de couvrir 180° pour avoir une 'vision' à 360 autour du robot. Je suis passé à 4 VL53L0X. J'ai tenté de scanner sur des secteurs de 90° avec un servo mais le montage n'était pas assez précis. Là je fais une pause de plusieurs mois avec Emile, un humanoïde.

 

Je suis passé à un moteur pas à pas pour avoir une tourelle précise pour faire mes aller-retours sur 90°. C'était la 1ère fois que j'utilisais un pas à pas. J'avais un capteur inductif pour la détection de fin de course. Là, je me rend compte que les VL53L0X voient flou.

 

Là, je saute le pas avec un lidar. Je refais une première version du driver en javascript sur raspberry. Tout fonctionne, je continue à en ajouter avec 4 roues mecanum parce que pourquoi pas. Là, le robot est devenu plus complexe. Pas ingérable mais trop complexe pour le temps que j'ai à y consacrer. Je kiffe, j'apprends beaucoup mais il faut que je simplifie.

 

Première simplification avec un arduino Due chargé de remplacer les 3 arduinos et le raspberry. On en est là dans ce fil.

 

L'arduino Due permet de gérer les trames du lidar mais est trop limité en mémoire pour gérer la cartographie. En tout cas pas assez finement à mon gout. 

 

L'idée de ces vacances est de revenir à la mécanique d'origine avec 3 roues mais montées sur 2 moteurs pas à pas. Et c'est encore plus simple. A priori, un raspberry seul permet de gérer le lidar et d'envoyer les impulsions aux drivers pas à pas. Je vais aussi refaire un châssis imprimé. C'est bien plus simple : pas de PID, plus de mémoire de travail et je retrouve un lien radio. Le petit bonus perso est que je vais tout programmer en JS.

 

Hector.001.png

 

L'ancienne version d'Hector est démontée. Le châssis mecanum sera utilisé pour un autre projet de télé-présence dont je n'ai pas encore parlé. Il mûrit dans ma tête depuis un moment et je trouve que les mecanum sont bien plus adaptées à ce projet qu'à un projet visant explorer l'odométrie.

 

Un petit retour sur les suspensions que j'ai utilisé pour absorber les distorsions du châssis souple à 4 roues. Ce sont les caoutchoucs qu'on trouve avec les servos. Après environ 6 mois, ils sont écrasés et ont perdu leur élasticité.

IMG_4698.jpg





Répondre à ce sujet



  



Aussi étiqueté avec au moins un de ces mots-clés : VL53L0X, Odomètrie, RPLIDAR A2, Arduino Due

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

0 members, 0 guests, 0 anonymous users