REBEQA : Différence entre versions

De Learning Lab Environnements Connectés
Sauter à la navigation Sauter à la recherche
(Conclusion sur la simulation)
Ligne 243 : Ligne 243 :
 
==Conclusion sur la simulation ==
 
==Conclusion sur la simulation ==
 
=== Plus valus de la simulation ===
 
=== Plus valus de la simulation ===
 
+
Avec Webots, on peut tester différents stratégies de commande du robots pour voir les avantages et inconvénients de certaines stratégies. On peut décrire un modèle de robot assez fidèle à la réalité et représenter aussi son environnement.
 +
La simulation nous a permis de développer une stratégie de commande pour les suiveurs de ligne et de l'adapter au mieux pour notre robot.
 
===Limites et inconvénient de Webots===
 
===Limites et inconvénient de Webots===
 +
Webots demande beaucoup de temps pour l'utiliser correctement et créer un modèle qui va représenter au mieux notre robot. On peut facilement perdre du temps sur une fonctionnalité que l'on ne maîtrise pas. Pour les délais que l'on a, il est souvent plus rentable d'investir du temps dans la conception du robot finale plutôt que d'essayer d'avoir une simulation. Tout dépend de la maîtrise du logiciel
  
 
=Tâches effectuées=
 
=Tâches effectuées=

Version du 25 mai 2025 à 20:15

Présentation du sujet

Mission générale

Le but de notre projet est de retrouver et récupérer un objet déposé dans un labyrinthe. Pour se faire, nous aurons besoin

  1. D'un labyrinthe : il sera construit par des lignes de scotch noires collées sur un fond blanc . Les robots devront suivre ces lignes.
  2. Robot bandit : Son rôle est de déposer un objet aléatoirement dans un labyrinthe (on choisit aléatoirement un temps qui fixera le moment auquel il doit déposer l'objet. Une fois l'objet déposé, le robot (retourne à sa position de départ en réalisant le chemin inverse).
  3. Robot Policier : Recherche l'objet métallique en parcourant le labyrinthe. Une fois l'objet trouvé, il revient à sa position de départ, communique le chemin à suivre pour récupérer l'objet au troisième robot.
  4. Robot Démineur : Récupère l'objet en suivant le chemin indiqué par le robot policier et revient à la base.

Détail du labyrinthe et des robots

- Labyrinthe : Il sera conçu à l'aide de scotchs noirs qui définiront le chemin. Il ne comporte pas de murs ni d'obstacles. Un code couleur permet de détecter une fin de route (scotch rouge) et le robot devra revenir sur ses pas ou un type d'intersection (3 branches : vert / 4 branches : jaune). Par défaut, le robot tournera tout le temps à droite (environ 90 degré). Le point de départ n'est pas considéré comme une fin de route (détection de blanc).

Dimension du labyrinthe à ajouter et de la largeur du chemin

- Les robots possèdent deux capteurs de suivi de lignes, 3 roues suédoises motorisées et un capteur de couleur. Ils intègrent tous une carte de commande R-Pi Picow.
- Le robot policier et le robot démineur possèdent en plus deux capteurs à ultrasons et un module de communication Bluetooth
- Le robot bandit et le robot démineur possèdent une pince motorisée, celle du robot démineur contiendra un "détecteur de métal" qui permettra de différencier un objet en métal d'un objet classique (en bois).

Matériel utilisé

- 3 cartes R-Pi Picow
- 2 capteurs ultrasons : HC-SR04
- 6 suiveurs de lignes
- 3 capteurs couleurs RGB
- 3 batteries
- 2 pinces dont une avec un détecteur d'objets métallique
- 2 Module Bluetooth
- 9 roues
- 1 objet métallique et 2 objets en bois de couleur

Pince

Les robots 1 et 3 seront munis de pinces. Ces dernières ont été modélisées à l'aide du logiciel SolidWorks et imprimées avec une imprimante 3D. Il y a une base qui fait la jonction entre les deux pinces, le servomoteur et le robot. Nous nous sommes inspirés des travaux des années précédentes en faisant bouger seulement une pince grâce au servomoteur qui va entrainer avec un système d'engrenage la seconde pince.

Servo Moteur

Afin de contrôler les pinces, nous allons utiliser 2 servo moteurs que nous avons récupéré d'anciens robots.

Datasheet : https://www.kjell.com/globalassets/mediaassets/701916_87897_datasheet_en.pdf?ref=4287817A7A

Nous avons donc testé leur bon fonctionnement avec une carte Arduino et le code suivant:

Code : Fichier:Moteur pince.zip

Identification de l'objet

On retrouve dans le labyrinthe un leurre et un objet déposé par le robot 1. Pour différencier le bon objet du leurre, nous avions d'abord pensé à utiliser un capteur de conductivité: le bon objet aurait été métallique et permettrait de laisser passer le courant, le différenciant du leurre non conducteur. Cependant, étant impossible à mettre en pratique avec le matériel à notre disposition et ayant un nombre de pin limité sur la carte de commande utilisée, nous avons opté pour une autre méthode d'identification d'objet basée sur la couleur. A l'aide d'un capteur de couleur TCS3200, nous allons pouvoir différencier l'objet d'une couleur spécifique du leurre de couleur blanche.

Code Arduino pour la détection d'un objet de couleur spécifique:

Capteurs

Capteur couleur TCS3200

- lien documentation : https://dronebotworkshop.com/arduino-color-sense/#TCS230_Arduino_Hookup Modification effectuée sur le code : allumage de la LED avec la commande

<<digitalWrite(PinDeLaLED, HIGH);>> Attention a bien laisser le mode LOW pour S1.

- Utilisation d'une carte Arduino UNO pour les tests.
- Meilleure détection pour une distance plus proche de 1cm (valeur exacte 1.5cm). Il sera donc placé sous les robots (au centre).
- Intervalles de détection : int redMin = 27; (Red minimum value) // int redMax = 155; (Red maximum value) // int greenMin = 33; (Green minimum value) // int greenMax = 210; (Green maximum value) // int blueMin = 30; (Blue minimum value) // int blueMax = 250; (Blue maximum value).
- La sortie renvoyée est sous format RGB avec le code choisi
- Les entrées S0 et S1 permettent la gestion du scaling (20% permettent de fixer une durée de pulsation acceptable et de limiter le bruit).
- Les entrées S2 et S3 permettent de définir un filtre couleur qui permettra de récupérer l'intensité de chaque composante RGB.

Code C++ : Fichier:Capteur couleur C.zip

Capteur ultrasons HC-SR04

- On branche l'alimentation sur 5V, Gnd à la masse, le pin 12 sur la sortie et le pin 11 sur l'entrée
- On le positionnera à l'avant pour détecter l'objet à récupérer (il n'y a pas d'obstacles extérieurs comme des murs).

Code Arduino : Fichier:Capteur US.zip Code C++ : Fichier:Capteur US C.zip

Capteurs suivi de ligne

Afin que les robots se déplacent dans le labyrinthe, nous allons utiliser des capteurs de lignes. Nous allons donc réutiliser le capteur de suivi de lignes des années précédentes qui est le capteur SparkFun Line sensor Breakout QRE1113.

Datasheet : https://www.sparkfun.com/datasheets/Robotics/QR_QRE1113.GR.pdf https://download.kamami.pl/p587610-KY-033-Joy-IT.pdf

Nous avons utiliser une carte arduino afin de tester le bon fonctionnement des capteurs de suivi de lignes et nous en avons 2 par robots soit 6 en tout.

Code C++ : Fichier:Suivi lignes.zip

Détecteur d'objet métallique

- Permet de détecter si un courant passe dans l'objet situé à l'intérieur de la pince : si l'objet est métallique, il conduit l'électricité ce qui forme un circuit fermé et donc on obtient une tension proche de zéro. Sinon, il ne conduit pas pas l'électricité et on obtient un circuit ouvert et on obtiendra une valeur proche de la tension d'alimentation (environ 5V).

Capteur Optique

Nous avons décider de reprendre l'idée du capteur optique écoconçu du robot RAMBOT présent sur les pinces du robot. Ce capteur permet de détecter si il y a bien un objet entre les pinces. Pour cela, nous avons repris les schémas électriques et modifié les composants.

Nous avons ensuite testé ce capteur avec le code suivant:

Code : Fichier:Capteuropt.zip

Ensemble des capteurs

Nous avons fait un test avec tous les capteurs mis en même temps sur une carte.

Code : Fichier:Robot3.zip

Communication

-Communication Wifi

Gestion de la motorisation des roues

Les batteries ne générant pas de tension continue d'un moment à un autre et pour répondre au problème de glissement des roues, nous avons besoin d'asservir nos moteurs. Pour cela nous avons chercher à visualiser des signaux des moteurs.

Voici donc les signaux du moteur en tournant les roues dans un sens: Tek001.png

Et voici les signaux du moteurs en tournant dans l'autre sens

Tek002.png

Batteries

Fabrication

Nouvelle base

Nous avons fabriquer une nouvelle base holonome en bois en forme de triangle afin d'avoir trois robots similaire. Il en existait déjà deux de cette forme en plexiglas. Nous n'avons pas trouvé de moteur équivalent aux deux bases en plexiglas (9V), nous avons donc récupéré des moteurs d'un autre robot qui sont en 6V. Nous avons fabriqué des équerres en métal pour attacher les moteurs.

Carte Électronique

Nous avions deux cartes électroniques fonctionnelles sur trois donc nous avons décidé d'en fabriquer une nouvelle afin d'en avoir trois uniforme. De plus, dans le dernier wiki, il nous était conseillé de les refaire car elles commençaient à se faire vieille. Ainsi, nous avons fabriqué une nouvelle carte électronique permettant de contrôler une base holonome pour trois roues ainsi que les différents capteur et actionneurs nous permettant de réaliser nos actions.

La contrainte principale de cette carte a été d'utiliser la carte Raspberry Pico W.

La carte comporte:

- La carte RaspberryPI Pico W, elle devra piloter les pont en H ainsi que les capteurs et actionneurs.
- Un TRACO TEN 3-1211N pour convertir la tension d'alimentation de nos batteries (9-18V) en une tension d’alimentation pour la Pico W (5V).
- Des ponts en H L293D pour contrôler les moteurs, le design est plus compacte que les L298N, cela prendra moins de place sur la PCB.
- Le module complet permettant d'utiliser le capteur optique (AOP TLC271ACP) qui a été développé lors de l'année précédente.
- Les sorties pour chacun des capteurs et actionneurs du projet.
- Un cavalier pour choisir la tension d'alimentation des moteurs (Batterie ou 5V).

Pour chacun des capteurs et actionneurs, on trouve les noms pour les brancher sur la PCB.

De plus, comme nous manquions de pin disponible, le deuxième capteur couleur doit être paramétré manuellement et ne détecte qu'une couleur prédéfini. Il faut sélectionner S0, S1, S2 et S3 (Label : Couleur2_Sel1 sur la PCB) avec les headers de 3.3V et GND qui se trouvent au dessus (Label : 3.3Sel1 et GNDSel1). Par exemple, pour définir S0 à 1, il faut brancher le premier pin de "Couleur2_Sel1" à 3.3V.

Pour réaliser la PCB nous avons réaliser le shématique et le routage sur le logiciel KiCad, voici les fichiers : Fichier:Projet robotique PCB.zip

Pcb.png

Shematic.png

Photo de la carte réalisé et de son prototype de test :

Prototype pcb.jpg

Simulation

Tutoriels

Liens utiles

Installation de Webots

Environnement VM (Ubuntu, il suffit alors d'installer Webots à partir à partir de l'app center) ou WSL (Linux pour windows avec Ubuntu)

Pour WSL

modification à faire dans Windows :

INSTALLER RAPIDEMENT UBUNTU SUR WINDOWS 10 - WSL [TUTO]

commande à taper :

Installer WSL 2 | Microsoft Learn

Installer Webots :

Webots documentation: Installation Procedure

Webots

Une simulation Webots contient au moins ces deux composants :

  • Un fichier world file (.wbt) qui définit un ou plusieurs robots et leurs environnements. Le langage utilisé est VRML97.
  • Un ou plusieurs fichiers de contrôle (controller programs) pour ces robots. Ces fichiers sont en C/C++/Java/Python/MATLAB. Nous utiliserons C++.

Eventuellement il peut y avoir des PROTO : un fichier qui permet de définir un nouveau type de robot, capteur, objet ou structure, en combinant des nœuds existants (comme Solid, Transform, Shape, etc.). C’est un modèle réutilisable avec une interface personnalisable (paramètres comme la taille, la couleur, la masse...)

Pour exécuter le controller (procédure à refaire à chaque changement de code) :

  • Dans le dossier du controller on tape les lignes de commandes
    • Export WEBOTS_HOME=CHEMIN_INSTALLATION_WEBOTS (souvent : /usr/local/webots)
    • make
  • Dans webots recharger le monde (CTRL+SHIFT+R)
  • Lancer la simulation

Modification d'un proto : Pour apporter une modification à un PROTO on préférera modifier le Node Tree plutôt que le code, modifier le Node Tree ne modifie pas le fichier code (et inversement). Si on modifie le fichier code, il faut sauvegarder le fichier puis recharger le monde pour appliquer le changement.

Créer un prototype dans Webots (en VRML97) est long et fastidieux. On préférera donc créer un modèle sous SolidWorks via 2 méthodes :

  • Exporter en fichier .wrl et recupérer les coordonnées des points du solide
  • Exporter un fichier .stl ou un .obj et récupérer directement la forme de notre modèle 3D


Créer un solide avec des formes originales

On a utilisé SolidWorks (partie à détailler avec image) pour modéliser notre solide puis on l'a exporté en .wrl (à préciser avec images) et on a extrait les coordonnées de notre solide. Sur Webots, on obtient le code suivant :

Solid {
  rotation 1 0 0 0
  children [
    Shape {
      appearance PBRAppearance {
        baseColor 0 0.8 0
        baseColorMap ImageTexture {
        }
        roughness 0.5
        metalness 0
      }
      geometry IndexedFaceSet {
        coord Coordinate {
          point [
             -0.089884 -0.040276 -0.000000, -0.089884 -0.040276 0.020000, -0.074666 -0.066129 0.000000, -0.074666 -0.066129 0.020000, -0.001198 0.116360 0.000000, -0.001198 0.116360 0.020000, 0.028801 0.116612 -0.000000, 0.028801 0.116612 0.020000, 0.105327 -0.064616 -0.000000, 0.105327 -0.064616 0.020000, 0.120108 -0.038510 -0.000000, 0.120108 -0.038510 0.020000
          ]
        }
        coordIndex [
           7, 11, 6, -1, 6, 11, 10, -1, 5, 7, 4, -1,
           4, 7, 6, -1, 1, 5, 0, -1, 0, 5, 4, -1,
           3, 1, 2, -1, 2, 1, 0, -1, 9, 3, 8, -1,
           8, 3, 2, -1, 11, 9, 10, -1, 10, 9, 8, -1,
           11, 7, 9, -1, 9, 7, 5, -1, 9, 5, 3, -1,
           3, 5, 1, -1, 2, 0, 8, -1, 8, 0, 4, -1,
           8, 4, 10, -1, 10, 4, 6, -1
        ]
     
  }
 }
]
}

Pour exporter en .stl nous l'avons fait pour modéliser un labyrinthe en 2D. Nous l'importons ensuite sur Webots en utilisant le type transform pour pouvoir utiliser une échelle "scale" car il peut y avoir des problèmes de conversion en les unités de SolidWordks et les unités de Webots. Il n'y a plus de scale sur les types "Solid" depuis une mise à jour. Sur le transform on ajoute une Shape puis une apparence et une géométrie. nous n'avons pas réussi à avoir les couleurs que nous avions mis sur SolidWorks.

Webots menu.png

Le modèle que nous avons modélisé sur SolidWork apparait sans les courleurs que nous avons mis sur SolidWorks

Labyrinth 2D dans Webots
Labyrinth dans SolidWorks, après des modifications de l'apparence et de la forme

Code pour contrôler notre robot Fichier:Omnic cmd.zip Vidéo simulation du suivie de ligne par le robot:

démonstration du suivi de ligne

Conclusion sur la simulation

Plus valus de la simulation

Avec Webots, on peut tester différents stratégies de commande du robots pour voir les avantages et inconvénients de certaines stratégies. On peut décrire un modèle de robot assez fidèle à la réalité et représenter aussi son environnement. La simulation nous a permis de développer une stratégie de commande pour les suiveurs de ligne et de l'adapter au mieux pour notre robot.

Limites et inconvénient de Webots

Webots demande beaucoup de temps pour l'utiliser correctement et créer un modèle qui va représenter au mieux notre robot. On peut facilement perdre du temps sur une fonctionnalité que l'on ne maîtrise pas. Pour les délais que l'on a, il est souvent plus rentable d'investir du temps dans la conception du robot finale plutôt que d'essayer d'avoir une simulation. Tout dépend de la maîtrise du logiciel

Tâches effectuées

  1. Réalisation d'un robot complet
    • Fabrication des cartes de commande
    • Fabrication de la base
  2. Contrôle du fonctionnement des pièces existantes
    • Capteurs
    • 2 robots déjà existants
  3. Simulation sur Webots
  4. Réalisation de la pince avec imprimante avec détecteur de métal

Pi-Pico

Fichier:Tuto Installation VSCODIUM.odt

Communication

Nous avons choisis de faire une communication via Wifi pour transmettre le chemin jusqu'à l'objet d'un robot à un autre, ce qui possible grâce a l'utilisation de Raspberry Pi Pico WH pour l'échange d'information via TCP/IP. Pour cela, un des Raspberry, le "Serveur" sert d'Access Point (AP) avec un serveur TCP. Puis l'autre Raspberry, le "Client" se connecte au Wifi et en lui forçant une IP. On peut par la suite se connecter au serveur TCP et commencer à transférer des informations sous forme d'un string binaire de 0 et de 1. Par la suite, cela est traduit par le Raspberry "Serveur" pour soit tourner à droite, soit à gauche.

Mécanique

Objet

Nous avons choisit un objet de 5cm de diamètre afin de pouvoir le détecter plus facilement avec le capteur de couleur. L'objet fait 14cm de haut, et a des côtés plus larges que son centre afin de l'attraper plus facilement. Il y a des transitions entre les différentes sections avec des pentes de 30° par rapport à l'horizontale afin de ne pas avoir besoin de support lors de l'impression de l'objet en 3D.

Pince

Les branches de la pince ont une courbure adaptée au diamètre de l'objet, avec l'introduction d'un jeu. La pince a un slot pour attacher le capteur de couleur.

Il n'y a pas d'emplacement pour le détecteur de présence pour la LED infrarouge de réception et son récepteur associé. Nous avons fait ce choix car il serait trop long de modéliser un emplacement pour la LED sans fragiliser la pince, donc elle sera collée sur la tranche de la branche de la pince.

Fichier:Test

Roue

Pour la roue, on prend le modèle .stl suivant, ouvrable avec Solidworks : https://www.thingiverse.com/thing:5031000 . On modifie le fichier de sorte d'avoir un diamètre d'axe de roue et une taille de roue similaire à ceux utilisés les années précédentes : - Hauteur de roue : 40 mm - Axe de roue : 4 mm

On fait une mise à l'échelle qui ramène la hauteur de roue à 40 mm. Puis on essaye d'adapter ensuite l'axe de roue à 4 mm.

Algorithmes

Suivi de lignes

La piste est bordée de deux lignes noires. La logique de l'algorithme est comme suit :

  • le capteur de ligne gauche rencontre une ligne noire -> le robot corrige est va à gauche. Matériellement c'est la roue avant qui tourne. idem pour la droite.


Problèmes rencontrés:

  • Les capteurs de lignes doivent être très proches du sol pour pouvoir capter la ligne, il faut donc faire des réglages précis à adapter pour chaque robot.
  • La PWM permet de régler la vitesse des moteurs, la clock de la PWM a été choisie à 5kHz part la fonction pwm_set_clkdiv_int_frac(slice_num_M1,98,0); le calcul peut être repris à avec ce site web
  • Le robot va trop vite pour que la correction soit efficace, il y a franchissement de ligne. De plus il faut prendre en compte que la correction n'a lieu uniquement quand le capteur détecte la ligne. Nous avons donc essayé :
    • De rajouter un délais pour que la correction ait lieu pendant plus longtemps, mais nous avions tout de même des problèmes de franchissement de ligne, toujours dût à la vitesse du robot.
    • De diminuer la vitesse des roues arrières pendant la correction en les passant de 255 à 180. Cette méthode est concluante et permet une correction de trajectoire même avec un angle d'attaque important. Cet angle va dépendre de la manière dont tourne le robot. Il faut s'assurer qu'il tourne suffisamment pour que la correction soit possible.


Le code comprend : Un fichier contenant le main : suivie_moteur.c, qui se sert des fonctions définies dans le fichier fonctions pour initialiser les différents ports GPIO de la carte pico et lancer la boucle infinie avec la fonction de suivie de ligne principale. Les fichiers fonctions.h et fonctions.c contiennent les éléments suivants :

  • Les différentes bibliothèques nécessaires au fonctionnement du code
  • Les définitions des différents ports GPIO, un par capteur de ligne et trois par moteur (2 pour le sens : IN1 et IN2 et 1 pour la PWM : ENA)
  • La fonction setup_capt qui initialise les différents ports GPIO, les moteurs dont PWM
  • La fonction pico_set_led qui prend en argument un booléen led_on et qui permet d'allumer la led de la board pi pico à des fins de débogage.
  • La fonction setPWM qui prend en argument le pin enable d'un moteur et qui fixe la valeur de la PWM par l'argument value qui prend une valeur entre 0 et 255.
  • La fonction commande_moteur() qui ne prend aucun argument et qui est l'algorithme principal de suivie de chemin.

Fichier:Suivi ligne.zip

Parcours du labyrinthe

Direction en fonction des couleurs

Les intersections du labyrinthe seront délimitées par des couleurs selon les directions possibles que le robot pourra emprunter :

  • Violet: présence d'une intersection
  • Rouge : virage à droite
  • Bleu : virage à gauche
  • Vert : virage à droite ou à gauche
  • Jaune : impasse

Ces couleurs sont placées sur le labyrinthe comme sur l'image suivante :

Labyrinthe final avec les couleurs pour les intersections

Parcours d'un arbre

Afin d'explorer l’ensemble des chemins du labyrinthe, on applique un algorithme basé sur une structure en arbre, où chaque nœud représente une intersection ou une impasse.

L’algorithme parcourt chaque nœud à partir d’un point de départ, en explorant toutes les branches possibles. À chaque intersection, il choisit un chemin, le suit jusqu’à une impasse, puis revient en arrière pour explorer les autres options. Cela permet de visiter tous les chemins du labyrinthe.

code: