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

IMA4 2016/2017 P27

2017-05-11T21:24:31Z

Bgriller : /* Fichiers Rendus */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures Travail additionnel !! Total
|-
| Définition cahier des charges
| 3
|
|
|
|
|
|
|
|
|
|
|
| 3
|-
| Recherche sur la législation et analyse fonctionnelle
|
| 2
| 2
|
|
|
|
|
|
|
|
|
| 4
|-
| Installation et configuration réseau de la Raspberry Pi 2
|
| 4
| 4
| 4
|
|
|
|
|
|
|
|
| 12
|-
| Conception PCB (mise en place des bibliothèques)
|
|
|
| 6
|
|
|
|
|
|
|
|
| 6
|-
| Conception PCB (routage)
|
|
|
|
| 8
| 8
|
|
|
|
|
|
| 16
|-
| Prise en main liaison I2C
|
|
|
|
|
| 4
| 4
| 4
|
|
|
|
| 12
|-
| Programmation des modules LoRa
|
|
|
|
|
|
| 4
|
|
| 4
|
|
| 8
|-
| Travail sur le module GPS
|
|
|
|
|
|
|
| 4
| 4
| 4
|
| 9
| 21
|-
| Programmation Raspberry Pi
|
|
|
|
|
|
|
| 4
| 4
| 8
| 8
| 9
| 33
|-
| Travaux finaux (rédaction rapport, commentaire du code et préparation soutenance)
|
|
|
|
|
|
|
|
|
|
|
| 10
| 10
|-
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.
[[Fichier:Donnees GPS.PNG|400px|thumb|left|Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"]]
 

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

===Travail additionnel===
*Etant donné le caractère bloquant des fonctions fscanf et fprintf servant à lire sur les liaisons séries de la Raspberry Pi, nous les remplaçons par les fonctions read et write qui se passent de buffer pour fonctionner. Le paramètre ''O_NONBLOCK'' est donc ajouté à la liste des drapeaux lors de la configuration des ports. Cela permet maintenant à la Raspberry présente dans la nacelle de dérouler son programme en l'absence de requêtes venant du sol.
*Tests de portée des modules LoRa Feather. Nous confirmons la portée indiquée dans la documentation (qui est d'environ 2 km sans obstacles entre les deux antennes).
*Conception et fabrication d'une nacelle en bois usiné à la découpeuse laser.
*Utilisation d'une carte Arduino MEGA2560 en tant que solution provisoire pour récupérer les données du capteur de pression. La liaison SPI étant plus complexe que prévu à gérer avec la Raspberry Pi.

== Fichiers Rendus ==

*Rapport final : [[Fichier:Rapport_P27_GRILLERE_MAHIEUX.pdf]]

*Codes disponible sur le dépôt Git suivant: https://archives.plil.fr/bgriller/ballon_atmospherique/

Fichier:Rapport P27 GRILLERE MAHIEUX.pdf

2017-05-11T21:14:59Z

Bgriller : Rapport final

Rapport final

IMA4 2016/2017 P27

2017-05-06T15:57:23Z

Bgriller : /* Travail additionnel */

IMA4 2016/2017 P27

2017-05-06T15:41:11Z

Bgriller : /* Feuille d'heures */

IMA4 2016/2017 P27

2017-05-06T15:31:10Z

Bgriller : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures Travail additionnel !! Total
|-
| Définition cahier des charges
| 3
|
|
|
|
|
|
|
|
|
|
|
| 3
|-
| Recherche sur la législation et analyse fonctionnelle
|
| 2
| 2
|
|
|
|
|
|
|
|
|
| 4
|-
| Installation et configuration réseau de la Raspberry Pi 2
|
| 4
| 4
| 4
|
|
|
|
|
|
|
|
| 4
|-
| Conception PCB (mise en place des bibliothèques)
|
|
|
| 6
|
|
|
|
|
|
|
|
| 6
|-
| Conception PCB (routage)
|
|
|
|
| 8
| 8
|
|
|
|
|
|
| 16
|-
| Prise en main liaison I2C
|
|
|
|
|
| 4
| 4
| 4
|
|
|
|
| 12
|-
| Programmation des modules LoRa
|
|
|
|
|
|
| 4
|
|
| 4
|
|
| 8
|-
| Travail sur le module GPS
|
|
|
|
|
|
|
|
| 8
| 4
|
| 9
| 21
|-
| Programmation Raspberry Pi
|
|
|
|
|
|
|
|
| 8
| 8
| 8
| 9
| 33
|-
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.
[[Fichier:Donnees GPS.PNG|400px|thumb|left|Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"]]
 

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

===Travail additionnel===
*Etant donné le caractère bloquant des fonctions fscanf et fprintf servant à lire sur les liaisons séries de la Raspberry Pi, nous les remplaçons par les fonctions read et write qui se passent de buffer pour fonctionner. Le paramètre ''O_NONBLOCK'' est donc ajouté à la liste des drapeaux lors de la configuration des ports. Cela permet maintenant à la Raspberry présente dans la nacelle de dérouler son programme en l'absence de requêtes venant du sol.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-18T15:27:54Z

Bgriller : /* Avancement du Projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.
[[Fichier:Donnees GPS.PNG|400px|thumb|left|Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"]]
 

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

===Travail additionnel===
*Etant donné le caractère bloquant des fonctions fscanf et fprintf servant à lire sur les liaisons séries de la Raspberry Pi, nous les remplaçons par les fonctions read et write qui se passent de buffer pour fonctionner. Le paramètre ''O_NONBLOCK'' est donc ajouté à la liste des drapeaux lors de la configuration des ports. Cela permet maintenant à la Raspberry présente dans la nacelle de dérouler son programme en l'absence de requêtes venant du sol.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-11T12:47:18Z

Bgriller : /* Avancement du Projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.
[[Fichier:Donnees GPS.PNG|400px|thumb|left|Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"]]
 

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-11T12:45:33Z

Bgriller : /* Semaine 9 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.
[[Fichier:Donnees GPS.PNG|400px|thumb|left|Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"]]

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

== Fichiers Rendus ==

Fichier:Donnees GPS.PNG

2017-04-11T12:38:47Z

Bgriller : exécution du programme C dans la Raspberry Pi: demande et lecture d'envoi de données GPS.

exécution du programme C dans la Raspberry Pi: demande et lecture d'envoi de données GPS.

IMA4 2016/2017 P27

2017-04-11T12:33:53Z

Bgriller : /* Avancement du Projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

===Semaine 10===
*Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-11T12:21:00Z

Bgriller : /* Semaine 9 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

===Semaine 9===
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-11T12:20:39Z

Bgriller : /* Semaine 8 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

===Semaine 8===
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

==Semaine 9==
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-02T13:46:07Z

Bgriller : /* Semaine 6 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

==Semaine 8==
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

==Semaine 9==
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-02T13:38:00Z

Bgriller : /* Avancement du Projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

====Description du système ====
Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon.
S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

====Composition de la nacelle====
Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

====Choix techniques : matériel et logiciel====
* Electronique embarquée :
Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa.
Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD.
De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol.
Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

* Structure de la nacelle :
Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable.
De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement.
Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====
Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:
*l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
*les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
*le dimensionnement des batteries.
*intégration du module GPS et LoRA.
*la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 3
| 8
| 8
| 8
| 10
| 8
| 10
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
*Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
*Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
*Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

===Semaine 2===
* Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:
Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges.
Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.
* Fin de la liste du matériel

===Semaine 3===
*Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
*Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
*Ci-dessous le composant de bibliotheque cree
[[Fichier:PatternMG.png|400px|thumb|left]].
 

===Semaine 4===
*Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

*Schéma de notre circuit pour le capteur de temperature
[[Fichier:SchematicMG.png|700px|thumb|left]]

 

===Semaine 5===
*Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
*Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
*Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

===Semaine 6===
*Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation:
[[Fichier:RX TX moniteurserial.PNG|700px|thumb|left]].
 
Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

===Semaine 7===
*Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
*Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.
Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

==Semaine 8==
*Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

==Semaine 9==
*Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

== Fichiers Rendus ==

IMA4 2016/2017 P27

2017-04-02T13:02:30Z

Bgriller : /* Semaine 6 */

IMA4 2016/2017 P27

2017-04-02T13:01:09Z

Bgriller : /* Semaine 6 */

IMA4 2016/2017 P27

2017-04-02T13:00:20Z

Bgriller : /* Semaine 6 */

IMA4 2016/2017 P27

2017-04-02T12:56:55Z

Bgriller : /* Semaine 6 */

Fichier:RX TX moniteurserial.PNG

2017-04-02T12:51:33Z

Bgriller : Moniteur série module Lora (test du code émission/réception de la documentation)

Moniteur série module Lora (test du code émission/réception de la documentation)

IMA4 2016/2017 P27

2017-03-17T21:47:11Z

Bgriller : /* Avancement du Projet */

IMA4 2016/2017 P27

2017-02-27T16:52:56Z

Bgriller : /* Avancement du Projet */

IMA4 2016/2017 P27

2017-02-27T16:50:10Z

Bgriller : /* Semaine 4 */

IMA4 2016/2017 P27

2017-02-15T16:55:51Z

Bgriller : /* Feuille d'heures */

IMA4 2016/2017 P27

2017-02-15T16:55:35Z

Bgriller : /* Feuille d'heures */

Projets IMA4 SC & SA 2016/2017

2017-02-15T14:06:41Z

Bgriller : /* Matériel à acquérir */

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 demandant une modification du 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 ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
6* Capteur de température[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
1* Smartphone sous Android 6.0+, 
6* ATmega32u4-AU (package TQFP), [http://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA32U4RC-AU/?qs=sGAEpiMZZMvqv2n3s2xjsWfDNH99npBWOb9m5kVBeoM%3d], 
6* Connecteur USB Zx20-B-5S-UINT(30)[http://www.mouser.fr/ProductDetail/Hirose-Electric/ZX20-B-5S-UNIT30/?qs=%2fha2pyFaduiI1PHIQp025swiTaQgBs3xrF3lm%2fjmZrmtw6zfCgwPXHsVofi5faNN], 
5* quartz 16Mhz [http://fr.farnell.com/multicomp/mcrsd16000f183000rr/quartz-16mhz-18pf-hc49-us-smd/dp/2395958] 
6* Chip guard[http://eu.mouser.com/ProductDetail/Bourns/CG0603MLC-05E/?qs=%2fha2pyFaduj8GWc5RpRwWsoz%252bsBNDfM0b%2fMwO0m8cAS%252b28tb9AwLWQ%3d%3d] 
10* Fusibles réarmables[http://eu.mouser.com/ProductDetail/Bourns/MF-MSMF050-2/?qs=%2fha2pyFadujDIyYlSEAmAtmxzhQX2R56dU6AOyKWoF1gS%2fKyt5ZQcQ%3d%3d], 
5* header(36 contacts) [http://fr.farnell.com/3m/929974-01-36/connecteur-rcpt-36pos-1-rangee/dp/2396216?MER=sy-me-pd-mi-alte], 
20* résistances de 22 ohm[http://fr.farnell.com/multicomp/mc0063w0603522r/res-couche-epaisse-22r-5-0-063w/dp/9331891], 
10* résistances de 10k ohm[http://fr.farnell.com/susumu/rr0816p-103-b-t5/res-couche-mince-10k-0-1-0-063w/dp/1653253], 
10* résistances de 1M ohm[http://fr.farnell.com/multicomp/mc0063w060311m/res-couche-epaisse-1m-1-0-063w/dp/9330410?ost=9330410&selectedCategoryId=&categoryNameResp=Toutes%2Bles%2Bcat%25C3%25A9gories&searchView=table&iscrfnonsku=false], 
10* capacités(CMS) de 22 pF[http://fr.farnell.com/multicomp/mc0603n220j500ct/condensateur-mlcc-c0g-np0-22pf/dp/1759057], 
10* capacité(CMS) de 1 uF[http://fr.farnell.com/walsin/0603x105k100ct/condensateur-mlcc-x5r-1uf-10v/dp/2496916], 
10* capacité(CMS) de 100 nF[http://fr.farnell.com/walsin/0603b104k500ct/condensateur-mlcc-x7r-0-1uf-50v/dp/2496834], 
10* diode[http://www.mouser.fr/ProductDetail/Wolfspeed-Cree/C3D16065A/?qs=sGAEpiMZZMtbRapU8LlZD2p%2ftt67Z%252br4005PkgBuAD1SM4AyiGk4XA%3d%3d].
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
Smartphone sous Android.
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
Raspberry Pi.
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
 2*Adaptateur 5V [http://www.gotronic.fr/art-adaptateur-mv530n-8000.htm], 
 2*Embase adaptateur [http://www.gotronic.fr/art-embase-alim-sa21a-14961.htm], 
 2*Arduino mini [http://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7617327/], 
 2*Modules bluetooth [http://fr.rs-online.com/web/p/modules-bluetooth/1244407/], 
 Capteur de température [http://www.mouser.fr/ProductDetail/Maxim-Integrated/MAX31725MTA+/?qs=sGAEpiMZZMucenltShoSnuJtr4xlG60lboc%252bnebe514%3d], 
 2*Accéléromètre [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8652FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxODTM36syD6sQ%3d], 
 4*Vibreurs [http://www.gotronic.fr/art-vibreur-miniature-vm1201-20685.htm], 
 5*Servomoteurs [http://www.gotronic.fr/art-servomoteur-s07nf-25182.htm], 
 5* Capacité 0.1µF (*1 capteur température, *2 accéléromètre, 2* régulateur)[http://fr.farnell.com/walsin/0805b104k500ct/condensateur-mlcc-x7r-0-1uf-50v/dp/2496944], 
 3*Résistance 4.7kohms ( capteur température) [http://fr.farnell.com/vishay/crcw08054k70fkta/res-couche-epaisse-4-7k-1-0-125w/dp/1653013RL], 
2*Capacité 0.33µF (régulateur) [http://www.mouser.fr/ProductDetail/Wurth-Electronics/885012105003/?qs=sGAEpiMZZMvzv9EAOJZmO9b76UYLhwTmM7EN2czdHKU%3d], 
 2*Régulateur 3.3V [http://www.mouser.fr/ProductDetail/Texas-Instruments/UA78M33CDCYR/?qs=sGAEpiMZZMtUqDgmOWBjgHbKmseNGGTSe%2f5roer8H%2fU%3d], 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
Accéléromètre 4 ADXL335[http://www.gotronic.fr/art-module-accelerometre-adxl335-3-axes-ef03049-23504.htm], 
Module Adafruit 9-DOF [http://www.gotronic.fr/art-module-9-dof-ada2472-23896.htm], 
Smartphone sous Android, 
Câble 12 conducteurs [http://fr.farnell.com/pro-power/pp000342/cable-12-conducteurs-0-5mm2-25m/dp/2440126], 
Arduino Mega, 
Résistance , 
Module WIFI ESP 8266 [http://www.gotronic.fr/art-module-wifi-serie-esp8266-113990084-23666.htm]. 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
Arduino UNO x5.
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
Atmega 328p [http://fr.farnell.com/atmel/atmega328p-pu/micro-8-bits-avr-32k-flash-28pdip/dp/1715487], 
Atmega 328p CMS [http://fr.farnell.com/atmel/atmega328p-au/micro-8-bits-avr-32k-flash-32tqfp/dp/1715486?selectedCategoryId=&exaMfpn=true&categoryId=&searchRef=SearchLookAhead&searchView=table&iscrfnonsku=false], 
FT232R (*2) [http://fr.farnell.com/ftdi/ft232rl-reel/usb-vers-uart-ssop28-232/dp/1146032], 
USB (*2) [http://fr.farnell.com/wurth-elektronik/65100516121/mini-usb-2-0-type-b-receptacle/dp/1642036], 
Led (*4)[http://fr.farnell.com/kingbright/kph-1608sgc/led-12mcd-vert-568nm/dp/2426215], 
bouton(*2) [http://www.mouser.fr/ProductDetail/E-Switch/LL3301NF065QG/?qs=sGAEpiMZZMvxtGF7dlGNpqqmTFthXBmf0KM%252bqj1KR%252bA%3d], 
Diode(*2)[http://eu.mouser.com/ProductDetail/Microsemi/1N4148UR-1/?qs=sGAEpiMZZMtoHjESLttvkmKnFwXErGnblScnaPsZQPwnq%2fwjQSnhEg%3d%3d], 
LM1117(*2) [http://www.mouser.fr/new/Texas-Instruments/nationalLM1117/], 
TB6612FNG (*2) [http://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm], 
Quartz 16 MHz (*2)[http://fr.farnell.com/raltron/as-16-000-18/quartz-16mhz-18pf-hc-49s/dp/1611761?MER=bn_para_1TP_LastViewed_3], 
RJ11(*6) [http://fr.farnell.com/molex/95522-2667/fiche-rj11-cat3-6-6/dp/2060715], 
Resistor 1k , 
Resistor 470 , 
Resistor 100 , 
Resistor 1M , 
Capacité 10 nF , 
Capacité 10uF , 
Capacité 22pF , 
'''MATERIELS CAPTEUR DE LIGNE'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_capteur_de_ligne], 
'''MATERIELS CAPTEUR ULTRASON'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_capteur_ultrason_.28en_cours.29], 
'''MATERIELS CODEUR INCREMENTAL'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_Odom.C3.A8tre_.28en_cours.29]. 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
LEDs IR (x20), RS [http://fr.rs-online.com/web/p/led-ir/6548334/], 
Phototransistors IR (x20), RS [http://fr.rs-online.com/web/p/phototransistors/6548047/], 
Drivers moteur Pololu (x1), GoTronic [http://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm], 
Drivers moteur TB6612FNG (x3), Mouser [http://www.mouser.fr/Search/ProductDetail.aspx?qs=rsevcuukUAy2UalRuv4E%2fQ%3d%3d] , <br\>
Borniers à vis (x20), Farnell [http://fr.farnell.com/camdenboss/ctb0502-2/bornier-carte-a-fil-2-voies-12awg/dp/2493622?MER=en-me-sr-b-all], <br\>
Résistances 220 Ohms CMS (x20), Mouser [http://www.mouser.fr/ProductDetail/Vishay-Dale/CRCW0603220RFKEA/?qs=sGAEpiMZZMtlubZbdhIBIKySljYCMs0HAiopx1mcVY0%3d] , <br\>
Résistances 470 kOhms CMS (x30), Mouser [http://www.mouser.fr/ProductDetail/Panasonic/ERJ-3GEYJ474V/?qs=sGAEpiMZZMtlubZbdhIBIDkNbKahCB4%252bXwMzav7V8qQ%3d], <br\>
LEDs couleur (x10), RS [http://fr.rs-online.com/web/p/led/8134845/], <br\>
Fils m-m (x1 lot de 65), Farnell [http://fr.farnell.com/multicomp/mcbbj65/assortiment-de-jumper-fil-65pcs/dp/2396146], <br\>
Capas 10uF CMS (x20) Mouser [http://www.mouser.fr/ProductDetail/Murata-Electronics/ZRB18AR61C106ME01L/?qs=sGAEpiMZZMs0AnBnWHyRQPHsfd5klL7FP%2fi0oh%252bVTwkomqr6NYKsqQ%3d%3d], <br\>
Capas 0.1uF CMS (x20) Mouser [http://www.mouser.fr/ProductDetail/Kemet/C0603C104K4RACTU/?qs=sGAEpiMZZMs0AnBnWHyRQFqPnX0OlvcoGdtRY%252bgH1%2fs%3d], <br\>
Embases CI 40 contacts 1 rangée (x6) RS [http://fr.rs-online.com/web/p/embases-de-circuit-imprime/4232841/], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) , <br\>
Interrupteurs (x4) , <br\>
Colliers de serrage .
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
Capteur de température DS75LV [http://www.mouser.fr/ProductDetail/Maxim-Integrated/DS75LVU+/?qs=sGAEpiMZZMucenltShoSnqz2Nq7rAtSUouPEUh693aE%3d], 
Capteur de pression [http://www.mouser.fr/ProductDetail/Measurement-Specialties/5525DSO-SB005GS/?qs=sGAEpiMZZMvhQj7WZhFIAJ6e00q4%2fiLk8vQEbfsXmbvuJAmWYTr67w%3d%3d], 
Module LoRa [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==], 
Module GPS [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==], 
1 RaspberryPi, 
Batterie 5000 mAh [http://fr.rs-online.com/web/p/batteries-externes/7757508/], 
1 carte microSD pour Raspberry 8GB. 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Nano , 
 2x Module XBee + 1x Shield , 
 Arduino UNO , 
 Xbee Adapter Board, 
 Raspberry Pi. 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Alimentation MicroUSB pour RaspberryPi, 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
Capteur de mesure Sharp GP2Y0A02YK x3 [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm], 
Appareil mobile sous OS Android (portable ou tablette ). 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
Récepteur LoRa 433/868Mhz, 
Logiciel Code compiler équipé d'un GCC pour MSP430, 
Carte cc430f5137 868MHz, 
1 antenne 868MHz[http://www.mouser.fr/ProductDetail/Linx-Technologies/ANT-868-CW-HWR-RPS/?qs=sGAEpiMZZMuBTKBKvsBmlOBg0H7cD5uyLmjn8%2f6ScJQ%3d], 
Breadboard, 
Quelques LEDs, 
pour 433MHz, 
(carte arduino + cc1101), 
Quartz 26MHz [http://fr.farnell.com/txc/7a-26-000maaj-t/crystal-26mhz-18pf-5-x-3-2mm/dp/2061710], 
2 antennes 433MHz[http://www.mouser.fr/ProductDetail/LPRS/ANT-SR433/?qs=sGAEpiMZZMuBTKBKvsBmlL2JeKAJ5GlFgePIl66EJDQoPGtUlcrRBQ%3d%3d]. 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
2 carte LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 
2 cartes Arduino (connecteurs USB & alimentation),. 

|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
Aucun matériel nécessaire. 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
Émetteur et récepteur infrarouge/photodiode (seulement 1 de chaque prêtées, il en faut 6 à 7 de chaque), 
Adaptateur PS512S [http://www.gotronic.fr/art-adaptateur-ps512s-19913.htm] , 
Shield carte SD (carte SD également), 
Module horloge temps réel (RTC) [http://www.gotronic.fr/art-module-horloge-temps-reel-ada3296-25536.htm], 
Capteur de proximité IR [http://www.gotronic.fr/art-capteur-de-proximite-ir-38-khz-2460-21766.htm], 
Capteur Ultrason , 
LEDs , 
Résistances , 
Arduino méga , 
ESP8266 , 
Servomoteur 360 , 
Solution de secours : Rapsberry , 
Solution de secours : Balance . 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
Raspberry pi modèle B minimum, 
batterie, 
circuit shut down(une breadboard, une LED, une resistance 220 ohms, 3 fils M/M, 2 fils M/F), 
un interrupteur on/off Référence : 7547 Selectronic, 
bois de palette, 
dongle wi pi, 
Rétroprojecteur, 
timer(circuit de retardement 5 secondes). 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
Deux lasers de différentes couleurs, 
Une paire de galvanomètres à miroir, 
Arduino, 
Raspberry Pi3, 
Câble secteur, 
Drivers galvanomètres x2, 
Alimentation laser, 
Lunette de sécurité x2 [https://www.amazon.fr/Uvex-S1933X-Eyewear-SCTOrange-Anti-Fog/dp/B000USRG90/ref=sr_1_1?ie=UTF8&qid=1485441383&sr=8-1&keywords=uvex+s1933x], 
Alimentation 230V/5V 1A [http://www.miniinthebox.com/fr/dual-usb-eu-prise-murale-5v-2a-voyage-adaptateur-chargeur-d-alimentation-pour-iphone7-6-xiaomi-samsung-et-autre-telephone-portable_p5410410.html?currency=EUR&litb_from=paid_adwords_shopping&sku=429_6917%7C752_20648&utm_source=google_shopping&utm_medium=cpc&adword_mt=&adword_ct=138705676724&adword_kw=&adword_pos=1o5&adword_pl=&adword_net=g&adword_tar=&adw_src_id=9653316068_661261352_33588296076_aud-79897721311:pla-256966386459&gclid=Cj0KEQiA_KvEBRCtzNil4-KR-LIBEiQAmgekFxxKjJJWBYCJlDZEa3Ke_2_WR0DzGVbz-jaCZHVIBoMaAvld8P8HAQ], 
Boitier ABS [http://fr.farnell.com/multicomp/g3118/boitier-abs-240x120x60mm-ip65/dp/1526656], 
DAC 4 canaux, avec interface I²C [http://www.mouser.fr/ProductDetail/Adafruit/1083/?qs=sGAEpiMZZMsMyYRRhGMFNtB2KhoPg%2fPbP3CExTYfM4M%3d], 
Connecteur C14 [http://fr.farnell.com/schurter/3-101-141/fiche-iec-c14-c18-avec-filtre/dp/2671668]. 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
 Un Minitel 1 Bistandard Alcatel Telic, 
 un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
 un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
 un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html], 
 deux optocoupleurs 4N25. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes, 2 Mouser Rouge[http://www.mouser.fr/ProductDetail/Lumex/SSL-LX5093LBI-SRD/?qs=sGAEpiMZZMvHYEB9WUp7ElLqM0HAvqw07NtkT0umwJ8%3d], Mouser Vert [http://www.mouser.fr/ProductDetail/Dialight/521-9465F/?qs=sGAEpiMZZMvHYEB9WUp7EvzO6BrrarQchHylkK4n3ZA%3d], , 
Smartphone sous Android, 
Aimants, Farnell [http://fr.farnell.com/duratool/d01767/aimant-12-x-3mm-pqt6/dp/1888096], 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
1 Transistor Bipolaire, Mouser [http://www.mouser.fr/ProductDetail/Fairchild-Semiconductor/MMBTH10/?qs=sGAEpiMZZMvDjfggS9kWsbCZIMjqR5oUPy4t%252bWqVHyk%3d] . 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
Logiciel MatLab Simulink, 
Logiciel RobotinoView, 
Robotino. 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
Logiciel MatLab Simulink, 
Logiciel RobotinoView, 
Robotino. 
|}

Projets IMA4 SC & SA 2016/2017

2017-02-15T14:03:41Z

Bgriller : /* Matériel à acquérir */

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 demandant une modification du 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 ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
6* Capteur de température[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
1* Smartphone sous Android 6.0+, 
6* ATmega32u4-AU (package TQFP), [http://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA32U4RC-AU/?qs=sGAEpiMZZMvqv2n3s2xjsWfDNH99npBWOb9m5kVBeoM%3d], 
6* Connecteur USB Zx20-B-5S-UINT(30)[http://www.mouser.fr/ProductDetail/Hirose-Electric/ZX20-B-5S-UNIT30/?qs=%2fha2pyFaduiI1PHIQp025swiTaQgBs3xrF3lm%2fjmZrmtw6zfCgwPXHsVofi5faNN], 
5* quartz 16Mhz [http://fr.farnell.com/multicomp/mcrsd16000f183000rr/quartz-16mhz-18pf-hc49-us-smd/dp/2395958] 
6* Chip guard[http://eu.mouser.com/ProductDetail/Bourns/CG0603MLC-05E/?qs=%2fha2pyFaduj8GWc5RpRwWsoz%252bsBNDfM0b%2fMwO0m8cAS%252b28tb9AwLWQ%3d%3d] 
10* Fusibles réarmables[http://eu.mouser.com/ProductDetail/Bourns/MF-MSMF050-2/?qs=%2fha2pyFadujDIyYlSEAmAtmxzhQX2R56dU6AOyKWoF1gS%2fKyt5ZQcQ%3d%3d], 
5* header(36 contacts) [http://fr.farnell.com/3m/929974-01-36/connecteur-rcpt-36pos-1-rangee/dp/2396216?MER=sy-me-pd-mi-alte], 
20* résistances de 22 ohm[http://fr.farnell.com/multicomp/mc0063w0603522r/res-couche-epaisse-22r-5-0-063w/dp/9331891], 
10* résistances de 10k ohm[http://fr.farnell.com/susumu/rr0816p-103-b-t5/res-couche-mince-10k-0-1-0-063w/dp/1653253], 
10* résistances de 1M ohm[http://fr.farnell.com/multicomp/mc0063w060311m/res-couche-epaisse-1m-1-0-063w/dp/9330410?ost=9330410&selectedCategoryId=&categoryNameResp=Toutes%2Bles%2Bcat%25C3%25A9gories&searchView=table&iscrfnonsku=false], 
10* capacités(CMS) de 22 pF[http://fr.farnell.com/multicomp/mc0603n220j500ct/condensateur-mlcc-c0g-np0-22pf/dp/1759057], 
10* capacité(CMS) de 1 uF[http://fr.farnell.com/walsin/0603x105k100ct/condensateur-mlcc-x5r-1uf-10v/dp/2496916], 
10* capacité(CMS) de 100 nF[http://fr.farnell.com/walsin/0603b104k500ct/condensateur-mlcc-x7r-0-1uf-50v/dp/2496834], 
10* diode[http://www.mouser.fr/ProductDetail/Wolfspeed-Cree/C3D16065A/?qs=sGAEpiMZZMtbRapU8LlZD2p%2ftt67Z%252br4005PkgBuAD1SM4AyiGk4XA%3d%3d].
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
Smartphone sous Android.
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
Raspberry Pi.
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
 2*Adaptateur 5V [http://www.gotronic.fr/art-adaptateur-mv530n-8000.htm], 
 2*Embase adaptateur [http://www.gotronic.fr/art-embase-alim-sa21a-14961.htm], 
 2*Arduino mini [http://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7617327/], 
 2*Modules bluetooth [http://fr.rs-online.com/web/p/modules-bluetooth/1244407/], 
 Capteur de température [http://www.mouser.fr/ProductDetail/Maxim-Integrated/MAX31725MTA+/?qs=sGAEpiMZZMucenltShoSnuJtr4xlG60lboc%252bnebe514%3d], 
 2*Accéléromètre [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8652FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxODTM36syD6sQ%3d], 
 4*Vibreurs [http://www.gotronic.fr/art-vibreur-miniature-vm1201-20685.htm], 
 5*Servomoteurs [http://www.gotronic.fr/art-servomoteur-s07nf-25182.htm], 
 5* Capacité 0.1µF (*1 capteur température, *2 accéléromètre, 2* régulateur)[http://fr.farnell.com/walsin/0805b104k500ct/condensateur-mlcc-x7r-0-1uf-50v/dp/2496944], 
 3*Résistance 4.7kohms ( capteur température) [http://fr.farnell.com/vishay/crcw08054k70fkta/res-couche-epaisse-4-7k-1-0-125w/dp/1653013RL], 
2*Capacité 0.33µF (régulateur) [http://www.mouser.fr/ProductDetail/Wurth-Electronics/885012105003/?qs=sGAEpiMZZMvzv9EAOJZmO9b76UYLhwTmM7EN2czdHKU%3d], 
 2*Régulateur 3.3V [http://www.mouser.fr/ProductDetail/Texas-Instruments/UA78M33CDCYR/?qs=sGAEpiMZZMtUqDgmOWBjgHbKmseNGGTSe%2f5roer8H%2fU%3d], 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
Accéléromètre 4 ADXL335[http://www.gotronic.fr/art-module-accelerometre-adxl335-3-axes-ef03049-23504.htm], 
Module Adafruit 9-DOF [http://www.gotronic.fr/art-module-9-dof-ada2472-23896.htm], 
Smartphone sous Android, 
Câble 12 conducteurs [http://fr.farnell.com/pro-power/pp000342/cable-12-conducteurs-0-5mm2-25m/dp/2440126], 
Arduino Mega, 
Résistance , 
Module WIFI ESP 8266 [http://www.gotronic.fr/art-module-wifi-serie-esp8266-113990084-23666.htm]. 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
Arduino UNO x5.
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
Atmega 328p [http://fr.farnell.com/atmel/atmega328p-pu/micro-8-bits-avr-32k-flash-28pdip/dp/1715487], 
Atmega 328p CMS [http://fr.farnell.com/atmel/atmega328p-au/micro-8-bits-avr-32k-flash-32tqfp/dp/1715486?selectedCategoryId=&exaMfpn=true&categoryId=&searchRef=SearchLookAhead&searchView=table&iscrfnonsku=false], 
FT232R (*2) [http://fr.farnell.com/ftdi/ft232rl-reel/usb-vers-uart-ssop28-232/dp/1146032], 
USB (*2) [http://fr.farnell.com/wurth-elektronik/65100516121/mini-usb-2-0-type-b-receptacle/dp/1642036], 
Led (*4)[http://fr.farnell.com/kingbright/kph-1608sgc/led-12mcd-vert-568nm/dp/2426215], 
bouton(*2) [http://www.mouser.fr/ProductDetail/E-Switch/LL3301NF065QG/?qs=sGAEpiMZZMvxtGF7dlGNpqqmTFthXBmf0KM%252bqj1KR%252bA%3d], 
Diode(*2)[http://eu.mouser.com/ProductDetail/Microsemi/1N4148UR-1/?qs=sGAEpiMZZMtoHjESLttvkmKnFwXErGnblScnaPsZQPwnq%2fwjQSnhEg%3d%3d], 
LM1117(*2) [http://www.mouser.fr/new/Texas-Instruments/nationalLM1117/], 
TB6612FNG (*2) [http://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm], 
Quartz 16 MHz (*2)[http://fr.farnell.com/raltron/as-16-000-18/quartz-16mhz-18pf-hc-49s/dp/1611761?MER=bn_para_1TP_LastViewed_3], 
RJ11(*6) [http://fr.farnell.com/molex/95522-2667/fiche-rj11-cat3-6-6/dp/2060715], 
Resistor 1k , 
Resistor 470 , 
Resistor 100 , 
Resistor 1M , 
Capacité 10 nF , 
Capacité 10uF , 
Capacité 22pF , 
'''MATERIELS CAPTEUR DE LIGNE'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_capteur_de_ligne], 
'''MATERIELS CAPTEUR ULTRASON'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_capteur_ultrason_.28en_cours.29], 
'''MATERIELS CODEUR INCREMENTAL'''[http://projets-imasc.plil.net/mediawiki/index.php?title=Finalisation_de_cartes_de_contr%C3%B4le_de_robot#Carte_Odom.C3.A8tre_.28en_cours.29]. 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
LEDs IR (x20), RS [http://fr.rs-online.com/web/p/led-ir/6548334/], 
Phototransistors IR (x20), RS [http://fr.rs-online.com/web/p/phototransistors/6548047/], 
Drivers moteur Pololu (x1), GoTronic [http://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm], 
Drivers moteur TB6612FNG (x3), Mouser [http://www.mouser.fr/Search/ProductDetail.aspx?qs=rsevcuukUAy2UalRuv4E%2fQ%3d%3d] , <br\>
Borniers à vis (x20), Farnell [http://fr.farnell.com/camdenboss/ctb0502-2/bornier-carte-a-fil-2-voies-12awg/dp/2493622?MER=en-me-sr-b-all], <br\>
Résistances 220 Ohms CMS (x20), Mouser [http://www.mouser.fr/ProductDetail/Vishay-Dale/CRCW0603220RFKEA/?qs=sGAEpiMZZMtlubZbdhIBIKySljYCMs0HAiopx1mcVY0%3d] , <br\>
Résistances 470 kOhms CMS (x30), Mouser [http://www.mouser.fr/ProductDetail/Panasonic/ERJ-3GEYJ474V/?qs=sGAEpiMZZMtlubZbdhIBIDkNbKahCB4%252bXwMzav7V8qQ%3d], <br\>
LEDs couleur (x10), RS [http://fr.rs-online.com/web/p/led/8134845/], <br\>
Fils m-m (x1 lot de 65), Farnell [http://fr.farnell.com/multicomp/mcbbj65/assortiment-de-jumper-fil-65pcs/dp/2396146], <br\>
Capas 10uF CMS (x20) Mouser [http://www.mouser.fr/ProductDetail/Murata-Electronics/ZRB18AR61C106ME01L/?qs=sGAEpiMZZMs0AnBnWHyRQPHsfd5klL7FP%2fi0oh%252bVTwkomqr6NYKsqQ%3d%3d], <br\>
Capas 0.1uF CMS (x20) Mouser [http://www.mouser.fr/ProductDetail/Kemet/C0603C104K4RACTU/?qs=sGAEpiMZZMs0AnBnWHyRQFqPnX0OlvcoGdtRY%252bgH1%2fs%3d], <br\>
Embases CI 40 contacts 1 rangée (x6) RS [http://fr.rs-online.com/web/p/embases-de-circuit-imprime/4232841/], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) , <br\>
Interrupteurs (x4) , <br\>
Colliers de serrage .
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
Capteur de température DS75LV [http://www.mouser.fr/ProductDetail/Maxim-Integrated/DS75LVU+/?qs=sGAEpiMZZMucenltShoSnqz2Nq7rAtSUouPEUh693aE%3d], 
Capteur de pression [http://www.mouser.fr/ProductDetail/Measurement-Specialties/5525DSO-SB005GS/?qs=sGAEpiMZZMvhQj7WZhFIAJ6e00q4%2fiLk8vQEbfsXmbvuJAmWYTr67w%3d%3d], 
Accéléromètre ADXL345 [http://fr.farnell.com/analog-devices/eval-adxl345z/carte-d-evaluation-adxl345-inerti/dp/2301487], 
Module LoRa [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==], 
Module GPS [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==], 
1 RaspberryPi, 
Batterie 5000 mAh [http://fr.rs-online.com/web/p/batteries-externes/7757508/], 
1 carte microSD pour Raspberry 8GB. 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Nano , 
 2x Module XBee + 1x Shield , 
 Arduino UNO , 
 Xbee Adapter Board, 
 Raspberry Pi. 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Alimentation MicroUSB pour RaspberryPi, 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
Capteur de mesure Sharp GP2Y0A02YK x3 [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm], 
Appareil mobile sous OS Android (portable ou tablette ). 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
Récepteur LoRa 433/868Mhz, 
Logiciel Code compiler équipé d'un GCC pour MSP430, 
Carte cc430f5137 868MHz, 
1 antenne 868MHz[http://www.mouser.fr/ProductDetail/Linx-Technologies/ANT-868-CW-HWR-RPS/?qs=sGAEpiMZZMuBTKBKvsBmlOBg0H7cD5uyLmjn8%2f6ScJQ%3d], 
Breadboard, 
Quelques LEDs, 
pour 433MHz, 
(carte arduino + cc1101), 
Quartz 26MHz [http://fr.farnell.com/txc/7a-26-000maaj-t/crystal-26mhz-18pf-5-x-3-2mm/dp/2061710], 
2 antennes 433MHz[http://www.mouser.fr/ProductDetail/LPRS/ANT-SR433/?qs=sGAEpiMZZMuBTKBKvsBmlL2JeKAJ5GlFgePIl66EJDQoPGtUlcrRBQ%3d%3d]. 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
2 carte LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 
2 cartes Arduino (connecteurs USB & alimentation),. 

|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
Aucun matériel nécessaire. 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
Émetteur et récepteur infrarouge/photodiode (seulement 1 de chaque prêtées, il en faut 6 à 7 de chaque), 
Adaptateur PS512S [http://www.gotronic.fr/art-adaptateur-ps512s-19913.htm] , 
Shield carte SD (carte SD également), 
Module horloge temps réel (RTC) [http://www.gotronic.fr/art-module-horloge-temps-reel-ada3296-25536.htm], 
Capteur de proximité IR [http://www.gotronic.fr/art-capteur-de-proximite-ir-38-khz-2460-21766.htm], 
Capteur Ultrason , 
LEDs , 
Résistances , 
Arduino méga , 
ESP8266 , 
Servomoteur 360 , 
Solution de secours : Rapsberry , 
Solution de secours : Balance . 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
Raspberry pi modèle B minimum, 
batterie, 
circuit shut down(une breadboard, une LED, une resistance 220 ohms, 3 fils M/M, 2 fils M/F), 
un interrupteur on/off Référence : 7547 Selectronic, 
bois de palette, 
dongle wi pi, 
Rétroprojecteur, 
timer(circuit de retardement 5 secondes). 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
Deux lasers de différentes couleurs, 
Une paire de galvanomètres à miroir, 
Arduino, 
Raspberry Pi3, 
Câble secteur, 
Drivers galvanomètres x2, 
Alimentation laser, 
Lunette de sécurité x2 [https://www.amazon.fr/Uvex-S1933X-Eyewear-SCTOrange-Anti-Fog/dp/B000USRG90/ref=sr_1_1?ie=UTF8&qid=1485441383&sr=8-1&keywords=uvex+s1933x], 
Alimentation 230V/5V 1A [http://www.miniinthebox.com/fr/dual-usb-eu-prise-murale-5v-2a-voyage-adaptateur-chargeur-d-alimentation-pour-iphone7-6-xiaomi-samsung-et-autre-telephone-portable_p5410410.html?currency=EUR&litb_from=paid_adwords_shopping&sku=429_6917%7C752_20648&utm_source=google_shopping&utm_medium=cpc&adword_mt=&adword_ct=138705676724&adword_kw=&adword_pos=1o5&adword_pl=&adword_net=g&adword_tar=&adw_src_id=9653316068_661261352_33588296076_aud-79897721311:pla-256966386459&gclid=Cj0KEQiA_KvEBRCtzNil4-KR-LIBEiQAmgekFxxKjJJWBYCJlDZEa3Ke_2_WR0DzGVbz-jaCZHVIBoMaAvld8P8HAQ], 
Boitier ABS [http://fr.farnell.com/multicomp/g3118/boitier-abs-240x120x60mm-ip65/dp/1526656], 
DAC 4 canaux, avec interface I²C [http://www.mouser.fr/ProductDetail/Adafruit/1083/?qs=sGAEpiMZZMsMyYRRhGMFNtB2KhoPg%2fPbP3CExTYfM4M%3d], 
Connecteur C14 [http://fr.farnell.com/schurter/3-101-141/fiche-iec-c14-c18-avec-filtre/dp/2671668]. 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
 Un Minitel 1 Bistandard Alcatel Telic, 
 un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
 un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
 un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html], 
 deux optocoupleurs 4N25. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes, 2 Mouser Rouge[http://www.mouser.fr/ProductDetail/Lumex/SSL-LX5093LBI-SRD/?qs=sGAEpiMZZMvHYEB9WUp7ElLqM0HAvqw07NtkT0umwJ8%3d], Mouser Vert [http://www.mouser.fr/ProductDetail/Dialight/521-9465F/?qs=sGAEpiMZZMvHYEB9WUp7EvzO6BrrarQchHylkK4n3ZA%3d], , 
Smartphone sous Android, 
Aimants, Farnell [http://fr.farnell.com/duratool/d01767/aimant-12-x-3mm-pqt6/dp/1888096], 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
1 Transistor Bipolaire, Mouser [http://www.mouser.fr/ProductDetail/Fairchild-Semiconductor/MMBTH10/?qs=sGAEpiMZZMvDjfggS9kWsbCZIMjqR5oUPy4t%252bWqVHyk%3d] . 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
Logiciel MatLab Simulink, 
Logiciel RobotinoView, 
Robotino. 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
Logiciel MatLab Simulink, 
Logiciel RobotinoView, 
Robotino. 
|}

IMA4 2016/2017 P27

2017-02-09T11:59:33Z

Bgriller : /* Avancement du Projet */

IMA4 2016/2017 P27

2017-02-01T15:53:15Z

Bgriller : /* Semaine 2 */

IMA4 2016/2017 P27

2017-02-01T15:52:58Z

Bgriller : /* Semaine 2 */

IMA4 2016/2017 P27

2017-02-01T15:35:39Z

Bgriller : /* Semaine 1 */

Projets IMA4 SC & SA 2016/2017

2017-02-01T14:35:38Z

Bgriller : /* Matériel à acquérir */

Projets IMA4 SC & SA 2016/2017

2017-02-01T14:24:38Z

Bgriller : /* Matériel à acquérir */

Discussion:Projets IMA4 SC & SA 2016/2017

2017-02-01T13:35:57Z

Bgriller : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant..
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| 
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| 
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| 
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| 
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| 
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| 
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| 
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.
| 
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| 
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| 
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?
| 
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Séance 5 !! Séance 6 !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| janvier 25 13h50-18h20 E304
| février 1 13h50-18h20 E304
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306
| E303
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 tout l'après-midi
| E305 tout l'après-midi
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| 1 février 13h50 18h10 E303 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304
| E305
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304
| E304
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| E305 de 13h50 à 18h20
| E305 de 13h50 à 18h20
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 tout l'après-midi
| E305 tout l'après-midi
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Valentin Dupont
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| janvier 25 13h50-18h20 E304
| février 1 13h50-18h20 E303
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305 13h50-16h30
D306A 16h30-18h
| C305/D306A
| 
| 
| 
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A
| C305/D306A
| 
| 
| 
| 
| 
| 
| 
| 
|}

IMA4 2016/2017 P27

2017-01-25T17:00:48Z

Bgriller : /* Avancement du Projet */

IMA4 2016/2017 P27

2017-01-23T15:41:02Z

Bgriller : /* Liste des tâches à effectuer */

IMA4 2016/2017 P27

2017-01-23T15:40:22Z

Bgriller : /* Liste des tâches à effectuer */

IMA4 2016/2017 P27

2017-01-23T15:38:56Z

Bgriller : /* Cahier des charges */

IMA4 2016/2017 P27

2016-12-16T23:57:28Z

Bgriller : /* Présentation générale du projet */

IMA4 2016/2017 P27

2016-12-15T16:44:14Z

Bgriller : /* Présentation générale du projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Les ballons météos atmosphérique permettent la récolte de données à haute altitude à partir de différents capteur embarqués dans une nacelle. Cette dernière est suspendue par des ballons remplis d'hélium (un gaz plus léger que l'air) qui permet d'exercer une force suffisante à l’élévation en altitude de la charge.
====Objectif du projet====

====Description du projet====

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

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===

== Fichiers Rendus ==

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:37:48Z

Bgriller : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/*
* Serial library
*/
////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include "serial.h"
////
// Functions
////
//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}
//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}
//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>
#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
int sd;
static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}
static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1);
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1);
else{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}
static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};
int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:35:27Z

Bgriller : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/*
* Serial library
*/
////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include "serial.h"
////
// Functions
////
//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}
//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}
//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>
#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
int sd;
static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}
static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1);
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1);
}
else{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}
static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};
int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:27:52Z

Bgriller : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/*
* Serial library
*/
////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include "serial.h"
////
// Functions
////
//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}
//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}
//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>
#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
int sd;
static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}
static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1);
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1);
}
else
{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}
static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};
int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:19:15Z

Bgriller : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/*
* Serial library
*/
////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include "serial.h"
////
// Functions
////
//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}
//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}
//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>
#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
int sd;
static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}
static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1);
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1);
}
else
{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:10:59Z

Bgriller : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/*
* Serial library
*/

////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>

#include "serial.h"

////
// Functions
////

//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}

//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}

//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>

#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50

int sd;

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;

switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1); }
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1); }
}
else
{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);

// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-31T15:09:14Z

Bgriller : /* Séance supplémentaire */

= Projet IMA3-SC 2015/2016 : Gestion de l'éclairage et du chauffage d'une pièce en fonction du nombre de personne. =

== Contexte ==

La gestion de l'énergie étant une problématique d'actualité, nous nous sommes dirigés vers le domaine de la domotique.
Notre objectif est de concevoir un système capable, d'une part, de gérer automatiquement l'éclairage d'une pièce et d'autre part, de conseiller l'utilisateur sur le chauffage de cette dernière via une application WEB.

== Cahier des charges ==

Concernant l'éclairage :
* 2 capteurs de présence (LED IR ou SONAR à définir)
* Des LEDs représentant l'éclairage
Concernant la gestion du chauffage :
* 1 capteur de température
Pour acquérir, traiter et afficher les données :
* Une Nanoboard
* Une Raspberry PI

== Séance 1 ==

=== Partie électronique ===
Prise en main de la RedBoard :
* Clignotement d'une LED
* Mesures de distance avec SONAR qui servira de capteur de présence.
* Caractéristiques du capteur de température TMP36GZ :
Étendue de mesure : -40°C à +125°C
Précision : +- 1°C à 25°C
Résolution : 10mV/°C
Offset : 0.5V
25°C->750mV

Utilisation de la RedBoard pour acquérir les signaux des capteurs et transmission par la liaison série intégrée jusqu'à l’ordinateur.

=== Partie informatique ===
*(Re)découverte du langage HTML.
*Découverte du langage CSS.
Recherche d'outils permettant la réalisation de graphiques 3D dynamique sur une page WEB :
* JavaScript
* CANVAS

== Séance 2 ==

=== Partie électronique ===

Nous choisissons de changer le capteur de présence par deux LED IR. Une personne est comptée entrante/sortante dans la pièce lorsque le faisceau IR est interrompu.
Nous devons donc numériser deux signaux, celui à la sortie du capteur de température et celui des LEDs.
Pour cela il nous faut utiliser un convertisseur analogique-numérique.
Nous sommes contraint de réaliser ce composant avec le FPGA et nous nécessitons donc une conversion par MLI.
Cette conversion nécessite la génération d'un signal triangulaire (utilisation d'un filtre passe bas) par le biais du FPGA et l’utilisation d'un comparateur entre ce signal et le signal du capteur pour obtenir un signal TTL interprétable en binaire.
Le schéma suivant illustre la conversion.

[[Fichier:Pwmproj.png]]

Pour retrouver la valeur de la tension délivrée par le capteur de température à partir du signal TTL, il faut mesurer la valeur moyenne de ce signal.

Pour le comptage de personne, nous utilisons un comparateur qui permet l’émission d'un état haut lorsque la luminosité reçue par la photodiode descend en dessous d'un certains niveau. Cela correspond à l'interruption de notre faisceau et au passage d'une personne.
Nous comptons le nombre d'interruption et l'enregistrons sous forme d'entier dans une mémoire adjacente au FPGA.

=== Partie informatique ===

Programmation du capteur de température et de la photodiode.

== Séance 3 ==

=== Partie électronique ===

Après plusieurs tentatives infructueuses d'accès à la salle d'électronique (car il n'y avait pas suffisamment de poste avec nanoboard pour le nombre de groupe du TD), nous avons pu réaliser les premiers schémas sur Altium.
Le premier correspond à l’émission d'un signal carré par le FPGA pour sa conversion future en signal triangulaire.

[[Fichier:PWM1 OAG.png]]

Il est composés des éléments suivants :
Un compteur 8 bits relié à deux blocs différents : L'horloge et un module délivrant un mot de 8 bit correspondant à la largeur d’impulsion désirée.
Nous utilisons le bloc PWM prédéfini dans Altium pour délivrer sur la broche 2 le signal carré.

Le signal de sortie de ce bloc est un signal carré que nous rendons triangulaire grâce au filtre passe bas.
Il suffit ensuite d'utiliser un comparateur (composant électronique) pour obtenir notre signal convertit.

Cependant, nous rencontrons des difficultés lors de la compilation du programme sous Altium. Nous remarquons que cela vient d'un problème de bibliothèque du logiciel et décidons de changer de poste pour le résoudre. Ce problème nous a fortement ralenti et nous décidons de réaliser une séance supplémentaire pour avancer le projet.

=== Partie informatique ===
Définition des données à échanger entre la partie électronique et le serveur Websocket.
Finition du code gérant les capteurs.

Voici le programme implémenté dans la Redboard:

int pd=2;
int senRead=0; // diode #1
int senRead2=2; // diode #2
int seuil=20; //seuil pour un obstacle
int cpt_IN=0; //compteur d'entrées
int cpt_OUT=0; //compteur de sorties
int signal_coupe=0; //indique le numéro de la diode dont le signal a été coupé
//pour le capteur de température
int val_t;
int tempPin = 1;

void setup()
{
pinMode(pd,OUTPUT);
digitalWrite(pd,HIGH); //alimentation photodiode
Serial.begin(9600);
}
void loop()
{
// Acquisition, calcul et affichage de la température
val_t = analogRead(tempPin);
float cel = ( val_t*125)/767.25; //Conversion en degrés Celsius
Serial.print(cel);
Serial.print("*C");

// Lecture photodiode 1
int val=analogRead(senRead); //Acquisition de la valeur numérique (comprise entre 0 et 1023) de la première diode
delay(10);
// Lecture photodiode 2
int val2=analogRead(senRead2); // Acquisition de la valeur numérique (comprise entre 0 et 1023) de la seconde diode
delay(10);

// test signal coupé
if ((val>seuil) && (val2<seuil)){
Serial.print("Signal 1 COUPE");
signal_coupe = 1;
cpt_OUT++;
delay(100);
}
if ((val2>seuil) && (val<seuil)){
Serial.print("Signal 2 COUPE");
signal_coupe = 1;
cpt_IN++;
delay(100);
}
Serial.print(signal_coupe);

}

== Séance supplémentaire ==

=== Partie électronique ===

Le problème de compilation résolu, c'est le signal en sortie de la nanoboard qui nous pose problème, il n'est pas de forme carrée mais plutôt aléatoire. Après des recherches infructueuses et chronophages, nous nous intéressons à la réalisation de la liaison série.
Nous souhaitons transférer la donnée température sous forme d'un mot de 8 bits. Le transfert du nombre de personnes comptées est un accès à la mémoire pour une lecture.

En prenant le cas du transfert de la données température, il convient de la mettre sous forme d'une trame utilisée par la liaisons RS232. Soit un bit de start, 8 bit de données et un bit de stop. Pas de bit de parité.
La meilleur façon d'assembler ces bits consiste à utiliser un multiplexeur 8 vers 1 pour une émissions bit à bit temporisée par un compteur. Ce compteur correspond à la vitesse de transmission en bauds, choisit arbitrairement à 9600 bits/s, il faut connecter une horloge de 9600Hz pour cela au compteur.
Nous trouvons ces informations en nous renseignant sur internet et en utilisant les travaux réalisés lors des projets précédents. Un programme Altium réalisable correspond au programme suivant, nous ne l'avons pas testé par manque de temps.

[[Fichier:Transmission_OAG.PNG]]

Un bloc supplémentaire de cadencement du compteur est utilisé afin d'obtenir la vitesse de 9600 bauds. L'envoie des données se fait par détection de l'appui sur bouton poussoir (SW_USER0).
Ci-dessous le détails du bloc de cadencement.

[[Fichier:Counter9600.PNG]]

L'entrée Bp correspondant au bouton poussoir
L'entrée clk correspondant à la clock à 50Mhz
L'entrée Counter[3..0] correspondant au bus du compteur
La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur
Le calcul de la nouvelle séquence d'horloge se fait de la manière suivante :
Front = Bp . /Bp-1
C = ( /Counter . C-1 ) + Front
CE_out = C + Counter

Ces résultats sont à implémenter sur la nanoboard et il reste de plus à corriger les erreurs liées à la conversion.

=== Partie informatique ===

Nous nous sommes occupé ici de la partie configuration du serveur et de la liaison série.

Le code paramétrant la liaison série est fourni dans le sujet du projet, il n'y a pas de modification à faire:

/* Serial library
*/
////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include "serial.h"
////
// Functions
////
//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY);
if(fd<0){ perror(device); exit(-1); }
return fd;
}
//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}
//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

De même, un exemple de fichier configurant le serveur Weebsocket nous a été fourni. Nous l'adaptons donc suivant les données de notre projet qui doivent transiter par le serveur (température, nombre de personne dans la pièce):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libwebsockets.h>
#include <unistd.h>
#include <termios.h>

#include "serial.h"
#define SERIAL_DEVICE "/dev/ttyUSB0"
#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50

int sd;

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
unsigned char signal,temp; // "signal" contient le numero de la diode dont le signal a été coupé, "temp" la valeur de la temperature
int nb_personne; // compteur de personne
nb_personne = 0;

switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
/*case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
sscanf(in,"%d %d",&temp_min,&temp_max);
temp_min = (temp_min+50)*(2.55/5);
//envoyer la tempÃ©rature min
if(temp_min <= 450 && temp_min>= -50 && temp_max <= 450 && temp_max>= -50)
{
if(write(sd,&temp_min,sizeof(char))!=1){ perror("main.write"); exit(-1); }
//envoyer la tempÃ©rature max
temp_max = (temp_max+50)*(2.55/5);
if(write(sd,&temp_max,sizeof(char))!=1){ perror("main.write"); exit(-1); }
}
else
{
printf("Data incorrect");
}
break; */
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(read(sd,&temp,sizeof(char))==1){
char tampon[LWS_SEND_BUFFER_PRE_PADDING+64+LWS_SEND_BUFFER_POST_PADDING];
char *out=tampon+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%d",temp);
temp = ((temp*125)/767.25); // conversion de la temprature en degrés Celsius
printf("%d\n",temp);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);

// traitement sur signal pour avoir le nombre de personne
sprintf(out,"%d",signal);
if(signal==0){
nb_personne++;
}
if(signal == 1){
nb_personne--;
}
printf("%d\n",nb_personne);
libwebsocket_write(wsi,(unsigned char *)out,strlen(out)+1,LWS_WRITE_TEXT);
}
libwebsocket_callback_on_writable(this,wsi);
break;
default:
break;
}
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");
sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
libwebsocket_service(context,WAIT_DELAY);
}
serialClose(sd);
libwebsocket_context_destroy(context);
return 0;
}

== Démonstration ==

== Conclusion ==
Ce premier projet SC en IMA3 nous a permis d’acquérir de multiples compétences.
En premier lieu des compétences techniques en Arduino, FPGA, Altium, WebSocket, HTML et CANVAS. Nous n'avions aucune connaissances dans ces domaines ce qui a été un frein très important sur notre progression. Cependant leur découverte n'a pu apporter que des choses bénéfiques.
Notre programme Arduino fonctionne et nous pourrions l’implémenter directement sur la Raspberry Pie car il n'est en effet pas nécessaire d'utiliser un FPGA dans notre situation.
Nous avons pu découvrir deux environnements totalement différents, l'électronique et l'informatique, qu'il a fallu relier entre eux ce qui consistait en un bon exercice.
Nous avons développé nos compétences sur le travail en autonomie car nous étions la plupart du temps seuls face aux différents problèmes à résoudre.
Nous aurions du revoir notre projet à la baisse au vue des contraintes imposées et de la difficultés de documentation et de prise en main des differents aspects du projet. De cette manière nous aurions pu finaliser un projet moins ambitieux mais fonctionnel.

Projet IMA3 P3, 2015/2016, TD1

2016-03-30T15:50:30Z

Bgriller : /* Partie informatique */

Projet IMA3 P3, 2015/2016, TD1

2016-03-30T15:49:31Z

Bgriller : /* Partie informatique */

Projet IMA3 P3, 2015/2016, TD1

2016-03-30T15:48:05Z

Bgriller : /* Partie informatique */

Projet IMA3 P3, 2015/2016, TD1

2016-03-30T15:47:28Z

Bgriller : /* Partie électronique */

Projet IMA3 P3, 2015/2016, TD1

2016-03-30T15:45:22Z

Bgriller : /* Partie électronique */