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
.