1) Préparation du schéma électronique de l’amplificateur et de l’alimentation
2) Choix des composants
3) Simulation du schémas électronique
4) Réalisation kicad
5) Réalisation de la plaque
6) Packaging
7) Liste du matériel commandé
III. Conclusion
1)Vidéo de présentation du projet
2) Remerciements
3) Webographie
I.Contexte du projet
1. Définition du projet
Dans le cadre de nos projet de première année il nous a été demandé de réaliser un amplificateur audio(stéréo) avec un cahier des charges définis. L’objectif primaire de ce genre de projet est non seulement de nous introduire au travail en équipe mais aussi en autonomie.
Notre projet l’amplificateur stéréo a pour but de permettre l’amplification de signaux sonores. De ce fait les sons issus d’un émetteur (smartphone par exemple) simulés par une variation de tension électriquement seront amplifiés pour être transmit à un récepteur (haut-parleur par exemple). Notre amplificateur devra être alimenté aussi bien sur le secteur qu’avec une batterie (voiture par exemple).
La première contrainte étant d’alimenter notre amplificateur, nous avons donc divisé notre projet en deux parties : l’alimentation et l’amplification.
Partie Alimentation : BARHAME Rayane, KELES Hakan, DARBOUX Marvin
Partie amplification : ABLAK Mehmet , AMAYOU Ayoub
2.Cahier des charges
Alimentation à rabattement et à retournement
230 v en entrée (l’alimentation pourra être branché à une prise) ; elle régule le courant et la tension pour qu’ils conviennent à l’amplificateur
10 à 12 v comme tension et jusqu’à 5 A en sortie
Source de courant constante avec transistor bipolaire
3.Expression du besoin
Ce schémas globalise de façons très générale toutes les contraintes (besoins) nécessaires a l’élaboration du projet. Les fonctions de services seront détaillées dans le tableau qui suit :
II. Déroulement du projet
1) Préparation du schéma électronique de l’amplificateur et de l’alimentation
Avant de commencer l’utilisation de logiciel et autres, nous avions dû commencer à faire la conception du schéma ‘brouillon’ sous forme papier. En effet, avec l’aide de notre tuteur, nous avions réaliser plusieurs calculs et plusieurs schémas différents pour pouvoir aboutir au schéma électronique de nos deux parties de notre projet.
2) Choix des composants
Après avoir fini la conception du schéma papier, nous avons commencé à choisir les composants pour la conception taille réelle. Nous avons donc préparer 2 fiches (une pour la partie Alimentation et l’autre pour la partie Amplification) avec le nom des composants non disponible à l’iut. Le choix des composants a été réalisé avec la prise en compte pour chaque composant du datasheet « idéale » pour notre projet du point de vue données de fabrication mais aussi du point de vue coût. Cette fiche regroupait donc le nom des composants à commander.
Exemple d’un document source que l’on a réalisé pour facilité la recherche des données composants :
2.1) Partie alimentation
Deux phases sont nécessaires à la réalisation d’un projet. La phase de conception et celle de la réalisation. Le choix des composant relie ces deux phases étroitement. Après la préparation de notre schémas électronique ils nous fallait trouver des composants adhérant à notre solution et attestant de la crédibilité de nos choix conformément à ce que le marché peut nous offrir. Cette étape c’est donc déroulé comme suit :
choix du condensateur : Calcul de la capacité du condensateur C = I / Δu * F I = 1A , Δu=5v (car on veut 10V en sortie et la transfo délivre une tension efficace de 15√2 = 21V donc la différence sera de 16), F = 100 Hz 1 Transfo = 50 Hz * 2 (en double)
choix de la diode Zener : 5 V
Pont redresseur de tension
choix de la résistance : Ampérage max : 250 Ma, Résistance : 16/(20*10^-3) = 800 Ω donc I =Vmin/R = 11/800 = 0.01375 = 13mA.
Afin de palier au défaut de la résistance pour avoir un courant continue, on a donc choisi d’opter pour un transistor
Choix du transistor: transistor PNP
Ampli opérationnel 741 avec tension de sortie max 25 mA
Choix du deuxième transistor:
Calcul des courants Ic pour des valeurs max et min :
– Pour le max : Icmax = β * Ibmax = 70 * (25*10^-3) = 1,75 A
– Pour le min : Icmin = β * Ibmin = 20 * (25*10^-3) = 0,5 A
Or 0,5 < 1A (Courant que l’on veut tirer) donc obligation de rajouter un transistor à l’aide d’un montage de Darlington en NPN. D’ou le choix de ce transistor 2n1711 en bas du 1er Transistor.
2.2) Partie amplification
3) Simulation du schémas électronique
Les schémas électriques on été réalisé dans un premier temps par le biais de PROTEUS ISIS (logiciel de simulation électronique)
Partie Alimentation: les tensions affichés par les voltmètres mettent donc en évidence la validité des choix de composants que nous avions fait ainsi que le respect du cahier des charges
Partie amplification: la courbe en verte fait office de tension de sortie et celle en jaune de tension d’entrée
4) Réalisation Kicad
Kicad est un logiciel de conception libre assisté par ordinateur intégrant à la fois un module de saisie de schémas et un module de routage de circuits électriques.
4.1) Conception partie alimentation
Nous avions eu pas mal de problèmes avec l’amplificateur opérationnel ainsi que le pont redresseur de tension afin de les relier comme il faut à la masse. La pose de la résistance variable vu qu’on arrivait pas a obtenir la bonne gamme de tension.
4.2)Conception partie amplification
La pose des radiateurs posait problème. Obtenir la bonne tension de sortie fut aussi très délicat.
6) Packaging
Le packaging c’est fait très rapidement. Il nous fallait une boite pas trop encombrante et simple à réaliser. La prise en main du logiciel ( ) c’est faite très rapidement, sans compter le fait que la forme complexe de la fermeture de la boite c’est faite très rapidement a cause de l’aisance d’utilisation du logiciel.
7) Liste du matériel commandé
III.Conclusion
1) Vidéo de présentation du projet
2) Remerciements
Ce projet fut pour nous une expérience unique. Il nous a instruit au travail en équipe et en autonomie. Nous remercions de ce fait nos professeurs de projet ainsi que nos professeurs électrotechnique et de bureautique pour le temps qu’ils nous ont consacré. Nous tenons également à remercier spécialement le responsable de L’IUT lab pour son implication dans la réalisation des plaques et du packaging.
Réaliser une maquette pédagogique pour les futurs étudiants de 1ère année.
But:
Remplacer l’ancienne sonde de température par un dispositif conforme et plus efficace que le précédent.
Permettre la caractérisation d’une sonde de température à tester.
Pouvoir refroidir ou chauffer le volume de test en dessous et au dessus de la température ambiante .
Contraintes:
Alimentation à découpage (0V-15V).
Température comprise entre 5°C et 70°C.
Monter à une température et savoir la maintenir (Ventilation et asservissement pour garder la température constante).
Normes de sécurité thermiques ,mécaniques et électriques.
Définitions des termes scientifiques
1) Tension électrique
Circulation du champ électrique le long d’un circuit
Mesuréeen volt
Notée U
2) Intensité (ou courant électrique) :
Déplacement d’ensemble de porteurs de charges électriques
Mesurée en ampère
Notée I
3) Résistance :
Grandeur caractérisant la « force » avec laquelle le conducteur s’oppose au passage du courant.
Exprimée en ohms Ω
Notée R
4) Tension alternative :
Tension variable qui prend alternativement des valeurs positives puis négatives
5) Tension continue :
Tension qui garde même signe et même valeur au cours du temps
6) Puissance électrique :
Représente la force motrice de l’électricité
Produit de la tension électrique aux bornes de laquelle est branchée l’appareil
Produit de l’intensité du courant électrique qui le traverse
Notée P
Exprimé en watt
Exemple d’utilisation d’une sonde de température
Ceci est un exemple d’utilisation de sonde de température:
Ici, on règle la température souhaitée
Cahier des charges
Diagramme bête à cornes
Diagramme de Gantt
Organigramme de Gantt
Étude des composants
Le module à effet Peltier.
Le module Peltier permet de transformer un courant électrique en une différence de température. Au sein de notre projet nous utiliseront le module Peltier pour refroidir notre plaque métallique. Ce module présente deux faces, dont l’une est dite froide et l’autre chaude. L’objet à refroidir se positionne sur la face froide et on évacue la chaleur avec un ventilateur par la face chaude.
La résistance chauffante.
La résistance chauffante est un matériau conducteur à base de métal présentant une résistance électrique au passage d’un courant qui la porte à une température donnée par effet joule.
Le relais
Notre relais est composé d’un électroaimant, qui lorsqu’il est alimenté transmet une force aux contacts. Les contacts commutent quand la bobine est alimentée et le retour à l’état initial se fait quand la bobine n’est plus alimentée.
L’AOP (L’Amplificateur opérationnel)
C’est un amplificateur électronique qui amplifie une différence de potentiel électrique présente à ses entrées. Les AOP ont été conçus pour effectuer des opérations mathématiques.
La diode de roue libre
La diode de roue libre se connecte en parallèle d’une charge inductive pour la continuité du courant électrique dans l’inductance. Cette diode permet d’assurer la continuité du courant électrique dans le circuit. En effet l’induction (la bobine du relais) à comme propriété essentielle qu’on ne peut pas rompre brutalement le courant qui la traverse car elle peut entrainer une surtension.
Le transistor NPN
Le transistor se comporte comme un interrupteur.
Les transistors bipolaires possèdent 3 connexions : le collecteur, la base et l’émetteur.
Le transistor s’active par une tension positive ou négative sur la base par rapport à l’émetteur.
Dans son état passif, le transistor bloque le flux électricité entre le collecteur et l’émetteur.
Sonde de température AD592
L’AD592 est une source de courant haute précision, elle nous fournit un courant par rapport à la température qu’elle relève. La sonde nous fournis 1µA par °K, ce qui nous permet de définir la température relevé.
Évolution du projet
Étude du cahier des charges
Alimentation
Étude du circuit de l’alimentation
Régulation
Étude du circuit de la régulation
Simulation sur plaque d’essai
Calcul des résistances
Achat composants
Réalisation Kicad
Connecteur entre borniers et Peltier/Résistance chauffante
Plaquette alimentation
Plaquette Régulation
Réalisation circuits imprimés
Circuit de l’alimentation
Circuit de la régulation
Circuit de l’AOP
Conception des boites
Montage des boites
Montage
//texte
Bilan
//vidéo de la maquette en fonctionnement
Mode d’emploi
//texte
Conclusion
//texte
Remerciements
Un grand merci à M. STRAFELLA et M.COLICCHIO, nos enseignants-chercheurs tuteurs pour ce projet, de nous avoir aidé pour ce projet.
Merci au département GEII de l’IUT de Mulhouse pour le prêt du matériel nécessaire et pour l’achat des composants.
Afin d’effectuer une mesure de courant dans un circulant électrique, il est possible d’utiliser une sonde sans contact électrique direct c’est-à-dire par isolation galvanique. L’IUT de Mulhouse utilise des sondes afin de mesurer les courants sur des maquettes d’études de systèmes. Ainsi le but du projet est la réalisation d’une sonde de courant étalonnée pour la mesure.
Pour notre deuxième semestre, nous avons eu comme projet la création d’une sonde de courant ou sonde à effet Hall :
Nous avons eu comme délai de 60 heures avec 4 heures de bonus lors des journées portes ouvertes de l’IUT.
Par ailleurs ce projet est destiné aux futurs étudiants qui manipuleront ces sondes lors de leur séance de travaux pratique. Ces sondes devront remplacées les anciennes qui ne sont plus aux normes. Nous allons remplacer les entrées non conformes par un potentiomètre qui régulera la tension à notre guise.
Ci-dessous une ancienne sonde de courant non conforme aujourd’hui:
Pour la création du schéma du projet nous avons besoin du logiciel Kicad pour a partie de création de schéma.
La partie de conception de la plaquette en modèle réel, il est nécessaire d’avoir la liste suivante :
Préparation des composants dans une boite individuelle
Une carte électronique vierge
Poste à souder
Fer à souder
Souffleuse
Etains
Des outils
Tournevis
Pince
Multimètre
Des outils de réalisation de la plaquette
Imprimante UV
Liquide révélateur
Massicot
Perceuse
Liste des composants nécessaire :
Quantité
Nom
Référence
Prix
*
1
Transformateur
121-3826
3,50 €
1
Fusible
848-2762
0.41€ -> 0.82€
1
Sonde LA 25-NP
286-311
21,20 €
2
–
Condensateur
862-3250
0,22€ -> 0,44€
Aluminium 2200µF
2
–
25V
653-0153
0,176€ -> 0,352€
Céramique 10nF
2
–
Régulateur de tension
298-8621
0,16€ -> 0,31€
L7915CV
–
L7815CV
298-8558
0,17€ ->
1
Pont redresseur
629-5989
0,438 €
1
Amplificateur op
371-1056
17,05 €
2
–
Résistances
132-258
0,017€ -> 0,034€
100Ω
1
LED
228-5988
0,168 €
1
Résistances LED
148-506
0,045 €
– 1kΩ
*
1
Port fusible
310-9841
1,87 €
*
1
Sortie coaxiale
619-6393
1,86 €
*
1
Interrupteur (switch)
124-5906
4,07 €
*
1
Potentiomètre
467-6106
0,228 €
Certains composants seront issus de la récupération de l’ancienne sonde, ce qui nous évitera une dépense en plus en matière d’œuvre (marqué par des *)
Par rapport à la documentation de la sonde, à la sortie de la sonde on choisit une résistance de 100Ω puis pour le choix du gain de l’AOP (Amplificateur Opérationnel non inverseur) on a également pris une résistance de 100Ω ainsi qu’une résistance variable de 1 kΩ pour avoir un gain de 11 maximum (Vsortie/ Ventrée = 1+R2/R1). On peut aller jusqu’à 9,5 car la résistance variable ne va pas jusqu’à 1 kΩ mais 850Ω.
Datasheet des composants :
Pour certaines pièces de la liste, nous devons nous servir du Datasheet du fournisseur afin d’avoir des données sur la pièce pour dessiner le module.
Le logiciel Kicad présenter ci-dessous, sera le seul logiciel informatique dont nous aurons besoin pour la réalisation du projet.
Dans la fenêtre de gauche, les fichiers sont :
Le circuit imprimé (Pcbnew)
La liste des empreintes des différents composants (Netliste)
Le schéma, le dessin du circuit (Eeshema)
Par la suite, lors de chaque enregistrement de fin de travail, les fichiers seront sauvegardés dans notre dossier personnel.
Dessin du schéma électronique de montage:
Pour commencer, nous avons commencé par créer le schéma de la sonde via la feuille d’explication (ER2.sch).
Création et association d’empreintes aux composants:
Pour ce qui est de certains composants comme la sonde LA 25-NP l’empreinte sera sous le nom de LA25NP, car nous avons dû créer une nouvelle empreinte qui n’existait pas auparavant afin de l’associer à ce composant. Ainsi que pour le switch sous le nom de SWittchy, le condensateur C1 et C2 en CP16-max, le bridge en pontRed etc… Pour pouvoir récupérer nos empreintes créer, on a créé une nouvelle librairie personnelle où toutes nos empreintes créées s’y retrouvent, nommé « ER2 ». La Netliste a pour but d’associer automatiquement l’empreinte aux composants lorsqu’on l’ajoute lors de la conception du circuit. (ci-dessous) De plus certains composants devaient être redessiner pour pouvoir avoir la bonne forme et dimension lors de l’insertion. Dans la Netliste courant à gauche, se situe les composants précédents et sur la droite les empreintes qu’on va attribuer aux composants.
Liaisons des composants et modifications des pads:
Ensuite on a dû modifier la taille des pads.
Après avoir effectué les modifications nécessaires pour les empreintes et vérifié, on a des chevelus qu’il faudra relié via un fil de taille 1.27mm.
Pour relié les composants entres eux, il faut cliquer sur un pad et relié au pad indiquer.
Avant :
Après :
Pour finir avec le logiciel, on imprime le tout en taille réelle. Lorsque l’étape de la réalisation sur Kicad est finie, nous pouvons passer à l’étape de la pratique qui est la conception.
Conception du circuit imprimé :
Pour commencer, il faut découper la carte électronique vierge à la dimension demandé à l’aide d’un massicot, puis après on tamponne la carte par un produit et on pose sur le circuit la feuille imprimée auparavant en taille réel et on frotte afin que le tout s’imprègne. Les typons serviront de « calque » pour la plaque découpé.
Par la suite on place la plaque et le typon dans une insoleuse durant 3 minutes afin que le cuivre soit parfaitement évacué et que le tracé soit bien visible.
On rince la plaque à l’eau puis on la nettoie avec du papier. Nous réitérons cette étape mais remplaçons l‘eau par du chlorure de fer. Au niveau des trous sur la plaque, les relevés de mesures ont été fait précédemment. Il suffit de percer à l’aide d’une mini perceuse. Une fois les étapes précédentes terminées, il faut souder les composants sur la plaque avec de l’étain.
A chaque soudure on teste les composants afin de voir leur fonctionnement. Puis à la fin on fera un test final.
Résultat obtenu:
La boite finale ressemble à :
Utilisation :
La sonde est à brancher sur secteur. Le voyant rouge indique le bon fonctionnement de la sonde. Pour faire les mesures on branche la sonde en série dans le circuit grâce aux bornes rouge et noire. La sortie coaxiale permet de visualiser les variations de courant sur un oscilloscope.
Conclusion
Durant ces heures d’études et réalisation, nous avons découvert le travail d’équipe, l’organisation et les contraintes lié à celui-ci. Nous avons pu approfondir nos connaissances en électrotechnique du premier et second semestre.A l’heure d’aujourd’hui, nous avons eu un problème avec notre première sonde. Le transformateur surchauffait. Il provenait de l’ancienne sonde qui était HS. Nous avons commandé un nouveau transformateur et avons dû modifier le typon pour correspondre aux nouvelles dimensions. Nous travaillons actuellement sur la réalisation de la sonde.
L’équipe de réalisation:
Anthony André Thanh
chef de projet responsable design responsable administratif
Dans le cadre du projet du second semestre en DUT GEII, (Génie Electrique et Informatique Industriel) de première année. Il nous est demandé de réaliser par groupe un projet, dont nous avons 60h encadré par nos professeurs (M.Hueber et M.Choisy ). Les enseignants nous ont demandé de choisir un projet que nous voulions réaliser sur une liste de 3 projets. Chaque projet doit être constituer de 2 à 6 personnes.
Membres du projet
Notre groupe est composé de deux étudiants en première année GEII :
Présentation du sujet
Nous avons pour projet, l’amélioration de la « ruche connectée » de l’an dernier (http://www.projetsgeii.iutmulhouse.uha.fr/ruche-connectee/). Elle est déjà équipé de capteurs de température et d’humidité. Les informations sont stockées et diffusées sur un site internet (http://abeilles.geiim.fr/accueil.php). Cela permet a l’apiculteur d’avoir des informations sur sa ruche en temps réel. Le système doit être autonome et en aucun cas, ne doit gêner l’apiculteur ou les abeilles dans leur travail. Notre but cette année consiste à améliorer l’alimentation de la ruche mais aussi ajouter un capteur de poids et un radiateur.
Cahier des Charges
1. Diagramme bête à cornes
La bête à cornes sert à définir à quoi sert le projet et à qui il sert.
2. MindMap
Le MindMap sert à montrer les différents points de réalisation du projet.
3. Diagramme de Pieuvre
Le diagramme de la pieuvre permet de connaître les différents fonctions, contraintes (gauche) et principales (droite) de notre projet.
4. Diagramme de Gantt
Le Gantt permet de prévoir l’organisation du temps dans le projet.
Budget détaillé
Notre Budget initial est de 200 euros. Nous disposons également du matériel mis à notre disposition à L’IUT Lab.
Nom
Quantité
Prix
Capteur de pression
4
29,99€
Capteur de température/Humidité
2
54,06€
Panneau solaire
1
48,65€
Gourde
4
19,96€
Câble USB 2m
1
5,28€
Plaque chauffante
1
20€
Battery management system
1
1,45€
Au total nous avons dépensé 179.39€ .
Gestion de projet
1. Etude de consommation
Avant de commencé tout type de montage, nous avons étudié la consommation de tout les composants de notre système embarqué afin de bien choisir l’alimentation qui suit. Nos capteur de température/d’humidité ont une plage de -40 à 125 degrés Celsius et 0% à 100% pour l’humidité .
Akeru
Capteur de température/d’humidité extérieure (SHT75)
Capteur de température/d’humidité intérieure (SHT11)
Capteur solaire
HXT711
IMAX
25 mA au repos/80 mA actif
1 mA
1 mA
0.002 mA
1.5 mA
2. Etude d’alimentation
Notre Système embarqué consomme au total près de 80 mAh. Nous devions commander un panneau solaire capable d’assurer l’alimentation.
Pour connaître la production du panneau solaire dans différents conditions ( à l’ombre, de coté, de dos, en plein soleil ), nous avons fait un montage pour ainsi avoir une estimation sous différents climats. Au plein soleil correspond à une alimentation optimale.
Pour stocker la production du panneau solaire, il suffit d’installer une batterie, accompagné d’un BMS qui permettra d’éviter la surcharge. La batterie fabriqué manuellement est composée de 3 piles lithium, au total 12V supportable par l’Akeru .
Mis en lien du panneau solaire et batterie
3. Etude capteur de poids
Nous avions à notre disposition des gourdes et des capteurs de pressions pour récupérer le poids de la ruche. Le capteur est alors placé au bout de la gourde mais malheureusement les capteurs de pressions atteignaient vite leurs limites et ne pourraient pas assurer une plage de mesure approprier.
Il a donc fallu penser à un système pour démultiplier la pression exercé sur cette gourde et ainsi repousser la limite du capteur de pression.
Des barres sont placées aux quatre coins du support de la ruche, ce qui servira à ce que la force exercée sur la gourde au milieu soit atténuée. Puisqu’une partie du poids est exercée sur les barres des coins de la ruche, cela soulagera d’une pression moins conséquente pour la gourde. Et ainsi on aura une plage de mesure beaucoup plus étendue.
Nous avons donc tester ce système de récupération du poids avec l’aide d’un programme pour convertir le résultat à la sortie du capteur en kilogramme et ainsi l’envoyer sur une plateforme où le poids sera affiché.
4. Collecte et affichage de donnée
La collecte des données de notre l’Akeru, par nos capteurs de pression, température/humidité sont transmis sur un site Actoboard dédié au réseau Sigfox. L’affichage de donnée peut-être modifié directement sur le site Actoboard . L’apiculteur peut consulter les informations en lignes rafraichie tous les 10 min.
5. Comparaison entre Sigfox et Lora
Lora
Sigfox
Fréquence utilisé
866 MHz et 433 MHz
868 MHh
Débit
300 bits/s à 100K bits/s
500 bits/s
Taille de transmission d’information
sans limite
avec une limite de 12 octets par message et 140 messages par jour
Puce (gère le flux de donné situé dans le circuit intégré)
Semtech ,Microsemi
Atmel, Texas, Silicon Labs, ST Micro
Bilan
Le système embarqué est capable de s’auto-alimenter et de transmettre ou recevoir des données via le réseau Sigfox, des données reçues en temps réel par nos différents capteur sur notre Akeru grâce au onde basse fréquence qui permettra ainsi a l’apiculteur de suivre sa ruche en ligne.
Dans le cadre du projet d’études du DUT Génie Electrique et Informatique Industriel de Mulhouse, nous avons du réaliser un projet lié au domaine de l’électronique et de l’informatique. Ce projet s’est étalé sur la totalité du deuxième semestre et a totalisé un volume horaire encadré de 60 heures. Ce projet qui n’est autre que le contrôle de l’humidité du sol.
Le choix de l’équipe et du projet a été effectué en fonction de nos affinités et de nos préférences. Durant la totalité du projet, deux professeurs nous ont encadré : M. Haultcoeur et M. XU.
Présentation du sujet
Le but du projet est de réaliser un système autonome de régulation du taux d’humidité du sol sur plusieurs types de sol différents. De plus si le niveau d’humidité passe sous un certain seuil le système devra y remédier.
Notre dispositif devra bien évidemment être mobile et non fixe pour pouvoir changer de point de mesure et il devra résister aux intempéries de façon à pouvoir rester à l’extérieur.
Cahier des charges
1.Bête à cornes
Afin de connaitre les besoin primaire ou l’exigence principal de notre projet il nous a fallu utiliser le diagramme dit « de la bête à cornes »:
2. Pieuvre
Maintenant que nous connaissons le besoin primaire nous pouvons passer au diagramme dit « de la pieuvre » qui permet d’identifier les fonction principales (FP) et contraintes (FC) :
FP1
Le capteur d’humidité pourra être déplacé par l’utilisateur et être réglé par ses soins
FP2
Notre projet devra pouvoir détecter le taux d’humidité du sol et réagir si il passe sous un certain seuil
FP3
Le système devra pouvoir être disposé en extérieur et devra donc résister aux conditions climatiques et intempéries
FP4
Le capteur devra être implantable dans tous types de sol
FC1
Le système devra pouvoir enregistrer les données que le capteur va récolter
FC2
Le conteneur qui accueillera le système devra etre esthétique et agréable à l’œil
3. MindMap
Avant de pouvoir passer dans le gros du projet il faut réalise un MindMap qui est le fait de représenté toute les idées et tache autour d’un même sujet et donc le voici :
4. Planification Gantt
Maintenant grâce au MindMap nous pouvons réalisé le Gantt qui est le fait de planifié toute ces taches :
5. Délais
La limite finale du projet correspond au jalon fixé par nos professeur encadrant qui été avancé le plus possible et si possible finir notre oeuvre avant le jour de la soutenance le jeudi 22 juin 2017.
Donc notre projet devra au plus tard être finie le jour précédent la soutenance, soit le Mercredi 21 Juin 2017.
6. Budget de départ
Le budget dont nous disposons est de 150€. Tous les matériaux disponibles à l’IUT et la commande de pièce annexe sont a prendre en compte dans le budget, seul le raspberry et ces accessoires(écran +souris +clavier) ne sont pas pris en comptent car prêtés par l’établissement.
7. Liste des achats
Pour notre projet nous n’avons acheté que quelques composants qui nous on permis de réaliser la nappe qui nous permettra par la suite de connecter les ports du raspberry au circuit de la plaque électronique car les autres composants ont été trouvé dans le magasin de L’IUT.
Réalisation du projet
1. Composants
Avant de pouvoir débuter notre projet il nous a fallu commencer par faire quelque recherche sur les composants mis a notre disposition par L’IUT :
1. Microcontrôleur
Caractéristiques technique:
1 Go de RAM
4 ports USB
40 broches GPIO
Port HDMI complet
port Ethernet
Prise audio combinée de 3,5 mm et vidéo composite
Interface caméra (CSI)
Interface d’affichage (DSI)
Emplacement de la carte Micro SD (maintenant push-pull plutôt que push-push)
VideoCore IV noyau graphique 3D
2. Capteur d’Humidité
En ce qui concerne les capteurs nous étions au préalable munis d’un capteur (conductivité électrique). Cela dit, en faisant des recherches plus approfondie j’ai découvert que certain autre type de capteur comportaient des atouts non négligeable pour avoir un dispositif de mesure avec une sensibilité élevé. J’ai donc décidé de faire un tableau de comparaison pour avoir une idée du capteur qu’il faudrait utiliser dans notre cas.
Grace a ce tableau on remarque que la méthode TDR (réflectométrie temporelle) ,qui mesure l’humidité volumique du sol ,permet une mesure très précise de l’ordre de la picoseconde (10^-12) se qui est largement suffisant dans notre cas.. Malgré la disponibilité et le prix un peu plus élevé, pour des mesures aussi précises et rapide autant payer un peu plus cher.
3. Électrovanne
Pour l’électrovanne j’ai décidé de faire pareil que pour le capteur pour vérifier que le type de notre électrovanne(TOR: tout ou rien) a été la plus adaptée :
D’après ce tableau on remarque que le Distributeur a commande proportionnel est celui qui serait le plus adapté. Prenons un exemple, si après une mesure on remarque que le taux d’humidité est inférieur a notre seuil défini grâce a ce distributeur nous pourrions réguler le flux d’eau qui arriverais afin d’optimiser le taux d’humidité contenu dans le sol. Cependant avec notre électrovanne nous devons améliorer le temps d’ouverture de l’électrovanne.
2. Test fonctionnement
Maintenant que nous connaissons les caractéristiques de nos composants nous allons pouvoir passer a la deuxième partie qui est le test de chaque composants afin de connaitre leur fonctionnement :
1. Capteur
Avant de faire des test dans des pots de terre j’ai commencé par voir les valeurs que me sort mon capteur dans de l’eau et dans l’air :
On observe sur l’image de gauche (Test dans l’eau) qu’avec une valeur de 3.3V en entrée, la valeur mesuré est de 1.26V ce qui prouve que plus l’humidité est importante plus la tension mesurée et faible.
On observe sur l’image de droite (Test dans l’air) qu’avec la même tension que dans le premier cas, si la valeur mesuré est la même que celle de l’entrée, l’humidité est plus importante en fonction de la résistance entre les 2 borne.
Maintenant que je connais un peu mieux le capteur et son fonctionnement je suis passé au test sur plusieurs types de terre fournie par notre professeur encadrant (M.XU) :
sur cette image on peut voir trois type de terre différent:
Sable (pots en haut au centre)
Mélange (pots en bas a gauche)
Argile (pots en bas a droite)
Premier test:
On remarque que sous une tension de 3.3V , la valeur mesuré en sortie vaut 3.15V ce qui signifie que le sable est une terre de base trés peu humide.Plus l’humidité est grande plus la tension mesuré et faible.
Deuxième test :
On observe que toujours sous une tension de 3.3V , la valeur que nous affiche le voltmètre est 0.66V, ce qui signifie que le mélange est 2 fois plus humide que la mesure faite précédemment dans l’eau.
Troisième test :
Pour finir on remarque que sur de l’argile, la tension mesuré en sortie 0.8V et un plus basse que celle réalisé dans l’eau(1.26V) .
En résumé, chaque type de terre avait ses propre caractéristique et donc pour un même volume d’eau chacune de ces terre aura ça propre manière de l’absorber. De ce fait, lors de la programmation du dispositif il y aura plusieurs facteurs a prendre en compte pour pouvoir optimiser l’irrigation des terres et donc le taux d’humidité.
2. Électrovanne
Pour l’électrovanne les tests ont été beaucoup plus simple a réaliser car j’ai juste mesuré la tension minimal a laquelle l’électrovanne s’ouvrait après réalisation du montage et test en augmentant la tension on trouve que sous une tension minimal de environ 6V l’électrovanne s’ouvrait.
Après la réalisations de ce montage j’ ai cherché un moyen de raccorder l’électrovanne a une arrivé d’eau et donc voici le prototype réalisé grâce au matériel a notre disposition:
On peut voir qu’on a raccordé l’entré de l’électrovanne avec un embout (de robinet) sur le tuyau d’arriver d’eau et grâce a un collier de serrage on a pu ouvrir l’arriver d’eau sans qu’il y ait des fuites.
3. Réalisation carte électronique
Pour la réalisation de mon circuit imprimé j’ai eu droit a l’aide de collègue extérieur a mon projet, ce qui m’a permis d’avancer plus vite et donc de pouvoir aboutir a quelque chose de concret, voici le résultat :
On peut voir sur ce graphique le schéma réalisé grâce au logiciel KiCad, ce schéma se compose de plusieurs partie différente :
Partie Capteur(rouge) : Cette partie se compose du connecteur pour le capteur qui va permettre de mesuré l’humidité du sol.
Partie Raspberry(vert) : cette partie se compose de tous ce qui est traitement des donné donc du MCP3008 qui est un convertisseur analogique numérique et des connecteur pour les ports GPIO du raspberry.
Partie Relay(orange) : Cette partie se compose de tous les composant qui permette le bon fonctionnement du relay.
Partie LM317(noir) : Cette partie se compose de tous les composant qui permette le bon fonctionnement du LM317 qui est un régulateur de tension.
Partie Externe(jaune) : Cette partie se compose d’un connecteur pour une batterie externe(en bas) de 5V est d’un connecteur(en haut) pour l’électrovanne.
Après avoir réalisé le montage ci-dessus je suis passer au routage du circuit toujours grâce a KiCad puis après un long processus en commençant par couper une plaque au dimension voulue puis en passant par plusieurs différent machine(ex: insoleuse, laveuse):
Donc pour le processus on commence par couper une plaque de cuivre au dimensions voulue puis on imprime les piste du circuit routé ensuite on commence par placé tout ceci dans une insoleuse (première photo) celle-ci permet de marquer sur notre plaque les piste du circuit ensuite on passe notre plaque dans un révélateur qui permet de faire apparaître celle-ci on continue ensuite par passer notre plaque dans une laveuse(seconde photo) celle-ci est composé de plusieurs solution chimique qui vont permettre d’enlever le surplus de cuivre et pour finir on passe a l’étamage des pistes.
Ensuite après y avoir souder chaque composant a son emplacement voici le résultat
4. Programmation
Lors de la programmation la tache fut assez rude car il a fallu prendre en compte beaucoup de paramètres liés au type de terre et d’autres lié au composant électronique utilisé lors de la création du circuit imprimé. Voici un prototype du programme qui n’a malheureusement pas pu être testé a cause d’un manque de temps et d’effectif :
#!/usr/bin/env python
import time
import os
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
elsif volts0 >1.5
GPIO.output(2,GPIO.LOW) #sortie 2 à 0L
time.sleep(1)
Normalement pour l’instant ce programme sert a mesure l’humidité du sol sur un seul type de terre(sol humide) mais comme dit précédemment je n’ai pas eu le temps de le tester.
Pour une meilleur compréhension du programme, du début jusqu’à la boucle « while » ce sont les configuration du MCP3008 puis ensuite il y a notre code.
5. Packaging
Enfin nous voici a la partie final qui permet de voir si tous les effort fournie tous au long de ce projet on aboutie a un dispositif qui répondra ou non au cahier des charge et au CDCF(cahier des charge fonctionnel) défini au début du projet, grâce au machine disponible a l’IUT lab voici le résultat des découpe faite a la machine laser qui ma permis de découpé mais plaque :
Ensuite après avoir assemblé toute ces pièces et les composant voici le résultat :
On observe dans cette boite 2 partie différente :
Partie électrovanne : Cette partie se compose uniquement de l’électrovanne d’un tuyau d’arrivé d’eau(gauche) et un tuyau pour l’irrigation du sol(droite).
Partie électronique : Cette partie se compose du circuit électronique réalisé, du raspberry et du capteur qui se situe a l’extérieur.
Pour finir après avoir ferme la boite voici le résultat final:
Conclusion
Pour conclure, ce projet ma permis de découvrir de nouvelles choses comme: la gestion d’un projet, le travail en équipe, la démarche à suivre pour arriver au bout d’un projet, certaines nouvelles méthodes. De plus, cela ma permis d’approfondir mes connaissances dans différent domaine. Enfin pour finir au cour de ceux projet j’ai eu a surmonté d’innombrable échec (surtout dans la réalisation de la carte électronique a cause de composant introuvable dans le magasin ce qui ma obligé a changer ma carte et lors de l’impression le noir n’été pas assez puissant ce qui a rendu mais piste fragile …) et problème surtout dû au membre de mon groupe qui on tous décidé de quitté le DUT GEII pour continuer ailleurs ce qui ma valu de travailler pour 4.
Perspectives d’évolution
Si notre dispositif devait être commercialisé a la fin des heure qui lui ont été consacré alors, on peut dire sans trop de doute que notre dispositif peut nettement s’améliorer en tout point tant en terme d’esthétique que de logistique ou encore de fonctionnement ou de précision des mesures. Notre projet peut encore grandement s’améliorer sur certain point comme par exemple en changeant le capteur (conductivité thermique) par un TDR pour nettement augmenter la précision ou encore pour l’électrovanne la changer par une a commande proportionnel qui permettrais de régulé le flux d’eau et donc de mieux doser l’eau qui sert a irriguer ou encore lors de la création du packaging utilisé des matériaux résistant au intempérie, etc… . Tout cela pour dire que notre projet a encore une grosse marge de progression avant de pouvoir être commercialisé sur le monde du marché.
Remerciements
L’IUT de Mulhouse ainsi que l’IUT LAB pour le budget et l’apport de matériels.
Créé par notre groupe, Meanlicx est un robot collaboratif capable d’assister une institutrice ou un instituteur. Le robot s’intègre rapidement dans un environnement scolaire existant en installant simplement un suivi de ligne métallique au sol pour lui permettre de se déplacer sereinement dans la salle de classe. La robotique collaborative fait le pari d’une équipe éducative Homme/Robot performante et productive : le robot suit des tâches répétitives de distribution de matériel permettant à l’institutrice de ne pas perdre de temps à cette tâche.
Equipé d’un système de caméra embarquée, comprise dans le robotino, le robot est capable de reconnaître les formes programmées pour connaître les différents points d’arrêts, détecter la présence d’objets, de personnes et peut ainsi éviter les collisions. Le robot est capable de détecter le niveau de volume sonore en alertant son entourage grâce à un dispositif de leds tricolores. De plus, un élève absent peut tout de même avoir l’impression d’assister au cours via YouTube grâce à une fonction detéléprésence.
Sommaire :
1. Introduction
2. Présentation du sujet
3. Cahier des Charges
Objectifs du projet
Diagramme Pieuvre
Fonctions et contraintes
Contraintes
Définition de termes techniques essentiels
Arduino
Raspberry Pi
Capteurs
4. Budget détaillé
5. Développement
6. Gestion de projet
7. Manuel Technique
8. Bilan
9. Bibliographie
10. Remerciements
1. Introduction
Dans le cadre du module Etudes et Réalisations du deuxième semestre en DUT de GEII (Génie Electrique et Informatique Industrielle), il nous est demandé de réaliser par groupe un projet imposé et présenté par les professeurs qui s’inscrit dans notre programme pédagogique.
2. Présentation du sujet
« Robot Collaboratif » est un sujet qui consiste en la création d’un robot, défini selon les souhaits des élèves d’une classe de CE1. Après avoir rencontré ces élèves de l’école Lamartine à Illzach pour partager nos connaissances en robotique, ils nous ont proposé des idées de robots qui leur seraient utiles. En faisant un tri dans leur propositions et après concertation au sein du groupe, nous avons choisi de concevoir un robot qui se déplace dans la salle de classe en délivrant aux élèves des objets que l’institutrice veut leur distribuer. De plus, si un élève est absent à l’école, il peut tout de même avoir l’impression d’être présent grâce à la fonctionnalité de téléprésence qui lui permet de suivre le cours depuis chez lui.
3. Cahier des Charges
Objectifs du projet
L’objectif principal de ce projet est de faire découvrir la robotique à des élèves en classe de CE1 puis de leur créer un robot qui répondra à leurs attentes. Cependant, les objectifs secondaires à prendre en compte sont :
– L’organisation de notre rencontre avec les enfants le lundi 6 mars au matin en leurs proposants différents défis et activités pédagogiques pour leur faire découvrir la robotique ;
– La création de quelques modèles de robots Mindstorms à montrer aux élèves ;
– La conception du prototype avec la programmation des moteurs des capteurs, la structure mécanique, l’interface Homme-machine, le déplacement du robot ;
– La présentation de notre prototype aux enfants le mercredi 31 mai ;
– La création du robot final.
Périmètre
Puisque nous travaillons avec des élèves de CE1, il est nécessaire d’employer un vocabulaire qui leur est compréhensible. Il faut également que nos robots répondent à leurs attentes.
Du 2 au 31 mars, 60 heures sont entièrement consacrées à ce module dans l’emploi du temps. Deux professeurs encadrant sont à notre disposition afin de suivre et noter notre travail tout en restant à notre disposition pour tout besoin.
Nous avons également poursuivi le travail de la conception de notre robot jusqu’à la soutenance finale durant une centaine d’heures.
Fonctions et contraintes
Ce diagramme représente les fonctions principales (FP) de notre projet et les fonctions contraintes (FC) sont les fonctions auxquelles il est soumis.
Contraintes
Date limite : 31 mai 2017 pour la présentation du prototype aux enfants
Budget : 200 €
Définition de termes techniques essentiels
Arduino
Un Arduino est un Microcontrôleur programmable ayant des entrées et des sorties et se programmant dans un langage très ressemblant au langage C et possédant un environnement de développement dédié. Toutes les connaissances et bibliothèques sur le développement de programme Arduino est libre d’accès.
Raspberry Pi
Une Raspberry Pi est un nano-ordinateur monocratique possédant son propre système d’exploitation sous Linux. Il permet de naviguer sur internet ainsi que développer des programmes et gérer des sorties.
Capteurs
Un capteur est un dispositif qui permet la transformation de l’état d’une grandeur physique observée en une grandeur utilisable.
Utilisation d’un robot six axes Stäubli TX60, équipé de son Teach et programmable via la suite logicielle Stäubli.
Utilisation d’une caméra noir et blanc intelligente NI1722 Smart Camera, programmée via le logiciel NI Vision Builder.
Connexion entre la caméra et le robot via une connexion Ethernet TCP.
Le robot doit être capable de reconnaitre des pièces de différentes formes, réparties sur une surface pouvant changer de taille et/ou de position.
Le robot ne doit pas entrer physiquement en contact avec la caméra.
La préhension des pièces se fera au moyen d’une ventouse qu’il faudra dimensionner et adapter au robot.
Objectif du projet
Ce projet doit mettre en place une interaction entre un robot six axes Stäubli TX60 et une caméra industrielle. Le but est de retirer des pièces de différentes formes du champ de vision de la caméra, en établissant une communication entre celle-ci et le robot afin de partager les coordonnées des pièces. Le robot doit ensuite retirer les pièces du champ de vision de la caméra, en fonction d’une « recette » dictée par l’utilisateur.
La caméra
La caméra utilisée pour le projet est une NI1722 Smart Camera. L’avantage d’avoir une caméra « intelligente » est de pouvoir se passer d’un ordinateur pour le traitement des images. Ainsi la prise de vue, la reconnaissance des pièces et le calcul de leurs coordonnées se fait directement du côté de la caméra et seules les coordonnées des pièces sont envoyées au robot.
Le robot
Le robot six axes Stäubli TX60 nous permet dans ce projet de déplacer les pièces. Il communique avec la caméra industrielle via une liaison Ethernet TCP, lui permettant de récupérer les coordonnées des différentes pièces. Le Teach permettant de contrôler le robot manuellement et la suite Stäubli permet de créer et tester une bonne partie du programme directement sur un simulateur. Le programme peut aussi être modifié directement sur le Teach, mais le manque d’ergonomie le destine surtout à faire des modifications sur le terrain.
La ventouse
La ventouse, couplée à un générateur de vide type venturi, est de taille très réduite. L’avantage d’une petite ventouse est de pouvoir avoir une erreur plus importante lors du pointage des pièces par le robot. L’ensemble, monté sur un support fixé au bout du bras du robot, est relié à l’arrivée d’air via le système pneumatique du robot. La ventouse et le générateur de vide ont été acheté sur le site https://www.smc.eu/portal_ssl/webpages/01_products/products.jsp sous les références :
ZPT10BF-A6 pour la ventouse
ZH05DL-06-06-06 pour le générateur de vide
Le fonctionnement
Le programme permettant la manutention des pièces se résume en plusieurs étapes :
La définition du repère caméra : le support de travail est doté de 3 points permettant de définir le repère de la caméra. Une fois le support et les trois points de repère placés dans le champ de vision de la caméra, celle-ci créé automatiquement le repère et calcule la variable permettant de faire la conversion millimètres / pixels.
Acquisition de l’image :
Binarisation de l’image : Définition du repère de la caméra :
Importation des coordonnées des pièces : pour cela, il suffit d’aller dans le menu correspondant et de sélectionner les coordonnées des pièces qui nous intéressent. Le robot va ensuite demander à la caméra de faire une prise de vue et de renvoyer les coordonnées des pièces en pixels, puis faire la conversion pixels/millimètres via une variable nConversion calculée au préalable. Les coordonnées de chaque pièce s’affichent une fois acquises par le robot.
Sélection de la « recette » : ce menu permet à l’utilisateur de choisir les pièces qu’il souhaite conserver dans le champ de vision de la caméra. Une fois que les pièces à conserver sont sélectionnées, le robot va automatiquement retirer les pièces indésirables et créer une pile de pièces pour chaque forme. Il serait aussi possible de faire l’inverse, en remplissant une boîte avec les pièces demandées par exemple. Après avoir fini sa manœuvre, le robot retourne en position initiale et attend l’acquisition de nouvelles pièces et/ou d’une nouvelle recette.
Conclusion
Ce projet nous a permis d’améliorer nos compétences sur certains points. Pour commencer, l’utilisation réelle d’une caméra industrielle apporte plusieurs manières de traiter un même problème de vision industrielle. Il faut prévoir l’éclairage, le fond sur lequel travailler en fonction de la couleur des pièces, ou encore la distance de focalisation de la caméra. La partie robotique, quoique plus facile à programmer grâce à la possibilité de faire une simulation sur le logiciel Stäubli, nous a néanmoins posé quelques problèmes de communication avec la caméra. Pour finir, nous pouvons dire que le projet pourrait être approfondi en prenant en compte la possibilité d’avoir plusieurs pièces de même forme, ou travailler en tenant compte des couleurs, ce qui nécessiterait un changement de caméra.
Projet réalisé par BOYARD André-Julien et SINGER Vincent.
Ce projet consiste à utiliser le robot Tx40 et l’automate de stockage. Le but de ce projet est grâce au robot de chercher les pièces de l’automate de stockage, de les prendre puis de les déposer en palette par colonne de deux pièces. L’utilisateur pourra choisir quelle pièce il voudra prendre (rouge, noir ou métallique) et/ou faire des combinaisons telles que rouge/noir ou bien métallique/rouge par exemple.
Présentation de l’équipement
Pour ce projet, nous avons utilisé le robot Tx40, c’est un robot articulé avec 6 degrés de liberté de la marque Stäubli.
Robot Tx40
Nous avons aussi utilisé l’automate de stockage pour amener les pièces dans le bon compartiment. C’est un automate de la marque Siemens que nous avions déjà vu en première année en API.
Automate de stockage
Réalisation
Pour la réalisation de ce projet, nous avons utilisé différents logiciels de programmation.
Pour la partie automate, nous avons utilisé le logiciel Siemens TIA Portal. Cela permet des programmer des automates (API) grâce à des programmes en ladder.
Programmation du choix des différentes pièces
Pour la partie robot, nous avons programmé grâce au logiciel Staubli ou directement grâce à la commande du robot.
Commande
Programmation
Programme du start qui défini le menu de choix
La programmation du robot est la partie la plus importante du projet, la plus longue et la plus difficile. Durant la programmation nous avons quelques problèmes comme le problème de collision avec l’automate quand le robot prend les pièces ou alors quand le robot ne peut pas aller à un endroit dû à un encombrement. Le fais de programmer directement sur la commande à été difficile et long car nous avons jamais fais cela avant. Le deuxième problème à été que le robot ne faisait pas exactement ce que la simulation montrait.
Rendu visuel du projet
A ce jour, le robot empile correctement chaque recette (r/r, n/n,m/m,n/m,n/r et r/m). Ce qu’il manque encore est le fais de faire plusieurs recettes à la fois, car il y a un problème dans les transformées du programme.
Nous n’avons pas réussi à arriver à la partie communication entre le robot et l’automate qui nous permettrait une gestion de nombre de pièce grâce aux différents compteurs.
Semestre 4
Présentation du projet
La suite du projet consiste à utiliser le robot Tx40 et l’automate de stockage. Le but de ce projet est, grâce au robot, de chercher les pièces de l’automate de stockage, de les prendre puis de les déposer dans chaque emboitement des différents socles. L’utilisateur pourra choisir quelle pièce il voudra prendre (rouge, noir ou métallique) et/ou faire des combinaisons telles que rouge/noir ou bien métallique/rouge par exemple.
Création de socle
Nous avons du créer deux socles grâce à une machine de découpe au laser, les différentes pièces s’emboiteront dans chaque emboitement un a un.
Socle en bois
Programmation
Après avoir étudié le nouveau but du projet, nous avons regardé si nous pouvions reprendre des parties de notre ancien programme. La partie du programme de prise des pièces est inchangé, mais toute la partie dépose a du être refaçonner.
Communication
Un autre but du projet était de mettre en place un communication TCP/IP entre l’automate et le robot Tx40 pour pouvoir connaitre le nombre de pièces dans l’automate.
Automate programmable industriel
Robot Staubli Tx40
Programme de communication TCP/IP
Nous avons d’abord essayé une communication local grâce à un hyperterminal. Nous avons pu envoyer un caractère qui correspondait à la détection de pièce dans l’automate. Cet essai à réussi et donc nous avons pu passer à l’étape suivante.
Nous avons alors essayer la communication entre le robot et l’automate sans succès.
Durant notre 3ème semestre de notre formation Génie Electrique et Informatique Industrielle (GEII), nous sommes à nouveau amené à réaliser un projet. Nous avions le choix entre différents sujets qui concernait soit le domaine de l’automatisme, soit le domaine du réseau industriel. Nous devions choisir 1 sujet de chaque domaine. Nous avons été reçu sur notre 2ème vœu qui est Modbus TCP.
Cahier des charges
diagramme « bête à cornes » :
diagramme « pieuvre » :
Tableau présentant la fonction principale et les fonctions contraintes :
Gestion du projet
Faire fonctionner dans un premier temps une lampe (1.7 A)
Programmer l’interface
Etude pour la fabrication d’une carte de puissance
Réalisation de la carte de puissance
Faire fonctionner feux de brouillard arrière, feu de plafond, phare, clignotants, ventilateur0, feux de freins
Activer ces composants à partir d’une interface avec des boutons
Interfaçage, fixations et câblages
Réalisation de la carte de puissance :
Avant de réaliser la carte, il fallait déjà connaître les caractéristiques des lampes, et en fonction choisir les composants qui correspondent. Donc il a fallu tester les feux.
Ci-après se trouve une image résumant les tests des différents feux, et le tableau comportant toutes les valeurs trouvées :
Feu avant Feu anti-brouillard arrière
Ces tests nous ont permis de voir l’intensité maximum qui devra traverser la carte et donc adapter la carte pour cela.
Pour la réalisation de cette carte, nous avons besoin : 3 borniers de 2, 2 borniers de 3, 2 diodes (de roue libre) « classiques », 2 relais et de 2 fusibles. Ensuite, la réalisation de cette carte se fait en 2 temps : premièrement, il s’agissait de réaliser la carte sur le logiciel Kicad et deuxièmement de la fabriquer.
L’étape Kicad se fait en 3 étapes ; il faut réaliser le schéma, créer la netliste associé pour enfin s’occuper du pcb. Le schéma que j’ai créé sur Eeschema est le suivant :
J’ai du changé le module du relais car il ne correspondait pas au mien. Par simplification, j’ai fait la moitié du schéma, et j’ai copier/coller pour avoir un schéma bien aligné et pour bien s’y retrouver. Avec ce schéma, j’ai généré la netliste qui suit :
A l’aide de cette Netliste, j’ai ouvert pcbnew. J’ai changé l’empreinte du fusible et des relais pour qu’ils correspondent aux tailles de mes composants.
Fusible :
Relais :
Une fois les composants bien disposés sur la carte, je pouvais créer les pistes. Un détails mais pas des moindres, toutes les pistes ne seront pas de la même taille puisqu’elles conduiront des courants différents. Ci-après se trouve le pcb de la carte de puissance.
La difficulté se trouve surtout dans la taille des pastilles et des trous puisque les pattes des composants doivent rentrer dans les trous.
Après quoi, il suffit d’imprimer le pcb en faisant apparaître les trous, les pastilles, les pistes et de bien vérifier que les trous ont la bonne taille et le bon espacement par rapport aux composants. Une fois fait, je suis passé à la fabrication de la carte.
Ma carte faisant à peu de chose près 10cm sur 10cm, j’ai pris un circuit imprimé et je l’ai coupé pour avoir les dimensions précédentes. Ensuite les étapes s’enchainent ; il faut graisser le dos de la feuille imprimé, placé la feuille ainsi que le circuit imprimé (démuni de son scotch bleu) aux UV en faisant bien attention d’être bien sur le circuit et j’ai mis une insolation d’une durée de 2’40 », j’ai passé la carte au révélateur puis dans la machine afin que la carte ne conserve que les pistes et les pastilles, et enfin passé la carte à l’étamage. On finit par faire les trous et les soudures en respectant le schéma. Et voila la carte de puissance!
Ici les images correspondants aux différentes étapes dans l’ordre chronologique :
Maintenant que la carte de puissance est créé, image suivant :
Il s’agit donc de la tester afin de vérifier qu’elle est fonctionnelle et qu’elle correspond aux attentes.
Programmation:
On a dû réaliser un programme pour faire une démonstration du projet à l’aide de l’automate qui pourra activer les sorties que l’on à programmé.
Automates :
Ensuite on pouvait commander ces sorties sur un IHM (Interface Homme-Machine)
IHM:
Voici le programme qui nous a permis de réaliser la fonction clignotant d’une voiture.
Comme vous pouvez le voir le programme est sur une sortie que l’on alterne entre TRUE (vrai) et FALSE (faux) avec d’avoir le clignotant. Le seul inconvénient était la vitesse de clignotement. Pour subvenir à cet inconvénient on à régler la vitesse du compteur qui réglait l’action entre le TRUE et le FALSE. On a du pour cela changer le temps de cycle du CPU qui était de 1000 ms. On l’a divisé par deux pour avoir un clignotant optimal donc 500 ms.
————————-
Continuité du projet au semestre 4
Au semestre 4, nous avons eu la chance de pouvoir continuer notre projet afin de le finaliser entièrement. Le but étant de commander tous les feux.
Nous avons commencé par la duplication de la carte initiale, et nous en avons fait 5 autres en suivant le même procédé.
Exemple de l’étape des UV.
Après tous les perçages et les soudures réalisés, nous nous sommes occupés du câblage en suivant le schéma suivant:
Ensuite nous avons améliorer l’interface en fonction. En effet, en rassemblant les feux par catégorie par le câblage, nous avons fait de même sur l’interface. Par contre, nous avons reçu qu’une partie de la dernière commande, ce qui a pour effet qu’on ne peut pas commander tous les catégories de feux comme les feux de position par exemple.
Notre professeur M. Mercklé nous a aussi procuré une batterie plus puissante qu’au semestre 3. En effet, auparavant nous étions limité à 6 ampères, et désormais nous sommes limités à 10 ampères ce qui nous permet d’allumer 2 catégories de feux en même temps au maximum (à part les feux de brouillard, car il y a 3 feux dans cette catégorie).
Du coté logiciel on à réaliser u ne fonctionnalité dédier au phare : l’appel de phare du programme que vous trouverez ci dessous:
Partie Lampe
Dans cet partie on a du mettre en place des lampes avec un automates wago qui les commandes.
On a mis en place l’automates wago on a du régler les sorties relais(en rouge) qui était en tout ou rien (0 1) et les sortie analogiques(en bleu) on était plus compliqué à mettre en oeuvre car il fallait trouver les tensions de commande qui sont de 0V à 10V. Et sur l’automates il sont codés sur 12 bits , cet sortie analogique nous sert pour faire varier l’intensité des ampoules. Sur l’IHM on a mis une nouvelle page dédier à cet automates avec des sliders qui permette de régler l’intensité des ampoules à distance .
Conclusion
Nous sommes arrivés à finaliser ce projet. Un projet est toujours intéressant et celui ci n’a pas fait exception. En effet, en tant que Technicien Supérieur nous devrons aussi savoir comment dimensionner, modéliser et réaliser une carte de puissance devant répondre aux besoins et pouvant faire face aux contraintes, programmer un automate et un interface, mettre en oeuvre une maquette, câbler et fixer. Malheureusement on a pas pus aboutir la fonctionnalités des lampes par manque de temps mais on a réaliser plus de la moitié du travail sur cette partie.Nous tenons à remercier nos professeurs, notamment M. Merckle, notre tuteur, pour avoir répondu à nos différentes questions, pour nous avoir conseillé et guidé.
Tous les étudiants du GEII, en première année sont confronté à un challenge au cours de leur troisième semestre. Ils sont tenus de choisir un projet. Celui-ci doit être en lien avec le génie électrique, et plus précisément en adéquation avec l’option choisis en deuxième année. Dans notre cas il s’agit de l’option énergie renouvelable, et du projet intitulé : Gestion de la consommation d’énergie d’une maison. Nous devons réaliser ce projet dans le cadre du module « Études & Réalisations », dont la notation comprend plusieurs facteurs, bien entendu la réalisation du projet, la présentation de celui-ci (site web, video, powerpoint…), l’implication des différents membres, ainsi que le résultat final.
Le projet sera mené par Samba DIENG, ainsi que BOULBAIR Badr. Bien entendu avec le soutien des différents professeurs auxquels nous avons fait appel pour nous venir en aide, en particulier Mr. Djafar OULD ABDESLAM, et Mr. Mahfoud DROUAZ.
Dans l’UE1, un module est consacré aux énergies renouvelables. Ce module est composé de plusieurs matières, qui ont toutes été source d’inspiration, mais les matières suivantes ont eu un impact direct sur le projet : éolien, solaire, et smart grid. L’association de ces trois matières accompagnées d’une longue réflexion, nous ont mené à créer une maison autonome en énergie. Pour cela, nous avons commencé par créer notre maison, puis lui offrir les sources d’énergies suivantes : deux éoliennes, ainsi qu’un panneau solaire. Notre maison sera commandée par un Arduino que nous vous présenterons plus tard. Cet Arduino va en fonction de la production et de la consommation de la maison prendre différentes décisions, pour manager au mieux l’énergie. Avec notre maison il y aura une voiture électrique, qui est donc à même de se comporter comme une source d’énergie électrique, ou au contraire comme un appareil ménager à part entière qui doit être rechargé. Il y a trois grandes situations par lesquelles la maison passera : -1er Cas, le cas favorable: La production des énergies renouvelables est supérieure à la consommation des appareils électriques de la maison, dans ce cas l’Arduino va diriger le surplus d’énergie vers la batterie de la voiture. Dans le cas ou la batterie de la voiture est déjà chargée, le surplus sera revendu à EDF. -2eme cas, le cas neutre: Ce cas correspond à une production d’énergie tout juste suffisante à la consommation de la maison.
–3eme cas, le cas défavorable: Içi la production d’énergie est inférieure à la consommation de la maison, dans ce cas l’Arduino va ordonner à la batterie de la voiture de se comporter comme une source d’énergie supplémentaire. Si par malchance la batterie serait déchargée, la dernière alternative sera de consommer l’énergie fournie par EDF.
II) Cahier des charges:
A) Expression du besoin
Diagramme bête à corne : c’est un outil de représentation de questions fondamentales. (A qui rend-il service, sur quoi agit-il, dans quel but).
B) Fonctions et Contraintes Diagramme pieuvre : Le diagramme pieuvre (ou APTE) nous permet de répertorier toutes les fonctions de notre produit. En effet nous rappelons que lors de la conception, les techniciens chercheront pour chaque fonction à satisfaire, la meilleure solution. Et c’est l’ensemble des solutions qui donnera le produit final.
FP1:
Gestion de la consommation en fonction de la production d’énergie électrique de la maison
FP2:
Faire en sorte que la proportion d’énergie produite gaspiller sois la plus petite possible
FC1:
Le budget, une centaine d’euro prévu en fonction de l’ampleur du projet.
FC2:
Reproduire les charges existantes dans une vraie maison à l’échelle de la maquette.
FC3:
Le temps, 60h au semestre 3, et 45h au semestre 4.
FC4:
L’esthétique, la maison doit être fidèle a une vraie maison.
FC5:
La production d’énergie renouvelables en intérieur (maquette pas prévu pour l’extérieur).
III) Ressources
A)L’Arduino Yun
L’Arduino Yun est un microcontrôleur basé sur le processeur ATMEGA32U4 et un processeur additionnel Atheros AR9331, sur lequel tourne la distribution Linux OpenWrt wireless stack. Il est également composé de composants complémentaires qui facilitent la programmation et l’interfaçage avec d’autres circuits.Il possède un régulateur linéaire 5 V et 3,3V. Le module possède un port USB, et est programmé avec une liaison série TTL. C’est via cet Arduino que nous avons fait la gestion de l’énergie.
B)L’écran LCD
Cet écran va nous permettre d’afficher notre consommation, ainsi que notre production en temps réel. Le nom des broches et leurs utilités nous sont données sur l’image. Pour cela il va simplement falloir brancher l’Arduino à l’écran, et écrire un programme pour mesurer les consommations et productions. sur l’image ci-après on voit le schéma électrique contenant l’arduino et l’écran.
C) Les composants électriques pour gérer l’énergie.
Les LEDs, utilisé à leur juste valeur elle
représenterons, l’éclairage de la maison.
Les résistances, elles aurons pour but de dissiper l’énergie,
qui dit dissipation dit échauffement du composant. c’est cet
échauffement qui synthétisera le chauffage de la maison.
Les relais: Ces composants seront placés à certains endroits
bien précis du circuit. Ils vont commander chacun une charge
(chauffage, éclairage, cuisine etc…)
Le régulateur de tension LMZ14203, qui va ajuster
la tension d’entrée a la tension nominale des relais..
IV) Réalisation du projet
A) La maison
Nous avons commencé par le support le plus important du projet, il s’agit de la maison. Pour cela nous avons sur les conseils des professeurs, chercher des plan pour maison en 2D sur internet. Après quelques recherches, nous avons trouvé les plans de la maison actuelle. Nous avons utilisé la découpeuse laser dans le FabLab de l’IUT, pour créer notre maison, puis nous l’avons assemblée.
Le plan de la maison trouver sur internet :
Le matériau utilisé pour construire la maison:
Découpeuse laser, avec laquelle nous avons
couper les planches de bases:
Résultat après assemblage de la maison:
B) Les charges
Ceci étant fait nous sommes passés au gros du travail, c’est-à-dire l’établissement des solutions électriques de notre maison et des différentes charges de celle-ci. Nous voulions dans un premier temps placé des LEDs associé à des résistances, pour que la consommation dans chaque branche du circuit soit différente. Mais pendant le bilan des puissances, nous nous sommes rendu compte qu’il serait plus judicieux et plus réaliste de synthétisé des appareils électrique de quotidiens avec des composants électrique de base à disposition. Par exemples nous avons la simulé la voiture électrique par une simple batterie, l’éclairage de la maison sera simulé par les LEDs, le chauffage sera simulé par des résistances, et pour les charges restantes nous sommes encore en train de réfléchir lesquelles choisir. Les charges étant plus ou moins définie, il nous fallait maintenant de quoi les alimentés.
C) La production d’énergie
L’alimentation de la maison sera divisée en plusieurs parties, les éoliennes, le panneau solaire, ainsi que la batterie de la voiture électrique qui sera un générateur en fonction de la situation, et il y a quand même pour le cas le plus défavorable une part reliée à EDF. N’ayant pas trouvé de génératrice adéquates à nos éoliennes nous avons décidé de simulé la production de leurs énergie, et de les faire tourner avec des moteurs. Le panneau ayant des dimensions un peu plus grandes que notre maquette il produirais assez à lui tout seul (220V). C’est pour cette raison que nous diminuerons volontairement sa production. La batterie fournira 12V/1,2Ah (sauf dans le cas ou elle doit être rechargée). EDF sera simplement un générateur à part, qui compensera l’énergie manquante.
Voici le panneau solaire: Les deux éoliennes:
D) Management de l’énergie via l’Arduino
Maintenant que nous avons la production d’énergie, les charges qui consommerons cette énergie, il va nous falloir mettre en œuvre des programmes sur l’Arduino et des composants qui vont se chargé de commander le tout.
Le premier programme sera le programme pour afficher la production et la consommation pour savoir dans quelle configuration nous nous situons. Pour pouvoir les affichés il faut bien entendu recueillir ces informations. Pour cela nous avons fait une première carte composée de deux capteurs de courants, deux capteur de tensions, la multiplication d’une mesure courant/tension nous donnera une consommation en watts (U X I = P). Les informations recueillit par les capteurs serons traiter par l’Arduino via un programme. Ces information sont prise a des endroits bien précis du circuit.
Le deuxième programme sera le programme de commande des relais, ceux-ci vont laisser passé ou bloquer le courant qui passera dans une branche. Ces décisions seront prises par l’arduino, en fonction de la configuration dans laquelle on se trouve (voir les trois cas cités dans l’introduction).
E) Réalisations concrètes
1) Câblage des charges : Toutes les charges sont branchés en parallèle l’une par rapport a l’autre, ce choix a été fait pour éviter que si une des charges venaient à être court-circuitée, le reste du montage soit intacte. toutes les charges ont été divisées en plusieurs compartiments, alimentés indépendamment les uns des autres (mais les alimentations viennent toutes de la même source.
2)Réalisation de la carte à relais : Cette carte aura un bornier par compartiment, aux quel sera relier un relais (interrupteur) commander électriquement via l’arduino pour faire varier la consommation (tous les relais ouverts=consommation nulle/tous les relais fermés= consommation max). La carte sera alimenter par une alimentation externe, car nous avons rencontrés des problèmes avec le panneau solaire qui ne relevaient pas de nos compétences. Se trouve également sur la carte une régulateur de tension, car nous envisageons d’alimenter le montage avec une tension plus élever que celle suporter par les charges, afin d’avoir une tension de référence globale.
3) Programmation : Le programme a été conçu sur le logiciel Arduino, dans un langage très proche du C. Ce programme va donner les ordres au relais de s’ouvrir ou de se fermé en fonctions des situations décrient dans l’introduction (favorable, défavorable, juste suffisant). le programme est divisé en deux, la première partie vise à lire la production et la consommation, tandis que la seconde partie va faire en sorte ue l’Arduino prendra une désision en fonction de ce qu’il a lu dans la première partie du programme. En voici une petite partie :
V) Perspectives d’améliorations
Il aurait été plus qu’intéressant de se munir de vrai génératrices pour les éoliennes, plutôt que de simuler l’énergie produite par celles-ci. De ce fait le bilan des puissances n’est fiable que partiellement.
Les mesure de la consommation et de la production sont des mesures générales, autrement dis on mesure la consommation de toutes le charges simultanément, et nous mesurons la productions de toutes le sources de production de la même manière. Pour gagner en précision il aurais été plus efficace de mettre en place une mesure par charge, ainsi que une mesure par centre de production.
De l’amélioration précédente découle celle-ci, les mesures étant multipliées, il aurais été profitable de pouvoir toutes les visualiser. Pour ce faire nous aurions pu utiliser un écran plus sophistiqué avec un menu, pour pouvoir cibler les mesures a visualiser.
VI) Bilan/conclusion
Du point de vue organisation le projet s’est plus ou moins bien déroulé. En effet nous nous étions dirigés vers un tout autre projet, mais après étude de celui-ci, nous sommes rendu compte qu’il nétais pas viable. Après réflexion et étude du nouveau projet qui est celui que nous venons de vous présenter, nous avons pu améliorer l’organisation, partager le travail, et le découper en plusieurs parties bien distinctes. Néanmoins tout le travail n’a pas encore été effectué. Nous avons pu réaliser les différentes composantes du projet, mais nous n’avons pas pu les mettre en commun, et par conséquent voir un résultat final.
Ce projet à laissé libre-cours a notre imagination. Nous avons pu travailler en groupe et se coordonner, et même parfois s’appuyer sur les autres groupes qui avaient des parties en commun avec notre projet. Nous avons approfondis nos connaissances dans les matières concernant les énergies renouvelables, ainsi que l’électronique. Nous avons fait face à des problèmes techniques qui ont suscité cogitation et réflexion, afin de les résoudre. Sans oublier les professeurs Mr OULD-ABDESLAM, Mr DROUAZ, ainsi que Mr VIGNE, qui nous ont été d’une précieuse aide tout au long du projet. En conclusion les projets s’encre bien dans l’étude et la réalisation, il sont agréable, et permettent d’apprendre par la pratique, qui fait le lien entre les cours les travaux dirigés, et les travaux pratiques.
Nous sommes un groupe de 3 étudiants qui avons choisi en tant que projet de 2ème année DUT GEII de réaliser un programme capable d’assister un utilisateur de télescope dans le positionnement de sa monture. Nous avons travaillé pendant 2 semaines sur ce projet, de façon libre tout en aillant accès à l’aide de Mr. HAEBERLE si besoin.
L’utilisateur devra choisir via un clavier l’étoile qu’il cherche à observer, puis la date, l’heure et le lieu dans lequel il se trouve pour permettre au programme d’afficher via un écran LCD les instructions nécessaires au réglages du télescope, à savoir les degrés d’inclinaisons sur le plan vertical et horizontal. Nous équipons la monture de verniers afin de pouvoir placer ces 2 axes aux bonnes valeurs, manuellement.
Dans un second temps, nous pourront transformer ce système appelé « push-to » (c’est à dire que le système nous fournit les coordonnées mais nous devons déplacer manuellement la monture du télescope) en un système dit « go-to », en ajoutant sur la monture des moteurs commandés par le programme. Ainsi, l’utilisateur n’aura plus qu’à choisir l’étoile qu’il souhaite observer. La date, l’heure et le lieu seront récupérés via un module GPS, et la monture s’orientera d’elle même via les moteurs pour pointer l’étoile.
Afin de réaliser le programme de notre projet, il est nécessaire d’avoir des notions de base en astronomie sans lesquelles nous ne pouvons pas comprendre le sens des calculs à effectuer.
Mouvements permanent des astres et de la Terre.
Les astres tout comme la Terre sont en permanence en train de se déplacer. Ainsi, aucun des repères des calculs n’est fixe et donc il faut savoir s’adapter.
Nous nous sommes appuyés sur le rapport de stage final réalisé il y a plusieurs années (du 6 Mai au 10 Juin 2009) par un ancien étudiant GEII : BIEHLER Stéphane.
Son projet était le même que le notre, à la seule différence qu’il était seul pour le réaliser, mais l’a fait en plus d’un mois.
Ce rapport nous a aidés à comprendre les notions de base d’astronomie : la compréhension de la position et du déplacement d’un objet (une étoile, un astre) par rapport à la Terre et plus particulièrement par rapport à l’endroit où l’on se situe. Un objet est repéré par son ascension droite et sa déclinaison, qui se mesurent respectivement en Heure Minute Seconde, et en Degré Minute Seconde.
La contrainte de mouvements :
La Terre ne tourne pas sur elle-même en 24h exactement mais en 23h 56m 4.09s, ainsi une différence se creuse entre la position d’une étoile entre 2 journées pour une même heure. Pour cette raison, il nous faut passer sur un autre calendrier, le calendrier Julien. Le programme effectue la conversion, suite à quoi on pourra calculer le temps sidéral, car si on connait le temps sidéral et la position de l’observateur, ainsi que les coordonnées de référence de l’étoile à observer, on peut en ressortir l’azimut et l’altitude via les équations de Taki. Ce sont les 2 paramètres finaux que l’on cherche à avoir puisque avec ceux-là, on est capable d’orienter notre monture facilement dans la bonne direction.
L’objectif premier du projet est de créer un programme embarqué capable de donner à l’utilisateur des instructions simple (angle horizontal et vertical de sa monture) à mettre en place afin d’observer l’étoile souhaitée.
Il sera ensuite envisageable de réduire au maximum le rôle de l’observateur dans la mise en position de la monture de son télescope, tout d’abord en rajoutant un module GPS capable de récupérer le lieu, la date et l’heure. Ainsi, l’utilisateur n’a plus à rentrer ces paramètres, il n’a plus qu’à choisir l’étoile et ajuster manuellement sa monture.
La plus grande progression possible serait ensuite de transformer ce système push-to en un go-to, en ajoutant des moteurs sur la monture du télescope et des encodeurs sur les axes verticaux et horizontaux, afin que le système se rende automatiquement aux coordonnées d’azimut et d’altitude. Sur un tel système, l’utilisateur n’a plus qu’à sélectionner l’étoile qu’il désire observer. La monture dirigera d’elle même le télescope tel qu’on voit cette étoile en tout lieu, toute heure.
Nous avons programmé sur ce type de plaquette (PIC18F4520). La lecture des coordonnées d’instructions pour orienter correctement la monture se liront sur l’écran LCD, et les informations saisies par l’utilisateur (Date, heure, choix de l’étoile) se feront via un clavier matriciel de ce type raccordé à la plaquette :
On fait le jour julien -2451545 car le jour julien débute le 01/01/2000 à 12h ce qui correspond à la valeur 2451545.
Lorsqu’on aura calculer le temps sidéral en heure, il faudra ensuite convertir ce résultat en heures minutes secondes.
Pour avoir les heures :
heure=(TSMH/24)
floor : correspond à la partie entière de l’heure
TSMH=heure-floor (heure)
TSMH=TSMH*24;
sidereal.h=floor(TSMH);
car 24 heures dans 1 jour.
Pour avoir les minutes :
TSMH=TSMH-floor(TSMH)
TSMH=TSMH*60
sidereal.h=floor(TSMH);
car 60 minutes dans 1 heure.
Pour avoir les secondes :
TSMH=TSMH-floor(TSMH)
TSMH=TSMH*60
sidereal.h=floor(TSMH);
car 60 secondes dans 1 minute.
1.4 Angle horaire
On va passer des coordonnées équatoriales (julien/temps sidéral) en coordonnées horaires (déclinaison /angle horaire).
L’angle horaire permettra par la suite d’avoir l’azimut et l’altitude.
Ce calcul est simplement la soustraction au temps sidéral à Greenwich de la longitude de l’observateur et de l’ascension droite de l’objet à pointer.
Angle horaire= Temps sidéral – Longitude – Ascension droite
Rappel : On ne peut pas faire directement la soustraction, car degré minutes secondes différents d’heure minutes seconde.
Difficulté : Le plus dur dans cette étape est de réussir à convertir des heures minutes secondes, que sont l’ascension droite et le temps sidéral, en radians, et des degrés minutes secondes (longitude) en radians.
Pour réaliser cela on a fait appel à des fonctions pour convertir des degrés minutes secondes en radians, fonctions qu’on aura récupérées du programme de Biehler Stéphane.
1.5 Azimut et altitude.
Le passage de coordonnées horaire (déclinaison angle horaire) au coordonnées céleste (azimut altitude) se font par les équations de Taki.
Dans la première équation, Le, Me et Ne représentent des coordonnées intermédiaires.
H représente l’angle horaire préalablement calculé et δ représente la déclinaison de l’objet à pointer.
On multiplie ensuite la matrice obtenue par une matrice de cosinus et sinus pour obtenir de nouvelles coordonnées Lh, Mh, Nh qui vont servir au calcul de l’azimut et l’altitude.
Enfin, on utilise les coordonnées calculées précédemment pour obtenir l’azimut et l’altitude.
Une fois qu’on a l’altitude et l’azimut , on a juste à déplacer la monture de façon à bien placer la monture pour pouvoir par la suite regarder l’étoile que l’on souhaite.
Sur le PIC18f4520 :
1. Initialisation
Il faut réaliser les calculs sur le PIC18f4520, pour cela il faut mettre les stacks à 256 car on a des variables doubles (float) et réaliser des calculs si conséquents demande beaucoup de mémoire.
2. Conversion grégorien julien
Lorsqu’on a réalisé dans la première partie la conversion grégorien julien, il faut séparer pour la valeur final les entiers et les décimaux.
Voici les lignes de codes à modifier:
3. Utilisation de l’affichage LCD
Pour l’afficheur LCD, il faut utiliser la bibliothèque printlcd.
On y retrouve une fonction permettant d’écrire le contenu :
ECRIT_CHAINE_d( » A vaut : %d !! « , a) ;
Et une autre qui permet de l’afficher :
AFFICHE_TEXTE(1)
Avec cet exemple, on écrit sur la première ligne avec une seule variable.
Si on veut écrire sur la deuxième ligne avec deux variables :
ECRIT_CHAINE_2d(A : %d et B : %d « , a, b) ;
AFFICHE_TEXTE(2) ;
Pour l’instant, Ecrit_CHAINE ne prend en compte qu’une valeur de 3 chiffres maximum.
Pour obtenir des disques gradués de bonne dimensions, nous avons choisi de les dessiner nous-même via le logiciel CorelDraw afin de les réaliser via la découpeuse laser.
Nous avons commencé par dessiner le disque à placer sur l’axe azimutal, d’un diamètre de 32cm. Pour prendre en main le logiciel, nous avons d’abord copié une image de disque gradué existant que nous avons simplement étirée aux bonnes dimensions. Nous avons ensuite du améliorer ce disque en le perçant non plus juste au centre, mais aussi à des endroits bien précis pour laisser passer des vis (4 vis en tout, des trous de 1cm de diamètre). Une fois ces trous bien placés, le disque aux bonnes dimensions, nous nous sommes rendus compte que la précision des traits de l’image n’était pas satisfaisante. Ayant acquis une certaine expérience sur le logiciel, nous sommes maintenant capables de dessiner complètement le disque, en partant du centre pour tracer tout les traits de graduations des degrés (à partir d’une droite verticale, que l’on copie/colle en l’orientant à chaque fois d’un degré de plus que la précédente), ce que nous avons fait pour finalement imprimer la version finale.
Voici le disque gradué pour l’axe azimutal que nous avons réalisé:
Associé à ce disque, nous devons dessiner un pointeur afin de rendre le pointage plus précis. Pour se faire, nous avons du réfléchir à comment intégrer le pointeur sur la monture. Une fois la solution trouvée, nous l’avons dessiner puis imprimer au laser, comme pour le disque. Pour le pointeur nous avons dû palier au 2,5 cm de hauteur entre la base et le disque gradué. Nous avons coller entre elles 5 plaques de bois qui ont chacune 5 mm d’épaisseur qui épousait le disque tournant pour éviter que ça frotte lorsqu’on tourne le disque tournant.
Voici le pointeur que nous avons réalisé:
Rapporteur vertical avec son pointeur :
Même principe pour le disque de l’axe vertical, seulement c’est un demi-disque (90°), qui doit laisser passer des vis au niveau de son axe horizontal. Nous avons donc rajouter de la matière en bas à la manière d’un rapporteur, puis imprimer le disque au laser. Celui-ci étant plus petit, la solution de copier une image existante apporte une précision satisfaisante, il n’est pas nécessaire de redessiner complètement chaque trait pour chaque degré nous même.
Pour le pointeur de l’axe vertical, il y a eu un obstacle : le support qui permet de mettre une deuxième lunette.
Pour palier ce problème nous avons du tout d’abord faire deux disque plus petit car sinon ça touche le support puis nous avons fais un troisième disque qui est un peu plus haut pour être à la taille du rapporteur puis pour être pile au même endroit que le rapporteur.
Pour cela, nous avons coller entre elles 4 plaques de bois qui ont chacune 5 mm d’épaisseur. Le pointeur épouse la forme du rapporteur pour éviter tout frottement entre elle et le rapporteur.
Le troisième disque, et le pointeur pour l’axe vertical :
Passer d’un Push-to à un Go-to
Pour passez du mode push-to au mode go-to, nous devons utiliser un moteur pas à pas.
Pour utiliser un moteur pas à pas il faut utiliser un driver pour permettre de piloter le moteur. On pourra choisir ensuite par le biais du driver sa vitesse de rotation et le nombre de pas que l’on souhaite.
Enable: Logique Inversée, permet d’activer ou désactivé le moteur. Etat Haut=High=Moteur actif… et axe bloqué entre les pas. Etat bas=Low=Axe totalement libre
M0, M1, M2: Permet de sélectionner la configuration Step/MicroStep. Ces broches disposent de résistances Pull-Down ramenant le potentiel à 0v lorsque rien n’est connecté sur ces broches.
Reset: Logique inversée. Permet de faire une réinitialisation du module. Généralement connecté sur la broche « sleep »,
Sleep: Logique inversée. Généralement connecté sur la broche « Reset » du module.
Step: Envoyer un signal d’horloge (Niveau Haut puis Niveau bas, High puis Low) pour avancer le moteur d’un pas.
DIR: Permet d’indiquer la direction de rotation du moteur. Etat Haut=High pour tourner dans un sens, Etat bas=Low pour tourner dans l’autre sens.
VMot: Tension d’alimentation. On a utiliser pour cela une alimentation de 12 volts et un courant de 1 A car une bobine fait 500mA et il y a deux bobines donc 1 A
GND: Sous « VMOT », masse pour l’alimentation du moteur.
A1 A2: Première bobine du moteur pas à pas bipolaire
B1 B2: Deuxième bobine du moteur pas à pas bipolaire (voir exemple ci-dessous)
Tous les câbles que vous allez brancher sur Step,DIR,M0,M1,M2 vont allez sur le port C ce qui va permettre ensuite de contrôler le driver.
Lorsque vous allez alimenter le PIC il faut utiliser une capacité de 46 µF pour protéger le driver et un radiateur pour éviter qu’il ne chauffe trop rapidement.
Pour les moteurs pas à pas, nous avons branché tout ce qui contrôlait le driver sur le port C.
Pour faire fonctionner le moteur pas à pas il faut juste faire un front montant sur le RC0 qui est le step dans les branchements.
PORTCbits.RC0 =PORTCbits.RC0 ^ 1;
Ensuite si vous voulez changer la résolution du moteur pas à pas et passez de 1/1 à 1/32.
Il faut modifier la valeur avec laquelle vous avez branchés le M0,M1,M2 dans la phase d’initialisation.
Résolution de 1 pas :
Vous devez mettre les ports M0,M1,M2 à 0
PORTCbits.RC3= 0;
PORTCbits.RC4= 0;
PORTCbits.RC5= 0;
Résolution de 1/36 pas :
Vous devez mettre les ports M0,M1,M2 à 1
PORTCbits.RC3= 1;
PORTCbits.RC4= 1;
Nous avons réussi à faire un moteur qui va d’une position x a y en fonction du pas et du sens
Pour cela nous avons tout d’abord initialiser :
Azi = 0; Position que l’on souhaite atteindre
PosAct = 270; Position initiale du pointeur
pas = 360.0/200.0; Pas de 1
Tout d’abord nous avons regarder si la valeur de Azi étais supérieure ou inférieure à la valeur que l’on souhaite pointer.
Puis en fonction de cela nous avons choisi soit de tourner dans le sens trigonométrique soit dans le sens inverse.
Par exemple avec cette phase d’initialisation :
if (PosAct > Azi)
{
if ( (PosAct – Azi) >=180.0 )
{
PORTCbits.RC1 = 1; // sens +
x=2*(360-(PosAct-Azi))/pas;
for (j=0; j < floor(x) ; j++ )
{
WaitEvent(ALARM_EVENT0);
ClearEvent(ALARM_EVENT0);
PORTCbits.RC0 = PORTCbits.RC0 ^ 1;//inversion RC0
if (PORTCbits.RC0==1)
{
i++;
if (PosAct ==360.0) /* !!! */
{
PosAct = 0.0;
}
PosAct = PosAct + pas;
}
}
}
Donc nous allons tourner dans le sens trigonométrique car c’est plus rapide d’allez de 270° a 0° en allant du sens trigonométrique car il ne faut que 90° pour qu’il atteigne cette position, contre 270° dans le sens des aiguilles d’une montre, ce qui est très conséquent pour le driver et le moteur pas à pas car il chauffe assez rapidement, pour ensuite le faire en fonction des calculs que nous avons réalisés auparavant avec l’altitude et l’azimut qui permet de pointer la monture là où on le souhaite.
Nous prenons la partie entière du calcul soit pour l’azimut soit pour l’altitude et nous la remplaçons par Azi qui est la position que l’on souhaite atteindre et cela va permettre de faire bouger le moteur du nombre de pas que l’on souhaite
Perspectives d’évolution du projet
Tout d’abord, nous avons envisagé pour la partie calcul et l’affichage du menu de réaliser un bus I2C entre 2 microcontrôleurs dont 1 partie s’occupera de la partie calcul et une s’occupera de la partie menu car lorsque nous essayons de fusionner les 2 programmes , le microcontrôleur n’a pas la capacité de mémoire suffisante pour réaliser ces deux tâches.
Puis nous pourrons utiliser un module GPS qui permettra d’avoir directement l’heure et la date au lieu de laisser l’utilisateur les rentrer.
Maintenant qu’on a le programme pour faire tourner le moteur comme on veut en fonction des calculs, nous devons trouver une solution pour implémenter les moteurs sur la monture, c’est à dire trouver à quel endroit et comment les placer sur la monture.
Il faudra ensuite faire en sorte de rajouter des roues de bonnes dimensions pour entrainer les axes avec la rotation du moteur pour obtenir le bon degré de rotation.
Une fois toutes ces perspectives d’évolutions mises en place, nous aurons un vrai système go-to qui sera donc capable de pointer une étoile avec pour seul intervention de l’utilisateur le choix de cette étoile depuis un menu.
Bilan
Dans l’ensemble, la direction à donner au projet était claire, nous savions quoi faire et comment le faire. La grosse difficulté de ce projet était de se familiariser avec l’astronomie, un domaine complètement inconnu pour les 3 membres de notre groupe. Ensuite, le succès de notre projet résidait dans la programmation, de ce fait nous avons passer beaucoup de temps à bien comprendre et implémenter les différents calculs, puis la mise en place d’un clavier et de l’écran LCD pour afficher les résultats.
Ce projet nous a fait prendre conscience de la difficulté d’aborder un sujet complètement nouveau, malgré le fait que tout les calculs sont déjà faits, expliqués et publiés partout sur internet, on se rend compte que programmer un calcul sans le comprendre n’aboutit jamais.
Un des deux termes associés au système de coordonnées équatoriales avec la
déclinaison. Elle est l’équivalent sur la sphère céleste de la longitude terrestre. Tout comme la
longitude d’un lieu mesure l’angle entre le méridien de ce lieu et un méridien de référence appelé
aussi méridien principal, l’ascension droite d’un astre mesure l’angle entre le cercle horaire de cet
astre et un cercle horaire de référence. Le point vernal correspond au point de référence où l’angle
vaut zéro. (Exemple Nébuleuse du crabe M1 du catalogue de Messier: asc=5h 34m 31,97s) S’exprime
en radian. (1s d’ascension droite vaut 1/240 degrés et vaut 15s d’arc).
Déclinaison :
Un des deux termes associés au système de coordonnées équatoriales avec l’ascension
droite. C’est l’angle mesuré sur un cercle horaire entre un point de la sphère céleste et l’équateur
céleste. Elle est exprimé en degrés, minutes et secondes d’arc. (Exemple Nébuleuse du crabe M1 du
catalogue de Messier: D= +22° 00’52,1″ où les primes représentent respectivement les minutes et
les secondes d’arc) S’exprime en radian.
Calendrier Julien :
Il compte le nombre
de jour depuis la date de sa création il est donc très facile de connaître un intervalle de temps il
suffit simplement de soustraire ses date, alors qu’en calendrier Grégorien il faudrait faire attention
aux années bissextiles etc…
Temps sidéral :
Somme de l’ascension droite d’un astre et de sa déclinaison. Il mesure le déplacement de
la voûte céleste en un lieu donné par rapport au méridien local.
Azimut :
Axe horizontal autour duquel on tournera la monture du télescope.
Altitude :
Axe vertical autour duquel on tournera la monture du télescope.
Nous tenons à remercier notre enseignant Mr HAEBERLE de nous avoir accompagnés et conseillés durant ce projet, et pour nous avoir fourni les documents nécessaires à la réalisation du projet.
Le but de ce projet est de réaliser la construction et la programmation d’un robot Poppy. Ce dernier devra exécuter des mouvements basiques tels que : lever les bras, marcher, s’accroupir… Pour cela, la partie mécanique sera traitée par deux étudiants de Génie Mécanique (GMP). Elle consiste à la création de supports de maintien pour des batteries et à réadapter le centre d’équilibre du robot. En outre, la partie électrique sera traitée par trois étudiants de Génie Electrique (GEII). Elle consiste à la programmation du robot qui sera faite en langage Python via le notebook disponible sur l’interface web du robot. De plus, un circuit de batteries sera inséré dans le robot pour assurer une alimentation autonome de ce dernier.
Nos ambitions
Nous avons constaté lors de la construction du robot que le point d’équilibre de ce dernier n’est pas bien centré et donc il ne peut marcher tout seul sans tomber. De plus, avec son alimentation filaire sur secteur, le câble de liaison crée une instabilité supplémentaire. Nous avons donc l’ambition de lui permettre de se déplacer de manière autonome (c’est-à-dire de lui modifier son point d’équilibre afin qu’il puisse marcher sans accompagnateur et de lui implanter des batteries dans les jambes pour lui permettre de s’alimenter sans être connecté au réseau).
Notre équipe se fixe donc plusieurs objectifs mettant en lien diverses activités liant les domaines mécaniques, électriques et encore de la programmation.
Composition de l’équipe et le rôle de chacun
Nous sommes une équipe de 5 étudiants tous en formation apprentissage inscrits à l’IUT de Mulhouse. Elle se compose :
-2 GMP (Génie Mécanique et Productique) qui s’occupent de la partie conception/assemblage et de l’étude de l’implantation des batteries dans le robot et de la gestion du nouvel équilibrage de celui-ci.
-3 GEII (Génie Electrique et Informatique Industrielle) qui s’occupent de la partie programmation/codage et de la configuration des servomoteurs. Ainsi que de l’étude de l’alimentation du robot avec des batteries et prévoir le rechargement de celles-ci.
Bien entendu, il est évident que pour une meilleure progression du projet, la coopération est primordiale. La répartition des activités est variée en fonction des spécialités GEII et GMP des membres du groupe afin de garantir une certaine polyvalence et d’acquérir une expérience et des compétences pour chacun.
Nous avons précisé les activités réalisés ainsi que les ambitions futures dans le suivi d’avancement : Suivi d’avancement 27avril
Les GMP ont rendu un rapport vous permettant d’en savoir un peu plus sur leur activités : Rapport GMP
Caractéristiques du robot
Les caractéristiques principales du robot sont les suivantes:
Alimentation et interfaces de programmation:
– Alimentation: une moyenne de 13V
-Programmation: langage Python
-Interface: programmation via le notebook disponible sur l’interface web du robot
Caractéristiques principales du robot:
-Hauteur: 83 cm
-Poids: 3,5 kg
-Systèmes embarqués : Odroid XU4 avec Ubuntu 14.04
-25 moteurs
-Caméra HD et à grande profondeur de champ.
Cahier des charges
-Le montage du robot devra être exécuté selon les critères de conception indiqués par le constructeur dans la documentation technique fournie sur internet.
-La nouvelle structure des jambes du robot devra permettre l’amélioration de son centre de gravité.
-Une alimentation autonome devra être conçue et appropriée pour alimenter le robot.
-La programmation du robot devra être fait en langage Python via le notebook disponible sur l’interface web du robot.
2. Analyse fonctionnelle
II- Réalisation et programmation du robot Poppy
1.Assemblage du robot
Le montage du robot a été fait par l’ensemble de l’équipe du projet.
Ayant reçu le robot en pièces détachées, l’assemblage de ce dernier à pu se faire à l’aide de vidéos tutorielles trouvées sur YouTube (le lien dirige vers la chaîne de Matthieu Lapeyre, sa chaîne présente clairement et simplement toutes les vidéos nécessaires au montage du robot étapes par étapes : https://www.youtube.com/user/bizounours94/videos).
Lors du montage du robot il était impératif de suivre les recommandations de montage pour minimiser les problèmes liés aux moteurs. En effet, pendant cette période, nous avions aussi par la même occasion configuré les moteurs pour leur imposer une position initiale.
Robot en pièces détachées Robot assemblé
Lors de l’assemblage, nous devions faire attention à aligner le point du support moteur et le point sur l’axe du servomoteur. Si cela n’était pas respecté, la position zéro du moteur n’aurait pas été cohérente avec l’articulation du robot.
L’adressage des Dynamixel a été effectué sur Herborist pour les configurer et ainsi leur donner une position zéro et une adresse unique pour les différencier.
2.Programmation
La programmation du robot a été faite en langage python. De plus, les instructions ont été saisies via le notebook disponible sur l’interface web du robot.
Voici l’interface web du robot:
Le Robot est connecté sur le réseau en wifi, puis l’accès se fait via le logiciel Putty grâce à une connexion SSH.
Voici l’interface du logiciel Putty:
Position initiale
Sans un premier temps, nous avons codé les positions initiales du robot grâce à la fonction: set_goal_position({numéro du moteur: angle})
Position actuelle
Nous avons ensuite codé la fonction: get_present_position(dxl_io.scan([numéro du moteur]))
Cette fonction permet de connaître la position actuelle du moteur, et l’angle auquel il est référencé.
Nous pouvons voir tous les angles des moteurs à un moment T, qui sont représentés sur l’interface du logiciel Putty.
Positions « garde à vous » et « Accroupi »
Ces deux instructions lient plusieurs mouvements de plusieurs parties du corps.
Pour rendre les mouvements plus fluides et moins brutales, nous utilisons des boucles While, qui permettent un changement d’angle progressif. (le moteur bouge de 1° à chaque tour de boucle)
Les instructions à la fin du code servent à exécuter les différentes fonctions du programme.
3. Alimentation autonome
Pour créer une alimentation autonome, nous avons opté pour des batteries lithium-ion 18650. Celles-ci présentent un faible encombrement et leur coût est peu élevé.
Caractéristiques des batteries lithium-ion 18650 :
Nous avons branché les batteries de façon à avoir une alimentation d’environs 5A et ayant une tension d’environ 14V. Nous avons opté pour un régulateur de charge qui permettra l’alimentation du robot et la recharge des batteries.
Ce régulateur comme son nom l’indique va permettre de réguler la charge entre les 6 batteries ( 2×3 paires) qui composent une jambe.
Schéma électrique du régulateur :
Nous avons décidé d’intégrer les batteries de la manière suivante :
Par la suite, nous avons implanté le circuit de batteries dans les jambes du robot imprimées par les étudiants GMP.
III- Bilan du projet
Les difficultés rencontrées
Le projet a connu plusieurs retards et problèmes, de ce fait, nous n’avons pas eu l’opportunité de terminer le projet par manque de temps.
Les problèmes sont apparus durant les toutes premières séances du projet car le robot n’était pas encore livré. Nous avions donc uniquement les documentations trouvées sur internet (nombreuses et parfois incorrectes) pour débuter. Néanmoins, nous avons pu tirer quelques informations utiles tels que les 26 degrés de liberté (à titre de comparaison, le robot NAO en a 25), ainsi que de récupérer des modélisations du robot (CATIA 3D, Solidworks…) qui ont pu servir aux GMP.
De plus, le projet a été une découverte pour l’ensemble de notre groupe ainsi que pour le corps enseignant. Le système d’exploitation Linux ainsi que le codage en python étant nouveaux (ou vague) pour les membres du groupe, il était donc prévisible que le groupe connaisse des difficultés sur le projet.
Nous n’allons pas lister tous les problèmes que nous avons pu rencontrer car ces derniers sont cités plus haut dans le tableau d’avancement.
Résultats obtenus
A la fin de l’année, le montage du robot à pu être réalisé (hormis l’assemblage final de la tête, du au besoin d’accès de la carte pour la programmation du robot). Les nouvelles jambes du robot (avec leurs supports intégrés) ont pu être imprimées avec l’insertion des batteries dans ces dernières.
Pour la programmation, nous avons codé des mouvements de base tout en lui assurant une bonne stabilité. Malheureusement nous n’avons pas eu le temps de lui permettre marcher (le code étant très complexe à réaliser, car même le constructeur n’a pas pu nous le fournir).
Objectifs réalisés
√ -Montage du robot et vérification du bon fonctionnement des moteurs via herborist
√ -Réaliser la connexion robot/PC via le réseau de l’uha par ethernet et ainsi communiquer avec le robot
√ -Trouver des batteries adaptées aux besoins énergétiques du robot
√ -Permettre la recharge de ces batteries : créer un régulateur qui assurera la fonction sans endommager celles-ci (pour cela effectuer les recherches nécessaires à la conception et au fonctionnement d’un régulateur)
√-Tester le robot avec les fonctionnalités simples comme le » Garde à vous » et « Accroupi »
± -Implanter les batteries dans le robot et lui donner de l’autonomie (marcher sans aide, alimentation sans fil)
Conclusion
Ce projet nous a fait découvrir un peu plus en détail la robotique et la programmation, depuis sa conception jusqu’à coder ses mouvements. La collaboration avec les GMP a été enrichissante par le biais des transferts de connaissances et de par les relations amicales qui en ont résulté.
Le projet avec le robot NAO se décompose en deux parties.
La première consiste à aider lors de portes ouvertes ou lors de salons d’orientations (comme La journée des carrières à Mulhouse ou Le salon de l’emploi et de la formation à Colmar) les jeunes visiteurs à trouver une formation pour leurs poursuites d’études. Le robot appartenant au CFAU, il ne présentera en toute logique que les formations administrées par le CFAU. Comme son nom l’indique le CFAU, Centre de Formation d’Apprentis Universitaires, ne gère que des formations en université, allant du DUT au Master en passant par le DEUST(niveau bac+2) ou le Diplôme Supérieur de Comptabilité et de Gestion (niveau bac+5), soit plus de 111 formations en Alsace.
La seconde partie du projet consiste à déplacer NAO dans le bâtiment B du département GEII de l’IUT de Mulhouse afin qu’il puisse en faire une visite guidée. NAO, se déplaçant sur pieds, est trop lent. C’est pourquoi nous l’installons sur un autre robot à roues. Dans cette partie nous programmons donc deux robots différents, le NAO et un Robotino commandé par NAO. Cette partie n’a pas été menée à terme contrairement à la première.
-NAO est un robot constitué d’une multitude de capteurs, de moteurs et de logiciels pilotés par un système d’exploitation sur mesure : NAOqi OS.
-Il possède 25 degrés de liberté , et une centrale inertielle qui lui permet de garder son équilibre, de savoir s’il est debout ou couché.
-NAO est équipé de deux caméras qui filment son environnement et lui permettent reconnaître les formes et les objets.
-Il peut accéder à Internet de manière autonome, avec le Wifi ou en Ethernet.
-Il peut entendre et parler à l’aide de ses 4 micros directionnels et hauts-parleurs.
Et c’est avant tout cette dernière spécificité qui nous intéresse. En effet Nao doit pouvoir nous répondre lorsque l’on s’adresse à lui.
Chorégraphe
C’est à l’aide du logiciel Chorégraphe, développé par Aldebaran (société Française, à l’origine du robot NAO rachetée par SoftBank Robotics Europe en 2015), que l’on programme un robot NAO.
Environnement chorégraphe
Sur cette capture se trouvent tous les onglets nécessaires.
ProjectContent: On comprend naturellement que cet onglet concerne tous les fichiers qui sont utilisés pour le projet.
Box librairies : Cet onglet contient une multitude de fonctions réalisables par le NAO. Comme lui faire dire quelque chose, le faire marcher, se lever, allumer des voyants ou réaliser des calculs.
Root : Cet onglet présente une version graphique du programme de notre robot NAO. Un programme NAO est composé de box comme celles qui sont visibles sur la capture.Les box peuvent être:
Des « Diagram Box », c’est à dire une box contenant d’autres box.
Des « Python Box », contenant du code en python, puisque NAO interprète ce langage(ainsi que le C#).
Des « Timeline Box », permettant de programmer une série de mouvement du robot.
Des blocs de fonctions , ceux que l’on trouve dans l’onglet Box librairies.
Des « Dialog Box », permettant comme son nom l’indique de programmer des dialogues.
Log viewer : Cet onglet est comme un banquier, si il vient vers vous c’est rarement bon signe. C’est un onglet de débogage. Si une compilation échoue, c’est ici que vous verrez pourquoi. Il est explicite.
Daliog : Cet onglet permet de communiquer avec NAO. À son démarrage Chorégraphe lance un NAO virtuel. Évidemment celui-ci n’a pas de micro, alors pour dialoguer avec lui on utilise cet onglet. Cet onglet sera l’un des deux onglets les plus utilisé.
Robot view: Cet onglet permet de connaitre la position du robot (robot virtuel et véritable NAO). Il affiche aussi ce que dit le NAO.
Script Editor: Cet onglet permet d’éditer tous les fichiers sous forme de texte propres à Chorégraphe, tel que les codes de bloc fonctions, bloc python, et surtout les dialogues. Cet onglet sera le second onglet le plus utilisé.
Le programme actuel du Robot NAO est extrêmement simple puisqu’il n’est composé d’uniquement deux box et de deux liaisons. De plus il ne contient pour le moment qu’un seul fichier de dialogue. Il est possible que par la suite il y ai deux à trois « Dialog Box » supplémentaires. La box « Formation »(voir capture la capture d’écran qui suit) ne traite que les DUTs pour le moment. Peut être d’autres box serons utilisés pour les licences et les Masters.
Programme actuel du NAO
Création du dialogue
Pour la réalisation du dialogue, il est difficile d’imaginer la quantité d’information à traiter. A titre d’exemple, il n’y a que 16 DUTs en alternances contre 49 licences et 41 Masters. Et à l’heure actuelle le dialogue n’a été réalisé que pour les DUTs, ce qui représente tout de même une centaine d’échanges. En effet bien qu’il n’y ai que 16 DUTs, il faut trouver un moyen de les distinguer pour ne pas avoir à tous les énoncer d’un coup. Par exemple, j’ai pris comme critères « Industrie » (6 formations) , « Gestion »(5 formations), et « autre » ( 5 formations). Ainsi il n’y a que trois paragraphes principaux à générer. Ensuite on présente les formations par ville. Ce qui donne une sorte d’arborescence dans la conversation, comme vous pouvez le voir dans capture suivante:
Dans cet extrait apparaissent des tags sous la forme %NOM.Ces tags permettent le passage d’un niveau à l’autre de la conversation lorsqu’on ne suit pas un ordre « naturel ». J’entends par là, lorsque que notre interlocuteur souhaite finalement non plus parler d’industrie mais de gestion. Ou par la suite lorsqu’il voudra parler de licence plutôt que de DUT. Ces tags peuvent être rejoins à l’aide des commandes ^goto et ^gotoReactive . La première sert à rejoindre une partie du dialogue qui ne fait pas partie de son arborescence (Lorsqu’on parle de l’industrie puis on veut parler de gestion). La seconde sert a retourner à une partie du dialogue de son arborescence (un dialogue en u5 peut rejoindre un dialogue en u4 si ils descendent du même dialogue u3). Ces nuances sont probablement difficiles à saisir, mais elles se comprennent très naturellement dès lors qu’on les utilises.
Un dialogue comme celui-ci est très long à réaliser. Malgré tout, c’est une tâche réalisable car il n’ y a que 16 DUTs. (voici le dialogue DUT complet, Le texte étant brut, il n’a pas pour but d’être lu intégralement, mais de démontrer la difficulté à réaliser un dialogue).
En revanche, il y a 49 licences et 41 Masters. Pour les différencier, il faudrait étudier chaque intitulés de formations et compter le nombre d’occurrence des domaines. Un travail conséquent si il devait être réalisé à la main. C’est pourquoi des fonctions, puis finalement une application ont été développés pour accélérer l’étude des formations.
La version actuelle du programme, testable sur chorégraphe (version d’essai à télécharger là*) est disponible ici.
*Inscription nécessaire
II L’outil développé
Les formations et leurs intitulés sont visibles ici. Elles ont toutes été recopiés dans un fichier CSV que voici.
Ce format a été choisi car les formations sont sous forme de tableau sur le site du CFAU, de plus python comprend de base une librairie lui permettant de traiter ce type de fichier. Python est utilisé car NAO lui même utilise ce langage et les fonctions ont étés initialement écrites pour lui (mais cette stratégie a été abandonnée).
Le terme fonction est utilisé en langage C et est très parlant. C’est pourquoi je l’ai utilisé jusqu’à maintenant. Mais le vrai terme en python est méthode. La suite de ce document traitant de code python, nous n’utiliserons donc plus le terme fonction, mais bien méthode.
Les méthodes développées:
conversion (filenameSource,filenameDestination) : Elle permet de convertir un fichier CSV en fichier TXT
filtre (filenameDestination): Lors de la conversion, des caractères inutiles apparaissent , tel que « ; ». Cette fonction permet de les supprimer.
trie (string,filenameSource,filenameDestination): Lorsqu’on envoie une chaine de caractères à cette fonction, celle ci va chercher dans le fichier Source si pour chaque lignes (1 ligne = 1 formation) la chaine s’y trouve. Auquel cas, elle écrit dans le fichier Destination la ligne contenant la formation. En résumé cette fonction permet de trouver chaque formation contenant cette chaîne.
triebarre (string,filenameSource,filenameDestination): Cette méthode n’inscrit dans le fichier Destination que les lignes ne contenant pas la chaine de caractères, à l’inverse de trie.
copie (filenameSource,filenameDestination) : Cette méthode est appelée a la fin de trie et triebarre. Le fichier Source est écrasé pour être la copie du fichier Destination.
txtcount (filename): Cette méthode donne le nombre de ligne dans le fichier Destination après un trie ou triebarre.
csvcount (filename): Cette méthode donne le nombre de ligne dans le fichier « listedeformations.csv ». Ce nombre est nécessaire à la génération du premier fichier Source.
NbOccurence (string,filenameSource): Cette méthode permet de savoir combien de fois on retrouve la chaine envoyée dans un fichier source (à ce niveau fichier Source et Destination sont identiques). Sa fonction première est implémentée dans l’outil final. Mais cette méthode pourrait aussi être utilisée pour ne pas faire rater une recherche avec un mot qui ne serait pas présent dans le fichier CSV (imaginons qu’on envoie « sethdfv » à trie, alors les fichiers Source et Destination seraient vide). Ce n’est pas encore implémentée dans l’outil final.
Ainsi, si on appelle les méthodes trie ou triebarre plusieurs fois de suite (sans rappeler la fonction conversion entre temps) on peut trier le fichier d’origine avec plusieurs mots. A titre d’exemple, si on veux avoir tout les DUTs de l’industrie mais où il n’y pas d’informatique, on appellera deux fois la méthode trie et une fois triebarre ( l’ordre n’a aucune importance) et copie sera appelée 3 fois (la dernière ne servira que si l’on souhaite encore affiner la recherche avec un quatrième appel de trie ou triebarre). Il serait trop compliqué de réaliser une méthode réalisant le tout en une fois. Pour une nouvelle recherche, il suffit d’appeler conversion.
D’autres méthodes pour le traitement du document CSV ont étés développées. Mais n’étant pas gardées pour l’outil final, elles ne seront pas détaillées ici.
Un premier programme en version console
Ces codes ont été réalisés avec l’IDE Spyder. Spyder, avec un interpréteur, nous permet d’exécuter nos codes sans les compiler (comme on le ferait dans un autre langage), puis d’interagir avec, comme lui envoyer des mots. C’est très pratique.
Environnement Spyder : Sur la gauche , le code en python. Sur la droite, l’interpréteur avec qui on peut interagir
Mais dès lors qu’on désire effectuer de nombreuses recherches, interagir avec l’interpréteur n’est plus aussi pratique. Pour mieux comprendre, nous allons étudier la capture précédente.
Le code sur la gauche a été interprété (sorte de compilation ne générant pas de fichier .exe) après avoir pressé la touche F5 . Sur la partie de gauche est alors apparu dans le champencadré en rouge avec le terme « Critères : »
J’y ai écris « DUT » , ce qui a affiché le champ encadré en bleu. txtcount nous apprend qu’on a 16 formations répondants à ce critère.
Par la suite j’ai écrit « industrie ». Malheureusement ce mot s’écrit Industrie dans le fichier Source. Il n’a donc pas été trouvé dans le fichier, on obtient alors lechamp encadré en vert. Comme nous l’indique txtcount avec le 0, notre fichier destination est vide. Cette situation aurait pu être évitée en utilisant NbOccurence comme garde fou.
Le programme demande alors si on veut effectuer un nouvelle recherche comme on peut le voir dans le champ encadré en orange. Tant qu’on ne renvoie pas « NON » , une nouvelle recherche est lancée , mais en repartant depuis le début. C’est là qu’apparait la limite de la version « console » de ce programme. Dans ce cas ce n’est pas très grave puisque qu’un seul critères a été entré. En revanche si il avait fallu travailler sur les licences, plus de critères sont nécessaires, mais aussi plus de recherches différentes (plusieurs combinaisons différentes de mots).
Le champ encadré en mauve, montre simplement la même recherche sans erreur.
De manière générale ces méthodes sont très utiles , mais ne sont pas pratiques sous cette forme.
La solution pour rendre ce programme plus pratique a été de développer une interface graphique pour utiliser toutes ces méthodes.
J’ai choisi de travailler avec Tkinter, une librairie python permettant de programmer un environnement graphique. L’avantage est qu’il est aisé de trouver de nombreuses ressources sur cette librairie, et même en français.
Dans un premier temps, j’ai dessiné sur papier la disposition générale que je désirais pour mon application. Assez vite j’ai codé cette disposition avec Tkinter. L’application est découpée en 5 panneaux qui sont:
Parcourir ( ne fonctionne pas pour le moment) , permettra de choisir le fichier à analyser. Actuellement , l’adresse du fichier est inscrite dans le code du programme.
L’insertion des mots clés, où l’on précise si on doit garder ou supprimer les lignes contenants ces mots. Limité à 6 mots pour le moment.
L’affichage du fichier destination. Le panneau est actualisé à chaque nouvelle recherche
Nombre d’occurrences. On y inscrit les mots dont on veut connaitre le nombre d’occurrence.
Lancer la recherche qui permet de … lancer la recherche (si si).
Les fonctions des panneaux ont donc été codées après leur mise en place. Un panneau est traité après l’autre.
Voici le rendu actuel du programme :
Le programme m’a permit de trouver tout les DUTs touchants l’industrie, d’ignorer les licences (ce qui avait déjà été fait en ne gardant que les DUTs) et d’ignorer toutes les formations touchants la gestion.
L’écran principale nous apprend alors qu’on a 6 formations répondants à ces critères. Puis les affiches. Le panneau du milieu nous confirme bien que nous avons 6 DUTs , 6 qui touchent l’industrie , et aucun ne touchant la gestion ou le tourisme (ce qui me fait penser que certains étudiants en GEII n’ont pas été informés par un NAO bien programmé). Un bug apparait pour le Bac+2 , alors que « ac+2 » affiche bien 6 .
Le programme est actuellement très mal écrit. Prochainement il sera récrit. La fonction parcourir devrait fonctionner afin de pouvoir, pourquoi pas, traiter d’autres CSV, ou même des fichiers TXT ou XLS. J’essaierais aussi d’améliorer la disposition des panneaux. Mais avant tout ça, je me servirais de cet outil pour trier les formations en licence et en master afin d’adapter au mieux le dialogue du robot NAO.
Vous pouvez tester cet outil en téléchargeant cette archive. Vous y trouverez le code python ainsi que la liste des formations déjà donnée plus haut. Veillez à mettre Versionrapport.py et Listedesformations.csv dans le même répertoire.
À titre indicatif, cette application a permit le traitement des masters en moins de 5 minutes , hors rédaction du dialogue. La capture nous apprends que nous 3 master en industrie, 14 en « gestion » (dont 6 en gestion de projet), 22 en management, 5 en informatique, 7 en marketing, 6 en achats, 6 en chimie et 1 en journalisme.
il y a plus que 41 masters ici. Certaines formations traitent plusieurs domaines. Ainsi une formation peut être en gestion et en management (3 formations)
En appelant triebarre avec cette application , il n’en ressort aucun master : En traitant les masters avec les critères indiqués plus haut, on s’assure de n’en manquer aucun lors de la rédaction du dialogue (capture téléchargeable ici).
Cette capture nous confirme l’intérêt de traiter les masters avec ces critères
B PROJET : Déplacer Robotino avec NAO
I Le Robotino
Ses caractéristiques
Comme le robot NAO, Robotino est un robot pédagogique. Il est possible de le programmer de très nombreuses de manières comme en C, C++, Java, .Net, Matlab, LabVIEW et Microsoft Robotics Developer Studio. Pour ma part, j’ai utilisé un logiciel fourni par FESTO, l’entreprise ayant développée ce robot. Robotino est en open source. À la différence de NAO, Robotino se déplace sur roue et non sur pied.
Voici quelques-unes de ses caractéristiques qui me seront utiles :
Déplacement omnidirectionnel.
Capteurs de distance infrarouge.
Capteurs incrémentaux qui permettent de mesurer la vitesse de rotation réelle de chaque moteur.
Communication Wifi.
Peut porter jusqu’à 20 kg.
Présentation de Robotino-view
Il faut comprendre qu’avec Robotino-view, le programme n’est pas sur le Robotino mais bien sur un PC. Et c’est ce PC qui à l’aide d’une connexion WIFI (possible aussi en en filaire) envoi les commandes à Robotino. En revanche c’est bien le Robotino qui est le serveur dans cas. C’est-à-dire que c’est lui qui fournit une adresse IP au PC.
Voici une description de différentes options disponibles.
Lecture : Permet de démarrer le programme du Robotino sur le PC.
Connexion : Permet de se connecter à un Robotino pour lui transmettre les instructions.
GRAFCET : Permet d’organiser notre programme sous la forme d’un grafcet. Son usage est contre-intuitif. Je ne l’ai compris qu’au moment de rédiger ces lignes.
Progr / Step : Permet de savoir si le programme est en cours d’exécution, et dans quelle tâche avec un voyant vert. Selon le grafcet, plusieurs étapes peuvent êtres actives simultanément.
Les variables : Ce tableau affiche les variables disponibles dans le programme.
Robotino-SIM
De la même manière que l’on pouvait utiliser un NAO virtuel, il est possible d’utiliser un Robotino virtuel. À ceci prêt que cette fonction n’est pas intégrée au logiciel permettant de le programmer Robotino-view. Dans la capture d’écran de Robotino-View, dans le rectangle bleu on peut voir l’adresse suivante : « 127.0.0.1:8080 ».
« 127.0.0.1 » est en fait une carte réseau virtuelle et 8080 le port de communication utilisé sur cette carte. Ce sont ces coordonnées que l’on va utiliser pour se connecter au robot virtuel généré par Robotino-Sim.
Dans la vidéo qui suit vous pouvez voir le Robot en mouvement.
Ce robot virtuel a été très pratique pour travailler à la maison.
II Comment communique NAO avec Robotino ?
Le programme Robotino-view permet d’utiliser un ou plusieurs serveurs UDP .
Ces serveurs gèrent 2 « messages » :
– message 0
– message 1
Il faut comprendre « message » comme un canal.
Le message 0 permet la lecture de 8 sorties et l’écriture sur 8 entrées. Idem pour le message 1.
Tous les X temps (à définir dans la configuration du serveur) le serveur envoi aux adresses configurées les valeurs de ces sorties.
Dès que le serveur reçoit une trame sous la bonne forme, il écrit sur les entrées du message de destination.
L’idée est alors de demander au robot NAO d’envoyer une trame pour commander le Robotino. Mais Nao doit aussi considérer les informations envoyées par Robotino. Par exemple, dans mon programme Robotino-view je demande à ce que, dès que les capteurs du Robotino détectent un objet, Nao soit au courant afin qu’il adapte sa conduite.
Récupération d’une trame
À l’aide d’un petit code en python, téléchargeable ici, il est possible de récupérer une trame .
Pour expliquer le plus simplement ce code, le client UDP attend en permanence un message sur le socket* « monSocket ». Dès qu’un message est reçu il est encodé en HEXADÉCIMAL et affiché.
En HEXA signifie qu’il n’affichera que des caractères compris entre 0 et 9 et A et F. La trame, qui peut être vue comme une série de 0 et de 1, est découpée en octets.
*« Les sockets servent à communiquer entre deux hôtes appelés Client / Serveur à l’aide d’une adresse IP et d’un port […]; ces sockets permettront de gérer des flux entrant et sortant afin d’assurer une communication entre les deux (le client et le serveur) » explication obtenues à la page https://openclassrooms.com/courses/introduction-aux-sockets-1.
Explications : Admettons que mon client UDP reçoive «0010101100000111», en HEXA cela donne 2B 07. Seulement en ASCII 2B correspond à un + et 07 correspond à un « bip sonore ». Si + est bien un caractère affichable, ce n’est pas le cas du bip. En l’occurrence les trames émises par Robotino-view sont destinées à envoyer des nombres et non des chaînes de caractères. Alors si on n’encode pas la trame, l’interpréteur python tentera d’afficher des caractères.
Dans la vidéo qui suit vous verrez la récupération une trame. Par la suite l’interpréterai.
Tout d’abord quelques explications.
Sur la partie gauche de la vidéo vous voyez la « console » de l’interpréteur python. C’est là que ce sont affichées les trames encodées en HEXA.
Sur la partie droite vous voyez une partie du logiciel Robotino-view ainsi que la fenêtre de commande du serveur UDP. On y voit bien que le serveur s’adresse au port 9180 de l’adresse 127.0.0.1. Sans ça, le client UDP n’aurait rien reçu.
00 : C’est l’ID du message (le « canal »). Ici il vaut 0.
2400 : C’est le nombre d’octet qui compose la trame. En HEXA ce devrait valoir : 9216. Pourtant il est évidant que si l’on regarde la trame indiquée plus haut on est loin de cette valeur. En vérité on est à 36 octets. Pour mieux comprendre il faut revenir sur le tableau sur les INT32. En fait le byte 0 (octet 0) est le byte de poids faible. Autrement dit, il faut lire non pas 24 00 mais 00 24, ce qui en base dix donne 2*16 + 4 = 36.
ab : C’est la somme de contrôle. Elle est égale à la somme de tous les octets composant la trame.
La somme de contrôle s’obtient en faisant : 255 – la somme de tous les octets de la trame.
Mais 1364 ne tiens pas sur un octet (qui peut valoir 255 max). Il faut alors faire 1364 % 256 = 84.
(256 car un octet peut valoir de 0 à 255, soit 256 valeurs possibles).
Et 255-84 = 171.
Cet octet, ainsi que le nombre d’octet dans la trame sont des outils pour tester l’intégrité de la trame.
Les octets suivant contiennent les valeurs lues sur les sorties INT0 à INT7 du message 0. Ici il s’agit de INT32 signés. C’est à dire que la valeur max est de 2^31 soit 2 147 483 648. Le bit de poids fort indiquant le signe de la valeur.
Voici une formule pour calculer facilement la valeur un INTX :
Si l’on regarde le bit de poids fort du INT5, on constate qu’il vaut 1 ( 255 en base 10 = 1111 1111 en base 2). Les nombres étant codés en complément à 2*, cela qui veut que dire c’est un entier négatif.
*C’est écrit nulle-part dans Robotino-view, c’est une conclusion que j’ai dû tirer moi même.
On peut obtenir sa valeur de deux façons différentes .
L’autre solution est de rester en base 10 et de faire :
A= (255 *256^3 + 255*256^2 +253*256 + 68) -256^4
A= -700
Maintenant nous savons lire une trame à la main, nous pouvons donc gérer théoriquement une communication de Robotino vers NAO et inversement. Mais il faut encore pouvoir automatiser l’écriture et la lecture de ces trames.
Lire automatiquement une trame reçue
J’ai écrit une méthode qui ne permet que de lire qu’un INTX à la fois, après réception d’une trame.
C’est la méthode Conversion_en_INT(String_a_Massacrer, int_a_retourner)
La méthode Conversion_en_INT demande comme argument la chaine que l’on veut étudier (que l’on a obtenue avec un client UDP) et surtout quel INTX on souhaite lire.
Afin de ne pas surcharger le Word press, vous trouverez un code python commenté ici de cette méthode.
Je propose de tester cette méthode.
J’utilise un nouveau code python, téléchargeable ici, qui me permet d’utiliser un client UDP qui appellera en boucle la méthode Conversion_en_INT(String_a_Massacrer,int_a_retourner) afin de lire les 8 INTX fournies par le message 0 et les 8 INTX fournies par le message 1.
Dans la vidéo suivante vous verrez le code en application:
Dans la partie de droite, on voit un programme Robotino-view qui écrit sur les entrées 0 à 7 du message 0, pareil pour le message 1. Les valeurs utilisées ont été notées au hasard.
Sur la partie gauche de la vidéo vous retrouverez ces mêmes valeurs suite à l’interprétation de la trame faite par ma méthode. Je prends le soin d’analyser l’ID du message.
Écrire « automatiquement » une trame
Cette méthode prend en argument 8 valeurs : l’ID des messages et les valeurs que l’on souhaite écrire pour INT0 à INT 7. Voici le prototype : ConversionUdp(ID_Message, int0,int1,int2,int3,int4,int5,int6,int7)
Là aussi, pour ne pas surcharger le WordPress, je vous propose de lire la méthode commentée, téléchargeable ici .
Dans la vidéo suivante vous verrez un code avec, téléchargeable ici, en application:
Je commence par envoyer la trame qui a été écrite dans la méthode commentée plus haut. On peut voir dans Robotino-view que les entrées prennent bien les valeurs désirées.
Ensuite le programme python s’arrête durant 4 secondes. Puis on envoie la trame qui a été écrite juste avant par la méthode ConversionUdp(1,0,0,0,0,0,0,0,0).
Nous maitrisons maintenant parfaitement l’envoi et la réception de ces trames. Nous pouvons commander le Robotino et Robotino peut envoyer les informations nécessaires, sous forme d’entier.
Code de déplacement
Je propose maintenant l’automatisation une tâche : La recherche d’un mur.
Ce ne sera pas UN programme, mais deux programmes qui communiquent l’un avec l’autre.
L’un est fait avec Robotino-view, l’autre avec Spyder en python.
Je vais commencer par présenter le programme sous Robotino-view.
Tout d’abord, voici son GRAFCET :
Il existe deux façons de faire se déplacer Robotino :
-Soit on lui indique une vitesse. En mm par seconde pour un déplacement verticale ou horizontale. En degré par seconde pour un déplacement angulaire => Ce sera fait avec la tâche « Step1 »
-Soit on lui indique une coordonnée en mm ou en degré. => Ce sera fait avec la tâche « Step2 »
Step1
Pour passer d’une étape à l’autre j’écris dans une variable « Changement_d_etape ».
C’est l’entrainement omnidirectionnel. C’est lui qui envoi les consignes aux 3 moteurs de Robotino.
La consigne de déplacement sur l’axe de X proviendra de INT0 du message 0.
La consigne de déplacement sur l’axe de Y proviendra de INT1 du message 0.
La consigne de déplacement angulaire proviendra de INT2 du message 0.
C’est la variable qui me permet de passer de STEP1 vers STEP2 (et inversement).
Elle sera affectée par INT3 du message 0.
Cette entrée INT5 du message 0 me permet d’activer le frein des moteurs.
Cette partie est un peu plus complexe.
Ceci est le capteur infrarouge 4. Dès qu’il voit un obstacle, il renvoi une valeur entre 0 et 2.54. S’il revoie 2.54 c’est que le capteur IR4 est presque au contact de l’obstacle.
Plutôt que de travailler sur une plage de 0 à 2.54. Je décide de traiter cette information sur une page de 0 à 100 qui est plus intuitive. Dès que mon capteur renvoi une information > 30% de 2.54, alors j’entre un 1 dans un sommateur.
Voici le sommateur. Le résultat obtenu est écrit dans INT0 du message 1.
C’est ainsi que je peux savoir si mon Robotino voit un mur ou obstacle à une distance que je considère suffisante.
Cette partie etait destinée à être optimisée. L’idée est de multiplier la sortie du comparateur du capteur 2 par 10, du capteur 3 par 100(pour le capteur 3), etc, jusqu’au capteur 9 par 100000000. Ainsi, on pourra manipuler la , à l’aide de modulo et de soustraction, la valeur lue dans INT0 du message 1 afin de déterminer précisément quel capteur voit un obstacle.
Si mon capteur infrarouge 1 voit un obstacle, j’écris dans INT1 du message 1.
J’ai besoin de cette information indépendamment de celles autres capteurs dans mon programme en python.
En résumé, STEP1 me permet de donner une vitesse de déplacement à Robotino, et de savoir s’il détecte un obstacle.
Step2
Cette fonction est un « parcoureur de position ». Il permet de parcourir une distance pour atteindre une coordonnée qu’on lui aurait donné en consigne. Il envoie les ordres de déplacement aux moteurs en fonction de la distance parcourue. Cette information il obtient à partir à partir de la fonction « odométrie ».
On envoie la consigne de distance sur l’axe des X avec l’entrée INT0 du message 0.
On envoie la consigne de distance sur l’axe des Y avec l’entrée INT1 du message 0.
On envoie la consigne d’angle avec l’entrée INT2 du message 0.
Curieusement dès qu’on envoie une distance à parcourir sur l’axe des X ou des Y, la fonction « parcoureur de position » s’exécute de suite. En revanche, si on veut parcourir un nouvel angle, il faut un front descendant sur cette entrée.On réalise ce front avec l’entrée INT4 du message 0.
Voici la fonction « Odométrie ». Avant de savoir quelle distance on a parcourue il faut lui donner un point de référence.
Pour ma part j’ai configuré les valeurs suivantes :
-0 en X.
-0 en Y.
-0 en degré.
Dès lors que l’on veut redéfinir un point de référence, il faut faire un front montant sur cette entrée. On réalise ce front avec l’entrée INT5 du message 0.
Ces deux fonctions méritent d’être illustrées par un exemple :
Disons que les positions de référence valent :
-> 25 en X.
->-72 en Y.
-> 0 en degré.
Maintenant disons que je donne en consigne au « parcoureur de position » :
-> -27 en X.
-> 257 en Y.
->15 en degré.
Robotino ne parcourra pas :
-> -27 en X.
-> 257 en Y.
->15 en degré.
Mais il parcoura :
-> (-27) – (25) = -52 en X.
->-257 – (-72) = 329 en Y.
-> 15 – 0= 15 en degré.
En réinitialisant systématiquement le point de référence à {0,0,0}. Ce « parcoureur de position » devient un « parcoureur de distance », bien plus pratique pour mon application.
Le capteur IR1 envoie une valeur comprise entre 0 et 2.54. Mais les entrées/sorties du serveur UDP ne traitent que des entiers.
Ce qui réduit beaucoup la précision du capteur puisque qu’on ne pourrait lire 0,1 ,et 2 si l’on le connectait directement à la sortie INT1 du message 1. En multipliant la sortie du capteur par 100, on peut écrire 255 valeurs sur la sortie INT1 du message1.
En résumé, STEP2 permet de faire parcourir une distance à Robotino et de lire les informations fournies par le capteur IR1.
Le programme Python
Dans l’image qui suit, vous voyez la disposition des capteurs à infrarouge (IRx) autour de Robotino. Je précise que la notion d’avant et arrière est arbitraire. Pour moi l’avant de Robotino est au niveau de IR1.
Le code que je vous présente (il ne sera pas détaillé comme les codes) n’est pas exécuté à partir d’un NAO, mais toujours depuis l’IDE Spyder.
# Le programme de Robotino-view doit être à l’étape Step1.
Au moment de démarrer le Robotino, celui-ci est incapable de savoir où il est.
J’envoie donc une trame au serveur UDP de Robotino-view. Celle-ci permet de dire à Robotino de reculer jusqu’à ce que n’importe lequel de ses capteurs à infrarouge détecte un mur. Le code python est en attente d’une trame qui l’informera quand les capteurs voient un mur : INT0 du message 1 > 0.
Le serveur UDP envoie en permanence des trames. Le programme python étant incapable de savoir laquelle contient l’information qu’il lui faut, il les scrute toutes.
Lorsque le programme python lit que INT0 du message 1 > 0, il active le frein des moteurs en envoyant une trame contenant INT5 du message 0 = 1.
Je demande alors à Robotino de tourner, jusqu’à ce que ce soit son capteur IR1 qui voit le mur. Le programme python attend alors une trame contenant INT1 du message 1 > 0.
Évidemment si le capteur IR1 voit déjà un mur, cette étape est passée instantanément.
Ensuite le programme python envoie une trame pour que le programme de Robotino-view passe à l’étape Step2. Ceci se fait en envoyant 2 sur l’entrée INT5 du message 0.
# Le programme de Robotino-view doit être à l’étape Step2.
L’objectif ici est de trouver la position optimum, pour que le capteur IR1 soit « en face » du mur. Je demande à Robotino de tourner de 3 degrés et de relever la valeur lue par le capteur IR1. Plus IR1 se rapproche du mur, plus la valeur qu’il lit est élevée. Le programme python compare toute ces valeurs. Dès que IR1 renvoie une valeur plus faible que la précédente, c’est qu’il s’éloigne du mur : La position optimum est passée. On retourne alors dans la position précédente.
Dans la vidéo qui suit, vous verrez les programmes communiqués, et le Robotino virtuel se déplacer en conséquence.
Il faut maintenant exécuter ce code non plus depuis l’IDE Spyder, mais depuis NAO.
On va commencer par enregistrer les méthodes développées (lecture et écriture de trame) dans fichier python. Pour ce faire on créer un fichier python « Robotino ». Le fichier python est téléchargeable ici.
On prend le soin de le mettre à la racine de projet NAO.
Ensuite on créer un block python qui sera lancé au démarrage.
Par la suite on importera ces méthodes dans les « python block », avec la commande :
from robotino import*
Malheureusement pour moi, je n’ai pas pu terminer mon projet. La suite ne présentera donc qu’une ébauche de programme.
Le fonctionnement est le suivant :
Au démarrage on lance le chargement du fichier python contenant les méthodes développées. Ensuite on active la caméra qui se situe dans la bouche du NAO et on active la reconnaissance des NAOMARKS(exemple visible sur l’image suivante).
Les valeurs lues par la caméra rentrent dans un switch case. En fonction du résultat on active la box « Com_simple », ou la box « STOP ».
-> « Com_simple » demande à Robotino de reculer jusqu’à ce qu’il voie un mur. Tourne jusqu’à ce que IR1 voit le mur. Et on active « Com_simple_2», qui sert à obtenir l’angle optimum. Les résultats de Com_simple2 ne sont pas probant, je n’ai pas trouvé les raisons.
-> « STOP » envoie une trame pour retourner à l’étape Step1 et remettre toutes les valeurs à 0.
Voici une vidéo où le NAO virtuel commande le Robotino virtuel.
Conclusion :
Si je suis satisfait de certain résultats obtenus comme la maitrise des trames ou la communication entre les robots, je reste déçu de ne pas avoir réussis à atteindre les objectifs fixés. Peut-être étaient-ils trop ambitieux pour mes compétences.
J’ai dans l’espoir que les ressources que je laisse seront assez lisibles pour de futurs utilisateurs, ou qu’au moins ils puissent s’aider des informations misa à disposition sur cette page.
La présentation du projet est terminée. Merci de votre attention.
Pour finir cette page, je vous présente le groupe à l’origine de ce projet : Le mononôme Alexandre Ribault.
La distribution du travail s’est faite de la façon suivante, pour une répartition juste et équitable de la charge de travail:
1. Présentation générale du projet
1.1 L’impression 3D
1.2 Cahier des charges
1.3 Gestion des tâches et du temps
1.4 Coût du projet
2. Recherche d’une solution
2.1 Analyse du système
2.2 Le Raspberry Pi 3
2.3 MQTT
2.4 Solution mécanique
3. Réalisation
3.1 Programmation
3.2 Réalisation des supports
Conclusion
Introduction :
Nous sommes actuellement en deuxième année de DUT Génie Electrique et Informatique Industrielle à l’IUT de Mulhouse et nous avons réalisé ce projet en collaboration avec deux étudiants en Génie Mécanique et Productique. Nous avons choisi la surveillance de l’imprimante 3D, en effet, l’impression 3D est une technologie pour le futur. Ainsi, de plus en plus de particulier possède une imprimante 3D et la surveillance du bon déroulement de l’impression à distance est susceptible d’intéresser un bon nombre de personnes.
La vision est un outil en plein développement au sein de l’industrie mais également chez les particuliers. Nous allons donc réaliser la supervision de l’impression d’une imprimante 3D située au sein du Département Génie Mécanique de l’IUT de Mulhouse. Cette supervision permettra de vérifier le bon fonctionnement de l’imprimante grâce à une image, si nous avons un défaut nous pourrons arrêter l’impression à distance.
Pour vous expliquer en détail le déroulement de ce projet, nous allons dans un premier temps réaliser une présentation générale du projet, puis nous allons vous exposer les solutions que nous avons proposé pour mener le projet à son terme. Ensuite, nous allons vous présentez la solution que nous avons mis en œuvre. Et pour finir, nous conclurons sur ce que nous à apporter ce projet.
1. Présentation générale du projet
Dans cette première partie nous expliquerons tout d’abord le principe de l’impression 3D, puis nous définirons le cahier des charges. Ensuite nous montrerons notre répartition des tâches et pour finir nous définirons le coût du projet.
1.1 L’impression 3D
L’impression 3D est un procédé qui permet de fabriquer des pièces en volume. Cela permet de réaliser un objet réel à partir d’un logiciel de conception assistée par ordinateur (CAO). Sur ce logiciel nous réalisons une pièce en 3 dimensions qui sera ensuite traitée par un logiciel qui organise le découpage en différentes couches nécessaires à la réalisation de la pièce.
Sur l’image ci dessus on retrouve le fichier avant l’impression et on retrouve le résultat après l’impression 3D. Il existe de nombreux types d’imprimante 3D avec une très large gamme de prix, ceci allant de l’imprimante basique pour un particulier à une imprimante complexe pour un industriel.
1.2 Cahier des charges
La surveillance de l’imprimante 3D est nécessaire pour les enseignants du département Génie Mécanique et Productique. En effet, certaines impressions peuvent durer plus de 24 heures et sont donc lancer le week-end. Cependant sans surveillance l’imprimante peut avoir un défaut et ne s’arrêtera pas. Une impression de 24 h raté engendre une perte de temps et de matière conséquente.
Définition du besoin
Fonction principale et contraintes
Fonctions
Critères
Niveaux/flexibilité
FP1 : Permettre la vision à distance afin de garantir le bon déroulement du procédé de fabrication
Fonctionnalité
Vision depuis une connexion internet
Microprocesseur
Marche/arrêt, lumière
Serveur MQTT
Rapsberry Pi 3
FC1 : Garantir une vision du procédé de fabrication
Qualité de l’image
Positionnement de la caméra
Résolution minimum 240p
Réglable
FC2 : résister au milieu extérieur
Vibrations,
chocs
Utilisation courante
FC3 : S’adapter à l’imprimante 3D
Type d’accroche
Ergonomie
Visser dans le carter de l’imprimante
Réglable/montable par l’utilisateur
FC4 : Garantir l’alimentation de la caméra
Electricité
Connexion internet
230V 50hz (secteur)
Wi-Fi ou RJ45
1.3 Gestion des tâches et du temps
En bleu : tâches des étudiants en GEII En vert : tâches des étudiants en GMP
1.4 Coût du projet au niveau électrique
Matériel à commander
Fournisseur
Références
Quantité à commander
Prix
Raspberry Pi3
Raspberry
RASPBERRY-PI-3B
1
40 €
Alimentation 5 V 3A
1
10 €
Câble Ethernet
5m
5 €
Caméra LOGITECH C170
Logitech
PN 960-001066
1
25 €
Servomoteur HS- 422 HITEC
Hitec
MRC-HS311VR
1
10 €
2. Recherche d’une solution
Dans cette seconde partie nous vous présenterons tout d’abord une analyse du système, puis le Raspberry Pi 3 et MQTT que nous allons utilisée. Et pour finir nous verrons la solution que nous avons trouvé au niveau mécanique.
2.1 Analyse du système
Tout d’abord rappelons que l’imprimante 3D fonctionne à une température ambiante d’environ 70°C. L’installation de la caméra peut se faire de deux façons différentes :
Insérer la caméra dans l’imprimante et mettre en place un système de ventilation
Positionner la caméra à l’extérieur de l’imprimante
Nous avons conserver la deuxième solution, c’est à dire de positionner la caméra à l’extérieur de l’imprimante. En effet, une caméra supportant une telle température serait trop coûteuse et de plus la mise en place de ce système de ventilation serait bien trop compliqué.
Nous avons donc choisie l’emplacement de la caméra mais il faut également prévoir le système permettant d’arrêter l’impression et d’ allumer la lumière.
Ainsi nous avons pu remarquer que les boutons de commande sont câblés à travers une nappe. Cette nappe est ensuite insérer dans un connecteur qui lui-même est soudé sur une carte électronique. Il n’est pas possible de reprendre le câblage des boutons poussoirs.
Sur la première image ci contre on aperçoit la sortie des boutons sur la carte électronique.
Et sur les deux boutons suivants, on aperçoit la nappe de sortie des boutons poussoirs. Il faut donc trouver un système qui permettra d’appuyer physiquement sur les boutons poussoirs.
2.2 Le Raspberry Pi 3
Le Raspberry Pi est un nano ordinateur de la taille d’une carte de crédit. Il fonctionne avec différentes versions du systèmes d’exploitations Linux, en effet, la plus utilisée est Raspbian. Le Raspberry Pi ne comporte pas d’alimentation, clavier, souris ou écran. On retrouve sur un aperçu du Raspberry Pi 3.
Comme on peut le voir sur l’image ci dessus, le Raspberry Pi 3 comporte 3 Ports USB et une prise Ethernet. On peut voir qu’il dispose également de ports GPIO qui peuvent être utilisés comme entrée/sortie. Il est également équipé d’une carte Wifi et du Bluetooth.
Ce Raspberry Pi 3 comporte donc parfaitement à nos besoins, il nous permettra tout d’abord de pouvoir branché une caméra à travers le port USB. Nous pourrons gérer des entrée et des sorties à travers les ports GPIO. Et de plus nous pourrons nous connecter à internet et au réseau de l’UHA grâce à la prise Ethernet ou à la carte Wifi.
2.3 MQTT
MQTT : Message Queuing Telemetry Transport
MQTT est une protocole de messagerie qui fonctionne sur le principe de subscriber / publisher qui a été développé pour simplifier la communication entre les machines. Il est basé sur le protocole TCP/IP. C’est un protocole très léger, de ce fait, nous pouvons envoyer des messages qui ne dépassent pas 256 Mo. Ceci est également un avantage, ce qui en fait un des protocoles de communication du « futur ». En effet, une partie d’application Messenger de Facebook utilise le protocole MQTT. Nous allons vous illustrer le fonctionnement avec le schéma suivant.
Nous retrouvons donc les subscriber et les publisher. Cependant nous avons un également le broker MQTT, c’est un serveur qui permettra de faire passer les messages entre les différents clients.
Un subscriber (souscripteur) souscrit à un ‘topic’. Ce topic sera alors ouvert dans le serveur. Ensuite le publisher (publieur) publiera dans le même topic que celui du subscriber et celui-ci réceptionnera le message.
Nous avons donc une communication entre les différents composants, mais tout le monde pourrait accéder au contenu qui passe par le broker MQTT.
En efet, nous pouvons sécurisé la communication du protocole MQTT. Dans un premier temps nous pouvons définir qui a le droit de publier sur le topic mais également ceux qui ont le droit de s’y abonner.
De plus nous avons un autre aspect de sécurité, c’est le Quality of Service pour les messages :
QoS niveau 0 : le message sera délivré une fois sans garantie de réception et ne sera pas sauvegardé sur le serveur ;
QoS niveau 1 : le message sera livré au moins une fois jusqu’à la réception d’un accusé de réception de la part du broker MQTT ;
QoS niveau 2 : le message sera renvoyé puis sauvegardé tant que le récepteur n’aura pas répondu.
A présent nous avons éclaircie le fonctionnement du protocole de communication MQTT. Cela a été difficile pour notre groupe d’intégrer ces notions du fait que nous n’avions jamais travaillé dans ce domaine de l’Internet of Things (IOT).
2.4 Solution mécanique
Nous avons donc réalisé une représentation du panneau de contrôle de l’imprimante sous créo.
Quelques modifications ont été apportés au moteur afin de pouvoir l’adapter à l’imprimante. Il a été nécessaire de réaliser une nouvelle came pour celui-ci afin de pouvoir atteindre les boutons du panneau de l’imprimante grâce à deux tiges de pression.
De ce fait, nous avons repris la base de la came initialement prévue puis créé une plus large qui nous a permis d’y insérer 2 boutons poussoir sous forme de vis pour exercer la pression sur les boutons. Avant la réalisation de cette came, nous avons donc réalisé un prototype sur créeo en récupérant l’entraxe entre les deux boutons de l’imprimante.
Came moteur :
L’objectif de cette partie est donc de détailler comment nous avons imaginé le système pour qu’il soit le mieux adapter au système.
Dans un premier temps il serait intéressant d’observer notre base de travail pour cette partie.
L’objectif de ce système était qu’il soit adaptable tant au niveau de la caméra que du cerveau moteur. Nous réalisé un montage sur créo pour observer la mise en place du système. Néanmoins, il manque la partie « bras et support de caméra » et la représentation des tige filetés permettant de régler la distance du cerveau moteur.
Pour cela, nous avons réalisé un système permettant de gérer par système de coulissement la position de notre caméra et de notre cerveau moteur. Le fait de pouvoir régler la caméra en hauteur nous permet d’anticiper la fabrication des pièces dans l’enceinte de l’imprimante car plus les pièces sont importantes en volume, plus il y aura des variations de hauteur du plateau.
Système de coulissement :
Cette partie est assez simple d’utilisation et de fabrication. Nous avons utilisé une tige de diamètre 15 et réalisé un méplat sur celle-ci pour la bloquer en rotation dans nos guides. Un système de vis de pression est utilisé d’une part pour bloquer notre tige dans les guides et ce même système est utilisé pour bloquer nos composants sur cette tige. Nous avons donc utilisé une tige en acier comportant la contrainte de poids mais néanmoins reste plus solide pour appliquer une pression avec les vis. Toutes les autres pièces sont donc usinées ou découper dans l’aluminium ou dans le plastique pour des raisons de légèreté.
Support cerveau moteur :
La plaque du cerveau moteur a donc une double fonction, d’une part la fixation du servomoteur et d’autre part elle permet la liaison entre le serve et le système de mise en position.
Pour la partie servomoteur, nous avions à disposition un moteur fourni par monsieur Chassignet. De ce fait, pour éviter les dépenses extérieures, nous avons réalisé un support adapté à ce moteur. Pour cela, nous avons récupéré les côtes de celui-ci (largeur du moteur, entraxe entre les alésages prévu pour la fixation) pour que l’on puisse l’insérer et le fixer sur le support.
La fonction de liaison entre le support came et le système de mise en position est réalisable par l’intermédiaire de 2 tiges filetées de diamètre 6 et d’un système d’écrou contre écrou.
Pièce liaison système coulissant et support cerveau :
Cette pièce sert à effectuer la liaison entre les deux parties du système. Nous retrouvons le diamètre 16 de notre basse et les deux tarauds M6 pour nos tiges filetés. Pour régler cette pièce en position, un système de vis de pression a été réalisé sur le diamètre 16.
L’ensemble de cette pièce est réalisable en découpe jet d’eau pour un gain de temps. Néanmoins les tarauds et les alésages sont à réaliser sur une perceuse à colonne.
Bras de réglage de la caméra :
Notre caméra sera maintenue à l’aide d’une pièce support réalisé par impression 3D qui se pince sur le bras de positionnement de la caméra.
Celui-ci s’adaptera au bâti de notre système de fixation qui sera directement ancré sur le profil de l’imprimante.
Ce bras permettra le réglage de la caméra en hauteur et en profondeur afin de pouvoir garantir le meilleur champ de vision pour surveiller les impressions en cours. Celui-ci se compose du tube ci-contre qui prend place sur le bâti du système et d’un simple tube cintré à 90°, coulissant dans le premier et situer grâce à une goupille sur lequel viens se pincer le support ci dessus.
3. Réalisation
3.1 Programmation
Afin de réaliser ce projet nous utilisons donc le protocole de communication MQTT. A travers nos différentes recherches sur celui-ci nous avons pu remarquer que le langage de programmation de plus utilisée est le langage Python. C’est un langage de programmation très puissant qui nous permettra de réaliser notre partie de programmation.
Tout d’abord nous avons dû installé une caméra sur le Raspberry, ainsi le but de cette première partie aura été de pouvoir capturé une image tout simplement. Pour cela nous avons tout d’abord utilisé une webcam de la marque Logitech.
Cette caméra Logitech présentant un bon rapport qualité/prix nous a tout de suite intéressé, en effet nous ne cherchions à avoir une caméra simple mais avec une bonne qualité de photo.
De ce fait il a tout d’abord fallu autoriser l’utilisation d’une caméra sur le Raspberry. Cela nous a donc permis de générer un code Python permettant de prendre une image de la webcam et de la lire.
Nous pouvons retrouvez ci dessous le code permettant de capturer une image.
On retrouve une première où l’on capture l’image, une deuxième phase où l’on compresse l’image sous le format JPEG et enfin une phase où nous enregistrons l’image dans le même dossier que le code mais où nous chargeons l’image avant l’envoi.
Afin de réaliser ces différentes phases nous avons utilisé la librairie open-cv de python.
A présent nous il faut comprendre comment programmé la communication en MQTT. Tout d’abord nous cherchons à mettre en place un client dans le protocole MQTT. Pour cela nous utiliserons l’application MQTT Snooper.
Cette application Android permettra d’envoyer des messages sur un topic, par exemple « projiut/snap ». Nous pourrons alors envoyé un message qui servira d’ordre au Raspberry.
Cependant ce message doit être lue par le Raspberry et après avoir lu le message le Raspberry doit exécuté une tâche qui est par exemple la capture d’une image.
Afin de faire transiter les différents messages nous utilisons le serveur de test « test.mosquitto.org ». Celui -i nous permettra d’envoyer es ordres sur le Raspberry. Cependant pour renvoyer l’image nous ne pourrons utiliser cette solution.
En effet le serveur de test serait accessible à tout le monde et ce n’est pas ce qui est voulu. De plus nous n’avons pas la possibilité d’ouvrir un port sur le réseau de l’UHA, ceci engendrerait la mise en place d’un protocole de sécurité trop important pour la réalisation de ce petit projet.
Nous avons donc décidé de renvoyer l’image à travers la messagerie Gmail. On retrouve le code python permet d’envoyer un mail ci dessous.
Ainsi lors de l’envoi d’un message sur le topic, nous capturerons une image puis nous enverrons celle-ci sur une adresse mail prédéfini. Une amélioration de ce système pourrait être que lors de l’utilisateur pourrait envoyer son adresse mail pour qu’on puisse envoyer à plusieurs utilisateurs.
Nous avons donc réalisé la partie acquisition et transmission de l’image. Il faut à présent gérer la partie commande du servomoteur. Le servomoteur présentera deux états, tout d’abord nous aurons un mouvement qui allumera la lumière pour la prise de la photo dans l’imprimante et enfin nous aurons un mouvement qui permettra d’arrêter l’impression.
Pour cela nous avons utilisé le code suivant :
Afin de commander le servomoteur nous lui envoyons des impulsions ce qui lui permet dans une position. Pour cela nous définissons un angle dans lequel le servomoteur doit se positionner.
Ci dessous nous retrouvons le schéma général de notre installation.
De plus vous pouvez retrouvez l’ensemble du code python ici.
Au cours de cette partie de programmation nous avons rencontrées de nombreuses difficultés puisque pour nous le Raspberry pi et le langage python n’étaient pas familier. De plus la mise en place de MQTT sur python a été la partie la plus difficile.
3.2 Réalisation des supports
Une fois toutes les pièces réalisées, nous avons donc pu faire l’assemblage du système où nous retrouvons les différents composants tels que :
Conclusion
Ce projet a été une expérience enrichissante du fait de la collaboration avec les étudiants du département Génie Mécanique et Productique mais également parce que nous avons acquis des connaissances très importantes dans le domaine de l’IOT. Ainsi nous maîtrisons à présent le langage python mais également le Raspberry Pi qui est un outils indispensable.
Le découverte du protocole MQTT est une véritable car en effet c’est un protocole très simple d’utilisation qui peut être mis en place d’un point de vue industriel mais également chez un particulier.*
Le système électrique avec le Raspberry Pi et la caméra fonctionne cependant la partie mécanique n’a pas été réalisé donc notre projet n’a pas pu être finalisé, c’est un point que nous regrettons puisque nous aurions apprécier voir l’aboutissement de notre travail.
Nous tenons à remercier Mr. CUDEL et Mr. VIGNE qui nous ont assistés et conseillés tout au long de notre projet. Nous tenons également à les remercier pour les connaissances qu’ils ont pu nous transmettre dans la gestion de projets.
Le projet FESTO consiste à automatiser entièrement une chaîne de montage. Nous avons choisi ce projet car il nous place dans une situation réelle qui pourrait être croisé en entreprise. Cela nous permet d’avoir un ancrage bien réel dans le monde industriel en plus du fait que l’on soit en apprentissage. Grâce à cela on pourra étoffer nos connaissances dans le domaine de l’automatisme industriel.
III/ Présentation
A/ Présentation du projet
Le projet a pour but d’automatiser la chaîne FESTO séparée en six modules allant du poste de distribution au poste de stockage, en une chaîne de production entière en ajoutant des éléments permettant de suivre et de simplifier la production. Deux types de pièces seront traités, les pièces noires, et les pièces blanches.
Les fonctions d’automatisme sont gérées par des automates S7-1214 du constructeur Siemens.
Architecture du réseau
B/ Poste de distribution
Ce poste permet d’alimenter pièce par pièce le système de fabrication. Les pièces proviennent d’un conteneur cylindrique. Elles tombent dans une cavité. Un capteur permet de détecter la présence d’une pièce ou non. Un vérin extrait la pièce de la chambre afin qu’un bras oscillant équipé d’une ventouse transfère la pièce vers le poste de mesure.
C/ Poste de mesure
Ce poste permet de tester certaines caractéristiques physiques des pièces issues du poste de distribution. Suite à ce test, les pièces dont la hauteur est trop haute sont mises à l’écart alors que les pièces validées sont envoyées vers le poste d’usinage.
D/ Poste d’usinage
Ce poste permet de simuler l’usinage des pièces. Il est composé de trois fonctions distinctes :
Un palpeur qui nous permet de détecter le fait que la pièce soit pleine ou non
Un taraudage qui simule l’usinage de la pièce
Une éjection qui transmet la pièce usinée vers le poste de placement
Ces trois fonctions peuvent être commandées simultanément et les pièces sont conduites d’une fonction à l’autre à l’aide d’un plateau tournant indexé.
E/ Poste de placement
Ce poste permet de placer des bouchons sur les pièces. Il est composé d’un tapis roulant qui permet de transférer les pièces, d’une butée qui permet d’arrêter les pièces devant le mécanisme de placement des thermomètres. Un effet venturi appliqué sur une ventouse permet alors de prendre un thermomètre, placé sur une rampe, et de l’insérer dans une pièce. A l’issue de ce placement la pièce poursuit son chemin sur le tapis roulant vers le poste de transfert.
F/ Poste de transfert
Ce poste permet de transférer les pièces issues du poste de placement vers le poste de stockage. Un capteur permet de détecter la présence d’une pièce à gauche. La pince pneumatique saisit alors la pièce et la transfère vers la droite. Une goulotte en position centrale peut servir de zone tampon lorsque les magasins de la zone de stockage sont pleins.
G/ Poste de stockage
Ce poste permet de stocker les pièces en fonction de leur couleur à la fin du processus de fabrication. Les pièces sont amenées par un tapis roulant. Deux capteurs sont utilisés, l’un permet de différencier la couleur de la pièce et l’autre sa matière tandis que deux aiguillages pneumatiques permettent de les faire glisser dans des compartiments différents.
IV/ Etude
A/ Analyse Fonctionnelle
1. Bête à corne
2. Diagramme Pieuvre
FP 1 : Automatiser la chaîne de production
FP 2 : Suivre la production de pièces
FC 1 : Interface de commande ergonomique pour l’utilisateur
FC 2 : Maintenance aisée en cas de défaut du système
FC 3 : L’opérateur doit être en sécurité lorsqu’il intervient sur la chaîne
FP : Fonction Principale & FC : Fonction Contrainte
3. Diagramme FAST (Function analysis system technique)
La technologie RFID (radio frequency identification) :
Cette technologie permet une mise en place de la traçabilité dans la production. Les pièces seront marquées en amont de la chaîne de production, on pourra y lire la date de début de production et la commande à laquelle cette pièce se réfère. La pièce sera lue et une nouvelle fois marquée en sortie de production. La durée de production, ainsi que le temps de traitement de la commande pourront être déterminé pour optimiser le temps de production.
Module de liaison des têtes de lecture/écriture RF180C/RF120C
Tête de lecture/écriture
RF310R
La technologie Code barre :
Cette technologie permet une mise en place d’un système de commande utilisé pour lancer la production d’un nombre précis de pièce pour un certain client. On se sert d’un lecteur de code barre utilisant une liaison RS232 et d’un module de liaison série pour communiquer avec l’automate.
Ce code barre permettra de déterminer le marquage qui sera inscrit dans le tag RFID.
Module liaison série RS232 CM1241
La supervision de la production (IHM) :
La supervision permet à l’opérateur d’avoir une vision globale de la production permettant d’agir en cas de défaillance du système. On utilisera des SIMATIC Touch Panel comme interfaçage pour la chaîne de production.
IHM
Simatic Touch Panel
B/ Planning
On a établit un planning estimatif en différenciant toutes les tâches à réaliser pour mener à termes notre projet. Le planning est évolutif et est donc mise à jour régulièrement.
Des données vont devoir être transmises entre les automates afin d’assurer un fonctionnement convenable lors de l’assemblage de la chaîne de production.
Résumé des transits de données entre les automates des postes
D/ Lancement d’un cycle de production
Le départ du cycle de production est décidé par un code barre qui contient toutes les informations nécessaires à la réalisation de la commande émise par un client.
Il a fallu déterminer quel codage était utilisé pour pouvoir créer des codes-barres qui sont propres à ce que l’on souhaite.
Grâce à différents essais on a identifié le codage comme étant de l’EAN (European Article Numbering) qui est utilisé par le commerce et dans l’industrie. Nous avons opté pour un code barre utilisant le codage EAN 13, qui nous donne accès à 12 caractères changeables à notre guise et un bit de contrôle.
Suite à cela, nous avons pensé à une trame pour nos codes-barres qui contiendrait toutes les informations qui nous sont nécessaires.
La trame doit contenir : le numéro de client, la quantité de pièces pour notre premier type de pièces, le type de la première pièce, la quantité pour notre second type de pièces, le type de la seconde pièce.
Le type de pièce 1 correspond à des pièces blanches et le type 2 correspond à des pièces noires.
Exemple d’un code barre généré pour correspondre à nos attentes
E/ Plan de programmation
Un plan de programmation est défini pour avoir une programmation claire et distincte sur tous les postes.
On commence par l’élaboration d’un grafcet et on définit une architecture sur la quelle on peut se référer lors de la programmation des postes, ceci permet de simplifier les éventuels modifications en vue de dépannage.
Grafcet réalisé pour la programmation du poste d’usinage
Grafcet de conduite
Grafcet de tâche du perçage
Grafcet de tâche du palpage
Grafcet de tâche de l’éjection
F/ Schématisation de l’IHM
On réalise des schémas de chaque sous-système pour faciliter la supervision de la production. De plus, une vue sera faite pour contrôler la gestion de la production, les caractéristiques de la commande en cours, la gestion du stock ainsi que le temps qui a été mis pour compléter la commande.
G/ Conclusion à mi-parcours
Nous avons séparé le projet en deux grandes parties. La partie Etude qui consiste à se familiariser avec le projet, les technologies utilisées ainsi que tout ce qui touche à la gestion de projet. La seconde concerne la Réalisation. Elle consiste à programmer chaque poste ainsi que chaque IHM.
Nous arrivons presque à la fin de l’étude puisque nous nous sommes habitués aux technologies RFID et code barre, malgré quelques difficultés liées à l’écriture ou à la lecture sur le tag RFID dût à la programmation et au milieu où l’on souhaite agir sur nos tags. De plus, il nous reste à terminer la schématisation des interfaces graphiques pour nous mettre en accord sur les informations qui sont à mettre en avant ainsi que la façon dont elles seront mises en avant.
Nous aborderons la réalisation, dès que l’étude sera terminé. Nous commencerons dans un premier temps par programmer tout les postes indépendamment en incluant nos données qui devront s’échanger entre les automates. Puis, nous nous occuperons de la partie interface pour le suivi de la production.
Toutefois, notre projet peut être amélioré. En effet, nous avons pensé, dans la mesure du possible, à rajouter des éléments nous permettant de nous rapprocher d’un fonctionnement industriel. Ainsi, nous pouvons éventuellement intégrer un bouton d’arrêt d’urgence général qui nous permettrait d’arrêter le système entier en cas de défaillance, un mode de marche manuel qui serait piloté par l’IHM.
V/ Réalisation
A/ La séparation des tâches
La réalisation est séparée en différentes tâches. Dans un premier temps il a fallu programmer chaque poste. Cette tâche a été séparé afin que chacun d’entre nous puisse programmer les automates. Suite à cela, il restait deux points à abordés, la mise en place de la communication entre automate afin d’échanger les différentes variables permettant le transit des pièces à produire, qui a été réalisé par Romain, ainsi que la supervision du système de production, réalisée par Jocelyn.
B/ La programmation des postes
Nous avons réalisé les grafcets de chaque poste pendant la partie étude du projet (voir partie IV sous-partie E). Nous avons donc programmé chaque poste selon le/les grafcets réalisés.
Nous avons suivi une architecture commune pour la programmation de chaque poste.
Exemple d’architecture des blocs d’un programme API
C/ La communication entre automate
La communication entre automate consistait à faire se connecter chaque automate entre eux afin de bloquer les sous-systèmes si un de ces derniers est bloqué et qu’il ne peut prendre une pièce, on obtient alors un blocage du système en attendant l’acheminement de la pièce bloquante pour continuer son fonctionnement normal. On utilise pour cela un bloc de donnée et des variables pour gérer l’acceptation des pièce de chaque poste (voir partie IV sous-partie C)
Exemple d’un bloc fonction « GET » qui permet de chercher des variables dans un autre automate
Exemple de tableau crée pour l’échange de donnée
D/ La supervision
Nous avons créer une vue par sous-systèmes le tout centralisé sur un seul IHM, à cela nous avons ajouté une vue permettant de voir les information contenu dans le code-barre qui a été scanné et une vue pour la lecture du tag RFID. Nous avons donc huit vues possibles.
Vue de l’IHM permettant la lecture du code-barre et le départ cycle
Vue de l’IHM permettant la lecture du tag RFID
Vue du suivi du fonctionnement du poste mesure
VI/ Conclusion générale
Nous avons choisi de réaliser ce projet car nous souhaitions une situation se rapprochant le plus de la réalité
Ce projet nous a permis de revoir certaines notions abordées en cours d’automatisme et de supervision telles que :
Langage LADDER ou langage à contacts
Le grafcet de production normale et de conduite
Identifications des adresses entre les esclaves et l’automate.
La mise en place de la supervision d’un système
De plus, cette expérience a pu nous faire découvrir le domaine de la gestion de projet et d’aborder des connaissances comme les diagrammes de GANTT, les différents outils utilisés dans le cahier des charges comme la bête à corne, la pieuvre ou encore le FAST.
Nous avons eu l’occasion d’approfondir nos connaissances dans l’environnement logiciel du logiciel SIEMENS TIA PORTAL permettant de programmer les automates S7-1200 qui ont été abordé durant les travaux pratiques d’automatismes durant les semestres 2 et 3.
Nous tenons à remercier monsieur VIGNE et monsieur CUDEL qui nous ont suivis et consacrés leurs temps à nous aider durant ce projet.
L’origine du projet de drone est née lors de la première réunion GEII/GMP. Ayant tous un intérêt commun pour les drones, notre groupe s’est formé naturellement. Cette innovation au cœur des sujets d’actualité technologique embarque de l’électronique ainsi que de la mécanique. Pour ne pas faire un simple drone, nous avons décidé d’y ajouter une autre technologie à la mode : la réalité augmentée. Elle offrira au pilote une expérience de vol immersive en vue à la première personne (FPV, First Person Viewer). Le drone sera équipé d’une caméra dont le retour vidéo se fera sur smartphone. Il sera placé dans un casque de réalité augmentée type cardboard, qui sera adapté par nos soins pour accueillir les équipement nécessaires.
II. Les premiers pas
1.La gestion du Projet
Il nous semble nécessaire de faire une parenthèse sur l’organisation du projet suite à la coopération GEII/GMP. La première contrainte est la communication, donc nous avons mis en œuvre une solution. Pour un bon suivi du projet et une bonne organisation, un outil de gestion de projet a été mis en place dès la première séance. Celui-ci se nomme Propulse et se révèle être très complet. Il propose la création de tâche avec la possibilité de les affecter aux membres du projet. L’avancement est régulièrement mise à jour par le responsable de la tâche. Une description peut être ajoutée pour savoir exactement de celle-ci.
L’outil dispose aussi d’une partie « Wiki » ou nous pouvons partager toutes sortes de documents et y rédiger des notes.
2. Analyse fonctionnelle
3. Définition des limites du projet, réalisation du cahier des charges
Divers et varié sont les drones que nous trouvons actuellement sur le marché. Petit, moyen, grand, drone de course ou drone pour la prise de vue, nous avons dû faire un choix. Le budget étant limité et restreint, le choix d’un drone pour la prise de vue ne répondait pas à ce critère étant donnée les coûts onéreux d’une bonne caméra.
Nous voulions un drone unique, tout droit sorti de notre imagination. L’impression 3D est la technologie parfaite pour répondre à ce critère. Nous avons ensuite réfléchis aux autres problématiques que nous allions rencontrer et ainsi établir le cahier des charges suivant :
Fonctions
Critères
Niveau
Flexibilité
FP1 : Vol en immersion
Temps de vol
5 minutes minimum
F0
Portée du drone
Respect de la loi, le drone doit être garder en visuel
F0
Retour vidéo fiable
Pas de perte du signal vidéo
F1
FC1: Châssis ergonomique
Dimensions
20×20 cm maximum, taille du plateau de l’imprimante 3D
F0
Solidité
Choix d’un matériaux résistant
F0
Sécurité et protection de l’appareil
Armature permettant la préservation des hélices et des composants
F0
Pratique et optimisé
Placement des composants sans problème de place
F1
FC2: Alimentation
Alimentation côté drone
Alimentation 12V, capacité importante
F0
Alimentation côté retour vidéo
Alimentation 12V, capacité suffisante pour une session de vol
F1
FC3: Stabilisation
Quadricoptère
Réglage des moteurs 2 à 2
F1
Répartition du poids
De manière homogène de façon à ne pas provoquer de déséquilibre
F2
4. [Drone] – Choix des composants : Comment et Pourquoi ?
Châssis
Très vite, nous avions a cœur de concevoir et réaliser notre propre châssis en impression 3D. À la vue des caractéristiques de l’imprimante, nous devions faire un drone occupant un volume de 20cm3 comme précédemment indiqué dans le cahier des charges.
Ce fût le premier critère déterminant pour la suite. Il fera donc l’objet d’une partie à lui seul dans la suite du rapport.
Contrôleur de vol
Ce composant a été de loin le plus simple a choisir. Le contrôleur de vol est la carte mère du drone, le modèle NAZE 32, est un des plus réputé et des plus utilisé. Il permet d’embarquer une caméra et est très modulable en fonction des options voulues. Nous pouvons ajouter toute sorte de capteur télémétrique permettant de la prise de donnée dans des endroits inaccessible.
Moteurs
Le premier composant que nous avons choisis était les moteurs. En effet, la taille des moteurs doit correspondre à la taille du drone, nous avons donc fait nos recherches afin de comprendre comment nous devions choisir les moteurs.
Suivant les caractéristiques des moteurs que nous utiliserons nous serons capables de soulever un certain poids pendant un temps donné.
Plusieurs paramètres sont à prendre en compte. Chaque moteur ont une grandeur (le KV). Il s’agit du nombre de rotations par minute du moteur pour 1 volt. De manière générale, plus un moteur tourne vite moins il a de couple, et inversement. Un moteur avec un KV bas, pourra donc supporter de plus grandes hélices qu’un moteur à KV élevé. Un KV élevé est idéal pour une conduite réactive et nerveuse, un KV bas est idéal pour plus de stabilité. Pour un drone qualifié de mini quadricopter (environ 500g) le KV idéal est aux alentours de 2300.
Hélices
Les hélices sont choisies en fonction des moteurs. L’idéal dans notre cas est donc hélices 5“.
Nous pouvons ensuite nous poser la question du nombre de pale : Bipale ou Tripale ?
La différence est assez simple, si on augmente le nombre de pale, la portance et la réactivité de la machine seront améliorées. C’est un aspect avant tout bénéfique, mais il y a aussi un inconvénient de taille qui se trouve être la consommation en énergie. En effet, une hélice tripale va nécessiter beaucoup plus d’énergie qu’une hélice bipale. Notre priorité sera de privilégier l’autonomie du drone, d’où le choix des hélices bipales
ESC
Les ESC (Electronic Speed Controller) sont des composants électroniques qui servent de variateurs et permettent de réguler la vitesse des moteurs. Les ESC reçoivent une valeur par le récepteur de la télécommande via le contrôleur de vol pour ensuite faire tourner les moteurs à la vitesse désirée.
Il existe différentes sortes d’ESC sur le marché : les 12A, 20A et 30A sont les plus communs. Le choix se fait en fonction des caractéristique de nos moteurs. Il faut regarder le courant maximum consommé par les moteur, les notre se situent à 7.4A. Il faut donc choisir un ESC supérieur à cette dernière. Pour notre utilisation les ESC 12A suffiront. Il faut savoir que plus on monte en gamme, plus les ESC sont conséquents au niveau de la taille et de poids.
Batterie
Pour le choix de la batterie, nous nous sommes appuyé sur l’expérience d’autre utilisateurs pour faire notre choix. Les caractéristique technique de la batterie doivent correspondre aux éléments qu’elle alimente. Afin d’avoir une autonomie raisonnable, nous avons choisis une batterie de 1500 mAh. Nous nous sommes assuré que les connectiques correspondent à notre carte électronique et au chargeur.
Caméra
La caméra est de résolution modeste mais largement suffisante pour le pilotage. Nous avons opté pour un capteur CCD pour ne pas avoir l’effet rolling shutter. Le capteur dispose d’un champ de vision de 148°. Un émetteur avec une fréquence de 5,8 GHz est nécessaire pour ne pas interférer avec les fréquences des commandes qui sont en 2,4 GHz.
Bilan du poids des composants
Voici un premier bilan des composants permettant d’avoir une idée du poids total du drone. L’estimation rentre dans nos critères de ne pas dépasser les 500g.
5. Simulation de la configuration
Pour avoir un premier aperçu sur les performances de notre drone, nous avons rechercher à simuler ses performances. Pour cela nous avons trouver sur le net différents calculateurs et formules bien pratique.
Relation entre la consommation des moteurs et la batterie
Nous avons 4 moteurs consommant 72 Watt chacun, soit 288 Watt l’ensemble. Rappelons que notre batterie est une 11.1, 1500mAh.
– On divise la consommation des moteurs par la tension d’alimentation pour trouver l’ampérage :
P=U.I donc I=288/11.1=26 A
– Nous pouvons donc maintenant calculer l’autonomie à l’aide de simulateurs prenant en compte divers paramètres tel que le taille du drone, sa forme, le poids,…
En comparant les données entre plusieurs simulateurs de batteries nous remarquons que nous obtenons des valeurs de temps de vol quasi identique.
https://www.ecalc.ch/xcoptercalc.php
Cette dernière capture d’écran permet de voir des données beaucoup plus détaillé.
6. [Casque Réalité augmenté] – Comment le réaliser ?
Le concept du casque de réalité augmentée est assez simple à mettre en œuvre. Le but du jeu est de transférer le signal vidéo de la caméra sur un émetteur 5.8GHz et de le récupérer sur un récepteur de la même fréquence. A la sortie du récepteur nous récupérons le signal vidéo analogique que nous envoyons via une connectique type RCA sur un convertisseur numérique. Celui-ci dispose d’une sortie USB 2.0 ou nous allons connecter le smartphone via un câble USB 2.0 vers micro USB.
Après quelques recherche sur le net nous avons trouvé des applications permettant la visualisation en direct du signal émis par la caméra. L’application FPViewer à été retenu, car celle-ci possède plusieurs options gratuites, notamment le retour vidéo classique en pleine écran, mais aussi un mode « Cardboard » pour la réalité augmentée. De plus il est possible d’enregistrer directement les images de la caméra en mp4.
Pour résumé l’installation schématiquement :
III. Conception du Drone
1. Modélisation et impression du châssis en 3D
Premières idées et méthode de réalisation
Pour le sujet du châssis, dans une premier temps nous avons fait un travail commun pour regrouper les idées de chacun. A partir de cela nous avons définit l’aspect esthétique et les critères essentiels que le châssis devait comporter. Notre critère essentiel est de concevoir un châssis ergonomique et facilement adaptable de manière à pouvoir placer les composant comme on le souhaite. Nous accorderons aussi une importance à la solidité et la protection des éléments composant le drone, tout en restant le plus léger possible.
Nous avons pensé au tout début à construire un drone à assembler fait de bois, à l’aide d’une découpeuse laser de l’IUT Lab. Le poids du châssis aurait été correct, mais en cas de chute le bois aurait vite cassé. Notre choix s’est finalement porté sur le plastique. Le plastique étant une méthode moderne, précise, et pratique c’était la meilleure option. Il restait ensuite à choisir le plastique et l’impression. Nous voulions utiliser l’impression filaire pour un premier prototype. Cependant lors des premiers test de l’impression, l’imprimante 3D eu beaucoup de mal. Nous avons donc choisi l’impression stéréo-lithographique, avec polymérisation aux UV. Le résultat se révèle bien plus résistant, et précis.
Le principe de l’impression UV en question se déroule en 3 phases comme suit ; la buse apporte le polymère, un rouleau passe pour écraser la matière apportée, et une exposition UV polymérise la matière. Le plateau sur lequel la matière arrive descend à chaque couche, le buse reste au même niveau, et si besoin est, une matière support est créée à base de mélange du polymère à une matière soluble dans l’eau, sur laquelle la buse va pouvoir ensuite travailler, cette technique est utilisé pour imprimer des plans horizontaux par exemple, le nombre de couche est tel qu’à l’oeil nu il n’est pas possible de les discerner.
Modélisation du premier prototype
La première contrainte fut la taille du plateau d’impression. L’imprimante UV ne nous permet pas de dépasser une taille de 20cm². Nous voulions un drone carré, la taille a été limité à 19cm pour avoir une petite marge de sûreté.
Modélisé à l’aide du logiciel Catia V5, de Dassault Systèmes. J’ai décidé de concevoir un châssis tubulaire, pour réduire la surface d’impression (il faudrait utiliser beaucoup de matière support, donc beaucoup de perte ainsi qu’un coût plus élevé), et en même temps créer une rigidité conséquente. L’objectif était de réaliser un “panier » au centre, et quatre supports en ronds pour les moteurs. J’ai pris les mesures des trous nécessaires aux fixations des moteurs, et de la caméra. J’ai rencontré quelques problèmes dû à la méthode de modélisation des formes géométriques des tubes, et du gabarits de ces tubes. J’ai tout d’abord fais des esquisses sur papier, ensuite quelques essais sur le logiciel pour finalement utiliser une forme carrée simple, mais fonctionnelle. Pour le fond du panier, nous avons évoqué l’idée d’un quadrillage lors de la mise en commun. Cela donnera un aspect pratique pour attacher nos composants de la manière souhaitée dans celui-ci. Il m’a fallu pas loin d’une dizaine d’heure pour sortir une première version finale en partant du papier jusqu’au fichier CAO, le temps de reprendre la main sur le logiciel.
Version finale du premier prototype
Modifications du futur prototype
Malgré un rendu très satisfaisant, quelques problèmes ressortent vite.
Tout d’abord augmenter le carré, de 80mm à 100mm de côté, réorienter les croix de fixations moteurs en les tournant de 45 degrés pour avoir la sortie de câble des moteurs en face des branches, augmenter la hauteur du “panier”. De 10mm car la batterie choisie ne rentrait pas à 2-3mm près, et modifier les branches pour optimiser la fixation des ESC. Ensuite prévoir une fixation d’un « bumper », pour protéger les hélices. Ils se fixeront au niveau des fixations moteurs pour une facilité de montage. La grille de fixation composant le bas du “panier” sera imprimé à part. Lors de la première impression l’imprimante a du remplir le panier de support pour réaliser cette partie, nous souhaitons éviter un tel gaspillage de matière. Un système sera mise en place pour maintenir cette plaque.
Un première aperçu du du futur châssis, encore en cours de modélisation
Conclusion
Le plus gros du travail a déjà été fait, concevoir une base de châssis. Les tubes en 3x4mm sont solide, et le châssis est léger. Les premiers résultats sont très convainquant, il ne reste plus qu’a modifier ces quelques détails sur la prochaine version, puis le châssis final sera opérationnel. En attendant nous utilisons le premier prototype pour faire nos premiers testes d’assemblage. Il sera aussi utilisé pour les premiers tests moteurs.
Modélisation du deuxième prototype
Après avoir corrigé les problèmes précédents, j’ai continué les modifications en éloignant légèrement les bras de fixations au niveau des fixations moteurs, pour avoir une meilleur rigidité, et plus de place, et en rajoutant des sortes de rampes sous les bras de fixation pour venir fixer les ESC. J’ai consolidé aussi les pieds, car sur l’ancien modèle nous en avons cassé un facilement. La grille de fixation est resté sur le même principe.
Avec ce châssis la nous sommes sur la bonne voie pour faire voler cette machine droit.
Conception d’une nouvelle version de châssis
Une fois que cette version a été imprimé nous avons réalisé que les défauts remarqué sur le 1er sont corrigés mais il restais un problème sur le placement des composant à l’intérieur. Nous avons donc fait ce que nous aurions du faire depuis le début –> modéliser les composant en 3D à taille réelle afin de faire un montage numérique du drone et ainsi valider les cotes du châssis. Ce montage nous a contraint de réfléchir sur un autre type de châssis. Les châssis précédents étaient long a imprimer, 12H en moyenne, et coutaient plus de 15€. Nous avons donc conçus le châssis suivant, en longueur, pour avoir le plus de place possible.
Il sera imprimé en plusieurs parties, afin de gagner en temps d’impression et en coût de matière. Nous avons ensuite corrigé certaines caractéristiques comme le support de caméra ou encore les barrières de protection. Nous avons également mis des rainures de renfort sur la partie inférieur :
Ci dessus, une vue de l’assemblage avec les composants. Il ne reste plus qu’a finaliser quelques détails esthétique.
Version final du châssis du drone
Nous avons imprimé ce châssis, et il nous semblait parfait, spacieux, et rigide. Mais un collègue a mis en évidence une faille de rigidité au niveau des fixations moteurs, qui s’est avéré fatal. Nous avons donc dû réimprimer un châssis, en ajoutant toutes sortes de renforts, pour pallier à toute fragilité.
Et voila les rainures de rigidité, avec des parties pleines à l’endroit de fragilité des fixations moteurs.
Modélisation bumpers
Pour protéger les hélices et le châssis nous avons décidé de modéliser des bumpers, en voici les plans, nous allons les imprimer dès que possible.
2. Assemblage
Soudure des ESC au PDB
Les ESCs ont besoin d’être alimenté en 5V, on va donc les souder sur des sorties 5V, mais il faut faire attention à un détail : la disposition. Le drone présente une forme en X, il faut donc les placer de préférence dans chaque coin du PDB pour une organisation optimal pour une meilleure intégration au châssis.
Schéma récapitulatif du câblage des ESCs
Soudure du connecteur XT60 au PDB
Il ne faut absolument pas oublier cette étape, qui permet la mobilité de la batterie. Nous avons souder un connecter de type XT60 mâle, pour aller avec le connecteur XT60 femelle de la batterie et donc lui permettre d’être amovible. Le remplacement de la batterie, ou la charge sont donc facilités.
Ajout du connecteur sur l’entrée 12V du PDB
Alimentation de la caméra, soudure de l’émetteur vidéo
L’alimentation de la caméra se fait indirectement, car celle-ci est relié directement à l’émetteur vidéo via un connecteur. L’émetteur et la caméra nous demande 12V. Nous avons donc prévu un PDB à cet effet ayant la sortie nécessaire.
Ajout de l’émetteur sur une sortie 12V
Montage des moteurs sur le châssis
Soudure des moteurs aux ESC
3. Paramétrage de la radiocommande
La télécommande est une Flysky I6, le effectué et le lien entre le récepteur (cf photos point suivant) et la télécommande, une simple manipulation d’appairage.
Réglages fins de courses + Config radio CF
4. Configuration et câblage du Naze 32
Câblage du Naze 32 :
Ce contrôleur de vol est fournis avec un PDB (Power Distributing Board), la batterie alimente cette carte en 11V , le PDB distribuera l’énergie aux ESC. Les ESC soudés dessus permettent de réguler la tension d’alimentation afin de l’adapter pour les moteurs. Les moteurs sont soudés aux ESC (aux 3 fils noirs).
Les ESC ont des BEC intégrés ( Battery Eliminator Circuit), ce composant visible dans l’ESC permet d’adapter la tension d’alimentation venant de la batterie (11V) pour le moteur (intensité variable), on vas se servir d’un des 4 BEC pour alimenter la Naze 32 en 5V. C’est pour cela que nous avons garder des pin d’alimentation d’un ESC (voir photo ci dessus).
Par la suite il a fallu assembler la naze 32 avec l’ensemble « PDB ». Il suffiras de brancher le pin « signal » (orange) sortant de chaque ESC à la carte sans oublier les pins d’alimentation liant le BEC à la carte.
Paramétrage du Naze 32
Nous avons par la suite paramétré la carte de vol à l’aide de CleanFlight. Dans un premier temps nous avons réglé le PID de la carte de vol dans le but d’avoir un drone stable.
Dans CleanFlight nous avons accès à un réglage des valeurs pour le P, le I et le D correspondant à une correction dans les trois axes X Y et Z.
Notre carte de vol Naze 32 contient un accéléromètre. Ce dernier ce calibre également sous CleanFlight dans l’onglet Setup.
Voici les différents modes que l’on peut assigner aux switches de la télécommandes.
5. Phase de test
Avant de passer au test grandeur nature, nous avons réaliser via un logiciel de simulation de vol, des tests de la télécommande et nous en avons profité pour nous entraîner à piloter sur ce logiciel.
Voici ci-dessous les premiers test des moteurs. Nous avons voulut vérifier que notre drone démarre bien suite à l’amorçage des moteurs via des switches sur la télécommande.
IV. Conception du casque de Réalité augmentée
1. Réalisation du casque
Nous avons décidé d’utiliser une autre technologies pour la construction du masque. Il seras découper par laser et seras fait en bois. Nous avons dessiner chaque pièces sur Creo, en étant vigilant a respecter le cahier des charges. Sur la photo suivante nous avons caché le haut du masque afin de voir l’intérieur. Le téléphone seras debout dans la partie grise (imprimé en 3D). A l’aide de rainures qui laisserons dépasser des ergots, nous serons capable de régler la position du smartphone.
2. Mise en place du retour vidéo sur le smartphone
Le retour vidéo sur smartphone s’effectue grâce à deux ensembles:
Un ensemble composé de la caméra et de l’émetteur avec son antenne qui émet sur une fréquence de 5.8 GHz, relié à une batterie provisoire pour les essais puis seras directement branché sur le PDB par la suite. Nous avons choisit 5.8 GHz comme fréquence car la fréquence 2.4 GHz est déjà utilisée pour le récepteur/transmetteur et par la télécommande servant à piloter le drone. Pour éviter d’avoir des interférences entre les deux couples récepteurs/transmetteurs nous avons choisit une fréquence bien plus élevée pour la partie vidéo.
Un autre ensemble composé du smartphone, un récepteur vidéo 5.8 GHz relié au convertisseur analogique numérique qui lui est branché au smartphone par un câble Micro USB/USB. Cet ensemble est alimenté par une batterie 11.1V 800mAh.
La liaison entre l’émetteur et le récepteur est très simple: il suffit d’alimenter le récepteur et l’émetteur puis de rechercher sur le récepteur le bon canal d’émission de la caméra.
De nos jours, l’automatisation de process devient une pratique de plus en plus courante. De la fabrication automobile à la régulation de température dans nos maisons, l’automatisation est omniprésente. Quand nous pensons aux cocktails, nous visualisons une préparation manuelle qui nécessite une certaine expérience.
C’est pourquoi nous avons comme projet de développer une machine à cocktails automatisé, pour montrer que l’automatisation peut être utilisée dans des domaines diversifiés et non essentiellement dans le domaine de l’industrie tout en faisant découvrir l’automatisation à un large public au travers d’un moyen ludique.
Grâce à ce projet nous allons pouvoir découvrir la dextérité et l’organisation que demande la conception complète d’une machine. De plus, nous allons pouvoir nous expérimenter dans les domaines mécaniques et électriques tout en développant le travail d’équipe.
L’équipe du projet est constituée de 2 étudiants GMP et 2 étudiants GEII.
GMP : Damien et Jeremy
GEII : Pierre et Nicolas
II. ANALYSE FONCTIONNELLE :
Avant d’établir un cahier des charges, nous avons voulu exprimer en premier lieu le besoin pour cette machine. C’est pour cela que nous avons établi une bête à cornes :
Suite à ce schéma nous avons pu réfléchir sur les liens entre le système et son environnement. Donc nous avons réalisé un diagramme pieuvre afin de recenser les fonctions du système.
Pour finir nous avons rédigé un cahier des charges raisonnable sur la conception de la machine. C’est grâce à ce cahier des charge que nous allons pouvoir faire le choix de nos équipements et des matériaux qui vont constituer la machine.
Cahier des charges :
Fonctions de services
Critères
Niveau d’exigence
Flexibilité
FP1 : Servir un cocktail à l’utilisateur
Temps du service
Environ 30 secondes
F3
Qualité
Respect de la commande
F0
FC1 : Préparer un cocktail en autonomie
Autonomie
Aucune intervention de l’utilisateur
F0
Gestion d’un programme
Automate
F0
FC2 : Doser les cocktails
Quantité en cL
+/- 0.5 cL
F2
FC3 : Respecter les normes d’hygiène
ISO 14001 / ISO 9001
F0
FC4 : Doit être simple d’utilisation
Interface de commande
Tactile (IHM) + Boutons
F0
FC5 : Déplacer le shaker
Déplacement transversal
Courroie
F0
Vitesse
0.05 m/s = 5cm/s
F2
Support
Dimension d’un shaker
F1
FC6 : Être alimenté en énergie
Alimentation système
230V AC
F0
Alimentation électrovannes
24V DC
FC7 : Assurer plusieurs services
Volume des contenants d’alcool
1 L
F1
Volume des contenants des diluants
3 L
F2
FC8 : Être esthétique
Câblage
Bon câblage, ordonné
F0
Montage de la machine
Propre, sans rayure, sans casse
Légende : -FP : fonction principale -FC : fonction complémentaire
-Classe de flexibilité :
0.Flexibilité nulle-Niveau impératif
1.Flexibilité faible-Niveau peu négociable
2.Flexibilité bonne-Niveau négociable
3.Flexibilité forte-Niveau très négociable
Pour ce projet nous avons décidé de toujours travailler en binôme afin de pouvoir avoir un autre avis lorsque l’on conçoit quelque chose.
Les binômes et leurs rôles sont :
-GMP : entière conception de la machine du point de vue mécanique (taille, matériaux, forme).
-GEII : entière conception de la machine du point de vue électrique (choix des composants électriques, câblage, programmation).
III. RÉALISATION DU PROJET :
3.1 Partie génie mécanique :
Tout d’abord nous avons du rassembler toutes nos idées. C’est à dire sa structure de base, comment le verre va se déplacer et où nous allons mettre les bouteilles. Nous sommes parti sur une machine de base rectangulaire avec un déplacement moteur+courroie pour le verre et nous avons mis les bouteilles en hauteur pour utiliser la gravité.
Ci-dessous la première esquisse de la forme de la machine :
C’est à partir de l’idée du déplacement du verre par courroie+moteur que nous avons eu comme idée de démonter une imprimante A0 non fonctionnelle pour récupérer le système du chariot et l’adapter sur notre machine. Ci dessous des images du démontage de l’imprimante :
Voici la modélisation de l’adaptation du système de déplacement du verre :
Ensuite est venu la réalisation, avec les photos ci-dessous nous allons vous montrer les étapes pour réaliser la machine :
Mise en place du système moteur+ courroie avec le chariot
Mise en place du système pour tenir les bouteilles à l’envers.
Pour finir voici une image de la partie mécanique terminée.
3.2 Partie génie électrique :
Pour débuter la partie électrique, nous avons listé tous les composants nécessaires à la réalisation :
Automate programmable => Afin de gérer le programme, les recettes et le déplacement
Interface Homme Machine => Ecran tactile permettant à l’utilisateur de choisir son cocktail
Moteur => Pour la déplacement du chariot
Électrovanne => Pour laisser passer ou pas le liquide
Relais => Pour l’inversion moteur, pour que le chariot puisse aller à droite ou à gauche
Fin de course => Mise à 0 de la position
Alimentation 24VDC => Pour alimenter notre système
Bouton poussoir => Bouton start
Bornier
Capteurs infrarouge => Pour le positionnement du chariot sous les bouteilles
Nous pouvons voir sur l’image ci-dessus tous nos composants électroniques. De gauche à droite : Le bornier, un disjoncteur, l’alimentation, l’automate puis le relais.
Ici nous pouvons voir une image des électrovannes cachées dans une goulotte électrique.
Pour finir voici une image du projet terminé.
IV. CONCLUSION DE NOTRE PROJET :
Grâce à ce projet nous avons pu voir la dextérité que demande la création d’une machine de A à Z, nous avons aussi pu voir que le travail en groupe est quelque chose d’important.
Pour au mieux conclure ce projet, voici un lien d’une vidéo montrant notre machine fonctionnelle : https://www.youtube.com/watch?v=WMygkw-IFeg&feature=youtu.be
La CanSat se développe dans le cadre d’un concours. Ce concours se déroule sous forme d’une compétition entre plusieurs écoles et/ou associations de particuliers. Le concours fixe plusieurs missions à effectué, le but étant de mener à bien le plus de missions possible. Selon le niveau auquel se déroule le concours, on impose le volume maximal dans lequel doivent s’articuler l’ensemble des composants choisis par les participants. En ce qui concerne notre CanSat, nous avons choisi d’opérer dans un 1L de contenance afin de pouvoir mettre en oeuvre l’ensemble du matériel nécessaire pour répondre aux mission que nous avons nous même défini.
II. Contexte
Afin de clôturer notre 2e année d’apprentissage, nous avons du choisir une idée de projet à réaliser. Ce projet devait se dérouler sur 60h, avec de groupes de 2 à 4 étudiants composés d’étudiants en GEII et d’étudiants en GMP, le tout sur une période d’octobre 2016 à mai 2017. Etant donné du faible volume horaire, et de la participation du département GMP, il a fallut rapidement s’organiser pour pouvoir travailler efficacement
III. Le cahier des charges
A. Les idées
N’étant pas contraint par les règlements du concours, nous avons pu décider librement de la conception de notre CanSat. Cependant nous nous sommes imposés la contenance minimale, à savoir 1L comme seule règle. Nous nous sommes ensuite sur les points suivants ; notre CanSat devra :
Etre capable de mesure de de grandeurs physique en temps réel telles que : La Température, la pression, la luminosité, l’accélération, l’humidité, la position
Avoir une autonomie suffisante pour monitorer les données pendant 3j
Transmettre les données en temps réel via un application au sol
Etre capable de supporter des chocs sans impacter les composants embarqués
Avoir une masse inférieur à 1kg
Avoir une hauteur maximale de 200mm et un diamètre de 80mm
Intégrer un parachute dont la masse ne doit pas excéder 1Kg
Avoir une structure ouverte pour faciliter les mesures des capteurs
Etre réutilisable
L’ensemble des réflexions peuvent être brièvement résumées par le schéma suivant :
Cependant, nous nous sommes réserver la possibilité d’ajouter des capteurs/modules au cours du projet, comme par exemple la mise en place d’une caméra par exemple.
B. Les solutions
1. Partie GeII
Nous avons choisi de réaliser ce projet en se basant sur un Raspberry pi 0. En effet, sa facilité de mise en oeuvre nous permets une grande flexibilité quand à la manière de mettre en oeuvre l’ensemble de nos capteurs. Aussi, la facilité d’utilisation du Raspberry ainsi que de ces cartes d’extensions nous à permis d’avancer rapidement lors du projet. Voici donc à quoi ressemble le cerveau de notre projet :
Le raspberry pi 0. Nous l’avons choisi notamment pour sa taille très réduite et sa consommation minime, parfaite pour concevoir un appareil avec une bonne durée de vie.
L’enviroPHAT, qui est une carte d’extention du raspberry pi 0. Cette carte rassemble une grande partie des capteurs dont nous avions besoin pour mesurer :
La temperature
La pression
La luminosité
L’accélération
L’enviroPHAT est facile d’utilisation, il utilise un bus I2C pour communiquer avec le raspberry.
Pour les mesures d’humidité, nous utiliserons une sonde d’humidité comme ci-dessous
Afin de pouvoir communiquer avec la CanSat une fois en l’air, et récupérer les données qu’elle mesurent, nous avons utilisé des modules XBEE S2C fonctionnant en 2.4 Ghz, d’après la suggestion de nos professeurs
Une fois configuré correctement, le module xbee permet d’émettre des informations a plus de 1km de portée en simulant une communication série. L’idée était donc d’utiliser 2 modules XBEE : un directement intégrer à la CanSat, et l’autre branché à un PC au sol. Cette installation permet de monitorer les valeurs relevés par la CanSat lorsqu’elle est en fonctionnement. Pour plus de sécurité, la communication est chiffré en AES 256.
Pour alimenter le projet, nous avons utiliser 4 batteries en parallèle
Ce sont des batteries Li-Ion produites par Samsung. ces batteries délivrent 3,7V et jusqu’à 2500mAh. D’après nos calculs, nous avons estimé la durée de vie de la CanSat à 4,5j d’autonomie grâce à ces 4 batteries. Ce qui est largement suffisant pour remplir nos conditions.
Enfin, nous avons utiliser un hacheur pour palier aux problème de tensions, notamment entre le raspberry pi zero et le module XBEE
C’est un hacheur Boost DC-DC pouvant convertir du 3,3V en 7V et du 5V en 9V. Il fonctionne avec de faibles intensité, et permet de centraliser l’alimentation de la CanSat.
2. Partie GMP
Nous avions différents idées pour la conception de notre Can-Sat. C’est pourquoi nous avons tout d’abord échangé nos idées à l’aide de croquis.
Solution 1Solution 2Solution 3Solution 4
Les solutions 1,2,3 utilisent le même principe. Une partie inférieure en un seul bloque usiné pour avoir un gain de matière. Une partie supérieure avec une platine permettant de fixer le raspberry. Cependant il est très difficile d’usiner ce type de bloc.
Après discussion entre nous et les professeurs, nous avons choisis la solution 4. Celle-ci est la plus simple à réaliser. Elle est composée de deux platines circulaires, 3 tiges filetées et de support pour le raspberry. Nous avons donc plusieurs petits éléments facile à réaliser, à assembler et modulable.
Voici le modèle 3D de la CanSat :
III. Le développement
A. Partie Electrique
Nous pouvons dégager 2 grandes partie dans la conception du projets :
La programmation du Raspberry pi et des capteurs environnants
La conception du Hacheur
Nous avons décidé de travailler ensemble sur les deux sujets de manière parallèle mais avons défini une personne en charge principal de chacune de ces deux tâches : Victorien pour la partie programmation et Alexandre pour la conception du hacheur.
La programation du Raspberry se fera en python. Ce langage à été choisi pour sa facilité de mise en oeuvre avec la carte d’extension.
Le programme sera composée de différente étapes avec des transitions à la manière du langage Grafcet.
Ces étapes permettront de définir dans quel état se trouve la Cansat (phase ascendante/descendante etc) et ainsi éviter un état non défini.
Les transitions se feront grâce aux relevés des différents capteurs.
Pour la communication des données, nous avons déterminer une trame type qui permettra de mettre en forme les données et ainsi les communiquer au PC via une liaison série puis sans fil grâce au Xbee.
Toutes les valeurs mesurées seront aussi enregistrées dans la carte SD du Raspberry pi pour pouvoir les exploiter après la mission.
Afin de mettre en oeuvre notre hacheur, nous avons choisi d’utiliser un circuit imprimé faisant office de régulateur , un MC34063. Cela implique tout un travail de dimensionnement des composants qui viendront s’implémenter autour du régulateur comme le montre le schéma suivant :
Figure 2. :Schéma général du régulateur en mode hacheur
Une fois le hacheur conçu, il sera testé et ensuite intégré à nos prototypes de CanSat. Nous envisageons à termes de faire concevoir un PCB par une société afin d’améliorer la qualité de notre hacheur.
B. Partie Mécanique
La conception commence par des croquis pour voir les différentes idées.
Nous avions différentes idées pour la conception de notre Can-Sat. C’est pourquoi nous avons tout d’abord échangé nos idées à l’aide de croquis.
Solution 1Solution 2Solution 3Solution 4
Les solutions 1,2,3 utilisent le même principe. Une partie inférieure en un seul bloque usiné pour avoir un gain de matière. Une partie supérieur avec une platine permettant de fixer la carte électronique. Cependant il est très difficile d’usiné des blocs comme ça.
Après discussion entre nous et les professeurs, nous avons choisis la solution 4. Celle-ci est la plus simple à réaliser. Elle est composée de deux platines circulaires, 3 tiges filetés et de support pour la carte électronique. Nous avons donc plusieurs petits éléments facile à réaliser, à assembler et modulable.
La conception de la CANSAT est terminée, les plans sont en cours de validation pour pouvoir produire nos pièces et ensuite assembler la CANSAT.
Nous avons aussi commencé à chercher des solutions pour la réalisation de notre parachute, mais la conception finale, le dimensionnement et la réalisation du parachute reste à faire.
Le robot BB8, connu pour ses parutions dans la célèbre saga Star Wars, est à l’origine de notre projet. Nous avons entrepris de reproduire un système de la sorte pouvant se définir comme un robot « boule ».
Ce système ayant déjà été reproduit par plusieurs personnes, mais n’ayant trouvé aucune base suffisamment documentée, nous avons décidé de concevoir de A à Z notre propre BB8, d’après nos propres idées, en nous inspirant bien évidemment des systèmes existants.
Ce projet consiste en la réalisation d’une sphère creuse dans laquelle vient s’insérer un système complet, lui permettant de se déplacer suivant plusieurs axes. Cette sphère sera télécommandée par un appareil mobile (tablette ou smartphone) à l’aide d’une application dédiée.
Grâce à ce projet, nous allons pouvoir découvrir le travail nécessaire à la conception complète d’un système, de la définition de son cahier des charges à sa mise en oeuvre, ainsi qu’à l’organisation que cela implique. Ce projet va également nous permettre d’améliorer nos capacités à travailler en équipe. Nous avons l’opportunité de mettre en commun le génie mécanique et le génie électrique dans ce projet, ce qui nous permettra de mettre en avant et de combiner les compétences et savoirs de chacun.
Membres du projet :
Pierre JAEGLE, étudiant en 2e année de Génie Mécanique et Productique
Arnaud STEINMANN, étudiant en 2e année de Génie Mécanique et Productique
Marion HELL, étudiante en 2e année en Génie Electrique et Informatique Industrielle
II. Pré-étude
1. Cahier des charges
FS
Fonction
Critères
Niveaux
Flexibilité
FP1
Déplacer BB8 dans l’espace
Durée
Autonomie 30 min
F1
Mouvement linéaire assuré
Absence d’oscillation
F0
Trajectoire dirigée
Commande par application de téléphone
F1
FC1
Dimension
Sphérique
Sphère extérieure
F0
Rayon
297 mm maxi
F0
FC2
S’adapter au terrain
Surface plane en intérieur
FC3
Utiliser une source d’énergie électrique
Stockage d’énergie
Electrique
F0
Transmission de cette énergie
En énergie mécanique
F0
FC4
Aspect esthétique donné à l’objet
Correspond aux goûts communs
Esthétique
F2
FC5
Employer un budget maximal
Coût
150€ maxi
F2
FC6
Communication
Enveloppe permettant de transmettre les signaux nécessaires
Signal Bluetooth
F0
FC7
Assurer la stabilité
Répartition des masses homogène
Stabilité et équilibre vérifié
F1
Les contraintes :
La conception d’un tel projet nécessite la prise en compte de plusieurs contraintes. Le robot se déplacera dans un environnement ouvert, il devra donc être en mesure de s’adapter à différents types de sol. Ces sols étant parfois irréguliers, il devra être en mesure de rester stable lors de ses déplacements.
Le robot sera piloté par différents sous-ensembles électroniques, commandés par un microcontrôleur programmé situé à l’intérieur de la sphère. Une application smartphone sera développée pour communiquer avec le robot et piloter ses déplacements. La communication entre le robot et sa commande à distance s’effectuera par liaison Bluetooth.
Les solutions :
Il nous faudra faire particulièrement attention lors de la conception des différentes pièces afin de réussir à équilibrer l’ensemble. Nous allons dans un premier temps concevoir le maximum de pièces symétriques pour obtenir un point de gravité central. Nous prévoirons des emplacements permettant l’ajout de cales pour ajuster l’équilibrage final de l’ensemble, afin de compenser les éventuelles imprécisions de calcul et de fabrication des pièces.
Pour permettre le passage des signaux, nous devrons choisir un matériau perméable aux ondes Bluetooth.
2. Répartition des tâches
III. Conception
1. Choix de solutions
Partie mécanique
Première étude
Partant de zéro, la plus grande partie de notre travail a été de définir comment concevoir la structure d’un robot sphérique, avec la recherche de solutions permettant un bon fonctionnement de l’ensemble. Pour nous aider dans cette tâche, nous avons conçu l’ensemble en 3D sur ordinateur.
Le travail de recherche nous a pris un temps considérable, il nécessite de prendre en compte de très nombreux paramètres qui influeront sur le bon fonctionnement du système.
Après une longue réflexion, nous avons décidé de concevoir notre BB8 de la manière suivante :
Notre système se présente ainsi, nous avons deux demi-sphères à droite et à gauche qui seront sur leurs extrémités « encastrées » avec la paroi intérieure de la sphère. Dans ces deux demi-sphères, on trouve un logement dans lequel viendra se positionner un roulement.
La pièce principale ci-dessus que l’on peut désigner tel un axe, possède de chaque côté une barre de stub, permettant le montage de roulements. Les stubs seront emboutis dans la pièce principale et une fois les roulements montés sur les stubs, on assemblera l’ensemble dans les demi-sphères.
Les deux moteurs que l’on aperçoit ont chacun une fonction bien précise, celui du bas permettra grâce à un déséquilibre et un entrainement sur la paroi intérieure de la sphère sans glissement, de créer un mouvement selon une direction. La roue en bout d’axe n’est pas encore modélisée. Le moteur du bas sera fixé à l’aide d’une tige sur mesure.
Le moteur du haut permettra, lui, grâce à un axe et des masselottes sur chaque extrémité (pas encore modélisés) de créer une rotation de l’ensemble en fonction de la puissance transmise au moteur. Ce dernier sera fixé sur une plaque, qui sera positionnée à l’aide de deux étirés.
Solution adoptée
Pour des raisons d’équilibre, d’ergonomie et de fonctionnement la conception de notre ensemble a été modifiée une dernière fois pour obtenir une version optimale. L’avis de nos enseignements fut pour cela très utile. Cette conception va permettre de disposer la batterie sous l’axe principale et donc de le placer au plus bas et diminuer la hauteur du centre de gravité.
Les dimensions de la pièce principale ont été modifiées pour des raisons de poids et donc d’équilibre. La pièce initiale était trop imposante. Ci-dessous la nouvelle pièce principale. La surface principale doit être conservée car c’est elle qui va permettre de supporter la carte Arduino.
La deuxième grande modification concerne la fixation du moteur inférieur. Nous avons décidé de concevoir un système permettant un ajustement du contact entre la roue et la surface intérieure de la sphère.
Pour cela les deux étirés vont traverser la plaque centrale et vont permettre un ajustement suivant l’axe Y de l’ensemble par rapport à la plaque principale à l’aide d’une vis de pression.
Un méplat a également été réalisé sur les étirés pour le blocage.
Pour limiter la taille des plaques que l’on peut voir en haut et en bas, un taraudage sera réalisé sur chaque extrémités des étirés.
Pour les roulements, nous avons décidé de réalisé un montage en X, un épaulement dans les deux logements des demi-sphères va permettre un arrêt sur la bague extérieur et un épaulement sur les deux arbres, l’arrêt sur la bague intérieur.
Nous avons également choisi deux barres d’étirés pour le montage des roulements au lieu du STUB choisi dans la solution précédente (les barres d’étirés étant beaucoup moins chères).
Vous pouvez voir ci-dessus les tiges d’étirés sur lesquels nous allons monter les roulements.
Nous avons cependant décidé de garder la solution de montage des deux arbres. Ils seront montés serrer dans la pièce principale.
Concernant la plaque inférieure qui va supporter la batterie. Nous avons réalisé un trou oblong pour permettre de régler la position de la roue du moteur au niveau du contact avec la surface intérieure de la sphère. Vous pouvez voir la solution ci-dessous.
Partie électronique
Le microcontrôleur
Afin de piloter les différents éléments, nous avons opté pour l’utilisation d’une platine de type « Arduino UNO ». Les modules Arduino sont des plate-formes de prototypage microcontrôlées « open-source ». Nous avons choisi ce module pour sa facilité d’utilisation, son faible coût, ainsi que sa mise en oeuvre rapide. La bibliothèque de développement Arduino, très complète, permet de configurer de manière simple les différents ports d’entrées/sorties du microcontrôleur présents sur la carte. Ces ports sont utilisables via des connecteurs femelles présents sur le bord de la platine, permettant ainsi de connecter différents équipements ou capteurs.
Un outil de développement est mis à disposition pour les utilisateurs d’Arduino et permet de programmer en langage C++.
La communication
Cette carte n’étant pas équipée de module de communication sans fil, nous l’avons connectée à
un équipement Bluetooth, de type « HC-05 ». Le protocole Bluetooth fonctionne comme une communication série bidirectionnelle. La plupart des équipements mobiles étant équipés de communication Bluetooth, il sera donc facile d’appairer un appareil afin de piloter notre robot. Nous avons choisi de développer une application smartphone plutôt qu’une télécommande dédiée afin d’assurer une modularité au fonctionnement de notre robot. En effet, si nous souhaitons faire évoluer son fonctionnement, il sera plus simple de modifier une partie programmation (software), que l’implémentation hardware et software d’une carte électronique.
La commande des moteurs
Nous avons choisi d’équiper notre robot de moteurs à courant continu. Pour en faire varier la vitesse, le module Arduino dispose de sorties « PWM » (signal à rapport cyclique variable). Il est cependant nécessaire d’utiliser une carte d’interfaçage, puisque la consommation en courant des moteurs est nettement supérieure à celle supportée par les ports de sorties de la carte, ce qui serait destructeur pour cette dernière.
Pour cela, nous utiliserons un montage « pont en H ». En plus de protéger le microcontrôleur, ce montage nous permettra de piloter le moteur dans les deux sens de rotation, mais également d’obtenir ce que l’on appelle un « frein magnétique », en fonction des transistors pilotés :
Nous avons sélectionné le composant « L293D » pour notre montage. Ce composant est un « quadruple demi-pont en H ». En utilisant deux demi-ponts par moteur, nous aurons donc 2 ponts pour les piloter, indépendamment l’un de l’autre.
Toujours dans un souci d’ergonomie et de rapidité de mise en oeuvre, nous avons trouvé un « shield » dédié, à connecter directement à notre module Arduino. Celui-ci comporte différents connecteurs pour le branchement des moteurs, ainsi que pour connecter une alimentation externe.
L’alimentation électrique
Une batterie sera chargée d’alimenter l’ensemble de l’électronique. Cette batterie devra être d’un encombrement modéré, et fournir une autonomie suffisante au robot. Son implantation dans la sphère devra permettre d’y accéder facilement afin d’en effectuer la recharge ou son remplacement.
IV. Fabrication des pièces
Lors de la fabrication des éléments conçues nous avons utilisé différents procédés pour obtenir les pièces souhaitées:
L’usinage
Moulage par moule perdu
Les machines principalement utilisées sont les suivantes :
la découpeuse jet d’eau
perceuse à colonne
fraiseuse traditionnel
tour traditionnel
tour à commande numérique
scie à bande
1. Méthode
L’IUT disposant d’un parc machine important et d’ateliers divers, nous avons exploité les ressources disponibles :
Parc machine GMP
IUT Lab
Atelier SGM
C’est à partir des machines disponibles que nous avons créé nos procédés.
Lors de nos procédés nous avons choisi les éléments pour correspondre le plus près possible aux éléments normés, et ainsi réduire les coûts et délais.
Moulage des demi-sphères extérieures :
Pour cela nous acheté des demi-sphères en polystyrène, de la résine époxy et nous nous sommes fournis en fibre de verre, puis nous avons effectué un montage collé avec celle-ci.
Nous avons tout d’abord procédé à une première couche de résine sur la demi-sphère. Puis par succession de couche de fibre de verre et de résine époxy, la fibre de verre étant préalablement découpé pour correspondre aux dimensions et à la forme de la demi-sphère.
Après quelques jours de séchage nous avons procédé à la découpe de la demi-sphère puis à leur ponçage.
2. Programme
Deux programmes de commande numérique ont été réalisés :
programme de tour à commande numérique pour réaliser les demi-sphères intérieures.
programme fraiseuse à commande numérique pour la plaque axe principale. Ce dernier à été testé mais n’a pas fonctionné du à des efforts de coupe trop importants dans le sens opposé au fond de l’étau. Ceci à éjecté la pièce. Nous n’avons pas pu continuer le travail car le CU72 est tombé en panne.
La réalisation des pièces s’est effectué normalement.
Pour réduire les usinages de l’ensemble des pièces simples, nous avons défini les épaisseurs directement aux côtes du brut.
V. Montage
Une fois les pièces créées, nous avons pu passer à l’assemblage. Ci-dessous la vue des différentes pièces ainsi que d’un montage provisoire du robot.
Le câblage entre les différents éléments a été réalisé par la même occasion. Il a alors s’agi de relier l’Arduino (équipé de son shield moteur) au module Bluetooth, à la batterie, ainsi qu’aux moteurs.
VI. Partie programmation
Le robot étant pré-monté, nous avons pu effectuer les essais logiciels et tester la commande du robot à distance. Nous avons alors du programmer notre module Arduino pour que le robot réponde de la bonne manière à une commande réceptionnée.
La programmation de l’Arduino a permis de :
Gérer les ports d’entrées et sorties de l’Arduino
Gérer la liaison série (Bluetooth)
Gérer la communication (réception de trames)
Piloter les moteurs
1. Structure du programme
Le programme réalisé s’est structuré de la manière suivante :
1. Configuration (Bluetooth, entrées et sorties du modules Arduino)
2. Attente de la réception d’une trame
3. Après réception, vérification du contenu (début et fin de trame) puis sauvegarde de la valeur
4. Exploitation des coordonnées : récupération et séparation des coordonnées en x et y puis conversion
5. Commande des moteurs en fonction de l’instruction reçue
Les programmes Arduino se séparent en deux boucles principales distinctes :
La fonction « setup », qui correspond à l’initialisation du module. Cette fonction n’est effecuée qu’une fois au démarrage de l’Arduino. C’est dans cette fonction que l’on effectuera la première étape.
La fonction « loop ». Il s’agit d’une boucle qui s’exécute tout au long de la mise en marche de l’Arduino, une fois la fonction « setup » réalisée. En d’autres termes il s’agit de la fonction principale, dans laquelle nous effectuerons les étapes 2 à 5. Nous appellerons alors simplement les fonctions « LectureTrame », « CalculCoordonnees » et « PilotageMoteurs » les une après les autres, en continu.
2. Fonctionnement du joystick
De nombreuses applications existantes permettent de dialoguer par liaison Bluetooth via un smartphone. Nous avons choisi d’utiliser l’application « Blueduino » disponible sur Windows Phone, qui permet très simplement de se connecter à un appareil par liaison Bluetooth, puis de lui envoyer une trame quelconque (caractères ASCII saisis via le clavier du téléphone au travers d’un terminal), soit des informations sur la position d’un joystick présent à l’écran.
L’application se présente de la manière suivante :
A chaque déplacement du joystick à l’écran, une trame est automatiquement envoyée au travers de la liaison Bluetooth, contenant les informations suivantes : * CoordonnéeX , CoordonnéeY, #
3. Développement des fonctions
Il a donc fallu développer les fonctions capables de récupérer la trame envoyée, de traiter ses informations puis de les exploiter pour déplacer notre robot.
Fonction LectureTrame
Cette fonction a pour simple but de lire une trame reçue par la liaison Bluetooth, de contrôler son intégrité (caractères de début et fin de trame), puis de retourner sa valeur dans une variable de type chaîne de caractères, qui sera stockée par la fonction principale dans une variable globale pour être exploitée par les différentes fonctions.
Fonction CalculCoordonnees
Cette fonction permet de récupérer la trame reçue précédemment, d’en séparer les composantes (coordonnées X et Y), puis d’en effectuer une conversion. Pour une meilleure compréhension et une exploitation plus simples de ces coordonnées, nous avons choisi de les convertir vers des valeurs positives et négatives (de -126 à 0 et de 0 à 127) au lieu des valeurs de 0 à 255 fournies par l’application Blueduino.
Cette fonction prend en paramètres la trame (chaîne de caractères) reçue, ainsi que deux pointeurs vers des variables globales dans lesquelles seront stockées les coordonnées du joystick.
Fonction PilotageMoteurs
Une fois les coordonnées récupérées, il faut les exploiter pour déplacer notre robot au travers des moteurs. Il s’agit donc de déterminer la vitesse de rotation du moteur du haut (qui met le robot en rotation) ainsi que du moteur du bas, qui entraîne la roue et donc la sphère vers l’avant ou l’arrière, à une vitesse donnée.
Les coordonnées ayant été converties vers des valeurs positives et négatives, nous pouvons utiliser directement un proportionnel de leur valeur pour gérer la rotation du robot. Le signe de la valeur en X nous permettra donc de connaître le sens de rotation, la valeur nous permettra d’obtenir directement un proportionnel de la vitesse du moteur à entraîner.
Pour la vitesse d’avancement du robot, nous avons cependant choisi d’utiliser la longueur du segment formé par les coordonnées X et Y. En d’autres termes, plus le point de destination du joystick est éloigné du centre, plus le moteur ira vite. Le sens de rotation (avant ou arrière) est quant à lui déterminé par le signe de la coordonnée en Y.
VII. Difficultés rencontrées
Nous avons rencontré plusieurs difficultés ayant retardé notre planning mais également notre conception de l’ensemble.
Après avoir commencé à dessiner plusieurs pièces en 3D, nous nous sommes rendu compte que notre système était surdimensionné en terme de matières, nous nous sommes également rendu compte que nous utilisions trop de pièces.
Nous en avons donc conclu qu’il nous fallait concevoir l’ensemble d’une autre manière, en minimisant le nombres de pièces et en concevant au plus léger et au plus simple. Ci-dessous une photo de notre première conception :
Comme nous pouvons le voir ci-dessus, les différentes pièces sont très grandes, elles engendrent également un copeau important lors des usinages, mais aussi une cotation lourde et des mises en position importantes.
Une autre difficulté a été de prendre en compte l’équilibrage du système, car pour un bon fonctionnement l’équilibrage de l’ensemble est primordial.
C’est la raison pour laquelle nous avons revu la conception de l’ensemble pour placer le module Arduino et la batterie au centre. Nous avons également décidé de respecter une symétrie suivant les deux plans, en rouge et en bleu, lors de la conception de nos pièces. Ces deux étant les plus important dans notre cas.
Au terme du délai imparti, nous ne sommes malheureusement pas arrivés aux objectifs que nous nous étions fixés. Bien que les pièces principales soient réalisées et que la programmation soit fonctionnelle, nous n’avons pas bénéficié de suffisamment de temps pour mettre en commun ces deux environnements. Pour arriver à un robot totalement abouti, les pièces auraient du être fabriquées et assemblées bien avant le terme du projet pour que la partie électronique puisse être développée sur un assemblage concret. Malheureusement ce point n’était pas réalisable au vu de l’emploi du temps des élèves de GMP.
Les points à améliorer pour obtenir un projet abouti sont les suivants :
La mise sous tension
A ce jour, la boule se ferme grâce à du ruban adhésif, ce qui complique très clairement sa mise sous tension et son arrêt étant donné qu’aucune pièce n’est accessible de l’extérieur. Il faudrait donc retravailler ce point pour obtenir un système d’ouverture simplifié.
La roue
Par souci de temps, la roue n’a pas pu être modélisée par le biais des machines dont nous disposons à l’IUT. Les différentes solutions testées ne possédaient pas suffisamment d’adhérence pour entraîner suffisamment la sphère.
Le module infrarouge
Un module infrarouge a été développé pour évoluer vers un déplacement autonome du robot à la recherche d’une balise. Malheureusement, la sphère en fibre de verre n’est pas suffisamment perméable à ces signaux pour obtenir un résultat concluant.
Conclusion
Ce projet nous a permis de réaliser un système complet, de la conception jusqu’au montage, ce qui fut très intéressant.
La fabrication nous a permis de découvrir de nouveaux procédés de mise en œuvre, de construction, de modélisation etc. Le choix des solutions au travers de multiples possibilités a été très enrichissant puisqu’il a nécessité de lister les points positifs et négatifs de chaque solutions pour ne garder que la meilleure, en fonction des différentes contraintes posées.
Nous nous sommes plongés dans l’univers de la gestion de projet, ce qui nous a confronté à la nécessité d’une bonne communication pour la réalisation d’un projet. Ce point nous a très clairement mis en difficulté et c’est ce qui nous a retardé dans notre réalisation. La communication entre les deux départements a été compliquée, notamment à cause des emplois du temps différents mais également parce que les objectifs posés au départ différaient. En effet, les finalités entre les deux départements n’étaient pas les mêmes : réalisation des pièces pour la partie génie mécanique, réalisation du robot fonctionnel pour la partie génie électrique. Ceci nous démontre également la nécessité de déterminer un cahier des charges exhaustif et clair en début de projet.
L’aspect collaboratif entre les deux départements présente néanmoins de grand avantages, comme la réalisation très complète de projets comme ce robot. Nous en retenons une expérience très enrichissante.
Dans le cadre de nos études en Génie Électrique et Informatique Industrielle (GEII), nous sommes amenés cette année à travailler sur un projet en collaboration avec le département Génie Mécanique et Productique (GMP).
Le projet que nous avons choisi consistera à différencier des pièces de formes différentes à l’aide d’une caméra se situant d’un côté du robot et de les amener de l’autre côté de celui-ci tout en les triant. Ceci sera réalisé à l’aide du robot TP80 de Stäubli que l’on va présenter par la suite.
Le robot dont nous disposons pour réaliser notre projet est le TP80 de Stäubli, il a été conçu en février 2012, pèse 71kg, il a la capacité de réaliser 200 déplacements par minutes et de ce fait a une charge nominale plutôt faible de 500g. Ce robot est très adapté aux applications de packaging dans l’agroalimentaire ou le secteur pharmaceutique par exemple.
2. Critères de fonctionnement :
Le robot doit être capable de différencier 4 types de pièces de formes différentes : rondes, carrées, triangles et étoile. Il devra les déplacer dans un ordre précis qui correspond à la demande de l’utilisateur.
3. Critères techniques :
Choix du préhenseur : il doit être adapté aux pièces que l’on va déplacer.
Prise en main du logiciel de programmation Stäubli.
Prise en main du logiciel de programmation du système de vision.
Le robot FAST picker TP80 est un robot extrêmement rapide conçu pour des opérations de manutention de pièces petites et légères (moins d’1 kg). Le robot FAST picker TP80 est particulièrement adapté aux applications de packaging dans divers secteurs comme l’agro-alimentaire, le médical, le photovoltaïque ou la cosmétique.
Vitesses élevées
Ce robot extrêmement rapide est en mesure de soutenir des cadences allant jusqu’à 200 coups/minute en fonctionnement continu.
Fixation simple
Le robot FAST picker TP80 peut être monté sur une structure bien plus légère que les robots à structure parallèle, apportant une réduction substantielle des coûts et une simplification de l’intégration du robot.
Précision et rigidité élevées
La conception et la construction très rigide du robot lui permet une grande répétabilité sur toute son enveloppe de travail.
Grande enveloppe de travail
Son rayon d’action de 800 mm et sa course de 100 mm (200 mm*) donnent au robot FAST picker TP80 une grande enveloppe de travail tout en maintenant des cadences très élevées.
Tous les câbles utilisateurs passent dans le bras
Les connexions électriques, pneumatiques et les entrées/sorties sont disponibles sur la bride outil avec l’ensemble des câbles logés et protégés à l’intérieur du bras.
Nous avons choisi pour la préhension d’utiliser un système venturi.
Nous ne possédons pas encore cette ventouse ainsi que le système venturi mais ce sera sur ce modèle que l’on travaillera. Nous avons donc réalisé par la suite une pièce permettant d’adapter ce système de préhension à la bride outil. Étant donné que nous n’avons pas d’étudiant GMP qui travaille avec nous, pour réaliser cette pièce nous nous sommes tournés vers M. CHASSIGNET qui nous a donc aidé pour la réalisation de cette pièce d’adaptation. Cette pièce a été découpée à l’atelier GMP au jet d’eau.
Usinage de la pièce
Pièce Finale
Celle-ci nous permettra d’être parfaitement centrés par rapport à la bride outil mais aussi d’empêcher tout mouvement de translation ainsi que de rotation.
Usinage de la pièce
Les pièces ont été dessinées à l’aide du logiciel Solidworks pour que par la suite nous puissions les faire découper par laser à l’IUT Lab.
2. Partie Programmation
La vision : NI VISION BUILDER
La programmation de la caméra se fait avec le Logiciel NI Vision Builder : C’est un logiciel qui donne la possibilité de configurer, définir des valeurs de référence et déployer aisément un système qui répond aux attentes des applications de vision industrielle. Depuis le filtrage par motif et la détection de présence jusqu’à l’alignement de précision et la classification. Un environnement de développement offrant un menu interactif remplace la complexité de la programmation en simplifiant le développement et la maintenance, sans sacrifier les performances et la gamme des fonctionnalités.
Voici un aperçu global du programme réalisé par la caméra. On commence par faire une calibration de la caméra pour déterminer quelle est la longueur, en millimètres, d’un pixel. Par la suite, la caméra va attendre que le robot lui envoie une demande d’acquisition afin d’envoyer au robot les coordonnées des pièces. La caméra réalisera donc une inspection afin de déterminer les coordonnées des pièces afin de les envoyer au robot.
La calibration :
Pour faire la calibration de la caméra, on va demander à la caméra de détecter les deux objets qui se situent à gauche afin de déterminer la longueur, en pixels, qui séparent ces deux éléments.
Afin de déterminer cette distance et la convertir en millimètres, nous avons utilisé un bloc « calculator » qui n’est rien d’autre qu’un programme LabView. Dans ce programme on récupère donc les positions en Y de chacun des objets afin de les soustraire pour obtenir la distance qui les sépare selon l’axe Y. Sachant que cette distance est égale à 140mm il suffit de faire un produit en croix pour obtenir la longueur en millimètre d’un pixel.
Grâce à cela, il nous suffira de multiplier cette valeur par les coordonnées en pixels de chaque objet pour obtenir leur coordonnées en mm.
Une fois la calibration finie et que le robot a demandé à la caméra de lui envoyer les coordonnées des pièces, la caméra va réaliser plusieurs étapes afin de différencier les différentes pièces. Afin de déterminer si la pièce est carrée, ronde ou triangle il a fallu faire une détection d’objet et y rajouter des filtres afin d’être capable de ne détecter uniquement les objets de chaque famille.
Une fois que cela est fait on peut envoyer ces coordonnées au robot.
La Programmation du Robot : Suite Stäubli Robotics
Nous utilisons le logiciel Stäubli pour la programmation du robot c’est un logiciel de développement, de simulation, de maintenance, et de suivi d’applications robotisées. Stäubli Robotics Suite intègre des outils permettant la réalisation de simulation 3D (importation de modèles CAO, modélisation 3D, détection de collision, analyse d’accessibilité, mesure réaliste de temps de cycle), de programmation et débogage par le biais d’un éditeur de programme, de maintenance, et de suivi de la cellule robotisée avec des outils d’accès à distance.
Le programme que nous avons développé avec le robot est fait comme suit.
On commence tout d’abord par mettre le Robot sous tension puis on fait appel au Menu.
Une fois dans le Menu, on peut aller dans le sous Programme Recette :
Au sein du menu Recette on a la possibilité de saisir le nombre de pièces que nous souhaitons déplacer.
On saisit le nombre de pièces triangulaires, le nombre de pièces rectangulaires, le nombre de pièces pentagonales et le nombre de pièces étoilées.
Après la saisie des nombres de pièces on envoie une demande d’acquisition à la caméra. Cette dernière nous envoie les coordonnées des pièces sous forme de tableau.
C’est à partir de ce moment que s’exécute le programme déplacement des pièces en fonction de leur forme.
3. Partie Communication
La communication se fait donc comme suit : Le constituant le Client envoie une demande d’acquisition à la Caméra le serveur. La Caméra effectue l’acquisition et envoie les coordonnées au robot sous forme de tableau.
On a de ce fait les coords[0] et coords[1] qui constituent respectivement les coordonnées x et y des carrés ainsi de suite.
Ce projet nous a permis d’améliorer nos connaissances en programme robotique et vision industrielle. La programmation du robot ainsi que celle de la caméra n’était pas très compliqué. Ce qui nous a causé problème tout au long du projet c’est la communication entre la caméra et le robot.
Le robot ne comprenait pas le type de données que lui envoyait la caméra.
Étudiants en deuxième année de DUT Génie électrique et informatique industrielle, nous devons réaliser au sein de notre université, un projet de fin d’études.
Ce projet consiste en la réalisation d’une station météo autonome permettant de connaître différentes mesures grâce à des capteurs puis les consulter rapidement et simplement sur internet.
Notre objectif pour ce projet est de concevoir une station pouvant être placée à l’extérieur au sein de l’IUT.
II. Cahier des charges et organisation du projet :
1) Analyse fonctionnelle :
2) Cahier des charges :
La station météo devra intégrer les caractéristiques et les mesures du tableau ci-dessous.
Les données seront envoyés par le protocole MQTT vers un site qui fera office d’interface. Dans notre cas nous le ferons sur Adafruit.io
Les données doivent être consultables facilement et protégées pas un mot de passe et un identifiant.
L’archivage devra être conservée sur le site pendant un mois.
Mesure de la température
-30 à +50 °C
Mesure de la pression atmosphérique
500 hPa à 1100 hPa
Mesure de l’humidité de l’air
0% à 100%
Mesure de la luminosité
0% à 100%
Consultation des mesures
Dashboard Adafruit.io
Archivages des mesures
1 mois
Autonomie énergétique
1 année
3) Les matériels et les outils utilisés :
ESP8266 sur KIT Wemos D1
Capteur de température et d’humidité : DHT11
Photorésistance
Capteur de pression atmosphérique : BMP180
Carte shield pour les différents capteurs fixée sur le kit Wemos
Environnement Arduino IDE
Protocole de messagerie MQTT : Broker : Adafruit.io
Dashboard Adafruit.io
Module Lipo Raider
Batterie 2500 mAh 3.7 Volts
Panneau solaire 3.5 W 6 Volts
580mAh
4) Diagramme de Gantt :
5) Répartition des tâches :
Mustafa
Quentin
Gestion du capteur d’humidité
Recherche de composants
Gestion du capteur de pression
Gestion du capteur de luminosité
Gestion du capteur de température
Interface Adafruit.io
Calcul/test de l’autonomie
Création du boîtier
IV. Le projet :
Description détaillée :
Le but de ce projet est de réaliser une station météo qui sera placée à l’extérieur, dans l’enceinte de l’IUT. Cette station sera fait à partir d’un module ESP8266 (explication dans la partie 2) et permettra d’acquérir différentes mesures météorologiques grâces à des capteurs qui l’intègre (température, humidité, luminosité, pression atmosphérique). La station sera connectée à internet par une connexion Wi-Fi et les mesures seront envoyées vers le site Adafruit.io par un protocole MQTT. L’interface nous indiquera les différentes mesures qui seront archivées pendant un mois. La station sera autonome grâce à l’alimentation du module par un panneau solaire et une batterie lithium.
Les différentes étapes de réalisation sont les suivantes :
Compréhension du protocole MQTT.
Compréhension et utilisation de l’environnement de programmation ARDUINO IDE avec la carte qui contient le module wifi ESP8266.
Connexion au serveur/broker Adafruit.io via le module wifi ESP8266 (Arduino IDE).
Acquisition des mesures des différents capteurs sur le module ESP8266 (sans connexion Wi-Fi).
Envoie des mesures vers Adafruit.io via le module wifi de l’ESP8266.
Gestion de l’interface Adafruit.io.
Gestion de l’autonomie de la station météo.
Mise en forme du boîtier et test en conditions réelles.
1) MQTT, c’est quoi ?
MQTT est un protocole de messagerie « publish-subscribe » basé sur le protocole TCP/IP. Ce protocole suit un modèle de communication de type publication/abonnement via un broker (dans notre cas le serveur Adafruit.io). Pour publier un message il faut créer un topic (par exemple « GEII/température ») dans notre serveur et paramétrer la liaison avec ce topic dans le code. Le message envoyé vers ce topic pourra être lu en s’abonnant à ce topic sur notre interface . Donc si on veut réceptionner des messages, on s’abonne à un topic et on attend que quelqu’un envoie un message sur le même serveur et dans ce même topic.
Pour notre projet nous utiliserons un serveur gratuit de test : Adafruit.io.
Si on souhaite un jour améliorer ce projet nous pourrons toujours réfléchir à la création de notre propre serveur MQTT.
-> Pour plus de détails sur ce type de protocole et voir quelques exemples, vous pouvez visionnez la vidéo suivante :
2)L’ESP8266, c’est quoi ?
L’ESP8266 est un module Wi-Fi qui peut être utilisée de deux manières :
associé à un autre micro-controlleur (par exemple un Arduino), l’ESP8266 s’occupera juste de la partie « communication Wi-Fi ». L’Arduino va envoyer des commandes à l’ESP8266 (commandes comme « connecte-toi à tel réseau Wifi », « envoie tel message à tel serveur », etc.).
L’ESP8266 peut aussi être utilisé de manière totalement autonome, en exécutant lui-même des applications que vous aurez programmées. L’ESP8266 ne va pas se contenter d’ajouter des fonctionnalités Wi-Fi à votre Arduino, il va exécuter lui-même le programme Arduino, tout en prenant en compte la partie Wi-Fi. On ne charge plus votre programme sur l’Arduino, mais directement sur l’ESP8266. Cependant le nombre de port GPIOs sont limités.
Dans notre cas l’ESP8266 est sur un kit Wemos D1, il est donc associé à un autre microcontrôleur qui permet la programmation sur Arduino IDE et la connexion à un ordinateur par un cable USB 2.0. Pareillement, si on souhaite améliorer la station nous pouvons réfléchir à l’utlisation de l’ESP8266 de manière autonome.
3) Utilisation de l’environnement Arduino IDE :
Pour la prise en main de l’environnement Arduino nous avons commencé par réaliser de simples codes comme allumer/éteindre une led. Ensuite, nous avons programmé la connexion Wi-Fi du module ESP8266 et essayé de nous connecter à un serveur MQTT (mosquitto.org puis Adafruit.io). Une fois connecté nous avons crée des topics sur Adafruit.io sur lesquels on envoi des messages. Finalement nous avons travaillé sur la réception et l’interfaçage des messages reçus sur Adafruit.io.
Pour nous entraîner nous avons donc d’abord réalisé le montage ci-dessous qui permet d’allumer et éteindre une LED via notre smartphone connecté sur un topic mosquitto.org qui est lui-même connecté avec le module ESP8266.
Carte Wemos relié à une LED piloté depuis le smartphone :
Une fois l’environnement ARDUINO et MQTT maîtrisés, nous avons commencé la programmation de l’ESP8266 avec un capteur de température et d’humidité DHT11 et une photorésistance.
Le DHT11 et la photorésistance reliés à l’ESP8266 :
4) Connexion Wi-Fi et serveur Adafruit.io :
Pour se connecter au réseau Wi-Fi avec l’ESP8266 sur l’environnement arduino, on définit d’abord le nom du réseau et le mot de passe de celui-ci. Ensuite, il nous suffit d’entrer la fonction suivante et de vérifier son état :
WiFi.begin(SSID, PASSWORD); // lancement de la connexion
while(WiFi.status() != Connected) ; //attente de connexion
Pour se connecter au serveur MQTT Adafruit.io, on télécharge le code d’initialisation sur Adafruit.com et on entre le nom du serveur, notre identifiant, mot de passe et pour finir nos topics. Le port par défaut est 1883.
Paramétrage :
Souscription en tant que Publisher :
Nous nous souscrivons aux topics tempGEII, humidityGEII, luxGEII, pressionGEII et altitudeGEII en tant que publieur. C’est-à-dire que notre module Wi-Fi publie les messages vers le serveur Adafruit.io et que pour lire les message sur le serveur, on doit souscrire en tant qu’abonnés sur chaques topics précédemment énoncés.
Maintenant que nous sommes connecté à Adafruit.io avec notre module Wi-Fi, nous allons nous occuper de la gestion des capteurs des envois des mesures vers le serveurs.
5) Acquisition et envois des mesures des capteurs vers Adafruit.io :
Pour la gestion des capteurs, nous n’avons pas fait l’étude approfondie de chaque composant, nous nous sommes servi de composants adaptés pour l’environnement Arduino. Nous avons donc pris un DHT11 pour la lecture de la température et de l’humidité et une simple photorésistance.
Pour la gestion du DHT11 et l’envoi des mesures vers Adafruit.io il faut :
télécharger la libraire DHT.h
appeler la fonction dht.readHumidity() pour lire l’humidité
appeler la fonction dht.readTemperature() pour lire la température
envoyer les résultats vers les topics sur le serveur : TempGEII.publish(temperature); et HumidityGEII.publish(humidity);
Pour la gestion de la photorésistance et l’envoi des mesures vers Adafruit.io il faut :
brancher le capteur sur un port analogique
faire une lecture de ce port avec la fonction analogRead(number of the pin);
mettre le résultat en pourcentage avec un produit en croix.
envoyer le résultat vers le topic lux sur Adafruit.io : luxGEII.publish(lux);
Evidemment il est possible d’ajouter d’autres capteurs. Faute de budget nous en resterons en cela pour le moment.
Interface Adafruit.io :
6) Gestion de la consommation :
Pour que la station météo soit autonome elle va être alimentée par une batterie lithium qui va se recharger à l’aide d’un panneau solaire. Le panneau solaire, la carte et la batterie vont être reliés à un module Lipo Rider qui va permettre d’envoyer le courant reçu du panneau solaire vers la batterie et d’alimenter la carte avec une tension stable de 5V.
Pour mettre en place le bon panneau et la bonne batterie il faut connaître la consommation de notre carte. Pour cela nous branchons un ampèremètre en série sur notre carte alimenté et nous relevons le courant de consommation. Ce dernier est de 48mA.
Nous avons choisi de prendre une batterie lithium de 2500mAh ce qui veut dire que notre station peut tenir au maximum 52 heures sans être rechargé, ce qui suffit amplement pour tenir toute la nuit quand le panneau n’apportera aucun courant à la batterie.
Nous avons choisi de prendre un panneau solaire 3.5W et 6Volts car il est adapté à notre module Lipo Rider et c’est un produit à très bon rapport qualité prix. Il nous fournit au maximum courant de 580 mA ce qui est largement suffisant pour recharger notre batterie, même pendants une journée nuageuse.
Une fois le panneau reçu nous avons crée un support en bois pour celui-ci à l’IUT LAB avec l’aide de Monsieur Sabbata.
Support et panneau solaire :
7) Mise en boîte :
Le boîtier nous a été donné par notre entreprise (et nous les remercions). Nous l’avons modifié et ajouté une ouverture vitrée sur le dessus pour que la lumière puisse pénétrer et d’autres petites ouvertures pour que l’air puisse circuler à l’intérieur.
Les amélioration à apporter :
Le choix de ce boîtier n’est pas le meilleur car il est noir est donc absorbe la chaleur. De plus, lorsque que les températures augmentes et que le soleil est présent, comme le boîtier est vitré, les rayons du soleils entrent à l’intérieur… Il faudrait donc changer de boîtier et opter pour un boîtier blanc et une séparation alimentation/capteurs.
Le couvercle du boîtier :
Comme on peut le voir 4 visses on été ajoutés pour fixer fortement la vitre sur le couvercle et de la colle a été répandue tout autour pour ne pas laisser passer l’eau durant de fortes pluies.
Le boîtier final :
Une sortie isolée à été ajouté avec une prise USB mâle qui va venir sur brancher sur le panneau solaire.
Le meilleur endroit pour ce boîtier, à l’état actuel, serait de le placer à l’ombre (mais toujours à la lumière) tout en réussissant à placer le panneau solaire au soleil. Effectivement lors de journées ensoleillées les données sont faussées par la chaleur présente dans le boîtier.
V. Conclusion :
Le plus difficile a été la mise en place du protocole MQTT pour la liaison avec le publisher (ESP8266) et le subscriber (Dashboard Adafruit.io). Mais après plusieurs essais nous sommes parvenus a l’utiliser et une fois compris il a été assez facile de continuer avec ce protocole.
Si nous pouvions refaire ce projet, nous changerions le boîtier et sortirions le capteur de température puisque durant une journée bien ensoleillée, la température est faussée par la chaleur présente à l’intérieur de la boite. Ensuite, nous ajouterions d’autres capteurs comme la un pluviomètre et un anémomètre. Pour finir pour pourrions supprimer la carte Wemos D1 et n’utiliser que le module ESP8266 pour le rendre autonome et miniaturiser la station.
Nous tenons à remercier les professeurs qui étaient présents pour nous aider lorsque nous rencontrions des difficultés mais aussi l’IUT de nous avoir mis à disposition l’IUT LAB.
Tous les étudiants du GEII, en première année sont confronté à un challenge au cours de leurs deuxième semestre. Ils sont tenus de choisir un projet parmi quatorze sujets présentés, dans notre cas il s’agit du Vélo magnétique. Nous devons réaliser ce projet dans le cadre du module « Études & Réalisations », dont la notation comprend plusieurs facteurs, bien entendu la réalisation du projet, mais également la communication au sein du groupe, l’implication des différents membres, et la conduite du projet.
Les Intervenants du Projet Vélo Magnétique est Anthony PIVERT et Badr BOULBAIR.
Tout le monde (ou presque) aime faire du vélo, cela permet de s’entretenir, se déplacer écologiquement, ou tout simplement de se divertir au cours d’une balade. Dans tous les cas nous fournissons un effort physique, et donc de l’énergie. Mais il est difficile de quantifier, et même de pouvoir réutiliser cette énergie avec un vélo ordinaire. C’est pourquoi nous avons fait un vélo capable de vous montrer l’énergie que vous produisez en temps réel, et même d’utiliser cette énergie afin de : Charger son smartphone/allumer DES lampes/ et même utiliser des objets tel qu’une perceuse. Dans la seconde partie du projet nous avons fait en sorte que plus la personne qui pédale essayera d’aller vite plus la contrainte au niveau du pédalier sera grande (principe du vélo elliptique), par le principe du frein magnétique, tout en gardant un vélo utilisable par un large intervalle de personnes.
Cahier des charges
A) Diagramme Bête à corne:
La bête à cornes est un outil de représentation de questions fondamentales. (A qui rend il service, sur quoi agit-il, dans quel but)
B) Diagramme Pieuvre
Le diagramme pieuvre regroupe les fonctions principales ainsi que les principales contraintes du projet. Dans notre cas nous avons un diagramme qui peux être divisé en deux parties.
Diagramme globale:
FP1
Générer de l’énergie électrique en fonction de l’énergie mécanique produite
Etudiants de première année en département GEII à l’I.U.T de Mulhouse, nous avons eu la chance de pouvoir choisir entre différents sujets de projets proposés par les enseignants. Une fois les groupes réalisés, nous pouvions commencer à travailler sur un projet avec une grande liberté tout en aillant accès à l’aide des enseignants si besoin. Pendant 4 semaines, le but était à la fois de gérer la conduite du projet, l’étude et la réalisation de celui-ci.
Nous avons lancé le projet par une visite à l’école Freinet de Mulhouse. L’objectif était de faire découvrir aux enfants la robotique. Les enfants étaient prévenus de notre visite et avaient pour mission de nous dessiner le robot de leur rêve sur le thème de notre projet : « Robot Aquatique ». Nous sommes donc venus récupérer les dessins afin de nous donner une idée des robots que nous allions devoir réaliser.
Ce que nous avons retenu :
Faire un robot « observateur » capable de se déplacer de façon autonome et de filmer les environs.
Faire 2 robots « combattants » capables de tirer de l’eau l’un sur l’autre et créer un jeu autour de cela. Ces robots sont quant à eux commandés par des manettes, afin de laisser les enfants jouer avec.
Nous avons aussi pu leur faire construire des robots Lego, ainsi que leur montrer ce qu’était dans les grandes lignes la programmation sur ordinateur.
Collaboration avec les enfants de l’école Freinet afin de construire des robots qui répondent dans la mesure du possible aux attentes des élèves.
Des recherches ont été effectuées pour le choix des composants et sur la manière de construire les robots. Des tests de flottabilités ont également été effectués sur la coque confectionnée par les membres du groupe.
Acteurs :
Les enfants dans la recherche d’idées
Notre groupe de projet, soit : SEDIRI Aladin, FOUCAULT Antoine, LAVALLEE Arthur, DEVERCHIN Arnaud, DECKER-WURTZ Alexis, BERTRAND Christopher et GAECHTER Hugo dans les changements à apporter aux idées pour les rendre réalisables et les réaliser
Mr HUEBER et CHOISY en tant que profs référents
Besoins :
Connaissances techniques à acquérir dans la construction physique et la programmation des robots
Construire des robots fonctionnels tout en répondant aux attentes des enfants
Respecter les contraintes de sécurité, et celles imposées de coûts et de délais
But :
Ce projet à pour but de promouvoir le département GEII aux journées portes ouvertes, ainsi que de sensibiliser les enfants de l’école à la robotique. Il est important de montré que la robotique est une discipline qui nous intéresse et nous intrigue, c’est pourquoi ce projet est très apprécié car il nous permet de mettre en pratique tout ce qu’on connait de ce domaine, d’apprendre de nouvelles choses, tout en renvoyant pour le GEII l’image d’être un département qui innove dans ses méthodes d’apprentissage.
200e imposés, extensible si besoin en appelant l’aide d’autres groupes qui n’ont pas besoin de tout utiliser
Délais :
Première date butoir à la JPO (1 robot fonctionnel en partie au moins nécessaire)
Date à laquelle les enfants viennent, où tous les robots doivent être fonctionnels, testés et approuvés (date en attente)
Date de fin de projet à laquelle tout doit être fini et présentable (26 Juin)
Sécurité :
Celle des robots et des enfants, s’assurer de l’étanchéité des robots et empêcher des fuites de courant dans l’eau.
Les normes officielles de sécurité des enfants sont à la charge de l’école.
Aucune norme officielle ne nous concernent dans la construction de nos robots, on ne trouve que des normes concernant des robots industriels ce qui n’est pas notre cas.
Taille du groupe :
Nous sommes 7 à travailler ensembles sur le même projet, ce qui exige une organisation et répartition des tâches irréprochables pour ne pas rendre certains travaux infructueux. On se sert donc de Google Drive pour avoir un tableau des tâches que chacun doit faire et pour quand. Chacun peut écrire sur ce fichier pour rendre compte de l’avancement de ses travaux et ainsi éviter des mésententes au sein du groupe.
Faire découvrir aux enfants les possibilités mais aussi les limites de la robotique, tout en rendant le projet fun à découvrir à travers le contrôle des robots et d’un jeu.
Un pour avancer/reculer (Moteur courant continu) et le second pour tourner (Servomoteur)
Et 3 moteurs sur les robots combattants :
Un pour avancer/reculer (Moteur courant continu) et le second pour tourner (Servomoteur) et la pompe
Le problème rencontré dans les 2 cas était qu’une seule batterie ne suffisait pas, car lorsqu’on fait tourner tout les moteurs d’un bateau, la chute de tension provoquée était trop importante et faisait planter l’arduino.
Notre solution a été de mettre 2 batteries sur les bateaux :
Une de 9V pour alimenter l’arduino, arduino qui servira ensuite à alimenter le servomoteur
Une de 12V pour les autres moteurs (MCC pour l’observateur, MCC et pompe pour les combattants)
Nous voulions au départ récupérer une manette déjà existante, type voiture commandée, afin de récupérer le récepteur, le mettre sur notre bateau plutôt que sur la voiture et réutiliser ainsi un fonctionnement déjà créer et simplement l’adapter à notre besoin.
Seulement, les manettes récupérées ne marchaient pas bien, beaucoup de composants étaient manquants, nous avons rencontré énormément de problème en voulant opter pour cette solution et ils auraient étés trop longs à résoudre. De plus, nous n’aurions en rien créer la communication, et le but de ce projet n’est pas de récupérer mais de créer.
Finalement, nous avons donc rajouter un shield USB sur l’arduino et un donggle bluetooth associé à une manette de PS3, ce qui nous a fait programmer : Programmation Commande Bateau
Nous pensions avoir un problème puisque le donggle bluetooth utilisé ne fonctionnait pas, mais c’était finalement simplement un composant dessoudé, nous l’avons donc simplement ressoudé.
Nous voulions récupérer pour les 3 bateaux 3x les mêmes servomoteurs récupérables à l’I.U.T, mais pour les robots combattants nous avons rencontré un problème de conflit avec la manette. En effet, soit le programme du servomoteur prenait de le dessus et fonctionnait à l’instar de celui de la manette, soit l’inverse, le programme de la manette fonctionne mais pas celui du servomoteur.
On a finalement du en prendre 2 nouveaux pour les robots combattants afin de régler ce problème.
Cela a entraîné un nouveau problème : Comment programmer ces nouveaux servomoteurs, et où trouver les drivers, étant donné qu’ils ne sont pas faits pour être programmés via arduino.
Nous avons d’abord créer une pompe avec un petit moteur et des tubes, mais cela ne fonctionnait pas à 100% car nous avions un problème d’amorçage/réamorçage, nous étions obligés d’aspirer l’air bloqué dans la pompe afin de la lancer, et si l’angle de tir devenait trop important le même problème arrivait. Il était donc inenvisageable d’interrompre systématiquement le fonctionnement des robots.
Notre solution fut d’acheter de nouvelles pompes. En ce qui concerne le programme pour l’activer, nous avons trouvé un schéma électrique pour gérer un moteur à courant continu avec une pin de l’arduino
Cela comprenait une diode anti retour, 2 résistances et un transistor npn.
Ça ne fonctionnait pas.
On a donc essayé de rajouter un transistor npn supplémentaire qui piloterait le précédent, mais ça ne résolvait pas le problème.
La solution fut finalement de remplacer le 1er transistor npn par un relais 12V qui est lui-même piloté par un transistor npn.
Nous avions au départ un problème de batterie qui nous a même fait envisager d’enlever la caméra : en effet, la caméra s’éteignait au bout de quelques petites minutes. Finalement, nous avons changé de caméra et nous la rechargeons grâce à une batterie nomade en cas de besoin.
Nous avions aussi rencontré un autre problème qui empêchait cette nouvelle caméra de fonctionner, problème résolu par une mise à jour du firmware.
Etant donné notre effectif ( 7 personnes ) nous nous devions d’être rigoureux dans la gestion et l’administration des tâches. Nous avons pour cela créer un dossier Google Drive partagé entre nous, sur lequel nous nous sommes organiser pour être sur que tout le monde avance ensemble sur le projet, éviter que trop ou trop peu de personnes travaillent sur la même chose, et garder le fil quant à la direction que nous voulions donner au projet.
Pour reprendre notre projet, il faudra se référer au tableau budget afin d’identifier tout ce qui se trouve sur le bateau, et continuer de programmer différentes fonctions sur l’arduino en démarrant grâce à ce tutoriel qui explique les bases.
Ne pas oublier de bien regarder les caractéristiques des batteries pour savoir comment les rechargées.
Les robots étant faits pour des enfants, leur utilisation est très facile. Pour les robots combattants, il suffit de le brancher comme ceci la batterie et le moteur sur l’arduino :
Puis de contrôler les bateaux à l’aide des manettes.
Le robot observateur est autonome, il suffit donc de le poser dans l’eau et de lancer le moteur à l’aide du branchement vu précédemment.
Ces 4 semaines de projet nous ont appris à étudier pour directement mettre en application les notions vues, ce qui permet de mieux les acquérir et de pouvoir associé la théorie à la pratique.
Dans notre groupe de 7, nous avons aussi beaucoup travaillé afin de bien se répartir les tâches, de bien avancer ensemble et de profiter de notre effectif pour aller plus vite et plus loin dans le projet, pour éviter que cela se transforme en handicap et nous ralentisse.
Nous nous devions aussi d’aboutir à des résultats puisque nous nous sommes engagés auprès des enfants à leur fournir des robots qui fonctionnent et avec lesquels ils pourraient jouer, nous ne pouvions donc pas les décevoir.
Dans l’ensemble, nous avons rencontrés un bon nombre de problèmes de réalisations, étant donné que nous avions beaucoup de directions dans lesquelles nous pouvions aller, nous avons pris beaucoup de temps afin de bien définir le chemin que nous donnerions au projet, et nous avons rencontré plusieurs problèmes en chemin, essentiellement techniques dans la réalisation des robots et aussi dans la programmation. Cependant nous avons toujours trouvé des solutions à nos problèmes, et nous pourrions donc conclure en disant que notre plus gros problème fut de respecter les délais.
Ce projet nous a à tous beaucoup apporté, nous avons découvert tout ce qu’implique un projet lorsqu’on le mène de A à Z et on a pu se rendre compte de l’importance de la conduite de projet afin de ne pas perdre le fil malgré tout les imprévus qui peuvent intervenir.
Dans le cadre de notre formation de première année de DUT GEII (Génie Electrique et Informatique Industrielle), le module Etudes et Réalisation (Projets) doit être réalisé. Nous avons eu la possibilité de choisir le projet qui nous intéressait le plus. Pendant 4 semaines, de mars à avril, l’emploi du temps a été grandement consacré à cela. Nous étions encadrés par des professeurs qui étaient à notre disposition et qui nous ont notés sur nos recherches et notre avancement.
Présentation du sujet
La Maquette Domotique est un ancien projet inachevé commencé il y a 2 ans, nous l’avons repris pour le continuer et le finaliser. Nous avons donc dû résoudre les problèmes rencontrés par nos prédécesseurs.
Par le biais de notre Maquette Domotique, nous devons sensibiliser les personnes sur les « énergies de demain » en simulant une maison totalement autonome énergiquement grâce aux énergies renouvelables.
Nous disposons des énergies suivantes:
-Éolien : Utilisation d’une éolienne domestique.
-Solaire : Installation de panneaux photovoltaïques ainsi que thermiques.
-Hydraulique : Cours d’eau présent afin d’alimenter une turbine hydraulique.
-Biomasse : Combustion des bio-déchets.
-Bois : Combustion de bois dans un foyer bois.
Sur la maquette, l’éolienne et la turbine hydraulique fonctionnent grâce à des moteurs.
Répartition des systèmes de production des énergies renouvelables
Nous devons rendre notre maquette à la fois démonstrative et ludique afin de plaire au public.
Gestion de Projet
Nous sommes suivis par un professeur, dans la matière « Conduite de projet », qui nous apprend à travailler sur des projets en général. Nous avons ainsi à faire les démarches, les explications et les présentations du projet.
Nous avons appris à planifier nos semaines pour y associer les tâches à effectuer chaque jour et ainsi éviter le plus possible les écarts.
Pour cela nous sommes un groupe de 4 étudiants :
-Maillard Guillaume : Chef de projet
-Muller Quentin
-Perreaut Romain
-Sutter Valentin
Cahier des Charges
Schéma « Bête à corne » :
Schéma « Pieuvre » : Fonction du projet
Fonction Principale : Rendre notre Maquette attractive afin de sensibiliser le public sur l’utilisation des énergies renouvelables.
Fonctions Contraintes : Nous devons prendre en compte les contraintes pour faire de notre maquette un projet rentable, intéressant et pédagogique.
Circuit de l’alimentation
Circuit de la régulation
Circuit de l’AOP
Projet
Définition du repère de la caméra :
C
Ceci est le capteur infrarouge 4. Dès qu’il voit un obstacle, il renvoi une valeur entre 0 et 2.54. S’il revoie 2.54 c’est que le capteur IR4 est presque au contact de l’obstacle.
Comme on peut le voir sur l’image ci dessus, le Raspberry Pi 3 comporte 3 Ports USB et une prise Ethernet. On peut voir qu’il dispose également de ports GPIO qui peuvent être utilisés comme entrée/sortie. Il est également équipé d’une carte Wifi et du Bluetooth.
Nous retrouvons donc les subscriber et les publisher. Cependant nous avons un également le broker MQTT, c’est un serveur qui permettra de faire passer les messages entre les différents clients.
Afin de commander le servomoteur nous lui envoyons des impulsions ce qui lui permet dans une position. Pour cela nous définissons un angle dans lequel le servomoteur doit se positionner.
Grafcet de tâche du perçage
Ce composant a été de loin le plus simple a choisir. Le contrôleur de vol est la carte mère du drone, le modèle NAZE 32, est un des plus réputé et des plus utilisé. Il permet d’embarquer une caméra et est très modulable en fonction des options voulues. Nous pouvons ajouter toute sorte de capteur télémétrique permettant de la prise de donnée dans des endroits inaccessible.
Les hélices sont choisies en fonction des moteurs. L’idéal dans notre cas est donc hélices 5“.
Pour le choix de la batterie, nous nous sommes appuyé sur l’expérience d’autre utilisateurs pour faire notre choix. Les caractéristique technique de la batterie doivent correspondre aux éléments qu’elle alimente. Afin d’avoir une autonomie raisonnable, nous avons choisis une batterie de 1500 mAh. Nous nous sommes assuré que les connectiques correspondent à notre carte électronique et au chargeur.
La caméra est de résolution modeste mais largement suffisante pour le pilotage. Nous avons opté pour un capteur CCD pour ne pas avoir l’effet rolling shutter. Le capteur dispose d’un champ de vision de 148°. Un émetteur avec une fréquence de 5,8 GHz est nécessaire pour ne pas interférer avec les fréquences des commandes qui sont en 2,4 GHz.
Le raspberry pi 0. Nous l’avons choisi notamment pour sa taille très réduite et sa consommation minime, parfaite pour concevoir un appareil avec une bonne durée de vie.
L’enviroPHAT, qui est une carte d’extention du raspberry pi 0. Cette carte rassemble une grande partie des capteurs dont nous avions besoin pour mesurer :
Voici un aperçu global du programme réalisé par la caméra. On commence par faire une calibration de la caméra pour déterminer quelle est la longueur, en millimètres, d’un pixel. Par la suite, la caméra va attendre que le robot lui envoie une demande d’acquisition afin d’envoyer au robot les coordonnées des pièces. La caméra réalisera donc une inspection afin de déterminer les coordonnées des pièces afin de les envoyer au robot.
La communication se fait donc comme suit : Le constituant le Client envoie une demande d’acquisition à la Caméra le serveur. La Caméra effectue l’acquisition et envoie les coordonnées au robot sous forme de tableau.
