Déroulement projet robots suiveurs

Éléments de notre projet

Instructable Robots suiveurs
Robots suiveurs

Sujet

Nous proposons aux participants de créer et développer des robots connectés, sur le thème initial de robots suiveurs. Le scénario de départ fait intervenir un robot-maître, suivi de 2 robots en file indienne. Ce scénario est appelé à évoluer en complexité au fil de l'avancée du projet.

Les robots seront développés sur des bases Stinger et Traxer qui embarquent une carte microcontrôleur qui gère la puissance et l'asservissement. Le dialogue (envoi de commandes) avec cette carte se fait par liaison série TTL 5V. L'intelligence du robot et la communication sans fil seront gérées par Arduino Yùn.

Premier Brainstorming : Séance 1

Participants : Charlotte, Safae, Léa, Flora, Jimmy, Mehdi, Cyril, Yoann, Axel.

Objectif

• Avoir 3 robots qui se suivent.
• Obtenir la même distance entre les robots au départ et à l’arrivée.

1ère solution évoquée : Robot maître avec détection des obstacles, les autres sans; le maître transmet l’itinéraire à suivre aux autres robots.

Problème : si vitesse différente des robots, cela ne marchera pas.

2ème solution : Le premier détecte et dit aux autres le parcours à suivre. Les deux autres suiveurs suivront le même parcours, ils auront cependant juste à veiller que la distance avec le robot de devant soit correct (sinon ils s’adapteront -> Accélérer/freiner).

Problème : nécessité de communiquer entre les robots.

Communication entre les robots

• 1ère solution:
  • Wi-Fi comme vu en première séance
  • Ethernet
  • Bluetooth

-> Choix de Wi-Fi car plus fiable et vu en première séance de projet.

Solutions techniques apportées en « vrac » :

• Utilisation de timers pour savoir combien de temps le robot doit rouler avant de s’arrêter.
• Les roues du robot sont asservies. Le robot va faire en sorte d’atteindre la vitesse que nous lui donnerons.

Résumé de la méthode à aborder pour le moment

Le maître détecte l’obstacle et tourne sur place d’un côté, il communique ensuite aux autres robots la distance minimum à partir de laquelle les robots esclaves devront tourner si il détecte un obstacle.

Problèmes engendrés par cette méthode : Pendant que le robot maître tournera, il est possible que les esclaves détectent le robot maître en pleine manœuvre comme un obstacle et qu’ils commencent à tourner, cela décalerait le parcours des robots esclaves car ils n’étaient pas censés tourner avant de détecter l’obstacle.

Solutions envisagées (à étudier plus tard dans le projet) : Pendant que le premier robot tourne, les autres s’arrêtent/ralentissent et attendent un peu que le robot ait terminé sa manœuvre de rotation. -> Cependant il faudra que les deux robots suiveurs rattrapent la distance perdue pendant qu’ils étaient à l’arrêt par la suite.

Répartition du travail :

• On se divise le travail en trois groupes pour éviter de tous travailler sur la même chose.
• Un groupe travaillera sur la communication entre deux cartes Arduino côté serveur
• Un autre groupe travaillera sur le robot maître (mise en marche et détection d’obstacles)
• Un troisième groupe travaillera sur la communication côté client
• Mise en commun des méthodes mises en place pour le calcul de la distance entre le capteur et l’objet afin d'arriver à une méthode la plus fiable possible de calcul de distance à l’aide des capteurs.

Idées de développements ultérieurs

• Faire un parcours sans obstacles où les robots feraient une chorégraphie et se rejoindraient tous à un moment donné.
• Programmer les robots pour que le robot maître, si jamais un robot est déplacé, puisse rappeler tout ses robots et qu’ils se remettent en place (PROBLÈME : il faudrait un GPS -> Matériellement pas possible à réaliser pour le moment).
• Commande à distance, pour ordonner une séparation par exemple, puis il faut qu’ils se remettent tous en place.

Idées à approfondir peut être et/ou à étudier pour pouvoir réaliser un projet intéressant.

Phasage

Jour 1

Qu'est-ce qu'on voulait faire ?

Prise en main de la carte Arduino Yùn.

Dans un premier temps, notre objectif était de faire clignoter la LED N°13, tout d'abord, en passant par le port série de la carte Arduino Yun, puis ensuite à partir d'une requête HTTP.

Qu'est-ce qu'on a fait ?

Pour atteindre notre objectif, dans un premier temps nous avons créé une méthode Blink , qui permet de faire clignoter la LED N°13 à partir du port série de la carte Arduino.

Dans un deuxième temps, nous avons configuré la carte en s'y connectant à partir d'un ordinateur en Wi-Fi pour pouvoir lui envoyer des requêtes HTTP. Nous avons ensuite utilisé un code ( fourni par Mr. Eric VERNEY ), que nous avons modifié en important la méthode Blink utilisée précédemment accessible depuis l'adresse 192.168.240.1/arduino/blink et permettant de faire clignoter la LED.

Objectif pour la séance prochaine

Prendre en main un télémètre à infrarouge , le brancher à la carte Arduino Yùn , et effectuer des mesures de distance précises.

Jour 2

Qu'est-ce qu'on voulait faire ?

Ce jour là nous avons eu le télémètre à mettre en place. Chaque groupe a travaillé de son côté pour prendre en main le télémètre à infrarouge et effectuer la tâche souhaitée.

Le but était d'arriver à mesurer une distance fiable et précise grâce au télémètre branché sur la Arduino Yùn.

Qu'est-ce qu'on a fait ?

1ère partie

Chaque groupe a d'abord lu la datasheet du composant. Puis nous avons connecté le télémètre à la Arduino en programmant les ports au préalable.

Une fois le télémètre en place, nous avons procédé de manière suivante:

• écriture d'un code pour récupérer les valeurs lues en mV par le télémètre
• lecture des valeurs et amélioration de la précision des mesures via un code qui fait une moyenne de 200 valeurs
• conversion des valeurs lues des mV en cm via une équation de linéarisation de la courbe théorique de la datasheet

2ème partie: Brain Storming

A la fin de la séance nous nous sommes réunis afin de discuter sur le cahier des charges, le travail à réaliser et sa répartition.

Au cours de ce brain storming, plusieurs solutions étaient envisagées quant à la réalisation du projet:

• Les trois robots sont équipés de télémètres et chacun gère les obstacles qu'il a face à lui. Les deux robots qui suivent doivent juste garder la même distance. Solution non retenue car demande un certains nombre de télémètre.
• Deux robots suiveurs reçoivent les ordres du premier qui transmet l'itinéraire mais non retenue car si la vitesse est différente entre les robots ça ne marchera pas.
• Le premier détecte et dit aux autres le parcours à suivre. Les deux autres suiveurs suivront le même parcours, ils auront cependant juste à veiller que la distance avec le robot de devant soit correct (sinon ils s’adapteront -> Accélérer/freiner). Cela nécessite de communiquer entre les robots.

La dernière solution est la solution retenue.

Qu'est-ce qu'il nous reste à faire ?

Le projet étant à son début, tout reste à faire!

Objectifs à court terme

• Établir la communication entre deux cartes Arduino via WiFi (un serveur / un client)
• Fixer le télémètre sur un robot et diriger le robot par rapport aux obstacles.

Jour 3

Qu'est-ce qu'on voulait faire ?

Notre objectif de cette séance était d'avancer les deux grosses parties du projet en parallèle. Ce travail consistait à :

• Mettre en place la communication Client/Serveur sur deux cartes Arduino.
• Réfléchir à un système et commencer sa réalisation pour l'installation des capteurs sur le robot de tête (robot qui va détecter les obstacles/robot serveur).

Qu'est-ce qu'on a fait ?

Partie Communication

Tout d'abord il a fallu nous connecter à nouveau aux cartes Arduino Yùn afin de pouvoir les configurer.

Notre objectif étant de pouvoir ensuite travailler sur les cartes via un point d'accès commun, nous permettant de communiquer entre nos PC et nos cartes via notre réseau (et aussi tester la communication directement entre les cartes).

Toutes les informations passeront par notre point d'accès. Notre carte est branchée à l'ordinateur uniquement pour alimenter la carte (elle ne reçoit plus de données en USB).

Concernant la communication inter-cartes nous désirions simplement commencer par envoyer un message Hello World pour vérifier si l'échange de données se faisait de manière correcte.

Problèmes rencontrés

Aucun point d'accès disponible et visible depuis notre salle de travail ne correspondait à nos attentes. Soit le réseau en question nécessitait l'utilisation de proxys ou bien notre carte se connectait au réseau, mais lorsque l'on connectait notre ordinateur à celui-ci, la carte se déconnectait au bout de quelques secondes.

Pour notre message Hello World nous arrivions bel et bien à transmettre notre message, cependant des séries de '-1' se glissaient au milieu de notre message. La solution à ce problème a été trouvée au début du jour 4.

Solution mise en place

Nous avons donc décidé d'utiliser un des routeurs fourni par l'école (modèle D-Link DWL 2100 AP) et de le configurer nous même afin que nous puissions agir sur tous les paramètres de notre réseau (notamment configurer le DHCP, le Lease time...). Après configuration de celui-ci nous avons finalement réussi à nous connecter à notre point d'accès (nos ordinateurs ainsi que nos cartes, ces dernières se connectent maintenant par défaut à notre routeur).

Présentation du support de suivi

Il nous a été présenté le support sur lequel nous devions faire le suivi journalier du projet, il s'agit donc de ce site.

Partie Capteurs Robots

Pour cette partie nous avons commencé par réfléchir à comment notre robot de tête (robot serveur) allait détecter nos obstacles. Nous devons être sûrs que notre robot pourra détecter un obstacle sur toute sa largeur (c'est-à-dire même au niveau des roues).

Ceci a permis de guider notre premier objectif de travail, qui a alors consisté à déterminer quel était expérimentalement le champs de vision de notre capteur (Est-il large ou mince ?). Nous avons réalisé un programme rapide grâce auquel nous faisions tourner les roues du robot lorsqu'il détecte un objet à moins de 30cm (au delà de cette distance notre capteur n'est plus très fiable). Notre conclusion est que le capteur détecte l'objet seulement si il se trouve dans l'axe (couloir d'environ 1cm) de l'émetteur de notre capteur (il y a un émetteur ainsi qu'un récepteur sur notre télémètre).

Cette étape d'expérimentation nous a permis de nous poser la question suivante : De combien de capteurs allons nous avoir besoin?

Nous sommes partis sur une base de trois capteurs pour pouvoir couvrir une largeur maximum de notre champs de course. La question suivante que nous avons dû nous poser était de savoir comment allions nous les positionner sur notre robot pour pouvoir détecter les obstacles de la meilleur façon possible.

Voici ci-dessous les deux premières configurations auxquelles nous avons pensé :

1er choix de configuration étudié pendant le Jour3

Choix de configuration adopté pendant le Jour3

La première n'a pas été approfondie car trop imprécise. La deuxième, quant à elle, est celle qui a été utilisée pour notre étude tout le reste de la journée. En effet, grâce à cette méthode nous pensons pouvoir détecter un objet sur toute la largeur du robot quelle que soit sa taille.

Pour installer ces télémètres de manière stable sur notre robot nous avons utilisé des socles fournis par l'école nous permettant de visser les capteurs au robot. (voir photo ci-dessous).

Socle utilisé pour placer nos capteurs

Problème rencontré

Nous avons constaté un problème lorsque le capteur n'a aucun objet placé devant lui (distance infinie). En effet, nous lisons une valeur numérique en sortie du capteur identique à la valeur que l'on devrait recevoir lorsque notre objet se trouve à 10cm de distance environ. Ceci est problématique car il n'y a pas de différence au niveau du capteur entre un chemin libre d'accès ou un objet situé à 10cm.

Solution apportée

Nous avons pensé à régler la distance seuil de notre programme (distance à partir de laquelle notre robot va avertir d'une collision et vouloir changer de direction) juste en dessous de la distance qui nous pose problème au niveau du capteur (10cm dans notre paragraphe précédent). Ainsi, si notre objet est à 10cm ou qu'il n'y a pas d'objet, notre robot avancera. Mais si l'objet est détecté à 9cm alors une manœuvre sera effectuée. Nous devons encore approfondir cette méthode de travail car nous ne sommes pas sûrs de sa fiabilité.

Objectifs pour la prochaine fois

Communication

La communication entre les deux cartes est à poursuivre. En effet, nous arrivons à envoyer une donnée par le serveur et qu'elle soit récupérée par le client, mais il y a encore des problèmes. La donnée réceptionnée comporte plus de données que l'original (les -1).

Il faudra donc régler ce problème afin que la communication entre les robots soit faite sans interférence ni perte de données.

Robot et télémètre

Il nous faut approfondir notre méthode de détection d'obstacles car pour le moment certains problèmes sont encore présents et notre objectif final serait d'obtenir une détection fiable.

Il nous faudrait vérifier les caractéristiques de nos trois télémètres et effectuer une série de test pour pouvoir utiliser les résultats obtenus afin d'arriver à une solution fiable de détection.

Wiki

• Rédaction du wiki
• Suivi du wiki

Jour 4

Qu'est ce qu'on voulait faire ?

Comme dit dans le Paragraphe Jour 3: Objectifs pour la prochaine fois nous devons améliorer la partie robot en mettant au point un système le plus fiable possible. Concernant la partie communication nous voulons pouvoir communiquer les informations que nous souhaitons entre les deux cartes en passant par notre routeur. Nous aimerions aussi déterminer une méthode de communication entre le maître et les esclaves. Nous mettre d'accords tous ensemble sur cette méthode et essayer de la fiabiliser pour échanger nos données de la façon la plus fiable possible.

Qu'est ce qu'on a fait?

Partie communication entre les deux cartes

Travail réalisé

On arrive à récupérer le message hello world sur la deuxième carte et à l'afficher pleinement sans -1, en modifiant le code de sorte à ce qu'il n'y ait envoi que sur demande du client. Par la suite , nous avons allumé la LED 13 de la première carte à partir de la deuxième carte . Nous avons mis en place un télémètre afin de détecter si l'obstacle est proche de celui-ci, et si c'est le cas, allumer la LED.

La LED s'allume quand la main est proche du capteur.

La LED s'éteint quand il n'y a pas d'objet.

Affichage sur l'interface Arduino de l'état de la LED

Pistes de travail

Deux stratégies d'approche sont possibles:

• Le robot principal (Maître: M) envoie ses données sur le serveur lorsqu’on le lui demande et les deux autres (esclaves : E1 & E2) lisent les données et adaptent leurs trajectoires en fonction de celles-ci.

• Le robot maître donne aux robots esclaves l’ordre de faire le mouvement, ces derniers lui renvoient l'information qu'ils ont bien reçu l'ordre.

Pour la suite du projet, nous avons choisi d'utiliser la deuxième stratégie car celle-ci présente une étape en moins, ce qui est pratique, et elle évite une surcharge du serveur du robot maître.

Tâches réalisées

• Tout d'abord nous avons testé et approuvé une nouvelle méthode de positionnement des capteurs sur le robot maître. En effet comme vu dans le paragraphe concernant la disposition des capteurs sur le robot, nous avions réfléchi et testé deux méthodes différentes cependant nous avons au début de cette 4ème journée réfléchi à une troisième méthode plus appropriée.

En effet, cette nouvelle méthode (voir schéma ci-dessous) nous permet de balayer toute la largeur de notre champ de course tout en restant très précis au niveau des capteurs (on n'a pas besoin de détecter les objets de très loin, donc on s’affranchit des problèmes de détection à de grandes distances).

Choix de configuration adopté pendant le Jour4

• Changement de format de la valeur utilisée pour notre détection. Nous convertissions la valeur récupérée en sortie du capteur puis nous effectuions des calculs pour convertir cette donnée en cm. Cependant nous avons rencontré de nombreux problèmes à cause de cette conversion donc nous avons décidé de ne pas convertir la valeur en cm mais de la laisser telle qu'elle afin que celle-ci soit plus facilement utilisable.

• Nous avons crée et utilisé un programme permettant à notre robot de tête de détecter les obstacles ainsi que de savoir de quel côté se trouve l'objet (plus à droite, à gauche, ou complètement devant). Grâce à cette information, le robot peut ensuite effectuer la manœuvre nécessaire qui va lui permettre d'éviter l'obstacle (tourner droite/gauche , marche arrière).

Vous pouvez voir une démonstration de ceci dans la vidéo suivante prise à la fin du jour 3 de notre projet.

Objectifs à réaliser pour la prochaine fois

Mettre en commun les deux parties sur lesquels nous avons travaillé. Ceci consiste à faire avancer ou arrêter un robot et que celui-ci communique cette information à une seconde carte Arduino Yùn.

Dans un second temps, nous aimerions avoir un second robot qui fonctionne (nous ne sommes pas sûrs à 100% que les autres robots soient opérationnels).

Jour 5

Qu'est ce qu'on voulait faire ?

• Faire avancer ou arrêter un robot tout en communiquant cette information à une deuxième carte Arduino. Celle-ci sera implanté sur un deuxième robot par la suite.
• Vérifier le bon fonctionnement d'un deuxième robot pour pouvoir l'utiliser par la suite.

Qu'est ce qu'on a fait?

Tests des nouveaux robots

Plusieurs autres robots sont disponibles dans les placards de notre école. Trois sont relativement identiques (même forme, deux roues motrices à l'avant et une roue pour stabiliser à l'arrière). Seul la carte motrice gérant notamment l'asservissement des roues du robot diffère selon le robot, cependant ceci ne devrait pas nous poser de problème pour faire fonctionner les robots. Un quatrième robot est mis à notre disposition, il est un petit peu différent de part sa conception cependant celui-ci est déjà monté et ne nécessite pas autant de travail que les autres robots. Une partie de notre groupe a donc commencé les tests sur un des deux "nouveaux" robots. Une fois ce robot effectif, nous avons commencé les tests sur le deuxième robot.

Problèmes rencontrés

Le programme que nous voulions tester était simple, nous voulions juste faire avancer et arrêter le robot afin de vérifier son bon fonctionnement. A ce stade ci un problème s'est posé car les deux roues ne tournaient pas à la même allure. Ce qui empêchait alors notre robot d'avancer de manière rectiligne. Après avoir essayer de trouver la source du problème, nous avons enfin compris d'où pouvais venir le problème. En effet lorsque le robot était alimenté avec la batterie portable, nous ne pouvions pas le faire avancer droit. Mais si nous l'alimentions à l'aide d'une alimentation fixe les roues tournaient enfin à la même vitesse (un très léger décalage minime entre les deux roues).

Communication entre un robot et une autre carte Arduino

Dans cette partie l'objectif était le suivant. Nous voulions réussir à faire avancer notre robot et pouvoir communiquer en Wi-fi l'état actuel du robot à une autre carte. C'est à dire que lorsque que l'on avance on envoi une requête HTML à notre carte serveur et celle-ci par exemple pourrait exécuter une action telle qu'allumer une de ses Leds pour vérifier la bonne transmission de l'information.

Comme nous l'avions déjà fait à la séance précédente nous avons pu communiquer des informations entre la carte du robot et l'autre carte Arduino. Ensuite l'étape suivante était d'envoyer depuis la deuxième carte (celle qui n'est pas implémentée sur un robot) un ordre d'avancer via Wi-fi à notre robot. Cette étape ci a été fonctionnelle pendant la première moitié de notre journée de travail cependant un problème de taille allait se poser par la suite.

Problèmes rencontrés

Lorsque nous avons voulu effectuer l'étape de la communication dans l'autre sens un problème est survenu. Il nous était alors impossible de faire avancer notre robot ET ensuite de communiquer via Wi-fi l'état de notre robot. Ces deux étapes qui marchaient parfaitement séparément ne pouvaient pas être combinées.

Après de nombreux essais et recherches sur des forums nous avons pu identifier la source du problème. En effet la communication Wi-fi (utilisant un bridge reliant le microcontrôleur et le microprocesseur) doit utiliser une ressource qui est la même que celle utilisée par la liaison Serial reliant la carte Arduino à la carte motrice de notre robot. C'est à dire que l'action d'avancer, et celle d'envoyer des données nécessitent toutes deux l'accès à une ressource qui ne peut pas être partagée. Nous avons alors pensé à allouer du temps pour que chaque partie du programme puisse utiliser la ressource mais nous ne savions pas comment forcer le bridge à perdre l'utilisation de la ressource en question.

Nous avons pensé essayer de contourner ce problème en utilisant un câble différent pour faire passer les ordres entre la carte Arduino et la carte motrice de notre robot. Nous voulions utiliser un câble micro-usb - RS232 (5V). Cependant aucun câble de ce type n'était présent dans l'école.

Objectifs à réaliser pour la prochaine fois

Nous aimerions régler ce problème de transmission entre la carte motrice et notre carte Arduino pour pouvoir ensuite effectuer nos tests entre notre robot et notre carte, puis entre nos différents robots vu que ceux-ci semblent opérationnels.

Jour 6

Qu'est ce qu'on voulait faire ?

Notre objectif principal est de trouver une solution au problème de communication entre les cartes ALORS QUE notre carte Arduino communique déjà avec notre carte motrice via une liaison TX/RX.

Qu'est ce qu'on a fait?

Comment résoudre notre problème?

Le problème de câble ne semble pas réalisable dans l'immédiat à cause d'un problème de matériel. Cependant après une discussion avec deux spécialistes Mr Bru et Mr Minot plusieurs solutions possibles ont été évoquées (qui ne nécessite pas de câble particulier). L'une d'entre elle, sur laquelle nous avons concentré nos efforts consiste à déplacer (au niveau logiciel) les pins sur lesquels la communication TX/RX s'effectue (pour nous permettre de libérer le bridge). Voici le bout de code qui nous permet d'affecter notre TX/RX aux pins que nous voulons (il suffit d'ajouter ces deux lignes de code):

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // Le premier paramètre correspond a la pin du TX, le deuxième au RX

Après utilisation et test de cette méthode nous avons effectivement pu à la fois avancer et envoyer l'état de notre robot sur l'autre carte arduino.

Communication entre deux robots

Maintenant que nous pouvons communiquer entre un robot et une carte, nous aimerions communiquer entre deux robots. C'est à dire de pouvoir faire avancer un robot, qu'il envoit son état à l'autre robot ("j'avance"), et que l'autre robot avance à son tour.

Voici une vidéo présentant cette étape de développement de notre projet. Nous voyons bien notre robot suiveur s'arrêter juste après que notre robot maître se stoppe (un petit temps de latence du à la transmission et au traitement est visible sur la vidéo).

Cependant nous avons remarqué un problème matériel relativement important. Nos robots ne roulaient pas droit alors que nous ne leur disions pas de tourner.

Réparation des roues du robot

Nous devions nous pencher sur ce problème de robots. Les roues arrières de nos deux robots semblaient être la source de ce problème. Après un changement de roues et un graissage de ces dernières les résultats obtenues furent bien meilleurs. Cependant la trajectoire de notre robot n'est pas totalement rectiligne ce qui ne nous permettrait pas de maitriser parfaitement notre trajectoire. Ceci est du au fait que les moteurs des roues ne tournent pas à la même vitesse.

Nous avons essayé de régler ceci en programmant deux vitesses différentes pour les deux roues de notre robot. Cette méthode fonctionne mais nous ne pensons pas qu'elle soit très viable pour la suite de notre projet.

Communication : Contenu des données à envoyer

Après avoir réussi à faire communiquer nos deux robots une question très délicate s'est posée.

Ce que l'on veut :

• Le maître détecte les obstacles, les évite et transmet les informations (ou ordres).
• L'esclave reçoit, traite et exécute l'instruction envoyée.

Ce que l'on sait :

• légère latence entre le moment ou l'on exécute une action sur le premier robot et celui ou elle sera exécutée sur le deuxième robot.
• Vitesse des robots constante (peut être différente entre les deux robot mais reste la même pour un robot durant l'exécution du programme).

Quel est le contenu (et non la forme) des informations à envoyer? Liste des actions que notre robot effectuera :

• Avancer/reculer.
• droite/gauche.
• Stop.

Après avoir réfléchi à plusieurs méthodes différentes nous avons envisagé une possibilité qui pourrait fonctionner. Nous aimerions en fait envoyer les informations à l'esclave en décalé. C'est à dire qu'on attendrai un certains temps avant que le maître dise à l'esclave de tourner par exemple. Comme ceci nous pourrions avoir l'esclave qui suit parfaitement le robot maître (il tournerai au même moment). Seul le moment ou le robot maître s’arrêtera définitivement pourrait être problématique car nous ne voudrions pas que l'esclave percute le robot maître. Cependant si nous connaissons le moment ou nous allons stopper notre application nous pouvons faire en sorte que l'esclave s’arrête a la bonne distance du maitre.

Une autre méthode a été étudiée pendant cette séance. En effet jusqu'à présent nous utilisons la méthode MOGO pour faire tourner les roues du robot. Mais il se trouve qu'il existe une méthode DIGO qui elle fait la même chose mais à laquelle nous pouvons dire roule sur telle ou telle distance. Donc nous pouvons fixer la distance sur laquelle nous voulons rouler (et non pas influer sur le temps pendant lequel nous voulons rouler). Ceci peut être un avantage et nous avons essayé de voir s'il était possible de récupérer la distance sur laquelle le robot a roulé (nous ne fixerions aucune distance mais nous aimerions la connaître).

Au final nous avons réussi à récupérer le nombre de Tics de chacun des moteurs du robot, c'est à dire que si nous connaissons le nombre de Tics par tour nous pouvons ensuite (en récupérant le nombre de Tics compté pendant le trajet d'un robot) en déduire la distance qu'il a parcouru.

Objectifs à réaliser pour la prochaine fois

Examiner la commande vel, qui permet de récupérer la vitesse de rotation d'un moteur, ceci pourrait permettre de contrôler la linéarité de la trajectoire en corrigeant le paramètre de commande en temps réel.

Jour 7

Qu'est ce qu'on voulait faire ?

N'ayant pas eu cours depuis une semaine nous avons effectué un point collectif concernant l'avancement de notre projet. Pendant celui-ci nous avons expliqué ou nous en sommes dans la confection de nos robots ainsi que quels étaient nos objectifs pour cette séance. Notamment le fait de vouloir calculer la distance parcouru par le robot en récupérant le nombre de tours que le moteur a effectuer pendant un certain temps. Nous avons évoqué à nouveau le problème que nous avons avec nos robots. Seul notre robot de tête est capable, pour le moment, d'effectuer une marche avant rectiligne. Nous avons donc pris la décision d'utiliser le robot chenille (ne possédant pas de roues mais des chenilles) qui lui avance de façon quasi-rectiligne (nous devons juste baisser un peu la puissance au niveau d'un moteur). Le troisième robot étant démonté nous avions comme objectif de l'assembler en choisissant au les deux moteurs ayant les performances les plus semblables possibles (deux parmi quatre disponible). Une équipe allait donc essayer de travailler sur le fait de contrôler la distance parcouru par le robot. Une autre allait monter le troisième robot, une dernière allait essayer de faire avancer le robot chenille tout droit de manière continue.

Qu'est ce qu'on a fait?

Construction du robot

Nous avons récupéré les 4 moteurs restants et n'étant pas utilisés par nos autres robots afin d'effectuer des tests sur ceux-ci. Nous les avons alimenté un à un afin de vérifier si certains moteurs étaient différents des autres (c'est à dire qu'ils ne tournent pas tous à la même vitesse). Ensuite nous avons ajouter ces moteurs sur notre robot, effectuer les branchements et vérifier que chacun des éléments était placé correctement. Cependant, nous n'arrivions pas à obtenir une trajectoire droite sur ce robot aussi. C'est pourquoi nous avons aussi utilisé pour ce robot la méthode de calibrage des roues utilisé par un autre de nos groupes de travail (et décrite ci-dessous).

Calibrage de la trajectoire

Pendant cette séance nous avons notamment réglé le problème de trajectoire de nos robots. Notre méthode consiste a ajuster à certains instants la vitesse d'une des deux roues du robot pour obtenir une trajectoire quasi-rectiligne sur de longue distance. Ce système nous permet de pouvoir continuer les tests sur nos robots sans avoir à remettre ceux-ci dans l'axe toutes les 2 secondes. Voici le résultat obtenu avec deux robots qui se suivent.

Récupération de la distance parcourue par les roues

Nous avons aussi notamment étudié le fait que nous pouvons à l'aide de la commande vel récupérer le nombre de tics effectué par le robot pendant un certain temps. Nous aimerions pouvoir travailler avec ces données pour transmettre de façon précise la distance parcourue par un robot avant de commencer une manœuvre par exemple. Ceci à pu être mis en place mais un problème subsiste quand au fait que pour l'instant nous n'arrivons pas à contrôler avec précision cette commande vel. Ceci sera peut être un problème à résoudre plus tard cependant nous avons soulevé d'autres problèmes que nous avons du étudier pendant la séance.

Point d'avancement

Une fois le test avec deux robots effectué, nous avons une nouvelle fois fait un point collectif quand aux tâches à réaliser dorénavant. Nous avons évoqué certaines tâches ou idées à réaliser durant cette réunion.

• Liaison Wi-Fi :

Deux problèmes se posent: comment diminuer la latence entre chaque robot? Installe-t-on un ordinateur intermédiaire pour diminuer cette latence?

• Faire tourner les robots de manière identique :

On peut même imaginer créer une chorégraphie à exécuter lorsque les robots tournent. Comme par exemple que le premier robot détecte un obstacles, effectue une figure en synchronisation totale avec l'autre robot (ceci est une idée évoquée par Monsieur BRU qui nous a expliqué que des alternatives à notre projet pourraient être trouvé, il faudrait juste qu'elles soient intéressantes d'un point de vue pédagogique.

• Récupérer la distance parcourue par les robots :

Nous aimerions pouvoir contrôler la distance parcourue par nos robots et pouvoir les communiquer entre eux.

• Tester le même programme avec nos trois robots :

Le problème rencontré lorsque l'on essaye ce même programme en essayant avec un robot "détecteur" et deux robots "suiveurs" est que la communication ne s'effectue pas assez bien entre les 3 robots.

Explication : La manière dont notre robot fonctionne (pour le moment) peut être expliqué (en pseudo code) de la manière suivante :

Tant que(1)
     lire Valeur Capteur();
     Si(obstacle Detecté())
     alors
          arreter();
          dire au robot1(arreter);   {Ici le problème est que on attend d'avoir la confirmation du robot 1 
                                      qu'il a bel et bien reçu le message avant de continuer la boucle}
          dire au robot2(arreter);   {On attend a nouveau la confirmation de la réception}
     fin si
     Si(pas d'obstacle détecté)
     alors
          avancer();
          dire au robot1(avancer);   {Ici le problème est que on attend d'avoir la confirmation du robot 1 
                                      qu'il a bel et bien reçu le message avant de continuer la boucle}
          dire au robot2(avancer);   {On attend a nouveau la confirmation de la réception}
     fin si
Fin Tant que

Le problème est que il existe, comme nous l'avions expliqué lors d'une précédente séance un temps de latence pour la communication Wi-fi entre deux robots. Ce qui veut dire que dans notre cas SI les trois robots sont arrêtés et que le premier ne détectant pas d'obstacle, avance et dis aux deux autres d'en faire de même, ALORS le temps que le robot va mettre à passer les ordres au robot sera du temps pendant lequel il ne contrôlera pas la valeur du capteur pour savoir si un obstacle est présent devant ou pas. Ceci à entrainé lors de notre essai un nombre de collision trop important de notre robot de tête.
De plus, un de nos robot suiveur était à nouveau incapable d'aller tout droit. Ceci est un nouveau problème sur lequel il va falloir nous pencher.

Réunion de fin de séance

En fin de séance un nouveau point d'avancement a été effectuer par l'ensemble de notre groupe afin de faire un point sur notre méthode de communication entre nos robots. Jusqu’à présent (voir Le schéma concernant notre méthode de communication du Jour 4) notre méthode de communication était fonctionnelle mais disposait de certains défauts notamment au niveau temps de communication. Comme expliqué dans le paragraphe précédent, notre méthode n'est pas réalisable avec 3 robots. C'est pourquoi nous désirerions changer de méthode pour en trouver une plus en adéquation avec nos attentes.

Voici la représentation d'une méthode qui pourrait peut être mieux fonctionner à laquelle nous avons pensé en fin de séance. Nous laissons une donnée présente sur le robot maître et c'est aux esclaves de récupérer l'information sur les deux robots esclaves.

Nous avons également évoqué l'idée d'utiliser la partie LINUX de notre carte Arduino Yùn.
En effet cette carte possède deux processeurs distincts. L'utilisation des deux processeurs de la carte (le premier Arduino - ATmega32u4', et le deuxième Linux - Atheros AR9331) pourrait nous permettre d'augmenter la vitesse de calcul de notre programme mais aussi de pouvoir effectuer plusieurs actions en même temps, ce qui supprimerait ainsi le problème évoqué précédemment.

Voici un tableau récapitulatif des principales caractéristiques des deux processeurs :

Lors de la prochaine séance nous aimerions pouvoir réussir a perfectionner notre méthode de communication entre robot pour qu'elle soit quasiment instantanée.

Jour 8

Qu'est ce qu'on voulait faire ?

Notre objectif de cette nouvelle matinée de travail était de régler les deux problèmes principaux évoqués la veille. A savoir le problème concernant la communication entre les robots (nous aimerions utiliser la partie LINUX de la carte si possible pour plus de performances). Il faut aussi régler le problème de direction des robots en utilisant les Tics des roues.

Ce que l'on a fait

Durant cette séance plusieurs problèmes se sont posé au niveau de la partie LINUX de notre projet, nous n'arrivions plus à faire les mises à jour de la carte Arduino pour installer certaines mises à jour dessus. Nous n'avons pas pu mettre en œuvre la communication inter-cartes via LINUX.

En ce qui concerne le réglage des roues (vérifier qu'elles aient bien de le même nombre de tours en mémoire à chaque instants) nous réussissions à récupérer le nombre de Tics effectués par la carte dans la console mais pas dans une variable que l'on pourrait exploiter par la suite.

Il nous a fallu effectuer plusieurs recherches pour pouvoir mettre à jour le processeur LINUX sur les cartes et nous avons pu mettre en place la connexion entre les parties LINUX des cartes. On écrit dans un fichier texte des instructions et le client se connecte à l'autre carte Arduino pour pouvoir récupérer ce fichier texte ainsi que les données présentes à l'intérieur.

Objectifs pour la prochaine séance

Nous devons aujourd'hui réaliser le code Arduino nous permettant, grâce à la partie Arduino, de lire un fichier texte sur un robot client (sur la partie LINUX du robot client à priori). Nous devons aussi finaliser la liaison Wi-fi entre les parties LINUX du robot.

Un de notre objectif serait de synchroniser nos robots et de leur faire réaliser les mêmes actions au même moment.

En parallèle nous voulons réussir à maîtriser la gestion des moteurs des robots pour pouvoir contrôler le nombre de tours fait par celui-ci. Ceci nous permettrait, comme dit précédemment de faire avancer nos robots de manière rectiligne en vérifiant régulièrement si ils ont effectué le même nombre de Tics moteur pendant un intervalle de temps donné.`

Jour 9

Qu'est ce qu'on voulait faire ?

Notre objectif de cette séance était de fiabiliser la liaison entre les deux cartes en passant par les processeurs LINUX plutôt que de tout faire grâce à la carte Arduino. Ceci nous permettrait de rendre notre programme beaucoup plus réactif aux changements d'états.

D'un autre coté nous voulons pouvoir lire et écrire dans un fichier texte a partir du processeur Arduino. Nous voulons aussi maîtriser les Tics des roues de notre robot pour nous permettre de les faire avancer droits.

Qu'est ce qu'on a fait?

En ce qui concerne la partie lecture/écriture dans un fichier nous arrivons à le faire parfaitement à partir du processeur LINUX mais pas Arduino, seul l'écriture a été effectuée pour le moment.

Côté Linux nous avons réussi à faire qu'un programme client écrit en python se connecte à un programme server et lise un fichier .txt en passant par une Socket connectant les deux programmes. Si l'on coupe notre programme serveur.

Ce qu'il nous reste à faire

Nous arrivons bientôt au terme de notre projet robotique. Il nous reste seulement une séance avant la soutenance finale. Notre unique objectif maintenant est de pouvoir montrer quelque chose de concret lors de cette présentation.

Quel que soit notre objectif (Faire "danser" les robots => Les robots effectuent les mêmes mouvements en même temps OU faire se suivre les robots => Les robots suivent tous le même parcours) nous devons pouvoir transmettre les données de manière instantanée grâce au microprocesseur Linux. Si nous arrivons à faire ceci entre notre séance du jour 9 et 10 nous pourrons probablement montrer quelque chose de concret lors de notre soutenance.

Jour 9 Bis

Certaines tâches ont pu être réaliser entre les deux séances ce qui nous permet de pouvoir maintenant effectuer une communication immédiate entre les deux cartes. Nous pouvons maintenant communiquer de manière quasi instantanée (quasi-invisible à l’œil nu).

Principe de la communication

• Une communication Wi-fi est établie entre les deux microcontrôleurs Linux de nos cartes.
• La partie Arduino de notre robot maître écrit dans un fichier texte enregistré sur notre carte.
• En continue, le robot maître va envoyer au robot esclave ce qui est écrit dans son fichier texte (ce qu'il fait comme mouvement).
• Le robot esclave écoute en permanence ce qu'il se passe sur son adresse IP.
• Si la donnée reçue est différente de la précédente (si l'ordre a changé) Alors...
• La partie Linux du robot esclave écrit la donnée dans un fichier texte.
• La partie Arduino du robot esclave lit la donnée et effectue l'action correspondante.

Ceci se déroule en continu et de manière si rapide que nous pouvons transmettre nos informations de manière quasi instantanée.

Voici notre schéma final résumant la communication entre nos deux robots :

Problème de Socket

Voici un problème que nous avons rencontré au niveau des Sockets mais que nous aovns réussi à résoudre. Lorsque l'on établie une communication entre deux cartes Arduino on va alors créer un socket qui va nous permettre de communiquer nos informations entre nos deux cartes.

Deux modes étaient alors possibles (cf Wikipédia : Sockets) :

• Le mode connecté (comparable à une communication téléphonique), utilisant le protocole TCP. Dans ce mode de communication, une connexion durable est établie entre les deux processus, de telle façon que l’adresse de destination n’est pas nécessaire à chaque envoi de données.

• Le mode non connecté (analogue à une communication par courrier), utilisant le protocole UDP. Ce mode nécessite l’adresse de destination à chaque envoi, et aucun accusé de réception n’est donné.

En résumé, au vue des résultats obtenus ainsi que le de la vitesse d'exécution des protocoles (UDP plus rapide et tout aussi adapté vu que nous n'avons pas forcément besoin d'effectuer une vérification des données vu qu'on les envoient en boucle) nous avons choisi de travailler à l'aide du protocole UDP, plus rapide et plus adapté car il nous permettait d'envoyer en boucle les données alors qu'avec TCP après un envoi nous ne pouvions plus rien envoyer.

Jour 10

Nous voilà enfin à notre dernière séance. Nous avons eu besoin de faire un point en début de séance pour nous répartir les différentes tâches de la matinée, entre rédaction du wiki, finalisation des codes robots ainsi que préparation de notre soutenance finale.

Voici la vidéo présentant la rapidité de communication entre nos robots après utilisation du mode de communication via les parties Linux de nos cartes.

Nous constatons bien que la communication et la synchronisation des mouvements de nos deux robots est immédiate. Seul un problème se pose à cette étape du projet, c'est que les robots ne tournent pas de la même manière. On peut voir sur la vidéo que même si les mouvements sont synchronisés. Un robot tourne néanmoins plus vite que l'autre.
Ce problème a été résolu lorsque nous nous rendons compte que les batteries n'étaient pas capables de délivrer la même puissance. Lorsque nous avons interverti les batteries sur nos robots, ce problème s'est quelque peu dissipé. Dans l'idéal nous aimerions avoir deux batteries assez puissante pour alimenter les capteurs et les moteurs des deux robots de manière identique (manque de puissance ==> les moteurs tournent moins vite).
Suite à cela, nous avons modifier notre code Arduino pour nous permettre d'effectuer certaines actions "spéciales" telles que faire un tour complet, un zig-zag etc...

Nous avons aussi voulu essayer de nous permettre de commander les mouvements du robot maître à l'aide d'un serveur Web.
Le principe de cette idée serait de pouvoir contrôler le robot maître à l'aide du clavier de notre ordinateur. Dans ce cas les capteurs seraient inutiles et nous pourrions, à l'aide des 4 flèches directionnelles, piloter notre robot maître, qui communiquerait toujours avec notre robot esclave. Ainsi nous pourrions piloter les deux robots à l'aide de notre clavier.

Présentation

Power Point

Fichier:Robotique-final.pptx