REBEQA

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: [à compléter]

Capteurs

Capteur couleur TCS3200

Les capteurs couleurs permettent de gérer les différentes intersections présentes dans le labyrinthe. Ils seront donc placés sous chaque robot (au centre) dans le but de s'arrêter au milieu de l'intersection. Un capteur de plus sera utilisé pour faire la distinction entre deux objets possibles. Celui-ci sera placé à l'avant du robot policier.

- 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).

- La sortie renvoyée par le capteur correspond à l'intensité lumineuse mesurée par le capteur. Celle-ci est obtenue en mesurant la longueur du pic à l'état haut.

- 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 (rouge, vert et bleu).

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

Capteur ultrasons HC-SR04

- Le capteur est alimenté en 5V. Le pin ECHO est celui qui émet l'onde, il est donc une sortie pour la carte. Au contraire, le pin TRIG transmet le signal reçu par le capteur, il correspond donc à une entrée pour la carte.

- 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. Les capteurs de suivi de lignes des années précédentes possèdent une sortie numérique. Cependant, lors de la fabrication de la carte, des ports analogiques ont été choisi. Nous allons donc utiliser de nouveaux capteurs de suivi de lignes qui sont les 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

Capteur Optique

Nous avons décidé 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

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:

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

Fabrication

Nouvelle base

Nous avons fabriqué 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

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

Simulation

Tutoriels

Liens utiles

• Documentation officielle Webots (en anglais)
• Le fichier Webots du robot omni_wheels se trouve
• Un tutoriel pour faire suivre une ligne au robot
• Le tutoriel vidéo en python
• en C++
• Des tutoriels allant de la prise en mains à l’utilisation de certains capteur dans Webots sont disponibles

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.

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

Pi-Pico

Fichier:Tuto Installation VSCODIUM.odt

Communication

Nous avons choisi 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.

Lien du Git que l'on a crée : https://github.com/skillernow/ComWifiInterPico

Mécanique

Il existe des licences étudiantes pour SolidWorks.

Voici une licence utilisable par tous les étudiants, à fin non-commerciale : 9020 0087 8312 9372 X626 MX2G source : https://www.visiativ-education-recherche.fr/licences/monde-de-leducation/licence-etudiante-gratuite-sdk/

Installer SolidWorks (si nécessaire) : Média:fichier:SolidWorksSetup.zip

Objet

Nous avons choisi 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 bords de diamètre plus larges 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.

Fichier objet : Fichier:Test.SLDPRT, Fichier:Test.STL

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 emplacement 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.

Branche gauche : Fichier:Test.SLDPRT, Fichier:Test.STL

Branche droite : Fichier:Test.SLDPRT, Fichier:Test.STL

Support central : Fichier:Test.SLDPRT, Fichier:Test.STL

Réhausseur : Fichier:Test.SLDPRT, Fichier:Test.STL

Moteur SG90 : Fichier:Test.SLDPRT, Fichier:Test.STL (pour modélisation et dimensionnement de la pince)

Axe SG90 : Fichier:Test.SLDPRT, Fichier:Test.STL

Après impression et tests de la pince, nous avons remarqué que le servomoteur SG90 est assez puissant pour attraper l'objet sans problème, mais que le contact plastique-plastique entre la pince et l'objet limite l'adhérence. Une solution possible serait de rajouter une rainure le long de le branche de la pince, afin d'y insérer un morceau de joint en caoutchouc. Ce n'est cependant pas forcément un problème car la pince a tout de même assez de force pour trainer l'objet sur le sol, tout en assurant un bon maintien en position.

Roues

L'année dernière, deux modèles de roues ont été utilisé. Des roues en plastique, avec des rouleaux adhérents; et des roues plus grandes, en aluminium. Ces roues ont leurs propres moyeux. En gardant uniquement le matériel fonctionnel, nous avions 5 petites roues et 4 grandes roues. Cela permet de faire facilement 2 robots holonomes à 3 roues.

Cependant, il reste 1 grande roue et 2 petites roues. Comme il n'a pas été possible de commander de nouvelles roues, suite à une annulation, il y a deux choix possibles qui se sont présentés : imprimer des roues holonomes en 3D ou avoir un robot avec des roues de différentes tailles.

Nous avons décider d'imprimer des roues en 3D, dans l'espoir d'avoir 9 roues de taille identique (et donc de ne pas utiliser les roues en métal, car elles nécessitent une adaptation de leur moyeu).

Roue imprimée en 3D

Pour la roue, nous avons regardé des nombreux modèles. Nous nous sommes basés le modèle .STL suivant : https://www.thingiverse.com/thing:5031000.

Il est difficile pour un logiciel de CAO d'ouvrir et de modifier les fichiers au format .STL, car il ne contient que des informations sur la géométrie finale de la pièce. Nous avons donc essayé de reconvertir la pièce en un format .SLDPRT, pour l'utiliser avec SolidWorks (via la reconnaissance de fonction). Cependant, nous avons laissé tourner un ordinateur pendant une après-midi, et n'avons pas obtenu de résultats.

Comme la taille de l'axe du moteur sur les fichiers que nous avons trouvés était toujours différente de celle nécessaire, nous avons fait des tests pour évaluer la possibilité d'imprimer un moyeu en plastique et de l'enfiler sur l'axe moteur.

Dans l'idée de potentiellement adapter les roues en métal à nos autres moteurs, nous avons essayé d'imprimer des moyeux pour ces dernières, ce qui permet de tester des techniques pour attacher les roues holonomes sur un axe moteur, tout en consommant moins de plastique (et de temps, car l'imprimante est assez lente).

Le plastique étant relativement mou et friable, un jeu quelconque faisait que la pièce tournait indépendamment de l'axe moteur. Nous avons essayé de retirer le jeu, mais la pièce se déformait et pouvait aussi tourner autour de l'axe moteur. Nous avons donc mis un remplissage de 100%, mais la pièce était alors très difficile à mettre en place. Le trou ayant gonflé lors de l'impression, il était maintenant trop petit. Nous avons donc forcé le moyeu sur l'axe, mais le plastique excédentaire s'est arraché, ce qui a ensuite donné les meilleurs résultats pour un moyeu en plastique. Mais, il était encore possible (quoique difficile) de faire tourner la roue et l'axe séparément.

Nous avons donc préféré adapter la roue imprimée en 3D à un moyeu existant, ce qui nécessitait de changer la taille de la roue (4cm -> 5cm). Nous avons donc ensuite cherché des vis à la bonne taille, mais n'avons trouvé aucun modèle de vis présent en assez grande quantité pour l'assemblage de la roue. Après avoir regardé les différents modèle de vis, nous avons choisi un modèle et avons adapté la roue à la vis. Pour gagner du temps, nous avons fait la commande et l'impression des roues en parallèle. Cependant, les vis de 25mm faisaient en réalité 24mm, ce qui fait que les écrous n'ont pas assez de surface de contact pour tenir correctement sur la vis.

Nos tests ont aussi montré que le frottement entre la partie centrale de la roue et le moyeu sont trop importants. Il n'est pas pertinent d'imprimer des rouleaux en plastique car leur adhérence à la table est moins grande que le frottement avec la roue. Autrement dit, une roue en une pièce, imprimée en plastique, aurait quasiment le même effet que la roue holonome en plastique.

Centre de la roue : Fichier:Test.SLDPRT, Fichier:Test.STL

Rouleau : Fichier:Test.SLDPRT, Fichier:Test.STL

Adaptation du moyeu d'autres roues

L'année dernière, plusieurs modèles de roues et moteurs ont été utilisé. Par un souci d'uniformisation des robots, nous avons décidé d'utiliser des moteurs identiques. Bien que des tests ultérieurs ont montré qu'ils n'avaient au final pas la même tension de fonctionnement, ils ont une taille et un axe identiques. De plus, ils étaient déjà monté sur le robot.

Après avoir obtenu des résultats décevants pour les roues holonomes imprimées en 3D, nous avons décidé d'utiliser les autres roues en métal. Nos tests précédents ont montré qu'il était difficile d'imprimer des moyeux en 3D. Nous avons donc décidé de réutiliser les moyeux trop grands, et de glisser des morceaux de collier de serrage à l'intérieur du moyeu afin que la vis de serrage puisse tout de même se caler contrer l'axe moteur. Cette solution bien que douteuse, nous a donné des meilleurs résultats que les moyeux imprimés en 3D.

Moyeu : Fichier:Test.SLDPRT, Fichier:Test.STL

Impression 3D

Pour l'impression 3D, généralement on peut utiliser un logiciel généraliste. Dans le cas présent, les imprimantes UltiMaker fonctionnent très mal avec un logiciel généraliste, et demandent l'utilisation du logiciel associé UltiMaker Cura. C'est un logiciel facile à utiliser et facile à installer.

Pour l'impression des pièces, nous avons enregistré nos fichiers SolidWorks (.SLDPRT) en fichier plus facilement ouvrable (.STL). A partir du logiciel Cura, nous avons slicé les pièces (génération du .GCode), permettant de donner les instructions des étapes à effectuer à l'imprimante.

Pour le paramétrage de l'imprimante, il existe des préréglages par défaut, mais il est important de vérifier les réglages comme le type de plastique (PLA dans notre cas), et le type de buse utilisée (diamètre, ici 0.2mm) directement sur la section "information système" de l'imprimante.

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.

Ces fichiers sont tous necessaires au bon fonctionnement du robot. Le fichier capteur_acq initialise les différents capteurs et défini l'algorithme de détection de couleur, cette algorithme (la fonction measure_couleur) utilise la fonction ajouter du fichier Parcours. C'est dans cette fonction ajouter que sont gérer les commandes de rotation de robot, selon le prochain nœud.

Le mouvement est comme suit :

• La variable booléenne go est utilisée dans le main. Le robot suit le chemin (algorithme de suivi de ligne, fonction commande_moteur du fichier fonctions) si go est vraie. Si go est fausse alors le robot s'arrête (fonction stop_moteur du fichier fonctions).
• Si le robot detecte la couleur violet (P), dans la fonction ajouter du fichier Parcours, la condition couleur == 'P' est vraie, go passe à faux et le robot s'arrête. On est alors au milieu de l'intersection.
• L'algorithme de parcours du graphe donne le nœud suivant à explorer. Exemple : la couleur est verte (V) et le nœud suivant est à droite, le robot tourne à droite, la variable go repasse à true et le robot suit de nouveau la ligne jusqu'à la detection de la prochaine intersection.

Remarque : les fonctions pour tourner sont basés sur un delay (les roues tournent pendant un certain temps). Cette méthode n'est pas fiable selon le robot, la vitesse des roues, la batterie. Asservir les moteurs serait plus efficace mais nous avons manqué de temps.