Challenge Robotique National

Robot Mobile

IUT de MulhouseGEII Mulhouselogo-uha

GEII 1A 2015-2016 MULHOUSE

Projet Robot Mobile

mulhouse_rotashneck

 

 



Membres du groupe:

 

  • BRULANT Antoine
  • DIAKHATE Matar
  • JUNCK Kevin
  • MARIAN JUDE Antony
  • SCHNELL Vincent
  • WAGNER Mickael

 

 

Présentation du sujet:

 

Dans le cadre du DUT Génie Électrique et Informatique Industrielle (G.E.I.I.) nous sommes amenés à réaliser un projet au courant du 2ème semestre. Cette année nous pouvions choisir entre 14 sujets différents. Nous avons choisis ce projet car nous nous sentons tous les 6 attirés par la robotique.

Notre projet est donc le suivant:

Nous devons concevoir et construire un robot qui  devra être indépendant, on peut donc dire qu’il sera plus ou moins doté d’une intelligence artificielle.

Le principe est simple, notre robot sera placé dans un coin du playground (dans ce cadre il s’agit d’une plate-forme utilisée pour tester un robot) de 8×8 mètres sur lequel seront placés des obstacles. Le but de la manœuvre étant que le robot atteigne le coin opposé du playground le plus rapidement possible et qu’une fois arrivé, il crève un ballon gonflable accroché sur son toit. Pour ce faire nous avons le droit d’utiliser tous les capteurs possibles et nous avons aussi le droit de placer jusqu’à 3 balises autours du ring pour pouvoir guider notre robot vers l’arrivée. Cependant un châssis nous est imposé.

 

Playground


 

 

Cahier des charges :

 

Bête à corne :

 

bete a corne

Diagramme Pieuvre :

 

Pieuvre_Projet

 

 

 

Pour résumer le diagramme pieuvre ci-dessus:

  • Le robot doit avant tout être capable de traiter les informations acquises à travers les capteurs et de se déplacer en fonction de celles-ci pour accéder à l’arrivée.

Cependant pour respecter les contraintes qui nous sont imposées le robot devra :

  • Traiter des informations grâce à un microcontrôleur (PIC 18F4520)
  • Être équipé de capteurs pour pouvoir détecter des obstacles
  • Être guidé par des balises
  • Remplir les conditions d’admission au concours robotique de Cachan
  • Être réalisable avec un budget de 200
  • Être terminé avant la présentation finale qui aura lieu fin Juin
  • Alimenté à partir d’une batterie 12V placée sur le robot
  • Posséder des moteurs et une interface de puissance pour pouvoir se déplacer

 

 


 

Gestion du projet:

Nous avons très rapidement compris qu’on pouvait découper notre projet en 3 parties afin de réaliser un robot conforme au normes imposées.

Ces 3 parties sont les suivantes:

  1. La motorisation du robot
  2. Détection d’obstacles
  3. Le guidage sur le playground

Nous sommes un groupe de 6 personnes,donc nous avons décider de nous diviser en 3 sous-groupes de 2 personnes afin de traiter toutes les parties simultanément.

1. Motorisation

 

Photo

Ainsi pour ce qui est de la partie motorisation du robot, Vincent et Matar ont utilisé des ponts en H dans le but de contrôler le sens de rotation du moteur ainsi que des sorties PWM (Pulse in With Modulation) afin de pouvoir gérer la vitesse de rotation des moteurs à l’aide d’une tension continue.

Pont en H

Test de la Motorisation

 

2. Détection

Pendant ce temps, Antony et Antoine se sont concentrés sur la détection des obstacles. Ils ont fini par conclure que l’outil le plus adapté pour repérer des obstacles est le capteur à ultrasons. Ainsi,il nous suffira d’envoyer des ondes dans la direction vers laquelle se déplace notre robot et de mesurer le temps que prendra l’onde pour revenir.Cela permettra de savoir à quelle distance se trouve l’obstacle et ainsi nous pourrons éviter tout obstacle qui se dressera devant notre robot.

capteur ultrason

Vidéo du fonctionnement de la partie Motorisation et Détection

 

3. Guidage

Mickaël et moi,nous avons travaillé sur cette 3ème partie. Après avoir évaluer toutes les solutions qui s’offraient à nous, nous avons conclu qu’utiliser une balise infra-rouge reste la meilleure option possible compte tenu de notre budget et de la durée du projet. Nous avons donc repris la balise qui a été fabriquée par le groupe de projet de l’année dernière et nous avons reprogrammé le microcontrôleur PIC18F4520 qui sera d’ailleur notre plate-forme de programmation tout au long du projet.

Bilan:

Actuellement,les 3 parties qui sont essentielles à la réalisation de notre robot sont terminées. Dans chacune des parties nous avons opté pour les méthodes les plus répandues pour la simple et bonne raison que ce sont les plus sûrs et les plus précises.

Pour ce qui est de la motorisation,nous  choisissons d’utiliser deux moteurs (un pour chaque roue) alimentés en PWM à l’aide d’un pont en H ainsi nous pouvons contrôler la vitesse et le sens de rotation.

Pour la détection d’obstacle,les émetteurs et récepteurs ultrasons ont été simple à contrôler et leurs précisions sont largement suffisantes pour subvenir à nos besoins ce qui justifie notre choix.

Pour le guidage,nous avons fait le choix d’utiliser des balises infrarouges car c’était la meilleure solution dans notre cas,compte tenu du fait que les autres solutions n’étaient pas réalisables avec notre budget ou étaient trop difficiles a mettre en œuvre.

 

Actuellement nous avons chacun fini nos parties mais nous n’avons pas encore pu mettre en commun pour créer un prototype. Cependant nous allons attaquer cette dernière phase du projet dans les jours à venir pour pouvoir finir notre projet dans les délais.

 

 

Conclusion:

Ce projet nous a aidé a mieux appréhender le travaille en équipe et nous a permis d’appliquer tous les cours théoriques que nous avons eu depuis le début de l’année.

Cependant nous nous sommes tous rendu compte que mener à termes un projet n’est pas toujours aussi facile que l’on le pensais. Nous avons dû faire beaucoup de recherches sur différents sujets pour pouvoir réaliser chacun nos parties. La partie programmation a été l’une des difficultés majeurs dans ce projet car nous n’avions jamais programmé un PIC auparavant.

Nous avons tous réalisé que lorsque nous rencontrons des problèmes,il est préférable de travailler tous ensemble pour résoudre le problème en vitesse et sans ambiguïté.

Au final nous sommes tous d’accord sur le fait que cette expérience est des plus enrichissantes car nous rencontrons de nombreux problèmes que nous serions souvent incapable de résoudre seuls, mais nous apprenons à les surmonter ensemble en équipe, ce qui nous permet de repousser nos limites et d’accélérer notre productivité


 

 

Portes_ouvertes_2016

 


Table traçante XY

Logo_IUT_Mulhouse                                              GEII

                                    capture_06232016_154752

Introduction

Etudiants de GEII première année, nous sommes arrivées a une période de l’année( mois de mars) que le département au projet d’étude et de réalisation de 1 ére année. C’est dans ce cadre là que plusieurs sujet de projets nous sont proposé. Libre aux étudiants de choisir sur quel projet ils vont se consacrer sur une période de 70 heures reparti en 4 semaines.

Dans notre cas, il s’agit du projet de la table traçante  XY.
prj 077

 

Read More


NAO sur Robotino

 

NAO se déplace

 

939397_10207861829137193_139388995_o

 

Résumé

 

Le département GEII de l’IUT de Mulhouse dispose de 4 robots humanoïdes NAO programmables qui sont capables de se déplacer en parfaite autonomie . Néanmoins, leur vitesse de marche reste très limitée. C’est pourquoi, il serait intéressant de pouvoir les asseoir sur un robot beaucoup plus mobile, un RoboTino, lui aussi à la disposition du département au nombre de 2. L’idée est donc de les rendre capables de réceptionner des informations transmises par le NAO afin de pouvoir amener celui-ci à bon port.

Une fois cette tâche établie, la finalité du projet serait de permettre au NAO d’accueillir et de guider des visiteurs au sein du bâtiment B grâce notamment au système de reconnaissance vocale du NAO et de ses différents capteurs.

Introduction

 

NAO est un robot humanoïde développé par Aldebaran Robotics, une start-up française basée à Paris, c’est un robot équipé de 14 à 25 degrés de liberté (=articulations) suivant les différents modèles proposés par la firme, ceux de l’IUT étant des modèles en ayant 25. Ce robot embarque un noyau linux (baptisé naoqi) ainsi que tout un panel de capteurs dont 4 capteurs ultrasons sur son torse pour l’évaluation des distances, 8 capteurs de pression, 2 caméras et 2 bumpers à ses pieds afin de détecter d’éventuels obstacles. Le tout pour un poids total de 4.8 kg et une hauteur de 58 cm. Il est surtout utilisé en laboratoire ou dans le domaine de l’enseignement comme c’est ici le cas.

En ce qui concerne son robot mobile, il s’agit d’un RoboTino développé par la firme Festo établie en Allemagne à Esslingen. C’est un robot programmable par PC, bardé de capteurs et capable de se déplacer en parfaite autonomie. Grâce à ses 3 moteurs et à ses roues suédoises, RoboTino peut se déplacer dans toutes les directions ainsi que tourner sur lui-même.

Il s’agit donc de notre projet du second semestre durant lequel nous avons travailler à faire communiquer les deux robots et rendre le tout fonctionnel.

Présentation du Sujet

 

Au cours de notre DUT GEII, nous sommes amenés lors du second semestre de notre première année à travailler sur un projet de notre choix parmi une dizaine de projets qui nous ont été proposés. Une fois le second semestre terminée, l’évaluation s’effectuera au cours d’une soutenance finale que nous avons eu le temps de préparer durant nos cours de conduite projet avec Monsieur ROTH. L’évaluation portera aussi sur notre esprit d’équipe, notre implication et le sérieux dont nous avons fait preuve au cours de toute la durée de notre projet.

Cahier des Charges

 

Préambule :

  • La société française Aldebaran Robotics, propose un robot humanoïde NAO autonome et programmable notamment destiné à des activités pédagogiques.
  • En 2008, la société lance une version academics de son robot afin de permettre son utilisation dans des laboratoires et dans des établissements d’enseignement tels que des universités
  • Le département GEII de l’IUT de Mulhouse possède ainsi 4 robots NAO au jour d’aujourd’hui.

Présentation :

  • Ils sont capables de recevoir et de guider des visiteurs potentiels à un endroit donné.
  • Les robots NAO sont donc des appareils capables de se déplacer de façon autonome au sein de leur environnement, mais leur vitesse de déplacement reste très limitée, restreignant ainsi grandement leur capacité d’accueil de visiteurs.
  • Le département GEII de l’IUT ayant aussi à sa disposition un robot mobile RoboTino capable de se déplacer en recevant des instructions au sein d’un réseau wifi, NAO doit pouvoir s’atteler à celui-ci et lui transmettre les bonnes informations pour arriver à destination.

Critères généraux :

  • L’assise de NAO sur le RoboTino doit être suffisamment stable pour assurer sa protection.
  • Mettre au point un dialogue commun entre les deux robots.
  • Une signalétique préalablement établie doit être mise en place au sein du bâtiment afin que NAO puisse s’orienter et donc transmettre les bonnes informations au robot mobile.

Critères de fonctionnement :

  • L’ensemble doit pouvoir se déplacer dans toutes les directions.
  • L’ensemble doit être capable de détecter et d’éviter un obstacle potentiel, que ce soit un objet ou une personne.
  • L’ensemble doit arriver à destination.

Critères techniques :

  • Prise en main du logiciel choregraphe et du langage python (NAO).
  • Prise en main du logiciel RoboTino view (Robot mobile).
  • Communication wifi entre les deux robots ou via des Entrées sorties + choix du routeur du robotino ou d’un routeur indépendant.
  • Utilisation de données UDP.

Bête à cornes:

 

Capture

Pieuvre:

 

Capture

Diagramme de Gantt

 

Capture

 

Développement

 

Nous pouvons distinguer plusieurs grandes étapes clés de notre projet, à savoir: (par ordre chronologique)

 

1°)La mise au point et la réalisation de l’assise:

Après avoir pensé à de multiples systèmes d’assise du NAO sur le Robotino, nous nous sommes décidé pour un système de « chaise » tout simplement, nos autres idées étant beaucoup plus complexes à réaliser et pas forcément plus efficaces. Parmi celles-ci, nous avons pensé à un socle surmonté d’une longue tige où fixer NAO debout dessus (solution pas vraiment stable), un système d’assise mais sans dossier avec un système de renne où NAO pourrait s’accrocher (plus ludique mais très instable elle aussi) ou encore un système d’escalier permettant à NAO de grimper de lui-même sur le robot mobile (solution difficile à mettre en oeuvre, risquée et sûrement très instable une fois de plus donc très vite abandonnée).

La solution de la chaise nous semblait donc être le meilleur choix.

 

12295005_10207861828897187_1779894414_o12422356_10207861828657181_397824911_o

 

2°)La prise en main des logiciels et du langage python:

Une fois la partie mécanique du projet résolue, nous avons commencé à nous initier à la programmation des deux robots puisque ce fût du matériel et un environnement de travail totalement nouveau pour nous. Nous nous sommes par la suite aussi intéressés aux bases du langages python nécessaire à la programmation de la mise en réseau des deux robots.

L’ensemble de cette période d’initiation a été opérée grâce notamment aux documents constructeurs et des divers tutos mis à notre disposition par nos professeurs tuteurs.

3°)Echanges de données UDP

Après avoir passer les quelques premières séances à nous approprier le projet et ses différents facteurs, nous avons pû commencer à nous attaquer au coeur même du sujet: la communication entre les deux robots.

Nous avons été aiguillé vers une utilisation de données UDP pour ce faire puisqu’il s’agit d’un des principaux protocoles de télé-communication au même titre que les données TCP, l’avantage des données UDP étant leur plus grande simplicité puisqu’elle n’implique pas de  » handshaking », cette simplicité qui à le défaut de ne pas garantir la bonne livraison du message envoyé.

C’est ici qu’intervient le langage python puisqu’il nous a permis de programmer un bloc vierge sur Choregraphe à l’origine de la communication entre les deux robots. En effet, ce bloc permet l’envoi de trames UDP du NAO à un serveur localisé sur le pc où le logiciel du robotino est lancé qui, lui, transmet ces trames au robotino afin de lui ordonner tel ou tel déplacement.

Pour être plus précis, nous avons récupérés grâce à un logiciel tiers (spyder) les codes générés par le robotino lors de chacun de ses déplacement (1 déplacement=1 code spécifique), nous avons ensuite fais correspondre chacun de ces codes à une instruction reconnue par le NAO (tout d’abord de type numérique puis de type vocal et enfin grâce au système de Nao Mark) à l’intérieur de ce bloc vierge sur l’interface Choregraphe propre au NAO.

 

Copie de nao mark code

 

 

 

Une fois cette étape établie, le reste de la programmation en python dans ce bloc permet l’envoi de ces codes sur un serveur que nous avons préalablement lancé et configuré sur RobotinoView.

 

tino1 - Copie

 

4°)Programmation de chacun des robots

Une fois la communication entre les deux robots établie, nous avons pu finaliser la programmation que nous avions esquissés de chacun de nos 2 robots puisqu’ils étaient jusqu’alors sommairement programmés afin de répondre à des ordres simples.

 

Notre programme RobotinoView:

 

Copie de tino1

 

Notre programme Choregraphe:

 

photo nao commande

 

Gestion de Projet

 

Notre chef de projet est Louis Spiesser et pour ce qui est  de la répartition des tâches, nous avons décidé de scinder l’équipe en deux:

  • Louis et Loïc ont été chargés de travailler sur NAO et son logiciel Choregraphe.
  • Luigi et Jean-Michel ont quant à eux été chargés de travailler sur le Robotino et son logiciel RobotinoView.

 

Ressources et bilan financier

 

Pour ce qui est des ressources utilisées, nous n’avons certes pas eu la nécessité de dépenser les 200 € mis à notre disposition mais nous avons cependant eu accès du matériel très couteux. En effet, nous avions à notre disposition 4 robots NAO valant 5000 € pièce ainsi qu’à deux robotino valant 8000 euros pièce sans compter la matière première et l’outillage fournis par l’IUT et nécessaire à la fabrication de notre assise.

 

Perspectives

 

Suite aux problèmes de portée wifi que nous avons rencontrés au cours de notre projet, nous avons été contraints de modifier la finalité de notre projet: A savoir, effectuer un itinéraire donné au sein de la salle B19, alors que notre perspective première était de pouvoir permettre à notre NAO de se déplacer au sein du bâtiment B voire même accueillir et présenter le bâtiment à des visiteurs potentiels.

Conclusion

 

Dans l’ensemble, notre projet s’est plus ou moins bien déroulé. En effet, nous avons eu pas mal de problèmes notamment au niveau du wifi comme expliqué précédemment mais aussi à d’autres niveau, principalement en ce qui concerne les Robotino puisque nous avons eu des problèmes de fusibles, de batterie et de clé wifi. Malgré cela, nous avons fini dans les temps tout en ayant progressé en programmation (Python) ou en réseau.

Au delà de cet approfondissement de nos connaissances en programmation et de notre initiation au réseau, ce projet nous a permis de développer un esprit d’équipe sur le long terme et d’effectuer un travail en autonomie sur une longue période.

En conclusion, malgré des hauts et des bas, ce fût un projet extrêmement intéressant malgré sa difficulté certaine et nous en tirons néanmoins un très bon souvenir.

 

Merci de nous avoir lu.

 

 

12499024_10207862073903312_1089619124_o

Jean-Michel, Loïc, Louis et Luigi