P59 Assistance globale pour aide au parking

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).

Étapes importantes (prévisionnel)

1. Étude des solutions techniques possibles.
2. Réalisation du réseau de capteurs, avec récupération des données.
3. Étude des services à implémenter à l'application mobile.
4. Réalisation de l'application mobile.
5. 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.

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:

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:

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)

Dans un second, temps, nous ferons des tests en condition réelle:

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 :

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 :

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 :

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 :

Planning prévisionnel revu

	Partie Applicative (PA)	Partie Réseau de Capteurs (PRC)	Partie Commune
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).
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.
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.
Du 16/02 au 18/02			Réaliser la communication entre le réseau de capteurs et le serveur (la base de données).
Le 19/02			Réaliser des tests sur la globalité du projet.
Le 20/02			Présenter les résultats; Réaliser une démonstration.
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 :

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 :

• 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

• 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

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: Finition de la rédaction du rapport, réalisation de la vidéo, préparation du support de soutenance et la préparer.

Rendus

• Rapport intermédiaire de projet : Fichier:Rapport projet intermediaire GERIER LY.pdf