Wiki de Projets IMA - Contributions de l’utilisateur [fr]

Fichier:RapportPFE ROYER MORISSE.pdf

2016-02-23T11:25:52Z

Mmorisse :

Projets IMA5 2015/2016

2016-02-23T11:25:35Z

Mmorisse : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> [[Fichier: Dossier_soutenance_P2_Data_Logger_Hideo_VINOT_IMA5SC_2015.pdf]]</td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> RDV pris le 23/02 avec L. Engels</td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> [[Fichier:PFE_Final_TENEUR_LIBAERT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> [[Fichier:FYP-P10-Lilliad-MSEKAR.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> [[Fichier:Rapport_PFE_P14_Matthieu_Marcadet.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> [[Fichier:Rapport_P18_COLAUTTI_LEFORT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> [[Fichier:IMA5-ASSP-JWPL.pdf]]</td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> [[Fichier:Rapport_final_P25_Smagghe_Tournier.pdf]]</td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td>Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td>[[Fichier:RapportPFE_ROYER_MORISSE.pdf]] </td>
<td> mardi 23 février à 11h15 avec Laurent Engels</td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> [[Fichier:Rapport_final_PFE_TISSOT_TIRABY.pdf]] </td>
<td> Tournée le 19/02 par L. Engels </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> [[Fichier:Rapport_P32_Sultana.pdf]]</td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> [[Fichier:IMA5_P40_Chauchard_Imbert_RapportFinal.pdf‎]] </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> [[Fichier:PFE_P13-Plateforme_expérimentation.pdf]]</td>
<td> Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

Projets IMA5 2015/2016

2016-02-23T11:24:40Z

Mmorisse : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> [[Fichier: Dossier_soutenance_P2_Data_Logger_Hideo_VINOT_IMA5SC_2015.pdf]]</td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> RDV pris le 23/02 avec L. Engels</td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> [[Fichier:PFE_Final_TENEUR_LIBAERT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> [[Fichier:FYP-P10-Lilliad-MSEKAR.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> [[Fichier:Rapport_PFE_P14_Matthieu_Marcadet.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> [[Fichier:Rapport_P18_COLAUTTI_LEFORT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> [[Fichier:IMA5-ASSP-JWPL.pdf]]</td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> [[Fichier:Rapport_final_P25_Smagghe_Tournier.pdf]]</td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td>[[Fichier:RapportPFE_ROYER_MORISSE.jpg]] </td>
<td> mardi 23 février à 11h15 avec Laurent Engels</td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> [[Fichier:Rapport_final_PFE_TISSOT_TIRABY.pdf]] </td>
<td> Tournée le 19/02 par L. Engels </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> [[Fichier:Rapport_P32_Sultana.pdf]]</td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> [[Fichier:IMA5_P40_Chauchard_Imbert_RapportFinal.pdf‎]] </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> [[Fichier:PFE_P13-Plateforme_expérimentation.pdf]]</td>
<td> Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

P27 Robot de fraiseuse

2016-02-19T14:13:19Z

Mmorisse :

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

Toutes les trajectoires ont été terminées. De plus, à partir de cette semaine, nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

Nous avons également commencé la réalisation d'un code permettant de lancer les trajectoires souhaitées en fonction des choix fait dans l'IHM.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

La réalisation du code faisant la liaison entre l'IHM et les trajectoires est plus compliqué que prévu. Nous avons des problèmes pour faire l'appel de nos programmes ainsi que pour la réalisation de nos boucles.

=== Semaine du 15 au 19 février 2016 ===

Tests concernant la communication entre l'interface et le robot à l'aide de la librairie CrossCom qui nous a été conseillée par Kuka.
Cette librairie est disponible uniquement en Visual Basic 6 et l'absence de documentation rend son utilisation difficile. Nous arrivons à récupérer le ''path'' de nos fichiers sur le robot via cette librairie mais il reste impossible de les exécuter. Différentes syntaxes on été testées pour lancer un programme, sans succès pour l'instant.

Le code principale permettant l’exécution des sous programmes est réalisé et la communication fonctionne.

P27 Robot de fraiseuse

2016-02-16T12:56:49Z

Mmorisse : /* Semaine du 8 au 12 février 2016 */

P27 Robot de fraiseuse

2016-02-16T12:54:59Z

Mmorisse : /* Semaine du 1 au 5 février 2016 */

P27 Robot de fraiseuse

2016-02-16T12:53:22Z

Mmorisse : /* Semaine du 25 au 29 janvier 2016 */

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

Toutes les trajectoires ont été terminées. De plus, à partir de cette semaine, nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

P27 Robot de fraiseuse

2016-02-16T12:52:24Z

Mmorisse : /* Semaine du 18 au 22 janvier 2016 */

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

A partir de cette semaine nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

Thermomètre connecté

2016-01-21T08:28:57Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth BLE. La communication BLE (Bluetooth Low Energie) permet de communiquer entre plusieurs objets connectés pour lesquels le besoin en débit de transmission de données est faible.
De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

[[Fichier:ComBLE.png|center|400px]]

Le code actuel nous permet de détecter les composants connectés en Bluetooth. Cependant, nous avons un problème. En effet, nous n'arrivons pas à recevoir les données émises par notre RFDuino.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Commencement de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T08:23:57Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth BLE. La communication BLE (Bluetooth Low Energie) permet de communiquer entre plusieurs objets connectés pour lesquels le besoin en débit de transmission de données est faible.
De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

[[Fichier:ComBLE.png|center|400px]]

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Commencement de l'application Android

===Séance 5 ===

Fichier:ComBLE.png

2016-01-21T08:23:12Z

Mmorisse :

Thermomètre connecté

2016-01-21T08:22:53Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth BLE. La communication BLE (Bluetooth Low Energie) permet de communiquer entre plusieurs objets connectés pour lesquels le besoin en débit de transmission de données est faible.
De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

[[Fichier:ComBLE.jpg|center|400px]]

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Commencement de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T07:58:14Z

Mmorisse : /* Séance 4 */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth BLE. La communication BLE (Bluetooth Low Energie) permet de communiquer entre plusieurs objets connectés pour lesquels le besoin en débit de transmission de données est faible.
De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Commencement de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T07:57:04Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth BLE. La communication BLE (Bluetooth Low Energie) permet de communiquer entre plusieurs objets connectés pour lesquels le besoin en débit de transmission de données est faible.
De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Réalisation de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T07:41:44Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_ULPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Réalisation de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T07:41:26Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (RFDuino_UFPDelay). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Réalisation de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-21T07:41:00Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Le code se décompose en deux parties. La première consiste en la récupération et l'envoie des données tandis que la deuxième sert à la gestion de l'énergie. En effet, le RFDuino se réveille toutes les 3 secondes (Blblt). Nous avions pensé utiliser une pin pour réveiller le RFDuino en applicant une tension sur une pin préalablement configuré. Cependant, n'ayant pas de composant supplémentaire nous avons préféré utiliser la première méthode.

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Réalisation de l'application Android

===Séance 5 ===

Option Internet des objets 2015/2016

2016-01-20T13:20:32Z

Mmorisse : /* Répartition des binômes */

== Projets ==

Les différents projets proposés ont pour but de réaliser un objet connecté de A à Z. Les objets seront dans la mesure du possible interopérables, soit directement, soit par l'intermédiaire d'un "point d'accès". Différentes problématiques relatives à l'Internet des Objets sont listées ci-dessous. Chaque projet devra intégrer une réflexion sur - au minimum - deux points de cette liste ; tous les points devront être abordés au travers de l'ensemble des projets.

Problématiques (techniques) principales rencontrées dans l'Internet des Objets et les réseaux de capteurs :

* Gestion d'énergie (mode veille et réveil des objets),
* Routage orienté économie d'énergie,
* Lien entre les objets connectés et l'Internet,
* Apport de la localisation,
* Stockage des données et leur représentation,
* Sécurité,
* Mise à jour du code embarqué,
* Distribution du traitement de l'information (object, fog, cloud).

Quelques idées d'objets connectés pouvant être réalisés ; d'autres projets peuvent être proposés (cf. liste matériel disponible) :
* Timer Connecté pour gérer les temps de paroles lors des soutenances (projets, stage, ...)
* Compteur de tour de piste. Lors d'un entrainement sur une piste d'athlétisme il est parfois difficile de compter le nombre de tour de piste effectué tout en réalisant les entraînements. L'idée est donc d'avoir un artefact attaché à la main, muni de boutons poussoir et d'un afficheur. A chaque bouton poussoir est attaché une fonction logiciel (ajouter un tour, remettre à zero, ...)
* Lampe de chevet connectée
* Visualisation de la qualité de l'air avec des artefacts interactifs
* Lampes connectées permettant de réfleter l'état du public dans un amphi lors d'un cours ou d'une soutenance
* Tee shirt augmenté
* "Caillou" connecté
* Boules décoratives connectées : en fonction de la distance entre les différentes boules, leur couleur change
* Sac à dos pour cycliste avec indicateurs de direction
* Réseau de capteurs pour suivi de l'environnement des salles de projets
* Sous-bock connecté
* ...

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Sous bock connecté]] || Benjamin LEFORT, Kevin COLAUTTI, Jean-Michel TOURNIER
|-
| [[Réseau de capteurs]] || Alexandre Jouy, Romain Libaert
|-
| [[Thermomètre connecté]] || Flavien Royer, Maxime Morisse
|-
| [[Réseau de lampes]] || Sandra HAGE, Julien HERIN
|-
| [[Brosse à dents intelligente]] || Elise TISSOT, Celine TIRABY
|-
| [[T Shirt d'ambiance connecté]] || Jean Wasilewski, Pierre Letousey
|-
| [[Enceintes Bluetooth connectées]] || Mehdi BAKALI, Antonin BRONNER, Jérôme SONTAG
|-
| [[Compteur de tour de piste]] || Jérôme Bailet, Mageshwaran Sekar
|-
| [[Lampe connectée]] || Mourad EL GHISSASSI, Yacine RACHIDI, Rudy ZANOTTI
|-
| [[Station météo connectée]] || Thibaut SCHOLAERT, Mehdi ZEGGAÏ
|-
| [[Clip&Connect - Actionneur domotique multifonction]] || Kev Franche, Flo Monange, Ben Descombes
|-
| [[Capteur UV connecté]] || Simon DELVARRE, Sanaa TOURBY

Option Internet des objets 2015/2016

2016-01-20T13:19:59Z

Mmorisse : /* Répartition des binômes */

== Projets ==

Les différents projets proposés ont pour but de réaliser un objet connecté de A à Z. Les objets seront dans la mesure du possible interopérables, soit directement, soit par l'intermédiaire d'un "point d'accès". Différentes problématiques relatives à l'Internet des Objets sont listées ci-dessous. Chaque projet devra intégrer une réflexion sur - au minimum - deux points de cette liste ; tous les points devront être abordés au travers de l'ensemble des projets.

Problématiques (techniques) principales rencontrées dans l'Internet des Objets et les réseaux de capteurs :

* Gestion d'énergie (mode veille et réveil des objets),
* Routage orienté économie d'énergie,
* Lien entre les objets connectés et l'Internet,
* Apport de la localisation,
* Stockage des données et leur représentation,
* Sécurité,
* Mise à jour du code embarqué,
* Distribution du traitement de l'information (object, fog, cloud).

Quelques idées d'objets connectés pouvant être réalisés ; d'autres projets peuvent être proposés (cf. liste matériel disponible) :
* Timer Connecté pour gérer les temps de paroles lors des soutenances (projets, stage, ...)
* Compteur de tour de piste. Lors d'un entrainement sur une piste d'athlétisme il est parfois difficile de compter le nombre de tour de piste effectué tout en réalisant les entraînements. L'idée est donc d'avoir un artefact attaché à la main, muni de boutons poussoir et d'un afficheur. A chaque bouton poussoir est attaché une fonction logiciel (ajouter un tour, remettre à zero, ...)
* Lampe de chevet connectée
* Visualisation de la qualité de l'air avec des artefacts interactifs
* Lampes connectées permettant de réfleter l'état du public dans un amphi lors d'un cours ou d'une soutenance
* Tee shirt augmenté
* "Caillou" connecté
* Boules décoratives connectées : en fonction de la distance entre les différentes boules, leur couleur change
* Sac à dos pour cycliste avec indicateurs de direction
* Réseau de capteurs pour suivi de l'environnement des salles de projets
* Sous-bock connecté
* ...

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Sous bock connecté]] || Benjamin LEFORT, Kevin COLAUTTI, Jean-Michel TOURNIER
|-
| [[Réseau de capteurs]] || Alexandre Jouy, Romain Libaert
|-
| [[Cuillère connecté]] || Flavien Royer, Maxime Morisse
|-
| [[Réseau de lampes]] || Sandra HAGE, Julien HERIN
|-
| [[Brosse à dents intelligente]] || Elise TISSOT, Celine TIRABY
|-
| [[T Shirt d'ambiance connecté]] || Jean Wasilewski, Pierre Letousey
|-
| [[Enceintes Bluetooth connectées]] || Mehdi BAKALI, Antonin BRONNER, Jérôme SONTAG
|-
| [[Compteur de tour de piste]] || Jérôme Bailet, Mageshwaran Sekar
|-
| [[Lampe connectée]] || Mourad EL GHISSASSI, Yacine RACHIDI, Rudy ZANOTTI
|-
| [[Station météo connectée]] || Thibaut SCHOLAERT, Mehdi ZEGGAÏ
|-
| [[Clip&Connect - Actionneur domotique multifonction]] || Kev Franche, Flo Monange, Ben Descombes
|-
| [[Capteur UV connecté]] || Simon DELVARRE, Sanaa TOURBY

Thermomètre connecté

2016-01-20T10:47:48Z

Mmorisse : /* Séance 4 */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===

* Réalisation de l'application Android

===Séance 5 ===

Thermomètre connecté

2016-01-20T10:46:50Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Partie 2 : Carte électronique 

La carte comprends une source de tension, un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60µA. Pour le RFDuino, son courant est de 18mA et il est alimenté entre 1.9 et 3.6V. Ainsi, la consommation du système est d'un peu moins de 60mW en utilisation normale. Cependant, nous avons vu précédemment que le RFDuino ne fonctionnait que quelques millisecondes toutes les 3 secondes. Cela signifie que le module permettant la recharge de la batterie peut être plus petit.
Ainsi avec un module de 40*40 mm, il est possible de générer un courant de 470mA et une tension de 2,4V.En couplant ce dispositif avec un hacheur élévateur de tension il serait possible d'alimenter notre système avec juste le module Peltier.

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===
===Séance 5 ===

Thermomètre connecté

2016-01-20T10:15:43Z

Mmorisse : /* Étapes du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au maximum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

Ainsi, ce projet permet de faire de la gestion d'énergie (mode veille) et d'un routage orienté économie d'énergie (Utilisation de l'effet Peltier)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Rechargement de la source de tension : Dissipateur Peltier
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

Le projet peut se décomposer en deux phases distinctes. La première consiste à réaliser le code du RFDuino. La deuxième partie consiste à réaliser une carte afin de relever la température du café et d'envoyer cette donnée au RFDuino. Enfin, la dernière partie permettra de communiquer entre le téléphone et le RFDuino.

Partie : Code RFDuino 

Le code présent dans le RFDuino doit permettre la gestion d'un mode veille afin de limiter au maximum la consommation. La plupart du temps, le RFDuino sera inactif et pendant quelques millisecondes il recevra les données provenant du capteur de température et les transmettra au téléphone (si le BLE est activé sur le téléphone). le code réalisé est le suivant :

[[Fichier:CodeIDE.png|center|upright=0.8|]]

Partie 2 : Carte électronique 

La carte comprends une source de courant/tension/A choisir , un module Peltier permettant de recharger la source et le capteur de température. Le capteur de température est linéaire et nécessite juste un ajustement car il se trouve en contact avec la paroi interne du thermomètre et non en contact avec le café. Une liaison entre la sortie du capteur de température et le RFDuino permettra la conversion de la tension de sortie ( 0mV -> 2°C et +/- 10mV/°C ).

[[Fichier:Capteurlel.jpg|center|200px]]

Le capteur utilisé est un capteur de température LM35 qui peut être alimenté entre 5 et 30V. Le courant qui le parcours est de 60<math>/micro</math>

Partie 3 : Communication RFDuino / Téléphone

La communication entre le RFDuino et le téléphone se fait par bluetooth. De plus, une application Android permet la réception des données et demande à l'utilisateur la température souhaité pour son café. A partir de ces deux données, il est possible d'en déduire le temps d'attente pour boire son café.

==Suivi de l'avancement du Projet==

===Séance 1 ===

* Récupération des différents composants
* Recherche d'informations
* Tentative de codage en C. Après divers problèmes, le code sera fait sous l'IDE dans un premier temps (modification en C si le temps le permet).

===Séance 2 ===

* Réalisation du code permettant la réception des températures
* Étude de la consommation globale du système

===Séance 3 ===

* Recherche d'informations et réalisation du mode veille
* Difficultés pour l'installation du logiciel pour l'application Android

===Séance 4 ===
===Séance 5 ===

Thermomètre connecté

2016-01-20T10:12:42Z

Mmorisse : /* Étapes du projet */

Fichier:Capteurlel.jpg

2016-01-20T10:12:08Z

Mmorisse :

Thermomètre connecté

2016-01-20T10:11:52Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-20T10:11:03Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-20T10:05:23Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-20T10:03:11Z

Mmorisse : /* Étapes du projet */

Fichier:CodeIDE.png

2016-01-20T10:02:41Z

Mmorisse : a téléversé une nouvelle version de « Fichier:CodeIDE.png »

Thermomètre connecté

2016-01-20T10:00:08Z

Mmorisse : /* Étapes du projet */

Fichier:CodeIDE.png

2016-01-20T09:59:20Z

Mmorisse :

Thermomètre connecté

2016-01-20T09:50:05Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-20T09:48:35Z

Mmorisse : /* Séance 3 */

Thermomètre connecté

2016-01-20T09:47:33Z

Mmorisse : /* Séance 3 */

Thermomètre connecté

2016-01-20T09:43:46Z

Mmorisse : /* Séance 2 */

Thermomètre connecté

2016-01-20T09:41:10Z

Mmorisse : /* Séance 2 */

Thermomètre connecté

2016-01-06T16:10:03Z

Mmorisse : /* Séance 1 */

Thermomètre connecté

2016-01-06T16:07:53Z

Mmorisse : /* Objectif du projet */

Thermomètre connecté

2016-01-06T16:05:55Z

Mmorisse : /* Cahier des charges */

Thermomètre connecté

2016-01-06T16:02:31Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-06T15:47:51Z

Mmorisse : /* Choix techniques : matériel et logiciel */

Thermomètre connecté

2016-01-06T15:46:45Z

Mmorisse : /* Étapes du projet */

Thermomètre connecté

2016-01-06T13:13:51Z

Mmorisse : /* Cahier des charges */

Thermomètre connecté

2016-01-06T12:54:56Z

Mmorisse : /* Cahier des charges */

Thermomètre connecté

2016-01-06T12:54:27Z

Mmorisse : /* Cahier des charges */

Thermomètre connecté

2016-01-06T12:53:19Z

Mmorisse :

Thermomètre connecté

2016-01-06T09:12:19Z

Mmorisse : Page créée avec « ==Cahier des charges== ===Présentation générale du projet=== ====Contexte==== ====Objectif du projet==== ====Description du projet==== ====Choix techniques : matérie... »

==Cahier des charges==
===Présentation générale du projet===

====Contexte====

====Objectif du projet====

====Description du projet====

====Choix techniques : matériel et logiciel====

==Étapes du projet==

Partie 1 : 

Partie 2 : 

Partie 3 : 

==Suivi de l'avancement du Projet==

===Séance 1 ===
===Séance 2 ===
===Séance 3 ===
===Séance 4 ===
===Séance 5 ===

Option Internet des objets 2015/2016

2016-01-06T09:11:18Z

Mmorisse : /* Répartition des binômes */

Fichier:Rapport Royer Morisse.pdf

2015-12-15T15:36:25Z

Mmorisse : a téléversé une nouvelle version de « Fichier:Rapport Royer Morisse.pdf »

Fichier:Rapport Royer Morisse.pdf

2015-12-15T12:20:29Z

Mmorisse :