RAMBOT

Présentation

Mission des robots

Le but est d'atteindre une base ennemie tout en récupérant les blessés sur le chemin. Pour cela nous avons trois robots:

1. L'éclaireur :
   • suit une ligne (suiveur) pour finir sur un drapeau qui signalera la fin du siège ;
   • envoie les positions des obstacles qu'il rencontre (blessé à sauver ou ennemi à capturer).
2. Le sauveteur :
   • reçoit l'ordre d'intervenir, envoyé par l'éclaireur ;
   • récupère les blessés et les ramène à sa base (hôpital).
3. Le blindé :
   • reçoit lui aussi l'ordre de l'éclaireur ;
   • récupère les ennemis et les ramène à sa base (prison).

Décomposition des actions élémentaires des robots

Dans l'idéal voici toutes les étapes à réaliser avec les robots:

1. Les trois robots sont au camp de base
2. Tant que pas d'obstacles : robot 1 fait sa "ronde" en suiveur de ligne
3. Détecte un obstacle
4. Identification blessé / ennemi
5. Communication avec tous les robots
6. Le robot 1 se déplace vers l'extérieur (pour laisser la place aux autres robots de passer)
7. Le robot 2 ou 3 (suivant celui qui est nécessaire) s'active et va à la position du robot 1 (suivant la ligne)
8. Il attrape l'individu
9. Retour à la base et dépose de l'individu
10. Envoie d'un signal au robot 1 pour qu'il se réactive
11. Envoie l'information à l'utilisateur
12. On reboucle sur l'étape 2
13. On atteint le drapeau et c'est gagné

Tout au long de la mission, l'utilisateur peut suivre le nombre de blessée rapatriés et d'ennemis capturés avec un interface.

Décomposition du travail

Tâches à réaliser par ordre de priorité :

1. Contrôle des moteurs de la plateforme principale et des plateformes secondaires
2. Odométrie et repérage dans l'espace
3. Détection de ligne
4. Asservissement
5. Détection des cibles
6. Identification
7. Communication sans fil entre les robots et avec l'utilisateur
8. Attrapage de la cible
9. Interface utilisateur

Contrôle des moteurs

Programmation des cartes

• ESP32 :

- Ajouter le support de la carte dans l'IDE Arduino en insérant ce lien dans Fichier → Préférences → URL de gestionnaire de carte supplémentaire : https://dl.espressif.com/dl/package_esp32_index.json

- Dans Outils → Type de carte → Gestionnaire de cartes, rechercher et installer ESP32

- Dans Outils → Type de carte sélectionner la carte ESP32

• Teensy :

- Installer le support de la carte dans l'IDE Arduino via ce lien

Robot 1

La plateforme du robot 1 est constituée de 4 roues suédoises. D'après le wiki de l'année dernière un des moteurs (le moteur 3) ne tournait que dans un sens. La cause était un des pont en H qui avait cessé de fonctionner correctement. On a alors décidé de dessouder et ressouder un nouveau pont en H. Mais en dessoudant nous avons abîmé la carte alors nous avons dû nous accommoder et rajouter des fils. Ensuite nous avons testé les moteurs qui ont tous fonctionné dans un sens mais dans l'autre sens nous avons envoyé trop de courant d'un coup. Le driver a alors de nouveau grillé. Pour y remédier nous avons pris une deuxième carte électronique sur laquelle il y avait déjà un driver pour deux moteurs que nous avons alors connecté en soudant des fils entre elle et la carte principale accueillant la Teensy. C'est après beaucoup de difficultés que nous avons réussi à faire tourner les quatre roues.

Finalement, après ces modifications, de nombreuses erreurs étaient encore présentes. Les moteurs n'étaient pas reliés aux bonnes roues et certains tournaient dans le sens inverse. Nous avons également constaté qu'un faux contact intervenait sur le moteur 4 ; sa masse n'était pas non plus bien fixée.

Par conséquent nous avons décidé de former deux équipes de travail :

- La première étant chargée de vérifier l'état de marche des robots suiveurs utilisés par nos prédécesseurs afin de s'en servir comme remplacement du robot 1.

- La deuxième ayant pour objectif de recréer une carte fonctionnel (sur une plaque d'essais) afin de gérer les 4 moteurs du robot n°1 et de remplacer l'ancienne qui présentait de nombreux problèmes.

La première équipe ayant terminé plus rapidement, nous avons décidé de changer de robot et d'utiliser un robot suiveur. Néanmoins, un premier pont en H fonctionnel a été réalisé sur la plaquette d'essais. Celui-ci permet de faire tourner deux moteurs. Pour utiliser le robot n°1, il suffit d'effectuer les mêmes branchements avec le deuxième pont en H.

Nouveau robot principal

Le robot suiveur n'étant pas holonome, nous avons effectué des modifications sur le code afin de faire tourner les moteurs. Pour ce faire nous nous sommes appuyés sur l'équation (6) de Fichier:Techniques Ingenieur.pdf dans la partie 2.1 Modélisation cinématique

Le code utilisé est le suivant : Fichier:Essai moteur eclaireur v1.zip

Robot 2 et 3

Afin de contrôler les déplacements des robots 2 et 3 nous avons utilisés le code suivant : Fichier:Essai moteurs.zip.
Voici la procédure à suivre pour vérifier et tester le fonctionnement des moteurs :

1. Alimenter la carte Teensy ;
2. Téléverser ce code dans la carte Teensy ;
3. Alimenter les moteurs via une batterie externe.

Ce code contient :

- La déclaration des constantes et variables utiles ;

- La défintion des fonctions MotorCCx (x correspondant au numéro du moteur) permettant de définir la vitesse et le sens de rotation de chaque moteur ;

- La fonction controleMoteur qui calcule l'orientation des roues ;

- La boucle principale permettant de vérifier que le robot avance, recule et tourne sur lui-même.

La fonction controleMoteur s'appuie sur la matrice donnée par Technique de l'ingénieur, à la partie 3.1 de Robotique mobile : conception, modélisation et commande : Fichier:Techniques Ingenieur.pdf.

.

Odométrie

L'odométrie désigne l'estimation des déplacements du robot en se basant de la rotation de ses moteurs (roues codeuses).
Elle est très complexe à mettre en place. On a donc décidé de trouver des alternatives car dans notre application l'odométrie n'est pas obligatoire.

Communication entre Teensy et ESP32

Les robots sont équipés de 2 cartes chacun : la Teensy qui contrôle les moteurs, et l'ESP32, sur laquelle sont branchés tous les capteurs. Ainsi, pour que le robot soit capable d'adapter ses déplacements en fonction des informations extéroceptives, il faut mettre en place un protocole de communication entre les 2 cartes. Pour cela, on utilise une liaison série, entre l'UART2 de la ESP32 (ports 16 et 17) et l'UART1 de la teenzy (port 0 et 1).

On peut suivre le protocole suivant pour communiquer via le bus série :

Sur la carte ESP32, il faut écrire :

void setup() 
{
  // put your setup code here, to run once:
  Serial2.begin(115200); // Initialize serial communication at 115200 baud
}

Puis, dans la fonction concernée :

Serial2.write((int) thetaP); // Envoie du float à la carte teensy

De manière réciproque sur le code de la carte Teensy :

   // send data only when you receive data:
  if (Serial1.available() > 0) {
    // read the incoming byte:
    thetatest = Serial1.read();
  }

Dans les premières phases de test, nous avons mis en place ce protocole pour transmettre la vitesse angulaire aux robots en temps réel, afin de réaliser le suivi de ligne (cf. partie correspondante du wiki).

Par la suite, lorsque nous avons voulu implémenter davantage de fonctions de déplacement, comme arrêter le robot ou lui faire faire demi-tour, nous avons été confronté à plusieurs difficultés. Dans un premier temps, nous avons opté pour une solution qui semblait la plus simple : la carte ESP32 envoie en temps réel des valeurs de u, v et thetaP à la teensy, qui se contente de mettre à jour ces nouvelles valeurs dans sa mémoire et de faire tourner les moteurs en conséquence. Pour différencier les données envoyées au niveau du récepteur, la ESP32 envoie un identifiant avant d'envoyer la valeur de u, v ou thétaP. Nous avons testé cette solution dans le programme suivant :

Fichier:Test com ESP teensy.zip

Pour que cette solution fonctionne, il faut que la carte Teensy essaie de récupérer les données du buffer plus vite qu'elles n'arrivent.
Lorsqu'on teste ce programme avec des valeurs arbitraires de u, v et théta, la communication marche relativement bien, mais certaines erreurs apparaissent parfois (par ex : u prend la valeur de v ou thétaP, ou même d'un identifiant (ou pareil avec u et théta)).
Lorsqu'on a testé d'utiliser ce même code pour faire réaliser au robot des fonctions de déplacements élémentaires, nous avons rencontré plusieurs difficultés : les valeurs étaient rarement transmises ou présentaient des erreurs. Malgré un débuggage prolongé, nous ne sommes toujours pas certains d'où venaient ces erreurs. Nous avons cependant remarqué que le type des erreurs dépendent des délais présents dans le code de la ESP32.

Finalement, nous avons opté pour une autre solution qui devrait provoquer moins d'erreurs : on ne communique par la liaison série que les valeurs de thétaP, ainsi que des valeurs servant d'identifiant au comportement que prend le robot (101 : avance, 102 : stop, ...). La différentiation du type de valeur transmise se fait au niveau du récepteur (teensy) selon la portée de la valeur reçue : si la valeur reçue est comprises entre -100 et 100, il s'agit d'une valeur de théta, et si elle est supérieure à 101, il s'agit d'une commande de comportement. On évite ainsi de transmettre la mauvaise valeur à une variable. Chaque comportement élémentaire de déplacement (avancer, reculer, tourner sur soi, stop, …) devra donc être codée sur la teensy, et on y fera correspondre une valeur entre 101 et 127 à communiquer par l'UART.

Afin d'assurer que la valeur est bel et bien transmise, on pourrait utiliser les bus Tx de la teensy et Rx de la ESP32, pour monter une liaison série en parallèle de l'existante, dans l'autre sens. De cette manière, on pourrait vérifier au niveau de l'ESP que le signal a bien été reçu, et le renvoyer dans le cas contraire.

Détection de ligne

On utilise le capteur SparkFun Line sensor Breakout QRE1113. Il s'agit d'un capteur de réflexion. Lorsque la réflexion est minimale (couleur noire), il nous renvoie la valeur de la tension d'alimentation (autour de 3,3V ici). Pour pouvoir détecter correctement il faudra le mettre à 2mm du sol.

Datasheet : https://www.sparkfun.com/datasheets/Robotics/QR_QRE1113.GR.pdf

Code : Fichier:Test ligne.zip

Asservissement de ligne

Dans cette partie, nous expliquons la méthode utilisée pour que les différents robots puissent suivre la ligne noire.

Envoie de données

Une fois la connexion faite, nous avons du faire la conversion des valeurs. En effet, la fonction Serial.write() ne peut écrire qu'un octet. Nous avons donc converti les valeurs sur 12 bits récupérées par les 2 capteurs (grâce à capteurD = analogRead(CAN1); en données d'un octet.

thetaP = ((255.0 / 8190.0) * thetaP) + 127.5;

Codes utilisés

Fichier:AsservissementLigneESP.zip
Fichier:Essai moteur v3.zip

Détection des cibles

La détection de cible consiste à repérer les cibles qui se trouvent à une certaine distance bien définie du robot, puis d'exécuter les actions nécessaires correspondantes. Cela nécessite l'utilisation des capteurs afin de collecter les données de distance entre l'objet (cible) et le robot, puis lire les données recueillies afin d'appliquer les actions prédéfinies.

Plusieurs possibilités ont été envisagées :

1. Capteur ultrason : ce capteur était trop imprécis de près. Il permet de détecter des obstacles imposants, nous allons donc l'utiliser plus tard pour la détection d'amers.
2. Télémètre infrarouge : Distance minimale de détection trop élevée (environ 10 cm).
3. Capteur à effet Hall : Ne capte que des aimants et uniquement de près et dans la direction du champ magnétique, ce qui est inutile dans notre cadre d'utilisation.
4. Capteur de lumière infrarouge : Distance maximale de détection trop élevée (plusieurs mètres).
5. Capteur couleur : Ce capteur nous permet de capter des couleurs (blanc, bleu, rouge, vert) à une distance assez faible (environ 5cm au mieux).

On a donc choisi le capteur de couleur TCS3200 (voir datasheet ci-dessous), que l'on connectera à la plateforme principale à l'aide d'une équerre en métal.
Malgré sa faible distance de détection, il est assez fiable et nous permet de simplifier l'identification des cibles.

Datasheet : Fichier:TCS3200 (1).PDF

Identification des cibles

Une fois que le robot a détecté la présence de cibles à proximité, encore faut-il les identifier pour différencier les alliés des ennemis. Pour cela, on utilise le capteur de couleur TCS3200, aussi utilisé pour la partie détection.

Code Arduino_Uno : Fichier:Test color sensor 4.zip

Code ESP32 THING : Fichier:Test color sensor esp 1.zip

On utilise le capteur pour identifier les objets rouges et les objets bleus. La mesure fonctionne jusqu'à environ 5cm.

Conception des cibles

Les cibles ont été faites pour faciliter la préhension avec la pince.

Système de Préhension

Capture

Les robots 2 et 3 doivent ramener une cible à leur base

Plusieurs solution ont été envisagées :

1. Un électro-aimant : Efficace uniquement à très courte distance (autour de 1cm). Pour palier à cela on a envisagé de le mettre sous le robot mais cela cause des problèmes de demi-tour et d'empilement dans les zones de dépôts. De plus, il chauffe assez rapidement, alimenté sous 24V ;
2. Une spatule qui s'inclinerait, et qui passerait sous le personnage : problèmes de stabilité et de précision ;
3. Une pince : plus stable, nécessite un servo moteur, plus maniable.

On a opté pour la pince qui semple être la solution la plus pratique et efficace pour notre cas. On a envisagé plusieurs méthodes : conception en lego, pièce en imprimante 3D ou tout simplement un achat. C'est cette dernière solution qui a eu notre préférence. On a choisit une pince adapté à notre servo, la Kitronik Klaw MK2 Robotic Gripper, malheureusement, nous n'avons pas pu la commander.

Ainsi, nous avons décidé d'imprimer en 3D une pince, dont voici les plans.
Fichier:Plan pince 3D.zip

On va utiliser le servo moteur MicroServo99 qui a une amplitude de 180°.
Code : Fichier:Servo.zip

Afin de commander l'ouverture et la fermeture de la pince, on utilise les valeurs suivantes :

1. grise : ouverture 155 ; fermeture 179.
2. orange : ouverture 130; fermeture 179.

Ces pinces seront couplées à la plaque de plexiglas à l'aide de deux équerres et une tige filetée.

Détection de saisie

Il va nous falloir détecter la présence de cible dans la pince pour activer sa fermeture. Pour cela nous avons décidé d'utiliser un capteur optique qui arrêtera le robot lorsque la cible est détectée et fermera la pince.

Nous n'avons pas trouvé de capteurs correspondant à nos besoins, nous avons donc décidé d'en concevoir un par nous même. On utilise pour cela un émetteur fonctionnant avec une LED émettant dans l'infrarouge, à 950nm, et d'un récepteur fonctionnant avec un phototransistor, ayant un maximum de sensibilité vers 900nm (voir datasheets ci-dessous).

Datasheet LED : Fichier:Osram opto semiconductor sfh 409 lead pb free prod-2891523.pdf

Datasheet phototransistor : Fichier:OFT-3301.pdf

Datasheet AOP pour comparateur : Fichier:Tlc271a.pdf

Dans un premier temps on réalise le montage avec la LED infrarouge :

Ensuite on réalise le montage avec le phototransistor accompagné d'un comparateur qui va nous permettre d'avoir une sortie 5V si l'objet n'est pas détecté ou 0V s'il est détecté :

Après plusieurs tests, on remarque que lorsque un objet sépare la diode du phototransistor, on a approximativement 0V aux bornes de la résistance. Lorsqu'il n'y a pas d'objet, on remarque que la tension aux bornes de la résistance est de plus de 100mV. Ainsi on choisit un seuil de 50mV pour le comparateur. On utilise un pont diviseur de tension pour obtenir cette tension :

Il nous faut 2 capteurs de ce type pour les 2 pinces qui seront sur les robots 2 et 3. Ainsi, on réalise ces montages sur 2 mini breadboard que l'on placera sur les robots avec les LED et phototransistors qui seront placés sur les pinces à l'aide de câbles plus long pour les excentrer des mini breadboard :

L'objectif maintenant est de relier le capteur optique au servomoteur via une carte ESP32. On utilise une entrée analogique qui va lire la valeur en sortie du capteur (0V si présence d'objet et 5V si non présence). Lorsqu'on détecte le passage de 5V à 0V, on fait varier l'angle du servomoteur (ce qui fermera la pince).

Code servo/capteur : Fichier:ServoCapteur.zip

Communication entre les robots et avec l'interface graphique

Notre scénario inclut la nécessité de pouvoir échanger plusieurs informations entre les robots. Elles sont au nombre de deux : la couleur du G.I. Joe qui a été détecté par le robot 1 et l'arrivée de robot 2 ou robot 3 à sa base après avoir récupéré ledit G.I. Joe. On veut aussi pouvoir consulter en temps réel l'évolution du nombre de G.I. Joe récupérés par les robots. On utilisera une interface graphique sous la forme d'une page internet pour cela.

Notre cahier des charges inclut la nécessité de communication entre les trois machines ainsi que l'utilisateur. Deux choix s'offrent à nous, la communication Bluetooth ou bien la communication Wi-Fi. Après avoir vu les échecs essuyés par les groupes des années précédentes quand ils essayaient d'utiliser cette technologie, nous avons décidé d'utiliser la communication Wi-Fi.

La carte ESP32

La première marche à franchir est de réussir à connecter les robots à un point d'accès Wi-Fi. Pour cela, la carte ESP32 dispose d'un module qui le permet : HttpClient. Il faut bien penser à l'installer avant de commencer à utiliser les codes qui suivent.

Voici le premier code : Fichier:Fonction connexion wifi.zip

Ce dernier est assez simple. On va appeler la fonction WiFi.begin() afin de se connecter à un réseau WiFi qui se trouve dans les environs de la carte. Pour cela, on peut passer jusqu'à deux arguments à la fonction. Le premier est le nom du réseau (obligatoire) et le second le mot de passe pour s'y connecter (optionnel). On note qu'accéder à un réseau sans utiliser le mot de passe est plus rapide, et donc bienvenu pour effectuer des tests.

Ensuite, il faut réfléchir à une structure qui va permettre aux robots d'échanger des informations entre eux. Pour cela, on va utiliser une API, qui est une collection de méthodes que nous allons créer et qui permettra à nos différents programmes de communiquer ensemble. Cette dernière démarrera son propre serveur sur lesquels toutes les machines vont se connecter. Nous y reviendrons dans la partie suivante. Gardez pour le moment à l'esprit que les quatre codes suivants vont envoyer une requête à cette API afin d'obtenir une information qui lui aura préalablement été communiquée par l'un des robots.
Rappelons les deux fonctions principales de notre cahier des charges en ce qui concerne la communication inter robots : transmettre la couleur du G.I. Joe repéré et savoir quand le robot 2 ou le robot 3 est rentré à sa base après avoir récupéré le soldat. Pour chacune d'entre elles, il faut prévoir d'un côté l'envoi et de l'autre la réception, ce qui nous fait donc un total de quatre fonctions Arduino à créer.
Commençons par la communication de la couleur.

D'abord pour l'envoi : Fichier:Fonction envoi couleur robot 1.zip

On a ici un premier exemple d'information à passer dans la requête. On veut savoir quelle est la couleur du soldat repéré par le robot 1. On va donc créer un nouveau type de données, un String, qui va prendre la valeur "?couleurGIJoe=***" avec *** remplacé par bleu ou rouge selon le cas. La balise '?' permet de délimiter le début d'une chaîne de requête, ce qui permet de passer un ou plusieurs paramètres dans le message qui pourront être exploités tels quels dans l'API.

Voyons maintenant le code de réception : Fichier:Fonction recuperation couleur robot 2 3.zip

Ici ce n'est pas l'envoi mais la réception qui diffère. On utilise la fonction client.readStringUntil() avec l'argument '\0' afin de lire la réponse de l'API jusqu'au caractère de fin de chaîne. Ensuite, on va analyser le message caractère par caractère avec la méthode indexOf() comportant "bleu" ou "rouge" en argument afin de vérifier si la chaîne contient l'un des deux termes. C'est ainsi qu'on traite la réponse de l'API.

Passons maintenant à l'envoi de l'arrivée de robot 2 ou robot 3 à sa base : Fichier:Fonction envoi arrivee robot 2 3.zip

Ici, même constat que pour l'envoi de la couleur du G.I. Joe par robot 1. On va déclarer une chaîne contenant l'information que l'on veut envoyer à l'API, à savoir le numéro du robot qui envoie le message.

Enfin, la réception de cette information par le robot 1 : Fichier:Fonction recuperation arrivee robot 2 3.zip

A nouveau, même traitement que pour la réception de la couleur du soldat par robot 2 et robot 3. On va récupérer le message et le lire caractère par caractère pour essayer de trouver le message "OK" indiquant que le robot 1 peut repartir.

L'API

Parlons maintenant de l'élément central de la communication dont le nom est revenu de nombreuses fois au-dessus : l'API.

En voilà le code : Fichier:Fichier api.zip

Commençons par la structure générale du code. Comme dit précédemment, une API est une collection de méthodes. Cela se traduit par une multitude de structures du type app.get() ou app.post(). Elles définissent la structure des requêtes que l'on va pouvoir faire à l'API et prennent en argument une arborescence qui va correspondre au chemin dans l'API où sont stockés les fonctions qui doivent être appelées pour répondre à la requête.
Prenons un exemple avec la plus simple des méthodes:

    @app.post("/api/data/receptionGIJoeSauves") 

    def get_data_gijoe_sauves(): 

         return GIJoesauves 

La première ligne va définir plusieurs choses. D'abord, on définit ici une méthode "get", symbolisée par le libellé app.get(). Ce mot clé signifie que l'on va récupérer une donnée uniquement, sans la remplacer chez le client. D'autres existent comme "put" ou "delete" mais la seule autre que nous utilisons dans ce programme est "post", qui permet de mettre à jour une donnée chez le client.
Ensuite, on précise en argument l'endroit où est située la méthode et ses fonctions associées. Cela n'a pas vraiment de sens dans un programme car les différents éléments qui le composent sont séparés et isolés par la ponctuation du langage de programmation, mais l'intérêt d'un API est de pouvoir être lancée sur un navigateur afin de visualiser et effectuer des tests sur les différentes méthodes. On accède ainsi à chacune d'entre elles en tapant dans la barre de recherche <adresse ip du serveur>:<numéro du port du serveur><arborescence méthode>. Par exemple, avec un PC ayant l'adresse IP 192.168.43.253 et en ayant lancé le serveur sur le port 8000, on accèderait à la méthode précédente en entrant 192.168.43.253:8000/api/data/receptionGIJoeSauves dans la barre de recherche du navigateur. On peut ainsi voir directement la sortie de la méthode s'afficher. Attention, cela ne marche que si l'on pense à lancer le serveur avant.
A la ligne suivante, on voit le mot clé "def", qui signifie que nous définissons une fonction. Puis nous indiquons le code de cette fonction. Celle qui est faite ici renvoie simplement un entier pour qu'il soit affiché dans l'interface graphique.
Enfin, un dernier élément à noter est les deux dernières lignes du code :

    if __name__ == "__main__": 

         uvicorn.run(app, host="0.0.0.0", port=8000) 

C'est ainsi que l'on va lancer le serveur grâce à la bibliothèque uvicorn. C'est aussi ici que l'on va préciser deux paramètres importants. Le "host" d'abord va signifier quelles machines vont pouvoir se connecter au serveur. Indiquer par exemple "localhost" signifie que seul le PC qui fait tourner le serveur pourra accéder à l'API. En revanche, si comme ici on écrit "0.0.0.0", toutes les machines présentes dans le réseau WiFi du serveur pourront y accéder. Enfin, le champ "port" va contenir le numéro de port dont nous avions besoin précédemment dans les cartes ESP32 et plus tard pour l'interface graphique. Voilà, maintenant que tout est prêt, il suffit de lancer la commande suivante pour lancer le serveur et l'API :

    fastapi run api.py

L'interface utilisateur

Pour mettre en forme les deux informations sur le nombre de soldats sauvés et capturés et assurer un retour utilisateur clair, nous avons décidé de créer une page internet qui va mettre en forme les données susmentionnées.

Notre interface utilisateur est réalisée avec Javascript en utilisant:

 -en Côté serveur la plate-forme Node.js avec les frameworks Express et Socket.Io pour créer un serveur capable de gérer des communications en temps réel et des requêtes HTTP. Ce serveur est conçu pour interagir avec des robots identifiant des objets de différentes couleurs (G.I. Joe). 
    Voilà son code : Fichier:Server.zip
 -et côté client avec HTML et CSS qui va permettre de créer une page web HTML qui permet de visualiser et de gérer les données relatives aux opérations d'un système de robots identifiant des objets(G.I. Joe) de différentes couleurs. Elle utilise aussi le Socket.Io pour communiquer en temps réel avec le serveur et fetch pour des requêtes HTTP simples.
      Voilà le code : Fichier:Index.zip

Télémètre ultrason

On utilise un télémètre ultrason HC-SR04 sur tous les robots.
Sur le premier, le télémètre est pointé vers le haut, et permet une détection du deuxième amer (arche), qui marque la fin de la démonstration.
Sur les robots secondaires, le télémètre est placé à l'arrière, et détecte le premier amer, qui permet le choix de la branche lors de la bifurcation. Il leur permet aussi de détecter la base, afin de déclencher un demi-tour.
Ces télémètres sont fixés à la base en plexiglas à l'aide d'un équerre en métal.

Problèmes rencontrés

Lors de ce projet nous avons rencontré plusieurs obstacles. Tout d'abord pendant la première semaine nous avons fait un inventaire sur le matériel nécessaire et le matériel déjà présent. A la fin de la première semaine nous avions donc tout le matériel nécessaire à part une pince afin d'attraper nos objets ainsi que des capteurs de suivi de ligne et du scotch blanc afin de faire la ligne pour la maquette.
Nous avons donc envoyé un mail à Matthieu Dumay qui n'a malheureusement pas été pris en compte pendant les trois semaines que nous avons eu entre les deux semaines de robotique malgré un mail de rappel de la commande.
Lors de la deuxième semaine nous avons donc dû improviser. Nous avons utilisé des feuilles blanches découpées en lamelles pour le suivi de ligne. Nous avons également trouvé de nouveaux capteurs de suivi de ligne. Et enfin nous avons choisi d'imprimer des pinces au lieu de les commander.
De plus, l'atelier de TSE s'avère être chichement équipé : pas moyen de trouver une simple pince universelle !
Les deux semaines ont été parsemées de petits problèmes de communication entre les groupes, même si globalement, la communication et le partage des tâches ont été optimisés.

Démonstrations finales

A la fin du projet, nous ne sommes pas parvenus par manque de temps à faire marcher toutes les fonctionnalités ensemble, bien que presque toutes (sauf le retour du robot 1 sur la ligne) fonctionnaient séparément. Pour témoigner de l'avancement du projet, nous avons donc réalisé 4 démonstrations, illustrant toutes les fonctionnalités

Démo 1 : Robot sauveteur seul

Dans cette démonstration, lorsque le robot sauveteur est allumé, il va chercher un allié sur la piste et le ramène à sa base.

Code : Fichier:Demo 1.zip

Démo 2 : Robot CRS + WIFI

Dans cette démo, lorsque le robot CRS est allumé, il se connecte en WIFI à l'API. Lorsqu'il a réussi (ce qui peut prendre quelques minutes), sa pince s'ouvre. Il attend alors le signal de l'API lui signalant un ennemi (là aussi, cela peut prendre quelques minutes), puis va alors l'appréhender et le ramène à sa propre base, de la même manière que pour la démonstration précédente.

Code : Fichier:Demo 2.zip

Démo 3 : robot 1 détection ennemi/allié

Dans cette démo, le robot 1 parcours la ligne jusqu'à voir un ennemi ou un allié puis se décale de la ligne.

Code : cf le code de la démo 5

Démo 4 : robot 1 envoie de détection de couleur au serveur

Dans cette démo, le robot 1 roule et quand détecte du rouge ou du bleu envoie le signal associé au serveur par WIFI.

Code : cf le code de la démo 5

Démo 5 : robot 1 fin de parcours

Dans cette démo, le robot 1 roule sous l'amer signalant la fin du parcours, le détecte et s'arrête.

Code : Fichier:Codes robot1.rar

Attention les prochains !

Pour l'année prochaine, la carte électronique pour la Teensy, les ponts en H et les moteurs de la plateforme principale seraient à changer si possible, car la qualité des soudures actuelles laissent à désirer. Le mieux serait de la refaire entièrement et de la commander.