Robots suiveurs 2

De Learning Lab Environnements Connectés
Aller à : navigation, rechercher

Projet du module Robots connectés 2017/2018.

Le projet consiste en la commande de trois robots holonomes (deux esclaves et un maître) : le nombre de degrés de libertés contrôlables est égal au nombre total de degrés de liberté. Nos robots en ont trois chacun : deux translations et une rotation.

figure 1 : Robots (maître à gauche et esclave à droite)



Ils sont donc équipés de roues suédoises (cf. figure 2) qui permettent d'aller dans toutes les directions de l'espace.

figure 2 : Roue holonome


Nous devons pouvoir commander, via smartphone ou tablette, le maître (lui envoyer des ordres de direction), qui va à son tour transmettre les ordres aux deux esclaves afin qu'ils le suivent.

figure 3 : Schéma synoptique

Cahier des charges

Dans un premier temps, nous devons développer une application Android afin de contrôler le robot maître.
Ensuite, cette application doit communiquer avec l'ESP32 en Bluetooth. Ce module doit par la suite communiquer en Wi-Fi avec les ESP32 des deux robots esclaves.
Le module Teensy de chaque robot devra gérer les différents mouvements et chorégraphies désirées :

  • Avancer,
  • Reculer,
  • Aller à droite,
  • Aller à gauche,
  • Aller en diagonale : avant-droite, avant-gauche, arrière-droite, arrière-gauche,
  • Aller en crabe,
  • Tourner sur lui même,
  • Zigzaguer.

Application et Communication WiFi et Bluetooth

Les robots vont devoir se coordonner en fonction des actions commandées à partir d'une application Android.
Pour ce faire, nous avons décidé d'appareiller le téléphone sur lequel l'application tournera avec le robot maître via Bluetooth. Le maître enverra alors les commandes adéquates aux robots esclaves via une communication WiFi.
La nouvelle carte Sparkfun ESP32 Thing intègre un module WiFi (comparable au module ESP8266) ainsi qu'un module Bluetooth. Cette carte nous semble donc être la meilleure option pour pouvoir implanter les actions voulue sur une carte type Arduino. Il faut cependant installer une librairie dans Arduino pour pouvoir utiliser cette carte. Les démarches à suivre sont sur ce lien :

Installation ESP32 sur Arduino

Communication WiFi

Transmission directe via Access Point (SoftAP) sur ESP32 :

Lors des premiers essais, il a été constaté qu'en utilisant une carte Sparkfun ESP32 Thing en tant que point d'accès et une autre en client, la communication ne semblait pas fonctionner lorsque les deux cartes se trouvaient à moins de 20cm l'une de l'autre.
De plus, les débits disponibles ne semblaient pas dépasser 1 mot/s.
Il semblait cependant déjà possible d'envoyer un mot clé "ok" pouvant représenter un bit de start, puis la distance distS1 entre le slave 1 et le master, puis la distance distS2 entre le slave 2 et le slave 1, puis l'action à réaliser (sur deux caractères).
Le tout avait été fait en prenant l'option d'un serveur sur chaque esclave, et le maître connecté en tant que client aux deux esclaves car la carte Sparkfun ESP32 Thing possède plusieurs interfaces wifi (4).
Cependant, le protocole UDP over WiFi permet d'utiliser toutes les possibilités du WiFi sans dépendre du nombre de liaison série disponible. De plus, ce protocole est relativement rapide à intégrer lorsque le travail précédent a été réalisé.


Transmission UDP via Access Point (SoftAP) sur ESP32 :

C'est pourquoi nous utiliserons le protocole wifi UDP pour la communications entre maitre et esclaves.
La solution retenue sera donc dans un premier temps de configurer la carte Sparkfun ESP32 Thing du maître en SoftAP, et d'ensuite connecté chacun des deux esclaves à ce réseau via une IP fixe.
Nous aurons alors les IPs suivantes :

Carte IP
Maître 192.168.4.1 (AP)
Slave1 192.168.4.2
Slave2 192.168.4.3

Il sera cependant possible de rajouter une carte Sparkfun ESP32 Thing fixe qui permettra de réaliser l'Access Point et d'éviter d'entrer dans la zone inférieure à 20 cm où les communications WiFi ne passent plus.

Dans le code mis en place, le maître envoie la distance voulue et l'action à l'esclave adéquat (si celui-ci s'est connecté au maître via l'envoi d'un premier mot "Connecté" mis en place dans la partie Setup() juste après la connexion). L'esclave lui renvoie la distance voulue et l'action qu'il vient de recevoir, ainsi que la distance réelle mesurée avec le lidar :

figure 4 : Contenu des paquets lors des communications

Il pourra cependant aussi envoyé le fait qu'il ait détecté un obstacle grâce à l'ultrason.
Toutes les données citées ci-dessus sont stockées à chaque fois dans un paquet qui sera envoyé via le protocole UDP (nous ne devons donc plus nous soucier d'un éventuel bit de start et/ou bit de stop). L'avantage est que l'envoi peut se faire depuis n'importe quel robot vers n'importe quel autre robot en indiquant juste l'IP et le port de destination.
Une importance particulière est accordée au bon découpage des paquets transmis étant donné qu'il y transite différents types de données (int pour distance, String pour action) qui sont convertis en String pour pouvoir être transmis.

Afin de simuler l'appui d'une commande sur l'application en attendant l'implantation des modules correspondant, nous avons mis en place un bouton poussoir qui, en s'actionnant, enverra les commandes entrées aux esclaves grâce à la différenciation des adresses IP.


Les codes sont disponibles à l'adresse suivante (onglet Backup) :

Code WiFi Arduino

Communication Bluetooth

Participants : SILVESTRE Charles, OKITAUDJI Florian

Il a été mis en oeuvre une communication Bluetooth entre un smartphone et l'ESP32 du maître. Les données reçues sont ensuite aiguillées vers un port série de l'ESP32 pour l'envoyer à la Teensy dans le but de piloter le moteur. Il existe 2 types de communication série, HardwareSerial et SoftwareSerial. Nous avons choisi d'utiliser le SoftwareSerial afin de laisser libre l'UART2 pour la communication avec le LIDAR.
Remarque: L'accès à l'UART1 n'est pas immédiat, il faut faire une manipulation (simple) mais qui risque de rendre instable le système. En effet, l'UART1 est connecté à la mémoire FLASH de l'ESP32.

La liaison entre l'ESP32 et la Teensy est une liaison série 8 bits sans bit de parité, nous avons configuré le baudrate à 9600. Conditionnement des données : L'ESP reçoit caractère par caractère les commandes envoyées via le smartphone. Nous avons donc dû discerner les différentes informations qui sont : commandes moteur, distance entre robot 1 et maître, et distance entre robot 2 et robot 1. Pour ce faire, nous avons mis en place différents caractères de fin de chaîne en fonction de l'information. Pour détecter les commandes moteur, le caractère "/" est inséré après la commande. Pour la distance entre le robot 1 et maitre ".", et pour la deuxième distance ":".

Caractères de séparation Information précédent le caractère
. Distance entre robot maitre et robot 1
 : Distance entre robot1 et robot2
/ Commande moteur
figure 5 : Aiguillage des données Bluetooth

Il y a 2 fonctions Arduino sur l'ESP permettant d'écrire sur le port série : print et write. Nous avons tout d'abord utilisé print car il n'était pas possible d'envoyer de variables String avec write. Cependant, c'est la fonction print qui nous a posé des problèmes lors de l'envoi. Nous avons donc, avec une astuce, envoyé les chaines de caractères avec write :

if (commande_reçue_bluetooth == String("av")) mySerial.write("av");

Et cette condition est répétée pour chacune des commandes moteur.

Les librairies utilisées proviennent des liens suivants:

ESP32 librairie Arduino

HardwareSerial

SoftwareSerial

Application Android

Participants : BRIALON Auriane, GALLEY Nicolas

Lien vers l'apk de l'application

Afin de diriger le robot maître, il est nécessaire de créer une application android qui va donc envoyer les commandes nécessaires. Nous avons dans un premier temps mis en place des commandes correspondant aux différentes actions réalisables par le robot que nous pouvons retrouver dans le tableau suivant :

Direction Commande
Avancer av
Reculer ar
Droite dr
Gauche ga
Avant-droit ad
Avant-gauche ag
Arrière-droit bd
Arrière-gauche bg
Chorégraphie rotation cr
Chorégraphie crabe cc
Chorégraphie zigzag cz
Stop st

L'application doit donc gérer les actions du robot en envoyant une chaîne de caractères (correspondant aux commandes vues précédemment) et gérer la distance de l'esclave 1 par rapport au maître et celle de l'esclave 2 par rapport à l'esclave 1. Nous devons donc mettre en place autant de boutons que d'actions possibles et deux zones de texte permettant de récupérer les différentes distances entrées par l'utilisateur.
De plus, l'application doit communiquer en Bluetooth avec le robot donc nous ajoutons un boutons permettant de voir et sélectionner les périphériques connectés en Bluetooth disponibles. (cf. figure 6)


figure 6 : Visuel de l'application

Nous créons l'application à l'aide de App Inventor 2 car ce dernier gère plus facilement le Bluetooth. En effet, après plusieurs essais sous Android Studio, nous n'arrivions toujours pas à gérer le Bluetooth et l'émulateur était vraiment très lent. App Inventor 2 utilise le principe de "Drag & Drope" ce qui permet de créer aisément une interface graphique ainsi que le programme. Pour implémenter une communication Bluetooth avec App Inventor 2, il suffit d'ajouter au projet un composant "Bluetooth client" et d'utiliser les fonctions d'envoie et de réception de données déjà toutes faites.

Remarque : L'application a été installée sur une tablette Android. La version d'Android nécessaire pour pouvoir communiquer en Bluetooth entre l'application et l'ESP doit être supérieure à 5.0 (Android Lollipop minimum).

Concernant le code, à chaque événement sur un bouton, nous envoyons la chaîne de caractères correspondante avec un "/" afin que la réception Bluetooth puisse séparer les différentes informations qu'elle reçoit.
Pour la distance, l'utilisateur la rentre dans une zone de texte et appuie sur valider. Donc, au clic, nous récupérons cette valeur que nous mettons dans une variable et que nous envoyons par la suite.

Nous allons maintenant voir le code plus en détail.
Dans un premier temps, il est nécessaire de déclarer deux variables correspondants aux distances que nous voulons envoyer au robot. Nous les initialisons à 50 (cf. figure 7).

figure 7 : Initialisation des variables

Ensuite, concernant le Bluetooth, nous récupérons la liste des périphériques Bluetooth disponibles (cf. figure 8).

figure 8 : Bluetooth partie 1

Puis nous nous connectons au périphérique sélectionné. Lorsque c'est fait, le bouton passe en vert et un message "connecté" apparaît. A l'inverse, le bouton est rouge et le message est "déconnecté" (cf. figure 9).

figure 9 : Bluetooth partie 2

Concernant les instructions à envoyer au robot, nous avons vu qu'il fallait créer différents boutons. Nous allons expliciter le fonctionnement des boutons :

  • L'instruction de marche arrière

Quand nous appuyons sur le bouton, l'application envoie par bluetooth une chaîne de caractères (ici "ar") ainsi qu'un caractère de fin de chaîne "/" permettant une réception des données plus facile, et le label "En marche" devient vert. Lorsque nous relâchons le bouton, le caractère envoyé est "st/", correspondant à l'instruction stop et le label "En marche" passe au rouge (cf. figure 10).

figure 10 : Instruction marche arrière

  • Les instructions de distance

Nous avons vu que nous pouvions choisir la distance entre les robots : S1 pour la distance entre le maître et l'esclave numéro 1 et S2 pour la distance entre les 2 esclaves. Concernant le code associé, dans un premier temps, si l'utilisateur n'entre aucune valeur, la valeur par défaut est 50 cm. Ensuite, si l'utilisateur entre une valeur supérieure à 600 cm alors cette dernière sera automatiquement mise à 600 cm, de même si la valeur entrée est inférieure à 50 cm, l'application enverra 50 cm. Ces valeurs correspondent à la plage d'utilisation des capteurs (cf. figure 11). Afin de permettre au robot maître d'envoyer la valeur de distance au bon esclave, nous avons ajouté un caractère à la suite de la valeur entière : un "." pour identifier la distance à envoyer à l'esclave 1, un ":" pour identifier la distance à envoyer à l'esclave 2.


figure 11 : Instructions de distance


  • Le test de communication Bluetooth

L'état de la communication Bluetooth entre le smartphone ou la tablette et le robot maître est continuellement mis à jour afin de modifier le label "Connecté/Déconnecté" en conséquence. Pour tester en continu la communication, nous avons ajouté à l'application un composant "Clock" (qui porte mal son nom car il s'agit en fait d'un timer). Grâce au composant Clock, nous envoyons régulièrement (toutes les 2.5 secondes) un caractère au robot maître. Ce caractère ne correspond bien sûr pas à un ordre de direction, puisqu'il s'agit ici simplement de vérifier la communication Bluetooth. La caractère envoyé est donc différent des caractères de commandes listés dans le tableau précédent (il s'agit d'un '+', qui n'est donc pas pris en compte par le robot maître). A chaque émission du '+', nous testons si le Bluetooth est bien connecté via la méthode ".ErrorOccurred". Si ce n'est pas le cas, le label indiquant l'état de la connexion passe au rouge et affiche "Déconnecté" :

figure 12 : Test de communication Bluetooth

Pourquoi envoyer toutes les 2.5 secondes un caractère au robot maître ? Tout simplement parce que app Inventor n'actualise pas de lui même l'état de la connexion. Ainsi, elle est testée uniquement lors de l'envoi d'une commande, ce qui veut dire que si la communication Bluetooth cesse de fonctionner, le label indiquant l'état de la connexion n'afficherais "Déconnecté" qu'à l'envoie de la prochaine commande.

Lidar et télémètre ultrasons (Guy Kouassi Kra,Baboucar Sane,Romain Vergez)

Lidar

Le Lidar ( LIght Detection And Ranging, soit détection et estimation de la distance par la lumière) permet de mesurer des distances à l'aide des propriétés du faisceau de lumière renvoyé par son émetteur.

Nous avons utilisé le capteur de distance TF-Mini Lidar au cours de ce projet.

figure 13 : Le Lidar

Il nous permet théoriquement de mesurer des distances comprises entre 30 cm et 12 m, avec une précision au cm, et une incertitude de 1% en dessous de 6m et 2% pour l'intervalle 6-12m. Nous avons donc mené une série de tests pour évaluer la stabilité lors d'une suite de mesures, ainsi que de vérifier s'il était nécessaire d'avoir un type d'écran particulier pour avoir des mesures précises.

Nous avons donc fait des mesures de distances avec le capteur en visant un mur puis une plaque en métal (qui permet d'avoir avoir une plus grande puissance reçue en réfléchissant mieux le signal).

figure 14 :
figure 15 :

Nous constatons qu'il existe deux calibres d'émission (bien que nous n'ayons pas trouvé d'informations supplémentaires dans les datasheets), ce qui pourrait être gênant quant à l'utilisation de la puissance reçue pour évaluer l'alignement des robots.

S'il apparait que nous pouvons mesurer des distances plus grande en attachant une plaque de métal à l’arrière du robot, les incertitudes sont plus grandes, et la distance minimale est plus élevée (au moins un mètre). On utilisera donc le lidar dans des conditions standards.

Télémètre ultrasons

Pour palier au problème du lidar en dessous de 50 cm, nous allons utiliser un télémètre à ultrason (le Module de détection aux ultrasons HC-SR04). Il permet de mesurer des distances comprises entre 3cm et 4m. Nous allons donc programmer le robot pour qu'il alterne entre la mesure lidar et la mesure du télémètre en fonction de la plage de distance dans laquelle il se trouve, et en particulier pour la gestion des obstacles.

figure 16 : Le télémètre

Néanmoins le fonctionnement de ce capteur pose un problème : il mesure la durée durant laquelle le signal de sortie est à l'état haut , ce qui dure au maximum 20 ms dans le cas d'une mesure valable. Cependant, si l'obstacle est à une distance trop grande le temps de réponse du capteur est de plus de 100ms ce qui représente un temps trop grand en terme d’utilisation du processeur de l'ESP32.

figure 17 : Fonctionnement du capteur

Il nous a fallu trouver une autre solution. Nous avons donc choisi de détecter les fronts montants et descendants, nous libèrons ainsi le processeur durant ce laps de temps.

Carte ESP

figure 18 :
figure 19 :

L'ESP32 est alimenté sur le port USB en 5V, l’ultrason et le lidar s'alimentent en 5V issu des pins VUSB de l'ESP. L'écho de l'ultrason est relié à la pin 27 de l'ESP et le trigger à la pin 26. Le RX du lidar est relié à la pin 17 de l'ESP et le TX à la pin 16. La communication série entre l'ESP et la teensy est établie sur les pins 5 et 15. Les masses de la teensy, de l'ESP, de l'ultrason et du lidar sont reliées. Remarque : les pistes reliant le VCC et GND de l'ultrason et du lidar aux pins de l'ESP sont coupées pour de pas envoyer du 5V dans les pins de l'ESP.

figure 20 :

La pin écho de l'ultrason renvoie du 5V vers la pin 27 de l'ESP, or cette dernière supporte du 3,3V au maximum, on utilise un pont diviseur de tension pour abaisser les 5V à 3,33V. Remarque: On met du scotch derrière pour isoler la carte en cas de contact sur une surface conductrice (risque de court-circuit).

Déplacements et chorégraphies

Déplacements des moteurs

Nous avons créé plusieurs fonctions pour manipuler les moteurs des robots:

  • Avancer
  • Reculer
  • Aller à droite
  • Aller à gauche
  • Aller en diagonale : avant-droite, avant-gauche, arrière-droite, arrière-gauche
  • Aller en crabe
  • Tourner sur lui même
  • Zigzaguer

En effet, il s'agit d'envoyer des commandes à partir de la carte teensy au pont en H de référence L298N pour manipuler les 4 roues du robot maître et les 3 roues des moteurs esclaves. Le pont en H quand à lui permet de manipuler la rotation des moteurs dans un sens donné à partir des sorties OUTPUT1 et OUTPUT2 et il permet également de faire varier la vitesse des moteurs ( entre 0 et 255) à partir de sa sortie analogique ENABLE.


IMU : Inertial Measure Unit


figure 21 : Pololu

Pour obtenir des informations précises sur l’inclinaison de nos trois robots par rapport au plan de masse nous avons utilisé un capteur inertiel. Pololu altimu-10 v4 qui est une unité de mesure inertiel (IMU : Inertial Measure Unit). En effet le capteur comprend un accéléromètre 3D, un gyroscope 3D et un magnétomètre.

  • L'accéléromètre 3D permet de mesurer la direction et l'amplitude de l'accélération subie par le capteur,
  • Le gyroscope 3D permet de mesurer la vitesse angulaire du capteur et l'orientation de l'axe de rotation,
  • La boussole 3D permet de mesurer l'orientation du champ magnétique extérieur par rapport au module.

Nous allons expliquer le principe de l'accéléromètre et du gyroscope.

L’accéléromètre

figure 22 :

figure 23 : Principe accéléromètre


Pour simplifier la compréhension de l’accéléromètre, imaginez une balle. Si nous imaginons cette balle dans un endroit sans champ gravitationnel ou sans d’autres champs qui pourraient affecter la position de la balle - la balle flottera simplement au milieu de la case.

figure 24 :Endroit sans champ gravitationnel

Par contre, si nous imaginons que chaque mur est sensible à la pression. Si nous bougeons brusquement la case vers la gauche (On prend l’accélération 1g = 9.8m / s ^ 2), la balle va frapper le mur X-. Nous mesurons ensuite la force de pression que la bille applique sur le mur et fournissons une valeur de -1 g sur l'axe X.

figure 25 : Endroit sensible à la pression

Remarque: l'accéléromètre détectera réellement une force dirigée dans la direction opposée à partir du vecteur d'accélération. Cette force est souvent appelée force d'inertie ou force fictive

L’accéléromètre mesure l'accélération indirectement à travers une force qui est appliquée à l'un de ses murs (selon notre modèle, cela pourrait être un ressort ou autre chose dans les accéléromètres réels). Cette force peut être causée par l'accélération, mais comme nous le verrons dans l'exemple suivant, elle n'est pas toujours causée par l'accélération
Posons maintenant notre boite sur la terre, la balle tombera sur le mur en Z et applique une force de 1g sur le mur du fond (voir figure ci-dessous)

figure 26 : Effet de la force de gravitation

Dans ce cas, la boîte ne bouge pas mais nous obtenons toujours une lecture de -1g sur l'axe Z. La pression a été causée par une force de gravitation.








Remarque: La force n’est pas toujours causée par l’accélération

Gyroscope

Ensuite, le deuxième dispositif de l'IMU est le gyroscope, qui mesure le mouvement de rotation d'un système par rapport aux axes de référence adoptés. Le nombre d'axes qui seront utilisés pour mesurer dépend du nombre d'axes que nous considérons dans notre système, par exemple, si nous utilisons un système à 2 axes, le gyroscope mesurera par rapport aux axes X et Y. Pour notre projet, nous considérons l'étude et la mesure des trois axes, X, Y et Z, comme le montre la figure 27.

figure 27 : Axes de mesure d’un gyroscope

Dans l'exemple de la figure précédente, on peut noter les projections de la force vectorielle R par les trois axes, pour les zones XY, YZ et XZ du plan, ainsi que les angles qui se forment entre les projections et les axes de référence.

  • Rxz – projection dans le plan XZ
  • Ryz – projection dans le plan YZ
  • Axz – angle entre Rxz et l’axe Z
  • Ayz – angle entre Ryz et l’axe Z


De cette façon, on peut dire que le gyroscope mesure la vitesse de changement des angles qui ont été présentés. C'est-à-dire qu'il renvoie une valeur qui correspond linéairement au taux de variation de cet angle.

figure 28 : mesure du Gyroscope par rapport aux plans XZ
figure 29 : mesure du Gyroscope par rapport aux plans YZ



Un exemple peut être illustré par le cas suivant. Si nous souhaitons mesurer la rotation de l'angle Axz, formé vers l'axe Y, on considère, pour le moment initial t0, l'angle que on peut nommer Axz0. Après, pour la deuxième mesure à l'instant t1, on considère l'angle Axz1. Comme ceci, le calcul du taux est donné de la façon suivante :


TauxAxz = (Axz1 - Axz0) / (t1 - t0).

Conclusion

Participants : ARNALDO ALVES Lucas, BOUCHIKHI Al mehdi, BRIALON Auriane, CARVALHO FONTÃO Caroline, DALIL Hajar, GALLEY Nicolas, KASZUBIAK Grégory, KRA Kouassi, OKITAUDJI Florian, RAMOS Théo, SANE Baboucar, SILVESTRE Charles, VERGEZ Romain.