Robots danseurs technique
Baguette magique
Schéma de câblage
Programmes/Résultats
Test du gyromètre
Le programme suivant nous a servi à tester le gyromètre, il renvoie des valeurs en fonctions de la direction dans laquelle le gyromètre est déplacé.
Résultats :
On voit ici les données brut renvoyées par le capteur Pololu, soit des valeurs d'accélération dans les trois directions de l'espace. Ces valeurs n'étant pas facilement lisibles nous avons implanté une fonction traduisant les informations bruts en directions.
Association des directions
Dans ce programme, nous avons associé des directions en fonction du mouvement détecté par le gyromètre. De plus, nous avons rajouté un bouton poussoir permettant de ne prendre en compte que les mouvements désirés.
Résultats :
Nous avons maintenant ici les résultats du capteur, une fois traités, ils nous permettent de savoir dans quel sens est dirigée la baguette de manière aisée.
Envoi des directions captées via BLE
Ce programme est utilisé pour tester toute la partie purement fonctionnelle du code, il recouvre toute la partie d’acquisition des données gyroscopiques, d'association de directions et de communication BLE.
Résultats :
- Côté serveur :
- Côté client (réception sur terminal android pour le test) :
Nous utilisons l’application mobile BLE scanner afin de récupérer les données émises par la carte via Bluetooth. Cela nous à permis de tester la communication de la baguette indépendamment de celle du robot.
Nous voyons bien la valeur envoyée (AV) dans "Value".
Programme final de la baguette magique
Pour finir, nous avons rajouté la programmation du ruban de leds, du vibro-moteur ainsi que la gestion des 2 modes de fonctionnements, à savoir le mode manuel et automatique.
Problème rencontré avec le ruban de LEDS
Nous avons un problème non résolu avec le ruban de LEDS, en effet certaines LEDS s'allument sans recevoir d'instructions comme le montre la photo ci-dessous.
Nous avons donc tenté d'isoler le problème en cherchant à changer les couleurs/intensités/instructions et même le modèle de carte.
Au final, il semblerait que le problème vienne du programme présents dans la bibliothèque du ruban. Nous avons donc cherché directement dans la librairie fournie avec la bande de LED afin d'identifier et de régler ce problème. N'étant toujours pas résolu à ce jour, nous pouvons tout de même utiliser le ruban. Les effets de monter et descente de l'allumage des leds restent appréciables malgré que certaines leds ont une couleur différente.
Un autre problème a été son alimentation, en effet non seulement elle peut être très consommatrice d'énergie mais en plus elle n'est pas alimentée en 3.3V. Ce qui implique l'ajout supplémentaire d'une batterie dans la baguette et donc une perte de place.
Conception 3D
La conception 3D de la baguette à été faite sous Solid Works. Elle a ensuite été imprimée en 3D.
Initialement elle devait s'ouvrir aux deux extrémités (à la manière d'un manche de corde à sauter) afin de pouvoir accéder aux différentes cartes et batteries à l'intérieur. De plus nous souhaitions qu'elle s'amincisse à son extrémité.
Cependant c'est l'ouverture par la tranche à la façon d'un moule (la baguette est coupée sur toute la longueur et maintenue en place par des vis) qui a été retenue, en effet cela garantie une plus grande résilience en une praticité accrue, au détriment cependant de l'aspect esthétique. De plus l'affinage à été abandonné car la place était top faible au vu du nombre de composants nécessaire et de leur taille.
Robot-maître
Schéma de câblage
Afin de pouvoir alimenter l'ensemble des cartes et moteur avec une seul batteries nous avons utilisé un pont diviseur de tension pré-fait pour nous assurer de la stabilité de la tension d'alimentation.
Programme
Le programme du robot-maître se sépare en deux grandes parties:
- le pilotage du robot (assuré par la carte Arduino Teensy)
- la communication avec la baguette et les robot-esclaves (assuré par la carte Sparkfun esp32)
Pilotage
Les moteurs sont pilotés via un asservissent et des interruptions par la carte Arduino Teensy.
Dès que l'une des roues codeuses atteint une nouvelle position elle génère une interruption afin d'optimiser la réactivité de notre asservissement en limitant les consommations électriques de la carte.
Après une période d'environ deux minutes les moteurs s’arrêtent de fonctionner car ils deviennent trop chaud. Nous avons changer les radiateurs pour en installer de plus gros afin de pallier le problème.
Communication Bluetooth
On voit ici une tentative de connexion entre la baguette et le robot, la connexion ne fonctionnait pas vraiment car le robot ce connectait et ce déconnectait en permanence
Nous avons donc modifié le code du robot pour régler ce problème.
Communication Wi-Fi
Les communications Wi-Fi et Bluetooth sont gérées par la carte Sparkfun esp32.
Nous avons dans un premier temps eu des problèmes pour établir une communication stable entre le serveur et le client. En effet le client pouvait se connecter mais il ne parvenait pas obtenir d'information de la part du serveur. Une fois réglé ce problème il à été simple de connecter un second client au serveur.
Cependant les deux clients ne sont pas connecté au même moment au serveur, ils alternent les connexions au serveur plusieurs fois par seconde.
Mais un problème persiste: lorsque la carte du robot-maître doit à la fois réservoir les informations Bluetooth et transmettre les ordres en Wi-Fi le système deviens instable. Afin de palier ce problème nous avons tenté de créer une connexion UDP pour pouvoir établir une connexion stable entre le robot-maître et les deux robot-esclaves simultanément.
La raison pour choisir ce prototype est que la liaison UDP ne considère pas la disponibilité des destinations, il ne prise en compte que ses addresses IP et le port. C'est-à-dire si la commande à envoyer est disponible, le serveur va l'envoyer directement vers les addresses des clients via le port prédéfinit sans considerer s'ils peuvent recevoir ou pas. Selon les resultats des testes que nous avons fait, nous pensons que le prototype UDP est assez stable pour notre application.
La solution retenue sera donc dans un premier temps de configurer la carte Sparkfun ESP32 Thing du serveur en SoftAP, et d'ensuite connecté chacun des deux clients à ce réseau via une IP fixe.
Nous aurons alors les IPs suivantes :
| Carte | IP |
|---|---|
| serveur (robot maître) | 192.168.4.1 (AP) |
| client1 (robot esclave1) | 192.168.4.2 |
| client2 (robot esclave2) | 192.168.4.3 |
Dans le code mis en place, les esclaves vont tout d'abord envoyer ses addresses IP au maître comme lui ditent qu'ils sont prêts, puis le maître envoie la commande ce qu'il a reçu de la baguatte par Bluetooth (sous format String) à l'esclave connecté.
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).
Nous avons rencontré des soucis avec la sparkfun hébergent à la fois le serveur bluetooth et Wi-Fi, en effet elle plante régulièrement après une utilisation trop longue. Cela est sans doute dû à des fuites de mémoires. Et la communication ne semblait pas fonctionner lorsque les cartes se trouvaient à moins de 20cm l'une de l'autre.
Finalement la communication est effectué à 115200 bauds et subit quelques conflit sans influences sur la stabilité globale.
Robot-esclave
Schéma de câblage
Le schéma de câblage des robot-esclaves est le même que celui du robot-maître, il a juste été adapté pour trois roues
Programme
Le programme des robot-esclaves est également le même que celui du maître, seule la partie concernant la communication Wi-Fi change.
Les deux robot-esclaves on évidement le même code client wifi, cependant ils ont chacun leur propre adresse IP
