Version du 14 novembre 2016 à 17:10

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

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.

Fichier:CR reunion 1.pdf

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.

Fichier:CR reunion 2.pdf

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,4 GHz ce qui correspond à des hyperfréquences. C’est pourquoi le bloc ci-dessous comprenant une antenne, un balun et deux condensateurs doit être étudié et dimensionné. (photo)

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, de même, l’impédance de sortie du balun est de 50 Ohms. Donc pour adapté c’est deux éléments il nous faut une ligne d’impédance caractéristique 50 Ohms. Pour une ligne microstrip, son impédance caractéristique dépend de ses dimensions et du matériau isolant. De nombreuse formules sont établies dans la littérature, nous avons utilisé celle présente dans logiciel Saturn PCB Design suivant la norme IPC-2152.

(photo)

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é. Nous trouvons alors que la largeur de la piste doit être égale à . Selon la datasheet, il était conseillé d’ajouter un guide d’onde coplanaire constitué de trous afin d'améliorer les performances de l'antenne. L’intérêt du balun (à finir)

Cependant pour cette partie de la chaîne, l’adaptation d’impédance est déjà réalisée par le composant. Pour ne pas trop modifier l’impédance différentielle des ports RFP et RFN, nous avons décidé de réaliser des pistes de longueur faible et assez large mais surtout des lignes symétriques.

Capa de couplage (à finir)

(photo du .brd)

(réalisation à lancer avant la fin de la semaine du 14)

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

https://riot-os.org/

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