Sommaire

1. Introduction – Composition et rôles de l’équipe
2. Définition du besoin – Outils d’analyse fonctionnelle et définition du système
3. Analyse solaire – Étude de la trajectoire du soleil et ensoleillement
4. Analyse mécanique – Conception et dimensionnement d’un support
5. Analyse électrique – Asservissement du système et normes électriques
6. Solution finale – Présentation de la solution retenue
   
7. Conclusion

1. 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 de 5 panneaux solaires. 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 4 étudiants. Les rôles, définis en début de projet, sont les suivants :

• DI MAURO Bastien – Définition du besoin et conception sous CREO
• HIRTH Matthieu – Analyse électrique et asservissement du système
• MANSUY Guillaume – Analyse mécanique et conception sous CREO
• SITTERLE Hugo – Analyse mécanique et choix de la motorisation

L’analyse de la trajectoire du soleil ou encore de la position du support dans l’IUT ont été étudiée par l’ensemble des membres de l’équipe.

2. Définition du besoin :

La première étape du projet est la définition du besoin. L’objectif est de définir les éléments à traiter, ainsi que les problématiques et les contraintes du projet.

Le diagramme des prestations nous permet de définir la fonction principale du système Tracker.

Le système Tracker permet à l’utilisateur de programmer la structure dans le but de suivre la trajectoire du soleil, et ainsi de maximiser le rendement de la production.

Le diagramme des interacteurs permet de mettre en évidence les fonctions principales et les fonctions contraintes.

• FP1 : Orienter le panneau solaire en fonction de la trajectoire du soleil
• FC1 : Résister au poids des panneaux
• FC 2 : Positionner le système sur un espace exposé au soleil
• FC 3 : Alimenter le système
• FC 4 : Résister aux conditions extérieures (Usure, rouille, vent)
• FC 5 : Faciliter la maintenance du matériel électrique présent sur le système

Nous avons également réalisé un diagramme FAST. Ce dernier nous permet de définir les solutions constructives choisies pour répondre aux problématiques.

Pour terminer, en reprenant les termes du diagramme des interacteurs, nous avons établi le tableau de caractérisation des fonctions :

Légende :

• FP: Fonction Principale
• FC: Fonction Contrainte
• Flexibilité F0: Flexibilité nulle – Niveau impératif
• Flexibilité F1: Flexibilité faible – Niveau peu négociable
• Flexibilité F2: Flexibilité bonne – Niveau négociable
• Flexibilité F3: Flexibilité forte – Niveau très négociable

3. Analyse solaire

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

• L’azimut,
• La hauteur,

L’azimut représente la position du soleil  selon les quatre points cardinaux et la hauteur représente l’inclinaison du soleil par rapport à l’origine d’un plan horizontal. L’asservissement se fait grâce à ces deux paramètres. Les panneaux solaires doivent se situer perpendiculairement aux rayons du soleil pour une production optimale.

A travers cette analyse nous allons décider de l’orientation à donner au système afin de garantir un rendement maximal. La localisation géographique du système nous est imposée et se situe entre le bâtiment GEII et GMP.

Dans un premier temps nous avons identifié la trajectoire du soleil sur l’emplacement choisit à l’aide du site SunEarthTools.

A partir de cette trajectoire nous avons pu en déduire l’heure à laquelle l’ensoleillement est maximal, soit environ 11h30 en été.

Le système sera donc orienté en direction du Sud, où le soleil est à son zénith.

Les rayons du soleil étant les plus importants entre environ 9h et 15h, cela nous donne une amplitude d’environ 100° en azimut à prévoir entre le début et la fin de journée. Cependant à cause du relief, des bâtiments et des arbres présents sur les lieux une amplitude de rotation inférieure serait suffisante.

La hauteur du soleil varie entre 20° et 65° environ au fil des saisons lorsque les panneaux produiront le maximum.

A l’aide d’un second site (http://re.jrc.ec.europa.eu/pvgis/apps4/pvest.php?lang=lang=fr&map=europe), nous avons estimé la production potentielle d’un tel système. Nous avons pu réaliser un comparatif entre un système fixe, un système asservi sur 1 axe de rotation (l’azimut) et un système asservi sur 2 axes de rotation (hauteur et azimut).

Nous nous sommes alors rendu compte qu’un système à deux axes de rotation n’était pas d’une grande valeur ajoutée par rapport à un système à un axe de rotation. De plus, la conception d’un système deux axes serait plus complexe et plus coûteuse.

Nous avons donc décidé de réaliser un système de Tracker solaire asservi sur un seul axe, l’azimut. Le système serait alors incliné de manière fixe par rapport à la hauteur moyenne du soleil, soit environ 40°.

E_d: Production moyenne par jour du système (kWh)

E_m: Production moyenne par mois du système (kWh)

4. Analyse mécanique

1. Choix de la motorisation

Après avoir déterminé l’inclinaison maximale nécessaire, il a fallu faire un choix sur le type de motorisation qui équipera le système. Pour cela, une étude de différentes solutions a été réalisé afin d’en choisir une qui correspondra au mieux à l’exigence principale du cahier des charges, faire pivoter le panneau avec un angle de 40°.

Cependant il a fallu respecter d’autres contraintes :

• La motorisation doit être facilement programmable avec les cartes Arduino
• La motorisation doit prendre le minimum de place
• La motorisation doit être étanche

Le tableau de comparaison ci-dessous nous permettra de comprendre le choix final de notre motorisation.

Après étude, notre choix s’oriente sur le vérin de parabole. Il répond parfaitement à nos différentes contraintes et peut être mise en place rapidement sans gros travaux sur la structure. La mise en place du vérin sur la structure nécessite cependant la conception d’une pièce spécifique permettant l’assemblage de ce dernier avec la structure.

Grâce à la modélisation sur le logiciel CREO3 nous savons exactement la position du vérin sur le cadre ainsi que sur les panneaux solaires.

Nous avons trouvé un vérin sur le site de « Transplanet », cependant après commande de celui-ci, le vérin n’est malheureusement jamais arrivé.

2. Structure

L’objectif de ce projet étant de rendre mobile 4 panneaux solaires, il s’agit de développer une structure mécanique supportant la charge des panneaux et comprenant des liaisons mécaniques permettant de satisfaire les paramètres abordés dans l’analyse de l’ensoleillement.

Après avoir étudié la possibilité d’intégrer deux axes de rotation pouvant supporter les panneaux solaires, il s’est avéré que la structure serait trop complexe et importante à réaliser.

De ce fait nous avons décidé d’asservir les panneaux sur 1 axe de rotation permettant un suivi du soleil durant la journée (l’azimut). Les panneaux seraient alors inclinés de manière fixe selon la hauteur moyenne du soleil (environ 40°).

Cependant avec une telle inclinaison un système supportant 4 panneaux atteindrait des dimensions trop importantes (hauteur de la structure supérieure à 4 m, résistance des matériaux).

Le système a donc été divisé en deux. Ce dernier devra supporter 2 panneaux et sera dupliqué pour les 2 autres restants.

En respectant les paramètres d’inclinaison est en laissant une marge de départ d’environ 1 m par rapport au sol afin d’éviter les collisions entre les panneaux et le sol, la hauteur et la longueur du système seraient d’environ 2 m. Nous avons décidé de solidariser les panneaux solaires selon leurs largeur afin réduire au maximum la taille du système. La largeur d’un panneau étant de 998 cm, l’axe supportant le poids des panneaux et permettant leurs rotation devra être supérieur à 2 m. Ce dernier doit être assez résistant pour :

• Ne pas fléchir sous le poids des panneaux (18 kg par panneau donc 36 kg pour deux),
• Assurer une durée de vie importante à la structure (ne pas rouiller),
• Limiter la masse de la structure mobile afin de réduire les efforts appliqués sur la structure fixe.

En premier nous sommes partie sur une structure composée :

–  D’une structure mobile comportant :

• Un tube servant d’axe de rotation,
• D’un cadre en profilé « U » solidarisant les deux panneaux,
• Deux traverses permettant la fixation des panneaux,
• Deux colliers filetés permettant le serrage des panneaux sur le tube support.

–  D’une structure fixe, supportant la structure mobile, comportant :

• Deux supports « triangles »,
• Deux paliers permettant la rotation de la structure mobile,
• Deux supports pour paliers permettant de donner l’inclinaison souhaitée aux paliers,
• Des rails de fixation permettant l’ancrage des « triangles » dans les fondations.

Les deux supports « triangles » sont de tailles différentes afin de donner l’inclinaison fixe aux panneaux. Une structure en forme de triangle a été choisie afin de mieux répartir les efforts et d’augmenter l’amplitude de rotation des panneaux. Un troisième « pieds » a été conçu pour le petit « triangle » afin de compenser le glissement des panneaux : la structure étant inclinée, les efforts se retrouvent concentrés sur le petit support. De plus, l’empattement important des triangles permet une meilleure stabilité du système face au vent ou à la neige. La fixation au sol de l’ensemble étant réalisé à l’aide de rails de fixation, la structure serait facilement démontable si besoin.

Cependant la structure devant être assemblée par soudage, avec la complexité des angles, il s’est avéré que la structure serait trop complexe à réaliser. De plus la structure fixe n’était pas assez rigide, les deux supports « triangles » devaient être solidaire.

Nous avons donc repensé la conception des supports de manière plus simple et sommes partis sur une base rectangulaire.

Deux rectangles en profilé carré reprenant les hauteurs des deux triangles seraient alors solidarisés par deux renforts horizontaux situés au sol et un renfort incliné se situant en dessous de l’axe de rotation des panneaux.

Des calculs de dimensionnement ont été réalisés sur la barre support des panneaux solaires. Cette étude a été réalisée sur une barre acier et aluminium ronde et creuse dont le diamètre extérieur est de 40 ou 50 mm avec une épaisseur variable, allant de 1 à 3 mm. Nous avons choisi une barre de diamètre 40 mm et d’épaisseur 2 mm en acier : celle-ci présente une flèche raisonnable de 19 mm en sachant que la force de 1000 N (en réalité la charge supportée par la barre est de l’ordre de 400 N) est appliquée en un point, au milieu de la barre.

3. Choix des paliers

Les panneaux solaires sont entrainés en rotation par un vérin électrique. Le vérin, fixé sur la structure métallique (Grand support), va entraîner le cadre d’assemblage des panneaux. Le débattement des panneaux dépendra de la course maximale du vérin.

La rotation de la traverse s’effectue par le biais de roulements à billes. Afin de bloquer la traverse en translation, nous avons choisis des paliers comportant des manchons. Les caractéristiques des paliers sont les suivantes :

• Palier à semelle en deux parties – Référence SNG 509
• Diamètre : 40 mm
• Entraxe des perçages de fixation : 170 mm
• Matière du palier : Fonte
• Roulement à billes – Référence SKF 1209K
• Manchon de serrage – Référence H209
• Bagues – Référence SR85X5,5
• Kit joints fourni – Référence TSNU509

Lien vers le revendeur : https://www.lebonroulement.com/tous-les-paliers-fonte/180149-palier-fonte-en-deux-parties-sng5091209k.html

Comme indiqué ci-dessus, les paliers vont permettre la rotation de la traverse supportant les panneaux, mais va également permettre l’arrêt axial de la traverse grâce au manchon.

Le montage de la traverse dans les paliers s’effectue de la manière suivante :

• Montage des paliers sur la structure métallique
• Montage de la traverse dans les paliers
• Serrage du manchon présent dans le palier inférieur une fois la traverse positionnée

4. Structure fixe

Le nombre de panneaux solaires étant passé à 5, nous avons changer la conception du support devant être fixe afin qu’il supporte 3 panneaux. L’inclinaison donnée au support fixe est la même que celle du support mobile, soit 33°. Cela permettra aux étudiants de réaliser un comparatif de la production solaire d’un système fixe et d’un système mobile.

5. Analyse électrique

Normes

Avant de commencer les analyses sur les panneaux, nous avons dû nous renseigner sur les normes existantes concernant l’installation de panneaux photovoltaïques raccordés au réseau telles que :

• Protection contre les chocs électriques
• Protection contre les surintensités
• Protection contre la foudre
• Signalisation
• Emplacement du coffret de mise en sécurité pompiers

Après avoir pris connaissance des normes liées aux panneaux, une nouvelle question s’est posée : faut-il brancher les panneaux en série ou en parallèle (ou les deux) ?

Lorsque les panneaux sont en série, les tensions s’additionnent. Lorsqu’ils sont en parallèle c’est les courants qui s’additionnent.

L’onduleur disponible exige une tension minimum de 140V. Concernant ses limites maximales, on atteint 400V et 10 A.

Le seul circuit possible est avec tous les panneaux en série.

Schéma électrique

Les panneaux en série sont reliés tout d’abord au coffret de securisé pompiers. On arrive ensuite dans la partie continue du boîtier de sécurité avant de passer par l’onduleur. Ce dernier va faire passer la tension en alternatif qui va repasser par le boîtier de sécurité mais dans la partie alternative. Enfin le courant arrive dans le réseau de l’IUT et alimente ce qui en a besoin.

L’ensemble est relié à la terre pour la protection parafoudre.

Montage

Pour rendre les panneaux mobiles et pour les faire suivre le soleil, il faut un système de tracker. Ce système est composé d’une carte Arduino Uno, d’un Motor Shield, d’une breadboard, de 2 photorésistances, de 2 résistances et d’un moteur.

Montage – Réalisé à l’aide du logiciel Fritzing

Le Motor Shield est directement empilé sur la carte Arduino et permet de piloter plusieurs moteurs jusqu’à 48V. Il pilotera le moteur permettant la rotation des panneaux.

lien : semageek

Les photorésistances sont reliées aux ports analogiques A2 et A3 de la carte. La sensibilité d’une photorésistance peut être changée en fonction de la valeur de la résistance reliée au Gnd. Plus la résistance est élevée, plus la sensibilité de la lumière sera forte et adaptée aux faibles intensités lumineuses. Au contraire, une résistance plus faible comme 100 Ω est plus adaptée en milieu ensoleillé.

Les deux photorésistances seront séparées par une pièce qui fait de l’ombre à l’une des deux quand les rayons du Soleil ne leur sont pas perpendiculaires.

Programmation

Lorsqu’il fait jour, le programme teste continuellement la valeur des photorésistances. Quand une différence de valeurs entre les 2 photorésistances est trop importante, une prise de valeurs est lancée pour réaliser une moyenne sur chaque photorésistance. Si l’écart entre les moyennes est supérieur à une valeur donnée, une tension s’applique aux bornes du moteur jusqu’à que la photorésistance la moins éclairée dépasse la valeur de l’autre. Le signe de la tension dépend de la photorésistance la plus éclairée.

Lorsqu’il fait nuit, la valeur de chaque photorésistance atteint 0. Les panneaux se placent alors en direction du levé du Soleil et s’arrêtent.

Programme

6. Solution finale

7. Conclusion

L’étude du projet a été réalisée cependant nous n’avons pas réussi à mettre en œuvre la solution conçu. Notre commande tardive de matériel ne nous permet malheureusement pas de réaliser la structure. Différents devis auprès de différents fournisseurs ont été réalisé, mais pour la plupart nous sommes toujours en attente de réponses.

Tous les plans des éléments présentés dans cet article ainsi que la liste des éléments à commander avec le nom des fournisseurs sont à disposition pour un éventuel prochain groupe d’étudiants souhaitant terminer le travail commencé.

Les documents sont disponibles en annexe ci-dessous (plans, devis et matériel nécessaire,etc.).

Annexes :

Mise en plan – Support fixe

Mise en Plan – Support mobile

Commande du matériel

Support Mobile

Support Fixe

Participant

• KERNACKER Thomas(GMP)
• ASTRIC François-David (GMP)
• KUPFER Paulin (GEII)

Le Lanceur (GMP)

Le projet du lanceur consiste à lancer une balle de squash de 24g dans une cible (panier) à une distance de 10m.

La contrainte que nous possédions était de faire tenir notre système complet dans un cube de 25 cm³.

Définition du besoin

Le diagramme « Bête à corne » nous permet de définir la fonction principale du lanceur.

Le diagramme « Pieuvre » permet de définir les fonctions principales et les fonctions contraintes de notre système.

Schéma Cinématique

La Conception

Au niveau de la conception du lanceur, nous avons décidés de nous rapprocher de l’idée du canon.

Le corps principale du lanceur est un fût où l’on vient placer les divers éléments du système d’armement et de propulsion.

Lanceur 3D

Au départ, nous avions envisagés trois solutions différentes pour armer notre lanceur.

La solution de gauche consiste à compresser un ressort de compression pour propulser la balle. L’inconvénient de cette solution est qu’elle n’est pas très modulable car l’on ne peut placer qu’un seul ressort.

La solution du centre consiste à tendre des élastiques pour envoyer la balle. Cette solution est pratique car l’on peut ajouter ou retirer facilement les couches d’élastiques pour régler la puissance de tir.

La dernière solution consiste à tendre des ressorts de tractions. Nous avons choisis cette solution car elle est assez modulable, on peut placer jusqu’à 4 ressorts sur le système, mais aussi pour le fait de travailler avec de « vrais » composants mécaniques.

Le lancé

Tout d’abord il nous a fallu déterminer les conditions avec lesquelles nous enverrons notre balle de squash à 10m. Nous supposons au départ plusieurs variables :

• Durée de vol de la balle de squash = 0.5s pour un tir très rapide
• Angle de tir = 15° pour un tir tendu
  

  

Grâce aux équations du mouvement, nous trouvons une vitesse de balle égale à 14m/s.

Pour évaluer l’énergie nécessaire au tir d’une balle de squash de 24g, nous avons alors réalisé un tableau Excel, nous donnant une énergie d’environ 2.3 Joule.

Cette valeur est très satisfaisante car situé après la chute de la courbe de l’énergie.

Dimensionnement

Avec la vitesse de 14m/s, nous déterminons ensuite les ressorts et moteurs nécessaires à la charge du tir.

Nous trouvons alors une raideur de ressort d’environ 4N/mm. Selon notre conception, celle-ci sera acquise grâce à 4 ressorts d’1N/mm chacun ou 8 ressorts de 0.5N/mm.

De même, nous déterminons un couple de sortie nécessaire à l’armement de 0.81N.m.

Nos recherches sur différents moteurs déjà disponible au sein de l’IUT nous ont permis de récupérer un petit moteur avec un couple de 3kg.cm, ce qui équivaut à 0.29N.m.

Son couple n’étant pas suffisant, il nécessitera l’accompagnement d’un système de réduction.

Par la suite nous avons déterminés le nombre de dents des deux roues dentées afin d’obtenir un couple de 0.28N.m.

Pour le système de réduction; on considérera un rendement hypothétique de 0.85.

Le système d’armement

Afin d’armer notre lanceur, nous avons conçus un système d’armement reprenant le principe d’un treuil.

Système d’armement 3D

Pour ce faire, on entraîne un axe avec un moteur accompagné d’un système de réduction. Cet axe va enrouler un câble en acier qui va ensuite tendre notre système de propulsion.

Nous avons dimensionnés nos engrenages de tel sorte à pouvoir récupérer un moteur fourni par l’IUT, ce qui nous évite des frais supplémentaires pour notre projet.

La pièce la plus complexe de système est l’axe car il doit avoir une tolérance géométrique élevé sur toute sa longueur (∅4 g6) pour permettre un ajustement juste glissant dans le cylindre tendeur.

Plan axe 2D

Cylindre tendeur 3D

L’axe est situé en dessous de la section droite du tube car il faut permettre au câble en acier de s’enrouler autour du cylindre tendeur de façon à garder le système de propulsion coaxial avec le fût.

L’arrêt axial de l’axe s’effectue par deux anneaux élastiques car il ne subit pas d’effort axial particulier. Il est guidé par deux coussinets en bronze afin de minimiser les frottements et d’avoir un rendement le plus élevé possible.

Coussinet en bronze

L’ensemble des pièces sont en aluminium dû à la légèreté de cette matière sauf l’axe qui est quant à lui en acier, afin de ne pas se faire cisailler par le câble en acier.

Le système de propulsion

Afin de propulser la balle de squash, nous avons conçu un tige guidée en translation à travers le fût du lanceur par une douille en plastique Igus.

Nous avons choisis cette douille en plastique car sa technologie lui permet d’avoir un coefficient de frottement très faible, qui se rapproche de la qualité d’une cage à bille, à moindre coût.

Système d’armement 3D

Douille plastique Igus 3D

L’ensemble de la tige est composé de 4 pièces afin de pouvoir la monter dans notre système de propulsion.

Ces quatre pièces sont mises en positions par guidages cylindriques et sont ensuite vissées sur l’axe de la tige.

Vue éclatée de la tige 3D

Le système de propulsion comportera donc 2 paires de ressorts différents suite à la rupture de stock de nos fournisseurs.

Ces ressorts sont fixés sur le disque et la tige afin de propulser l’ensemble de la tige, guidée par la douille en plastique.

Le disque est fixé dans le fût par deux vis M4 et est ensuite goupiller pour lui permettre de bien rester fixe suite aux efforts qu’il va subir.

La pièce tenant la câble en acier a été conçu afin de permettre au câble de bien rester dans le plan de la section droite du fût.

Pièce porte-câble 3D

L’ensemble des pièce sont en aluminium pour minimiser le poids du système.

Fixation au bâti

L’ensemble du fût est tenu par une pièce intermédiaire permettant de la tenir est de régler son angle de tir. Malheureusement, faute de temps, nous n’avons pas pu réaliser ce système.

Fixation tube 3D

Le Système de Visée (GEII)

Le système de visée sera par reconnaissance visuel d’une couleur autour de la cible . Il fonctionnera sur le principe d’un tracking de couleur rouge et d’une gestion de 2 servos-moteur.

Le Matériel

• 2 Servo-moteur. J’ai utilisé des moteur 50 Hz, la Fréquence est importante à connaitre car il faut la renseigner dans certains programmes, en effet un servo moteur fonctionne avec pour consigne une impulsion de 1 à 2 ms sur sa fréquence de fonctionnement. Pour la bibliothèque servo.h la fréquence est calculée toute seul.
• Un Raspberry pi au minimum 2 (je n’ai pas testé sur une version antérieur).Il est nécessaire d’avoir une certaine puissance de calcul pour faire du traitement d’image.
• Une camera Pi module V1 suffi car à 10 metre une cible de 1m mesure 11 pixel de rayon soit une tache de 380 pixel. Le calcul vaut : rayon=2549*1/tan(26.75) *10 . L’aire = rayon * rayon * pi.

Le système

Il n’est pas très compliqué. La Caméra pi a son emplacement dans la carte. Les servo-moteurs peuvent avoir leur alimentation extérieur mais on peut aussi les câbler sur le 5 V de la Raspberry. Il faut aussi réunir toutes les masses. Les codes couleurs des câbles des servo moteur sont precis: brun = la terre, rouge = le +, jaune = la consigne.

Le Programme

Le programme est donc un tracking du rouge(h = 20, s = 240, v = 200) on aurait aussi pu le faire avec d’autre couleur mais il faut en avoir une qui ne soit pas confondable avec l’élément du décor.Le programme complet sera en fin de ce paragraphe, il incluras tout les outils facilitant le paramétrages du système.

Le programme consiste en trois parti:

1. Le traitement de l’image
2. Positionnement des coordonné
3. Mise en mouvement des moteurs

Le traitement de l’image est une binarisation des pixels rouges en blanc. Pour cela il faut d’abord passer l’image de BGR (bleu, vert, rouge) en HSV (teinte, saturation, brillance). Ensuite le programme crée un masque de recherche qui passe sur chaque pixel pour le comparé.

En second, le programme va récupérer les coordonnés de la plus grande tache, cette tache sera notre cible, il faudra parfois ajuster les valeur de s et h en fonction du décor car la luminosité peut faire varier ces valeurs. Cette partie calcul le centre de gravité de la tache et il déplace petit à petit les anciennes coordonnées. Lorsque ceci est fait, il dessine le cercle nous permettant de voir quelle tache il a désigné comme étant la plus grosse de notre image.

Enfin on va calculer l’angle à ajouter au lanceur pour qu’il puisse se replacer en face de la cible. Pour ce calcul il faut ajouter à l’ancien angle, le nouvelle angle qui vaut le rapport difference de pixel par rapport au centre sur les pixel max fois l’angle.

Avec la bibliothèque Servo on a seulement besoin de renseigner l’angle. Certain comme GPIO sur Raspberry demande des calculs supplémentaires dépendant de vos moteur mais ce sera toujours sur la base de a+(angle/180)*b.

Voici le programme:

#include « opencv/highgui.h »

#include « opencv/cv.h »

#include <iostream>

#include <stdlib.h>

#include <stdio.h>

#include <servo.h>

//methode mathematique

#define max(a, b) ((a) > (b) ? (a) : (b))

#define min(a, b) ((a) < (b) ? (a) : (b))

#define abs(x) ((x) > 0 ? (x) : -(x))

#define sign(x) ((x) > 0 ? 1 : -1)

// pas de l’object

#define STEP_MIN 5

#define STEP_MAX 100

IplImage *image;

// position de reference

CvPoint objectPos = cvPoint(-1, -1);

// parametre de couleur

int h = 20, s = 240, v = 200, tolerance = 15;

/*

* binarisation de l’image

*/

CvPoint binarisation(IplImage* image, int *nbPixels) {

int x, y;

CvScalar pixel;

IplImage *hsv, *mask;

IplConvKernel *kernel;

int sommeX = 0, sommeY = 0;

*nbPixels = 0;

Pif paf pouf

// creation du masque de binarisation

mask = cvCreateImage(cvGetSize(image), image->depth, 1);

// recreer l’image en couleur HSV

hsv = cvCloneImage(image);

cvCvtColor(image, hsv, CV_BGR2HSV);

// creation du masque de recherché de couleur

cvInRangeS(hsv, cvScalar(h – tolerance -1, s – tolerance, 0), cvScalar(h + tolerance -1, s + tolerance, 255), mask);

// definition de l’outil de reconnaissance

kernel = cvCreateStructuringElementEx(5, 5, 2, 2, CV_SHAPE_ELLIPSE);

// filtrage des parasite

cvDilate(mask, mask, kernel, 1);

cvErode(mask, mask, kernel, 1);

// On cherche le centre de l’objet

for(x = 0; x < mask->width; x++) {

for(y = 0; y < mask->height; y++) {

// Si le pixel est un de ceux tracké le prendre en compte pour le centre de gravité.

if(((uchar *)(mask->imageData + y*mask->widthStep))[x] == 255) {

sommeX += x;

sommeY += y;

(*nbPixels)++;

}

}

}

// affichage sur écran pour les tests

cvShowImage(« GeckoGeek Mask », mask);

cvReleaseStructuringElement(&kernel);

cvReleaseImage(&mask);

cvReleaseImage(&hsv);

// Si l’on a rien on considère l’objet au centre

if(*nbPixels > 0)

return cvPoint((int)(sommeX / (*nbPixels)), (int)(sommeY / (*nbPixels)));

else

return cvPoint(-1, -1);

}

/*

* ajout d’un cercle indicatif renseignant la position de l’objet

*/

Point addObjectToVideo(IplImage* image, CvPoint objectNextPos, int nbPixels) {

int objectNextStepX, objectNextStepY;

// Calcul de la position du cercle

if (nbPixels > 10) {

// Si aucune position trouvé

if (objectPos.x == -1 || objectPos.y == -1) {

objectPos.x = objectNextPos.x;

objectPos.y = objectNextPos.y;

}

// Deplacement du cercle vers l’object

if (abs(objectPos.x – objectNextPos.x) > STEP_MIN) {

objectNextStepX = max(STEP_MIN, min(STEP_MAX, abs(objectPos.x – objectNextPos.x) / 2));

objectPos.x += (-1) * sign(objectPos.x – objectNextPos.x) * objectNextStepX;

}

if (abs(objectPos.y – objectNextPos.y) > STEP_MIN) {

objectNextStepY = max(STEP_MIN, min(STEP_MAX, abs(objectPos.y – objectNextPos.y) / 2));

objectPos.y += (-1) * sign(objectPos.y – objectNextPos.y) * objectNextStepY;

}

} else {

objectPos.x = -1;

objectPos.y = -1;

}

// On dessine le cercle

if (nbPixels > 10)

cvDrawCircle(image, objectPos, 15, CV_RGB(255, 0, 0), -1);

cvShowImage(« GeckoGeek Color Tracking », image);

//retour des coordonee du point

Return objectPos;

}

int main() {

Servo moty;

Servo motX;

Point viseur;

Float x;

Float y;

Moty.attach(8);

Moty.attach(7);

while(1)

// Image & hsvImage

IplImage *hsv;

// Video Capture

CvCapture *capture;

int nbPixels;

CvPoint objectNextPos;

// initialization de la capture video

capture = cvCreateCameraCapture(200);

if (!capture) {

printf(« Video non prise.\n »);

return -1;

}

// creation de la fenetre

cvNamedWindow(« test « , CV_WINDOW_AUTOSIZE);

cvNamedWindow(« test Mask », CV_WINDOW_AUTOSIZE);

cvMoveWindow(« test Color Tracking », 0, 100);

cvMoveWindow(« test Mask », 650, 100);

// On prend l’image courrante

image = cvQueryFrame(capture);

objectNextPos = binarisation(image, &nbPixels);

viseur = addObjectToVideo(image, objectNextPos, nbPixels);

//mise en mouvement des moteurs

x=viseur.x/2549*26.75+x; //angle que l’on veut rajouter(2549 la resolution/26.75 l’angle de vue)

y=viseur.y/1944*20.7+y;

moty.write(y) ;

motx.write(x) ;

delay(15) ;

// Destruction de la fenetre

cvDestroyWindow(« test Color Tracking »);

cvDestroyWindow(« test Mask »);

cvReleaseCapture(&capture);

return 0;

}

Avancement

Le projet n’a pu être fini fautes de temps, ma principal difficulté ne fut pas dans le programme car chaque partie était assez simple mais dans l’installation de l’opencv sur Raspberry. Je n’ai jamais réussi à l’installer puis l’utiliser sur 2 raspberry différent. J’ai aussi pris du retard car après une mauvaise manipulation j’ai grillé une Raspberry du au nombreux changement durant mes test des moteurs en Arduino

L’équipe ayant réalisée le projet :

Johann GRINAN (GEII)

Jérôme WILLIG (GEII)

Hugo MACCAGLIA (GMP)

Jonathan MEISTER (GMP)

Noémie HARDY (GMP)

Sommaire

                                         1. Introduction

2. Analyse fonctionnelle

3. Réalisation côté GEII

4. Réalisation côté GMP

                                         5. Conclusion

                                         6. Documents annexes

Introduction

L’impression 3D est l’appellation « grand public » des procédés de fabrication de pièces en volume par ajout ou agglomération de matière. L’impression 3D permet de réaliser un objet réel : un concepteur dessine l’objet 3D grâce à un outil de conception assistée par ordinateur (CAO). Le fichier 3D obtenu est traité par un logiciel spécifique qui organise le découpage en tranches des différentes couches nécessaires à la réalisation de la pièce. Le découpage est envoyé à l’imprimante qui dépose ou solidifie la matière couche par couche jusqu’à obtenir la pièce finale. Le principe reste proche de celui d’une imprimante 2D classique à cette grande différence près : c’est l’empilement des couches qui crée le volume.

De ce fait, cet outil est indispensable pour les étudiants du département Génie Mécanique et Productique (GMP) afin de réaliser tous types de pièces, et donc l’IUT en possède quelques unes. Cependant, les professeurs de ce département nous ont rapporté un problème à l’utilisation de leurs imprimantes : Les temps d’impression étant long (peuvent durer des jours), aucun moyen de supervision n’est mis en place pour contrôler cette machine, notamment pendant les weekend. De plus, il arrive que parfois, la matière ne s’empile pas comme on le souhaiterait et donc non seulement la pièce à imprimer n’est pas aboutie, mais en plus, de la matière est consommée « pour rien », entraînant des coûts supplémentaires.  Vous trouverez donc, ci-dessous, comment nous avons procéder pour la réalisation d’un tel projet.

Analyse fonctionnelle

Cahier des charges (CdCF) :

Intégrer un système de commande à distance (supervision) pour une des imprimante 3D du département GMP comprenant :

• La possibilité de voir en temps réel (+ ou – 5 min) l’état de l’impression en cours, et pour y arriver, devoir d’abord allumer la lumière en actionnant un bras mécanique qui ira appuyer sur le bouton concerné de la machine
• Pouvoir arrêter le système en cas de mauvaise impression pour limiter les dégâts

La partie mécanique (support de la caméra + bras mécanique) sera réalisée par les étudiants du département GMP

La partie électrique (supervision, câblages, intégration de l’informatique embarquée) sera réalisée par les étudiants du département GEII

Expression du besoin :

Diagramme des interactions :

Diagramme FAST :

Estimation coût projet :

L’IutLab (Le FabLab de l’Iut) nous a fourni tout le matériel.

Réalisation côté GEII

I.  Initialisation du Raspberry Pi

Nous avons reçu un Raspberry Pi 3 sans système d’exploitation, il a donc fallu formater une carte microSD et en télécharger un dessus. Nous avons fait le choix de prendre Raspbian, mais il en existe une variété comme Ubuntu, Fedora, etc.

Voici à quoi ressemble l’environnement de travail :

Il faut brancher un clavier, une souris, un écran sur le Raspberry, il est donc plus pratique pour nous de travailler depuis l’ordinateur, ce qui nécessite la prise à distance de celui-ci.

Pour avoir accès à l’invite de commande du Raspberry depuis l’ordinateur, nous avons utilisé le logiciel Putty basé sur du SSH qui sécurise la connexion à distance.

Il suffit de rentrer l’adresse IP du Raspberry dans le champ « Host Name ». Celle-ci peut être connue via la commande « ifconfig » sur le Raspberry ou « ipconfig/all » sur l’ordinateur.

Il faut ensuite rentrer des identifiants paramétrables depuis le Raspberry. De base, id : pi et pwd : raspberry

Cette technique permet uniquement d’avoir accès à l’invite de commande depuis l’ordinateur. Pour avoir son interface graphique, nous avons utilisé le logiciel « VNC Viewer ».

Il serait aussi avantageux de pouvoir envoyer des fichiers depuis l’ordinateur vers le Raspberry sans passer à chaque fois par la carte microSD. L’utilisation du logiciel « Filezilla » utilisant le protocole SFTP nous a été d’une grande utilité.

Sur la partie gauche, vous trouvez les fichiers présents sur votre machine et à droite sur celle à qui vous voulez l’envoyer.  Comme toutes les connexions à distance réalisées ci-dessus, il vous faut l’adresse IP du Raspberry.

Comme nous allons réalisé notre programme en python, il faut installer l’IDE. La commande Linux permettant de faire cette action est « wget ». Il a fallu donc nous familiariser avec les commandes principales sur Linux.

Comme pour tout autre langage de programmation, l’installation de librairies est indispensable. Voici la liste des nos librairies :

• « paho.mqtt.client » pour la communication en MQTT
• « RPi.GPIO » pour piloter les GPIO (pin du Rpi) comme sur un Arduino par exemple
• « time » pour les tempos

II.  Compréhension du python et du protocole MQTT 

Nous avons fait le choix de programmer en python sur le Raspberry. Ce langage de programmation nous offre des fonctionnalités comme :

• créer des interfaces graphiques

• faire circuler des informations au travers d’un réseau

• dialoguer d’une façon avancée avec votre système d’exploitation

C’est grâce à lui que l’on va interpréter les messages reçus en MQTT. Mais au fait, qu’est ce que le MQTT ?

MQTT (MQ Telemetry Transport) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP. Comme nous le voyons sur l’image, un capteur va, par exemple, envoyer ses données sur un topic spécifique via le broker MQTT et les appareils abonnés à ce topic pourront recevoir ces données.

Avantages : Ceci prend en compte une de nos principales contraintes : l’ouverture d’un port à l’UHA n’est pas autorisé pour des raisons de sécurité. Si nous faisons un serveur sur le Raspberry, nous pouvons que consulter la page depuis le réseau local, ce qui n’est pas pratique et ne répond pas au cahier des charges. Or, en passant par le broker : « test.mosquitto.org » les messagent transiteront par celui-ci ce qui résout le problème.

Voir doc. annexes pour le code en python stocké sur le Raspberry

III. Câblage électrique Raspberry

Schéma de câblage du servomoteur.

Le Raspberry ne fournissant pas assez de courant sur ses GPIO, il a fallu rajouter une alimentation externe à pile pour que le servomoteur reçoive assez de courant, sinon des vibrations peuvent apparaître. Attention à bien brancher la masse du Raspberry avec la borne négative des piles, et celle du servomoteur ensemble pour avoir le même référentiel.

Actuellement, nous branchons les différents composants électroniques via la « breadboard » afin d’effectuer les tests, et par la suite, les composants seront soudés les uns aux autres et placés dans une boîte isolée du milieu extérieur.

IV.  Mise en place de la supervision

Nous avons dû créer un serveur Node-Red sur IBM Cloud et un sur le Raspberry Pi pour éviter l’ouverture du port (1880) du Raspberry qui mettrait le réseau de l’IUT en danger, car même sécurisé, la présence de failles peut être rapidement décelée par autrui.

Comment cela fonctionne et communique ensemble :

Sur IBM Cloud (génération de requêtes + affichage résultat de celle-ci si besoin) : Mise en forme de l’interface graphique visible par l’utilisateur qui va générer des « requêtes ». Ces dernières seront envoyées par le protocole décrit plus haut (MQTT) via un Broker. Il suffit donc d’avoir Internet pour envoyer des données.

Sur Raspberry (commande associée à la requête) : Réception des « requêtes » effectuées sur l’interface qui génère une action sur le Raspberry (ex : prendre une photo, mettre une sortie à 1 ou 0, etc…). Si besoin, nous renvoyons le résultat (toujours par MQTT) sur le Cloud (ex : l’image prise par le Pi qui a été convertie en base64).

Node-Red permet de créer une interface graphique très facilement par l’intermédiaire de blocs appelés « node » mappés entre eux (voir ci-dessous). Il s’installe sur Raspberry mais comme nous ne voulons pas faire de serveur dessus il faut passer par un Cloud. Le seul que nous avons trouvé permettant une utilisation gratuite est IBM Bluemix.

Notre « Flow » tournant sur le Cloud (voir doc. annexes pour le programme) :

Notre « Flow » tournant sur le Raspberry (voir doc. annexes pour le programme) :

Si les Nodes MQTT restent à l’état « connecting », changez le broker utilisé. Vous pourrez trouver sur Internet une liste de broker en ligne, en voici une liste : 

• iot.eclipse.org
• broker.hivemq.com
• test.mosquitto.org
• test.mosca.io
• broker.mqttdashboard.com

L’interface actuelle pour notre supervision :

Note : L’information de la température de la CPU peut paraître inutile mais grâce à elle, nous savons si Node-RED Cloud et Node-RED sur le Raspberry communiquent bien entre eux, ce qui permet de gagner du temps pendant la maintenance en cas de problème.

Boitier de protection réalisé à l’aide d’une imprimante 3D :

Afin de créer une boîte sur mesure qui assurera la protection de l’électronique intégrée, nous avons procédé par CAO et réalisé le boîtier grâce à une imprimante 3D:

Réalisation côté GMP

Conception des supports de fixation :

I. Support de caméra

Ci-dessous, l’ancienne puis la nouvelle conception du support

Dans l’ancienne solution, les 2 pattes venant se glisser derrière la vitre risquant d’être trop fragile, nous les avons donc remplacés pas une seule.

Nous avons décidé de réaliser le support de la caméra en impression 3D. En effet les contraintes sur ce support étant faibles, le PLA est suffisamment résistant pour supporter le poids de la caméra.

La caméra est fixée avec du scotch double face sur la paroi.

II. Réalisation du support amovible du doigt motorisé

Vue d’ensemble du système de fixation

Graphe des liaisons :

III. Réalisation des pièces à l’atelier :

• Sur machine CN à découpe jet d’eau :

Support moteur                                                                                                                                               Support axe

La programmation de la machine jet d’eau se fait directement depuis le poste machine. Il faut transférer le fichier .dxf contenant le profil que devra suivre la buse de la machine pour le transformer ensuite en trajectoire.

• Sur machine traditionnelle :

Débitage du brut pour l’axe                              Usinage en pince de l’axe                          Fraisage de la rainure de passage du moteur

Les trajectoire d’entrée de la découpe jet d’eau ont dû être ébavurés ainsi que toutes les arrêtes vives.

 Modification du cahier des charges :

Changement du cahier des charges durant le projet. Ce changement est de pouvoir appuyer sur les boutons de l’imprimante manuellement sans avoir à faire pivoter le bras pour accéder aux boutons.

De ce fait nous avons usiner deux boutons venant se fixer derrière les vis de pression permettant d’appuyer sur les commandes de l’imprimante par l’intermédiaire des vis de pression.

Nous avons usiné les boutons en laiton pour plus d’esthétique, avec un léger arrondi pour améliorer l’ergonomie.

Montage du système

Conclusion

Situation actuelle :

Supervision permettant de :

• Piloter le système conçu par les GMP avec le servomoteur
• Envoyer une image sur un mail à sélectionner
• Envoyer une image sur l’interface directement
• Suivre les actions effectuées grâce à un journal d’évènement

Nous avons également intégré une sécurité pour notre microcontrôleur :

• Mise en marche d’un ventilateur si la température de la CPU dépasse 50°
• Arrêt du Raspberry si la température de la CPU dépasse 80°

Connaissances générales acquises :

• Gestion de projet : Savoir respecter un cahier des charges, dans les délais et coûts souhaités
• Humain : Dialoguer avec un autre corps de métier et se mettre d’accord sur les façons de réaliser un système
• Programmation : Capacité d’adaptation notamment en python qui est un langage de programmation très convoité en industrie
• Technique : Capacité à surmonter et résoudre des problèmes techniques, pouvant retarder le projet, et donc être rapide et efficace dans la recherche d’information

Le fait d’avoir pu répondre au cahier des charges nous a permis de voir notre projet fini, ce qui est d’autant plus motivant pour nous :

Documents annexes

Vous pourrez trouver ci-dessous des procédures utiles concernant le projet (méthodes à appliquer, erreurs à éviter…) ainsi que nos programmes :

Procédures pour Node-RED :

Création compte IBM

Duplication de notre Flow

Redémarrer le serveur IBM (tous les 10 jours en version gratuite)

Sélection du TOPIC MQTT via menu déroulant

Programmes python et Node-RED :

Programme python pour le servomoteur

Flow sur le Cloud

Flow sur le Raspberry

Flow pour la sélection via menu déroulant

Equipe ayant travaillé sur le projet :

• Julien Gruaux – GMP
• Axel Sitterle – GMP
• Nathan Zindy – GMP
• Margot Daval – GEII
• Nathan Mourant – GEII

Sommaire

I/ Présentation du projet
II/ Analyse fonctionnelle
III/ Réalisation côté GMP
IV/ Réalisation côté GEII
V/ Conclusion

I/ Présentation du projet

Depuis plusieurs années, l’automatique devient de plus en plus banales, aussi bien dans le milieu industriel que dans le quotidien, à travers la domotique. En constatant ce fait et voulant en profiter, des étudiants de deuxième année de l’an dernier avait eu pour projet de réaliser un bar à cocktail automatisé.
En se basant sur ce projet, les départements GMP et GEII de l’IUT de Mulhouse nous ont demandé de créer une nouvelle machine à cocktail automatisée pour pouvoir la présenter en démonstration lors des journées portes ouvertes de l’IUT. Au cours de cet article, nous allons donc vous expliquer notre travail pour réaliser ce projet avec une équipe composée d’apprentis GMP et d’apprentis GEII.

II/ Analyse fonctionnelle

A- Diagramme des besoins et des interacteurs

Afin de pouvoir établir un cahier des charges répondant à tous les besoins de la machine, nous avons commencer par faire un diagramme des besoins ainsi qu’un diagramme des interacteurs.
Les besoins de notre projet étant les mêmes que pour celui de l’an dernier, nous avons repris celui du projet de l’an dernier :

Il en est de même pour le diagramme des interacteurs :

FP : Fonction Principale
FC: Fonction Contrainte

B- Cahier des charges

Grâce aux diagramme ci dessus et en discutant entre nous, nous avons alors pu établir le cahier des charges suivant :

Flexibilité :
F0 : Flexibilité nulle – niveau impératif
F1 : Flexibilité faible – niveau peu négociable
F2 : Flexibilité bonne – niveau négociable
F3 : Flexibilité forte – niveau très négociable

C- Diagramme FAST

A partir du cahier des charges que nous avons établi grâce aux deux diagrammes précédents et nos discussions, nous pouvons maintenant établir un diagramme FAST pour notre projet :

D- Répartition du travail

Partie génie mécanique :

• Choix des solutions techniques pour répondre aux attentes : Axel, Nathan Z. et Julien
• Modélisation sur Créo : Nathan Z.
• Choix des matériaux de la structure : Axel et Julien
• Conception et mise en plan des pièces à usiner : Axel, Nathan Z. et Julien
• Usinage : Axel, Nathan Z. et Julien
• Assemblage : Axel, Nathan Z. et Julien

Partie génie électrique :

Les deux apprentis GEII ayant chacun déjà eu des diplômes dans des domaines différents avant de reprendre leurs études en GEII, la répartition du travail entre eux s’est fait selon leurs parcours. En effet, nous avons cherché à tirer profits de cela pour identifier les points forts de chacun au moment de répartir le travail pour nous montrer plus efficace. Ainsi, Nathan M. ayant déjà des compétences dans le domaine mécanique, choisir les moteurs pour le projet ou s’occuper du calcul de dimensionnement électrique sont plus simples à faire pour lui. Sur le même principe, la programmation du Raspberry et de l’IHM sont plus simple pour Margot qui a déjà des compétences en programmation. On obtient alors la répartition du travail suivante :

• Choix du moteur et des capteurs : Nathan M.
• Dimensionnement électrique : Nathan M.
• Installation électrique et câblage : Nathan M. et Margot
• Programmation Raspberry : Margot
• Réalisation et programmation IHM : Margot
• Rédaction du dossier : Margot

Cependant, Nathan M. ayant démissionné de la formation en début du deuxième semestre après plusieurs semaines d’absence, la répartition du travail a été complètement bouleversée pour faire face au départ de Nathan M. et au retard dû à son absence.
Cependant, pour ne pas abandonner le projet ou le laisser inachevé, il a été convenu qu’un binôme de première année en GEII continuerait à travailler sur le sujet durant leur temps de projet.

III/ Réalisation côté GMP

Ce projet est issue de la récupération d’ancien objets inutilisés sauf pour les moteurs, les pompes péristaltiques et les doseurs-bouteilles. Les pièces spécifiques comme les pignons des moteurs ou encore le support pour le verre, on été dessinées et imprimées en 3D par nos soins.

A- Plateau mobile

1.) Le plateau et son moteur

Tout est partie de la récupération d’une imprimante ayant un plateau motorisé. Ce plateau guidé à l’aide de deux glissières est le parfait élément pour commencer notre projet de bar automatisé,
alias AUTOM-A-TISE.

Le but étant d’avoir un plateau où l’on puisse déposer le verre. Ce plateau va ensuite se translater pour positionner le verre en dessous des différentes stations, à savoir deux stations avec doseur-bouteille et une station avec l’arrivée de liquide venant des pompes péristaltiques.

Nous avons dessinée un schéma cinématique pour définir les différents liaisons à mettre en place pour l’installation des différents éléments.

Schéma cinématique :

Il a fallut placer le moteur sur le bâti avec un système de courroie et de tendeur pour transmettre la rotation du moteur au plateau.

Liaison du moteur au plateau (à l’aide de deux vis + une rondelle et équerre de fixation) :

Conception du pignon du moteur sur Creo :

2.) Le support pour le verre

Le support a d’abord été dessiné sur Creo, il est en trois pièces :

• un socle central intégrant l’emplacement pour un capteur de présence verre.
• deux pattes extérieurs qui vont venir appuyer le verre de part et d’autre pour le maintenir en position à l’aide de ressorts.

Il a été imprimé grâce à l’imprimante 3D puis les ressorts on été formé à la main.

Le support-verre durant sa conception :

Réalisation finale :

B- Le poussoir pour doseur-bouteille

Nous sommes partis d’une base trouvée dans le local des pièces usagées de l’IUT à côté de l’IUT LAB. C’est un rail, dont la position était probablement codée, avec un coulisseau qui possédait un système pneumatique.

Nous avons décidé de placer une crémaillère à l’intérieur de ce rail pour pouvoir utiliser le coulisseau comme poussoir. Le moteur sera fixé sur le rail fixe et la crémaillère sur le coulisseau qui sera mobile.

Nous avons d’abord conçu le pignon du moteur sur Creo, puis la crémaillère en récupérant l’empreinte du pignon. Nous avons envoyé ces pièces pour l’impression 3D, l’impression de la crémaillère s’est fait sur le flanc pour obtenir une fibre se dirigeant dans le sens des efforts des dents du pignon.

Assemblage final du système de crémaillère à l’intérieur d’un profilé aluminium :

IV/ Réalisation côté GEII

A- Choix des moteurs, capteurs et dimensionnement électrique

L’un des objectifs que nous nous étions fixé au moment du dimensionnement électrique était de limiter au maximum le nombre de prise nécessaire au fonctionnement du bar à cocktails automatisé par soucis de praticité. Le bloc secteur d’alimentation de la Raspberry Pi étant déjà fourni, nous avons alors penser à utiliser une multiprise classique à l’intérieur de la machine afin de pouvoir y brancher tous les différents éléments nécessaires tout en assurant la nécessité d’un seul branchement extérieur au bar à cocktails pour son fonctionnement.

Pour limiter les dépenses mais aussi le câblage et l’alimentation nécessaire, nous avons également opté pour des moteurs pas à pas. Comme nous utilisons une carte HAT Adafruit pour Rasberry Pi permettant de piloter des moteurs continus et pas à pas, nous avons rapidement décidé de prendre des moteurs de la même marque. Les moteurs devant être capable d’aller dans les deux sens, et la carte de pilotage pouvant être alimentée jusqu’à 12V, nous avons alors opté pour des moteurs pas à pas de 12V et de couple 20N*cm. Il compte 200 pas par révolution et chaque angle de pas est de 1,8 degré. La première bobine est reliée aux câbles rouge et jaune, et la seconde bobine aux câbles vert et gris.

On compte deux moteurs identiques, l’un qui permettra de faire avancer le plateau et le deuxième qui assurera la montée et la descente du mécanisme activant les doseurs des bouteilles. Ils seront tous les deux alimentés par la carte HAT, elle-même alimentée en 12V. Pour raccorder la carte HAT à celle de la Raspberry, il suffit de placer les connecteurs 2×20 femelles de la carte de pilotage des moteurs sur ceux 2×20 mâles de la carte Raspberry Pi, réalisant ainsi un nouvel étage. Nous vous proposons ci-dessous le schéma de câblage des moteurs et de l’alimentation sur la carte HAT de pilotage.

Attention cependant, la carte HAT prenant tous les connecteurs 2×20 de la carte Raspberry Pi, l’alimentation de l’écran de cette dernière doit également se faire via la carte HAT d’Adafruit une fois cette dernière connectée. L’écran étant alimenté en 5V, comme la Raspberry Pi, il faut alors utiliser un connecteur 5V et un autre GND disponibles sur la carte HAT.

Concernant les capteurs, l’utilisation de moteurs pas à pas nous permet de nous passer de capteurs de position. L’idée d’un capteur à contact, pour s’assurer de la présence d’un verre dans la machine, a fini par être abandonnée par manque de temps. Un emplacement pour un capteur à contact à pourtant été prévu dans la structure du socle pour le verre, ce qui permet un éventuel ajout par la suite.

Au niveau des alimentations nécessaires, il nous faut donc une alimentation de 5V pour la Raspberry Pi et son écran tactile, et une alimentation de 12V pour la carte HAT de pilotage des moteurs Adafruit, qui s’occupera d’alimenter les deux moteurs pas à pas. Le bloc secteur pour l’alimentation de la Raspberry Pi est déjà fournie, il ne nous reste donc plus qu’à utiliser un autre bloc secteur de 12V pour l’alimentation de la carte HAT.

B- Programmation de la Raspberry

Il a été choisi dès le début du projet de piloter le bar à cocktails automatisé grâce à une Raspberry Pi. C’est donc sur cette dernière que nous devions programmer. Bien que le Python reste son langage de développement « natif », il reste possible de développer un programme dans plusieurs autres langages. Cependant, avant de commencer le développement d’un programme ou même de choisir son langage de développement, nous avons d’abord travailler sur l’algorithme du programme afin de connaître les éventuelles contraintes ou libertés de choix possibles. Par exemple, les deux moteurs n’étant jamais actif en même temps, un système multitâches n’était pas obligatoire pour la programmation.

Une programmation du bar à cocktails grâce à l’outil Node Red a été envisagé durant un moment. En effet, l’utilisation de Node Red permettait de piloter les pins GPIO de la Raspberry Pi pour les moteurs, mais aussi de rendre le bar à cocktails connecté grâce à l’interface de Node Red. De plus, la gestion de l’IHM devenait bien plus simple à faire, se créant grâce au programme. Cependant, pour rendre le bar à cocktails connecté, une connexion internet était nécessaire, ce qui peut ne pas être forcément possible partout. De plus, la sauvegarde d’un projet nécessite un import puis un export de flux, ce qui ne permet pas de rendre le bar à cocktails prêt à l’utilisation sans la recréation d’un projet et l’export du programme développé. Pour finir, Node Red utilise exclusivement du langage javascript, langage avec lequel nous n’étions pas à l’aise. Et le manque de temps nous empêchait de faire une remise à niveau suffisante pour le développement du projet.

Le choix d’une carte HAT d’Adafruit, permettant le pilotage de moteurs pas à pas ou continus (jusqu’à deux moteurs pas à pas ou quatre moteurs continus), nous a permis d’opter pour une autre solution de développement. En effet, la carte HAT était livrée avec une librairie Python déjà existante permettant le pilotage des différents moteurs pouvant être connectés à la carte, ainsi que des petits programmes de tests de fonctionnement pour chaque type de moteurs. Le langage Python ressemblant énormément au langage C, vu durant la première année de GEII, son utilisation était alors beaucoup plus intuitive et aisée que celle du javascript. De plus, cela étant le langage « natif » de la Raspberry, nous étions sûr de ne pas avoir de problèmes d’interprétation du script. Malheureusement, l’utilisation d’un script en Python nous faisait renoncer au côté connecté du bar à cocktails et nous obligeait à trouver une autre solution pour l’IHM.
Pourtant, par manque de temps pour le développement du programme, le script en Python fut la solution retenue pour le projet. Son développement a donc être pu fait assez rapidement, bien qu’il manquait le nombre de pas nécessaire aux moteurs pour les déplacements demandés. Par manque de temps également, le pilotage de la pompe péristaltique n’a pas pu être fait et ajouté au programme.

Ainsi, voici la partie principale du programme développé pour le projet :

Comme on peut le voir sur la capture d’écran, le programme a été entièrement commenté afin de faciliter le travail d’autres personnes pouvant avoir à modifier le code si le projet est repris par la suite.

Malheureusement, suite à un problème technique avec les connecteurs 2×20 de la carte HAT, il nous a été impossible de réaliser les tests concernant le nombre de pas nécessaires aux moteurs pour les divers déplacements. Pour la même raison, et n’ayant pas toutes les données nécessaires, il n’a pas été possible de tester le programme du bar à cocktail dans son intégralité.

C- Ce qu’il reste à faire

Dû fait de la démission de Nathan M. du DUT GEII et du retard déjà accumulé avant son départ, le projet n’a pas pu être terminé du côté électrique malgré notre envie d’aller jusqu’au bout. Cependant, pour palier à ce problème, qui semblait déjà inévitable au moment de la démission de Nathan M., il a rapidement été convenu que le projet serait repris par un binôme de première année en DUT GEII pour faire en sorte de le finir.

La première mission qui était prévue de leur confier était le câblage des différents éléments de la machine. C’est d’ailleurs également pour cette raison que nous avons tenu a essayé de le limiter au maximum, afin de faire en sorte qu’ils perdent le moins de temps possible sur cette tâche.
En plus du câblage, et suite au problème technique survenu lors de la phase de test de la carte HAT Adafruit, ils devront également s’occuper de mettre en place la nouvelle carte de pilotage en place et tester le nombre de pas nécessaires aux moteurs pour les divers mouvements. Une fois cela fait, ils pourront alors rentrer les valeurs trouvées dans le programme déjà prêt pour le pilotage du bar à cocktails et tester ce dernier.
Pour finir, ils pourront également modifier ce programme afin d’y intégrer la gestion de la pompe péristaltique prévue dans la machine.

Enfin, concernant les améliorations possibles s’ils ont le temps ou si le projet est également repris alors leur travail, il peut être intéressant d’ajouter un capteur à contacts pour s’assurer de la présence d’un verre sur le socle, comme nous pensions le faire au départ.
Il peut également être possible d’adapter le code pour une utilisation de Node Red afin de pouvoir rendre le bar à cocktail connecté et avoir une IHM convenable. Le développement d’une IHM semble être aussi une bonne piste d’amélioration du projet actuel.

IV/ Conclusion

Malgré les différentes difficultés rencontrées, nous avons pu aboutir à une réalisation mécanique fonctionnelle et avancé au maximum la réalisation électrique et informatique. Cette dernière sera transmise à un binôme de première année de GEII afin de la finaliser. Pour leur permettre une plus grande facilité de câblage, nous avons donc choisi de ne pas figer les éléments électroniques du projet sur le système.

Le projet reste malgré tout améliorable, et des perspectives d’évolutions peuvent être envisagées. Il nous a permis de travailler en équipe tout en partageant nos idées et nos connaissances.

Notre projet s’inscrit dans une démarche économique, où la récupération de matériaux et autres éléments récupérés au stock des pièces usagés de l’IUT Lab a été essentielle. Les implantations des différents éléments sur le système de base (imprimante) a développé notre capacité d’adaptation.

L’équipe ayant participé au projet :

• LITZLER Nathan(GEII)
• HAEGELIN Francois (GEII)
• BAUMANN Jeffrey (GMP)
• SCHIEBER Louis (GMP)

Sommaire

1.  Présentation du projet
2.  Analyse fonctionnelle
3.  Réalisation électrique
4.  Réalisation mécanique
5. Conclusion

1. Présentation du projet

Créée en 1986, la norme DMX est toujours d’actualité chez les professionnels de l’éclairage et de l’événementiel. La raison ? Elle est économe en câbles : un cordon XLR DMX peut gérer 512 canaux au total. Sachant qu’un projecteur moyen peut être piloté par 1 à 15 canaux environ, une seule ligne DMX permet de couvrir la plupart des besoins en éclairage.
De plus, le DMX est un langage standardisé, qui fonctionne avec n’importe quel matériel d’éclairage au sens large, quelle que soit la marque : projecteur PAR, blocs de leds, strombes, machines à effet, lyres, etc.…
A chaque canal est affectée une valeur allant de 0 à 255, permettant de contrôler chaque paramètre avec précision. Depuis le logiciel ou la console, vous pourrez programmer des animations, les sauvegarder, les rappeler, les modifier…

Ayant un membre du groupe travaillant dans le milieu de l’événementiel et s’intéressant aux nouvelles technologies scéniques nous avons eu la curiosité de décrypter le DMX et ses trames. C’est pour cette raison qu’ayant l’opportunité de réaliser un projet entre GMP (Génie mécanique et productique) et GEII (Génie électrique et informatique industrielle) nous avons décidé de nous lancer dans la conception d’une lyre DMX afin de d’allier nos spécialités. Cette lyre low cost est donc la reproduction d’une lyre commercialisée créée de toutes pièces par nos soins et à moindres coûts. Vous découvrirez donc, ci-dessous, les étapes ainsi que la répartition de notre projet.

2.Analyse fonctionnelle

Cahier des charges

Réalisation d’une lyre commandée par un arduino comprenant :

• L’envoi de trames DMX via le logiciel node managment utility
• L’acquisition de trames DMX via un réseau Ethernet grâce à un boitier ENTTEC
• La commande de 2 moteurs pas à pas
• La commande de leds de différentes couleurs

Bête à corne :

FAST :

Estimation coût du projet :

Les prix d’une lyre DMX variant de 160€  à 1500€ nous n’avons finalement pas économisé énormément au vu des heures passées sur le projet.

Répartition des tâches :

RÉALISATION ELECTRIQUE

1. Prise en main du DMX

Afin de bien commencer le projet nous avons du comprendre de quelle manière les trames DMX sont envoyés et découpés afin de les réceptionner de la meilleure façon.

Le protocole DMX512 est donc un protocole qui permet de contrôler 512 canaux en affectant à chacun d’entre eux une valeur entre 0 et 255.

La transmission se fait de façon sérialisée, ainsi tous les appareils esclaves recevront les 512 valeurs en même temps. Dans notre cas nous avons uniquement la lyre qui reçoit les trames donc les problèmes des 32 appareils maximum sur une même ligne DMX ne nous dérange pas.

Le principe de fonctionnement est relativement complexe cependant nous pouvons en retenir que la transmission se fait par un cable d’une paire blindée raccordé à des connecteur XLR de type 5 broches (seuls les 3 premières sont utilisés). La trame est envoyé 44 fois par seconde soit une fréquence de rafraîchissement de 44Hz.

La commande du protocole DMX se fait généralement via un pupitre plus ou moins complexes selon la taille de la scène et son utilités.  Pour nos essais nous utiliserons le logiciel Node Management Utility, qui est plus facile à prendre en main, afin d’envoyer les différentes valeurs sur les différents canaux.

Pour finir nous avons appris qu’une norme permettait d’éviter le câblage fastidieux. La norme nommée Art-Net est donc celle que nous utiliserons tout au long de notre projet, elle intègre les trames DMX dans des paquets Ethernet et simplifie le câblage.

2. Choix du matériel électrique

Le choix du matériel fut la partie la plus longue du projet puisque nous surmontions les problèmes de matériel au fur et à mesure que nous les rencontrions. Nous avons donc commencer la programmation avec un arduino UNO avant de nous rendre compte que celui-ci ne fonctionnait pas du fait qu’il n’a qu’un seul port série. Nous avons donc, par la suite, du faire évoluer notre Arduino UNO en Arduino MEGA.

Le membre de notre groupe travaillant dans l’événementiel ayant un spot lumineux a sa disposition nous n’avons donc pas eu besoin de choisir les leds, nous les avons simplement récupérées.

3. Connexion à l’arduino

Nous avons ensuite dû nous connecter à l’arduino avec le DMX afin d’acquérir les trames. Nous passerons donc par un boitier ENTTEC permettant la traduction des trames ART-Net en DMX512.

Une fois la trame acquise nous avons du comprendre comment la traduire afin de faire fonctionner les moteurs et les leds grâce aux instructions envoyées.

Nous nous sommes rendu compte qu’il fallait rajouter un module pour recevoir les trames DMX sur l’arduino. Ce schéma utilise donc un module qui comporte un MAX485 qui permet l’adaptation entre la carte arduino (0V-5V) et le protocole RS485. Le module MAX485 peut fonctionner en émetteur et récepteur, ici nous ne l’utiliserons que en tant que récepteur.

Attribution des bornes

Une fois les trames acquises grâce au module nous avons créer un programme comprenant une librairies DMXSerial.h permettant de traduire ces signaux en sortie PWM afin de piloter le moteur et les leds.

Signal de sortie PWM :

Ainsi en fonction de la valeur envoyé sur les différents canaux les équipements esclaves fonctionneront comme décrit dans l’image ci dessus (la valeur 255 = 100%).

3. Programmation

Pour commencer nous avons programmer les leds et le moteur séparément avant des les intégrer dans le même programme.

Choix et câblage des leds:

Nous avons démonté le spot lumineux existant afin d’en récupérer les leds et définir quels seraient ses besoins énergétiques.

Les leds sont des PAR6_RGB 3 en 1 (Bleu rouge et vert) consommant 1W.

Afin de contrôler les led (alimentés en 12V) avec l’Arduino , une solution est d’utiliser des transistors Mosfets avec une résistance d’un kilo ohm comme ci-dessous sans oublier de mettre toutes les masses communes.

Câblage des leds RGB

      Câblage des leds RGB

Programmation leds:

Choix et câblage moteur

Afin de limiter l’alimentation nécessaire, nous avons choisis des moteurs pas à pas. Utilisant un arduino pour contrôler ce moteur nous nous sommes renseignés auprès de l’IUTLAB sur la disponibilité des moteurs pas à pas. Les moteurs devant aller dans les deux sens et ne pouvant dépasser une alimentation de 12v, nous avons choisis des moteurs pas à pas de 12V.

Afin de contrôler ces moteurs grâce à l’arduino nous avons du rajouter un shield de puissance.

Enable : Allume la led du pin 13 de l’arduino pour signifier que la carte de puissance est en route

Step : Gère les pas du moteur

Direction : Gère le sens de rotation du moteur

VMOteur : Alimentation moteur

GND/Masse : Connexion à la masse

2B, 2A, 1A, 1B : Sorties du moteur

VDD : Alimentation 12v

Câblage finale avant intégration dans boitier

Programmation finale (moteur + leds):

Problèmes rencontrés:

• Réception de la trame DMX et traduction du signal contrôler le moteur et allumer les leds

    >  Librairie DMXSerial pour acquérir les trames DMX et librairie STEPPER pour controler le moteur pas à pas

• Faire tourner deux fonctions en simultanées sur l’arduino

     > Suppression de la fonction DMXSerial.dataUpdated()/DMXSerial.resetUpdated() qui permet l’attendre d’une mise à jour d’une trame

     > Utilisation de la fonction micros()

Améliorations possible:

• Intégration d’un embout XLR mâle femelle pour améliorer l’esthétique de la connexion entre le shield DMX et le boitier Art-Net.
• Création d’un programme gérant une interface DMX afin d’obtenir un show automatisé.
• Mise en place d’un deuxième moteur avec son shield de puissance pour gérer la rotation horizontale des leds.
• Intégration d’un circuit imprimé

RÉALISATION MECANIQUE

1. Choix de la motorisation et des transmissions

Après avoir défini le cahier des charges, nous avons retenu la solution des moteurs pas-à-pas. Ceux-ci ont la spécificité de pouvoir s’arrêter précisément. Cela nous permet donc de bien gérer la course de la lyre.

Notre lyre est composée de deux moteurs. L’un pouvant faire tourner le plateau sur l’axe verticale et l’autre, placé sur la plateau qui eut faire tourner le spot sur un axe horizontal. Ils sont fixé à l’aide de brides.

La conception de notre lyre c’est faites en deux parties. Nous avons tout d’abord commencé par concevoir le boitier principal. Il accueille tous les composants électroniques ainsi le premier moteur qui fait tourner le plateau selon l’axe vertical.

Notre première idée était une boite thermo pliée de 5 faces avec en plus un couvercle. Mais nous n’avons pas retenu cette solution pour des raisons d’étanchéité. Il aurait aussi été compliqué de fixer les composants sur le fond dû à une épaisseur de paroi trop faible. Nous aurions aussi rencontré des difficultés de montage dû au manque de modularité du boitier.

Notre deuxième solution était donc de faire chaque face indépendante l’une de l’autre. Cela nous a permis d’avoir un fond plus épais que les parois. De ce fait, nous avons opté pour une épaisseur de 10mm ce qui permet donc de percer et tarauder le fond pour pouvoir y fixer des composants. Réalisé par impression 3D, le fond du boitier a une forme carrée de 200 par 200mm comprenant différentes extrusions. Une première série d’extrusions sur les côtés qui permettent la mise en position des parois lors de l’assemblage. Puis 8 pattes de fixations intégrants des écrous montés serrés dans des logements hexagonales prévus à cet effet. Les parois latérales sont donc maintenues en position par des ensembles vis-écrous.

Dans l’hypothèse d’une production en série cette pièce aurait été réalisée en moulage par injection de matière plastique type ABS.

Pour les parois latérales nous avons décidé de faire les 4 parois identiques en épaisseur 3mm en PMMA. Elles sont munies de 4 trous de passage de vis destinés à leur maintien en position comme évoqué précédemment. Le fait de faire 4 parois identiques permet de ne pas chercher quelle paroi doit être montée à quel endroit. Un ordre de montage de ces parois n’est donc pas nécessaire. Chaque paroi a en revanche un sens de montage car elles ne sont pas symétriques, en effet pour obtenir une bonne finition au niveau des angles nous les avons fait se chevaucher successivement l’une sur l’autre.

Le couvercle quant à lui est muni d’une « corniche »  ce qui permet sa mise en position plus facilement. Il sera maintenu en position avec les parois de la même manière que le fond grâce à des pattes de fixation avec écrous intégrés. Cette partie du boitier aura également été effectué par impression 3D.

Sur ce couvercle est fixé un palier lisse réalisé en aluminium à l’aide d’un tour à commandes numériques. Celui-ci a pour but d’assurer la liaison pivot entre le plateau et le haut du boitier. Nous avons opté pour une liaison pivot par palier lisse car la liaison pivot devait également assurer le passage de câble du boitier vers le spot et le second moteur.

Donc c’est cet assemblage qui constitue cette première partie de la lyre.

Vient ensuite la partie du haut, le plateau tournant. Il a été réalisé en plusieurs parties. La partie principale en PMMA est thermo pliée en forme de U. C’est sur cette pièce que l’on viendra fixer les autres composants permettant la rotation du spot selon l’axe horizontal.

Pour guider le plateau en rotation avec le boitier, nous avons conçu seconde une pièce que l’on viendra fixer sur la partie principale du plateau. Cette pièce est un second palier lisse, cette fois-ci réalisé en impression 3D. Nous avons opté pour cette réalisation car nous y avons directement intégré une roue dentée sur le bas qui sera entraînée par le moteur dans le boitier. C’est donc plus exactement à travers cette pièce que passeront les câbles qui vont du boitier jusqu’au spot et au moteur.

Sur cette pièce en U viendra aussi se visser une bride sur laquelle sera fixée le moteur qui permettra de faire tourner le spot suivant l’axe horizontal.

Pour le guidage du spot, nous avons conçu deux différents systèmes de chaque côté du spot. D’un côté nous avons fait une pièce qui sera vissée sur la pièce principale du plateau. Le spot sera libre en rotation autour de cette pièce. Celle-ci est  creuse suivant son axe mais il y a aussi un trou sur le côté ce qui permet un passage des câbles qui sortent du second palier lisse évoqué plus haut jusque dans le spot.

De l’autre côté nous avons une pièce semblable à la précédente mais avec un tube plus petit qui viendra accueillir un axe monté serrer à l’aide d’une vis de pression.

Cet axe permettra de guider une roue dentée qui sera fixée sur le spot, ce qui permet la mise en rotation du spot sur l’autre côté

Le spot tournera donc autour de l’axe diamètre 5mm d’un côté et autour de la pièce de passage de câble qui est diamètre 16mm.

Améliorations possibles :

• Rigidifier la pièce principale du plateau
• Réduction des vibrations faites par le moteur

SHOW FINAL

CONCLUSION

Tout au long de ce projet nous avons pu mettre a rude épreuve les compétences acquises en cours. Nous avons également pu décrypter le DMX et ses mystères afin d’en comprendre les trames et  protocoles. Le travail d’équipe avec un autre corps de métier nous a appris que la communication au sein d’un groupe est primordial au bon déroulement d’un projet. N’ayant pas eu toutes les informations en notre possession dès le début du projet nous avons eu du mal à nous mettre en route ainsi qu’à départager les taches que chacun devait effectuer. De plus n’ayant eu les cours de gestion de projet qu’une fois le délai du projet entamé de moitié ce fut compliquer de respecter les délais.

Cependant la mise en pratique des connaissances scolaires fut intéressante et la finalité du projet fonctionnant à 80% est relativement satisfaisante.