Readme.md

Projet Interdisciplinaire ou de Découverte
de la Recherche

Smart City Lights

supervisé par :
CHOLEZ Thibault
&

FESTOR Olivier

réalisé par :
GAUBE Aurélien
&

JACQUET Corentin

4 juin 2018

Table des matières
1 Introduction
2 Étude des besoins

3 État de l’art

3.1 Composants possibles
3.2 Technologies sans-fil possibles

3.2.1 Portée et consommation

3.2.2 Autres critères

3.2.3 Solution retenue

4 Mise en œuvre
4.1 Architecture générale de Smart-City Lights

4.2 Architecture matérielle du contrôle-projecteur

4.3 Micro-code développé

4.3.1 SKY-mote twizy

4.3.2 SKY-mote Lampadaire

4.4 Tests

4.5 Difficultés rencontrées

5 Conclusion
Glossaire
1 Introduction
Ce rapport s’inscrit dans le cadre du Projet Interdisciplinaire ou de Découverte de la Recherche
(PIDR) de notre formation à Télécom Nancy. Il vise à nous faire réfléchir sur un sujet très précis et

limité dans le cadre du thème étudié. Notre projet Smart City Lights a pour thème la ville intelligente

et plus précisément la gestion intelligente de l’éclairage public sur les parkings. Dans ce contexte, nous

devons concevoir et réaliser une infrastructure de lampadaires intelligents pour le parking du site de

Remicourt. Ceux-ci doivent s’allumer dynamiquement lorsque le parking est parcouru par un véhicule,

dans notre projet, incarné par la Twizy de Télécom Nancy. L’installation devra être autonome et pos-

siblement extensible à de nouveaux éléments voire à d’autres contextes.

La problématique de la ville intelligente est une problématique clé de la ville du futur. En effet, l’en-

jeu est à la fois de réduire la consommation globale d’énergie, notamment en éteignant les éclairages

publique, sans pour autant augmenté l’insécurité lié à l’absence de lumière. La gestion des éclairages est

un enjeu majeur de la lutte contre le réchauffement climatique car la quasi totalité des villes utilisent un

éclairage publique et l’utilisation d’éclairages intelligents permet de réduire de 70% la consommation

électrique pour l’éclairage publique d’une ville. L’utilisation de luminaires intelligents pourrait

donc aider à résoudre une problématique énergétique mondiale et ainsi améliorer le futur de l’humanité.

Mais pour atteindre cet objectif, il faut garantir aux villes un éclairage autonome peu consommateur,

fiable quel que soit les circonstances, et qui s’adapte efficacement à la présence humaine dans sa zone

de contrôle.

La suite du rapport détaille l’étude des besoins dans le chapitre 2, puis l’état de l’art des technologies

possibles dans le chapitre 3. La solution technique que nous avons retenue et sa mise en oeuvre pour

répondre à la problématique sont décrites dans le chapitre 4. Nous nous sommes particulièrement at-

taché à la réalisation technique et notamment informatique, mais il ne faut pas perdre de vue l’aspect

économique et écologique, notamment dans le choix des équipements.

2 Étude des besoins
Notre cas d’étude est le parking de l’école. Celui-ci comporte un certain nombre de lampadaires
classiques qui s’allument selon l’horaire de la journée. Ils seront dans le cadre de ce projet complétés

par des projecteurs à LEDs qui interagirons avec le passage d’un véhicule connecté : la Twizy.

Le besoin exprimé par l’équipe encadrante comporte deux modes d’éclairage :

— Le premier, d’usage courant, qui allume les lampadaires devant le véhicule et éteint ceux derrière

lui.

— Le second, synonyme d’alerte, qui fait clignoter les lampadaires dans un certain périmètre autour

du véhicule ayant déclenché l’alerte.

Le système devra être suffisamment réactif pour être mis en place dans le cadre d’une conduite

de nuit à vitesse modérée. Il devra de plus prendre en compte que plusieurs véhicules peuvent rouler

simultanément sur le réseau. Des délais courts, un dispositif sécurisé et une anticipation dynamique

des déplacements seront des compléments appréciables.

Figure 2.1 – Parking d’expérimentation
Dans le but de réduire le champs de développement, nous avons d’abord concentré nos effort sur

une simulation représentant un déplacement linéaire du véhicule selon un axe parallèle à la rangée

de lampadaires. Ce cadre de recherche restreint nous a notamment permis d’éviter les calculs liés à

l’ordinateur de bord et au GPS de la twizy. Dans un second temps, nous nous sommes appliqués

à permettre l’usage du mode alerte, la présence simultanée de plusieurs véhicules et les trajectoires

complexes.

3 État de l’art
La première étape de notre recherche est la réalisation d’un état de l’art dans le domaine des tech-
nologies de communications sans fil courtes et moyennes portées. Nous avons donc établis une liste des

matériels, technologies et protocoles utilisés pour ce type d’application, et choisi des critères permet-

tant de les comparer.

Nous envisagerons dans un premier temps les composants matériels disponibles, puis nous compare-

rons les différentes technologies sans fil. Nous étudierons ensuite les différents protocoles réseaux qui

répondront à nos besoins. Nous conclurons alors sur la solution que nous aurons choisie.

3.1 Composants possibles
Il existe actuellement une grande variété de composants matériels permettant de faire communiquer
des objets, dont une grande partie est expérimental et donc non disponible à l’achat. Les deux princi-

paux actuellement disponible sur le marché sont les Raspberry Pi et les Arduino, tous deux existants

en de multiple version et variantes, et possédant des modules d’extensions très divers. Il existe d’autres

types de cartes, moins orientées vers le tous public, et souvent développer dans le cadre de recherche

par des université. Une des plus courante est la TelosB aussi connu sous le nom de carte SKY-mote,

terme que nous emploierons dans ce rapport. Il est possible de rajouter des modules sur ces cartes,

dans le but de les rendre réceptives à leur environnement (capteurs luminosité, ...) ou d’augmenter

leurs capacités existantes (antennes, batteries, ...). Dans le cadre de cet état de l’art, nous n’essayerons

pas de comparer toutes les configurations, et nous contenterons des caractéristiques générales, car les

modules coûtent souvent plus cher que la carte sur laquelle ils se fixent.

Nous avons donc restreint ce comparatif aux trois modèles les plus courant et avons essayé de les

comparer en fonction de leur autonomie, puissance, coût, fréquences et protocoles supportés mais aussi

de leur disponibilité à l’école. Il s’est avérer très compliqué d’obtenir des informations précises, en de-

hors du coût et de la fréquence, car d’une part, l’autonomie dépends quasi-exclusivement de la source

d’alimentation et il est donc plus logique de dimensionner correctement la batterie utilisé que de choisir

sur cette valeur, d’autre part, les protocoles supportés dépendent uniquement du software déployé, et

cette valeur ne permet donc pas de choisir entre les matériels.

Les figures suivantes (3.1, 3.2 et 3.3) illustrent ces composants matériels et le tableau 3.1 leurs prin-

cipales caractéristiques.

Figure 3.1 – Raspberry 3
Figure 3.2 – Arduino
Figure 3.3 – SKY-mote
Technologie

Rasberry Pi 3

Arduino

Telos-B (SKY-Mote) 8MHz

Cadence

1200Mhz 6.2 Gflops 40 e * Toutes*
16Mhz 0.1 Mflops 20 e * Toutes*
80 e ** 2,4GHz
?

Puissance

Coûts Fréquences Protocoles Supportés

Tous

Tous

Tous

*Selon modules d’extensions **Telecom Nancy possède déjà des Telos-B

Table 3.1 – Composants matériels possibles
Ce tableau montre bien la différence de puissance entre les Raspberry Pi 3, qui sont de véritables

ordinateurs, et les TelosB SKY-Mote, qui sont des puces connectés. Si le choix se limitait aux caractéris-

tiques décrites ici, le choix se porterait probablement sur les Raspberry Pi 3 qui sont les plus puissants,

mais il faut aussi pensez à la consommation horaire, et bien sur au coût, car l’école possède déjà les

SKY-Mote nécessaire. En outre, la fréquence utilisé n’est pas primordiale, tant qu’elle n’interfère pas

avec les équipements traditionnelles déjà présent, tels que le réseau wifi.

Ces informations, ont portée notre choix vers les TelosB SKY-Mote développé par l’université de

Berkeley.

3.2 Technologies sans-fil possibles
3.2.1 Portée et consommation
Conjointement avec le choix du matériel, il est nécessaire d’identifier la technologie qui répond le
mieux à nos besoins. Nous nous sommes restreints aux technologies sans fil, car une installation filaire

n’est pas envisageable sans travaux importants. De plus, nous avons classés les technologies en fonction

de leur portée, en éliminant directement les technologies aux portées trop faibles (Bluetooth, NFC, ...)

et celles aux portées trop longues pour notre utilisation, car celles-ci ne permettent pas une communi-

cation suffisamment précise ou sont alors trop énergivores.

La figure 3.4 permet d’observer les principales technologies sans fils, d’après leur porté et leur débit,

on y constate notamment le faible recouvrement des technologies, chacune ayant son usage propre et

ses caractéristiques uniques.

Le tableau 3.2 synthétise les principales caractéristiques des protocoles sans fil en terme de consom-

mation et de portée. Il en ressort que les technologies qui correspondent le plus à la topologie de notre

milieu d’étude sont le Wifi et le 802.15.4, car ils ont tous les deux une portée d’environ 100m en terrain

ouvert. La technologie LORA est quand à elle possible, mais pourrait donner lieu à des imprécisions. Le

Bluetooth pourrait être utiliser, si les lampadaires communiquent entre eux pour diffuser l’information

de l’arrivée d’un véhicule.

On peut aussi constater que les consommations électriques de ces technologies sont loin d’être toutes

équivalentes, avec de fortes variations d’échelles puisqu’on passe de 1550mW à 36.9mW en transmis-

sion entre le Wifi et le 802.15.4. La différence lorsque les antennes sont au repos est encore plus forte,

avec une consommation de 0.06µW pour le 802.15.4 et une de 6mW pour le LORA, soit 100 000 fois plus.

A la lumière de ce comparatif, il a été choisi de mettre en place le protocole 802.15.4, qui répond à

la fois à nos exigences de portée et de faible consommation.

Technologie

Wifi

Bluetooth

802.15.4

LORA

Portée Conso. Transmission Conso. endormi

100m

10m

100m

5km

1550mW

215mW

36.9mW

400mW

6600µW

330µW

0.06µW

6mW

Table 3.2 – Comparatif des différentes technologies sans fi
Figure 3.4 – Comparatif débit/portée des différentes technologies sans fil
3.2.2 Autres critères
Outre les considérations de portée et de consommation, les technologies sans-fil et les protocoles
associés présentent d’autres caractéristiques importantes pour notre problématique. Nous avons donc

comparé les différents protocoles qui semblaient répondre le mieux aux besoins, nous avons souhaité

comparer leur difficulté d’implantation, leur sécurité, leur débit et leur topologie possible. La difficulté

d’implémentation est une notion très subjective, qu’il est difficile d’évaluer et nous ne l’avons pas gar-

der comme critère. Les critères restant sont résumé dans le tableau 3.3.

Protocole

Wifi

Bluetooth

802.15.4(ZigBee)

802.15.4(6LoWPAN)

LORA

Sécurité

Débit Topologie

Sécurisé(AES)

Selon Mode utilisé

54MB/s étoile, arbre, maillé

2MB/s étoile

Selon implémentation 200kB/s étoile, arbre, maillé

250kB/s étoile, arbre, maillé

30kB/s étoile

Sécurisé(AES)

AES128

Table 3.3 – Comparatif des différentes technologies sans-fil
On constate que tous les protocoles offrent une bonne sécurité si on prend la peine de l’implémenter,

les débits varies et le 6LowPAN présente un des plus bas débit à 250kB/s. La topologie varie selon

les protocoles, et la topologie en étoile étant adaptée à notre problématique dans laquelle une voiture

informe n lampadaire autonome de sa position, la topologie ne limite pas notre choix. En choisissant

le 6LowPAN, nous optons donc pour un protocole qui offre un relativement bas débit, mais cela n’est

pas très grave car les volumes de données à transmettre sont extrêmement faible.

3.2.3 Solution retenue
Suite aux différents comparatifs, nous avons choisi d’implémenter la technologie 802.15.4 sur les
cartes SKY-mote avec le protocole 802.15.4 6LowPAN associé. Ce choix tiens d’abord d’un soucis

de correspondance matériel/technologie/protocole, mais aussi des caractéristiques individuelles des

éléments cités tels que présentés dans les paragraphes précédents. Cette technologie de liaisons est

associée à des projecteurs à LEDs qui assurent une forte luminosité avec une faible consommation

électrique, montés sur batterie, tel que cela est décrit par la figure 4.1.

4 Mise en œuvre
4.1 Architecture générale de Smart-City Lights
L’architecture générale est conçue autour de SKY-mote autonomes capables de communiquer entre-
eux en utilisant le protocole 802.15.4 . C’est un réseau décentralisé, où chacun est capable de commu-

niquer avec tout le monde (dans une limite de portée physique) sans dépendre d’un service tiers. La

topologie déployé est un réseau en étoile à partir de chaque voiture, dans laquelle chaque mote émet

et reçoit des messages en broadcast contenant toutes les informations nécessaire sans qu’il y ai besoin

d’initialiser des connexions. Outre la simplicité d’implementation, cette solution offre aussi une faible

consommation de bande passante car très peu de messages sont echangés.

Côté voiture, le SKY-mote embarqué dans la twizy connaît sa position grâce au GPS embarqué dans

la twizy. Ce GPS est relié à un micro ordinateur présent dans la twizy, qui communique les coordonnées

actuelles de la voiture au SKY-mote. Le SKY-mote communique alors cette position en broadcast et le
mode d’éclairage souhaité à toutes les SKY-mote à porté.

Côté lampes, les autres SKY-motes (fixés aux lampadaires) connaissent leur propre position GPS

enregistrée en dur à l’installation car celle-ci est fixe. Quand les motes reçoivent les coordonnées de

la twizy, un calcul de distance est effectué avec la latitude et longitude récupérées et l’éclairage est

déclenché si nécessaire, c’est à dire si la distance entre la voiture et le lampadaire est assez faible. La

durée de l’éclairage est mise à jour à chaque réception de position donnant une distance suffisamment

courte (20mètres dans nos tests), et s’effectue de manière alternative si le mode alerte est enclenché.

Il a été envisagé de réaliser une rediffusion du message de la twizy avec un seul bond afin de per-

mettre aux SKY-motes hors de portée de la twizy de recevoir tout de même sa position, mais cela ne

s’est pas révéler nécessaire, la porté de la technologie 802.15.4 étant largement suffisante pour assurer

de bonne communication directe.

La solution permet une gestion de plusieurs voitures en simultané et la défaillance d’un SKY-mote

n’a pas de répercussion sur le reste de l’environnement, seul le lampadaire concerné cesse de fonction-

ner. De plus il n’y a pas d’interférence entre deux véhicules, chacun envoyant sa position a tous ceux

qui le reçoivent et si les deux véhicules sont proches, le lampadaire qui reçoit les deux décide juste de

s’allumer quand il y est déjà, sans que cela perturbe le fonctionnement globale du système.

4.2 Architecture matérielle du contrôle-projecteur
Le principe est d’utiliser un SKY-mote autonome, qui décide d’allumer ou d’éteindre son projecteur
selon ce qu’il reçoit sur son antenne 802.15.4. Il reçoit des messages contenant toutes les données né-

cessaires directement de la voiture. Il calcule la distance qui le sépare de la voiture et la compare à un

seuil fixé d’avance. Si la distance est inférieur au seuil, le SKY-mote décide d’allumer son projecteur à

LED, et agit pour cela sur un relais électro-magnétique tel que présenté sur la figure 4.1

Des projecteurs LED seront mis en place sur chaque lampadaire sur le parking, couplés à des SKY-

mote selon le schéma de la figure 4.1 (le mote est représenté par son port d’extension :

La solution proposée n’a malheureusement pas pu être testée physiquement car les projecteurs n’ont

pas été reçus dans les temps. Nous avons donc réalisé une simulation Cooja permettant

Figure 4.1 – Schéma du couplage SKY-mote / projecteur
de faire la démonstration du code développé. Nous avons aussi essayer de réaliser une mise en oeuvre

d’usage des ports d’extension, pour prouver la faisabilité du couplage SKY-mote/projecteur LED, mais

cela n’a pas pu être réalisé avec ContikiOS. Des essais prometteurs mais non concluant ont

pu être réalisé avec TinyOS. En attendant la réalisation d’un code fonctionnel, le reste

du système à été développer en utilisant les LEDs intégrés aux SKY-Mote.

D’un point de vue hardware, lorsque la décision d’allumer le lampadaire est prise, le SKY-mote envoie

une impulsion électrique dans une pin de son port d’extension. Celui-ci est relié électriquement à un

relais électronique bistable contrôlant le circuit de puissance du projecteur à LED. Ce relais

permet de séparer l’électronique de contrôle, constitué du SKY-mote de l’électronique de puissance

qui alimente le projecteur à LED. Son fonctionnement bistable permet de ne consommer de l’énergie

pour la commande que lors du changement de commande. Le circuit de puissance est constitué d’une

batterie, dans notre cas un power-pack qui alimente le projecteur à LED, un interrupteur classique
permet à un utilisateur de couper manuellement le projecteur, pour d’éventuelles maintenances, tandis

que le relais électronique agit comme un interrupteur à commande numérique.

4.3 Micro-code développé
Pour réaliser l’architecture envisagée, nous avons écrit deux programmes en C pouvant s’exécuter
sur les SKY-mote, chacun de ces codes est ensuite adapté pour y inscrire soit pour les voitures, le trajet

du mote (en l’absence de connection à un GPS embarqué dans la twizy) soit pour les lampadaire, la

position GPS à laquelle le mote sera fixé.

4.3.1 SKY-mote twizy
Ce programme a pour but de permettre au SKY-mote connecté à la twizy de pouvoir communiquer
les coordonnées GPS de celle-ci aux autres SKY-motes en utilisant le protocole 802.15.4 .

Les tests sur le Parking ne pouvant être réalisés faute de matériel, la liaison entre le module GPS de

la twizy et la SKY-mote n’a pas été implémentée. Cela pourra être réalisé via la connexion USB des

SKY-mote, qui peux être branché directement sur la carte DFRobot servant d’ordinateur de bord à la

twizy. Cette carte connaît la position GPS de la twizy grâce à un GPS Garmin 18x lvc.

Nous nous contentons ici d’enregistrer dans notre programme une coordonnée GPS à émettre, que l’on

peut faire varier dynamiquement pour les simulations. La version actuelle simule numériquement la

traversée du parking dans la longueur.

L’envoi se fait sous la forme d’une chaîne de caractère concaténant la latitude, la longitude et un

flag de valeur 1 si le mode alerte est actif. Les 6 premiers caractères correspondent aux 6 premiers

décimaux de degré de la latitude, suivis des 6 premiers décimaux de degré de la longitude et enfin un

1 ou un 0 pour le flag d’alerte.

4.3.2 SKY-mote Lampadaire
Ce programme est exécuté sur chaque SKY-mote de lampadaire et permet d’enclencher l’éclairage
de ceux-ci si la twizy est à portée. La latitude et la longitude de l’emplacement du lampadaire sont

enregistrées directement dans deux variables afin de réaliser un calcul de distance par approximation

linéaire. Les SKY-motes fonctionnant en 16 bits empêchant l’utilisation des bibliothèques mathéma-

tiques usuelles, il a été nécessaire de coder une fonction racine carrée, ce qui a été réalisé via l’algorithme

d’approximation de Newton. Cela a de plus l’avantage de réduire la somme des calculs réalisés par la

carte, ce qui réduit sa consommation et accélère son fonctionnement.

La SKY-mote est capable de recevoir le broadcast envoyé par le SKY-mote de la twizy sous
forme de chaîne de caractères. Nous la décodons pour récupérer la latitude et longitude de la twizy

ainsi que le flag correspondant au mode d’affichage. Le programme calcule la distance par rapport à

ses propres coordonnées et si la twizy est à moins de 20 mètres, l’éclairage de la LED est enclenché

pour 5 secondes. Si le mode alerte est activé via le flag dédié, l’éclairage s’effectuera de manière à

clignoter à une fréquence d’une demie-seconde. En mode classique, la durée d’éclairage est remise à 5

secondes à chaque nouvelle réception de position en dessous de 20 mètres. Il est également envisagé

que la SKY-mote rediffuse en broadcast les coordonnées de la twizy pour transmettre l’information aux
autres lampadaires hors de portée du message de la twizy. Ce renvoi en broadcast semble cependant
superflu au vu de la faible taille des installations (parking) et de la portée des antennes utilisées ( 125m).

4.4 Tests
Les tests ont été réalisés avec le simulateur Cooja permettant de visualiser les différentes
SKY-motes ainsi que leurs portées d’émission. L’environnement du parking a été reproduit en plaçant

les SKY-mote représentant les lampadaires dans la même configuration que le parking de Télécom

Nancy.

Figure 4.2 – Schéma d’une simulation avec déplacement linéaire
Le déplacement de la twizy sur le parking a été simulé en faisant varier la position GPS émise par

la SKY-mote représentant la twizy. Le Mote représentant la twizy bougeant lui aussi de manière ap-

proximative grâce à l’extension Mobility de Cooja. Sur la figure 4.2, on constate que les

motes hors de portée sont inactifs, ceux qui sont à portée, mais en dehors du cercle de 20 mètres

reçoivent mais restent éteint, tandis que les autres qui sont à portée et en dessous de 20 mètres sont

allumés.

D’autres tests ont été réalisé avec deux véhicules comme sur la figure 4.3. On y a constater les inter-

actions lorsque les deux véhicules sont à portée des mêmes lampadaires. On commence à y apercevoir

la limite des tests sur Cooja, la synchronisation entre des déplacements GPS et la position des voitures

dans la simulation est difficile à mettre en place. Néanmoins on prouve que notre système peut gérer

plusieurs voitures en même temps.

Figure 4.3 – Schéma d’une simulation impliquant deux voitures
Nous avons réussi à réaliser 3 scénarios différents, celui d’une voiture avançant sur le parking, celui

d’une voiture avançant puis qui s’arrête pour déclencher le mode alerte, et enfin celui de deux voitures

circulant sur le parking. Les résultats sont satisfaisants, d’après ces simulations, il n’est pas nécessaire

de réaliser des retransmissions aux autres SKY-motes aux alentours pour augmenter la portée de

l’information. Nos simulations se déroulant dans l’environnement du Parking de Télécom Nancy, ceux-

ci nous invitent pour une prochaine étape à les réaliser en version grandeur nature directement sur

le parking pour vérifier le bon fonctionnement en condition réel, et être plus maniable quand aux

mouvements de la twizy pour des tests plus approfondis.

4.5 Difficultés rencontrées
La prise de connaissance des technologies utilisées –SKY-mote, Contiki , Cooja et 802.15.4–
a nécessité la lecture de documentations longues, complexes et souvent incomplètes car axées sur des

outils ou des situations très spécifiques. La mise en place de circuit électriques utilisant les ports d’ex-

tension des SKY-motes étant peu répandue, il a été très compliqué de trouver des exemples concernant

leur utilisation.

La présence concurrentiel de contikiOS et TinyOS à elle aussi perturbé nos recherches car

tous les exemples utilisés pour TinyOS sont rédigé en NesC, qui est un dialecte du C non compatible

avec Contiki. Il a parfois été nécessaire d’effectuer un travail de traduction entre les languages pour

obtenir des résultats.

Nous avons aussi fait face à la limitation de puissance des SKY-motes en terme d’espace de sto-

ckage, mais surtout en terme de longueur des registres de calcul, puisque le fonctionnement 16 bits

des processeurs MSP430 des SKY-mote les empêche d’utiliser la majeure partie des bibliothèques C

standard. Nous avons dû adapter notre programme avec une implémentation spécifique du calcul de

distance, la reprogrammation de la fonction racine carré en utilisant le principe de Newton ou encore

des adaptations au niveau du type de données utilisées, toujours dans le but de rester sur les cases de

16bits de l’architecture CPU utilisé.

5 Conclusion
Ce PIDR s’est inscrit dans la problématique de la ville intelligente, avec pour objectif de rendre
dynamique et interactif les éclairages publique, notamment par le biais d’une voiture connecté : la

twizy.

Ce Projet Interdisciplinaire ou de Découverte de la Recherche à été enrichissant sur le plan du déve-

loppement de logiciel proche des couches réseaux et proche du matériel. Il nous a permis de comprendre

l’envoi de message dans un réseau décentralisé de capteurs autonomes. Nous avons réussi à déployer sur

simulateur une série d’algorithme interagissant entre eux via la technologie sans fil 802.15.4, et avons en

cela établis la preuve du concept utilisé. Nous avons constaté avec plaisir que nos algorithmes simples

donnaient de bon résultats pour suivre en éclairage une voiture avançant lentement sur un parking. La

non-réception du matériel nous a contraint à adapter notre méthode de travail, notamment en réalisant

plus de tests sur l’environnement Cooja et il a par conséquent été décevant de ne pas pouvoir le mettre

en place physiquement.

Nous n’avons pas réussi à atteindre tous les objectifs, mais le développement global est bien avancés,

avec de bonne simulations. Il reste principalement à finaliser l’interaction entre les Pins d’extensions

GPIO et les projecteurs, ce qui demande de réaliser des tests avec du matériel réel.

De manière général, plusieurs poursuites et améliorations du projet peuvent être envisagées :

— Prendre en compte la vitesse de la voiture pour optimiser l’éclairage, notamment en amont de la

trajectoire.

— Établir la connexion entre la twizy et la SKY-mote pour accéder aux données de bord de la twizy.

— Relier effectivement les SKY-mote aux projecteurs (quand ils seront reçus) pour déclencher un

éclairage au lieu d’allumer une LED.

Ces trois points sont accompagnés d’une dernière tâche qui consistera à régler finement les temps

d’allumage, les fréquences de clignotement, les portées seuils pour l’allumage, ... pour optimiser la

consommation électrique finale de l’installation, et atteindre ainsi l’objectif d’économie d’énergie à

l’origine du projet.

Glossaire
Projet Interdisciplinaire ou de Découverte de la Recherche Projet obligatoire d’initiation à la re-
cherche active au sein d’une équipe ou d’un laboratoire visant à mettre en place une solution

pertinente à un problème précis.

Smart City Une ville intelligente – de l’anglais «Smart City» – est une zone urbaine intégrant les
technologies de l’information et de la communication, et des dispositifs connectés au réseau dans

le but d’optimiser ses services urbains.

Telos B SKY-Mote Carte programmable développée par l’université de Berkeley, elle permet no-
tamment la mise en place de réseau de capteurs autonomes relié en 802.15.4. Ces cartes parfois

abrégé Mote sont de plus en plus utilisé pour mettre en place des objets et structures connectées

dites intelligentes.

Twizy La Renault Twizy est une petite voiture électrique orientée sur l’écomobilité. Celle de l’école
dispose d’équipements supplémentaires pour la rendre interactive avec son environnement.

Bibliographie
.