Le but de ce projet est de réaliser la construction et la programmation d’un robot Poppy. Ce dernier devra exécuter des mouvements basiques tels que : lever les bras, marcher, s’accroupir… Pour cela, la partie mécanique sera traitée par deux étudiants de Génie Mécanique (GMP). Elle consiste à la création de supports de maintien pour des batteries et à réadapter le centre d’équilibre du robot. En outre, la partie électrique sera traitée par trois étudiants de Génie Electrique (GEII). Elle consiste à la programmation du robot qui sera faite en langage Python via le notebook disponible sur l’interface web du robot. De plus, un circuit de batteries sera inséré dans le robot pour assurer une alimentation autonome de ce dernier.
Nos ambitions
Nous avons constaté lors de la construction du robot que le point d’équilibre de ce dernier n’est pas bien centré et donc il ne peut marcher tout seul sans tomber. De plus, avec son alimentation filaire sur secteur, le câble de liaison crée une instabilité supplémentaire. Nous avons donc l’ambition de lui permettre de se déplacer de manière autonome (c’est-à-dire de lui modifier son point d’équilibre afin qu’il puisse marcher sans accompagnateur et de lui implanter des batteries dans les jambes pour lui permettre de s’alimenter sans être connecté au réseau).
Notre équipe se fixe donc plusieurs objectifs mettant en lien diverses activités liant les domaines mécaniques, électriques et encore de la programmation.
Composition de l’équipe et le rôle de chacun
Nous sommes une équipe de 5 étudiants tous en formation apprentissage inscrits à l’IUT de Mulhouse. Elle se compose :
-2 GMP (Génie Mécanique et Productique) qui s’occupent de la partie conception/assemblage et de l’étude de l’implantation des batteries dans le robot et de la gestion du nouvel équilibrage de celui-ci.
-3 GEII (Génie Electrique et Informatique Industrielle) qui s’occupent de la partie programmation/codage et de la configuration des servomoteurs. Ainsi que de l’étude de l’alimentation du robot avec des batteries et prévoir le rechargement de celles-ci.
Bien entendu, il est évident que pour une meilleure progression du projet, la coopération est primordiale. La répartition des activités est variée en fonction des spécialités GEII et GMP des membres du groupe afin de garantir une certaine polyvalence et d’acquérir une expérience et des compétences pour chacun.
Nous avons précisé les activités réalisés ainsi que les ambitions futures dans le suivi d’avancement : Suivi d’avancement 27avril
Les GMP ont rendu un rapport vous permettant d’en savoir un peu plus sur leur activités : Rapport GMP
Caractéristiques du robot
Les caractéristiques principales du robot sont les suivantes:
Alimentation et interfaces de programmation:
– Alimentation: une moyenne de 13V
-Programmation: langage Python
-Interface: programmation via le notebook disponible sur l’interface web du robot
Caractéristiques principales du robot:
-Hauteur: 83 cm
-Poids: 3,5 kg
-Systèmes embarqués : Odroid XU4 avec Ubuntu 14.04
-25 moteurs
-Caméra HD et à grande profondeur de champ.
Cahier des charges
-Le montage du robot devra être exécuté selon les critères de conception indiqués par le constructeur dans la documentation technique fournie sur internet.
-La nouvelle structure des jambes du robot devra permettre l’amélioration de son centre de gravité.
-Une alimentation autonome devra être conçue et appropriée pour alimenter le robot.
-La programmation du robot devra être fait en langage Python via le notebook disponible sur l’interface web du robot.
2. Analyse fonctionnelle
II- Réalisation et programmation du robot Poppy
1.Assemblage du robot
Le montage du robot a été fait par l’ensemble de l’équipe du projet.
Ayant reçu le robot en pièces détachées, l’assemblage de ce dernier à pu se faire à l’aide de vidéos tutorielles trouvées sur YouTube (le lien dirige vers la chaîne de Matthieu Lapeyre, sa chaîne présente clairement et simplement toutes les vidéos nécessaires au montage du robot étapes par étapes : https://www.youtube.com/user/bizounours94/videos).
Lors du montage du robot il était impératif de suivre les recommandations de montage pour minimiser les problèmes liés aux moteurs. En effet, pendant cette période, nous avions aussi par la même occasion configuré les moteurs pour leur imposer une position initiale.
Robot en pièces détachées Robot assemblé
Lors de l’assemblage, nous devions faire attention à aligner le point du support moteur et le point sur l’axe du servomoteur. Si cela n’était pas respecté, la position zéro du moteur n’aurait pas été cohérente avec l’articulation du robot.
L’adressage des Dynamixel a été effectué sur Herborist pour les configurer et ainsi leur donner une position zéro et une adresse unique pour les différencier.
2.Programmation
La programmation du robot a été faite en langage python. De plus, les instructions ont été saisies via le notebook disponible sur l’interface web du robot.
Voici l’interface web du robot:
Le Robot est connecté sur le réseau en wifi, puis l’accès se fait via le logiciel Putty grâce à une connexion SSH.
Voici l’interface du logiciel Putty:
Position initiale
Sans un premier temps, nous avons codé les positions initiales du robot grâce à la fonction: set_goal_position({numéro du moteur: angle})
Position actuelle
Nous avons ensuite codé la fonction: get_present_position(dxl_io.scan([numéro du moteur]))
Cette fonction permet de connaître la position actuelle du moteur, et l’angle auquel il est référencé.
Nous pouvons voir tous les angles des moteurs à un moment T, qui sont représentés sur l’interface du logiciel Putty.
Positions « garde à vous » et « Accroupi »
Ces deux instructions lient plusieurs mouvements de plusieurs parties du corps.
Pour rendre les mouvements plus fluides et moins brutales, nous utilisons des boucles While, qui permettent un changement d’angle progressif. (le moteur bouge de 1° à chaque tour de boucle)
Les instructions à la fin du code servent à exécuter les différentes fonctions du programme.
3. Alimentation autonome
Pour créer une alimentation autonome, nous avons opté pour des batteries lithium-ion 18650. Celles-ci présentent un faible encombrement et leur coût est peu élevé.
Caractéristiques des batteries lithium-ion 18650 :
Nous avons branché les batteries de façon à avoir une alimentation d’environs 5A et ayant une tension d’environ 14V. Nous avons opté pour un régulateur de charge qui permettra l’alimentation du robot et la recharge des batteries.
Ce régulateur comme son nom l’indique va permettre de réguler la charge entre les 6 batteries ( 2×3 paires) qui composent une jambe.
Schéma électrique du régulateur :
Nous avons décidé d’intégrer les batteries de la manière suivante :
Par la suite, nous avons implanté le circuit de batteries dans les jambes du robot imprimées par les étudiants GMP.
III- Bilan du projet
Les difficultés rencontrées
Le projet a connu plusieurs retards et problèmes, de ce fait, nous n’avons pas eu l’opportunité de terminer le projet par manque de temps.
Les problèmes sont apparus durant les toutes premières séances du projet car le robot n’était pas encore livré. Nous avions donc uniquement les documentations trouvées sur internet (nombreuses et parfois incorrectes) pour débuter. Néanmoins, nous avons pu tirer quelques informations utiles tels que les 26 degrés de liberté (à titre de comparaison, le robot NAO en a 25), ainsi que de récupérer des modélisations du robot (CATIA 3D, Solidworks…) qui ont pu servir aux GMP.
De plus, le projet a été une découverte pour l’ensemble de notre groupe ainsi que pour le corps enseignant. Le système d’exploitation Linux ainsi que le codage en python étant nouveaux (ou vague) pour les membres du groupe, il était donc prévisible que le groupe connaisse des difficultés sur le projet.
Nous n’allons pas lister tous les problèmes que nous avons pu rencontrer car ces derniers sont cités plus haut dans le tableau d’avancement.
Résultats obtenus
A la fin de l’année, le montage du robot à pu être réalisé (hormis l’assemblage final de la tête, du au besoin d’accès de la carte pour la programmation du robot). Les nouvelles jambes du robot (avec leurs supports intégrés) ont pu être imprimées avec l’insertion des batteries dans ces dernières.
Pour la programmation, nous avons codé des mouvements de base tout en lui assurant une bonne stabilité. Malheureusement nous n’avons pas eu le temps de lui permettre marcher (le code étant très complexe à réaliser, car même le constructeur n’a pas pu nous le fournir).
Objectifs réalisés
√ -Montage du robot et vérification du bon fonctionnement des moteurs via herborist
√ -Réaliser la connexion robot/PC via le réseau de l’uha par ethernet et ainsi communiquer avec le robot
√ -Trouver des batteries adaptées aux besoins énergétiques du robot
√ -Permettre la recharge de ces batteries : créer un régulateur qui assurera la fonction sans endommager celles-ci (pour cela effectuer les recherches nécessaires à la conception et au fonctionnement d’un régulateur)
√-Tester le robot avec les fonctionnalités simples comme le » Garde à vous » et « Accroupi »
± -Implanter les batteries dans le robot et lui donner de l’autonomie (marcher sans aide, alimentation sans fil)
Conclusion
Ce projet nous a fait découvrir un peu plus en détail la robotique et la programmation, depuis sa conception jusqu’à coder ses mouvements. La collaboration avec les GMP a été enrichissante par le biais des transferts de connaissances et de par les relations amicales qui en ont résulté.
Le projet avec le robot NAO se décompose en deux parties.
La première consiste à aider lors de portes ouvertes ou lors de salons d’orientations (comme La journée des carrières à Mulhouse ou Le salon de l’emploi et de la formation à Colmar) les jeunes visiteurs à trouver une formation pour leurs poursuites d’études. Le robot appartenant au CFAU, il ne présentera en toute logique que les formations administrées par le CFAU. Comme son nom l’indique le CFAU, Centre de Formation d’Apprentis Universitaires, ne gère que des formations en université, allant du DUT au Master en passant par le DEUST(niveau bac+2) ou le Diplôme Supérieur de Comptabilité et de Gestion (niveau bac+5), soit plus de 111 formations en Alsace.
La seconde partie du projet consiste à déplacer NAO dans le bâtiment B du département GEII de l’IUT de Mulhouse afin qu’il puisse en faire une visite guidée. NAO, se déplaçant sur pieds, est trop lent. C’est pourquoi nous l’installons sur un autre robot à roues. Dans cette partie nous programmons donc deux robots différents, le NAO et un Robotino commandé par NAO. Cette partie n’a pas été menée à terme contrairement à la première.
-NAO est un robot constitué d’une multitude de capteurs, de moteurs et de logiciels pilotés par un système d’exploitation sur mesure : NAOqi OS.
-Il possède 25 degrés de liberté , et une centrale inertielle qui lui permet de garder son équilibre, de savoir s’il est debout ou couché.
-NAO est équipé de deux caméras qui filment son environnement et lui permettent reconnaître les formes et les objets.
-Il peut accéder à Internet de manière autonome, avec le Wifi ou en Ethernet.
-Il peut entendre et parler à l’aide de ses 4 micros directionnels et hauts-parleurs.
Et c’est avant tout cette dernière spécificité qui nous intéresse. En effet Nao doit pouvoir nous répondre lorsque l’on s’adresse à lui.
Chorégraphe
C’est à l’aide du logiciel Chorégraphe, développé par Aldebaran (société Française, à l’origine du robot NAO rachetée par SoftBank Robotics Europe en 2015), que l’on programme un robot NAO.
Environnement chorégraphe
Sur cette capture se trouvent tous les onglets nécessaires.
ProjectContent: On comprend naturellement que cet onglet concerne tous les fichiers qui sont utilisés pour le projet.
Box librairies : Cet onglet contient une multitude de fonctions réalisables par le NAO. Comme lui faire dire quelque chose, le faire marcher, se lever, allumer des voyants ou réaliser des calculs.
Root : Cet onglet présente une version graphique du programme de notre robot NAO. Un programme NAO est composé de box comme celles qui sont visibles sur la capture.Les box peuvent être:
Des « Diagram Box », c’est à dire une box contenant d’autres box.
Des « Python Box », contenant du code en python, puisque NAO interprète ce langage(ainsi que le C#).
Des « Timeline Box », permettant de programmer une série de mouvement du robot.
Des blocs de fonctions , ceux que l’on trouve dans l’onglet Box librairies.
Des « Dialog Box », permettant comme son nom l’indique de programmer des dialogues.
Log viewer : Cet onglet est comme un banquier, si il vient vers vous c’est rarement bon signe. C’est un onglet de débogage. Si une compilation échoue, c’est ici que vous verrez pourquoi. Il est explicite.
Daliog : Cet onglet permet de communiquer avec NAO. À son démarrage Chorégraphe lance un NAO virtuel. Évidemment celui-ci n’a pas de micro, alors pour dialoguer avec lui on utilise cet onglet. Cet onglet sera l’un des deux onglets les plus utilisé.
Robot view: Cet onglet permet de connaitre la position du robot (robot virtuel et véritable NAO). Il affiche aussi ce que dit le NAO.
Script Editor: Cet onglet permet d’éditer tous les fichiers sous forme de texte propres à Chorégraphe, tel que les codes de bloc fonctions, bloc python, et surtout les dialogues. Cet onglet sera le second onglet le plus utilisé.
Le programme actuel du Robot NAO est extrêmement simple puisqu’il n’est composé d’uniquement deux box et de deux liaisons. De plus il ne contient pour le moment qu’un seul fichier de dialogue. Il est possible que par la suite il y ai deux à trois « Dialog Box » supplémentaires. La box « Formation »(voir capture la capture d’écran qui suit) ne traite que les DUTs pour le moment. Peut être d’autres box serons utilisés pour les licences et les Masters.
Programme actuel du NAO
Création du dialogue
Pour la réalisation du dialogue, il est difficile d’imaginer la quantité d’information à traiter. A titre d’exemple, il n’y a que 16 DUTs en alternances contre 49 licences et 41 Masters. Et à l’heure actuelle le dialogue n’a été réalisé que pour les DUTs, ce qui représente tout de même une centaine d’échanges. En effet bien qu’il n’y ai que 16 DUTs, il faut trouver un moyen de les distinguer pour ne pas avoir à tous les énoncer d’un coup. Par exemple, j’ai pris comme critères « Industrie » (6 formations) , « Gestion »(5 formations), et « autre » ( 5 formations). Ainsi il n’y a que trois paragraphes principaux à générer. Ensuite on présente les formations par ville. Ce qui donne une sorte d’arborescence dans la conversation, comme vous pouvez le voir dans capture suivante:
Dans cet extrait apparaissent des tags sous la forme %NOM.Ces tags permettent le passage d’un niveau à l’autre de la conversation lorsqu’on ne suit pas un ordre « naturel ». J’entends par là, lorsque que notre interlocuteur souhaite finalement non plus parler d’industrie mais de gestion. Ou par la suite lorsqu’il voudra parler de licence plutôt que de DUT. Ces tags peuvent être rejoins à l’aide des commandes ^goto et ^gotoReactive . La première sert à rejoindre une partie du dialogue qui ne fait pas partie de son arborescence (Lorsqu’on parle de l’industrie puis on veut parler de gestion). La seconde sert a retourner à une partie du dialogue de son arborescence (un dialogue en u5 peut rejoindre un dialogue en u4 si ils descendent du même dialogue u3). Ces nuances sont probablement difficiles à saisir, mais elles se comprennent très naturellement dès lors qu’on les utilises.
Un dialogue comme celui-ci est très long à réaliser. Malgré tout, c’est une tâche réalisable car il n’ y a que 16 DUTs. (voici le dialogue DUT complet, Le texte étant brut, il n’a pas pour but d’être lu intégralement, mais de démontrer la difficulté à réaliser un dialogue).
En revanche, il y a 49 licences et 41 Masters. Pour les différencier, il faudrait étudier chaque intitulés de formations et compter le nombre d’occurrence des domaines. Un travail conséquent si il devait être réalisé à la main. C’est pourquoi des fonctions, puis finalement une application ont été développés pour accélérer l’étude des formations.
La version actuelle du programme, testable sur chorégraphe (version d’essai à télécharger là*) est disponible ici.
*Inscription nécessaire
II L’outil développé
Les formations et leurs intitulés sont visibles ici. Elles ont toutes été recopiés dans un fichier CSV que voici.
Ce format a été choisi car les formations sont sous forme de tableau sur le site du CFAU, de plus python comprend de base une librairie lui permettant de traiter ce type de fichier. Python est utilisé car NAO lui même utilise ce langage et les fonctions ont étés initialement écrites pour lui (mais cette stratégie a été abandonnée).
Le terme fonction est utilisé en langage C et est très parlant. C’est pourquoi je l’ai utilisé jusqu’à maintenant. Mais le vrai terme en python est méthode. La suite de ce document traitant de code python, nous n’utiliserons donc plus le terme fonction, mais bien méthode.
Les méthodes développées:
conversion (filenameSource,filenameDestination) : Elle permet de convertir un fichier CSV en fichier TXT
filtre (filenameDestination): Lors de la conversion, des caractères inutiles apparaissent , tel que « ; ». Cette fonction permet de les supprimer.
trie (string,filenameSource,filenameDestination): Lorsqu’on envoie une chaine de caractères à cette fonction, celle ci va chercher dans le fichier Source si pour chaque lignes (1 ligne = 1 formation) la chaine s’y trouve. Auquel cas, elle écrit dans le fichier Destination la ligne contenant la formation. En résumé cette fonction permet de trouver chaque formation contenant cette chaîne.
triebarre (string,filenameSource,filenameDestination): Cette méthode n’inscrit dans le fichier Destination que les lignes ne contenant pas la chaine de caractères, à l’inverse de trie.
copie (filenameSource,filenameDestination) : Cette méthode est appelée a la fin de trie et triebarre. Le fichier Source est écrasé pour être la copie du fichier Destination.
txtcount (filename): Cette méthode donne le nombre de ligne dans le fichier Destination après un trie ou triebarre.
csvcount (filename): Cette méthode donne le nombre de ligne dans le fichier « listedeformations.csv ». Ce nombre est nécessaire à la génération du premier fichier Source.
NbOccurence (string,filenameSource): Cette méthode permet de savoir combien de fois on retrouve la chaine envoyée dans un fichier source (à ce niveau fichier Source et Destination sont identiques). Sa fonction première est implémentée dans l’outil final. Mais cette méthode pourrait aussi être utilisée pour ne pas faire rater une recherche avec un mot qui ne serait pas présent dans le fichier CSV (imaginons qu’on envoie « sethdfv » à trie, alors les fichiers Source et Destination seraient vide). Ce n’est pas encore implémentée dans l’outil final.
Ainsi, si on appelle les méthodes trie ou triebarre plusieurs fois de suite (sans rappeler la fonction conversion entre temps) on peut trier le fichier d’origine avec plusieurs mots. A titre d’exemple, si on veux avoir tout les DUTs de l’industrie mais où il n’y pas d’informatique, on appellera deux fois la méthode trie et une fois triebarre ( l’ordre n’a aucune importance) et copie sera appelée 3 fois (la dernière ne servira que si l’on souhaite encore affiner la recherche avec un quatrième appel de trie ou triebarre). Il serait trop compliqué de réaliser une méthode réalisant le tout en une fois. Pour une nouvelle recherche, il suffit d’appeler conversion.
D’autres méthodes pour le traitement du document CSV ont étés développées. Mais n’étant pas gardées pour l’outil final, elles ne seront pas détaillées ici.
Un premier programme en version console
Ces codes ont été réalisés avec l’IDE Spyder. Spyder, avec un interpréteur, nous permet d’exécuter nos codes sans les compiler (comme on le ferait dans un autre langage), puis d’interagir avec, comme lui envoyer des mots. C’est très pratique.
Environnement Spyder : Sur la gauche , le code en python. Sur la droite, l’interpréteur avec qui on peut interagir
Mais dès lors qu’on désire effectuer de nombreuses recherches, interagir avec l’interpréteur n’est plus aussi pratique. Pour mieux comprendre, nous allons étudier la capture précédente.
Le code sur la gauche a été interprété (sorte de compilation ne générant pas de fichier .exe) après avoir pressé la touche F5 . Sur la partie de gauche est alors apparu dans le champencadré en rouge avec le terme « Critères : »
J’y ai écris « DUT » , ce qui a affiché le champ encadré en bleu. txtcount nous apprend qu’on a 16 formations répondants à ce critère.
Par la suite j’ai écrit « industrie ». Malheureusement ce mot s’écrit Industrie dans le fichier Source. Il n’a donc pas été trouvé dans le fichier, on obtient alors lechamp encadré en vert. Comme nous l’indique txtcount avec le 0, notre fichier destination est vide. Cette situation aurait pu être évitée en utilisant NbOccurence comme garde fou.
Le programme demande alors si on veut effectuer un nouvelle recherche comme on peut le voir dans le champ encadré en orange. Tant qu’on ne renvoie pas « NON » , une nouvelle recherche est lancée , mais en repartant depuis le début. C’est là qu’apparait la limite de la version « console » de ce programme. Dans ce cas ce n’est pas très grave puisque qu’un seul critères a été entré. En revanche si il avait fallu travailler sur les licences, plus de critères sont nécessaires, mais aussi plus de recherches différentes (plusieurs combinaisons différentes de mots).
Le champ encadré en mauve, montre simplement la même recherche sans erreur.
De manière générale ces méthodes sont très utiles , mais ne sont pas pratiques sous cette forme.
La solution pour rendre ce programme plus pratique a été de développer une interface graphique pour utiliser toutes ces méthodes.
J’ai choisi de travailler avec Tkinter, une librairie python permettant de programmer un environnement graphique. L’avantage est qu’il est aisé de trouver de nombreuses ressources sur cette librairie, et même en français.
Dans un premier temps, j’ai dessiné sur papier la disposition générale que je désirais pour mon application. Assez vite j’ai codé cette disposition avec Tkinter. L’application est découpée en 5 panneaux qui sont:
Parcourir ( ne fonctionne pas pour le moment) , permettra de choisir le fichier à analyser. Actuellement , l’adresse du fichier est inscrite dans le code du programme.
L’insertion des mots clés, où l’on précise si on doit garder ou supprimer les lignes contenants ces mots. Limité à 6 mots pour le moment.
L’affichage du fichier destination. Le panneau est actualisé à chaque nouvelle recherche
Nombre d’occurrences. On y inscrit les mots dont on veut connaitre le nombre d’occurrence.
Lancer la recherche qui permet de … lancer la recherche (si si).
Les fonctions des panneaux ont donc été codées après leur mise en place. Un panneau est traité après l’autre.
Voici le rendu actuel du programme :
Le programme m’a permit de trouver tout les DUTs touchants l’industrie, d’ignorer les licences (ce qui avait déjà été fait en ne gardant que les DUTs) et d’ignorer toutes les formations touchants la gestion.
L’écran principale nous apprend alors qu’on a 6 formations répondants à ces critères. Puis les affiches. Le panneau du milieu nous confirme bien que nous avons 6 DUTs , 6 qui touchent l’industrie , et aucun ne touchant la gestion ou le tourisme (ce qui me fait penser que certains étudiants en GEII n’ont pas été informés par un NAO bien programmé). Un bug apparait pour le Bac+2 , alors que « ac+2 » affiche bien 6 .
Le programme est actuellement très mal écrit. Prochainement il sera récrit. La fonction parcourir devrait fonctionner afin de pouvoir, pourquoi pas, traiter d’autres CSV, ou même des fichiers TXT ou XLS. J’essaierais aussi d’améliorer la disposition des panneaux. Mais avant tout ça, je me servirais de cet outil pour trier les formations en licence et en master afin d’adapter au mieux le dialogue du robot NAO.
Vous pouvez tester cet outil en téléchargeant cette archive. Vous y trouverez le code python ainsi que la liste des formations déjà donnée plus haut. Veillez à mettre Versionrapport.py et Listedesformations.csv dans le même répertoire.
À titre indicatif, cette application a permit le traitement des masters en moins de 5 minutes , hors rédaction du dialogue. La capture nous apprends que nous 3 master en industrie, 14 en « gestion » (dont 6 en gestion de projet), 22 en management, 5 en informatique, 7 en marketing, 6 en achats, 6 en chimie et 1 en journalisme.
il y a plus que 41 masters ici. Certaines formations traitent plusieurs domaines. Ainsi une formation peut être en gestion et en management (3 formations)
En appelant triebarre avec cette application , il n’en ressort aucun master : En traitant les masters avec les critères indiqués plus haut, on s’assure de n’en manquer aucun lors de la rédaction du dialogue (capture téléchargeable ici).
Cette capture nous confirme l’intérêt de traiter les masters avec ces critères
B PROJET : Déplacer Robotino avec NAO
I Le Robotino
Ses caractéristiques
Comme le robot NAO, Robotino est un robot pédagogique. Il est possible de le programmer de très nombreuses de manières comme en C, C++, Java, .Net, Matlab, LabVIEW et Microsoft Robotics Developer Studio. Pour ma part, j’ai utilisé un logiciel fourni par FESTO, l’entreprise ayant développée ce robot. Robotino est en open source. À la différence de NAO, Robotino se déplace sur roue et non sur pied.
Voici quelques-unes de ses caractéristiques qui me seront utiles :
Déplacement omnidirectionnel.
Capteurs de distance infrarouge.
Capteurs incrémentaux qui permettent de mesurer la vitesse de rotation réelle de chaque moteur.
Communication Wifi.
Peut porter jusqu’à 20 kg.
Présentation de Robotino-view
Il faut comprendre qu’avec Robotino-view, le programme n’est pas sur le Robotino mais bien sur un PC. Et c’est ce PC qui à l’aide d’une connexion WIFI (possible aussi en en filaire) envoi les commandes à Robotino. En revanche c’est bien le Robotino qui est le serveur dans cas. C’est-à-dire que c’est lui qui fournit une adresse IP au PC.
Voici une description de différentes options disponibles.
Lecture : Permet de démarrer le programme du Robotino sur le PC.
Connexion : Permet de se connecter à un Robotino pour lui transmettre les instructions.
GRAFCET : Permet d’organiser notre programme sous la forme d’un grafcet. Son usage est contre-intuitif. Je ne l’ai compris qu’au moment de rédiger ces lignes.
Progr / Step : Permet de savoir si le programme est en cours d’exécution, et dans quelle tâche avec un voyant vert. Selon le grafcet, plusieurs étapes peuvent êtres actives simultanément.
Les variables : Ce tableau affiche les variables disponibles dans le programme.
Robotino-SIM
De la même manière que l’on pouvait utiliser un NAO virtuel, il est possible d’utiliser un Robotino virtuel. À ceci prêt que cette fonction n’est pas intégrée au logiciel permettant de le programmer Robotino-view. Dans la capture d’écran de Robotino-View, dans le rectangle bleu on peut voir l’adresse suivante : « 127.0.0.1:8080 ».
« 127.0.0.1 » est en fait une carte réseau virtuelle et 8080 le port de communication utilisé sur cette carte. Ce sont ces coordonnées que l’on va utiliser pour se connecter au robot virtuel généré par Robotino-Sim.
Dans la vidéo qui suit vous pouvez voir le Robot en mouvement.
Ce robot virtuel a été très pratique pour travailler à la maison.
II Comment communique NAO avec Robotino ?
Le programme Robotino-view permet d’utiliser un ou plusieurs serveurs UDP .
Ces serveurs gèrent 2 « messages » :
– message 0
– message 1
Il faut comprendre « message » comme un canal.
Le message 0 permet la lecture de 8 sorties et l’écriture sur 8 entrées. Idem pour le message 1.
Tous les X temps (à définir dans la configuration du serveur) le serveur envoi aux adresses configurées les valeurs de ces sorties.
Dès que le serveur reçoit une trame sous la bonne forme, il écrit sur les entrées du message de destination.
L’idée est alors de demander au robot NAO d’envoyer une trame pour commander le Robotino. Mais Nao doit aussi considérer les informations envoyées par Robotino. Par exemple, dans mon programme Robotino-view je demande à ce que, dès que les capteurs du Robotino détectent un objet, Nao soit au courant afin qu’il adapte sa conduite.
Récupération d’une trame
À l’aide d’un petit code en python, téléchargeable ici, il est possible de récupérer une trame .
Pour expliquer le plus simplement ce code, le client UDP attend en permanence un message sur le socket* « monSocket ». Dès qu’un message est reçu il est encodé en HEXADÉCIMAL et affiché.
En HEXA signifie qu’il n’affichera que des caractères compris entre 0 et 9 et A et F. La trame, qui peut être vue comme une série de 0 et de 1, est découpée en octets.
*« Les sockets servent à communiquer entre deux hôtes appelés Client / Serveur à l’aide d’une adresse IP et d’un port […]; ces sockets permettront de gérer des flux entrant et sortant afin d’assurer une communication entre les deux (le client et le serveur) » explication obtenues à la page https://openclassrooms.com/courses/introduction-aux-sockets-1.
Explications : Admettons que mon client UDP reçoive «0010101100000111», en HEXA cela donne 2B 07. Seulement en ASCII 2B correspond à un + et 07 correspond à un « bip sonore ». Si + est bien un caractère affichable, ce n’est pas le cas du bip. En l’occurrence les trames émises par Robotino-view sont destinées à envoyer des nombres et non des chaînes de caractères. Alors si on n’encode pas la trame, l’interpréteur python tentera d’afficher des caractères.
Dans la vidéo qui suit vous verrez la récupération une trame. Par la suite l’interpréterai.
Tout d’abord quelques explications.
Sur la partie gauche de la vidéo vous voyez la « console » de l’interpréteur python. C’est là que ce sont affichées les trames encodées en HEXA.
Sur la partie droite vous voyez une partie du logiciel Robotino-view ainsi que la fenêtre de commande du serveur UDP. On y voit bien que le serveur s’adresse au port 9180 de l’adresse 127.0.0.1. Sans ça, le client UDP n’aurait rien reçu.
00 : C’est l’ID du message (le « canal »). Ici il vaut 0.
2400 : C’est le nombre d’octet qui compose la trame. En HEXA ce devrait valoir : 9216. Pourtant il est évidant que si l’on regarde la trame indiquée plus haut on est loin de cette valeur. En vérité on est à 36 octets. Pour mieux comprendre il faut revenir sur le tableau sur les INT32. En fait le byte 0 (octet 0) est le byte de poids faible. Autrement dit, il faut lire non pas 24 00 mais 00 24, ce qui en base dix donne 2*16 + 4 = 36.
ab : C’est la somme de contrôle. Elle est égale à la somme de tous les octets composant la trame.
La somme de contrôle s’obtient en faisant : 255 – la somme de tous les octets de la trame.
Mais 1364 ne tiens pas sur un octet (qui peut valoir 255 max). Il faut alors faire 1364 % 256 = 84.
(256 car un octet peut valoir de 0 à 255, soit 256 valeurs possibles).
Et 255-84 = 171.
Cet octet, ainsi que le nombre d’octet dans la trame sont des outils pour tester l’intégrité de la trame.
Les octets suivant contiennent les valeurs lues sur les sorties INT0 à INT7 du message 0. Ici il s’agit de INT32 signés. C’est à dire que la valeur max est de 2^31 soit 2 147 483 648. Le bit de poids fort indiquant le signe de la valeur.
Voici une formule pour calculer facilement la valeur un INTX :
Si l’on regarde le bit de poids fort du INT5, on constate qu’il vaut 1 ( 255 en base 10 = 1111 1111 en base 2). Les nombres étant codés en complément à 2*, cela qui veut que dire c’est un entier négatif.
*C’est écrit nulle-part dans Robotino-view, c’est une conclusion que j’ai dû tirer moi même.
On peut obtenir sa valeur de deux façons différentes .
L’autre solution est de rester en base 10 et de faire :
A= (255 *256^3 + 255*256^2 +253*256 + 68) -256^4
A= -700
Maintenant nous savons lire une trame à la main, nous pouvons donc gérer théoriquement une communication de Robotino vers NAO et inversement. Mais il faut encore pouvoir automatiser l’écriture et la lecture de ces trames.
Lire automatiquement une trame reçue
J’ai écrit une méthode qui ne permet que de lire qu’un INTX à la fois, après réception d’une trame.
C’est la méthode Conversion_en_INT(String_a_Massacrer, int_a_retourner)
La méthode Conversion_en_INT demande comme argument la chaine que l’on veut étudier (que l’on a obtenue avec un client UDP) et surtout quel INTX on souhaite lire.
Afin de ne pas surcharger le Word press, vous trouverez un code python commenté ici de cette méthode.
Je propose de tester cette méthode.
J’utilise un nouveau code python, téléchargeable ici, qui me permet d’utiliser un client UDP qui appellera en boucle la méthode Conversion_en_INT(String_a_Massacrer,int_a_retourner) afin de lire les 8 INTX fournies par le message 0 et les 8 INTX fournies par le message 1.
Dans la vidéo suivante vous verrez le code en application:
Dans la partie de droite, on voit un programme Robotino-view qui écrit sur les entrées 0 à 7 du message 0, pareil pour le message 1. Les valeurs utilisées ont été notées au hasard.
Sur la partie gauche de la vidéo vous retrouverez ces mêmes valeurs suite à l’interprétation de la trame faite par ma méthode. Je prends le soin d’analyser l’ID du message.
Écrire « automatiquement » une trame
Cette méthode prend en argument 8 valeurs : l’ID des messages et les valeurs que l’on souhaite écrire pour INT0 à INT 7. Voici le prototype : ConversionUdp(ID_Message, int0,int1,int2,int3,int4,int5,int6,int7)
Là aussi, pour ne pas surcharger le WordPress, je vous propose de lire la méthode commentée, téléchargeable ici .
Dans la vidéo suivante vous verrez un code avec, téléchargeable ici, en application:
Je commence par envoyer la trame qui a été écrite dans la méthode commentée plus haut. On peut voir dans Robotino-view que les entrées prennent bien les valeurs désirées.
Ensuite le programme python s’arrête durant 4 secondes. Puis on envoie la trame qui a été écrite juste avant par la méthode ConversionUdp(1,0,0,0,0,0,0,0,0).
Nous maitrisons maintenant parfaitement l’envoi et la réception de ces trames. Nous pouvons commander le Robotino et Robotino peut envoyer les informations nécessaires, sous forme d’entier.
Code de déplacement
Je propose maintenant l’automatisation une tâche : La recherche d’un mur.
Ce ne sera pas UN programme, mais deux programmes qui communiquent l’un avec l’autre.
L’un est fait avec Robotino-view, l’autre avec Spyder en python.
Je vais commencer par présenter le programme sous Robotino-view.
Tout d’abord, voici son GRAFCET :
Il existe deux façons de faire se déplacer Robotino :
-Soit on lui indique une vitesse. En mm par seconde pour un déplacement verticale ou horizontale. En degré par seconde pour un déplacement angulaire => Ce sera fait avec la tâche « Step1 »
-Soit on lui indique une coordonnée en mm ou en degré. => Ce sera fait avec la tâche « Step2 »
Step1
Pour passer d’une étape à l’autre j’écris dans une variable « Changement_d_etape ».
C’est l’entrainement omnidirectionnel. C’est lui qui envoi les consignes aux 3 moteurs de Robotino.
La consigne de déplacement sur l’axe de X proviendra de INT0 du message 0.
La consigne de déplacement sur l’axe de Y proviendra de INT1 du message 0.
La consigne de déplacement angulaire proviendra de INT2 du message 0.
C’est la variable qui me permet de passer de STEP1 vers STEP2 (et inversement).
Elle sera affectée par INT3 du message 0.
Cette entrée INT5 du message 0 me permet d’activer le frein des moteurs.
Cette partie est un peu plus complexe.
Ceci est le capteur infrarouge 4. Dès qu’il voit un obstacle, il renvoi une valeur entre 0 et 2.54. S’il revoie 2.54 c’est que le capteur IR4 est presque au contact de l’obstacle.
Plutôt que de travailler sur une plage de 0 à 2.54. Je décide de traiter cette information sur une page de 0 à 100 qui est plus intuitive. Dès que mon capteur renvoi une information > 30% de 2.54, alors j’entre un 1 dans un sommateur.
Voici le sommateur. Le résultat obtenu est écrit dans INT0 du message 1.
C’est ainsi que je peux savoir si mon Robotino voit un mur ou obstacle à une distance que je considère suffisante.
Cette partie etait destinée à être optimisée. L’idée est de multiplier la sortie du comparateur du capteur 2 par 10, du capteur 3 par 100(pour le capteur 3), etc, jusqu’au capteur 9 par 100000000. Ainsi, on pourra manipuler la , à l’aide de modulo et de soustraction, la valeur lue dans INT0 du message 1 afin de déterminer précisément quel capteur voit un obstacle.
Si mon capteur infrarouge 1 voit un obstacle, j’écris dans INT1 du message 1.
J’ai besoin de cette information indépendamment de celles autres capteurs dans mon programme en python.
En résumé, STEP1 me permet de donner une vitesse de déplacement à Robotino, et de savoir s’il détecte un obstacle.
Step2
Cette fonction est un « parcoureur de position ». Il permet de parcourir une distance pour atteindre une coordonnée qu’on lui aurait donné en consigne. Il envoie les ordres de déplacement aux moteurs en fonction de la distance parcourue. Cette information il obtient à partir à partir de la fonction « odométrie ».
On envoie la consigne de distance sur l’axe des X avec l’entrée INT0 du message 0.
On envoie la consigne de distance sur l’axe des Y avec l’entrée INT1 du message 0.
On envoie la consigne d’angle avec l’entrée INT2 du message 0.
Curieusement dès qu’on envoie une distance à parcourir sur l’axe des X ou des Y, la fonction « parcoureur de position » s’exécute de suite. En revanche, si on veut parcourir un nouvel angle, il faut un front descendant sur cette entrée.On réalise ce front avec l’entrée INT4 du message 0.
Voici la fonction « Odométrie ». Avant de savoir quelle distance on a parcourue il faut lui donner un point de référence.
Pour ma part j’ai configuré les valeurs suivantes :
-0 en X.
-0 en Y.
-0 en degré.
Dès lors que l’on veut redéfinir un point de référence, il faut faire un front montant sur cette entrée. On réalise ce front avec l’entrée INT5 du message 0.
Ces deux fonctions méritent d’être illustrées par un exemple :
Disons que les positions de référence valent :
-> 25 en X.
->-72 en Y.
-> 0 en degré.
Maintenant disons que je donne en consigne au « parcoureur de position » :
-> -27 en X.
-> 257 en Y.
->15 en degré.
Robotino ne parcourra pas :
-> -27 en X.
-> 257 en Y.
->15 en degré.
Mais il parcoura :
-> (-27) – (25) = -52 en X.
->-257 – (-72) = 329 en Y.
-> 15 – 0= 15 en degré.
En réinitialisant systématiquement le point de référence à {0,0,0}. Ce « parcoureur de position » devient un « parcoureur de distance », bien plus pratique pour mon application.
Le capteur IR1 envoie une valeur comprise entre 0 et 2.54. Mais les entrées/sorties du serveur UDP ne traitent que des entiers.
Ce qui réduit beaucoup la précision du capteur puisque qu’on ne pourrait lire 0,1 ,et 2 si l’on le connectait directement à la sortie INT1 du message 1. En multipliant la sortie du capteur par 100, on peut écrire 255 valeurs sur la sortie INT1 du message1.
En résumé, STEP2 permet de faire parcourir une distance à Robotino et de lire les informations fournies par le capteur IR1.
Le programme Python
Dans l’image qui suit, vous voyez la disposition des capteurs à infrarouge (IRx) autour de Robotino. Je précise que la notion d’avant et arrière est arbitraire. Pour moi l’avant de Robotino est au niveau de IR1.
Le code que je vous présente (il ne sera pas détaillé comme les codes) n’est pas exécuté à partir d’un NAO, mais toujours depuis l’IDE Spyder.
# Le programme de Robotino-view doit être à l’étape Step1.
Au moment de démarrer le Robotino, celui-ci est incapable de savoir où il est.
J’envoie donc une trame au serveur UDP de Robotino-view. Celle-ci permet de dire à Robotino de reculer jusqu’à ce que n’importe lequel de ses capteurs à infrarouge détecte un mur. Le code python est en attente d’une trame qui l’informera quand les capteurs voient un mur : INT0 du message 1 > 0.
Le serveur UDP envoie en permanence des trames. Le programme python étant incapable de savoir laquelle contient l’information qu’il lui faut, il les scrute toutes.
Lorsque le programme python lit que INT0 du message 1 > 0, il active le frein des moteurs en envoyant une trame contenant INT5 du message 0 = 1.
Je demande alors à Robotino de tourner, jusqu’à ce que ce soit son capteur IR1 qui voit le mur. Le programme python attend alors une trame contenant INT1 du message 1 > 0.
Évidemment si le capteur IR1 voit déjà un mur, cette étape est passée instantanément.
Ensuite le programme python envoie une trame pour que le programme de Robotino-view passe à l’étape Step2. Ceci se fait en envoyant 2 sur l’entrée INT5 du message 0.
# Le programme de Robotino-view doit être à l’étape Step2.
L’objectif ici est de trouver la position optimum, pour que le capteur IR1 soit « en face » du mur. Je demande à Robotino de tourner de 3 degrés et de relever la valeur lue par le capteur IR1. Plus IR1 se rapproche du mur, plus la valeur qu’il lit est élevée. Le programme python compare toute ces valeurs. Dès que IR1 renvoie une valeur plus faible que la précédente, c’est qu’il s’éloigne du mur : La position optimum est passée. On retourne alors dans la position précédente.
Dans la vidéo qui suit, vous verrez les programmes communiqués, et le Robotino virtuel se déplacer en conséquence.
Il faut maintenant exécuter ce code non plus depuis l’IDE Spyder, mais depuis NAO.
On va commencer par enregistrer les méthodes développées (lecture et écriture de trame) dans fichier python. Pour ce faire on créer un fichier python « Robotino ». Le fichier python est téléchargeable ici.
On prend le soin de le mettre à la racine de projet NAO.
Ensuite on créer un block python qui sera lancé au démarrage.
Par la suite on importera ces méthodes dans les « python block », avec la commande :
from robotino import*
Malheureusement pour moi, je n’ai pas pu terminer mon projet. La suite ne présentera donc qu’une ébauche de programme.
Le fonctionnement est le suivant :
Au démarrage on lance le chargement du fichier python contenant les méthodes développées. Ensuite on active la caméra qui se situe dans la bouche du NAO et on active la reconnaissance des NAOMARKS(exemple visible sur l’image suivante).
Les valeurs lues par la caméra rentrent dans un switch case. En fonction du résultat on active la box « Com_simple », ou la box « STOP ».
-> « Com_simple » demande à Robotino de reculer jusqu’à ce qu’il voie un mur. Tourne jusqu’à ce que IR1 voit le mur. Et on active « Com_simple_2», qui sert à obtenir l’angle optimum. Les résultats de Com_simple2 ne sont pas probant, je n’ai pas trouvé les raisons.
-> « STOP » envoie une trame pour retourner à l’étape Step1 et remettre toutes les valeurs à 0.
Voici une vidéo où le NAO virtuel commande le Robotino virtuel.
Conclusion :
Si je suis satisfait de certain résultats obtenus comme la maitrise des trames ou la communication entre les robots, je reste déçu de ne pas avoir réussis à atteindre les objectifs fixés. Peut-être étaient-ils trop ambitieux pour mes compétences.
J’ai dans l’espoir que les ressources que je laisse seront assez lisibles pour de futurs utilisateurs, ou qu’au moins ils puissent s’aider des informations misa à disposition sur cette page.
La présentation du projet est terminée. Merci de votre attention.
Pour finir cette page, je vous présente le groupe à l’origine de ce projet : Le mononôme Alexandre Ribault.
La distribution du travail s’est faite de la façon suivante, pour une répartition juste et équitable de la charge de travail:
1. Présentation générale du projet
1.1 L’impression 3D
1.2 Cahier des charges
1.3 Gestion des tâches et du temps
1.4 Coût du projet
2. Recherche d’une solution
2.1 Analyse du système
2.2 Le Raspberry Pi 3
2.3 MQTT
2.4 Solution mécanique
3. Réalisation
3.1 Programmation
3.2 Réalisation des supports
Conclusion
Introduction :
Nous sommes actuellement en deuxième année de DUT Génie Electrique et Informatique Industrielle à l’IUT de Mulhouse et nous avons réalisé ce projet en collaboration avec deux étudiants en Génie Mécanique et Productique. Nous avons choisi la surveillance de l’imprimante 3D, en effet, l’impression 3D est une technologie pour le futur. Ainsi, de plus en plus de particulier possède une imprimante 3D et la surveillance du bon déroulement de l’impression à distance est susceptible d’intéresser un bon nombre de personnes.
La vision est un outil en plein développement au sein de l’industrie mais également chez les particuliers. Nous allons donc réaliser la supervision de l’impression d’une imprimante 3D située au sein du Département Génie Mécanique de l’IUT de Mulhouse. Cette supervision permettra de vérifier le bon fonctionnement de l’imprimante grâce à une image, si nous avons un défaut nous pourrons arrêter l’impression à distance.
Pour vous expliquer en détail le déroulement de ce projet, nous allons dans un premier temps réaliser une présentation générale du projet, puis nous allons vous exposer les solutions que nous avons proposé pour mener le projet à son terme. Ensuite, nous allons vous présentez la solution que nous avons mis en œuvre. Et pour finir, nous conclurons sur ce que nous à apporter ce projet.
1. Présentation générale du projet
Dans cette première partie nous expliquerons tout d’abord le principe de l’impression 3D, puis nous définirons le cahier des charges. Ensuite nous montrerons notre répartition des tâches et pour finir nous définirons le coût du projet.
1.1 L’impression 3D
L’impression 3D est un procédé qui permet de fabriquer des pièces en volume. Cela permet de réaliser un objet réel à partir d’un logiciel de conception assistée par ordinateur (CAO). Sur ce logiciel nous réalisons une pièce en 3 dimensions qui sera ensuite traitée par un logiciel qui organise le découpage en différentes couches nécessaires à la réalisation de la pièce.
Sur l’image ci dessus on retrouve le fichier avant l’impression et on retrouve le résultat après l’impression 3D. Il existe de nombreux types d’imprimante 3D avec une très large gamme de prix, ceci allant de l’imprimante basique pour un particulier à une imprimante complexe pour un industriel.
1.2 Cahier des charges
La surveillance de l’imprimante 3D est nécessaire pour les enseignants du département Génie Mécanique et Productique. En effet, certaines impressions peuvent durer plus de 24 heures et sont donc lancer le week-end. Cependant sans surveillance l’imprimante peut avoir un défaut et ne s’arrêtera pas. Une impression de 24 h raté engendre une perte de temps et de matière conséquente.
Définition du besoin
Fonction principale et contraintes
Fonctions
Critères
Niveaux/flexibilité
FP1 : Permettre la vision à distance afin de garantir le bon déroulement du procédé de fabrication
Fonctionnalité
Vision depuis une connexion internet
Microprocesseur
Marche/arrêt, lumière
Serveur MQTT
Rapsberry Pi 3
FC1 : Garantir une vision du procédé de fabrication
Qualité de l’image
Positionnement de la caméra
Résolution minimum 240p
Réglable
FC2 : résister au milieu extérieur
Vibrations,
chocs
Utilisation courante
FC3 : S’adapter à l’imprimante 3D
Type d’accroche
Ergonomie
Visser dans le carter de l’imprimante
Réglable/montable par l’utilisateur
FC4 : Garantir l’alimentation de la caméra
Electricité
Connexion internet
230V 50hz (secteur)
Wi-Fi ou RJ45
1.3 Gestion des tâches et du temps
En bleu : tâches des étudiants en GEII En vert : tâches des étudiants en GMP
1.4 Coût du projet au niveau électrique
Matériel à commander
Fournisseur
Références
Quantité à commander
Prix
Raspberry Pi3
Raspberry
RASPBERRY-PI-3B
1
40 €
Alimentation 5 V 3A
1
10 €
Câble Ethernet
5m
5 €
Caméra LOGITECH C170
Logitech
PN 960-001066
1
25 €
Servomoteur HS- 422 HITEC
Hitec
MRC-HS311VR
1
10 €
2. Recherche d’une solution
Dans cette seconde partie nous vous présenterons tout d’abord une analyse du système, puis le Raspberry Pi 3 et MQTT que nous allons utilisée. Et pour finir nous verrons la solution que nous avons trouvé au niveau mécanique.
2.1 Analyse du système
Tout d’abord rappelons que l’imprimante 3D fonctionne à une température ambiante d’environ 70°C. L’installation de la caméra peut se faire de deux façons différentes :
Insérer la caméra dans l’imprimante et mettre en place un système de ventilation
Positionner la caméra à l’extérieur de l’imprimante
Nous avons conserver la deuxième solution, c’est à dire de positionner la caméra à l’extérieur de l’imprimante. En effet, une caméra supportant une telle température serait trop coûteuse et de plus la mise en place de ce système de ventilation serait bien trop compliqué.
Nous avons donc choisie l’emplacement de la caméra mais il faut également prévoir le système permettant d’arrêter l’impression et d’ allumer la lumière.
Ainsi nous avons pu remarquer que les boutons de commande sont câblés à travers une nappe. Cette nappe est ensuite insérer dans un connecteur qui lui-même est soudé sur une carte électronique. Il n’est pas possible de reprendre le câblage des boutons poussoirs.
Sur la première image ci contre on aperçoit la sortie des boutons sur la carte électronique.
Et sur les deux boutons suivants, on aperçoit la nappe de sortie des boutons poussoirs. Il faut donc trouver un système qui permettra d’appuyer physiquement sur les boutons poussoirs.
2.2 Le Raspberry Pi 3
Le Raspberry Pi est un nano ordinateur de la taille d’une carte de crédit. Il fonctionne avec différentes versions du systèmes d’exploitations Linux, en effet, la plus utilisée est Raspbian. Le Raspberry Pi ne comporte pas d’alimentation, clavier, souris ou écran. On retrouve sur un aperçu du Raspberry Pi 3.
Comme on peut le voir sur l’image ci dessus, le Raspberry Pi 3 comporte 3 Ports USB et une prise Ethernet. On peut voir qu’il dispose également de ports GPIO qui peuvent être utilisés comme entrée/sortie. Il est également équipé d’une carte Wifi et du Bluetooth.
Ce Raspberry Pi 3 comporte donc parfaitement à nos besoins, il nous permettra tout d’abord de pouvoir branché une caméra à travers le port USB. Nous pourrons gérer des entrée et des sorties à travers les ports GPIO. Et de plus nous pourrons nous connecter à internet et au réseau de l’UHA grâce à la prise Ethernet ou à la carte Wifi.
2.3 MQTT
MQTT : Message Queuing Telemetry Transport
MQTT est une protocole de messagerie qui fonctionne sur le principe de subscriber / publisher qui a été développé pour simplifier la communication entre les machines. Il est basé sur le protocole TCP/IP. C’est un protocole très léger, de ce fait, nous pouvons envoyer des messages qui ne dépassent pas 256 Mo. Ceci est également un avantage, ce qui en fait un des protocoles de communication du « futur ». En effet, une partie d’application Messenger de Facebook utilise le protocole MQTT. Nous allons vous illustrer le fonctionnement avec le schéma suivant.
Nous retrouvons donc les subscriber et les publisher. Cependant nous avons un également le broker MQTT, c’est un serveur qui permettra de faire passer les messages entre les différents clients.
Un subscriber (souscripteur) souscrit à un ‘topic’. Ce topic sera alors ouvert dans le serveur. Ensuite le publisher (publieur) publiera dans le même topic que celui du subscriber et celui-ci réceptionnera le message.
Nous avons donc une communication entre les différents composants, mais tout le monde pourrait accéder au contenu qui passe par le broker MQTT.
En efet, nous pouvons sécurisé la communication du protocole MQTT. Dans un premier temps nous pouvons définir qui a le droit de publier sur le topic mais également ceux qui ont le droit de s’y abonner.
De plus nous avons un autre aspect de sécurité, c’est le Quality of Service pour les messages :
QoS niveau 0 : le message sera délivré une fois sans garantie de réception et ne sera pas sauvegardé sur le serveur ;
QoS niveau 1 : le message sera livré au moins une fois jusqu’à la réception d’un accusé de réception de la part du broker MQTT ;
QoS niveau 2 : le message sera renvoyé puis sauvegardé tant que le récepteur n’aura pas répondu.
A présent nous avons éclaircie le fonctionnement du protocole de communication MQTT. Cela a été difficile pour notre groupe d’intégrer ces notions du fait que nous n’avions jamais travaillé dans ce domaine de l’Internet of Things (IOT).
2.4 Solution mécanique
Nous avons donc réalisé une représentation du panneau de contrôle de l’imprimante sous créo.
Quelques modifications ont été apportés au moteur afin de pouvoir l’adapter à l’imprimante. Il a été nécessaire de réaliser une nouvelle came pour celui-ci afin de pouvoir atteindre les boutons du panneau de l’imprimante grâce à deux tiges de pression.
De ce fait, nous avons repris la base de la came initialement prévue puis créé une plus large qui nous a permis d’y insérer 2 boutons poussoir sous forme de vis pour exercer la pression sur les boutons. Avant la réalisation de cette came, nous avons donc réalisé un prototype sur créeo en récupérant l’entraxe entre les deux boutons de l’imprimante.
Came moteur :
L’objectif de cette partie est donc de détailler comment nous avons imaginé le système pour qu’il soit le mieux adapter au système.
Dans un premier temps il serait intéressant d’observer notre base de travail pour cette partie.
L’objectif de ce système était qu’il soit adaptable tant au niveau de la caméra que du cerveau moteur. Nous réalisé un montage sur créo pour observer la mise en place du système. Néanmoins, il manque la partie « bras et support de caméra » et la représentation des tige filetés permettant de régler la distance du cerveau moteur.
Pour cela, nous avons réalisé un système permettant de gérer par système de coulissement la position de notre caméra et de notre cerveau moteur. Le fait de pouvoir régler la caméra en hauteur nous permet d’anticiper la fabrication des pièces dans l’enceinte de l’imprimante car plus les pièces sont importantes en volume, plus il y aura des variations de hauteur du plateau.
Système de coulissement :
Cette partie est assez simple d’utilisation et de fabrication. Nous avons utilisé une tige de diamètre 15 et réalisé un méplat sur celle-ci pour la bloquer en rotation dans nos guides. Un système de vis de pression est utilisé d’une part pour bloquer notre tige dans les guides et ce même système est utilisé pour bloquer nos composants sur cette tige. Nous avons donc utilisé une tige en acier comportant la contrainte de poids mais néanmoins reste plus solide pour appliquer une pression avec les vis. Toutes les autres pièces sont donc usinées ou découper dans l’aluminium ou dans le plastique pour des raisons de légèreté.
Support cerveau moteur :
La plaque du cerveau moteur a donc une double fonction, d’une part la fixation du servomoteur et d’autre part elle permet la liaison entre le serve et le système de mise en position.
Pour la partie servomoteur, nous avions à disposition un moteur fourni par monsieur Chassignet. De ce fait, pour éviter les dépenses extérieures, nous avons réalisé un support adapté à ce moteur. Pour cela, nous avons récupéré les côtes de celui-ci (largeur du moteur, entraxe entre les alésages prévu pour la fixation) pour que l’on puisse l’insérer et le fixer sur le support.
La fonction de liaison entre le support came et le système de mise en position est réalisable par l’intermédiaire de 2 tiges filetées de diamètre 6 et d’un système d’écrou contre écrou.
Pièce liaison système coulissant et support cerveau :
Cette pièce sert à effectuer la liaison entre les deux parties du système. Nous retrouvons le diamètre 16 de notre basse et les deux tarauds M6 pour nos tiges filetés. Pour régler cette pièce en position, un système de vis de pression a été réalisé sur le diamètre 16.
L’ensemble de cette pièce est réalisable en découpe jet d’eau pour un gain de temps. Néanmoins les tarauds et les alésages sont à réaliser sur une perceuse à colonne.
Bras de réglage de la caméra :
Notre caméra sera maintenue à l’aide d’une pièce support réalisé par impression 3D qui se pince sur le bras de positionnement de la caméra.
Celui-ci s’adaptera au bâti de notre système de fixation qui sera directement ancré sur le profil de l’imprimante.
Ce bras permettra le réglage de la caméra en hauteur et en profondeur afin de pouvoir garantir le meilleur champ de vision pour surveiller les impressions en cours. Celui-ci se compose du tube ci-contre qui prend place sur le bâti du système et d’un simple tube cintré à 90°, coulissant dans le premier et situer grâce à une goupille sur lequel viens se pincer le support ci dessus.
3. Réalisation
3.1 Programmation
Afin de réaliser ce projet nous utilisons donc le protocole de communication MQTT. A travers nos différentes recherches sur celui-ci nous avons pu remarquer que le langage de programmation de plus utilisée est le langage Python. C’est un langage de programmation très puissant qui nous permettra de réaliser notre partie de programmation.
Tout d’abord nous avons dû installé une caméra sur le Raspberry, ainsi le but de cette première partie aura été de pouvoir capturé une image tout simplement. Pour cela nous avons tout d’abord utilisé une webcam de la marque Logitech.
Cette caméra Logitech présentant un bon rapport qualité/prix nous a tout de suite intéressé, en effet nous ne cherchions à avoir une caméra simple mais avec une bonne qualité de photo.
De ce fait il a tout d’abord fallu autoriser l’utilisation d’une caméra sur le Raspberry. Cela nous a donc permis de générer un code Python permettant de prendre une image de la webcam et de la lire.
Nous pouvons retrouvez ci dessous le code permettant de capturer une image.
On retrouve une première où l’on capture l’image, une deuxième phase où l’on compresse l’image sous le format JPEG et enfin une phase où nous enregistrons l’image dans le même dossier que le code mais où nous chargeons l’image avant l’envoi.
Afin de réaliser ces différentes phases nous avons utilisé la librairie open-cv de python.
A présent nous il faut comprendre comment programmé la communication en MQTT. Tout d’abord nous cherchons à mettre en place un client dans le protocole MQTT. Pour cela nous utiliserons l’application MQTT Snooper.
Cette application Android permettra d’envoyer des messages sur un topic, par exemple « projiut/snap ». Nous pourrons alors envoyé un message qui servira d’ordre au Raspberry.
Cependant ce message doit être lue par le Raspberry et après avoir lu le message le Raspberry doit exécuté une tâche qui est par exemple la capture d’une image.
Afin de faire transiter les différents messages nous utilisons le serveur de test « test.mosquitto.org ». Celui -i nous permettra d’envoyer es ordres sur le Raspberry. Cependant pour renvoyer l’image nous ne pourrons utiliser cette solution.
En effet le serveur de test serait accessible à tout le monde et ce n’est pas ce qui est voulu. De plus nous n’avons pas la possibilité d’ouvrir un port sur le réseau de l’UHA, ceci engendrerait la mise en place d’un protocole de sécurité trop important pour la réalisation de ce petit projet.
Nous avons donc décidé de renvoyer l’image à travers la messagerie Gmail. On retrouve le code python permet d’envoyer un mail ci dessous.
Ainsi lors de l’envoi d’un message sur le topic, nous capturerons une image puis nous enverrons celle-ci sur une adresse mail prédéfini. Une amélioration de ce système pourrait être que lors de l’utilisateur pourrait envoyer son adresse mail pour qu’on puisse envoyer à plusieurs utilisateurs.
Nous avons donc réalisé la partie acquisition et transmission de l’image. Il faut à présent gérer la partie commande du servomoteur. Le servomoteur présentera deux états, tout d’abord nous aurons un mouvement qui allumera la lumière pour la prise de la photo dans l’imprimante et enfin nous aurons un mouvement qui permettra d’arrêter l’impression.
Pour cela nous avons utilisé le code suivant :
Afin de commander le servomoteur nous lui envoyons des impulsions ce qui lui permet dans une position. Pour cela nous définissons un angle dans lequel le servomoteur doit se positionner.
Ci dessous nous retrouvons le schéma général de notre installation.
De plus vous pouvez retrouvez l’ensemble du code python ici.
Au cours de cette partie de programmation nous avons rencontrées de nombreuses difficultés puisque pour nous le Raspberry pi et le langage python n’étaient pas familier. De plus la mise en place de MQTT sur python a été la partie la plus difficile.
3.2 Réalisation des supports
Une fois toutes les pièces réalisées, nous avons donc pu faire l’assemblage du système où nous retrouvons les différents composants tels que :
Conclusion
Ce projet a été une expérience enrichissante du fait de la collaboration avec les étudiants du département Génie Mécanique et Productique mais également parce que nous avons acquis des connaissances très importantes dans le domaine de l’IOT. Ainsi nous maîtrisons à présent le langage python mais également le Raspberry Pi qui est un outils indispensable.
Le découverte du protocole MQTT est une véritable car en effet c’est un protocole très simple d’utilisation qui peut être mis en place d’un point de vue industriel mais également chez un particulier.*
Le système électrique avec le Raspberry Pi et la caméra fonctionne cependant la partie mécanique n’a pas été réalisé donc notre projet n’a pas pu être finalisé, c’est un point que nous regrettons puisque nous aurions apprécier voir l’aboutissement de notre travail.
Nous tenons à remercier Mr. CUDEL et Mr. VIGNE qui nous ont assistés et conseillés tout au long de notre projet. Nous tenons également à les remercier pour les connaissances qu’ils ont pu nous transmettre dans la gestion de projets.
Le projet FESTO consiste à automatiser entièrement une chaîne de montage. Nous avons choisi ce projet car il nous place dans une situation réelle qui pourrait être croisé en entreprise. Cela nous permet d’avoir un ancrage bien réel dans le monde industriel en plus du fait que l’on soit en apprentissage. Grâce à cela on pourra étoffer nos connaissances dans le domaine de l’automatisme industriel.
III/ Présentation
A/ Présentation du projet
Le projet a pour but d’automatiser la chaîne FESTO séparée en six modules allant du poste de distribution au poste de stockage, en une chaîne de production entière en ajoutant des éléments permettant de suivre et de simplifier la production. Deux types de pièces seront traités, les pièces noires, et les pièces blanches.
Les fonctions d’automatisme sont gérées par des automates S7-1214 du constructeur Siemens.
Architecture du réseau
B/ Poste de distribution
Ce poste permet d’alimenter pièce par pièce le système de fabrication. Les pièces proviennent d’un conteneur cylindrique. Elles tombent dans une cavité. Un capteur permet de détecter la présence d’une pièce ou non. Un vérin extrait la pièce de la chambre afin qu’un bras oscillant équipé d’une ventouse transfère la pièce vers le poste de mesure.
C/ Poste de mesure
Ce poste permet de tester certaines caractéristiques physiques des pièces issues du poste de distribution. Suite à ce test, les pièces dont la hauteur est trop haute sont mises à l’écart alors que les pièces validées sont envoyées vers le poste d’usinage.
D/ Poste d’usinage
Ce poste permet de simuler l’usinage des pièces. Il est composé de trois fonctions distinctes :
Un palpeur qui nous permet de détecter le fait que la pièce soit pleine ou non
Un taraudage qui simule l’usinage de la pièce
Une éjection qui transmet la pièce usinée vers le poste de placement
Ces trois fonctions peuvent être commandées simultanément et les pièces sont conduites d’une fonction à l’autre à l’aide d’un plateau tournant indexé.
E/ Poste de placement
Ce poste permet de placer des bouchons sur les pièces. Il est composé d’un tapis roulant qui permet de transférer les pièces, d’une butée qui permet d’arrêter les pièces devant le mécanisme de placement des thermomètres. Un effet venturi appliqué sur une ventouse permet alors de prendre un thermomètre, placé sur une rampe, et de l’insérer dans une pièce. A l’issue de ce placement la pièce poursuit son chemin sur le tapis roulant vers le poste de transfert.
F/ Poste de transfert
Ce poste permet de transférer les pièces issues du poste de placement vers le poste de stockage. Un capteur permet de détecter la présence d’une pièce à gauche. La pince pneumatique saisit alors la pièce et la transfère vers la droite. Une goulotte en position centrale peut servir de zone tampon lorsque les magasins de la zone de stockage sont pleins.
G/ Poste de stockage
Ce poste permet de stocker les pièces en fonction de leur couleur à la fin du processus de fabrication. Les pièces sont amenées par un tapis roulant. Deux capteurs sont utilisés, l’un permet de différencier la couleur de la pièce et l’autre sa matière tandis que deux aiguillages pneumatiques permettent de les faire glisser dans des compartiments différents.
IV/ Etude
A/ Analyse Fonctionnelle
1. Bête à corne
2. Diagramme Pieuvre
FP 1 : Automatiser la chaîne de production
FP 2 : Suivre la production de pièces
FC 1 : Interface de commande ergonomique pour l’utilisateur
FC 2 : Maintenance aisée en cas de défaut du système
FC 3 : L’opérateur doit être en sécurité lorsqu’il intervient sur la chaîne
FP : Fonction Principale & FC : Fonction Contrainte
3. Diagramme FAST (Function analysis system technique)
La technologie RFID (radio frequency identification) :
Cette technologie permet une mise en place de la traçabilité dans la production. Les pièces seront marquées en amont de la chaîne de production, on pourra y lire la date de début de production et la commande à laquelle cette pièce se réfère. La pièce sera lue et une nouvelle fois marquée en sortie de production. La durée de production, ainsi que le temps de traitement de la commande pourront être déterminé pour optimiser le temps de production.
Module de liaison des têtes de lecture/écriture RF180C/RF120C
Tête de lecture/écriture
RF310R
La technologie Code barre :
Cette technologie permet une mise en place d’un système de commande utilisé pour lancer la production d’un nombre précis de pièce pour un certain client. On se sert d’un lecteur de code barre utilisant une liaison RS232 et d’un module de liaison série pour communiquer avec l’automate.
Ce code barre permettra de déterminer le marquage qui sera inscrit dans le tag RFID.
Module liaison série RS232 CM1241
La supervision de la production (IHM) :
La supervision permet à l’opérateur d’avoir une vision globale de la production permettant d’agir en cas de défaillance du système. On utilisera des SIMATIC Touch Panel comme interfaçage pour la chaîne de production.
IHM
Simatic Touch Panel
B/ Planning
On a établit un planning estimatif en différenciant toutes les tâches à réaliser pour mener à termes notre projet. Le planning est évolutif et est donc mise à jour régulièrement.
Des données vont devoir être transmises entre les automates afin d’assurer un fonctionnement convenable lors de l’assemblage de la chaîne de production.
Résumé des transits de données entre les automates des postes
D/ Lancement d’un cycle de production
Le départ du cycle de production est décidé par un code barre qui contient toutes les informations nécessaires à la réalisation de la commande émise par un client.
Il a fallu déterminer quel codage était utilisé pour pouvoir créer des codes-barres qui sont propres à ce que l’on souhaite.
Grâce à différents essais on a identifié le codage comme étant de l’EAN (European Article Numbering) qui est utilisé par le commerce et dans l’industrie. Nous avons opté pour un code barre utilisant le codage EAN 13, qui nous donne accès à 12 caractères changeables à notre guise et un bit de contrôle.
Suite à cela, nous avons pensé à une trame pour nos codes-barres qui contiendrait toutes les informations qui nous sont nécessaires.
La trame doit contenir : le numéro de client, la quantité de pièces pour notre premier type de pièces, le type de la première pièce, la quantité pour notre second type de pièces, le type de la seconde pièce.
Le type de pièce 1 correspond à des pièces blanches et le type 2 correspond à des pièces noires.
Exemple d’un code barre généré pour correspondre à nos attentes
E/ Plan de programmation
Un plan de programmation est défini pour avoir une programmation claire et distincte sur tous les postes.
On commence par l’élaboration d’un grafcet et on définit une architecture sur la quelle on peut se référer lors de la programmation des postes, ceci permet de simplifier les éventuels modifications en vue de dépannage.
Grafcet réalisé pour la programmation du poste d’usinage
Grafcet de conduite
Grafcet de tâche du perçage
Grafcet de tâche du palpage
Grafcet de tâche de l’éjection
F/ Schématisation de l’IHM
On réalise des schémas de chaque sous-système pour faciliter la supervision de la production. De plus, une vue sera faite pour contrôler la gestion de la production, les caractéristiques de la commande en cours, la gestion du stock ainsi que le temps qui a été mis pour compléter la commande.
G/ Conclusion à mi-parcours
Nous avons séparé le projet en deux grandes parties. La partie Etude qui consiste à se familiariser avec le projet, les technologies utilisées ainsi que tout ce qui touche à la gestion de projet. La seconde concerne la Réalisation. Elle consiste à programmer chaque poste ainsi que chaque IHM.
Nous arrivons presque à la fin de l’étude puisque nous nous sommes habitués aux technologies RFID et code barre, malgré quelques difficultés liées à l’écriture ou à la lecture sur le tag RFID dût à la programmation et au milieu où l’on souhaite agir sur nos tags. De plus, il nous reste à terminer la schématisation des interfaces graphiques pour nous mettre en accord sur les informations qui sont à mettre en avant ainsi que la façon dont elles seront mises en avant.
Nous aborderons la réalisation, dès que l’étude sera terminé. Nous commencerons dans un premier temps par programmer tout les postes indépendamment en incluant nos données qui devront s’échanger entre les automates. Puis, nous nous occuperons de la partie interface pour le suivi de la production.
Toutefois, notre projet peut être amélioré. En effet, nous avons pensé, dans la mesure du possible, à rajouter des éléments nous permettant de nous rapprocher d’un fonctionnement industriel. Ainsi, nous pouvons éventuellement intégrer un bouton d’arrêt d’urgence général qui nous permettrait d’arrêter le système entier en cas de défaillance, un mode de marche manuel qui serait piloté par l’IHM.
V/ Réalisation
A/ La séparation des tâches
La réalisation est séparée en différentes tâches. Dans un premier temps il a fallu programmer chaque poste. Cette tâche a été séparé afin que chacun d’entre nous puisse programmer les automates. Suite à cela, il restait deux points à abordés, la mise en place de la communication entre automate afin d’échanger les différentes variables permettant le transit des pièces à produire, qui a été réalisé par Romain, ainsi que la supervision du système de production, réalisée par Jocelyn.
B/ La programmation des postes
Nous avons réalisé les grafcets de chaque poste pendant la partie étude du projet (voir partie IV sous-partie E). Nous avons donc programmé chaque poste selon le/les grafcets réalisés.
Nous avons suivi une architecture commune pour la programmation de chaque poste.
Exemple d’architecture des blocs d’un programme API
C/ La communication entre automate
La communication entre automate consistait à faire se connecter chaque automate entre eux afin de bloquer les sous-systèmes si un de ces derniers est bloqué et qu’il ne peut prendre une pièce, on obtient alors un blocage du système en attendant l’acheminement de la pièce bloquante pour continuer son fonctionnement normal. On utilise pour cela un bloc de donnée et des variables pour gérer l’acceptation des pièce de chaque poste (voir partie IV sous-partie C)
Exemple d’un bloc fonction « GET » qui permet de chercher des variables dans un autre automate
Exemple de tableau crée pour l’échange de donnée
D/ La supervision
Nous avons créer une vue par sous-systèmes le tout centralisé sur un seul IHM, à cela nous avons ajouté une vue permettant de voir les information contenu dans le code-barre qui a été scanné et une vue pour la lecture du tag RFID. Nous avons donc huit vues possibles.
Vue de l’IHM permettant la lecture du code-barre et le départ cycle
Vue de l’IHM permettant la lecture du tag RFID
Vue du suivi du fonctionnement du poste mesure
VI/ Conclusion générale
Nous avons choisi de réaliser ce projet car nous souhaitions une situation se rapprochant le plus de la réalité
Ce projet nous a permis de revoir certaines notions abordées en cours d’automatisme et de supervision telles que :
Langage LADDER ou langage à contacts
Le grafcet de production normale et de conduite
Identifications des adresses entre les esclaves et l’automate.
La mise en place de la supervision d’un système
De plus, cette expérience a pu nous faire découvrir le domaine de la gestion de projet et d’aborder des connaissances comme les diagrammes de GANTT, les différents outils utilisés dans le cahier des charges comme la bête à corne, la pieuvre ou encore le FAST.
Nous avons eu l’occasion d’approfondir nos connaissances dans l’environnement logiciel du logiciel SIEMENS TIA PORTAL permettant de programmer les automates S7-1200 qui ont été abordé durant les travaux pratiques d’automatismes durant les semestres 2 et 3.
Nous tenons à remercier monsieur VIGNE et monsieur CUDEL qui nous ont suivis et consacrés leurs temps à nous aider durant ce projet.
L’origine du projet de drone est née lors de la première réunion GEII/GMP. Ayant tous un intérêt commun pour les drones, notre groupe s’est formé naturellement. Cette innovation au cœur des sujets d’actualité technologique embarque de l’électronique ainsi que de la mécanique. Pour ne pas faire un simple drone, nous avons décidé d’y ajouter une autre technologie à la mode : la réalité augmentée. Elle offrira au pilote une expérience de vol immersive en vue à la première personne (FPV, First Person Viewer). Le drone sera équipé d’une caméra dont le retour vidéo se fera sur smartphone. Il sera placé dans un casque de réalité augmentée type cardboard, qui sera adapté par nos soins pour accueillir les équipement nécessaires.
II. Les premiers pas
1.La gestion du Projet
Il nous semble nécessaire de faire une parenthèse sur l’organisation du projet suite à la coopération GEII/GMP. La première contrainte est la communication, donc nous avons mis en œuvre une solution. Pour un bon suivi du projet et une bonne organisation, un outil de gestion de projet a été mis en place dès la première séance. Celui-ci se nomme Propulse et se révèle être très complet. Il propose la création de tâche avec la possibilité de les affecter aux membres du projet. L’avancement est régulièrement mise à jour par le responsable de la tâche. Une description peut être ajoutée pour savoir exactement de celle-ci.
L’outil dispose aussi d’une partie « Wiki » ou nous pouvons partager toutes sortes de documents et y rédiger des notes.
2. Analyse fonctionnelle
3. Définition des limites du projet, réalisation du cahier des charges
Divers et varié sont les drones que nous trouvons actuellement sur le marché. Petit, moyen, grand, drone de course ou drone pour la prise de vue, nous avons dû faire un choix. Le budget étant limité et restreint, le choix d’un drone pour la prise de vue ne répondait pas à ce critère étant donnée les coûts onéreux d’une bonne caméra.
Nous voulions un drone unique, tout droit sorti de notre imagination. L’impression 3D est la technologie parfaite pour répondre à ce critère. Nous avons ensuite réfléchis aux autres problématiques que nous allions rencontrer et ainsi établir le cahier des charges suivant :
Fonctions
Critères
Niveau
Flexibilité
FP1 : Vol en immersion
Temps de vol
5 minutes minimum
F0
Portée du drone
Respect de la loi, le drone doit être garder en visuel
F0
Retour vidéo fiable
Pas de perte du signal vidéo
F1
FC1: Châssis ergonomique
Dimensions
20×20 cm maximum, taille du plateau de l’imprimante 3D
F0
Solidité
Choix d’un matériaux résistant
F0
Sécurité et protection de l’appareil
Armature permettant la préservation des hélices et des composants
F0
Pratique et optimisé
Placement des composants sans problème de place
F1
FC2: Alimentation
Alimentation côté drone
Alimentation 12V, capacité importante
F0
Alimentation côté retour vidéo
Alimentation 12V, capacité suffisante pour une session de vol
F1
FC3: Stabilisation
Quadricoptère
Réglage des moteurs 2 à 2
F1
Répartition du poids
De manière homogène de façon à ne pas provoquer de déséquilibre
F2
4. [Drone] – Choix des composants : Comment et Pourquoi ?
Châssis
Très vite, nous avions a cœur de concevoir et réaliser notre propre châssis en impression 3D. À la vue des caractéristiques de l’imprimante, nous devions faire un drone occupant un volume de 20cm3 comme précédemment indiqué dans le cahier des charges.
Ce fût le premier critère déterminant pour la suite. Il fera donc l’objet d’une partie à lui seul dans la suite du rapport.
Contrôleur de vol
Ce composant a été de loin le plus simple a choisir. Le contrôleur de vol est la carte mère du drone, le modèle NAZE 32, est un des plus réputé et des plus utilisé. Il permet d’embarquer une caméra et est très modulable en fonction des options voulues. Nous pouvons ajouter toute sorte de capteur télémétrique permettant de la prise de donnée dans des endroits inaccessible.
Moteurs
Le premier composant que nous avons choisis était les moteurs. En effet, la taille des moteurs doit correspondre à la taille du drone, nous avons donc fait nos recherches afin de comprendre comment nous devions choisir les moteurs.
Suivant les caractéristiques des moteurs que nous utiliserons nous serons capables de soulever un certain poids pendant un temps donné.
Plusieurs paramètres sont à prendre en compte. Chaque moteur ont une grandeur (le KV). Il s’agit du nombre de rotations par minute du moteur pour 1 volt. De manière générale, plus un moteur tourne vite moins il a de couple, et inversement. Un moteur avec un KV bas, pourra donc supporter de plus grandes hélices qu’un moteur à KV élevé. Un KV élevé est idéal pour une conduite réactive et nerveuse, un KV bas est idéal pour plus de stabilité. Pour un drone qualifié de mini quadricopter (environ 500g) le KV idéal est aux alentours de 2300.
Hélices
Les hélices sont choisies en fonction des moteurs. L’idéal dans notre cas est donc hélices 5“.
Nous pouvons ensuite nous poser la question du nombre de pale : Bipale ou Tripale ?
La différence est assez simple, si on augmente le nombre de pale, la portance et la réactivité de la machine seront améliorées. C’est un aspect avant tout bénéfique, mais il y a aussi un inconvénient de taille qui se trouve être la consommation en énergie. En effet, une hélice tripale va nécessiter beaucoup plus d’énergie qu’une hélice bipale. Notre priorité sera de privilégier l’autonomie du drone, d’où le choix des hélices bipales
ESC
Les ESC (Electronic Speed Controller) sont des composants électroniques qui servent de variateurs et permettent de réguler la vitesse des moteurs. Les ESC reçoivent une valeur par le récepteur de la télécommande via le contrôleur de vol pour ensuite faire tourner les moteurs à la vitesse désirée.
Il existe différentes sortes d’ESC sur le marché : les 12A, 20A et 30A sont les plus communs. Le choix se fait en fonction des caractéristique de nos moteurs. Il faut regarder le courant maximum consommé par les moteur, les notre se situent à 7.4A. Il faut donc choisir un ESC supérieur à cette dernière. Pour notre utilisation les ESC 12A suffiront. Il faut savoir que plus on monte en gamme, plus les ESC sont conséquents au niveau de la taille et de poids.
Batterie
Pour le choix de la batterie, nous nous sommes appuyé sur l’expérience d’autre utilisateurs pour faire notre choix. Les caractéristique technique de la batterie doivent correspondre aux éléments qu’elle alimente. Afin d’avoir une autonomie raisonnable, nous avons choisis une batterie de 1500 mAh. Nous nous sommes assuré que les connectiques correspondent à notre carte électronique et au chargeur.
Caméra
La caméra est de résolution modeste mais largement suffisante pour le pilotage. Nous avons opté pour un capteur CCD pour ne pas avoir l’effet rolling shutter. Le capteur dispose d’un champ de vision de 148°. Un émetteur avec une fréquence de 5,8 GHz est nécessaire pour ne pas interférer avec les fréquences des commandes qui sont en 2,4 GHz.
Bilan du poids des composants
Voici un premier bilan des composants permettant d’avoir une idée du poids total du drone. L’estimation rentre dans nos critères de ne pas dépasser les 500g.
5. Simulation de la configuration
Pour avoir un premier aperçu sur les performances de notre drone, nous avons rechercher à simuler ses performances. Pour cela nous avons trouver sur le net différents calculateurs et formules bien pratique.
Relation entre la consommation des moteurs et la batterie
Nous avons 4 moteurs consommant 72 Watt chacun, soit 288 Watt l’ensemble. Rappelons que notre batterie est une 11.1, 1500mAh.
– On divise la consommation des moteurs par la tension d’alimentation pour trouver l’ampérage :
P=U.I donc I=288/11.1=26 A
– Nous pouvons donc maintenant calculer l’autonomie à l’aide de simulateurs prenant en compte divers paramètres tel que le taille du drone, sa forme, le poids,…
En comparant les données entre plusieurs simulateurs de batteries nous remarquons que nous obtenons des valeurs de temps de vol quasi identique.
https://www.ecalc.ch/xcoptercalc.php
Cette dernière capture d’écran permet de voir des données beaucoup plus détaillé.
6. [Casque Réalité augmenté] – Comment le réaliser ?
Le concept du casque de réalité augmentée est assez simple à mettre en œuvre. Le but du jeu est de transférer le signal vidéo de la caméra sur un émetteur 5.8GHz et de le récupérer sur un récepteur de la même fréquence. A la sortie du récepteur nous récupérons le signal vidéo analogique que nous envoyons via une connectique type RCA sur un convertisseur numérique. Celui-ci dispose d’une sortie USB 2.0 ou nous allons connecter le smartphone via un câble USB 2.0 vers micro USB.
Après quelques recherche sur le net nous avons trouvé des applications permettant la visualisation en direct du signal émis par la caméra. L’application FPViewer à été retenu, car celle-ci possède plusieurs options gratuites, notamment le retour vidéo classique en pleine écran, mais aussi un mode « Cardboard » pour la réalité augmentée. De plus il est possible d’enregistrer directement les images de la caméra en mp4.
Pour résumé l’installation schématiquement :
III. Conception du Drone
1. Modélisation et impression du châssis en 3D
Premières idées et méthode de réalisation
Pour le sujet du châssis, dans une premier temps nous avons fait un travail commun pour regrouper les idées de chacun. A partir de cela nous avons définit l’aspect esthétique et les critères essentiels que le châssis devait comporter. Notre critère essentiel est de concevoir un châssis ergonomique et facilement adaptable de manière à pouvoir placer les composant comme on le souhaite. Nous accorderons aussi une importance à la solidité et la protection des éléments composant le drone, tout en restant le plus léger possible.
Nous avons pensé au tout début à construire un drone à assembler fait de bois, à l’aide d’une découpeuse laser de l’IUT Lab. Le poids du châssis aurait été correct, mais en cas de chute le bois aurait vite cassé. Notre choix s’est finalement porté sur le plastique. Le plastique étant une méthode moderne, précise, et pratique c’était la meilleure option. Il restait ensuite à choisir le plastique et l’impression. Nous voulions utiliser l’impression filaire pour un premier prototype. Cependant lors des premiers test de l’impression, l’imprimante 3D eu beaucoup de mal. Nous avons donc choisi l’impression stéréo-lithographique, avec polymérisation aux UV. Le résultat se révèle bien plus résistant, et précis.
Le principe de l’impression UV en question se déroule en 3 phases comme suit ; la buse apporte le polymère, un rouleau passe pour écraser la matière apportée, et une exposition UV polymérise la matière. Le plateau sur lequel la matière arrive descend à chaque couche, le buse reste au même niveau, et si besoin est, une matière support est créée à base de mélange du polymère à une matière soluble dans l’eau, sur laquelle la buse va pouvoir ensuite travailler, cette technique est utilisé pour imprimer des plans horizontaux par exemple, le nombre de couche est tel qu’à l’oeil nu il n’est pas possible de les discerner.
Modélisation du premier prototype
La première contrainte fut la taille du plateau d’impression. L’imprimante UV ne nous permet pas de dépasser une taille de 20cm². Nous voulions un drone carré, la taille a été limité à 19cm pour avoir une petite marge de sûreté.
Modélisé à l’aide du logiciel Catia V5, de Dassault Systèmes. J’ai décidé de concevoir un châssis tubulaire, pour réduire la surface d’impression (il faudrait utiliser beaucoup de matière support, donc beaucoup de perte ainsi qu’un coût plus élevé), et en même temps créer une rigidité conséquente. L’objectif était de réaliser un “panier » au centre, et quatre supports en ronds pour les moteurs. J’ai pris les mesures des trous nécessaires aux fixations des moteurs, et de la caméra. J’ai rencontré quelques problèmes dû à la méthode de modélisation des formes géométriques des tubes, et du gabarits de ces tubes. J’ai tout d’abord fais des esquisses sur papier, ensuite quelques essais sur le logiciel pour finalement utiliser une forme carrée simple, mais fonctionnelle. Pour le fond du panier, nous avons évoqué l’idée d’un quadrillage lors de la mise en commun. Cela donnera un aspect pratique pour attacher nos composants de la manière souhaitée dans celui-ci. Il m’a fallu pas loin d’une dizaine d’heure pour sortir une première version finale en partant du papier jusqu’au fichier CAO, le temps de reprendre la main sur le logiciel.
Version finale du premier prototype
Modifications du futur prototype
Malgré un rendu très satisfaisant, quelques problèmes ressortent vite.
Tout d’abord augmenter le carré, de 80mm à 100mm de côté, réorienter les croix de fixations moteurs en les tournant de 45 degrés pour avoir la sortie de câble des moteurs en face des branches, augmenter la hauteur du “panier”. De 10mm car la batterie choisie ne rentrait pas à 2-3mm près, et modifier les branches pour optimiser la fixation des ESC. Ensuite prévoir une fixation d’un « bumper », pour protéger les hélices. Ils se fixeront au niveau des fixations moteurs pour une facilité de montage. La grille de fixation composant le bas du “panier” sera imprimé à part. Lors de la première impression l’imprimante a du remplir le panier de support pour réaliser cette partie, nous souhaitons éviter un tel gaspillage de matière. Un système sera mise en place pour maintenir cette plaque.
Un première aperçu du du futur châssis, encore en cours de modélisation
Conclusion
Le plus gros du travail a déjà été fait, concevoir une base de châssis. Les tubes en 3x4mm sont solide, et le châssis est léger. Les premiers résultats sont très convainquant, il ne reste plus qu’a modifier ces quelques détails sur la prochaine version, puis le châssis final sera opérationnel. En attendant nous utilisons le premier prototype pour faire nos premiers testes d’assemblage. Il sera aussi utilisé pour les premiers tests moteurs.
Modélisation du deuxième prototype
Après avoir corrigé les problèmes précédents, j’ai continué les modifications en éloignant légèrement les bras de fixations au niveau des fixations moteurs, pour avoir une meilleur rigidité, et plus de place, et en rajoutant des sortes de rampes sous les bras de fixation pour venir fixer les ESC. J’ai consolidé aussi les pieds, car sur l’ancien modèle nous en avons cassé un facilement. La grille de fixation est resté sur le même principe.
Avec ce châssis la nous sommes sur la bonne voie pour faire voler cette machine droit.
Conception d’une nouvelle version de châssis
Une fois que cette version a été imprimé nous avons réalisé que les défauts remarqué sur le 1er sont corrigés mais il restais un problème sur le placement des composant à l’intérieur. Nous avons donc fait ce que nous aurions du faire depuis le début –> modéliser les composant en 3D à taille réelle afin de faire un montage numérique du drone et ainsi valider les cotes du châssis. Ce montage nous a contraint de réfléchir sur un autre type de châssis. Les châssis précédents étaient long a imprimer, 12H en moyenne, et coutaient plus de 15€. Nous avons donc conçus le châssis suivant, en longueur, pour avoir le plus de place possible.
Il sera imprimé en plusieurs parties, afin de gagner en temps d’impression et en coût de matière. Nous avons ensuite corrigé certaines caractéristiques comme le support de caméra ou encore les barrières de protection. Nous avons également mis des rainures de renfort sur la partie inférieur :
Ci dessus, une vue de l’assemblage avec les composants. Il ne reste plus qu’a finaliser quelques détails esthétique.
Version final du châssis du drone
Nous avons imprimé ce châssis, et il nous semblait parfait, spacieux, et rigide. Mais un collègue a mis en évidence une faille de rigidité au niveau des fixations moteurs, qui s’est avéré fatal. Nous avons donc dû réimprimer un châssis, en ajoutant toutes sortes de renforts, pour pallier à toute fragilité.
Et voila les rainures de rigidité, avec des parties pleines à l’endroit de fragilité des fixations moteurs.
Modélisation bumpers
Pour protéger les hélices et le châssis nous avons décidé de modéliser des bumpers, en voici les plans, nous allons les imprimer dès que possible.
2. Assemblage
Soudure des ESC au PDB
Les ESCs ont besoin d’être alimenté en 5V, on va donc les souder sur des sorties 5V, mais il faut faire attention à un détail : la disposition. Le drone présente une forme en X, il faut donc les placer de préférence dans chaque coin du PDB pour une organisation optimal pour une meilleure intégration au châssis.
Schéma récapitulatif du câblage des ESCs
Soudure du connecteur XT60 au PDB
Il ne faut absolument pas oublier cette étape, qui permet la mobilité de la batterie. Nous avons souder un connecter de type XT60 mâle, pour aller avec le connecteur XT60 femelle de la batterie et donc lui permettre d’être amovible. Le remplacement de la batterie, ou la charge sont donc facilités.
Ajout du connecteur sur l’entrée 12V du PDB
Alimentation de la caméra, soudure de l’émetteur vidéo
L’alimentation de la caméra se fait indirectement, car celle-ci est relié directement à l’émetteur vidéo via un connecteur. L’émetteur et la caméra nous demande 12V. Nous avons donc prévu un PDB à cet effet ayant la sortie nécessaire.
Ajout de l’émetteur sur une sortie 12V
Montage des moteurs sur le châssis
Soudure des moteurs aux ESC
3. Paramétrage de la radiocommande
La télécommande est une Flysky I6, le effectué et le lien entre le récepteur (cf photos point suivant) et la télécommande, une simple manipulation d’appairage.
Réglages fins de courses + Config radio CF
4. Configuration et câblage du Naze 32
Câblage du Naze 32 :
Ce contrôleur de vol est fournis avec un PDB (Power Distributing Board), la batterie alimente cette carte en 11V , le PDB distribuera l’énergie aux ESC. Les ESC soudés dessus permettent de réguler la tension d’alimentation afin de l’adapter pour les moteurs. Les moteurs sont soudés aux ESC (aux 3 fils noirs).
Les ESC ont des BEC intégrés ( Battery Eliminator Circuit), ce composant visible dans l’ESC permet d’adapter la tension d’alimentation venant de la batterie (11V) pour le moteur (intensité variable), on vas se servir d’un des 4 BEC pour alimenter la Naze 32 en 5V. C’est pour cela que nous avons garder des pin d’alimentation d’un ESC (voir photo ci dessus).
Par la suite il a fallu assembler la naze 32 avec l’ensemble « PDB ». Il suffiras de brancher le pin « signal » (orange) sortant de chaque ESC à la carte sans oublier les pins d’alimentation liant le BEC à la carte.
Paramétrage du Naze 32
Nous avons par la suite paramétré la carte de vol à l’aide de CleanFlight. Dans un premier temps nous avons réglé le PID de la carte de vol dans le but d’avoir un drone stable.
Dans CleanFlight nous avons accès à un réglage des valeurs pour le P, le I et le D correspondant à une correction dans les trois axes X Y et Z.
Notre carte de vol Naze 32 contient un accéléromètre. Ce dernier ce calibre également sous CleanFlight dans l’onglet Setup.
Voici les différents modes que l’on peut assigner aux switches de la télécommandes.
5. Phase de test
Avant de passer au test grandeur nature, nous avons réaliser via un logiciel de simulation de vol, des tests de la télécommande et nous en avons profité pour nous entraîner à piloter sur ce logiciel.
Voici ci-dessous les premiers test des moteurs. Nous avons voulut vérifier que notre drone démarre bien suite à l’amorçage des moteurs via des switches sur la télécommande.
IV. Conception du casque de Réalité augmentée
1. Réalisation du casque
Nous avons décidé d’utiliser une autre technologies pour la construction du masque. Il seras découper par laser et seras fait en bois. Nous avons dessiner chaque pièces sur Creo, en étant vigilant a respecter le cahier des charges. Sur la photo suivante nous avons caché le haut du masque afin de voir l’intérieur. Le téléphone seras debout dans la partie grise (imprimé en 3D). A l’aide de rainures qui laisserons dépasser des ergots, nous serons capable de régler la position du smartphone.
2. Mise en place du retour vidéo sur le smartphone
Le retour vidéo sur smartphone s’effectue grâce à deux ensembles:
Un ensemble composé de la caméra et de l’émetteur avec son antenne qui émet sur une fréquence de 5.8 GHz, relié à une batterie provisoire pour les essais puis seras directement branché sur le PDB par la suite. Nous avons choisit 5.8 GHz comme fréquence car la fréquence 2.4 GHz est déjà utilisée pour le récepteur/transmetteur et par la télécommande servant à piloter le drone. Pour éviter d’avoir des interférences entre les deux couples récepteurs/transmetteurs nous avons choisit une fréquence bien plus élevée pour la partie vidéo.
Un autre ensemble composé du smartphone, un récepteur vidéo 5.8 GHz relié au convertisseur analogique numérique qui lui est branché au smartphone par un câble Micro USB/USB. Cet ensemble est alimenté par une batterie 11.1V 800mAh.
La liaison entre l’émetteur et le récepteur est très simple: il suffit d’alimenter le récepteur et l’émetteur puis de rechercher sur le récepteur le bon canal d’émission de la caméra.
De nos jours, l’automatisation de process devient une pratique de plus en plus courante. De la fabrication automobile à la régulation de température dans nos maisons, l’automatisation est omniprésente. Quand nous pensons aux cocktails, nous visualisons une préparation manuelle qui nécessite une certaine expérience.
C’est pourquoi nous avons comme projet de développer une machine à cocktails automatisé, pour montrer que l’automatisation peut être utilisée dans des domaines diversifiés et non essentiellement dans le domaine de l’industrie tout en faisant découvrir l’automatisation à un large public au travers d’un moyen ludique.
Grâce à ce projet nous allons pouvoir découvrir la dextérité et l’organisation que demande la conception complète d’une machine. De plus, nous allons pouvoir nous expérimenter dans les domaines mécaniques et électriques tout en développant le travail d’équipe.
L’équipe du projet est constituée de 2 étudiants GMP et 2 étudiants GEII.
GMP : Damien et Jeremy
GEII : Pierre et Nicolas
II. ANALYSE FONCTIONNELLE :
Avant d’établir un cahier des charges, nous avons voulu exprimer en premier lieu le besoin pour cette machine. C’est pour cela que nous avons établi une bête à cornes :
Suite à ce schéma nous avons pu réfléchir sur les liens entre le système et son environnement. Donc nous avons réalisé un diagramme pieuvre afin de recenser les fonctions du système.
Pour finir nous avons rédigé un cahier des charges raisonnable sur la conception de la machine. C’est grâce à ce cahier des charge que nous allons pouvoir faire le choix de nos équipements et des matériaux qui vont constituer la machine.
Cahier des charges :
Fonctions de services
Critères
Niveau d’exigence
Flexibilité
FP1 : Servir un cocktail à l’utilisateur
Temps du service
Environ 30 secondes
F3
Qualité
Respect de la commande
F0
FC1 : Préparer un cocktail en autonomie
Autonomie
Aucune intervention de l’utilisateur
F0
Gestion d’un programme
Automate
F0
FC2 : Doser les cocktails
Quantité en cL
+/- 0.5 cL
F2
FC3 : Respecter les normes d’hygiène
ISO 14001 / ISO 9001
F0
FC4 : Doit être simple d’utilisation
Interface de commande
Tactile (IHM) + Boutons
F0
FC5 : Déplacer le shaker
Déplacement transversal
Courroie
F0
Vitesse
0.05 m/s = 5cm/s
F2
Support
Dimension d’un shaker
F1
FC6 : Être alimenté en énergie
Alimentation système
230V AC
F0
Alimentation électrovannes
24V DC
FC7 : Assurer plusieurs services
Volume des contenants d’alcool
1 L
F1
Volume des contenants des diluants
3 L
F2
FC8 : Être esthétique
Câblage
Bon câblage, ordonné
F0
Montage de la machine
Propre, sans rayure, sans casse
Légende : -FP : fonction principale -FC : fonction complémentaire
-Classe de flexibilité :
0.Flexibilité nulle-Niveau impératif
1.Flexibilité faible-Niveau peu négociable
2.Flexibilité bonne-Niveau négociable
3.Flexibilité forte-Niveau très négociable
Pour ce projet nous avons décidé de toujours travailler en binôme afin de pouvoir avoir un autre avis lorsque l’on conçoit quelque chose.
Les binômes et leurs rôles sont :
-GMP : entière conception de la machine du point de vue mécanique (taille, matériaux, forme).
-GEII : entière conception de la machine du point de vue électrique (choix des composants électriques, câblage, programmation).
III. RÉALISATION DU PROJET :
3.1 Partie génie mécanique :
Tout d’abord nous avons du rassembler toutes nos idées. C’est à dire sa structure de base, comment le verre va se déplacer et où nous allons mettre les bouteilles. Nous sommes parti sur une machine de base rectangulaire avec un déplacement moteur+courroie pour le verre et nous avons mis les bouteilles en hauteur pour utiliser la gravité.
Ci-dessous la première esquisse de la forme de la machine :
C’est à partir de l’idée du déplacement du verre par courroie+moteur que nous avons eu comme idée de démonter une imprimante A0 non fonctionnelle pour récupérer le système du chariot et l’adapter sur notre machine. Ci dessous des images du démontage de l’imprimante :
Voici la modélisation de l’adaptation du système de déplacement du verre :
Ensuite est venu la réalisation, avec les photos ci-dessous nous allons vous montrer les étapes pour réaliser la machine :
Mise en place du système moteur+ courroie avec le chariot
Mise en place du système pour tenir les bouteilles à l’envers.
Pour finir voici une image de la partie mécanique terminée.
3.2 Partie génie électrique :
Pour débuter la partie électrique, nous avons listé tous les composants nécessaires à la réalisation :
Automate programmable => Afin de gérer le programme, les recettes et le déplacement
Interface Homme Machine => Ecran tactile permettant à l’utilisateur de choisir son cocktail
Moteur => Pour la déplacement du chariot
Électrovanne => Pour laisser passer ou pas le liquide
Relais => Pour l’inversion moteur, pour que le chariot puisse aller à droite ou à gauche
Fin de course => Mise à 0 de la position
Alimentation 24VDC => Pour alimenter notre système
Bouton poussoir => Bouton start
Bornier
Capteurs infrarouge => Pour le positionnement du chariot sous les bouteilles
Nous pouvons voir sur l’image ci-dessus tous nos composants électroniques. De gauche à droite : Le bornier, un disjoncteur, l’alimentation, l’automate puis le relais.
Ici nous pouvons voir une image des électrovannes cachées dans une goulotte électrique.
Pour finir voici une image du projet terminé.
IV. CONCLUSION DE NOTRE PROJET :
Grâce à ce projet nous avons pu voir la dextérité que demande la création d’une machine de A à Z, nous avons aussi pu voir que le travail en groupe est quelque chose d’important.
Pour au mieux conclure ce projet, voici un lien d’une vidéo montrant notre machine fonctionnelle : https://www.youtube.com/watch?v=WMygkw-IFeg&feature=youtu.be
La CanSat se développe dans le cadre d’un concours. Ce concours se déroule sous forme d’une compétition entre plusieurs écoles et/ou associations de particuliers. Le concours fixe plusieurs missions à effectué, le but étant de mener à bien le plus de missions possible. Selon le niveau auquel se déroule le concours, on impose le volume maximal dans lequel doivent s’articuler l’ensemble des composants choisis par les participants. En ce qui concerne notre CanSat, nous avons choisi d’opérer dans un 1L de contenance afin de pouvoir mettre en oeuvre l’ensemble du matériel nécessaire pour répondre aux mission que nous avons nous même défini.
II. Contexte
Afin de clôturer notre 2e année d’apprentissage, nous avons du choisir une idée de projet à réaliser. Ce projet devait se dérouler sur 60h, avec de groupes de 2 à 4 étudiants composés d’étudiants en GEII et d’étudiants en GMP, le tout sur une période d’octobre 2016 à mai 2017. Etant donné du faible volume horaire, et de la participation du département GMP, il a fallut rapidement s’organiser pour pouvoir travailler efficacement
III. Le cahier des charges
A. Les idées
N’étant pas contraint par les règlements du concours, nous avons pu décider librement de la conception de notre CanSat. Cependant nous nous sommes imposés la contenance minimale, à savoir 1L comme seule règle. Nous nous sommes ensuite sur les points suivants ; notre CanSat devra :
Etre capable de mesure de de grandeurs physique en temps réel telles que : La Température, la pression, la luminosité, l’accélération, l’humidité, la position
Avoir une autonomie suffisante pour monitorer les données pendant 3j
Transmettre les données en temps réel via un application au sol
Etre capable de supporter des chocs sans impacter les composants embarqués
Avoir une masse inférieur à 1kg
Avoir une hauteur maximale de 200mm et un diamètre de 80mm
Intégrer un parachute dont la masse ne doit pas excéder 1Kg
Avoir une structure ouverte pour faciliter les mesures des capteurs
Etre réutilisable
L’ensemble des réflexions peuvent être brièvement résumées par le schéma suivant :
Cependant, nous nous sommes réserver la possibilité d’ajouter des capteurs/modules au cours du projet, comme par exemple la mise en place d’une caméra par exemple.
B. Les solutions
1. Partie GeII
Nous avons choisi de réaliser ce projet en se basant sur un Raspberry pi 0. En effet, sa facilité de mise en oeuvre nous permets une grande flexibilité quand à la manière de mettre en oeuvre l’ensemble de nos capteurs. Aussi, la facilité d’utilisation du Raspberry ainsi que de ces cartes d’extensions nous à permis d’avancer rapidement lors du projet. Voici donc à quoi ressemble le cerveau de notre projet :
Le raspberry pi 0. Nous l’avons choisi notamment pour sa taille très réduite et sa consommation minime, parfaite pour concevoir un appareil avec une bonne durée de vie.
L’enviroPHAT, qui est une carte d’extention du raspberry pi 0. Cette carte rassemble une grande partie des capteurs dont nous avions besoin pour mesurer :
La temperature
La pression
La luminosité
L’accélération
L’enviroPHAT est facile d’utilisation, il utilise un bus I2C pour communiquer avec le raspberry.
Pour les mesures d’humidité, nous utiliserons une sonde d’humidité comme ci-dessous
Afin de pouvoir communiquer avec la CanSat une fois en l’air, et récupérer les données qu’elle mesurent, nous avons utilisé des modules XBEE S2C fonctionnant en 2.4 Ghz, d’après la suggestion de nos professeurs
Une fois configuré correctement, le module xbee permet d’émettre des informations a plus de 1km de portée en simulant une communication série. L’idée était donc d’utiliser 2 modules XBEE : un directement intégrer à la CanSat, et l’autre branché à un PC au sol. Cette installation permet de monitorer les valeurs relevés par la CanSat lorsqu’elle est en fonctionnement. Pour plus de sécurité, la communication est chiffré en AES 256.
Pour alimenter le projet, nous avons utiliser 4 batteries en parallèle
Ce sont des batteries Li-Ion produites par Samsung. ces batteries délivrent 3,7V et jusqu’à 2500mAh. D’après nos calculs, nous avons estimé la durée de vie de la CanSat à 4,5j d’autonomie grâce à ces 4 batteries. Ce qui est largement suffisant pour remplir nos conditions.
Enfin, nous avons utiliser un hacheur pour palier aux problème de tensions, notamment entre le raspberry pi zero et le module XBEE
C’est un hacheur Boost DC-DC pouvant convertir du 3,3V en 7V et du 5V en 9V. Il fonctionne avec de faibles intensité, et permet de centraliser l’alimentation de la CanSat.
2. Partie GMP
Nous avions différents idées pour la conception de notre Can-Sat. C’est pourquoi nous avons tout d’abord échangé nos idées à l’aide de croquis.
Solution 1Solution 2Solution 3Solution 4
Les solutions 1,2,3 utilisent le même principe. Une partie inférieure en un seul bloque usiné pour avoir un gain de matière. Une partie supérieure avec une platine permettant de fixer le raspberry. Cependant il est très difficile d’usiner ce type de bloc.
Après discussion entre nous et les professeurs, nous avons choisis la solution 4. Celle-ci est la plus simple à réaliser. Elle est composée de deux platines circulaires, 3 tiges filetées et de support pour le raspberry. Nous avons donc plusieurs petits éléments facile à réaliser, à assembler et modulable.
Voici le modèle 3D de la CanSat :
III. Le développement
A. Partie Electrique
Nous pouvons dégager 2 grandes partie dans la conception du projets :
La programmation du Raspberry pi et des capteurs environnants
La conception du Hacheur
Nous avons décidé de travailler ensemble sur les deux sujets de manière parallèle mais avons défini une personne en charge principal de chacune de ces deux tâches : Victorien pour la partie programmation et Alexandre pour la conception du hacheur.
La programation du Raspberry se fera en python. Ce langage à été choisi pour sa facilité de mise en oeuvre avec la carte d’extension.
Le programme sera composée de différente étapes avec des transitions à la manière du langage Grafcet.
Ces étapes permettront de définir dans quel état se trouve la Cansat (phase ascendante/descendante etc) et ainsi éviter un état non défini.
Les transitions se feront grâce aux relevés des différents capteurs.
Pour la communication des données, nous avons déterminer une trame type qui permettra de mettre en forme les données et ainsi les communiquer au PC via une liaison série puis sans fil grâce au Xbee.
Toutes les valeurs mesurées seront aussi enregistrées dans la carte SD du Raspberry pi pour pouvoir les exploiter après la mission.
Afin de mettre en oeuvre notre hacheur, nous avons choisi d’utiliser un circuit imprimé faisant office de régulateur , un MC34063. Cela implique tout un travail de dimensionnement des composants qui viendront s’implémenter autour du régulateur comme le montre le schéma suivant :
Figure 2. :Schéma général du régulateur en mode hacheur
Une fois le hacheur conçu, il sera testé et ensuite intégré à nos prototypes de CanSat. Nous envisageons à termes de faire concevoir un PCB par une société afin d’améliorer la qualité de notre hacheur.
B. Partie Mécanique
La conception commence par des croquis pour voir les différentes idées.
Nous avions différentes idées pour la conception de notre Can-Sat. C’est pourquoi nous avons tout d’abord échangé nos idées à l’aide de croquis.
Solution 1Solution 2Solution 3Solution 4
Les solutions 1,2,3 utilisent le même principe. Une partie inférieure en un seul bloque usiné pour avoir un gain de matière. Une partie supérieur avec une platine permettant de fixer la carte électronique. Cependant il est très difficile d’usiné des blocs comme ça.
Après discussion entre nous et les professeurs, nous avons choisis la solution 4. Celle-ci est la plus simple à réaliser. Elle est composée de deux platines circulaires, 3 tiges filetés et de support pour la carte électronique. Nous avons donc plusieurs petits éléments facile à réaliser, à assembler et modulable.
La conception de la CANSAT est terminée, les plans sont en cours de validation pour pouvoir produire nos pièces et ensuite assembler la CANSAT.
Nous avons aussi commencé à chercher des solutions pour la réalisation de notre parachute, mais la conception finale, le dimensionnement et la réalisation du parachute reste à faire.
Le robot BB8, connu pour ses parutions dans la célèbre saga Star Wars, est à l’origine de notre projet. Nous avons entrepris de reproduire un système de la sorte pouvant se définir comme un robot « boule ».
Ce système ayant déjà été reproduit par plusieurs personnes, mais n’ayant trouvé aucune base suffisamment documentée, nous avons décidé de concevoir de A à Z notre propre BB8, d’après nos propres idées, en nous inspirant bien évidemment des systèmes existants.
Ce projet consiste en la réalisation d’une sphère creuse dans laquelle vient s’insérer un système complet, lui permettant de se déplacer suivant plusieurs axes. Cette sphère sera télécommandée par un appareil mobile (tablette ou smartphone) à l’aide d’une application dédiée.
Grâce à ce projet, nous allons pouvoir découvrir le travail nécessaire à la conception complète d’un système, de la définition de son cahier des charges à sa mise en oeuvre, ainsi qu’à l’organisation que cela implique. Ce projet va également nous permettre d’améliorer nos capacités à travailler en équipe. Nous avons l’opportunité de mettre en commun le génie mécanique et le génie électrique dans ce projet, ce qui nous permettra de mettre en avant et de combiner les compétences et savoirs de chacun.
Membres du projet :
Pierre JAEGLE, étudiant en 2e année de Génie Mécanique et Productique
Arnaud STEINMANN, étudiant en 2e année de Génie Mécanique et Productique
Marion HELL, étudiante en 2e année en Génie Electrique et Informatique Industrielle
II. Pré-étude
1. Cahier des charges
FS
Fonction
Critères
Niveaux
Flexibilité
FP1
Déplacer BB8 dans l’espace
Durée
Autonomie 30 min
F1
Mouvement linéaire assuré
Absence d’oscillation
F0
Trajectoire dirigée
Commande par application de téléphone
F1
FC1
Dimension
Sphérique
Sphère extérieure
F0
Rayon
297 mm maxi
F0
FC2
S’adapter au terrain
Surface plane en intérieur
FC3
Utiliser une source d’énergie électrique
Stockage d’énergie
Electrique
F0
Transmission de cette énergie
En énergie mécanique
F0
FC4
Aspect esthétique donné à l’objet
Correspond aux goûts communs
Esthétique
F2
FC5
Employer un budget maximal
Coût
150€ maxi
F2
FC6
Communication
Enveloppe permettant de transmettre les signaux nécessaires
Signal Bluetooth
F0
FC7
Assurer la stabilité
Répartition des masses homogène
Stabilité et équilibre vérifié
F1
Les contraintes :
La conception d’un tel projet nécessite la prise en compte de plusieurs contraintes. Le robot se déplacera dans un environnement ouvert, il devra donc être en mesure de s’adapter à différents types de sol. Ces sols étant parfois irréguliers, il devra être en mesure de rester stable lors de ses déplacements.
Le robot sera piloté par différents sous-ensembles électroniques, commandés par un microcontrôleur programmé situé à l’intérieur de la sphère. Une application smartphone sera développée pour communiquer avec le robot et piloter ses déplacements. La communication entre le robot et sa commande à distance s’effectuera par liaison Bluetooth.
Les solutions :
Il nous faudra faire particulièrement attention lors de la conception des différentes pièces afin de réussir à équilibrer l’ensemble. Nous allons dans un premier temps concevoir le maximum de pièces symétriques pour obtenir un point de gravité central. Nous prévoirons des emplacements permettant l’ajout de cales pour ajuster l’équilibrage final de l’ensemble, afin de compenser les éventuelles imprécisions de calcul et de fabrication des pièces.
Pour permettre le passage des signaux, nous devrons choisir un matériau perméable aux ondes Bluetooth.
2. Répartition des tâches
III. Conception
1. Choix de solutions
Partie mécanique
Première étude
Partant de zéro, la plus grande partie de notre travail a été de définir comment concevoir la structure d’un robot sphérique, avec la recherche de solutions permettant un bon fonctionnement de l’ensemble. Pour nous aider dans cette tâche, nous avons conçu l’ensemble en 3D sur ordinateur.
Le travail de recherche nous a pris un temps considérable, il nécessite de prendre en compte de très nombreux paramètres qui influeront sur le bon fonctionnement du système.
Après une longue réflexion, nous avons décidé de concevoir notre BB8 de la manière suivante :
Notre système se présente ainsi, nous avons deux demi-sphères à droite et à gauche qui seront sur leurs extrémités « encastrées » avec la paroi intérieure de la sphère. Dans ces deux demi-sphères, on trouve un logement dans lequel viendra se positionner un roulement.
La pièce principale ci-dessus que l’on peut désigner tel un axe, possède de chaque côté une barre de stub, permettant le montage de roulements. Les stubs seront emboutis dans la pièce principale et une fois les roulements montés sur les stubs, on assemblera l’ensemble dans les demi-sphères.
Les deux moteurs que l’on aperçoit ont chacun une fonction bien précise, celui du bas permettra grâce à un déséquilibre et un entrainement sur la paroi intérieure de la sphère sans glissement, de créer un mouvement selon une direction. La roue en bout d’axe n’est pas encore modélisée. Le moteur du bas sera fixé à l’aide d’une tige sur mesure.
Le moteur du haut permettra, lui, grâce à un axe et des masselottes sur chaque extrémité (pas encore modélisés) de créer une rotation de l’ensemble en fonction de la puissance transmise au moteur. Ce dernier sera fixé sur une plaque, qui sera positionnée à l’aide de deux étirés.
Solution adoptée
Pour des raisons d’équilibre, d’ergonomie et de fonctionnement la conception de notre ensemble a été modifiée une dernière fois pour obtenir une version optimale. L’avis de nos enseignements fut pour cela très utile. Cette conception va permettre de disposer la batterie sous l’axe principale et donc de le placer au plus bas et diminuer la hauteur du centre de gravité.
Les dimensions de la pièce principale ont été modifiées pour des raisons de poids et donc d’équilibre. La pièce initiale était trop imposante. Ci-dessous la nouvelle pièce principale. La surface principale doit être conservée car c’est elle qui va permettre de supporter la carte Arduino.
La deuxième grande modification concerne la fixation du moteur inférieur. Nous avons décidé de concevoir un système permettant un ajustement du contact entre la roue et la surface intérieure de la sphère.
Pour cela les deux étirés vont traverser la plaque centrale et vont permettre un ajustement suivant l’axe Y de l’ensemble par rapport à la plaque principale à l’aide d’une vis de pression.
Un méplat a également été réalisé sur les étirés pour le blocage.
Pour limiter la taille des plaques que l’on peut voir en haut et en bas, un taraudage sera réalisé sur chaque extrémités des étirés.
Pour les roulements, nous avons décidé de réalisé un montage en X, un épaulement dans les deux logements des demi-sphères va permettre un arrêt sur la bague extérieur et un épaulement sur les deux arbres, l’arrêt sur la bague intérieur.
Nous avons également choisi deux barres d’étirés pour le montage des roulements au lieu du STUB choisi dans la solution précédente (les barres d’étirés étant beaucoup moins chères).
Vous pouvez voir ci-dessus les tiges d’étirés sur lesquels nous allons monter les roulements.
Nous avons cependant décidé de garder la solution de montage des deux arbres. Ils seront montés serrer dans la pièce principale.
Concernant la plaque inférieure qui va supporter la batterie. Nous avons réalisé un trou oblong pour permettre de régler la position de la roue du moteur au niveau du contact avec la surface intérieure de la sphère. Vous pouvez voir la solution ci-dessous.
Partie électronique
Le microcontrôleur
Afin de piloter les différents éléments, nous avons opté pour l’utilisation d’une platine de type « Arduino UNO ». Les modules Arduino sont des plate-formes de prototypage microcontrôlées « open-source ». Nous avons choisi ce module pour sa facilité d’utilisation, son faible coût, ainsi que sa mise en oeuvre rapide. La bibliothèque de développement Arduino, très complète, permet de configurer de manière simple les différents ports d’entrées/sorties du microcontrôleur présents sur la carte. Ces ports sont utilisables via des connecteurs femelles présents sur le bord de la platine, permettant ainsi de connecter différents équipements ou capteurs.
Un outil de développement est mis à disposition pour les utilisateurs d’Arduino et permet de programmer en langage C++.
La communication
Cette carte n’étant pas équipée de module de communication sans fil, nous l’avons connectée à
un équipement Bluetooth, de type « HC-05 ». Le protocole Bluetooth fonctionne comme une communication série bidirectionnelle. La plupart des équipements mobiles étant équipés de communication Bluetooth, il sera donc facile d’appairer un appareil afin de piloter notre robot. Nous avons choisi de développer une application smartphone plutôt qu’une télécommande dédiée afin d’assurer une modularité au fonctionnement de notre robot. En effet, si nous souhaitons faire évoluer son fonctionnement, il sera plus simple de modifier une partie programmation (software), que l’implémentation hardware et software d’une carte électronique.
La commande des moteurs
Nous avons choisi d’équiper notre robot de moteurs à courant continu. Pour en faire varier la vitesse, le module Arduino dispose de sorties « PWM » (signal à rapport cyclique variable). Il est cependant nécessaire d’utiliser une carte d’interfaçage, puisque la consommation en courant des moteurs est nettement supérieure à celle supportée par les ports de sorties de la carte, ce qui serait destructeur pour cette dernière.
Pour cela, nous utiliserons un montage « pont en H ». En plus de protéger le microcontrôleur, ce montage nous permettra de piloter le moteur dans les deux sens de rotation, mais également d’obtenir ce que l’on appelle un « frein magnétique », en fonction des transistors pilotés :
Nous avons sélectionné le composant « L293D » pour notre montage. Ce composant est un « quadruple demi-pont en H ». En utilisant deux demi-ponts par moteur, nous aurons donc 2 ponts pour les piloter, indépendamment l’un de l’autre.
Toujours dans un souci d’ergonomie et de rapidité de mise en oeuvre, nous avons trouvé un « shield » dédié, à connecter directement à notre module Arduino. Celui-ci comporte différents connecteurs pour le branchement des moteurs, ainsi que pour connecter une alimentation externe.
L’alimentation électrique
Une batterie sera chargée d’alimenter l’ensemble de l’électronique. Cette batterie devra être d’un encombrement modéré, et fournir une autonomie suffisante au robot. Son implantation dans la sphère devra permettre d’y accéder facilement afin d’en effectuer la recharge ou son remplacement.
IV. Fabrication des pièces
Lors de la fabrication des éléments conçues nous avons utilisé différents procédés pour obtenir les pièces souhaitées:
L’usinage
Moulage par moule perdu
Les machines principalement utilisées sont les suivantes :
la découpeuse jet d’eau
perceuse à colonne
fraiseuse traditionnel
tour traditionnel
tour à commande numérique
scie à bande
1. Méthode
L’IUT disposant d’un parc machine important et d’ateliers divers, nous avons exploité les ressources disponibles :
Parc machine GMP
IUT Lab
Atelier SGM
C’est à partir des machines disponibles que nous avons créé nos procédés.
Lors de nos procédés nous avons choisi les éléments pour correspondre le plus près possible aux éléments normés, et ainsi réduire les coûts et délais.
Moulage des demi-sphères extérieures :
Pour cela nous acheté des demi-sphères en polystyrène, de la résine époxy et nous nous sommes fournis en fibre de verre, puis nous avons effectué un montage collé avec celle-ci.
Nous avons tout d’abord procédé à une première couche de résine sur la demi-sphère. Puis par succession de couche de fibre de verre et de résine époxy, la fibre de verre étant préalablement découpé pour correspondre aux dimensions et à la forme de la demi-sphère.
Après quelques jours de séchage nous avons procédé à la découpe de la demi-sphère puis à leur ponçage.
2. Programme
Deux programmes de commande numérique ont été réalisés :
programme de tour à commande numérique pour réaliser les demi-sphères intérieures.
programme fraiseuse à commande numérique pour la plaque axe principale. Ce dernier à été testé mais n’a pas fonctionné du à des efforts de coupe trop importants dans le sens opposé au fond de l’étau. Ceci à éjecté la pièce. Nous n’avons pas pu continuer le travail car le CU72 est tombé en panne.
La réalisation des pièces s’est effectué normalement.
Pour réduire les usinages de l’ensemble des pièces simples, nous avons défini les épaisseurs directement aux côtes du brut.
V. Montage
Une fois les pièces créées, nous avons pu passer à l’assemblage. Ci-dessous la vue des différentes pièces ainsi que d’un montage provisoire du robot.
Le câblage entre les différents éléments a été réalisé par la même occasion. Il a alors s’agi de relier l’Arduino (équipé de son shield moteur) au module Bluetooth, à la batterie, ainsi qu’aux moteurs.
VI. Partie programmation
Le robot étant pré-monté, nous avons pu effectuer les essais logiciels et tester la commande du robot à distance. Nous avons alors du programmer notre module Arduino pour que le robot réponde de la bonne manière à une commande réceptionnée.
La programmation de l’Arduino a permis de :
Gérer les ports d’entrées et sorties de l’Arduino
Gérer la liaison série (Bluetooth)
Gérer la communication (réception de trames)
Piloter les moteurs
1. Structure du programme
Le programme réalisé s’est structuré de la manière suivante :
1. Configuration (Bluetooth, entrées et sorties du modules Arduino)
2. Attente de la réception d’une trame
3. Après réception, vérification du contenu (début et fin de trame) puis sauvegarde de la valeur
4. Exploitation des coordonnées : récupération et séparation des coordonnées en x et y puis conversion
5. Commande des moteurs en fonction de l’instruction reçue
Les programmes Arduino se séparent en deux boucles principales distinctes :
La fonction « setup », qui correspond à l’initialisation du module. Cette fonction n’est effecuée qu’une fois au démarrage de l’Arduino. C’est dans cette fonction que l’on effectuera la première étape.
La fonction « loop ». Il s’agit d’une boucle qui s’exécute tout au long de la mise en marche de l’Arduino, une fois la fonction « setup » réalisée. En d’autres termes il s’agit de la fonction principale, dans laquelle nous effectuerons les étapes 2 à 5. Nous appellerons alors simplement les fonctions « LectureTrame », « CalculCoordonnees » et « PilotageMoteurs » les une après les autres, en continu.
2. Fonctionnement du joystick
De nombreuses applications existantes permettent de dialoguer par liaison Bluetooth via un smartphone. Nous avons choisi d’utiliser l’application « Blueduino » disponible sur Windows Phone, qui permet très simplement de se connecter à un appareil par liaison Bluetooth, puis de lui envoyer une trame quelconque (caractères ASCII saisis via le clavier du téléphone au travers d’un terminal), soit des informations sur la position d’un joystick présent à l’écran.
L’application se présente de la manière suivante :
A chaque déplacement du joystick à l’écran, une trame est automatiquement envoyée au travers de la liaison Bluetooth, contenant les informations suivantes : * CoordonnéeX , CoordonnéeY, #
3. Développement des fonctions
Il a donc fallu développer les fonctions capables de récupérer la trame envoyée, de traiter ses informations puis de les exploiter pour déplacer notre robot.
Fonction LectureTrame
Cette fonction a pour simple but de lire une trame reçue par la liaison Bluetooth, de contrôler son intégrité (caractères de début et fin de trame), puis de retourner sa valeur dans une variable de type chaîne de caractères, qui sera stockée par la fonction principale dans une variable globale pour être exploitée par les différentes fonctions.
Fonction CalculCoordonnees
Cette fonction permet de récupérer la trame reçue précédemment, d’en séparer les composantes (coordonnées X et Y), puis d’en effectuer une conversion. Pour une meilleure compréhension et une exploitation plus simples de ces coordonnées, nous avons choisi de les convertir vers des valeurs positives et négatives (de -126 à 0 et de 0 à 127) au lieu des valeurs de 0 à 255 fournies par l’application Blueduino.
Cette fonction prend en paramètres la trame (chaîne de caractères) reçue, ainsi que deux pointeurs vers des variables globales dans lesquelles seront stockées les coordonnées du joystick.
Fonction PilotageMoteurs
Une fois les coordonnées récupérées, il faut les exploiter pour déplacer notre robot au travers des moteurs. Il s’agit donc de déterminer la vitesse de rotation du moteur du haut (qui met le robot en rotation) ainsi que du moteur du bas, qui entraîne la roue et donc la sphère vers l’avant ou l’arrière, à une vitesse donnée.
Les coordonnées ayant été converties vers des valeurs positives et négatives, nous pouvons utiliser directement un proportionnel de leur valeur pour gérer la rotation du robot. Le signe de la valeur en X nous permettra donc de connaître le sens de rotation, la valeur nous permettra d’obtenir directement un proportionnel de la vitesse du moteur à entraîner.
Pour la vitesse d’avancement du robot, nous avons cependant choisi d’utiliser la longueur du segment formé par les coordonnées X et Y. En d’autres termes, plus le point de destination du joystick est éloigné du centre, plus le moteur ira vite. Le sens de rotation (avant ou arrière) est quant à lui déterminé par le signe de la coordonnée en Y.
VII. Difficultés rencontrées
Nous avons rencontré plusieurs difficultés ayant retardé notre planning mais également notre conception de l’ensemble.
Après avoir commencé à dessiner plusieurs pièces en 3D, nous nous sommes rendu compte que notre système était surdimensionné en terme de matières, nous nous sommes également rendu compte que nous utilisions trop de pièces.
Nous en avons donc conclu qu’il nous fallait concevoir l’ensemble d’une autre manière, en minimisant le nombres de pièces et en concevant au plus léger et au plus simple. Ci-dessous une photo de notre première conception :
Comme nous pouvons le voir ci-dessus, les différentes pièces sont très grandes, elles engendrent également un copeau important lors des usinages, mais aussi une cotation lourde et des mises en position importantes.
Une autre difficulté a été de prendre en compte l’équilibrage du système, car pour un bon fonctionnement l’équilibrage de l’ensemble est primordial.
C’est la raison pour laquelle nous avons revu la conception de l’ensemble pour placer le module Arduino et la batterie au centre. Nous avons également décidé de respecter une symétrie suivant les deux plans, en rouge et en bleu, lors de la conception de nos pièces. Ces deux étant les plus important dans notre cas.
Au terme du délai imparti, nous ne sommes malheureusement pas arrivés aux objectifs que nous nous étions fixés. Bien que les pièces principales soient réalisées et que la programmation soit fonctionnelle, nous n’avons pas bénéficié de suffisamment de temps pour mettre en commun ces deux environnements. Pour arriver à un robot totalement abouti, les pièces auraient du être fabriquées et assemblées bien avant le terme du projet pour que la partie électronique puisse être développée sur un assemblage concret. Malheureusement ce point n’était pas réalisable au vu de l’emploi du temps des élèves de GMP.
Les points à améliorer pour obtenir un projet abouti sont les suivants :
La mise sous tension
A ce jour, la boule se ferme grâce à du ruban adhésif, ce qui complique très clairement sa mise sous tension et son arrêt étant donné qu’aucune pièce n’est accessible de l’extérieur. Il faudrait donc retravailler ce point pour obtenir un système d’ouverture simplifié.
La roue
Par souci de temps, la roue n’a pas pu être modélisée par le biais des machines dont nous disposons à l’IUT. Les différentes solutions testées ne possédaient pas suffisamment d’adhérence pour entraîner suffisamment la sphère.
Le module infrarouge
Un module infrarouge a été développé pour évoluer vers un déplacement autonome du robot à la recherche d’une balise. Malheureusement, la sphère en fibre de verre n’est pas suffisamment perméable à ces signaux pour obtenir un résultat concluant.
Conclusion
Ce projet nous a permis de réaliser un système complet, de la conception jusqu’au montage, ce qui fut très intéressant.
La fabrication nous a permis de découvrir de nouveaux procédés de mise en œuvre, de construction, de modélisation etc. Le choix des solutions au travers de multiples possibilités a été très enrichissant puisqu’il a nécessité de lister les points positifs et négatifs de chaque solutions pour ne garder que la meilleure, en fonction des différentes contraintes posées.
Nous nous sommes plongés dans l’univers de la gestion de projet, ce qui nous a confronté à la nécessité d’une bonne communication pour la réalisation d’un projet. Ce point nous a très clairement mis en difficulté et c’est ce qui nous a retardé dans notre réalisation. La communication entre les deux départements a été compliquée, notamment à cause des emplois du temps différents mais également parce que les objectifs posés au départ différaient. En effet, les finalités entre les deux départements n’étaient pas les mêmes : réalisation des pièces pour la partie génie mécanique, réalisation du robot fonctionnel pour la partie génie électrique. Ceci nous démontre également la nécessité de déterminer un cahier des charges exhaustif et clair en début de projet.
L’aspect collaboratif entre les deux départements présente néanmoins de grand avantages, comme la réalisation très complète de projets comme ce robot. Nous en retenons une expérience très enrichissante.
Dans le cadre de nos études en Génie Électrique et Informatique Industrielle (GEII), nous sommes amenés cette année à travailler sur un projet en collaboration avec le département Génie Mécanique et Productique (GMP).
Le projet que nous avons choisi consistera à différencier des pièces de formes différentes à l’aide d’une caméra se situant d’un côté du robot et de les amener de l’autre côté de celui-ci tout en les triant. Ceci sera réalisé à l’aide du robot TP80 de Stäubli que l’on va présenter par la suite.
Le robot dont nous disposons pour réaliser notre projet est le TP80 de Stäubli, il a été conçu en février 2012, pèse 71kg, il a la capacité de réaliser 200 déplacements par minutes et de ce fait a une charge nominale plutôt faible de 500g. Ce robot est très adapté aux applications de packaging dans l’agroalimentaire ou le secteur pharmaceutique par exemple.
2. Critères de fonctionnement :
Le robot doit être capable de différencier 4 types de pièces de formes différentes : rondes, carrées, triangles et étoile. Il devra les déplacer dans un ordre précis qui correspond à la demande de l’utilisateur.
3. Critères techniques :
Choix du préhenseur : il doit être adapté aux pièces que l’on va déplacer.
Prise en main du logiciel de programmation Stäubli.
Prise en main du logiciel de programmation du système de vision.
Le robot FAST picker TP80 est un robot extrêmement rapide conçu pour des opérations de manutention de pièces petites et légères (moins d’1 kg). Le robot FAST picker TP80 est particulièrement adapté aux applications de packaging dans divers secteurs comme l’agro-alimentaire, le médical, le photovoltaïque ou la cosmétique.
Vitesses élevées
Ce robot extrêmement rapide est en mesure de soutenir des cadences allant jusqu’à 200 coups/minute en fonctionnement continu.
Fixation simple
Le robot FAST picker TP80 peut être monté sur une structure bien plus légère que les robots à structure parallèle, apportant une réduction substantielle des coûts et une simplification de l’intégration du robot.
Précision et rigidité élevées
La conception et la construction très rigide du robot lui permet une grande répétabilité sur toute son enveloppe de travail.
Grande enveloppe de travail
Son rayon d’action de 800 mm et sa course de 100 mm (200 mm*) donnent au robot FAST picker TP80 une grande enveloppe de travail tout en maintenant des cadences très élevées.
Tous les câbles utilisateurs passent dans le bras
Les connexions électriques, pneumatiques et les entrées/sorties sont disponibles sur la bride outil avec l’ensemble des câbles logés et protégés à l’intérieur du bras.
Nous avons choisi pour la préhension d’utiliser un système venturi.
Nous ne possédons pas encore cette ventouse ainsi que le système venturi mais ce sera sur ce modèle que l’on travaillera. Nous avons donc réalisé par la suite une pièce permettant d’adapter ce système de préhension à la bride outil. Étant donné que nous n’avons pas d’étudiant GMP qui travaille avec nous, pour réaliser cette pièce nous nous sommes tournés vers M. CHASSIGNET qui nous a donc aidé pour la réalisation de cette pièce d’adaptation. Cette pièce a été découpée à l’atelier GMP au jet d’eau.
Usinage de la pièce
Pièce Finale
Celle-ci nous permettra d’être parfaitement centrés par rapport à la bride outil mais aussi d’empêcher tout mouvement de translation ainsi que de rotation.
Usinage de la pièce
Les pièces ont été dessinées à l’aide du logiciel Solidworks pour que par la suite nous puissions les faire découper par laser à l’IUT Lab.
2. Partie Programmation
La vision : NI VISION BUILDER
La programmation de la caméra se fait avec le Logiciel NI Vision Builder : C’est un logiciel qui donne la possibilité de configurer, définir des valeurs de référence et déployer aisément un système qui répond aux attentes des applications de vision industrielle. Depuis le filtrage par motif et la détection de présence jusqu’à l’alignement de précision et la classification. Un environnement de développement offrant un menu interactif remplace la complexité de la programmation en simplifiant le développement et la maintenance, sans sacrifier les performances et la gamme des fonctionnalités.
Voici un aperçu global du programme réalisé par la caméra. On commence par faire une calibration de la caméra pour déterminer quelle est la longueur, en millimètres, d’un pixel. Par la suite, la caméra va attendre que le robot lui envoie une demande d’acquisition afin d’envoyer au robot les coordonnées des pièces. La caméra réalisera donc une inspection afin de déterminer les coordonnées des pièces afin de les envoyer au robot.
La calibration :
Pour faire la calibration de la caméra, on va demander à la caméra de détecter les deux objets qui se situent à gauche afin de déterminer la longueur, en pixels, qui séparent ces deux éléments.
Afin de déterminer cette distance et la convertir en millimètres, nous avons utilisé un bloc « calculator » qui n’est rien d’autre qu’un programme LabView. Dans ce programme on récupère donc les positions en Y de chacun des objets afin de les soustraire pour obtenir la distance qui les sépare selon l’axe Y. Sachant que cette distance est égale à 140mm il suffit de faire un produit en croix pour obtenir la longueur en millimètre d’un pixel.
Grâce à cela, il nous suffira de multiplier cette valeur par les coordonnées en pixels de chaque objet pour obtenir leur coordonnées en mm.
Une fois la calibration finie et que le robot a demandé à la caméra de lui envoyer les coordonnées des pièces, la caméra va réaliser plusieurs étapes afin de différencier les différentes pièces. Afin de déterminer si la pièce est carrée, ronde ou triangle il a fallu faire une détection d’objet et y rajouter des filtres afin d’être capable de ne détecter uniquement les objets de chaque famille.
Une fois que cela est fait on peut envoyer ces coordonnées au robot.
La Programmation du Robot : Suite Stäubli Robotics
Nous utilisons le logiciel Stäubli pour la programmation du robot c’est un logiciel de développement, de simulation, de maintenance, et de suivi d’applications robotisées. Stäubli Robotics Suite intègre des outils permettant la réalisation de simulation 3D (importation de modèles CAO, modélisation 3D, détection de collision, analyse d’accessibilité, mesure réaliste de temps de cycle), de programmation et débogage par le biais d’un éditeur de programme, de maintenance, et de suivi de la cellule robotisée avec des outils d’accès à distance.
Le programme que nous avons développé avec le robot est fait comme suit.
On commence tout d’abord par mettre le Robot sous tension puis on fait appel au Menu.
Une fois dans le Menu, on peut aller dans le sous Programme Recette :
Au sein du menu Recette on a la possibilité de saisir le nombre de pièces que nous souhaitons déplacer.
On saisit le nombre de pièces triangulaires, le nombre de pièces rectangulaires, le nombre de pièces pentagonales et le nombre de pièces étoilées.
Après la saisie des nombres de pièces on envoie une demande d’acquisition à la caméra. Cette dernière nous envoie les coordonnées des pièces sous forme de tableau.
C’est à partir de ce moment que s’exécute le programme déplacement des pièces en fonction de leur forme.
3. Partie Communication
La communication se fait donc comme suit : Le constituant le Client envoie une demande d’acquisition à la Caméra le serveur. La Caméra effectue l’acquisition et envoie les coordonnées au robot sous forme de tableau.
On a de ce fait les coords[0] et coords[1] qui constituent respectivement les coordonnées x et y des carrés ainsi de suite.
Ce projet nous a permis d’améliorer nos connaissances en programme robotique et vision industrielle. La programmation du robot ainsi que celle de la caméra n’était pas très compliqué. Ce qui nous a causé problème tout au long du projet c’est la communication entre la caméra et le robot.
Le robot ne comprenait pas le type de données que lui envoyait la caméra.
Étudiants en deuxième année de DUT Génie électrique et informatique industrielle, nous devons réaliser au sein de notre université, un projet de fin d’études.
Ce projet consiste en la réalisation d’une station météo autonome permettant de connaître différentes mesures grâce à des capteurs puis les consulter rapidement et simplement sur internet.
Notre objectif pour ce projet est de concevoir une station pouvant être placée à l’extérieur au sein de l’IUT.
II. Cahier des charges et organisation du projet :
1) Analyse fonctionnelle :
2) Cahier des charges :
La station météo devra intégrer les caractéristiques et les mesures du tableau ci-dessous.
Les données seront envoyés par le protocole MQTT vers un site qui fera office d’interface. Dans notre cas nous le ferons sur Adafruit.io
Les données doivent être consultables facilement et protégées pas un mot de passe et un identifiant.
L’archivage devra être conservée sur le site pendant un mois.
Mesure de la température
-30 à +50 °C
Mesure de la pression atmosphérique
500 hPa à 1100 hPa
Mesure de l’humidité de l’air
0% à 100%
Mesure de la luminosité
0% à 100%
Consultation des mesures
Dashboard Adafruit.io
Archivages des mesures
1 mois
Autonomie énergétique
1 année
3) Les matériels et les outils utilisés :
ESP8266 sur KIT Wemos D1
Capteur de température et d’humidité : DHT11
Photorésistance
Capteur de pression atmosphérique : BMP180
Carte shield pour les différents capteurs fixée sur le kit Wemos
Environnement Arduino IDE
Protocole de messagerie MQTT : Broker : Adafruit.io
Dashboard Adafruit.io
Module Lipo Raider
Batterie 2500 mAh 3.7 Volts
Panneau solaire 3.5 W 6 Volts
580mAh
4) Diagramme de Gantt :
5) Répartition des tâches :
Mustafa
Quentin
Gestion du capteur d’humidité
Recherche de composants
Gestion du capteur de pression
Gestion du capteur de luminosité
Gestion du capteur de température
Interface Adafruit.io
Calcul/test de l’autonomie
Création du boîtier
IV. Le projet :
Description détaillée :
Le but de ce projet est de réaliser une station météo qui sera placée à l’extérieur, dans l’enceinte de l’IUT. Cette station sera fait à partir d’un module ESP8266 (explication dans la partie 2) et permettra d’acquérir différentes mesures météorologiques grâces à des capteurs qui l’intègre (température, humidité, luminosité, pression atmosphérique). La station sera connectée à internet par une connexion Wi-Fi et les mesures seront envoyées vers le site Adafruit.io par un protocole MQTT. L’interface nous indiquera les différentes mesures qui seront archivées pendant un mois. La station sera autonome grâce à l’alimentation du module par un panneau solaire et une batterie lithium.
Les différentes étapes de réalisation sont les suivantes :
Compréhension du protocole MQTT.
Compréhension et utilisation de l’environnement de programmation ARDUINO IDE avec la carte qui contient le module wifi ESP8266.
Connexion au serveur/broker Adafruit.io via le module wifi ESP8266 (Arduino IDE).
Acquisition des mesures des différents capteurs sur le module ESP8266 (sans connexion Wi-Fi).
Envoie des mesures vers Adafruit.io via le module wifi de l’ESP8266.
Gestion de l’interface Adafruit.io.
Gestion de l’autonomie de la station météo.
Mise en forme du boîtier et test en conditions réelles.
1) MQTT, c’est quoi ?
MQTT est un protocole de messagerie « publish-subscribe » basé sur le protocole TCP/IP. Ce protocole suit un modèle de communication de type publication/abonnement via un broker (dans notre cas le serveur Adafruit.io). Pour publier un message il faut créer un topic (par exemple « GEII/température ») dans notre serveur et paramétrer la liaison avec ce topic dans le code. Le message envoyé vers ce topic pourra être lu en s’abonnant à ce topic sur notre interface . Donc si on veut réceptionner des messages, on s’abonne à un topic et on attend que quelqu’un envoie un message sur le même serveur et dans ce même topic.
Pour notre projet nous utiliserons un serveur gratuit de test : Adafruit.io.
Si on souhaite un jour améliorer ce projet nous pourrons toujours réfléchir à la création de notre propre serveur MQTT.
-> Pour plus de détails sur ce type de protocole et voir quelques exemples, vous pouvez visionnez la vidéo suivante :
2)L’ESP8266, c’est quoi ?
L’ESP8266 est un module Wi-Fi qui peut être utilisée de deux manières :
associé à un autre micro-controlleur (par exemple un Arduino), l’ESP8266 s’occupera juste de la partie « communication Wi-Fi ». L’Arduino va envoyer des commandes à l’ESP8266 (commandes comme « connecte-toi à tel réseau Wifi », « envoie tel message à tel serveur », etc.).
L’ESP8266 peut aussi être utilisé de manière totalement autonome, en exécutant lui-même des applications que vous aurez programmées. L’ESP8266 ne va pas se contenter d’ajouter des fonctionnalités Wi-Fi à votre Arduino, il va exécuter lui-même le programme Arduino, tout en prenant en compte la partie Wi-Fi. On ne charge plus votre programme sur l’Arduino, mais directement sur l’ESP8266. Cependant le nombre de port GPIOs sont limités.
Dans notre cas l’ESP8266 est sur un kit Wemos D1, il est donc associé à un autre microcontrôleur qui permet la programmation sur Arduino IDE et la connexion à un ordinateur par un cable USB 2.0. Pareillement, si on souhaite améliorer la station nous pouvons réfléchir à l’utlisation de l’ESP8266 de manière autonome.
3) Utilisation de l’environnement Arduino IDE :
Pour la prise en main de l’environnement Arduino nous avons commencé par réaliser de simples codes comme allumer/éteindre une led. Ensuite, nous avons programmé la connexion Wi-Fi du module ESP8266 et essayé de nous connecter à un serveur MQTT (mosquitto.org puis Adafruit.io). Une fois connecté nous avons crée des topics sur Adafruit.io sur lesquels on envoi des messages. Finalement nous avons travaillé sur la réception et l’interfaçage des messages reçus sur Adafruit.io.
Pour nous entraîner nous avons donc d’abord réalisé le montage ci-dessous qui permet d’allumer et éteindre une LED via notre smartphone connecté sur un topic mosquitto.org qui est lui-même connecté avec le module ESP8266.
Carte Wemos relié à une LED piloté depuis le smartphone :
Une fois l’environnement ARDUINO et MQTT maîtrisés, nous avons commencé la programmation de l’ESP8266 avec un capteur de température et d’humidité DHT11 et une photorésistance.
Le DHT11 et la photorésistance reliés à l’ESP8266 :
4) Connexion Wi-Fi et serveur Adafruit.io :
Pour se connecter au réseau Wi-Fi avec l’ESP8266 sur l’environnement arduino, on définit d’abord le nom du réseau et le mot de passe de celui-ci. Ensuite, il nous suffit d’entrer la fonction suivante et de vérifier son état :
WiFi.begin(SSID, PASSWORD); // lancement de la connexion
while(WiFi.status() != Connected) ; //attente de connexion
Pour se connecter au serveur MQTT Adafruit.io, on télécharge le code d’initialisation sur Adafruit.com et on entre le nom du serveur, notre identifiant, mot de passe et pour finir nos topics. Le port par défaut est 1883.
Paramétrage :
Souscription en tant que Publisher :
Nous nous souscrivons aux topics tempGEII, humidityGEII, luxGEII, pressionGEII et altitudeGEII en tant que publieur. C’est-à-dire que notre module Wi-Fi publie les messages vers le serveur Adafruit.io et que pour lire les message sur le serveur, on doit souscrire en tant qu’abonnés sur chaques topics précédemment énoncés.
Maintenant que nous sommes connecté à Adafruit.io avec notre module Wi-Fi, nous allons nous occuper de la gestion des capteurs des envois des mesures vers le serveurs.
5) Acquisition et envois des mesures des capteurs vers Adafruit.io :
Pour la gestion des capteurs, nous n’avons pas fait l’étude approfondie de chaque composant, nous nous sommes servi de composants adaptés pour l’environnement Arduino. Nous avons donc pris un DHT11 pour la lecture de la température et de l’humidité et une simple photorésistance.
Pour la gestion du DHT11 et l’envoi des mesures vers Adafruit.io il faut :
télécharger la libraire DHT.h
appeler la fonction dht.readHumidity() pour lire l’humidité
appeler la fonction dht.readTemperature() pour lire la température
envoyer les résultats vers les topics sur le serveur : TempGEII.publish(temperature); et HumidityGEII.publish(humidity);
Pour la gestion de la photorésistance et l’envoi des mesures vers Adafruit.io il faut :
brancher le capteur sur un port analogique
faire une lecture de ce port avec la fonction analogRead(number of the pin);
mettre le résultat en pourcentage avec un produit en croix.
envoyer le résultat vers le topic lux sur Adafruit.io : luxGEII.publish(lux);
Evidemment il est possible d’ajouter d’autres capteurs. Faute de budget nous en resterons en cela pour le moment.
Interface Adafruit.io :
6) Gestion de la consommation :
Pour que la station météo soit autonome elle va être alimentée par une batterie lithium qui va se recharger à l’aide d’un panneau solaire. Le panneau solaire, la carte et la batterie vont être reliés à un module Lipo Rider qui va permettre d’envoyer le courant reçu du panneau solaire vers la batterie et d’alimenter la carte avec une tension stable de 5V.
Pour mettre en place le bon panneau et la bonne batterie il faut connaître la consommation de notre carte. Pour cela nous branchons un ampèremètre en série sur notre carte alimenté et nous relevons le courant de consommation. Ce dernier est de 48mA.
Nous avons choisi de prendre une batterie lithium de 2500mAh ce qui veut dire que notre station peut tenir au maximum 52 heures sans être rechargé, ce qui suffit amplement pour tenir toute la nuit quand le panneau n’apportera aucun courant à la batterie.
Nous avons choisi de prendre un panneau solaire 3.5W et 6Volts car il est adapté à notre module Lipo Rider et c’est un produit à très bon rapport qualité prix. Il nous fournit au maximum courant de 580 mA ce qui est largement suffisant pour recharger notre batterie, même pendants une journée nuageuse.
Une fois le panneau reçu nous avons crée un support en bois pour celui-ci à l’IUT LAB avec l’aide de Monsieur Sabbata.
Support et panneau solaire :
7) Mise en boîte :
Le boîtier nous a été donné par notre entreprise (et nous les remercions). Nous l’avons modifié et ajouté une ouverture vitrée sur le dessus pour que la lumière puisse pénétrer et d’autres petites ouvertures pour que l’air puisse circuler à l’intérieur.
Les amélioration à apporter :
Le choix de ce boîtier n’est pas le meilleur car il est noir est donc absorbe la chaleur. De plus, lorsque que les températures augmentes et que le soleil est présent, comme le boîtier est vitré, les rayons du soleils entrent à l’intérieur… Il faudrait donc changer de boîtier et opter pour un boîtier blanc et une séparation alimentation/capteurs.
Le couvercle du boîtier :
Comme on peut le voir 4 visses on été ajoutés pour fixer fortement la vitre sur le couvercle et de la colle a été répandue tout autour pour ne pas laisser passer l’eau durant de fortes pluies.
Le boîtier final :
Une sortie isolée à été ajouté avec une prise USB mâle qui va venir sur brancher sur le panneau solaire.
Le meilleur endroit pour ce boîtier, à l’état actuel, serait de le placer à l’ombre (mais toujours à la lumière) tout en réussissant à placer le panneau solaire au soleil. Effectivement lors de journées ensoleillées les données sont faussées par la chaleur présente dans le boîtier.
V. Conclusion :
Le plus difficile a été la mise en place du protocole MQTT pour la liaison avec le publisher (ESP8266) et le subscriber (Dashboard Adafruit.io). Mais après plusieurs essais nous sommes parvenus a l’utiliser et une fois compris il a été assez facile de continuer avec ce protocole.
Si nous pouvions refaire ce projet, nous changerions le boîtier et sortirions le capteur de température puisque durant une journée bien ensoleillée, la température est faussée par la chaleur présente à l’intérieur de la boite. Ensuite, nous ajouterions d’autres capteurs comme la un pluviomètre et un anémomètre. Pour finir pour pourrions supprimer la carte Wemos D1 et n’utiliser que le module ESP8266 pour le rendre autonome et miniaturiser la station.
Nous tenons à remercier les professeurs qui étaient présents pour nous aider lorsque nous rencontrions des difficultés mais aussi l’IUT de nous avoir mis à disposition l’IUT LAB.
C
Ceci est le capteur infrarouge 4. Dès qu’il voit un obstacle, il renvoi une valeur entre 0 et 2.54. S’il revoie 2.54 c’est que le capteur IR4 est presque au contact de l’obstacle.
Comme on peut le voir sur l’image ci dessus, le Raspberry Pi 3 comporte 3 Ports USB et une prise Ethernet. On peut voir qu’il dispose également de ports GPIO qui peuvent être utilisés comme entrée/sortie. Il est également équipé d’une carte Wifi et du Bluetooth.
Nous retrouvons donc les subscriber et les publisher. Cependant nous avons un également le broker MQTT, c’est un serveur qui permettra de faire passer les messages entre les différents clients.
Afin de commander le servomoteur nous lui envoyons des impulsions ce qui lui permet dans une position. Pour cela nous définissons un angle dans lequel le servomoteur doit se positionner.
Grafcet de tâche du perçage
Ce composant a été de loin le plus simple a choisir. Le contrôleur de vol est la carte mère du drone, le modèle NAZE 32, est un des plus réputé et des plus utilisé. Il permet d’embarquer une caméra et est très modulable en fonction des options voulues. Nous pouvons ajouter toute sorte de capteur télémétrique permettant de la prise de donnée dans des endroits inaccessible.
Les hélices sont choisies en fonction des moteurs. L’idéal dans notre cas est donc hélices 5“.
Pour le choix de la batterie, nous nous sommes appuyé sur l’expérience d’autre utilisateurs pour faire notre choix. Les caractéristique technique de la batterie doivent correspondre aux éléments qu’elle alimente. Afin d’avoir une autonomie raisonnable, nous avons choisis une batterie de 1500 mAh. Nous nous sommes assuré que les connectiques correspondent à notre carte électronique et au chargeur.
La caméra est de résolution modeste mais largement suffisante pour le pilotage. Nous avons opté pour un capteur CCD pour ne pas avoir l’effet rolling shutter. Le capteur dispose d’un champ de vision de 148°. Un émetteur avec une fréquence de 5,8 GHz est nécessaire pour ne pas interférer avec les fréquences des commandes qui sont en 2,4 GHz.
Le raspberry pi 0. Nous l’avons choisi notamment pour sa taille très réduite et sa consommation minime, parfaite pour concevoir un appareil avec une bonne durée de vie.
L’enviroPHAT, qui est une carte d’extention du raspberry pi 0. Cette carte rassemble une grande partie des capteurs dont nous avions besoin pour mesurer :
Voici un aperçu global du programme réalisé par la caméra. On commence par faire une calibration de la caméra pour déterminer quelle est la longueur, en millimètres, d’un pixel. Par la suite, la caméra va attendre que le robot lui envoie une demande d’acquisition afin d’envoyer au robot les coordonnées des pièces. La caméra réalisera donc une inspection afin de déterminer les coordonnées des pièces afin de les envoyer au robot.
La communication se fait donc comme suit : Le constituant le Client envoie une demande d’acquisition à la Caméra le serveur. La Caméra effectue l’acquisition et envoie les coordonnées au robot sous forme de tableau.
