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

Encaissement RFID

2014-02-26T13:37:44Z

Jkemajou : /* Le back office (Interface Administrateur) */

=''Présentation du projet''=
----
== Objectif ==

Le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur entreprise, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur entreprise. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur entreprise et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur entreprise afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|600px]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez entreprise qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Il nous a donc proposé de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur.

Une prochaine réunion a été envisagée afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel protocole pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

[[Fichier:Diag_dep.png|500px|thumb|left|Digramme de déploiement]]
[[Fichier:Arch_Fonc1.png|600px|thumb|right|Architechture Fonctionnelle]]

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

 

=''Réalisation de l'application WEB J2EE ''=
----
== Choix d'implémentation ==

====Le choix du modèle MVC====
[[Fichier:Mcv_diag.png|200px|thumb|left|modèle MVC]]
 
Nous avons choisi de respecter le modèle MVC pour réaliser notre application car une architecture MVC cherche à séparer trois choses : le Modèle, les Vues et les Contrôleurs. Les contrôleurs permettent de répondre aux actions de l'utilisateur. Chaque contrôleur est associé à une vue : cette dernière permet uniquement de présenter des informations à un utilisateur. Bien entendu, l'information renvoyée est dépendante des actions d'entrées de l'utilisateur. Les traitements sont réalisés par le modèle (la logique métier).
 
Etant donné que nous cherchons à mettre en œuvre une architecture MVC via un environnement J2EE, on peut donc faire les rapprochements suivants :
*Un contrôleur est implémenté sous forme de servlet Java.
*Le modèle consiste en l'implémentation de la logique métier du site Web.
*Chaque vue est implémentée via une JSP.

====Diagramme de classes====

[[Fichier:Diag_class.png|700px|diagramme de classes]]

== Développement: niveau EJB ==
La technologie J2EE repose sur la notion de Bean, implémentée sous forme de classes Java, ces objets particuliers, gérés par le container et stockés dans la base de données, sont de 2 types: les entity Bean (persistants) et les Session beans (relatifs au contexte d’utilisation).

====les entity beans====

Un Bean entité aura comme annotation « @Entity ».
La clef primaire est définie par une annotation « @Id ».
Voici la liste des beans qui constituent la structure du site :
[[Fichier:Bean_client.png|500px|bean client]][[Fichier:Bean_panier.png|500px|bean panier]][[Fichier:Bean_produit.png|500px|bean produit]]

Pour chaque clé primaire, on assigne une propriété de génération et d’auto incrémentation. (L’annotation sera @GeneratedValue).

====les sessions beans====

L'accès aux Entity Beans est réalisé à travers un entity manager. Cet entity manager sera accessible par un bean session sans état.
Nous avons utilisé deux sessions bean : « ClientManager » pour décrire les méthodes utilisés par un client et « AdminManager » pour décrire les méthodes utilisées par un administrateur. Ces deux sessions bean sont « stateless ».
Le bean « ClientManager » possède trois méthodes principales tandis que le bean « AdminManager » possède huit méthodes principales tous les deux définies par des interfaces @remote et @local.Voici la liste des sessions beans qui constituent la structure du site:

[[Fichier:Session_clientManager.png|500px|session bean client]][[Fichier:Session adminManager.png|500px|session bean admin]]

Les 2 sessions Bean sont utilisées pour accéder aux beans depuis un client local. Tout au long de notre projet, seules les interfaces locales seront utilisées.Les beans stateless vont utiliser un objet entity Manager afin de manipuler les entités. Pour cela, il y a utilisation de la nouvelle fonctionnalité des EJB 3.0 : l'injection de ressource ou "dependency injection".

@PersistenceContext( unitName = « JPADB »)
protected EntityManager em;

L'annotation « @PersistenceContext » va être analysée par le conteneur et la variable « entityManager » va être initialisée. Ensuite, il suffit d'appeler des méthodes sur cette variable. Ce n'est plus au développeur de rechercher la variable, il demande au conteneur.

NB : L’ajout en base de données se fait en créant des beans et en les persistant au travers de l’entity manager.Lorsqu’on veut par contre récupérer une information en base de données, il y a interrogation de l'entity manager en effectuant une requête en base grâce à l’annotation « @NamedQuery ».

====les relations====

Les relations que nous avons définit entre nos entités constituent un élément clef des EJB, elles permettent de définir au sein de la base de données des relations entre les beans qui y sont enregistrés. Ces relations ont été définies dès la conception du projet et font partie intégrante de la structure de la base de données. Nous allons principalement utiliser dans notre projet la relation « @onetomany - @manytoone»

Voici un schéma symbolisant les différentes relations entre nos EJB

[[Fichier:Relation_ejb.png|500px|relation ejb]]

== Développement: niveau WEB ==

Nous avons décidé de scindé notre interface web en deux :
*Le back office ou interface administrateur, qui permettra à l’administrateur du site d’effectuer certaines mise à jour comme le rajout de nouveaux produits en base de données.
*Le front office ou interface client, qui permettra au client après connexion d’accéder à son compte, de visualiser ses commandes et de valider ses achats.
Ces interfaces sont donc respectivement outillées par les sessions-beans AdminManager et ClientManager déjà décrites plus haut.

====Le back office (Interface Administrateur)====

Cette interface est constituée de la servlet AjouterPanier.java, de la JSP ajouterproduit.jsp et de l’objet métier ProduitForm.java

[[Fichier:Interface_admin.png|500px|thumb|right|Interface Administrateur]]
<br\>
Il s’agit d’un formulaire qui permet à l’administrateur du site de rajouter des produits en base de données en renseignant leurs attributs. (Nom, epc et description)
Il permet aussi d’afficher les messages d’erreurs ou de succès comme le montre le schéma ci-dessous:
[[Fichier:Interface_admin_erreur.png|500px|thumb|left|Interface Administrateur avec erreur]]
<br\><br\><br\><br\><br\><br\><br\><br\><br\><br\>
concernant notre modèle, c’est lui qui permet effectivement de rajouter de nouveaux produits en base de données en se basant sur les méthodes décrites dans la session-beans adminManager. Il vérifie que notre rajout se passe bien et s’occupe aussi de la vérification des champs du formulaire : c’est-à-dire savoir si tous les champs de la JSP sont correctement remplis lors du « submit », savoir si on n’est pas en train de rentrer deux fois les mêmes produits en base de données.
Il permet aussi de générer les messages d’erreurs ou de succès en cas d’erreur ou de succès de l’ajout en base de données. voici ci-dessous les méthodes dont nous avons eu besoin:

[[Fichier:Modele_produit.png|500px|Interface Administrateur avec erreur]]

Encaissement RFID

2014-02-26T13:35:41Z

Jkemajou : /* Développement: niveau EJB */

=''Présentation du projet''=
----
== Objectif ==

Le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur entreprise, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur entreprise. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur entreprise et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur entreprise afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|600px]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez entreprise qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Il nous a donc proposé de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur.

Une prochaine réunion a été envisagée afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel protocole pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

[[Fichier:Diag_dep.png|500px|thumb|left|Digramme de déploiement]]
[[Fichier:Arch_Fonc1.png|600px|thumb|right|Architechture Fonctionnelle]]

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

 

=''Réalisation de l'application WEB J2EE ''=
----
== Choix d'implémentation ==

====Le choix du modèle MVC====
[[Fichier:Mcv_diag.png|200px|thumb|left|modèle MVC]]
 
Nous avons choisi de respecter le modèle MVC pour réaliser notre application car une architecture MVC cherche à séparer trois choses : le Modèle, les Vues et les Contrôleurs. Les contrôleurs permettent de répondre aux actions de l'utilisateur. Chaque contrôleur est associé à une vue : cette dernière permet uniquement de présenter des informations à un utilisateur. Bien entendu, l'information renvoyée est dépendante des actions d'entrées de l'utilisateur. Les traitements sont réalisés par le modèle (la logique métier).
 
Etant donné que nous cherchons à mettre en œuvre une architecture MVC via un environnement J2EE, on peut donc faire les rapprochements suivants :
*Un contrôleur est implémenté sous forme de servlet Java.
*Le modèle consiste en l'implémentation de la logique métier du site Web.
*Chaque vue est implémentée via une JSP.

====Diagramme de classes====

[[Fichier:Diag_class.png|700px|diagramme de classes]]

== Développement: niveau EJB ==
La technologie J2EE repose sur la notion de Bean, implémentée sous forme de classes Java, ces objets particuliers, gérés par le container et stockés dans la base de données, sont de 2 types: les entity Bean (persistants) et les Session beans (relatifs au contexte d’utilisation).

====les entity beans====

Un Bean entité aura comme annotation « @Entity ».
La clef primaire est définie par une annotation « @Id ».
Voici la liste des beans qui constituent la structure du site :
[[Fichier:Bean_client.png|500px|bean client]][[Fichier:Bean_panier.png|500px|bean panier]][[Fichier:Bean_produit.png|500px|bean produit]]

Pour chaque clé primaire, on assigne une propriété de génération et d’auto incrémentation. (L’annotation sera @GeneratedValue).

====les sessions beans====

L'accès aux Entity Beans est réalisé à travers un entity manager. Cet entity manager sera accessible par un bean session sans état.
Nous avons utilisé deux sessions bean : « ClientManager » pour décrire les méthodes utilisés par un client et « AdminManager » pour décrire les méthodes utilisées par un administrateur. Ces deux sessions bean sont « stateless ».
Le bean « ClientManager » possède trois méthodes principales tandis que le bean « AdminManager » possède huit méthodes principales tous les deux définies par des interfaces @remote et @local.Voici la liste des sessions beans qui constituent la structure du site:

[[Fichier:Session_clientManager.png|500px|session bean client]][[Fichier:Session adminManager.png|500px|session bean admin]]

Les 2 sessions Bean sont utilisées pour accéder aux beans depuis un client local. Tout au long de notre projet, seules les interfaces locales seront utilisées.Les beans stateless vont utiliser un objet entity Manager afin de manipuler les entités. Pour cela, il y a utilisation de la nouvelle fonctionnalité des EJB 3.0 : l'injection de ressource ou "dependency injection".

@PersistenceContext( unitName = « JPADB »)
protected EntityManager em;

L'annotation « @PersistenceContext » va être analysée par le conteneur et la variable « entityManager » va être initialisée. Ensuite, il suffit d'appeler des méthodes sur cette variable. Ce n'est plus au développeur de rechercher la variable, il demande au conteneur.

NB : L’ajout en base de données se fait en créant des beans et en les persistant au travers de l’entity manager.Lorsqu’on veut par contre récupérer une information en base de données, il y a interrogation de l'entity manager en effectuant une requête en base grâce à l’annotation « @NamedQuery ».

====les relations====

Les relations que nous avons définit entre nos entités constituent un élément clef des EJB, elles permettent de définir au sein de la base de données des relations entre les beans qui y sont enregistrés. Ces relations ont été définies dès la conception du projet et font partie intégrante de la structure de la base de données. Nous allons principalement utiliser dans notre projet la relation « @onetomany - @manytoone»

Voici un schéma symbolisant les différentes relations entre nos EJB

[[Fichier:Relation_ejb.png|500px|relation ejb]]

== Développement: niveau WEB ==

Nous avons décidé de scindé notre interface web en deux :
*Le back office ou interface administrateur, qui permettra à l’administrateur du site d’effectuer certaines mise à jour comme le rajout de nouveaux produits en base de données.
*Le front office ou interface client, qui permettra au client après connexion d’accéder à son compte, de visualiser ses commandes et de valider ses achats.
Ces interfaces sont donc respectivement outillées par les sessions-beans AdminManager et ClientManager déjà décrites plus haut.

====Le back office (Interface Administrateur)====

Cette interface est constituée de la servlet AjouterPanier.java, de la JSP ajouterproduit.jsp et de l’objet métier ProduitForm.java

[[Fichier:Interface_admin.png|500px|thumb|right|Interface Administrateur]]
<br\>
Il s’agit d’un formulaire qui permet à l’administrateur du site de rajouter des produits en base de données en renseignant leurs attributs. (Nom, epc et description)
Il permet aussi d’afficher les messages d’erreurs ou de succès comme le montre le schéma ci-dessous:
[[Fichier:Interface_admin_erreur.png|500px|thumb|left|Interface Administrateur avec erreur]]

concernant notre modèle, c’est lui qui permet effectivement de rajouter de nouveaux produits en base de données en se basant sur les méthodes décrites dans la session-beans adminManager. Il vérifie que notre rajout se passe bien et s’occupe aussi de la vérification des champs du formulaire : c’est-à-dire savoir si tous les champs de la JSP sont correctement remplis lors du « submit », savoir si on n’est pas en train de rentrer deux fois les mêmes produits en base de données.
Il permet aussi de générer les messages d’erreurs ou de succès en cas d’erreur ou de succès de l’ajout en base de données. voici ci-dessous les méthodes dont nous avons eu besoin:

[[Fichier:Modele_produit.png|500px|Interface Administrateur avec erreur]]

Fichier:Modele produit.png

2014-02-26T13:35:23Z

Jkemajou :

Fichier:Interface admin erreur.png

2014-02-26T13:27:32Z

Jkemajou :

Fichier:Interface admin.png

2014-02-26T13:21:58Z

Jkemajou :

Encaissement RFID

2014-02-26T13:16:06Z

Jkemajou : /* les sessions beans */

Fichier:Relation ejb.png

2014-02-26T13:14:13Z

Jkemajou :

Encaissement RFID

2014-02-26T13:06:01Z

Jkemajou : /* les entity beans */

Fichier:Session adminManager.png

2014-02-26T12:59:23Z

Jkemajou :

Fichier:Session clientManager.png

2014-02-26T12:58:30Z

Jkemajou :

Encaissement RFID

2014-02-26T12:45:28Z

Jkemajou : /* Choix d'implémentation */

Fichier:Bean produit.png

2014-02-26T12:38:58Z

Jkemajou :

Fichier:Bean panier.png

2014-02-26T12:38:40Z

Jkemajou :

Fichier:Bean client.png

2014-02-26T12:38:24Z

Jkemajou :

Encaissement RFID

2014-02-26T12:24:54Z

Jkemajou : /* Semaine 10 à 14 */

Encaissement RFID

2014-02-26T12:24:38Z

Jkemajou : /* Semaine 10 à 14 */

Encaissement RFID

2014-02-26T12:24:10Z

Jkemajou : /* Semaine 10 à 14 */

Encaissement RFID

2014-02-26T12:22:38Z

Jkemajou : /* Semaine 10 à 14 */

Encaissement RFID

2014-02-26T12:22:19Z

Jkemajou : /* Semaine 10 à 14 */

Encaissement RFID

2014-02-26T12:20:54Z

Jkemajou :

Fichier:Diag class.png

2014-02-26T12:16:46Z

Jkemajou :

Fichier:Mcv diag.png

2014-02-26T12:05:02Z

Jkemajou :

Encaissement RFID

2014-02-26T11:38:39Z

Jkemajou : /* Semaine 10 à 14 */

Fichier:Arch Fonc1.png

2014-02-26T11:35:19Z

Jkemajou :

Encaissement RFID

2014-02-26T11:06:59Z

Jkemajou : /* Semaine 10 à 14 */

Fichier:Diag dep.png

2014-02-26T11:04:24Z

Jkemajou : Diagramme de déploiement

Diagramme de déploiement

Encaissement RFID

2013-12-16T02:15:38Z

Jkemajou : /* Semaine 4 à Semaine 7 */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|600px]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

[[Fichier:Arch_Fonc.png|Architecture Fonctionnelle]]

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

Encaissement RFID

2013-12-16T02:13:02Z

Jkemajou : /* Semaine 4 à Semaine 7 */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

[[Fichier:Arch_Fonc.png|Architecture Fonctionnelle]]

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

Encaissement RFID

2013-12-16T02:11:51Z

Jkemajou : /* Semaine 10 à 14 */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|500px|Cablage Arduino+GPS]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

[[Fichier:Arch_Fonc.png|Architecture Fonctionnelle]]

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

Fichier:Arch Fonc.png

2013-12-16T02:09:55Z

Jkemajou :

Encaissement RFID

2013-12-16T02:09:07Z

Jkemajou : /* Semaine 10 (Quatrième Réunion) */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|500px|Cablage Arduino+GPS]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

== Semaine 10 à 14 ==

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE.
L’architecture technique sera réalisé très bientôt.

Fichier:Spec Fonc.pdf

2013-12-16T02:04:23Z

Jkemajou :

Encaissement RFID

2013-12-16T02:01:29Z

Jkemajou : /* Semaine 9 */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|500px|Cablage Arduino+GPS]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): [[Fichier: Spec_Fonc.pdf‎]]

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

Encaissement RFID

2013-12-16T01:56:45Z

Jkemajou : /* Semaine 8 (Troisième réunion) */

=''Présentation du projet''=
----
== Objectif ==

En collaboration avec Oxylane, le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits oxylane seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite par Oxylane concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution:
http://www.youtube.com/watch?v=eob532iEpqk

== Matériel requis ==

*Un portique
*Une tablette

=''Gestion du projet''=
----

== Semaine 1 ==

Cette semaine a été consacré au choix des projets

== Semaine 2 ==

Prise de contact avec notre tuteur Oxylane, planification d'une réunion et début de réflexion sur le sujet

== Semaine 3 (Première Réunion) ==

Première réunion (Mercredi 25/09/2013) avec notre tuteur Oxylane. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

== Semaine 3 (Deuxième Réunion) ==

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur Oxylane et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution.
En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

== Semaine 4 à Semaine 7 ==

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile.
Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur Oxylane afin de proposer la solution et la faire valider.

[[Fichier:UCDsystem.png|500px|Cablage Arduino+GPS]]

== Semaine 8 (Troisième Réunion) ==

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications.
A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez oxylane qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

== Semaine 9 ==

Préparation de la prochaine réunion avec Mr BRUNO HOUTTEMANE, Réalisation du powerpoint de présentation de notre scénario.

== Semaine 10 (Quatrième Réunion) ==

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur Oxylane. Le but de cette réunion était de présenter notre scénario, à Mr BRUNO HOUTTEMANE, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Mr HOUTTEMANE nous a donc proposer de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur pour les équipes d'Oxylane.

Une prochaine réunion a été envisagé afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel Protocol pourrait être utilisé pour communiquer entre le portique et le serveur web.

Encaissement RFID

2013-12-16T01:20:23Z

Jkemajou : /* Semaine 4 à Semaine 7 */

Encaissement RFID

2013-12-16T01:17:52Z

Jkemajou : /* Semaine 4 à Semaine 7 */

Fichier:UCDsystem.png

2013-12-16T01:15:53Z

Jkemajou :

Fichier:UCD system-RIFD.png

2013-12-16T01:12:11Z

Jkemajou :

Encaissement RFID

2013-12-16T01:07:24Z

Jkemajou : /* Semaine 4 à Semaine 7 */

Encaissement RFID

2013-12-16T01:05:01Z

Jkemajou : /* Gestion du projet */

Encaissement RFID

2013-12-15T23:05:30Z

Jkemajou : /* Objectif */

Encaissement RFID

2013-12-15T22:58:07Z

Jkemajou : /* matériel requis */

Encaissement RFID

2013-12-15T22:57:27Z

Jkemajou : /* matériel requis */

Encaissement RFID

2013-12-15T22:56:35Z

Jkemajou : /* matériel requis */

Encaissement RFID

2013-12-15T22:51:04Z

Jkemajou : /* Présentation */

Traceur de choc

2013-05-14T20:15:14Z

Jkemajou : /* Dernière Semaine: Semaine du 06/05/2013 */

=''Présentation du projet''=
----

Le but de ce projet est de réaliser une carte permettant de mesure l'accélération,intégrant un GPS et transmettant les données à '''une montre communicante TI'''. D'une manière plus explicite, cette carte devrait nous permettre dans un premier temps de tracer par exemple la position d'un colis. Grace au '''GPS''' nous devrions être capable de donner la position du colis à tout moment ('''Géolocalisation''') mais par contre en cas de perte du signal, nous devrions passer par l’accéléromètre pour estimer à nouveau la position du colis. Dans un second temps, nous devrons enregistrer dans une '''carte SD''' les différentes valeurs des accélérations afin de savoir ou d'estimer si il y a eu un choc ou pas(par exemple).Enfin, nous devrons être capable de transmettre en temps réel ces données à la fin à une montre TI via '''Liaison radio'''.

=''Matériel Requis''=
----

*Un Arduino UNO
*Un Module GPS(NMEA GPS)
*Un Accéléromètre(ADXL3xx)
*Un afficheur LCD(Shield LCD couleur)
*Une Carte SD

=''1ère séance: 04/02/2013''=
----

Cette première séance a été mise à profit afin de mieux cerner le projet:

*Contact des encadrants du projet.

*Présentation du projet par M. Alexandre Boé.

*Discussion autour des différentes parties du projet.

=''2ème séance: 07/02/2013''=
----

Dans cette deuxième séance, nous avons pris la peine de bien défini et hiérarchisé notre projet pour pouvoir bien déléguer les rôles pour chaque étape. Nous avons donc vu que le projet était constitué de 2 parties essentielles(La partie arduino et la partie réalisation de la carte) et qu'il était pas judicieux d'évoluer tout les 2 sur une même partie.

Nous nous sommes donc répartis les tâches: Une personne qui travaillera sur la '''partie Arduino''' et une autre qui travaillera sur la '''partie carte électronique'''.

Ensuite nous avons pris connaissance des outils avec lesquelles nous devions travailler. Pour la partie carte, nous avons décidé d'utiliser le logiciel Eagle pour la réalisation de notre Schematic et notre PCB car nous avons remarqué que pour chaque Shield arduino nous pouvions facilement avoir le schematic Eagle correspondant.

=''3ème séance: 11/02/2013''=
----

====Partie Carte====

Prise en main du logiciel Eagle et auto-formation à l'aide d'un tutoriel car c'était un logiciel qu'on ne connaissait pas du tout.

====Partie Arduino====

Au cours de la 3e séance nous nous sommes intéressé au '''module GPS''', que nous avons eu un peu de mal a faire marcher.

'''schema de connection:'''

[[Fichier:GPS1.png|200px|Cablage Arduino+GPS]] [[Fichier:Gps.jpg|200px|aduino+GPS]]

Le schéma de montage ci-dessus vous présente comment nous avons connecté notre GPS à l'arduino. Maintenant concernant la partie logicielle pour que le GPS communique avec le GPS, nous avons utilisé la bibliothèque '''tinygps'''. A partir d'un code exemple nous avons donc programmer notre GPS mais a la fin de cette séance nous n'avons pas pu obtenir de résultat.

=''4ème séance: 14/02/2013''=
----

====Partie Carte====

Le but de la réalisation de la carte étant de rendre plus petit et plus compact notre système réalisé sur arduino, il était donc question de réfléchir sur les différents composants que nous devions utilisés sur notre carte électronique. Donc durant cette séance, nous avons télécharger dans un premier temps le schématic eagle de notre arduino Uno et nous avons essayé de réfléchir sur ce qu'il y avait a viré ou a gardé pour notre projet.

====Partie Arduino====

N’ayant pas obtenu les résultats voulu a la seance précédente, nous avons cherché a bien comprendre comment se faisait la communication entre l'arduino et le GPS. Nous avons donc compris que le GPS utilisait bien le protocole RX/TX mais les broches de communication dépendaient de la position de l'interrupteur '''UART/DTLINE''' sur le Shield GPS comme le montre le schéma ci-dessous (Option 2):

[[Fichier:Shield.png|200px|thumb|Option Shield GPS]]

L'option 2 est l'interrupteur de sélection de l'UART: Si l'UART est sélectionné, le GPS communiquera avec l'arduino directement avec les broches 0 et 1 . si '''DTLINE''' est sélectionné, le GPS sera connecté par défaut aux broches 2 et 3. '''DLINE''' doit donc être d'abord sélectionné pour téléverser le programme dans l'arduino car le mode '''UART''' utilise les même broches utilisées pour programmer l'arduino. si le mode UART est sélectionné et que par la suite nous téléversons le code, nous aurons des erreurs dans l'IDE de l'arduino qui signalera un '''Conflit de bus'''.

Pour éviter à chaque fois d’être confronté ace problème, nous étions un peu obligé de trouver comment émuler d'autres ports séries pour la communication entre le GPS et l'Arduino comme çà les broches 0 et 1 seront utilisées seulement pour la communication entre le PC et l'Arduino. Nous avons donc vu que la bibliotheque '''SoftwareSerial''' permettait de le faire. Donc finnallement à la fin de cette séance , nous avons pu faire fonctionner le GPS.

====NB:====
Le GPS à besoin de quelques minutes pour pouvoir détecter un satellite et ensuite nous donner des valeurs. Donc faut être très patient.

=''5ème et 6ème séance: Semaine du 25/02/2013''=
----

====Partie Carte====

nous avons jugé judicieux de concevoir notre traceur de choc sous forme de plusieurs cartes (couches) superposées,chaque couche comportant un seul module :
(1) microprocesseur
(2) module GPS
(3) accéléromètre
(4) micro SD
la pièce principale de notre prototype étant le microprocesseur, nous avons décidé de concevoir entièrement la couche "microprocesseur" avant de débuter la conception des autres couches.
Sachant bien dans entendu que lors de la conception de cette dernière nous devrons prévoir assez de broches entrées-sorties pour communiquer avec les modules d’étages supérieurs et le circuit d'alimentation.
voici le schematic de la couche "microprocesseur"
[[Fichier:circuit.jpg|500px|center|Option Shield GPS]]

====Partie Arduino====

Lors de cette séance, nous avons pu faire fonctionner l'accéléromètre(ADXL345). tout d'abord, nous avons cherché le protocole utilisé par ce dernier et nous avons vu qu'il pouvait utiliser soit le protocole '''I2C''' soit le protocole '''SPI'''. Pour ce projet, nous avons décidé d'utiliser le protocole '''I2C''' qui nécessite d'inclure la bibliothèque '''Wire.h''' dans le code. Le schéma de câblage est le suivant:
[[Fichier:Acc1.jpg|250px|thumb|Option Shield GPS]]

comme on peut le voir ci-contre le brochage est le suivant:
*CS ->3V3
*SDO -> GND
*SDA ->A4
*SCL -> A5
*VCC ->3V3
*GND -> GND

A la fin de cette séance nous avons donc pu recueillir les valeurs des accélérations sur les axes x,y et z.

=''7ème et 8ème séance: Semaine du 04/03/2013''=

====Partie Arduino====

Au cours de cette séance, nous nous sommes concentré sur l'écran LCD (Shield LCD) et sur la carte SD. Comme nous avons fait avec les autres shields, nous avons tout d'abord cherché le protocole de communication utilisé par chaque module.

==>Pour l'Ecran LCD nous avons vu qu'il utilisait le protocole '''SPI''' le schema de cablage est le suivant:
'''[[Fichier:LED.jpg|150px|thumb|shield lcd+arduino]]

les broches de communication pour ce mode sont:
*Reset (RES)-->8
*Chip-select-->9
*Data in/out (DIO)-->11
*Serial Clock (SCK)-->13

==> Pour la carte SD, nous avons donc vu que la carte SD utilisait le protocole '''SPI''' pour communiquer avec l'arduino et les broches utilisées sont :
*Reset (RES)-->12
*Chip-select-->4
*Data in/out (DIO)-->11
*Serial Clock (SCK)-->13

=''8ème et 11ème séance: Semaine du 11/03/2013''=

Au cours de cette séance, ayant déjà vu que tous les modules arduino marchaient indépendamment, nous avons voulu les mettre ensemble. Nous avons donc commencé par mettre ensemble le GPS et l’Accéléromètre (GPS+ Accéléromètre).
Nous avons fait notre programme arduino que nous avons par la suite envoyé dans l'arduino! mais malheureusement rien ne marchait!! A la fin de la semaine, nous n'avons donc pas pu avoir les résultats que nous étions censés obtenir.

=''12ème et 13ème séance: Semaine du 18/03/2013''=

Au début de cette semaine, nous nous sommes fixés comme objectifs de résoudre le problème que nous avions la dernière fois et pour cela, nous avons décidé de tester différentes combinaisons entre modules (différents ensembles) pour voir d'où provenait le problème. Nous avons donc décider d'essayer l'ensemble '''GPS + Ecran LCD'''. Au terme de le 1ère séance de cette semaine, nous avons pu faire fonctionner le GPS et l'Ecran ensemble. nous avons pu afficher sur l'écran LCD les informations provenant du GPS (latitude, longitude, heure, date).Donc une chose est sure c'est que notre GPS et notre écran sont bien compatibles.
A la prochaine séance, nous avons décider d'essayer cette fois ci l'ensemble: ["Ecran LCD + Accéléromètre" ]. Le but était d'afficher les valeurs des accélérations x,y et z sur l'écran LCD mais à la fin de la séance, nous n'avons pas réussi à afficher ces valeurs. A chaque fois nous avions un écran noir!! ce qui nous semblait bizarre car chaque module fonctionnait indépendamment.
Finalement a la fin de cette séance, nous n'avions pas toujours su la source du problème et nous étions toujours bloqué au même niveau.

=''14ème et 15ème séance: Semaine du 25/03/2013''=

L'objectif de cette semaine était de résoudre a tout pris notre problème. A travers les différentes combinaisons entre modules que nous effectués la semaine dernière, nous supposions que le problème venait de l'accéléromètre car à chaque fois qu'on l'associe à un autre module, le programme ne fonctionne plus!
A l'aide de l'explication de nos tuteurs, et grâce à nos camarades ayant obtenus le même problème que nous et aux recherches sur internet, nous avons donc finalement pu identifier le problème. Le problème était en fait une '''incompatibilité de bibliothèque''' entre '''Wire.h''' et '''Softwareserial'''.

=''16ème et 17éme séance: Semaine du 01/04/2013''=

Au cours de cette semaine, nous avons réfléchi au moyen de pouvoir contourner cet incompatibilité de bibliothèque. Nous avons donc décider de ne plus utiliser la bibliothèque SoftwareSerial. Mais le fait de ne plus l'utiliser nous handicapait beaucoup. On ne pouvait plus utiliser le '''Moniteur série''' du pc en même temps que le GPS, car comme nous vous l'avions expliqué plus haut, ces derniers utilisent les même broches pour communiquer à savoir les broches '''RX''' et '''TX'''(0 et 1). A la fin de la séance, nous avons donc pu afficher cette fois ci les données fournies par le GPS(latitude, longitude, date, heure) sur l'écran LCD sans problème.
Dans un second temps, nous avons donc essayer de faire communiquer 3 modules en même temps à savoir '''LED + GPS + Accéléromètre'''. Cette fois ci, nous n'avons eu aucun problème. Nous avons bien réussi à afficher les valeurs des accélérations et les données du GPS sur la l'écran LCD.

=''18ème et 19éme séance: Semaine du 08/04/2013''=

Au cours de cette semaine, il était question d'utiliser la carte SD pour essayer d'enregistrer les valeurs des accélérations et les données à l'intérieur. Mais cet fois çi, on a été a nouveau confronté à un nouveau problème, celui du dépassement de la mémoire RAM.
A l'aide de la commande '''avr-size''' nous avons bien vérifié que le problème que nous avions provenait bel et bien d'un dépassement de la mémoire de l'arduino UNO (32kb).
Nous avons compris que, vu que nous utilisons plusieurs modules simultanément, nous sommes obligé d'inclure plusieurs librairies pour les faire fonctionner or celles ci, misent ensemble, font rapidement exploser la taille du programme. Aussi, lorsque nous faisons un programme utilisant des chaines de caractère à stocker comme c'est le cas dans ce projet, la taille du programme peut facilement augmenter. Il était donc question de trouver une solution à ce problème.

=''Travaux Supplémentaires: Vacances de printemps''=

Durant ces vacances nous avons trouvé une solution pour résoudre notre problème de dépassement de mémoire et notre problème d'incompatibilité en les bibliothèques Softwareserial et Wire.h. Nous avons donc décidé de récupérer au retour des vacances un '''arduino ATMEGA2560''' car nous avons qu'il y avait '''256kb''' de RAM dessus et que nous pourrions émuler plusieurs ports séries dessus car il dispose de plusieurs broches RX et TX.
Nous avons durant ces vacances, pris le temps de calibrer notre accéléromètre pour savoir quand il y aura choc ou pas.

=''20ème et 21éme séance: Semaine du 29/04/2013''=

Au cours de cette séance, nous avons donc récupérer notre arduino ATMEGA et nous avons modifier notre programme de tel sorte que chaque module puisse fonctionner indépendamment sur un '''ATMEGA2560''' car les broches de communication avaient changé.

Ensuite une fois que nous avons vérifier que chaque module fonctionnait indépendamment, nous avons réaliser l'ensemble complet final, c'est à dire ''' GPS + ECRAN LCD + ACCÉLÉROMÈTRE + CARTE MICROSD''' et nous avons vérifié que le comportement attendu était bien ce que nous voulions.

=''Dernière Semaine: Semaine du 06/05/2013''=

Nous avons réalisé la vidéo de notre projet en expliquant son fonctionnement.

Version Finale Rapport: [[media:Rapport_Projet_2013_V5.pdf‎]]

Code Arduino: [[media:Traceur.zip]]

Traceur de choc

2013-05-14T20:14:10Z

Jkemajou : /* Dernière Semaine: Semaine du 06/05/2013 */

Fichier:Rapport Projet 2013 V5.pdf

2013-05-14T20:13:37Z

Jkemajou :

Traceur de choc

2013-05-12T23:11:35Z

Jkemajou : /* Dernière Semaine: Semaine du 06/05/2013 */

=''Présentation du projet''=
----

Le but de ce projet est de réaliser une carte permettant de mesure l'accélération,intégrant un GPS et transmettant les données à '''une montre communicante TI'''. D'une manière plus explicite, cette carte devrait nous permettre dans un premier temps de tracer par exemple la position d'un colis. Grace au '''GPS''' nous devrions être capable de donner la position du colis à tout moment ('''Géolocalisation''') mais par contre en cas de perte du signal, nous devrions passer par l’accéléromètre pour estimer à nouveau la position du colis. Dans un second temps, nous devrons enregistrer dans une '''carte SD''' les différentes valeurs des accélérations afin de savoir ou d'estimer si il y a eu un choc ou pas(par exemple).Enfin, nous devrons être capable de transmettre en temps réel ces données à la fin à une montre TI via '''Liaison radio'''.

=''Matériel Requis''=
----

*Un Arduino UNO
*Un Module GPS(NMEA GPS)
*Un Accéléromètre(ADXL3xx)
*Un afficheur LCD(Shield LCD couleur)
*Une Carte SD

=''1ère séance: 04/02/2013''=
----

Cette première séance a été mise à profit afin de mieux cerner le projet:

*Contact des encadrants du projet.

*Présentation du projet par M. Alexandre Boé.

*Discussion autour des différentes parties du projet.

=''2ème séance: 07/02/2013''=
----

Dans cette deuxième séance, nous avons pris la peine de bien défini et hiérarchisé notre projet pour pouvoir bien déléguer les rôles pour chaque étape. Nous avons donc vu que le projet était constitué de 2 parties essentielles(La partie arduino et la partie réalisation de la carte) et qu'il était pas judicieux d'évoluer tout les 2 sur une même partie.

Nous nous sommes donc répartis les tâches: Une personne qui travaillera sur la '''partie Arduino''' et une autre qui travaillera sur la '''partie carte électronique'''.

Ensuite nous avons pris connaissance des outils avec lesquelles nous devions travailler. Pour la partie carte, nous avons décidé d'utiliser le logiciel Eagle pour la réalisation de notre Schematic et notre PCB car nous avons remarqué que pour chaque Shield arduino nous pouvions facilement avoir le schematic Eagle correspondant.

=''3ème séance: 11/02/2013''=
----

====Partie Carte====

Prise en main du logiciel Eagle et auto-formation à l'aide d'un tutoriel car c'était un logiciel qu'on ne connaissait pas du tout.

====Partie Arduino====

Au cours de la 3e séance nous nous sommes intéressé au '''module GPS''', que nous avons eu un peu de mal a faire marcher.

'''schema de connection:'''

[[Fichier:GPS1.png|200px|Cablage Arduino+GPS]] [[Fichier:Gps.jpg|200px|aduino+GPS]]

Le schéma de montage ci-dessus vous présente comment nous avons connecté notre GPS à l'arduino. Maintenant concernant la partie logicielle pour que le GPS communique avec le GPS, nous avons utilisé la bibliothèque '''tinygps'''. A partir d'un code exemple nous avons donc programmer notre GPS mais a la fin de cette séance nous n'avons pas pu obtenir de résultat.

=''4ème séance: 14/02/2013''=
----

====Partie Carte====

Le but de la réalisation de la carte étant de rendre plus petit et plus compact notre système réalisé sur arduino, il était donc question de réfléchir sur les différents composants que nous devions utilisés sur notre carte électronique. Donc durant cette séance, nous avons télécharger dans un premier temps le schématic eagle de notre arduino Uno et nous avons essayé de réfléchir sur ce qu'il y avait a viré ou a gardé pour notre projet.

====Partie Arduino====

N’ayant pas obtenu les résultats voulu a la seance précédente, nous avons cherché a bien comprendre comment se faisait la communication entre l'arduino et le GPS. Nous avons donc compris que le GPS utilisait bien le protocole RX/TX mais les broches de communication dépendaient de la position de l'interrupteur '''UART/DTLINE''' sur le Shield GPS comme le montre le schéma ci-dessous (Option 2):

[[Fichier:Shield.png|200px|thumb|Option Shield GPS]]

L'option 2 est l'interrupteur de sélection de l'UART: Si l'UART est sélectionné, le GPS communiquera avec l'arduino directement avec les broches 0 et 1 . si '''DTLINE''' est sélectionné, le GPS sera connecté par défaut aux broches 2 et 3. '''DLINE''' doit donc être d'abord sélectionné pour téléverser le programme dans l'arduino car le mode '''UART''' utilise les même broches utilisées pour programmer l'arduino. si le mode UART est sélectionné et que par la suite nous téléversons le code, nous aurons des erreurs dans l'IDE de l'arduino qui signalera un '''Conflit de bus'''.

Pour éviter à chaque fois d’être confronté ace problème, nous étions un peu obligé de trouver comment émuler d'autres ports séries pour la communication entre le GPS et l'Arduino comme çà les broches 0 et 1 seront utilisées seulement pour la communication entre le PC et l'Arduino. Nous avons donc vu que la bibliotheque '''SoftwareSerial''' permettait de le faire. Donc finnallement à la fin de cette séance , nous avons pu faire fonctionner le GPS.

====NB:====
Le GPS à besoin de quelques minutes pour pouvoir détecter un satellite et ensuite nous donner des valeurs. Donc faut être très patient.

=''5ème et 6ème séance: Semaine du 25/02/2013''=
----

====Partie Carte====

nous avons jugé judicieux de concevoir notre traceur de choc sous forme de plusieurs cartes (couches) superposées,chaque couche comportant un seul module :
(1) microprocesseur
(2) module GPS
(3) accéléromètre
(4) micro SD
la pièce principale de notre prototype étant le microprocesseur, nous avons décidé de concevoir entièrement la couche "microprocesseur" avant de débuter la conception des autres couches.
Sachant bien dans entendu que lors de la conception de cette dernière nous devrons prévoir assez de broches entrées-sorties pour communiquer avec les modules d’étages supérieurs et le circuit d'alimentation.
voici le schematic de la couche "microprocesseur"
[[Fichier:circuit.jpg|500px|center|Option Shield GPS]]

====Partie Arduino====

Lors de cette séance, nous avons pu faire fonctionner l'accéléromètre(ADXL345). tout d'abord, nous avons cherché le protocole utilisé par ce dernier et nous avons vu qu'il pouvait utiliser soit le protocole '''I2C''' soit le protocole '''SPI'''. Pour ce projet, nous avons décidé d'utiliser le protocole '''I2C''' qui nécessite d'inclure la bibliothèque '''Wire.h''' dans le code. Le schéma de câblage est le suivant:
[[Fichier:Acc1.jpg|250px|thumb|Option Shield GPS]]

comme on peut le voir ci-contre le brochage est le suivant:
*CS ->3V3
*SDO -> GND
*SDA ->A4
*SCL -> A5
*VCC ->3V3
*GND -> GND

A la fin de cette séance nous avons donc pu recueillir les valeurs des accélérations sur les axes x,y et z.

=''7ème et 8ème séance: Semaine du 04/03/2013''=

====Partie Arduino====

Au cours de cette séance, nous nous sommes concentré sur l'écran LCD (Shield LCD) et sur la carte SD. Comme nous avons fait avec les autres shields, nous avons tout d'abord cherché le protocole de communication utilisé par chaque module.

==>Pour l'Ecran LCD nous avons vu qu'il utilisait le protocole '''SPI''' le schema de cablage est le suivant:
'''[[Fichier:LED.jpg|150px|thumb|shield lcd+arduino]]

les broches de communication pour ce mode sont:
*Reset (RES)-->8
*Chip-select-->9
*Data in/out (DIO)-->11
*Serial Clock (SCK)-->13

==> Pour la carte SD, nous avons donc vu que la carte SD utilisait le protocole '''SPI''' pour communiquer avec l'arduino et les broches utilisées sont :
*Reset (RES)-->12
*Chip-select-->4
*Data in/out (DIO)-->11
*Serial Clock (SCK)-->13

=''8ème et 11ème séance: Semaine du 11/03/2013''=

Au cours de cette séance, ayant déjà vu que tous les modules arduino marchaient indépendamment, nous avons voulu les mettre ensemble. Nous avons donc commencé par mettre ensemble le GPS et l’Accéléromètre (GPS+ Accéléromètre).
Nous avons fait notre programme arduino que nous avons par la suite envoyé dans l'arduino! mais malheureusement rien ne marchait!! A la fin de la semaine, nous n'avons donc pas pu avoir les résultats que nous étions censés obtenir.

=''12ème et 13ème séance: Semaine du 18/03/2013''=

Au début de cette semaine, nous nous sommes fixés comme objectifs de résoudre le problème que nous avions la dernière fois et pour cela, nous avons décidé de tester différentes combinaisons entre modules (différents ensembles) pour voir d'où provenait le problème. Nous avons donc décider d'essayer l'ensemble '''GPS + Ecran LCD'''. Au terme de le 1ère séance de cette semaine, nous avons pu faire fonctionner le GPS et l'Ecran ensemble. nous avons pu afficher sur l'écran LCD les informations provenant du GPS (latitude, longitude, heure, date).Donc une chose est sure c'est que notre GPS et notre écran sont bien compatibles.
A la prochaine séance, nous avons décider d'essayer cette fois ci l'ensemble: ["Ecran LCD + Accéléromètre" ]. Le but était d'afficher les valeurs des accélérations x,y et z sur l'écran LCD mais à la fin de la séance, nous n'avons pas réussi à afficher ces valeurs. A chaque fois nous avions un écran noir!! ce qui nous semblait bizarre car chaque module fonctionnait indépendamment.
Finalement a la fin de cette séance, nous n'avions pas toujours su la source du problème et nous étions toujours bloqué au même niveau.

=''14ème et 15ème séance: Semaine du 25/03/2013''=

L'objectif de cette semaine était de résoudre a tout pris notre problème. A travers les différentes combinaisons entre modules que nous effectués la semaine dernière, nous supposions que le problème venait de l'accéléromètre car à chaque fois qu'on l'associe à un autre module, le programme ne fonctionne plus!
A l'aide de l'explication de nos tuteurs, et grâce à nos camarades ayant obtenus le même problème que nous et aux recherches sur internet, nous avons donc finalement pu identifier le problème. Le problème était en fait une '''incompatibilité de bibliothèque''' entre '''Wire.h''' et '''Softwareserial'''.

=''16ème et 17éme séance: Semaine du 01/04/2013''=

Au cours de cette semaine, nous avons réfléchi au moyen de pouvoir contourner cet incompatibilité de bibliothèque. Nous avons donc décider de ne plus utiliser la bibliothèque SoftwareSerial. Mais le fait de ne plus l'utiliser nous handicapait beaucoup. On ne pouvait plus utiliser le '''Moniteur série''' du pc en même temps que le GPS, car comme nous vous l'avions expliqué plus haut, ces derniers utilisent les même broches pour communiquer à savoir les broches '''RX''' et '''TX'''(0 et 1). A la fin de la séance, nous avons donc pu afficher cette fois ci les données fournies par le GPS(latitude, longitude, date, heure) sur l'écran LCD sans problème.
Dans un second temps, nous avons donc essayer de faire communiquer 3 modules en même temps à savoir '''LED + GPS + Accéléromètre'''. Cette fois ci, nous n'avons eu aucun problème. Nous avons bien réussi à afficher les valeurs des accélérations et les données du GPS sur la l'écran LCD.

=''18ème et 19éme séance: Semaine du 08/04/2013''=

Au cours de cette semaine, il était question d'utiliser la carte SD pour essayer d'enregistrer les valeurs des accélérations et les données à l'intérieur. Mais cet fois çi, on a été a nouveau confronté à un nouveau problème, celui du dépassement de la mémoire RAM.
A l'aide de la commande '''avr-size''' nous avons bien vérifié que le problème que nous avions provenait bel et bien d'un dépassement de la mémoire de l'arduino UNO (32kb).
Nous avons compris que, vu que nous utilisons plusieurs modules simultanément, nous sommes obligé d'inclure plusieurs librairies pour les faire fonctionner or celles ci, misent ensemble, font rapidement exploser la taille du programme. Aussi, lorsque nous faisons un programme utilisant des chaines de caractère à stocker comme c'est le cas dans ce projet, la taille du programme peut facilement augmenter. Il était donc question de trouver une solution à ce problème.

=''Travaux Supplémentaires: Vacances de printemps''=

Durant ces vacances nous avons trouvé une solution pour résoudre notre problème de dépassement de mémoire et notre problème d'incompatibilité en les bibliothèques Softwareserial et Wire.h. Nous avons donc décidé de récupérer au retour des vacances un '''arduino ATMEGA2560''' car nous avons qu'il y avait '''256kb''' de RAM dessus et que nous pourrions émuler plusieurs ports séries dessus car il dispose de plusieurs broches RX et TX.
Nous avons durant ces vacances, pris le temps de calibrer notre accéléromètre pour savoir quand il y aura choc ou pas.

=''20ème et 21éme séance: Semaine du 29/04/2013''=

Au cours de cette séance, nous avons donc récupérer notre arduino ATMEGA et nous avons modifier notre programme de tel sorte que chaque module puisse fonctionner indépendamment sur un '''ATMEGA2560''' car les broches de communication avaient changé.

Ensuite une fois que nous avons vérifier que chaque module fonctionnait indépendamment, nous avons réaliser l'ensemble complet final, c'est à dire ''' GPS + ECRAN LCD + ACCÉLÉROMÈTRE + CARTE MICROSD''' et nous avons vérifié que le comportement attendu était bien ce que nous voulions.

=''Dernière Semaine: Semaine du 06/05/2013''=

Nous avons réalisé la vidéo de notre projet en expliquant son fonctionnement.

Version Partielle Rapport:
[[media:Rapport_Projet_2013.pdf]]

Version Finale Rapport: [Coming Soon]

Code Arduino: [[media:Traceur.zip]]

Fichier:Traceur.zip

2013-05-12T23:11:17Z

Jkemajou :