P7 Régulation temps réel sur réseau sans fil
Sommaire
Régulation temps réel sur réseau sans fil
Présentation du projet
Les réseaux temps-réels réclament l'acheminement en temps contrôlé des données avec un grand niveau de confiance. L'utilisation de réseaux sans fil pose donc un grand problème dû à la difficulté d'être sur de la délivrance des données dans un temps borné.
Liste des tâches
Le projet consistera en :
- Recherche bibliographique sur les réseaux sans fils temps-réel,
- Implémentation d’un protocole de communication avec des notions temps-réel, soit à partir de la littérature (si possible), soit développé par nos soins.
Les différents algorithmes seront développés sur cartes de développement STM32F4 avec un lien radio de type Zigbee, La délivrance de l’information par lien radio étant sujette à risque, éventuellement modification de l’algorithme de commande pour résister à une perte plus ou moins sévère d’information en provenance des capteurs.
Planning prévisionnel
| Tâche | Date | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 | 2017 | ||||||||||||||||||||||||
| 19/09 | 26/09 | 03/10 | 10/10 | 17/10 | 24/10 | 31/10 | 07/11 | 14/11 | 21/11 | 28/11 | 05/12 | 12/12 | 19/12 | 26/12 | 02/01 | 09/01 | 16/01 | 23/01 | 30/01 | 06/02 | 13/02 | 20/02 | |||
| Recherche bibliographique sur les réseaux sans fils temps-réel | |||||||||||||||||||||||||
| Définition des problématiques et d'une application | |||||||||||||||||||||||||
| Recherches sur Riot, Contiki, RPL | |||||||||||||||||||||||||
| Choix de l'OS et implémentation sur les cartes STM32F4 | |||||||||||||||||||||||||
| 1er test : discussion entre 3 nœuds sans notions de temps-réel | |||||||||||||||||||||||||
| 2eme test : ajout d'un nœud pour ajouter une contrainte de routage (statique) | |||||||||||||||||||||||||
| Ajout des contraintes temps-réel (deadlines, priorités...) sans prendre en compte les fautes de transmission | |||||||||||||||||||||||||
| Prise en compte des fautes de transmission | |||||||||||||||||||||||||
Avancement du projet
Recherche bibliographique
La première phase de notre projet consiste à réaliser des recherches bibliographiques sur les réseaux sans fils temps-réel. Pour partager les résultats de ces recherches, nous avons choisi d'utiliser Google Drive : ainsi, nous pouvons à tout moment consulter les documents déjà trouvés sur internet, en déposer de nouveaux, et partager tout cela avec nos tuteurs école.Le but de ces recherches est, notamment, de répondre aux questions suivantes : - Existent-ils des réseaux sans fils temps-réel ? - Si oui, lesquels ? Quelles sont leurs limites ? Comment fonctionnent-ils ? - Si non, quelles sont les difficultés connues et que l'on peut rencontrer lorsqu'on souhaite mettre en place un tel réseau ?
Malheureusement, nous n'avons pas eu beaucoup de résultats, que ce soit sur Internet ou encore à la bibliothèque universitaire. Ceci est simplement du au fait que peu, voire aucun, travaux n'a été effectué sur ce sujet. Est-ce parce que les technologies actuellement existantes ne le permettent pas ou parce que l'apport d'une solution à ce problème n'apporte pas grand chose technologiquement parlant ? Le travail que nous réaliserons lors de ce projet permettra peut-être de répondre à cette question.
Suite à cela, nous avons décider de nous réunir avec nos tuteurs pour discuter un peu de ce sujet, puisque tout cela nous semblait un peu "vague".
Première réunion (05/10/2016)
Nous avons donc eu une première réunion avec Alexandre Boé (Thomas Vantroys n'étant pas disponible pour le créneau fixé). Nous lui avons présenté nos recherches et lui avons exposé nos difficultés à avoir des résultats, ce qui ne l'a pas surpris vu le sujet. Nous avons notamment discuté de la démarche à adopter sur ce projet : le but n'est pas de fournir un livrable fonctionnel à tout prix, mais plutôt de préciser le sujet, de tenter de traiter les problématiques une à une afin que notre travail puisse être repris par une autre personne à la fin du projet.
L'accent a également été porté sur l'aspect "gestion de projet", là encore pour que notre travail soit le plus clair possible. Il a ainsi été convenu qu'une réunion bimensuelle serait prévue afin de faire le point sur notre avancement. A la fin de chaque réunion, un compte-rendu sera établi. Ce dernier sera publié sur le Google Drive commun ainsi que sur le wiki.
Du 05/10 au 12/10/2016
Suite à cette première réunion, nous avons repris l'ensemble des documents que nous avions trouvés lors de nos recherches pour en lister les principales problématiques qu'il serait intéressant de traiter pendant ce projet. Trois problématiques ressortent de ces documents : - le routage : mettre en place un routage "complexe" : non-linéaire et dynamique - le type de temps-réel : doit-on mettre en place un temps-réel dur ? - Que faire en mode dégradé ? (cette question est liée à la problématique précédente)
D'autres questions pourraient être intéressantes à traiter comme la sécurité et la gestion de l'énergie. Toutefois, nous décidons de ne pas prendre en compte ces problématiques pour notre projet.
Nous avons également réfléchi à une application possible, assez simple : le but étant que celle-ci soit la vitrine de notre travail. Elle consisterait à allumer une lampe lorsqu'une personne est détecter dans la pièce.
Enfin, nous avons établi un premier calendrier prévisionnel que l'on peut retrouver plus haut dans cette page.
Jusqu'ici, nous avons travaillé ensemble, sans se répartir les tâches. En effet, il a fallu se mettre d'accord sur l'application, sur le calendrier pour pouvoir ensuite répartir les tâches et avancer efficacement.
Du 13/10 au 19/10/2016
Lors de la première réunion, nous avons décidé d'orienter nos recherches principalement sur deux systèmes d'exploitation : Contiki et Riot. Ce sont tous deux des OS très légers avec une faible empreinte mémoire. Ils présentent beaucoup de points communs, mais Contiki n'offre pas de support temps-réel. Nous avons également fait des recherches sur FreeRTOS, car cet OS temps-réel est proposé par l'aide au développememnt STM32CubeMX. Il est très simpliste, nous pourrons donc l'utiliser assez facilement, mais cela peut être un inconvénient : il ne convient peut-être pas à notre projet.
Le choix de l'OS sera discuté lors de la 2ème réunion avec nos encadrants.
Deuxième réunion (19/10/2016)
Lors de cette réunion, trois points ont été abordés : - Application choisie - Passage en revue du calendrier prévisionnel - Présentation des recherches et choix de l'OS
Après discussion, l'application a été jugée trop simpliste. Nous l'avons donc changer pour prendre celle-ci : commander un robot en ligne droite. Il y aura donc une notion de régulation et un vrai problème en cas de dégradation de la transmission des données (il devra continuer à avancer en ligne droite même s'il ne reçoit plus les ordres).
Comme nous le pensions, nous ne pourrons pas utiliser FreeRTOS, car il ne correspond pas à ce que l'on a besoin pour mener à terme ce projet. Nous avons donc opter l'OS Riot qui implémente le protocole RPL (protocole de routage particulièrement adapté aux réseaux de capteurs). Il nous faudra donc effectuer le portage radio : pour cela, nous choisissons de développer une carte électronique au lieu de modifier le driver d'une carte déjà existante (solution plus rapide à priori).
Enfin, notre calendrier prévisionnel a été jugé trop linéaire. En effet, nos tâches se suivent en cascade, alors qu'il faudrait réaliser plusieurs tâches en même temps afin d'être plus efficace. Nous ajouterons également un échelon supplémentaire à la première version de ce calendrier : la communication entre deux nœuds.
Matériel
Du 20/10 au 26/10/2016
Nous avons du commander très rapidement les composants nécessaires à la conception de notre carte électronique, la date limite de dépôt des bons de commandes étant normalement dépassée. En entendant la réception de ces composants, nous avons décidé de nous répartir les prochaines tâches afin d'être plus efficace. L'un d'entre nous avait alors pour mission de réaliser le routage de la carte, tandis que l'autre s'intéressait plus en détails au code source de RIOT OS en étudiant, par exemple, les exemples fournis avec le code et en tentant de trouver les informations qui nous seront utiles dans les nombreux fichiers de RIOT (comme par exemple le code source du protocole de routage dont nous aurons besoin par la suite). Pour prendre en main RIOT, nous avons décider de réaliser le programme qui permet de faire le classique "Hello World" : le but étant ici d'allumer une LED. Ce programme a été très simple à réaliser grâce aux fonctions que propose RIOT. Ensuite, nous avons décidé d'ajouter une étape supplémentaire : faire clignoter une LED à l'aide d'un timer pour que nous apprenions à nous servir de ce dernier (cela pourrait être utile pour la suite du projet).
Réalisation du module RF
Afin de permettre la liaison sans fils de nos nœuds, nous sommes amenés à utiliser des modules de communication sans fils. Maintenant que nous avons déterminé le micro kernel (Riot-OS) que nous souhaitions intégrer sur notre microcontrôleur, il nous a été conseillé de choisir un module compatible (C’est-à-dire que que le driver de la puce gérant la radiofréquence doit être intégré).Lors de la réunion, après une rapide études des différentes puces gérées, nous avons choisi l’AT86RF231 car il présentait, dans sa datasheet, un schematic simple et une BOM pour la réalisation du module radio.
Réalisation du schematic sous Eagle
Pour la réalisation de cette carte, nous avons commencé par dessiner, sur Eagle, les différents packages nécessaires. Une fois cela réalisé, nous avons constaté une erreur dans notre commande. Il s’agissait de l’oscillateur à 16 Mhz qui ne correspondait pas et dont l’utilisation était différente. C’est une erreur connue mais que l’on devra corriger. Malgré cela, le schematic a pu être réalisé en intégrant un package d’oscillateur commun. Ensuite, concernant les entrées/sorties numériques de la carte, nous avons respecté le schéma ci-dessus et avons ajouté une entrée d’alimentation 3,3V et la masse.
Du 02/11 au 09/11/2016
Réalisation du routage
La réalisation du routage est la partie la plus technique pour cette carte. Le tramsmetteur radio AT86RF231 envoie les données modulées via les pins RFP et RFN. La bande utilisée pour les liaisons Zigbee est à 2,45 GHz ce qui correspond aux hyperfréquences. C’est pourquoi le bloc ci-dessous, constitué d'une antenne, d'un balun et de deux condensateurs, doit être étudié et dimensionné.
Pour cela rappelons quelques éléments de bases nécessaires à notre étude :
*L’impédance d’entrée Ze d’un quadripôle est l’impédance équivalente qui, mise au borne d’un générateur, donne la même intensité et la même
tension.
*L’impédance de sortie Zs d’un quadripôle est l’impédance en série d’un générateur vu par la une résistance Ru en sortie.
*Le principe fondamental de l’adaptation d’impédance est le suivant : en connectant sur une charge de résistance R, une ligne de transmission
d'impédance caractéristique R, on retrouvera à l'autre extrémité de la ligne la même résistance R. Autrement dit, la source et la charge de
résistance R seront « adaptées » si la ligne qui les relie possède une impédance caractéristique de même valeur. L'adaptation sera conservée
quelle que soit la longueur de la ligne.
*L’impédance caractéristique est la résistance vue par le générateur aux premiers instants de la transmission. Elle dépend uniquement des
caractéristiques de la ligne.
*Le coefficient de réflexion est un nombre sans dimensions qui indique la quantité d'énergie réfléchie en bout ou en début de ligne. Il est
défini par une équation qui met en jeu l'impédance caractéristique de la ligne et l'impédance du bout de ligne ou du générateur. Il est
compris entre -1 et +1 et égal à 0 si la ligne est adaptée.
*Les feeders sont les lignes qui alimentent les antennes. Ils doivent véhiculer l'énergie de l'ampli final vers l'antenne dans le cas
d'émission, avec un minimum d'onde réfléchie. Ils doivent donc avoir comme valeur d'impédance caractéristique la valeur de l'impédance de
l'antenne.
L’antenne choisie est une antenne CMS et sera utilisée pour l’émission et la réception. Selon la datasheet, son impédance est de 50 Ohms et il de même pour l’impédance de sortie du balun. Pour adapter ces deux éléments, il nous faut une ligne d’impédance caractéristique 50 Ohms. Pour une ligne microstrip, l'impédance caractéristique dépend de ses dimensions et du matériau isolant. De nombreuse formules sont établies dans la littérature pour calculer cette impédance, nous avons choisi le modèle présent dans logiciel AppCAD.
Pour réaliser cette opération, il nous faut donc l’épaisseur t de la piste, l’épaisseur h du diélectrique ainsi que sa permittivité. A Polytech, il est possible de réaliser des cartes avec des pistes d'épaisseur 35 um avec un diélectrique verre-epoxy FR4 d'épaisseur 0,8 mm. Avec ces informations, nous trouvons une largeur de piste égale à 1,44 mm. Selon la datasheet, il était conseillé d’ajouter un guide d’onde coplanaire constitué de trous afin d'améliorer le transport de l'énergie jusqu'à l'antenne. De plus, l'ajout de vias permet d'atténuer l'effet capacitif des plans de masses situés de part et d'autres du diélectrique. Le rôle du balun est de transformer une impédance symétrique en impédance asymétrique et vice versa. Le balun réalise également une fonction d'adaptation d'impédance entre les ports RFP et RFN et l'antenne. Pour ne pas trop modifier l’impédance différentielle, nous avons décidé de réaliser des pistes de longueur faible et assez large mais surtout des lignes symétriques. Enfin les condensateurs à l'entrées des ports RFP/RFN sont utilisés pour supprimer la composante continue de l'entrée RF provenant de l'antenne.
La demande de réalisation de la carte a été réalisé le 17/11/2016.
Du 09/11 au 16/11/2016
Clignotement de LED grâce aux timers
Comme nous avons pu le dire, nous nous sommes lors de cette semaine sur l'utilisation des timers : le but étant de faire clignoter deux des quatre LED de la carte STM32F4 avec un temps de clignotement différent pour chacune (1 seconde pour la première et 0.5 seconde pour la seconde). Le clignotement se fait donc en mode interruption. Pour plus de clarté, nous avons décidé d'utiliser un timer pour chaque LED (bien qu'il soit possible de n'utiliser qu'un timer). Finalement, le programme est assez simpliste, mais il a fallu un certain temps avant de trouver et de maîtriser les différentes fonctions qui permettent de faire le travail.
PHOTO A VENIR !!!!
Mise en place d'un premier réseau utilisant RPL
N'ayant pas encore finalisé le portage radio (notre carte électronique n'étant pas prête), nous avons décidé de faire un premier test en mode native, c'est-à-dire que nous allons compiler RIOT et le faire tourner sur notre système en temps que processus. Le but de ce test est de mettre en place un réseau virtuel composé de 3 instances RIOT et qui implémente le protocole de routage RPL. Pour ce faire, nous avons utilisé l'exemple "gnrc_networking" fourni par RIOT qui permet, notamment, d'expérimenter la communication entre plusieurs instances RIOT.
Pour utiliser cet exemple, il faut d'abord créer 3 interfaces virtuelles tap (tap0, tap1 et tap2) ainsi qu'un bridge les connectant ensemble (tapbr0) : cela constitue un réseau virtuel que les instances RIOT pourront utiliser pour communiquer. RIOT propose un script qui permet de mettre en place cette configuration. Il suffit donc de taper la commande suivante :
$RIOT_PATH/dist/tools/tapsetup/tapsetup --create 3 (où RIOT_PATH correspond à la racine du dossier RIOT et 3 correspond au nombre d'interfaces souhaité)
Ensuite, nous compilons le code exemple "gnrc_networking" et nous ouvrons 2 autres terminaux (chaque terminal représentera un nœud du réseau). Dans chaque terminal, nous entrons la commande :
make term PORT=tap{0,1,2} (selon le terminal choisi)
Un shell RIOT se lance alors dans les trois terminaux. Il nous faut maintenant initialiser RPL. Nous choisissons le nœud tap0 comme nœud RPL root. Sur ce noeud, la commande ifconfig nous retourne :
ifconfig
Iface 6 HWaddr: 8e:c0:50:34:31:6c
MTU:1500 HL:64 RTR RTR_ADV
Source address length: 6
Link type: wired
inet6 addr: ff02::1/128 scope: local [multicast]
inet6 addr: fe80::8cc0:50ff:fe34:316c/64 scope: local
inet6 addr: ff02::1:ff34:316c/128 scope: local [multicast]
inet6 addr: ff02::2/128 scope: local [multicast]
inet6 addr: ff02::1a/128 scope: local [multicast]
Statistics for Layer 2
RX packets 0 bytes 0
TX packets 2 (Multicast: 2) bytes 142
TX succeeded 2 errors 0
Statistics for IPv6
RX packets 0 bytes 0
TX packets 2 (Multicast: 2) bytes 114
TX succeeded 2 errors 0
Pour ce noeud, nous configurons une adresse IPv6 globale :
> ifconfig 6 add 2001:db8::1 success: added 2001:db8::1/64 to interface 6
Nous pouvons maintenant utiliser la commander suivante dans les trois terminaux afin d'initialiser RPL :
> rpl init 6 successfully initialized RPL on interface 6
Comme nous avons pu le dire, c'est le nœud utilisant tap0 qui est le nœud root. Nous le définissons ainsi grâce à la commande :
> rpl root 1 2001:db8::1
Nous avons désormais la possibilité de voir la configuration du nœud grâce à la commande rpl. Par exemple, pour le nœud root, nous avons le retour suivant :
rpl
instance table: [X]
parent table: [ ] [ ] [ ]
instance [1 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
dodag [2001:db8::1 | R: 256 | OP: Router | PIO: on | CL: 0s | TR(I=[8,20], k=10, c=1, TC=80s, TI=196s)]
Pour un des deux autres nœuds, nous avons :
rpl
instance table: [X]
parent table: [X] [ ] [ ]
instance [1 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
dodag [2001:db8::1 | R: 512 | OP: Router | PIO: on | CL: 0s | TR(I=[8,20], k=10, c=2, TC=0s, TI=1s)]
parent [addr: fe80::8cc0:50ff:fe34:316c | rank: 256 | lifetime: 298s]
Nous avons donc construit un réseau virtuel implémentant le protocole de routage RPL, ce dernier comportant 1 nœud root et deux nœuds fils. Si on tente d'envoyer un message udp entre les deux fils par exemple, cela fonctionne. Cependant, si on supprime le nœud root, alors il n'est plus possible de communiquer entre les deux fils (ce qui est normal car le message devait d'abord passer par le root avant d'être redistribué au bon nœud).
Nous avons donc eu, grâce à cet exemple, une première approche de RPL. IL pourrait être intéressant d'implémenter une architecture différente (qui proposerait plusieurs routes possibles) afin de voir si on peut forcer un paquet à prendre telle ou telle route (ce qui nous aidera par la suite lorsqu'on souhaitera faire face à des problèmes de communications).
Du 16/11 au 23/11/2016 (non rédigé)
- peu de temps à consacrer au projet - demande de réalisation de la carte - machine pour imprimer les cartes en panne - réalisation d'un nouveau calendrier qui tient compte de ce problème - répartition des tâches
Liens bibliographiques et documents
Recherches sur les travaux déjà existants liés aux réseaux sans fil temps-réel
Fichier:Proposition et validation formelle d'un protocole MAC temps reel pour reseaux de capteurs lineraires sans fils.pdf
Fichier:A Real-Time and Reliable Transport RT Protocol for Wireless Sensor and Actor Networks.pdf
Fichier:A Survey on Real-Time MAC Protocols in Wireless Sensor Networks.pdf
Fichier:SPEED A Stateless Protocol for Real-Time Communication.pdf
Recherches sur Contiki
http://www.contiki-os.org/
https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation_pour_capteur_en_r%C3%A9seau
Recherches sur Riot
Recherches sur FreeRTOS
https://www.freertos.org/
https://fr.wikipedia.org/wiki/FreeRTOS
Recherches sur RPL
http://www.ipso-alliance.org/wp-content/media/rpl.pdf https://fr.wikipedia.org/wiki/6LoWPAN
