Développement de modules de communication pour la ...motive.cemagref.fr/_publication/PUB00031027.pdf · recherche d’une communication avec un certain niveau de qualité de service,

1 Mémoire d'école d'ingénieur Arnaud ABONNAT

MÉMOIRE EN VUE DE L’OBTENTION DU TITRE D’INGÉNIEUR DÉPARTEMENT : GÉNIE ELECTRIQUE

ET DU MASTER RECHERCHE MSIR

____________________________________

Développement de modules de communication pour la coopération de robots mobiles en milieu

naturel

Présentée par

Arnaud ABONNAT Tuteur industriel : M. Gil De Sousa

____________________________________

Juin 2010 Cemagref de Clermont-Ferrand Campus universitaire des Cézeaux 24 avenue des Landais BP50085 63172 Aubière cedex



Résumé Ce stage intitulé « Développement de modules de communication pour la coopération de robots mobiles en milieu naturel » est proposé par le centre de Clermont-Ferrand du Cemagref, institut de recherche en sciences et technologies pour l’environnement. Ma dernière année de formation d'école d'ingénieur à Polytech'Clermont-Ferrand en génie électrique et la formation de Master Recherche deuxième année MSIR, (modèles, systèmes, imagerie, robotique) correspondent au profil requis. Au sein de l'équipe COPAIN animée par M. Jean-Pierre Chanet, mon objectif est le développement de modules de communication sans fil par ZigBee assurant une qualité de service. La solution proposée repose sur l'adaptation d'un capteur sans fil nommé LiveNode habituellement utilisé dans les réseaux de capteur sans fil (RCSF). Un module simulant une flotte de véhicules est également proposé afin d'étudier l'impact de la communication sur la régulation de la flotte. Du 15 février au 14 août 2010, mon maître de stage M. Gil De Sousa du Cemagref et mon tuteur de stage M. Lounis Adouane de Polytech'Clermont-Ferrand s'assurent de l'avancement de mes travaux.

Abstract This training course entitled " Development of modules of communication for the cooperation of mobile robots in natural environment " is proposed by the Cemagref center at Clermont-Ferrand. It is a research institute in sciences and technologies for the environment. My last year of training of engineering school at Polytech'Clermont-Ferrand in electric engineering and the training of the second degree at Master's MSIR, (models, systems, imaging, robotics) corresponds to the required profile. Within the team Copain manager by Mr. Jean-Pierre Chanet, my objective is the development of modules of wireless communication by ZigBee assuring a quality of service. The application is an adaptation of LiveNode usually used in the networks of wireless sensor (WSN). A module simulating a fleet of vehicle is also proposed to study communication the regulation of the fleet. Of February 15th in 14 August 2010, Mr. Gil De Sousa of Cemagref and Mr. Lounis Adouane of Polytech'Clermont-Ferrand make sure of the progress of my works.


Remerciement Je remercie la direction du Cemagref de Clermont-Ferrand pour m'avoir permis de réaliser mon stage de fin d'études d'école d'ingénieur au sein d'une équipe de recherche. Je tiens à remercier tout particulièrement Gil De Sousa, mon maître de stage, et Roland Lenain, « co-maître » de stage, pour l'attention avec laquelle ils ont suivi mon travail ainsi que pour leur aide et la disponibilité qu'ils m'ont toujours manifestée. Mes remerciements s'adressent également à Aurélien Jacquot pour ses nombreux conseils, sa sympathie et sa bonne humeur qui contribuent au bon déroulement de mon stage. Merci également à toute l'équipe du Cemagref, particulièrement aux membres de la pause café pour l'accueil qu'ils m'ont réservé. Enfin, je profite de ce mémoire pour remercier M. Jacques Lafond et M. Michel James pour m'avoir soutenu lors des deux ans nécessaires à valider ma première année à Polytech'Clermont-Ferrand.


Table des figures Figure 1 : La plateforme de robots mobiles ............................................................................... 9 Figure 2 : Diagramme d'un véhicule........................................................................................ 10 Figure 3 : Emplacement des capteurs sur le robucarTT........................................................... 10 Figure 4 : LiveNode première version ......................................................................................11 Tableau 1 : Couches physique du protocole de communication IEEE 802.15.4 (2006) [ZIGBEE 10]............................................................................................................................ 12 Figure 5 : AT91SAM7S256 Block Diagram [ATMEL 05] ......................................................13 Figure 6 : Diagramme AROCCAM ......................................................................................... 14 Figure 7 : Symétrie /Asymétrie d'une communication ............................................................ 16 Figure 8 : Collision de messages.............................................................................................. 16 Figure 9 : Architecture de réseau ............................................................................................. 17 Figure 10 : Zone de couverture d'un réseau ad hoc.................................................................. 17 Figure 11 : Routage TBRF....................................................................................................... 18 Figure 12 : Routage DSR......................................................................................................... 19 Figure 13 : Routage OLSR....................................................................................................... 20 Figure 14 : Routage LAR1....................................................................................................... 20 Figure 15 : Bandes passantes ................................................................................................... 21 Figure 16 : Principe d'une mesure OTT................................................................................... 22 Figure 17 : Principe d'une mesure RTT ................................................................................... 22 Figure 18 : Principe d'une mesure RTT avec communications croissantes ............................. 23 Tableau 2 : Equation pour un filtre à 4 zones .......................................................................... 24 Figure 19 : Observation des nœuds voisins, (1) directe, (2) indirecte, (3) rapporté ................ 26 Figure 20 : Ordonnanceur par priorité ..................................................................................... 26 Figure 21 : Ordonnanceur SFQ................................................................................................ 27 Figure 22 : Ordonnanceur CBQ............................................................................................... 27 Figure 23 : Ordonnanceur HTB ............................................................................................... 27 Figure 24 : Architecture logiciel du module de communication.............................................. 29 Figure 25 : Structure d'une trame............................................................................................. 30 Figure 26 : Machine d'état de la fonction de réception............................................................ 31 Figure 27 : Identifiant des différends nœuds ........................................................................... 32 Figure 28 : Résultat d'une communication LiveNode vers Ordinateur.................................... 33 Figure 29 : Résultat d'une communication Ordinateur vers LiveNode.................................... 33 Figure 30 : Description du modèle........................................................................................... 34 Figure 31 : Fonction de commutation lisse.............................................................................. 35 Figure 32 : Calcul de la nouvelle trajectoire ........................................................................... 36 Figure 33 : Trajectoire sans suivi et sans communication ....................................................... 37 Figure 34 : Trajectoire avec suivi et sans communication ....................................................... 37 Figure 35 : Trajectoire avec suivi et communication à 1% d'erreur ........................................ 38


SOMMAIRE Table des figures............................................................................................................... 5 Introduction ...................................................................................................................... 7 I Présentation des organisations ....................................................................................... 8

I.1 Cemagref ................................................................................................................ 8 I.2 Polytech'Clermont-Ferrand..................................................................................... 8 I.3 Master ..................................................................................................................... 8

II Contexte de l’étude ....................................................................................................... 9 II.1 Plateforme robot mobile........................................................................................ 9 II.2 Capteur sans fil LiveNode....................................................................................11 II.3 Logiciel AROCCAM .......................................................................................... 13

III Etat de L'art sur les réseaux ad hoc............................................................................ 15 III.1 Problématique de la couche physique................................................................ 15 III.2 Problématique du routage .................................................................................. 16 III.3 Définition de la qualité de service ..................................................................... 20

III.3.1 Estimateur de bande passante..................................................................... 21 III.3.2 Congestion d'un réseau............................................................................... 25 III.3.3 Ordonnancement d’envoi de message........................................................ 26

IV Module de communication........................................................................................ 29 IV.1 Architecture logicielle du module de communication ....................................... 29 IV.2 Ordonnanceur du module de communication .................................................... 32 IV.3 Expérimentations réalisées et résultats............................................................... 33

V Modélisation de la communication sans fil ................................................................ 34 V.1 Présentation du système et de l'objectif de la simulation .................................... 34 V.2 Description du modèle de simulation.................................................................. 34 V.3 Améliorations apportées au modèle de simulation.............................................. 35 V.4 Simulations réalisées et résultats ......................................................................... 36

Conclusion...................................................................................................................... 39 Bibliographies / Références............................................................................................ 40 Annexes .......................................................................................................................... 42


Introduction L'agriculture moderne doit répondre aux besoins d'une population de plus en plus importante. Afin d'accroitre la productivité, des machines agricoles de plus en plus imposantes sont ainsi développées. Cependant, l'impact environnemental et les contraintes mécaniques ont augmenté avec la taille de ces machines. Une des alternatives proposées par le Cemagref est le développement d'une flotte de véhicules qui collaborent, de manière autonome, pour réaliser une tâche agricole. Pour cela, les travaux sur le guidage de véhicule le long d’une trajectoire, grâce aux mesures de capteurs proprioceptifs et intéroceptifs, doivent être poursuivis. De plus, le pilotage d'une flotte demande un échange d'information entre les véhicules. Les modules de communication développés par mes soins seront ainsi embarqués sur chaque véhicule. L'ensemble des modules forment un réseau similaire à un réseau de capteurs sans fil. La recherche d’une communication avec un certain niveau de qualité de service, m’a amené, dans un premier temps, à réaliser un état de l'art sur les réseaux de capteurs sans fil ainsi que des méthodes de mesure et d'estimation du débit d'information voire, bande passante disponible. Une politique de qualité de service a été implantée sur les modules constitués d'un microcontrôleur et d’une puce de communication ZigBee. En parallèle du développement des modules, j'ai programmé une interface pour le logiciel AROCCAM. Pour étendre ces recherches sur l'influence de la qualité de la communication dans le contrôle d'une flotte de véhicules, j'ai développé un module dédié à la communication sans fil dans un modèle de simulation de flotte de véhicules.


I Présentation des organisations

I.1 Cemagref Le Cemagref, institut de recherche en sciences et technologies pour l’environnement, est un établissement public à caractère scientifique et technologique (EPST) français au même titre, par exemple, que l’INRA (Institut National de Recherche Agronomique). Il est placé sous la double tutelle des ministères en charge de la Recherche et de l'Agriculture. Il collabore avec d'autres organismes de recherche, universités, industriels et collectivités territoriales sur les thématiques environnementales. Ses recherches portent notamment sur la qualité des eaux de surface, la biodiversité, les technologies vertes, le développement territorial, l'économie de l'environnement, les écotechnologies. Le Cemagref dispose de neuf centres en métropole dont celui de Clermont-Ferrand et deux antennes à Strasbourg et en Martinique. Le centre de Clermont-Ferrand, qui est sous la direction de Mme Anne Rizand, possède un site au Cézeaux d'Aubière et un second à Mondoldre. Les agrosystèmes, les dynamiques de l’environnement et territoriales des espaces ruraux sont les thématiques de recherche abordées au centre de Clermont-Ferrand. Les trois équipes Carac'Terre, Copain et Team de l'Unité de Recherche Technologies et systèmes d'information pour les agrosystèmes (UR TSCF) du département Ecotechnologies sont réparties sur les deux sites.

I.2 Polytech'Clermont-Ferrand Polytech'Clermont-Ferrand anciennement C.U.S.T. forme des ingénieurs au sein de l'université Blaise Pascal depuis 1969. Chaque année, plus de 200 élèves obtiennent le titre d'ingénieur. La spécificité de l'école de Clermont est de regrouper plusieurs disciplines dans les cinq départements que sont le génie biologique, le génie civil, le génie électrique, le génie mathématique et modélisation et le génie physique. Le département génie électrique, dirigé par M. Khalil El Khamlichi Drissi, propose une formation complète dans son domaine en adéquation avec les besoins du monde industriel. Les différents stages et projets ainsi que les conférences d'industriels sont quelques uns des liens tournés vers les entreprises. Des enseignements avec des aspects plus théoriques comme l'automatisme, le traitement de l'information sont aussi prodigués. De plus, Polytech'Clermont-Ferrand propose aux élèves de suivre une formation de Master Recherche en parallèle à leur dernière année d'étude.

I.3 Master Le Master Recherche MSIR (modèles, systèmes, imagerie, robotique) a pour objectif de former de futures doctorants en leur transmettant la méthodologie et la technique en leur proposant quatre parcours, que sont la recherche opérationnelle et productique, les systèmes d'information et de communication, l'imagerie-vision et la robotique-perception.


II Contexte de l’étude La réalisation d'une tâche agricole dans un champ nécessite généralement le passage de plusieurs engins comparables à une flotte de véhicules. Le pilotage des engins de façon automatique implique l'échange d'information. Dans le cadre du Cemagref, la flotte sera constituée d'un tracteur qui jouera le rôle de véhicule guide et de deux plateformes robots mobiles qui le suivront. Le développement des modules est réalisé de manière générique pour pouvoir étendre l'application à un nombre plus important de véhicules (Contrainte de la flotte,...). Les informations échangées seront transmises du module de communication à un ordinateur (calculateur) embarqué qui réalisera la régulation de trajectoire du véhicule. Le programme pour piloter les plateformes mobiles sera développé avec le logiciel AROCCAM (Architecture d'Ordonnancement de Capteurs pour la Création d'Algorithmes Modulaires). Une interface spécifique est également développée pour relier le module de communication au logiciel AROCCAM. De plus, le module développé durant le stage, se base sur l'expérience de l'équipe COPAIN et sur leurs travaux déjà menés sur les réseaux de capteurs intelligents sans fil (RCSF). On pourra notamment s’appuyer sur les travaux de M. Aurélien Jacquot réalisés durant sa thèse intitulée « Supervision de réseaux d’Objets Intelligents Communicants sans fil » basés sur un capteur intelligent nommé LiveNode. L'idée directrice du stage est l'adaptation de ces capteurs, au rôle de module de communication, embarqués sur les plateformes robots mobiles. Cette nouvelle fonctionnalité impose un changement sur le réseau qui devient de type MANET. Un état de l'art sur les réseaux ad hoc a été, dans un premier temps réalisé, suivi d'une familiarisation avec le matériel électronique et les outils de développement disponibles.

II.1 Plateforme robot mobile

Figure 1 : La plateforme de robots mobiles

Les deux véhicules que le Cemagref utilise sont un robucarTT et un robuFAST (voir Figure 1) de chez Robosoft. Ces solutions de plateforme mobile sont conçues pour des déplacements rapides (6 m/s) en terrain naturel comme les champs agricoles. Un ordinateur avec un système d'exploitation Ubuntu est embarqué sur chaque véhicule. Il remplit le rôle de calculateur pour piloter la plateforme. Le logiciel AROCCAM remplit le rôle d'interface entre les capteurs proprioceptifs, intéroceptifs et les actionneurs. Le module de communication développé se comporte comme un capteur pour ce logiciel (voir Figure 2).


Figure 2 : Diagramme d'un véhicule

Des équipements ont été rajoutés sur le robucarTT sur le site des Cézeaux (voir Figure 3). En voici une liste non exhaustive : - un GPS avec correction centimétrique, (1); - un radar, (2); - une caméra, (3); - un télémètre, (4); - un modem Wi-Fi.

Figure 3 : Emplacement des capteurs sur le robucarTT

Notre projet équipe la plateforme d'un nouvel élément. Le module de communication


est une adaptation d'un capteur sans fil nommé LiveNode à notre application.

II.2 Capteur sans fil LiveNode Le LiveNode (ou LIMOS Versatile Embedded wireless sensor Node) développé par le laboratoire LIMOS est un nœud de RCSF ou capteur sans fil. Un microcontrôleur ARM7TDMI AT91SAM7S256 d’ATMEL Corporation permet de piloter différents capteurs de grandeur physique ou dispositifs de mesure. Il peut également réaliser la sauvegarde des données collectées par les capteurs et calculer de nouvelles informations à partir de celles-ci. Une puce XBee ou XBeePro remplit le rôle de medium radio. Elle communique avec le microcontrôleur par liaison série. Un module GPS peut lui être également ajouté. Le LiveNode a pour vocation d’être utilisé comme un capteur intelligent avec une longue autonomie (voir Figure 4).

Figure 4 : LiveNode première version

Une nouvelle version du LiveNode est actuellement en développement. Une carte électronique munie du même microcontrôleur ARM7 et d’une puce XBeePro servira d’élément de base ou de carte mère. Des cartes filles avec des dispositifs de mesure seront connectées et pilotées par bus I²C à la carte mère. Afin que notre projet puisse utiliser cette nouvelle version, une carte fille spécifique est à développer. Elle jouera le rôle d'interface Entrée/Sortie. La puce XBeePro est une solution technique répondant aux caractéristiques de la norme ZigBee [ZIGBEE 10]. La spécification ZigBee décrit un protocole propriétaire pour communiquer par radiofréquence s'appuyant sur la norme IEEE802.15.4. La norme ZigBee prévoit l'utilisation de trois bandes de fréquence (868, 915 et 2400 MHz). La gamme de fréquence de la puce XbeePro est de 2400 MHz. Cette norme a été développée pour des applications industrielles à bas coût, une longue autonomie, un faible débit et à moyenne portée. Les principaux paramètres de la couche physique sont


décrits dans le tableau 1. La portée théorique d'une puce XBeePro est de 1500m dans un espace libre d’obstacle [XBEE 06]. La configuration de la puce permet notamment le choix du canal de fréquence parmi les 16 disponibles de la bande de 2400 MHz. Il est aussi possible d'attribuer une adresse à la puce et de désigner l'adresse d'une autre. Cela forme un couple de puces communicantes implémentant un mode point-à-point. Le changement de couple nécessite une reprogrammation de la configuration. Ce changement demandant plusieurs secondes, le choix a été fait d'utiliser le mode « diffusion » (ou « broadcast »). Un mécanisme de retransmission en cas de collision est présent. Le nombre de tentatives de retransmission peut être choisi. Notre application utilise, par défaut, trois tentatives. La configuration du port série est celle par défaut : 9600 b/s, sans bit de parité et avec un bit de stop. Un buffer d'une capacité de 100 octets se trouve en entrée du port série afin d'attendre la disponibilité de l'antenne partagée entre les opérations d’envoi et de réception. Dans le cas où la bande passante se révèlerait insuffisante, il est possible d'augmenter le débit du port série et/ou d'ajuster le nombre de tentatives de retransmission.

Tableau 1 : Couches physique du protocole de communication IEEE 802.15.4 (2006)

[ZIGBEE 10] Le microcontrôleur AT91SAM256 de chez ATMEL Corporation était déjà utilisé dans des prototypes de capteurs intelligents du Cemagref (voir Figure 5). Les caractéristiques qui ont amené à son choix lors du prototypage du capteur sont multiples [ATMEL 05]. Il intègre une mémoire flash de 256 Ko permettant de sauvegarder les données collectées par les dispositifs de mesure. Il dispose de deux liaisons séries universelles asynchrones (USART). Ces liaisons permettent de communiquer avec un module GPS, facultatif, pour l'un et, le reste du réseau pour l'autre via la puce XBee. Sa fréquence de fonctionnement est de 50 MHz et sa tension d'alimentation est de 3.3V. Dans la configuration qui nous intéresse, dite de module de communication sans fil, le microcontrôleur réalise la gestion du réseau avec la notion de qualité de service. L'un des USART(s) est toujours relié à la puce XBeePro. L'autre relie le nœud devenu


module de communication au PC avec l'interface logiciel AROCCAM.

Figure 5 : AT91SAM7S256 Block Diagram [ATMEL 05]

II.3 Logiciel AROCCAM L'architecture d'ordonnancement de capteur pour la création d'algorithmes modulaires (AROCCAM) est née d’une collaboration entre le Lasmea et le Cemagref [TESSIER 06]. Ce logiciel centralise les données capteurs et réalise une fusion de données pour notamment les algorithmes de pilotage de véhicules. Cette architecture multitâche et événementielle est légère en temps d'exécution. Une application possède une fonction permettant de s'abonner à des interfaces et des fonctions programmes. Au lancement d'AROCCAM, son noyau liste les différents abonnements propres à chaque application, puis attend les événements des interfaces. Une fois qu'un événement est détecté, les données de l'interface sont transmises aux applications qui disposent d’un abonnement et les fonctions programmes des applications associées sont exécutées.


La version d'AROCCAM utilisée est la version 1.12 fonctionnant avec le système d'exploitation Ubuntu 8.0.4. Ce couple Ubuntu-AROCCAM correspond à la configuration des applications déjà développées pour le pilotage du RobucarTT. Le programme de l'interface n'est pas exportable sur une version plus récente du logiciel. Le module de Communication n'est pas un capteur natif d'AROCCAM et nécessite donc le développement d’une nouvelle interface (voir Figure 6).

Figure 6 : Diagramme AROCCAM

Noyau du logiciel

Application (A)

Interface (Joystick)

Application (B)

Interface (GPS)

Interface (Horloge)

Interface (Module de Communication)

Demande d’abonnement à des interfaces

Événements


III Etat de L'art sur les réseaux ad hoc Les réseaux ad hoc sont des réseaux sans fil dans lequel les nœuds s'organisent par eux-mêmes pour établir les communications au sein du réseau. Une forte dynamique dans leur organisation caractérise les réseaux ad hoc. Les nœuds susceptibles d’appartenir à un tel réseau sont souvent mobiles, d'autant plus s'ils sont embarqués sur des véhicules. L'arrivée ou le départ d'un nœud dans le réseau est alors fréquent. On retrouve les termes MANET (Mobile Ad hoc NETwork) ou VANET (Véhicule Ad hoc NETwork) dans plusieurs publications [LABIOD 06]. Dans les réseaux ad hoc, des problématiques déjà présentes dans les réseaux filaires, comme le routage, sont encore plus complexes à résoudre.

III.1 Problématique de la couche physique Les réseaux sans fil hertzien utilisent l'air comme médium de communication. La propagation des ondes électromagnétiques est conditionnée par l'antenne utilisée pouvant être omnidirectionnelle ou directionnelle. La portée radio D d'une antenne, dans les conditions d'un espace libre de tout obstacle, suit l'équation suivante :

Pr4

GrGePeD

××××

=π

λ

Où λ est la longueur d'onde, Pe et Pr sont respectivement la puissance émise et celle reçue, Ge et Gr sont respectivement le gain isotrope de l'antenne de l'émetteur et de celle du récepteur. La réflexion des ondes, liée à la présence d’obstacles, diminue la portée précédemment calculée. La zone de couverture d'une antenne correspond à l'espace dans lequel un récepteur reçoit une puissance égale ou supérieure à sa puissance de réception. Selon la puissance de chaque nœud, un problème d'asymétrie peut apparaître. La communication est symétrique entre deux nœuds lorsqu'ils se trouvent chacun dans la zone de couverture de l'autre. Elle est asymétrique quand l'un des deux nœuds n’est pas dans la zone, et elle devient coupée si aucun des deux n’est à portée l’un de l'autre (voir Figure 7). Une communication symétrique est donc nécessaire pour qu'elle soit bidirectionnelle [LABIOD 06].


Figure 7 : Symétrie /Asymétrie d'une communication

La problématique des collisions de messages demeure la même que pour un réseau filaire. Dans le cas de communications sur un seul canal de fréquence, des règles permettent d'éviter une collision. Deux nœuds ne peuvent pas émettre en même temps, s'ils sont mutuellement à portée. En outre, un nœud ne peut recevoir deux signaux en même temps (voir Figure 8).

Figure 8 : Collision de messages

III.2 Problématique du routage Le mécanisme d'acheminement d'un message d'un point à l'autre du réseau correspond au routage. Il consiste à choisir le chemin reliant deux points du réseau. L'architecture centralisée hiérarchisée s'oppose à l'architecture décentralisée multipoint complexe (voir Figure 9). Un réseau centralisé permet de simplifier le routage. Les nœuds de niveaux supérieurs centralisent les communications partant des niveaux inférieurs. Il suffit alors que chaque nœud central connaisse ses voisins. Le goulot d'étranglement des nœuds centraux provoque un fort risque de saturation. Afin de comprendre les différents mécanismes en jeux et les méthodes pouvant être mises en place pour éviter les risques mentionnés, une étude sur les différents protocoles de routages existants a été menée. L'architecture multipoint complexe admet plusieurs routes possibles pour relier deux points. La complexité du routage vient du choix du meilleur chemin parmi la multitude


possible. L'avantage d'un tel système est de diminuer le risque de saturation du réseau.

Figure 9 : Architecture de réseau

Dans un réseau filaire, l'infrastructure est globalement fixe. Une fois l'architecture connue, des tables de routage sont créées. La forte mobilité des nœuds des réseaux ad hoc modifie fréquemment l'architecture. Chaque nœud du réseau est limité par sa portée d'émission et est donc isolé d'une partie du réseau. La possibilité qu'a chaque nœud de servir de relais radio permet d'étendre le réseau à l'ensemble des nœuds sous couverture radio du réseau (voir Figure 10). La stratégie de routage doit être connue par l'intégralité des nœuds.

Figure 10 : Zone de couverture d'un réseau ad hoc

La problématique du routage des réseaux ad hoc reste ouverte [CHANET1 07]. En effet, la complexité est multiple : - l'architecture est fortement dynamique;


- la qualité de la communication varie selon la portée de chaque nœud, (notamment les liens radios asymétriques); - l'air est un médium ouvert aux perturbations, (bruits radio et obstacles physique); - les ressources des nœuds sont souvent limitées (puissance de calcul, énergie …); - le médium radio est peu fiable pour la sécurité. Les protocoles de routage sont autant abondants que les problèmes rencontrés sont nombreux. Les protocoles de routage sont répartis en quatre catégories : proactif, réactif, hiérarchique et géographique [LABIOD 06]. Les protocoles de routage proactifs utilisent des tables de routage comme dans les réseaux filaires. Afin de remédier au problème des mouvements des nœuds, les tables sont mises à jour en continue. Ces mises à jour génèrent des communications supplémentaires afin de maintenir le réseau. Le protocole TBRPF (Topology Broadcast based on Reverse Path Forwarding) est un exemple de protocole proactif. Chaque Nœud construit son arborescence menant à tous les autres nœuds. L'algorithme de Dijkstra permet d'obtenir les routes les plus courtes en nombre de sauts. Des messages « Hello » sont émis par chaque nœud périodiquement pour signaler sa présence à ses voisins. Une fois l'arborescente construite, seuls les changements de voisinage la mettent à jour. Cela permet de limiter la bande passante utilisée uniquement aux messages de contrôle. La Figure suivante montre les arborescences de deux nœuds.

Figure 11 : Routage TBRF

Les protocoles de routage réactifs explorent le réseau suite à une demande d'établissement de communication. Le coût, en termes de communication, de la gestion du réseau est faible. L'inconvénient d'un tel principe est le temps d'attente lié à l'exploration. Le protocole DSR (Dynamic destination-Sequenced Distance-Vector) appartient à cette catégorie. L'exploration se fait par l’inondation de messages RREQ (Route REQuest) possédant la liste des nœuds par lesquels ils sont passés. Chaque nœud ne transmet qu'une fois le message. Une fois que le message RREQ arrive à destination, une réponse


avec un message RREP (Route REPly) est renvoyée au nœud demandeur. Le RREP possède la route qu'il faudra suivre. Le schéma suivant montre la recherche du chemin entre le nœud A et le nœud G.

Figure 12 : Routage DSR

Les protocoles hiérarchiques sont destinés aux réseaux avec un grand nombre de nœuds. Ce type de protocole permet une meilleure dissémination des informations en regroupant des nœuds dans des sous-ensembles (ou « cluster »). Un nœud est désigné ou élu maître de chaque sous-ensemble. L'ensemble des nœuds « maître » (ou « clusterhead ») forment le sous-réseau de niveau supérieur. Le principal avantage de cette solution est la réduction de la taille des tables de routage. Les protocoles hiérarchiques sont également efficaces en présence de nœud avec un critère dominant comme une position fixe ou une zone de couverture plus importante. Le protocole OLSR (Optimized Link State Routing) est hiérarchique et proactif. Périodiquement, il réalise la mise à jour des tables de routage par une inondation. Afin de limiter le nombre de messages de contrôle, certains nœuds sont élus « nœud MPR » (Multi Point Relay). Leur rôle est de propager l'inondation. Le Réseau s'organise autour du sous-réseau des MPR comme le montre la Figure 13.


Figure 13 : Routage OLSR

Les protocoles géographiques prennent en compte la situation physique des nœuds. Il est indispensable d'avoir un moyen de localisation. Cette information facilite le routage en donnant une direction à l'exploration. Le protocole LAR1 (Location-Aided Routing) est géographique. Il prend en compte la position que peut avoir le nœud de destination par rapport à sa position connue. Une surface rectangulaire incluant le nœud émetteur et la zone de probable localisation du nœud destinataire détermine les nœuds utilisables comme relais. La Figure 14 représente l'acheminement d'un message de A à J. Le nœud J pouvant se déplacer à une vitesse Vj.

Figure 14 : Routage LAR1

III.3 Définition de la qualité de service La qualité de service correspond à un niveau d’exigence requis par un client et à une politique à suivre afin de répondre au mieux à ses attentes [LABIOD 06], [SWEENEY 04]. Les attentes souhaitées dans les réseaux de communication sont fortement dépendantes de l'application. Un débit d'information infiniment élevé avec un temps de


transfert et un taux d'erreur nul est l'objectif idéal. Les contraintes physiques et techniques imposent des limites et un compromis entre ces trois objectifs. De plus, afin d'appliquer une politique satisfaisante, des mesures doivent être réalisées pour estimer l'état du réseau. Le temps de transfert peut être caractérisé par des mesures du délai instantané et/ou du délai moyen pour le transfert d'un message entre l’émetteur et le récepteur. La mesure de la gigue des messages correspondant à une fluctuation des délais de transfert, est une autre valeur caractérisant le temps de transfert. La qualité du réseau dépend également du taux d’erreurs. L'erreur peut être de différentes natures : − la perte d'un message; − la corruption de l'information du message; − la mauvaise insertion correspondant à l'arrivée d'un message au mauvais destinataire. La qualité du réseau peut être estimée de manière locale entre deux nœuds ou dans un nœud, ou sur l'ensemble du réseau en interpolant la qualité du chemin entre deux points du réseau. Le terme de bande passante est souvent utilisé pour parler du débit d'information d'un réseau. Une liaison entre deux nœuds d'un réseau se caractérise par une bande passante maximale théorique, une bande passante libre et la bande passante utilisée (voir Figure 15). La bande passante maximale théorique est fixée par la technologie choisie, tandis que la bande passante libre est limitée par l'application et l'environnement de la liaison.

Figure 15 : Bandes passantes

III.3.1 Estimateur de bande passante Les estimateurs de bande passante sont de type invasif ou non-invasif. Les estimateurs invasifs reposent sur l'envoi de messages dédiés à la mesure. Ces estimations sont d'autant meilleures que le nombre de messages de mesures sont nombreux. Il en résulte néanmoins une diminution de la bande passante maximale utile. Les estimateurs non-invasifs analysent des informations portées par les messages de la communication courante. Ils utilisent également des informations sur l'état du nœud.


III.3.1.a Les estimateurs de bande passante invasifs Les estimateurs de bande passante invasifs utilisent la mesure du délai de transmission d'un message entre l'émetteur et le destinataire. Le délai de transfert varie selon le nombre de nœuds le long du trajet et la distance les séparant. Les deux méthodes élémentaires pour cette mesure sont la méthode One-way Trip Time (OTT) et la méthode Round-Trip Time (RTT) [LAI 99], [AMAM2 07]. La méthode OTT est une mesure directe du temps entre l'envoi et la réception du message spécifique à la mesure. Sa mise en œuvre impose que l'émetteur et le destinataire partagent une même base de temps. Le destinataire mesure le temps entre la date d'envoi fixée et la date d'arrivée du message spécifique à la mesure (voir Figure 16).

Figure 16 : Principe d'une mesure OTT

La méthode RTT est la mesure du temps entre l'envoi d'un message et la réception d'une réponse à ce message. L'émetteur envoie un message spécifique. Le destinataire le reçoit et renvoie un message d'acquittement en réponse (voir Figure 17). Le délai de transfert est égal à la moitié du temps mesuré, dans l'hypothèse que l'aller et le retour soient symétriques. Le principal avantage de cette méthode est qu'elle ne nécessite pas de partager une même base de temps.

Figure 17 : Principe d'une mesure RTT

La formule suivante permet, par exemple, d’estimer la bande passante :

PRTTf

LKBP

××=

(rep.)POTTf

LKBP

×××=

2

Où K est une constante prenant en compte le contexte du réseau. Elle peut varier de 0,87


à 1,31. L est la taille des messages, RTTf (rep. OTTf) est la mesure RTT (rep. OTT) filtrée et P est le taux de perte. Le filtre de la mesure RTT est réalisé par la méthode EWMA d'équation :

)1()1()( λλ −×+×−= RTTnRTTfnRTTf (rep.) )1()1()( λλ −×+×−= OTTnOTTfnOTTf

Avec RTTf(n-1) (rep.OTTf(n-1)) la valeur précédente calculée et λ le gain du filtre. Si λ est proche de 1 le filtre est stable (les nouvelles mesures ont moins d'influence) et si λ est proche de 0, le filtre est agile (les nouvelles valeurs influent fortement la valeur filtrée). La méthode Train Of Packet Pair (TOPP) et la méthode Self-LOading Periodic Streams (SLoPS) complètent la méthode RTT. La méthode TOPP envoie successivement deux messages, tandis que la méthode SLoPS envoie un premier message puis envoie un second message à la période suivante. La mesure du temps entre la réception des messages d'acquittement permet d'estimer la bande passante perdue due à des communications croissantes (voir Figure 18).

Figure 18 : Principe d'une mesure RTT avec communications croissantes

III.3.1.b Les estimateurs de bande passante non-invasifs Les estimateurs de bande passante non-invasifs ne génèrent aucun message spécifique. Ils utilisent les informations sur l'état du nœud comme le nombre de message en transitions ou le temps d'attente dans le nœud. L'hypothèse que le nœud subisse un goulot d'étranglement au niveau de l'envoi de message permet d'estimer la bande passante. Dans le cas où il n'y a aucun message dans le nœud, on peut supposer que la bande passante libre est maximale pour l'envoi de message. Inversement si le nombre de


messages stockés augmente, alors la bande passante libre diminue. La taille d'un message est une information qui peut être mesurée. Il est alors possible de comparer le nombre d'octets reçus en une seconde au débit maximal théorique. De plus, les protocoles de communication imposent souvent une encapsulation des données dans une trame. Une trame dispose d’un entête et de données permettant généralement la détection d'erreurs de transmission en fin de trame. Le calcul du taux d'erreurs complète l'estimation. Certains entêtes possèdent la date de l'envoi du message et un identifiant de message. Une mesure de RTT (ou de OTT) devient possible sans l'utilisation de message spécifique. Dans le cas d'une application générant des communications en continue la méthode Non Invasive Manet Bandwidth Estimator (NIMBE) [CHANET2 07] permet d'obtenir une bonne estimation basée sur les formules suivantes :

−×

−×=2

min

2exp

11max

RTTRTT

LBPBP

(Rep.)

−

−×=2

minexp

11max

OTTOTT

LBPBP

L'ensemble des estimateurs de bande passante sont très sensibles aux pics de variation. Le filtre Flip-Flop affine l'estimation de manière algorithmique. Selon la variation entre deux estimations consécutives, l'équation inverse ou non les coefficients d'un filtre EWMA. L'algorithme 1 est alors utilisé pour le choix de l'équation.

Où BP(x) est la bande passante estimée à l'instant x, σ la variance de la bande passante et λ une constantes entre 0,5 et 1. Le filtre à adaptation de zone est une amélioration du filtre Flip-Flop [AMAM1 04]. Le nombre de zones sont supérieurs à deux, contrairement au filtre Flip-Flop. La correspondance zone-équation est résumée dans le Tableau 2.

Tableau 2 : Equation pour un filtre à 4 zones


III.3.2 Congestion d'un réseau La congestion d'un réseau est la conséquence de la réalisation d’un nombre important de communications provoquant un ralentissement global de celui-ci. Une congestion peut être locale ou globale. Des phénomènes non- exhaustifs en sont la cause. Le routage est naturellement une cause de problèmes comme présenté dans le chapitre précédant. Des goulots d'étranglement peuvent, par exemple, se trouver au niveau du nœud qui centralise les communications. Des messages cherchant leur destinataire peuvent se retrouver bloqués dans une boucle du réseau. Leurs accumulations rendent l'ensemble des nœuds de la boucle bloquants aux autres communications. Une différence entre le débit d'entrée et de sortie d'un même nœud, ainsi qu'une différence de débits entre nœuds sont également une cause de congestion. Le blocage d'un message est également possible à l'intérieur d'un nœud. Le chapitre suivant sur l'ordonnancement d'envoi de message développera ce point. Une congestion peut également être due à un acte malveillant. Un nœud corrompu peut bloquer ou mal rediriger les communications. La sollicitation d'un nœud par un nombre important de demandes bloquera également les communications [LABIOD 06]. Si aucune méthode n’est mise en place pour diminuer voire arrêter la congestion, un problème local est susceptible de rapidement se propager à l'ensemble du réseau. Limiter le temps passé d'un message dans le réseau est une méthode courante pour diminuer la congestion d'une boucle. Le temps passé est généralement mesuré en nombre de sauts du message avec la méthode TTL (Time-To-Live). De la mémoire peut être rajoutée au nœud pour augmenter la taille des buffers de réception, de manière à atténuer un pic d'activité. Il est également possible qu'un nœud ayant rempli son buffer supprime un certain nombre de messages pour alléger le réseau. En limitant le nombre de messages sur le réseau, la congestion se voit maîtrisée. Il est possible de fixer le nombre d'envois de messages pour une période donnée, mais des méthodes permettent d'exploiter le réseau de manière plus optimale. La mesure de la bande passante libre permet de limiter au minimum l'envoi de messages afin d'éviter la congestion du réseau. Les réseaux ad hoc sont difficiles à protéger d'un nœud malveillant. La nature même du réseau admet l'intégration de nouveaux nœuds. Les méthodes de cryptage sont une solution pour sélectionner les nœuds entrants mais complexes à mettre en œuvre dans les réseaux de capteur sans fil. Une méthode consistant à observer les nœuds voisins et à leur attribuer une réputation de fiabilité est possible [LABIOD 06]. Les nœuds avec une faible réputation sont peu sollicités pour le routage. Trois méthodes, utilisant la possibilité d'écoute des nœuds, sont possibles avec les réseaux sans fils (voir Figure 19) : • Le nœud émetteur A demande à B de transmettre un message pour C. Une fois sa demande faite, le nœud A écoute le nœud B et vérifie qu'il le transmet correctement à C. Alors A se fait une réputation de B, (méthode directe). • Le nœud D écoute ses voisins et entend que B doit transmettre un message à C. Il vérifie que B transmet correctement à C. Alors D se fait une réputation de B, (méthode indirecte). • Le nœud D écoute ses voisins et entend que B doit transmettre un message à C. Il vérifie que B transmet correctement à C. Le nœud D finit par transmettre la réputation de B à ses voisins, (méthode rapporté).


Figure 19 : Observation des nœuds voisins, (1) directe, (2) indirecte, (3) rapporté

III.3.3 Ordonnancement d’envoi de message Les messages dans un réseau n'ont pas tous la même fonction. Les chapitres précédents ont décrit des méthodes utilisant des messages de contrôles en plus de ceux de l'application. De plus, les messages de l'utilisateur ne remplissent également pas les mêmes fonctions. Les nœuds du réseau transmettent indifféremment ces messages ou utilise un ordonnanceur [DUVAL], [CLAFFY 03]. Ce dernier varie selon les attentes de l'application. Une file de messages FIFO (First In First Out) permet de sauvegarder les messages en attendant leur envoi. Cette méthode du moindre effort peut évoluer afin de privilégier certains messages. Il est courant de caractériser les messages d'une priorité. L'ordonnanceur se complexifie avec un classement des messages selon leur priorité (voir Figure 20). Plusieurs files de messages matérialisent le résultat de ce classement. L'ordonnanceur effectue alors l'envoi par ordre de priorité. Un problème de congestion apparaît à ce niveau, des messages pouvant être bloqués par l'arrivée en continue de messages plus prioritaires. Différents ordonnanceurs vont maintenant être présentés. Leur différence vient généralement des critères de classement et d'envoi des messages utilisés.

Figure 20 : Ordonnanceur par priorité

La méthode SFQ (Stochastic Fair Queuing) classe toujours les messages par priorité. L'envoi se fait avec un tirage aléatoire au niveau des files de messages (voir Figure 21). Des pondérations permettent aux files les plus prioritaires d'être privilégiées. Cette

Priorité

Priorité forte Priorité

Priorité faible

Critère du classement

File de messages Critère d'envoi


méthode a été proposée pour résoudre le problème de blocage des messages les moins prioritaires.

Figure 21 : Ordonnanceur SFQ

La méthode CBQ (Class Base Queuing) n'utilise plus la priorité comme critère de classement, mais la bande passante désirée pour le message (voir Figure 22). Une mesure de la bande passante disponible en sortie est réalisée. L'envoi est accordé en priorité aux messages les moins demandeurs de bande passante sous condition que la bande passante libre est suffisante.

Figure 22 : Ordonnanceur CBQ

La méthode HTB (Hierarchical Token Bucket) utilise le type d'application auquel le message est dédié (voir Figure 23). Selon les applications, les messages requièrent une certaine bande passante. L'envoi se réalise comme pour la méthode CBQ.

Figure 23 : Ordonnanceur HTB

Priorité

Priorité forte Tirage aléatoire

Priorité faible

50 %

1%

Pondérations Critère du classement


Bande passante souhaitée

Besoin fort Besoin et Bande passante disponible Besoin faible

Critère du classement


Mesure de la bande passante

Classement

Téléchargement 6 Mb/s

Interactif 6 Mb/s Vidéo 4 Mb/s

VoIP 4 Mb/s

Envoi en fonction de la bande passante

Mesure de la bande passante


La méthode CSS (Clark Shenker Shang) classe les messages en fonction de leur besoin d’arrivée à destination dans un temps borné ou non. L'envoi sera accordé aux messages ayant le temps d'expiration le plus proche.


IV Module de communication

IV.1 Architecture logicielle du module de communication La programmation du microcontrôleur AT91SAM7S256 se réalise avec le logiciel de développement IAR Embedded Workbench Kickstart. Ce logiciel permet la compilation de codes en langage C et la programmation du microcontrôleur par liaison JTAG. Un mode « Debug » est accessible pour corriger d'éventuelles erreurs de comportement du programme. L'application développée doit configurer les périphériques du microcontrôleur notamment les deux liaisons série asynchrone universel (USART(s)), ordonner, réaliser l'envoi et la réception de messages sur ces deux liaisons, et assurer un niveau de qualité de service. La Figure 24 décrit le modèle suivi pour structurer le logiciel de communication. Un message reçu doit tout d'abord remonter les différentes couches pour pouvoir être routé, puis redescendre pour être envoyé. La qualité de service réalise des mesures dans toutes les couches traversées par les messages et calcule les critères d'envoi.

Figure 24 : Architecture logiciel du module de communication

Le programme est réalisé de telle sorte qu'il puisse être amélioré. Pour cela, l'application est divisée en plusieurs tâches. La tâche US assure la configuration et l’utilisation des périphériques USART(s). La tâche TI assure la configuration et l’utilisation des périphériques Timer(s). Ces deux premières tâches constituent la couche de plus bas niveau. La couche supérieure est l'ordonnanceur, matérialisé par la tâche OR où est organisé l'envoi des messages en fonction des données de la qualité de service. La dernière couche correspond à la tâche RO qui détermine le routage de messages.


Parallèlement à cette pile, la tâche QS réalise le relevé des mesures de la qualité de service et calcule les critères permettant de prendre des décisions à son sujet. Les fichiers « .h » d'une couche fournissent les interfaces uniquement pour la couche supérieure. Les interfaces sont constituées par les prototypes des fonctions, des constantes et définitions de type. Des fonctions sont uniquement dédiées à retourner les valeurs des variables globales, ceci dans le but de limiter ce type de variables à une même tâche. Les noms des variables globales, des constantes et des fonctions sont constitués des deux premières lettres correspondantes à leur tâche associée, puis de quatre autres lettres désignant leur rôle (une variable globale, une constante, une fonction). Exemple : US_FUNC_trans_char. Le fichier Boart.h fait la correspondance entre des étiquettes permettant d'accéder aux ressources du microcontrôleur et des étiquettes propres à notre application, cela dans le but de conserver le reste du programme en cas de changement de composant. Le fichier frame.h définit la structure de la trame dans laquelle sont conservées les données de la communication. Des informations supplémentaires sont ajoutées aux données « utilisateur », afin d'assurer le routage, de caractériser le type de données, de tester l'intégrité des données à leur réception et de propager des informations utiles à la qualité de service. Actuellement, le réseau ne comprend que deux nœuds sans fils et ne nécessite pas de champs identifiant le destinataire, mais dans le but de conserver un certain niveau de généricité, plusieurs champs sont présents dans l'entête. L'entête comprend les identifiants des différents nœuds acteurs de la communication, le nombre de sauts possibles avant destruction du message, un critère sur la nature du message, la date d'envoi et la taille du message (voir Figure 25). L'identifiant de l'émetteur ID_E correspond au nœud à l'origine du message pour un destinataire d'identifiant ID_D. Les messages transitent par une succession de couples de nœuds transmetteur-récepteur d'identifiant ID_T et ID_R. Le TTL (Time-to-Live) est une valeur initialisée à la création du message et décrémentée à chaque saut de transmission. Le message est détruit si à sa réception, son paramètre TTL est nul. Ce fonctionnement a pour but de lutter contre la congestion du réseau par erreur de routage. La Critère correspond à la nature du message. Il fait intervenir la notion de priorité et sera décrite dans le chapitre sur l'ordonnanceur du module de communication. Le corps de la trame contient les données « utilisateur ». Chaque donnée comprend le nom de la donnée sur un octet et sa valeur sur quatre autres octets. De plus, deux octets identifiant les trames de l'application en début de trame et un checksum en fin de trame ne figurant pas dans la structure sont transmis. La taille maximale d'une trame est fixée à 100 octets équivalant à la taille maximale du buffer d'entrée de la puce XBeePro.

Figure 25 : Structure d'une trame


Le fichier usart.c réalise les envois et les réceptions. Les fonctions atomiques utilisées sont l'envoi d'un octet par appel de fonction et la réception d'un octet par interruption. L'envoi d'une trame s'effectue par l'envoi successif des octets de la trame. Avant l'envoi du premier octet, la valeur du checksum est initialisée à zéro, puis, après chaque envoi, le checksum est calculé en réalisant un « ou-exclusif » entre sa valeur précédente et la valeur transmise. La fonction d'interruption qui accuse la réception d'un octet, rend compte également du décodage et de la vérification du checksum des trames. Le décodage est réalisé à l'aide d'une machine d'états qui évolue à chaque réception d'octet (voir Figure 26). Le temps passé dans cette fonction d'interruption est court. À chaque état de la machine, la sauvegarde de l'octet reçu et un calcul du checksum intermédiaire sont exécutés.

Figure 26 : Machine d'état de la fonction de réception

Une fois qu'une trame est reconnue correcte, elle est sauvegardée en attendant sa lecture par une autre fonction. La taille mémoire étant limitée, seules les trois dernières trames de chaque USART sont conservées. L'interface avec la couche supérieure se fait avec deux fonctions : la fonction d'envoi et la fonction de réception d'une trame. Le fichier ordonnanceur.c organise l'envoi des messages selon la stratégie expliquée dans le chapitre suivant « Ordonnanceur du module de communication ». L'interface avec la couche supérieure se fait avec deux fonctions : la fonction d’insertion et la fonction de lecture d'une trame. Le fichier routage.c est actuellement minimaliste. Les trames sont redirigées en fonction de ID_D. Dans notre application les ordinateurs « PC » avec le logiciel AROCCAM ont également un identifiant. Le routage se fait avec des identifiants connus d'avance afin de réaliser des tests. Une version plus complexe avec l'utilisation de protocole routage


CIVIC sera à développer pour assurer le fonctionnement d'un réseau ad hoc fortement mobile.

Figure 27 : Identifiant des différends nœuds

Le fichier QoS.c calcule les paramètres utiles à l'ordonnanceur pour prendre ses décisions. Le nombre total d'octets, le nombre d'octets d'erreur et le nombre des nœuds voisins sont les informations nécessaires aux calculs. Ces relevés sont réalisés toutes les secondes.

IV.2 Ordonnanceur du module de communication L'ordonnanceur développé reprend le principe des trois phases présentées dans le chapitre « Ordonnancement d’envoi de message ». Les messages entrants sont, tout d'abord, classés selon certains critères, puis sauvegardés dans des files de messages, pour finalement être sélectionnés et envoyés selon d'autres critères. Différentes idées ont mené à cette solution. La première est le souhait de pouvoir différencier les messages importants, urgents et normaux. La deuxième est de pouvoir utiliser l'ordonnanceur comme régulateur de bande passante pour assurer la qualité de service. La dernière est de réaliser un ordonnanceur suffisamment générique pour être utilisé pour d'autres applications que la communication entre véhicules. Les notions d'importance et d'urgence pour un message se retrouvent dans d’autres applications comme la surveillance médicale. L'urgence fait référence au besoin d'arriver rapidement. Tandis que la notion d'importance fait référence à la nécessité d'arriver. Dans un premier temps, nous considérons donc qu'il est acceptable qu’un message urgent soit perdu. L'hypothèse est, que s'il arrive en retard, alors l'information est tout de même perdue car le message est obsolète. Il est également acceptable qu'un message important mette du temps pour arriver voire qu'il reste bloqué et sauvegardé pour être transmis plus tard. De plus, la notion de priorité reste valable pour les trois types de messages, (urgents, importants et normaux). Des problèmes apparaissent lorsqu'on considère le couple type et priorité du message. Ceci ressort également avec le choix entre l'envoi d’un message normal avec une priorité maximale et l'envoi d’un message urgent avec la priorité la plus faible. Il est possible alors de voir la priorité comme une pondération entre types. Afin de simplifier la phase de classement, nous utilisons des priorités restreintes à chaque type normal. Il devient possible de caractériser les types et les priorités avec un seul critère correspondant au champ dédié dans nos trames. La valeur « 0 » désigne les messages urgents, la valeur « 1 » les importants et les valeurs de « 2 » à « 7 » la priorité des messages normaux. L'envoi consiste à toujours envoyer les messages urgents. Dans le cas où il n'y a plus de messages urgents, le taux d’erreurs mesuré par la qualité de service détermine si les messages importants peuvent être envoyés. Au-delà d'un certain taux d’erreurs, le risque de perdre un message est trop élevé, donc seuls les messages normaux pourront être envoyés. L'ordonnanceur remplit également un rôle contre la congestion du réseau. Les messages normaux sont majoritaires par rapport aux messages urgents et importants. Ils sont donc la principale source de congestion, d'autant plus si leurs tailles sont importantes. L'idée mise en place est de bloquer les messages de plus grande taille en cas de bande passante faible. Un second classement selon la taille est donc appliqué aux messages normaux.


IV.3 Expérimentations réalisées et résultats Des essais de communication entre le LiveNode et l'HyperTerminal de l'ordinateur par liaison série constituent les premiers tests de la phase de développement du programme du nœud. Ils ont permis la validation de l'envoi et de la réception de messages par port série. La communication LiveNode vers ordinateur est tout d'abord testée avec un message « Hello » (voir Figure 28).

Figure 28 : Résultat d'une communication LiveNode vers Ordinateur

Le test de la communication ordinateur vers LiveNode consiste à faire répondre le LiveNode. Un message avec une valeur quelconque est envoyé au LiveNode, qui une fois reçu, renvoie à l'ordinateur un message avec la valeur incrémentée de un.

Figure 29 : Résultat d'une communication Ordinateur vers LiveNode

Les tests pour valider la communication sans fil par puces XBee nécessitent l'utilisation d'un second nœud. L'envoi et la réception sont également testés avec un message « Hello » et une réponse à un message. Le nœud relié à l'ordinateur remplit son rôle définitif de module de communication, tandis que le second nœud joue le rôle émetteur de message « Hello » ou de réponse. Des essais similaires ont été faits une fois que l'interface dédiée au logiciel AROCCAM fut programmée. Une succession d'essais a permis d'estimer une limite de fréquence d'envoi en fonction du nombre de données. L'intégralité des modules a été testée avec une application proche de leurs futures utilisations. Un Ordinateur avec AROCCAM relié à un LiveNode et à un GPS constitue une plateforme mobile. L'application transmet des données GPS à une fréquence de 2Hz par le LiveNode au second LiveNode en position fixe. Un numéro de trame est ajouté afin de comparer les trames envoyées et reçues.


V Modélisation de la communication sans fil

V.1 Présentation du système et de l'objectif de la simulation L'objectif de la modélisation est de faciliter l'étude du système constitué de la flotte de véhicules. La communication entre les véhicules est essentielle pour qu'ils puissent réaliser une tâche en coopération. La régulation des déplacements suivant une trajectoire est la première étape de toute tâche plus complexe. Des informations comme la position des plateformes mobiles doivent être partagées en temps réel. Une défaillance des communications peut provoquer des erreurs dans la régulation. Le simulateur permet d'étudier l'influence de la communication sur la qualité de la régulation, ceci en limitant les risques d’une expérimentation tout en facilitant la répétabilité des tests.

V.2 Description du modèle de simulation Un simulateur fut développé à partir des travaux de M. Roland Lenain sur la régulation d'une flotte le long d'une trajectoire [BOM 05], [LENAIN 06]. L'intégration du modèle caractérisant les communications demande une remise en forme des modules constituant le modèle du système. Ce modèle permet de simuler trois véhicules, suivant une même trajectoire de référence sans glissement (voir Figure 30).

Figure 30 : Description du modèle

Le modèle utilisé est un tricycle suivant une trajectoire caractérisé par : ● i, l'indice du véhicule ; ● c, la trajectoire suivie ; ● L, la longueur entre la roue avant et l'essieu arrière ; ● l, la largeur de l'essieu arrière ; ● δ, l'angle entre l'axe de la roue avant et l'axe du véhicule ; ● Oi, le centre de l'essieu arrière ● Vi, la vitesse du véhicule ; ● θi, l'angle entre l'axe du véhicule et l'axe [Oa Xa) ; ● M, le point de c le plus proche de Oi ; ● yi, l'erreur latérale, soit la distance M.Oi ; ● θc, l'angle entre la tangente à c en M avec l'axe [Oa Xa) ;


● si, l'abscisse curviligne sur c en M ; ● c(s), la courbure de c en M ;

● θ~ = θc- θi, l'erreur angulaire du véhicule par rapport à c. L'évolution du véhicule par rapport à une trajectoire de référence est décrite par :

( )

×−×−×=

×=×−

×=

ysc

sc

Lv

vyysc

vS

)(1

~cos)(tan~

~sin

1

~cos

θδθ

θ

θ

&

&

&

Le comportement de bas niveau (temps de réponse, limites mécaniques, …) est également modélisé pour représenter au mieux les plateformes de robots mobiles. Un bruit de mesure est ajouté aux grandeurs d'état du véhicule. La régulation se fait en plusieurs étapes. La première consiste à rechercher la coordonnée de c la plus proche de Oi. Puis, une interpolation est réalisée, à partir des coordonnées adjacentes à celle trouvée, pour trouver le polynôme au plus prés de la trajectoire. Finalement, M est déterminé par la méthode du moindre carrée appliquée au

polynôme. L'étape suivante consiste à calculer yi etθ~ . La dernière étape est de calculer

δ pour faire tendre y& et θ&~ vers zéro. La formation des véhicules dans la flotte peut aussi bien être un convoi, les véhicules se suivent les uns dernière les autres, ou, en aile d'avion, les véhicules sont décalés en retrait par rapport au véhicule leader [LENAIN 10]. Pour cela yi ne correspond plus à la distance entre M et Oi mais au calcul suivant :

( ) ( )yiii

yii dyydy 111 −−− −×+= σ

Où ( )1−iyσ est la fonction de commutation lisse, montrée dans la Figure 31. Cela permet

d'éviter les collisions des véhicules s'ils venaient à se rapprocher. yid L'écart à la

trajectoire de référence.

Figure 31 : Fonction de commutation lisse

V.3 Améliorations apportées au modèle de simulation La première modification apportée est d'externaliser la trajectoire de référence au


modèle véhicule. Notre modèle doit rendre le véhicule dépendant à la position et à la trajectoire du véhicule leader, et non à une trajectoire prédéfinie. Cela entraine des modifications dans les lois de régulation. La première étape de la régulation est la réception de la position du leader. Une fois la trajectoire du leader reçue, la construction d'une trajectoire de référence propre au véhicule est réalisée. Elle consiste à ajouter un écart latéral à la trajectoire du leader. A partir des deux dernières positions Pt et Pt-1 du leader, On approxime la tangente à la trajectoire du leader. Puis, selon l'écart désiré, on calcule le nouveau point Tn appartenant à la trajectoire servant de référence au véhicule (voir Figure 32). Seul un certain nombre de points de cette trajectoire sont conservés afin de limiter la taille de la mémoire une fois que les lois de régulation seront implantées sur les plateformes de robots mobiles.

Figure 32 : Calcul de la nouvelle trajectoire

Suite aux premières simulations, le bruit de mesure se révèle problématique dans l'approximation de la tangente à la trajectoire du leader. Un filtre de Kalman pour les valeurs reçues est placé avant le module des lois de régulation.

La seconde modification apportée est l'intégration d'un modèle de modules de la communication entre les véhicules. La communication est modélisée par un délai entre l'envoi par le leader et la réception par les véhicules suiveurs. Des erreurs de transmission peuvent être introduites faisant changer les valeurs et occasionnant des ruptures de communication en fonction de la distance entre véhicules. Les taux d'erreurs sont paramétrables et permettent de simuler des environnements différents. Une première correction peut être sélectionnée pour chaque type d'erreur. Elle consiste à maintenir les valeurs précédentes. Les schémas bloque du modèle de la flotte, du véhicule et de la communication sont en annexes.

V.4 Simulations réalisées et résultats Tout d'abord, une simulation sans faire intervenir le modèle de la communication a été réalisée afin de comparer avec les résultats des modèles « avant » et « après


l'externalisation » des trajectoires. Les trois véhicules disposent tous de la même trajectoire. Le leader doit la suivre sans écart latéral, le véhicule 2 avec un écart de deux mètres et le véhicule 3 avec un écart de quatre mètres. On peut voir comme prévu, sur la Figure 33, que l'écart entre véhicules reste constant. L'erreur de suivie vient du glissement des véhicules.

Figure 33 : Trajectoire sans suivi et sans communication

La simulation (voir Figure 34) suivante montre l'erreur de suivie des véhicules 2 et 3 lorsqu'ils doivent suivre le véhicule leader. Les trajectoires en trait fin des véhicules 2 et 3 correspondent à l'écart désiré.

Figure 34 : Trajectoire avec suivi et sans communication

La dernière Figure corresponde à une simulation où les véhicules 2 et 3 doivent suivre


le véhicule leader avec tous les deux le même écart. Le modèle de communication est appliqué entre le véhicule 3 et le leader avec 1% d'erreur sur la transmission et sans rupture.

Figure 35 : Trajectoire avec suivi et communication à 1% d'erreur


Conclusion Ces quatre premiers mois de stage m'ont permis de développer un prototype du module de communication basé sur un capteur intelligent sans fil nommé LiveNode. L'état de l'art sur les réseaux ad hoc ont permis de voir l'étendue du champ de leurs applications, mais aussi les problématiques qui le leur sont liées. Si des solutions sont disponibles pour les problèmes de collision de message, de congestion des réseaux ou de routage, ces problématiques restent ouvertes. La stratégie de l'ordonnanceur que j'ai développé permet d'être générique à plusieurs applications tout en étant simple à implanter. Il assure également qualité de service, qui pourra être amélioré avec un meilleur estimateur de bande passante. D'autre part le logiciel AROCCAM m'a pris d'aborder l'implantation d'une régulation d'un point de vue pratique. L'interface que j'ai développée pour AROCCAM et la carte fille pour interfacer la nouvelle version du LiveNode avec un ordinateur me permettront de réaliser davantage d'essais afin d'améliorer la qualité de service, notamment l'estimation de la bande passante. De plus, les résultats de ces tests serviront à affiner le module simulant la communication entre véhicules de la flotte. Une première validation sera réalisée avec l'implantation des modules de communication nouvelle version sur les plateformes de robots mobiles. Je souhaite également avoir le temps de réaliser d'autres tests avec l'équipe TEAM pour poursuivre et appliquer mes travaux sur le pilotage d'une flotte de véhicules.


Bibliographies / Références [AMAM1 04] A. Amamra, R. Aufrere, J.P. Chanet, G. De Sousa, J.J. Li, H. Zhou, K. Hou, A new adaptive zone filter to estimate RTT in MANET, Université Blaise Pascal, Publication, 7 pages, 2004 [AMAM2 07] A. Amamra, K.M. Hou, SLOT: A Fast and Accurate Technique to estimate Available Bandwidth in Wireless IEEE 802.11, LIMOS Laboratory, Université Blaise Pascal, Publication, 6 pages, 2007 [ATMEL 05] ATMEL Corporation, AT91 ARM® Thumb®-based Microcontrollers, Datasheet, 516 pages, 2005 [BOM 05] J. Bom, B. Thuilot, F. Marmoiton, P. Martinet, Une Stratégie de Commande Globale pour le Convoi de Véhicules Urbains basée sur des Lois de Commande Découplées Non-Linéaires, Lasmea, Publication, 12 pages, 2005 [CHANET1 07] J.P. Chanet, Algorithme de routage coopératif à qualité de service pour des réseaux ad hoc agri-environnementaux, Thèse pour obtention du grade de Docteur d'Université, 138 pages, 2007 [CHANET2 07] J.P. Chanet, K. Hou, A. Amamra, G. De Sousa, J.J. Li, A Non Invasive MANAT Bandwidth Estimator for Quatity of Service: NIMBE, Cemagref, LIMOS, Publication, 4 pages, 2007 [CLAFFY 03] K. Claffy, C. Dovrolis, Bandwidth estimation measurement methodologies and application,CAIDA, Geargia Tech, Presentation, 60 pages, 2003 [DUVAL] L. Duval , Introduction à la qualité de service liée à la Toip, Département Réseaux et Télécommunications Institut Universitaire de Technologie de la Roche sur Yon, Publication, 15 pages [LABIOD 06] H. Labiod, Réseaux mobiles ad hoc et réseaux de capteurs sans fil, Ouvrage chez Lavoisier, 347 pages, 2006 [LAI 99] K. Lai & M. Baker, Measuring Bandwidth, Department of Compute Science, Stanford University, Publication, 11 pages, 1999 [LENAIN 06] R. Lenain, B. Thuilot, C. Cariou, P. Martinet, Commande de véhicules en presence de glissement : Application au suivi de trajectoire pour les engins agricoles, Cemagref, Lasmea, Publication, 6 pages, 2006 [LENAIN 10] R. Lenain, J. Preynat, B. Thuilot, P. Martinet, Adaptive formation control of a fleet of mobile robots : Application to autonomous field operations, Cemagref, LASMEA, Publication, 6 pages, 2010 [SWEENEY 04] J.D. Sweeney, R. Grupen, P. Shenoy, Active QoS Flow Maintenance in Controlled Mobile Networks, Laboratory for Perceptual Robotics Department of Computer Science University of Massachusetts, Publication, 9 pages, 2004


[TESSIER 06] C. Tessier, C. Cariou, C. Debain, F. Chausse, R. Chapuis, C. Rousset, A Real-Time, Multi-Sensor Architecture for fusion of delayed observations: Application to Vehicle Localisation, Cemagref, Lasmea, ECA, Publication, 6 pages, 2006 [XBEE 06] MaxStraam, XBee™/XBee-PRO™ OEM RF Modules, Datasheet, 69 pages, 2006 [ZIGBEE 10] The ZigBee Alliance, http://www.zigbee.org, 2010


Annexes

I

Table des annexes

Code du module de communication Le fichier Boart.h ………………………………………………………… II Le fichier frame.h ………………………………………………………... IV Le fichier main.c ………………………………………………………..... V Le fichier usart.c ………………………………………………………..... VII Le fichier ordonnanceur.c …..…………………………………………..... XVIII Le fichier routage.c ……………………………………………………..... XXIII Le fichier QoS.c ………………………………………………………...... XXV Schéma du simulateur Le schéma du modèle de la flotte de véhicules …………………………… XXVI Le schéma du modèle du véhicule ………………………………………… XXVII Le schéma du modèle de la communication ……………………………… XXVIII

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Compil\SrcIAR\Board.h

Page 1 of 2

/*---------------------------------------------------------------------------- 1

* ATMEL Microcontroller Software Support - ROUSSET - 2

*---------------------------------------------------------------------------- 3

* The software is delivered "AS IS" without warranty or condition of any 4

* kind, either express, implied or statutory. This includes without 5

* limitation any warranty or condition with respect to merchantability or 6

* fitness for any particular purpose, or against the infringements of 7

* intellectual property rights of others. 8

*---------------------------------------------------------------------------- 9

* File Name : Board.h 10

* Object : AT91SAM7S Evaluation Board Features Definition File. 11

* 12

* Creation : JPP 24/Feb/2005 13

* 1.1 14/Oct/05 JPP : Change MCK 14

*---------------------------------------------------------------------------- 15

*/ 16

#ifndef Board_h 17

#define Board_h 18

19

#include "../include/AT91SAM7S256.h" 20

#define __inline inline 21

#include "../include/lib_AT91SAM7S256.h" 22

23

#define true -1 24

#define false 0 25

26

/*-------------------------------*/ 27

/* SAM7Board Memories Definition */ 28

/*-------------------------------*/ 29

// The AT91SAM7S64 embeds a 16-Kbyte SRAM bank, and 64 K-Byte Flash 30

31

#define ID_NOEUD 0x11 32

33

#define INT_SARM 0x00200000 34

#define INT_SARM_REMAP 0x00000000 35

36

#define INT_FLASH 0x00000000 37

#define INT_FLASH_REMAP 0x01000000 38

39

#define FLASH_PAGE_NB 512 40

#define FLASH_PAGE_SIZE 128 41

42

/*-----------------*/ 43

/* Leds Definition */ 44

/*-----------------*/ 45

46

47

/** for board with sensor */ 48

/*PIO Flash PA PB PIN */ 49

#define LED1 (1<<9) // PA0 / PGMEN0 & PWM0 TIOA0 48 */ 50

#define LED2 (1<<10) // PA1 / PGMEN1 & PWM1 TIOB0 47 */ 51

#define NB_LEB 2 52

53

/** for evaluation board */ 54

55

//#define LED1 (1<<0) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */ 56

//#define LED2 (1<<1) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */ 57

//#define LED3 (1<<2) 58

//#define LED4 (1<<3) 59

60

//#define NB_LEB 2 61

62

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Compil\SrcIAR\Board.h

Page 2 of 2

63

#define LED_MASK (LED1|LED2) 64

65

/*------------------*/ 66

/* USART Definition */ 67

/*------------------*/ 68

/* SUB-D 9 points J3 DBGU*/ 69

70

#define XBee 1 71

#define BASE_US_XBee AT91C_BASE_US1 72

#define ID_US_XBee AT91C_ID_US1 73

#define US_RXD_PIN_XBee AT91C_PA21_RXD1 74

#define US_TXD_PIN_XBee AT91C_PA22_TXD1 75

#define US_RTS_PIN_XBee AT91C_PA24_RTS1 76

#define US_CTS_PIN_XBee AT91C_PA25_CTS1 77

78

#define PC 2 79

#define BASE_US_PC AT91C_BASE_US0 80

#define ID_US_PC AT91C_ID_US0 81

#define US_RXD_PIN_PC AT91C_PA5_RXD0 /* JP9 must be close */ 82

#define US_TXD_PIN_PC AT91C_PA6_TXD0 /* JP7 must be close */ 83

#define US_RTS_PIN_PC AT91C_PA7_RTS0 /* JP8 must be close */ 84

#define US_CTS_PIN_PC AT91C_PA8_CTS0 /* JP6 must be close */ 85

86

87

/*--------------*/ 88

/* Master Clock */ 89

/*--------------*/ 90

91

#define EXT_OC 18432000 // Exetrnal ocilator MAINCK 92

#define MCK 48054857 // MCK (PLLRC div by 2) 93

#define MCKKHz (MCK/1000) // 94

95

#endif /* Board_h */ 96

97

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Src\frame.h

Page 1 of 1

#ifndef frame_h 1

#define frame_h 2

/*----------------------------------------------------------------------------*/ 3

/* "frame" | ID_T | ID_R | SizeData | Data | */ 4

/*----------------------------------------------------------------------------*/ 5

/* Byte | 1 | 1 | 1 | x | */ 6

/*----------------------------------------------------------------------------*/ 7

// Part of frame 8

#define NID_T (unsigned int)0 //Place of ID_T 9

#define NID_R (unsigned int)1 //Place of ID_R 10

#define NID_E (unsigned int)2 //Place of ID_E 11

#define NID_D (unsigned int)3 //Place of ID_D 12

13

#define NTTL (unsigned int)4 //Place of TTL 14

15

#define NPriorite (unsigned int)5 //Place of TTL 16

17

#define NDispatchDate (unsigned int)6 //Place of Time 18

// 7 Time 19

// 8 Time 20

// 9 Time 21

22

#define NSizeData (unsigned int)10 //Place of SizeData 23

#define NData (unsigned int)11 //Place of the beginning of the data 24

25

26

#define SizeHeadFrame 11 // bytes = (ID_T + ID_R + ID_E + ID_D + SizeData) 27

#define SizeMaxData 89 // bytes 28

#define SizeMaxFrame 100 // bytes = SizeMaxData + SizeHeadFrame 29

30

31

typedef struct T_Frame{ 32

unsigned char ID_T; // Identifier transmitter 33

unsigned char ID_R; // Identifier receiver 34

unsigned char ID_E; // Identifier expediteur 35

unsigned char ID_D; // Identifier destinataire 36

unsigned char TTL; // Time-To-Live 37

unsigned char Priorite; // Priorite 38

unsigned int DispatchDate; 39

unsigned char SizeData; 40

unsigned char Data[SizeMaxData]; 41

unsigned int DeliveryDate; //Not passed on 42

//... 43

}T_Frame; 44

45

46

#endif /* frame_h */ 47

48

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Src\main.c

Page 1 of 2

//*------------------------------------------------ ---------------------------- 1

//* ATMEL Microcontroller Software Support - ROUSSET - 2

//*------------------------------------------------ ---------------------------- 3

//* The software is delivered "AS IS" without warra nty or condition of any 4

//* kind, either express, implied or statutory. Thi s includes without 5

//* limitation any warranty or condition with respe ct to merchantability or 6

//* fitness for any particular purpose, or against the infringements of 7

//* intellectual property rights of others. 8

//*------------------------------------------------ ---------------------------- 9

//* File Name : main.c 10

//* Object : main application written in C 11

//* 1.0 24/Jun/04 JPP : Creation 12

//* 1.1 21/Feb/05 JPP : Update AT91C_RSTC_URSTEN 13

//* 1.2 29/Aug/05 JPP : Update AIC definion 14

//*------------------------------------------------ ---------------------------- 15

16

// Include Standard LIB files 17

#include "Board.h" 18

#include "usart.h" 19

#include "timer.h" 20

#include "Ordonnenceur.h" 21

#include "routage.h" 22

#include "QoS.h" 23

24

//* Waiting time between LED1 and LED2 25

#define WAIT_TIME MCK 26

27

28

29

int main( void ) 30

//* Begin 31

{ 32

33

//* Enable User Reset and set its minimal assertion to 960 us 34

AT91C_BASE_RSTC->RSTC_RMR = AT91C_RSTC_URSTEN | (0x4<<8) | (unsigned int)(0xA5<<24); 35

36

//* Init 37

// First, enable the clock of the PIOB 38

AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_PIOA ); 39

40

//* then, we configure the PIO Lines corresponding to LED1 to LED8 41

//* to be outputs. No need to set these pins to be driven by the PIO because it is GPIO pins onl y. 42

AT91F_PIO_CfgOutput( AT91C_BASE_PIOA, LED_MASK ) ; 43

//* Clear the LED's. On the EB55 we must apply a "1 " to turn off LEDs 44

AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED_MASK ) ; 45

46

47

//* Init Usart 48

US_FUNC_init(); 49

TI_FUNC_init(); 50

OR_FUNC_init(); 51

RO_FUNC_init(); 52

for (;;){ 53

// QoS 54

QoS_mise_a_jour(); 55

// routage 56

RO_FUNC_routage(); 57

} 58

59

//* End 60

} 61

62

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Src\main.c

Page 2 of 2

63

64

65

66

/* 67

//------------------------------------------------- ---------------------------// 68

// Note general 69

//------------------------------------------------- ---------------------------// 70

// 71

// Utilisation des fonction malloc() et free() on n 'eccésite une modification 72

// du fichier at91sam7s256 pour definir sous zone m emoire pour le " Heap " 73

// ajout de la ligne 117 : -D_HEAP_STACK_SIZE=100 0 74

// ajout de la ligne 121 : -Z(DATA)HEAP+_HEAP_STAC K_SIZE=RAMSTART-RAMEND 75

// 76

// 77

*/ 78

79

C:\Documents and Settings\arnaud.abonnat\Mes docume nts\IAR_programme\Prog1_07_06_10\Src\usart.c

Page 1 of 11

// Include Standard LIB files 1





#include "frame.h" 6

7

#define USART_INTERRUPT_LEVEL 7 8

#define AT91_BAUD_RATE 9600 9

#define CKS_INIT_VALUE 0 10

11

/*USART BufferRec*/ 12

#define US_CONS_SizeBufferRec 4 // 4 frame 13

// and SizeMaxFrame 256 // of 256 bytes 14

15

//* \fn AT91F_US_Baudrate 16

//* \brief Calculate the baudrate 17

//* Standard Asynchronous Mode : 8 bits , 1 stop , no parity 18

#define AT91C_US_ASYNC_MODE ( AT91C_US_USMODE_NORMAL + \ 19

AT91C_US_NBSTOP_1_BIT + \ 20

AT91C_US_PAR_NONE + \ 21

AT91C_US_CHRL_8_BITS + \ 22

AT91C_US_CLKS_CLOCK ) 23

24

/*USART BufferRec*/ 25

typedef struct{ 26

unsigned char fifo[US_CONS_SizeBufferRec][SizeMaxFrame]; // 4 frame of 256 bytes 27

unsigned int level; 28

unsigned int writing; 29

}US_TYPE_fifo; 30

31

enum US_TYPE_etat { 32

EWait, 33

EIDt1, 34

EID_T, 35

EID_R, 36

EID_E, 37

EID_D, 38

ETTL, 39

EPriorite, 40

ETime0, 41

ETime1, 42

ETime2, 43

ETime3, 44

ESizeData, 45

EData, 46

ECKS1 47

}; 48

49

/*----------------------------------------------------------------------------*/ 50

/*Prototype */ 51

/*----------------------------------------------------------------------------*/ 52

//user function 53

unsigned int FunctionCharInFrame( void); 54

unsigned int FunctionUS_GLOB_error_char_XBee( void); 55

unsigned int FunctionCharSend( void); 56

unsigned int FunctionLossRateUSART( void); 57

58

unsigned int US_FUNC_total_char_XBee( void); 59

unsigned int US_FUNC_error_char_XBee( void); 60

unsigned int US_FUNC_total_char_PC( void); 61

unsigned int US_FUNC_error_char_PC( void); 62


Page 2 of 11

63

unsigned int US_FUNC_recev_data(T_Frame *frame); 64

unsigned int US_FUNC_trans_data(T_Frame *frame, unsigned int v); 65

void US_FUNC_init( void); 66

//interne 67

void US_FUNC_irq_handler_PC( void); 68

void US_FUNC_irq_handler_XBee( void); 69

unsigned int US_FUNC_recev_data_PC(T_Frame *frame); 70

unsigned int US_FUNC_recev_data_XBee(T_Frame *frame); 71

//interne + userDeBug 72

unsigned char US_FUNC_trans_char( unsigned char c, unsigned int v, unsigned char CKS); 73

unsigned char US_FUNC_trans_int( unsigned int c, unsigned int v, unsigned char CKS); 74

unsigned char US_FUNC_trans_short( unsigned short c, unsigned int v, unsigned char CKS); 75

76

77

78

/*----------------------------------------------------------------------------*/ 79

/*GLOBAL VARIABLE */ 80

/*----------------------------------------------------------------------------*/ 81

US_TYPE_fifo US_GLOB_fifo_rec_XBee; 82

US_TYPE_fifo US_GLOB_fifo_rec_PC; 83

unsigned int LossRateUSART; 84

unsigned int US_GLOB_total_char_XBee; 85

unsigned int US_GLOB_error_char_XBee; 86

unsigned int US_GLOB_total_char_PC; 87

unsigned int US_GLOB_error_char_PC; 88

89

unsigned int CharSend; 90

91

92

93

/*----------------------------------------------------------------------------*/ 94

/*USER FUNCTION */ 95

/*----------------------------------------------------------------------------*/ 96

unsigned int US_FUNC_total_char_XBee( void){ 97

unsigned int out; 98

out = US_GLOB_total_char_XBee; 99

US_GLOB_total_char_XBee = 0; 100

return out; 101

} 102

/*----------------------------------------------------------------------------*/ 103

unsigned int US_FUNC_error_char_XBee( void){ 104


out = US_GLOB_error_char_XBee; 106

US_GLOB_error_char_XBee = 0; 107

return out; 108

} 109

/*----------------------------------------------------------------------------*/ 110

unsigned int US_FUNC_total_char_PC( void){ 111


out = US_GLOB_total_char_PC; 113

US_GLOB_total_char_PC = 0; 114

return out; 115

} 116

/*----------------------------------------------------------------------------*/ 117

unsigned int US_FUNC_error_char_PC( void){ 118


out = US_GLOB_error_char_XBee; 120


return out; 122

} 123

/*----------------------------------------------------------------------------*/ 124


Page 3 of 11

unsigned int FunctionCharSend( void){ 125


out = CharSend; 127

CharSend = 0; 128

return out; 129

} 130

/*----------------------------------------------------------------------------*/ 131

unsigned int FunctionLossRateUSART( void){ 132

return LossRateUSART; 133

} 134

135

/*----------------------------------------------------------------------------*/ 136

unsigned int US_FUNC_recev_data(T_Frame *frame){ 137

static unsigned int k= 1; 138

139

if(k== 1){ k= 2; 140

if(!(US_FUNC_recev_data_PC(frame))) 141

return 0; 142

if(!(US_FUNC_recev_data_XBee(frame))) 143

return 0; 144

145

} 146

else{ k= 1; 147

if(!(US_FUNC_recev_data_XBee(frame))) 148

return 0; 149

if(!(US_FUNC_recev_data_PC(frame))) 150

return 0; 151

152

} 153

return 1; 154

155

} 156

/*----------------------------------------------------------------------------*/ 157

unsigned int US_FUNC_trans_data(T_Frame *frame, unsigned int v){ 158

int i; 159

unsigned char c; 160

unsigned int i_int; 161

unsigned short CKS = CKS_INIT_VALUE; 162

163

i_int = TI_FUNC_ms(); 164

165

CKS = US_FUNC_trans_char( '#' ,v,CKS); 166

167

CKS = US_FUNC_trans_char( 'T' ,v,CKS); 168

169

c=frame->ID_T; 170

CKS = US_FUNC_trans_char(c,v,CKS); 171

172

c=frame->ID_R; 173


175

c=frame->ID_E; 176


178

c=frame->ID_D; 179


181

c = frame->TTL - 0x01 ; 182


184

c = frame->Priorite; 185



Page 4 of 11

187

CKS = US_FUNC_trans_int(i_int,v,CKS); 188

189

c=frame->SizeData; 190


192

for(i= 0 ; i<(frame->SizeData) ; i++){ 193

c=frame->Data[i]; 194


} 196

US_FUNC_trans_char(CKS,v,CKS); 197

198

CharSend += frame->SizeData + SizeHeadFrame; 199

return 0; 200

} 201

/*----------------------------------------------------------------------------*/ 202

void US_FUNC_init( void ) 203

//* Begin 204

{ 205

AT91PS_USART COM; 206

//Initialization of the global variable 207

US_GLOB_fifo_rec_XBee.level = 0; 208

209

US_GLOB_fifo_rec_XBee.writing= 0; 210

211

US_GLOB_total_char_XBee = 0; 212


US_GLOB_total_char_PC = 0; 214

US_GLOB_error_char_PC = 0; 215

216

//USART Micro-XBeee 217

COM = BASE_US_XBee; 218

/* Configure PIO controllers to periph mode*/ 219

AT91F_PIO_CfgPeriph( AT91C_BASE_PIOA, 220

(( unsigned int) US_RXD_PIN_XBee ) | 221

(( unsigned int) US_TXD_PIN_XBee ) | 222

(( unsigned int) US_RTS_PIN_XBee ) | 223

(( unsigned int) US_CTS_PIN_XBee ), // Peripheral A 224

0); // Peripheral B 225

226


AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PM C, 1 << ID_US_XBee ) ; 228

// Usart Configure 229

AT91F_US_Configure (COM, MCK, AT91C_US_ASYN C_MODE, AT91_BAUD_RATE, 0); 230

// Enable usart 231

COM->US_CR = AT91C_US_RXEN | AT91C_US_TXEN; 232

//* Enable USART IT error and RXRDY 233

AT91F_US_EnableIt(COM,AT91C_US_RXRDY); 234

//* open Usart 1 interrupt 235

AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, ID_ US_XBee, USART_INTERRUPT_LEVEL,AT91C_AIC_SRCTYPE_INT_HI 236

AT91F_AIC_EnableIt (AT91C_BASE_AIC, ID_US_X Bee); 237

238

239

//USART Micro-PC 240

COM = BASE_US_PC; 241

/* Configure PIO controllers to periph mode*/ 242

AT91F_PIO_CfgPeriph( AT91C_BASE_PIOA, 243

(( unsigned int) US_RXD_PIN_PC ) | 244

(( unsigned int) US_TXD_PIN_PC ) | 245

(( unsigned int) US_RTS_PIN_PC ) | 246

(( unsigned int) US_CTS_PIN_PC ), // Peripheral A 247

0); // Peripheral B 248


Page 5 of 11

249


AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PM C, 1 << ID_US_PC ) ; 251

// Usart Configure 252

AT91F_US_Configure (COM, MCK, AT91C_US_ASYN C_MODE, AT91_BAUD_RATE, 0); 253

// Enable usart 254

COM->US_CR = AT91C_US_RXEN | AT91C_US_TXEN; 255

//* Enable USART IT error and RXRDY 256

AT91F_US_EnableIt(COM,AT91C_US_RXRDY); 257

//* open Usart 1 interrupt 258

AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, ID_ US_PC, USART_INTERRUPT_LEVEL,AT91C_AIC_SRCTYPE_INT_HIGH 259

AT91F_AIC_EnableIt (AT91C_BASE_AIC, ID_US_P C); 260

//* End 261

} 262

/*----------------------------------------------------------------------------*/ 263

/*INTERN FUNCTION */ 264

/*----------------------------------------------------------------------------*/ 265

__ramfunc void US_FUNC_irq_handler_XBee( void) 266

{ 267

AT91PS_USART USART_pt = BASE_US_XBee; 268

unsigned int status; 269


unsigned int j; 271

static unsigned int i_usart_re; 272

static unsigned char N; 273

static unsigned short CKS; 274

static enum US_TYPE_etat E=EWait; 275

//variable of QoS 276

277

static unsigned char charInFrame= 0; 278

static unsigned int loss= 0; 279

static unsigned int totalReceipt= 0; 280

281

282

AT91F_AIC_DisableIt (AT91C_BASE_AIC, ID_US_XBee); 283

284

//* get Usart status register 285

status = USART_pt->US_CSR; 286

if ( status & AT91C_US_RXRDY){ 287

j = US_GLOB_fifo_rec_XBee.writing; 288

c = ( unsigned char)AT91F_US_GetChar(USART_pt); 289

290

291

US_GLOB_total_char_XBee ++; 292

charInFrame ++; 293

294

switch (E){ 295

case EWait : if( c == '#' ){ 296

E = EIDt1; 297

charInFrame = 0; 298

} 299

else{ 300

US_GLOB_error_char_XBee ++; 301

} 302

CKS = CKS_INIT_VALUE; 303

CKS^= c; 304

break; 305

case EIDt1 : if( c == 'T' ) E = EID_T; 306

else E = EWait; 307

CKS^= c; 308

break; 309

310


Page 6 of 11

case EID_T : E = EID_R; 311

US_GLOB_fifo_rec_XBee.fif o[j][NID_T] = c; 312

CKS ^= c; 313

break; 314

315

case EID_R : E = EID_E; 316

US_GLOB_fifo_rec_XBee.fif o[j][NID_R] = c; 317

CKS ^= c; 318

break; 319

320

case EID_E : E = EID_D; 321

US_GLOB_fifo_rec_XBee.fif o[j][NID_E] = c; 322

CKS ^= c; 323

break; 324

325

case EID_D : E = ETTL; 326

US_GLOB_fifo_rec_XBee.fif o[j][NID_D] = c; 327

CKS ^= c; 328

break; 329

330

case ETTL : E = EPriorite; 331

US_GLOB_fifo_rec_XBee.fif o[j][NTTL] = c; 332

CKS ^= c; 333

break; 334

335

case EPriorite : E = ETime0; 336

US_GLOB_fifo_rec_XBee.fif o[j][NPriorite] = c; 337

CKS ^= c; 338

break; 339

340

case ETime0 : E = ETime1; 341

US_GLOB_fifo_rec_XBee.fif o[j][NDispatchDate] = c; 342

CKS ^= c; 343

break; 344


US_GLOB_fifo_rec_XBee.fif o[j][NDispatchDate+ 1]= c; 346

CKS ^= c; 347

break; 348



CKS ^= c; 351

break; 352

case ETime3 : E = ESizeData; 353


CKS ^= c; 355

break; 356

357

case ESizeData :E = EData; 358

US_GLOB_fifo_rec_XBee.fif o[j][NSizeData] = c; 359

N = c; 360

if(!N) E = ECKS1; // no data 361

i_usart_re = NData; 362

CKS ^= c; 363

break; 364

365

case EData : if(i_usart_re == N- 1 + NData) E = ECKS1; 366

if(i_usart_re > SizeMaxFrame) E = EWait; 367

US_GLOB_fifo_rec_XBee.fif o[j][i_usart_re] = c; 368

i_usart_re ++; 369

CKS ^= c; 370

break; 371

372


Page 7 of 11

case ECKS1 : E = EWait; 373

if(CKS == c){ // frame OK 374

US_GLOB_fifo_rec_XBee.w riting ++; 375

totalReceipt++; 376

if(!(US_GLOB_fifo_rec_XBee.writing < US_CONS_SizeBuff erRec)) 377

US_GLOB_fifo_rec_XBee .writing = 0; 378

US_GLOB_fifo_rec_XBee.l evel ++; 379

if(!(US_GLOB_fifo_rec_XBee.level < US_CONS_SizeBuffer Rec)){ 380

US_GLOB_fifo_rec_XBee .level = US_CONS_SizeBufferRec- 1; 381

loss ++; 382

} 383

} 384

else{ // frame false 385

US_GLOB_error_char_XBee += charInFrame + 1; 386

} 387

break; 388

default: break; 389

} 390

} 391

392

//Function of QoS 393

if(totalReceipt == 10){ 394

LossRateUSART = loss; 395

totalReceipt= 0; 396

loss = 0; 397

} 398

399

//* Reset the satus bit 400

USART_pt->US_CR = AT91C_US_RSTSTA; 401

AT91F_AIC_EnableIt (AT91C_BASE_AIC, ID_US_XBee); 402

} 403

/*----------------------------------------------------------------------------*/ 404

__ramfunc void US_FUNC_irq_handler_PC( void) 405

{ 406

AT91PS_USART USART_pt = BASE_US_PC; 407

unsigned int status; 408


unsigned int j; 410

static unsigned int i_usart_re; 411

static unsigned char N; 412

static unsigned short CKS; 413

static enum US_TYPE_etat E=EWait; 414

//variable of QoS 415

416

static unsigned char charInFrame= 0; 417

static unsigned int loss= 0; 418

static unsigned int totalReceipt= 0; 419

420

421

AT91F_AIC_DisableIt (AT91C_BASE_AIC, ID_US_PC); 422

423

//* get Usart status register 424

status = USART_pt->US_CSR; 425

if ( status & AT91C_US_RXRDY){ 426

j = US_GLOB_fifo_rec_PC.writing; 427

c = ( unsigned char)AT91F_US_GetChar(USART_pt); 428

429

US_GLOB_total_char_PC ++; 430

charInFrame ++; 431

432

switch (E){ 433

case EWait : if( c == '#' ){ 434


Page 8 of 11

E = EIDt1; 435

charInFrame = 0; 436

} 437

else{ 438

US_GLOB_error_char_PC + +; 439

} 440

CKS = CKS_INIT_VALUE; 441

CKS^= c; 442

break; 443

case EIDt1 : if( c == 'T' ) E = EID_T; 444

else E = EWait; 445

CKS^= c; 446

break; 447

448

case EID_T : E = EID_R; 449

US_GLOB_fifo_rec_PC.fifo[ j][NID_T] = c; 450

CKS ^= c; 451

break; 452

453

case EID_R : E = EID_E; 454

US_GLOB_fifo_rec_PC.fifo[ j][NID_R] = c; 455

CKS ^= c; 456

break; 457

458

case EID_E : E = EID_D; 459

US_GLOB_fifo_rec_PC.fifo[ j][NID_E] = c; 460

CKS ^= c; 461

break; 462

463

case EID_D : E = ETTL; 464

US_GLOB_fifo_rec_PC.fifo[ j][NID_D] = c; 465

CKS ^= c; 466

break; 467

468

case ETTL : E = EPriorite; 469

US_GLOB_fifo_rec_PC.fifo[ j][NTTL] = c; 470

CKS ^= c; 471

break; 472

473

case EPriorite : E = ETime0; 474

US_GLOB_fifo_rec_PC.fifo[ j][NPriorite] = c; 475

CKS ^= c; 476

break; 477

478


US_GLOB_fifo_rec_PC.fifo[ j][NDispatchDate] = c; 480

CKS ^= c; 481

break; 482


US_GLOB_fifo_rec_PC.fifo[ j][NDispatchDate+ 1]= c; 484

CKS ^= c; 485

break; 486



CKS ^= c; 489

break; 490

case ETime3 : E = ESizeData; 491


CKS ^= c; 493

break; 494

495

case ESizeData :E = EData; 496


Page 9 of 11

US_GLOB_fifo_rec_PC.fifo[ j][NSizeData] = c; 497

N = c; 498

if(!N) E = ECKS1; // no data 499

i_usart_re = NData; 500

CKS ^= c; 501

break; 502

503

case EData : if(i_usart_re == N- 1 + NData) E = ECKS1; 504

if(i_usart_re > SizeMaxFrame) E = EWait; 505

US_GLOB_fifo_rec_PC.fifo[ j][i_usart_re] = c; 506

i_usart_re ++; 507

CKS ^= c; 508

break; 509

510

case ECKS1 : E = EWait; 511

if(CKS == c){ // frame OK 512

US_GLOB_fifo_rec_PC.wri ting ++; 513

totalReceipt++; 514

if(!(US_GLOB_fifo_rec_PC.writing < US_CONS_SizeBuffer Rec)) 515

US_GLOB_fifo_rec_PC.w riting = 0; 516

US_GLOB_fifo_rec_PC.lev el ++; 517

if(!(US_GLOB_fifo_rec_PC.level < US_CONS_SizeBufferRe c)){ 518

US_GLOB_fifo_rec_PC.l evel = US_CONS_SizeBufferRec- 1; 519

loss ++; 520

} 521

} 522

else{ // frame false 523

US_GLOB_error_char_PC + = charInFrame + 1; 524

} 525

break; 526

default: break; 527

} 528

} 529

530

//Function of QoS 531

if(totalReceipt == 10){ 532

LossRateUSART = loss; 533

totalReceipt= 0; 534

loss = 0; 535

} 536

537

//* Reset the satus bit 538

USART_pt->US_CR = AT91C_US_RSTSTA; 539

AT91F_AIC_EnableIt (AT91C_BASE_AIC, ID_US_PC); 540

} 541

542

543

/*----------------------------------------------------------------------------*/ 544

unsigned char US_FUNC_trans_char( unsigned char c, unsigned int v, unsigned char CKS){ 545

switch(v){ 546

case 1 : while(!AT91F_US_TxReady (BASE_US_XBee )); 547

AT91F_US_PutChar (BASE_US_XBee,c); 548

return CKS^c; 549

550

case 2 : while(!AT91F_US_TxReady (BASE_US_PC )); 551

AT91F_US_PutChar (BASE_US_PC,c); 552

return CKS^c; 553

554

default : return CKS^c; 555

} 556

} 557

/*----------------------------------------------------------------------------*/ 558


Page 10 of 11

unsigned char US_FUNC_trans_int( unsigned int c, unsigned int v, unsigned char CKS){ 559

unsigned char byte0; //MSB 560

unsigned char byte1; // 561

unsigned char byte2; // 562

unsigned char byte3; //LSB 563

unsigned char cks; 564

byte0 = ( unsigned char)((c& 0xFF000000 )>> 24); 565

byte1 = ( unsigned char)((c& 0x00FF0000 )>> 16); 566

byte2 = ( unsigned char)((c& 0x0000FF00 )>> 8); 567

byte3 = ( unsigned char)(c& 0x0000000FF ); 568

cks=US_FUNC_trans_char(byte0,v,CKS); 569

cks=US_FUNC_trans_char(byte1,v,cks); 570

cks=US_FUNC_trans_char(byte2,v,cks); 571

return US_FUNC_trans_char(byte3,v,cks); 572

} 573

/*----------------------------------------------------------------------------*/ 574

unsigned char US_FUNC_trans_short( unsigned short c, unsigned int v, unsigned char CKS){ 575

unsigned char byte0; //MSB 576

unsigned char byte1; //LSB 577

unsigned char cks; 578

byte0 = ( unsigned char)((c& 0xFF00 )>> 8); 579

byte1 = ( unsigned char)(c& 0x00FF ); 580

cks = US_FUNC_trans_char(byte0,v,CKS); 581

return US_FUNC_trans_char(byte1,v,cks); 582

} 583

584

585

/*----------------------------------------------------------------------------*/ 586

unsigned int US_FUNC_recev_data_XBee(T_Frame *frame){ 587

unsigned int i; 588

unsigned int j; 589

unsigned int N; 590


592

out = 1; 593

if(US_GLOB_fifo_rec_XBee.level > 0){ 594

j=US_GLOB_fifo_rec_XBee.writing; 595

for(i= 0; i<US_GLOB_fifo_rec_XBee.level; i++){ 596

if(j == 0) j = US_CONS_SizeBufferRec- 1; 597

else j--; 598

} 599

frame->DeliveryDate = TI_FUNC_time(); 600

frame->ID_T =US_GLOB_fifo_rec_XBee.fifo[j][ NID_T]; 601

frame->ID_R =US_GLOB_fifo_rec_XBee.fifo[j][ NID_R]; 602

frame->ID_E =US_GLOB_fifo_rec_XBee.fifo[j][ NID_E]; 603

frame->ID_D =US_GLOB_fifo_rec_XBee.fifo[j][ NID_D]; 604

605

frame->TTL =US_GLOB_fifo_rec_XBee.fifo[j][ NTTL]; 606

607

frame->Priorite =US_GLOB_fifo_rec_XBee.fif o[j][NPriorite]; 608

609

frame->DispatchDate =US_GLOB_fifo_rec_XBee. fifo[j][NDispatchDate]<< 24; 610

frame->DispatchDate +=US_GLOB_fifo_rec_XBee .fifo[j][NDispatchDate+ 1]<< 16; 611

frame->DispatchDate +=US_GLOB_fifo_rec_XBee .fifo[j][NDispatchDate+ 2]<< 8; 612

frame->DispatchDate +=US_GLOB_fifo_rec_XBee .fifo[j][NDispatchDate+ 3]; 613

614

frame->SizeData =N =US_GLOB_fifo_rec_XBee.fifo[ j][NSizeData]; 615

for(i= 0 ; i< N ; i++){ 616

frame->Data[i] =US_GLOB_fifo_rec_XBee.fifo[ j][NData+i]; 617

} 618

US_GLOB_fifo_rec_XBee.level--; 619

out = 0; 620


Page 11 of 11

} 621

return out; 622

} 623

/*----------------------------------------------------------------------------*/ 624

unsigned int US_FUNC_recev_data_PC(T_Frame *frame){ 625

unsigned int i; 626

unsigned int j; 627

unsigned int N; 628


630

out = 1; 631

if(US_GLOB_fifo_rec_PC.level > 0){ 632

j=US_GLOB_fifo_rec_PC.writing; 633

for(i= 0; i<US_GLOB_fifo_rec_PC.level; i++){ 634

if(j == 0) j = US_CONS_SizeBufferRec- 1; 635

else j--; 636

} 637

frame->DeliveryDate = TI_FUNC_time(); 638

frame->ID_T =US_GLOB_fifo_rec_PC.fifo[j][NI D_T]; 639

frame->ID_R =US_GLOB_fifo_rec_PC.fifo[j][NI D_R]; 640

frame->ID_E =US_GLOB_fifo_rec_PC.fifo[j][NI D_E]; 641

frame->ID_D =US_GLOB_fifo_rec_PC.fifo[j][NI D_D]; 642

643

frame->TTL =US_GLOB_fifo_rec_PC.fifo[j][NT TL]; 644

645

frame->Priorite =US_GLOB_fifo_rec_PC.fifo[ j][NPriorite]; 646

647

frame->DispatchDate =US_GLOB_fifo_rec_PC.fi fo[j][NDispatchDate]<< 24; 648

frame->DispatchDate +=US_GLOB_fifo_rec_PC.f ifo[j][NDispatchDate+ 1]<< 16; 649

frame->DispatchDate +=US_GLOB_fifo_rec_PC.f ifo[j][NDispatchDate+ 2]<< 8; 650

frame->DispatchDate +=US_GLOB_fifo_rec_PC.f ifo[j][NDispatchDate+ 3]; 651

652

frame->SizeData =N =US_GLOB_fifo_rec_PC.fifo[j] [NSizeData]; 653

for(i= 0 ; i< N ; i++){ 654

frame->Data[i] =US_GLOB_fifo_rec_PC.fifo[j] [NData+i]; 655

} 656

US_GLOB_fifo_rec_PC.level--; 657

out = 0; 658

} 659

return out; 660

} 661

662

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Src\Ordonnenceur.c

Page 1 of 5

#include<stdlib.h> 1

#include"usart.h" 2

#include"frame.h" 3

#include"Ordonnenceur.h" 4

#include"QoS.h" 5

6

#define OR_CONS_SizeMaxDonne 256 7

#define OR_CONS_CRITERE_MIN 0 8

#define OR_CONS_CRITERE_MAX 7 9

10

typedef struct OR_TYPE_element{ 11

struct OR_TYPE_element* precedant; 12

int critere; 13

unsigned int cannal; 14

T_Frame *donnee; 15

struct OR_TYPE_element* suivant; 16

}OR_TYPE_element; 17

18

19

typedef struct OR_TYPE_file_attente{ 20

OR_TYPE_element tete; 21

OR_TYPE_element queue; 22

int taille; 23

int tailleMax; 24

} OR_TYPE_file_attente; 25

26

/*------------------------------------------------- ---------------------------*/ 27

/*PROTOTYPE */ 28

/*------------------------------------------------- ---------------------------*/ 29

// user function 30

void OR_FUNC_init(void); 31

int OR_FUNC_inser_message(T_Frame *Message, unsigned int v); 32

unsigned int FunctionLossRateOrdo(void); 33

unsigned int FunctionRateFilling(void); 34

int OR_FUNC_envoi(void); 35

unsigned int OrdoSizeLine(void); 36

// intern function 37

void OR_FUNC_initFileAttente (OR_TYPE_file_attente* file,int tailleMax); 38

int OR_FUNC_inser_messageFileAttente(OR_TYPE_file_attente * file, T_Frame* message, unsigned int 39

int OR_FUNC_envoiFileAttente(OR_TYPE_file_attente * file); 40

41

/*------------------------------------------------- ---------------------------*/ 42


/*------------------------------------------------- ---------------------------*/ 44

OR_TYPE_file_attente fileMessageUrgent; 45

OR_TYPE_file_attente fileMessageImportant; 46

OR_TYPE_file_attente fileMessageGrandeTaille; 47

OR_TYPE_file_attente fileMessageMoyenneTaille; 48

OR_TYPE_file_attente fileMessagePetiteTaille; 49

unsigned int LossRateOrdo; 50

unsigned int NCharInFile; 51

52

53

/*------------------------------------------------- ---------------------------*/ 54


/*------------------------------------------------- ---------------------------*/ 56

void OR_FUNC_init(void){ 57

//declaration en variable global 58

OR_FUNC_initFileAttente (&fileMessageUrgent,2); 59

OR_FUNC_initFileAttente (&fileMessageImportant,3); 60

OR_FUNC_initFileAttente (&fileMessageGrandeTaille,2); 61

OR_FUNC_initFileAttente (&fileMessageMoyenneTaille,3); 62


Page 2 of 5

OR_FUNC_initFileAttente (&fileMessagePetiteTaille,4); 63

NCharInFile = 0; 64

} 65

/*------------------------------------------------- ---------------------------*/ 66

int OR_FUNC_inser_message(T_Frame *Message,unsigned int v){ 67

int error; 68

int taille; 69

char critere; 70

71

error = 1; // default error 72

73

if(Message->TTL == 0) return 0; // on tue le message. 74

75

critere = Message->Priorite; 76

77

// critere = 0 message -> fileMessageUrgent 78

// critere = 1 message -> fileMessageImporta nt 79

// critere = 2 message -> fileMessageAutre 80

switch (critere){ 81

case 0 :error = OR_FUNC_inser_messageFileAttente(&fileMessageUrgent, Message,v); 82

if(!(error==2))break; 83

case 1 :error = OR_FUNC_inser_messageFileAttente(&fileMessageImportant, Message,v); 84

if(!(error==2))break; 85

case 2 : 86

default:taille = Message->SizeData; 87

if(taille < (SizeMaxFrame/3)){ 88

error = OR_FUNC_inser_messageFileAttente(&fileMessagePetiteTaille, Message,v); 89

break; 90

} 91

if(taille < (SizeMaxFrame*2/3)){ 92

error = OR_FUNC_inser_messageFileAttente(&fileMessageMoyenneTaille, Message,v); 93

break; 94

} 95

error = OR_FUNC_inser_messageFileAttente(&fileMessageGrandeTaille, Message,v); 96

break; 97

} 98

return error; 99

} 100

/*------------------------------------------------- ---------------------------*/ 101

int OR_FUNC_envoi(void){ 102

int K; 103

104

if(!OR_FUNC_envoiFileAttente(&fileMessageUrgent)) 105

return 0; 106

107

K = QoS_Nombre_Erreur(); 108

if(K < 100){ 109

if(!OR_FUNC_envoiFileAttente(&fileMessageImportant)) 110

return 0; 111

} 112

113

K = QoS_BP(); 114

if(K > 70){ // Bamde passante libre estimer > 70% 115

if(!OR_FUNC_envoiFileAttente(&fileMessageGrandeTaille)) 116

return 0; 117

} 118

if(K > 40){ // Bamde passante libre estimer > 40% 119

if(!OR_FUNC_envoiFileAttente(&fileMessageMoyenneTaille)) 120

return 0; 121

} 122

// Bamde passante libre estimer < 40% 123

if(!OR_FUNC_envoiFileAttente(&fileMessagePetiteTaille)) 124


Page 3 of 5

return 0; 125

return 1; 126

} 127

/*------------------------------------------------- ---------------------------*/ 128

unsigned int FunctionLossRateOrdo(void){ 129

return LossRateOrdo; 130

} 131

/*------------------------------------------------- ---------------------------*/ 132

unsigned int FunctionRateFilling(void){ 133

unsigned int RateFilling; 134

RateFilling = fileMessagePetiteTaille.taille; 135

RateFilling += fileMessageMoyenneTaille.taille; 136

RateFilling += fileMessageGrandeTaille.taille; 137

RateFilling += fileMessageImportant.taille; 138

RateFilling += fileMessageUrgent.taille; 139

140

141

142

return RateFilling; 143

} 144

/*------------------------------------------------- ---------------------------*/ 145

unsigned int OrdoSizeLine(void){ 146

return NCharInFile; 147

} 148

/*------------------------------------------------- ---------------------------*/ 149

/*INTERN FUNCTION */ 150

/*------------------------------------------------- ---------------------------*/ 151

void OR_FUNC_initFileAttente (OR_TYPE_file_attente* file,int tailleMax){ 152

file->tete.precedant = NULL; 153

file->tete.critere = OR_CONS_CRITERE_MIN; 154

file->tete.suivant = &(file->queue); 155

file->queue.precedant = &(file->tete); 156

file->queue.critere = OR_CONS_CRITERE_MAX + 1; 157

file->queue.suivant = NULL; 158

file->taille = 0; 159

file->tailleMax = tailleMax; 160

} 161

/*------------------------------------------------- ---------------------------*/ 162

int OR_FUNC_inser_messageFileAttente(OR_TYPE_file_attente * file, T_Frame* message,unsigned int v){ 163

int i; 164

unsigned int N; 165

static unsigned int lossOrdo=0; //QoS:nombre d'echec pour cause de file pleinne 166

static unsigned int NMessage=0; //QoS:nombre de fois d'appel de cette fonction 167

OR_TYPE_element *nouveau_element; 168

OR_TYPE_element *elementCourant; 169

170

//QoS 171

if(NMessage == 10){ 172

LossRateOrdo = lossOrdo; 173

lossOrdo=0; 174

NMessage=0; 175

} 176

NMessage++; 177

//verification 178

if(!(file->taille < file->tailleMax)){ 179

lossOrdo ++; 180

return 2; //error full line 181

} 182

N = (unsigned int)message->SizeData; 183

if( N > SizeMaxData) 184

return 1; //error too many data 185

//memory allocation 186


Page 4 of 5

if ((nouveau_element = (OR_TYPE_element *) malloc (sizeof (OR_TYPE_element))) == NULL) 187

return 1; //error full memory 188

if ((nouveau_element->donnee = (T_Frame *) malloc(N + SizeHeadFrame))== NULL){ 189

free(nouveau_element); 190

return 1; //error full memory 191

} 192

//OR_FUNC_init du nouvelle element 193

nouveau_element->critere = message->Priorite; 194

nouveau_element->cannal = v; 195

//save message in the memory 196

nouveau_element->donnee->ID_T = message->ID_T; 197

nouveau_element->donnee->ID_R = message->ID_R; 198

nouveau_element->donnee->ID_E = message->ID_E; 199

nouveau_element->donnee->ID_D = message->ID_D; 200

201

nouveau_element->donnee->TTL = message->TTL; 202

nouveau_element->donnee->Priorite = message->Priorite; 203

204

nouveau_element->donnee->SizeData = message->SizeData; 205

for(i=0; i<N; i++){ 206

nouveau_element->donnee->Data[i] = message->Data[i]; 207

} 208

// recherche de sa place dans la file d'attente 209

elementCourant = &file->queue; 210

while( nouveau_element->critere < elementCourant->critere){ 211

elementCourant = elementCourant->precedant; 212

} 213

//insertion dans la file d'attente // A - New - B 214

nouveau_element->precedant = elementCourant; // A <- New - B 215

elementCourant = elementCourant->suivant; // 216

nouveau_element->suivant = elementCourant; // A <- New -> B 217

elementCourant->precedant = nouveau_element; // A <- New <-> B 218

elementCourant = nouveau_element->precedant; // 219

elementCourant->suivant = nouveau_element; // A <-> New <-> B 220

//mise a jour des information de file d'attente 221

file->taille++; 222

NCharInFile += message->SizeData + SizeHeadFrame; 223

224

return 0; 225

} 226

/*------------------------------------------------- ---------------------------*/ 227

int OR_FUNC_envoiFileAttente(OR_TYPE_file_attente * file){ 228

OR_TYPE_element *supp_element; 229

OR_TYPE_element *elementCourant; 230

231

if (file->taille == 0) 232

return 1; // error void line 233

234

supp_element = file->tete.suivant; 235

236

NCharInFile -= supp_element->donnee->SizeData + SizeHeadFrame; 237

//envoi du message 238

if(US_FUNC_trans_data(supp_element->donnee,supp_element->cannal)) return 1; //error 239

240

//retrait de la file d'attente 241

file->tete.suivant = supp_element->suivant; 242

243

elementCourant = file->tete.suivant; 244

245

elementCourant->precedant = &file->tete; 246

247

//liberation de la memoire 248


Page 5 of 5

free (supp_element->donnee); 249

free (supp_element); 250

251

//mise a jour des information de file d'attente 252

file->taille--; 253

return 0; 254

} 255

256

unsigned int OR_FUNC_recev_data(T_Frame *frame){ 257

return US_FUNC_recev_data(frame); 258

} 259

260

261

262

263

264

265

266

267

268

269

270

C:\Documents and Settings\arnaud.abonnat\Mes docume nts\IAR_programme\Prog1_07_06_10\Src\routage.c

Page 1 of 2

#include "routage.h" 1

#include "frame.h" 2



#include "voisinage.h" 5


7

T_Frame MessageRecu; 8

9

10

//message de vie 11

T_Frame MessageHello; 12

13

14

void RO_FUNC_routage( void){ 15

static unsigned int tmp_appliA= 0; 16

static unsigned int tmp_appliB= 0; 17

unsigned int error= 0; 18

19

if(!(OR_FUNC_recev_data(&MessageRecu))){ 20

VO_FUNC_mise_a_jour(&MessageRecu); 21

22

switch(MessageRecu.ID_D){ 23

case ID_NOEUD: //Mise a jour du capture + ... 24

if(MessageRecu.ID_E == MessageRecu.ID_T){ //message d'AROCCAM 25

TI_FUNC_MiseAJour_Tim e(MessageRecu.DispatchDate); 26

} 27

break; 28

case 1 : 29

case 2 : 30

if(MessageRecu.ID_E == MessageRecu.ID_T){ //message d'AROCCAM 31

if(MessageRecu.ID_E == MessageRecu.ID_D){ //echo 32

MessageRecu.ID_T = ID_NOEUD; 33

error = OR_FUNC_ins er_message(&MessageRecu,PC); 34

} 35

else{ //transfert 36

MessageRecu.ID_T = ID_NOEUD; 37

error = OR_FUNC_ins er_message(&MessageRecu,XBee); 38

} 39

} 40

else{ //message d'un noeud 41

MessageRecu.ID_T = ID _NOEUD; 42

error = OR_FUNC_inser _message(&MessageRecu,PC); 43

} 44

break; 45

default : //rien faire. destruction du message 46

break; 47

} 48

//end routage 49

} 50

51

VO_FUNC_Nettoy(); 52

if(!OR_FUNC_envoi()){ 53

tmp_appliB = TI_FUNC_time(); 54

} 55

tmp_appliA= TI_FUNC_time(); 56

57

if(tmp_appliA < tmp_appliB) tmp_appliB=tmp_appliA; 58

if((tmp_appliA - tmp_appliB)>= 1000 ){ 59

tmp_appliB=tmp_appliA; 60

61

62

C:\Documents and Settings\arnaud.abonnat\Mes docume nts\IAR_programme\Prog1_07_06_10\Src\routage.c

Page 2 of 2

error = OR_FUNC_inser_message(&MessageHel lo,XBee); 63

error = OR_FUNC_inser_message(&MessageHel lo,PC); 64

} 65

66

} 67

68

void RO_FUNC_init( void){ 69

VO_FUNC_init(); 70

71

MessageHello.ID_T = ID_NOEUD; 72

MessageHello.ID_R = 0xFF; 73

MessageHello.ID_E = ID_NOEUD; 74

MessageHello.ID_D = 0xFF; 75

MessageHello.TTL = 0x08 ; 76

MessageHello.Priorite = 0x00 ; 77

MessageHello.Data[ 0]= 'H' ; 78

MessageHello.Data[ 1]= 'e' ; 79

MessageHello.Data[ 2]= 'l' ; 80

MessageHello.Data[ 3]= 'l' ; 81

MessageHello.Data[ 4]= 'o' ; 82

MessageHello.SizeData = 5; 83

} 84

85

86

87

88

89

90

C:\Documents and Settings\arnaud.abonnat\Mes documents\IAR_programme\Prog1_07_06_10\Src\QoS.c

Page 1 of 1


#include "voisinage.h" 2


4

5

/*----------------------------------------------------------------------------*/ 6

/*Prototype */ 7

/*----------------------------------------------------------------------------*/ 8

//user function 9

unsigned int QoS_BP(void); 10

void QoS_mise_a_jour(void); 11

unsigned int QoS_Nombre_Erreur(void); 12

//interne 13

14

//interne + userDeBug 15

16

/*----------------------------------------------------------------------------*/ 17


/*----------------------------------------------------------------------------*/ 19

unsigned int QS_GLOB_erreur_recu; 20

unsigned int QS_GLOB_total_recu; 21

unsigned int QS_GLOB_total_recu_max; 22

23

/*----------------------------------------------------------------------------*/ 24


/*----------------------------------------------------------------------------*/ 26

unsigned int QoS_BP(void){ 27

unsigned int K; 28

K = 100*(QS_GLOB_total_recu_max - QS_GLOB_total_recu); 29

// D = (1 + FunctionNombreDeVoisin()); 30

return K/QS_GLOB_total_recu_max; 31

}; 32

/*----------------------------------------------------------------------------*/ 33

void QoS_mise_a_jour(void){ 34

static unsigned int tempsA,tempsB = 0; 35

36

tempsA= TI_FUNC_time(); 37

if((tempsA-tempsB)>1000){ 38

tempsB = tempsA; 39

QS_GLOB_erreur_recu = US_FUNC_error_char_XBee() + US_FUNC_error_char_PC(); 40

QS_GLOB_total_recu = US_FUNC_total_char_XBee() + US_FUNC_total_char_PC(); 41

42

if(QS_GLOB_total_recu > QS_GLOB_total_recu_max) 43

QS_GLOB_total_recu_max = QS_GLOB_total_recu; 44

} 45

} 46

/*----------------------------------------------------------------------------*/ 47

unsigned int QoS_Nombre_Erreur(void){ 48

return QS_GLOB_erreur_recu; 49

} 50

51

52

53