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. (à compléter)

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 :

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

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

Rendus

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