P59 Assistance globale pour aide au parking : Différence entre versions
(→Présentation du projet) |
(→Avancement du projet) |
||
| Ligne 38 : | Ligne 38 : | ||
'''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables. | '''Objectifs de la semaine suivante:''' Continuer les recherches et potentiellement, commencer à choisir quelques solutions techniques réalisables. | ||
| + | |||
===Semaine 2=== | ===Semaine 2=== | ||
| Ligne 44 : | Ligne 45 : | ||
'''Objectifs de la semaine suivante:''' Définir une solution technique (avec schéma) qui pourrait répondre à notre problème. | '''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. | ||
Version du 31 octobre 2014 à 11:23
Sommaire
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.
