Wiki d'activités IMA - Contributions de l’utilisateur [fr]

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:50:59Z

Flefevre :

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

=== RFduino ===

Après avoir conçu notre carte PCB, nous avons pu aborder la programmation de notre contrôleur pour qu'il puisse discuter via BLE avec l'application ainsi qu'interagir avec les composants du PCB. Pour cela, nous utiliserons l'IDE Arduino et principalement deux bibliothèques qui sont <Wire.h> et <RFduinoBLE.h>.

Avant d'attaquer cet aspect, nous avons d'abord pris le temps de comprendre comment fonctionnait le protocole GATT, qui est associé au BLE, mais également le protocole i2C pour la communication avec l'accéléromètre.

Tout notre programme est fourni en fin de Wiki.

=== OptaliBox ===

Notre interface utilisateur à fixer sur le frigo est maintenant prête. Nous devions donc réfléchir au dispositif que nous allions fixer avec des aimants sur la porte du frigo.

Nous avons opté pour un boîtier que nous avons pu concevoir au Fabricarium de l'école. Voici le rendu final :

[[Fichier:Yo2.jpg|200px|thumb|left|Fabrication du boîtier OptaliBox]]
[[Fichier:Yo1.png|300px|thumb|center|OptaliBox contenant notre interface utilisateur]]

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

[[Fichier:Optali-master.zip]]

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

* Programmation BLE RFduino : http://www.rfduino.com/wp-content/uploads/2014/03/rfduino.ble_.programming.reference.pdf
* Programmation BLE Android : https://github.com/lann/RFDuinoTest

Fichier:Yo2.jpg

2017-05-15T17:46:17Z

Flefevre :

Fichier:Yo1.png

2017-05-15T17:45:57Z

Flefevre :

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:34:20Z

Flefevre : /* Avancement du Projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

=== RFduino ===

Après avoir conçu notre carte PCB, nous avons pu aborder la programmation de notre contrôleur pour qu'il puisse discuter via BLE avec l'application ainsi qu'interagir avec les composants du PCB. Pour cela, nous utiliserons l'IDE Arduino et principalement deux bibliothèques qui sont <Wire.h> et <RFduinoBLE.h>.

Avant d'attaquer cet aspect, nous avons d'abord pris le temps de comprendre comment fonctionnait le protocole GATT, qui est associé au BLE, mais également le protocole i2C pour la communication avec l'accéléromètre.

Tout notre programme est fourni en fin de Wiki.

=== OptaliBox ===

Notre interface utilisateur à fixer sur le frigo est maintenant prête. Nous devions donc réfléchir au dispositif que nous allions fixer avec des aimants sur la porte du frigo.

Nous avons opté pour un boîtier que nous avons pu concevoir au Fabricarium de l'école. Voici le rendu final :

[[Fichier:Accelerosch.PNG|500px|thumb|left|Fabrication du boîtier OptaliBox]]
[[Fichier:Accelerosch.PNG|500px|thumb|left|OptaliBox contenant notre interface utilisateur]]

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

[[Fichier:Optali-master.zip]]

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

* Programmation BLE RFduino : http://www.rfduino.com/wp-content/uploads/2014/03/rfduino.ble_.programming.reference.pdf
* Programmation BLE Android : https://github.com/lann/RFDuinoTest

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:17:17Z

Flefevre : /* Bibliographie */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

[[Fichier:Optali-master.zip]]

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

* Programmation BLE RFduino : http://www.rfduino.com/wp-content/uploads/2014/03/rfduino.ble_.programming.reference.pdf
* Programmation BLE Android : https://github.com/lann/RFDuinoTest

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:03:48Z

Flefevre : /* Avancement du Projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

[[Fichier:Optali-master.zip]]

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:02:41Z

Flefevre : /* Codes et fichiers du projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

[[Fichier:Optali-master.zip]]

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T17:02:01Z

Flefevre : /* Codes et fichiers du projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

Archive ZIP :

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

Fichier:Optali-master.zip

2017-05-15T17:01:09Z

Flefevre :

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-15T16:59:40Z

Flefevre : /* Fichiers Rendus */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

=== Codes et fichiers du projet ===

=== Liens vers dépôt GIT ===

* dépôt GIT de l'école : https://archives.plil.fr/ahuet/P46-Aide-anti-gaspillage-alimentaire
* dépôt GitHub : https://github.com/FrancoisLefevre12/Optali

== Bibliographie ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-11T14:40:15Z

Flefevre : /* Rapport de projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_final_P46.pdf]]

== Bibliographie ==

Fichier:Compte rendu projet final P46.pdf

2017-05-11T14:39:44Z

Flefevre :

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-11T14:21:55Z

Flefevre : /* Fichiers Rendus */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|'''02/05'''
*Réalisation de la vidéo de présentation du projet avec Laurent Engels.
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|'''04/05'''
*Débuggage de la "LED_Perim". Le problème n'était donc pas électrique mais bien au niveau software. Il existait un conflit entre l'allumage de cette LED et la pin TX de la liaison série qui était défini sur la même broche.
*Débuggage de l'appli pour éviter les quelques plantages que l'on peut avoir parfois.
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

=== Rapport de projet ===

[[Fichier:Compte_rendu_projet_P46.pdf]]

== Bibliographie ==

Fichier:Compte rendu projet P46.pdf

2017-05-11T14:20:20Z

Flefevre :

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-04T08:43:37Z

Flefevre : /* Feuille d'heures */

Projets IMA4 SC & SA 2016/2017

2017-05-04T08:36:45Z

Flefevre : /* 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
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
| Alexandre Boé / Thomas Vantroys
| Florian Giovannangeli
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
 Feuille de Plexiglass , 
 une plaque de polystérene , 
 3 AOPs (comparateur) , 
 3 Diodes , 
 2 Ventilateurs 100 m3/h 12V [http://www.sellande.com/sellande-webcom/home/393-ventilateur-12v-100m3-h-3752132012327.html?gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgNjN3dRX7D5BOfBUbN9WdjSVzbfLBF_YsaI59D0MaCxoC_oDw_wcB] , 
 1 Panneau solaire 10Wc 12V [https://www.apb-bluepower.com/panneau-solaire-photovoltaique-12v-10w-apb-energy,fr,4,QX-P-10.cfm] , 
 2 sondes de températures [http://fr.rs-online.com/web/p/sondes-de-temperature/1241079/] , 
 une Batterie 70Ah 12V [https://www.manomano.fr/batterie-2319?model_id=1988070&referer_id=537135&gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgcniSnImZEGSLytrHpgv4fTHGFuj1r30kH340E0wmPxoC6ovw_wcB] .
|-
| 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 (en 3v3 finalement) [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], 
 Silicone alimentaire (internet conseillé par un chercheur de l'inria. Prendre sorta clear 40A) [http://www.creation-silicone.com/31.la-serie-sorta-clear] (la cigale et la fourmi à lille) [http://www.cigaleetfourmi.fr/silicones-alginates-et-latex/1262-silicone-alimentaire-peau-liquide-2-kg.html#more_info_tabs] (Rougier&Plé à lille) [http://www.rougier-ple.fr/silicone-alimentaire-4428-1-kg.r.html] 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
 Deux téléphones sur android (dont un LG G4C de l'école). 
|-
| 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\>
Connecteur HE14 MH100 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh100-4457.htm], <br\>
Connecteur HE14 MH190 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh190-4458.htm], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) [http://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] , <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 ). 
CAN 12 bits (ADS1015 12-bit ADC. 
|-
| 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]]
|
 3 modules LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 

|-
| 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], 
|-
| 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. 
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
|
2 x Feather M0 LoRa 433MHz, 
1 x Batterie DC5V LogiLink, 
2 x Capteurs de choc PKGS-00GXP1-R [http://fr.farnell.com/murata/pkgs-00gxp1-r/capteur-de-choc-piezoelec-0-35pc/dp/2707454] , 
3 x Capteurs d'humidité/température SHT11 [http://fr.farnell.com/sensirion/sht11/capteur-humidite-temp-v4/dp/1590511] , 
3 x Accéléromètres FXLS8471QR1 [http://fr.farnell.com/nxp/fxls8471qr1/accelerometre/dp/2377753] , 
1 x Connecteur femelle 16 broches [http://fr.farnell.com/3m/929974-01-16/connect-femelle-16-voies-1-rang/dp/2672440], 
5 x Condensateurs 100nF [http://fr.farnell.com/multicomp/mc0603b104k500ct/condensateur-mlcc-x7r-100nf-50v/dp/1759122], 
2 x Condensateurs 4.7nF [http://fr.farnell.com/walsin/0603x475k6r3ct/condensateur-mlcc-x5r-4-7uf-6/dp/2496930], 
3 x Résistances 10kΩ [http://fr.farnell.com/multicomp/mc0063w0603110k/res-couche-epaisse-10k-1-0-063w/dp/9330399RL], 
|
|}

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-03T15:42:53Z

Flefevre : /* Fichiers Rendus */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

== Bibliographie ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-03T15:31:20Z

Flefevre : /* Raspberry Pi */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-03T15:30:56Z

Flefevre : /* Feuille d'heures */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-03T15:30:24Z

Flefevre : /* Feuille d'heures */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)====

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04''' (3 heures)
*Ajout des listes recettes dans ListeRecette
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
|
|'''03/05'''
*Remplacement de la LED "LED_Perim" qui était défaillante et ne s'allumait pas quand il le fallait.
*Début de la réalisation du rapport de projet.
|
|-
|Semaine 16
|
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-01T18:54:55Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)====

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04'''
*Ajout des listes recettes dans ListeRecette
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
| '''27/04''' (3 heures)
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

Il manque sur la carte finale notre bouton poussoir qui permettait le reset de notre RFduino. Malheureusement en essayant de souder celui-ci, nous avons retiré du cuivre de la carte, ce qui nous empêche de pouvoir faire circuler le courant dans ce bouton. De plus, la piste avec du cuivre manquant était également responsable de l'alimentation de notre accéléromètre ainsi que d'une LED indiquant la mise sous-tension du contrôleur. Pour le rendu final, nous souderons un fil sur la LED pour pouvoir l'alimenter, cependant il serait plus complexe d'alimenter l'accéléromètre. Celui-ci ne fonctionnait déjà pas correctement de manière électrique. La soudure de ce composant demandait une grande précision puisqu'il est de taille minuscule. Nous n'utiliserons donc pas ce composant dans notre montage final.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-05-01T18:48:48Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)====

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04'''
*Ajout des listes recettes dans ListeRecette
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.
|-
|Semaine 15
| '''27/04''' (3 heures)
*Ajout des requêtes des recettes sur ListeRecette.java
*Création du fichier listeRecette.php sur le serveur pour faire la requête SQL et envoyer sur l'application.
|
|
|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

Pour pouvoir souder nos différents composants, nous avons été rendre visite à Thierry Flamen, responsable du service EEI, afin de passer nos composants CMS au four (résistances et accéléromètre). En effet il était presque impossible de souder tous ces composants manuellement. Après ce passage au four, il nous restait les composants traversants à souder, c'est-à-dire les pins, les LEDs et notre buzzer. Voici le rendu après nos soudures :

[[Fichier:pcbfinal1_p46.jpg|200px|thumb|left|Vue du dessous de notre carte]]
[[Fichier:pcbfinal2_p46.jpg|200px|thumb|center|Vue du dessus de notre carte]]

== Fichiers Rendus ==

Fichier:Pcbfinal2 p46.jpg

2017-05-01T18:42:47Z

Flefevre :

Fichier:Pcbfinal1 p46.jpg

2017-05-01T18:41:56Z

Flefevre :

Projets IMA4 SC & SA 2016/2017

2017-05-01T18:40:17Z

Flefevre : /* 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
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
| Alexandre Boé / Thomas Vantroys
| Florian Giovannangeli
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
 Feuille de Plexiglass , 
 une plaque de polystérene , 
 3 AOPs (comparateur) , 
 3 Diodes , 
 2 Ventilateurs 100 m3/h 12V [http://www.sellande.com/sellande-webcom/home/393-ventilateur-12v-100m3-h-3752132012327.html?gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgNjN3dRX7D5BOfBUbN9WdjSVzbfLBF_YsaI59D0MaCxoC_oDw_wcB] , 
 1 Panneau solaire 10Wc 12V [https://www.apb-bluepower.com/panneau-solaire-photovoltaique-12v-10w-apb-energy,fr,4,QX-P-10.cfm] , 
 2 sondes de températures [http://fr.rs-online.com/web/p/sondes-de-temperature/1241079/] , 
 une Batterie 70Ah 12V [https://www.manomano.fr/batterie-2319?model_id=1988070&referer_id=537135&gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgcniSnImZEGSLytrHpgv4fTHGFuj1r30kH340E0wmPxoC6ovw_wcB] .
|-
| 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 (en 3v3 finalement) [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], 
 Silicone alimentaire (internet conseillé par un chercheur de l'inria. Prendre sorta clear 40A) [http://www.creation-silicone.com/31.la-serie-sorta-clear] (la cigale et la fourmi à lille) [http://www.cigaleetfourmi.fr/silicones-alginates-et-latex/1262-silicone-alimentaire-peau-liquide-2-kg.html#more_info_tabs] (Rougier&Plé à lille) [http://www.rougier-ple.fr/silicone-alimentaire-4428-1-kg.r.html] 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
 Deux téléphones sur android (dont un LG G4C de l'école). 
|-
| 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\>
Connecteur HE14 MH100 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh100-4457.htm], <br\>
Connecteur HE14 MH190 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh190-4458.htm], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) [http://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] , <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 ). 
CAN 12 bits (ADS1015 12-bit ADC. 
|-
| 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]]
|
 3 modules LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 

|-
| 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], 
|-
| 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. 
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
|
2 x Feather M0 LoRa 433MHz, 
1 x Batterie DC5V LogiLink, 
2 x Capteurs de choc PKGS-00GXP1-R [http://fr.farnell.com/murata/pkgs-00gxp1-r/capteur-de-choc-piezoelec-0-35pc/dp/2707454] , 
3 x Capteurs d'humidité/température SHT11 [http://fr.farnell.com/sensirion/sht11/capteur-humidite-temp-v4/dp/1590511] , 
3 x Accéléromètres FXLS8471QR1 [http://fr.farnell.com/nxp/fxls8471qr1/accelerometre/dp/2377753] , 
1 x Connecteur femelle 16 broches [http://fr.farnell.com/3m/929974-01-16/connect-femelle-16-voies-1-rang/dp/2672440], 
5 x Condensateurs 100nF [http://fr.farnell.com/multicomp/mc0603b104k500ct/condensateur-mlcc-x7r-100nf-50v/dp/1759122], 
2 x Condensateurs 4.7nF [http://fr.farnell.com/walsin/0603x475k6r3ct/condensateur-mlcc-x5r-4-7uf-6/dp/2496930], 
3 x Résistances 10kΩ [http://fr.farnell.com/multicomp/mc0063w0603110k/res-couche-epaisse-10k-1-0-063w/dp/9330399RL], 
|
|}

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-30T19:49:37Z

Flefevre : /* Feuille d'heures */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Feuille d'heures===
{| class="wikitable"
|-
! !! Lundi 16-18h !! Mercredi 14-18h !! Jeudi 8-10h
|-
|Semaine 1

| '''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

| '''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

| '''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

|-
|Semaine 2

| '''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

| '''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

| '''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

|-
|Semaine 3

| '''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

| '''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.
|
|-
|Semaine 4

| '''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

| '''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

| '''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

|-
|Semaine 5 (interruption pédagogique)====

| '''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

| '''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.
|
|-
|Semaine 6
| '''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

| '''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.
|

|-
|Semaine 7
| '''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

| '''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

| '''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

|-
|Semaine 8
| '''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

| '''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

| '''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

|-
|Semaine 9
| '''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

| '''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

| '''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

|-
|Semaine 10
| '''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

| '''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

|
|-
|Semaine 11

| '''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

| '''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

| '''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

|-
|Semaine 12 (Interruption pédagogique)

| '''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

| '''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

| '''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

|-
|Semaine 13 (Interruption pédagogique)

| '''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

|

|
|-
|Semaine 14
| '''24/04'''
*Modification de la présentation du wiki
*Modification de la fonctionnalité du bouton actualiser en changement d'activité

| '''26/04'''
*Ajout de la page liste recette

| '''27/04'''
*Ajout des listes recettes dans ListeRecette
*Soudure des derniers composants pour terminer le PCB. Tout est soudé sauf le bouton poussoir qui devait permettre un reset du RFduino. En cherchant d'ailleurs à souder ce bouton, nous avons retiré malencontreusement la piste de cuivre permettant de répartir le 3.3V du RFduino sur notre PCB. Notre accéléromètre qui ne marchait déjà pas vraiment n'est plus alimenté. Nous ferons sans notre accéléromètre pour le rendu final.

|}

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-19T14:38:08Z

Flefevre : /* Semaine 13 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

'''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

====Semaine 11====

'''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

'''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

'''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

====Semaine 12 (Interruption pédagogique)====

'''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

'''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

'''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

====Semaine 13 (Interruption pédagogique)====

'''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-19T14:37:55Z

Flefevre : /* Semaine 11 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

'''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

====Semaine 11====

'''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

'''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

'''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

====Semaine 12 (Interruption pédagogique)====

'''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

'''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

'''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

====Semaine 13====

'''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-19T14:37:33Z

Flefevre : /* Semaine 12 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

'''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

====Semaine 11====

'''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

'''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

'''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

====Semaine 12==== (Interruption pédagogique)

'''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

'''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

'''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

====Semaine 13====

'''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-19T14:37:08Z

Flefevre : /* Avancement du Projet */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

'''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

====Semaine 11====

'''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

'''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

'''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

====Semaine 12====

'''11/04''' (3 heures)
*Après avoir remarqué que le code de l'accéléro ne fonctionnait pas alors qu'il paraît correct, nous avons décidez de vérifier les propriétés électriques de notre montage.
En observant à l'analyseur logique, il semblerait que l'horloge de la liaison i2C n'est en fait qu'un signal bruité. Il faudra donc retenter de souder le composant quand cela sera possible.

'''13/04''' (6 heures)
*Terminaison du programme RFduino qui fonctionne théoriquement, nous attendons de terminer les dernières soudures pour pouvoir le tester physiquement.
*En attendant de pouvoir réaliser des soudures, nous avons repris la partie communication bluetooth entre le RFduino et l'appli. Après avoir tenté d'utiliser un programme permettant de gérer le protocole GATT sans savoir envoyer ou recevoir de données, nous nous sommes orientés sur une communication plus basique basée sur de nombreux exemples que l'on peut voir sur le web.

'''15/04''' (6 heures)
*Après s'être rendu compte que la communication plus "basique" que nous voulions utiliser n'était pas compatible avec le BLE, nous sommes une fois de plus repartis de zéro pour cette partie.
*Après quelques recherches, nous avons trouvé un programme réalisant la gestion d'un socket BLE sur le principe du protocole GATT. Grâce à celui-ci, il nous est possible de recevoir et d'envoyer des données via BLE sur RFduino ainsi que sur l'appli mobile.

====Semaine 13====

'''17/04 (4 heures)'''
*Ajout du singleton Etat pour partager l'état des aliments dans la réserve alimentaire
*Transfert des requêtes de la base de donnée vers le singleton pour optimiser l'actualisation et le partage des données.
*Actualisation automatique des données sur la page principale.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-04-09T16:30:22Z

Flefevre : /* Semaine 11 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

'''29/03'''
*Mise en place du tri des Produits avec un critère d'ordonnabilité variable
*Implémentation du champs recherche et action sur la liste
*Écriture des pages Php consume.php et delete.php pour décrémenter le nombre d'aliment dans le frigo ou le supprimer
*Récupération des composants
*Passage au four pour souder les premiers composants en CMS

====Semaine 11====

'''03/04'''
*Dé-soudage et resoudage de l'accéléromètre.
*Soudure des composants

'''05/04'''
*Test du Buzzer
*Code de l'accéléromètre
*Création de l'Optali box (la boite qui contient le RFduino fixé au frigo)
*Finition de la fonction 'delete'

'''06/04'''
*Problème pour faire fonctionner le code de l'accéléro. Il faudra le tester électriquement.
*Implantation du logo de l'appli
*Debuggage d'une requête de la page 'list'
*Documentation sur les listes déroulantes sous les EditTexts.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-27T15:53:32Z

Flefevre : /* Semaine 10 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-27T15:53:14Z

Flefevre : /* Semaine 10 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

====Semaine 10====
'''27/03'''
*Debuggage de la requête get de l'activité ListActivity (suite). Utilisation de la solution postman.
*Mise à jour du wiki pour la partie Altium.
*Gestion du dépôt git.
*Récupération de la carte PCB au service EEI;

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-27T15:00:45Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

Nous avons envoyé nos fichiers Altium au service EEI afin qu'il puisse réaliser physiquement notre carte. Nous nous retrouvons donc avec notre carte PCB récupérée auprès du service EEI. Voici le rendu :

[[Fichier:P46_carte.jpg|400px|thumb|center|Fabrication de notre carte PCB]]

== Fichiers Rendus ==

Fichier:P46 carte.jpg

2017-03-27T14:55:52Z

Flefevre :

Projets IMA4 SC & SA 2016/2017

2017-03-27T14:40:03Z

Flefevre : /* 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
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
| Alexandre Boé / Thomas Vantroys
| Florian Giovannangeli
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
 Feuille de Plexiglass , 
 une plaque de polystérene , 
 3 AOPs (comparateur) , 
 3 Diodes , 
 2 Ventilateurs 100 m3/h 12V [http://www.sellande.com/sellande-webcom/home/393-ventilateur-12v-100m3-h-3752132012327.html?gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgNjN3dRX7D5BOfBUbN9WdjSVzbfLBF_YsaI59D0MaCxoC_oDw_wcB] , 
 1 Panneau solaire 10Wc 12V [https://www.apb-bluepower.com/panneau-solaire-photovoltaique-12v-10w-apb-energy,fr,4,QX-P-10.cfm] , 
 2 sondes de températures [http://fr.rs-online.com/web/p/sondes-de-temperature/1241079/] , 
 une Batterie 70Ah 12V [https://www.manomano.fr/batterie-2319?model_id=1988070&referer_id=537135&gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgcniSnImZEGSLytrHpgv4fTHGFuj1r30kH340E0wmPxoC6ovw_wcB] .
|-
| 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], 
 Silicone alimentaire (internet conseillé par un chercheur de l'inria. Prendre sorta clear 40A) [http://www.creation-silicone.com/31.la-serie-sorta-clear] (la cigale et la fourmi à lille) [http://www.cigaleetfourmi.fr/silicones-alginates-et-latex/1262-silicone-alimentaire-peau-liquide-2-kg.html#more_info_tabs] (Rougier&Plé à lille) [http://www.rougier-ple.fr/silicone-alimentaire-4428-1-kg.r.html] 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
 Deux téléphones sur android (dont un LG G4C de l'école). 
|-
| 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\>
Connecteur HE14 MH100 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh100-4457.htm], <br\>
Connecteur HE14 MH190 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh190-4458.htm], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) [http://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] , <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]]
|
 3 modules LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 

|-
| 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], 
|-
| 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. 
|-
| P3 [[IMA4 2016/2017 P3|Capteurs enfuis pour vieillissement du béton]]
|
|}

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-23T13:06:33Z

Flefevre : /* Semaine 9 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

'''22/03'''
*Debuggage de la requête get de l'activité ListActivity
*Connexion possible entre le RFduino et notre appli mobile. Il faut maintenant pouvoir assurer un échange de données via du GATT.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui envoie la liste des aliments avec leur nom, leur date, leur quantité dans le frigo, la quantité d'exemplaires acheté en tout depuis la mise en place de l'appareil. Le tri se fera directement dans l'application mobile. 

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté. Pour la lecture de caractère, nous utilisons la librairie tesseract.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-21T12:04:53Z

Flefevre : /* Semaine 9 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

'''21/03''' (séance supplémentaire de 3 heures)
*Début du développement de la partie communication entre RFDuino et l'appli mobile. Nous pouvons détecter le RFduino à partir de Android Studio mais nous n'arrivons pas encore à nous connecter dessus directement.
*Finition de la fonctionnalité tesseract. La lecture de caractères est donc maintenant possible.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui récupère un nombre qui défini selon quoi la liste est trié (0=par nom, 1=par date, 2=nombre dans le frigo, 3= par nombre en tout). Elle récupère aussi un mot ou un début de mot ou rien pour faire une recherche dans la base. On utilisera la syntaxe: 
Product.product='".$Search."%'

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-20T16:54:00Z

Flefevre : /* Semaine 8 */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

'''16/03'''
*Changement de stratégie au niveau de la requête JsonArrayRequest. On récupère toute la base et ensuite le traitement sera effectuer dans l'application mobile.
*Rédaction de la partie Altium du wiki.
*Recherche de docs sur le système bluetooth du RFduino.

====Semaine 9====
'''20/03'''
*Réalisation de différents réglages pour pouvoir utiliser l'application Optali sur l'Android phone fourni par notre professeur (LG G4c)
*Recherche de docs concernant la partie java responsable de la communication Bluetooth.
*Reprise de la solution Tesseract pour la lecture de caractères.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui récupère un nombre qui défini selon quoi la liste est trié (0=par nom, 1=par date, 2=nombre dans le frigo, 3= par nombre en tout). Elle récupère aussi un mot ou un début de mot ou rien pour faire une recherche dans la base. On utilisera la syntaxe: 
Product.product='".$Search."%'

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-16T08:34:57Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui récupère un nombre qui défini selon quoi la liste est trié (0=par nom, 1=par date, 2=nombre dans le frigo, 3= par nombre en tout). Elle récupère aussi un mot ou un début de mot ou rien pour faire une recherche dans la base. On utilisera la syntaxe: 
Product.product='".$Search."%'

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

[[Fichier:Finalproto_sch.PNG|400px|thumb|left|Schematic du montage final]]
[[Fichier:Finalproto_pcb.PNG|400px|thumb|center|PCB du montage final]]

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

Fichier:Finalproto sch.PNG

2017-03-16T08:30:04Z

Flefevre :

Fichier:Finalproto pcb.PNG

2017-03-16T08:29:39Z

Flefevre :

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-16T08:12:30Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui récupère un nombre qui défini selon quoi la liste est trié (0=par nom, 1=par date, 2=nombre dans le frigo, 3= par nombre en tout). Elle récupère aussi un mot ou un début de mot ou rien pour faire une recherche dans la base. On utilisera la syntaxe: 
Product.product='".$Search."%'

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

(photo schematic)
(photo pcb)

On retrouve sur notre PCB final les headers, respectivement de 8 et 5 pins, de part et d'autre de la carte, qui représentent le RFDuino, où nous souderons des broches pour qu'elles puissent être intégrées au RFDuino. On note la présence de 5 autres headers de 2 pins, dont 3 pour des LEDs puis les 2 autres pour le buzzer et le bouton poussoir. Ce qui reste sont les composants CMS avec plusieurs composants à 2 pattes qui sont toutes les résistances de notre montage, celles de protection pour les LEDs et les pull-ups pour l'accéléromètre. Le dernier composant à 8 pattes est donc bien l'accéléromètre.

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-16T08:00:39Z

Flefevre : /* Altium Designer */

==Cahier des charges==

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

====Contexte====

En France, nous jetons en moyenne 21% des aliments que nous achetons, ce qui représente une perte de 100 à 160 euros par an par habitant. Cela est en partie dû à la date limite de consommation associée à chaque produit. En effet, à partir du moment où cette date sera dépassée le consommateur jettera les produits concernés sans réfléchir, même si ceux-ci peuvent parfois être encore mangeables. Plutôt que d'essayer de les convaincre du contraire, il serait judicieux de proposer aux adeptes du gaspillage une aide permettant de gérer tous les aliments dont ils disposent chez eux afin d'éviter la surprise de tomber sur plusieurs produits périmés lorsqu'ils ouvrent la porte de leur frigo.

====Objectif du projet====

Ce projet permet d'aider les utilisateurs d'une part à mémoriser les denrées périssables qu'ils disposent dans leur réserve alimentaire et d'autre part d'avertir l'utilisateur qu'un événement important a lieu. Ceci peut être une notification qu'un aliment va bientôt dépasser sa date de péremption, que la porte du frigidaire est restée ouverte ou encore que le nombre d'aliments dans la réserve devient critique et qu'il faudra de nouveau l'alimenter. Enfin, le système aidera l'utilisateur à trouver des idées de repas pouvant permettre de consommer les aliments en fin de vie.

Notre prototype permettra d'éviter le gaspillage alimentaire ainsi que d'aider l'utilisateur dans sa gestion du stockage d'aliments.

====Description du projet====

Notre système sera composé de 3 éléments.

Premièrement, un ou des smartphones appartenant aux utilisateurs. Ces derniers permettront de scanner grâce à son appareil photo, le code barre du produit ainsi que sa date de péremption. Il servira aussi d'interface utilisateur pour notre système. En effet, c'est par cet outil que l'utilisateur pourra lister tous les aliments que l'utilisateur a dans sa base et tout ça en les triant par date de péremption, ou encore voir les recettes possibles pour consommer des aliments en fin de vie.

Deuxièmement, un serveur, de type Raspberry, qui permettra de stocker la base de donnée contenant les aliments de la réserve. Ce serveur sera connecté par wifi.

Troisièmement, un contrôleur (Rfduino) qui comportera une LED pour indiquer la mise sous tension du contrôleur, une LED pour prévenir l'utilisateur qu'un aliment va bientôt passer sa date de péremption et une dernière LED pour prévenir l'utilisateur que son niveau de réserve est critique ainsi qu'un buzzer et un accéléromètre pour buzzer quand la porte du frigo est restée trop longtemps ouverte. Ce dernier sera fixé au frigo par l'intermédiaire d'un dispositif adapté qui sera un système aimanté qui se pose sur le frigo.

Nous implémenterons donc une application mobile Android qui fera le lien entre les 2 autres systèmes.

Pour la partie électronique que nous aurons à réaliser, nous utiliserons une Breadboard pour faire des premiers tests puis nous créerons une carte PCB pour notre montage final.

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

On utilisera une Raspberry Pi en guise de serveur pour pouvoir s'occuper du stockage de toutes les données dans notre projet puisque notre contrôleur sera incapable de les contenir, ce n'est d'ailleurs pas son but ici.

Notre smartphone fera donc le lien entre notre base de données et notre système embarqué par l'intermédiaire de l'application mobile.

Nous prendrons ici un RFduino puisque celui-ci nous permet d'ajouter des modules comme bon nous semble afin d'adapter le système aux besoins de notre application. Il est également parfaitement compatible avec les applications Android. De plus, nous avons un Bluetooth directement intégré au RFduino pour s'assurer que les liaisons RFduino-application mobile se fassent correctement.
On notera également que ce contrôleur consomme peu de courant et ne demande qu'une faible tension d'alimentation, critères importants pour ce genre de projet. C'est la raison principale de son utilisation pour être utilisé comme interface physique sur le frigo, en ajoutant également sa taille réduite comparée à la Raspberry Pi.

====Liste de matériel====

Nous avons donc besoin du matériel suivant :

*Raspberry Pi.
*Clef wifi
*RFduino (RFD22102 DIP Board, RFD22121 USB Shield, RFD22126 Dual AAA battery shield).
*2 piles AAA.
*3 leds tranversantes.
*3 Résistances 330 Ohm.
*1 Résistance 10 kOhm.
*Un buzzer.
*Accéléromètre.
*Aimants
*Un boîtier permettant d'intégrer la RFduino + fixation sur le frigo (modélisation à voir).

Pour le buzzer, l'accéléromètre et les résistances, nous choisirons des composants CMS pour nous permettre d'avoir une carte plus petite.

===Calendrier prévisionnel===

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

* Configurer la Raspberry :
** Installer et configurer le serveur.
** Créer le diagramme UML de notre future base de données.
** Créer la base sur le serveur.
** Configurer la connexion WiFi.

* Monter et programmer la RFduino :
** Connecter les différents modules au RFduino (accéléromètre, LEDs, buzzer, Batterie, module Bluetooth).
** Récupérer les consignes du smartphone grâce au Bluetooth.
** Programmer le comportement du RFduino en fonction des consignes.
** Construire le boitier final.

* Implémenter l'application mobile Android :
** Une première activité permettant de se connecter au RFduino et à la Raspberry.
** Scanner une date et un code barre.
** Ajout/suppression d'un aliment dans la base de donnée.
** Envoi d'une consigne au RFduino.
** Rendre l'interface utilisateur ergonomique (lister aliments, envoyer vers page de recettes avec l'utilisation des aliments bientôt périmés...).

====Calendrier====

Répartition du temps consacré au projet (120h *2) :

*Partie Raspberry : 60h
*Partie RFduino : 60h
*Partie développement mobile : 120h

==Avancement du Projet==

===Résumé===

====Semaine 1====

'''23/01''' :
* Installation du logiciel Android Studio pour être prêt à commencer l'application mobile.
* Création du Repository Git sur GitHub : https://github.com/FrancoisLefevre12/Optali.git
* Réalisation de différents schémas fonctionnels pour se donner une idée du travail à effectuer, aussi bien du software que du hardware.
* Quelques précisions supplémentaires apportées sur le cahier des charges.
* Ajout de liens de référence pour la liste de matériel à acheter.

'''25/01''' :
* Précision des composants requis (accéléromètre, buzzer, LEDs, résistances).
* Écriture du montage à la main.
* Étude du fonctionnement de l'accéléromètre, du buzzer.
* Écriture de la structure de l'application à la main.

'''26/01''' :
*Réalisation graphique de la première page de l'application.
*Conception du schéma électrique pour tous les composants connectés au RFduino.

====Semaine 2====

'''30/01''' :
*Réalisation du diagramme UML de la base de données qui sera stockée sur la Raspberry Pi
*Installation de l'outil de développement mobile sur le second PC

'''01/02''' :
*Nous nous sommes d'abord rendus compte que la résistance entre un des GPIO et l'accéléromètre était inutile, nos premiers calculs étaient erronés. Nous ne la garderons donc pas sur notre schéma électrique final.
*Avancement sur la partie application mobile : réalisation de la page "Ajout" sur laquelle nous tomberons après avoir cliquer sur "ajout" sur la page principale de l'application. Nous avons étendu l'activité principale jusqu'à cette nouvelle activité "Ajout".
*Nous avons récupéré notre Raspberry Pi pour commencer à installer notre base de données dessus. Nous avons actuellement quelques problèmes pour nous connecter sur la Raspberry. Nous travaillons sur ce point.

'''02/02''' :
* Application mobile : Mise en place des LEDs sur la home page et de la zone de notification avec les messages associés.

====Semaine 3====

'''06/02''' :
*Nous arrivons à accéder à la Raspberry via le port série de celle-ci. Nous avons également configuré sa connexion Ethernet afin de pouvoir télécharger des paquets dessus et installer notre base de données.
*Nous rencontrions des problèmes sur le second PC de travail pour récupérer le projet Optali sur Android Studio via notre dépôt GIT. Nous avons pu rectifier ce souci.

'''08/02''' :
*Tentative d'établissement d'un point d'accès WiFi sur notre Raspberry. Nous n'avons pas réussi pour le moment.
*Restructuration du Repository git.
*Essai d'importation de la librairie Zxing qui permettra de décoder les code-barres.

====Semaine 4====

'''13/02'''
*Configuration du wifi de la Raspberry.
*Étude d'une mise en place d'un service web via php.

'''15/02'''
*Mise en place d'un lecteur de caractère sur l'application. On utilisera tesseract.
*Début de la création du PCB via Altium designer. Création d'une librairie pour l'accéléromètre qui est un composant CMS assez spécial. On pourra cependant utiliser des headers classiques pour le buzzer et les LEDs puisque ce sont des composants traversants.
*Création des premiers fichiers php de connection à la base de donnée et d'insertion d'aliments. Tous ces fichiers seront déposés de la même manière sur le dépôt git.

'''16/02'''
*Adaptation avec prise en compte des cas du code php d'insertion de produits par requête sur la base de donnée.
*Ajout du code d'implantation de la base de donnée.
*Altium: Accéléromètre terminé, mise en place des résistances.

====Semaine 5 (interruption pédagogique)====

'''22/02 (3 heures)'''
*Installation de l'OS de la raspberry.
*Installation d'Openssh-server, apache2, php5, iptables, mysql-server, php5-mysql.
*Redirection des ports du routeur vers la raspberry.
*Configuration de iptables de la raspberry.

'''23/02 (2 heures)'''
*Implantation de la base de donnée sur la raspberry pi.

====Semaine 6====
'''27/02'''
*Vérification de la syntaxe de l'insertion de valeurs dans la base de donnée.
*Création des premières requêtes sur la base de donnée.
*Finalisation du PCB de l'Optali Board.

'''01/03'''
*Étude et ajout de la librairie volley pour communiquer avec le serveur.
*Implantation de la fonction d'envoi de données jusqu'au serveur.
*Après avoir vu avec un professeur, nous avons remarqué que le routage n'était pas adéquat et la disposition des composants n'était pas optimal. Du travail reste donc encore à effectuer.

====Semaine 7====
'''06/03'''
*Correction du fichier post.php
*Finition du protocole d'ajout d'aliment sur la base de donnée. (Code php et page ajout terminée).
*PCB terminé.
*Installation d'arduino IDE, doc arduino collecté.

'''08/03'''
*Implémentation de la page ListeIngredient.xml et de l'activité listActivity.java.
*Documentation sur la procédure de communication bluetooth entre la Rfduino et l'application mobile.
*Obtention de librairie en lien avec cela.
*Prise en main de programmation rfduino.

'''09/03'''
*Nous nous sommes rendus compte qu'il était nécessaire de rajouter un bouton poussoir sur notre montage afin de permettre la réinitialisation de notre RFDuino si nécessaire. Nous devons également faire en sorte de pouvoir poser notre carte PCB directement sur notre RFDuino en utilisant des broches. Nous devons donc rajouter ces éléments-ci.
*Ecriture de la page get.php
*Premiers tests sur la ListView de l'activité ListActivity.

====Semaine 8====
'''13/03'''
*Recherche de pistes concernant la programmation RFDuino. Nous pouvons la détecter en bluetooth via un smartphone Android.
*Finition du Tablelayout et du code java associé sur la page ListActivity.

'''15/03'''
*Ajout de la JsonArrayRequest dans la page ListActivity.
*Nous nous sommes rendus compte au moment de programmer la liaison I2C de l'accéléromètre avec la RFDuino que nous avions oublié de mettre des résistances pull-up entre l'alimentation du composant et les broches SDA et SCL. Les modifications ont donc été faites puis nous avons envoyé finalement notre PCB à la fabrication.

===Premières idées===

Voici les premières idées de l'application mobile et du composant fixé sur le frigo.
[[Fichier:Optali_v1.jpg|400px|thumb|left|Optali version 1]]
[[Fichier:OptaliBox_v1.jpg|400px|thumb|center|OptaliBox version 1]]
[[Fichier:P46_schema.jpg|400px|thumb|center|Schéma électrique version 1]]

En s'intéressant aux différentes datasheets ou données constructeur des composants que nous voulons utiliser, nous trouvons indispensable d'utiliser des résistances de 330 Ohms pour l'utilisation des LEDs, pour éviter de les griller.

Edit : Retrait de la résistance R2.

Concernant l'accéléromètre, nous avons choisi un modèle qui nous permet de brancher directement ce module sur une broche du RFDuino. On branchera directement les GPIOs de la RFduino sur les ports SDA et SCL de l'accéléromètre qui correspondent à l'interface I2C pour pouvoir communiquer. On utilisera aussi la broche INT1 pour pouvoir générer des interruptions directement depuis l'accéléromètre.

On connectera le buzzer directement à une broche de la RFduino aussi. Concernant celui-ci il reste une incertitude puisqu'on ne trouve aucune information sur le courant à fournir pour l'alimentation de ce composant sur sa datasheet. Après différentes recherches sur Internet, il pourrait être nécessaire d'utiliser un montage amplificateur à transistor comme un émetteur commun pour booster le courant en sortie d'une broche GPIO. Quelques buzzers trouvés avec des données constructeur montrent que ce type de composant nécessite généralement un courant d'environ 30 mA. Nous verrons dans la pratique si cela sera vraiment nécessaire. Par sécurité, on ajoutera un transistor bipolaire dans la liste de matériel.

[[Fichier:screen_LED.png|400px|thumb|left|Données constructeur pour LEDs]]
[[Fichier:screen_accel.png|400px|thumb|center|Datasheet de l'accéléromètre]]

===Raspberry Pi===

====Configuration école====

*Pour configurer notre Raspberry Pi, nous utilisons son port série et "minicom". Pour pouvoir télécharger des paquets, il fallait la connecter au réseau. Nous lui avons donc affecté une adresse IP fixe avec le fichier /etc/network/interfaces. Voici les modifications qui ont été apportées :

auto eth0
iface eth0 inet static
address 172.26.78.15
netmask 255.255.240.0
gateway 172.26.79.254

Il a également fallu ajouter la commande "export http_proxy=http://proxy.polytech-lille.fr:3128" (il faudra effectuer cette commande à chaque démarrage de la Pi) pour pouvoir utiliser le proxy de l'école.
Nous avons de plus modifier le fichier /etc/resolv.conf avec la ligne suivante :

nameserver 193.48.57.34

Malgré cela, nous avions des soucis pour nous connecter au réseau. Il y avait en fait un processus dhcp en tâche de fond qui nous empêchait de garder le contenu de resolv.conf. Il a donc fallu trouver ce processus pour le "kill" et pouvoir accéder correctement au réseau.

Nous avons du coup pu installer postgresql pour pouvoir configurer une base de données sur notre Pi.

====Configuration à domicile====

Pour nous mettre dans une situation plus fidèle à notre projet, nous avons configuré la raspberry à domicile.

Nous avons tout d'abords installé Raspbian, puis installé les paquets nécessaire au fonctionnement du serveur. 
- '''Openssh-server''': permettre d'accès à distance à la raspberry pour pouvoir y accéder depuis l'école. 
- '''Iptables''': pour sécuriser les ports non utilisé et libérer l'accès aux ports qui nous intéressent (ssh 22,http 80,https 443). 
- '''apache2, php5, mysql-server''' : pour mettre en place notre service web. 

Ensuite nous avons rediriger les ports 80 et 22 du routeur pour pouvoir accéder à la raspberry de l'extérieur.

Pour finir, nous avons créer un fichier de config iptables permettant de sécuriser un minimum la base de donnée et de permettre d'autoriser la communication des ports 22, 80 et 443 correspondants aux ports ssh, http et https. le fichier de configuration a été déposé dans le dépôt git. Il nous a fallut le rendre exécutable via un chmod. Puis pour l'exécuter à chaque démarrage du system, dans le fichier /etc/init.d/ taper :

sudo update-rc.d firewall defaults (si notrefichier s'appelle firewall et s'il est dans init.d)

===Base de donnée===

Nos données alimentaires disponibles par toute la famille doivent être stocké sur un serveur de base de donnée externe (tel une Raspberry pi). Nous nous proposons de créer le diagramme UML représentant cette future base de donnée.
[[Fichier:Optali_UML.jpg|700px|thumb|center|Diagramme UML base de donnée]]

On créera donc 3 entités. Date, Product et Recipe.

- Product rassemble les aliments qui sont ou ont été dans la réserve alimentaire. NbProdIn permet de connaître le nombre de produits identiques (possibilité de date différentes mais pas de doublons et on garde l'information de quantité. NbProdBought donne une information sur le nombre de produits identique ayant été acheté depuis la mise en service de la base de donnée. Ainsi nous pourrons par la suite proposer une liste de course à l'utilisateur en fonction de la fréquence d'achat des produits.

- Recipe contient les recettes que pourra rentrer l'utilisateur sur l'application. L'utilisateur pourra ainsi se voir proposer des recettes en fonction de ce qu'il a dans son frigo et de ses recettes personnelles.

'''''Edit : On ajoutera une valeur entière dans les tables Date et Unity pour gérer le cas où il existe plusieurs produits (différents ou identiques) avec une date de péremption équivalente. On les appellera NbDate la valeur dans la table Date et NbUnity dans la table Unity. On leur ajoutera de même une clef primaire IdUnity et IdListProduct'''''

On utilisera MySql pour la gestion de nos bases de données.
La syntaxe pour l'implanter dans la base de donnée à été jointe au dépôt git.

Pour lancer my SQL, on tapera:

mysql -h localhost -u root -p

===Web service===

====Page init.php====

Page qui permet d'initier l'accès à la base de donnée sur le serveur. Elle est requise pour les pages qui suivent.

====Page post.php====

Page qui permet l'insertion d'un produit et d'une date via l'application mobile. Elle prend donc ces deux arguments et les insère dans les tables Unity, Product et Date.

====Page get.php====

Page qui récupère un nombre qui défini selon quoi la liste est trié (0=par nom, 1=par date, 2=nombre dans le frigo, 3= par nombre en tout). Elle récupère aussi un mot ou un début de mot ou rien pour faire une recherche dans la base. On utilisera la syntaxe: 
Product.product='".$Search."%'

===Application Mobile===

====Home page====

Page d'accueil permettant d'accéder aux pages d'ajout et de liste des produits disponibles. 
La page permet aussi d'effectuer la connexion entre la rfduino et l'application mobile. Elle montre les alertes (signaux) à l'utilisateur
et écrit leur signification.

====Page d'ajout====

Pour ajouter un produit et lire une date on utilisera un champ editText pour permettre à l'utilisateur d'écrire "Manuellement" dedans grâce au clavier du smartphone. 
De plus on utilise un bouton qui appellera la caméra pour détecter les caractères d'un produit ou d'une date. Au début nous voulions utiliser un détecteur de code barre, nous l'avons implémenté mais nous avons remarqué que la mise au point sur une surface non plane prend du temps d'autant plus qu'il faut questionner une base de donnée contenant tous les numéro de codes barres utilisés. Nous avons donc prit la décision d'utiliser uniquement la lecture de caractère et nous créerons une liste déroulante sous l'editText pour faciliter l'insertion d'un produit qui a déjà été ajouté.
 
Pour l'envoi, nous utilisons la librairie Volley développé par google.

====Page Liste====

Permet de lister les produits dans la base de donnée. Une série de boutons radio permettent de trier les produits par ordre alphabétique, par date de péremption, par nombre d’occurrence dans la réserve alimentaire, par nombre d'achat depuis la mise en place du système. 
Une colonne permet de sélectionner les aliments désirés (par checkBox) pour ensuite les supprimer via un button "suppr" ou les choisir pour trouver des recettes qui les utilisent. 
Un EditText permet d'effectuer une recherche sur la base de donnée.

===Altium Designer===

Pour permettre au RFDuino de communiquer avec les différents composants, nous aurons besoin de quelques composants électroniques. Afin que cela soit plus esthétique pour la modélisation finale, nous allons créer une carte PCB pour rassembler tous ces composants dessus. On utilisera le logiciel Altium Designer pour cela.

Avant de représenter notre circuit général, nous allons commencer par créer une librairie rassemblant tous les composants que nous utiliserons par la suite, en particulier nos composants CMS (accéléromètre et résistances). Pour ce qui est des LEDs et du buzzer, qui sont traversants, nous pourrons utiliser des headers classiques.

Il a donc fallu créer le schematic ainsi que l'empreinte de nos composants CMS. Voici un exemple avec notre accéléromètre :
[[Fichier:Accelerosch.PNG|500px|thumb|left|Schematic de l'accéléromètre]]
[[Fichier:Acceleropcb.PNG|500px|thumb|center|Empreinte PCB de l'accéléromètre]]

Tous les fichiers Altium sont disponibles sur notre dépôt GIT. Après cela, nous pouvons maintenant construire notre schematic du montage entier et ensuite le fichier PCB afin de pouvoir graver notre circuit.

Après quelques modifications sur le montage prévu initialement, c'est-à-dire en enlevant une résistance entre un GPIO et l'alimentation de l'accéléromètre ainsi qu'en rajoutant des résistances pull-up sur les broches de notre liaison i2C (SDA et SCL) et un bouton poussoir en plus pour permettre un reset du RFDuino, nous avons pu créer notre schematic global pour en faire un PCB et l'exporter au format Gerber. De ce fait, le service EEI de Polytech pourra réaliser la gravure de notre carte PCB.

Voici quelques photos pour illustrer notre projet sur Altium :

(photo schematic)
(photo pcb)

Quelques difficultés ont été rencontrées durant ce travail notamment concernant les contraintes de construction sur le PCB final. En effet, les composants CMS choisis (surtout l'accéléromètre) étant parfois très petits, Altium n'accepte pas forcément le faible espacement entre les différentes pattes des composants, ce qui pose problème lors de la compilation. De plus, le plan de masse ne prenait pas en compte tous les éléments devant être rattachés à la masse. Il a fallu légèrement déplacer les headers représentant le RFDuino pour que cela soit possible. Il faudra alors peut-être légèrement plier les broches qui viendront s'intégrer sur le RFDuino pour ajouter notre PCB sur le RFDuino.

== Fichiers Rendus ==

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-15T17:28:16Z

Flefevre : /* Semaine 8 */

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-13T17:17:37Z

Flefevre : /* Semaine 7 */

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-09T08:51:05Z

Flefevre : /* Semaine 7 */

Projets IMA4 SC & SA 2016/2017

2017-03-09T07:30:32Z

Flefevre : /* 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]]
|
 Feuille de Plexiglass , 
 une plaque de polystérene , 
 3 AOPs (comparateur) , 
 3 Diodes , 
 2 Ventilateurs 100 m3/h 12V [http://www.sellande.com/sellande-webcom/home/393-ventilateur-12v-100m3-h-3752132012327.html?gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgNjN3dRX7D5BOfBUbN9WdjSVzbfLBF_YsaI59D0MaCxoC_oDw_wcB] , 
 1 Panneau solaire 10Wc 12V [https://www.apb-bluepower.com/panneau-solaire-photovoltaique-12v-10w-apb-energy,fr,4,QX-P-10.cfm] , 
 2 sondes de températures [http://fr.rs-online.com/web/p/sondes-de-temperature/1241079/] , 
 une Batterie 70Ah 12V [https://www.manomano.fr/batterie-2319?model_id=1988070&referer_id=537135&gclid=CjwKEAiAlZDFBRCKncm67qihiHwSJABtoNIgcniSnImZEGSLytrHpgv4fTHGFuj1r30kH340E0wmPxoC6ovw_wcB] .
|-
| 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], 
 Silicone alimentaire (internet conseillé par un chercheur de l'inria. Prendre sorta clear 40A) [http://www.creation-silicone.com/31.la-serie-sorta-clear] (la cigale et la fourmi à lille) [http://www.cigaleetfourmi.fr/silicones-alginates-et-latex/1262-silicone-alimentaire-peau-liquide-2-kg.html#more_info_tabs] (Rougier&Plé à lille) [http://www.rougier-ple.fr/silicone-alimentaire-4428-1-kg.r.html] 
 ARduino uno pour essais, 
 Servomoteur pour essais. 
 Deux téléphones sur android (dont un LG G4C de l'école). 
|-
| 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\>
Connecteur HE14 MH100 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh100-4457.htm], <br\>
Connecteur HE14 MH190 (x10) [http://www.gotronic.fr/art-connecteur-he14-mh190-4458.htm], <br\>
Capteurs Ultrasons SR04 (x3), <br\>
Piles ou accumulateurs (x16 à 1.5V), <br\>
Odomètres codeurs (x4) , <br\>
Boutons poussoirs (x4) [http://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] , <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]]
|
 3 modules LoRa 3179 Adafruit [http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ==],, 

|-
| 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 P46 : Aide anti-gaspillage alimentaire

2017-03-01T15:38:43Z

Flefevre : /* Altium Designer */

IMA4 2016/2017 P46 : Aide anti-gaspillage alimentaire

2017-03-01T15:35:04Z

Flefevre : /* Premières idées */