real-time bluetooth communication system for control of a mobile robot

Systeme temps reel communicant Bluetoothpour le controle de robot mobile

Real-time Bluetooth communication system forcontrol of a mobile robot

Fabrice Peyrard∗

Ces travaux de recherche presentent une plate-forme de mesures de liens asynchrones Bluetooth afin de disposer des contraintes temporelles intrinsequesde ce reseau et protocole de communication. Ces mesures temporelles sont necessaires a l’application qu’on souhaite mettre en oeuvre pour le controle etla commande de robot mobile au travers du lien de communication Bluetooth. On presente la plate-forme ainsi que le protocole de mesure qu’on a realisea partir de systemes d’exploitation temps reel communicants. On a developpe une application de traitement de donnees radio et temporelles permettantune evaluation en temps reel du comportement global du systeme communicant.

This paper presents a measurement platform of Bluetooth asynchronous links in order to obtain the intrinsic temporal constraints of this network andcommunication protocol. These temporal measurements are necessary for the application the authors wish to implement for mobile robot control througha Bluetooth communication link. The platform, as well as the measurement protocol, which is based on real-time communication operating systems, ispresented. An application of radio and temporal data processing allowing a real-time evaluation of the global behaviour of the communicating system hasbeen developed.

Mots cles / Keywords : evaluation de performances; systeme temps reel; WPAN Bluetooth / Bluetooth WPAN; performance evaluation; real-time system

I Introduction

Les objectifs de nos travaux de recherche sont axes sur la mise en oeu-vre de l’evaluation de performances d’une plate-forme de communi-cation Bluetooth en mode point a point pour le controle et la com-mande d’un robot mobile pilote par un systeme distant temps reel.En fonction des proprietes du lien de communication Bluetooth dansun tel systeme, nous pouvons determiner grace a la plate-forme demetrologie, les contraintes temporelles ainsi supportees. Ces dernieresseront donc les parametres d’entree de la boucle d’asservissement pourle controle/commande du robot au travers du reseau Bluetooth.

Les objectifs des travaux presentes dans cet article sont de mettreen evidence les proprietes intrinseques d’un lien Bluetooth point apoint en mode asynchrone de type DM1 (Data – Medium rate). Nouspresentons la mise en oeuvre de la plate-forme de metrologie, le pro-tocole associe ainsi que les resultats obtenus devant etre pris en con-sideration comme parametres d’entree de la boucle d’asservissementde la commande de processus a distance.

II Contexte general des travaux de recherche

Ces travaux s’inscrivent dans une etude globale de controle et de com-mande de robots mobiles cooperatifs pilotes par des systemes tempsreel. L’originalite finale envisagee de nos travaux est de disposer d’unensemble de robots mobiles cooperants pour le transport et la manu-tention d’objets volumineux. Les robots cooperants sont distants d’unequinzaine de metres et sont au nombre de 7 au maximum correspon-dant ainsi a la topologie d’un reseau de type Scatternet Bluetooth [1].Les robots sont pilotes par un poste de controle jouant le role de maıtre

∗Fabrice Peyrard est au Laboratoire de recherche LATTIS–EA4155, 1,place Georges Brassens BP 60073, 31703 Blagnac Cedex, France. Courriel :[email protected].

Bluetooth. Dans une telle application les communications radio sont enchamp libre entre les robots et le poste de controle. Le WPAN mobileest donc naturellement soumis aux perturbations de son environnementd’evolution, c’est-a-dire la nature des materiaux de l’environnement,mais en aucun cas a partir d’obstacle materiel entre les entites com-municantes. Ces travaux font donc l’objet de recherches appliqueesdans le domaine de la cohabitation et de l’analyse de performances desysteme [2] d’exploitation temps reel tel que RTAI (RealTime Appli-cation Interface) [3]–[4] et des modules de communication Bluetoothsur une interface asynchrone RS-232. Cette partie a fait deja l’objetde publications [5]–[6]. Une seconde partie de recherche theoriqueconsiste a modeliser a l’aide de RdPTS (reseaux de Petri temporisesstochastiques), a partir de la norme Bluetooth [7], le comportement dece protocole de communication en particulier pour les paquets de typeDM1 en integrant les aspects probabilistes d’erreurs de trames et lesaspects temporels de la communication. Cet axe de recherche a faitl’objet des publications suivantes [8]–[10]. L’objectif final est de pou-voir comparer et analyser les resultats theoriques obtenus par les outilsde simulation des RdPTS et ceux de la plate-forme de metrologie, afinde caracteriser les contraintes temporelles minimales a respecter pourla boucle d’asservissement du controle et de la commande d’un robotmobile. Ceci permettra en particulier d’evaluer les retards engendres ala fois par les systemes d’exploitation temps reel et la communicationsans fil Bluetooth.

III Environnement temps reel communicant

III.A Systeme temps reel RTAIParmi les systemes d’exploitation, nous pouvons distinguer deuxfamilles, les systemes d’exploitation a temps partage et les systemesd’exploitation temps reel. Dans un systeme d’exploitation a tempspartage, l’ordonnanceur partage le temps du processeur entre lesdifferentes taches executables. Un systeme d’exploitation temps reeldoit en plus garantir la disponibilite des ressources materielles pourdes taches definies, dans des limites temporelles precises. Les temps

Can. J. Elect. Comput. Eng., Vol. 33, No. 2, Spring 2008

64 CAN. J. ELECT. COMPUT. ENG., VOL. 33, NO. 2, SPRING 2008

Figure 1 : Acces au port serie sous RTAI.

Figure 2 : Modes de gestion de l’horloge avec RTAI.

d’acquisition et de traitement de l’information doivent aussi etreinferieurs aux temps d’occurrence de cette information [11].

Parmi l’ensemble des systemes temps reel en licence libre,RTAI [4], [12] est celui retenu, car il repond a l’ensemble des criteresspecifiques de notre application en termes de performances, de tailledu noyau, de latence, d’acces libre aux codes sources et a la gestiondes ports serie.

RTAI est un projet inspire de RTLinux [13], qui apporte desameliorations et des corrections concernant les modes temps reel et lagestion des nombres flottants. Il permet aussi de developper des tachestemps reel dans l’espace utilisateur avec une granularite temporellesuffisamment fine grace a l’extension LXRT (LinuX Real Time) [14].

Parmi les criteres, que nous venons de citer, auquel doit repondrele systeme temps reel retenu, nous avons porte notre attention touteparticuliere sur les mecanismes temps reel de la gestion des ports seriepour communiquer avec les modules Bluetooth ainsi que la gestionde l’horloge pour fournir la meilleure precision lors de la metrologiedu systeme global communicant. Les systemes temps reel RTLinux,QNX [8] et VxWorks [15] auraient pu etre des candidats potentielspour notre application temps reel communicante, mais ne satisfaisaientpas a tous les criteres techniques de communications par port serie, dedisponibilite des codes sources libres et des couts reduits des licencesd’utilisation pour notre prototype. Ce sont les principales raisons del’orientation de notre choix vers RTAI.

III.A.1 Acces au port serie dans le mode LXRTComme nous l’avons enonce precedemment, l’architecture RTAI offredeux espaces de developpement :

• l’espace noyau, qui permet de developper des applications tempsreel accedant directement aux differents modules qui composentle noyau, offrant ainsi souplesse et performance lors de sonutilisation,

• l’espace utilisateur LXRT, qui permet de developper des tachestemps reel dont l’interaction avec le noyau est protegee.

Dans le cadre de nos travaux sur les communications temps reel,nous avions la possibilite soit d’ecrire une interface specifique asyn-chrone avec la gestion des interruptions, soit d’utiliser une des inter-faces offertes par les modules disponibles de communication. RTAIoffre deux interfaces de gestion des ports asynchrones. L’interfaceRT COM [16] issue initialement de RTLinux et son evolution pourRTAI, l’interface SPDRV (Serial Port DRiVer) [17]. D’apres lesspecifications de SPDRV et des mesures temporelles relevees [18]–[19], nous avons porte notre choix sur son utilisation, ne necessitantpas l’ecriture specifique d’une interface temps reel asynchrone.

L’utilisation de l’interface SPDRV peut s’effectuer en acces directau noyau par le biais du module rtai spdrv.o ou bien en modeutilisateur protege par le biais du module rtai spdrv lxrt.o,comme le presente la figure 1.

Nous presentons au paragraphe III.A.4 une analyse comparative desprimitives d’emission et de reception de SPDRV dans les modes noyauet utilisateur.

III.A.2 Gestion de l’horlogeRTAI offre deux modes d’utilisation de l’horloge, le mode periodiqueet le mode One Shot. Ces deux modes s’utilisent en moded’exclusion mutuelle. La figure 2 illustre ces deux modes de gestionde l’horloge systeme.

Le mode periodique utilise l’interruption du composant materiel8254 avec une frequence maximale de 1.193 18 Mhz, ce qui corre-spond a une periodicite de 838 ns. Le codage des valeurs d’horloges’effectue sur 32 bits.

Le mode One Shot est base sur la frequence du processeur pourincrementer un registre specifique de 64 bits a chaque cycle du pro-cesseur. Il utilise pour cela la fonction RDTSC (ReaD Time StampCounter) [20]. Par consequent, plus la frequence du processeur estelevee, plus la periode d’echantillonnage est precise.

Pour l’ensemble des mesures temporelles que nous avons realisesur la plate-forme de metrologie, nous avons utilise le mode de gestionde l’horloge One Shot pour sa precision sur un systeme monopro-cesseur cadence a 1 GHz.

III.A.3 Temps acces des primitivesDans l’objectif de disposer d’une reference temporelle pour comparerles mesures des communications Bluetooth, nous avons dans un pre-mier temps mesure localement sur le systeme temps reel du poste decontrole, les temps d’execution des primitives d’entree/sortie sur leport serie dans le mode utilisateur LXRT. Nous avons donc mis enoeuvre un systeme boucle entre les ports serie afin de s’affranchirdes problemes de synchronisation d’horloges distribuees. La figure 3presente les temps d’ecriture et de lecture mesures en fonction dela taille du message transmis. Le temps d’execution de la primi-tive d’emission varie entre 30 µs et 60 µs pour des paquets de 1 a600 octets. Le temps d’execution de la primitive de reception varielui sensiblement autour de 8 µs, quelque soit la taille de ces memespaquets.

La primitive d’emission necessite un temps d’execution plus longque celle de reception, car l’ecriture dans le buffer logiciel temps reels’effectue sequentiellement, alors que la reception se realise par bloc.La figure 4 resume les valeurs temporelles mesurees en particulierlors de l’initialisation de la tache temps reel ainsi que l’ouverture duport serie.

PEYRARD: SYSTEME TEMPS REEL COMMUNICANT BLUETOOTH POUR LE CONTROLE DE ROBOT MOBILE 65

Figure 3 : Temps d’execution des primitives temps reel d’entree/sortie.

Figure 4 : Valeurs temporelles liees a une tache temps reel communicante.

Les temps d’initialisation de la tache temps reel (30 µs) etd’ouverture du port serie (35 µs) doivent etre pris en compte une seulefois lors de l’activation du processus communicant et restent dans desproportions raisonnables. Par contre, le temps d’execution de la primi-tive d’ecriture est penalisant lors de chaque emission. Ce phenomeneest a prendre en consideration dans la boucle d’asservissement ducontrole/commande de robot a distance par un lien Bluetooth.

III.A.4 Performances des modes noyau et LXRTNous avons evalue les temps d’execution des primitives de lecture etd’ecriture des ports serie dans le mode noyau et nous les avons com-pare avec les resultats precedemment obtenus dans le mode LXRT. Lafigure 5 represente la duree d’execution de la primitive rt spwritedans les deux modes noyau et LXRT.

Contrairement au mode LXRT, nous pouvons constater dans lemode noyau une quasi-stabilite du temps d’execution (50 µs) de la pri-mitive d’ecriture. Nous constatons aussi que ce mode noyau apporteune sensible amelioration de ce temps d’execution.

La figure 6 illustre la comparaison des temps d’execution de laprimitive de lecture dans les modes noyau et LXRT. Nous pouvonsconstater que dans le mode noyau le temps d’execution de la primi-tive de lecture est proche de 1 µs avec une stabilite temporelle quasiparfaite. Ceci est beaucoup plus satisfaisant que l’execution de cettememe primitive en mode LXRT, dont le temps est borne par 10 µs.

Suite a ces evaluations de performances, nous retenons que l’utili-sation des primitives d’entree/sortie sur le port serie s’avere efficace etstable temporellement en mode noyau, alors que le mode LXRT induitdes retards considerables. C’est donc ce mode temps reel que nousretenons pour la suite des evaluations temporelles.

III.A.5 ConclusionNous venons de presenter les caracteristiques principales du systemetemps reel RTAI ainsi que son evaluation temporelle dans les modesnoyau et LXRT pour des communications temps reel par port serie.Cette etape preliminaire etait indispensable afin de connaıtre les limitesdu systeme temps reel pour interconnecter des modules de communi-cation sans fil Bluetooth.

Figure 5 : Temps d’execution de la primitive rt spwrite.

Figure 6 : Temps d’execution de la primitive rt spread.

Nous presentons par la suite les caracteristiques du reseau Bluetoothafin d’offrir un support et un ensemble de protocoles de communica-tion entre le poste de commande et le robot mobile.

III.B Systemes communicants BluetoothParmi l’ensemble des reseaux locaux ou personnels sans fil, nousavons retenu le reseau Bluetooth [21]–[22] pour notre environnementexperimental. En effet ce type de reseau a fait l’objet de nombreuxtravaux [5]–[6], [23] au sein de notre laboratoire. Le couplage avecRTAI nous a permis de l’experimenter et de l’evaluer dans un environ-nement temps reel.

III.B.1 TopologiesLe reseau Bluetooth propose trois types de topologies, illustres sur lafigure 7 :

• point a point : 1 station maıtre et 1 station esclave,

• point-multipoints : 1 station maıtre et 7 stations esclaves, appeleeaussi Piconet,

• reseau maille : agregation de 10 Piconets, appelee aussiScatternet.

La topologie point a point est parfaitement adaptee a l’architecturedu reseau de la plate-forme de metrologie, a savoir un poste de com-mande et un robot mobile.

III.B.2 Canaux de communicationBluetooth offre deux types de canaux de communications :

• les canaux synchrones SCO (Synchronous-Connection-Oriented), dedies principalement au transport de la voix,

• les canaux asynchrones ACL (Asynchronous ConnectionLess),dedies principalement au transport des donnees.

Le tableau 1 resume l’ensemble des liens asynchrones offerts ainsique les debits associes. Les differents debits offerts par les liensACL sont dus en particulier a une utilisation variable du nombred’intervalles temporels (time slots) pour transporter l’information, etau choix du niveau de redondance utilise pour les codes detecteurs etcorrecteurs d’erreurs.


Figure 7 : Topologies Bluetooth.

Tableau 1Canaux asynchrones Bluetooth

Type de lien Type ACL Donnees utiles Code detecteur Code correcteur Nombre d’intervalles Debit theorique(octets) CRC16 FEC temporels max. Kb/s

DM1√

17√

2/3 1 108.8DH1

√27

√– 1 172.8

DM3√

121√

2/3 3 387.2DH3

√183

√– 3 585.6

DM5√

224√

2/3 5 477.8DH5

√239

√– 5 732.2

En effet, l’utilisation de code correcteur FEC (Forward Error Cor-rection) offre une qualite de service supplementaire, mais reduit bienentendu la bande passante utile. Le code 1/3 FEC consiste a triplerchaque bit emis (utilise seulement pour les liens SCO), alors que lecode 2/3 FEC transmet 15 bits pour 10 bits utiles. Le code detecteurd’erreur CRC16 (Cyclic Redundancy Code) est quant a lui base sur lepolynome diviseur : d(x) = x16 + x12 + x5 + 1.

III.B.3 Architecture protocolaire simplifieeLe reseau Bluetooth peut s’integrer dans les differents reseaux filairesEthernet et sans fil WiFi sur la base du protocole IP. Cependant, dansnotre application experimentale temps reel, nous nous positionnons auplus bas niveau de l’architecture protocolaire, afin de nous affranchirde tous les temps de traversees des couches superieures de protocoles.

La figure 8 illustre l’architecture des couches basses de Bluetoothdont l’interconnexion des modules est realisee par un lien serie asyn-chrone avec le systeme temps reel via l’interface HCI (Host ControllerInterface). La couche physique radio utilise la bande ISM (industrielle– scientifique – medicale) a 2.4 GHz pour les emissions et receptionsur le medium air. La couche Baseband permet la synchronisation desmodules et les multiplexages des liens et traite les codes FEC et CRC.Enfin, la couche LMP (Link Manager Protocol) est dediee a la gestionde l’etat des liens et traite les paquets en provenance et a destinationde l’interface HCI.

IV Mesures de references

IV.A Module de pilotage BluetoothNotre choix s’est porte sur des modules Bluetooth pilotes par une in-terface serie pour les raisons suivantes : d’une part, pour satisfaire lescontraintes d’encombrement, d’economie d’energie et de communica-tion part port serie du systeme embarque du robot mobile, et d’autrepart pour l’evaluation de notre module Bluetooth specifique developpeau laboratoire pour des travaux de recherche connexes au notre.

Nous avons donc utilise un systeme modulaire illustre par la fi-gure 9, dont le coeur du systeme est une carte fille (#1) integrantles couches physique, LMP et Baseband. Ce module radio estcompose d’un emetteur/recepteur PBA 31301 compatible classe 2,implemantant la version v1.0B [7] de la couche physique Bluetooth.Le module Bluetooth nomme ROK 101007 integre toutes les couchescablees en dessous de HCI permettant des communications point apoint ou point-multipoints de type Scatternet. Trois types d’interfacesHCI sont disponibles : UART et USB pour les liens ACL et PCM pourles liens SCO de type voix.

Cette carte peut recevoir tout module Bluetooth Ericsson inter-changeable car elle dispose d’un support de ROK a force d’insertionnulle. Une antenne integree est aussi prevue. Une seconde carte (#2)offre l’ensemble des interfaces HCI de la specification Bluetooth. Des


Figure 8 : Architecture des couches basses de Bluetooth.

composants assurent les conversions et les adaptations de tensions.Par manque de maturite du module temps reel USB pour RTAI, nousavons du utiliser l’interface RS-232 de ces modules communicantsBluetooth.

IV.A.1 Interface HCI et paquetsL’interface HCI, grace a des commandes specifiques, permet le pi-lotage du module Bluetooth pour son controle intrinseque via lacouche Baseband. L’emission et la reception des donnees utiles pourles liens ACL sont effectuees via la couche LMP. Ces differentes com-mandes de controle et de donnees sont transmises par l’intermediairede paquets specifiques classifies en trois categories :

• les paquets de commandes utilises par l’hote pour controler lemodule Bluetooth,

• les paquets d’evenements utilises par le module Bluetooth pourrepondre a une commande,

• les paquets de donnees pour le transport des donnees utiles versun autre module Bluetooth distant.

La figure 10 illustre l’interaction de ces trois types de paquets entrel’hote de commande et le module sans fil Bluetooth.

Chaque paquet HCI est identifie par un octet d’entete specifiquesuivi de ses parametres comme l’illustre la figure 10.

Les paquets de donnees ACL envoyes sur l’interface HCI subissentune mise en forme specifique de la part du module Bluetooth afin deformater un nouveau paquet dedie a l’envoi sur le lien ACL radio.

IV.A.2 Pilotage de BluetoothAfin d’optimiser la configuration d’un module Bluetooth dansnotre environnement temps reel, nous avons definit une sequenced’initialisation.

La sequence de commandes suivantes, definie par le tableau 2,represente les commandes necessaires et suffisantes a l’initialisationd’un module Bluetooth. Cette sequence est independante du roledu module Bluetooth dans la communication maıtre ou esclave, cequi nous a permis de developper un module unique programmeRT init BT.o pour l’initialisation. Chaque entite specifique maıtreou esclave doit executer ce module. De plus, seul le maıtre doit etablirla connexion avec l’esclave dont il connaıt au prealable son adresseMAC. Une fois la connexion creee, l’esclave genere un evenementd’etablissement de connexion.

Figure 9 : Carte de communication Bluetooth.

Nous avons evalue les temps de traitement de chacune des com-mandes de ce module d’initialisation, dont le temps hors connexionest legerement superieur a 23 ms. Nous constatons par contre que letemps d’etablissement de la connexion occupe a lui seul environ 2 s.Il est important de prendre ce temps en consideration lors de la phased’etablissement d’une connexion Bluetooth, notamment dans un envi-ronnement multi-robots (Piconet). Suite a la presentation a cette phasede connexion entre le maıtre et l’esclave, nous detaillons au paragraphesuivant la phase de transmission de donnees entre les deux entites com-municantes dans l’environnement temps reel.

IV.B Taches temps reel communicantesAfin de valider notre plate-forme experimentale, nous avons, dansun premier temps sur un mono-systeme temps reel, defini deuxtaches temps reel de meme priorite sur ce systeme. Ces taches,RT send acl.o et RT receive acl.o, traitent respectivementl’emission et la reception des donnees. C’est le processus esclave(robot) qui doit necessairement etre initialise en premier, car il traite,sur interruption du port serie, la reception aperiodique des donnees.Le processus maıtre (poste de controle) emet des donnees en modeaperiodique apres tirage d’un temps aleatoire, et arme un chien degarde en cas pour borner la reception de l’acquittement de l’esclave. Lafigure 11 illustre le protocole de communication entre les deux portsserie d’un meme systeme temps reel afin de realiser les mesures tem-porelles a partir d’une horloge unique.

La premiere etape indispensable pour la validation du systeme estd’evaluer le comportement global de l’ensemble des taches temps reelen interconnectant les ports serie par un medium filaire. La fiabilite dece systeme nous a ensuite conduits a realiser les memes mesures ensubstituant le support de transmission filaire par une communicationsur le medium radio dont les modules Bluetooth maıtre et esclave sontdistants de 5 metres. Ceci correspondent a la topologie d’un Scatternetde robots cooperants.

IV.C Evaluations de performancesIV.C.1 Mesures sur le medium filaireSuite a l’architecture de reseau et de protocole presentee a la figure 11,nous avons dans un premier temps evalue le comportement du mono-systeme temps reel filaire en transmettant des paquets de donnees detaille variable entre 1 et 512 octets. En effet, nous souhaitions verifierle comportement intrinseque du module rtai spdrv.o dont la taillemaximale du buffer logiciel est specifiee a 512 octets dans le noyauRTAI.

Cette plate-forme nous permet de realiser des mesures temporellesen s’affranchissant des contraintes de synchronisation d’horloges dansun environnement multi-systemes.

La figure 12 represente les valeurs mesurees dans l’environnementfilaire dont le debit des ports serie est specifie a 115 200 bits/s.

Nous pouvons constater que les courbes obtenues sont au dessus dela courbe theorique, puisqu’elles incluent le transport de l’ensemble debits de gestion de l’interface serie (bit de stop, parite, . . . ) ainsi que letemps de traversee des couches protocolaires du systeme temps reel.


Figure 10 : Pilotage d’un module Bluetooth via l’interface HCI.

Figure 11 : Protocole de communication mono-systeme.


Tableau 2Temps mesures de la sequence d’initialisation

Actions Initialisation Mode de detection Activation Changement du Creation d’unelogicielle du module automatique des de la gestion debit a 115 Kb/s connexion DM1

Bluetooth modules (Inquiry) des evenements sur un lien ACLCommande > cmd reset > cmd wse > cmd sef 0x02 > cmd esuartbr > cmd ccapplicative INQUIRY PAGE 0x00 0x02 115200 0x111111111111Commande HCI # COMMAND # COMMAND # COMMAND # COMMAND # COMMAND 01 05 04 0D

01 03 0C 00 01 1A 0C 01 03 01 05 0C 03 02 00 02 01 09 FC 01 02 11 11 11 11 11 11 0800 00 00 00 00 00

Temps d’execution 8.198 023 4.063 218 2.732 338 8.054 214 1905.595en millisecondesTemps d’initialisation 23.047 793en millisecondesTemps total 1.928 642 793d’etablissement d’uneconnexion en secondes

Figure 12 : Mesures temporelles sur un mono-systeme temps reel filaire.

Figure 13 : Augmentation du temps de transmission en fonction de la taille des paquets.

Cette charge temporelle supplementaire est caracterisee par une aug-mentation entre 18 et 73 % comme l’illustre la figure 13. Plus la tailledes paquets est petite, plus le temps relatif necessaire au traitement et ala transmission est grand. En effet, ceci est principalement du au tempsde traitement logiciel par les taches temps reel, qui est proportionnelle-ment plus faible que le temps de transmission. Neanmoins, dans uneapplication a fortes contraintes temporelles, il s’agira d’utiliser des pa-quets d’une taille superieure a 120 octets afin de ne pas exceder 20 %d’augmentation de temps de traitement.

A partir de la figure 12, les paquets de commande et de reponsesont de taille identique, ce qui justifie parfaitement que les courbes as-sociees a la commande et a la reponse soient confondues. Ceci permetde valider la stabilite du systeme temps reel dans cet environnementfilaire, et donc de realiser des mesures dans l’environnement sans filBluetooth, en s’appuyant sur ces mesures initiales comme referencesou abaques.

Figure 14 : Mesures temporelles sur un mono-systeme temps reel Bluetooth.

Figure 15 : Debits Bluetooth mesures avec des paquets DM1 et DH1.

IV.C.2 Mesures avec BluetoothEn utilisant le meme protocole que celui presente a la figure 11, nousavons realise les mesures temporelles sur le mono-systeme communi-cant Bluetooth dont les resultats sont presentes a la figure 14.

Nous constatons un affaiblissement du debit utile Bluetooth du es-sentiellement aux differents octets constituant l’enveloppe de la trame(en-tete, CRC, . . . ), des bits de gestion de l’interface serie, ainsi queles temps de serialisation et de traversee de modules Bluetooth. Ledebit utilisateur offert par Bluetooth sur cette plate-forme temps reeln’excede pas les 40 Kbits/s via l’interface HCI. Ceci s’avere conformeaux debits mesures d’environ 30 Kbits/s [5] sur les couches logiciellessuperieures a HCI.

Nous presentons a la figure 15 une analyse comparative d’unlien Bluetooth ACL avec des paquets de type DM1 et DH1. Ils se


Figure 16 : Plate-forme de metrologie et architecture logicielle.

differencient par un niveau de qualite de service superieur pour lespaquets DM1 car ils implementent un code de redondance 2/3 FECsupplementaire.

La difference de debit entre DH1 et DM1 n’est que de 5 Kbits/s aumaximum, alors qu’en theorie elle est de 65 Kbits/s. Cette differenceest due a la limitation du port serie a 115.2 Kbits/s. Par consequent,cette limitation ne nous a pas permis d’evaluer explicitement les pa-quets de types DM3/DH3 et DM5/DH5. En effet, les ports serie appa-raissent dans ce cas comme un goulot d’etranglement pour les canauxACL Bluetooth au-dela de 115.2 Kbits/s.

IV.D ConclusionCette maquette experimentale mono-systeme a ete realisee dans le butde valider l’interoperabilite entre le systeme temps reel RTAI et desmodules sans fil Bluetooth, pour des communications asynchrones vial’interface serie du systeme.

Nous avons caracterise et developpe des taches temps reeld’emission et de reception en s’appuyant sur les modules noyau deRTAI notamment pour la gestion des interruptions des ports serie.Nous avons ensuite realise un ensemble de mesures sur le mediumfilaire afin d’evaluer le comportement global du systeme, pour en-suite realiser ces memes mesures dans l’environnement sans fil Blue-tooth. Nous avons constate l’impact du temps de traversee des couchesde RTAI et des modules Bluetooth, que nous caracterisons plusprecisement dans la partie suivante. Nous y mettons en oeuvre uneplate-forme de communication Bluetooth entre deux entites communi-cantes geree par des systemes temps reel RTAI distincts.

V Plate-forme de mesures

Nous presentons dans cette partie l’ensemble de la plate-forme demetrologie, en s’appuyant sur le systeme d’exploitation temps reelRTAI et sur le systeme de communication Bluetooth pour recueillirdes donnees de mesures temporelles de traitement et de transmission,de niveaux des signaux radio ainsi que les debits de communication.

V.A Protocole de mesuresL’architecture logicielle associee a chaque entite materielle, illustreesur la figure 16, est composee d’un systeme d’exploitation Linux de

type Redhat 8, avec un noyau RTAI et d’une tache temps reel de pi-lotage des modules Bluetooth.

La tache temps reel de pilotage des modules Bluetooth execute unesequence d’initialisation des modules [24] permettant ainsi de definirle type du module (maıtre ou esclave) puis de faire l’attachement entreles deux modules et d’associer un canal asynchrone de type DM1. Unpaquet DM1 permet de transporter jusqu’a 17 octets de donnees utiles.La qualite de service au niveau du taux d’erreurs est assuree par laredondance de donnees implementee par le 2/3 FEC. L’integrite desdonnees est garantie de plus par le CRC16. Le debit utile maximumtheorique est donc de 108.8 Kbits/s.

Une fois cette etape d’initialisation correctement executee, la tachetemps reel d’emission devient periodique et active le protocole de com-munication que nous avons realise specialement pour la metrologiedu lien de communication Bluetooth. Ce protocole de mesures envoieperiodiquement une trame DM1 qui doit etre acquittee positivement.Les charges utiles des trames de donnees et d’acquittement contien-nent 17 octets, ce qui correspond a la taille maximum supportee par lanorme pour les paquets DM1.

La charge utile de la trame d’acquittement contient une valeur duniveau du signal radio de reception du module esclave. Cette valeurcorrespond au RSSI (Received Signal Strength Indicator) mesure surle module Bluetooth des la reception de la trame de donnees.

Le comportement du protocole ainsi que les mesures radio sont il-lustres par le chronogramme sur la figure 17. Ce protocole se situe auniveau LLC (Logical Link Control) de type 3. Nous rappelons que leniveau LLC3 correspond a un transfert fiable de bout en bout acquitte.

En effet, notre protocole s’appuie sur la couche 2 de Bluetooth quiest basee sur la methode d’acces de type TDD (Time-Division Du-plex). Nous ne presentons pas en detail ici cette methode d’acces,mais nous rappelons brievement son principe pour les communica-tions avec des paquets DM1. Le temps est decoupe en intervalles de625 µs. Le module maıtre utilise 1 intervalle de temps pour communi-quer avec un module esclave. Ce dernier utilise l’intervalle de tempssuivant pour acquitter la donnee du maıtre. Par consequent, un echangemaıtre/esclave dure 1.25 ms dans le meilleur des cas.

En effet, si le protocole ARQ (Automatic Repeat reQuest) de lacouche 2 observe la non-reception de la trame apres expiration du timer


Figure 17 : Protocole de metrologie.

ou bien des erreurs de transmission grace au CRC, il se chargera alorsautomatiquement de faire les reemissions sur les intervalles temporelsadequats suivants.

Avec les modules Bluetooth Ericsson dont nous disposons, il est im-possible de parametrer le protocole TDD de la couche 2. Sans remettreen cause le fonctionnement intrinseque du TDD, nous aurions souhaitepouvoir indiquer au PDU (Protocol Data Unit) de la couche 2 :

• dans un premier temps, le parametrage du protocole ARQ en in-diquant le nombre de reemissions souhaitees en cas d’erreur oude perte de trame,

• puis dans un deuxieme temps, de transmettre toutes les trameserronees ou non a la couche LLC depuis la couche LMP.

Ceci nous aurait permis de controler avec un niveau de granulariteplus fin, le comportement des modules Bluetooth, dans l’objectif delimiter les retards induits dans la boucle d’asservissement du systemecommande. D’autre part, avec une remontee des trames erronees a lacouche LLC, il deviendra ainsi possible d’analyser en temps reel laqualite du lien radio, et d’anticiper un etat d’arret temporaire du robotavant la rupture du lien radio, mettant ainsi le robot hors controle.

Avec des modules Bluetooth autorisant un tel parametrage de lacouche 2, nous illustrons sur la figure 18 un exemple de bouclesd’asservissement avec et sans reemissions automatiques. Ces deux cascorrespondent respectivement a ARQ = 1 et ARQ = 0.

Nous observons dans le deuxieme cas que la duree de la communi-cation dans la boucle d’asservissement est de 2 ·625 µs, alors que dansle premier cas elle est le double avec l’incertitude que la communica-tion soit correcte sur les intervalles de temps 3 et 4.

Ce deuxieme cas necessite bien entendu que l’application tempsreel communicante prenne en charge les reemissions des trames er-ronees ou non recues. Ces reemissions peuvent etre calibrees enfonction de l’application, comme par exemple lors du pilotage d’unrobot en mouvement ou il peut etre necessaire d’indiquer un ordred’immobilisation si l’ordre precedent de tourner a gauche ne lui soitpas parvenu.

Cependant, l’architecture materielle des modules communicantsBluetooth s’avere limitative en termes de performances temporelles,car elle s’utilise au travers de l’interface asynchrone RS-232. Nouspresentons dans la conclusion de ces travaux des perspectives envisa-geables de plate-forme integree afin de remedier a cette limitation.


Figure 18 : Asservissement et reemission ARQ.

V.B MetrologieApres avoir presente l’environnement global de la plate-forme de com-munication, nous consacrons cette partie a l’explication du protocolede mesures.

Tout d’abord, nous rappelons que suivant les cas d’applicationstemps reel, une classification des types metrologiques s’impose :

• soit en temps differe, c’est-a-dire post-execution du systeme, oubien avec un decalage temporel entre le moment ou la donneeest generee et le moment ou elle est interpretee. Ce type demetrologie necessite generalement un stockage des donnees etest adapte aux applications a faibles contraintes temporelles ap-pelees aussi en temps reel mou.

• soit en temps reel, c’est-a-dire au moment exact ou la donnee estgeneree, elle est alors immediatement interpretee. C’est le casd’applications a forte contraintes temporelles ou en temps reeldur comme pour notre application de controle de robot a distance.

Pour notre plate-forme de metrologie, nous avons donc utilise unsysteme d’exploitation temps reel pilotant le module maıtre pourcollecter toutes les donnees mesurees au cours d’un echange entremaıtre/esclave. Ces donnees sont ensuite traitees et interpretees a lavolee mais jamais stockees.

V.B.1 Protocole de mesuresLe protocole de collecte de mesures est base sur des echangesperiodiques entre le maıtre et l’esclave en utilisant des paquets DM1Bluetooth. C’est le module maıtre qui est le coordinateur du systemeglobal de mesure. Son role est donc de recueillir ses mesures radio (ap-pelees RSSI) locales et de mettre en forme un paquet DM1 de requetede la mesure radio distante du module esclave. Ce dernier realise lamesure radio locale et met en forme un paquet DM1 de reponse dela mesure radio. Grace a ce protocole de collecte de donnees radio,le module maıtre mesure en temps reel la performance du lien LLC3ainsi mis en oeuvre. Il en deduit les performances en termes de debitdu lien DM1 ainsi sollicite.

Les mesures radio effectuees sur les modules maıtre et esclave sontcodees sur 1 octet chacune. Le module maıtre code sur 4 octets chaquevaleur temporelle correspondant a l’horloge temps reel du systeme.Ceci permet la mesure temporelle des echanges de bout en bout.

A l’issu, le module maıtre deduit donc le debit utile (appele aussithroughput) du lien DM1 et le code sur 4 octets. Par consequent, achaque periode d’echantillonnage, le coordinateur du systeme globalde mesure genere 10 octets de donnees mesurees.

Le probleme du choix du type de metrologie s’impose parmi ceuxque nous avons presentes precedemment. Nous n’avons pas retenule type de metrologie en temps differe, car la tache temps reel dumodule maıtre cadence le protocole de metrologie a une frequenced’echantillonnage de 25 ms pour le traitement des requetes et desreponses des mesures radio. A une telle frequence, les donneesmesurees pendant 1 heure representent un volume de 1.44 Mo astocker avant le traitement et l’analyse. Par consequent, la metrologieen temps differe n’est pas adaptee a notre application, notamment pourles observations sur plusieurs heures.

C’est donc la metrologie en temps reel que nous avons retenu, dansun premier temps pour faire effectivement des mesures et d’evaluer lesperformances du systeme communicant, puis dans un deuxieme tempspour agir sur le systeme asservi des lors que le protocole de mesureevaluera une degradation du systeme.

V.B.2 Acquisition des donneesLa collecte des donnees mesurees est realisee par les taches temps reeldes systemes communicants et plus particulierement par celle du coor-dinateur de mesure. Il est necessaire ensuite de transferer ces mesuresvers une autre tache du systeme, afin de decharger celle du coordina-teur. Deux contraintes fondamentales sont a considerer pour le choixdu mode de transfert des donnees :

• le traitement des donnees est asynchrone par rapport a lageneration des donnees,

• le volume de donnees mesurees est de 10 octets par periode de25 ms, soit les valeurs temporelles T1 et T2 codees sur 4 octetschacune et les valeurs RSSIM et RSSIE codees sur 1 octet cha-cune, presentees a la figure 17.

Il convient donc de determiner le mode de transfert adapte aces contraintes. Parmi les moyens existants de communication (si-gnaux, fichier, tube, message, memoire partagee, file d’attente) entreles taches du systeme d’exploitation temps reel, nous avons retenul’utilisation d’une file d’attente temps reel (RT FIFO (Real Time –


Figure 19 : Architecture de collecte des mesures.

First In First Out)) car elle presente le meilleur compromis en termesd’utilisation et de performance. En effet, c’est un moyen de communi-cation idealement adapte aux transferts des donnees inter-taches avecun ordonnancement temporelle entre les donnees echangees.

Nous avons calibre la taille de cette FIFO a 1024 octets en fonc-tion de la periode d’echantillonnage de 25 ms pour la generation desdonnees et de la periode d’echantillonnage de traitement pouvantvarier de 100 ms a 2.1 s. De plus, nous avons pris en considerationle fait que la tache de recuperation des donnees soit asynchrone parrapport a celle du coordinateur par le biais de la FIFO. C’est donc latache du coordinateur qui gere le controle total de la FIFO pour eviterle debordement de la file d’attente.

Afin de permettre un maximum de souplesse pour la productiondes graphes des donnees mesurees, nous avons implante une appli-cation cliente au travers d’un serveur Web. C’est sur le coordinateurdu systeme global qu’un serveur Web (processus Apache (non tempsreel)) est active. Une tache non temps reel de type cgi-bin a etedeveloppee afin de recuperer les donnees stockees dans la FIFO et deles envoyer au travers du protocole http vers l’application cliente.Cette derniere est developpee comme une applet Java qui permet ainsiune totale portabilite quelque soit le systeme client cible. Les donneesrecueillies sont formatees et enfin tracees graphiquement. La figure 19illustre le fonctionnement du traitement des donnees.

V.C Evaluation des performancesGrace a ce protocole de metrologie en temps reel et analysable a dis-tance sur un ordinateur equipe d’un navigateur Internet, nous avonsrealise les mesures intrinseques aux protocoles de communicationBluetooth et celles liees aux modules eux-memes. Nous avons realisedes mesures de debits utiles du lien Bluetooth DM1 en faisant varier lataille des paquets de la couche applicative. Nous avons observe que lesdebits augmentent en fonction de la taille des paquets comme l’illustrela figure 20. Nous avons confirme dans un environnement radio peuperturbe que le debit utile minimal est d’environ 11 Kbits/s, et le debitmaximal de 29 Kbits/s.

Ces mesures experimentales nous ont permis d’observer des tempsvariables de traitements des octets en fonction de leurs volumes dansles liens radio. Ces temps de traitements sont composes du temps de

traitement par les taches temps reel ainsi que du temps de serialisationdans les modules Bluetooth. Nous avons pu mettre en avant que lesmodules dont nous disposions necessitent entre 0.13 et 0.32 ms pourtraiter 1 octet. En effet, les temps de traitements des systemes tempsreel sont 1000 fois plus petits, donc consideres comme negligeables.Ces mesures temporelles sont illustrees par la figure 21.

Paradoxalement, plus les modules ont une charge importanted’octets a traiter, plus les temps diminuent, mais ils ne sont jamaisinferieurs a 0.11 ms/octet. Ceci s’explique par le fait que les donneestraitees octet par octet necessitent l’execution d’une routine du moduleBluetooth pour chaque octet. Cette meme routine est utilisee pour letraitement de plusieurs octets. Il s’agit donc de determiner un compro-mis entre le volume d’information a transmettre dans chaque paquet etle temps minimal a respecter pour valider la boucle d’asservissementpour le controle/commande. D’apres la figure 21, c’est pour une valeurde 120 octets que les performances sont optimales.

A partir du protocole de metrologie (figure 17) et des paquets dedonnees de 17 octets, les mesures relevees (figure 22) mettent en avantun temps minimum de traitement de 24.327 ms. C’est le temps mini-mum necessaire pour que le module maıtre ait une reponse a unerequete, soit la transmission de 34 octets. En regime etablit et sans per-turbation, nous remarquons que les repetitions automatiques du proto-cole ARQ sont regulierement sollicitees pour des valeurs ARQ = 1 etARQ = 2. Ceci induit respectivement des augmentations de temps de2 · 625 µs et de 4 · 625 µs sur la transmission radio Bluetooth.

Le comportement du protocole ARQ n’est pas adapte au controle/commande par des taches temps reel, car il est non deterministe(en termes de repetitions) et induit considerablement des tempssupplementaires dans la boucle d’asservissement comme nous l’avonspresente a la figure 18. Le comportement reel mesure confirme biennos hypotheses, et necessiterait un controle et une maıtrise totale duprotocole ARQ, ce qui n’est pas le cas avec les modules Bluetoothdont nous disposons.

L’interface de la plate-forme de metrologie est illustree par la fi-gure 23, representant les mesures realisees pour une taille de tramesde 255 octets. Les temps mesures par le coordinateur sont d’environ140.32 ms pour un debit maximum de 29 Kbits/s. Suite a des perturba-


Figure 20 : Debits utiles avec des paquets DM1.

Figure 21 : Debit utile et temps de traitement par octet.

tions volontaires du systeme, par obstruction des antennes, nous obser-vons des variations significatives de mesures radio RSSI, se traduisantparfois par des chutes du debit.

De multiples mesures nous ont permis d’observer que des atte-nuations radio engendrees volontairement sur les antennes des mo-dules Bluetooth provoquaient immediatement des variations des RSSIavant que la qualite de la communication soit affectee. Cette observa-tion est fondamentale pour le controle/commande de robot a distancecar elle permet de predire une eventuelle degradation du lien radio,et par consequent de pouvoir l’indiquer a priori a l’operateur afin deprendre la mesure adequate. Ce phenomene peut etre integre dans laboucle d’asservissement du systeme afin d’anticiper les retards induitspar la degradation du lien de communication.

VI Conclusion

Nous avons presente nos travaux de recherche sur la metrologie d’unlien asynchrone Bluetooth de type DM1 controle par des systemestemps reel. Nous avons principalement mis en avant l’influence dela taille des trames sur le debit utile. Lie a ce phenomene, nousavons evalue le temps de traitement d’un octet dans les modulesBluetooth ainsi que les temps necessaires a la traversee des coucheslogicielles des systemes temps reel RTAI. Les releves en temps reeldes mesures radio sur les modules maıtre et esclave sont des in-formations indispensables pour le fonctionnement d’un protocole decontrole/commande de robot integrant les retards temporels. Cecirepresente un moyen predictif de l’etat de la communication.

Les temps de traitements des paquets DM1 par les modules Blue-tooth sont tres nettement superieurs aux temps de transmission ra-dio. Ceci est du aux faibles performances de l’architecture materielledes modules communicants. Les interfaces a haut debit ont evolue

Figure 22 : Temps d’acces du protocole de metrologie et influence de l’ARQ.

Figure 23 : Interface de mesures de la plate-forme de metrologie.

en termes de performance et d’integration, offrant des systemescommunicants Bluetooth plus performants (version 2.0) et disposantd’interfaces de commande integree (USB, PCMCIA, PCI, . . . ).

References

[1] C. Law, A.K. Mehta et K.-Y. Siu, “A new Bluetooth Scatternet formation protocol,”Mobile Networks Applicat. J., vol. 8, no. 5, oct. 2003, pp. 485–498.

[2] A. Das, A. Ghose, A. Razdan, H. Saran et R. Shorey, “Enhancing performance ofasynchronous data traffic over the Bluetooth wireless ad-hoc network,” dans Proc.IEEE INFOCOM ’01, vol. 1, Anchorage, Alaska, 2001, pp. 591–600.

[3] L. Marzario, L. Abeni et G. Lipari, “Improving the responsiveness of Linux appli-cations in RTAI,” dans Proc. Fourth Real-Time Linux Workshop, Boston, Mass., 6–7dec. 2002, http://www.realtimelinuxfoundation.org.

[4] RTAI Programming Guide 1.0, Milan, Italie: Dipartimento di IngegneriaAerospaziale Politecnico di Milano (DIAPM), sept. 2000.

[5] T. Val et G. Juanole, “Developpement d’applications de metrologie pour le WPANBluetooth,” presente au Colloque Francophone sur l’Ingenierie des Protocoles(CFIP 2002), Montreal, 27–30 mai 2002.

[6] T. Val, “Contribution a l’ingenierie des systemes de communication sans fil,” Ha-bilitation a Diriger des Recherches, Universite de Toulouse II, Toulouse, France,soutenue le 11 juillet 2002.

[7] Specification of the Bluetooth System: Core V1.0B, Bellevue, Wash.: Bluetooth Spe-cial Interest Group, 1999.

[8] D. Hildebrand, “An architectural overview of QNX,” dans Proc. ACM Workshop onMicro-Kernels and Other Kernel Architectures, 1992, pp. 113–126.

[9] T. Khoutaif et G. Juanole, “Formal modelling and evaluation of the data trans-fer phase of the ACL links on the WPAN Bluetooth,” dans Proc. 11th IEEE Int.Conf. Emerging Technologies and Factory Automation (ETFA 2006), Prague, Rep.tcheque, 20–22 sept. 2006, pp. 30–37.

[10] T. Khoutaif et F. Peyrard, “Modelisation mathematique du controle d’erreurs dansla couche MAC de Bluetooth,” dans Proc. 9th Maghrebian Conf. Information Tech-nologies (MCSEAI ’06), Agadir, Maroc, 07–09 dec. 2006.

[11] P. Ficheux, Linux embarque, Paris: Edition Eyrolles, 2000.


[12] P. Mantegazza, E. Bianchi, L. Dozio et G.L. Ghiringhelli, “Complex control sys-tem: Applications of DIAPM-RTAI at DIAPM,” presente a Real Time Workshop,Vienne, Autriche, 1999.

[13] “FAQ,” Socorro, N.M.: FSMLabs, 2008, http://www.fsmlabs.com/about/faq/.

[14] E. Bianchi et L. Dozio, “Some experiences in fast hard realtime control in user spacewith RTAI/LXRT,” presente a Real Time Linux Workshop, Orlando, Fla., 2000.

[15] VxWorks Programmer Guide, Alameda, Calif.: Wind River System Inc., 1995.

[16] J. Kupper, P.N. Daly et T.J. Mahoney, “Real time Linux documentation project,”RTLinux, 2000.

[17] P. Mantegazza et G. Renoldi, “Real time application interface documentation ofserial port drivers,” RealTime Application Interface (RTAI), 2002.

[18] T. Khoutaif, F. Peyrard, T. Val et G. Juanole, “Evaluation de performances des com-munications entre taches temps reel sur une interface asynchrone,” dans EDSYS ’04(Congres annuel des doctorants de l’ecole doctorale systemes de Toulouse),Toulouse, France, Mai 2004.

[19] T. Khoutaif et F. Peyrard, “Evaluation de performances des communications asyn-chrones d’un systeme temps reel base sur RTAI,” dans Proc. IEEE Conf. Sci. Elec-tron. Technol. Inform. Telecommun. (SETIT ’05), Tunisie, 27–31 mars 2005.

[20] M. Frederick et William P. Shackleford, “Timing studies of real-time Linux forcontrol,” dans Proc. Real-Time Linux Workshop, Milan, Italie, oct. 2001.

[21] Specification of the Bluetooth system: Core V1.2, Bluetooth Special Interest Group,2001.

[22] J. Bray et F.C. Sturman, Bluetooth 1.1 connexion sans fil, le premier guide enfrancais sur la specification Bluetooth, Edition CampusPress, 2002.

[23] F. Peyrard et T. Val, “Simulation et analyse de performances de liens synchronesBluetooth avec Opnet,” presente au Colloque Francophone sur l’Ingenierie des Pro-tocoles (CFIP 2002), Montreal, 27–30 mai 2002.

[24] T. Khoutaif et F. Peyrard, “Performances evaluation of the asynchronous Bluetoothlinks in a real time environment,” dans Proc. IEEE Conf. Personal Wireless Com-mun. (PWC ’05), Colmar, France, aout 2005, pp. 235–243.

Fabrice Peyrard est docteur en informatique depuis 1998.Il effectue sa recherche scientifique au laboratoire LATTISEA4155 de l’Universite Toulouse II, Toulouse, France, dansles domaines des communications des reseaux locaux sans fil.Il est Maıtre de conferences a l’IUT de Blagnac et dispense desenseignements de reseaux et de telecommunications.

real-time bluetooth communication system for control of a mobile robot

Documents