Course en Cours Carrosserie

Sommaire

  1. Présentation du projet
  2. Cahier des charges
  3. Conception
  4. Coût financier
  5. Usinage
  6. Conclusion

I/ Présentation du projet :

Course en cours est une compétition annuelle dont le but est d’imaginer, concevoir, construire et faire courir un véhicule doté, d’une motorisation électrique. Il n’y a pas de direction car la voiture ne devra rouler qu’en ligne droite. Différentes épreuves seront proposées tels qu’une course de rapidité sur 15 mètres, le temps de réaction (déclencher le départ du véhicule le plus rapidement possible), ainsi qu’une épreuve d’arrêt au stand

Dans le cadre de notre projet différentes tâches sont demandées. La collaboration entre 2 étudiants GEII ET 6 étudiants GMP sera nécessaire afin de mener à bien le projet.

Le travail des étudiants GMP et GEII est répartie en 4 groupes :

-Conception et réalisation des roues (2étudiants GMP)

-Conception et réalisation du châssis (2étudiants GMP)

-Conception et réalisation de la carrosserie (2étudiants GMP)

-Connectique et liaisons des systèmes électronique du moteur (2étudiants GEII)

Notre partie consiste en la réalisation de la carrosserie, pour cela nous devons respecter un cahier des charges imposé par le règlement de course en cours

Dans ce projet nous allons tout d’abord étudier le sujet avec l’analyse du cahier des charges, puis concevoir notre coque à l’aide du logiciel inventor et enfin fabriquer notre carrosserie en utilisant le procédé de stratoconception et thermoformage ainsi que du prototypage rapide pour réaliser l’aileron

II/ Cahier des charges
1)Diagramme des prestations

2)Diagramme des interacteurs

3)Tableau de caractérisation

Description fonctionnelle : Diagramme FAST

Le diagramme FAST (Function Analysis System Technic) indique comment une fonction de service est réalisée à l’aide de fonctions techniques. Il met en évidence une hiérarchie entre les fonctions techniques.

III) Conception

Choix de l’échelle du modelé

Création des plans nécessaire à la conception

Modélisation de l’aileron en 4 pièces

IV) Coût financier

Pour la partie carrosserie les coûts seront assez faibles, ils correspondent uniquement à l’achat des matières premières comme les plaques de medium pour stratoconception ainsi qu’à la plaque de pvc pour thermoformage, et de la visserie.

Ce qui fait un total de 44,4 euros TTC

V) Usinage

Usinage du moule en stratoconception

La stratoconception est un procédé de prototypage rapide qui consiste à décomposer la pièce en un ensemble de couches élémentaires appelées strates de les usiner et ensuite les assembler afin d’obtenir la pièce entière.

Sur les photos ci contres vous pouvez voir notre modèle CAO que nous avons découpé en 10 couches de 9 mm. Que nous avons ensuite usiné puis assemblé en les collant   

Prototypage rapide de l’aileron

Prototypage rapide des logos

Assemblage coque et aileron

  1. En raison de la situation actuelle nous n’avons pas réussis à thermoformer notre coque qui aurait par la suie dû être peinte et assemblé à l’aide de 4 goupilles sur le châssis de la voiture.

Ce projet nous a tout de même permis de travailler en équipe tout en collaborant avec les autres groupes du projet course en cours afin que tout le monde puisse respecter son cahier des charges. Grace à ce projet nous avons également découvert la démarche à effectuer en passant du cahier des charges, le choix de solutions technique, la conception ainsi que la fabrication pour pouvoir mener un projet à bien.


Eolienne – 2019

 Remerciements


Nous souhaitons dans un premier temps remercier l’IUT de Mulhouse, pour nous avoir permis de réaliser ce projet.

Nous remercions également tous nos professeurs pour les connaissances qu’ils nous ont transmis durant ces deux années de DUT GEII et tout particulièrement M.Steger ainsi que M.Cudel pour l’accompagnement dont nous avons bénéficié tout au long de la réalisation de ce projet.

Enfin nous remercions nos camarades pour leur aide lors de la rédaction de ce rapport.

Membres du projet :

  • Guilhem LEMAIRE
  • Loïc SCHMITT
  • Louise RIEFFEL

Sommaire


  1. Présentation du projet
  2. Analyse fonctionnelle
  3. Éolienne HY-600
  4. Equipements sélectionnés
  5. Dimensionnement des câbles

1. Présentation du projet


Dans le cadre d’un projet GEII, nous devions remettre en fonctionnement une éolienne pour l’IUT de Mulhouse. L’éolienne sur laquelle nous devions travailler était destinée à la casse suite à la démolition du site sur laquelle elle était installée, mais a été récupérée par l’IUT pour pouvoir la réutiliser. Malheureusement des parties étaient manquantes. L’IUT a pu récupérer uniquement la structure de l’éolienne, il nous faut alors reconstituer toute la partie électrique allant de pair avec l’éolienne. Nous disposons donc des pales, du moteur de l’éolienne, ainsi que de son mat.

2. Analyse fonctionnelle


Problématique : Réhabiliter et installer une éolienne sur le site de l’IUT de Mulhouse.

Ce diagramme répond au besoin en 3 questions : A qui ? / Sur quoi ? / Dans quel but ?

L’intérêt d’une éolienne est de transformer l’énergie cinétique du vent en une énergie électrique :

Schéma explicatif des composants d’une éolienne :

Fonctionnement souhaité de l’éolienne : L’éolienne génère de l’énergie électrique, cette énergie est ensuite transmise au contrôleur qui (?), l’énergie est ensuite stockée dans la batterie. L’onduleur est lui raccordé à la batterie ainsi qu’au réseau électrique. Si il reste de l’électricité dans la batterie, l’onduleur transfert cette électricité au réseau électrique de l’IUT, sinon il transfert à l’IUT l’énergie provenant du réseau électrique général.

Il nous fallait alors trouver les équipements suivants :

  • Contrôleur -> Régulateur de charge
  • Batterie
  • Onduleur
  • Connecteur de charge (celui initialement présent dans l’éolienne était défectueux)

3. Éolienne HY-600



Avec la référence trouvée sur l’éolienne nous avons pu trouver les documentations suivantes :

  • Phaesun : Small ind Turbie User Manual HY-400, HY-600, HY-1000
  • Windmax : Wind Turbine Guidbook HY-400, HY-600, HY-1000, HY-2000, HY-3000

Nous ne pouvons pas être sûrs qu’une de ces documentation correspond parfaitement à l’éolienne que nous disposons mais elles apportent des informations intéressantes qui nous serons plus qu’utiles pour la suite du projet.

On relève alors les informations issues des diverses documentations :

  • Plus la vitesse moyenne du vent est élevée, plus l’éolienne sera génératrice d’énergie. La puissance disponible dans le vent augmente avec le cube de la vitesse du vent. Une turbulence plus faible entraîne également plus de puissance.
  • Les obstacles (arbres, bâtiments, etc.) réduiront la vitesse du vent et, par conséquent, dégraderont les performances de l’éolienne. Une tour immédiatement sous le vent d’un bâtiment doit avoir au moins deux fois sa hauteur.
  • Un dimensionnement correct des fils est important pour la sécurité et l’efficacité énergétique. Des câbles sous-dimensionnés entraîneront une perte d’énergie dans le système, créeront une surchauffe et augmenteront le risque d’incendie. Plus la taille du fil est grande, plus la perte d’énergie est faible. Cependant, les câbles de plus grande taille sont plus coûteux.

4. Equipements sélectionnés


Régulateur de charge

Nous avons choisi un régulateur de charge capable de charger des batteries 12/24V, qui fonctionne en mode standard (régulateur d’éolienne seule) ou en mode hybride (éolienne/solaire). La puissance de cet équipement est à 600w car c’est la puissance crête produite par notre éolienne.

 

 

Pour l’instant on souhaite utiliser cet équipement en mode standard, mais la perspective du mode hybride est une bonne chose pour permettre, dans le futur, la modification et/ou l’amélioration du système actuellement souhaité.

 

Batteries

Recherche de deux batteries  correspondant aux caractéristiques du régulateur de charge :

Fonctionnement des batteries selon leur assemblage:

On dispose les batteries en série pour  additionner les tensions et obtenir une tension de sortie de 24V.

On obtient alors les caractéristiques suivantes :

  • Une puissance de 600W
  • Une tension de 24V
  • Un courant de : 600/24 =25A
  • Une capacité de 75Ah ou de 50Ah, selon le modèle de batterie choisi

5. Dimensionnement des câbles


De l’éolienne au régulateur

Nous avons 40 mètres qui séparent l’éolienne du régulateur.

Ayant une puissance P = 600W et une tension U = 24V on en déduit la relation P = U*I*√3

D’où : I =P/(U∗√3) =600/(24∗√3)  ≈ 15A

Chute de tension pour : S = 10 mm² et L = 40m

Chute de tension pour : S = 16 mm² et L = 40m

Un câble d’une section de 16mm² garantissait une plus faible chute de tension, mais après réflexion, en fonction de nos besoin et pour des raisons budgétaires, on choisira un câble de section 10mm².

D’après les caractéristiques ci-dessus nous avons choisi le câble suivant :

 

 

Du régulateur à la batterie

10 mètres séparent le régulateur des batteries.

A la sortie du régulateur nous avons une puissance P = 600W et une tension U = 24V

D’où I = P/U =600/24  ≈ 25A

 

Chute de tension pour : S = 6 mm² et L = 10m

Sachant qu’en sortie du régulateur nous sommes en monophasé, nous avons choisi les deux câbles suivants :

Cosse batterie + Embout de câble 6mm²

Du côté du régulateur le câblage se fera à l’aide d’embouts, du coté de la batterie le câblage se fera à partir de cosses à  oeillet.

 

 

Du régulateur à l’onduleur

10 mètres séparent le régulateur de l’onduleur. A la sortie du régulateur nous avons une puissance P = 600W et une tension U = 24V

D’où I = P/U =600/24  ≈ 25A

Chute de tension pour : S = 6 mm² et L = 10m

Sachant qu’en sortie du régulateur nous sommes en monophasé, nous avons choisi les deux câbles suivants :

 

 

 

De l’onduleur au réseau IUT

Sachant qu’en sortie de l’onduleur nous sommes en triphasé, nous avons choisi le câble suivant :

 

 

Liaisons équipotentielles

30 mètres séparent l’éolienne du point de terre, on pourrait prendre une section similaire à celle du câble de l’éolienne jusqu’au régulateur mais pour question de sécurité on prendra du 16mm²

Ci dessous le câble choisi :

Choix de la cosse :

On a choisi de percer le mât afin de pouvoir y fixer le câble de mise à la terre à l’aide de cosses.

Conclusion


Fin mars/début avril nous avons eu la responsabilité de remettre en état une éolienne qui allait partir à la casse. La structure était conservée, mais la partie électrique de l’installation n’a pu être récupérée.Il nous fallait donc reconstituer cette partie.

Nous avons alors effectuer des recherches sur les différents équipements à intégrer afin de reconstituer l’installation.

Nous avons alors pu identifier et commander les équipements de base nécessaires au fonctionnement du système souhaité :

  • Contrôleur
  • Batterie
  • Câbles

Il ne reste plus qu’à trouver l’onduleur et connecteur de charge qui assurera la liaison entre le moteur et le régulateur ainsi que toute la partie concernant la protection de l’ouvrage.

Webographie




Image principale éolienne :https://www.amazon.fr/TOPQSC-R%C3%A9sidentiel-Imperm%C3%A9able-D%C3%A9marrage-Efficacit%C3%A9/dp/B071QWM9RX/ref=sr_1_28?keywords=Mini+eolienne&qid=1560246280&s=gateway&sr=8-28

Image éolienne schéma : <a href=https://fr.pngtree.com>Graphiques de pngtree.com</a>

Schéma explicatif composants éolienne : https://www.connaissancedesenergies.org/quels-sont-les-constituants-d-une-eolienne-130125

Régulateur de charge : https://www.future-tech.fr/regulateur-de-charge-solaire-eolienne-12v-24v-600w,fr,4,757.cfm

Batterie 75Ah : https://fr.rs-online.com/web/p/batteries-au-plomb/7270439/

Batterie 50Ah : https://fr.rs-online.com/web/p/batteries-au-plomb/8720096/


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.


Bobineuse d’imprimante 3D


I.           Introduction

II.         Cahier des charges

     1)      « Bête à corne » : énoncé du besoin

     2)      Diagramme « pieuvre » : analyse des besoins

     3)      Contraintes

III.         Conception

     1)      Solution retenue : schéma cinématique

     2)      Calcul du rapport d’engrenages

     3)      Modélisation

     4)      Définition du nombre de tour de la bobine

IV.         Réalisation

V. Conclusion

 

I.                   Introduction

Le projet tuteuré de notre DUT a pour objectif de réaliser un système permettant de rembobiner le fil d’imprimante 3D d’une bobine achetée sur une bobine type de l’imprimante afin de faciliter la le transfert.

Nous sommes deux étudiants de GMP à réaliser ce projet :

VUILLEMIN Joffrey
CONSALVO Matteo

II.                Cahier des charges

 

1)     « Bête à corne » : énoncé du besoin

 

 

2)     Diagramme « pieuvre » : analyse des besoins

 

FP1 : Permettre à l’utilisateur de rembobiner un fil facilement et sans effort.

FP2 : Transmettre le fil d’une bobine achetée sur la bobine type de l’imprimante.

FC1 : S’adapter à la diversité de bobine achetée.

FC2 : Permettre à l’utilisateur une mise en place rapide du système.

FC3 : S’adapter à l’énergie du secteur.

FC4 : S’adapter à l’environnement : être maniable.

3)     Contraintes

Pour réaliser le système, nous sommes libres de sa conception mais avec quelques contraintes :

  • Enrouler une bobine de 1 kg de fil d’ABS de Ø 1,75mm
  • Temps pour l’enroulage : +/- 1h
  • Vitesse max de la bobine : 150tr/min
  • Variété de bobine achetée
  • Enrouler le fil de façon à faire des spires propres
  • Un seul moteur pour la rotation de la bobine et le guidage du fil
  • Budget de 500 €

III.              Conception

1)     Solution retenue : schéma cinématique

Nous avons décidé de réaliser ce système avec une liaison crémaillère et demi-pignon afin que ceux-ci, qui tournent dans le sens opposé, font faire des aller-retours à la crémaillère de la distance de la largeur de la bobine pour enrouler le fil de manière propre. Nous avons alors réalisé une suite d’engranges comme sur le schéma cinématique suivant :

2)     Calcul du rapport d’engrenages

Largeur de la bobine = 56mm

Diamètre du fil = 1,75mm

S=R*θ

Or on veut un angle d’entrainement pour chaque demi pignon de π rad.

On peut donc déterminer le rayon primitif : 56/π =17,825mm

La condition pour que la bobine enroule le fil de façon correcte : 1 tour bobine doit correspondre à une avance de 1,75mm

Il faut donc que le pignon tourne d’un angle de 1,75/17,825=0,09818 rad quand la bobine fait un tour.

On détermine donc le rapport de réduction qui est de 0,09818/2π= 0,01563

R=0,01563

R=(Z1*Z3) / (Z2*Z4) = 0,01563

En prenant Z1=Z3=17

Et Z2=Z4=136

On obtient un R=0,015625

3)     Modélisation

Pour commencer la conception, on a d’abord réalisé un squelette pour définir l’emplacement de chaque engrenage et chaque axe. On a donc pu ensuite réaliser le bâti.

Pour le concevoir, on a pris en compte les entraxes entre les différents engrenages pour ainsi créer les différents supports. Ensuite on a réalisé chaque axe en faisant son assemblage pour créer ainsi des chaines de côtes et avoir une cotation fonctionnelle des arbres. On a ensuite réalisé les plans de fabrications des différentes pièces à fabriquer.

Pour avoir un réglage possible des entraxes des pignons, on a décidé d’attacher les axes au bâti avec des vis et avec un trou de passage permettant du jeu.

Afin de pouvoir régler la position d’un des deux demi-pignon, on a ajouté une plaque réglable axialement permettant de contrôler la position du demi-pignon qui lui sera fixé dessus.

Pour régler la position de la crémaillère on a mis des trous oblongs sur celle-ci pour son réglage par rapport à un axe et sur le bâti pour son réglage par rapport à la crémaillère :

 

Pour la réalisation des plans, on a fait les chaînes de côtes afin de coté l’arbre fonctionnellement. En voici quelques exemples :

        

 

 

 

4)     Définition du nombre de tour de la bobine

Pour que le moteur s’arrête de tourner, on a prévu un capteur qui va compteur le nombre de tour et qui va s’arrêter à un certain nombre. Celui-ci va être défini de la manière suivante :

Il faut qu’on rembobine 1kg de fil ce qui correspond à 410 m de fil. La largeur de la bobine étant de 56 mm et le fil de diamètre 1.75 mm. On peut donc faire 32 tours par rangée de fil sur la largeur de la bobine. Le diamètre de la bobine vide est de 148mm. On a donc une suite arithmétique pour calculer le nombre de tour pour arriver à 410m : Un = (32*π*148) + 0.351n

On trouve r= 0.351 car à chaque tour on ajoute 1.75*2 au diamètre d’enroulement :

U1=32*π*(148+2*1.75) = 15,230 m

U0=32*π*148 = 14,879 m

Donc r = 15,230-14,879 = 0.351 m

On a donc la relation suivante : Un = 14.879 + 0.351n

Avec la formule de la somme des suites arithmétiques, on trouve que U0+U1+……+U21 = 408.42m

Il faut donc que la bobine fasse 21*32 = 672 tours pour qu’elle ait rembobiné 1 kg de fil.

IV.             Réalisation

Pour la réalisation des pièces, nous avons décidé d’usiner à la machine traditionnelle les axes et les supports. De plus, nous avons réalisé le bâti en aluminium en découpe jet d’eau. Nous voulions créer notre série d’engrenages avec cette machine découpe jet d’eau mais elle est tombée en panne. Nous avons donc changé de méthode et alors utilisé l’impression 3D en plastique pour les réaliser.

V.                Conclusion

 

Ce projet nous a permis de voir comment fonctionne le déroulement d’un projet, de la phase d’avant-projet, d’étude, de commande et enfin de réalisation. Manquant beaucoup de temps en atelier, nous n’avons pas pu finir la réalisation.


Course en cours 2019

LE PROJET COURSE EN COURS

Objet : Concevoir et réaliser un modèle réduit de voiture à moteur électrique dans le but de participer à la finale de course en cours se déroulant à Paris le 05 Juin 2019

 

Tout d’abord, nous devions respecter un certain nombre de contraintes comme les dimensions du véhicule, le poids, le moteur imposé…

Nous étions un groupe de 3 étudiants constitué de 2 GMP et un GEII :  – Delimata Thomas – Nambot Maxime  –  Meyer Robin

Notre équipe, composée de 3 passionnés d’automobile, plus ou moins ancienne sellons les affinités de chacun, s’est orienté vers la conception d’une voiture au style néo-rétro, inspiré d’un modèle mythique des années 70 et 80, championne d’Europe de rallycross en 1977. Fabriqué par une marque qui vient de renaître de ses cendre dernièrement,nous parlons évidement de l’Alpine A310.

Pour faire plaisir à Maxime, on peut également retrouver des air de Bx dans le design de la caisse, mais chuttt….

De la conception à la réalisation de la voiture puis la course

La conception du châssis

Nous sommes partis dans l’idée de réaliser un châssis en impression 3D

 

 

Nous avons prévus des supports pour la batterie ainsi que notre moteur

Ci dessous, un éclaté de la voiture complète:

projetsgeii.iutmulhouse.uha.fr/…/eclate.pdf

La conception des autres éléments

Sur ce châssis, nous avons du prévoir des fixations pour un support d’axe avant.

Ce support d’axe a été réalisé en fraisage sur commande numérique à partir d’un brut en aluminium.

Robin s’est occupé de réaliser la FAO de cette pièce, et Maxime s’est occupé des réglages sur machine.

 

Afin de réaliser la liaison entre le support d’axe et les roues, nous avons usine des axes en acier à partir de diamètres existants. Robin s’est occupé de l’usinage des gorges pour les anneaux élastiques sur tour traditionnel ainsi que des logements pour l’alésage des roues. Maxime, de son côté à commander des roulements pour afin d’assurer la liaison entre l’axe et le support d’axe.

 

 

 

 

Ensuite nous avons fabriqué les roues en impression 3D avec un surmoulage en silicone, réalisé à l’IUT Lab.

Sur ces roues nous avons dû ajouter des créneaux et modifier la section pour la bonne cohésion de la matière lors de l’impression et la bonne adhérence du silicone lors du moulage, suivi d’un passage sous cloche à vide afin de retirer les bulles d’air prises au piège dans le silicone.

 

Une fois tous les éléments conçus, fabriqués, et finalisés, nous avons pu assembler la voiture et la faire rouler.

Puis la caisse a été conçue à l’aide du logiciel Créo.

 

Une fois le design validé, nous avons imprimé la caisse en 3D, en 2 parties assemblées par la suite. L’impression ne voulant pas fonctionner sur les imprimantes de l’IUT, la caisse ci-dessous a été imprimée sur l’imprimante personnelle de Maxime, une Creality CR10-S.

Ensuite viennent les finitions réalisées par Maxime : ponçage, masticage, 2ème ponçage au papier de verre de carrossier, mise en après, peinture, finitions, poses des autocollants et vernis.
Pour obtenir le résultat final suivant : Le but étant de rester fidèles aux codes esthétiques d’une voiture de rallye des années 80’s.

 

Projet innovation GEII

 D

La course à Paris

 

 Une nouvelle Apline A110 à l’entrée de l’événement Notre stand Les pistes

La concurrence est rude!

 

 


Baby Foot connecté 2019

Equipe de projet

  • BASLE Valentin (2ème année DUT GEII)
  • CHEMCHI Mochine (2ème année DUT GMP)
  • TOZLU Deniz (2ème année DUT GMP)

 

Introduction

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). L’objectif du projet est de rénover un baby foot pour en créer un baby foot connecté et confortable à jouer. 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.

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 !

 

PARTIE GEII

 

Etat des lieux

Nous avons retrouvé le baby-foot dans un état critique.

Les extrémités du baby foot comportant les buts se sont effondrées en conséquence les câbles et fils ont été endommagés

 

Partie Câblage:

– Câbles dessoudés, scotchés entre eux

– Cuivre de leds qui s’enlève

– Gaines abimées

  

Partie programmation :

-Carte micro SD endommagée, données perdus

 

Cahier des charges

Diagramme pieuvre :

 

Cahier des charges fonctionnel :

Budget

Prix : 185,92 €

Economie :  421,20 €

 

Câblage

Schéma électrique Baby-Foot Connecté

Programmation

Pour effectuer le programme j’ai utilisé le logiciel Node-Red

 

Il s’agit d’une application reposant sur Node.js, 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…

 

Palettes téléchargées pour réaliser le programme : 

 

 

               

 

Le programme est composé de 3 Menus

 

Pour lancer Node Red depuis le navigateur -> http://ADRESSE_IP_DE_VOTRE_PI:1880/

Les fonctions/blocs fonctionnels utilisés pour réaliser le programme :

 

Template : permet d’insérer du texte et des images. La programmation s’effectue en langage HTML.

Rpio gpio :Input gpio

Rpi gpio : Output gpio

Button : Permet l’ajout d’un bouton

Counter : Permet l’ajout d’un compteur

Trigger : Ce nœud peut être utilisé pour créer un délai d’attente au sein d’un flux. Par défaut, lorsqu’il reçoit un message, il envoie un message avec une charge utile de 1. Il attend ensuite 250 ms avant d’envoyer un deuxième message avec une charge utile de 0. Cela pourrait être utilisé, par exemple, pour faire clignoter une LED attachée à un poste.

Rising edge : Un noeud qui transfère son message entrant uniquement si la valeur numérique de la charge utile du message dépasse un seuil spécifié

Change: Définir, modifier, supprimer ou déplacer les propriétés d’un message, d’un contexte de flux ou d’un contexte global. Le nœud peut spécifier plusieurs règles qui seront appliquées dans l’ordre dans lequel elles ont été définies.

Text input : Ajoute un champ de saisie de texte à l’interface utilisateur. Le mode peut être un texte normal, un courriel ou un sélecteur de couleur.

Menu Princpal :

 

 

Menu Règles du jeu  :

 

 

Menu Score/Match  :

 

 

Le programme permet :

  • La détection de buts hors gamelles
  • L’affichage du score des deux équipes (score max 10)
  • Le clignotement des leds lors d’un but (bleu ou rouge en fonction de l’équipe qui à marqué)
  • Bouton remise à zéro permet de réinitialiser les score des deux équipes à 0
  • Boutons gamelles qui permet d’ajouter +1 à l’équipe qui marqué en réalisant une gamelle

 

Etude du capteur pour la détection de gamelles 

Pour la détection de gamelles nous sommes parties sur un capteur de vibration

SW-420 :

 

Principe de fonctionnement :

Le capteur serait installé sur une plaque métallique légèrement surélevée en bas (plaque métallique fixé dans la cage) ce qui permet de faire trembler la plaque et donc le capteur, qui pourra ensuite détecter un mouvement

Test de la détection de mouvement/ vibration sur python :

 

branchement du catpeur sur le rasberry pi

 

Programme sur python

 

Résultat :

Bilan :

Le projet n’a pas pu être terminé suite à l’état dans lequel était le baby foot et les données perdues de la micro SD du Rasberry PI

La remise en état physique + peinture (partie GMP ) du baby foot à mis plus de temps que prévu.

Pendant cette période le baby-foot n’était pas exploitable pour remettre en place le câblage et tester le programme.

Les plaques pour fixer les capteurs de vibrations n’ont pas été réalisées.

 

Solution pour remédier à ces problèmes :

 

Avoir les heures en commun avec les différents départements (GMP GEII)

-Définir un chef de projet

-Une meilleur communication et une meilleur écoute entre les départements

-Organiser des réunions hebdomadaires pour parler de l’avancement


Surveillance Parking


 

GAUDIOZ Alexandre | ZAID EL KHIL Damien

 


Sommaire

  1. Présentation du projet

    1. Contexte

  2. Cahier des charges

    1. Objectifs

    2. Ressources données

  3. Recherches effectuées

    1. Caméra et orientation

    2. Bibliothèques nécessaires

  4. Expérimentations

    1. Traitement d’image

    2. Système miniature

    3. Première version du programme

    4. Deuxième version du programme

  5. Application plus poussée

    1. Vitesse d’acquisition

    2. Analyse temporelle

    3. Deuxième version du programme

  6. Conclusion

    1. Améliorations envisageables

    2. Apports


Présentation du projet

Contexte

Notre projet « ParkWatcher » cherche à s’inscrire dans les nouveaux procédés de surveillance, partiellement ou entièrement automatisés. Basé sur un programme existant et popularisé ces dernière années, OpenCV. Notre projet consiste à traiter les images provenant d’une caméra de surveillance orientée sur un parking afin d’optimiser les nombre de véhicules pouvant y stationner en signalant tout manquement aux règles qui régissent les parkings privés et à établir des statistiques.

 

En effet, la démocratisation des véhicules particuliers pousse les institutions publiques et privées à aménager des endroits prévus pour accueillir ces derniers. Toutefois, le nombre croissant de véhicules utilisés au quotidien implique une difficulté à assurer la pérennité de ces endroits. Ces derniers temps, les parkings technologiquement équipés pullulent car nous sommes dans une optique de stockage de données afin de mieux répondre aux attentes des consommateurs, mais certains parkings ne peuvent pas s’offrir ce luxe car ils nécessitent une configuration adaptée à la lecture de plaques, à la disposition de capteurs inductifs, indiquant, avec un témoin lumineux, la disponibilité des places. C’est pour ces mêmes raisons que ces parkings sont généralement des parkings couverts.

exemple de technologie indiquant la disponibilité d’une place
Figure 1 : Exemple de technologie indiquant la disponibilité d’une place.

Mais qu’en est t il des parkings ouverts ? Le dispositif que nous avons développé est une alternative à ces infrastructures onéreuses, rendant le contrôle et l’acquisition de données plus accessibles.


Cahier des charges

Objectifs

Certains objectifs nous ont été imposés :

  1. Identification des véhicules : Détecter les différents éléments apparaissant sur le retour image de la caméra de surveillance et les identifier dans le but de les filtrer (dans notre cas, identification des véhicules et des piétons).
  2. Délimitation des places de stationnement et définition de leurs états : Identifier les places de stationnement, distinguer la disponibilité de l’emplacement, observer si un véhicule est bien ou mal stationné.
  3. Statistiques : à l’aide des relevés, établir des statistiques tels que : le temps de stationnement moyen, le nombre d’emplacements disponibles ou encore l’heure d’affluence.
  4. Affichage : Créer une interface propre, agréable, où ls statistiques et les informations sont clairement visibles et accessibles à tous les utilisateurs.

Carte heuristique détaillant les objectifs
Figure 2 : Carte heuristique détaillant les objectifs.

Ressources données

Pour mieux comprendre la suite, il est nécessaire de faire une brève présentation de ce qu’est OpenCV : OpenCV est une bibliothèque employée dans le traitement d’images. Elle est grandement appréciée car permet le traitement d’image en temps réel et est sous licence libre (BSD).

 

Afin de gagner du temps, un programme python nous a été fourni. Ce code permet d’utiliser le réseau de neurone généré par OpenCV afin de reconnaître des éléments appartenant à la base de donnée « Darknet ». Chaque élément à un identifiant propre qui lui est attribué; cet identifiant est contenu dans un “ClassId(XX)”, XX étant l’identifiant. Pour le projet nous nous sommes limités à reconnaître les personnes et les voitures, les autres véhicules n’étant pas censés circuler sur le campus et les autres objets ne présentant pas d’intérêt notable. Cette sélection est aisément modifiable.

Correspondance d’un élément avec un ClassID
Figure 3 : Correspondance d’un élément avec un ClassID.

Le programme affiche en sortie l’image ou la vidéo traitée, avec les éléments graphiques générés par OpenCV (les éléments tels que les visages, les ordinateurs, chiens, chats, voitures sont encadrés et leur nature est indiquée en haut du susdit cadre via un texte).

Exemple d’image que peut récupérer le programme de base OpenCV / Darknet à la fin de son exécution.
Figure 4 : Exemple d’image que peut récupérer le programme de base OpenCV / Darknet à la fin de son exécution.

En terme de matériel physique, il a été mis à notre disposition une Raspberry Pi 3 ainsi qu’une webcam. La Raspberry Pi 3 étant sous Raspbian, une distribution Linux, le python s’est imposé comme langage de programmation le plus adapté à nos besoins.


Recherches effectuées

Caméra et orientation

Nous avons effectué plusieurs tests pour déterminer quelle prise de vue est la plus adaptée au projet, et aux vues des méthodes présentées dans la partie « Expérimentations », la vue de dessus est un choix logique. Elle nous permet de biens distinguer les véhicules, et de bien les situer dans l’espace, à la différence d’une prise de vue oblique ou ras du sol.

 

Une webcam Logitech C170 nous a été fourni, sa résolution est suffisante pour le bon fonctionnement du projet.

Bibliothèques nécessaires

Après quelques recherches, nous avons établi une liste des bibliothèques nécessitant une importation dans notre programme python. Ainsi on y retrouve “time” et “datetime” qui servent à gérer le temps, que ce soit pour indiquer la date et l’heure actuelle ou pour calculer des intervalles de temps, déterminants la durée de stationnement d’un véhicule. Il y a aussi “numpy” qui est une extension du langage python permet d’effectuer certains types de calculs, “cv2” qui n’est autre que OpenCV, “matplotlib” qui apporte de nombreuses fonctionnalités au niveau de l’interface graphique et “collections” qui nous a aidé à gérer les couleurs.

Bibliothèques importées dans le programme principal final.
Figure 5 : Bibliothèques importées dans le programme principal final.


Expérimentations

Traitement d’images

 

Une fois l’image proprement récupérée et les véhicules reconnus, il a fallu identifier les places de parkings. Nous avons décidé de mettre un point à coordonnées X Y au centre des stationnements et de développer un algorithme qui aura comme seules coordonnées celles du point. Deux méthodes se sont présentées à nous : d’une part le mode manuel, qui consiste à entrer à la main les coordonnées des différentes places et d’autre part la détection de lignes par traitement d’image.

 

Le mode manuel consiste à entrer dans le programme la valeur de X et de Y à partir d’une image témoin (voir figure XX). Dans le programme, il se présente comme ceci : “TabPlaceXY = np.array([[100,257],[300,257],[500,257],…])” avec entre chaques crochets, le point [X,Y] du centre de la place. L’avantage de cette méthode est qu’elle est très simple à mettre en oeuvre et qu’elle est légère à compiler, ce qui n’est pas négligeable car OpenCV rend le programme lourd à compiler, que qui ralenti le nombre d’image par secondes. En revanche, si la caméra subit un mouvement, le programme devient caduc et une intervention est nécessaire pour modifier les coordonnées des points.

 

La détection de lignes est une méthode très intéressante, elle consiste à analyser l’image pour en extraire les lignes qui la compose, à partir de là, les places pourraient êtres identifiées automatiquement et actualisées en cas d’un mouvement de caméra; de plus, connaissant la taille moyenne d’une place de parking, l’algorithme pourrait s’adapter à tout parking, quelle que soit la hauteur de la caméra. Pour ce faire, nous avons utilisé la transformée de Hough qui repère les différences de contraste entre 2 pixels et si ces différences se perpétue à des endroits suffisamment proches, le programme en déduit qu’une ligne s’y trouve. OpenCV intègre la transformée de Hough, et nous permet de l’appeler comme suit: “cv2.HoughLinesp(edges,1,np.pi/180,100,minLineLenght,maxLineGap)”. Nous avons appris à nos dépens que pour utiliser cette méthode, une image très propre est nécessaire, nous l’avons donc expérimentée sur des images fictives (parking avec asphalt homogènement noir et lignes blanches parfaites) mais n’avons réussis à le porter sur système réel.

Transformée de Hough sur système réel.
Figure 6 : Transformée de Hough sur système réel.

Transformée de Hough sur une image parfaite.
Figure 7 : Transformée de Hough sur une image parfaite (Exemple 1).

Transformée de Hough sur image parfaite.
Figure 8 : Transformée de Hough sur une image parfaite (Exemple 2).

La méthode manuelle a donc été utilisée.

 

Ensuite, il a suffit de récupérer le barycentre du rectangle encadrant les véhicules (qui nous est donné par OpenCV) puis d’établir sa position par rapport au centre d’une place et ainsi, de voir dans quelle zone il se situe et donc, dans quelle zone le véhicule se situe.

Système miniature

Parking miniature.
Figure 9 : Parking miniature.

Suite au besoin évident de tester le programme, un environnement simulé était nécessaire. Un parking miniature a alors été réalisé avec des voiture miniatures. OpenCV nous a renvoyé le ClassId « 62 », autrement dit il voyait les voitures miniatures comme étant des téléphones portables; nous y avons remédié en traitant dans le programme, les téléphones portables comme des voitures; a noter que cela ne se produit pas uniquement avec les voitures miniatures mais avec toute voiture vue à la verticale.

 

À partir de ce modèle, nous avons réalisé différents cas de figures, mettant en évidence les qualités et les défauts du programme.

 

Les premières expérimentations ne furent pas probantes, en effet, les voitures n’étaient pas reconnues, du moins pas toutes, et pas tout le temps. Il nous fallu du temps pour s’apercevoir que le problème ne venait pas de notre programme mais de la luminosité. Ne pouvant bénéficier de la lumière naturelle en de bonnes conditions, nous avons utilisé un éclairage artificiel, à l’aide de nos smartphones comme visible sur la Figure 9. Le problème était résolu.

Première version du programme

Ayant une méthode d’approche et des ressources suffisantes, un premier programme a pu être conçu. En un premier temps les informations concernant l’état des places apparaissaient dans un terminal puis nous les avons intégrées au retour image pour plus de visibilité et de simplicité d’utilisation.

Situations dans lesquelles la première version du programme fonctionne bien.
Figure 10 : Situations dans lesquelles la première version du programme fonctionne bien.

On peut remarquer que dans ces 4 différentes situations, le programme fonctionne correctement, certes, l’interface graphique n’est pas très attrayante et reste peu lisible mais on peut y remarquer certaines fonctionnalités :

  1. Les véhicules sont reconnus et encadrés (L’affichage de la nature de l’objet « cell phone » est due à l’amalgame que fait OpenCV des voitures en vue aérienne comme expliqué précédemment).
  2. Les places sont numérotées et affichent un code couleur : Jaune lorsque la place est disponible, Vert lorsque la place est occupée et Rouge lorsque la place est prise par un véhicule mal stationné.
  3. Des informations sont disposées à gauche : Nombre de places disponibles, de véhicules, de véhicules mal stationnés, de véhicules bien stationnés et une mention « LA CIRCULATION EST PERTURBÉE » fait son apparition lorsqu’un véhicule n’est pas assez rentré dans sa place, comme visible sur le troisième cas de figure.

Erreur si un véhicule stationne entre 2 places.
Figure 11 : Erreur si un véhicule stationne entre 2 places.

La première erreur rencontrée (visible sur la Figure 11) est facilement rectifiable. En effet, un seul véhicule est détecté mais à l’écran apparaît « VEHICULE(S) MAL STATIONNE(S) = 2 », cela vient simplement du fait que le programme travail avec les places et non avec les véhicules, autrement dit, le programme regarde si la place est occupée par un véhicule et non pas si le véhicule occupe une place. Nous avons donc changé l’ordre dans lequel travail le programme (visible sur Figure 12).

Algorigramme de la deuxième version du programme.
Figure 12 : Algorigramme de la deuxième version du programme.

Erreur si un véhicule se stationne à l'horizontale.
Figure 13 : Erreur si un véhicule se stationne perpendiculairement.

La deuxième erreur rencontrée (visible sur la Figure 12) est due a notre manque de méfiance. Si un véhicule se positionne au milieu de la place, mais perpendiculairement, son barycentre est dans la zone de véhicule bien stationné. Pour y remédier, nous avons établi que si la largeur du véhicule est supérieure à sa longueur, il est reconnu par le logiciel comme étant mal stationné.


Application plus poussée

Vitesse d’acquisition

Jusque là, seul des photos étaient traitées, la Raspberry Pi 3 peut exécuter le programme mais pas sans peines, la carte chauffe, parfois se coupe et met jusqu’à 1 minute pour afficher le résultat. Dans le but de traiter des images en temps réel et en continu, un environnement plus stable et plus performant était nécessaire. Pour avoir un temps d’exécution plus raisonnable nous avons transféré le programme sur une machine Linux.

Type d’ordinateur Raspberry Pi 3 Machine Linux
Fréquence processeur 1,2 GHz 2,4 GHz
Temps d’exécution 50 secondes 2 secondes

Le temps d’exécution fut grandement réduit et les risques de surchauffes quasiment nulles. Pour que le retour vidéo soit totalement fluide il faudrait que l’ordinateur utilisé puisse afficher environ 24 images par secondes, soit environ 50 fois plus que la machine utilisée. Il n’aurait pas raisonnable d’utiliser une telle machine pour le projet car l’intérêt est moindre : en l’espace de 2 secondes, il n’y a pas d’événement impactant pouvant se produire sur un parking.

Analyse Temporelle

Afin de répondre pleinement au cahier des charges, il nous a fallu introduire une référence de temps dans notre programme. Ainsi certaines fonctionnalités peuvent être ajoutées, telles que le temps de stationnement de chaque véhicule, individuellement, le temps moyen de stationnement des véhicules, l’heure d’affluence ainsi qu’un affichage de la date sur l’interface pour avoir un repère temporel en cas d’enregistrement des vidéos de surveillance.

Deuxième version du programme

La deuxième version du programme intègre : la correction des bugs constatés après les tests sur la première version, une nouvelle interface plus claire, plus fonctionnelle et les nouvelles fonctionnalités rendues possibles grâce à la considération du temps.

Deuxième version du programme (Capture d'écran 1).
Figure 14 : Deuxième version du programme (Capture d’écran 1).

Deuxième version du programme (Capture d'écran 2).
Figure 15 : Deuxième version du programme (Capture d’écran 2).

L’interface a été entièrement repensée, rendant les informations bien plus lisibles et attrayantes. Hélas, appliqué à un système réel, le programme ne fonctionne pas correctement, on voit, par exemple que l’état de la place 4 est différent entre la Figure 14 et la Figure 15 alors que le véhicule n’a pas bougé. Malheureusement le programme a été intégralement développé sur le système miniature, ces dysfonctionnements n’ont pas étés anticipés et se sont révélés lors des tests tardifs avec des vidéos de surveillance. Les paramètres changeants entre le système miniature et le système réel sont : la caméra, l’échelle, le nombre de véhicules (bien plus important). Nous supposons donc que le problème est lié à un de ces paramètres.


Conclusion

Améliorations envisageables

En un premier temps, il faudrait corriger ce dysfonctionnement lorsque l’on travail sur un système réel. Ensuite, certaines améliorations pourrait être apportées :

  1. La transformée de Hough : trop complexe pour que l’on puisse l’utiliser correctement, il serait très plaisant de l’incorporer au programme principal.
  2. Base de données : les statistiques s’accumulant tout les jours, il pourrait être intéressant de les retrouver dans une base de données.

Apports

Ce projet nous a appris a travailler en autonomie, tout en renforçant nos connaissances du langage python et du traitement d’image.

 

 

Nous tenons à adresser nos remerciements à Mr Bazeille Stéphane et Mr Rebert Martin pour nous avoir suivi tout au long du projet en nous donnant des conseils avisés.


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


Microbrasserie

Groupe du projet

       Didierjean Romain

       Kettela Antoine

       Kontzler Louis


Sommaire

  1. Présentation du projet

  2. Analyse fonctionnelle

  3. Réalisation du projet

  4. Production de la bière

  5. Conclusion

  6. Annexes


Présentation projet

La bière est une boisson alcoolisée millénaire obtenu par fermentation d’un moût végétal. Il s’en boit des millions de litres chaque années et chaque pays revendique un savoir-faire unique. Nous allons donc nous plonger dans cette boisson et produisant notre propre bière.

Pour produire une bière, il faut 4 ingrédients :

  • De l’eau
  • Du malt
  • Du houblon
  • De la levure

Il y a ensuite plusieurs étapes de la production à respecter pour réussir sa bière :

  • Le concassage
  • Le brassage
  • La fermentation
  • La garde au froid
  • L’embouteillage et la refermentation

Le choix des ingrédients, des quantités utilisées et le temps de fermentation détermineront le goût, le degré d’alcool et la couleur de la bière. Il faut aussi veuillez à respecter au mieux les étapes pour ne pas rater la boisson.

Nous allons donc faire une analyse fonctionnelle du projet, puis nous allons réaliser la partie technique du projet en câblant l’armoire électrique chargé d’alimenter le malaxeur, le malaxeur qui brassera la bière, il faudra aussi créer un GRAFCET et un programme afin d’automatiser le brassage. Ensuite, nous détaillerons la production de notre bière. Et pour finir, nous conclurons sur ce que nous à apporter le projet et des possibles évolutions qu’on pourrait lui apporter.


Analyse fonctionnelle

Un projet de bière avait déjà été fait par initiaux en 2018. Nous avons donc pour objectif de partir de leur projet et de l’améliorer en automatisant le brassage afin de simplifier et fiabiliser cette étape. Le cahier des charges est de faire une bière légèrement ambrée tout en respectant des paliers de températures/ Il faut donc automatiser le brassage avec un automate Siemens S7-1200 pour réguler la température.

La diagramme bête à cornes du projet est le suivant :

Les paliers de températures à respecter :


Réalisation du projet

     1. Câblage de l’armoire

L’armoire était déjà câblée. Il fallait donc optimiser les branchements, sertir des fils, et rendre l’armoire fonctionnelle pour le projet. Pour cela, nous avons utiliser des relais de commandes, des relais de puissance, l’automate, un variateur et il a fallu relier les fils au malaxeur.

Les contacteurs utilisés ont les fonctions suivantes :

  • KVAR  =     Mise sous tension
    variateur
  • KA0     =    Relais de maintien du
    disjoncteur de la
    partie puissance
  • KA2     =    Fin de course bas
  • KA1     =    Fin de course haut
  • KAdef  =    Défauts
  • KADE   =    Descendre la pâle
  • KDET   =  Chauffage
  • KAMO =  Monter la pâle

     2. Câblage du malaxeur

Les étapes que nous avons suivi pour faire la partie câble ont été :

  1. Enlever tous les câbles de l’Ecolsab Habils
  2. Câbler selon les anciens schémas
  3. Noter les modifications effectuées
  4. Ajouter une sonde PT100
  5. Modifier les schémas sur QElectroTech (Annexe 1)

     3. Programmation de l’automate

L’automate utilisé est un siemens S7-1200, il nous a été prêté pour le projet et par la suite il faudra en acheter un. Nous avons aussi utiliser un écran pour  d’IHM.  Un switch a fait le lien entre l’IHM  et l’automate.

Il a ensuite fallu élaborer les GRAFCET (Annexes 2 et 3) et développer le ladder sut TIAGrafcet_Choix_du_Mode Portal.

     4. Création de l’IHM

L’IHM a deux vues : vue principale(à gauche) et vue Recette (à droite).

La vue Principale sert à choisir le mode de fonctionnement, acquitter une étape, mettre en marche/ arrêter et de voir si la résistance électrique chauffe. Elle permet d’avoir des informations en temps réel, pour le moment seulement la température relevé par la sonde PT100. Changer le temps et la température des paliers est possible dans la vue Recette.


Production de la bière

     1. Concassage

Concasser les grains permet de mieux faire infuser le malt dans l’eau durant le brassage. La photo nous montre la différence entre le grain concassé (à gauche) et le grain entier (à droite).

Pour notre bière ambrée, nous avons utilisé :

  • 2250g de malt Munich
  • 2250g de malt Vienna

     2. Brassage

Durant cette étape, il faut chauffer et brasser en respectant les paliers du cahiers des charges (voir Analyse fonctionnelle) que nous avons défini dans notre programme. Cette étape va caractériser notre bière.

     3. Rinçage

Le rinçage des drêches permet de séparer les grains du moût à l’aide d’un filtre. Sur l’image, nous observons bien l’utilité du filtrage. Tous les grains son rester dans la cuve, tandis que le moût est passé à travers.

     4. Ébullition

C’est le dernier palier de chauffe, il permet de stériliser la bière. C’est aussi à ce moment que l’on ajoute le houblon. Il y a deux types d’houblon:

  • L’amérisant : nous avons utiliser 33g de Styrian Goldinds pour notre première bière que nous avons du  laisser 60 minutes.
  • L’aromatique : nous n’en avons pas utiliser pour la première bière. Pour la deuxième nous l’avons mis 10 minutes avant la fin.

     5. Refroidissement

La cassure de la température permet de produire des protéines dans la bière. La bière doit impérativement ne pas être chaude pour ne pas tuer les levures incorporées par la suite.

Le refroidissement idéal est rapide et doit se faire avec un serpentin ou refroidisseur à plaque. Nous avons refroidis la première bière en mettant la cuve dans l’eau, ce qui n’est pas un refroidissement optimal.

     6. Fermentation

C’est à cette étape que l’on ajoute la levure pour la première fermentation.La fermentation dure 3 semaines dans une cuve avec un barboteur, à température ambiante (25°).

     7. Mise en bouteille

Avant de mettre en bouteille, on ajoute le sucre dans la bière. C’est la deuxième fermentation. Il faut faire attention a ne pas mettre trop de liquide dans les bouteilles car il y a un risque d’explosion s’il y  a trop de pression. Il faut ensuite mettre les capsules manuellement.

     8. Création d’une étiquette

Nous avons décider de créer une étiquette à mettre sur les bouteilles que nous avons produites. Romain s’est chargé de la créer, elle est libre de droit pour de futures bières.


Conclusion

Ce projet nous a permis de mettre en pratique les notions de supervision et d’automatismes que nous avions reçu. Il nous a aussi permis de nous familiarisé avec des schémas électriques et prendre en main un logiciel pour les modifier. il nous a aussi appris a mieux gérer notre temps car il fallait avoir fini assez tôt pour pouvoir produire la bière en comptant les fermentations.

Donc, c’était un projet très intéressant. Nous avons découvert l’univers de la bière avec pédagogie et il y a eu du concret grâce à la production de notre propre bière, il reste cependant quelques améliorations à faire.

Les futures améliorations du projet auxquelles nous avons pensé sont :

  • Pouvoir lire la température de la plaque dans l’automate sur l’IHM
  • Améliorer l’étape de refroidissement (en ajoutant un serpentin ou un refroidisseur à plaques)
  • Utiliser un PWM ou PID pour la régulation de la température

Annexes

Annexe 1 :  Schémas électrique de l’Ecolsab Habilis

Annexe 2 : Grafcet Choix du Mode

Annexe 3 :  Grafcet du mode Auto


Robot de Combat Tyler 1 – Maker Fight 2018

 

Projet Robot de combat MakerFight

 

 

Sommaire

 

 

I) Contexte et définition du projet

1) Contexte (p3)

2) Objectifs de notre groupe (p3)

3) Périmètre du projet (p4)

4) Critères d’acceptabilité (p4)

 

II) Besoins du robot (p5)

III) Contraintes

1)Coûts (p6)

2) Délais (p6)

3) Autres (p6)

 

IV) Déroulement du projet

1) Planification (p7)

 

V) Journée MakerFight et préparation

 

 

 

I)Contexte et définition de projet

 

  1. Contexte

 

Le MakerFight est un événement créé il y a 3 ans permettant de réunir des intéressés de la robotique, de la mécanique et de l’électronique afin de faire concourir des robots de combat en les faisant s’affronter dans une arène.

La première édition du MakerFight était privée mais cette année, celle-ci est ouverte a tous ceux qui veulent y présenter un robot de combat. Cet événement se déroulera cette année le Samedi 21 avril.

 

2) Objectifs de notre groupe

Pour cet événement, notre groupe se fixe plusieurs objectifs :

 

  • Avoir à la date du 21 avril, un robot permettant de concourir.
  • Contrôler le robot à distance
  • Faire fonctionner tous les moteurs
  • Remporter des matchs

 

3)Périmètre du projet :

 

Pour le bon fonctionnement de notre projet, notre groupe de quatre membres (TOUSSAINT Raphaëlle,KIEFFER Maxime, HUSSER Valentin et JUND Bastien) avons dû nous fixer des limites pour notre projet :

 

  • Le règlement du MakerFight (Masse, types d’armes)
  • Notre budget de 200€
  • Le temps imparti pour notre projet
  • La faisabilité technique

 

 

4)Critères à respecter :

 

Pour valider notre robot, et ainsi lui permettre de concourir, nous avons dû soumettre notre robot a plusieurs règles :

 

Les armes interdites :

-Explosifs

-Liquide

-Êtres vivants

-Projectiles

-Décharges électrique

Autres contraintes :

-Masse : 20 kg maximum avec une marge de 100 grammes

-Contrôle du robot à distance (sans fil)

-Nécessite un dispositif de sécurité en dehors de l’arène

 

II)Besoins du robot

 

Fonction Critères Priorité Flexibilité
FP1 Doit se déplacer sans problèmes dans l’arène

-roues

-taille

Haute Temps de réaction variable
FP2 Doit respecter les contraintes imposées

-Poids

-Armes

-Budget

Haute Poids : +100g
FP3 Doit utiliser les armes à disposition

-scie

-bèche

Haute /
FC1 Fournir une documentation Site des projets Moyenne Date remise doc
FC2 Etre transporter en sécurité Protection plastique Haute /
FC3 Préparation évènement MakerFight Entrainement contrôles Faible /

 

III)Contraintes

 

1)Coûts

 

Le budget accordé à notre projet est de 5O € par personne, soit un total de 200 €. Un peu moins de la moitié de notre budget a été dépensé pour acheter des batteries et environ 50€ ont été dépensé pour des cartes électroniques.

Pour réaliser notre projet, nous avons pu bénéficier de l’aide de Mr.DeSabbata , ainsi qu’un accès à l’IUT Lab , ou nous avons pu utiliser les logiciels tel que CorelDraw ou différentes machines, ce qui nous as permit d’économiser de l’argent et du temps.

 

2)Délais

 

Le délai final pour notre robot est la date du MakerFight, c’est-à-dire le 21 avril 2018. Depuis le début de notre projet, nous avons assister à plusieurs réunions (en Novembre et en Février), permettant de mettre au point l’avancement de notre robot.

 

3)Autres

 

En termes de contraintes, nous avons dû nous renseigner sur les différentes règles du MakerFight, ainsi que sur les mesures de sécurité à prendre concernant la protection des armes en dehors de l’arène, afin d’éviter tout risques.

Nous avons aussi dû prendre en compte le délai imposé par l’IUT pour l’achat de nos différents composants, pour la gestion de notre budget. Le fait de travailler sur le robot uniquement en dehors des heures de cours est aussi une contrainte en plus.

 

 

 

IV)Déroulement du projet

 

Depuis le début de notre projet, nous sommes passés par plusieurs phases :

-Phase de recherches : formes du robot, type d’armes, idées …

Durant cette premiere phase, nous avons tout d’abord fait quelques réunions afin de décider de la taille et de la forme finale du robot. Nous avons aussi commencé a imaginé

les différentes armes de notre robot ainsi que son moyen de déplacement.  Nous en somme arrivés a la conclusion que notre robot sera rectangulaire et possédera comme armes :

-une scie

-une bêche coupée en deux

-Deux bras a l’avant

-Phase de conception : 

Lors de cette deuxième phase , nous avons commencé a faire des tests pour réaliser une maquette de notre robot, ainsi que ses plans . Pour cela  nous avons utilisé différents  logiciels tels que CorelDraw et Solidworks. Cette phase s’est étendue jusqu’au dernier jour car il comporte aussi la partie programmation sous Arduino qui fut un véritable casse-tête

 

 

 

-Phase de récupération : matériaux, moteurs, recherche partenariat

Cette phase ci fut l’une des plus longues car nous devions recherché tous les matériaux nécessaire a la fabrication de notre robot. Pendant plusieurs mois, nous avons recherché des moteurs de perceuses pour faire fonctionner les roues , un moteur de ventilateur de moteur de voiture pour notre scie , des moteurs de lève-vitre pour les bras du robot ainsi qu’un moteur d’essuie glace pour notre bêche. Nous avons réussis a en trouver une grosse partie en demandant à des casses automobiles et les moteurs de perceuse en demandant dans notre entourage. Pour le châssis , nous avons obtenus un partenariat avec un métallurgiste du nom de John Steel qui nous a gracieusement offerts les plaques pour notre châssis en échange d’un peu de visibilité.

-Phase d’assemblage  : fixation et modification moteurs

Durant cette phase , nous avons du modifier certains moteurs pour les adapter a notre robots :

 

-moteurs des roues :

Nous avons modifié le moteur de tel sorte qu’il soit plus résistant et moins limité dans ses capacités ; nous avons remplacé l’étage de pignons en plastique qui entraîne le moteur par des pignons en métal et nous avons enlevé le limiteur de couple pour éviter que les roues soient limitées en vitesse , donc en maniabilité.

 

-moteur de bêche

 

Pour celui-ci , nous n’avons pas eu besoin de modifier la moteur .En revanche , nous avons du fixer un bras à la bêche et percer un trou de la bonne taille dans ce meme bras afin de l’emboiter dans l’axe du moteur

 

-moteur de scie

 

Encore une fois , nous n’avons pas eu besoin de modifier le moteur mais nous avons du récupérer l’axe d’un moteur de meuleuse. Nous avons usiné la pièce et permis ainsi d’entraîner notre scie sans que cette dernière puisse sortir de son axe.

 

V) Journée Makerfight et préparation

Malgré que la nuit fût courte, nous étions remonté à bloc (malgré le stress) pour cette journée, lors de notre arrivée, il nous restait un certains nombre de test à faire:

-Vérifier que les roues fonctionnait correctement, la bêche ainsi que la scie.
-Prendre en main la maniabilité du robot

 

Arriva le moment temps redouté par tous les robots de la pesé ainsi que des tirages aux sorts pour les groupes:

Tout se déroulait correctement jusqu’à notre premier combat aux alentours de 10h45, nous affrontions le redoutable Sweetie Bot, la première manche fût remporté par lui, lors de celle-ci notre scie, monté à l’envers se dévissa et nous ne pouvions donc utiliser que la bèche, malgré celà nous remportons la deuxième manche avant de nous incliner sur la troisième manche.

Après le combat, ce fût une véritable course:
-Remonter la scie à l’endroit.
-Le pont en H de la bèche était HS.

Pas de répis, il fallait tout réparer avant le deuxième combat face à Schbunk, un adversaire redoutable.

Arrive donc le moment fatidique : Le combat contre Schbunk.

La première manche fût totalement en son sens.
La deuxième manche, nous arrivons à accrocher cette manche avant une troisième qui promettait d’être très mouvementé.
Mais, lors de la deuxième manche, une de nos roues avaient cessé de fonctionner, la dernière manche promettait d’être compliqué, mais, malgré ça, le robot s’est bien défendu !

Il avait maintenant, quelques blessures de « guerres », et avait survécu.
Comme le combat précédent, il était de notre devoir de le remettre sur roues pour qu’il puisse continuer à concourir.

La suite des matchs, se fût malheureusement sur deux roues (fautes aux pont en H).
Malgré ça, le robot s’est bien défendu et cette journée fût affolante et excitante à vivre!

Une expérience à refaire!

 

 


Mise en oeuvre d’un module Wago

 

Mise en œuvre d’un module Wago

Introduction

Dans le cadre des projets du troisième semestre du DUT GEII, nous avons été amené à utiliser un automate programmable de la marque WAGO afin de réaliser une récupération de données de consommation d’une installation électrique. De plus nous avons dû programmer une interface graphique plus claire pour l’utilisateur.
Le groupe est composé d’Alexandre MEYER, Célestin HAGER et de Benoît WITZ.

 

 


Sommaire

Objectifs

Outils

Le projet

Problèmes rencontrés

Bilan

Conclusion

Remerciements

 

 

 


Objectifs

Notre projet possède différents objectifs, son but principal est de récupérer et d’archiver les mesures de tensions, de courants et de puissances afin de pouvoir observer la consommation et ainsi mieux la gérer.

Dans un second temps il faut centraliser et afficher les données récupérées sous forme de graphiques plus compréhensible pour une personne non familière avec le domaine des énergies.
Et pour finir rendre tout cela portable afin de pourvoir l’utiliser sur des installations électriques externes.


Outils

module_ 750-494

Automate WAGO (CENTRALE FASTLOGGER 3G)

Module 750-494 (monophasé + triphasé)

module_750-495

Module 750-495/000-002 (triphasé)

Module de terminaison 750-600

4 sondes de courants (60/1A)

boucle Rogowski

4 boucles de Rogowski (RT500)

Alimentation +24V

sonde de courant

Logiciels :

  • CoDeSys
  • WAGO Ethernet settings
  • WAGO-IO Check
  • MakerCase
  • CorelDRAW


Le projet

Les premières heures de projets ont été consacré à la prise en main du matériels (automate et outils de mesures) ainsi qu’à la lecture de la documentation technique.

Nous avons ensuite effectué les branchement afin d’alimenter l’automate, ainsi que  mettre en place une connexion entre lui et les différents ordinateurs du réseau informatique de l’UHA.

 

 

Ensuite nous avons pris en main les interfaces permettant la visualisation et le paramétrage, WebVisu et Web-based Management.

Web-based Management est une interface propre à l’automate qui permet de régler ses différents paramètres.

WebVisu est l’interface de la marque qui permet de voir en temps réel les différentes mesures effectués. On y retrouves tout les éléments tel que le courant, la surintensité, le cos phi, la tension …

Une fois mis sous tension nous avons procédé à nos premiers tests de mesures à l’aide du module 750-495/000-002, un test avec les sondes de courants, un autre avec les boucles de Rogowski. Depuis l’interface FASTLOGGER, nous avons remarqué que les valeurs affichées étaient hors normes. C’est pour cela que l’on a effectué des mesures de référence à l’aide d’une pince ampèremétrique.

Après comparaison des mesures, et grâce à l’intervention du service technique WAGO, nous nous sommes aperçu que les sondes de courants n’étaient pas faite pour ce module, contrairement aux boucles de Rogowski.

En effet il faut savoir que les boucles de Rogowski ne peuvent donner une valeur précise que si la charge mesurée fournit au moins 20% du courant admissible par la boucle. Dans notre cas le courant maximal admissible est de 500A, il faudra donc que la charge mesurée fournisse au minimum 100A pour avoir une valeur de mesure précise.
Le module 750-495/000-002 n’étant pas utilisable dans notre cas car nous n’avons pas accès à une armoire électrique pour avoir un tel niveau d’ampérage.Pour continuer nos différents tests, nous avons utilisé le module 750-494, les sondes de courants fonctionnant avec celui-ci. Nous avons refait des tests de mesures avec des résultats cohérent pour la charge que nous avons mis en place, ici un fer à souder.

Afin de pouvoir afficher les différentes valeurs récupérées lors de nos mesures, nous avons développé un programme permettant d’afficher la consommation horaire, journalière, ainsi que sur une semaine.
Pour se faire nous avons utilisé le logiciel Codesys 2.3 modifié par la société WAGO qui inclus directement la référence de notre automate.
Les langages utilisés sont le Ladder ainsi que le texte structuré. De plus nous utilisons une librairie, PowerMesurement_494_02 qui inclus les blocs Ladder permettant la récupération des mesures du module complémentaire 750-494.

Une fois les données récoltées, il nous a été demandé de pouvoir les affichées sur une interface graphique selon les critère de l’uha.
Dans un premier temps, le but était de pouvoir afficher les valeurs en temps réel.

Par la suite nous avons réussi à pouvoir consulter un historique des consommations d’une semaine tant que l’automate est alimenté.

Afin de compléter notre projet, nous avons été amené à concevoir et à réaliser une mallette pouvant accueillir notre automate WAGO, son alimentation ainsi que les différents instruments de mesures. Les logiciels MakerCase et CorelDRAW ont permis la modélisation de notre mallette  ainsi qu’à la construction des plans. La réalisation des différentes parties a été faite à l’aide de la découpeuse laser de l’IUTLab.  Nous utilisons  du contreplaqué de 3mm et 5mm pour faire l’armature et ces différents rangements pour les boucles de Rogowski et les sondes de courant. Le couvercle a été fabriqué de la même sorte, mais nous avons décidé de le faire en plexiglas transparent. La boîte est fabriqué de telle sorte qu’on puisse rajouter des modules, des sondes de courants ainsi que des boucles de Rogowski.

 


Problèmes rencontrés

Nous avons du résoudre de nombreux problèmes concernant la mise en fonctionnement du WAGO ainsi que ces différents outils de mesures :

  • JAVA : Nous avons dû faire la Mise à jour de JAVA sur le PC afin de faire fonctionner le WebVisu.
  • Problème accès Web-based Management : nous avons essayé de communiquer via une liaison série et pour cela nous avons désactivé le port http.
  • Problème du logiciel FASTLOGGER: Réinstallation du FASTLOGGER.
  • Coefficient de transformation sonde de courant : la sonde courant n’avait pas le bon coefficient de transformation ce qui nous donnait des fausses valeurs pour l’essai avec un module 750-494 en monophasé.
  • Nous avions pas la version de CeDeSys permettant de ce connecter au WAGO.

La résolution de ces problèmes nous on fait perdre de nombreuses heures, afin de les résoudre nous avons fait appel au service technique WAGO.

 


Conclusion

Nous n’avons pas accompli tous les objectifs fixés en début de projet, en effet nous ne sommes pas arrivés à archiver nos données. Pour le moment la malette n’est pas encore autonome.
Néanmoins nous avons tout de même réalisé la majeur partie de notre projet, la mise en réseau et l’alimentation de l’automate WAGO, la récupération de données, la fabrication et l’assemblage de la mallette, ainsi que la réalisation d’une interface graphique ont été
effectués.


Remerciements

Nous tenons à remercier les personnes qui ont permis la bon déroulement du projet, tout particulièrement Mr Ould Abdeslam, Mr Drouaz, Mr De Sabbata et le service technique WAGO.

 

iutCouleur


EfficacEnergie

Projet :

MISE EN SERVICE DU SERVEUR EFFICACENERGIE

 

 

 

 

Introduction

 

Le projet sur lequel nous avons travaillé au cours de ces trois derniers mois a été la remise en marche de l’interface web « Efficacenergie ». Notre groupe est constitué de trois membres au total :

  • KELES Hakan
  • OZTUNC Tunç
  • SANGWA Marco

Les recherches que l’on a menées ont été divisé en trois sous parties :

  • Prendre en main l’architecture
  • Remise en marche de l’interface
  • Réalisation des rapports de mesures

Pour pouvoir réaliser ces recherches, nous avons eu au total 98h de projet en groupe (sans compter le travail personnel). Le compte-rendu de ces 98H a été divisé en deux parties :

  • 1ère évaluation au bout de 56h de projet le 11 janvier 2018
  • Soutenance finale le 26 janvier 2018

L’interface que nous avons utilisé tout au long du projet, « Efficacenergie » est un outil qui permet :

  • De surveiller les consommations à l’aide de capteurs
  • D’avoir à disposition des tableaux de bord personnalisables
  • L’édition automatique de rapports (fonctionnalité dont nous ne disposons pas car nous avons l’ancienne version)
  • Possibilité de projeter ses mesures en direct en mode diaporama
  • La possibilité d’ajouter ou supprimer à tout moment des capteurs
  • Faire une cartographie des capteurs et répéteurs (pour pouvoir, par exemple plus facilement intervenir en cas de panne)

 

L’interface web « Efficacenergie » a été conçue par Distrame, une société de création et développement de solutions de surveillance des consommations d’énergies. En résumé, ce que l’on peut dire sur l’utilité de cette interface, c’est la réduction des consommations énergétiques (jusqu’à 30% selon leurs revendications).

Pour information, l’accès au serveur ne peut se faire que sur le réseau local de l’IUT à l’aide de l’adresse IP du serveur et grâce à la connaissance des identifiants et du mot de passe (selon votre statut d’identifiant, le serveur vous donne le droit ou non d’avoir la possibilité de modifier les paramètres). Nos principales sources d’aide ont été nos professeurs et tuteurs de projet : Monsieur OULD Abdeslam et Monsieur DROUAZ Mahfoud, les différentes documentations, fichiers PDF ainsi que l’aide des services techniques de la société Distrame.

L’installation de plusieurs outils (fixation capteurs, répéteurs, …) et logiciels ont été nécessaires tout au long du projet (Wavenet Monitor, WebCorTool …).

Sommaire

I/Cahier des charges

II/Inventaire

III/Etape lié à la configuration

IV/Analyse

V/Fonctionnalités de l’interface web « Efficacenrgie »

VI/Conclusion

VII/Remerciement

I/ Cahier des charges

 

Diagramme bête à corne du système :

 

 

Diagramme pieuvre du projet :

L’objectif du projet est d’étudier le fonctionnement du système « Efficacenergie » afin d’identifier le problème lié à l’envoie sur l’interface web des données enregistrées par les différents modules.

 

II/ Inventaire

 

III/ Etape lié à la configuration

 

Pour pouvoir utiliser le système nous avons eu le besoin de faire plusieurs configurations, la premier étant la configuration des capteurs Coronis qui se fera via le logiciel Wavenet Monitor ainsi que celle du collecteur de données. Pour faire ces configurations, nous avons dû connecter le Waveport qui doit être lui aussi configuré. Pour réaliser cette tâche, nous avons réalisé des tutoriels montrant et expliquant chaque manœuvre des configurations :

  • « Configuration du collecteur de donnes CORONIS »
  • « Configuration des capteurs/répéteurs » .

Ces tutoriels sont disponibles en annexe avec également d’autres tutoriels expliquant le fonctionnent du système « Efficacenergie ».

Pour pouvoir effectuer la configuration du capteur nous avons besoin d’une autre configuration au préalable qui est :

Configuration des capteurs Coronis

       La configuration du waveport

En effet dans « panneau de configuration » il faut repérer le port COM attribué au waveport par l’ordinateur et le configurer de telle sorte qu’elle soit comprise entre 2 et 9.

       La connexion du waveport

La connexion au waveport s’effectue via le logiciel wavenet monitor.

Lorsque notre waveport est configuré puis connecté, on pourra affectuer la configuration des capteurs Coronis.

On effectue tout d’abord la déclaration des modules

Cela vient à effectuer via le logiciel Wavenet Monitor, la saisie des adresses radio de chaque capteur et répéteur.

 

  • Puis on crée l’architecture radio

Cela permet de rendre communiquant les modules, les répeteurs et le waveport dans le loqiciel Wavenet Monitor.

 Ensuite on effectue la configuration des modules

C’est-à-dire la configuration du pas de temps et l’heure de rapatriement des données vers le Waveport.

Déclaration des capteurs Coronis dans Efficacenergie

Lorsque nous avons effectué la configuration des capteurs, nous avons besoin d’effectuer la déclaration des capteurs Coronis dans Efficacenergie.

Configuration du collecteur de données Coronis

Pour pouvoir effectuer la configuration du collecteurs de données Coronis nous avons besoin de l’outil « Webcortool Distrame Edition »

-Connexion du collecteur de données

-Paramétrage du collecteur de données

-Forcer un rapatriement de données à partir d’un collecteur Ethernet

 

 

IV/ Analyse

 

Au niveau des analyses, nous avons effectué différents tests RSSI (Received Signal Strength Indication) afin de vérifier la puissance du signal envoyé par les différents capteurs via le logiciel Wavenet Monitor.

Pour se faire, nous avons d’abord placé le capteur de température WTH12 à différents endroits dans le bâtiment B, nous en avons conclu que la distance affectait la qualité ou la réceptivité du signal. Ainsi nous avons utilisé un répéteur (REP3) qu’on a ajouté à l’architecture radio du système sur le logiciel Wavenet Monitor. Puis nous avons fait le même test que précédemment en modifiant la position du capteur et du répéteur. On a déduit d’après la documentation qu’il fallait pas avoir un pourcentage RSSI en dessous de 30%. Nos tests ont été concluants avec le répéteur car nous avons obtenu une valeur RSSI minimum de 41% en plaçant les capteurs aux endroits voulus (compteur d’impulsion WFL2 en B21).

Test RSSI réalisé avec le capteur de température WTH12 près du collecteur de données et les capteurs d’impulsions WFL1 et WFL2 dans leur salle respective ainsi que le répéteur REP3.

Suite aux bons résultats, nous avons ajouté des capteurs au répéteur à notre disposition, cependant, certains étant trop distant du répéteur, nous avons dû en ajouter un autre : le REP4 dans le couloir du bâtiment B. Ainsi nous avons refait des tests RSSI avec les résultats ci-dessous.

Test RSSI avec le répéteur REP4 envoyant au répéteur REP3 le signal des capteur WTH10, WTH11 et WFL1 distant de celui-ci. A gauche se trouve une visualisation de l’architecture radio de l’ensemble du système.

Cependant, durant notre appel avec le technicien de la société Distrame, ce dernier nous à fait la remarque que le niveau de pile des capteurs pouvait être un facteur de la mauvaise réception du signal, nous avons du dans ce cas vérifier par nous-même leur état via Wevenet Monitor.

Procédure pour accéder au niveau de batterie de la pile d’un capteur, ici le WTH10. Pour ce
faire, il faut se rendre dans la rubrique « Gestion des données » sur la face principale du logiciel.

Toujours durant l’appel, nous sommes aussi allés dans le serveur QNAP à l’aide du logiciel FileZilla Client FTP afin de recueillir les données qu’il a reçu du collecteur de donnée.

Connexion du au serveur NAS (serveur QNAP) sur le logiciel FileZilla Client FTP

Une fois sur le serveur, nous avons pu récupérer un fichier « .xml » sur lequel les données stockées par les capteurs ont été envoyé sur le collecteur de données.

Une fois ces tests et analyses terminés nous avons synchronisé le collecteur et le serveur afin que le processus de traitement des données du serveur se remette en marche et envoie les données des capteurs sur l’interface web « Efficacenergie ».

Après le rapatriement de données, les données des capteurs ont bien été acheminées sur l’interface web, ainsi durant toute une semaine, nous avons pu observer l’acquisition des différentes données des capteurs (modules de température wavetherm et modules de mesure d’énergie waveflow) sur l’interface web.

V/ Fonctionnalité de l’interface web « Efficacenergie »

 

Après avoir créé le dossier, on crée un tableau de bord pour pouvoir justement voir nos données.

On demande un ajout de tableau de bord puis l’onglet suivant apparaît :

On donne le nom du tableau de bord à créer, dans notre cas on prend le « capteur témoin » Wavetherm 12 (d’où le nom WTH12). Le nombre de colonne permet de mettre en place l’agencement des panneaux d’affichage des données. Dans ce cas par exemple, l’écran se divise en deux et on a deux tableaux d’affichage sur la même colonne.

On met le dossier dans lequel doit être présent le tableau de bord.

Avant d’ajouter le tableau de bord, il faut donner la liste des droits selon les utilisateurs. Pour notre cas (juste un exemple), nous avons donné le droit de modifier et de pouvoir lire le tableau aux utilisateurs « groupe1 lpro » et à « mulhouse iut ». « Bertrand SIMON » et « Almedin Cavalic » ont juste le droit de lire les données tandis que le dernier utilisateur « Michael SCHERER » n’a aucun accès.

 

Une fois le tableau de bord créé, il faut l’ouvrir et aller sur la configuration de la première fenêtre (faire la même manipulation pour les autres fenêtres s’il y en a plusieurs).

Pour chaque fenêtre, lui donner un nom et préciser le type de fenêtre que vous voulez créer.

Sur l’interface « Efficacenergie », et avec la version que l’on a (version 2.13 de 2014), on peut avoir quatre types de fenêtre : un graphique, un tableau de données, des compteurs manuels (pas utilisé pour notre cas) ou encore des textes dynamiques.

Pour notre cas, nous expliquerons comment faire la configuration d’une fenêtre graphique et la fenêtre d’un tableau de données.

Le cas d’une fenêtre graphique

On précise tout d’abord les données d’axes avec leurs noms et leurs configurations. Le mieux est de mettre la taille de l’échelle en automatique pour que l’on ait pas à toujours changer l’échelle en permanence pour chaque jours écoulés. Après avoir précise les axes, on passe aux données série. Pour cette étape d’ajout de série, il faudra donc assigner le module de l’architecture que l’on a créé au préalable.

Le nom de la série n’est pas très important. Il faut tout d’abord dire quel type de graphique, on veut obtenir. Avec la version que l’on a (version 2.13 de 2014), on a la possibilité d’avoir une courbe, un diagramme en barres, une courbe en zone, une courbe lissée ou encore une courbe lissée en zone.

Une fois le type renseigné, il faut retrouver le module qui sera source des données, en précisant à chaque fois le collecteur parent du module.

Les axes correspondent au nom que vous avez donnée au préalable. Le facteur de conversion reste à 1 pour notre cas et l’unité de mesure change selon le capteur que l’on a (Wavetherm ou Waveflow)

Au final, on choisit la référence de la couleur que l’on veut donner au graphique obtenu.

Le cas d’un tableau de données :

Dans le cas d’un tableau de données, la manipulation est plus simple car on ne demande que le nom de série. On aura donc à remplir le tableau suivant (comme avec la fenêtre graphique, on doit rechercher le module).

Que ce soit pour le graphique ou le tableau, il faut à présent préciser les dates pour pouvoir visualiser toute nos données.

Il faut donc remplir les champs présents sur le bord du haut de la fenêtre.

Pour ce cas, nous utilisons une période d’une semaine allant du 17 janvier 2018 au 24 janvier 2018 (ps : les données antérieures au 15 janvier 2018 ont été archivées en raison du mauvais fonctionnement du système). L’échantillonnage sera de préférence réalisé toutes les 15 minutes.

Il faut toujours prendre 1 jour après pour pouvoir visualiser les données du dernier jour (si on met jusqu’au 24, il mettra les données jusqu’au 24 00h donc on ne verra pas ce jour là). De plus, pour information, il faut au moins une heure pour obtenir les données en prenant en compte le temps de rapatriement des données.

Ce que l’on obtient donc au final :

 

Sur 1 semaine, on remarque que la température ne monte pas et présente une petite diminution avec stagnation du 20 au 21 janvier 2018, ce qui est logique car ces 2 jours correspondent au samedi-dimanche, donc la période où les chauffages sont éteints (les chauffages ne sont pas en action pendant les week-ends à l’IUT).

On peut très bien rétrécir le temps en 1 ou 2 jours pour pouvoir faire l’analyse des données et voir si c’est cohérent.

On prend donc comme intervalle, un intervalle de 24h pour voir les modifications en 1 journée.

 

En faisant l’analyse des autres jours et de celui-là on remarque que le chauffage se remet en route vers 4h30 – 5h du matin et qu’il s’éteint vers 18h du lundi au vendredi. En analysant, on en déduit que le samedi le chauffage est ouvert jusqu’à 12h et il s’éteint tandis que dimanche il est éteint toute la journée.

A côté de ces tracés, on peut créer et enregistrer la carte.Pour cela, il faudra aller dans la partie configuration de l’interface et charger une image de la vue aérienne de l’IUT.

Pour que les valeurs soient plus facilement analysables, nous pouvons ajouter des « limites ». Ces « limites » sont des tracées que l’on fait sur le graphique pour le faire encore plus visible et donner des informations supplémentaires.

On ajoute ces limites depuis la fenêtre de configuration de fenêtre. Ces limites peuvent être fait sur la verticale ou l’horizontale. Par exemple, sur la courbe suivante nous indiquons les températures max et min limites que l’on obtient au cours des dernières semaines.

 

Sur le prochain, nous mettons des limites pour indiquer le moment où le chauffage est allumé. Bien sûr, ces indications sont des informations que l’on a déduit.

Chaque bande verte correspond au moment où le chauffage est allumé.

Après cela, il faut ajouter un tableau de bord puis configurer la fenêtre en texte dynamique avec le fond d’écran du plan de l’IUT. Après cela il faudra ajouter à chaque fois les éléments. On aura des liens avec des textes dynamiques.

 

VI/ Conclusion

 

Après vérification des éléments du système, le problème était donc au niveau du serveur et de son processus de traitement des fichiers qu’il recevait du collecteur de données en grande quantité. Ainsi le problème réglé et la synchronisation avec le serveur et le collecteur de données effectuée, les données des capteurs sont bien enregistrées sur l’interface web. Reste plus qu’à ajouter d’autres capteurs et à réaliser une carte correcte de l’IUT et ses capteurs avec leur niveau RSSI. De plus, d’autres fonctionnalités sont disponibles sur la nouvelle version de l’interface web « Efficacenergie », cependant, nous ne disposons que d’une des premières versions qui date d’il y a 4 ans.

 

 

VI/ Remerciements

 

Nous tenons à remercier notre professeur en charge de ce projet à savoir M.OULD, pour nous avoir guidé tout au long de ces semaines à appréhender le système, nous voulons également remercier le technicien de la société Distrame de nous avoir aider à régler informatiquement le problème de traitement des fichier du serveur.


Microbrasserie


 

 

 

 

 Micro-Brasserie

 

 

 

 

 

 

 

 

 

 


Sommaire



  • L’équipe


    Notre équipe de projet est composée de :

    • PATRE Guillaume
    • QUANG Benjamin
    • NGUYEN Thanh Suon

    Présentation du projet


    Objectif :

    • Réaliser une maquette permettant la production de bière.

    But :

    • Créer un programme permettant l’automatisation de la production.
    • Créer un IHM simple et compréhensible pour tout utilisateur.
    • Effectuer de la régulation de vitesse sur le malaxeur et la pompe.

    Analyse fonctionnelle


  • Diagramme bête à cornes 


    Montage


    //texte


    Bilan


    Le projet de la Micro-Brasserie nous à fait découvrir des notions pratiques et techniques dans le domaine de informatique industrielle notamment. Ce projet a été enrichissant pour chacun de nous 3 et nous a permis de créer une cohésion dans le travail de groupe. La répartition des tâches fût très importante pour le gain de temps et pour développer l’autonomie de chacun. Pour finir ce projet est très intéressant car il touche à tous les domaines du DUT Geii.


    Mode d’emploi


    //texte


    Conclusion


    //texte


    Remerciements


    Un grand merci à Mr OULD ABDESLAM et Mr DROUAZ, nos enseignants-chercheurs tuteurs pour ce projet ainsi qu’à Mr DE SABATTA, 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 et matériels.

     


Interface de gestion d’énergie

INTERFACE DE GESTION D’ÉNERGIE
Volume horaire du projet: 98heures

 

OBJECTIF : Réalisation d’une interface pour le contrôle et la gestion d’énergie.

Professeurs référents: 
Monsieur DROUAZ Mahfoud
Monsieur OULD-ABDESLAM Djaffar

Équipe :
ZINK Valentin
ROCA Maxime
BRUGGER Marie-Camille
NAZE Anthony

 

SOMMAIRE :
Présentation du projet :
1. Introduction

Partie traitement des données (présentation DAQExpress) :
1. Acquisition des données
2. Traitement du signal récupéré
3. Création de la base de données
4. Envoi des données

Partie création d’interface et gestion des données :
1. Interface
2. Problèmes rencontrés
3. Solutions apportées

Conclusion :
1. Ouverture du projet

Introduction:

Le projet d’interface de gestion d’énergie nous a été référé par Mr DROUAZ ainsi
que Mr OULD-ABDESLAM. Ce projet a pour but de récupérer des mesures en utilisant le
module de 16 entrées analogiques/numériques NI-9220 (outil développé par National
Instrument), qui, via le châssis NI cDAQ-9174, bufférise toute les données et les envoie via
un port USB. Par la suite, le traitement des données se fait à l’aide du logiciel DAQExpress
(logiciel développé par National Instrument). Sur celui-ci, il existe deux fonctions
principales :
 Le traitement des données (VI’s),
 La configuration et la visualisation directe de la mesure des entrées/sorties.
Les entrées sont configurées d’après les mesures de tension, de courant obtenues. Par la
suite, données stockées seront enregistrées dans des fichiers « .csv ». Un programme envoie
les données sur un serveur, puis, un autre programme récupère les données sur le serveur et
les affiche sur une interface. La programmation se fait à l’aide du langage en Python 3.
Le projet a été réparti en deux grandes parties : la première partie qui traite les données puis
les envoie et la seconde qui les récupère pour pouvoir ensuite les afficher.
Schéma explicatif du projet « Interface de gestion d’énergie »
Il a fallu en premier lieu approfondir nos connaissance de programmation en Python 3 ainsi
qu’apprendre à utiliser le logiciel DAQExpress, semblable au logiciel LabView que nous
avions déjà utilisé.

I. Partie traitement des données (présentation DAQExpress) :
Acquisition des données :
Pour l’acquisition des données, on utilise le logiciel DAQExpress. Tout d’abord, il a fallu
créer un fichier au format « .csv » pouvant stocker les données. Grâce à ce format,
l’organisation des données permet que celles-ci soient envoyées sur le serveur déjà créé
auparavant par les MMI de l’IUT de Mulhouse. Les données sont traitées (diagramme sous
DAQExpress), puis envoyées et enregistrées dans un fichier dont le chemin sur l’ordinateur
a été défini préalablement. L’échantillonnage de la mesure est de 15kHz. Nous avons un
échantillonnage élevé sur une mesure de tension, ce qui lui permet d’être précise.
L’acquisition est à ce stade stoppée par un bouton stop, elle est donc non quantifiée.
Le problème majeur rencontré a été la séparation des informations reçues. Ces
dernières étaient écrites dans le fichier en chaîne de caractères dans une colonne du fichier
au format csv. Il a fallu les séparer par des points-virgules. Ceux-ci sont ensuite retranscrits
par un changement de colonne.

 

Traitement du signal récupéré :
Par la suite, nous avons échantillonné les données à 7 kHz pour pouvoir récupérer la
valeur moyenne de chaque mesure. Elles sont ensuite traitées en les multipliant par l’échelle
des sondes, puis multipliées entre elles pour avoir la puissance. Les valeurs
sont inscrites dans le fichier. Pour pouvoir les traiter, les données, brutes, changent de
« type » pour permettre certaines opérations :
 En tableau pour les grouper
 En nombre décimal pour les calculer
 En chaîne de caractère pour les écrire

Pour pouvoir inscrire les données dans le fichier, on doit les organiser dans un ordre
conventionnel. Nous avons choisi de les organiser dans l’ordre suivant :
1) tension
2) courant
3) puissance
Cet ordre permettra à la partie qui réceptionne et affiche de connaître la correspondance
entre la donnée et sa signification.
Pour finir, nous avons rajouté plusieurs entrées. Nous avons pris 6 entrées : 3 mesures de
tension et 3 mesures de courant. Au total, 9 valeurs sont envoyées : 3 valeurs de tension, 3
valeurs de courant et 3 de puissance. Enfin, il a fallu rajouter la date et l’heure de la mesure
des relevés. Nous avons décidé d’enregistrer chaque mesure dans un fichier .csv qui lui est
propre. Ce fichier commence par le bandeau de présentation de l’ordre des données. Les
valeurs affichées sont le temps puis les neuf mesures.

 

Envoi des données :
Nous devons ensuite envoyer les données. Nous avons donc fais un programme en
Python 3. Le programme scanne le fichier .csv, extrait la date, puis les données et les envoie
via un URL au serveur.

Dans un premier traitement de fichier sur DAQ Express nous avions mis un caractère« * »
marquant la fin du fichier. Par la suite nous avons trouvé une fonction en Python qui
retournait la longueur des données du fichier. Par conséquent, ce caractère était inutile. Au
final, nous avons complété ce caractère par la valeur du temps d’attente entre chaque
mesure. Cette donnée nous permet de régler une fonction Timer dans le programme d’envoi
Python. Il nous suffit maintenant de lancer le programme Python (envoi.py), puis de lancer
l’acquisition de données. DAQ Express crée un fichier pour chaque mesure. A la fin de
l’écriture de chaque mesure, le programme envoie les données du dernier fichier créé. Il faut
ensuite arrêter le programme.

II. Partie création d’interface et gestion des données :
Interface :
En premier lieu, il a fallu apprendre le langage Python. Sur Python nous utilisons la
bibliothèque Tkinter, pour afficher les valeurs obtenues depuis la base de données sur une
interface graphique pour pouvoir les visualiser. Nous a commencé à faire des essais
d’affichages « brutes » de la base de données (date, tension, courant) dans la même frame. Le
résultat n’était pas très lisible.
Pour pouvoir faire cela il a fallu créer 9 blocs (V1, V2 et V3, I1, I2 et I3 et P1, P2 et
P3). Nous avons commencé par créer une interface avec un design plutôt simpliste sans trop
de couleurs, ni d’images afin de ce concentré exclusivement sur la récolte et la visualisation
des données. Nous avons commencé par importer des données d’un fichier .txt et .csv. Nous
nous sommes ensuite diviser le travail encore une fois en 2 partie (Maxime qui fait le
design, et Valentin pour la partie séparation des données et affichage sur l’interface).
Mais cette séparation n’était valable que sur un fichier csv qui devait être sur le même
PC pour pouvoir fonctionner.Il a fallu adapté le code pour extraire les données mais cette
fois depuis la base de données.
Jusqu’à présent les données s’actualisaient manuellement via un bouton situé sur
l’interface. A la demande de M.DROUAZ , nous avons commencé à chercher des solutions
quant à la création d’une actualisation automatique. Suite aux nombreuses difficultés que
cela représentaient,le chef de projet et les 2 responsables de l’interface ont joint leurs efforts.
L’actualisation automatique est d’ailleurs toujours en phase de recherche et de création.

 

Problèmes rencontrés :
Nous avons rencontrés des problèmes sur le placement des différents blocs et sur la
récolte des données. Le fait d’avoir été dans une perpétuelle appréhension du langage
Python avec les objectifs qui nous étaient donnés rendait la tâche difficile. Le code était lui
aussi fastidieux car chaque bloc était constitué de 2 Frames et de 2 Labels. (Une Frame est
un conteneur permettant de séparer des éléments et un Label un espace dans laquelle on
peut écrire du texte). Et le fait de décupler cela pour tous les blocs de tensions de courants et
de puissances rendait le code très chargé et pas très lisible.

Erreur courante :

Le système ne trouve pas le contenu du tableau contenant les valeurs successives de tension, courant et puissance

 

Solutions apportées :
Après une meilleure appréhension du langage Python, nous avons pu exploiter au
maximum ce langage. Afin de remédier aux problèmes rencontrés, nous avons décidé de
revoir notre code quant à la mise en forme de l’interface graphique. Nous avons décidé
d’insérer une image contenant initialement les 9 blocs qu’il nous faut pour n’y insérer que le
texte pour l’affichage de données. Ce qui fait qu’il n’y a plus de Frames et plus de Labels ce
qui nous a permis d’avoir un gain de place dans le code non négligeable.
Après de gros problèmes rencontrés pour l’actualisation automatique de la fenêtre,
nous avons décidé de placer un bouton « Ouvrir » permettant à chaque clic effectuer, de
pouvoir effectuer une actualisation. C’est-à-dire que sur un nombre défini de mesures
récoltés par DAQ Express et envoyés directement à la base de données, on récupère à
chaque clique, le dernier échantillon ce trouvant dans la base de donnée. Cette méthode est
quant à elle facile à mettre en place et à codé, c’est pour cela qu’on l’utilise.

III. Conclusion :

Ouverture du projet :
Actuellement, nous avons réussi a collecter les données et a les envoyer sur le
serveur. Nous avons aussi une interface dont le design est terminé. Nous affichons donc les
valeurs à partir du serveur.
Il nous reste une actualisation automatique à ajouter. Nous pourrions aussi
développer la prise en charge des mesures pour en faire un graphe évolutif de la puissance
sur une une longue période de mesure.