EXTENSION D’UNE ARCHITECTURE CANOPEN SUR SERVEUR OPC DA

SOMMAIRE

  1. INTRODUCTION
  2. CANopen
  3. etc…

1. INTRODUCTION

Durant ce projet, nous allons devoir compléter l’architecture d’un serveur OPC DA. Ce serveur OPC existant déjà, nous allons y ajouter des équipements CANopen que nous allons pouvoir superviser à distance. Pour cela, nous avons différentes tâches à effectuer pour pouvoir finaliser le projet.
Tout d’abord, il faut savoir que nous allons utiliser le logiciel Automation Studio qui est un logiciel de conception de circuits, de simulation et de documentation de projets. Nous utiliserons également le logiciel InTouch nous permettant de faire de la supervision industrielle et de commander notre système à distance.

2. CANopen

Le protocole CAN, initialement créé pour le marché de l’automobile, est un Bus qui priorise les messages sans altérer ou détruire la requête. Il intègre la 2ème couche du modèle OSI alors que la plupart des protocoles se limitent à la 1ère couche.
Ensuite, nous allons mettre en place le module CANopen sur notre système et le paramètrer. CANopen permet de garder un profil standard dans les systèmes de contrôle industriel. Il convient aux automates en temps réel car c’est une solution efficace destinée aux applications industrielles.
Sur ce module, nous allons y brancher quatre équipements de différents fabricants. Nous commencerons donc par un équipement d’un fabricant en le paramétrant pour le tester grâce au server OPC puis en y ajoutant une supervision. Nous répéterons cette opération avec 4 equipements (Entrée/Sortie) de 4 fabricants différents et un dernier équipement qui sera un variateur.

Représentation du modèle OSI pour les couches relatives à CANopen (couche 7). Les couches 1 et 2 étants relatives au bus CAN.
Le concept CANopen repose sur un dictionnaire d’objets renseigné par l’interface de communication et appliqué aux entrées/sorties de l’équipement.
Schéma de principe du serveur de communication multi-protocoles. Il échange des données avec le process via différents protocoles industriels (Ethernet et bus de terrain). Les clients, type supervision, peuvent visualiser et piloter les variables du serveur indépendamment des protocoles utilisés.
Concrètement, le serveur OPC multi-protocoles est un API B&R avec des coupleurs maîtres en CANopen, Profibus, ASI, IO-Link etc.
Voilà l’état du projet au départ. L’automate, via le réseau Powerlink, pilote un module d’extension déporté. Ce module dispose, à gauche, d’un coupleur CANopen Maître avec un 1er coupleur esclave (I/O B&R).
L’état du projet final fait apparaître 4 équipements supplémentaires
(WAGO, PROFACE, SCHNEIDER, ALTIVAR) en plus des I/O B&R

APPLICATION DE SUPERVISION D’ÉQUIPEMENTS

Introduction

Notre projet consistait en la gestion de tout les équipements de la salle contrôlable en Modbus. Dans le cadre des études et réalisations des semestres 3 et 4, nous avons eu l’occasion de développer une application de test et de contrôle de l’ensemble des équipements présents dans la salle B018 (salle de Réseaux), par le biais du protocole Modbus/TCP avec une visualisation VNC. Pour mener à bien ce projet nous avons eu recours au logiciel Automation Studio qui nous a permis d’effectuer les différents essais et applications.

Comme le montre ce schéma, on va se servir d’une interface qui apparaîtra sur le PC, cependant tout le programme sera exécuté dans l’automate à l’adresse 200.200.200.175 qui, lui, contrôlera les équipements et nous permettra d’avoir une visualisation sous VNC (l’automate est serveur VNC, le PC, lui, est client VNC). La liste des équipements est la suivante, accompagnés de leur adresse IP dans la salle.

Intitulé : Modules : @IP :
Colonne Lumineuse MOXA .252 :2
Lampes Fluocompactes WAGO .215
Portique 206 WAGO .214/.219
RECDIGIT WAGO .210 :6
JANITZA JANITZA .251
WAGO 352 WAGO .179/.189/.199
BC0087 B&R .243/.244/.245
CIE-H10 SOLLAE .240
WAGO 841 WAGO .216/.217/.218
WAGO 315 WAGO .210 :9
CPU CP3586 .176
Modélisation du réseaux Modbus

Fonctionnement Modbus

Généralités

Le Client, par l’intermédiaire d’une trame requête, va envoyer des informations aux serveurs, dans notre cas, nos équipements. Les serveurs, à leur tour, vont répondre par le biais d’une trame réponse pour envoyer les informations demandées ou les actions demandées.

Avec Automation Studio, pour gérer la communication Modbus, nous allons créer les équipements et leurs attribuer une adresse IP. Au niveau de la configuration, nous allons créer des blocs qui seront composés d’un ou plusieurs « channels ». Ainsi, ces « channels » apparaîtront dans la gestion des entrées et sorties et auront donc une variable associée.

Modes de fonctionnement

Les échanges entre l’automate Client et les équipements serveur peuvent se faire de plusieurs façon, suivant le mode sélectionné lors de la configuration. Cyclique, Non-Cyclique ou bien Send Once.

Mode cyclique :

En mode cyclique, la communication est toujours active et va renvoyer constamment la valeur. On peut ici voir lorsque la valeur est a 1 on envoie 1.

Mode non-cyclique :

En mode non-cyclique, il y aura une valeur (ici, le bouton) qui va décider d’activer ou non la communication. Lorsqu’elle est active, elle fonctionne comme en mode cyclique. Lorsqu’elle est désactivée, la communication s’arrête et la valeur va se figer. La LED va donc rester allumer jusqu’à l’ordre d’arrêt.

Mode Send Once :

En mode « SendOnce », grâce au petit bout de programme (ci-dessus), nous n’occuperons la communication que lors de l’envoi (ou de la réception). En effet, quand « SendOnce » passe à 1, nous envoyons nos valeurs. Dans notre cas, vu qu’on veut envoyer la valeur de notre bouton, nous allons attendre un front sur celui-ci. Quand un front sera détecté, nous allons faire passer « SendOnce » à 1, ce qui permettra d’envoyer la valeur que le bouton aura pris. « SendOnce » ne repassera pas à 0 automatiquement, c’est pourquoi, on attend l’acquittement, qui passe à 1 seulement si les valeurs sont bien reçues par l’équipement. Une fois l’acquittement reçu, on remettra « SendOnce » à 0. Quant à l’acquittement, il repassera automatiquement à 0.

Visualisation

Nous pouvons voir ci-dessus, le menu général de notre tableau de bord. Un simple clic sur n’importe quel équipement vous amènera à une page détaillée. Nous avons disposé des témoins lumineux sur chaque équipement afin de vérifier l’état de celui-ci, repérés par leur adresse IP. Nous avons aussi regroupé les appareils similaires entre eux par souci d’ergonomie.

Par exemple lorsqu’on cliquera sur « Colonne Led » on aura la page ci-dessous (à gauche) qui permet de contrôler les trois lumières, une lumière par bouton. Et si l’on clique sur « Wago 841 » on aura la page ci-dessous (à droite) qui permet de contrôler 3 Wago différent et donc de contrôler leur sorties ainsi que de visualiser leurs entrées.

Module Janitza

Le module Janitza est un appareil de mesures intégré dans le réseau électrique de la salle de classe. Il est capable de mesurer des dizaines de grandeurs physiques. Nous l’avons configuré pour en transmettre 22 sur notre visualisation. Celle-ci affiche ces grandeurs selon deux modes de fonctionnement :

Le mode de visualisation en « temps réel », où l’évolution sur les graphiques se fait en continu par rapport aux mesures. Cela est réalisé grâce à la lecture des ports du Janitza associé à chaque grandeur physique.

Le mode de visualisation « historique », où les graphiques sont figés, représentant une évolution ayant eu lieu dans le passé. Ce mode de visualisation est plus pratique pour étudier ces mesures, et est permis grâce à la lecture d’un tableau préalablement rempli et donc les valeurs ont été stockées sans avoir été écrasées.

Nous avons configuré cet appareil de telle sorte à ce qu’il puisse nous communiquer :
La fréquence du réseau
Les intensités des courants sur chacune des trois phases
Les tensions entre chacune des phases et entre chacune de ces phases avec le neutre
Les puissances réelles, actives, réactives et le cos φ sur chacune des phases

Ainsi, il convenait de pouvoir visualiser toutes ces mesures grâce à notre application VNC. Voici un extrait de notre visualisation en temps réel :

Comme l’indique l’échelle à l’horizontale, les mesures en continu s’étalent sur 5 minutes avant de progresser en écrasant les mesures les plus anciennes : le fonctionnement est dit « dynamique »

Ci-dessous, vous pouvez vous apercevoir que les valeurs relevées sur les graphiques (partie de droite) correspondent, en temps réel, avec celle qu’indique le module Janitza via ses ports, chacun associés à une grandeur physique (partie de gauche – visualisation en mode monitoring du mapping du Janitza).

Ensuite, la visualisation « historique » consiste en la lecture de tables, une pour chaque grandeur physique, servant de lieu de stockage aux variables.

Ainsi, sur le graphique suivant vous pouvons observer un graphique en cours de remplissage :

Graphique affichant la lecture du tableau en cours de remplissage
Voici la table associée au fréquence, en cours de remplissage, comme en atteste les cases encore vide au moment de la capture, à partir de la 17ème case. Ainsi, le graphique plus haut se rempli au rythme de celui-ci et arrêtera de progresser au même moment

Module NetIO4ALL

Un autre appareil était directement lié au module Janitza, il s’agit de la multiprise NetIO4All. Cette multiprise est commandable à distance, et permets d’appliquer des charges supplémentaires sur le réseau. Grâce à cet appareil on a pu effectuer des tests en envoyant des charges sur le réseau et en observer l’impact sur les mesures du Janitza, vérifiant que l’on pouvait observer les modifications sur nos graphiques.

A gauche, la page d’accueil de la commande de l’appareil sur l’application VNC. A droite, une photographie de l’appareil.

Il convenait de configurer quatre commandes sur chacun des quatre Channels (les quatre prises) du module :
Une commande ON/OFF classique
Une commande ON DELAY, lançant le système pour un temps bien précis
Une commande OFF DELAY, eteignant le système pour un temps bien précis
Une commande TOGGLE, lançant le système lorsqu’il est éteint et l’éteignant lorsqu’il est en fonctionnement
De plus, pour les deux modes DELAY, nous devons pouvoir choisir le délai grâce à une fenêtre d’écriture numérique et un bouton UPDATE pour valider notre choix.

Ensuite, nous avons trois fenêtres d’affichage en temps réel pour les valeurs suivante : le courant, la puissance et l’énergie générés par la prise commandée.

Conclusion

Cette application répond maintenant au cahier des charges lié au projet. Elle permettra de rapidement voir l’état des équipements en ModbusTCP, et ainsi les nouveaux étudiant pourront rapidement voir les équipements Modbus de la salle, ainsi que ce que l’on peut faire avec ce protocole. En effet pour expliquer quelque chose comme un protocole c’est beaucoup plus agréable d’avoir un exemple, de plus il est possible d’observer les trames sous Wireshark. Cependant, pour éviter d’avoir trop de problème, l’automate n’accepte qu’un seul client VNC à la fois.

Ce projet se sera révélé très intéressant car il nous aura permis d’encore plus explorer les réseaux d’automates industriels. En effet, les TP ont été beaucoup moins poussés que le projet que nous avons fait. De plus, nous avions, lors du semestre 2, pu installer et configurer des automates. Ces deux projets, en plus des cours, nous donnent un véritable bagage pour le domaine de l’automatisme industriel.

Pour finir, nous tenons à remercier, bien évidemment, M.MERCKLE pour sa présence et, surtout, sa disponibilité nous permettant de parfois trouver des solutions à nos problèmes grâce à ses connaissances qui étaient plus étendues sur le sujet.


PILOTAGE SYNCHRONISÉ DE MOTEURS ASYNCHRONES

Synthèse du projet de pilotage synchronisé de moteurs asynchrones

Sommaire

  1. Introduction
  2. Cahier des charges
    1. Bête a corne
    2. Diagramme pieuvre et Tableau des fonctions
  3. Étude de l’installation
    1. Ancienne installation
    2. Installation actuelle
  4. Développement du pilotage synchronisé
    1. Moteur asynchrone
    2. Moteur Pas à Pas
    3. Servomoteurs
  5. Conclusion
  6. Annexe

1.Introduction

Dans le cadre de notre projet d’étude et réalisation, nous avons réalisé un projet permettant la commande synchronisé de deux moteurs asynchrones. Ce projet à été fait durant le Semestre 3 et 4. Nous avons eu pour objectif d’élaborer un banc d’expérimentation et de démonstration du contrôle de mouvement synchronisé basé sur deux moteurs asynchrones. Lors de ce projet nous avons 2 grandes parties qui ce sont dégagées. Nous avions une première partie sur l’étude et la réalisation de l’installation. Celle-ci consistait à étudier l’ancienne installation ayant seulement un moteur asynchrone, puis dans un second temps réaliser l’installation complète ayant deux moteurs asynchrones. La seconde partie concerne le développement des commandes pour les moteurs asynchrones. Pour cela nous avons tous d’abord étudié et développé des commandes de base sur différents types de moteurs. Puis dans un second temps nous avons développé les commandes et la visualisation des moteurs asynchrones avec leurs colonnes lumineuses.

Récapitulatif de l’ensemble de l’installation avant/après

Cahier des charges

Bête a corne

Ce projet doit permettre la synchronisation du mouvement de deux moteurs asynchrones grâce au contrôles de commandes

Diagramme pieuvre et Tableau des fonctions

FP1: Contrôle de mouvement synchronisé des moteurs : Pouvoir contrôlé la synchronisation des moteurs

FP2: Opérateurs : Permettre une utilisation facile des commande

FC1: Alimentation 230V triphasé : Alimenter l’installation en 230V triphasé

FC2: Ethernet Powerlink : Communiqué grâce à Ethernet

FC3: Normes : Respecter les normes de protection et de sécurité

FC4: Visualisation des commandes : Avoir une visualisation complète et fonctionnelle

Étude de l’installation

Ancienne installation

Dans un premier temps nous avons étudié l’ancienne installation. Cela avait pour but de comprendre le fonctionnement de l’installation ainsi que de connaître les principaux composants de celle-ci. Par la suite nous avons fait un croquis de l’installation pour avoir un schéma propre et compréhensible.

schéma de l’ancienne installation

A la suite de ce schéma nous avons réalisé plusieurs autres schémas allant de la partie alimentation à la partie commande du moteur. Lors de l’étude de la partie alimentation, nous nous sommes aperçus que certains équipements étant assez anciens ont dû être changés. L’installation est alimentée par un transformateur triphasé produisant du 230V. Le moteur asynchrone est câblé en couplage triangle. Pour la partie commande, nous avons remarqué que la boitier de marche/arrêt est alimenté par une phase du 230V triphasé.

Schéma de l’intérieur du boitier Marche/Arrêt

Sur le schéma ci-dessus nous avons le boitier Marche/Arrêt ainsi que son équipement de sécurité qui sont représenté. Nous pouvons voir que KM1 et KM2 permettent la connexion des différentes phases pour alimenter le variateur du moteur asynchrone. Nous pouvons voir que le contacteur permet de faire la connexion entre la partie puissance et la partie commande de l’ensemble variateur/moteur.

Installation actuelle

Après avoir étudié l’ancienne installation, nous avons conçus le schéma de la nouvelle installation. Celle-ci ressemble à l’ancienne installation avec quelques modifications.

Schéma de la nouvelle installation

L’installation permettra de piloter deux moteurs asynchrones avec deux variateurs. Pour cela nous avons juste à réalisé l’installation en double comme sur le schéma ci-dessus. Les boitiers de Marche/Arrêt ne seront plus alimentés par une phase du 230V triphasé mais ils seront alimentés en 24V. Pour cela nous devons intégrer un transformateur 230/24V. Celui-ci permet d’avoir 230V au primaire et 24V au secondaire. Nous avons rajouté deux disjoncteurs, le premier en amont et le second en aval du transformateur.Cela permet la protection des boitier Marche/Arrêt. Le reste de l’installation reste en 230V triphasé. Son fonctionnement reste similaire à l’ancienne installation. Les deux nouveaux ensembles variateurs/moteurs sont installés sur une même grille, pour avoir les deux ensembles côte à côte.

Développement du pilotage synchronisé

Moteur asynchrone

Nous avons commencé à étudié le pilotage du moteur asynchrone grâce à un ancien projet d’étudiants. Cela nous a permis de prendre en main le logiciel Automation Studio. Par la suite nous avons étudié les commandes existantes permettant de contrôler le moteur en créant une configuration permettant de relier la partie matérielle a la partie logicielle comme on peut le voir dans l’image suivante.

Pour pouvoir interagir avec le moteur, nous avons testé toutes les commandes étant déjà en place sur l’interface Homme-Machine. Nous pouvions par exemple démarrer,arrêter où choisir la vitesse de rotation du moteur. Par la suite nous avons améliorer le programme ainsi que l’interface. Nous avons ajouté et vérifié si toutes les variables étaient correctes et nous les avons fait apparaître sur l’interface.

Visualitation IHM

Ci-dessus nous avons l’interface Homme-Machine du moteur asynchrone. Pour pouvoir démarrer le moteur nous devons suivre quelques étapes. Tous d’abord la variable « MpAxisBasic » doit être activé. Elle permet de contrôlé l’axe du moteur et à été ajouté par nos soins pour pouvoir choisir le type d’axe que nous voulons pour plus tard. Puis la variable « Power » doit être activé ainsi que la variable « Home ». La variable « Power » met le moteur en marche et la variable « Home » met le moteur en position initial. Puis nous mettons en marche la variable « Move Velocity » qui va faire tourner le moteur si une valeur est donnée. Nous avons un graphique qui trace l’évolution de la vitesse du moteur en fonction du temps. Par la suite nous avons rajouté 2 nouvelles variables une pour la décélération et une pour l’accélération. Nous pouvions donc entrer une valeur dans ces deux variables et voir que le graphique changeait selon les valeurs rentrées. Pour arrêter le moteur nous avions la variable « Stop » et si un problème survenait nous avons la variable « ErrorReset » qui permettait de remettre à zéro toutes les variables pour pouvoir redémarrer le moteur.

Moteur Pas à Pas

Après avoir étudié le moteur asynchrone, nous nous sommes intéressés aux moteurs Pas à Pas. Nous nous sommes aidés de l’interface faite précédemment pour cette partie. Dans cette partie nous devions créer et utilisé une visualisation comportant 2 couplages. Nous aurions le choix entre un couplage linéaire et un couplage CAM entre les deux moteurs. Nous avons réutilisé le programme et les blocs utilisé dans la partie précédente pour vérifier le bon fonctionnement des moteurs. Pour la suite de cette partie nous avons créer 2 blocs permettant de contrôler un moteur chacun et un troisième bloc pour gérer le couplage entre les deux moteurs.

2 blocs MpAxis_0 et MpAxis_1 pour la commandes de 2 axes et un bloc MpAxisCouplig pour le couplage entre les 2 axes

Le premier bloc nommé « MpAxisBasic_0 » permet de contrôle l’axe d’un des deux moteurs, celui-ci servira d’axe maître. Les 3 variables les plus importantes de ce bloc sont encadrer en rouge. La première variable « gMpLinkAxe2 » permet de gérer la mise en route du moteur maître. La seconde variable « AxisPar2 » quand à elle permet de gérer les réglages du moteur (sens de rotation,vitesse de rotation…). Puis la dernière variable « gAxis03 » permet l’identification de notre axe maître par rapport à l’axe esclave. Nous avons un second bloc similaire appelé « MpAxisBasic_1 » qui permet de contrôler le second moteur.

Le second bloc nommé « MpAxisCoupling » permet de contrôlé l’axe et le couplage du moteur esclave. Nous aurons le choix entre le couplage linéaire ou le couplage CAM. Le couplage linéaire ressemble à des roues dentées de son fonctionnement donc nous choisissons la vitesse de multiplication de l’axe esclave par rapport à l’axe maître. Cette axe suis les besoins de l’axe maître mais est plus difficile à mettre en place pour un mouvement balancier. Contrairement au couplage linéaire, le couplage CAM est quand à lui beaucoup plus performant. Ce couplage permet d’utilisé n’importe qu’elle sens de manière précise et efficace. Les 3 variables les plus importantes sont aussi encadrées en rouges. La première variable « gMpLinkAxe1 » permet de gérer la mise en route du moteur esclave. La seconde variable « AxisPar3 » quand à elle permet de gérer les réglages du couplage. Puis la dernière variable « gMpLinkAxe2 » permet la représentation de l’axe maître que l’axe esclave va devoir suivre.

Après avoir crée les différents blocs nous avons introduit les nouvelles variables sur l’interface. Nous avons une partie pour activer et commander l’axe maître. Puis nous avons une seconde partie pour activer l’axe esclave. Pour finir nous avons une partie permettant de voir si les moteurs sont prêt à être couplés puis nous pouvons choisir entre les 2 couplages différents. Nous pouvons donc choisir de contrôler les moteurs de manière séparé ou de manière couplé.

IHM des moteurs Pas à Pas

Pour pouvoir démarrer les moteurs nous devons refaire les mêmes étapes énoncés dans la partie moteur asynchrone. Puis pour choisir le couplage nous avons la variable « GEAR » qui est la variable pour avoir le couplage linéaire et nous avons la variable « CAM » qui est pour la couplage CAM. Nous avons 2 entrée numériques qui sont « NUM » et « DEN » qui permettent de rentrer 2 valeurs une au numérateur et l’autre au dénominateur pour calculé un rapport de transformation. Puis pour prendre en compte les nouveaux réglages fait nous avons la variable « UPDATE ».

Servomoteurs

Nous allons étudié un dernier type de moteurs. Ces moteurs sont des servomoteurs. Un servomoteur est un système produisant un mouvement grâce à une commande externe. Pour cette partie nous allons nous aidés des blocs de la partie précédentes. Nous gardons les mêmes variables, les seuls qui changent sont les variables encadrées en rouge.

Bloc MpAxisBasic_0

Le bloc nommé « MpAxisBasic_0 » permet de contrôlé l’axe maître. Celui-ci sera un axe virtuel contrairement à la partie précédente où nous avons un axe maître réel. La première variable nommée « gAxisBasic » permet de contrôlé les différentes commandes de l’axe. La seconde variable « AxisPar » permet de contrôlé les différents réglages concernant le moteur. Pour la dernière variable « gVAxis01 », celle-ci permet d’identifiée l’axe que nous allons contrôler. Pour cette variable nous allons utilisé l’axe virtuel. Nous avons 2 autres blocs nommé « MpAxisBasic_1 et MpAxisBasic_2 », qui sont similaire au bloc ci-dessus mais permettent de contrôler les axes réels des servomoteur 1 et servomoteur 2.

Bloc MpAxisCoupling_1

Le bloc ci-dessus nommé « MpAxisCoupling_1 » nous permet de faire le couplage entre deux axes. Nous avons la première variable « gAxisBasic_2 » cette variable représente l’axe esclave d’un des moteurs. La second variable « AxisPar4 » celle-ci permet de choisir les réglages de l’axe. La dernière variable « gAxisBasic » représente l’axe maître que va devoir suivre l’axe esclave. Nous avons un second bloc de couplage pour le second servomoteurs ayant les variables différentes mais un fonctionnement similaire.

Pour la partie visualisation nous avons réutilisé IHM de la partie précédente que nous avons amélioré et ajouté les différentes variables nécessaires.

IHM des servomoteurs

Nous avons ajouté une partie maître pour nous permettre d’allumer et de contrôler l’axe virtuel. Le reste des variables restent les mêmes et les étapes pour allumer les moteurs sont identiques à toutes les parties. Nous avons juste à active la partie maître en premier si nous voulons que les moteurs suivent l’axe virtuel.

Conclusion


COMMUNICATION OPC UA & ARCHITECTURE RÉSEAU

Remerciements

Nous tenons à chaleureusement remercier notre enseignant de réseaux et notre superviseur de projet Monsieur MERCKLÉ. Pour sa disponibilité lorsque nous avions besoin d’aide et pour son engouement autour du sujet ce qui a boosté notre curiosité et nous a beaucoup motivé pour donner le meilleur de nous-même durant ce travail.

Sommaire

I) Introduction

II) Présentation

II).a) Gestion du projet :

II).b) L’OPC UA ?

II).c) OPC DA / OPC UA:

II).d) Disposition réelle des équipements

III) Réalisation

III).a) Serveur

III).b) Protocole Client 01

III).c) Protocole Client 02

III).d) Protocole Client 05

III).e) UA Expert

IV).a) Pages d’Aide

IV).b) Réalisation du support de la colonne lumineuse

IV).c) Pilotage d’une colonne lumineuse

V) Améliorations

VI) Conclusion

I) Introduction

Ce projet Études & Réalisation du 3ème et 4ème semestre en DUT GEII, traitait le protocole de communication OPC UA (Open Platform Communications Unified Architecture). 

En effet, ce protocole de communication industriel développé par OPC Foundation qui est un regroupement de 5 entreprises fait en 1994, permet la communication au sein d’une machine, entre machines et entre une machine et sa supervision. Il a plusieurs points forts, notamment le fait d’être compatible toutes plateformes (Windows, Linux, Android et Mac). Ce qui permet son utilisation au sein de n’importe quelle entreprise industrielle tout en gardant leurs postes informatiques actuel sans se soucier de l’OS. Ce qui est une restriction en moins et une économie financière en plus.

Ce protocole fonctionne suivant le principe client-serveur avec plusieurs types de clients.

De plus, le fait que les transferts de données se fassent par un et unique protocole et que les connections à différents clients nécessitent plusieurs étapes, tout cela fait que c’est un protocole sécurisé.

L’OPC UA va indéniablement se démocratiser de plus en plus au sein des industries étant donné que nous sommes aux prémices de la 4ème Révolution Industrielle, dans laquelle toutes les machines/objets industriels seront interconnectés entres eux et c’est ce que permettra ce protocole. Protocole qui est d’ailleur standardisé pour permettre l’Industrie 4.0 .

II) Présentation

L’aboutissement de notre projet est la mise en oeuvre d’un tutoriel complet expliquant  l’OPC UA. Ce tutoriel est destiné à notre enseignant Monsieur MERCKLÉ et aux futurs étudiants de DUT/LP SARII car il agit sur le cours traitant du protocole de communication OPC UA dans le but de faciliter sa compréhension au travers d’une prise en main concrète et appuyé par des pages d’aide. Ci-dessous la Bête-à-cornes définissant synthétiquement  notre projet :

II).a) Gestion du projet :

Pour réaliser ce projet nous nous somme fixé durant les heures de TP plusieurs objectifs. Ce projet qui totalise environ 100h de travail a été divisé en plusieurs parties.

Tout d’abord nous avons consacré environ 12h de travail sur la découverte et l’apprentissage du logiciel Automation Studio, afin de comprendre ses fonctionnalitées et son utilisation. Puis nous avons pris connaissance et développé le client 01 sur 14h pour mieux s’approprier et appréhender le protocole OPC UA. Nous avons passé ensuite 10h sur le client 02 qui possédait des outils différents rendant son utilisation plus complexe. Pour finir nous avons étudié et mis en place le client 05 en environ 15h. Nous sommes resté cohérent sur nos objectifs tout au long du projet tout en respectant les temps impartis.

II).b) L’OPC UA?

Présent sur la couche 4 du modèle OSI (Transport), OPC UA contrairement à d’autres protocole est indépendant, il n’est donc pas développé par un fabricant d’automates, mais par OPC Foundation un Consortium industriel de 5 entreprises à but non lucratif (Fisher-Rosemount, Rockwell Software, Opto, Intellution, Intuitive Technology), son développement a commencé en 1994. Il fonctionne classiquement sur le principe client-serveur avec une communication transparente, des capteurs-actionneurs aux systèmes ERP ou au cloud. Le protocole est indépendant de la plateforme et contient de base des mécanismes de sécurité. 

Plus simplement, le but d’OPC UA est d’unifier les communications des appareils et des composants, il est donc compatible avec tous les OS (Mac, Linux, Android et Windows), et avec une grosse partie des appareils : exactement ce qu’il faut dans l’industrie dite “4.0”. Très utilisé chez nos voisins Allemand, il tend à se développer en France (l’entreprise allemande Hager de gestion de l’énergie l’utilise dans ses usines en France par exemple)  et finira inéluctablement par prendre le dessus sur d’anciens protocoles moins universels, car il ne demande pas de changement d’équipements.  

OPC UA est un modèle cohérent, global et normalisé (IEC 62451), il est invisible pour les équipements et permet l’échange de données au sein d’une machine, entre machines et également entre une machine et un système. Via cette unification, les systèmes, les machines et les composants deviennent toutes des ressources pilotées par un superviseur. Là est la pierre angulaire d’OPC UA, l’universalisme dans l’utilisation et la transmission des données, qui permet et permettra à l’industrie de réduire drastiquement ses coûts. 

OPC Foundation a également axé le développement d’OPC UA sur la cyber sécurité, comme vous le verrez tout au long de ce projet le protocole intègre un système d’authentification et d’autorisation utilisateurs, certains utilisateurs auront accès ou non à l’écriture ou à la lecture de données contenues sur le ou les serveurs, bien évidemment les données sont chiffrées et les actions faites par les utilisateurs peuvent être tracées.

Structure du réseau OPC


Le standard de l’OPC UA comporte au minimum un Serveur OPC qui possède le langage propriétaire du matériel ou du logiciel  où il va collecter les informations à exploiter.

Il possède également une application ou Client OPC qui met en oeuvre les spécifications du standard et qui communique avec n’importe quel Serveur  OPC.

Il peut également contenir des informations ou données à exploiter telles que : des valeurs stockées sur des automates, des bases de données ou tout autres fichiers). 

Ce standard est résumé sur le schéma ci-dessous:

II).c) OPC DA/ OPC UA


L’OPC classique, est le prédecesseur de l’OPC UA qui lui mêle les différentes variantes telles que l’OPC DA, AE ou encore  HDA. L’OPC classique utilise DCOM (une technique de communication entre logiciels dans un réseau) pour établir un lien entre serveur et client, alors que l’OPC UA lui utilise différents protocoles de communication comme le TCP/IP ou encore le HTTPS qui permettent l’utilisation de données externes telles que des fichiers excels ou drives. Ces protocoles dépendent du SDK (kit de développement qui dispose d’un convertisseur de langage de programmation en langage machine) qui rend l’utilisation de ces protocoles possible et rend la communication efficace.

L’OPC DA est un groupe de standards qui se focalise sur l’acquisition des données en continu, il est très facile de récupérer la valeur d’une variable et de lui affecter plusieurs éléments comme par exemple une heure d’échantillonnage ou la qualité d’un signal. En revanche les valeurs sont publiques, entraînant une faible sécurité des données notamment pour les variables pilotées. OPC DA est aussi OS dépendant car le protocole est uniquement défini pour windows. Le protocole fonctionne avec une architecture reliant tous les appareils entre eux. 

Le protocole OPC UA reprend le protocole OPC DA classique en corrigeant ses défauts. Cette fois le logiciel est OS indépendant et sécurisé.

II).d) Disposition réelle des équipements

Pour mener à bien ce projet nous avons utilisé plusieurs équipements. Nous avions à notre disposition deux PC pour développer sur le logiciel Automation Studio, Ainsi que deux Automates programmables avec CPU  (automate avec unité de calcul). Chaque automate possède sa propre adresse IP, la CPU 1 a pour adresse : 200.200.200.186 et la CPU 2 : 200.200.200.184. 

Par la suite nous avons ajouté un Coupleur de Bus ou BC (Bus Controller) qui lui a pour adresse 200.200.200.165. La CPU 1 est utilisé pour les clients et communique avec la CPU 2 et le coupleur de bus sur lesquels sont stockés le serveur. Sur les sorties de notre coupleur de bus il y a deux leds branchées, nous verrons ce que nous pouvons en faire…

III) Réalisation

Configuration des Automates 

Au début, nous allons faire tourner les clients en simulation sur un poste, et le serveur en simulation sur un autre,  une fois que ce sera fonctionnel, nous allons faire communiquer le client stocké sur un CPU automate avec le serveur sur un autre CPU automate, enfin, nous ajouterons un coupleur de bus sur lequel tournera également le serveur et dont nous essayerons de piloter les entrées et les sorties.

Etapes de Réalisation 

Il faut bien comprendre que OPC UA est un protocole permettant de donner précisément des droits d’accès ou non à des utilisateurs aux données stockées sur le serveur, par conséquent lorsqu’on lance un projet OPC UA, il y a des pages utilisateurs déjà faites, chacune ayant des droits précis et différents, ainsi qu’une page serveur avec des variables stockées dessus. Par exemple VarX, VarY et VarZ qui s’incrémentent avec le temps via une fonction codée sur le serveur (ce qui peut permettre de vérifier par exemple que l’on récupère bien sur le client les valeurs d’une variable en temps réel si il a cette permission). Mais on peut très bien déclarer nos variables et y accéder. 

Durant ce projet nous avons développé l’accès et la supervision de 3 d’entre eux, le “Client 01”, “Client 02” et le “Client 05”. Le Client 01 utilise des blocs fonctions qui lui permettent uniquement d’écrire ou lire une valeur d’une données du serveur. Il aura accès à la valeur de cette donnée uniquement lorsqu’il en fait la demande. Le Client 2 lui, peut lire une variable mais cette fois ci de manière monitoré, c’est à dire que le serveur lui renvoie la valeur d’une données en temps réel, à un interval de temps défini. Ces deux clients nécessitent que le serveur tourne sur une CPU car il effectue des calculs continu. 

Le Client 05 quant-à-lui est un peu différent, car il sera utilisé pour communiquer avec des matériels n’ayant pas d’unité de calcul, comme un coupleur de bus par exemple. Nous disposons d’un coupleur de bus B&R sur lequel deux leds sont installées, nous tâcherons de pouvoir les allumer et les éteindre à notre guise.

Librairie ASOPCUAC & Bloc fonction

Le projet OPC UA créé contient plusieurs bibliothèques (library), la plus importante et celle que nous utiliserons le plus est “AsOpcUac”, elle contient tous les blocs fonctions (structure) de données utilisées par les clients. 

Durant ce projet, une bonne partie des blocs fonctions présents dans la bibliothèque ont été utilisés, il faut donc bien comprendre ce qu’est un bloc fonction.

Ils sont très utilisés en automatisme, ils sont l’équivalent des structures en programmation classique, c’est un ensemble de programmes ou de fonctions contenu dans un autre élément (ici la liste à gauche). Ils contiennent donc des méthodes qui leurs sont propres et des variables qui peuvent être de type différents et défini en temps que entrée ou sortie. C’est comme un programme dans le programme, ce qui facilite grandement la compréhension du code.

Tous les blocs fonctions utilisées durant le projet sont disponibles en annexe.

III).a) Serveur 

Nous avons d’abord réalisé une visu serveur, afin de visualiser la valeur des variables stockées sur celui-ci.

Déclaration des variables :

Visu du serveur : 

III).b) Protocole du Client 01 

Voici le Protocole donné dans la documentation du Client01 :

L’organigramme est le suivant : 

Nous pouvons voir que les blocs fonctions comportent des variables booléennes d’états, “occupé” (busy) et “terminé” (done), qui permettent de vérifier l’accès aux blocs fonctions. 

Voici dans le détail les explications des actions effectuées par chaque bloc : 

Avant toute choses il nous a fallu modifier la valeur de “ServerEndPointUrl” dans la page de code du client 01, en donnant l’adresse du serveur, ici notre serveur est à l’adresse IP 200.200.200.184.

Nous avons ensuite créé une visu et à l’aide de bouton, un par bloc, nous avons pour chaque bloc fonction, passé à 1 leurs variables booléennes “Execute”.  

Il faut donc, passer par les blocs : 

  • Connect
  • NameSpaceGetIndex
  • NodeGetHandle

Afin de pouvoir lire ou écrire sur une variable stockée sur le serveur. 

Une fois les opérations voulues terminées, pour se déconnecter il faudra passer par les blocs : 

  • NodeReleaseHandle
  • Disconnect

Pour chaque bloc fonction nous avons affiché leurs variables d’état, le voyant de gauche devient orange si le bloc fonction est occupé (busy) et celui de droite devient vert lorsqu’il n’a pas renvoyé d’erreurs (done). 

Le bloc fonction “Connect” contient une variable qui renvoie une valeur qui est l’indice de connexion qui nous est propre (ce qui fait que la connexion peut être retracée comme nous l’avons vu précédemment), nous affichons également la valeur stockée dans “NameSpaceIndex” qui est une valeur propre à la machine sur laquelle nous nous connectons. Si plusieurs clients sont connectés sur la même machine, ils auront le même NameSpaceIndex.

“NodeGetHandle” renvoie également une valeur qui sera propre à la connexion à une variable, la modification par exemple d’une donnée par un utilisateur peut donc également être retracée. 

Lorsque qu’on exécute le bloc Read ou Write, une variable de type “DATE” est renvoyée nous l’avons également affichée, on peut non seulement savoir qui a accédé ou modifié une valeur, mais également quand. 

Coté client nous avons deux variables, VarA et VarB, lorsque nous exécutons un “READ”, VarA et VarB récupère la valeur de la variable VarX stockée sur le serveur. Les valeurs ne se mettent pas à jour automatiquement, il faudra donc exécuter le bloc fonction “READ” dès que l’on veut récupérer la valeur actuelle de VarX.

VarB dans notre visu est un objet dans lequel on peut écrire une valeur lorsque qu’on exécute un “WRITE” la valeur de VarX récupère la valeur de VarB, et VarB s’incrémente de 1. 

Voici la visu créée pour le client 01 :

III).c) Protocole Client 02 

Voici les étapes d’utilisation données dans la documentation technique du client 02 :

Voici l’organigramme du client 02, avec en petit les blocs fonctions similaires au client 01, nous pouvons voir que le bloc Read/Write a été remplacé par 4 autres blocs :

Explication des 4 nouveaux blocs fonctions : 

Le client 02 contrairement au client 01 peut donc, cycliquement lire la valeur d’une variable contenue sur le serveur, c’est à dire qu’une fois qu’il aura fait le lien avec une variable grâce à SubscriptionCreate (ici VarX), il pourra monitorer une variable coté client avec MonitoredItemAdd (ici VarA). 

VarA récupère donc la valeur de VarX à un intervalle de temps donné, défini dans le programme, ici 1 seconde. Toute les secondes, SubscriptionCreate envoie une alerte (uniquement si VarX est modifié, rappelons que VarX s’incrémente en continu sur le serveur. Si sa valeur était constante SubscriptionCreate n’enverrait pas d’alerte), quand MonitoredItemAdd reçoit cette alerte, il déverse la valeur de VarX dans VarA. Ca y est, nous lisons une valeur du serveur cycliquement ! 

Il nous a fallu également modifier la valeur de “ServerEndPointUrl” dans la page de code du client 02, en donnant l’adresse du serveur. Ici notre serveur est aussi à l’adresse IP 200.200.200.184.

Visu du client 02 :

III).d) Protocole Client 05 

Voici les étapes de connexion au client 05 (comme nous les avons utilisées) : 

Comme vous pouvez le voir le protocole de connexion de ce client est quasiment similaire à celui du client 02 il permet cependant de lire une variable sur le serveur et de stocker sa valeur dans une variable monitorée et également d’écrire via celle-ci, le client 05 possède donc une étape Read/Write.  

Pour ce client, nous souhaitons donc piloter les leds branchées (via un “Write”) sur le coupleur de bus, il faudra donc dans le code du client 05 comme pour les précédents définir l’adresse IP sur laquelle on veut se connecter, ici 200.200.200.165. Afin de pouvoir piloter la led en temps réel, il faudra donc qu’on envoie une information cycliquement. Pour ce client nous avons décidé de ne pas utiliser les blocs SubscriptionCreate et MonitoredItemAdd. Pour les shunter et avoir un résultat équivalent, nous avons créé un programme ST “Clock” qui sera appelé cycliquement toutes les 1000ms. 

Dès que la “Clock” s’exécute nous modifions la variable “Execute” du bloc fonction “Write”, ce qui enverra donc cycliquement l’information voulue au serveur (soit ON soit OFF afin de piloter la led).

Avant toutes choses voici les modifications à apporter sur le code afin de se connecter au coupleur de bus : 

Username passe à Anonymous (donné dans l’aide d’AS) : 

On modifie “ServerEndPointUrl”, en donnant l’adresse du serveur, ici notre serveur est notre coupleur de bus à l’adresse IP 200.200.200.165.

Dans le bloc exécutant “GetNameSpaceIndex” la valeur de “NamespaceUri” doit être modifiée (donné dans l’aide d’AS).

Nous sommes maintenant prêt à intégrer notre bloc fonction “Write”. 

Voici l’organigramme du client 05 : 

Un bloc fonction est venu se rajouter : “TranslatePath”, nous vous expliquerons son fonctionnement, mais pour le définir il faut utiliser un autre outil, UA Expert…

III).e) UA Expert

Pour le client 05 et la connexion avec le coupleur nous avons été amené à utiliser UA expert, un logiciel ayant de multiples fonctionnalités, il nous permet par exemple d’accéder aux données du serveur, aux historiques de connexions… Nous l’utiliserons afin de diagnostiquer notre matériel, en accédant à notre coupleur de bus avec UA expert nous pouvons visualiser les chemins d’accès aux entrées et sorties de nos variables et nous pouvons également les piloter. Nous avons donc deux leds branchées sur notre coupleur de bus, ainsi nous pouvons vérifier sur quelle sortie elles sont branchées. Après les avoir tester nous avons pu voir qu’elles étaient branchées sur les sorties “DigitalOutput01” pour la bleue et “DigitalOutput02” pour la blanche.

Le Client 05 qui pilotera les sorties de notre coupleur de bus dispose donc d’un bloc fonction TranslatePath qui convertit un chemin d’accès à une sortie d’un appareil (Relative Path) en un “NodeIDs” compris et utilisable par OPC UA. Dans la documentation technique, il est expliqué comment construire son Relative Path. 

Pour notre led bleue (DigitalOutput01) Le chemin d’accès sera donc : 

‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’ 

Et notre ligne de code : 

RelativePath:=‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’

Arbre des dossiers du coupleur de bus sur UAexpert, que nous avons dû suivre pour écrire notre RelativePath

Le bloc servant à écrire (Write, voir ci-dessous) est donné dans l’aide, mais bien évidemment des modifications sont à effectuer pour coller à notre système. “StartNodeID_Root.Identifier” prend la valeur 85 (pour Objects, voir image ci-dessus). Ensuite il faut donner notre RelativePath, notons qu’avec la fonction strcat() de la librairie AsString (à ajouter) on peut concaténer des chaînes de caractères et découper le RelativePath pour qu’il soit plus facilement modulable, ce qui peut permettre par exemple de n’avoir qu’à modifier le “01” final en “02” pour se connecter à la sortie numéro 2. Ca y est, nos leds sont pilotables !

Visu client 05 :

IV).a) Pages d’aide

Pour finir, afin de rendre le logiciel que l’on a développé plus compréhensible, nous avons créé des pages d’aide, qui expliquent les protocoles de connexions aux différents clients. 

Dans un premier temps nous avons créé une page d’accueil, puis dans celle-ci nous avons ajouté une aide concernant l’OPC UA et ses fonctionnalités permettant aux utilisateurs de mieux comprendre les étapes communes aux différents clients. Par la suite nous avons également créé une aide pour chaque clients et ainsi détaillés leurs blocs fonctions. Il y a par conséquent une aide pour le client 01, le client 02 et le client 05 qui lui reprend des méthodes du client 02 et dispose d’un renvoie à l’aide de celui-ci. En effet dans le client 05, certaines étapes ne sont pas utilisées car nous les avons contourné étant donné que nous utilisons une méthode différente permettant d’effectuer les mêmes opérations (Clock).

IV).b) Réalisation du support de la colonne lumineuse 

La colonne lumineuse que nous allons piloter est constituée de 4 Leds, un buzzer et un bouton poussoir. Pour assembler les composants et former une colonne lumineuse nous avons élaboré et construit une boîte pouvant contenir l’ensemble des composants et pouvant être directement fixé sur des supports du panneau. 

Voici le rendu final du boîtier, accueillant l’ensemble des équipements (Leds, buzzer, bouton poussoir).

IV).c) Pilotage d’une colonne lumineuse

Nous allons dans cette partie controller une colonne lumineuse constitué de plusieurs entrées (bouton poussoir) et plusieurs sorties (4 Leds et un buzzer). Pour cela il est nécessaire de pouvoir contrôler plusieurs entrée/sortie. 

V) Améliorations

Une fois la découverte de tous les types de clients, à nous de composer. On pourrait imaginer fusionner des clients pour créer le nôtre afin de lui donner des droits bien précis que l’on aurait défini. Dans certaines variantes du client 1, le client peut lire ou écrire des tableaux sur le serveur, on pourrait imaginer, en le fusionnant avec le client 02, lire cycliquement la valeur d’un tableau stocké sur le serveur. 

Enfin on pourrait modifier le serveur afin qu’il effectue d’autres opérations, on pourrait concevoir une calculatrice, à qui on enverrait des valeurs depuis le client et qui effectuerait les opérations sur le serveur. 

On pourrait également rajouter d’autres appareils, communiquer avec d’autres automates qui effectueront des tâches bien précises, ou un autre coupleur de bus, voire même un capteur. OPC UA est de toute manière compatible avec une énorme partie des appareils disponibles dans notre salle de TP.

L’OPC UA tire aussi sa force dans sa sécurité et nous pourrions mettre en place des protocoles de sécurité (définition d’un mot de passe par client, d’un historique de connexion…).

Ce ne sont que des suppositions, peut être que nous déciderons à terme de faire autre chose si d’autres idées nous viennent. Si on peut en faire autant c’est que le protocole OPC UA est tellement vaste et offre tellement de possibilités que l’on aurait de quoi l’explorer et l’analyser pendant des semaines ! 

VI) Conclusion

Nous n’avions jamais entendu parler de ce protocole avant le premier cours d’étude et réalisation, et nous nous rendons compte à terme que nous avons vraiment bien fait de choisir ce projet. En effet, le protocole OPC UA tend tellement à se démocratiser, qu’on pourrait se demander s’il ne va pas devenir un standard dans l’industrie ? 

De part sa sécurité ou encore son utilisation il nous a permis de mieux comprendre l’enjeu des communications client serveur dans l’industrie. Il reste notamment accessible et est appliqué dans de nombreux domaines tels que le pharmaceutique, le pétrole, le gaz ou encore la robotique. 

Nous avons perçu ce projet comme bénéfique car il nous a permis de développer plus de connaissances dans ce domaine et de maîtriser efficacement l’OPC UA. Il nous reste de nombreux points à découvrir ou à approfondir. 

Ce projet rend bien compte de l’importance de la communication et ses protocoles liés au sein de  l’industrie et du basculement vers “l’industrie connectée”.

Annexes

Blocs Fonctions


Banc de vision 2019


INTRODUCTION

Le projet « Banc de Vision » a été effectué en collaboration avec des étudiants GMP. Il a été nécessaire d’allier les compétences des uns et des autres afin de mener à bien ce projet.

Ce banc de vision à été étudié et conçu afin de répondre à différents besoins: il permet d’une part la numérisation d’une pièce de fonderie sous différents angles de vue et facilite d’autre part la détection des défauts de surface éventuels sur une pièce. La structure du banc est commune avec d’autres projets tels que le banc de vision à éclairage multi-spectral et permet donc d’augmenter les possibilités proposées à l’utilisateur.

 


SOMMAIRE

1. DIAGRAMMES
2. CAHIER DES CHARGES
3. LISTE DU MATÉRIEL
4. MOTEUR PAS À PAS
5. CLAVIER 16 TOUCHES
6. CAPTEUR DE FIN DE COURSE
7. PAN-TILT
8. CONCEPTION DES PIECES MECANIQUES
9. CONCLUSION
10. ANNEXES

1. DIAGRAMMES

1.1. DIAGRAMME PIEUVRE

Ce banc de vision s’adresse à quiconque souhaite avoir une première approche de la géométrie d’un pièce de fonderie, en la visionnnant sous différents angles afin de numériser par exemple cette pièce ou de détecter des défauts de surface.

1.2. FONCTIONS

FP1: capturer une pièce de fonderie

FC1: s’adapter aux dimensions des pièces de fonderie

FC2: respecter le budget

FC3: se fixer au châssis prédéfini avec le projet « éclairage multi-spectral »

FC4: assurer une prise de vue sous différents angles et à différentes hauteurs

FC5: Permettre le stockage et le transfert des photos


2. CAHIER DES CHARGES

 

Il est demandé aux élèves l’étude préalable et la conception d’un banc de vision permettant de numériser une pièce (de fonderie par exemple) sous différents angles.

Ce banc est constitué d’une glissière verticale sur laquelle une caméra peut se déplacer de haut en bas et s’incliner grâce à un support pan-tilt. Ce mécanisme doit s’intégrer au sein d’une structure aluminium multifonctions, commune à différents projets.

Le cahier des charges stipule que le banc peut accueillir des pièces de fonderie de 300 mm de longueur, 300 mm de largeur et 400 mm de hauteur. La caméra permettant la prise de clichés doit être située à 400 mm minimum de la pièce à analyser. La pièce peut être posée sur un plateau tournant (autre projet) afin de visualiser toutes ses faces. Si l’on souhaite une vue de la partie haute de la pièce, la caméra pourra être déplacée le long d’un axe afin d’augmenter son altitude de prise de vue. Un moteur pas à pas assure la translation verticale de la caméra.

La capture de la pièce pourra être effectuée soit manuellement, soit à l’aide de programmes préétablis à l’aide d’un clavier de commande.

Afin de ne pas forcer le mécanisme et endommager les différentes pièces, deux butées de fin de course assurent la pérennité de l’ensemble du système.

 

Le diagramme FAST ci-dessous permet de retrouver toutes les fonctions de services , les solutions constructives ainsi que les critères auxquels le banc de vision doit répondre.

 

 


3. LISTE DU MATÉRIEL

Notre première mission a été de sélectionner le matériel nécessaire à nos tests.

  • une carte Arduino Mega
  • un moteur pas à pas de 12V, 1.2A
  • un shielda vis pour faciliter les branchements
  • une alimentation de 230V en entrée et 12V + 5V en sortie est utilisée pour alimenter l’ensemble du banc de vision.
  • un servo-moteur pour le pan-tilt
  • un clavier 16 touches
  • 2 capteurs de fin de course

 


4. MOTEUR PAS À PAS

Qu’est-ce qu’un moteur pas à pas ?

Un moteur pas à pas est un moteur permettant de commander précisément le positionnement de son rotor quel que soit le nombre de tours qu’il a à exécuter. Chaque moteur a un nombre de pas définis par révolution, c’est-à-dire un nombre de secteurs bien déterminé. Dans notre cas chaque pas fait 1,8°,  soit 200 pas pour effectuer un tour de 360°.

Afin d’assurer l’entrainement permettant la translation verticale de la caméra, nous avons utilisé un moteur pas à pas de 12V, 1.2A, un microstep driver permettant l’alimentation en puissance ainsi que la gestion partielle de la rotation du moteur et un Arduino Mega en guise d’électronique de commande.

Voici le schéma simplifié de l’installation:

La carte Arduino transmet un signal carré au micro step driver (partie puissance) qui se charge en interne d’alimenter alternativement chaque bobine du moteur. Plus la durée entre deux impulsions consécutives est courte, plus la vitesse de rotation du moteur est importante.

La cadence de rotation est déterminée par le temps séparant deux impulsions. Plus le temps est court, plus le moteur est rapide, plus le temps est grand, plus le moteur sera lent.

PINs:

  • PUL+/-: vitesse de rotation du moteur en fonction de la cadence des impulsions de l’Arduino
  • DIR+/-: sens de rotation du moteur
  • ENA+/-: alimentation du moteur (désactiver l’alimentation quand le moteur n’est pas en rotation, sinon il surchauffe!)
  • A et B: bobines du moteur

 


5. CLAVIER 16 TOUCHES

Un clavier 16 touches est utilisé afin de permettre aux utilisateurs de contrôler facilement le banc. Il est possible de démarrer des programmes automatiques, mais aussi de commander le banc en mode manuel.

Description des touches:

  • Carré noir: entrer en mode automatique
  • Carré blanc: entrer en mode manuel
  • 0,1,2,3: programmes automatiques
  • 9: trigger photos
  • Flèches Haut/Bas: monter/descendre le banc en mode manuel
  • Flèches Gauche/ Droite: monter/descendre le pan-tilt par pas de 10°
  • Autres touches: non utilisées pour l’instant

 

 

Le clavier fonctionne de la manière suivante:

Il est constitué de lignes et de colonnes, le tout étant relié aux ports de l’Arduino. Les lignes sont connectées sur des sorties et les colonnes sur des entrées. Chaque ligne du clavier est alimentée tour à tour en 5V (balayage).

 

 

Lors d’un appui sur une des touches du clavier, un contact se crée entre une ligne et une colonne et la détection de la touche est effectuée par l’Arduino. L’Arduino n’a plus qu’à réaliser la correspondance entre la ligne alimentée et la colonne d’où vient le signal pour connaître le numéro de la touche enfoncée. Une librairie permet de réaliser ce traitement.

 


6. CAPTEUR DE FIN DE COURSE

Les capteurs de fin de course que nous avons utilisés sont des capteurs infrarouges (E18-DN80K). Ils sont équipés d’un émetteur et d’un récepteur. L’émetteur crée un faisceau lumineux de manière constante. Temps que le faisceau n’est pas réfléchi, cela signifie qu’aucun obstacle n’est présent devant le capteur. Si au contraire le faisceau est réfléchi vers la cellule réceptrice, c’est qu’un obstacle est dans la trajectoire du faisceau. Le capteur transmet alors un signal de 5V continu au port de l’Arduino.

Dans notre cas, nous avons placé deux de ces capteurs sur le banc, un en haut de la glissière et l’autre en bas.

Si le capteur haut détecte un obstacle, il envoie un signal à l’Arduino afin de stopper la montée du plateau. Même principe avec le capteur bas, lorsque le plateau descend.

 


7. PAN-TILT

Afin de permettre à la caméra se s’incliner, nous avons utilisé un support un pan-tilt.

Un servo-moteur de modélisme permet l’inclinaison de celui-ci. Les GMP ont réalisé un support de caméra sur mesure afin d’épouser les formes du servo-moteur.

 

Au niveau de la programmation, nous avons fait le choix de donner au servo-moteur une course maximale de 90° par pas de 10°. Il peut donc se déplacer de l’horizontale à la verticale et inversement.

 


 

 

8. CONCEPTION DES PIECES MECANIQUES

8.1   Choix de conception

 

Le cahier des charges demande d’assurer la prise de vue de clichés dans différents angles et surtout à différentes hauteurs. De ce fait un guidage en translation de la caméra est nécessaire. Plusieurs solutions pouvaient être utilisées :

Guidage en translation par galet                                        Guidage en translation par patin                                   Guidage en translation par profilés ronds

 

Peu importe la choix de conception l’entrainement du plateau s’effectue avec un système poulie cranté / courroie.

Après réflexions c’est le guidage en translation par profilés ronds qui va être utilisé pour des raisons de coût, de faisabilité et d’assemblage. Le chariot (partie qui translate sur les profilés ronds) sera lié sur un profilé rond par une liaison pivot et sur l’autre profilé par une liaison bi-ponctuelle.

 

8.2   Vue d’ensemble

 

Pour avoir un aperçu de l’ensemble, ci-dessous une vue du projet modélisé sur Créo :

 

Parmi tous ces composants certaines pièces ont été achetées soit :

  • Les profilés ronds
  • Les supports d’arbres
  • Les deux poulies
  • Le bâti

 

8.3   Usinage de la plaque support

 

Ci-dessous la plaque support où tout les éléments du banc de vision vont se fixer. L’objectif de cela est de pouvoir avoir une interface amovible qui peut se démonter par l’intermédiaire de 4 vis. Cette plaque à été réalisée sur la machine de découpe jet d’eau dans l’atelier GMP.

 

8.4   Fabrication additive 3D

8.4.1  Conception du chariot

 

Comme dit précédemment, le chariot va coulisser sur deux profilés ronds mais avec deux liaisons différentes :

  • Une liaison pivot glissant d’un côté assurée par une douille à billes
  • Une liaison bi-ponctuelle pour empêcher la rotation de la pivot glissant

Les deux liaisons permettent d’aboutir à une liaison glissière qui correspond bien au mouvement recherché.

 

Nous avons décidé de nous orienter vers la fabrication additive 3D pour faire cette pièce, ci-dessous la conception finale du chariot :

Face avant du chariot                                                                                 Face arrière du chariot

 

Sur la face avant il  y a un trou qui permet par l’intermédiaire d’un boulon de fixer le pantilt qui à été fait également en impression 3D.

 

8.4.2  Support moteur

 

Pour fixer le moteur (qui va entraîner une poulie crantée) à la plaque support, un support à du être réalisé.

Le support répond bien à sa fonction mais plusieurs axes d’améliorations seraient envisageables. En effet la pièce n’est pas rigide et fléchit, il serait nécessaire d’ajouter des renforts sur la pièce ou bien de la faire en métal (Découpe jet d’eau + Pliage).

 

8.4.3  Pan tilt

 

Pour permettre l’inclinaison de la caméra, nous avons utilisé un servomoteur mais aucune interface n’était fournie avec. De ce fait toujours en fabrication additive plastique nous avons réalisé cette interface qui permet d’obtenir des prises de vues dans différents angles.

 

L’ensemble est composé de deux pièces :

  • Une pièce en liaison avec le chariot
  • Une pièce en liaison avec la caméra

Bien que le plastique offre une légèreté incomparable par rapport au métal, des renforts ont été prévus pour éviter toute flexion.

 

Ci-dessous un court aperçu du résultat final, aboutissement du travail effectué par les GEII et les GMP :

 

 


9. CONCLUSION GEII

Nous avons trouvé ce projet très intéressant. Le fait de pouvoir travailler en équipe avec un groupe de GMP très investis dans leur travail était un réel plaisir et nous a permis de mener à bien ce projet.

Ce projet nous a permis de découvrir le fonctionnement d’un moteur pas à pas mais aussi celui d’un clavier et d’un capteur infrarouge. Nous avons aussi pu approfondir nos connaissances en programmation et voir le potentiel impressionnant des cartes Arduino, pourtant vendues à un prix raisonnable. Ces dernières permettent de réaliser des projets aboutis avec une grande liberté et de multiples fonctionnalités.

Nous sommes satisfaits du résultat final et espérons que ce projet pourra évoluer dès l’an prochain!

 


10. ANNEXES

DATASHEET:

LIEN CAPTEUR DE FIN DE COURSE

LIEN CLAVIER 16 TOUCHES

LIEN CODE ARDUINO

LIEN CODE PRÉSENTATION POWER POINT


Banc de Vision à éclairage multi-spectral

Sommaire :

  1. Introduction
  2. Etude du projet
  3. Partie GMP
    1. Les solutions adoptées
    2. La CAO
    3. La réalisation du projet
  4. Partie GEII
    1. L’éclairage
    2. La capture d’images
    3. La motorisation
    4. Les supports des LEDs et le boitier de commande
  5. Conclusion

Introduction :

Le projet de « Banc d’éclairage multi-spectral » fut un projet en collaboration entre le département Génie Mécanique et Productique et le département Génie Electrique et Informatique Industrielle. Il nous a été confié par Monsieur Christophe Cudel, professeur dans le département GEII et responsable des apprentis de ce département.

Ce projet a pour but de prendre des photos en noir et blanc, sous différents spectres sélectionnés, de plusieurs pièces défilant sur un plateau motorisé. Ces différentes vues nous permettrons ensuite de mettre en évidence les défauts de la pièce. Nous pourrons aussi, avec les images de certains spectres, reconstituer une image couleur à partir de ceux-ci.

Pour cela, un groupe de 5 personnes fut constitué, 3 élèves de GMP et 2 élèves de GEII.

Les étudiants de GMP se sont occupés de toute la partie mécanique et du bâti et les étudiants de GEII ont développé toute la partie éclairage, la capture de l’image et la commande du moteur.

Le bâti ci-dessus, situé dans le département GEII, sera notre modèle. Pour notre projet, un bâti similaire a été commandé avec les dimensions adéquats. Il a été décidé que le bâti sera commun avec le projet de « Banc de vision » d’un autre groupe.

Etude du projet :

Pour débuter le projet, nous fûmes, tous les 5, une étude de celui-ci. Nous avons donc commencé par une bête à cornes afin de répondre aux questions : pour qui ? Sur quoi ? Pour quoi ?

Une fois ces questions résolues, nous avons pu établir une analyse fonctionnel du projet.

Le principe découlant de cette analyse est simple. Depuis un boitier de commande, nous commandons l’exécution des tâches suivantes : la couleur de l’éclairage, le nombre de pièces à analyser et le départ du traitement.

Les commandes effectuées depuis la console sont envoyées à l’arduino qui contrôle toute la procédure. Ainsi, en fonction des couleurs et du nombre de pièces choisies,l’arduino va envoyer les informations aux différents actionneurs aux moments voulus.

 

Partie GMP :

Les solutions adoptées :

Pour ce projet, l’idée nous ayant semblé la plus simple à réaliser s’est rapidement avéré être la réalisation d’une plaque circulaire avec des emplacements pour les pièces à photographier, cette solution ne nécessitant qu’un unique moteur, la ou une table se déplaçant sur deux axes en aurait nécessité deux.

Par la même, ce projet devant s’adapter dans un bâti composé de profilés, il nous est rapidement venu à l’idée d’ajouter à ce bâti une barre verticale, au fond au centre de ce bâti, sur laquelle nous pourrions fixer notre caméra et notre éclairage, ce à la verticale du plateau tournant qui emmènerait les pièces sous la caméra.

 

La CAO :

(CAO initiale de notre projet)

(CAO suite à modifications : pignons et roue-dentée ont été inversés – la barre verticale a été décalée sur un des cotés afin de pouvoir modifier le support des LEDs ainsi que le support caméra)

[Transmission entre le moteur qui vient se fixer sous l’adaptateur rouge et le plateau tournant, guidé par l’axe vert fixe dans le bâti, par un système roue dentée (jaune) – pignon (bleu). Nous nécessitons un rapport important de par la faible puissance du moteur que nous avions à utiliser. Les engrenages sont ici inversés (erreur de notre part, corrigé dans la version finale)]

[L’entraxe de l’engrenage est géré à l’aide de trous oblongs dans la plaque maintenant le moteur (en bleu), le pignon étant fixé sur l’adaptateur qui est directement sur la sortie du moteur]

(Cette plaque vient supporter une caméra. Il y a de nombreux trous dans la zone à droite permettant d’accueillir divers modèles de caméra)

[Cette plaque sert à tenir les deux anneaux de LEDs (1 RGB, 1 IR/UV). Sous les anneaux de LEDs sera fixé un diffusant (plaque de plastique semi-transparente)].

 

[Ces deux plaques sont fixées au bâti par des équerres, permettant d’en régler la position en hauteur. On peut voir sur cette image le plus gros des modèles de caméra que nous avions à adapter sur le support, et le plus grand des anneaux de LEDs (en rouge). La caméra peut passer au travers du support de LEDs à l’aide du trou situé en son milieu]

[Le plateau tournant (jaune) peut accueillir deux plateaux différents, avec respectivement six et neuf cases, mis en position par les deux goujons gris]

La réalisation du projet :

Nous n’avons pas eu le temps de réaliser toutes les pièces de notre projet : seul ont été réalisés : le palier lisse venant sur l’axe du plateau tournant pour permettre la rotation de ce dernier, l’adaptateur sortie du moteur, et l’axe du plateau tournant.

 

La partie GEII :

L’éclairage :

Afin d’éclairer le banc de vision, 2 cercles de LEDs furent utilisés. Un premier, petit, composé de 24 LEDs et un second, plus grand, composé de 4 quart de cercle, pour un total de 60 LEDs.

Le premier cercle fut utilisé pour l’éclairage du banc dans les spectres visibles par l’œil humain. Le second cercle aurait dû être utilisé pour l’éclairage du banc dans les spectres invisibles par l’homme, l’infrarouge et l’ultraviolet. Malheureusement, les LEDs infrarouges et ultraviolettes étant relativement chère, le second cercle n’a pas pu être modifier. Il éclairera donc sous le même spectre que le premier.

Les cercles sont composés de LEDs adressables WS2812B. La spécificité de celles-ci est qu’elles sont transmetteuses. C’est à dire qu’une LED, connectée en série avec les autres, va recevoir une trame de n fois 24 bits. Cette trame constitue le paramétrage des LEDs. La première LED va être paramétrée par les premier 24 bit puis, va transmettre le reste de la trame à la LED suivante. Cette opération va se produire le nombre de fois, n, équivalent au nombre de LEDs que possède le cercle paramétré.

Afin de commander nos cercles, nous avons utilisé un arduino UNO, qui sera aussi utilisé pour la capture d’image et la commande du moteur, et la bibliothèque  de fonctions fourni par le constructeur.  Le programme de la gestion de l’éclairage peut être résumé par le diagramme suivant :

L’entièreté des programmes sont disponible en téléchargement ici.

La capture de l’image :

Pour la capture d’images nous avions comme obligation de pouvoir accepter une caméra standard ou une caméra intelligente, pour le projet un caméra cognex. Ces caméra ont la possibilité de prendre des photos grâce à un signal déclencheur, nous avons donc utilisé cela lors de ce projet.

Nous avons intégré le déclenchement de la capture dans le programme de la gestion des éclairages comme le diagramme ci-dessous peut vous le montrer.

Après l’allumage des LEDs dans la couleur souhaité nous envoyant une impulsion, par le biais d’un signal haut puis bas, sur l’entrée de déclenchement de la caméra.

Les caméra étant différentes, un soucis se posa. La caméra standard acceptant un signal de déclenchement de 5V n’a aucun soucis pour fonctionner en étant branchée sur l’arduino. En revanche, la caméra Cognex a un déclenchement plus élevé.

Nous avons donc utilisé un optocoupleur afin de le piloter. Pour cela l’optocoupleur a dû être modifié car le signal sortie était encore trop faible. En effet, l’optocoupleur possédait une résistance de 10kΩ  qui, couplé avec les 10kΩ déjà présent, était beaucoup trop élevé. Pour abaisser cette résistance, nous avons donc rajouté une résistance de 10kΩ  en parallèle à celle de l’optocoupleur.

Cela nous a permis de baisser suffisamment la résistance pour que le signal de déclenchement soit détecté par la caméra.

Le fonctionnement du moteur :

Pour le défilement des pièces nous avons utilisé un moteur pas à pas, contrôlé par l’arduino, via un shield moteur.Ce moteur est composé de deux bobines qui fonctionne de manière alterné afin de faire tourner l’axe. Cette gestion alternative est gérer par le shield moteur, il nous a permis de commander le sens du moteur, sa rotation ainsi que son alimentation.

Lors de l’exécution du programme, l’arduino envoie une demande de rotation au shield moteur via une impulsion en 5V. Celui-ci envoie ensuite la commande au moteur via un signal en 12V.

Cette impulsion faisant tourner le moteur que d’un seul pas, nous avons donc bouclé cette partie de code afin de l’exécuter le nombre de fois nécessaire. Notre programme possédant 2 modes de fonctionnement, le premier permet de traiter 6 pièces et le second 9 pièces, celui-ci devra donc boucler un nombre différent de fois.

Afin de calculer ce nombre nous savions que le moteur possédait 200 pas, nous avons donc divisé ce nombre par le nombre de pièce observées afin de connaitre le nombre de pas à effectuer entre chaque pièce. Lors ce ces calculs, nous avons remarqué un reste dans ces division. Ainsi pour supprimer le décalage qui sera créé, nous avons ajouté une rotation de 2 pas à la fin du programme.

Les supports des LEDs et le boitier de commande :

Les supports des cercles de LEDs n’ayant pas pu être usinés par le GMP par manque de temps, nous les avons donc fait à l’IUT LAB. Pour cela nous les avons dessinés sur le logiciel CorelDraw puis fait découper par une découpeuse/graveuse laser (CNC) sur une plaque de contreplaqué de 5mm. Nous avons aussi découpé les diffusants sur une plaque de plastique transparent de 3mm.

Une fois les pièces finalisées, nous avons vissé/collé les cercles de LEDs sur leur support et mis en  place leurs diffusants.

Nous en avons aussi profité pour créer notre boitier de commande. Pour cela nous avons réutilisé la CNC afin de découper notre boîte dans une planche de contreplaqué de 5mm. Sur la face avant nous avons ajouté des trous afin de pouvoir fixer les différentes commandes sur le boîtier. Nous y avons aussi fait graver la fonction de chaque commande afin que l’interface soit clair pour l’utilisateur et quelques éléments esthétiques pour finalement obtenir ce résultat :

Conclusion :

Lors de ce projet nous avons pu apprendre beaucoup de choses. Nous avons notamment pu découvrir ce qu’était un optocoupleur et comment cela fonctionnait, ou encore comment contrôler un moteur pas à pas grâce à un arduino. La plus grande découverte fut le fonctionnement des LEDs adressables ainsi que la manière de les programmer grâce à sa bibliothèque de fonctions.

Au final, ce projet a pu nous apporter beaucoup de chose, tant en apprentissage qu’en mise en oeuvre de connaissances. Nous avons aussi pu découvrir et utiliser des machines complexes à l’IUT LAB ainsi que leurs logiciel d’exploitation. Tout cela fut très instructif malgré certains points n’ayant pas pu êtres testé en conditions réelles, dû à certaines pièces manquantes.

Ce projet pourrait donc être amélioré de plusieurs façons :

Pour commencer, nous pourrions usiner les différents plateaux initialement pensés.

Ensuite, nous pourrions tester notre programme de commande du moteur et le corriger aux besoins.

Une fois ces éléments fait, nous pourrions installer notre système sur le bâti initial.

Ces étapes importantes faites, nous pourrions refaire le câblage des éléments du projet, afin que notre boîtier de commande ne s’ouvre plus sous la pression des câbles à l’intérieurs.

Nous pourrions aussi le modifier en y ajoutant un bornier. Cela nous facilitera le câblage, le branchement/débranchement et le changement de caméra. Cela isolerait aussi le câblage à l’intérieur du boitier, ce qui nous garantira l’intégrité du câblage de la boite.

 

Nous espérons que ce projet pourra être continué l’année prochaine et que les améliorations citées ci-dessus pourront être mise en oeuvre.


Tracker Solaire

Sommaire

  1. Introduction
  2. Définition du besoin
  3. Analyse solaire
  4. Analyse mécanique
  5. Analyse électrique
  6. Réalisation
  7. Conclusion

 

Introduction

Dans le cadre d’un projet de deuxième année de DUT partagé entre le département GEII et le département GMP, nous travaillons sur un système de tracker solaire. L’objectif du projet est de créer un système asservi capable de suivre la trajectoire du soleil afin de maximiser le rendement de la production d’un panneau solaire. A travers ce document, nous allons présenter les différentes études menées, les problématiques rencontrées et les solutions proposées pour répondre à la problématique du projet.

Notre groupe est ainsi composé de 6 étudiants :

  • Kelian Khassani – GMP
  • Arnaud Zehringer – GMP
  • Timothé Roussel – GMP
  • Boubacar Diallo – GEII
  • Sofian Beldi – GEII
  • Hugo Houillon – GEII

Définition du besoin

La première étape de la réalisation de ce projet est la réalisation du cahier des charges et la définition du besoin ainsi que des différentes contraintes que nous serons amenés à rencontrer.

La but premier de ce projet est d’établir un système permettant pour l’instant à un panneau solaire de suivre la trajectoire du soleil afin de maximiser sa production.

 

Analyse solaire

La trajectoire du soleil se définie selon deux paramètres exprimés en degré :

 

  • L’azimut : Représente la position du soleil selon les 4 points cardinaux

 

  • La hauteur : Représente l’inclinaison du soleil par rapport à l’origine du plan horizontal

 

Les panneaux solaires devront donc être orientés de façon à être perpendiculaire aux rayons du soleil.

 

Afin de déterminer exactement les intervalles de position des panneaux selon ces deux paramètres, nous avons utilisé le site internet SunEarthTool. Ce site permet de calculer automatiquement la position du soleil dans l’année selon des coordonnées GPS.

Nous avons donc renseigné à ce site internet la position à laquelle nous souhaitons installer les panneaux solaires :

Une fois le site choisi, le site nous donne la position du soleil selon les mois de l’année :

 

Nous avons donc pu déterminer que le panneau solaire devra avoir une course de 50 à 310 ° en azimuth et de 20 à 90 ° en hauteur.

Afin d’estimer la production du panneau solaire tracké sur deux axes, nous avons utilisé un second site qui calcule automatiquement la production d’un panneau solaire selon les mois de l’année.

Nous avons renseigné les caractéristiques du panneau dont on dispose :

  • Puissance maximale : 145 W
  • Courant de court-circuit : 4,7 A
  • Tension maximum : 34 V
  • Courant maximum : 4,26 A

Nous avons regardé combien produirai potentiellement un panneau fixe incliné à 35° et combien produirai potentiellement un panneau tracké sur deux axes. Nous avons ensuite comparé les deux tableaux pour voir s’il est rentable d’effectuer un panneau solaire tracké sur deux axes.

 

En moyenne, nous remarquons qu’un système de panneau solaire tracké sur deux axes pourrait produire 30% de plus qu’un panneau fixe et incliné à 30°.

Il faut également faire attention au fait que le tracker ne doive pas consommer plus que le surplus produit par un système tracké pendant le mois le plus défavorable. Il faut donc que le tracker ne consomme pas plus de 1,2 kWh mensuel.

Analyse mécanique

Afin de permettre au panneau solaire de se déplacer sur 2 axes les GMP ont imaginé un système équipé d’un motoréducteur pour suivre l’azimut du soleil et d’un vérin électrique pour suivre la hauteur du soleil.

 

Analyse électrique

Toute l’énergie produite par le panneau solaire est acheminée au travers d’un régulateur de charge qui va s’occuper de charger les batteries correctement.

Pour ce projet, nous avons fait le choix de travailler en 24V. C’est pourquoi, nous avons acheté 2 batteries de 12V 12Ah branchées en série. Le motoréducteur et lé vérin électrique fonctionneront donc en 24V.

D’après l’analyse mécanique et électrique, nous devions trouver un vérin électrique avec les caractéristiques suivantes :

  • Course du vérin : 300mm
  • Force : 900N
  • Tension de fonctionnement : 24V

Nous avons donc acheté le vérin électrique MPP-EC 90kg 300mm 900N 24V.

 

Nous avons également acheté un motoréducteur qui fonctionne en 24V capable de faire tourner l’axe du système du tracker solaire.

 

Afin de capter la position du soleil, nous avons nous avons conçu un système composé de 3 photorésistances qui délivrent une tension analogique en fonction de l’intensité lumineuse. Ces trois photos résistances sont séparées chacune par une paroi opaque. Ce capteur est perpendiculaire aux rayons du soleil lorsque les trois photorésistances mesurent la même valeur d’intensité lumineuse.

 

Nous avons réalisé ce capteur et voici à quoi il ressemble :

 

Une fois que nous savons capter la position du soleil, nous avons donc réfléchi à comment piloter le motoréducteur et le vérin électrique pour orienter le panneau perpendiculairement aux rayons du soleil.

Pour se faire, nous avons décidé de travailler avec des modules Arduino. Premièrement, un Arduino UNO est utilisé pour interpréter les mesures des trois photorésistances. En fonction des valeurs lues, l’arduino va estimer s’il est nécessaire de modifier l’angle du panneau en azimut ou en hauteur. Il va envoyer les informations de commande à un Arduino Motoshield qui lui va piloter le motoréducteur et le vérin électrique.

Le MotorShield pilote les actionneurs en PWM. Il utilise en entrée le courant des batteries pour piloter les actionneurs.

Voici le schéma global de notre installation électrique :

 

 

Voici l’algorithme simplifié de l’Arduino qui va permettre d’orienter le panneau dans la bonne direction :

 

 

Nous avons mis en place un coffret électrique qui contient les batteries, le régulateur de charge et les modules Arduino :

 

Réalisation

Afin d’installer toute la structure du tracker et du panneau solaire, nous avons coulé une petite dalle en béton (1.20m * 0.8m) :

 

Conclusion

Nous n’avons pas pu continuer ce projet, malheureusement il nous manquait des pièces mécaniques, ce qui nous a empêché d’installer toute la structure. Nous laissons à disposition du futur groupe d’étudiant un dossier de conception du système de tracker solaire.

Ce projet nous aura permis d’apprendre à travailler en groupe et également a appréhender un projet : les contraintes qui s’y appliquent, la réalisation d’un cahier des charges, le travail de groupe, les dates limites, etc..

Ne pouvant plus nous rendre à l’université, il nous est impossible de joindre les codes arduino utilisés. Afin d’aider les futurs étudiants à la programmation de l’arduino, il va falloir utiliser une librairie arduino motorshield capable de piloter les actionneurs en PWM. Il faut également savoir lire et interpréter les valeurs analogiques fournies par les photorésistances.

Nous remercions l’ensemble des enseignants ainsi que le personnel de l’UHA qui nous auront permis de réaliser et d’avancer au mieux dans notre projet.

Dossier de conception Tracker Solaire


Réflecteur solaire automatisé

Projet réflecteur solaire automatisé

 

LUCAS Miguel                        KIEFFER Maxime                      NESTELHUT Alexandre

 

 

SOMMAIRE

 

     I.Préparation

              Contexte et principe

              Choix des techniques et du matériel

              Montage du réflecteur

              Recherche des coordonnées solaires

 

     II.Création du support

            Pied et rotation

             Cadre et pivotement

             Montage final (à compléter)

 

     III.Programmation

             Branchements et configuration

             Tests des servomoteurs avec des valeurs données

             Amélioration à l’aide de la carte SD

             Modifications complémentaires

 

     IV.Conclusion et remerciements

 

 

 I.Préparation

 

 1.Contexte et principe

Dans le cadre d’étude et réalisation du troisième semestre du DUT GEII (Génie Électrique et Informatique Industrielle), un projet nous a été confié par notre professeur référent, M. OULD ABDESLAM Djafar, consistant à étudier la mise en place d’un réflecteur solaire et ainsi dans un deuxième temps le réaliser dans le but de faire converger les rayons du soleil vers un point donné (par exemple une maison pour pouvoir chauffer celle-ci) d’une manière autonome.Ce type de réflecteur n’étant pas commercialisé en France, la conception et la programmation se créera de toutes pièces par notre groupe, et pourra aboutir à une présentation pour des entreprises intéressées et ainsi effectuer une potentielle mise sur le marché.

 

 

 

 

Ce réflecteur est composé d’une base solide afin de maintenir la structure stable en cas d’intempéries ou de temps indésirable. Sur celui-ci seront situés un servomoteur et un moteur pas à pas contrôlés par une carte Arduino permettant d’effectuer les rotations nécessaires, à savoir une horizontalement et l’autre verticalement pour que le miroir fixé à la structure puisse se mouvoir dans plusieurs positions et angles possible nécessaires à réflexion des rayons du soleil, ceux-ci devant incider sur un point précis, en l’occurrence ici les fenêtres du bâtiment afin de le chauffer ou d’améliorer sa luminosité de manière écologique.

 

 

2.Choix des techniques et du matériel

 

Nous avons utilisé un moteur pas à pas pour sa rotation continue permettant de faire plusieurs tours pour descendre et remonter le panneau, et inversement le servomoteur qui reste bloqué à son dernier angle lorsque l’on coupe l’alimentation pour pouvoir tourner et rester dans l’orientation voulue.

 

Nous avons utilisé une carte Arduino Uno étant donné que cette dernière est pratique dû à sa simplicité de fonctionnement et sa faible consommation. Pour alimenter le servomoteur ainsi que la carte Arduino, nous avons choisis un adaptateur USB 4 ports étant donné que la puissance délivrée par l’Arduino n’est pas suffisante pour le servomoteur. Une alimentation externe plus puissante est prévue pour le moteur pas à pas.

 

 

3.Montage du réflecteur solaire

 

 

Lors du montage, nous avons constaté que la fixation de base du panneau risquait de subir les aléas de la météo et ainsi fragiliser le réflecteur. Pour régler ce souci, nous avons eu l’idée de renforcer la structure avec des plaques reliées aux coins supérieurs et ainsi de remplacer l’ancien support.

 

 

 

4.Recherches pour les coordonnées solaires

 

Afin de réaliser notre projet, nous avons dû faire des recherches concernant les positions et trajectoires du soleil pour calculer les angles de rotation des servomoteurs, un par rapport au Zénith du Soleil et un par rapport à l’Azimut.

 

Azimut et Zénith (ici hauteur) :

 

 

 

Pour cela, nous avons utilisé de nombreux sites afin de nous renseigner au maximum tels que http://www.solartopo.com ou encore www.sunearthtools.com que nous allons utiliser pour récupérer les données.

 

Au préalable, nous avons calculé la hauteur (Zénith) grâce à une formule trouvée sur le site www.buzzcasonits.blogspot.com pour vérifier que les valeurs soient cohérentes.

 

 

Le meilleur moyen d’avoir les données étant de les récupérer directement sur le site web, nous avons téléchargé le fichier csv pour l’année 2019.

 

 

Par la suite nous avons testé nos hypothèses en vrai, grâce à notre réflecteur et à un Fluke Thermal Imager, muni d’un laser.

 

 

II. Création du support

 

1.Pied et rotation

 

Pour créer le support, nous avons récupéré un bon nombre de pièces. Tout d’abord, pour la base nous avons utilisé un tube rectangulaire muni d’un pied. Nous avons alors mesuré les dimensions du servomoteur puis découper le haut du support aux bonnes dimensions. Pour soutenir le servomoteur, la partie découpée a été pliée. Pour finaliser cette partie nous avons limé les bords afin d’éviter les rayures.

 

 

Ensuite nous avons tracé le schéma pour les parties supérieures du support. Nous avons découpé le tout dans du bois (medium). Ce système sera composé de 2 disques en bois, l’un posé sur l’autre grâce à des billes en verre calées dans un rainure afin d’éviter de mettre tout le poids de la partie supérieure sur le servomoteur

 

 

Après avoir tracé le schéma sur papier nous avons fait une modélisation 3D grâce au logiciel de CAO FreeCAD (logiciel libre totalement gratuit) dans le but de les réaliser grâce à la fraiseuse CNC 3 axes à l’IUTlab ; voici les figures représenter en 3D dans le logiciel :

 

 

 

Malheureusement nous n’avons pas pu réaliser les cylindres à la fraiseuse 3 axes ; nous les avons donc faits « à la main » : pour créer le cylindre ainsi que la gouttière nous avons utilisé la fraiseuse manuelle, pour les parties qui durent être creusée nous avons dégrossi le travail grâce à la perceuse à colonne puis affiné aux ciseaux à bois. Voici le résultat :

 

 

 

 

Pour pouvoir fixer le tout nous avons vissé (temporairement pour avoir un pied stable) une plaque bien plus grande en bois (medium de 5 cm d’épaisseur). Le tout monté donne ce résultat :

 

 

2.Cadre et pivotement

 

Une fois les deux cylindres fixés sur le pied nous sommes passés au second axe qui lui est en deux parties : le support du miroir et l’entraînement du servomoteur :

 

– le support en miroir est entouré d’un cadre en aluminium qui fait le pourtour du miroir, lui étant coincé entre une barre en bois et le cadre justement pour éviter de devoir le percer

 

 

 

-l’entrainement est fait par le servomoteur qui agit sur deux barres reliées entre elles et au miroir, mais le servomoteur manquant de puissance pour soulever le miroir nous allons devoir améliorer ce mécanisme.

 

 

3.Montage final

 

Après de multiples tests, nous avons constaté que le moteur n’était pas assez puissant pour pouvoir faire remonter le panneau. C’est pourquoi nous avons changé notre deuxième axe en utilisant une tige filetée avec un moteur pas à pas.

Contrairement au servomoteur, le moteur pas à pas va fonctionner en nombre de tours et va faire tourner la tige filetée ce qui va provoquer l’inclinaison du miroir.

 

 

Après avoir modifié cet axe, nous avons assemblé les deux parties entre elles grâce à trois vis et deux tiges filetés avec écrous.

 

 

 

III.Programmation

 

1.Branchements du système

 

A savoir : l’Arduino est alimentée grâce au port Vin connecté à l’un des servomoteurs directement branché sur le secteur

 

Configuration carte Arduino Uno

2.Test des servomoteurs avec des valeurs données

 

3.Amélioration à l’aide de la carte SD

 

Une fois que les moteurs tournent nous devons cette fois-ci obtenir les valeurs à leur envoyer à partir d’un fichier texte. Pour ce faire nous avons choisi l’option d’utiliser une carte SD car l’accès à celle-ci est plus simple que si nous devions accéder à la mémoire de l’Arduino. Nous avons donc commandé une extension SD pour notre carte Arduino UNO et branché soigneusement sur celle-ci.

4.Modifications complémentaires

 

 

Suite à l’avancement du projet, nous avons remarqués que notre programme initial ne convenait plus à nos besoins. Nous avons fait des modifications : une par rapport à la récupération de données et l’autre par rapport à une modification faite dans le montage.

 

– Modification pour la récupération de données sur un an : Dans ce cas , nous avons remplacé le fichier sur la carte SD par un fichier ayant les valeurs pour toute l’année, puis nous avons modifié le programme car la lecture sur un an n’est pas pareil que celle sur un jour.

 

 

-Modification pour le fonctionnement du moteur pas à pas

 

Dans ce cas, nous avons remplacé notre servomoteur par un moteur pas à pas donc nous avons changé la formule pour ce dernier. Pour cela nous calculons le nombre de pas de que le moteur doit faire pour obtenir le nombre de tours, ce qui diminuera ou augmentera la distance entre le moteur et le bout de la tige filetée et donc incliner le panneau d’un certain angle

 

 

 

IV.Conclusion et remerciements

 

Nous voulons tout d’abord remercier Mr OULD ABDESLAM Djafar de nous avoir guidé et aidé tout au long du projet. Nous voulons aussi remercier Mr DE SABBATA pour nous avoir donné de nombreux conseils et aussi pour nous avoir autorisé à utiliser l’IUT Lab pour nos besoins. Nous aimerions également remercier Mr WIRA pour son aide concernant la gestion de la carte SD et la lecture du fichier.

Pour conclure, ce projet a été pour nous une expérience importante pour notre cursus car nous avons pu travailler en groupe tout au long de l’année. Nous avons appris à nous partager les tâches, à faire des compromis entre nous pour pouvoir satisfaire au mieux les besoins du projet. De plus cette expérience fut d’autant plus enrichissante car nous avions un projet concret avec une réalisation à la clé qui s’est concrétisée.

Nous pouvons également ajouter à ce projet divers points d’amélioration, que ce soit remplacer les pièces en bois par de l’aluminium pour augmenter sa robustesse, un anémomètre permettant de coucher le panneau en cas de vent fort détecté, une cale pour éviter le redressement quelque peu brusque du retour en position initiale du panneau. Un capteur serait également à prévoir sous le miroir pour l’éviter de descendre trop loin et causer des dégâts.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Mallette qualité de l’énergie

Quentin JACQUEY

Anas BOUHSSINE

Emre TEKIN

Mise en œuvre d’un module WAGO

Rapport de Projet

Introduction

 

Dans le cadre de notre DUT GEII, il nous fallait réaliser un projet pendant notre troisième semestre. Ce projet reposait sur un automate programmable WAGO, celui-ci nous permettrait de réaliser des mesures et une récupération des données de consommations électriques d’une installation.

Nous avons alors dû programmer une interface graphique pour faciliter la prise en main de l’utilisateur.

Finalement, la récupération et affichage des données de l’automate se feront au travers d’un Janitza, un appareil de mesure couplé au WAGO.

 

Afin de mener à bien ce projet, nous avions à notre disposition une mallette, composée de l’automate auquel nous avons ajouté un appareil, tenant le rôle de transformateur 230/24 V afin d’alimenter l’automate. Nous avons également utilisé un Janitza, dont le rôle sera détaillé plus loin.

Sommaire

A. Objectifs

B. Ressources

  1. Avancement

  2. Installation

  3. Mesures

  4. Banque de données

  5. Reprise de toutes les étapes

C. Reprise de la banque de données

D. Difficultés rencontrées

E. Conclusion

F. Annexes

 

A. Objectif

Notre projet WAGO permet de mesurer et analyser une ou plusieurs installations électriques, ce qui permet à l’utilisateur de contrôler ou optimiser sa consommation électrique.

Nous avons comme projet également de transférer les données vers l’automate depuis un Janitza, afin de créer une banque de données qui va permettre de récupérer et stocker les données instantanées dans l’automate venant du Janitza.

B. Ressources

 

Pour notre projet, nous avions à disposition :

  • Automate WAGO (Référence 6028-2186)(Centrale Fastlogger 3G)

  • Module 750-494 Module de mesure

  • Module 750-495 Module de mesure

  • Module 750-600 Module d’extrémité

  • 3 sondes de courants 60V/1A
  • 4 boucles de Rogowski

 

 

 

Nous avons intégré un transformateur 230/24V qui est utilisé comme alimentation.

Nous utilisons comme câbles un câble d’ordinateur recyclé et dénudé. Nous branchons ce câble à la prise de la mallette.

Nous avons également utilisé plusieurs logiciels :

 

  • WAGO Ethernet settings

  • WAGO-IO Check

 

  • Fastlogger

Nous avions envisagé d’utiliser le logiciel Codesys et éventuellement un Raspberry PI afin de créer une base de données où stocker les données.

Nous avons finalement opté pour la solution du Janitza.

Le Janitza est un appareil de mesure  que nous avons utilisé afin de projeter les données récoltées par le Janitza vers notre automate.  Son installation et branchement sont détaillés ci-dessous.

 

C. Avancement

Le schéma ci-dessous démontre le but de notre projet et les différentes étapes de notre projet.

 

Notre projet ce sépare en plusieurs étapes :

  1. L’installation
  2. Les mesures
  3. Programmation envoi des données
  4. Reprise des étapes

Le contenu de chacune de ces étapes ainsi que l’avancement actuel sont développées ci-dessous.

 

1.L’installation

Nous avons dû, en premier lieu, nous approprier le matériel à disposition, et comprendre le fonctionnement de celui-ci en lisant les documentations techniques.

Les branchements de l’automate ont été préalablement effectués, il nous fallait cependant connecter l’automate à une alimentation. Là où les étudiants de l’année précédente avaient utilisé un transformateur externe, nous avons opté pour un transformateur interne à la mallette.  Pour cela, nous avons utilisé un transformateur 230/24V fourni par le professeur. Il nous fallait donc intégrer le transformateur dans la mallette qui nous était fourni. Pour cela, nous avons utilisé un câble d’ordinateur que nous avons dénudé afin de servir de câble d’alimentation reliant la prise de la mallette au transformateur.

Après avoir testé le bon fonctionnement du transformateur et de l’automate, il nous fallait maintenant s’occuper de l’adresse IP de l’automate.

Une adresse nous avait été fournie : 10.95.11.33, préalablement configuré grâce à WAGO Ethernet Settings cette adresse correspond à l’adresse de l’automate dans le réseau UHA.  Pour tester la concordance de l’adresse, nous avons configuré un ordinateur portable sur le même sous-réseau que l’automate à l’adresse : 10.95.11.32.

Après vérification, l’automate a la bonne adresse.

Nous avons également installé FASTLOGGER dans l’automate grâce aux étapes décrites en Annexe 1.

 

2.Mesures

Une fois l’automate correctement configuré, nous avons effectué des mesures grâces à des lampes halogènes.

Nous avons utilisé IO-CHECK pour voir les mesures.

Pour mesurer, nous avons utilisé les sondes de courants sur une seule phase.

Voici les mesures obtenues :

D’abord, avec les lampes à mi-puissance :

Puis avec les lampes à leur puissance maximale:

Grâce à ces mesures, nous nous sommes assurés du bon fonctionnement et du logiciel, et de l’automate.

En effet, nous constatons qu’à leur puissance maximale, les lampes produisent des harmoniques plus importantes et plus nombreuses, ce qui démontre le bon fonctionnement des mesures de notre automate.

 

 

3.Banque de Donnée

 

Pour créer une banque de données, nous envisagions d’utiliser CODESYS ainsi qu’un Raspberry PI. Cependant, nous avons  eu des problèmes vis-à-vis des logiciels. Nous possédions CODESYS 2.3, mais les automates WAGO ne sont pas reconnus comme des cibles du logiciel. Pour résoudre ce problème, nous avons communiqué avec Mr. MARTIN, qui travaille chez WAGO. Mr. MARTIN a répondu à notre demande et nous a donné accès au logiciel avec la référence de notre automate.

Nous avons trouvé la référence correspondante du logiciel qui allait avec notre automate. Nous pouvions désormais nous consacrer à la programmation de la banque de données. Quant au Raspberry PI, nous avions décidé d’abandonner l’idée de l’utiliser. En effet, le logiciel qui nous permettrait d’utiliser le Raspberry PI était payant.  De plus, CODESYS remplissait déjà toutes les fonctions nécessaires à notre projet.

Nous avions besoin d’accéder à la fonction ‘‘root’’ du logiciel Putty afin de pouvoir modifier, supprimer ou ajouter des fonctions dans l’automate. Pour y accéder, il nous fallait un identifiant et un mot de passe, malheureusement aucun des deux ne nous a été donné par les anciens étudiants en charge de ce projet. Nous étions donc obligés de reboot l’automate et refaire alors toutes les étapes décrites précédemment.

 

4.Reprise de étapes

 

Après avoir fait un « reset » de l’automate grâce à ces  étapes (Annexe 2), nous avons perdu toutes les données que contenait l’automate. Nous voulions donc reprendre toutes les étapes. Malheureusement l’adresse IP initiale qui nous a été donnée est fausse. Nous avions donc activement recherché l’adresse IP actuelle de l’automate. Nous avons trouvé comment faire (Annexe 2). L’adresse IP de l’automate est donc désormais 192.168.1.17.

Nous avons également reset les identifiants et mot de passe pour le site Web-Base Management, ce que l’on recherchait. Nous avons défini les mots de passe tel quels:

Identifiant :                  1.user                           2.admin

Mot de passe :            1.wago                         2.user

Nous avions donc dû refaire toutes les étapes précédentes, une fois l’adresse IP de l’automate reconfiguré sur 10.95.11.33.

 

Après que notre automate ait été reconfiguré correctement, nous pouvions reprendre la programmation de la banque de données grâce à Codesys.

Nous avions pour cela configuré le logiciel pour qu’il reconnaisse l’adresse de l’automate.

 

Afin de compiler et charger le programme dans l’automate, nous avions besoin d’un mot de passe qui était :

Mot de passe : user

Ainsi, nous avons réussi à transférer le programme dans l’automate, nous pouvions alors récupérer les données de la consommation électrique des installations.

Le résultat est montré ci-dessous.

Après de nombreux tests, nous avions compris qu’il nous fallait utiliser Fastlogger après avoir discuté au téléphone avec notre contact WAGO.

 

Après avoir eu accès aux pleins pouvoirs sur l’automate grâce à Putty (Annexe 3), nous avons pu accéder à Fastlogger, que nous avions installé précédemment. Ce logiciel nous permet d’accéder directement aux données récoltées dans l’automate.

 

Le logiciel Fastlogger se présente sous cette forme :

 

Après avoir vu un aperçu de ce que donnait la récolte des données.

Fastlogger va nous permettre d’archiver ces données sur un fichier .csv contenu dans la carte mémoire.

Nous allons alors transférer ces données archivées et récoltées sur un serveur FTP donné par l’IUT.

Malheureusement, le serveur FTP était inutilisable, en effet,  la complexité du réseau empêchait d’établir une liaison avec notre automate. Nous avons donc dû abandonner l’idée du serveur.

Nous devions également nous servir d’un module de mesure, le Janitza 96 RM-E. Il s’agit d’un équivalent du Wago que nous utilisons comme centre de mesure. Pour cela, nous avons connecté le Janitza avec l’automate en Modbus TCP/IP afin de récupérer les valeurs mesurées par le Janitza. Le Wago sert alors de centre de collecte des données du Janitza que l’on enregistre sous CSV grâce à un adressage spécifique.  (ANNEXE 4)

 

D. Difficulté rencontré

 

Lors de notre projet, nous avons rencontré certaines difficultés. En effet, la première difficulté fut de trouver le logiciel adapté pour nous permettre de coder notre banque de données. Après avoir trouvé Codesys, la difficulté a été de nous le procurer. La version WAGO n’étant pas disponible sur leur site, nous avons envoyé des mails à notre contact MR. Martin, il nous a envoyé un lien pour le télécharger mais qui ne contenait pas la référence de notre automate. Il nous a alors fallu attendre qu’il nous renvoie le lien contenant le logiciel avec notre référence.

  • Nous avons rencontré des difficultés afin de transférer le programme depuis le logiciel vers l’automate. Nous avons donc essayé plusieurs méthodes. D’abord avec un câble ETHERNET, cela ne marchait pas. Nous avons alors essayé avec un câble RS232, cela ne marchait pas non plus. Enfin nous avons branché l’automate sur le réseau, et nous avons pu nous connecter à lui depuis le logiciel grâce à son adresse IP.
  • Le problème majeur que nous avons rencontré a été l’accès au noyau de l’automate Wago. En effet l’installation du fastlogger doit se faire dans le noyau par le logiciel « Putty ». Ce logiciel comporte 3 utilisateurs. Le premier ne servant à rien est « User » utiliser pour voir les fichiers installé dans le noyau. Le second est « admin » qui peut être utilisé pour accéder au noyau et y transférer certains fichiers. Enfin il y a le super admin « root » qui donne libre accès à toute manipulation du noyau. C’est celui-ci qui était la cause du problème car le mot de passe défaut a été modifier.

La solution est donc de réinstaller le firmware du wago (Annexe 5…) et d’utiliser le mot de passe par défaut.

  • Nous avons eu également l’idée d’utiliser un serveur FTP afin d’y stocker les données. Malheureusement, la connexion de l’automate avec le serveur était impossible, dû à la complexité du réseau UHA (sécurité).
  • Nous avons donc dû utiliser un Janitza 96 Rm-E. La complexité de son utilisation ainsi que celle de la connexion avec notre automate nous a apporté des difficultés sur la compréhension de ceux-ci. Grâce à des recherches fructueuses, nous avons compris son utilisation et nous avons donc pu utiliser le Janitza tel que nous en avions besoin.

 

E. Conclusion

 

Si on devait résumer notre projet, nous pourrions dire que nous avons apporté :

  • Un transformateur interne, afin d’alimenter de manière autonome l’automate
  • Modification des mots de passe des différents logiciels que nous avons dû réinitialiser
  • Installation du Fastlogger dans l’automate, ainsi que son codage et son utilisation
  • Après de nombreux problèmes, l’utilisation du Janitza comme module de mesure et utilisation de notre Wago comme centre de collecte de ces données

Cependant, nous sommes conscients que notre projet aurait pu être amélioré :

En effet, si l’utilisation du serveur FTP, la récolte des données aurait pu être plus ludique et attractive.

Nous aurions pu également créer une interface graphique pour mieux représenter les données récoltées à partir du Janitza.

 

F. Annexes

 

Annexe 1 : Installer FASTLOGGER

  • Copier-coller le fichier .ipk dans le dossier tmp du FTP du contrôleur
  • Ouvrir une connexion SSH sur le contrôleur grâce à Putty [se connecter avec les identifiants suivant : root (utilisateur) et wago (mot de passe)]
  • Sous Putty, ouvrir le dossier tmp (grâce à la commande « cd /tmp »).
    Il faut respecter l’espace entre le ‘d’ et le ‘/’
  • Lancer la commande d’installation :« ipkg install install-fastlogger_1.2.10_arm.ipk ».

Il faut respecter tous les espaces et bien renseigner le nom du fichier y compris l’extension. FASTLOGGER se lance donc.

Annexe 2 : Reset et trouver l’adresse IP

Reset :

  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange.
  • Mettre le Switch en mode « Reset ».
  • Attendre 3 secondes le temps que la Led « Sys » soit rouge.

Trouver adresse IP :

  • Mettre le Switch en mode « STOP »
  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange
  • L’adresse IP de l’automate est alors : 192.168.1.17

Source : Data sheet 750-8207

 

Annexe 3 : Avoir les pleins droits sur l’automate

 

Sur Putty, rentrer les informations telles quelle :

Un message d’information va s’afficher, cliquer sur « Oui ».

Une boite de dialogue va alors s’afficher :

S’identifier en tant que « root », le mot de passe correspondant est : « user ».

Vous aurez dès lors un accès total sur l’automate, c’est-à-dire que vous pourrez avoir accès aux programmes installés sur l’automate, les modifier, en supprimer, ou en créer.

 

Annexe 4 : Configuration Janitza

 

Configuration de l’adresse IP du Janitza :

Appuyer pendant 5 secondes sur la touche 1 et 2 du janitza pour entrer dans le mode de paramétrage du janitza.

La navigation dans le menu est possible grâce à la touche sur laquelle se trouve une flèche vers la droite et la validation la touche vers le haut.

En navigant dans ce menu, on peut changer l’adresse IP du Janitza dans la sous-section addr où l’adressage ce fait en 4 étapes.

Suite à cela on rentre cette adresse dans la case dédié dans le fastlogger dans l’onglet configuration modbus TCP/IP

Dans l’onglet requête, on ajoute l’adressage spécifique à la valeur que l’on veut.

Dans l’onglet donné on peut visualiser les données et aussi archiver les valeurs que l’on souhaite.

Attention à l’ état !!

Etat 150: Sans réponse

Etat 129: Problème Communication

Etat 0: En fonctionnement

Visualisation des données avec possibilité d’archivage.

 

Attention à l’adressage ! L’adressage fournit dans le noyau du wago est incorrecte et il faut ajouter un par un les adressages de registre que l’on souhaite récupérer retrouvable dans la datasheets du Janitza.

Annexe 5 : Réinstallation Firmware

1.Télécharger ce fichier

http://www.wago.com/public-download/Support/FW/0750-8xxx/WAGO_FW_0750-8xxx_I.ZIP

2.3.4.

5. Insérer la carte SD dans le PFC200 ou la microSD dans le PFC100, puis le redémarrer électriquement. Le lecteur de cartes SD ou microSD clignote orange pendant plusieurs secondes. L’image du noyau est automatiquement chargée dans la mémoire RAM.

Après la séquence d’initialisation, les LEDS SYS et I/O sont vertes fixes. La LED RUN est rouge fixe, le lecteur de cartes SD ne clignote plus.

A ce stade, l’image du noyau est simplement présente en mémoire RAM, il est nécessaire de la copier sur la mémoire Flash interne.

6. Une fois tous cela fait connecter vous à Web-Based Management.

7. Retirer la carte SD ou microSD, puis redémarrer le PFC. Le PFC a été mis à jour. Retourner sur le Web-Based Management afin de vérifier la version du firmware.

8.La carte SD n’est pas utilisable en stockage. Il faut donc la formater.

 

 


Supervision Efficacité Energétique

HEGE Simon

MINERY Loïc

Rapport Efficace Energie

Projet 2018/2019

 

 

 


Sommaire

  1. Remerciements

  2. Introduction

  3. Cahier des Charges

    1. Bêtes à corne
    2. Diagramme pieuvre
    3. Partage des tâches
    4. Schéma de fonctionnement
    5. Environnement logiciel
    6. Environnement matériel
    7. Capteurs utilisés
    8. Comparaison capteurs
      1. Première partie
      2. Deuxième partie
  4. Recensement capteurs

    1. Création d’une interface VBA sur Excel
  5. Logiciel EfficaceEnergie

    1. Prise en main
    2. Création plan IUT
    3. Enregistrement nouveaux capteurs
    4. Compte admin et utilisateur
    5. Analyse de résultats
  6. Conclusion

  7. Annexes

    1. Captures d’écrans Comparaison
    2. Novembre
    3. Septembre
    4. Octobre

Remerciements

Nous tenons à remercier notre professeur référent, M. Ould qui nous a proposé ce projet et nous a guidé tout au long de ses semaines de recherches et de supervision. Nous souhaitons également remercier M.Marco SANGWA qui nous a permis d’utiliser son rapport de stage.

Introduction

Le but principal de ce projet était d’analyser les données de capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. Notre projet Efficacenergie a donc consister en l’installation de capteurs dans l’établissement, puis en leur enregistrement dans le logiciel Efficacenergie afin de relever leurs courbes de consommation ou leurs courbes de température. Nous avons recenser les capteurs existants et nous avons analyser les données des capteurs déjà installés. Nous avons également utilisé le rapport de stage de M. Marco SANGWA, étudiant de l’année passée, qui nous as permis de comprendre le fonctionnement des différents logiciels afin d’installer les capteurs plus facilement et plus rapidement.


Cahier des Charges

Bêtes à corne

 

Diagramme pieuvre

Contraintes majeurs

  • Plan interactif : Le plan devait être clair et intuitif afin de pouvoir effectuer le suivi de la consommation pour chaque capteur.
  • Déclaration des capteurs : Chaque capteur devait être déclaré sur le logiciel wavenet, on lui a attribué ensuite un répéteur si cela était nécessaire.
  • Cohérence des valeurs : Trouver l’origine d’un décalage de ± 9 % entre les relevés des capteurs Distrame et UHA.

Contraintes mineurs

  • Esthétique : L’interface doit être esthétique dans la mesure du possible.
  • Fiabilité : L’interface doit fonctionner correctement ainsi que la déclaration des capteurs dans l’architecture.
  • Simplicité : Elle doit être simple d’utilisation.
  • Sécurité : Mise en place de comptes utilisateur et administrateur.

Partage des tâches

MINERY Loïc :

  • Création plan IUT interactif avec courbes et mesures pour chaque capteur de chaque bâtiment.
  • Comparaison capteurs UHA et Distrame
  • Recensement des capteurs
  • Installation des nouveaux capteurs
  • Powerpoint

HEGE Simon :

  • Création de l’interface pour le recensement des capteurs
  • Recensement des capteurs
  • Comparaison capteurs UHA et Distrame
  • Installation des nouveaux capteurs
  • Rapport

Schéma de fonctionnement

Environnement logiciel

  • Interface Distrame Efficacenergie
  • Logiciel Wavenet monitor
  • Logiciel Diris Digiware

Environnement matériel

  • Capteurs
  • Ordinateurs

Capteurs utilisés

Comparaison capteurs

Première partie

Notre enseignant référent, M. OULD nous a demandé de comparer sur plusieurs mois les valeurs de consommation électriques mesurées par les capteurs de la société DISTRAME et ceux de l’UHA. Nous avons utilisé le logiciel EfficaceEnergie ainsi que le logiciel Diris Digiware de l’UHA, auquel nous avons eu accès grâce au compte utilisateur de M. OULD. Nous avons ainsi comparé les données des capteurs installés dans différents bâtiments.

 

Tableau de la consommation des bâtiments selon le mois

Tableau de la consommation des bâtiments par semaines

 

Nous avons alors remarqué que les capteurs UHA ont toujours des valeurs plus élevées que ceux de DISTRAME sauf au mois de Juillet (valeurs en rouges) où nous constatons que les capteurs UHA du bâtiment A et Générale sont plus élevées que ceux de Distrame.

Nous avons calculé les pourcentages de différences entre les capteurs et il semble qu’en générale, sur trois mois, la différence soit d’environ 9 %.

Conclusion première partie

Nous avons remarqué une différence d’environ 9 % entre les capteurs des deux sociétés. Nous avons alors contacté, par mail et téléphone, M. LALLEMANT, un agent de DISTRAME, pour lui demander s’il avait une explication à cette différence entre les capteurs. Il ne pouvait malheureusement pas nous répondre. Nous avons ensuite contacté par téléphone M. SCHMIDT qui nous a redirigé vers le support de Distrame. Un agent nous a demandé les références de nos capteurs ainsi que celles des compteurs. Il souhaitait aussi connaitre les valeurs de nos boucles de courants, mais nous n’y avons pas accès seul.  Nous lui avons envoyé toutes les informations par mail par deux fois, sans réponse de sa part.


Deuxième partie

Notre enseignant référent nous a demandé, dans un second temps, de comparer les valeurs de consommation électriques des capteurs DISTRAME et UHA mais cette fois sur une période de 6 mois. Ainsi , nous avons comparé les données du mois de juillet 2018 au mois de décembre de la même année afin de vérifier si la différence de 9 % persistait sur une longue période.

Rapport de consommation sur la période juillet-décembre 2018

Consommation bâtiment A

 

La valeur du capteur Distrame de consommation du bâtiment A est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.94%.

Nous observons un pic de consommation à environ 200 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment B

 

La valeur du capteur Distrame de consommation du bâtiment B est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.59%, ce qui est assez proche de la valeur obtenue pour le bâtiment A.

A la date du 10 décembre 2018, nous observons à nouveau un pic de consommation à environ 440 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment C

 

La valeur du capteur Distrame de consommation du bâtiment C est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 2.52%.

 

Nous observons encore un pic de consommation à environ 700 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiment E

 

La valeur du capteur Distrame de consommation du bâtiment E est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.99%, ce qui est beaucoup moins élevé que les valeurs obtenues pour les bâtiments A et B.

 

A la date du 10 décembre 2018, nous observons de nouveau un pic de consommation à environ 760 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiments DFGH

 

La valeur du capteur Distrame de consommation des bâtiments D, F, G et H est cette fois-ci moins élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons donc un point de pourcentage négatif de -2.04%.

A la date du 10 décembre 2018, nous observons un pic de consommation à environ 1300 kWh pour le capteur UHA qui n’est pas présent sur le relevé du capteur Distrame.

Consommation logements de fonctions

 

La valeur du capteur Distrame de consommation des logements de fonctions est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.14%, ce qui qui représente l’écart le plus faible entre les capteurs de l’UHA et ceux de Distrame.

On n’observe pas de pic de consommation au 10 décembre, les deux graphiques semblent équivalents.

Consommation générale de l’IUT

 

La valeur du capteur Distrame de consommation générale est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous observons un plus grand écart avec un point de pourcentage de 4.74%.

On observe un pic de consommation le 10 décembre 2018 pour environ 3500 kWh.

 

Nous avons remarqué une différence entre les valeurs générales mesurées par les capteurs et celles obtenues en additionnant les valeurs obtenues précédemment. Ainsi, la valeur mesurée par le capteur UHA est plus petite que celle obtenue par la somme alors que la valeur mesurée par le capteur Distrame est plus élevé. Les valeurs obtenues par la somme sont plus cohérentes car plus rapprochées l’une de l’autre.

Conclusion deuxième partie

Nous avons remarqué que les relevés des capteurs UHA et Distrame sont cohérents entre eux. Les valeurs des capteurs Distrame sont généralement plus élevées que celles des capteurs UHA sauf pour les bâtiments D-F-G-H.

Nous avons également remarqué un pic de consommation au 10 décembre 2018, uniquement présent sur les relevés des capteurs UHA. Ce pic n’est pas présent sur le relevé de la consommation des logements de fonctions ni sur les relevés des capteurs Distrame. Il s’est donc produit quelque chose au niveau des capteurs UHA ce jour-là.

Enfin, la moyenne de la différence des pourcentages entre les valeurs obtenues sur 6 mois par les capteurs UHA et Distrame est de 1.99%, en comptant le pourcentage négatif des bâtiments D-F-G-H. On remarque donc que la différence de 9% sur une semaine diminue à 2 % sur 6 mois ce qui est une très bonne chose. Les différents capteurs ne donnent donc pas des valeurs trop différentes.


Recensement capteurs

Tout d’abord, nous avons recensé tous les capteurs non-installés physiquement, car il y en avait des nouveaux et des anciens, puis nous avons vérifiés lesquels étaient déjà enregistrés dans EfficacEnergie. Nous en avons également profité pour vérifier les noms de tous les capteurs sur le logiciel et repérer les doublons, les capteurs obsolètes ou bien tout simplement les capteurs mal déclarés.

Ainsi, nous avons comptés 14 capteurs-émetteurs et 5 répéteurs non-installés physiquement. Sur ces 14 capteurs, 10 sont des capteurs waveflows, 3 sont des nouveaux capteurs et 1 seul est un capteur wavesense. Sur les 3 nouveaux capteurs, nous avons 2 capteurs wavetherms et 1 capteur LEM.

Nous avons également recensé 5 répéteurs dont 2 sont des wavetalks.

Certains capteurs non-installés physiquement étaient déjà enregistrés sur le logiciel EfficacEnergie, nous n’aurons donc pas besoin de les enregistrer mais juste les installer sur un compteur. Ils étaient enregistrés sous le collecteur Ethernet qu’il faudra changer pour le collecteur Webdyn. C’était le cas des WFL3 à 9.

Ensuite, nous avons recensés les capteurs physiquement installés dans l’enceinte de l’IUT. Certains capteurs étaient enregistrés sous le collecteur Ethernet dans le logiciel EfficacEnergie, ils ne donnaient donc aucun relevé sur le logiciel. Ainsi le capteur WFL de la salle B010 n’envoyait aucun résultat depuis avril, date à laquelle il a été mis sur le mauvais collecteur. Afin de les faire fonctionner, nous les avons enregistrés sous le collecteur Webdyn qui reçoit toutes les données et les envois au serveur.

Mise en place du capteur sur le collecteur webdyn

Nous avons aussi remarqué que certain capteur enregistré ne correspondait en réalité à aucun capteur réel, il faudra donc les supprimer.

Capteurs ne relevant aucunes données car n’existant pas physiquement

D’autres capteurs étaient utilisés en double sous deux noms différents, nous allons donc en supprimer un des deux.

Capteurs existants en double


Création d’une interface VBA sur Excel

Cette interface permet de rechercher rapidement l’adresse radio, la localisation ainsi que le type de capteur associés au nom d’un capteur ou répéteur. Elle permet également d’ajouter à tout moment un capteur ou un répéteur en plus.

Tableau Excel recensant les capteurs + Interface

Logiciel EfficaceEnergie

Prise en main

Pour débuter, nous avons créé un fichier à notre nom, dans lequel nous avons créé tous les graphiques et tableau. Afin d’obtenir ces fameux graphiques, nous nous sommes aidés du rapport de projet de l’année dernière ainsi que de l’aide présente sur le logiciel.  Nous avons ainsi créé notre premier graphique.

 

Paramétrages permettant la création d’un graphique

Comparaison de la consommation entre les bâtiments de l’IUT (RGB) et la courbe de consommation générale (Noir)

 

Nous remarquons sur ce graphique que la consommation générale n’est pas l’addition de toutes les consommations mais plutôt leur moyenne.

Après la création d’un graphique nous avons voulu créer un tableau.

Graphique et tableau montrant la consommation du bâtiment B sur une journée (Les graphiques barres ont été remplacés par des graphiques linéaires depuis)


Création plan IUT

Après avoir pris en main le site EfficacEnergie, nous avons été capable de créer une carte de l’IUT avec la position des capteurs et ce qu’ils mesurent. Pour cela, nous nous sommes aidés  du rapport de projet de l’année dernière dans lequel toutes les positions des capteurs étaient précisées. Après vérification, certains capteurs avaient malheureusement été changés de place comme le capteur de température WTH salle B016 qui à été déplacé dans l’amphithéâtre nord et que nous avons donc renommé. Nous avons également nous-mêmes rajouté certains capteurs, comme le capteur de température de la cave A ou bien encore celui du bureau de M.Ould.

Plan interactif de l’IUT

Chaque capteur est ainsi représenté par un point avec son nom sur lequel on peut cliquer afin d’avoir le détail de ses mesures. S’il s’agit d’un capteur de température, il est représenté par un point rouge tandis qu’un capteur de consommation est lui représenté par un point vert. Lorsqu’il s’agit de la consommation de plusieurs bâtiments, le capteur est représenté par une maison.

Détail des mesures du capteur de température du bâtiment A

Enregistrement nouveaux capteurs

Le cahier des charges du projet impliquait d’installer de nouveaux capteurs aussi bien physiquement que sur le logiciel. Ainsi, nous avons installé deux capteurs de température Wavethermes que nous avons appelés respectivement WTH15 et WTH16. Le capteur-transmetteur WTH15 a été installé dans le bureau de M. Ould tandis que le WTH16 à lui été installé dans la cave du bâtiment A par un technicien de l’IUT. Avant de les installer physiquement, nous les avons d’abord configurés dans le logiciel wavenet monitor, permettant de vérifier qu’ils fonctionnent correctement et de créer l’architecture réseau.

Ajout d’un capteur à l’aide de son adresse radio

Capteur assigné par défaut. Mauvaise architecture.

Capteur assigné au waveport. Bonne architecture.

Test du signal du capteur concluant

Puis nous avons rentrés les capteurs dans le logiciel Efficaceenergie grâce à leurs codes. Nous avons ensuite pu effectuer toute sortes de tests comme le test RSSI, qui permet de vérifier le pourcentage de signal qui arrive au collecteur, le test de batteries, qui permet de voir le pourcentage de batteries restantes dans chaque capteurs et transmetteurs, ainsi qu’un test de rapatriement, qui permet d’enregistrer la valeur que le capteur lit à l’instant présent.

Activation du collecteur WebdynRF obligatoire pour ajouter des capteurs

 

Ajout du capteur avec sa période d’échantillonnage

 

Test signal du capteur

 

Test du niveau de batterie

 

Test des valeurs rapatriées depuis le capteur


Compte admin et utilisateur

Nous avons créé un compte admin dans lequel nous pouvons ajouter des capteurs et créer des tableaux et courbes. Le compte utilisateur ne permet pas de créer de courbes mais uniquement de visualiser les relevés dont l’admin a donné les droits de visualisation. Nous ne pouvons malheureusement pas créer de compte où l’on pourrait créer des graphiques mais ne pas avoir accès aux configurations.

Fichiers et paramètres auxquels l’admin à accès

Seul le fichier avec le plan et le paramètre de déconnexion sont accessibles au compte utilisateur

Analyse de résultats

Le capteur WFL salle B010 donnait des courbes inadéquates. En effet, les courbes étaient sous formes de pulsions complètement irréalistes pour une valeur de consommation. Nous avons vérifier son branchement au compteur et cela ne changeant rien, nous avons décidé de l’enlever car il ne servait à rien.

Consommation en janvier 2019

Consommation en avril 2018

Le capteur de température de la cave A marche correctement et on remarque que la température reste bien constante à 16 degrés Celsius.

Température de la cave par jour durant une semaine

Le capteur de température du bureau de M. Ould marche lui aussi correctement et on remarque que la température baisse jusqu’à 18 degrés Celsius le week-end, notamment le dimanche. En effet, l’IUT pour baisser sa consommation ne chauffe pas les salles le week-end. Le dimanche 3 mars, la température dans le bureau reste à 20 degrés Celsius car il y avait les portes ouvertes ce week-end là.

Température du bureau de M.Ould tous les jours sur un mois

Conclusion

Notre projet abouti permet la visualisation et l’analyse des données des capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. La surveillance de la consommation par les intervenants de l’IUT sera aussi plus efficace et rapide grâce à la carte interactive. Cette carte devrait être mise sur grand écran au sein même de l’IUT afin que le public puisse y accéder à tous moment grâce au compte utilisateur. La justesse des données pourrait être améliorée si l’on découvre d’où vient la légère différence entre les capteurs UHA et Distrame. Notre projet a également permis la surveillance de la température de la cave A afin que la bière du projet micro-brasserie automatisée soit toujours à bonne température. Il permettrait également la surveillance de la production énergétique du projet Centrale d’autoconsommation solaire.


Annexes

Septembre

Relevé du capteur de consommation Distrame du bâtiment A

Relevé du capteur de consommation UHA du bâtiment A

Octobre

 

Novembre

 

 

 


Micro-Brasserie solaire automatisée

Sommaire:

Remerciement

Introduction

  1. La passionnante histoire de la bière
    1. Chronologie de la bière
    2. Fabrication
  2. Réalisation des bières de GEII
    1. Première bière: apprentissage de brassage
    2. Deuxième Bière: consommation d’énergie
  3. Automatisation
    1. liste du matériel nécessaire
    2. Motorisation du moulin
    3. motorisation du malaxeur
    4. Asservissement de température
  4. Amélioration possible
  5. Conclusion

Remerciements:

Ce projet n’aurait pu être réalisé sans l’aide d’une multitude de personnes que nous tenons à remercier ici. Parmi elles :

– M. Ould-Abdeslam pour la proposition et le suivi complet de ce projet ainsi que pour les commandes de matériel,

– les techniciens de l’IUT qui nous ont permis d’automatiser le moulin à l’aide d’une simple pièce qui nous manquait,

– M. De Sabatta pour sa patience et ses nombreux conseils,

– M. Hiebel, du lycée Charles de Gaulle à PULVERSHEIM, section “chaudronnerie”, pour la tôle en inox qui nous manquait afin de réaliser notre malaxeur.

Nous tenons également à remercier M. Drouaz qui nous a apporté des conseils pour la fabrication de la bière et qui était présent à chacun de nos brassages ainsi que pour les stérilisations du matériel, ainsi que toutes les personnes qui se sont démenées pour nous trouver des bouteilles de bières refermables ou qui peuvent être encapsulées.

Pour finir, nous remercions l’IUT qui nous a donné le financement pour aboutir et surtout commencer ce magnifique projet.  

Introduction:

Nous sommes deux étudiantes de deuxième année en GEII: Toussaint Raphaëlle et Dusausay Laura.

Dans le cadre de notre scolarité, nous avons choisi, dans notre projet, de créer une microbrasserie, dont l’automatisation exploite l’énergie solaire.

Mais dans un premier temps, laissez-nous vous faire découvrir cet art ancestral à travers son histoire, sa fabrication ainsi que son automatisation.

1.La passionnante histoire de la bière :

    1. Chronologie de la bière

Le principe de la bière est de réaliser une fermentation de céréales. La première a vu le jour à Jericho (à côté de Jérusalem)  en 12 000 avant J.C.

Celui-ci s’est développé partout dans le monde en faisant évoluer sa recette de siècle en siècle.

En 4 000 av JC, en Egypte, la bière était une boisson divine. Plus tard elle gagnera l’Europe en devenant une boisson remplie de vertus médicinales. En 1435 ce sont les prêtres qui ont l’exclusivité de la fabrication de ce breuvage. Puis durant l’ère industrielle Pasteur va faire la découverte de la levure ce qui va révolutionner le mode de préparation. Finalement ce n’est qu’en 1950 que la bière va commencer à être industrialisée.

    1.2 Fabrication

1.2.1 Matières premières

Eau Il faut 6L à 8L pour 1L de bière
malt Orge germé et caramélisé, froment, ou seigle
houblon Pour l’amertume, l’arôme, aseptisation, digestibilité
levure Pour la fermentation alcoolique

Tab 1: Les matières premières de la bière

1.2.2 Les 5 grandes étapes

maltage Le malt crée les enzymes nécessaires à la  création d’alcool lors de la fermentation (déjà fait lors de la commande du malt)
Le brassage On hydrate et chauffe le malt permettant l’activation des enzymes ainsi que l’obtention des sucres
cuisson du moût On filtre la fermentation. Le liquide qui en ressort est chauffé à plusieurs températures avec du houblon et d’autres épices. Cette étape permet de donner du goût à la bière
fermentation Cela désigne la réaction chimique qui transforme le sucre en alcool. L’ajout de levure permet de gérer ce procédé.Celui-ci est fait en 2 temps de repos avec des températures différentes.
la garde Procédé de la gazéification

  Tab 2: Explication des procédés de fabrication

2.Réalisation des bières de GEII

    2.1 Première Bière: apprentissage de brassage

Pour notre projet nous avons commandé une microbrasserie afin de l’automatiser. Mais avant toute chose il fallait que l’on se familiarise avec les différents procédés pour connaître les étapes essentielles à automatiser.

Nous voilà donc parties dans la création de notre Première bière.

2.1.1 Matériel et matières premières

Pour 20L de bière:

Kit Brewferm; Une balance; Un minuteur; Récipient pour le malt concassé; Rallonge électrique; Cotons tiges pour stériliser le robinet des cuves

4,4 kg de malt du kit Brewferm; Houblon du kit Brewferm; Eau (suffisamment pour les différentes phases de cuisson et le refroidissement); Sucre Candy du kit Brewferm; Levure du kit Brewferm

2.1.2 Recette de fabrication

Pour commencer, moudre le malt à l’aide du moulin.

Faire chauffer 20 L d’eau jusqu’à atteindre 52°C. Puis ajouter le malt. Après 15 minutes de cuisson, augmenter la température à 62°C puis attendre 45 minutes. Augmenter la température jusqu’à 72°C puis laisser cuire 15 minutes. Enfin, augmenter la température jusqu’à 78°C et attendre 5 minutes. La phase d’empâtage est terminée, on peut passer à la filtration.

Mettre le contenu de la cuve dans une cuve de filtration puis récupérer le liquide sortant du robinet qu’on remet à nouveau dans la cuve de filtration jusqu’à ce que le liquide devienne plus clair.

Vider le contenu de la cuve par le robinet dans la cuve chauffante jusqu’à atteindre 24 L. Pour cela, ajouter de l’eau à la température de 75°C dans la cuve de filtration et patienter. Une fois la valeur de 24L atteinte, faire chauffer jusqu’à atteindre l’ébullition. Une fois le mélange porté à ébullition mettre la chaussette contenant le houblon et patienter pendant 80 minutes.

Commencer à stériliser le refroidisseur, la cuillère ainsi que la cuve de fermentation.

ATTENTION : une fois stérilisé, il ne faut plus mettre ce matériel en contact avec autre chose que la future bière.

A la fin des 80 minutes de cuisson, enlever la chaussette et passer à la phase de refroidissement.

Brancher un tuyau entre le robinet de la cuve chauffante et le refroidisseur, un tuyau entre le refroidisseur et la cuve de fermentation, brancher un tuyau entre le refroidisseur et le robinet d’eau froide et le dernier tuyau entre le refroidisseur et l’évier dans lequel ressortira l’eau qui sera chaude. Activer l’eau froide avec un gros flux puis ouvrir le robinet de la cuve chauffante pour libérer la bière. Attendre que le processus soit terminé.

Pour terminer, ajouter la levure dans de l’eau suivant les indications de la levure. Ajouter cette levure dans la bière et mélanger sans faire de bulle.

Enfin fermer la cuve de fermentation et ajouter le barboteur, dans celui-ci, mettre un peu d’eau.

ATTENTION : l’eau ne doit pas entrer en contact avec la bière.

Mettre la cuve de fermentation dans une salle à 20°C pendant 2 semainesAprès 2 semaines de fermentation, mettre la cuve dans une salle/cave à 15°C pendant 2 semaines.

Stériliser les bouteilles qui vont contenir la bière 48h avant la mise en bouteille à l’aide de chemipro dilué dans de l’eau. Le jour de la mise en bouteille, faire fondre avec de l’eau 7g/L de sucre puis l’ajouter dans la cuve de fermentation (après avoir stérilisé la cuillère).

Stériliser le robinet de la cuve de fermentation. Mettre les bouteilles stérilisées 10 minutes dans de l’eau bouillante puis mettre la bière dans les bouteilles. Stériliser les capsules et capsuler les bouteilles.

Laisser la bière minimum 2 semaines en bouteilles à température ambiante avant dégustation.

 

2.2 Deuxième Bière : consommation d’énergie

Début juin 2018 l’IUT de Mulhouse a investi dans 2 panneaux solaires. Ils peuvent produire jusqu’à 2,2 kWh.

Fonctionnement d’un panneau solaire:

Un panneau solaire est constitué de cellules dites photovoltaïque. Une cellule est constituée de 2 couches de silicium dopées respectivement P et N. Initialement, cette jonction PN est électriquement neutre. Un photon d’énergie suffisante va créer un trou par arrachement d’un l’électron. Par l’agitation des électrons voisins, ce trou va être comblé en piégeant un électron. À l’échelle de la cellule, le comportement est équivalent à une force électromotrice. Si la jonction est insérée dans un circuit fermé, un courant va circuler. Pour augmenter la puissance disponible, il faut placer plusieurs cellules pour former un panneau solaire. La tension est continue. L’énergie peut alors être stockée dans une batterie, qui joue le rôle de récepteur quand elle se charge, puis de générateur lorsqu’elle débite vers un utilisateur. Si l’utilisateur exploite une tension sinusoïdale, il faut alors intercaler un onduleur.

Lors de l’installation il faut veiller qu’aucun objet faisant de l’ombre soit à proximité du panneau. En effet contre toute attente, lorsqu’une cellule est ombragée, c’est la totalité du panneau qui cesse de produire.  Ainsi, à l’IUT, un arbre cache une partie du panneau et fait perdre 30% de la production.

Lors de la première bière nous n’avons pas pu mesurer la consommation d’énergie dont nous avons besoin lors de la fabrication. C’est lors de la fabrication d’une seconde bière, dont la recette est en annexes 2 et 3, que nous avons mesuré la consommation d’énergie nécessaire. Toute les données de production des panneaux solaire de l’IUT sont envoyées sur la plateforme.

Ainsi nous avons pu voir notre consommation d’énergie.

Lors de la fabrication de cette bière, nous avons mesuré la consommation électrique de tout le processus en utilisant les batteries (stock maximal de 4,8 kWh). Ces batteries conservent l’énergie récupérée grâce au panneau solaire installé à l’extérieur du bâtiment. Nous nous baserons sur la consommation des batteries pour ultérieurement faire une analyse de la consommation d’énergie totale d’un brassage.

Au début du processus les batteries étaient chargées à 89% de la charge maximale. On a fait chauffer de l’eau jusqu’à 80°C avant de la laisser refroidir à 67°C. Une fois à 80°C les batteries étaient à 72% de leur charge maximale. Juste avant la phase de filtration les batteries étaient à 68%. Puis on fait chauffer de l’eau de rinçage, une fois l’eau à 78°C les batteries étaient à 60%. Puis on porte l’eau à ébullition. Au début des 80 minutes de cuisson les batteries étaient à 43% puis à la fin de la cuisson elles étaient à 26%.

Remarque: Lors de cette journée les batteries ont pu se recharger légèrement.

Nous voyons sur la courbe de production des batteries ci-dessus, que de 10 h à 11 h 30 le panneau a produit une puissance jusqu’à 600 W et de 15 h 30 à 16 h la consommation était moindre (cf les encadrés noirs de la Fig 8)

Au bilan, pour faire tout le processus (sans compter la mise en bouteille) on a utilisé 89 % – 26 % = 63 % des batteries. Soit 0,63 x 4,8 kWh = 3 kWh. En toute rigueur, on a remarqué que lors de cette journée, les batteries ont pu se recharger légèrement, ce qui signifie que l’énergie réelle consommée est légèrement supérieure.

Cet essai a montré la faisabilité d’alimenter notre installation par le réseau issu des panneaux solaire.

3. Automatisation :

3.1 Liste du matériel nécessaire :

pour le malaxeur et le moulin Pour le PID de la cuve
Une perceuse 900W/230V Une carte Raspberry Pi avec son écran tactile, son alimentation et une carte SD
Des boulot M6 et M8 en inox Un clavier, souris

Une tige filetée M6 en inox d’une longueure d’un mètre

Une tige filetée M8 en inox d’une longueure d’un mètre

Une LED de roue libre 1N4002
Un fer plat en inox une sonde PT100

Pour la sécurité:

Un transformateur 12V 500mA

Un relais de puissance 12V 300mA

Un relais 5V

Une multiprise et une prise terre

Une carte Arduino Uno avec son câble et une résistance 100 Ohm

3.2 Motorisation du moulin :

Lors de la fabrication de la deuxième bière, nous avons motorisé la rotation du moulin à malt. Pour cela les techniciens de l’IUT nous ont usiné une pièce s’adaptant directement au moulinet du moulin pour ainsi utiliser une perceuse. 

La motorisation du moulin est terminée.

3.3 Motorisation du malaxeur :

Nous avons décidé de créer une pièce totalement en inox pour mélanger la bière de façon autonome.

Le choix de l’inox n’est pas anodin: c’est le seul métal inoxydable, adapté à l’alimentaire, et sans influence sur la saveur de la bière.

De ce fait nous avons réalisé un carré avec un fer plat d’un mètre où nous avons inséré des tiges filetées.

De ce fait lors de la rotation fait par la perceuse le liquide dans la cuve est mélangé de façon homogène.

 

 

3.4 Asservissement de la température :

Afin d’asservir la température, nous avons utilisé une sonde PT100, une carte Arduino Uno, une carte Raspberry Pi, un écran, un relais 5V, un relais 12V, un transformateur, une prise avec terre et la cuve chauffante Brewferm.

Le but est de commander la sonde PT100 à l’aide d’un Raspberry Pi afin que la température soit affichée sur un écran et qu’elle se régule seule suivant le programme de cuisson demandé. La sonde PT100 envoie un signal analogique et le Raspberry Pi ne reçoit que des signaux numériques, c’est pourquoi on ajoute une carte Arduino Uno qui fait office de convertisseur analogique/numérique. La carte Raspberry Pi sera donc reliée à un écran qui affichera le programme de cuisson et la température.

Elle sera aussi reliée à un relais 5V qui sera relié à un relais de puissance 12V. Les deux relais servent de protection à notre matériel. Ce relais de puissance sera relié d’un côté par la cuve chauffante Brewferm, et d’un autre côté par un transformateur qui sera branché au 230V de la prise secteur. 

Nous avons choisi la sonde PT100 grâce à ses caractéristiques :

– une précision d’un dixième de degré : largement suffisant pour notre application,

– gamme de température allant de 0 °C à 100 °C : adaptée à notre température de cuisson qui est de 90 °C,

– temps de réponse inférieure à 1 s : parfaitement cohérent avec notre projet. En effet, la montée en température de notre cuve est environ de 30 minutes pour une élévation de 20 °C. Le temps de réponse du capteur seul est donc négligeable.

3.4.1 Connectique Raspberry Pi → Cuve

 cuve relais de puissance relais 5V Raspy

Pour s’assurer de la sécurité de la cuve ainsi que de l’interface, nous utilisons des relais. 

On va utiliser une triplette avec un arrêt ON/OFF de plus de 3000W pour s’assurer qu’elle supporte les 2000W de la cuve, la perceuse du malaxeur ainsi que les relais. 

Par loi de Joule, 2kW, 230 V aboutit à un courant de 8,7 A. Ce qui nécessite un câble de section 1 mm2. Une fois le branchement réalisé nous pouvons passer à la programmation.

3.4.2 Programmation de la sonde:

Objectif : à travers une interface l’utilisateur choisira les 3 temps de cuisson et les températures associées ainsi que le temps de houblon. De cette façon l’utilisateur peut vaquer à ses occupations en recevant un email à chaque changement de cuisson, pour chaque houblon et fin de cuisson.

Nous avons donc commencé cette partie de l’automatisation par la programmation de la carte Raspberry Pi et de la carte Arduino Uno. La particularité de la sonde PT100, c’est qu’à 0 degrés Celsius celle-ci agit comme une résistance de 100 ohms. Celle-ci est reliée à la carte Arduino à l’aide d’un pont diviseur de tension avec une résistance 100 Ohm afin de faire la conversion analogique/numérique et de sortir une valeur de la température. (Fig 13) Cette valeur de température sera ensuite envoyée au Raspberry Pi. Le Raspberry Pi sera programmé pour recevoir les informations de la sonde dans un premier temps.

Pour l’arduino nous avons fait un programme nous permet de récupérer les valeurs de la sonde qui arrivent sur le port analogique de l’Arduino. Nous recevons les valeurs en millivolts que nous convertissons en degrés Celsius.

Pour ce faire, nous utilisons la fonction map qui permet de faire cette conversion. Pour calibrer la sonde, nous la mettons à 0°C et récupérons la valeur en millivolt. Nous ferons de même pour 100°C. Pour finir nous affichons le résultat en degrés sur la console. 

3.4.3 Programmation du contrôle de la cuve

Nous allons utiliser le  logiciel python pour programmer la cuve. Le principe de fonctionnement est le suivant :

  • Nous contrôlons constamment la température, si elle est trop froide on active le GPIO 12 (pin sur lequel est branché la cuve) donc on allume la cuve, sinon on le désactive pour l’éteindre.
  • Nous avons créé des paliers de température et de houblons
  • Nous utilisons des minuteurs pour savoir si le temps des paliers sont écoulés pour passer au suivant
  • Nous pilotons également 5 autres GPIO qui vont servir à envoyer des mails de suivi à l’utilisateur

Initialisation :

En début de programme toutes les variables, mettrons les GPIO sur FALSE (éteint), nous enregistrons les temps de cuisson et des houblons saisis

Chronomètre:

Nous utilisons le temps instantané sur lequel nous allons ajouter la durée saisie par l’utilisateur. 

Cependant l’utilisateur rentre dans l’interface une durée en minute uniquement, telle que 90 minutes. Ainsi, nous avons créé 2 fonctions permettant de transformer et d’ajouter la saisie des minutes de l’utilisateur, en heure et minute d’arrivée.

ex: il est 13h30, nous saisissons 70 min →  70 minutes c’est 1h et 10 minutes.–> la fonction renvoie heure prévu= 1h, Minute prévu=40

Régulation de la température:

Pour cela, nous avons créé une fonction qui va piloter le GPIO relié à la cuve pour l’activer ou non. Le principe est le suivant : si la température reçue par la sonde est inférieure à la température désirée, on allume la cuve sinon on l’éteint.

Architecture du programme:

Le programme est essentiellement constitué de “while” et de condition ”if”. Pour la première cuisson nous attendons que l’utilisateur lance le programme en appuyant sur le bouton de l’interface. Le programme est fait en deux parties : première cuisson et deuxième cuisson. A chaque fois nous devons attendre que l’utilisateur active la cuisson pour lancer l’algorithme. 

Dès lors, pour la première cuisson, nous allons créer des boucles qui vont s’exécuter tant que la cuisson avec ses paliers ne sont pas arrivées à termes.  A l’intérieur nous y plaçons la condition suivante :

Si la température relevé par la sonde est inférieure ou supérieure à 5°C de la température voulue pour le palier, nous la régulons comme nous avons vu précédemment.

Sinon nous lançons le chronomètre adéquat au palier. Et rentrons dans une boucle “tant que  l’heure instantanée est inférieure à l’heure de fin du chronomètre” , nous relevons la température de la sonde, nous ajustons en conséquence la température et nous relevons l’heure instantanée. Dès qu’on sort du “tant que” nous activons le GPIO adapté pour envoyer un mail puis nous le remettons en état OFF.

Cette condition va être répétée 3 fois soit le nombre de paliers maximum dans la première cuisson.

Lorsque les 3 paliers ont été exécutés, nous envoyons un mail de fin de première cuisson, sortons de tous les “tant que”, et coupons la cuve. 

Pour la deuxième cuisson le principe est similaire mais simplifié car la température reste constante à 90°C.

Ainsi nous allons faire une série de chronomètre avec comme consigne tant que le chronomètre précédent n’est pas écoulé on ne passe pas au suivant. Dès qu’un chronomètre est écoulé nous envoyons un mail, indiquant qu’il faut rajouter un houblon.

3.4.4 Programmation de NodeRed

L’application Node Red se fait en trois étapes distinctes, nous commençons par détecter un changement de front sur l’un des pins du Raspberry Pi (boite bleue). Ce changement de front nous indiquera à quel moment de la cuisson nous nous situons. Ensuite, suivant le pin détecté, on fait une fonction dans laquelle on affiche le message voulu (boite orange). Pour finir, ce message est envoyé par email afin de prévenir l’utilisateur du changement de température dans une cuisson ou alors pour prévenir qu’il faut mettre le houblon (boite verte).

3.4.5 Programmation de l’interface

Voici l’interface utilisée:

La programmation de l’interface se fait plutôt facilement. Il suffit de connaître les lignes de codes qui permettent de faire apparaître un bouton, une liste ou encore un texte et le tour est joué.

Voici des extraits de codes expliqués:

Nous avons choisi d’afficher l’heure  sur l’interface afin de nous éviter d’avoir une montre à côté de nous. Pour cela, nous avons créé une fonction qui permet de récupérer l’heure instantanée du Raspberry Pi. Puis on sélectionne l’endroit où l’on veut l’affiche à l’aide de la fonction “.grid”. On choisit la colonne et la ligne dans lesquelles on veut que l’heure s’affiche. 

Ensuite nous avons différentes zones de textes, ce sont les zones dans lesquelles on a déjà un texte comme “Palier 1”.  Pour cela, nous utilisons un “Label”, nous lui donnons un nom et le plaçons dans l’interface toujours à l’aide de la fonction “.grid”.

Nous avons également créé des “Spinbox” qui représentent les cases dans lesquelles nous choisissons une valeur. Nous décidons de pouvoir avoir des valeurs entre 0 et 150 “from_=0, to=150”, sauf pour la température que nous décidons d’avoir comme minimum 30 (from_=30, to=150). Les trois quarts du programme sont constitués de ces quatre lignes. 

Pour terminer, nous avons ajouté deux boutons : un qui lancera le chronomètre de la première cuisson, et un qui lancera le chronomètre de la deuxième cuisson.

On utilise donc la fonction “Button” dans laquelle nous entrons un texte, qui figurera sur le bouton, ainsi qu’une commande à lancer et sa position dans l’interface. Cette commande se trouve dans le programme qui contrôle la cuve. Ainsi, lors de l’appui sur le bouton de l’interface, le chronomètre ainsi que les fonctions de chauffe se mettent en route grâce à la liaison entre les deux programmes.

Le petit plus de notre interface est d’avoir une barre de menu dans lequel nous avons un seul menu, “Fichier”.

Dans ce menu “Fichier” nous avons créé un sous-menu “Bière blonde” et un sous-menu “Bière Ambrée”. En cliquant sur ces sous-menus, la recette de la bière s’affiche dans la console grâce à la fonction “command=”. Les fonctions “Recette_biere_blonde” et “Recette_biere_ambree” nous permettent tout simplement d’écrire dans la console le texte voulu qui est entre guillemets. Nous avons également ajouté un sous-menu “Quitter” qui permet de fermer l’interface.

4.Améliorations possibles :

 

Pour améliorer ce projet nous pouvons y apporter certaines modifications au niveau de la programmation, du malaxeur ou encore de la sonde.

4.1 La programmation:

Faute de temps, nous n’avons pas pu rassembler les programmes de l’interface et du programme principal. Pour les rassembler il y a 2 solutions. La première c’est de les rassembler tout en gardant 2 programmes différents, un pour le programme principal et un pour le programme de l’interface. La deuxième solution est de mettre les 2 programmes dans un seul et même programme qui lancera tout en même temps, cependant cette solution donnera un programme très long et assez complexe.

4.2 Le malaxeur:

Le malaxeur est prêt mais il n’est pas en place. Pour cela, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la tige filetée qui se logera dans le mandrin de la perceuse. Mais pour tenir la perceuse il faudrait aussi pouvoir

 

4.3 La sonde:

La sonde est programmée mais pour l’instant elle est juste posée dans la cuve. Pour la fixer, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la sonde, mais attention, il faudrait trouver une solution afin qu’elle ne soit pas emportée par le remous du malaxeur.

5. Conclusion

Ce projet fut très enrichissant que ce soit d‘un point de vue technique  que d’un point de vue humain. En effet à travers ce projet nous avons pu rencontrer plusieurs personnes qui nous ont soutenu et partagé leurs savoirs.

Sur le côté technique, l’automatisation de la micro brasserie fut très complet. Nous avons vu la programmation sur 3 supports différents (Raspberry Pi, Node Red, Arduino). Pour la mécanique nous avons pensé, découpé, plié, assemblé différentes pièces. Côté électronique, nous nous sommes occupées des commandes et de l’assemblage des éléments.

La partie énergie nous a sensibilisé au fonctionnement et à la lecture des graphiques fournis par le panneau solaire.

Finalement, ce projet est bien plus qu’un simple projet brassage. C’est un assemblage de savoir faire que nous avons mené à bien grâce à nos connaissances et au partage des savoir-faire. Pour le mener à terme, nous n’avons pas hésité à prendre de notre temps personnel.

Malgré les difficultés rencontrées nous avons réussi à obtenir un système qui fonctionne convenablement.

 


Babyfoot connecté


Equipe de projet 

  • BERRIAT Théodore (2ème année DUT GEII)
  • ENDLE Antoine (2ème année DUT GEII)
  • HALTER Jérôme (2ème année DUT GEII)
  • HUSSON Stuart (2ème année DUT GMP)
  • MARCHAND Louis (2ème année DUT GMP)

LE CONCEPT : PRÉSENTATION GÉNÉRALE

 

Dans le cadre de nos études en Génie Électrique et Informatique Industrielle (GEII), nous sommes ammenés cette année à réaliser un projet en collaboration avec le département Génie Mécanique et Productique (GMP).  Grâce à notre mixité de compétences, notre babyfoot connecté, à donc pour vocation de renforcer l’espace convivial de rencontre et d’échanges entre tous les étudiants de l’IUT de Mulhouse.


Qu’est-ce que le baby foot ?

Pour faire simple, le baby foot c’est une table avec des rebords, 8 barres, des poignées sur chacune de celles-ci, des joueurs et une balle. Il y a une cage de chaque côté du terrain de jeu. Chaque joueur/équipe utilise ses poignées pour faire bouger leurs joueurs afin qu’ils tapent la balle dans la cage adverse. On attaque toujours vers la droite et l’on défend à sa gauche. Il existe différentes sortes de « tables de jeu », que nous appellerons plus communément « baby-foot », qui ont chacune leur caractéristiques propres, c’est pour cela que l’écartement entre les joueurs, leur taille/proportion, le type de barre… diffère selon le modèle de baby-foot utilisé. Le baby foot est joué dans pratiquement le monde entier.
Le jeu est très rapide, amusant et convient à absolument tout le monde, personne n’est exclu. Vous pouvez jouer des années sans jamais être lassé.


Présentation du projet

Nous avons choisi de rénover un baby foot inemployé car son état était défectueux, pour en créer un baby foot connecté performant et confortable à jouer. Notre démarche favorise la convivialité au seins de notre amical à l’IUT de Mulhouse. Aujourd’hui, l’innovation est au cœurs du monde, c’est aussi pourquoi nous sommes particulièrement motivé sur le fait d’innover un objet « banal » et de le transformer en un objet technologique, cela représente en vrai défi technique. Notre baby foot connecté sera principalement équipé d’un Raspberry PI 3, d’un écran, de capteurs et de leds. Il pourra compter les buts inscrits afin de les afficher sur un écran ainsi qu’allumer les leds de la couleur adéquate lors d’un but selon l’équipe l’ayant marqué, et tout cela de façon autonome ! En parallèle, nos collaborateurs du département Génie Mécanique et Productique s’occuperont de la rénovation et de l’esthétique de celui-ci.


Cahier des charges 

Diagramme bête à cornes

Diagramme Pieuvre

 

Nom de la fonction Désignation de la fonction de service
FP1 Permettre à l’utilisateur de simuler une partie de football sur table et de se divertir
FC1 Permettre une interaction à l’utilisateur
FC2 Permettre la détection de buts
FC3 Permettre d’afficher le score et être réglable par l’utilisateur

Diagramme bloc

 

Diagramme d’exigence

 

Budget

Partie Capteurs

Passons à présent à la détection des buts !

Montage électrique :

Nous avons récupéré des capteurs de proximité dans nos entreprises, ce qui nous permettra d’avoir une plus grande durée de vie, ainsi qu’une robustesse accrue. En revanche, ces capteurs n’étaient pas adaptés pour une utilisation sur un microcontrôleur. En effet, ils délivrent un signal comprit entre 12V et 24V, alors que notre Raspberry PI3+ accepte maximum 5V sur le Port GPIO.

Pour se faire, nous avons du faire un Pont diviseur de tension, pour abaisser la tension de 12V à 5V (les 12V proviennent de l’alimentation qu’on leur fournit). Nous avons utilisé une résistance de 220 Ohm ainsi qu’une Diode Zener  5.1 V, on câblera comme ceci :

Voici en image un test que nous avons effectué avec les composants cités si dessus, ainsi qu’une LED pour vérifier la présence de tension de 5V à la sortie du montage  :

(Le capteur est au niveau logique « 1 », c’est à dire qu’il délivre une tension de 12V que l’on abaisse à 5V)

La LED n’est pas grillée, on peut donc se brancher sur le port GPIO de notre Raspberry !

Voici à quoi ressemble notre « adaptateur » une fois soudé. Nous l’avons placé dans une boite pour éviter des contacts avec d’autres fils, faciliter le raccordement, et le protéger du milieu ambiant.

Notre capteur sera alors relié à notre pont diviseur de tension, et la sortie de celui-ci sera reliée sur les PIN numéro 7 et 37 du microcontrôleur. Passons à présent au software, qui nous permettra de compter les buts marqués par chaque équipe.

Programmation :

Nous avons commencé à programmer en langage python sur l’invité de commande du Raspberry, mais nous avons vite remarqué que la gestion de plusieurs événements ainsi que la surveillance simultanée de l’état des capteurs allait être compliqué.
Voici un exemple de code pour détecter le passage au niveau logique « 1 » d’un capteur :

 

 

Nous avons opté pour une autre solution de programmation, beaucoup plus simple et facile à mettre en oeuvre : Node-Red.
On passe donc du code ci dessus à ceci, pour les mêmes fonctionnalités :

 

Présentation de Node Red : 


Node-RED
 est un langage de programmation graphique par assemblage de blocs fonctionnels qui permet de développer des objets connectés (et beaucoup d’autres choses). Node-Red est un projet Open Source (et gratuit) soutenu par IBM. On programme avec Node-RED en liant des fonctions présentées sous la forme de briques, cela réduit fortement le codage. Le flux de données passe d’un traitement à l’autre (d’une fonction à l’autre). Certaines fonctions proposent des paramètres qu’il suffit de définir à l’aide d’une liste de choix ou d’un champ à remplir (par exemple un clé d’API pour un service météo). Il existe plusieurs centaines de bibliothèques dans tous les domaines : enregistrer les données sur une base de données (MySQL, MongoDB…), piloter les E/S d’un Arduino ou d’un Raspberry, ajouter une interface graphique (UI) pour tracer des graphiques, afficher des jauges, commander un relai à l’aide d’un bouton…

 

 

 

 

 

 

Démarrer Node-Red

Pour démarrer Node-Red sur Raspberry dans Menu -> Programmation

On peut également démarrer depuis le Terminal avec la commande

Une fois lancé, nous avons préféré programmer sur ordinateur.
Pour cela,  il suffit de récupérer l’adresse IP de notre Raspberry sur l’invité de commande puis de saisir sur le navigateur internet :

On arrive ensuite sur l’écran de Node-Red

 

Sur la gauche de l’écran se trouvent toutes les fonctions disponibles. Au centre se trouve la zone de programmation. Le panneau de droite regroupe un onglet info regroupant des informations contextuelles (exemple correspondant à la fonction sélectionnée…) et un onglet debug qui renvoie les messages d’erreurs ainsi que les messages de la fonction debug qui se trouve dans les outils output.

A partir de là, nous avons installé les nœuds nécessaires afin de pouvoir répondre à notre cahier des charges initial.

Ce progiciel va donc nous permettre de gérer la détection des buts, la gestion des rubans de LEDS, mais aussi l’affichage du score sur notre afficheur, par exemple.

Voici à quoi ressemble l’ensemble des blocs afin de gérer l’information des capteurs, ainsi que les compteurs des buts marqués par chaque équipe. On va détailler le rôle de chacun si dessous :

On retrouve en première position à gauche l’entrée du port GPIO du Raspberry :

Le bloc suivant intitulé « Rising Edge » va nous permettre de détecter uniquement le front montant du signal du capteur : autrement dit, on ne va pas tester le niveau logique du capteur (0 ou 1) mais le passage de l’état 0 du capteur, à l’état 1. Ceci va nous permettre de n’incrémenter notre compteur de but qu’une seule fois, car il est initialement programmé pour s’incrémenté à chaque changement d’état à son entrée. Sans ce bloc, lors d’une détection de but, notre compteur s’incrémentait de +2 (+1 lors du passage du capteur de 0 à 1, puis une nouvelle fois de +1 en repassant de 1 à 0). Afin d’obtenir ces deux blocs, nous avons du les installer au préalable, comme ci dessous :

Voici le bloc « compteur » qui se situe après le bloc front montant , avec comme paramètres :

  • Name : le nom du compteur
  • Initial Count : Valeur initiale du compteur = 0
  • Default Step : incrément la valeur, par pas de 1
  • Lower Limit : valeur limite basse = 0
  • Upper Limit : valeur limite haute = 10
  • Mode : increment, car on augmente la valeur de 1 but à chaque événement
  • Outputs : une seule sortie à la sortie de ce bloc

En dernière position nous avons un bloc appelé « set msg.count », qui sera utilisé pour transmettre la valeur actuelle des compteurs vers l’affichage sur le dashboard. Nous détailleront cette partie dans la rubrique « Interface »

 

Partie Interface Graphique Node Red

Nous avons tout d’abord commencé par installer le nœud dashboard. Celui ci nous a permit de gérer l’interface graphique à l’aide de différentes commandes. Chacune d’elle est spécifique, vous trouvez le contenu un peu plus bas.

 

 

 

 

 

 

 

 

 

 

 

 

 

1) Conception de la page d’accueil :

  

La page d’accueil est constitué de deux blocs. Le premier bloc « logo » et le second « Réalisation ». Ce sont tous les deux des « templates », c’est à dire que nous allons pouvoir insérer des images, écrire, décider de l’alignement du texte… grâce à la programmation en html.

2) Menu Règles :

On affiche la page des règles avec un scroll :

3) Menu de match : Score 

  • Nœud But Equipe Rouge => Affiche le texte sur l’interface graphique
  • Nœud Score =>  Récupère la valeur du compteur
  • Nœud Compte Equipe Bleu => Permet de disposer la valeur du compteur au centre
  • Nœud Remise à zéro => Lors d’un appui, il envoie l’info au RAZ et ainsi le RAZ injecte 0 dans le nœud de comptage

Avec le bouton de remise à zéro :

Partie Leds 

 

Les leds dans le projet baby-foot connecté auront comme but de clignoter de la couleur respective à celle de l’équipe afin d’avertir l’utilisateur de la présence d’un nouveau but.

 

Pour répondre à ce besoin nous nous sommes tourné vers l’utilisation d’un ruban de led pour la gestion de la taille des zones à éclairer sur le baby-foot.

Les résistances auront pour but de résister au passage du courant dans les transistors.

 

Le fonctionnement d’un transitor :

 

Le transistor dispose de 3 bornes, le collecteur, l’émetteur et la base. Le collecteur et l’émetteur sont techniquement symétriques. Dans notre cas le collecteur sera la couleur du ruban de leds et l’émetteur le 0V, car nous souhaitons émettre aux leds le 0V afin de les faire briller. La base, notre signal de sortie du Raspberry permet de laisser passer ou non la conductivité du collecteur vers l’émetteur en laissant passer les électrons se trouvant dans le transistor grâce à l’envoie d’une faible tension, ici 3,3V.

 

Schéma d’un Transistor NPN avec 0V à la base

Schéma d’un Transistor NPN avec 3,3V à la base

 

Montage électrique :

 

Mesure courant des leds :

  • Bleu : 0.7A
  • Rouge : 0.8A
  • Vert : 0.7A

 

Matériels utilisés :

  • 1 Ruban de leds BRG de 12V
  • 1 Alimentation 12V/2A
  • 3 Transistors 2N4922 NPN 2A
  • 3 Résistances 270 Ohms

 

Pour s’assurer du bon fonctionnement du montage nous avons simuler le signal délivré par le Raspberry à l’aide d’un générateur de tension réglé sur une tension de 3,3V.

 

 

Nous avons élaboré un boitier comprenant le montage précédent.

Voici des photos du résultat final de la boite.

 

Le programme :

 

Voici une vue d’ensemble du programme sur Node-Red permettant le clignotement des leds.

Le programme est composé d’une succession de 4 temporisations de type trigger lancées lors du passage à 1 du capteur détectant un but. Ces temporisations sont reliées aux sorties des leds de la couleur  du but qui fera ainsi clignoter les leds.

 

Le fonctionnement des différentes temporisations en série nous permet de créer différentes impulsions chacune de la valeur de la plus petite temporisation crée. Ce qui entraîne un clignotement des leds pendant une durée de 1s toutes les 125ms dans notre cas.

 

Trigger :

Module de sortie :

 

 

 

Schéma Electrique du Baby-Foot Connecté :

Schéma électrique Baby-Foot Connecté

 

Câblage du Baby-Foot : 

 

Finalisation de la partie Génie Electrique et Informatique Industrielle en vidéo : 

 

Partie GMP

Dans un premier temps, nous avons procédé au démontage et à la rénovation du baby-foot. L’état initial de la structure était exécrable (trous, visseries abimés, bois enfoncé, saletés…) Cette remise en état fut chronophage et couteuse en matériaux (colles, mastic, pâte à réparer, visseries neuves) et en nouveaux outils (forets, mèche à bois). En disposant uniquement d’une soixantaine d’heures de projets, la partie purement mécanique et industrielle du projet fut un réel contre la montre. Malheureusement, malgré de nombreuse heure supplémentaire, le projet n’a pas pu totalement aboutir, notamment à cause de nombreux problèmes au cours du démontage et de la rénovation, bien que les opérations d’usinage et de conception ce sont quant à elles généralement bien déroulés.

Nous allons maintenant vous présenter notre cahier des charges mis en place début décembre, avec les fonctions mises en place et les tâches restants à effectuer :

Cahier des charges (GMP)

FONCTIONS

CRITÈRES

NIVEAUX

FP1 : Assurer une bonne jouabilité du babyfoot

 

Guidage barres de jeu et confort

 

 

Système de palier lisse

Arrêt axial des barres

 

FC1 : Stabiliser le babyfoot

 

Stabiliser

Renforcer les pieds Double pied
Lier les pieds Tige filetée + écrous

 

FC2 : Assurer l’acheminement des balles vers les capteurs

 

Acheminer

 

 

Guider la balle

 

Lattes + tube PVC

 

FC3 : Loger les composants électroniques

 

Logement

Écran Boitier en bois
Capteurs Sur tube PVC

 

FC4 : Doit être esthétique

 

Esthétisme
Design, formes Formes discrètes
Couleurs Toutes

 

FP1 : Assurer une bonne jouabilité du babyfoot

 

Réalisation de paliers lisses afin d’assurer le bon guidage des barres. Après concertation avec les professeurs, l’idée retenue était de réaliser les paliers lisse en laiton pour éviter le contact entre acier et aluminium (peu favorable au glissement). Après consultation avec l’atelier, le délai d’approvisionnement du tube de laiton correspondant à notre besoin était trop important. C’est pourquoi nous avons décidé de réaliser les paliers en aluminium avec bague plastique et utiliser des barres en acier.

 

Présentation du système :

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=4

 

 

 

Modélisation des pièces sous Creo

 

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=3https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=2

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=3

 

 

 

Réalisation de la FAO (Fabrication assistée par ordinateur)

 

 

 

 

Usinage de la pièce avec une commande numérique

 

 

Résultat obtenu :

 

Préparation du flan pour accueillir les 2 pièces

 

 

Perçage de 3 trous diamètre 3.2 pour faire passer les vis d’assemblage M3 du système de guidage.

 

 

Assemble du système de guidage

 

 

Renouvellement des barres : Démontage des barres actuelles, débitage de ronds d’acier Ø15, perçage et mise en place des nouveaux bonhommes. Montage des anneaux de serrage pour bloquer la barre axialement en translation.

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1528&part=2

 

 

Nouvelles surfaces de jeux : nouveau tapis et plinthes en bois. Prise de côtes, mise en plan papier puis transmission à GRAUER Construction, spécialiste dans la création de maisons à ossature bois.

Restructuration du fonds de but : « Gamelles » intempestives dus à la forme peu ingénieuse du fond de but : découpe d’une plaque PVC vissées avec un coussinet sur la paroi pour créer un effet d’amortissement.

Rehausse du plateau de jeu : Pour assurer un meilleur confort de jeu avec les nouveaux joueurs plus petits que les anciens modèles, nous avons rehausser le plateau de jeu à l’aide de calles plastiques normalisées fournies par GRAUER Construction.

 

A faire :

  • Découpe & pose du tapis de jeux
  • Ajout de palier cylindrique plastique (type IGUS) pour minimiser le frottement acier-aluminium des barres avec le palier : Bien que la translation des barres dans les paliers soit optimale avec un système correctement lubrifié, cette solution améliorerait d’avantage le confort de jeu.
  • Opération de percage-alesage et montage serré des paliers cylindriques sur 16 pièces déjà réalisées

 

FC1 : Stabiliser le babyfoot

Stabilisation : Ajout de 4 pieds supplémentaires, conception CAO, mise en plan DXF et sous-traité par HUSSON International (Les pièces en bois trop massive ne pouvant pas être usinées à l’atelier)

Nouveau système de solidarisation du bâti : Fixation des pieds deux à deux via une tige filetée. Le maintien de la distance entre les deux mêmes pieds est assuré par une entretoise. L’écart entre les pieds droits et les pieds gauches sont maintenus grâce à un système de contre-écrou.

A faire :

  • Nous avons pu observer une nette amélioration de la stabilité, mais un phénomène de bascule reste présent et problématique pour le confort de jeu et l’endommagement prématuré des composants. Une recherche d’une nouvelle solution ou amélioration du concept est envisageable.

 

FC2 : Acheminer la balle vers les capteurs

 

Goulotte d’alimentation : Assemblage d’une structure bois/PVC permettant de guider la balle de la sortie de but à l’accès de repêche.

 

A faire :

Perfectionnement de la structure, dans de rares positions la balle reste coincée.

FC3 : Logements des composants électroniques

Création d’un logement d’écran : Réalisation d’un logement d’écran en bois permettant le passage des câbles jusqu’au Raspberry

 

Logement des capteurs dans la goulotte PVC : Réalisation d’une rainure dans la goulotte permettant l’insertion des capteurs en position verticale pour une détection de la balle vers le bas.

 

 

FC4 : Doit être esthétique

Visserie non apparente : Réalisation de cache écrou en impression 3D pour cacher la visserie apparente.

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=5

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=4

Habillage : découpe de profil aluminium pour réaliser le haut de but

Ponçage : peinture à réaliser

 

Conclusion : Ce projet fut motivant de par notre intérêt pour le baby-foot mais également dans l’application de nos compétences de génie mécanique. Cependant, il fut trop ambitieux de prévoir la remise à neuf intégrale du baby-foot en 60 heures. Il y aurait Intérêt de reconduire le projet l’année prochaine pour les futurs étudiants de deuxième année : une base fonctionnelle est en place, mais il reste beaucoup de piste d’améliorations pour obtenir un produit optimal. De plus, lors de la création de chaque pièce, par soucis de ne pas abîmer la structure existante et de pouvoir modifier en cas d’échec, chaque pièce a été conçu de manière à pouvoir être démontées facilement, ce qui facilitera la prise en main par d’autres étudiants.

 

État actuel :

 

 


Lanceur de volants de badminton


LANCEUR DE VOLANT POUR BADMINTON

 

 » On ne devient pas champion dans un gymnase. On devient champion grâce à ce qu’on ressent; un désir, un rêve, une vision. On doit avoir du talent et de la technique. Mais le talent doit être plus fort que la technique. « 

Mohammed Ali

 

 



REMERCIEMENTS

 

Nous tenons a remercier nos professeurs tuteurs sans qui ce projet n’aurait certainement pas aboutis. Nous remercions également Mr De Sabbata qui a été présent à chaque étapes du projets ainsi que nos camarades qui ont fait preuve d’une bienveillance exceptionnelle lors de la conception et des tests.

 

 



 

 

Cet article fait office de rapport dans le cadre du cours Etudes et réalisation. Il s’agit de l’étape final de notre projet qu’est, vous l’aurez compris, le lanceur de volant. Ce projet à été choisie par nous même et réalisé sous la tutelle de nos professeurs référents que sont Mr Bazeille et Mr Verrier. Dans la suite de ce développement, nous allons essayer de vous expliquer et illustrer les étapes intrinsèques à notre réalisation, puis nous allons conclure sur une petite démonstration.

 

Objectif: Réaliser un lanceur de volant pour badminton

 

Membres de l’équipe:  Alexandre DARTOIS,  Adin BADIENZI et Marvin DARBOUX

 

Sommaire

 

I) Contextualisation

1) Présentation du projet

2) Gantt

II) Conception

1) Construction mécanique

2) Conception électrique

III) Programmation

IV) Conclusion

 

 

 



 

I) Contextualisation 

 

Tout d’abord comme son nom l’indique notre projet sera un robot qui va lancer des volants à différentes positions du terrain. Il devra idéalement pouvoir faire des routines permettant l’entrainement du joueur. Notre projet n’a pas vraiment de cahier des charge unique car il évolue au fur est à mesure des besoins liées aux contraintes de jeux.

 1) Présentation du projet

Avant de se lancer dans la conception d’un objet tels que celui ci , quelques prérequis sont importants. Par exemple la vitesse d’un lancer de volant qui peut atteindre les 450 km/h ou encore la taille du terrain  étant de 13,40 m sur 5,20 m pour la réalisation des routines. De ce fait il nous est très vite venu l’idée de se servir de deux disques tournant en sens inverse de façons a pouvoir propulser un volant vers un endroit prédéfinis. On s’est aussi inspiré des modèles existants tels que :

–  Le BLK

 

– Le Aliobot Supra

On peut voir que ces 2 lanceur sont vraiment riches en choix d’exercices et de fonctionnement car il peuvent faire énormément de routines ainsi que des routine spéciales crées par le joueur lui même en réglant la vitesse des volant. Mais le plus intéressant est que le BLK peut se connecter via le Bluetooth à un portable et a son application propre pour faire différente routines.

 

De ce fait, l’idée du support viens très rapidement afin de stabiliser le tout et permettre éventuellement de réaliser manuellement les routines. Pour que ce système soit un peu plus optimale voila les premiers objectifs que nous nous sommes fixés :

Le capteur devait servir à l’incrémentation des volants. Il permettait au lanceur de savoir si le volant est effectivement parti ou non. Si oui il devra permettre au lanceur de repositionner un autre volant de façon autonome et aussi de connaitre le nombre de volant que compose sa série. Pour ce faire il fallait bien évidement un support pour les volants et un système permettant de bloquer les volants le temps que le capteur perçoive un volant.

Afin de réaliser ce tour de force on a eu comme matériel droit à :

– Un RasPi 3 Model B

– Des kits de construction mechano ( gentillement fournis par l’iut lab)

– La possibilité de commander des composants sous peine d’accord de nos tuteurs

 


 

2) GANTT

Avant de pouvoir passer à la partie physique de notre projet on a du commencer par une approche plutôt papier sur l’étude de notre système: la répartition des tache, comment aboutir au résultat escompté, etc . Donc pour ce faire on a commencé par faire différentes analyses avec différents logiciel permettant la facilité pour l’avancement de notre projet et des taches a réaliser.

 

  • Première analyse fonctionnelle dit « la Bête a corne » :

Cette première analyse nous a permis d’exprimer le besoin primaire, donc son exigence principal sous forme très simplifiée.

  • Seconde analyse :

Maintenant qu’on a exprimé la fonction principal de notre lanceur on peut passer à une autre analyse qui est le « le MindMap », cette analyse est le fait de représenter les grande idée et partie qui vont constituer un même sujet qui pour nous est notre lanceur de volant:

 

  • Dernière analyse :

Maintenant grâce a notre MindMap on peut faire notre Gantt qui est le fait de planifier toutes les idées trouvé lors de l’analyse précédente en fonction de la durée de notre projet ainsi que d’autres contraintes.

Grace a notre planification on peut voir les durée « prévisionnelle » et surtout la date de début et de fin du projet et de chaque sous partie.Notre projet commença le 30 novembre 2017 et la dernière consacré a celui-ci était le 22 janvier 2018.

 



II) Conception

 

Maintenant que toute l’étude est faite on peut passer au gros du projet qu’est la partie conception d’une structure adéquate pour notre lanceur.

 

1) Conception mécanique 

Avant de pouvoir tester des programmes on doit tout d’abord ce pencher sur une structure permettant de lancer des volants.

Schémas illustrant le mode de fonctionnement

 

D’où Notre choix qui c’est très vite porté sur les méchanos pour la réalisation de la structure à cause de la diversité des composants et outils que présente ces boites(Makeblock). On a commencé dans l’optique que ce que nous réaliserons avec les méchanos sera un prototype pour ensuite créer notre « vrai » réalisation. Dans un premiers temps nous nous sommes concentrés sur la structure:

  • Première réalisation et problèmes associés

Réalisation intermédiaire (I)

On peut voir sur cette image que notre réalisation n’est pas adéquate pour lancer des volants de part ça rigidité qui n’est pas bonne car certaines pièces sont déformé sous le poids de nos moteur et des tremblements du a la rotation des moteur. L’impacte de la mise en route des moteurs provoque un bruit assourdissant à cause de l’écart et des frottements entre les roues dentés.

  • Après ces premiers résultats quelques peut chaotiques, voici ce que nous avions imaginé ensuite

Résultat intermédiaire (II)

On peut voir sur cette image que le second test juste l’aspect externe montre un peu plus de rigidité mais il y a d’autre aspect technique qui on était résolu comme par exemple le niveau des roue qui était du a la mauvaise rigidité de la structure ainsi que l’espace pour le volant ou encore les vibration des moteur qui on était réduite, etc. Donc au vue des aspects résolu on remarque qu’une grande partie était du a la rigidité de la structure. Cependant les 2 plus gros problème sont toujours a résoudre : Les tremblement ainsi que le bruit assourdissant.

Le modèle illustré ci-dessus fait office de premier prototype pour notre lanceur de volant. Bien que plutôt satisfaisant pour effectuer des lancers, on a préférer le solidifier pour le prototype finale, prototype que nous illustrerons dans la partie conception électrique car cette structure comporte des composant qui seront expliqué dans cette partie.


Maintenant que nous disposons d’une structure convenable au lancé on va pouvoir y incorporé des composant qui vont permettre le confort des utilisateurs ainsi que le bon fonctionnement de notre lanceur.

2) Conception électrique

Pour commencer voici un petit schéma qui regroupe les grandes parties qui compose notre lanceur et qui seront implantés dans la structure vu dans la partie conception mécanique :

 

Principe de fonctionnement

 

Nous avons essayé par le biais du schémas ci-dessus de vous illustrer les différents  composants électriques qui ont intervenus lors de la conception du lanceur.Voici une liste non exhaustive des composants que nous avions choisi:

  • dans le cas des moteurs on a opté  pour le 42BYG Stepper
  • dans le cas du capteur Ultrason on a opté pour le Me Ultrasonic sensor
  • pour l’affichage du choix des routines on a choisi le Me TFT LCD screen
  • pour gérer l’ensemble des composants on a choisi le Me Orion
  • pour choisir son mode de jeux on a préférer le Me 4Button

Pourquoi le 42BYG stepper ?

En résumé il s’agissait tout simplement du moteur pas à pas le plus puissant disponible dans les boites Makeblock. Avec sa puissance, on pouvait se rapprocher (avec un système similaire à celui des engrenages) d’un lancer ordinaire de volant par un individus quelconque.  De plus par le biais du contrôleur qui lui est systématiquement associer on pouvait gérer le voltage et l’ampérage, donc agir sur la façons dont allait tourner le moteur ( les roues) .

2H ME Make (contrôleur pas à pas)

Le Me 2H Microstep Driver est une pilote de moteur pas à pas hybride à 2 phases, et adopte l’alimentation de DC 12 ~ 36V. Il est adapté pour piloter le moteur pas à pas hybride à 2 phases avec une tension de 24 ~ 36V et un courant inférieur à 2,0A. Ce pilote utilise la boucle de courant numérique complète pour mettre en œuvre le contrôle de micropas, de sorte que le moteur présente une faible ondulation du couple, une faible vitesse et un fonctionnement fluide, des vibrations et du bruit faibles. Lorsqu’il tourne à grande vitesse, son couple de sortie est relativement élevé et sa précision de positionnement est élevée.

 

Le Me Orion , qu’est ce que c’est ?

Me Orion

Le Makeblock Orion est une sorte de carte mère basée sur Arduino Uno . Il se munit de huit ports RJ25 pour se connecter à tous les autres modules de la série Me (kit Inventor ou séparé sur demande) avec des étiquettes couleur. Il supporte  la plupart des logiciels de programmation (Arduino / Scratch / AduBlock).

 

Maintenant que vous connaissez la plupart des composant qui seront implanté dans notre lanceur voici le résultat final après que chaque composants soit inséré :

On peut voir sûr cette image la structure final avec les solution technique au problème expliqué dans la partie conception mécanique et donc les solution sont pour le bruit on a utilisé une courroie entre l’axe du moteur et celui des roue qui permet d’évité le frottement entre les 2 axes et pour les tremblement on a opté pour des pied qui vont permettre au moteur de ne pas être directement en contacte avec le sol et ainsi limité au maximum les vibrations. On peut voir aussi les composant électrique utilisé comme :  – la carte Me Orion (en haut au milieu)

– les 2 moteur (en bas) et leur driver (en haut)

– l’écran LCD (en haut)

– le capteur (au milieu de l’image)

– la télécommande (a gauche au milieu)

Maintenant que nous avons un prototype opérationnel on peut passez a la partie programmation.

 



III) PROGRAMMATION

 

Avant de ce lancé dans du code pur et dur voici un schéma explicatif de comment notre lanceur fonctionnera et donc de comment le programme sera fait.

Principe de fonctionnement informatique

 

1) Rasberry Pi 3

Qu’est ce que c’est ?

Le Raspberry Pi est un ordinateur à processeur ARM conçu par David Braben, dans le cadre de sa fondation Raspberry Pi2. Cet ordinateur  permet l’exécution de plusieurs variantes du système d’exploitation libre GNU/Linux et des nombreux logiciels compatibles. Il existent actuellement plusieurs versions du Raspberry-Pi. Il est malgré sa taille réduite suffisamment ouvert (ports USB, réseau) et puissant (ARM 700 MHz, 256 Mo de mémoire vive pour le modèle d’origine, 512 Mio sur les dernières versions) pour permettre une grande palette d’utilisations.

Le Raspberry Pi 3 est quant à lui équipé d’un processeur ARM Cortex-A53 quad-core 64 bits (Bradcom BCM2837) fonctionnant à 1.2GHz, de 4 ports USB 2.0, 1Go de mémoire, 1 sortie vidéo HDMI 1.3a, 1 port Ethernet 10/100, 1 prise jack audio/vidéo. La version 3 ajoute le support du Bluetooth 4 BLE (BCM43438) et plus du WiFi 802.11 b/g/n (BCM43438). Enfin, il possède un connecteur CSI permettant de brancher une caméra compatible.

 

Raspi 3

Un problème c’est alors très vite posé. Celui de se servir d’un rasberry Pi pour piloter une cate arduino. Afin de palier à ce problème une solution existe : le Megapi

Megapi Makerblock

Mais on très vite abandonné cette piste faute de matériel. Il fallait se  munir d’un Megapi et coté timing on étais assez limités. On a donc écarté le fait d’inclure le Rasberry Pi dans notre projet.

Nous avons décidé d’utiliser arduino afin de programmer.

2) Arduino (logiciel)

Mais arduino qu’est ce que c’est ?

Le logiciel Arduino (IDE) open source fonctionne sous Windows, Mac OS X et Linux. L’environnement est écrit en Java et basé sur processing avec d’autres logiciels open-source. Il fonctionne également comme compilateur C. Le C est adopté dans le monde entier pour les microprocesseurs. Il offre un bon compromis entre l’effort de développement et l’efficacité du programme.

 

 

Maintenant que le domaine informatique est devenu limpide on va pouvoir passez au code que je vais séparé en plusieurs partie distincte pour que votre compréhension soit plus facile :



Pour commencé on a inséré les librairie qui sont propre a notre carte MeOrion et pour notre moteur pas a pas AccelStepper, ensuite on définie une longueur max pour notre écran LCD et après on a créer des variable qu’on a mit a 0  de base ou d’autre qu’on a juste créer ensuite on a définie chaque composant utilisé :  – MeSerial (écran LCD) connecté au port 5.

– Me4Button(télécommande) connecté au port 8 et on définie ce qui ce passe quand on appuie sur le bouton.

– AccelStepper(Moteur pas à pas) on définie les 2 sens de marche et sur quel variable interne au MeOrion il sont connecté, le FULL2WIRE signifie qu’il n’y a que 2 fil pour un sens.

– MeUltrasonicSensor (capteur Ultrason) connecté au port 6 du MeOrion.

 

 

Maintenant qu’on a définie les librairies, les variables et les composant on peut passez a l’initialisation.



Pour l’initialisation on a juste définie une série d’action que notre lanceur va exécuté. Le mySerial.begin permet de définir la vitesse des bits donc des bauds et les mySerial.print(ln) permette d’écrire sur l’écran LCD. Donc cette série d’action va écrire UHA dans un rectangle ensuite on attend 3 seconde puis efface tous et on écris 3 phrase « Salut … » « Je suis B0-1 … » « Jouons ensemble ! » ensuite on efface tous et on écris « Owww tu vas kiffer » et aprés on efface tous.

 

 

Maintenant que notre initialisation est faite on va passez a la création de la fonction menu.



Pour la fonction menu ces une fonction qui est créé et qui pourra être appelez dans le programme, donc on peut voir que cette fonction est très simple elle permet juste d’écrire les 3 jeux qu’il y a et sur quel bouton il faut appuyé et sur quel bouton appuyé pour retourné au menu.

 

 

Maintenant on peut passez a la boucle infinie.



On peut voir dans cette boucle qu’au début définie ce que signifie appuyé sur le bouton et ensuite comme la variable start a été mise a 0 au début alors on appelle la fonction menu vu précédemment ensuite on passe start à 1 pour pouvoir commencé le programme.

 

 

Maintenant avant de passez a la création des jeux on va commencé par le capteur.



On peut voir que pour le capteur on commence par créer un compteur ensuite il faut que le moteur tourne toujours donc il faut constamment mettre des stepper(1/2).run() ensuite on demande pour que l’écran LCD écrive Nb_de volant suivi de la valeur du compteur. Puis pour un aspect visuelle on dit que pour chaque jeux on veut qu’il écrive le nom de ce jeux.

 

 

Maintenant pour un aspect visuelle on a définie des conditions.



On peut voir que ces condition sont active que quand soit tout les bits poubelle sont à 0 ou a 1 pour explication les bits poubelle sont définie pour l’activation(=1) ou la désactivation(=0) du mode de jeux pour résumé il permette soit que les moteur accélère pour pouvoir commencé le jeux soit qu’il décélère pour pouvoir arrêté le jeux, chaque jeux possède sont bit poubelle. Donc quand un des bits et a 0 alors on écrit que les moteurs vont s’arrêté et donc atteindre 0 tr/min et inversement quand un des bits et a 1 alors le moteur va atteindre 1200 tr/min.

 

 

Maintenant pour notre plus grand plaisir on a créé un événement.



On peut voir pour cette événement qu’il s’active quand le capteur a compté 10 volant et il va écrire sur l’écran « PFF petit joueur ».

 

 

Maintenant on peut passez a la création des jeux.



On peut voir pour la création du jeux 1 qu’on regarde quel bouton a été pressé si ces le bouton 1 alors on est dans le mode_jeux=1 et on incrémente la variable poubelle adéquate ensuite si celle-ci est égal a 1 alors on écrit le nom du jeux et la vitesse des moteurs. Ensuite on définie que la position actuelle des moteur est 0 et on lui donne une vitesse max une accélération et une position a atteindre (comme la position est très grande le moteur ne s’arrêtera pas tout de suite) et on fait cela pour les 2 moteurs.

 

 

Maintenant que la partie accélération et faite il faut passez a la partie décélération.



On peut voir comme je l’ai dit précédemment quand poubelle égal 2 (égal 0 car boucle infinie donc il voit poubelle égal à 0) alors le moteur est en phase de décélération, donc quand on appui de nouveau sur le même jeux la variable s’incrémente et donc on passe en phase de décélération (poubelle=2) dans cette phase on écrit la vitesse du moteur et le nom du jeux ensuite on prend la position du moteur actuelle et on lui dit qu’il a 5 fois cette distance pour s’arrêté.

Voici pour un mode de jeux mais le scénario ce répète a part que les moteur utilisé ne seront pas les même.

 



IV CONCLUSION

 

Quoi de mieux qu’une petite vidéo démonstrative pour conclure ?

 

 

Perspectives d’évolutions:

  • gestion plus effective du temps et des priorités
  • réalisation du vrai lanceur à l’instar d’un prototype
  • réalisation d’un socle pour les volants et choix de moteurs plus puissants

Webographie:


Microscope à bille

 

 

 

 

 

 

Microscope à bille

 

 

 

 

Sommaire :

 

 

Introduction

Cahier des Charges

Ressources

Réalisation du Projet

Perspectives D’améliorations

Conclusion

Remerciements

 

 

 

 

Introduction

 

Lors de cette deuxième année en DUT GEII, je suis amené à réaliser un projet, celui-ci doit être en lien direct avec ma formation ( génie électrique et informatique industrielle ), pour mon cas, il s’agit du projet intitulé « Microscope à bille », ce projet rentre dans le cadre du module « études et réalisations » dont la notation dépend des efforts fournies (avancement du projet), ainsi que le rapport et la vidéo .

Pour mon projet, il m’est demandé d’utiliser une Raspberry Pi 3 mais également de faire une « Conception Assistée par Ordinateur » (CAO) du microscope. Afin de réaliser mon projet, qui consiste à acquérir des images et faire du traitement de donnée, j’utilise « Python » un langage de programmation intégré dans le Raspberry Pi 3.

 

 

Cahier des Charges

 

 

A quoi sert le projet et à qui il sert ?

  

Les différents fonctions et contraintes du projet :

 

 

 

 

Fonctions principales : Le projet doit posséder les bases d’une microscope traditionnelles, en terme d’acquisition d’image, zoom,  réglage de luminosité et travaille d’un échantillon.

 

Contrainte Informatique : J’utilise une Raspberry Pi afin de crée le microscope.  Au delà de ça, il faut une interface visuelle afin de rendre le projet plus intuitif. La prise en main et la maîtrise des différents langages sont nécessaires pour réaliser le projet.

 

Contrainte Conceptuelle : J’utilise Corel Draw afin de réaliser la conception assistée par ordinateur de ma microscope en obtenant en produit final, un appareil peu coûteux et simple d’accès.La prise en main et la maîtrise des notions d’optiques sont nécessaires pour réaliser le projet.

 

Contrainte de ressources : Le budget est limité à 100€.

 

 

Organisation du projet :

 

 

 

 

Ressources

 

 

PICAMERA :

Caméra permettant d’acquérir une image ou faire une vidéo. Dans mon cas, elle est utilisée en tant que lentille d’acquisition d’image. Elle est de très bonne qualité,  en effet elle possède une multitude d’application (réglage de contraste, résolution, qualité…) très facile d’accès.

 

 

 

RASPBERRY PI 3:

C’est un mini-ordinateur qui relie les différents module du microscope. Cette carte contrôle l’écran, les LEDS ainsi que la caméra à travers des langages de programmations notamment le python.

 

 

 

SENSEHAT :

C’est un module qui contient un ensemble de capteur (pression, ultrason, température…), personnellement j’utilise seulement la matrice de LED compatible avec Raspberry Pi pour des raisons d’accessibilité. Ces LEDS sont simples à programmer. Cependant, le flux lumineux qu’elles délivrent est irrégulier après expérience.

 

ECRAN LCD :

Ecran tactile «  7 pouces » permettant de visualiser les images acquises par le microscope.  Il est possible de travailler directement avec le microscope sans avoir besoin d’être à proximité d’un écran d’ordinateur grâce à une interface manipulée avec python.

 

 

BILLE :

C’est utilisé comme une lentille, de 1,92 millimètres de diamètre, qui permet d’agrandir 177 fois l’image de la camera, qui est placé entre la source de lumière et l’échantillon.  La seule problématique est la distance entre la focale et l’échantillon.

 

Réalisation du Projet

 

Programmation : 

Dans un premier temps, l’objectif consiste à acquérir une image à l’aide de la PiCamera. La maîtrise de linux et aussi python est nécessaire avant de débuter l’un est semblable à l’invite commande d’un PC et l’autre est un langage de programmation intégré dans le Raspberry PI. Pour capturer une image, il faut : télécharger la librairie appropriée, déclarée au tout début du programme python. On à ainsi accès aux différents fonctionnalités comme par exemple : le contraste de l’image, la résolution, obtenir une vidéo, image ….

Puis dans un second temps le but est de régler la luminosité délivrée par le sense hat par le biais de la matrice de LED, pour facilité l’observation de l’échantillon. Il faut également installer la librairie pour ce cas.

Ensuite il m’est demandé de mettre au point une interface permettant de manipuler le code de manière tactile via Tkinter. Et pour terminer, faire du traitement d’image avec OpenCv, le travaille ce fait sur les pixels de l’image, le but est d’obtenir un échantillon perceptible pour ensuite l’étudier, avec l’aide du détection de contours et de filtre. 

 

 

Test 1 : observation d’un échantillon de plume d’oiseau avec filtre.

 

 

 

Test 2 : observation d’un échantillon de plume d’oiseau sans filtre.

 

 

Conception :

Pour ce projet, il m’est demandé de faire une CAO de la microscope. Pour ce faire, certains critères doivent être traités en amont, tout d’abord la distance focale entre la bille et la lentille de caméra (quelques millimètres ), ensuite la distance entre l’échantillon et la source de lumière (proche de 2cm), prendre en compte la taille de la nappe (15 cm), un support pour projeter la lumière à un point précis, un support pour tenir l’échantillon et le tout relié au Raspberry pi. Pour la conception, le logiciel utilisé est « CorelDraw ». C’est une conception en 3D utilisant une machine  à découpe laser.

 

Perspectives D’améliorations

 

 

Afin que le projet puisse connaître de meilleur résultat, il est envisageable de travaillé sur la source d’éclairage, l’autotomie ainsi qu’un moyen de support, d’extension pour la Picamera. 

 

Source d’éclairage :  LED Blanche.

   

 

Extension Picamera : Raspberry Pi Camera HDMI Câble Extension

 

Autonomie : Batterie lithium 5 Volts.

 

 

 

Conclusion

 

 

Ce projet m’a permis de découvrir de nouvelles choses comme : la gestion d’un projet, le travail en autonomie, la démarche à suivre pour arriver au bout d’un projet. De plus, cela m’a permis d’approfondir mes connaissances en informatique, en langage python, l’univers de linux ainsi qu’à la conception d’une microscope. 

 

 

Remerciements

 

 

Merci au département GEII de l’IUT de Mulhouse pour le budget et l’apport de matériels.

Nos professeurs encadrants Mr Verrier et Mr Bazeille de m’avoir aidé pour ce projet.


Microscopie sans lentille

  

MICROSCOPE SANS LENTILLE

 

SOMMAIRE

 

INTRODUCTION

PROBLÉMATIQUES

STRATÉGIES

COMPOSANTS

CAO

PROGRAMMATION

VIDÉO

CONCLUSION

POUR ALLER PLUS LOIN…

REMERCIEMENTS

 

INTRODUCTION

 

Durant notre deuxième année de DUT Génie Electrique et Informatique Industrielle nous devions effectuer un projet d’étude et réalisation. Nous avons choisi de réaliser un microscope sans lentille à l’aide d’un Raspberry Pi 3. Pour mener à bien se projet nous étions encadrés par deux professeurs, Mr Verrier et Mr Bazeille et notre équipe était composée de la manière suivante :

  • Arthur Gasser – Chef de Projet
  • Quentin Dijoux – Responsable Programmation
  • Raphaël Jimenez – Responsable Conception Assistée par Ordinateur

Notre microscope devait impérativement être réalisé en utilisant un Raspberry Pi 3 et nous devions le créer à l’aide d’une Conception Assistée par Ordinateur (CAO). Il nous a donc tout d’abord fallut apprendre les bases de la programmation Linux, Unix et de l’univers Raspberry en général. Mais nous avons également dû approfondir certaines notions concernant le domaine de l’optique pour pouvoir dimensionner notre microscope de manière optimale. La capture de l’image zoomée se fait à l’aide d’une RaspiCam Noire V2 et peut être visualisée sur un écran LCD et l’éclairage se fait à l’aide d’un module de leds SenseHat.

Nous avons commencé ce projet le jeudi 30/11/2107 et nous l’avons achever le lundi 22/01/2108. La réalisation d’un microscope géré électroniquement nous intéressait tout particulièrement car les différents aspects de conception et de programmation étaient nouveaux pour nous. Mais ce projet faisait appel à d’autres notions intéressantes comme l’holographie par exemple.

 

PROBLÉMATIQUES

 

Comment programmer efficacement le microscope pour qu’il soit simple d’utilisation ?

Comment dimensionner rigoureusement la CAO pour que les zooms effectués par le microscope soient suffisamment conséquents et nets ?

Nous voyons ressortir ici les deux points principaux de notre projet : CAO et Programmation.

 

STRATÉGIES

 

Ce projet était assez conséquent tant au niveau de la charge de travail qu’au niveau de la difficulté. Nous avons donc relevé le challenge en donnant le meilleur de nous même ! Nos points forts étaient notre motivation et notre bonne répartition des rôles. Nous avons également essayé de communiquer régulièrement avec nos professeurs encadrants afin qu’ils soient tenus au courant des avancements de notre projet et pour qu’ils puissent nous conseiller au mieux.

Nous avons tout d’abord réalisé le cahier des charges fonctionnelles accompagné de différents diagrammes pour bien commencer le projet. Puis nous avons effectué les différentes recherches nécessaires afin de pouvoir démarrer la programmation de la caméra et des leds. Ensuite nous avons étudié un certains nombres de documents afin de pouvoir calculer la future résolution de notre microscope qui nous a permis de le dimensionner et nous avons rédigé les différents documents accompagnant notre projet tout au long de celui-ci. Plus notre projet avançait, plus il était complexe, il a donc fallut travailler en dehors des heures prévues pour les études et réalisations, lors de nos temps libres.

Nous vous invitions à télécharger le PDF suivant afin de visualiser nos différents diagrammes qui nous ont permis de démarrer le projet dans les meilleures conditions possibles (Bête à cornes, MindMap, Pieuvre, Ligne des temps).

Stratégies

 

COMPOSANTS

 

Notre microscope est constitué de plusieurs éléments, nous allons vous les présenter brièvement. Les caractéristiques électroniques de ces composants sont détaillées dans notre Cahier des charges techniques disponible en bas de page.

  • RASPBERRY PI 3 Modèle B

C’est le cœur de notre microscope. En effet cette carte contrôle notre écran, nos leds ainsi que notre caméra. L’entièreté de la programmation a été réalisé sur ce Raspberry et toutes les informations sont centralisées à l’intérieur de ce dernier.

  • ECRAN LCD

Cet écran tactile permet de visualiser les images récupérées à l’aide de notre microscope. Il rajoute énormément de confort car il est possible de travailler directement avec le microscope sans avoir besoin d’être à proximité d’un autre écran. Cependant, travailler sur un écran plus grand reste plus confortable sur le long terme.

  • RASPICAM NOIRE V2

Cette caméra nous permet de capturer nos images zoomées. Elle est de très bonne qualité mais dans le cadre de notre application, comme le nom de notre projet l’indique, nous avons été amené à retirer la lentille présente sur la caméra. Cela est indispensable pour pouvoir réaliser les zooms des images.

  • SENSEHAT

Cette petite carte contient un module leds compatible avec Raspberry, voilà pourquoi nous l’avons choisi pour réaliser l’éclairage dans notre microscope. Ces leds sont pratiques à utiliser et assez simples à programmer. Cependant, le flux lumineux qu’elles délivrent est assez faible. Il est possible d’augmenter la qualité de notre microscope avec des leds plus puissantes.

  • CARTE SD

Nous réalisons des captures ainsi que du traitement d’image, ces opérations sont assez lourdes niveau mémoire. Nous avons donc du ajouter une carte SD de 16go compatible avec Raspberry pour éviter tout problème et pour mener à bien notre projet.

  • ÉCHANTILLON

Enfin, comme dans tout microscope, il faut un échantillon à observer. Comme pour les microscope classique nous observons des échantillons présents sur de simples lames standards.

CAO

 

L’un des points principaux de notre projet était de réaliser une CAO (Conception Assistée par Ordinateur) pour créer notre microscope. Pour cela, nous avons utilisé le logiciel Tinkercad, qui était le plus pratique dans notre cas car c’est un logiciel en ligne, nous pouvions donc travailler chez nous et sur tous les PC de l’IUT (voici un lien vers le site Tinkercad).

Pour une question de praticité, nous avons décidé de réaliser notre microscope en plusieurs pièces pour faciliter le montage ainsi que la maintenance. Dans cette partie, nous allons vous présenter chacune des pièces en détail.

  • SOCLE

Commençons par la base de notre microscope. Ce socle a été conçu afin que la caméra et surtout le capteur soit au milieu du microscope. Il y a également un chemin de câble qui passe en dessus pour que la nappe de la caméra soit protégée et pour la connecter directement au Raspberry de manière efficace. Le Raspberry et l’écran sont donc placés sur la partie avant du socle (la plus grande) pour des questions de confort.

  • MURS/ÉCHANTILLON

Sur ce socle, vient la partie qui permettra d’accueillir l’échantillon. Cette pièce est constituée de 4 murs et sur deux de ces murs, il y a une fente permettant d’introduire l’échantillon dans le microscope à l’aide de la pièce que nous allons voir tout de suite.

  • SUPPORT/ÉCHANTILLON

On place l’échantillon sur cette pièce puis on l’introduit dans le microscope. Tout a été étudié pour que le support soit maintenu par les deux fentes vues précédemment. Cette pièce est de cette forme car l’échantillon ainsi que la lumière doivent arriver jusqu’au capteur située juste en dessous.

  • PROTECTION

Pour que notre écran et notre Raspberry soient protégés contre les chutes. Nous avons réalisé cette pièce permettant de les caler. Sur cette pièce nous avons également réalisé deux trous pour laisser passer les câbles provenant du SenseHat et de l’alimentation mais aussi pour brancher le clavier, la souris et un câble HDMI. Nous avons aussi placé le logo de l’IUT ainsi que nos noms sur le dessus de la pièce.

  • PINHOLE

Cette pièce est entièrement pleine. Mais en son centre, il y a le trou appelé « pinhole » permettant de laisser passer la lumière. Sa taille a été étudiée afin que le phénomène de diffraction soit respecté, nous verrons les détails des phénomènes physiques dans la dernière partie de ce document.

  • FOCALE

Afin que le flux de lumière soit plus conséquent, nous avons ajouté une focale pour concentrer la lumière en un seul point. Cette pièce est donc constituée d’un trou permettant de fixer parfaitement la focale au centre.

  • LEDS/TUYAU

Notre module de leds sera fixé sur cette pièce, nous avons percé un trou afin de laisser passer les câbles du SenseHat. Ces câbles passeront ensuite dans le tuyau et descendront jusqu’au Raspberry.

  • TOIT

Voici la dernière pièce de notre microscope. Il s’agit d’un cube permettant de refermé le montage. Sur cette pièce nous pouvons voir le nom de notre microscope « μSCO-Pi 3D » ainsi que notre logo.

La CAO était une étape très importante du projet, nous avons donc consacré beaucoup de temps pour la réaliser de la manière la plus précise, esthétique et ergonomique. Cependant, le rendu final présentait quelques erreurs de précision que nous avons tenté de corriger au mieux. Nous avons dû peindre notre microscope en noir pour empêcher la lumière extérieure de gêner notre acquisition. Nous avons utilisé l’imprimante 3D (résine) de l’IUT Lab, nous souhaitons donc remercier Mr De Sabbata pour son aide.

Nous vous invitions à télécharger notre Cahier des charges techniques (CDCT) en bas de page dans la rubrique « Pour aller plus loin… » afin de visualiser nos différentes pièces ainsi que le microscope fini sur Tinkercad et après impression.

 

PROGRAMMATION

 

La programmation de notre microscope est réalisée en Python 3. Avant ce projet, nous n’avions aucune connaissance en Python et en Linux, nous avons donc dû nous adapter et apprendre ces différents langages. Nous souhaitions que notre microscope puisse être utilisé par tout le monde, c’est pour cela que nous avons annoté chacun de nos programmes. Nous utilisons trois programmes principaux et nous allons détailler leur contenu.

  • ACQUISITION

La programmation de notre microscope est réalisée en Python 3. Avant ce projet, nous n’avions aucune connaissance en Python et en Linux, nous avons donc dû nous adapter et apprendre ces différents langages. Nous souhaitions que notre microscope puisse être utilisé par tout le monde, c’est pour cela que nous avons annoté chacun de nos programmes. Nous utilisons trois programmes principaux et nous allons détailler leur contenu.

  • RECONSTRUCTION

La capture étant réalisée, il faut maintenant améliorer le rendu de celle-ci. Pour cela veillez cliquer sur le bouton « Reconstruction 2D » afin de lancer le programme correspondant. Ce dernier va réaliser une mise au point numérique à l’aide d’un recalage de pixel. Pour cela, il faut utiliser plusieurs FFT (Fast Fourier Transformer). Ces différents termes peuvent paraître compliqués mais en visualisant la photo une fois reconstruite vous allez très vite comprendre son impact sur l’image que vous avez prise précédemment. Une fois la reconstruction terminée vous pouvez analyser votre image.

  • ANALYSE

Pour ouvrir ce programme il vous suffit d’appuyer sur le bouton correspondant. Une fois le programme lancé, vous pouvez réaliser un certains nombres d’actions :

  • Contouring
  • Zoom
  • Déplacement
  • Annotation
  • Sauvegarde

Pour accéder à ces différentes actions, il vous suffit de lire les instructions présentes sur votre écran.

Vous pouvez retrouver tous nos codes en téléchargement dans la rubrique « Pour aller plus loin… » en bas de page.

 

VIDÉO

 

Dans le cadre du projet nous avons du réaliser une vidéo résumant l’entièreté de celui-ci. Nous n’avons pas réalisé une vidéo classique, en effet, nous avons utilisé une macro sur PowerPoint afin de transformer ce dernier en vidéo full HD puis nous avons rajouté nos voix ainsi qu’une musique en fond. Cette vidéo est disponible juste ici, nous vous invitons à la visionner.

 

 

CONCLUSION

 

Malgré le manque de connaissance, nous nous sommes adaptés très rapidement à l’univers Raspberry. Nous avons réussi à créer un programme assez simple d’utilisation ainsi qu’un CAO précise, nous avons atteints nos objectifs. Nous sommes globalement très satisfaits du rendu final de notre microscope. Le projet était assez complexe mais nous avons redoublé d’effort pour le mener à bien. Nous arrivons à obtenir des images zoomées avec une résolution et une précision correctes. Nous aurions cependant pu avoir de meilleurs résultats avec une source de lumière plus adaptée à la situation et un pinhole plus petit (ce qui était difficilement réalisable). Et avec plus de temps, nous aurions aimé réaliser, en plus de la reconstruction 2D, une reconstruction 3D de nos images mais c’est encore un autre niveau de difficulté.

Mais notre microscope n’est pas encore dans son état final puisque Mr Verrier continuera à travailler sur celui-ci et l’utilisera lors de divers présentations ou événements.

 

POUR ALLER PLUS LOIN…

 

Afin que notre projet soit plus complet et plus détaillé, nous avons rédiger plusieurs documents. Si notre projet vous a intéressé, nous vous invitons à les télécharger. Les différents programmes que nous avons réalisé sont également en téléchargement.

  • Cahier des charges fonctionnelles

Indispensable au bon démarrage du projet, ce cahier des charges définit les différents cadres et objectifs de celui-ci. Il permet de partir dans la bonne direction et de vérifier si tous les membres de l’équipe ont la même vision des moyens à mettre en œuvre pour accomplir les objectifs.

CDCF

  • Cahier des charges techniques

Ce document récapitule les fonctions des composants que nous avons utilisé, la manière dont nous avons effectué notre CAO, les différents calculs de dimensionnement que nous avons du faire et aussi un résumé de la partie programmation.

CDCT

Interface Raspberry

Analyse Raspberry

Interface Moniteur

Analyse Moniteur

Reconstruction

  • Guide d’utilisation et d’installations

Ce guide vous permet de comprendre comment utiliser notre microscope étape par étape mais il vous explique également comment installé les divers logiciels que nous avons installé sur notre Raspberry.

Guide

  • Rapport de nos séances

Ce document permet de visualiser l’avancement de notre projet au fur et à mesure de nos séances de travail.

Rapport des séances

 

REMERCIEMENTS

 

Nos professeurs encadrants pour leurs aides et leurs conseils.

L’IUT ainsi que l’IUT LAB de Mulhouse pour le budget et l’apport de matériels.

 


Anneaux de photodiodes

Anneau photodiodes

 

LITZLER Cédric

ZUGMEYER Adrien

BARETTI Gaetan

 


Sommaire

 

1. Présentation du projet

2. Attributions des rôles

3. Câblage électrique & Réalisation du circuit imprimé

4. Programmation Arduino

5.Programmation Python(Spyder)

6. Serveur MQTT

7.Avancé du projet

8. Conclusion

9.Remerciements

 


1. Présentation du projet

Dans le cadre de notre projet de 2ème année en « Etudes et Réalisations », nous avons mes 2 camarades ainsi que moi-même été amenés à travailler ensemble sur le projet d’un anneau de photodiodes.

Le but de ce projet est de créer un système de mesure qui sera utilisé pour visualiser la direction de l’étirement d’un textile soumis à un test.

Le système sera composé d’une carte Arduino, d’un laser, d’un circuit électrique de forme circulaire, d’une alimentation et de photodiodes. Ce système sera placé au dessus du textile et protégé de la lumière par un tube ou une jupe. Le laser et les photodiodes pointeront en direction du textile et la lumière du laser sera plus ou moins réfléchie par le tissu vers les photodiodes placées sous la forme d’un cercle afin de connaitre l’intensité de l’étirement et la direction des fibres du textile. Ces mesures seront lues via un PC sous forme de tension .

Ci-dessous, voici un premier schéma montrant un peu à quoi va ressembler le résultat final de notre projet ainsi que 2 images de notre maquette actuelle. A cela, il faut encore y rajouter un manche ou un support permettant de fixer le matériel tel que la carte Arduino, les connexions des différents câbles électriques, la pile etc…

 


2. Attributions des rôles

 

LITZLER Cédric:

  • Programmation de la carte Arduino
  • Programmation Python
  • Câblage & conception du schéma électrique
  • Réalisation du câblage électrique de la plaquette finale
  • Rédaction du dossier texte

 

ZUGMEYER Adrien:

  • Etude de la partie électrique: Réalisation du Circuit-Imprimé & Conception du schéma électrique
  • Rédaction du dossier texte
  • Travail sur le support

 

BARETTI Gaetan:

  • Conception du Schéma électrique, Planification & création du serveur MQTT (abandoné)
  • Rédaction du dossier texte
  • Travail sur le support

 

 


3. Câblage électrique

Le projet prévoyait initialement 36 photodiodes mais après une étude plus détaillée de tous le système, nous somme passé à 8 photodiodes pour un soucis de complexité. La difficulté principale réside dans la présence du grand nombre de fils au final. Après s’être documenté sur internet et sur divers sites, j’ai pu dresser le schéma électrique qui permet la liaison des photodiodes avec la carte Arduino. Ce câblage comporte 8 résistances de 1MΩ, la carte Arduino MEGA, 8 photodiodes et beaucoup de fils électriques.

La masse est relié entre la résistance et la photodiode. La photodiode elle, est relié à l’autre entrée de la résistance et relie les entrées analogiques de A0 à A7.

Ci-dessous, le schéma électrique réalisé sur le logiciel kicad:

 

 

 

Réalisation du circuit imprimé:

A l’aide du schéma électrique réalisé sur le logiciel Kicad, nous avons pu nous en servir pour créer le circuit imprimé.

Adrien a donc dû se familiariser avec l’environnement de travail de Kicad ce qui n’a pas été chose aisée car c’est un logiciel qui n’est pas très intuitif. Kicad permet, à partir d’un schéma électrique, de créer un Circuit imprimé en associant les empreintes des composants avec leur noms. Voici le résultat obtenu après plusieurs heures de travail sur le logiciel de création:

 

 

 

 

 

 

 

                                                                                                    Voici a quoi ressemblera le circuit imprimé lorsqu’il sera fini

 

Suite à cela nous avons pu utiliser le laboratoire de Circuit imprimé pour découper le disque puis le percer pour accueillir les pattes des composants électronique, nous avons enfin, pu souder les composants à la carte.

 



4. Codage Arduino

Le codage de la carte Arduino est une étape très importante dans le projet afin de recevoir les valeurs des photodiodes. Après avoir réalisé de nombreuse recherches sur internet sur la façon de construire ce code, j’ai travaillé en plusieurs étapes.

Dans un premier temps j’ai commencé par essayer de piloter 1 seule photodiode puis 4, puis d’ajouter un bouton pour contrôler les acquisitions uniquement lors de son appui dessus. Finalement, j’ai pu supprimer ce bouton n’ayant plus de réel utilité puisque toutes les acquisitions se font maintenant via le logiciel Spyder.

A présent, le programme comporte les 8 photodiodes et fonctionne efficacement.

Le programme utilise la liaison série à 38400 bits/seconde.

 

Le principe général est le suivant:

Les photodiodes relèvent une valeur correspondant à une tension en fonction de la luminosité qu’elles perçoivent. Le programme doit pouvoir lire les valeurs du nombre d’acquisition et de la durée entre 2 acquisitions sur le port série. Ces valeurs saisies par l’utilisateur seront stockés dans des variables dans la mémoire ROM (voir explication de l’utilisation de la mémoire ROM en-dessous du code)

De plus, il doit également pouvoir envoyer les valeurs des photodiodes via le port série de façon à être récupérée grâce à une instruction bien précise sur le logiciel Spyder.

 

 

Le code arduino final:

 




 

Quelques explications importantes:

 

-On commence par déclarer les bibliothèques utilisées.

-On déclare dans un integer constant nommé numReading  la taille du tableau (Ici 6).         Objectif –> Lisser légèrement les valeurs en utilisant les 6 dernières valeurs présentes dans le tableau afin de ne pas avoir a traiter des signaux « parasites ».

-Utilisation de « EEPROM.read(0) » et « EEPROM.read(1) » dans le programme arduino car les variables sont généralement stockés dans un buffer et que les paramètres du nombre d’acquisition et du délai entre 2 acquisitions ne sont transmises qu’une seul fois par le port série. Ecrire ce résultat dans la ROM de la carte Arduino permet donc de préserver cette valeur.

-Ne pas oublier dans la fonction setup l’initiailisation de la communication serie à 38400 et l’initialisation du tableau.

-ReadIndex nous servira à évoluer de 0 à 6 pour lire chaque valeur du tableau.

-Total contient la somme de toutes les valeurs du tableau.

-Average sera la valeur moyenne du tableau (total / numReading).

 

Fonction principale loop():

-On retire de total la valeur actuellement indexée du tableau (afin de faire de la place pour la nouvelle).

-On vient stocker la valeur du potentiomètre dans l’index en cours du tableau.

-On ajoute la valeur au total.

-On augmente l’index de 1 afin de passage à la « case suivante » du tableau.

-Si l’index dépassee 6, alors on le remet à 0. Le tableau évolue de reading[0] à reading[6].

-On calcul la valeur moyenne du tableau reading[].

-On envoit la moyenne au moniteur série.

 

 

 


 

5. Programmation Python (Spyder)

 

Spyder est un environnement de développement pour Python qui intègre de nombreuses bibliothèques à usage scientifique tel que « Matpolib » que nous importons afin de pouvoir tracer notre graphique en forme de polygone.

 

Préparation:

Si le module du port série n’est pas installé, vous obtiendrez ce message d’erreur: “No module named serial”. Cela est dû au fait que le port série n’est pas directement inclut avec python

Pour ce faire il a fallu l’installer  à l’aide de la ligne de commande « pip install pyserial » dans Anaconda Prompt*:

 

*J’ai installé Anaconda Navigator qui regroupe en quelque sorte tous les fichier dont a besoin Spyder pour fonctionner

 

Afin d’accélérer la vitesse de transmission du port série, il a fallu modifier le réglage de la vitesse de transmission du port associé (dans notre cas COM6). Réglé de manière générale à 9600, je l’ai accéléré à 38400!

Il est également important de ne pas oublier de renseigner ce paramètre dans le code Arduino et Python!

 

 

 

 

 

 

 

Code Python utilisé dans le projet:



 

J’ai mis des commentaires un peu partout dans le code pour ne pas s’y perdre et comprendre l’application générale du programme. Sachez qu’une fois les données du port série récupérées, il est possible de créer plus ou moins n’importe quelle interface graphique à l’aide de code trouvable sur internet. Dans notre cas, il s’agit du diagramme de Kiviat.

 

 

Démonstration du fonctionnement du programme:

 

Lorsque nous lançons le logiciel Spyder, celui-ci affichera dans la console la chose suivante:

 

Nous pouvons ainsi lancer l’exécution de fichier depuis le bandeau général du logiciel (voir icône au centre du cercle rouge)

 

Il faudra ensuite renseigner les bons paramètres:

  • « start » : lance le processus d’acquisition
  • le nombre d’image crée avant la temporisation
  • L’intervalle de temps en secondes entre 2 acquisitions

Remarque:

La saisie des données (nombre d’acquisition et intervalle de temps) est limité à une valeur de 255. Cette valeur limite est du au fait qu’elle est est envoyé sous forme de caractère. Lors de son envoi sur le port série, elle est encodé sous forme de table Ascii qui contient 255 valeurs.

 

 

Après avoir renseigné les paramètres nécessaire, le programme en Python va générer un graphique correspondant aux différentes valeurs des photodiodes relevées.

Nous affichons le numéro de l’image (ici 0 puis 1 puis 24)pour connaitre l’avancée de l’acquisition ainsi que les valeurs mesurées par les photodiodes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lorsque le bon nombre d’acquisition est atteint, la temporisation dure le nombre de seconde indiqués (ici 10s) puis recommence à effectuer les acquisitions et ainsi de suite.

 

 

Pour arrêter la console, il suffit d’appuyer sur le bouton suivant:

 

 

Une fois la console arrêté, il faut redémarrer le noyau puis relancer l’exécution du fichier.

 

Si nous ne redémarrons pas le noyau un message d’erreur viendra. Il indiquera un problème au niveau du port série.

En effet, le fait d’interrompre la console, le port série reste en quelque sorte ouvert et ne se referme pas. Cependant il est difficile de le refermer efficacement puisque la seule solution serait d’écrire quelque chose de bien définit dans la console qui exécuterait ensuite une instruction fermant le port série; seulement le défilement des images générés rend impossible la saisie (où alors uniquement lorsque la pause entre 2 acquisitions se réalise). J’ai alors opté pour l’interruption et le redémarrage du noyau. Cette solution ne prend pas beaucoup plus de temps, et n’ayant pas de contrainte défini dans le cahier des charges, cette méthode peut-être validé!

 

Une image en extension png  identique à celle présente dans la console est aussi crée dans le dossier ou se trouve le fichier Python et ceux à chaque acquisition. Cependant, seul la dernière image (celle avant la temporisation) n’est vraiment accessible puisque les autres, dès que crées, sont aussitôt écrasés par celle d’une nouvelle acquisition.

 


 

5. Serveur MQTT

L’Intérêt de créer un serveur MQTT était de pouvoir bénéficier d’une interface à distance qui aurai permis de lancer les acquisitions à distance et récupérer les valeurs sans devoir être connecté a un PC. Pour cela Gaetan a créé un serveur local sur son PC via le broker Mosquitto. Nous avons réussi à obtenir des résultats en interconnectant deux PC avec un câble ethernet: nous avons réussi à nous connecter à un topic et pu lire et publier sur celui-ci via l’interface de commande Windows.

Voici l’initialisation du serveur sur le premier PC

 

 

On peut ensuite publier sur un topic de test via un second PC pour vérifier que le serveur fonctionne

 

 

Un souscripteur au topic va pouvoir lire le message envoyé depuis le second PC

Il faut maintenant pouvoir connecté notre Arduino à ce serveur MQTT.

Pour cela on va utiliser un shield ethernet pour le connecté sur le même réseau local que le serveur.

On doit alors ajouté les bibliothèque Arduino liés au protocole MQTT pour la communication entre l’Arduino et le serveur ainsi qu’une bibliothèque ethernet pour interagir avec le shield.

Ci dessous le code permettant à l’Arduino de se connecter au serveur MQTT et souscrire à un topic :

Nous avons malheureusement été contraint d’abodonner le serveur MQTT à cause d’un manque de matériel, nous n’avions qu’un shield ethernet pour l’Arduino alors que nous avions besoin d’un shield Wi-Fi ( rupture de stock depuis plusieurs mois ) qui nous aurai permis de nous connecter à distance au réseau local. Dans un souci de respect des délais Gaetan a décidé de travailler sur le support.

 


6. Support

Dans un premier temps nous avons créé la partie principale du support qui va maintenir le laser et diriger le faisceau vers le bas. Il est constitué d’un tube ainsi que d’un capuchon réalisé à la découpe laser.

 

 

 

 

 

 

 

 

 

On a ensuite constitué une plateforme pour positionner l’Arduino, le tout est surélevé à l’aide de baguette en bois pour que le tissu placer en dessous puisse réfléchir la lumière du laser sur l’anneau de photodiode.

On place alors une « jupe » sur la structure afin d’isoler l’anneau de photodiode de toute lumière exterieur qui risque de perturber les résultats.

L’ensemble de la structure à été réalisé à la découpe laser.

Le support est léger donc facilement déplaçable au dessus d’un tissu cependant il est très fragile.

 


7. Avancé du projet

Le schéma électrique ainsi que son montage fonctionne correctement.

La partie concernant la programmation Arduino & Python à été entièrement réalisé.

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données et de « sauver » le rendu final du projet.

L’idée du serveur MQTT a été abandonné.

Le circuit imprimé à été réalisé mais ne fonctionne pas.

 

8. Conclusion

 

La partie concernant la programmation Arduino & Python à été entièrement réalisé et son principe fonctionne correctement. Cependant, il peut encore être perfectible en simplifiant peut-être encore les codes et améliorant encore certaines choses (ex:vérifier les saisies rentrées par les utilisateurs, simplifier l’arrêt et le redémarrage des acquisitions)

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données. J’ai pu approfondir mes connaissances en language c++ et découvrir le langage python.

Devant réaliser des tâches qui ne me concernait pas à l’origine, j’aurai pu perfectionner les codes que j’ai écris avec ce temps de perdu.

Grace à ce projet nous avons pu apprendre à utiliser de nouveaux logiciels,  de nouveaux langages de programmation, nous avons pu rencontrer de nouveaux matériaux (photodiodes).  Mais il faut avant tout savoir faire preuve d’esprit critique  savoir ce qui a fonctionné c’est bien, savoir ce qui n’a pas marché et pourquoi c’est mieux.

 

Nous avons accumulé beaucoup de retard ce qui nous a fait perdre toute notre marge d’erreur, nous avons accumulé du retard pour différentes raisons,  certains membres du groupe ont manqué d’organisation durant la durée du projet et ainsi empêché la finalisation du projet, il y a aussi eu un manque de communication dans l’équipe.

Il faut donc garder à l’esprit les erreurs que l’on a commises lors de ce projet afin de ne plus les reproduire dans le futur .

 


9. Remerciement

Nous souhaitons tous les 3 remercier les professeurs pour les aides, les explications et les conseils qu’ils nous ont fournis. Nous souhaitons également Christophe De Sabbata pour sa patience et son aide.


Banc d’acquisition pour un système de vision

BANC DE VISION


Contrôle visuel de pièces

 

Notre Groupe :

FREUDENREICH Theo – BENSCH Dylan – MEYER Virgile


Un contrôle métrologique n’est pas toujours nécessaire afin de vérifier qu’une pièce soit conforme. Il est également possible de réaliser un contrôle visuel, à l’aide d’une caméra industrielle permettant de faire des prises de vue rapides, qui seront traitées par un logiciel. Notre projet s’inscrit dans le contrôle de pièces brutes de fonderie, un tel contrôle visuel est donc suffisant.

Nous réaliserons le banc sur lequel sera fixé une caméra. Ce banc devra pouvoir tourner autour de la pièce en question pour prendre différents angles de vue et contrôler la pièce.


Sommaire :

  1. Cahier des charges
  2. Solution retenue
  3. Conception
  4. Réalisation et montage du banc
  5. Motorisation de l’arc

1.Cahier des charges

Expression du besoin:

Le Banc de vision est destiné à un industriel. Il permet de prendre différentes prises de vues d’une pièce, sans intervention humaine,  à l’aide d’une caméra.

 

 

 

 

 

 

 

 

Diagramme des intéracteurs : 

 

Cahier des charges : 

Il présente succinctement les différents critères à respecter lors de la fabrication du banc :

2.Solution retenue : 

 

  • La caméra est fixée sur le chariot, qui permet son déplacement sur l’arc
  • L’arc, relié à un axe et un moteur pas à pas, va permettre de tourner autour de la pièce
  • La bille sous l’arc permet de diminuer la charge appliquée sur l’axe
  • Le bâti réalisé en profilés Bosch, permet de supporter l’ensemble.

 

 

 

 

 

 

 

3.Conception

Vue d’ensemble:

Plans Axe:

Plan Arc:

 

Plan chariot:

Vue éclatée du chariot :

Plan :

4.Réalisation et montage du banc

A l’exception des éléments standards liés aux profilés Bosch (équerres, cubes de liaison) et la poulie fixée sur l’axe, nous avons réalisés les pièces à l’atelier du département GMP.

Usinage de l’axe: pièce la plus complexe car elle comprend des rainures et perçages difficilement réalisable avec des moyens dit conventionnels. Nous avons donc réalisé cette pièce sur le tour 6 axes DMG Alpha 500. Pour cela nous avons tout d’abord utilisé le logiciel de FAO Esprit.

 

C’était une partie extrêmement enrichissante dans notre projet, nous avons exploré les nombreuses possibilités qu’offre le logiciel Esprit et les machines d’usinage 6 axe. En effet nous avons utilisés la broche de reprise mais aussi des outils tournants radiaux et axiaux et toutes les procédures que cela implique.

Découpage des plaques et de l’arc: De nombreux composants de notre projet, sont issus de découpe dans des plaques d’aluminium, ces pièces ont étés découpées par jet d’eau. cette opération à été réalisée par M. Senn, car pour des raisons de sécurité la découpe jet d’eau n’est pas accessible en ce moment.

Montage : Montage de la transmission entre le moteur et l’axe :

Montage du chariot sur l’arc : Le taraudage M10 n’a pas pu être réaliser, une vis et un écrou maintiennent l’ensemble :

L’assemblage finale sur le bâti : Seul le taraudage afin de pouvoir assembler la bille de maintient en bas de l’arc n’a pas été réalisé, la bille n’est donc pas en place, il en résulte une flexion importante du bâti, ainsi qu’un effort important au niveau de l’axe que rend la rotation difficile.

5.Motorisation de l’arc

 

L’arc est motorisé à l’aide d’un moteur pas à pas. Il nous permet de ne faire qu’un certain angle avec l’arc, lorsque l’ordre en est donné.

Le moteur doit être relié à une carte de puissance, qui permet de l’alimenter, la arduino ne pouvant pas le faire elle même.

Nous avons décidé de diviser le tour par 45° afin d’offrir 8 points de vue différents.

Calcul du nombre pas nécessaires:

Le moteur pas à pas réalise 200 pas par tour. Soit 1.8° par pas. Comme l’on réalise une prise de vue tous les 45°, il faut faire 25 pas.

Le rapport de réduction entre les deux roues étant de 11/72, il faut donner une consigne de 25/0.1528=163.6 pas.

Le logiciel arduino contient une bibliothèque « Stepper » qui permet de contrôler directement les moteurs pas à pas, voici le programme réalisé :

  • Pour que le moteur tourne il faut que le bouton soit à 0L. En effet, le contact est tout le temps fermé, sauf lors de l’appuie sur le bouton où il va s’ouvrir.

Schéma du câblage :

6.Conclusion

Même si nous ne sommes pas arrivé au terme de notre Projet, celui-ci nous a permis de mettre en pratique un grand nombre des compétences et savoirs étudiés en DUT GMP. Ceci au travers de phases de conception, recherche de solution, de fournisseur et de réalisation. Nous avons utilisé une grande gamme d’outils technologiques, logiciels comme matériels.


Supervision d’un panneau solaire

Les élèves ayant réalisé le projet :

  • Léo GOUZOUAZI étudiant GEII
  • Nikola ILIC étudiant GEII

Sommaire

  1. Présentation du Projet
  2. Analyse fonctionnelle
  3. Matériel
  4. Réalisation
  5. Avancée du projet
  6. Conclusion

Introduction

Le but du projet « Supervision d’un panneau solaire » est d’exercer un contrôle ou une vérification sur l’activité du panneau solaire situé au sein de l’IUT de Mulhouse, et ces informations seront stockées dans un tableur. Tout cela est rendu possible à l’aide de capteurs de courant, d’humidité, de température, de lumière, d’une Arduino Yun et de différents calculs réalisés à l’aide des valeurs renvoyées par les capteurs.

Ces valeurs étant constamment en évolution et n’étant pas fournises par le constructeur, nous proposons ainsi aux personnes voulant les exploiter une façon de s’en servir pour leurs études personnelles, les données étant récupérables tout les soirs.


Analyse fonctionnelle

Cahier des Charges Fonctionnelles (CdCF) :

Exercer un contrôle de l’activité du panneau solaire situé à l’IUT de Mulhouse pour laisser libre service de ces informations à Mme.Ihssane Chtouki et à ses recherches :

  • Pouvoir récupérer, stocker et utiliser les donnés relatives au panneau solaire à distance.
  • Renvoyer toutes les valeurs des capteurs toutes les minutes entre 6h du matin et 22h.
  • Possibilité de mettre le système de mesure à l’extérieur.
  • Toutes les valeurs doivent être récupérées sous forme de tableau.

La réalisation complète du projet serra réalisée par les étudiants du département Génie Électrique et Informatique Industrielle.

 

Expression du besoin (bête à corne) :


Matériel

Description du matériel :

-La carte :

  • Une carte Arduino Yun :

 

La carte Arduino Yun est une carte Arduino à laquelle a été rajouté un processeur qui fonctionne sous Linux Linino, cette carte possède une connectivité Ethernet, WiFi, une mémoire RAM ainsi qu’une mémoire flash (dont une partie est occupée par la distribution Linux) et un lecteur de carte micro-SD. Pour notre projet nous avons choisi cette carte afin de pouvoir exploiter sa fonctionnalité Ethernet et mirco-SD.

-Les Capteurs :

  • Un capteur de température et d’humidité : Le DHT 22

Le DHT 22 est un capteur de température et d’humidité très précis, il peut mesurer une humidité qui varie entre 0 et 100% avec une précision de ± 2% et pour ce qui est des mesures de température, elle peuvent aller de -40 a +80°C  avec une précision de ± 0.5°C. Cette précision explique pourquoi nous avons fait le choix de ce capteur.

  • Un capteur de luminosité : Le TSL2591

Le TSL2591 est un capteur de luminosité il permet de mesurer une intensité lumineuse qui varie de 188 µLux à 88000 Lux. Cette information nous est nécessaire car grâce elle nous pouvons déterminer la production du panneau solaire en W/m².

Il faut également savoir que ce capteur est un capteur fonctionnant sous I²C. Le bus I²C permet de faire communiquer entre eux des composants électroniques grâce à trois fils : un signal de données (SDA), un signal d’horloge (SCL), et un signal de référence électrique (masse). Cette particularité nous obligera donc a utilisé les Pins 2 et 3 de l’arduino (la 2 pour le SDA et la 3 pour le SCL).

Pour tout savoir sur le protocole I2C nous vous invitons à vous rendre sur ce site.

  • Capteur de courant linéaire à effet hall : Le MR003-006.2

Ce capteur à effet hall nous permet de mesurer un courant de ±5A

Mais qu’est-ce que l’effet hall? Tout courant électrique traversant un champ magnétique continu B subit une force électromagnétique dont le sens est donné par la règle des trois doigts (force Laplace). Les trajectoires des charges du courant électriques sont donc déviées en présence de B. Il apparaît donc une d.d.p. (différence de potentiel) sur deux bornes du capteur, dite Tension de Hall. Pour savoir exactement comment fonctionne notre capteur nous vous invitons à consulter sa Datasheet ici.

 


Réalisation

Synoptique

 

Configuration de l’Arduino Yun et de la carte SD

La carte Arduino Yun peut être utiliser comme serveur, pour cela il suffit de créer un répertoire « /arduino/www/ » sur le carte SD, tout les fichier présent dans le répertoire « www » serons accessible en tapant l’adresse « http://10.92.11.25/sd/ » (adresse IP de notre carte) dans n’importe quel navigateur web. Pour cela nous avons créer les dossier directement sur la carte SD avec un ordinateur.

 

Code

Le Code complet est disponible en cliquant ici.

Configuration du TSL2591 : void configureSensor(void)

Le TSL2591 est paramétrable en fonction des conditions d’utilisation. Cette configuration ce fait au début dans une fonction appeler configureSensor(). Le capteur étant à l’extérieur, il est soumis au rayon du soleil et donc à une lumière assez forte, nous l’avons donc configurer pour qu’il ne soit pas trop sensible.

 Initialisation : void setup()

Dans le setup nous allons démarré la liaison entre les deux processeurs grâce à la fonction Bridge.begin(). La fonction FileSystem.begin() nous permet de communiquer avec Linino. La fonction dht.begin() permet de communiquer avec le capteur DHT22.

 

Récupération de la date et l’heure : String getTimeStamp() et String getDateStamp()

Les deux fonctions fonctionne exactement de la même façon, elle vont tout simplement récupérer l’heure et la date du système d’exploitation Linino.

Ecriture dans un fichier .csv : void loop()

Les données des capteurs doivent être écrit dans un fichier csv. Ce format permet de structurer du texte dans un tableau. Le principe est simple chaque ligne du texte correspond à une ligne dans le tableau. Pour créer des colonnes, il suffit de séparer le texte par un un point virgule. Ce Format est compatible avec Microsoft Excel.

Exemple :

 

Dans notre cas nous voulons un tableau par jour, et connaitre le température, l’humidité et l’irradiance toute les minutes entre 6h et 22h.

Dans un premier temps nous allons récupérer l’heure grâce à la fonction getTimeStamp(). Quand il est 6h nous allons créer le fichier grâce à la fonction FileSystem.open(). Nous devons indiquer le chemin ou le fichier doit être créer. Nous avons décidés d’utiliser la date comme nom du fichier mais nous devons modifier les slashs par des underscores. Nous récupérons la date grace à la fonction String getDateStamp() qui nous renvois une chaîne de caractères, pour faire modifier les slashs par des underscores nous devons concaténer la chaîne de caractères dans un tableau grâce à la fonction DateStr.toCharArray(). La structure de la fonction FileSystem.open() est FileSystem.open(const char*, int), donc nous devons concaténer CheminConst dans un tableau. Puisque le fichier n’existe pas encore, la fonction va le créer.

Dans un second temps nous allons écrire les mesures des capteurs dans le fichier toute les minutes jusqu’à 22h. Pour cela nous allons utiliser une boucle while et un compteur. Dans cette boucle nous récupérons les données des capteurs dans des variables indépendante. Pour acquérir les valeurs des capteurs nous utilisons les fonctions disponible dans la librairie proposé par le fabriquant. Puis nous créer une seule chaîne de caractères dataString.


Avancée du projet

Lors de nos première séances projet, nous avions un projet totalement différent, nous avions pour objectif de mettre en place un pilotage à distance du chauffage des salles du bâtiment A. Pour ce faire nous voulions nous baser sur les emplois du temps disponibles sur le site de l’UHA dans la rubrique salles GEII et ainsi optimiser l’utilisation du chauffage en fonction de l’utilisation des salles. Or après avoir réalisé une étude approfondie des besoins et avoir étudié plus en détails la façon dont sont codés les emplois du temps, nous avons appris que ce projet ne serrait pas réalisable car le système de chauffage de l’IUT était centralisé. Nous voila arrivé à la fin de la 3ème séance. Il nous faut donc un nouveau projet. Après concertation avec M.Steger nous avons pu dès lors trouver notre nouveau projet : Supervision d’un panneau solaire.

Dès ce moment nous avons été orientés vers l’idée de la création d’un serveur MQTT sa réalisation nous a demandé un grand nombre d’heures qui n’ont au final aboutie à rien car nous avons abandonné la réalisation de ce serveur lui préférant une page internet.

Ayant déjà la carte Arduino Yun nous avons pu réaliser nos codes pour les capteurs choisis, par chance, l’IUT disposait déjà d’un capteur DHT11 utilisant les mêmes bibliothèques que le DHT22 nous avons donc pu tester ce premier code. Après commande et réception des différents capteurs tout c’est très vite enchainé, les codes ayant été écrits en amont ont pu directement être testés avec succès.

A cette date la partie codage est finie, le seul aspect non abordé du projet est la possibilité de positionner le système de mesure à l’extérieur.


Conclusion

Nous avons pu, lors de ce projet nous servir des connaissances acquises lors de nos études, et les mettre à profit dans un but précis. Nous avons également pu découvrir ce qu’est la gestion d’un projet, faire le choix des éléments les plus adaptés, communiquer et travailler en équipe dans un but précis, faire face à des difficultés mais également gérer les délais. Nous avons pris du retard dans notre projet pour différentes raisons, tel que le délais de la réception des capteurs (que nous avons pu en partie contourner en écrivant les codes sans pouvoir les tester) mais également lors de la tentative de création d’un serveur MQTT qui au final n’a pas été créé ou bien lorsque nous avons passé 3 séances à travailler sur un projet non réalisable. Ces erreurs sont donc à garder en mémoire et à ne plus reproduire dans nos projets futurs.


Remerciements

Nous tenons à remercier M. De Sabbata pour sa patience, son aide et ses conseils pour les soudures qui ont du être réalisées sur les différents capteurs ainsi que pour le prêt d’une carte Arduino Yun sans laquelle ce projet n’aurait pas pu se réaliser.


Course en cours

Projet « Course en Cours » :

 


L’équipe ayant réalisée le projet :

Antoine KIENTZ (GMP)

Théo RIGHINI (GMP)

Nicolas LE FOLL (GEII)

Titouan RIVIERE (GEII)

 

 



Sommaire

I. Introduction

           II. Analyse fonctionnelle

           III. Voiture de Course

         IV. Projet d’innovation

        V. Avancé du projet 

 

 


 Introduction : 

Notre projet se déroule dans le cadre de « Course en Cours », c’est un concours durant lequel plusieurs équipes composées de 4 à 6 étudiants doivent durant une année scolaire, développer une voiture de course miniature, mais également créer un stand, développer un projet d’innovation et préparer une soutenance.

Course en Cours est un dispositif pédagogique original, centré sur les Sciences et la Technologie. Lors de ce concours, les participants montent leur écurie en utilisant les connaissances théoriques obtenues lors des enseignements dispensés dans leurs formations.

Nous avons donc à notre disposition tous les moyens de production et de fabrication du département GMP de l’IUT  de Mulhouse, ainsi qu’un accès à l’IUT Lab et à aux installations du département SGM.

La première étape était d’organiser l’équipe suivant le règlement du concours. Il a fallu définir différent poste :

  • Chef d’équipe : Nicolas LE FOLL
  • Ingénieur conception : Antoine KIENTZ
  • Ingénieurs fabrication : Antoine KIENTZ, Théo RIGHINI
  • Responsables essais : Titouan RIVIERE, Nicolas LEFOLL
  • Responsable style/design : Nicolas LE FOLL, Antoine KIENTZ
  • Responsable communication/sponsoring : Titouan RIVIERE, Théo RIGHINI

La première partie de ce projet concerne la création d’une voiture de course miniature (châssis, coque, train avant, etc…). Le moteur de la voiture est fourni par l’organisation du concours.

Les épreuves auxquelles nous allons participer sont les suivantes :

  • Course de vitesse
  • Arrêt au stand
  • Temps de réaction
  • Développement sur Catia (logiciel de CAO)

La première partie, réalisée par les élèves de GMP, concerne la création d’une voiture (châssis, train avant, roues, coque) en deux exemplaires, le moteur et la transmission étant fournie par l’organisation. Cette partie permettra à l’équipe de participer aux différentes courses. Antoine, élève en GMP, sera le membre de l’équipe qui participera à l’épreuve de CAO sur Catia.

Cette première partie sera réalisée par les élèves de GMP Antoine KIENTZ et Théo RIGHINI.

La seconde partie est un projet d’innovation qui s’inscrit directement dans le sujet du concours, il s’agit ici de développer/créer une application de « l’intelligence numérique » sous la forme d’un objet programmé répondant à la problématique de course en cours mettant en œuvre des capteurs , actionneurs et un traitement algorithmique de l’information.

Cette seconde partie quand à elle, est réalisée par Titouan RIVIERE et Nicolas LE FOLL, élèves de GEII.

 


 Voiture de Course :

  1. Conception du véhicule

La phase de conception a été la partie la plus longue à réaliser. En effet, celle-ci nous a demandée beaucoup de temps de réflexion, et de mises en communs des idées, avant d’arriver à des solutions idéales et réalisables.

Nous nous sommes donc réunis devant un tableau, et avons exposés diverses solutions qui nous semblants intéressantes. Ensuite, nous avons évalués les points forts et les points faibles de chaque solution, pour décider de la plus idéale.

  1. Phase de fabrication et de montage

La phase de fabrication a été séparée en plusieurs parties.

Le châssis

Le châssis a été produit à l’aide d’une imprimante 3D, avec une matière appelée PLA. Cette imprimante est une SIGMAX BCN3D, disposant d’un plateau format A3. Elle est équipée d’un système de double extrusion indépendante, permettant des impressions simultanées, en mode miroir (symétrie) ou duplication.

Au fil du temps, notre solution a souvent évoluée du fait de nouvelles contraintes inattendues ou simplement afin de simplifier l’ensemble. Nous sommes passés par trois principaux designs de châssis, dont deux qui ont été réalisés.

Voici les trois versions par lesquelles nous sommes passés :

Châssis V1 :

Cette version n’a pas abouti, elle était restée au stade de concept. Nous l’avons conçue selon nos premières idées. La forme globale du châssis n’a pas été beaucoup modifiée.

Nous avions imaginé des rebords chanfreinés afin d’y caler la carrosserie, cependant cela n’était pas concluant. Nous n’avions pas encore imaginé la fixation de la carrosserie, du moteur et de la batterie, ainsi que tout l’ensemble train avant.

Châssis V2 :

 

Sur cette deuxième version, nous étions premièrement partis sur la mise en place de trois plots de maintien et mise en position de la carrosserie (deux latéraux, un à l’avant) :

 

Nous avons finalement opté pour une méthode plus simple qui sera expliqué lors de la présentation du châssis V3.

Les points de fixation de ce châssis sont les suivants :

 

Pour la batterie, la solution retenue  est une bande de fixation dite « scratch » qui entoure la batterie, étant donné que le bloc moteur/batterie, la châssis et la coque doivent être démontable en moins de deux minutes (imposé par l’organisation). La bande permet un maintien réglable et  un démontage rapide. Nous avons donc créé une encoche dans le châssis afin de permettre le passage du scratch.

 

 

Pour le moteur, nous avons mis en place deux bossages percés épousant la forme prévue à cet effet déjà présente sur le bloc moteur. Lors du montage, nous utiliserons un système de fixation vis/rondelle/écrou.

 

Châssis V3 : 

Pour cette troisième et dernière version du châssis, nous avons apporté plusieurs modifications majeures.

Premièrement, nous avons ajouté une deuxième encoche pour la fixation de la batterie (logement du scratch) afin d’assurer un maintien en position optimal. Nous avons également agrandi les encoches car l’imprimante 3D plaçait un matériau de  support dans ceux-ci,  qui était difficile à enlever en post-impression, ce qui a résulté d’une détérioration du logement.

Nous avons mis en place une rainure dans le « mur » qui guide la batterie, directement en sortie du moteur. Cette modification a été réalisé car le câble qui relie la batterie au moteur est plus court que sur les mesures réalisé sur les plans CATIA fournis par l’organisation. Par conséquent, il est impossible de passer  le câble sous la batterie. Nous l’avons donc passé par le côté. De plus, nous avons placé un arrêt au bout de la batterie afin de l’arrêter en translation en direction du train avant.

 

 

Au niveau des points de fixation de la coque, nous avons réalisé quatre trous répartis de manière égale sur le châssis, dans lesquels nous allons implanter quatre tiges métalliques de hauteur supérieure à la coque. Une fois la coque posée sur le châssis, nous placerons une goupille pour pouvoir arrêter la coque en translation et l’empêcher de se déloger.

Il a également fallu prévoir le passage de fil guide de la piste Course en Cours sur tout le long du véhicule. Nous avons donc créé un morceau rapporté que nous plaçons dans un logement sous le châssis.

 

Dernièrement, nous avons déduit que le train avant devait être réglable. Étant donné que la voiture n’est pas dirigeable, nous ne pouvons pas nous permettre d’avoir un défaut de trajectoire. Il faut qu’elle ait un mouvement rectiligne uniforme. C’est pourquoi nous avons inclus deux trous oblong au niveau du train avant afin d’assurer la fixation de l’ensemble fusée (guidage de l’axe) ainsi que son réglage.

 

Voici un comparatif en photos du châssis V2 et V3 :

 

Vidéo de l’impression du châssis :

 

La fusée

La fusée est le nom donné à l’ensemble fixé sur le châssis ayant pour fonction principale de guider l’axe avant en rotation.

Nous avons opté pour une réalisation en usinage conventionnel d’un ensemble composé de deux pièces. Nous avons choisis de réaliser ces pièces en usinage dans un brut d’aluminium car ces pièces devraient disposer d’alésages (H7) pour accueillir des bagues en bronze, afin de réaliser un guidage parfait de l’axe. Ces pièces apportent également de la rigidité au véhicule.

Axe avant :

L’axe du train avant a été usiné à l’aide d’un petit tour conventionnel. Cette étape a été minutieuse car il fallait par moment charioter l’axe sur 30mm en réalisant un diamètre 3mm. La tige était donc fortement soumise à la flexion. Il a fallu être précis lors des phases d’usinages et faire attention à l’usure des plaquettes carbures car l’outil chauffait beaucoup.

 

L’axe est une pièce de révolution disposant de trois diamètres différents :

  • Diamètre 6mm : c’est le diamètre non fonctionnel de l’axe, il est présent au centre de la fusée et n’est soumis à aucune contrainte particulière.
  • Diamètre 4mm : c’est le diamètre qui est monté glissant dans les bagues en bronze H7, la rotation optimale repose sur ce diamètre. Afin d’éviter quelconque frottement entre la roue et la fusée, ce diamètre dépasse d’1mm de la fusée et fait donc office de butée pour la roue.
  • Diamètre 3mm : c’est le diamètre aux extrémités de l’axe, il est fileté en M3x35 (mise en place d’un écrou au bout) et c’est lui qui accueille les roues.

Les roues :

Les roues ont été réalisées en impression 3D. Elles sont composée d’une ou plusieurs jantes (cela dépend du train avant ou arrière) et d’une bande roulante (polyuréthane) faisait office de pneumatique.

 

La jante arrière est décomposée en deux parties. La première partie qui contient le trou diamètre 3mm de passage de l’axe, et la deuxième partie contenant un carré de 4.5×4.5mm, carré présent sur l’axe moteur et ayant pour but d’entraîner les roues arrières.

Ces deux parties s’emboîtent l’une dans l’autre et englobe la bande roulante. La bande roulante est adaptée à cette jante et réalisée spécialement selon ses dimensions.

 

Les roues avant fonctionnent sur un principe similaire. Elles sont composées d’une jante disposant d’un trou diamètre 3mm de passage de l’axe, et d’une bande roulante également réalisée sur mesures.

 

La coque :

Nous voulions cette coque avec une allure aérodynamique, style supercar futuriste. L’esquisse a été pensée comme le reste du véhicule, chacun a donné son avis et cela a abouti à des croquis.

Une fois l’alllure principale du véhicule trouvée, nous avons réalisé sa conception sur CatiaV5. Nous nous sommes alors tournés vers le département SGM afin de leur demander des conseils sur les techniques de thermo-moulage.

Sur les conseils de Mr. ANTHOINE, nous avons dépouillé (5°) la coque pour faciliter le démoulage et l’avons rayonné (5mm) pour éviter les problèmes liés aux angles vifs lors du démoulage. Le plateau de leur machine de thermo-moulage n’étant pas assez grand, nous avons donc recours à l’aide du Lycée Théodore DECK de Guebwiller qui ont une machine capable de réaliser des pièces de telles dimensions (300×120).

 

 

La fabrication sera réalisée soit en ABS (épaisseur 1,5mm, plus simple à peindre mais moins résistant) soit en PVC (épaisseur 1mm, transparent donc plus compliqué à peindre, plus résistant aux chocs).

La matrice de moulage a été imprimée en deux parties, puis collée pour le moulage.

Aujourd’hui, il reste à mouler la coque au lycée Théodore DECK, et réaliser les quatre barres de fixations de la coque sur le châssis en tournage.

Conclusion :

Grâce à ce projet, nous avons pu suivre un projet entier, de sa conception à sa fabrication. Nous avons pu appliquer les compétences acquises lors des deux années de DUT, en conception mécanique mais également lors des cours de CAO.

Nous avons pu développer nos qualités de travail en groupe mais également nos capacités de réflexions. Les problèmes rencontrés ont été des challenges que nous avons pu relever en appliquant encore une fois les connaissances du DUT GMP.

Pour finir, nous avons pu utiliser les connaissances d’usinages acquises lors de la première année.

 

 


 Projet d’innovation :

 

La seconde partie de ce projet comme définit dans l’introduction, s’inscrit directement dans l’objectif du concours. Nous avons donc choisi de « créer » une voiture dite connectée, ce qui veut dire que l’on doit pouvoir accéder à un certain nombre de capteurs et pouvoir agir sur les effecteurs présent dans la voiture.

Analyse fonctionnelle

Cahier des charges fonctionnel :

Intégrer un système composé de capteurs et d’effecteurs dans une voiture télécommandée et envoyer ces informations en temps réel via une IHM  :

  • le système doit comporter des capteurs comme de température, humidité, accéléromètre et doit être assez petit pour rentrer dans une voiture télécommander.
  • Échange des informations en temps réel.
  • Avoir une IHM pour pouvoir visualiser ces données et agir sur les effecteurs.

 

Bête à corne :

 


Réalisation Matériel:

Dans un premier temps, nous avons choisi un Arduino Yun, qui est composé d’un microcontrôleur car il permet d’un part une intégration facile dans la voiture et de gérer un certain nombre de capteurs et d’effecteur, et d’un autre part de gérer en parallèle grâce un processeur spécifique une page web.

 

Architecture Arduino Yun.

En effet, le Yun possède deux processeurs différents et donc deux environnements permettant de gérer dans une première partie l’acquisition des données en langage C (environnement Arduino) qui par le bridge sera envoyé au noyau Linux, pour exécuter des protocoles HTTP et d’interagir avec notre IHM web.

 

 

 

Les capteurs choisis sont les suivants :

  • Double capteur de température

Le premier capteur est installé à l’extérieur de la voiture dans le but de connaitre la température ambiante. Le deuxième, collé au moteur à courant continu, indiquera la température de ce dernier afin que nous puissions agir dessus.

 

 

 

 

 

  • Capteur de luminosité

 

Situé sous le toit de la voiture, le capteur servira à capter la luminosité ambiante et agira sur les phares.

 

 

  • Capteur de chocs

 

Collé au niveau du capot, le tilt sensor envoie une impulsion en cas de chocs (utilisable pour un arrêter le moteur par exemple).

  • Accéléromètre

 

 

Les actionneurs :

Leds : Rajout de leds au niveau des phares.

Les leds peuvent-être dirigées de différentes façon : soit par une requête directement envoyée de la page web par un utilisateur, soit si la luminosité tombe à moins de 40 lux

Ventilateur : Comme les leds, s’actionne à l’aide d’une requête ou si la température du moteur dépasse les 60 degrés Celcius.

 

Voici les codes en C commentés :

 

 

 


Supervision :

 

Pour la réalisation de la supervision, nous avons dû créer une IHM permettant de visualiser toutes les données acquises ainsi que d’envoyer des « ordres » à l’Arduino. Pour réaliser cette IHM nous avons choisi d’utiliser le format web, rendu possible grâce à l’Arduino Yun, et donc nous avons écrit cette IHM en Hyper Text Markup Language (HTML) qui est un langage de balisage conçu pour représenter les pages web, uniquement structurel.

Cette IHM web est constitué de deux parties :

  • La première page est l’acquisition des capteurs :

 

 

  • La deuxième page permet d’agir directement sur les effecteurs via des boutons.

Après création de cette page web, il nous faut maintenant pouvoir dialoguer avec l’Arduino.

C’est donc pour cela que l’on a utilisé le Javascript, qui est un langage de programmation de script orienté objet qui permet de rendre les pages web dynamique autrement dit interactive avec l’utilisateur.

 

 

Hors ce langage ne s’exécute seulement que sur le client et ne permet donc aucun échange avec le serveur. C’est donc pour cela que l’on a utilisé le protocole Hypertext Transfer (HTTP) et plus précisément le XMLHttpRequest qui est un objet du navigateur accessible en Javascript permettant d’obtenir des données du serveur au format XML, JSON, ou HTML.

 

C’est donc grâce à ce protocole que l’on à créée une fonction type qui permet de recevoir non seulement des données mais aussi envoyer des « ordres » à l’Arduino qui seront ensuite traités pour gérer les effecteurs comme expliqué dans la première partie.

 

 

Dans la page « capteurs », les requêtes vont se lancer automatiquement toutes les secondes sans actions préalable de l’utilisateur.

 

 

Puis la page « effecteurs », elles seront lancées par l’utilisateur directement via l’appui de boutons.

 

 

 


Conclusion :

Malgré quelques problèmes rencontrés, on à réussis à remplir nos objectifs. En effet, le calibrage des capteurs n’à pas été facile, de même pour mettre en fonctionnement l’Arduino à cause de la configuration de base.

Maintenant après avoir terminé ce projet il y plusieurs d’amélioration possible :

  • Agir directement sur le moteur avec le capteur de choc.
  • Gérer les phases d’accélération grâce au capteur d’accélération.
  • Avoir la vitesse en temps réel.

 

 

 


Documents Annexes :

 

Code en C Arduino :

code HTML/CSS et JS :

ProjetCourseEnCour

 

 

 

 

 

 

 

….


Amplificateur audio

logo uha                                                           Capture d’écran 2017-03-15 à 16.51.27

AMPLIFICATEUR STÉRÉO

Capture

SOMMAIRE

I. Contexte du projet

1.Définition du projet

2.Cahier des charges

3.Expression du besoin

II. Déroulement du projet

1) Préparation du schéma électronique de l’amplificateur et de l’alimentation

2) Choix des composants

3) Simulation du schémas électronique

4) Réalisation kicad

5) Réalisation de la plaque

6) Packaging

7) Liste du matériel commandé

III. Conclusion

 1)Vidéo de présentation du projet

2) Remerciements

3) Webographie

I.Contexte du projet

 

1. Définition du projet

Dans le cadre de nos projet de première année il nous a été demandé de réaliser un amplificateur audio(stéréo) avec un cahier des charges définis. L’objectif primaire de ce genre de projet est non seulement de nous introduire au travail en équipe mais aussi en autonomie.

Notre projet l’amplificateur stéréo a pour but de permettre l’amplification de signaux sonores. De ce fait les sons issus d’un émetteur (smartphone par exemple) simulés par une variation de tension électriquement seront amplifiés pour être  transmit à un récepteur (haut-parleur par exemple). Notre amplificateur devra être alimenté aussi bien sur le secteur qu’avec une batterie (voiture par exemple).

Capture

La première contrainte étant d’alimenter notre amplificateur, nous avons donc divisé notre projet en deux parties : l’alimentation et l’amplification.

  • Partie Alimentation : BARHAME Rayane, KELES Hakan, DARBOUX Marvin
  • Partie amplification :  ABLAK Mehmet , AMAYOU Ayoub

2.Cahier des charges

  • Alimentation à rabattement et à retournement
  • 230 v en entrée (l’alimentation pourra être branché à une prise) ; elle régule le courant et la tension pour qu’ils conviennent à l’amplificateur
  • 10 à 12 v comme tension et jusqu’à 5 A en sortie
  • Source de courant constante avec transistor bipolaire

3.Expression du besoin

Capture

 

Ce schémas globalise de façons très générale toutes les contraintes (besoins) nécessaires a l’élaboration du projet. Les fonctions de services seront détaillées dans le tableau qui suit :

Capture1

II. Déroulement du projet

1) Préparation du schéma électronique de l’amplificateur et de l’alimentation

Avant de commencer l’utilisation de logiciel et autres, nous avions dû commencer à faire la conception du schéma ‘brouillon’ sous forme papier. En effet, avec l’aide de notre tuteur, nous avions réaliser plusieurs calculs et plusieurs schémas différents pour pouvoir aboutir au schéma électronique de nos deux parties de notre projet.

2) Choix des composants

Après avoir fini la conception du schéma papier, nous avons commencé à choisir les composants pour la conception taille réelle. Nous avons donc préparer 2 fiches (une pour la partie Alimentation et l’autre pour la partie Amplification) avec le nom des composants non disponible à l’iut. Le choix des composants a été réalisé avec la prise en compte pour chaque composant du datasheet « idéale » pour notre projet du point de vue données de fabrication mais aussi du point de vue coût. Cette fiche regroupait donc le nom des composants à commander.

Exemple d’un document source que l’on a réalisé pour facilité la recherche des données composants :

 

 

2.1) Partie alimentation

Deux phases sont nécessaires à la réalisation d’un projet. La phase de conception et celle de la réalisation. Le choix des composant relie ces deux phases étroitement. Après la préparation de notre schémas électronique ils nous fallait trouver des composants adhérant à notre solution et attestant de la crédibilité de nos choix conformément à ce que le marché peut nous offrir. Cette étape c’est donc déroulé comme suit :

  • choix du condensateur : Calcul de la capacité du condensateur C = I / Δu * F I = 1A , Δu=5v (car on veut 10V en sortie et la transfo délivre une tension efficace de 15√2 = 21V donc la différence sera de 16), F = 100 Hz  1 Transfo = 50 Hz * 2 (en double)

condensateurcondo

 

  • choix de la diode Zener : 5 V

Capture

diode zener

 

 

 

 

 

 

 

  • Pont redresseur de tension

Capturepont_redresseur_V

  • choix de la résistance : Ampérage max : 250 Ma, Résistance : 16/(20*10^-3) = 800 Ω donc I =Vmin/R = 11/800 = 0.01375 = 13mA.

Afin de palier au défaut de la résistance pour avoir un courant continue, on a donc choisi d’opter pour un transistor

  • Choix du transistor: transistor PNP

transistortransitor pnp 2

 

  • Ampli opérationnel 741 avec tension de sortie max 25 mA

ampli_op

 

  • Choix du deuxième transistor:

Calcul des courants Ic pour des valeurs max et min :

– Pour le max : Icmax = β * Ibmax = 70 * (25*10^-3) = 1,75 A

– Pour le min : Icmin = β * Ibmin = 20 * (25*10^-3) = 0,5 A

Or 0,5 < 1A (Courant que l’on veut tirer) donc obligation de rajouter un transistor à l’aide d’un montage de Darlington en NPN. D’ou le choix de ce  transistor 2n1711 en bas du 1er Transistor.

sup_transis

 

2.2) Partie amplification

 

 

 

3) Simulation du schémas électronique

Les schémas électriques on été réalisé dans un premier temps par le biais de PROTEUS ISIS (logiciel de simulation électronique)

  • Partie Alimentation: les tensions affichés par les voltmètres mettent donc en évidence la validité des choix de composants que nous avions fait ainsi que le respect du cahier des charges

 Capture

 

  • Partie amplification: la courbe en verte fait office de tension de sortie et celle en jaune de tension d’entrée

Capture

 

4) Réalisation Kicad

Kicad est un logiciel de conception libre assisté par ordinateur intégrant à la fois un module de saisie de schémas et un module de routage de circuits électriques.

4.1) Conception partie alimentation

conception partie alimentation

Nous avions eu pas mal de problèmes avec l’amplificateur opérationnel ainsi que le pont redresseur de tension afin de  les relier comme il faut à la masse. La pose de la résistance variable vu qu’on arrivait pas a obtenir la bonne gamme de tension.

4.2)Conception partie amplification

conception partie amplification

La pose des radiateurs posait problème. Obtenir la bonne tension de sortie fut aussi très délicat.

6) Packaging

Le packaging c’est fait très rapidement. Il nous fallait une boite pas trop encombrante et simple à réaliser. La prise en main du logiciel ( ) c’est faite très rapidement, sans compter le fait que la forme complexe de la fermeture de la boite c’est faite très rapidement a cause de l’aisance d’utilisation du logiciel.

7) Liste du matériel commandé

liste de matériel commandé

 

 

III.Conclusion

1) Vidéo de présentation du projet

 

2) Remerciements

Ce projet fut pour nous une expérience unique. Il nous a instruit au travail en équipe et en autonomie. Nous remercions de ce fait nos professeurs de projet  ainsi que nos professeurs électrotechnique  et de bureautique pour le temps qu’ils nous ont consacré. Nous tenons également à remercier spécialement le responsable de L’IUT lab pour son implication dans la réalisation  des plaques et du packaging.

 

IMG-20170615-WA0000

3) Webographie

lien RS components

explications sur le principe

redresseur double alternance monophasé

 

 

 


Sondes de température

Résultat de recherche d'images pour "iut de mulhouse"Résultat de recherche d'images pour "geii mulhouse"

PROJET : Sonde de température

Sonde de température

 

GEII 1A 2016/2017 MULHOUSE


Sommaire



L’équipe


IMG-20170620-WA0001


De gauche à droite :
  • OZTUNG Tunç
  • ZINK Valentin
  • PATRE Guillaume
  • QUANG Benjamin
  • ROCA Maxime
  • VIRARAGOURADJA Richard

Présentation du projet


Objectif:

  • Réaliser une maquette pédagogique pour les futurs étudiants de 1ère année.

But:

  • Remplacer l’ancienne sonde de température par un dispositif conforme et plus efficace que le précédent.
  • Permettre la caractérisation d’une sonde de température à tester.
  • Pouvoir refroidir ou chauffer le volume de test en dessous et au dessus de la température ambiante .

Contraintes:

  • Alimentation à découpage (0V-15V).
  • Température comprise entre 5°C et 70°C.
  • Monter à une température et savoir la maintenir (Ventilation et asservissement pour garder la température constante).
  • Normes de sécurité thermiques ,mécaniques et électriques.

 


 

Définitions des termes scientifiques


1) Tension électrique
  • Circulation du champ électrique le long d’un circuit
  • Mesurée en volt
  • Notée U

2) Intensité (ou courant électrique) :
  • Déplacement d’ensemble de porteurs de charges électriques
  • Mesurée en ampère
  • Notée I

3) Résistance :
  • Grandeur caractérisant la « force » avec laquelle le conducteur s’oppose au passage du courant.
  • Exprimée en ohms Ω
  • Notée R

tension intensitéresistance


4) Tension alternative :
  • Tension variable qui prend alternativement des valeurs positives puis négatives

Image4

 

 

 

 

 

 

 


5) Tension continue :
  • Tension qui garde même signe et même valeur au cours du temps

 

 

 

 

 


 

6) Puissance électrique :
  • Représente la force motrice de l’électricité
  • Produit de la tension électrique aux bornes de laquelle est branchée l’appareil
  • Produit de l’intensité du courant électrique qui le traverse
  • Notée P
  • Exprimé en watt

Exemple d’utilisation d’une sonde de température


Ceci est un exemple d’utilisation de sonde de température:7.Régulateur climatique modulante

Ici, on règle la température souhaitée

 


Cahier des charges


  • Diagramme bête à cornes

bête à corne

 

 


Diagramme de Gantt


Organigramme de Gantt

gantt1

gantt2

 

 


Étude des composants


  • Le module à effet Peltier.

Le module Peltier permet de transformer un courant électrique en une différence de température. Au sein de notre projet nous utiliseront le module Peltier pour refroidir notre plaque métallique. Ce module présente deux faces, dont l’une est dite froide et l’autre chaude. L’objet à refroidir se positionne sur la face froide et on évacue la chaleur avec un ventilateur par la face chaude.

peltier

  • La résistance chauffante.

La résistance chauffante est un matériau conducteur à base de métal présentant une résistance électrique au passage d’un courant qui la porte à une température donnée par effet joule.

res

  • Le relais

Notre relais est composé d’un électroaimant, qui lorsqu’il est alimenté transmet une force aux contacts. Les contacts commutent quand la bobine est alimentée et le retour à l’état initial se fait quand la bobine n’est plus alimentée.

relaisymbole

  • L’AOP (L’Amplificateur opérationnel)

C’est un amplificateur électronique qui amplifie une différence de potentiel électrique présente à ses entrées. Les AOP ont été conçus pour effectuer des opérations mathématiques.

aopschéma aop

  • La diode de roue libre

La diode de roue libre se connecte en parallèle d’une charge inductive pour la continuité du courant électrique dans l’inductance. Cette diode permet d’assurer la continuité du courant électrique dans le circuit. En effet l’induction (la bobine du relais) à comme propriété essentielle qu’on ne peut pas rompre brutalement le courant qui la traverse car elle peut entrainer une surtension.

diodeschéma diode

  • Le transistor NPN

Le transistor se comporte comme un interrupteur.

Les transistors bipolaires possèdent 3 connexions : le collecteur, la base et l’émetteur.

Le transistor s’active par une tension positive ou négative sur la base par rapport à l’émetteur.

Dans son état passif, le transistor bloque le flux électricité entre le collecteur et l’émetteur.

npntransistor

  • Sonde de température AD592

L’AD592 est une source de courant haute précision, elle nous fournit un courant par rapport à la température qu’elle relève. La sonde nous fournis 1µA par °K, ce qui nous permet de définir la température relevé.

ad592


Évolution du projet


Étude du cahier des charges

Alimentation

 

    • Étude du circuit de l’alimentation

 

IMG_20170303_144853-min(1)

 

Régulation

  • Étude du circuit de la régulation

IMG_20170303_144859-min

  • Simulation sur plaque d’essai
  • Calcul des résistances

 

IMG_20170313_095547-min IMG_20170309_122331-min IMG_20170309_122315-min

  • Achat composants

Capture

  • Réalisation Kicad
  1.   Connecteur entre borniers et Peltier/Résistance chauffante
    sonde
  2. Plaquette alimentationalim
  3. Plaquette Régulation

Capture1

  • Réalisation circuits imprimés
IMG_20170620_114231-min Circuit de l’alimentation
IMG_20170329_093810-minCircuit de la régulation
IMG_20170620_114656-minCircuit de l’AOP

 

  • Conception des boites

    IMG_20170327_115447-min

  • Montage des boites

Montage


 

//texte


Bilan


 

//vidéo de la maquette en fonctionnement


Mode d’emploi


 

 

//texte


Conclusion


 

//texte


Remerciements


Un grand merci à M. STRAFELLA et M.COLICCHIO, nos enseignants-chercheurs tuteurs pour ce projet, de nous avoir aidé pour ce projet.

Merci au département GEII de l’IUT de Mulhouse pour le prêt du matériel nécessaire et pour l’achat des composants.

 

 

 

 


Sonde de courant

Présentation projet sonde de courant:

iutm

 

 

Référence

GEII

Auteurs

Anthony NAZE

Thanh Suon NGUYEN

André NDALLA

 

 

SOMMAIRE

 

 

1)Introduction

  1. Présentation du projet
  2. Listes des composants
  3. Exemple datasheet composant

 

2)Programmation et conception de la carte électronique de la sonde

  1. Présentation du logiciel Kicad
  2. Dessin du schéma électronique de montage
  3. Création et association d’empreintes aux composants
  4. Liaisons des composants et modifications des pads
  5. Conception du circuit imprimé
  6. Résultat obtenu

 

3)Conclusion

 

Introduction

 

 

Présentation du projet

BeteACorne

Afin d’effectuer une mesure de courant dans un circulant électrique, il est possible d’utiliser une sonde sans contact électrique direct c’est-à-dire par isolation galvanique. L’IUT de Mulhouse utilise des sondes afin de mesurer les courants sur des maquettes d’études de systèmes. Ainsi le but du projet est la réalisation d’une sonde de courant étalonnée pour la mesure.

Pour notre deuxième semestre, nous avons eu comme projet la création d’une sonde de courant ou sonde à effet Hall :

 

« un courant électrique traversant un matériau baignant dans un champ magnétique, engendre une tension perpendiculaire à ce dernier »

Edwin Herbert Hall

 

Nous avons eu comme délai de 60 heures avec 4 heures de bonus lors des journées portes ouvertes de l’IUT.

Sans titre

Par ailleurs ce projet est destiné aux futurs étudiants qui manipuleront ces sondes lors de leur séance de travaux pratique. Ces sondes devront remplacées les anciennes qui ne sont plus aux normes. Nous allons remplacer les entrées non conformes par un potentiomètre qui régulera la tension à notre guise.

 

Ci-dessous une ancienne sonde de courant non conforme aujourd’hui:

17360777_1116764615136082_369193511_n

 

Pour la création du schéma du projet nous avons besoin du logiciel Kicad pour a partie de création de schéma.

 

La partie de conception de la plaquette en modèle réel, il est nécessaire d’avoir la liste suivante :

 

  • Préparation des composants dans une boite individuelle
  • Une carte électronique vierge
  • Poste à souder
  • Fer à souder
  • Souffleuse
  • Etains
  • Des outils
  • Tournevis
  • Pince
  • Multimètre
  • Des outils de réalisation de la plaquette
  • Imprimante UV
  • Liquide révélateur
  • Massicot
  • Perceuse

pieuvre

Liste des composants nécessaire :

 

 

 

Quantité Nom Référence Prix
* 1 Transformateur 121-3826 3,50 €
1 Fusible 848-2762 0.41€ -> 0.82€
1 Sonde LA 25-NP 286-311 21,20 €
2 Condensateur 862-3250 0,22€ -> 0,44€
Aluminium 2200µF
2 25V 653-0153 0,176€ -> 0,352€
Céramique 10nF
2 Régulateur de tension 298-8621 0,16€ -> 0,31€
L7915CV
L7815CV 298-8558 0,17€ ->
1 Pont redresseur 629-5989 0,438 €
1 Amplificateur op 371-1056 17,05 €
2 Résistances 132-258 0,017€ -> 0,034€
100Ω
1 LED 228-5988 0,168 €
1 Résistances LED 148-506 0,045 €
– 1kΩ
* 1 Port fusible 310-9841 1,87 €
* 1 Sortie coaxiale 619-6393 1,86 €
* 1 Interrupteur (switch) 124-5906 4,07 €
* 1 Potentiomètre 467-6106 0,228 €

 

 

Certains composants seront issus de la récupération de l’ancienne sonde, ce qui nous évitera une dépense en plus en matière d’œuvre (marqué par des *)

 

Par rapport à la documentation de la sonde, à la sortie de la sonde on choisit une résistance de 100Ω puis pour le choix du gain de l’AOP (Amplificateur Opérationnel non inverseur) on a également pris une résistance de 100Ω ainsi qu’une résistance variable de 1 kΩ pour avoir un gain de 11 maximum (Vsortie/ Ventrée = 1+R2/R1). On peut aller jusqu’à 9,5 car la résistance variable ne va pas jusqu’à 1 kΩ mais 850Ω.

 

Datasheet des composants :

 

Pour certaines pièces de la liste, nous devons nous servir du Datasheet du fournisseur afin d’avoir des données sur la pièce pour dessiner le module.

 

 

Voici l’exemple Datasheet du composant LA 25-NP :

lem
Programmation et conception de la carte:

 

 

Présentation du logiciel Kicad:

Le logiciel Kicad présenter ci-dessous, sera le seul logiciel informatique dont nous aurons besoin pour la réalisation du projet.

Dans la fenêtre de gauche, les fichiers sont :

  • Le circuit imprimé (Pcbnew)
  • La liste des empreintes des différents composants (Netliste)
  • Le schéma, le dessin du circuit (Eeshema)

kicad1

 

Par la suite, lors de chaque enregistrement de fin de travail, les fichiers seront sauvegardés dans notre dossier personnel.

Dessin du schéma électronique de montage:

Pour commencer, nous avons commencé par créer le schéma de la sonde via la feuille d’explication (ER2.sch).

kicad2

Création et association d’empreintes aux composants:

Pour ce qui est de certains composants comme la sonde LA 25-NP l’empreinte sera sous le nom de LA25NP, car nous avons dû créer une nouvelle empreinte qui n’existait pas auparavant afin de l’associer à ce composant. Ainsi que pour le switch sous le nom de SWittchy, le condensateur C1 et C2 en CP16-max, le bridge en pontRed etc… Pour pouvoir récupérer nos empreintes créer, on a créé une nouvelle librairie personnelle où toutes nos empreintes créées s’y retrouvent, nommé « ER2 ». La Netliste a pour but d’associer automatiquement l’empreinte aux composants lorsqu’on l’ajoute lors de la conception du circuit. (ci-dessous) De plus certains composants devaient être redessiner pour pouvoir avoir la bonne forme et dimension lors de l’insertion. Dans la Netliste courant à gauche, se situe les composants précédents et sur la droite les empreintes qu’on va attribuer aux composants.

kicad3

Liaisons des composants et modifications des pads:

Ensuite on a dû modifier la taille des pads.

kicad7

 

Après avoir effectué les modifications nécessaires pour les empreintes et vérifié, on a des chevelus qu’il faudra relié via un fil de taille 1.27mm.

kicad4

 

Pour relié les composants entres eux, il faut cliquer sur un pad et relié au pad indiquer.

 

Avant :

kicad5

 

Après :

kicad6

Pour finir avec le logiciel, on imprime le tout en taille réelle. Lorsque l’étape de la réalisation sur Kicad est finie, nous pouvons passer à l’étape de la pratique qui est la conception.

Conception du circuit imprimé :

 

Pour commencer, il faut découper la carte électronique vierge à la dimension demandé à l’aide d’un massicot, puis après on tamponne la carte par un produit et on pose sur le circuit la feuille imprimée auparavant en taille réel et on frotte afin que le tout s’imprègne. Les typons serviront de « calque » pour la plaque découpé.

decoupe

 

Par la suite on place la plaque et le typon dans une insoleuse durant 3 minutes afin que le cuivre soit parfaitement évacué et que le tracé soit bien visible.

typon visible

 

 

revelateur

On rince la plaque à l’eau puis on la nettoie avec du papier. Nous réitérons cette étape mais remplaçons l‘eau par du chlorure de fer. Au niveau des trous sur la plaque, les relevés de mesures ont été fait précédemment. Il suffit de percer à l’aide d’une mini perceuse. Une fois les étapes précédentes terminées, il faut souder les composants sur la plaque avec de l’étain.

soudure

A chaque soudure on teste les composants afin de voir leur fonctionnement. Puis à la fin on fera un test final.

Résultat obtenu:

La boite finale ressemble à :

sonde

Utilisation :

La sonde est à brancher sur secteur. Le voyant rouge indique le bon fonctionnement de la sonde. Pour faire les mesures on branche la sonde en série dans le circuit grâce aux bornes rouge et noire. La sortie coaxiale permet de visualiser les variations de courant sur un oscilloscope.

 

 

 

Conclusion

Durant ces heures d’études et réalisation, nous avons découvert le travail d’équipe, l’organisation et les contraintes lié à celui-ci. Nous avons pu approfondir nos connaissances en électrotechnique du premier et second semestre.A l’heure d’aujourd’hui, nous avons eu un problème avec notre première sonde. Le transformateur surchauffait. Il provenait de l’ancienne sonde qui était HS. Nous avons commandé un nouveau transformateur et avons dû modifier le typon pour correspondre aux nouvelles dimensions. Nous travaillons actuellement sur la réalisation de la sonde.

L’équipe de réalisation:

WhatsApp Image 2017-06-14 at 17.00.01

Anthony                                              André                                                   Thanh

                                                                chef de projet                               responsable design                      responsable administratif


Robots ruches connectées

 

Ruches connectées

Sommaire :

 

Introduction

Membres du projet

Présentation du sujet

Cahier des Charges

1. Diagramme bête à  cornes

2. MindMap

3. Diagramme de Pieuvre

4. Diagramme de Gantt

Gestion de projet

1. Etude de consommation

2. Etude d’alimentation

3. Etude capteur de poids

4. Collecte et affichage de donnée

5. Comparaison entre Sigfox et Lora

Bilan

Bibliographie

Remerciements

 

Introduction

 

 

Dans le cadre du projet du second semestre en DUT GEII, (Génie Electrique et Informatique Industriel) de première année. Il nous est demandé de réaliser par groupe un projet, dont nous avons 60h encadré par nos professeurs (M.Hueber et M.Choisy ). Les enseignants nous ont demandé de choisir un projet que nous voulions réaliser sur une liste de 3 projets. Chaque projet doit être constituer de 2 à 6 personnes.

 

 

Membres du projet

 

 

Notre groupe est composé de deux étudiants en première année GEII :

Capture-5

Présentation du sujet

 

 

Nous avons pour projet, l’amélioration de la « ruche connectée » de l’an dernier (http://www.projetsgeii.iutmulhouse.uha.fr/ruche-connectee/). Elle est déjà équipé de capteurs de température et d’humidité. Les informations sont stockées et diffusées sur un site internet (http://abeilles.geiim.fr/accueil.php). Cela permet a l’apiculteur d’avoir des informations sur sa ruche en temps réel. Le système doit être autonome et en aucun cas, ne doit gêner l’apiculteur ou les abeilles dans leur travail. Notre but cette année consiste à améliorer l’alimentation de la ruche  mais aussi ajouter un capteur de poids et un radiateur.

 

 

Cahier des Charges

 

1. Diagramme bête  à  cornes

 

 

La bête à cornes sert à définir à quoi sert le projet et à qui il sert.

Capture-6

2. MindMap

 

 

Le MindMap sert à montrer les différents points de réalisation du projet.

Capture-1

 

3. Diagramme de Pieuvre

 

 

Le diagramme de la pieuvre  permet de connaître les différents fonctions,  contraintes (gauche) et principales (droite) de notre projet.

Capture-2

4. Diagramme de Gantt

 

 

Le Gantt permet de prévoir l’organisation du temps dans le projet.

Capture-4

Budget détaillé

 

 

Notre Budget initial est de 200 euros. Nous disposons également du matériel mis à  notre disposition à L’IUT Lab.

Nom

Quantité

Prix

Capteur de pression

4

29,99€

Capteur de température/Humidité

2

54,06

Panneau solaire

1

48,65

Gourde

4

19,96

Câble USB 2m

1

5,28

Plaque chauffante

1

20€

Battery management system

1

1,45

Au total nous avons dépensé 179.39€ .

 

 

Gestion de projet

 

1. Etude de consommation

 

 

Avant de commencé tout type de montage, nous avons étudié la consommation de tout les composants de notre système embarqué afin de bien choisir l’alimentation qui suit. Nos capteur de température/d’humidité ont une plage de -40 à  125 degrés Celsius et 0% à  100% pour l’humidité .

20170526_161651

Akeru Capteur de température/d’humidité extérieure (SHT75) Capteur de température/d’humidité intérieure (SHT11) Capteur solaire HXT711
IMAX 25 mA au repos/80 mA actif 1 mA 1 mA 0.002 mA 1.5 mA

 

 

2. Etude d’alimentation

 

 

Notre Système embarqué consomme au total près de 80 mAh. Nous devions commander un panneau solaire capable d’assurer l’alimentation.

Sans titred

Pour connaître la production du panneau solaire dans différents conditions ( à  l’ombre, de coté, de dos, en plein soleil ), nous avons fait un montage pour ainsi avoir une estimation sous différents climats. Au plein soleil correspond à une alimentation optimale.

Capture-1Capture-2

 

graph

 

Pour stocker la production du panneau solaire, il suffit d’installer une batterie, accompagné d’un BMS qui permettra d’éviter la surcharge. La batterie fabriqué manuellement est composée de 3 piles lithium, au total 12V supportable par l’Akeru .

20170526_13434020170526_140030

 

Mis en lien du panneau solaire et batterie

 20170526_165323

3. Etude capteur de poids

Nous avions à notre disposition des gourdes et des capteurs de pressions pour récupérer le poids de la ruche. Le capteur est alors placé au bout de la gourde mais malheureusement les capteurs de pressions atteignaient vite leurs limites et ne pourraient pas assurer une plage de mesure approprier.

20170526_13440120170526_134503Capture-3

 

Il a donc fallu penser à un système pour démultiplier la pression exercé sur cette gourde et ainsi repousser la limite du capteur de pression.

20170526_160600

 

Des barres sont placées aux quatre coins du support de la ruche, ce qui servira à ce que la force exercée sur la gourde au milieu soit atténuée. Puisqu’une partie du poids est exercée sur les barres des coins de la ruche, cela soulagera d’une pression moins conséquente pour la gourde. Et ainsi on aura une plage de mesure beaucoup plus étendue.

20170526_162051Test Sans titre5

Nous avons donc tester ce système de récupération du poids avec l’aide d’un programme pour convertir le résultat à la sortie du capteur en kilogramme et ainsi l’envoyer sur une plateforme où le poids sera affiché.

4. Collecte et affichage de donnée

 

 

La collecte des données de notre l’Akeru, par nos capteurs de pression, température/humidité  sont transmis sur un site Actoboard dédié au réseau Sigfox. L’affichage de donnée peut-être modifié directement sur le site Actoboard . L’apiculteur peut consulter les informations en lignes rafraichie tous les 10 min.

Capture-3 Capture-5Capture-6

Capture-7

 

5. Comparaison entre Sigfox et Lora

 

 

 Lora  Sigfox
Fréquence utilisé 866 MHz et 433 MHz  868 MHh
 Débit 300 bits/s à 100K bits/s  500 bits/s
Taille de transmission d’information sans limite avec une limite de 12 octets par message et 140 messages par jour
 Puce (gère le flux de donné situé dans le circuit intégré)  Semtech ,Microsemi  Atmel, Texas, Silicon Labs, ST Micro

 

Bilan

 

 

Le système embarqué est capable de s’auto-alimenter et de transmettre ou recevoir des données via le réseau Sigfox, des données reçues en temps réel par nos différents capteur sur notre Akeru grâce au onde basse fréquence qui permettra ainsi a l’apiculteur de suivre sa ruche en ligne.

 

 

Bibliographie

 

 

Cahier des charges fonctionnelles  :  Cahier de charges fonctionnelles

Cahier des charges techniques :Cahier des charges techniques

Carnet de bord : Carnet de bord

Remerciements

 

 

Merci au département GEII de l’IUT de Mulhouse pour le budget et l’apport de matériels.

Nos professeurs encadrants Mr Hueber et Mr Choisy de nous avoir aidé pour ce projet.


Ruche solaire

Projet Ruche Solaire

 

Logo-GEii-mulhouse

 

Régulation de la température d’une ruche grâce à la chaleur du soleil

pour éliminer le Varroa destructeur.

 

Sommaire

                               I.  Cahier des Charges

                              II.  Préparation du projet

                              III. Cahier des Charges Techniques

                              IV.  Réalisation du projet

 


I. Cahier des charges

    1. Contexte

Problématique :
Comment se débarrasser du varroa de façon écologique ?

 

Objectifs :

Eliminer le varroa destructeur dans une ruche
Technique écologique et facile d’utilisation
Méthode faisable pendant la miellée


 2. Bête à cornes

Image1


3. Diagramme Pieuvre

Image2


4. Contraintes

 

Capture


II. Préparation du projet

1. Mind Map

Image1


2. Organigramme GANTT

Image2

Suite …

CaptureProjet


3. Répartition des tâches

 

Capture

 


III. Cahier des Charges Techniques

1. Solution Technique

Image2

 

 

  • Traitement par hyperthermie :

– Varroa => 41°C

– Abeille => 47°C

  • Déjà eu des précédents>/span>
  • Objectif => 80% à ± 10%

 

 


 

 

 

 

 

1.Ruche + écran LCD + capteur

2.Panneau solaire ou batterie

3.Raspberry PI

4.Carte d’alimentation

 

 

 

 

 

 

 

 

 

 


 

 

2.1 Fonctionnement de l’écran LCD

 

Heberger imageHeberger image

 

 

 

 

 

        Ecran en mode opaque                                                                               Ecran en mode transparent

 

3. Ecarts de prévision et problèmes

 

Capture

 

 

1ère Année DUT GEii – promotion 2017

 


Régulation humidité du sol

Projet 1ère Année DUT GEii – promotion 2017



Résultat de recherche d'imagesRésultat de recherche d'images



 

CONTRÔLE HUMIDITÉ DU SOL

photo_projet

 



 

SOMMAIRE

I. Introduction

II. Présentation du sujet

III. Cahier des charges

  1. Bête à cornes
  2. Pieuvre
  3. MindMap
  4. Planification Gantt
  5. Délais
  6. Budget de départ
  7. Liste des achats

IV. Réalisation du projet

  1. Composants:
    1. Microcontrôleur
    2. Capteur d’Humidité
    3. Électrovanne
  2. Test fonctionnement:
    1. Capteur
    2. Électrovanne
  3. Réalisation carte électronique
  4. Programmation
  5. Packaging

V. Conclusion

VI. Perspectives d’évolution

VII. Remerciements



 

Introduction

 

Dans le cadre du projet d’études du DUT Génie Electrique et Informatique Industriel de Mulhouse, nous avons du réaliser un projet lié au domaine de l’électronique et de l’informatique. Ce projet s’est étalé sur la totalité du deuxième semestre et a totalisé un volume horaire encadré de 60 heures. Ce projet qui n’est autre que le contrôle de l’humidité du sol.

Le choix de l’équipe et du projet a été effectué en fonction de nos affinités et de nos préférences. Durant la totalité du projet, deux professeurs nous ont encadré : M. Haultcoeur et M. XU.

 



Présentation du sujet

 

Le but du projet est de réaliser un système autonome de régulation du taux d’humidité du sol sur plusieurs types de sol différents. De plus si le niveau d’humidité passe sous un certain seuil le système devra y remédier.

Notre dispositif devra bien évidemment être mobile et non fixe pour pouvoir changer de point de mesure et il devra résister aux intempéries de façon à pouvoir rester à l’extérieur.



Cahier des charges

 

1.Bête à cornes

 

Afin de connaitre les besoin primaire ou l’exigence principal de notre projet il nous a fallu utiliser le diagramme dit « de la bête à cornes »:

 

Diagramme Bete à corne


 

2. Pieuvre 

 

Maintenant que nous connaissons  le besoin primaire nous pouvons passer au diagramme dit « de la pieuvre » qui permet d’identifier les fonction principales (FP) et contraintes (FC) :

Capture

FP1

Le capteur d’humidité pourra être déplacé par l’utilisateur et être réglé par ses soins

FP2

Notre projet devra pouvoir détecter le taux d’humidité du sol et réagir si il passe sous un certain seuil

FP3

Le système devra pouvoir être disposé en extérieur et devra donc résister aux conditions climatiques et intempéries

FP4

Le capteur devra être implantable  dans tous types de sol

FC1

Le système devra pouvoir enregistrer les données que le capteur va récolter

FC2

Le conteneur qui accueillera le système devra etre esthétique et agréable à l’œil


3. MindMap

Avant de pouvoir passer dans le gros du projet il faut réalise un MindMap qui est le fait de représenté toute les idées et tache autour d’un même sujet et donc le voici :

mind_maps


4. Planification Gantt

Maintenant grâce au MindMap nous pouvons réalisé le Gantt qui est le fait de planifié toute ces taches :

 

gantt_prevision

gantt_2

 

 

 

 

 

 

 

 

 

 

 


5. Délais

 

La limite finale du projet correspond au jalon fixé par nos professeur encadrant qui été avancé le plus possible et si possible finir notre oeuvre avant le jour de la soutenance le jeudi 22 juin 2017.

Donc notre projet devra au plus tard être finie le jour précédent la soutenance, soit le Mercredi 21 Juin 2017.


6. Budget de départ

 

Le budget dont nous disposons est de 150€. Tous les matériaux disponibles à l’IUT et la commande de pièce annexe sont a prendre en compte dans le budget, seul le raspberry et ces accessoires(écran +souris +clavier) ne sont pas pris en comptent car prêtés par l’établissement.


7. Liste des achats

 

Pour notre projet nous n’avons acheté que quelques composants qui nous on permis de réaliser la nappe qui nous permettra par la suite de connecter les ports du raspberry au circuit de la plaque électronique car les autres composants ont été trouvé dans le magasin de L’IUT.



 

Réalisation du projet

 

1. Composants

 

Avant de pouvoir débuter notre projet il nous a fallu commencer par faire quelque recherche sur les composants mis a notre disposition par L’IUT :

1. Microcontrôleur

raspberry pi 3 b

  Caractéristiques technique:

  • 1 Go de RAM
  • 4 ports USB
  • 40 broches GPIO
  • Port HDMI complet
  • port Ethernet
  • Prise audio combinée de 3,5 mm et vidéo composite
  • Interface caméra (CSI)
  • Interface d’affichage (DSI)
  • Emplacement de la carte Micro SD (maintenant push-pull plutôt que push-push)
  • VideoCore IV noyau graphique 3D

2. Capteur d’Humidité

capteur-d-humidité-du-sol-analogique-et-numérique

 

En ce qui concerne les capteurs nous étions au préalable munis d’un capteur (conductivité électrique). Cela dit, en faisant des recherches plus approfondie j’ai découvert que certain autre type de capteur comportaient  des atouts non négligeable pour avoir un dispositif de mesure avec une sensibilité  élevé. J’ai donc décidé de faire un tableau de comparaison pour avoir une idée du capteur qu’il faudrait utiliser dans notre cas.

tableau comparatif capteur

 

Grace a ce tableau on remarque que la méthode TDR (réflectométrie temporelle) ,qui mesure l’humidité volumique du sol ,permet une mesure très précise de l’ordre de la picoseconde (10^-12) se qui est largement suffisant dans notre cas.. Malgré la disponibilité  et le prix un peu plus élevé, pour des mesures aussi précises et rapide autant payer un peu plus cher.


3. Électrovanne

 

distributeur TOR

 

Pour l’électrovanne j’ai décidé de faire pareil que pour le capteur pour vérifier que le type de notre électrovanne(TOR: tout ou rien)  a été la plus adaptée  :

 

tableau comparatif distributeur

D’après ce tableau on remarque que le Distributeur a commande proportionnel est celui qui serait le plus adapté. Prenons un exemple, si après une mesure on remarque que le taux d’humidité est inférieur a notre seuil défini grâce a ce distributeur nous pourrions réguler le flux d’eau qui arriverais afin  d’optimiser le taux d’humidité contenu dans le sol. Cependant avec notre électrovanne nous devons améliorer le temps d’ouverture de l’électrovanne.


 

2. Test fonctionnement

 

Maintenant que nous connaissons les caractéristiques de nos composants nous allons pouvoir passer a la deuxième partie qui est le test de chaque composants afin de connaitre leur fonctionnement :

1. Capteur

 

  • Avant de faire des test dans des pots de terre j’ai commencé par voir les valeurs que me sort mon capteur dans de l’eau et dans l’air :

test eautest air

 

 

On observe sur l’image de gauche (Test dans l’eau)  qu’avec une valeur de 3.3V en entrée, la valeur mesuré est de 1.26V ce qui prouve que plus l’humidité est importante plus la tension mesurée et faible.

On observe sur l’image de droite (Test dans l’air) qu’avec la même  tension que dans le premier cas, si la valeur mesuré est la même que celle de l’entrée,  l’humidité est plus importante en fonction de la résistance entre les 2 borne.

 

 

 

  • Maintenant que je connais un peu mieux le capteur et son fonctionnement je suis passé au test sur plusieurs types de terre fournie par notre professeur encadrant (M.XU) :

type de terre

sur cette image on peut voir trois type de terre différent:

  • Sable       (pots en haut au centre)
  • Mélange (pots en bas a gauche)
  • Argile     (pots en bas a droite)

Premier test:

20170315_113519

On remarque que sous une tension de 3.3V , la valeur mesuré en sortie vaut 3.15V  ce qui signifie que le sable est une terre de base trés peu humide.Plus l’humidité est grande plus la tension mesuré et faible.

Deuxième test :

mélange

 

 

 

 

 

 

On observe que toujours sous une tension de 3.3V , la valeur que nous affiche le voltmètre est 0.66V, ce qui signifie que le mélange est 2 fois plus humide que la mesure faite précédemment dans l’eau.

Troisième test :

20170315_145500

Pour finir on remarque que sur de l’argile, la tension mesuré en sortie 0.8V et un plus basse que celle réalisé dans l’eau(1.26V) .

En résumé, chaque type de terre avait ses propre caractéristique et donc pour un même volume d’eau chacune de ces terre aura  ça propre manière  de l’absorber.  De ce fait, lors de la programmation du dispositif il y aura plusieurs facteurs a prendre en compte pour pouvoir optimiser l’irrigation des terres et donc le taux d’humidité.


2. Électrovanne

 

Pour l’électrovanne les tests ont été beaucoup plus simple a réaliser car j’ai juste mesuré la tension minimal a laquelle l’électrovanne s’ouvrait après réalisation du montage et test en augmentant la tension on trouve que sous une tension minimal de environ 6V l’électrovanne s’ouvrait.

Après la réalisations de ce montage j’ ai cherché un moyen de raccorder  l’électrovanne a une arrivé d’eau  et donc voici le prototype réalisé grâce au matériel a notre disposition:

raccordement electrovanne

On peut voir qu’on a raccordé l’entré de l’électrovanne avec un embout (de robinet) sur le tuyau d’arriver d’eau et grâce a un collier de serrage on a pu ouvrir l’arriver d’eau sans qu’il y ait des fuites.


3. Réalisation carte électronique

 

Pour la réalisation de mon circuit imprimé j’ai eu droit a l’aide de collègue extérieur a mon projet, ce qui m’a permis d’avancer plus vite et donc de pouvoir aboutir a quelque chose de concret, voici le résultat :

kicad

On peut voir sur ce graphique le schéma réalisé grâce au logiciel KiCad, ce schéma se compose de plusieurs partie différente :

  • Partie Capteur(rouge) : Cette partie se compose du connecteur pour le capteur qui va permettre de mesuré l’humidité du sol.
  • Partie Raspberry(vert) : cette partie se compose de tous ce qui est traitement des donné donc du MCP3008 qui est un convertisseur analogique numérique et des connecteur pour les ports GPIO du raspberry.
  • Partie Relay(orange) : Cette partie se compose de tous les composant qui permette le bon fonctionnement du relay.
  • Partie LM317(noir) : Cette partie se compose de tous les composant qui permette le bon fonctionnement du LM317 qui est un régulateur de tension.
  • Partie Externe(jaune) : Cette partie se compose d’un connecteur pour une batterie externe(en bas) de 5V est d’un connecteur(en haut) pour l’électrovanne.

Après avoir réalisé le montage ci-dessus je suis passer au routage du circuit toujours grâce a KiCad puis après un long processus en commençant par couper une plaque au dimension voulue puis en  passant par plusieurs différent machine(ex: insoleuse, laveuse):

19458017_674873999384229_73346049_n

 

 

 

 

19402425_674874009384228_1114615964_o

 

 

 

 

 

Donc pour le processus on commence par couper une plaque de cuivre au dimensions voulue puis on imprime les piste du circuit routé  ensuite on commence par placé tout ceci dans une insoleuse (première photo) celle-ci permet de marquer  sur notre plaque les piste du circuit ensuite on passe notre plaque dans un révélateur qui permet de faire apparaître celle-ci on continue ensuite par passer notre plaque dans une laveuse(seconde photo) celle-ci est composé de plusieurs solution chimique qui vont permettre d’enlever le surplus de cuivre et pour finir on passe a l’étamage des pistes.

Ensuite après y avoir souder chaque composant a son emplacement voici le résultat

19359254_674046116133684_846436720_o


 

4. Programmation

 

Lors de la programmation la tache fut assez rude car il a fallu prendre en compte beaucoup de paramètres liés au type de terre et d’autres lié au composant électronique utilisé lors de la création du circuit imprimé. Voici un prototype du programme qui n’a malheureusement pas pu être testé a cause d’un manque de temps et d’effectif :

#!/usr/bin/env python
import time
import os
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

def readadc(adcnum, clockpin, mosipin, misopin, cspin):

if ((adcnum > 1) or (adcnum < 0))
return -1
GPIO.output(cspin, True)
GPIO.output(clockpin, False)
GPIO.output(cspin, False)
commandout = adcnum
commandout |= 0x18
commandout <<= 3

for i in range(5):
if (commandout & 0x80):
GPIO.output(mosipin, True)

else:
GPIO.output(mosipin, False)
commandout <<= 1
GPIO.output(clockpin, True)
GPIO.output(clockpin, False)
adcout = 0

for i in range(12):

GPIO.output(clockpin, True)
GPIO.output(clockpin, False)
adcout <<= 1

if (GPIO.input(misopin)):
adcout |= 0x1
GPIO.output(cspin, True)
adcout /= 2
return adcout
SPICLK = 19
SPIMISO = 13
SPIMOSI = 6
SPICS = 5
SPIRELAY = 2
GPIO.setup(SPIMOSI, GPIO.OUT)
GPIO.setup(SPIMISO, GPIO.IN)
GPIO.setup(SPICLK, GPIO.OUT)
GPIO.setup(SPICS, GPIO.OUT)
GPIO.setup(SPIRELAY,GPIO.OUT)

While true :

adcnum = 0
read_adc0 = readadc(adcnum, SPICLK, SPIMOSI, SPIMISO, SPICS)
volts0 = read_adc0 * ( 3300.0 / 1024.0)
print « \tvaleur brute 1 : %s » % read_adc0
print « \ttension 1 : %s volts\n\n » % volts0
if volts0 <= 1.5
GPIO.output(2,GPIO.HIGH) #sortie 2 à 1L

elsif volts0 >1.5
GPIO.output(2,GPIO.LOW) #sortie 2 à 0L

time.sleep(1)

Normalement pour l’instant ce programme sert a mesure l’humidité du sol sur un seul type de terre(sol humide) mais comme dit précédemment je n’ai pas eu le temps de le tester.

Pour une meilleur compréhension du programme, du début  jusqu’à la boucle « while » ce sont les configuration du MCP3008 puis ensuite il y a notre code.


 

5. Packaging

 

Enfin nous voici a la partie final qui permet de voir si tous les effort fournie tous au long de ce projet on aboutie a un dispositif qui répondra ou non au cahier des charge et au CDCF(cahier des charge fonctionnel)  défini au début du projet, grâce au machine disponible a l’IUT lab voici le résultat des découpe faite a la machine laser qui ma permis de découpé mais plaque :

vue eclaté

Ensuite après avoir assemblé toute ces pièces et les composant voici le résultat :

19401099_674801139391515_802661941_o

On observe dans cette boite 2 partie différente :

19402573_674801059391523_856599959_o

  • Partie électrovanne : Cette partie se compose uniquement de l’électrovanne d’un tuyau d’arrivé d’eau(gauche) et un tuyau pour l’irrigation du sol(droite).

19401135_674801069391522_1830698318_o

  • Partie électronique : Cette partie se compose du circuit électronique réalisé, du raspberry et du capteur qui se situe a l’extérieur.

Pour finir après avoir ferme la boite voici le résultat final:

photo_projet



Conclusion

 

Pour conclure, ce projet ma  permis de découvrir de nouvelles choses comme: la gestion d’un projet, le travail en équipe, la démarche à suivre pour arriver au bout d’un projet, certaines nouvelles méthodes. De plus, cela ma permis d’approfondir mes connaissances dans différent domaine. Enfin pour finir au cour de ceux projet j’ai eu a surmonté d’innombrable échec (surtout dans la réalisation de la carte électronique a cause de composant introuvable dans le magasin ce qui ma obligé a changer ma carte et lors de l’impression le noir n’été pas assez puissant ce qui a rendu mais piste fragile …) et problème surtout dû au membre de mon groupe qui on tous décidé de quitté le DUT GEII pour continuer ailleurs ce qui ma valu de travailler pour 4.



 

 Perspectives d’évolution

 

Si notre dispositif devait être commercialisé a la fin des heure qui lui ont été consacré alors, on peut dire sans trop de doute  que notre dispositif peut nettement s’améliorer en tout point tant en terme d’esthétique que de logistique ou encore de fonctionnement ou de précision des mesures. Notre projet peut encore grandement s’améliorer sur certain point comme par exemple en changeant le capteur (conductivité thermique) par un TDR pour nettement augmenter la précision ou encore pour l’électrovanne la changer par une a commande proportionnel qui permettrais de régulé le flux d’eau et donc de mieux doser l’eau qui sert a irriguer ou encore lors de la création du packaging utilisé des matériaux résistant au intempérie, etc… . Tout cela pour dire que notre projet a encore une grosse marge de progression avant de pouvoir être commercialisé sur le monde du marché.



 

Remerciements

 

L’IUT de Mulhouse ainsi que l’IUT LAB pour le budget et l’apport de matériels.

Nos professeurs encadrants Mr Haulcoeur et Mr Xu.

Projet_IUTLab_avec_IUT_de_Mulhousetéléchargement

 

 

 

 


Robot à l’Ecole

Capture d’écran 2017-03-15 à 16.51.18

 

 

robot école

 

Robot Collaboratif

 

 

Créé par notre groupe, Meanlicx est un robot collaboratif capable d’assister une institutrice ou un instituteur. Le robot s’intègre rapidement dans un environnement scolaire existant en installant simplement un suivi de ligne métallique au sol pour lui permettre de se déplacer sereinement dans la salle de classe. La robotique collaborative fait le pari d’une équipe éducative Homme/Robot performante et productive : le robot suit des tâches répétitives de distribution de matériel permettant à l’institutrice de ne pas perdre de temps à cette tâche.

 

Equipé d’un système de caméra embarquée, comprise dans le robotino, le robot est capable de reconnaître les formes programmées pour connaître les différents points d’arrêts, détecter la présence d’objets, de personnes et peut ainsi éviter les collisions. Le robot est capable de détecter le niveau de volume sonore en alertant son entourage grâce à un dispositif de leds tricolores. De plus, un élève absent peut tout de même avoir l’impression d’assister au cours via YouTube grâce à une fonction de téléprésence.

 

Capture d’écran 2017-06-26 à 12.05.46

 

 


 

Sommaire :

 

1. Introduction

2. Présentation du sujet

3. Cahier des Charges

  • Objectifs du projet
  • Diagramme Pieuvre
  • Fonctions et contraintes
  • Contraintes
  • Définition de termes techniques essentiels 
    • Arduino
    • Raspberry Pi
    • Capteurs

4. Budget détaillé

5. Développement

6. Gestion de projet

7. Manuel Technique

8. Bilan

9. Bibliographie

10. Remerciements

 


1. Introduction

 

Dans le cadre du module Etudes et Réalisations du deuxième semestre en DUT de GEII (Génie Electrique et Informatique Industrielle), il nous est demandé de réaliser par groupe un projet imposé et présenté par les professeurs qui s’inscrit dans notre programme pédagogique. 

 

 

2. Présentation du sujet

 

« Robot Collaboratif » est un sujet qui consiste en la création d’un robot, défini selon les souhaits des élèves d’une classe de CE1. Après avoir rencontré ces élèves de l’école Lamartine à Illzach pour partager nos connaissances en robotique, ils nous ont proposé des idées de robots qui leur seraient utiles. En faisant un tri dans leur propositions et après concertation au sein du groupe, nous avons choisi de concevoir un robot qui se déplace dans la salle de classe en délivrant aux élèves des objets que l’institutrice veut leur distribuer. De plus, si un élève est absent à l’école, il peut tout de même avoir l’impression d’être présent grâce à la fonctionnalité de téléprésence qui lui permet de suivre le cours depuis chez lui.

 

Bête à cornes - Robot collaboratif

 

 

3. Cahier des Charges

 

 

  • Objectifs du projet

L’objectif principal de ce projet est de faire découvrir la robotique à des élèves en classe de CE1 puis  de leur créer un robot qui répondra à leurs attentes. Cependant, les objectifs secondaires à prendre en compte sont :

– L’organisation de notre rencontre avec les enfants le lundi 6 mars au matin en leurs proposants différents défis et activités pédagogiques pour leur faire découvrir la robotique ;

– La création de quelques modèles de robots Mindstorms à montrer aux élèves ;

– La conception du prototype avec la programmation des moteurs des capteurs, la structure mécanique, l’interface Homme-machine, le déplacement du robot ;

– La présentation de notre prototype aux enfants le mercredi 31 mai ;

– La création du robot final.

Capture d’écran 2017-06-26 à 12.05.52

 

  • Périmètre

Puisque nous travaillons avec des élèves de CE1, il est nécessaire d’employer un vocabulaire qui leur est compréhensible. Il faut également que nos robots répondent à leurs attentes.

Du 2 au 31 mars, 60 heures sont entièrement consacrées à ce module dans l’emploi du temps. Deux professeurs encadrant sont à notre disposition afin de suivre et noter notre travail tout en restant à notre disposition pour tout besoin.

Nous avons également poursuivi le travail de la conception de notre robot jusqu’à la soutenance finale durant une centaine d’heures.

 

  • Fonctions et contraintes

Ce diagramme représente les fonctions principales (FP) de notre projet et les fonctions contraintes (FC) sont les fonctions auxquelles il est soumis.

 

Capture d’écran 2017-03-15 à 16.43.48Capture d’écran 2017-03-09 à 09.41.14

 

  • Contraintes 
    • Date limite : 31 mai 2017 pour la présentation du prototype aux enfants
    • Budget : 200 €

 

  • Définition de termes techniques essentiels 
  • Arduino

Un Arduino est un Microcontrôleur programmable ayant des entrées et des sorties et se programmant dans un langage très ressemblant au langage C et possédant un environnement de développement dédié. Toutes les connaissances et bibliothèques sur le développement de programme Arduino est libre d’accès.

  • Raspberry Pi

Une Raspberry Pi est un nano-ordinateur monocratique possédant son propre système d’exploitation sous Linux. Il permet de naviguer sur internet ainsi que développer des programmes et gérer des sorties.

  • Capteurs

Un capteur est un dispositif qui permet la transformation de l’état d’une grandeur physique observée en une grandeur utilisable.

 

Read More


Vision sur Robot TX60

Rapport projet TX60

Cahier des charges

 

  • Utilisation d’un robot six axes Stäubli TX60, équipé de son Teach et programmable via la suite logicielle Stäubli.
  • Utilisation d’une caméra noir et blanc intelligente NI1722 Smart Camera, programmée via le logiciel NI Vision Builder.
  • Connexion entre la caméra et le robot via une connexion Ethernet TCP.
  • Le robot doit être capable de reconnaitre des pièces de différentes formes, réparties sur une surface pouvant changer de taille et/ou de position.
  • Le robot ne doit pas entrer physiquement en contact avec la caméra.
  • La préhension des pièces se fera au moyen d’une ventouse qu’il faudra dimensionner et adapter au robot.

Objectif du projet

Ce projet doit mettre en place une interaction entre un robot six axes Stäubli TX60 et une caméra industrielle. Le but est de retirer des pièces de différentes formes du champ de vision de la caméra, en établissant une communication entre celle-ci et le robot afin de partager les coordonnées des pièces. Le robot doit ensuite retirer les pièces du champ de vision de la caméra, en fonction d’une « recette » dictée par l’utilisateur.

 

La caméra

La caméra utilisée pour le projet est une NI1722 Smart Camera. L’avantage d’avoir une caméra « intelligente » est de pouvoir se passer d’un ordinateur pour le traitement des images. Ainsi la prise de vue, la reconnaissance des pièces et le calcul de leurs coordonnées se fait directement du côté de la caméra et seules les coordonnées des pièces sont envoyées au robot.

 

Le robot

Le robot six axes Stäubli TX60 nous permet dans ce projet de déplacer les pièces. Il communique avec la caméra industrielle via une liaison Ethernet TCP, lui permettant de récupérer les coordonnées des différentes pièces. Le Teach  permettant de contrôler le robot manuellement et la suite Stäubli permet de créer et tester une bonne partie du programme directement sur un simulateur. Le programme peut aussi être modifié directement sur le Teach, mais le manque d’ergonomie le destine surtout à faire des modifications sur le terrain.

 

La ventouse

La ventouse, couplée à un générateur de vide type venturi, est de taille très réduite. L’avantage d’une petite ventouse est de pouvoir avoir une erreur plus importante lors du pointage des pièces par le robot. L’ensemble, monté sur un support fixé au bout du bras du robot, est relié à l’arrivée d’air via le système pneumatique du robot. La ventouse et le générateur de vide ont été acheté sur le site https://www.smc.eu/portal_ssl/webpages/01_products/products.jsp sous les références :

  • ZPT10BF-A6 pour la ventouse
  • ZH05DL-06-06-06 pour le générateur de vide

Ventouse TX60Venturi TX60

 

 

 

 

Le fonctionnement

 

Le programme permettant la manutention des pièces se résume en plusieurs étapes :

  • La définition du repère caméra : le support de travail est doté de 3 points permettant de définir le repère de la caméra. Une fois le support et les trois points de repère placés dans le champ de vision de la caméra, celle-ci créé automatiquement le repère et calcule la variable permettant de faire la conversion millimètres / pixels.

Acquisition de l’image :Acquisition TX60

Binarisation de l’image :Binarisation TX60 Définition du repère de la caméra :Definition repere TX60

 

  • Importation des coordonnées des pièces : pour cela, il suffit d’aller dans le menu correspondant et de sélectionner les coordonnées des pièces qui nous intéressent. Le robot va ensuite demander à la caméra de faire une prise de vue et de renvoyer les coordonnées des pièces en pixels, puis faire la conversion pixels/millimètres via une variable nConversion calculée au préalable. Les coordonnées de chaque pièce s’affichent une fois acquises par le robot.

Conversion TX60

 

 

  • Sélection de la « recette » : ce menu permet à l’utilisateur de choisir les pièces qu’il souhaite conserver dans le champ de vision de la caméra. Une fois que les pièces à conserver sont sélectionnées, le robot va automatiquement retirer les pièces indésirables et créer une pile de pièces pour chaque forme. Il serait aussi possible de faire l’inverse, en remplissant une boîte avec les pièces demandées par exemple. Après avoir fini sa manœuvre, le robot retourne en position initiale et attend l’acquisition de nouvelles pièces et/ou d’une nouvelle recette.

Recette

 

Conclusion

Ce projet nous a permis d’améliorer nos compétences sur certains points. Pour commencer, l’utilisation réelle d’une caméra industrielle apporte plusieurs manières de traiter un même problème de vision industrielle. Il faut prévoir l’éclairage, le fond sur lequel travailler en fonction de la couleur des pièces, ou encore la distance de focalisation de la caméra. La partie robotique, quoique plus facile à programmer grâce à la possibilité de faire une simulation sur le logiciel Stäubli, nous a néanmoins posé quelques problèmes de communication avec la caméra. Pour finir, nous pouvons dire que le projet pourrait être approfondi en prenant en compte la possibilité d’avoir plusieurs pièces de même forme, ou travailler en tenant compte des couleurs, ce qui nécessiterait un changement de caméra.

Projet réalisé par BOYARD André-Julien et SINGER Vincent.


Déstockage par Robot TX40

Projet déstockage par robot Tx40

 

Membre du groupe

MULLER Quentin et DUBY Luc

 

Présentation du projet

 

Ce projet consiste à utiliser le robot Tx40 et l’automate de stockage. Le but de ce projet est grâce au robot de chercher les pièces de l’automate de stockage, de les prendre puis de les déposer en palette par colonne de deux pièces. L’utilisateur pourra choisir quelle pièce il voudra prendre (rouge, noir ou métallique) et/ou faire des combinaisons telles que rouge/noir ou bien métallique/rouge par exemple.

 

 

Présentation de l’équipement

 

Pour ce projet, nous avons utilisé le robot Tx40, c’est un robot articulé avec 6 degrés de liberté de la marque Stäubli.

 

 

robot
Robot Tx40

 

 

Nous avons aussi utilisé l’automate de stockage pour amener les pièces dans le bon compartiment. C’est un automate de la marque Siemens que nous avions déjà vu en première année en API.

 

 

siemens
Automate de stockage

 

 

Réalisation

Pour la réalisation de ce projet, nous avons utilisé différents logiciels de programmation.

  • Pour la partie automate, nous avons utilisé le logiciel Siemens TIA Portal. Cela permet des programmer des automates (API) grâce à des programmes en ladder.

 

ladder
Programmation du choix des différentes pièces

  • Pour la partie robot, nous avons programmé grâce au logiciel Staubli ou directement grâce à la commande du robot.

 

 

          Commande

commande

 

Programmation

progra
Programme du start qui défini le menu de choix

 

                                                                                  

La programmation du robot est la partie la plus importante du projet, la plus longue et la plus difficile. Durant la programmation nous avons quelques problèmes comme le problème de collision avec l’automate quand le robot prend les pièces ou alors quand le robot ne peut pas aller à un endroit dû à un encombrement. Le fais de programmer directement sur la commande à été difficile et long car nous avons jamais fais cela avant. Le deuxième problème à été que le robot ne faisait pas exactement ce que la simulation montrait.

 

Rendu visuel du projet

A ce jour, le robot empile correctement chaque recette (r/r, n/n,m/m,n/m,n/r et r/m). Ce qu’il manque encore est le fais de faire plusieurs recettes à la fois, car il y a un problème dans les transformées du programme.

Nous n’avons pas réussi à arriver à la partie communication entre le robot et l’automate qui nous permettrait une gestion de nombre de pièce grâce aux différents compteurs.

 

Semestre 4

 

Présentation du projet

La suite du projet consiste à utiliser le robot Tx40 et l’automate de stockage. Le but de ce projet est, grâce au robot, de chercher les pièces de l’automate de stockage, de les prendre puis de les déposer dans chaque emboitement des différents socles. L’utilisateur pourra choisir quelle pièce il voudra prendre (rouge, noir ou métallique) et/ou faire des combinaisons telles que rouge/noir ou bien métallique/rouge par exemple.

 

Création de socle

Nous avons du créer deux socles grâce à une machine de découpe au laser, les différentes pièces s’emboiteront dans chaque emboitement un a un.

 

Image1
Socle en bois

 

Programmation

Après avoir étudié le nouveau but du projet, nous avons regardé si nous pouvions reprendre des parties de notre ancien programme. La partie du programme de prise des pièces est inchangé, mais toute la partie dépose a du être refaçonner.

Image2

 

Communication

Un autre but du projet était de mettre en place un communication TCP/IP entre l’automate et le robot Tx40 pour pouvoir connaitre le nombre de pièces dans l’automate.

 

 

Image3
Automate programmable industriel

 

 

Image5
Robot Staubli Tx40

 

Image4
Programme de communication TCP/IP

 

Nous avons d’abord essayé une communication local grâce à un hyperterminal. Nous avons pu envoyer un caractère qui correspondait à la détection de pièce dans l’automate. Cet essai à réussi et donc nous avons pu passer à l’étape suivante.

Nous avons alors essayer la communication entre le robot et l’automate sans succès.