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

P59 Assistance globale pour aide au parking

2015-02-24T09:03:36Z

Cly : /* Matériel et outils nécessaires */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel et outils nécessaires==

===Matériel nécessaire===

Utilisation de plusieurs cartes CC430 réalisées par Monsieur BOÉ et Monsieur VANTROYS. Il s’agit de cartes électroniques comprenant un module RF (Radio Frequency) permettant d’envoyer et de recevoir des informations en communication sans fil à une certaine fréquence. Un capteur est connecté à ce dernier.

L’utilisation de ces cartes n’était pas la plus adaptée pour le projet mais il était intéressant de les utiliser afin de concevoir un prototype. En effet, elle est plus performante que ce dont nous avions réellement besoin (mémoire, puissance de calcul, etc.).
Par ailleurs, afin d'assurer une bonne communication sans fil, nous avons décidé d'utiliser la bande de fréquence 868 MHz. Grâce à cette fréquence, la communication peut être réalisée à une plus grande distance par rapport à une fréquence de 2,4 GHz et ce, pour une même taille d’antenne.

Nous avons également besoin du MSP430 LaunchPad. Il permet de flasher les cartes.
Pour notre prototype, nous avons utilisé un interrupteur pour chaque carte où il y a besoin d’un capteur. L’interrupteur permet de remplacer le capteur. On va pouvoir simuler un obstacle en changeant de valeur l’interrupteur.

===Outils nécessaires===
Utilisation d’un serveur web a été fait. Il s’agit d’un serveur informatique utilisé pour publier des sites web sur Internet.

Afin de réaliser une page web, nous avons besoin de certains outils comme les langages HTML et CSS. Ces derniers sont des langages de balisage permettant de structurer une page web. PHP est un langage de programmation utilisé pour le développement de pages web ; c’est celui qui est le plus utilisé dans ce domaine. Il est gratuit et ne nécessite aucune licence d’utilisation. Il existe un nombre incommensurable de bibliothèques et de tutoriels.

Pour que l’application fonctionne correctement, le site web doit stocker les informations relatives aux parkings renseignés. Pour cela nous utilisons une base de données. Il s’agit d’un outil capable de stocker et de récupérer des informations comme défini précédemment. Nous utiliserons le langage MySQL qui est un langage de programmation permettant la gestion de base de données (ajout, mise à jour ou suppression d’informations). Ce langage présente quelques avantages : il est gratuit et présente beaucoup de fonctionnalités. Il est également très répandu et il est très facile de rechercher des informations en cas de problème.

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Gérer la partie Administrative (mot de passe oublié, envoi de mail, désinscription, etc.) PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine sera de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

===Semaine 19===

'''Partie applicative (PA)'''

* Gestion de mise à jour des données sans l'intervention humaine.
* Intégration de la carte à l'application.
** Gestion de la géolocalisation
** Gestion d'un itinéraire pour arriver à la destination souhaitée
** Ajout de l'auto-complétion pour renseigner les lieux de manière aisée
** Affichage des parkings par ville (afin d'éviter de trop lourds calculs pour référencer tous les parkings sur la carte)
** Mise à jour des données dans les infos bulles gérée

Voici la représentation de la page avec la carte et ses fonctionnalités :
[[Fichier:RepresentationFonctionnalitesCarte.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Gérer la création de parking (interface), modifier la bdd et créer un programme en langage C permettant de récupérer les informations envoyées par liaison série (de la carte "concentrateur général" vers un ordinateur) et les envoyer sur le serveur. Une page php sera créée afin de mettre à jour la base de données. PRC : Réaliser la communication série permettant le lien entre les deux parties.

===Semaine 20===

Rédaction du rapport.
Préparation de la vidéo à tourner la semaine suivante.

'''Partie applicative (PA)'''

* La base de données a été modifiée, elle se présente sous cette forme :
[[Fichier:BDD finale.png|upright=3|vignette|center]] 
* L'interface pour créer une visualisation de parking a été réalisé (cf. figure ci-dessous), grâce à cette interface :
** Le configurateur peut utiliser un plan déjà construit
** Il peut également modifier le type de chaque case (route, place, autre)en double cliquant
** Lorsqu'il crée une place, il peut renseigner des paramètres comme l'id de capateur associé à la place ou sa pmorphologie
** Il peut visualiser la configuration en cliquant une seule fois
** Les informations sont transmises à la BDD pour sauvegarder les résultats
[[Fichier:Mode Configurateur.png|upright=3|vignette|center]] 

* L'interface du côté utilisateur a été également développée :
** Lorsque l'utilisateur choisit un parking, l'interface s'affiche
** Elle se met à jour régulièrement
** L’utilisateur peut voir les caractéristiques de chaque place de parking
[[Fichier:Application Avec interface utilisateur.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Amélioration de la communication RF, notamment au niveau de la gestion des accusés de réception.
* Réalisation de l'émission entre une carte et un PC permettant la mise à jour de transmettre les informations au système embarqué. Les données alors transmises sont: l'identifiant du parking, l'identifiant du capteur et l'état du capteur.

'''Partie Système embarqué (permettant de faire communiquer le PRC et PA)'''

* Réalisation de la réception série pour récupérer les informations du réseau de capteurs.
* Réalisation de la requête http de type post en utilisant une socket avec système SSL pour pouvoir envoyer des informations de manière sécurisée sur le serveur web.

'''Objectifs de la semaine suivante: Finition de la rédaction du rapport, réalisation de la vidéo, préparation du support de soutenance et la préparer.'''

===Semaine 21===

* Mise en commun des deux parties, avec la partie Système Embarqué. Association de la réception série avec l'envoi d'informations sur le serveur web.
* Réalisation de la vidéo le lundi matin à 10h.
* Rédaction du rapport.
* Préparation de la soutenance.

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-24T09:02:33Z

Cly : /* Semaine 21 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel et outils nécessaires==

a. Matériel nécessaire

Utilisation de plusieurs cartes CC430 réalisées par Monsieur BOÉ et Monsieur VANTROYS. Il s’agit de cartes électroniques comprenant un module RF (Radio Frequency) permettant d’envoyer et de recevoir des informations en communication sans fil à une certaine fréquence. Un capteur est connecté à ce dernier.

L’utilisation de ces cartes n’était pas la plus adaptée pour le projet mais il était intéressant de les utiliser afin de concevoir un prototype. En effet, elle est plus performante que ce dont nous avions réellement besoin (mémoire, puissance de calcul, etc.).
Par ailleurs, afin d'assurer une bonne communication sans fil, nous avons décidé d'utiliser la bande de fréquence 868 MHz. Grâce à cette fréquence, la communication peut être réalisée à une plus grande distance par rapport à une fréquence de 2,4 GHz et ce, pour une même taille d’antenne.

Nous avons également besoin du MSP430 LaunchPad. Il permet de flasher les cartes.
Pour notre prototype, nous avons utilisé un interrupteur pour chaque carte où il y a besoin d’un capteur. L’interrupteur permet de remplacer le capteur. On va pouvoir simuler un obstacle en changeant de valeur l’interrupteur.

b. Outils nécessaires
Utilisation d’un serveur web a été fait. Il s’agit d’un serveur informatique utilisé pour publier des sites web sur Internet.

Afin de réaliser une page web, nous avons besoin de certains outils comme les langages HTML et CSS. Ces derniers sont des langages de balisage permettant de structurer une page web. PHP est un langage de programmation utilisé pour le développement de pages web ; c’est celui qui est le plus utilisé dans ce domaine. Il est gratuit et ne nécessite aucune licence d’utilisation. Il existe un nombre incommensurable de bibliothèques et de tutoriels.

Pour que l’application fonctionne correctement, le site web doit stocker les informations relatives aux parkings renseignés. Pour cela nous utilisons une base de données. Il s’agit d’un outil capable de stocker et de récupérer des informations comme défini précédemment. Nous utiliserons le langage MySQL qui est un langage de programmation permettant la gestion de base de données (ajout, mise à jour ou suppression d’informations). Ce langage présente quelques avantages : il est gratuit et présente beaucoup de fonctionnalités. Il est également très répandu et il est très facile de rechercher des informations en cas de problème.

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Gérer la partie Administrative (mot de passe oublié, envoi de mail, désinscription, etc.) PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine sera de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

===Semaine 19===

'''Partie applicative (PA)'''

* Gestion de mise à jour des données sans l'intervention humaine.
* Intégration de la carte à l'application.
** Gestion de la géolocalisation
** Gestion d'un itinéraire pour arriver à la destination souhaitée
** Ajout de l'auto-complétion pour renseigner les lieux de manière aisée
** Affichage des parkings par ville (afin d'éviter de trop lourds calculs pour référencer tous les parkings sur la carte)
** Mise à jour des données dans les infos bulles gérée

Voici la représentation de la page avec la carte et ses fonctionnalités :
[[Fichier:RepresentationFonctionnalitesCarte.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Gérer la création de parking (interface), modifier la bdd et créer un programme en langage C permettant de récupérer les informations envoyées par liaison série (de la carte "concentrateur général" vers un ordinateur) et les envoyer sur le serveur. Une page php sera créée afin de mettre à jour la base de données. PRC : Réaliser la communication série permettant le lien entre les deux parties.

===Semaine 20===

Rédaction du rapport.
Préparation de la vidéo à tourner la semaine suivante.

'''Partie applicative (PA)'''

* La base de données a été modifiée, elle se présente sous cette forme :
[[Fichier:BDD finale.png|upright=3|vignette|center]] 
* L'interface pour créer une visualisation de parking a été réalisé (cf. figure ci-dessous), grâce à cette interface :
** Le configurateur peut utiliser un plan déjà construit
** Il peut également modifier le type de chaque case (route, place, autre)en double cliquant
** Lorsqu'il crée une place, il peut renseigner des paramètres comme l'id de capateur associé à la place ou sa pmorphologie
** Il peut visualiser la configuration en cliquant une seule fois
** Les informations sont transmises à la BDD pour sauvegarder les résultats
[[Fichier:Mode Configurateur.png|upright=3|vignette|center]] 

* L'interface du côté utilisateur a été également développée :
** Lorsque l'utilisateur choisit un parking, l'interface s'affiche
** Elle se met à jour régulièrement
** L’utilisateur peut voir les caractéristiques de chaque place de parking
[[Fichier:Application Avec interface utilisateur.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Amélioration de la communication RF, notamment au niveau de la gestion des accusés de réception.
* Réalisation de l'émission entre une carte et un PC permettant la mise à jour de transmettre les informations au système embarqué. Les données alors transmises sont: l'identifiant du parking, l'identifiant du capteur et l'état du capteur.

'''Partie Système embarqué (permettant de faire communiquer le PRC et PA)'''

* Réalisation de la réception série pour récupérer les informations du réseau de capteurs.
* Réalisation de la requête http de type post en utilisant une socket avec système SSL pour pouvoir envoyer des informations de manière sécurisée sur le serveur web.

'''Objectifs de la semaine suivante: Finition de la rédaction du rapport, réalisation de la vidéo, préparation du support de soutenance et la préparer.'''

===Semaine 21===

* Mise en commun des deux parties, avec la partie Système Embarqué. Association de la réception série avec l'envoi d'informations sur le serveur web.
* Réalisation de la vidéo le lundi matin à 10h.
* Rédaction du rapport.
* Préparation de la soutenance.

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-24T09:00:18Z

Cly : /* Semaine 20 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel et outils nécessaires==

a. Matériel nécessaire

Utilisation de plusieurs cartes CC430 réalisées par Monsieur BOÉ et Monsieur VANTROYS. Il s’agit de cartes électroniques comprenant un module RF (Radio Frequency) permettant d’envoyer et de recevoir des informations en communication sans fil à une certaine fréquence. Un capteur est connecté à ce dernier.

L’utilisation de ces cartes n’était pas la plus adaptée pour le projet mais il était intéressant de les utiliser afin de concevoir un prototype. En effet, elle est plus performante que ce dont nous avions réellement besoin (mémoire, puissance de calcul, etc.).
Par ailleurs, afin d'assurer une bonne communication sans fil, nous avons décidé d'utiliser la bande de fréquence 868 MHz. Grâce à cette fréquence, la communication peut être réalisée à une plus grande distance par rapport à une fréquence de 2,4 GHz et ce, pour une même taille d’antenne.

Nous avons également besoin du MSP430 LaunchPad. Il permet de flasher les cartes.
Pour notre prototype, nous avons utilisé un interrupteur pour chaque carte où il y a besoin d’un capteur. L’interrupteur permet de remplacer le capteur. On va pouvoir simuler un obstacle en changeant de valeur l’interrupteur.

b. Outils nécessaires
Utilisation d’un serveur web a été fait. Il s’agit d’un serveur informatique utilisé pour publier des sites web sur Internet.

Afin de réaliser une page web, nous avons besoin de certains outils comme les langages HTML et CSS. Ces derniers sont des langages de balisage permettant de structurer une page web. PHP est un langage de programmation utilisé pour le développement de pages web ; c’est celui qui est le plus utilisé dans ce domaine. Il est gratuit et ne nécessite aucune licence d’utilisation. Il existe un nombre incommensurable de bibliothèques et de tutoriels.

Pour que l’application fonctionne correctement, le site web doit stocker les informations relatives aux parkings renseignés. Pour cela nous utilisons une base de données. Il s’agit d’un outil capable de stocker et de récupérer des informations comme défini précédemment. Nous utiliserons le langage MySQL qui est un langage de programmation permettant la gestion de base de données (ajout, mise à jour ou suppression d’informations). Ce langage présente quelques avantages : il est gratuit et présente beaucoup de fonctionnalités. Il est également très répandu et il est très facile de rechercher des informations en cas de problème.

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Gérer la partie Administrative (mot de passe oublié, envoi de mail, désinscription, etc.) PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine sera de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

===Semaine 19===

'''Partie applicative (PA)'''

* Gestion de mise à jour des données sans l'intervention humaine.
* Intégration de la carte à l'application.
** Gestion de la géolocalisation
** Gestion d'un itinéraire pour arriver à la destination souhaitée
** Ajout de l'auto-complétion pour renseigner les lieux de manière aisée
** Affichage des parkings par ville (afin d'éviter de trop lourds calculs pour référencer tous les parkings sur la carte)
** Mise à jour des données dans les infos bulles gérée

Voici la représentation de la page avec la carte et ses fonctionnalités :
[[Fichier:RepresentationFonctionnalitesCarte.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Gérer la création de parking (interface), modifier la bdd et créer un programme en langage C permettant de récupérer les informations envoyées par liaison série (de la carte "concentrateur général" vers un ordinateur) et les envoyer sur le serveur. Une page php sera créée afin de mettre à jour la base de données. PRC : Réaliser la communication série permettant le lien entre les deux parties.

===Semaine 20===

Rédaction du rapport.
Préparation de la vidéo à tourner la semaine suivante.

'''Partie applicative (PA)'''

* La base de données a été modifiée, elle se présente sous cette forme :
[[Fichier:BDD finale.png|upright=3|vignette|center]] 
* L'interface pour créer une visualisation de parking a été réalisé (cf. figure ci-dessous), grâce à cette interface :
** Le configurateur peut utiliser un plan déjà construit
** Il peut également modifier le type de chaque case (route, place, autre)en double cliquant
** Lorsqu'il crée une place, il peut renseigner des paramètres comme l'id de capateur associé à la place ou sa pmorphologie
** Il peut visualiser la configuration en cliquant une seule fois
** Les informations sont transmises à la BDD pour sauvegarder les résultats
[[Fichier:Mode Configurateur.png|upright=3|vignette|center]] 

* L'interface du côté utilisateur a été également développée :
** Lorsque l'utilisateur choisit un parking, l'interface s'affiche
** Elle se met à jour régulièrement
** L’utilisateur peut voir les caractéristiques de chaque place de parking
[[Fichier:Application Avec interface utilisateur.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Amélioration de la communication RF, notamment au niveau de la gestion des accusés de réception.
* Réalisation de l'émission entre une carte et un PC permettant la mise à jour de transmettre les informations au système embarqué. Les données alors transmises sont: l'identifiant du parking, l'identifiant du capteur et l'état du capteur.

'''Partie Système embarqué (permettant de faire communiquer le PRC et PA)'''

* Réalisation de la réception série pour récupérer les informations du réseau de capteurs.
* Réalisation de la requête http de type post en utilisant une socket avec système SSL pour pouvoir envoyer des informations de manière sécurisée sur le serveur web.

'''Objectifs de la semaine suivante: Finition de la rédaction du rapport, réalisation de la vidéo, préparation du support de soutenance et la préparer.'''

===Semaine 21===

* Mise en commun pour la partie Système embarqué
* Rédaction du rapport
* Mise en commun des deux parties. Association de la réception série
* Réalisation de la vidéo le lundi matin à 10h
* Préparation de la soutenance

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-20T18:41:41Z

Cly : /* Semaine 18 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Gérer la partie Administrative (mot de passe oublié, envoi de mail, désinscription, etc.) PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine sera de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

===Semaine 19===

'''Partie applicative (PA)'''

* Gestion de mise à jour des données sans l'intervention humaine.
* Intégration de la carte à l'application.
** Gestion de la géolocalisation
** Gestion d'un itinéraire pour arriver à la destination souhaitée
** Ajout de l'auto-complétion pour renseigner les lieux de manière aisée
** Affichage des parkings par ville (afin d'éviter de trop lourds calculs pour référencer tous les parkings sur la carte)
** Mise à jour des données dans les infos bulles gérée

Voici la représentation de la page avec la carte et ses fonctionnalités :
[[Fichier:RepresentationFonctionnalitesCarte.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Gérer la création de parking (interface), modifier la bdd et créer un programme en langage C permettant de récupérer les informations envoyées par liaison série (de la carte "concentrateur général" vers un ordinateur) et les envoyer sur le serveur. Une page php sera créée afin de mettre à jour la base de données. PRC : Réaliser la communication série permettant le lien entre les deux parties.

===Semaine 20===

Rédaction du rapport.
Préparation de la vidéo à tourner la semaine suivante.

'''Partie applicative (PA)'''

'''Partie réseau de capteurs (PRC)'''

* Amélioration de la communication RF, notamment au niveau de la gestion des accusés de réception.
* Réalisation de l'émission et de la réception série entre une carte et un PC permettant la mise à jour de la base de données. Les données alors transmises sont: l'identifiant du parking, l'identifiant du capteur et l'état du capteur.

'''Objectifs de la semaine suivante:'''

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-20T18:40:56Z

Cly : /* Avancement du projet */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Gérer la partie Administrative (mot de passe oublié, envoi de mail, désinscription, etc.) PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine sera de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

===Semaine 19===

'''Partie applicative (PA)'''

* Gestion de mise à jour des données sans l'intervention humaine.
* Intégration de la carte à l'application.
** Gestion de la géolocalisation
** Gestion d'un itinéraire pour arriver à la destination souhaitée
** Ajout de l'auto-complétion pour renseigner les lieux de manière aisée
** Affichage des parkings par ville (afin d'éviter de trop lourds calculs pour référencer tous les parkings sur la carte)
** Mise à jour des données dans les infos bulles gérée

Voici la représentation de la page avec la carte et ses fonctionnalités :
[[Fichier:RepresentationFonctionnalitesCarte.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Gérer la création de parking (interface), modifier la bdd et créer un programme en langage C permettant de récupérer les informations envoyées par liaison série (de la carte "concentrateur général" vers un ordinateur) et les envoyer sur le serveur. Une page php sera créée afin de mettre à jour la base de données. PRC : Réaliser la communication série permettant le lien entre les deux parties.

===Semaine 20===

Rédaction du rapport.
Préparation de la vidéo à tourner la semaine suivante.

'''Partie applicative (PA)'''

'''Partie réseau de capteurs (PRC)'''

* Amélioration de la communication RF, notamment au niveau de la gestion des accusés de réception.
* Réalisation de l'émission et de la réception série entre une carte et un PC permettant la mise à jour de la base de données. Les données alors transmises sont: l'identifiant du parking, l'identifiant du capteur et l'état du capteur.

'''Objectifs de la semaine suivante:'''

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-15T21:25:46Z

Cly : /* Semaine 18 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

* Communication RF fonctionnelle.
* Établissement d'un protocole de communication basique permettant de traiter l'envoi et la réception de données, ainsi que les accusés de réception.
* Création des identifiants des cartes lors de la compilation. Deux identifiants sont à définir lors de la compilation: s'il s'agit d'un module capteur, il faut définir son identifiant, ainsi que l'identifiant du concentrateur auquel il est affilié; s'il s'agit d'un module concentrateur, il faut définir son identifiant, ainsi que l'identifiant du prochain concentrateur auquel il doit retransmettre les données (si le module concentrateur est celui du concentrateur général, alors l'identifiant du prochain concentrateur devra être initialisé à zéro).
* Mise en place de la remontée de données entre les différents modules (des capteurs au concentrateur général).

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine est de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailler sur l'interface. PRC : Réaliser la communication série permettant le lien entre les deux parties.

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-15T21:16:40Z

Cly : /* Semaine 17 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''

Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine est de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailer sur l'interface PRC :

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-15T21:16:19Z

Cly : /* Semaine 17 */

==Présentation du projet==

===Description du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, il est de plus en plus stressant de se rendre à son lieu de travail ou dans des grandes surfaces. Les embouteillages, les accidents sont des facteurs de stress pour les automobilistes. De plus, lors de l'arrivée de ces derniers dans les parkings, ils perdent de précieuses minutes à chercher des places pour se garer. Ce qui peut augmenter le stress, la pollution et l’énervement. C'est dans ce contexte que nous proposons une solution aux automobilistes afin qu'ils puissent se garer rapidement dans de bonnes conditions.
 

===Objectifs===
L'objectif du projet consiste à réaliser un parking intelligent. Une application ainsi sera créée pour qu'un utilisateur puisse consulter des informations sur les parkings répertoriés comme sa taille où le nombre de places disponibles. Il pourra ainsi s'y rendre et se garer facilement (localisation des places disponibles).

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

===Semaine 7===

Le choix de la carte CC430 a été fait pour plusieurs raisons:
* carte à disposition pour le projet;
* carte comprenant un micorcontrôleur (MSP430F5137) et un module RF (CC1101) permettant de faire de la transmission et de la réception de données à la fréquence de 868MHz;
* une première phase de tests peut être effectuée au niveau de la performance du matériel; dans un second temps, le matériel pourra être adapté en fonction de la mémoire/consommation d’énergie, etc.
Rermarque: Pour le projet, nous n’avons pas besoin d’un grand débit donc on peut descendre dans les fréquences et nous devons également faire de la transmision/réception dans un milieu perturbé (plus la fréquence est basse, plus la portée est importante et peut augmenter la robustesse de la communication).

 Nous avons repensé le schéma général répondant à la problématique afin qu’il soit le plus générique possible:

[[Fichier:SchemaPrincipe_v2.png|upright=2.5|vignette|center]]

 Nous avons également choisi une topologie ''Cluster-Tree''.
Après quelques recherches et informations données par monsieur Boé, nous nous sommes rendu compte que la topologie multi-sauts n’était pas la meilleure des solutions pour des raisons de consommation d’énergie. En effet, avec cette topologie, certains modules ont beaucoup de transmission/réception à faire, ce qui augmente donc la consommation de courant et diminue ainsi l’autonomie. La topologie ''Cluster-Tree'' est moins consommatrice de courant. En effet, chaque module de transmission/réception devra transmettre ses informations à un concentrateur assez proche qui transmettra au concentrateur général. Ces derniers seront connectés à des sources d’énergie comme des lampadaires, par exemple. Seuls les modules de capteurs seront un problème en termes de consommation d’énergie. 
 Cette topologie se présente sous cette forme:

[[Fichier:TopologieClusterTree.png|upright=2.5|vignette|center]]

 En choisissant la carte CC430, deux choix s’offraient à nous:
* utilisation d’un OS sur le microcontrôleur MSP430;
* pas d’utilisation d’OS. 

Plusieurs raisons nous ont fait choisir de ne pas utiliser un OS sur le microcontrôleur:
* bien que les protocoles de communication déjà écrits sur un OS nous auraient permis de gagner du temps, l’utilisation d’un OS peut augmenter la consommation de courant. Or, nous souhaitons avoir une consommation la plus faible possible pour que le matériel puisse durer plus longtemps et éviter ainsi de la maintenance.
* sans utilisation d’OS, le choix des composants sera plus large et plus adapté. En effet, le choix d’un OS nous limite sur le choix des microcontrôleurs.

'''Partie applicative (PA)''' 
Réflexions sur la partie application (BDD + application Web/Mobile).
Dans un premier temps, des tests pourront être faits de la manière suivante: (en cours) 
Schéma illustrant la phase de tests dans un premier temps (concentrateur général relié à un PC faisant office de serveur web + BDD)
[[Fichier:com_test.png|upright=3|vignette|center]] 

Dans un second, temps, nous ferons des tests en condition réelle: 
[[Fichier:com_réelle.png|upright=3|vignette|center]]
 

'''Partie réseau de capteurs (PRC)''' 
Première prise en main du MSP430 LaunchPad. 

'''Objectifs de la semaine suivante:''' PA : Réaliser la BDD et chercher informations sur la création d'une application sur serveur web. PRC : Approfondir les tests sur la carte CC430.

===Semaine 8===

'''Partie applicative (PA)'''

Recherches sur le module à utiliser afin de communiquer entre le concentrateur général et internet: pour le moment rien de concluant.
Recherches sur l’hébergeur capable d’héberger une BDD et un site web (gratuit).
Recherches sur quel type de BDD et de quel type de code pour application utiliser: quelques pistes.
Recherches sur comment rendre générique l’application: utiliser seulement une application web qui sera utilisable par n’importe quel smartphone relié à internet: framework bootstrap ou EJB Ano.

Pour le moment, easyPHP a été téléchargé. Avec ce logiciel, il est possible d'utiliser Apache. Le code pourra se faire en PHP et la BDD peut être réalisée sous MySQL. La prise en main a été faite et dans la semaine, la BDD sera créée sous peu et le développement du site commencera aussi sous peu.

'''Partie réseau de capteurs (PRC)'''

Appréhension du LaunchPad: compilation de fichiers test et deploiement sur le LaunchPad.
 > par exemple, ne faire clignoter qu’une des deux LEDs ou allumer la LED verte et l’éteindre lors de l’appui sur RESET.
La compilation et le déploiement sont réalisés sur le MSP430G2553.

Recherche sur les branchements à réaliser entre le LaunchPad et les cartes CC430.
 > en effet, le LaunchPad va servir de programmateur dans notre projet.

'''Objectifs de la semaine suivante:''' PA : Recherches sur les BDD afin de réaliser notre BDD. Création de vues basiques en PHP pour accéder à la BDD de manière graphique. PRC : Recherches sur le CC430F5137: compiler sur le MSP du CC430F5137 pour allumer une LED sur cette carte. Ajouter un interrupteur pour agir sur cette LED, si le temps le permet.

===Semaine 9===

Nous nous sommes concentrés sur la partie réseau de capteurs cette semaine.

'''Partie réseau de capteurs (PRC)'''

Réalisation du branchement entre le MSP et une carte CC430F5137: le branchement a par ailleurs été laborieux, de par une mauvaise compréhension de l'utilisation des cartes CC430F5137.
 > plusieurs programmes basiques ont été flashés sur le CC430F5137, de sorte à allumer les LEDs de différentes couleurs.

L'ajout d'un interrupteur n'a pu être fait cette semaine, car il faut faire réaliser des soudures par M. Flamen pour pouvoir brancher une entrée...

'''Objectifs de la semaine suivante:''' PA : Se familiariser avec les langages tels que (HTML, CSS, PHP, XML, JavaScript, SQL). PRC : Ajouter un interrupteur sur une carte CC430F5137 réaliser les tests avec cet interrupteur. Rechercher comment utiliser les composants RF de la carte et commencer à s'en servir.

===Semaine 10===

'''Partie applicative (PA)'''

Réalisation de tutoriels portant sur HTML, CSS et JavaScript afin de mieux se familiariser avec ces langages. Cette étude préalable permettra une meilleure avancée dans le projet par la suite.

'''Partie réseau de capteurs (PRC)'''

Réalisation des soudures sur la carte CC430F5137 afin de pouvoir ajouter un interrupteur simulant le capteur des places de parking. Interrupteur mis en place, avec début de tests. Problèmes de registres non-initialisés correctement... à voir la semaine prochaine.

'''Objectifs de la semaine suivante:''' PA : continuer à se familiariser avec les langages : Finaliser les tests avec l'interrupteur et commencer la communication RF.

===Semaine 11===

'''Partie applicative (PA)'''

Réalisation des tutoriels. Ces tutoriels portent sur PHP et MySQL. 
La base de données a été pensée de cette manière :

[[Fichier:BDD_Merise.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Tests avec l'interrupteur fonctionnels: registres P2IE (autorisation d'interruption) et P2IES (front descendant) initialisés, la LED réagit suivant l'état de l'interrupteur.
 > le fil soudé sur les cartes est en P2.3.
 Rermarque: Les LEDs de toutes les cartes CC430F5137 ne fonctionnent pas correctement: pour certaines, seule la couleur rouge fonctionne [cartes 121, 335, 433 et 439]. Les LEDs des autres cartes [145 et 251] fonctionnent correctement: les tests de communication RF se feront alors sur ces cartes.

Premiers tests pour la commmunication RF et la communication série, sans succès actuellement.

'''Objectifs de la semaine suivante:''' PA : Finir les tutoriels et construire le site web et la BDD. PRC : Réaliser une communication RF et une communication série.

===Semaine 12===

Une partie a été consacrée à la rédaction du rapport intermédiaire de projet.

'''Partie applicative (PA)'''

Construction du site web. Gestion des comptes utilisateurs (membre, administrateur et configurateur)
Réflexion sur l'interface permettant de créer un parking pour y associer une place de parking avec un capteur. Le parking ainsi créé sera modifiable par le configurateur.
Il se présente sous cette forme : 
[[Fichier:Interface parking cree.png|upright=3|vignette|center]] 

Le configurateur pourra ainsi définir des routes, des places de parkings et autres (arbres, batiment etc.). Le parking se présente sous forme de quadrillage. L'opérateur pourra définir une ou plusieurs comme étant d'un certain type (route, place ou autre). Il pourra définir les types de places ainsi que leur morphologie et renseigner si c'est une place handicapée ou non. Il pourra ainsi créer son parking. 

Il sera également possible de visualiser le parking via le compte "membres" présenté sous la forme suivante :
[[Fichier:Interface parking visu.png|upright=3|vignette|center]] 

'''Partie réseau de capteurs (PRC)'''

Soudures de tous les fils permettant de connecter un interrupteur pour la phase de tests. 
Recherches d'informations sur la Datasheet afin d'effectuer une communication RF : recherche des différents registres, leur rôle ainsi que les rôles de chaque bit.

'''Objectifs de la semaine suivante:''' Finir la rédaction du rapport et du support. Préparation de la soutenance.

===Semaine 13===

Rédaction du rapport. 
Préparation du support de soutenance. 
Préparation de la soutenance en faisant des répétitiions.

'''Objectifs de la semaine de la rentrée:''' PA : Mettre en forme de site Web (design). Commencer à chercher sur comment concevoir l'interface permettant de créer un parking et d'y associer une place de parking avec un capteur. PRC : Gérer basiquement la communication RF.

===Semaine 14 (Première semaine de Janvier après la rentrée)===

'''Partie applicative (PA)'''

La semaine a été dédiée à agencer de manière intuitive le site web (sur papier au départ) et à la recherche des différents moyens de créer l'interface permettant de créer un parking (idées potentielles : en PHP ou plus probable en Javascript).

'''Partie réseau de capteurs (PRC)'''

Rectification de l'interruption liée à l'interrupteur. 
Suite de la documentation sur le module RF.

'''Objectifs de la semaine suivante:''' PA : Mettre en ligne le site et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF.

===Semaine 15===

'''Partie applicative (PA)'''

Mise en ligne du site :
* Problème de mise en ligne du site liée à une erreur de l'administrateur;
* Résolution du problème avec Monsieur REDON;
* Transfert de la BDD du serveur local sur le serveur en ligne;
* Quelques différences entre le serveur local et le serveur en ligne;
* Résolution de quelques problèmes mais il reste encore quelques problèmes à résoudre.

'''Partie réseau de capteurs (PRC)'''

Modification du Makefile, car nouvel agencement des fichiers/documents. 
Suite de la documentation sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : Finir de résoudre les problèmes rencontrés et commencer la partie interface pour créer un parking. PRC : Gérer basiquement la communication RF, avec un protocole de communication à définir.

===Semaine 16===

'''Partie applicative (PA)'''

* Correction des autres problèmes (sessions et header)
* Difficulté rencontrée pour versionner les fichiers avec Github. (problème non résolu)
* Rajout de la gestion de recherche par département et région (réflexion sur utiliser PHP, AJAX ou JavaScript): Choix du JavaScript car avec PHP, le temps de latence, lorsque l'on choisit une région et qu'il propose les départements associés, est trop long.
* Modifier la hiérarchisation des dossiers et fichiers sur le serveur(non finie)

'''Partie réseau de capteurs (PRC)'''

Récupération de nouveaux fichiers sources exemples de la communication RF avec les mêmes cartes.
Début de la gestion de la communication RF.
 > la carte émettrice semble envoyer des données, mais la carte réceptrice ne les reçoit pas.

'''Objectifs de la semaine suivante:''' PA : Finir la gestion de département et régions. PRC : Finir la communication RF, avec son protocole de communication à définir.

===Semaine 17===

'''Partie applicative (PA)'''

* Gestion des départements et région terminée
* Familiarisation avec les outils utilisés pour Google Maps. Plusieurs tâches ont été réalisées (non intégrées à l'application):
** Recherche et géolocalisation d'une adresse
** Personnalisation des icônes sur une carte à un endroit précis
** Affichage des informations de l'icône représentant un parking

'''Partie réseau de capteurs (PRC)'''
Débuggage sur la communication RF.

'''Objectifs de la semaine suivante:''' PA : PRC : Réussir la communication RF, avec son protocole de communication. Implémenter la remontée de données jusqu'à la carte "concentrateur général".

===Semaine 18===

'''Partie applicative (PA)'''

* Hierarchisation correcte des fichiers et dossiers pour le site (dossier sql, JavaScript, css, php, images)
* Création de foncions génériques pour accéder à la bdd
* Gestion oubli mot de passe par un membre et envoi de mail en fonction pour qu’il puisse récupérer ses identifiants avec changement de mot de passe
* Gestion du changement de mot de passe par un membre
* Gestion de la désinscription d’un membre
* Gestion des cas particuliers (lorsqu’un membre est connecté, qu’il accède à une page partciulière avec certains droits, qu’il se déconnecte, il ne peut pas visualiser les informations de la page précédente.
* Gestion du compte admin : un membre ayant les droits admin, peut ajouter un membre, changer ses droits ou le supprimer de la base de données.

'''Partie réseau de capteurs (PRC)'''

'''Objectifs de la semaine suivante:''' PA : Le but de la semaine prochaine est de réaliser la gestion de la carte permettant de visualiser sur un plan les parkings. Une deuxième phase sera consacrée à l'affichage des données et mise à jour de celle-ci. Une dernière phase consistera à commencer à travailer sur l'interface PRC :

Voici le planning que nous avons établi pour la fin de projet :

{| class="wikitable alternance centre"
|+ Planning prévisionnel revu
|----
! !! scope="col" | Partie Applicative (PA) !! scope="col" | Partie Réseau de Capteurs (PRC) !! scope="col" | Partie Commune
|----
! scope="row" | Du 05/02 au 06/02
|
* Finir d’écrire la BDD (à l’écrit et sur internet);
* Permettre d’ajouter, de modifier et supprimer des parkings (dans la BDD) avec les paramètres grâce au membre de type “configurateur”;
* Permettre l’ajout, la modification et la suppression de nouveaux membres, (dans la BDD) avec les paramètres grâce au membre de type “admin”.
||
* Finir la communication RF avec son protocole de communication (à définir exactement).
|----
! scope="row" | Du 09/02 au 10/02
|
* Gérer la carte : mettre sur la carte les icônes à chaque endroit où un parking est renseigné et permettre d’afficher les informations lors de clics sur l’icône.
||
* Gérer les identifiants des capteurs;
* Gérer les collisions en testant les émissions et réceptions de plusieurs modules capteurs.
|----
! scope="row" | Du 11/02 au 13/02
|
* Réaliser l’interface : permettre à un configurateur de créer un parking de manière représentative;
* Permettre l’affichage dynamique pour visualiser un plan.
||
* Gérer le réseau avec la topologie ''Cluster-Tree''.
|----
! scope="row" | Du 16/02 au 18/02
| || ||
* Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
|----
! scope="row" | Le 19/02
| || ||
* Réaliser des tests sur la globalité du projet.
|----
! scope="row" | Le 20/02
| || ||
* Présenter les résultats;
* Réaliser une démonstration.
|----
! scope="row" | Du 20/02 au 25/02
| || ||
* Apporter les modifications nécessaires par rapport aux retours lors de la démonstration;
* Rédiger le rapport;
* Préparer la soutenance.
|}

== Rendus ==

* Rapport intermédiaire de projet : [[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf‎]]

P59 Assistance globale pour aide au parking

2015-02-05T21:11:04Z

Cly : /* Semaine 17 */

P59 Assistance globale pour aide au parking

2015-02-05T21:10:35Z

Cly : /* Avancement du projet */

P59 Assistance globale pour aide au parking

2014-12-07T20:30:43Z

Cly : /* Semaine 11 */

P59 Assistance globale pour aide au parking

2014-12-02T11:34:01Z

Cly : /* Semaine 11 */

P59 Assistance globale pour aide au parking

2014-12-02T11:32:51Z

Cly : /* Avancement du projet */

P59 Assistance globale pour aide au parking

2014-12-02T11:24:05Z

Cly : /* Avancement du projet */

P59 Assistance globale pour aide au parking

2014-11-26T10:58:47Z

Cly : /* Avancement du projet */

P59 Assistance globale pour aide au parking

2014-11-18T08:36:14Z

Cly : /* Semaine 8 */

P59 Assistance globale pour aide au parking

2014-11-18T08:34:53Z

Cly : /* Avancement du projet */

Fichier:TopologieClusterTree.png

2014-11-18T08:33:57Z

Cly : a téléversé une nouvelle version de « Fichier:TopologieClusterTree.png »

Fichier:TopologieClusterTree.png

2014-11-18T08:30:42Z

Cly :

Fichier:SchemaPrincipe v2.png

2014-11-18T08:28:01Z

Cly : a téléversé une nouvelle version de « Fichier:SchemaPrincipe v2.png »

Fichier:SchemaPrincipe v2.png

2014-11-18T08:19:53Z

Cly :

P59 Assistance globale pour aide au parking

2014-11-12T16:56:59Z

Cly : /* Semaine 7 */

P59 Assistance globale pour aide au parking

2014-11-04T20:37:24Z

Cly : /* Description du projet */

P59 Assistance globale pour aide au parking

2014-10-31T12:20:57Z

Cly : /* Semaine 3 */

==Présentation du projet==

===Contexte du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, le stationnement peut s'avérer difficile et long.
 

===Description du projet===
Ce projet propose une solution à ce problème: il s'agit de réaliser un parking intelligent qui permettrait aux automobilistes de trouver une place et de se garer de manière plus aisée. Cette solution consiste à la réalisation d'un réseau de capteurs, qui communiquerait vers une application web/mobile. Celle-ci permettrait ainsi aux utilisateurs d'être tenus au courant des places disponibles (nombre et localisation).
 

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

[[Fichier:SchemaPrincipe.png|upright=1.5|vignette|center]]

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

Fichier:SchemaPrincipe.png

2014-10-31T12:13:00Z

Cly : Schéma principe

Schéma principe

P59 Assistance globale pour aide au parking

2014-10-31T11:23:46Z

Cly : /* Avancement du projet */

==Présentation du projet==

===Contexte du projet===
De nos jours, de par l'augmentation du nombre de véhicules circulant, le stationnement peut s'avérer difficile et long.
 

===Description du projet===
Ce projet propose une solution à ce problème: il s'agit de réaliser un parking intelligent qui permettrait aux automobilistes de trouver une place et de se garer de manière plus aisée. Cette solution consiste à la réalisation d'un réseau de capteurs, qui communiquerait vers une application web/mobile. Celle-ci permettrait ainsi aux utilisateurs d'être tenus au courant des places disponibles (nombre et localisation).
 

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

===Semaine 3===

Recherches sur les capteurs à utiliser. Établissement d’un tableau récapitulatif qui prend en compte les avantages et inconvénients de chaque capteur.

Définition d’un schéma répondant à la problématique. Le schéma est générique (quelque soit le capteur utilisé ou le module de communication sans fil, le résultat sera le même).

'''Objectifs de la semaine suivante:''' Rendre compte de nos avancements à nos tuteurs et discuter des questions qui nous sont venues.

===Semaine 4===

Prise de rendez-vous avec M. BOÉ pour faire part de l’avancement du projet et pour avoir des informations complémentaires, à savoir:
* le type de capteur à utiliser: pour le prototype qui sera réalisé, on n’utilisera pas nécessairement le capteur le plus adapté au problème, cependant une étude sur les capteurs devrait être réalisée;
* la possibilité de fermer un parking: la fermeture des parkings n’est pas envisageable, car toutes sortes de parkings est à prendre en considération, ce qui rendrait alors difficile, voire impossible de réaliser un système basé sur des parkings fermés;
* la réflexion sur des équipements intégrables à une voiture: cette solution poserait problème que ce soit au niveau technologique ou logistique (il faudrait alors que tous les automobilistes soient équipés pour cela fonctionne correctement).

Réflexion sur l’agencement de l’application web/mobile.

'''Objectifs de la semaine suivante:''' Rechercher la topologie à utiliser pour le réseau de communication et commencer les recherches de composants.

===Semaine 5===

Réflexion sur le type de communication à adopter. Il existe trois types de topologie: multi-hop, par relais ou directement par liaison directe.

Nous avons donc choisi de partir sur la communication multi-hop. En effet, cette communication nous permet de réduire au plus le nombre d'éléments dans la chaîne de communcation (pas de relais) et d'assurer une meilleure robustesse du système, car les données peuvent suivre différents chemins, et à une portée plus courte que la liaison directe.

Par ailleurs, nous avons décidé que la communication se ferait en 868 MHz; cette fréquence permettant une meilleure portée et robustesse que 2,4 GHz, répondant ainsi mieux à notre problème. Celle-ci devra respecter la norme IEEE 802.15.4.

Le choix des composants est un point assez difficile car en effet, il y a plusieurs éléments qui nous freinent dans notre réflexion: le nombre d’envois d’informations dans un temps imparti, la puissance du microcontrôleur pour gérer les envois, la contrainte météorologique, etc.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser.

===Semaine 6===

En ce qui concerne le choix des composants, nous avons pensé au CC1101 pour la partie RF. Il nous a alors été indiqué l'existence du panStamp AVR, qui combine un CC1101 avec un ATMega328p. L'utilisation des panStamps pourrait alors servir pour les modules liés aux capteurs, de même que pour le module de réception lié au concentrateur.

Cependant, après des échanges avec M. BOÉ, il semblerait que l'utilisation d'un panStamp AVR ne serait pas adapté à notre projet et apporterait des complications alors que d'autres solutions existent et pourraient être plus pertinentes.

'''Objectifs de la semaine suivante:''' Définir la technologie à utiliser en tenant compte des remarques reçues. Commencer en parallèle le côté applicatif et la base de données.

Projets IMA5 2014/2015

2014-10-31T10:47:12Z

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

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

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td> </td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td></td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td></td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td></td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td></td>
</tr>
<tr><td>[[P21 balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td></td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td></td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td></td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / « wireless]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td></td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td></td>
</tr>
</table>

P59 Assistance globale pour aide au parking

2014-10-13T13:28:28Z

Cly : /* Présentation du projet */

P59 Assistance globale pour aide au parking

2014-10-13T13:28:10Z

Cly : /* Présentation du projet */

Projets IMA5 2014/2015

2014-10-07T17:15:40Z

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

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

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td></td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> </td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td></td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td></td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td></td>
</tr>
<tr><td>[[P21 balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td></td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td></td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / « wireless]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td></td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td></td>
</tr>
</table>

Projets IMA5 2014/2015

2014-09-30T13:02:15Z

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

P59 Assistance globale pour aide au parking

2014-09-30T13:00:15Z

Cly : /* Avancement du projet */

==Présentation du projet==

 

==Cahier des charges==

 

==Matériel nécessaire==

 

==Étapes importantes (prévisionnel)==

# Étude des solutions techniques possibles.
# Réalisation du réseau de capteurs, avec récupération des données.
# Étude des services à implémenter à l'application mobile.
# Réalisation de l'application mobile.
# Réalisation de la transmission de données.
(sachant que les étapes 1/2 et 3/4 peuvent être plus ou moins réalisées en parallèle)

==Avancement du projet==

===Semaine 1===

Prise de rendez-vous avec les encadrants pour une redéfinition plus précise du cahier des charges.

Recherches sur les solutions de ''Smart Parking'' déjà existantes, afin de choisir celle qui nous serait la plus adaptée.

'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables.

===Semaine 2===

Suite des recherches sur les solutions de ''Smart Parking''. Réflexion sur les solutions techniques (type de capteurs, nombre de capteurs).

'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème.

P59 Assistance globale pour aide au parking

2014-09-25T13:41:01Z

Cly : Page créée avec « ==Présentation du projet== ==Cahier des charges== ==Matériel nécessaire== ==Étapes importantes (prévisionnel)== # Étude des solutions technique... »

Projets IMA5 2014/2015

2014-09-25T13:29:07Z

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

Robots humanoïdes 2013 groupe II

2014-04-13T12:02:34Z

Cly : /* Améliorations possibles */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

[[Fichier:Montage Naos.JPG|vignette|gauche|upright=1.8|Schéma général]]

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Matériel nécessaire===

# Deux NAO;
# Un routeur;
# Un PC fonctionnant sous Linux.

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

[[Fichier:nao_server_client_old_wiki.png|vignette|upright=1.75|Environnement Serveur-Clients]]Lors de cette semaine, nous avons tout d'abord cherché à réaliser un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

====Semaine 7====

[[Fichier:Strace_wiki_close_socket.png|vignette|gauche|upright=1.6|Fermeture des sockets]]Nous avons modifié le programme afin de synchroniser correctement les deux NAO. Pour pallier le problème précédent, il a fallu réaliser un simple test afin d'éviter que la valeur envoyée par le serveur ne revienne à l'étape précédente... Nous avons aussi rajouté la récupération des adresses IP des NAO afin de pouvoir les différencier et de réaliser les bons tests pour la synchronisation. Cette fois-ci les tests ont montré que les deux NAO étaient synchronisés. On peut tout de même noter qu'actuellement, les NAO ne sont pas parfaitement synchronisés: il y a un décalage d'une durée égale à la durée d'émission et de réception entre le serveur et le client (en effet, les données sont envoyées à un NAO, puis à l'autre, ce qui explique ce décalage).

Nous avons ensuite de nouveau modifié le programme afin d'arrêter le client et le serveur lorsque la synchronisation est finie. Lors d'un débuggage, nous avons par ailleurs remarqué que le système client/serveur fonctionnait, mais de manière peu correcte niveau programmation... le client ouvre actuellement des sockets en continu, ce qui n'est évidemment pas ce qu'il faut faire... Nous avons donc décidé de modifier ce système afin d'avoir un programme plus propre...

'''Objectifs pour la semaine 8:''' modifier le système client/serveur pour corriger le problème des sockets.

====Semaine 8====

[[Fichier:nao_synchro_strace_close.png|vignette|droite|upright=1.6|Utilisation des sockets]]Nous avons dans un premier temps résolu le problème de la création des sockets de communication. Actuellement, nous ne créons qu'un seul socket par client NAO et chaque NAO n'utilise que son socket respectif pour communiquer avec le serveur. Cela nous permet alors d'avoir un programme plus fiable et d'éviter de potentielles erreurs de réseau durant la création et les tentatives de communication de nouveaux sockets avec le serveur.

Ensuite, nous avons réfléchi à un algorithme permettant de quitter proprement les programmes des clients et du serveur lorsque la synchronisation des NAO était terminée. L'implémentation a été effectuée et cela fonctionne.

Au niveau de la synchronisation, elle s'effectue avec quelques millisecondes de décalage (temps de communication entre un NAO et le PC), un temps totalement négligeable pour le bon déroulement du programme Choregraphe des NAO.

'''Objectifs pour la semaine 9 : ''' Vérifier avec le second binôme du projet NAO que l'intégralité du projet fonctionne correctement.

====Semaine 9====

Lors des tests avec le second binôme du projet NAO, nous nous sommes rendu compte qu'il y avait encore quelques erreurs d'algorithmes, au niveau de certains cas initiaux ou peu probables auxquels nous n'avions pas pensé auparavant. Nous avons alors amélioré l'algorithme du programme client afin de pallier tous les potentiels cas défaillants: état "prêt" des NAO au démarrage, ou encore les deux NAO sont prêts exactement en même temps.
Enfin, après avoir réglé ces problèmes, nous avons filmé la synchronisation des NAO avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I deuxième groupe].

===Bilan du projet===

Les premières semaines de projet, nous avons commencé par appréhender les logiciels, les notions et les spécificités liés au NAO. Nous avons alors principalement lu de la documentation et exécuté les exemples afin de comprendre au mieux son fonctionnement avant de le programmer.

Après cette première approche du NAO, nous avons réfléchi à ce qu’il était alors concrètement possible de faire pour synchroniser les deux NAO. Nous en avons discuté avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I second binôme du projet NAO], et nous avons décidé de les synchroniser par un événement de parole. Visuellement parlant, nous avons décidé que lorsqu’un NAO était “prêt” (et attendait alors le second NAO), il devait baisser la tête.

Dans cette seconde partie du projet, après avoir apporté des précisions sur le cahier des charges, nous avons donc commencé à programmer le système clients/serveur. Pour que ce système fonctionne, il fallait exécuter le serveur sur un ordinateur et les clients sur les NAO. Ceci nécessitait ainsi de réaliser une ''cross-compilation'', et de se connecter via ''ssh'' aux NAO. Après la réalisation de ce système de clients/serveur, nous avons écrit l’algorithme de synchronisation. De par la communication par TCP, les NAO ne pouvaient parfaitement être synchronisés, car l’un des deux NAO recevait nécessairement l’information après l’autre. Cependant, la synchronisation réalisée était amplement suffisante pour le reste du programme de comportement sous Choregraphe.

Au cours de ces 10 semaines de projet, nous sommes alors parvenus à réaliser un système de clients/serveur en C++ (utilisant les librairies de C pour la partie réseau), qui permet de réaliser une synchronisation de deux NAO. Ceci correspond au cahier des charges que l’on s’était fixé au début du projet.

===Améliorations possibles===

Notre système clients/serveur ne peut actuellement gérer que deux NAO. Pour améliorer cela, il aurait été bien de:
<blockquote>> restructurer notre programme et utiliser un tableau (ou une liste) de structure de données: on pourrait par exemple créer une structure de données pour les NAO avec leur adresse IP et leur état;</blockquote>
<blockquote>> utiliser des fonctions de sondage de la socket (''poll()'' ou ''select()'') pour récupérer toutes les connexions potentielles de clients;</blockquote>
<blockquote>''ou''</blockquote>
<blockquote>> utiliser des processus légers (''threads'') pour le système clients/serveur, ce qui aurait amélioré l’efficacité du système et nous aurait permis de gérer facilement tous les clients potentiels.</blockquote>

Robots humanoïdes 2013 groupe II

2014-04-13T10:05:02Z

Cly : /* Projet de Coopération Nao N2N: Partie Communication/Réseau */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

[[Fichier:Montage Naos.JPG|vignette|gauche|upright=1.8|Schéma général]]

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Matériel nécessaire===

# Deux NAO;
# Un routeur;
# Un PC fonctionnant sous Linux.

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

[[Fichier:nao_server_client_old_wiki.png|vignette|upright=1.75|Environnement Serveur-Clients]]Lors de cette semaine, nous avons tout d'abord cherché à réaliser un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

====Semaine 7====

[[Fichier:Strace_wiki_close_socket.png|vignette|gauche|upright=1.6|Fermeture des sockets]]Nous avons modifié le programme afin de synchroniser correctement les deux NAO. Pour pallier le problème précédent, il a fallu réaliser un simple test afin d'éviter que la valeur envoyée par le serveur ne revienne à l'étape précédente... Nous avons aussi rajouté la récupération des adresses IP des NAO afin de pouvoir les différencier et de réaliser les bons tests pour la synchronisation. Cette fois-ci les tests ont montré que les deux NAO étaient synchronisés. On peut tout de même noter qu'actuellement, les NAO ne sont pas parfaitement synchronisés: il y a un décalage d'une durée égale à la durée d'émission et de réception entre le serveur et le client (en effet, les données sont envoyées à un NAO, puis à l'autre, ce qui explique ce décalage).

Nous avons ensuite de nouveau modifié le programme afin d'arrêter le client et le serveur lorsque la synchronisation est finie. Lors d'un débuggage, nous avons par ailleurs remarqué que le système client/serveur fonctionnait, mais de manière peu correcte niveau programmation... le client ouvre actuellement des sockets en continu, ce qui n'est évidemment pas ce qu'il faut faire... Nous avons donc décidé de modifier ce système afin d'avoir un programme plus propre...

'''Objectifs pour la semaine 8:''' modifier le système client/serveur pour corriger le problème des sockets.

====Semaine 8====

[[Fichier:nao_synchro_strace_close.png|vignette|droite|upright=1.6|Utilisation des sockets]]Nous avons dans un premier temps résolu le problème de la création des sockets de communication. Actuellement, nous ne créons qu'un seul socket par client NAO et chaque NAO n'utilise que son socket respectif pour communiquer avec le serveur. Cela nous permet alors d'avoir un programme plus fiable et d'éviter de potentielles erreurs de réseau durant la création et les tentatives de communication de nouveaux sockets avec le serveur.

Ensuite, nous avons réfléchi à un algorithme permettant de quitter proprement les programmes des clients et du serveur lorsque la synchronisation des NAO était terminée. L'implémentation a été effectuée et cela fonctionne.

Au niveau de la synchronisation, elle s'effectue avec quelques millisecondes de décalage (temps de communication entre un NAO et le PC), un temps totalement négligeable pour le bon déroulement du programme Choregraphe des NAO.

'''Objectifs pour la semaine 9 : ''' Vérifier avec le second binôme du projet NAO que l'intégralité du projet fonctionne correctement.

====Semaine 9====

Lors des tests avec le second binôme du projet NAO, nous nous sommes rendu compte qu'il y avait encore quelques erreurs d'algorithmes, au niveau de certains cas initiaux ou peu probables auxquels nous n'avions pas pensé auparavant. Nous avons alors amélioré l'algorithme du programme client afin de pallier tous les potentiels cas défaillants: état "prêt" des NAO au démarrage, ou encore les deux NAO sont prêts exactement en même temps.
Enfin, après avoir réglé ces problèmes, nous avons filmé la synchronisation des NAO avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I deuxième groupe].

===Bilan du projet===

Les premières semaines de projet, nous avons commencé par appréhender les logiciels, les notions et les spécificités liés au NAO. Nous avons alors principalement lu de la documentation et exécuté les exemples afin de comprendre au mieux son fonctionnement avant de le programmer.

Après cette première approche du NAO, nous avons réfléchi à ce qu’il était alors concrètement possible de faire pour synchroniser les deux NAO. Nous en avons discuté avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I second binôme du projet NAO], et nous avons décidé de les synchroniser par un événement de parole. Visuellement parlant, nous avons décidé que lorsqu’un NAO était “prêt” (et attendait alors le second NAO), il devait baisser la tête.

Dans cette seconde partie du projet, après avoir apporté des précisions sur le cahier des charges, nous avons donc commencé à programmer le système clients/serveur. Pour que ce système fonctionne, il fallait exécuter le serveur sur un ordinateur et les clients sur les NAO. Ceci nécessitait ainsi de réaliser une ''cross-compilation'', et de se connecter via ''ssh'' aux NAO. Après la réalisation de ce système de clients/serveur, nous avons écrit l’algorithme de synchronisation. De par la communication par TCP, les NAO ne pouvaient parfaitement être synchronisés, car l’un des deux NAO recevait nécessairement l’information après l’autre. Cependant, la synchronisation réalisée était amplement suffisante pour le reste du programme de comportement sous Choregraphe.

Au cours de ces 10 semaines de projet, nous sommes alors parvenus à réaliser un système de clients/serveur en C++ (utilisant les librairies de C pour la partie réseau), qui permet de réaliser une synchronisation de deux NAO. Ceci correspond au cahier des charges que l’on s’était fixé au début du projet.

===Améliorations possibles===

Notre système clients/serveur ne peut actuellement gérer que deux NAO. Pour améliorer cela, il aurait été bien de:
<blockquote>> restructurer notre programme et utiliser un tableau (ou une liste) de structure de données: on pourrait par exemple créer une structure de données pour les NAO avec leur adresse IP et leur état;</blockquote>
<blockquote>> utiliser des processus légers (''threads'') pour le système clients/serveur, ce qui aurait amélioré l’efficacité du système et nous aurait permis de gérer facilement tous les clients potentiels.</blockquote>

Robots humanoïdes 2013 groupe II

2014-04-13T09:51:25Z

Cly : /* Projet de Coopération Nao N2N: Partie Communication/Réseau */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

[[Fichier:Montage Naos.JPG|vignette|gauche|upright=1.8|Schéma général]]

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Matériel nécessaire===

# Deux NAO;
# Un routeur;
# Un PC fonctionnant sous Linux.

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

[[Fichier:nao_server_client_old_wiki.png|vignette|upright=1.75|Environnement Serveur-Clients]]Lors de cette semaine, nous avons tout d'abord cherché à réaliser un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

====Semaine 7====

[[Fichier:Strace_wiki_close_socket.png|vignette|gauche|upright=1.6|Fermeture des sockets]]Nous avons modifié le programme afin de synchroniser correctement les deux NAO. Pour pallier le problème précédent, il a fallu réaliser un simple test afin d'éviter que la valeur envoyée par le serveur ne revienne à l'étape précédente... Nous avons aussi rajouté la récupération des adresses IP des NAO afin de pouvoir les différencier et de réaliser les bons tests pour la synchronisation. Cette fois-ci les tests ont montré que les deux NAO étaient synchronisés. On peut tout de même noter qu'actuellement, les NAO ne sont pas parfaitement synchronisés: il y a un décalage d'une durée égale à la durée d'émission et de réception entre le serveur et le client (en effet, les données sont envoyées à un NAO, puis à l'autre, ce qui explique ce décalage).

Nous avons ensuite de nouveau modifié le programme afin d'arrêter le client et le serveur lorsque la synchronisation est finie. Lors d'un débuggage, nous avons par ailleurs remarqué que le système client/serveur fonctionnait, mais de manière peu correcte niveau programmation... le client ouvre actuellement des sockets en continu, ce qui n'est évidemment pas ce qu'il faut faire... Nous avons donc décidé de modifier ce système afin d'avoir un programme plus propre...

'''Objectifs pour la semaine 8:''' modifier le système client/serveur pour corriger le problème des sockets.

====Semaine 8====

[[Fichier:nao_synchro_strace_close.png|vignette|droite|upright=1.6|Utilisation des sockets]]Nous avons dans un premier temps résolu le problème de la création des sockets de communication. Actuellement, nous ne créons qu'un seul socket par client NAO et chaque NAO n'utilise que son socket respectif pour communiquer avec le serveur. Cela nous permet alors d'avoir un programme plus fiable et d'éviter de potentielles erreurs de réseau durant la création et les tentatives de communication de nouveaux sockets avec le serveur.

Ensuite, nous avons réfléchi à un algorithme permettant de quitter proprement les programmes des clients et du serveur lorsque la synchronisation des NAO était terminée. L'implémentation a été effectuée et cela fonctionne.

Au niveau de la synchronisation, elle s'effectue avec quelques millisecondes de décalage (temps de communication entre un NAO et le PC), un temps totalement négligeable pour le bon déroulement du programme Choregraphe des NAO.

'''Objectifs pour la semaine 9 : ''' Vérifier avec le second binôme du projet NAO que l'intégralité du projet fonctionne correctement.

====Semaine 9====

Lors des tests avec le second binôme du projet NAO, nous nous sommes rendu compte qu'il y avait encore quelques erreurs d'algorithmes, au niveau de certains cas initiaux ou peu probables auxquels nous n'avions pas pensé auparavant. Nous avons alors amélioré l'algorithme du programme client afin de pallier tous les potentiels cas défaillants: état "prêt" des NAO au démarrage, ou encore les deux NAO sont prêts exactement en même temps.
Enfin, après avoir réglé ces problèmes, nous avons filmé la synchronisation des NAO avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I deuxième groupe].

===Bilan du projet===

Les premières semaines de projet, nous avons commencé par appréhender les logiciels, les notions et les spécificités liés au NAO. Nous avons alors principalement lu de la documentation et exécuté les exemples afin de comprendre au mieux son fonctionnement avant de le programmer.

Après cette première approche du NAO, nous avons réfléchi à ce qu’il était alors concrètement possible de faire pour synchroniser les deux NAO. Nous en avons discuté avec le [http://projets-imasc.plil.net/mediawiki/index.php?title=Robots_humano%C3%AFdes_2013_groupe_I second binôme du projet NAO], et nous avons décidé de les synchroniser par un événement de parole. Visuellement parlant, nous avons décidé que lorsqu’un NAO était “prêt” (et attendait alors le second NAO), il devait baisser la tête.

Dans cette seconde partie du projet, après avoir apporté des précisions sur le cahier des charges, nous avons donc commencé à programmer le système clients/serveur. Pour que ce système fonctionne, il fallait exécuter le serveur sur un ordinateur et les clients sur les NAO. Ceci nécessitait ainsi de réaliser une cross-compilation, et de se connecter via ssh aux NAO. Après la réalisation de ce système de clients/serveur, nous avons écrit l’algorithme de synchronisation. De par la communication par TCP, les NAO ne pouvaient parfaitement être synchronisés, car l’un des deux NAO recevait nécessairement l’information après l’autre. Cependant, la synchronisation réalisée était amplement suffisante pour le reste du programme de comportement sous Choregraphe.

Au cours de ces 10 semaines de projet, nous sommes alors parvenus à réaliser un système de clients/serveur en C++ (utilisant les librairies de C pour la partie réseau), qui permet de réaliser une synchronisation de deux NAO. Ceci correspond au cahier des charges que l’on s’était fixé au début du projet.

===Améliorations possibles===

Notre système clients/serveur ne peut actuellement gérer que deux NAO. Pour améliorer cela, il aurait été bien de:
<blockquote>> restructurer notre programme et utiliser un tableau (ou une liste) de structure de données: on pourrait par exemple créer une structure de données pour les NAO avec leur adresse IP et leur état;</blockquote>
<blockquote>> utiliser des processus légers (threads) pour le système clients/serveur, ce qui aurait amélioré l’efficacité du système et nous aurait permis de gérer facilement tous les clients potentiels.</blockquote>

Robots humanoïdes 2013 groupe II

2014-03-30T19:38:10Z

Cly : /* Projet de Coopération Nao N2N: Partie Communication/Réseau */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Matériel nécessaire===

# Deux NAO;
# Un routeur;
# Un PC fonctionnant sous Linux.

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

Lors de cette semaine, nous avons tout d'abord cherché à réaliser un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

====Semaine 7====

Nous avons modifié le programme afin de synchroniser correctement les deux NAO. Pour pallier le problème précédent, il a fallu réaliser un simple test afin d'éviter que la valeur envoyée par le serveur ne revienne à l'étape précédente... Nous avons aussi rajouté la récupération des adresses IP des NAO afin de pouvoir les différencier et de réaliser les bons tests pour la synchronisation. Cette fois-ci les tests ont montré que les deux NAO étaient synchronisés. On peut tout de même noter qu'actuellement, les NAO ne sont pas parfaitement synchronisés: il y a un décalage d'une durée égale à la durée d'émission et de réception entre le serveur et le client (en effet, les données sont envoyées à un NAO, puis à l'autre, ce qui explique ce décalage).

Nous avons ensuite de nouveau modifié le programme afin d'arrêter le client et le serveur lorsque la synchronisation est finie. Lors d'un débuggage, nous avons par ailleurs remarqué que le système client/serveur fonctionnait, mais de manière peu correcte niveau programmation... le client ouvre actuellement des sockets en continu, ce qui n'est évidemment pas ce qu'il faut faire... Nous avons donc décidé de modifier ce système afin d'avoir un programme plus propre...

'''Objectifs pour la semaine 8:''' modifier le système client/serveur pour corriger le problème des sockets.

Robots humanoïdes 2013 groupe II

2014-03-30T19:36:30Z

Cly : /* Avancement du projet */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

Lors de cette semaine, nous avons tout d'abord cherché à réaliser un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

====Semaine 7====

Nous avons modifié le programme afin de synchroniser correctement les deux NAO. Pour pallier le problème précédent, il a fallu réaliser un simple test afin d'éviter que la valeur envoyée par le serveur ne revienne à l'étape précédente... Nous avons aussi rajouté la récupération des adresses IP des NAO afin de pouvoir les différencier et de réaliser les bons tests pour la synchronisation. Cette fois-ci les tests ont montré que les deux NAO étaient synchronisés. On peut tout de même noter qu'actuellement, les NAO ne sont pas parfaitement synchronisés: il y a un décalage d'une durée égale à la durée d'émission et de réception entre le serveur et le client (en effet, les données sont envoyées à un NAO, puis à l'autre, ce qui explique ce décalage).

Nous avons ensuite de nouveau modifié le programme afin d'arrêter le client et le serveur lorsque la synchronisation est finie. Lors d'un débuggage, nous avons par ailleurs remarqué que le système client/serveur fonctionnait, mais de manière peu correcte niveau programmation... le client ouvre actuellement des sockets en continu, ce qui n'est évidemment pas ce qu'il faut faire... Nous avons donc décidé de modifier ce système afin d'avoir un programme plus propre...

'''Objectifs pour la semaine 8:''' modifier le système client/serveur pour corriger le problème des sockets.

Robots humanoïdes 2013 groupe II

2014-03-24T20:43:44Z

Cly : /* Avancement du projet */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

====Semaine 6====

Lors de cette semaine, nous avons tout d'abord écrit un programme permettant le système client/serveur entre NAO et PC. Le système client/serveur utilise le protocole TCP, car il est important que les NAO reçoivent les bonnes données au risque de ne plus être synchronisés. Après avoir réalisé ceci, nous avons écrit les algorithmes de synchronisation pour les NAO (clients) et pour le PC (serveur). Nous avons ensuite procédé à l'intégration du système client/serveur dans les algorithmes de synchronisation précédemment écrits. Les tests ont montré qu'il y avait un problème d'algorithme, car le réseau client/serveur fonctionnait correctement:
<blockquote>> comme le serveur lit continuellement les données et que les NAO envoient continuellement leur état, lorsqu’un NAO est prêt, lui seul reçoit la "bonne" variable de retour, alors que l’autre reçoit la variable de retour qui correspond à son état.</blockquote>
Nous avons donc essayé de résoudre ce problème avec un système de sémaphores (quand le premier NAO envoie une donnée d'état, il attend que le second NAO reçoive la donnée retour du serveur avant d'autoriser la réception de son côté):
<blockquote>> le serveur renvoie une erreur, car il ne renvoie pas la réponse au bon client...</blockquote>

'''Objectifs pour la semaine 7:''' résoudre le problème d'algorithme afin de permettre aux deux NAO d'être synchronisés.

Robots humanoïdes 2013 groupe II

2014-03-16T22:30:34Z

Cly : /* Avancement du projet */

==Projet de Coopération Nao N2N: Partie Communication/Réseau==

===Présentation du projet===

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.
 

===Cahier des charges===

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

<blockquote>> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.</blockquote>

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

<blockquote>> Programmation en C++ (a priori) dans les NAO.</blockquote>

===Étapes importantes (prévisionnel)===

# Étude approfondie de la communication NAO vers PC et PC vers NAO;
# Création d'une zone de mémoire partagée;
# Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

===Avancement du projet===

====Semaine 1====

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:
<blockquote>> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;</blockquote>
<blockquote>> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;</blockquote>
<blockquote>> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).</blockquote>

'''Objectifs pour la semaine 2:''' écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

====Semaine 2====

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:
<blockquote>> problèmes liés à la compilation en début de semaine, désormais réglés;</blockquote>
<blockquote>> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);</blockquote>
<blockquote>> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.</blockquote>

'''Objectifs pour la semaine 3:''' réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

====Semaine 3====

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de '''qibuild2'''.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel.
Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

'''Premier test avec qibuild2''': récupération des données de la centrale inertielle du NAO.

<blockquote>> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;</blockquote>

<blockquote>> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de ''qibuild2''.</blockquote>

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC).
Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

'''Objectifs pour la semaine 4:''' déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

====Semaine 4====

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):
<blockquote>> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);</blockquote>
<blockquote>> nous avons alors réalisé la suite d'événements suivants:
<blockquote>> abaissement de la tête du NAO ''(récupération des valeurs liées à l'axe de la tête du NAO)''</blockquote>
<blockquote>> réaction du NAO par la parole ''(après avoir dépassé un certain seuil lors de son mouvement de tête)''</blockquote>
<blockquote>> mouvement quelconque du NAO ''(après l'événement de parole)'' </blockquote></blockquote>

'''Objectifs pour la semaine 5:''' réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

====Semaine 5====

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:
<blockquote>> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;</blockquote>
<blockquote>> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.</blockquote>
Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

'''Objectifs pour la semaine 6:''' intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.

====Bilan de mi-projet====

Au cours de ce projet, nous avons pu dans un premier temps nous familiariser avec l'interface du NAO. Nous nous sommes rapidement orientés vers la programmation C++ des robots afin de comprendre leur architecture et leurs différentes fonctions. Au cours des premières semaines, la mission principale était donc d'apprendre à utiliser un environnement de cross-compilation: ''Qibuild''.
Nous avons donc appris à utiliser des chaînes de compilation (''toolchains'') permettant de créer des exécutables en local afin d'utiliser le NAO à partir de notre PC. Le but du projet résidant dans un programme C++ intégré au NAO, nous nous sommes rapidement intéressés à la cross-compilation. La cross-compilation permet de créer des exécutables compréhensibles par le NAO. Cette compilation permet de compiler le projet ciblé dans un langage que le NAO pourra ensuite exécuter.

Après avoir étudié les exemples fournis par Aldebaran, nous avons pu contrôler le NAO et récupérer certaines informations grâce à des ''NAO Keys'' (arguments de fonctions permettant de récupérer la valeur d'un certain capteur). Nous avons alors modifié ces exemples pour récupérer des données intéressantes liées au NAO (inclinaison de la tête, position de sa centrale inertielle...) et qui permettront plus tard la synchronisation des deux NAO.

Nous avons ensuite tenté d'utiliser les fonctions de reconnaissance audio du bruit et de la parole. Cependant, la reconnaissance du bruit n'est pas utilisable lorsque le NAO ou qu'un autre NAO est en mouvement à proximité car le seuil maximum de détection est atteint trop rapidement. Nous nous sommes donc plus intéressés à la reconnaissance de parole afin de se rendre compte qu'elle est assez fiable pour synchroniser les NAO. En effet, lorsque le NAO 1 parle, le NAO 2 reconnaît avec un indice de confiance de 90% ce qu'il a dit. Nous allons alors baser notre synchronisation sur cette fonction.

Aujourd'hui, nous avons décidé de créer un réseau simple afin de faire communiquer les NAO entre eux. De cette façon, nous allons pouvoir informer l'état de NAO 2 à NAO 1 et vice versa. Lorsque le NAO 1 sera prêt, on attendra que le NAO 2 soit prêt pour commencer à soulever l'objet. En accord avec l'autre groupe de projet, un NAO sera prêt lorsque sa tête sera baissée. Nous savons actuellement récupérer la position de la tête du NAO, ce qui nous facilite alors la tâche.

La partie la plus importante restante est donc la communication réseau des NAO avec notre PC qui fera office de serveur.

Robots humanoïdes 2013 groupe II

2014-03-14T08:40:50Z

Cly : /* Avancement du projet */

Robots humanoïdes 2013 groupe II

2014-03-10T18:46:28Z

Cly : /* Semaine 4 */

Robots humanoïdes 2013 groupe II

2014-03-10T18:45:45Z

Cly : /* Semaine 4 */

Robots humanoïdes 2013 groupe II

2014-03-10T18:41:35Z

Cly : /* Avancement du projet */

Robots humanoïdes 2013 groupe II

2014-02-17T11:10:08Z

Cly : /* Avancement du projet */

Robots humanoïdes 2013 groupe II

2014-02-17T11:09:22Z

Cly : /* Avancement du projet */

Robots humanoïdes 2013 groupe II

2014-02-08T00:04:52Z

Cly :

Robots humanoïdes 2013 groupe II

2014-02-07T23:13:27Z

Cly :

Robots humanoïdes 2013 groupe II

2014-02-07T23:13:08Z

Cly :