IMA4 2016/2017 P21 : Différence entre versions
(→Après vacances) |
(→Après vacances) |
||
Ligne 428 : | Ligne 428 : | ||
Peu de temps avant les vacances, suite à une discutions avec nos encadrants, on nous a demandé de passer de l'arduino Uno à l'arduino Mega. Tout le travail effectué jusqu'à ce moment là n'est évidemment pas perdu mais certaine tâche sur lesquelles nous avons travaillé durant de nombreuses heures n'ont plus d'utilités telles que le shift register puisque l'arduino mega possède un nombre de sortie assez important pour pouvoir contrôler les matrices de led, les capteurs et les relais sans avoir à l'utiliser. | Peu de temps avant les vacances, suite à une discutions avec nos encadrants, on nous a demandé de passer de l'arduino Uno à l'arduino Mega. Tout le travail effectué jusqu'à ce moment là n'est évidemment pas perdu mais certaine tâche sur lesquelles nous avons travaillé durant de nombreuses heures n'ont plus d'utilités telles que le shift register puisque l'arduino mega possède un nombre de sortie assez important pour pouvoir contrôler les matrices de led, les capteurs et les relais sans avoir à l'utiliser. | ||
+ | |||
+ | |||
Suite à cette nouvelle, j'ai alors changer certain réglage mais un problème pour charger le programme sur l'arduino est arrivé. Nous avons eu beaucoup de mal à régler ce soucis. Après plusieurs heures passer pour résoudre ce soucis, nous avons pu reprendre la programmation. Nous n'avions à ce moment la plus besoin du shift register, juste le besoin de contrôler les 10 Pins directement. Nous avons pu tester le code avec une matrice Arduino et le résultat était concluant, on pouvait directement gérer depuis l'ordinateur quel matrice serait affiché selon la machine choisit. | Suite à cette nouvelle, j'ai alors changer certain réglage mais un problème pour charger le programme sur l'arduino est arrivé. Nous avons eu beaucoup de mal à régler ce soucis. Après plusieurs heures passer pour résoudre ce soucis, nous avons pu reprendre la programmation. Nous n'avions à ce moment la plus besoin du shift register, juste le besoin de contrôler les 10 Pins directement. Nous avons pu tester le code avec une matrice Arduino et le résultat était concluant, on pouvait directement gérer depuis l'ordinateur quel matrice serait affiché selon la machine choisit. | ||
+ | |||
+ | |||
Une fois la gestion d'affichage de machine totalement finit, nous avons pu enchaîner avec la simulation des différents état des machines, et des actions que celles ci font. Cette partie n'est pas totalement fini, 3 machines sur 4 sont actuellement. La partie informatique pour gérer la dernière machine n'est pas très compliqué mais demande d'avoir bien compris le rôle de celle ci. | Une fois la gestion d'affichage de machine totalement finit, nous avons pu enchaîner avec la simulation des différents état des machines, et des actions que celles ci font. Cette partie n'est pas totalement fini, 3 machines sur 4 sont actuellement. La partie informatique pour gérer la dernière machine n'est pas très compliqué mais demande d'avoir bien compris le rôle de celle ci. | ||
+ | |||
+ | |||
Une fois tout ceci terminé, nous avons fini la partie communication avec l'arduino pour faire quelque chose de clair et facile d'utilisation. | Une fois tout ceci terminé, nous avons fini la partie communication avec l'arduino pour faire quelque chose de clair et facile d'utilisation. | ||
[[Fichier:lienfinal.jpg|500px|thumb|center|Figure 11 : Interface graphique] | [[Fichier:lienfinal.jpg|500px|thumb|center|Figure 11 : Interface graphique] |
Version du 6 mai 2017 à 14:06
Sommaire
Cahier des charges
Présentation générale du projet
Chaque année se déroule la RoboCup, compétition internationale de robotique, et l’Association de Robotique de Polytech Lille a pour but principal de participer à celle-ci, dans la Logistics League.
Le but de la ligue est de trouver des solutions robustes pour l’ajout de robots dans un environnement industriel. Bien entendu, cet environnement est simplifié par l’usage de machines MPS (Modular Production System) de Festo. 4 types de MPS sont utilisés pour cette compétition :
- Base Station.
- Delivery Station.
- Ring Station.
- Cap Station.
Contexte
Pour raison budgétaire, une machine complète coûtant environ 6000€, nous aimerions développer une MPS 4-en-1 permettant de simuler des accostages sur tous les types de machines. Un accostage consiste en :
- approche de la machine via laser ou AR TAG (vision) ;
- prise ou dépose d’un objet ;
- détection de feux tricolores pour reconnaissance type machine (phase d’exploration) et état (phase de production).
Nous allons donc essayer de développer une machine MPS 4-en-1 qui permettra à l'association de robotic de Polytech'Lille de s’entraîner dans des conditions s'approchant de celles de la compétition. Cela permettra de pouvoir tester l’interaction robot-machine qui n'est pas possible avec la simulation.
Objectif du projet
Les objectifs de notre projet sont les suivants:
- Faire passer la station créée pour n'importe quel type de machine (BS, DS, RS et CS) au yeux de la RefereeBox et du robot.
- Etre capable de répondre à la Refereebox depuis la station.
- Etre capable de simuler le rôle de chaque station : partie électronique (tapis roulant , capteur, feu ...).
- Créer une interface homme-machine permettant d'effectuer les actions non faites par notre station.
Description du projet
Nous avons pour but de d'automatiser une station MPS capable de simuler le rôle de 4 stations MPS différentes que l'on peut trouver lors de la compétition Robocup. Lorsqu'un robot s'approche d'une station, il la reconnait grâce à un QRcode. Nous allons donc devoir gérer le fait de faire varier le QRcode présent sur la machine MPS dans l'optique de la faire passer pour le type de machine voulu par la RefBox. Nous allons aussi devoir gérer la communication entre notre machine et la RefereeBox. Notre machine sera autonome et devra donc être programmée pour répondre à ces besoins.
Choix techniques : matériel et logiciel
Pour réaliser notre projet, nous avons besoin du matériel suivant:
- Arduino uno avec module WIFI.
- Tapis roulant ( moteur 404.603 : 24v ; 3,1A )
- Feu tricolore ( 5924-00 signal tower : 24v , 1A )
- Capteur de présence
- Capteur photoélectrique
- Un servomoteur + barrière ( blocage des composants au milieu du tapis roulant)
- Partie électronique de puissance pour faire le lien arduino -> partie mécanique ( 4 relais statiques )
- Un moyen d'afficher 4 QRcodes différents sur le coté de la machine MPS avec une qualité suffisante. ( 2 démux + 2 expandeur I2C + 50 led blanches + 10 resistances 230 ohm) sur matrice faite nous même pour avoir la bonne taille + boitier led pour créer un AR-code propre
- 2 nappes pour amener les pins de l'arduino jusqu'aux matrices led sur le coté de la machine
- 4 connecteurs carte à carte
Calendrier prévisionnel
Liste des tâches à effectuer
Les tâches à effectuer sont les suivantes :
- Électronique de puissance : Création du circuit (Schematic)
- Électronique de puissance : Réalisation de la carte (PCB et assemblage)
- Électronique de puissance : Tests de la carte
- Réseau : commande réseau pour communiquer avec la RefereeBox
- Réseau : protocole
- Informatique : programmation pour simuler plusieurs états de fonctionnements de la machine (BS, DS, RS CS)
Calendrier
Avant le 19/12/16 - Élaboration du Cahier des charges en complétant le Wiki
Avant fin Janvier - Effectuer une liste du matériel nécessaire pour le projet
Répartition sur le S8 - 120h X 2 : Conception de la carte (50h) / Tests de la carte (10h) / Réseau (100h) / Informatique (100h)
Feuille d'heures
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total | ||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cahier des charges | 5h | 4h | ||||||||||||
Recherche de solutions | 10h | |||||||||||||
Wiki | 1h | |||||||||||||
Conception schéma électronique | ||||||||||||||
Tutoriels C++ | ||||||||||||||
Documentation technique | ||||||||||||||
Choix des composants | ||||||||||||||
Conception sur Altium | ||||||||||||||
Programmation Leds | ||||||||||||||
Programmation Shift Register | ||||||||||||||
Programmation générale | ||||||||||||||
Conception pièce 3D | ||||||||||||||
Changement du schéma électrique | ||||||||||||||
Partie physique | ||||||||||||||
Réunions avec nos tuteurs | 2h |
Avancement du Projet
Jeu 8/12/16 - Rendez-vous de présentation du projet avec les encadrants.
Jeu 15/12/16 - Rendez-vous pour définir le cahier des charges avec les encadrants.
Semaine 1
Nous avons commencé par représenter les différentes parties de la MPS avec le placement des composants sans entrer dans les détails.
Sur le côté, de part et d'autre de la machine, nous allons trouver la partie d'affichage d'AR-code. Cette partie sera reliée à la machine à l'aide d'une nappe.
Sur le dessus de la machine, nous allons trouver la plus part des composants. C'est-à-dire, le tapis roulant, les capteurs, le feu etc. On peut y voir une batterie qui ne sera pas gérée pour l'instant.
Lors de cette première séance de projet, nous recherchions différentes solutions à notre problème, le problème étant la reproduction de différents modèles des AR-Codes. Ainsi, nous avions pensé à différentes solutions.
La première étant de mettre deux tablettes électronique pour ensuite changer les différentes images des AR-Codes, nous avions pensé à manipuler ces tablettes à l'aide de l'arduino. Mais cette solution n'a pas été retenu car nous n'avions pas le budget pour réaliser notre projet avec cette méthode.
Dans un second temps, notre solution était d'acheter 2 matrices de led pour les contrôler directement depuis l'arduino mais nous avons rencontré quelques problèmes. Tout d'abord nous avons besoin d'au minimum, une matrice 5*5. Il est facile de trouver une matrice de cette taille mais il faut prendre en compte que le robot doit reconnaître l'AR-code. Les matrices vendues dans le commerce sont faites de led très serrées ce qui ne permet pas au robot de reconnaître le code. Cette solution, bien que moins coûteuse, ne peut pas non plus être utilisée.
La dernière solution étant de faire nous même la matrice de led ce qui nous permet de mettre un écart entre chaque led. De plus, on pourra créér à l'imprimante 3D un support permettant de séparer chaque led pour obtenir des carrés bien net. On pourra mettre sur ce support un plexiglace ou tout autre composant opaque.
Voici un schéma ci-dessous résumant ce que nous venons d'expliquer.Semaine 2
Nous avons commencé à réfléchir à toute la partie électronique de puissance qui nous permettra de pouvoir contrôler les composants. Ainsi, nous obtenons le schéma électrique suivant:
Pour faire cela, nous avons d'abord besoin de faire des recherches sur les composants à forte puissance que nous allons contrôler, c'est-à-dire le moteur pour le tapis roulant et le feu tricolore.
Tout d'abord, nous avons commencé à faire des recherches sur le moteur 404.603 permettant de mettre en mouvement le tapis roulant. Ce moteur a besoin d'être alimenté à hauteur de 24V avec un courant optimale de 1.25A. Nous avons ensuite fait des recherches sur le feu tricolore que nous allons utiliser pour permettre au robot de détecter l'état de la machine. Ce feu, comme le moteur, doit être alimenté avec du 24V et a besoin de 1A.
Notre idée initiale étant de tout gérer directement avec l'arduino tombe ici à l'eau car il est impossible de générer de tel courant et tension. Après avoir fait quelques recherches pour la partie alimentation des deux composants ci-dessus, nous avons en accord avec nos encadrants, pris la liberté d'alimenter le moteur et le feu avec une alimentation externe ( celle d'une paillasse de tp permettant de sortir du 24V très simplement).
Ayant maintenant une alimentation continue nous permettant d'alimenter nos 2 composants, nous avons à mettre en relation notre partie commande, qui est l'arduino et la partie alimentation des composants à forte consommation. Pour faire ceci, nous avons décidé d'utiliser des relais statiques facilement commandable avec les sorties arduino.
Semaine 3
Durant cette semaine, nous savions qu'il fallait commencer à se familiariser avec le langage de programmation C++ car nous allions devoir l'utiliser lors de notre projet pour la communication avec la RefereeBox qui est l'arbitre validant la fabrication demandée par elle même. Pour avoir de bonnes bases pour la suite de notre projets, nous avons réalisé quelques tutoriels en C++.
Une fois cette familiarisation avec ce langage de programmation, nous avions décidé de réfléchir à la façon dont nous allions programmer notre matrice de leds. Nous avons donc choisi de coder en binaire toutes les combinaisons des AR-Codes pour pouvoir coder la matrice que nous réaliserons prochainement. Nous avons donc dû faire plusieurs choix cette semaine, nous avons décidé d'utiliser le logiciel Altium Designer pour la partie électronique. Puis nous avons choisi de coder en langage C notre partie programmation de l'Arduino. De plus, nous allons mettre un espacement de un centimètre entre chaque led lors de la réalisation du routage de notre matrice de led.
Semaine 4
Lors de cette semaine, nous avons réalisé de nombreuses étude de documentations pour vérifier une dernière fois notre liste de composants. Une fois ce travail effectué nous sommes allés nous entretenir avec nos encadrants pour savoir si notre solution était toujours réalisable. Après cette rencontre avec nos encadrants, nous avons décidés de bien organiser notre travail et il s'avère que trois grands axes se sont dégagés :
- Gestion de la matrice de leds
- Gestion du feu tricolore
- Gestion du convoyeur
Nous avions déjà décidé de commencer à travailler sur la partie de la gestion de la matrice de leds, car nous savions que cela serai le travail le plus conséquent de notre projet. Dans cette partie de notre travail, il faut réaliser deux cartes de matrices de leds, et une carte de commande connectée à notre Arduino. De plus, nous allions devoir simuler les machines permettant de réaliser certaines tâches spécifique à l'aide de nos différents AR-codes.
Ensuite concernant la gestion du feu, nous allons utiliser trois relais pour pouvoir gérer les différentes couleurs du feu tricolore. Puis dans la partie de la gestion du convoyeur, nous allons utiliser deux relais pour commander la partie avant et arrière et trois capteurs de présences un premier en début de course, un second en milieu de course et un dernier en fin de course.
Voici la liste de composants que nous avions donnés à nos encadrants :
Pour la partie informatique, nous avons commencé à travailler sur l'arduino. Nous avons pris le choix de gérer, pour l'instant, le choix de la machine à simuler directement via un terminal. Pour faire ceci, nous avons à mettre en place une connexion entre le pc et l'arduino. La première étape sera donc faire la liaison série. Elle sera unidirectionnelle puisque nous n'avons rien à transmettre au pc. Cette partie la est en développement.
Semaine 5
Durant cette semaine, nous avons commencé à réaliser les schématics des matrices de leds à l'aide du logiciel Altium designer pour ne pas prendre de retard en attendant nos composants.
Puis, nous avons continué notre travail de cette semaine sur un site de simulation d'arduino pour pouvoir commencer à travailler avec des leds.
Au niveau de la partie liaison série, nous sommes arrivé au point où nous pouvons communiquer directement avec l'arduino depuis un terminal. Nous avons testé le programme en simulant des ordres d'allumages de led, il n'y a pas eu de soucis particulier. La partie suivante sera de géré l'expandeur avec le bus SDA et SCL. Cependant, une alerte nous a été émis à propos de l'intensité de chaque LED qui pourrait varier selon le nombre de LED à allumer à la sortie de l'expandeur. Nous allons donc vérifier cette partie là avant de faire le programme.
Semaine 6
Après avoir réfléchi au problème d'intensité des LED, la solution que nous avons retenu est d'allumer une LED à la fois. Nous avons aussi pris la liberté de changer l'expandeur par un Shift Register qui est plus simple d'utilisation pour la même rendu (dans notre cas).
Puis nous avons réalisé le routage de notre carte comme nous pouvons le voir dans la capture d'écran suivante. Il fallait bien vérifier les différentes contraintes que nous voulions c'est-à-dire 1 cm entre chaque led ou encore les dimensions de la carte. Ensuite, nous avons vérifié les différentes tailles pour nos perçages.
Semaine 7
Concernant la partie informatique, nous avons essentiellement travaillé sur le Shift Register qui est maintenant fini, cependant, une simple erreur de codage que nous n'avions pas remarqué au début nous à fait perdre un bon nombre d'heure. Nous sommes revenu sur la liaison série puisque la 1ère version était bloquante dans le programme, en effet, elle bloquait le programme tant que rien n'arrivait sur le port RX. Nous essayons donc de résoudre ce problème pour le moment. De plus après avoir rencontré nos tuteurs, il s'est avéré qu'en vérifiant notre schéma électronique de base ils ont remarqué que nous devions retravailler sur notre schéma globale car il n'y avait pas de sécurité électrique, nous devions donc rechercher une solution assez rapide c'est pourquoi cette semaine nous avons dû étudier plusieurs datasheet pour ne pas se tromper lors de nos futurs calibrages de résistances par exemple.
Semaine 8
Nous avons, pour la partie informatique, rectifié la liaison série qui n'est plus bloquante. Cette partie la nous permet maintenant d'avoir toutes nos fonctions essentielles au programme. Le reste du travail est simulé chaque sorte de machine. Il ne devrait pas y avoir de problème majeur pour cette partie car elle utilise que des fonctions déjà testées. On nous a demandé de travaillé sur l'interface qui permet de communiquer avec l'arduino pour pouvoir choisir le mode. Nous avons donc pris le temps de faire une interface facile d'utilisation et bien expliqué. Cette interface n'est pour l'instant pas définitif mais elle est très proche du rendu finale.
Semaine 9
Lors de cette semaine, nous sommes allés dans la salle de l'ARPL pour commencer la phase de la partie physique de la MPS c'est-à-dire qu'il fallait placer nos différentes parties sur notre MPS (convoyeur, barrières et le feu). Dans un premier temps, nous avons eu un premier problème pour placer notre feu entre deux rails, les fils de l'alimentation électrique bloquais lorsque nous voulions serré le feu. nous avons alors décidé de percer à la base du feu pour faire passer les fils dedans ce qui a favorisé sa pose.
Nous devions aussi mettre des barrières sur le convoyeur mais il nous manquait quelques pièces c'est pourquoi nous avons pris la décision suivante, réaliser les pièces en 3D. Nous avons donc utilisé le logiciel Onshape et avons réalisé la conception de la pièce suivante.
Le choix de réalisé certaines pièces à l'imprimante 3D plutôt que d'autre a été pris selon la facilité de trouver certain composants et le nombre de composant dont nous avons besoin. ( Et aussi bien évidemment la complexité de la pièce étant donné que nous avons qu'une formation très trivial en matière de CAO ).
Semaine 10
Pendant cette semaine, nous sommes allés imprimer nos pièces 3D, nous avons alors testé nos pièces et elles sont bien fonctionnelles. Puis nous avons travailler sur le convoyeur, notre câblage électrique était bon nous avions bien les leds du capteur qui s'allumaient lorsque nous approchions un objet. Nous avons ajouté un code qui compilé mais lorsque nous voulions recevoir les valeur du capteur nous ne les recevions pas. Nous allons donc essayer de régler ce problème assez rapidement.
Après vacances
Peu de temps avant les vacances, suite à une discutions avec nos encadrants, on nous a demandé de passer de l'arduino Uno à l'arduino Mega. Tout le travail effectué jusqu'à ce moment là n'est évidemment pas perdu mais certaine tâche sur lesquelles nous avons travaillé durant de nombreuses heures n'ont plus d'utilités telles que le shift register puisque l'arduino mega possède un nombre de sortie assez important pour pouvoir contrôler les matrices de led, les capteurs et les relais sans avoir à l'utiliser.
Suite à cette nouvelle, j'ai alors changer certain réglage mais un problème pour charger le programme sur l'arduino est arrivé. Nous avons eu beaucoup de mal à régler ce soucis. Après plusieurs heures passer pour résoudre ce soucis, nous avons pu reprendre la programmation. Nous n'avions à ce moment la plus besoin du shift register, juste le besoin de contrôler les 10 Pins directement. Nous avons pu tester le code avec une matrice Arduino et le résultat était concluant, on pouvait directement gérer depuis l'ordinateur quel matrice serait affiché selon la machine choisit.
Une fois la gestion d'affichage de machine totalement finit, nous avons pu enchaîner avec la simulation des différents état des machines, et des actions que celles ci font. Cette partie n'est pas totalement fini, 3 machines sur 4 sont actuellement. La partie informatique pour gérer la dernière machine n'est pas très compliqué mais demande d'avoir bien compris le rôle de celle ci.
Une fois tout ceci terminé, nous avons fini la partie communication avec l'arduino pour faire quelque chose de clair et facile d'utilisation.
[[Fichier:lienfinal.jpg|500px|thumb|center|Figure 11 : Interface graphique]