Robots suiveurs : Différence entre versions

De Learning Lab Environnements Connectés
Sauter à la navigation Sauter à la recherche
Ligne 164 : Ligne 164 :
  
 
Voici ci-dessous les deux premières configuration auxquelles nous avons tout d'abord pensé :
 
Voici ci-dessous les deux premières configuration auxquelles nous avons tout d'abord pensé :
[[Fichier:Image Robot2 Jour3.png|vignette|1er choix de configuration étudié pendant le Jour3]]
+
[[Fichier:Image Robot2 Jour3.png|cadre|centre|1er choix de configuration étudié pendant le Jour3]]
 
[[Fichier:Image robot Jour3.png|cadre|centre|Choix de configuration adopté pendant le Jour3]]
 
[[Fichier:Image robot Jour3.png|cadre|centre|Choix de configuration adopté pendant le Jour3]]
  

Version du 13 mai 2015 à 14:35

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 sera gérée par Arduino Yùn.

Projet

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 maitre avec détection les autres sans, le maitre transmet l’itinéraire à suivre aux autres robots.

Problème : si vitesse différente des robots ça 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 a 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 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 qu’on lui donnera.

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 maitre tournera il est possible que les esclaves détectent le robot maitre en pleine manœuvre comme un obstacle et qu’il commence à tourner, ce qui décalerai le parcours du robot esclave car il n’était pas censé 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 est 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 coté serveur
  • Un autre groupe travaillera sur le robot maitre (mise en marche et détection d’obstacles)
  • Un autre groupe travaillera sur la communication coté client
  • Mise en commun des méthodes mises en place pour le calcul de la distance entre le capteur et l’objet pour 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 ou les robots ferait une chorégraphie et se rejoindrait tous à un moment donné.
  • Programmer les robots pour que le robot maitre, 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 peut 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 Yun.

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, à et en suite à 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 Yun , 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è partie

Chaque groupe a d'abord lu la datasheet du composant. Puis nous avons connecter la 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è 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 quand à la réalisation du projet:

  • Les trois robot 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 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 a veiller que la distance avec le robot de devant soit correct (sinon ils s’adapteront -> Accélérer/freiner). Cela nécessité 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
  • Etablir la communication entre deux cartes 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 a 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

Aucuns point d'accès disponible et visible depuis notre salle de travail ne correspondait a 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 a 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'utilisé un des routeurs fournis par l'école (modèle D-Link DWL 2100 AP) et de le configurer nous même afin que nous puissions agir sur tout 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 a notre point d'accès (nos ordinateurs ainsi que nos cartes, ces dernières ce 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 commencer par réfléchir a comment notre robot de tête (robot serveur) allait pouvoir détecter nos obstacles. Nous devons être sûrs que notre robot pourra détecter un obstacle sur toute sa largeur (c'est a dire même au niveau des roues).

Ceci à permis de guider notre premier objectif de travail, qui a alors consisté a déterminer quel était expérimentalement le champ 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 a 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 champ de course. La question suivante que nous avons du 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 configuration auxquelles nous avons tout d'abord 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 quand à 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 utiliser des socles fournis par l'école nous permettant de visser les capteurs au robot de manière stable (voir photo ci-dessous).

PHOTO A RETOUCHER ET AJOUTER ICI.

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 a 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). Comme cela si notre objet est a 10cm ou qu'il n'y a pas d'objet notre robot avancera. Mais si l'objet est detecté a 9cm alors une manoeuvre 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, on arrive à envoyer une donnée par le serveur et qu'elle soit récupéré 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 dis dans le Paragraphe FAIRE LE LIEN VERS 3.3.3 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'accord 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é

Le hello world arrive à être récupéré par la deuxième carte et à être afficher pleinement sans -1.

Problèmes rencontrés

Les messages passent mais il y a un soucis dans la concaténation.

Pistes de travail

Deux stratégies d'approche sont possible:

  • Le robot principal envois ses données sur le serveur lorsqu’on lui demande et les deux autres lisent les données et adaptent leur trajectoire en fonction.

Objectifs à réaliser pour la prochaine fois