Version du 27 septembre 2018 à 16:27

Présentation générale

Description

La recherche de places de parking est une tâche fastidieuse, consommatrice de temps et polluante.

Objectifs

Pour remédier à ce problème, nous proposons de réaliser un ensemble composé :

• D'un capteur de détection de voiture :
• D'un système de transmission basé sur une carte "maison" (µC : CC430) déjà existante ;
• D'un système de stockage et de visualisation des places libres.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

Calendrier prévisionnel

Réalisation du Projet

Semaine du 17/09

En attendant un entretien avec les encadrants de projet pour mettre au point un cahier des charges précis, plusieurs recherches bibliographiques ont été effectuées.

Plusieurs solutions existent déjà pour effectuer la détection de voitures dans un parking, axées autours de trois méthodes :

• Détection avec un capteur par place
• Détection avec des capteurs en entrée et en sortie de parking
• Détection par caméra

Chaque solution présente des avantages et des inconvénients, qu'il faudra analyser afin de choisir la solution adaptée.

Le solution avec un capteur par place est précise et indique facilement et précisément l'occupation des places. Elle est de plus peu coûteuse en énergie par capteur, la détection ne devant pas être effectuée en permanence. En revanche cette méthode est coûteuse car nécessite un capteur par place, et implique une remontée d'informations complexe à mettre en place (sans fil ou filaire).

La solution avec des capteurs en entrée et en sortie est peu coûteuse et permet une remontée d'informations assez simple (peu de données à transmettre). En revanche elle n'est pas précise et indique seulement le nombre de voitures/places restantes dans le parking et non les places précises restantes. Elle est de plus coûteuse en énergie pour les capteurs, devant être actifs très souvent afin de ne pas manquer une voiture.

La solution par caméra est économe en matériel, une caméra pouvant être suffisante pour un parking entier, et permet de détecter précisément les places restantes. Elle n'est cependant pas pratique pour un parking souterrain, consomme beaucoup d'énergie par capteur et nécessite des capacités de traitement d'images hors de la portée d'un cc430. Elle peut cependant utiliser un serveur pour effectuer les calculs.

Des liens vers les études sont disponibles dans la partie Documentation

L'entretien avec les encadrant à de plus été préparer afin de pouvoir déterminer u cahier des charges précis. Les questions suivantes doivent être abordées :

• Objectifs précis du projet
• Localisation du parking, type de parking
• Durée de vie minimale des capteurs
• Type de détection voulu
• Budget
• Design du boiter du capteur
• Utilisation de RIOT imposée
• Quel type d'affichage
• Alimentation des capteurs
• Utilisation d'un serveur
• Utilisation du protocole RPL

Semaine du 34/09

Suite au rendez-vous du 21/09, les questions suivantes ont été écartées :

• Durée de vie minimale des capteurs
• Type de détection voulu
• Budget
• Design du boitier du capteur
• Quel type d'affichage
• Alimentation des capteurs
• Utilisation d'un serveur

En effets ces questions ne sont pas prioritaires et n'entreront dans l'équations que si le projet avance très vite.

• Objectifs précis du projet

L'objectif principal du projet est de déployer un réseau d'objets sans fils possédant des capacités de routage dynamique.

• Localisation du parking, type de parking

Le parking d'étude sera le parking de l'IRCICA, mais des essais en condition réel seront intéressant mais ne sont pas une priorité

• Utilisation du protocole RPL

Le routage dynamique devra préférentiellement être mis en place en respectant le protocole RPL

• Utilisation de RIOT imposée

RIOT OS n'est en aucun cas imposé, et l'utilisation d'un autre OS (Contiki a été évoqué) est parfaitement envisageable, voir même tenter une appproche sans OS.

Ayant déjà travaillé avec RIOTOS et le CC430, je sais qu'il peut y avoir des problème concernant la taille et l'occupation en RAM des OS. Ma première mission est donc de déterminer si le CC430 et ses 32ko de ROM et 4ko de RAM permettent l'utilisation des implémentations du protocoles RPL des différents OS de l'embarqués, ou si d'autres options plus simple (routage statique voir simple broadcast) sont à privilégier.

Documentation

Documents Rendus