TP Khepera - AutomatesConception du logiciel de communication avec le khepera

3IF, INSA de Lyon, 2006/2007Guillaume Beslon, Frederique Biennier, Christian Wolf

Preambule

Ce TP est le premier d’une serie de quatre au cours desquels vous realiserez progressive-ment le logiciel de commande d’un robot de type Khepera. Il s’agit d’un mini-robot mobile(5 cm de diametre, voir ci-dessus) propulse par deux roues (propulsion differentielle) et dis-posant de dix capteurs de proximite a infra-rouge. Il embarque un microcontroleur Mororola68331 qui peut fonctionner en mode autonome ou en mode controle. Dans ce dernier cas, onpilote le Khepera depuis une station de travail via une liaison serie de type RS232. Dans lecadre de ces TPs, nous utiliserons le robot en mode controle (le robot sera controle par unestation VxWorks “maıtre”, voir figure 1). Il est donc indispensable de disposer d’un servicede communication controle-robot fiable sur la base de la liaison RS232. Le but des premiersTPs de cette serie sera donc de developper ce service. Pour cette premiere seance, nous nousattacherons en particulier a concevoir un service de communication fiable en nous basant surune architecture de type OSI.

Travail demande dans ce TP

– Conception, sur papier, des automates pour la couche liaison et pour la couche physiquedu protocole de communication.

– Validation par un compte rendu en fin de seance.

1 Rappels sur les protocoles de communication

Un systeme de communication doit au minimum permettre un echange de donnees fiable,sans perte ni duplication entre systemes informatiques. Pour cela, il faut s’assurer que (i)

1

Fig. 1 – Organisation du systeme de controle. Le robot Khepera est relie, via une liaison serieRS232, a une station VxWorks chargee de le controler en temps-reel.

l’interlocuteur a bien recu les informations, (ii) que les informations recues ne comportaientpas d’erreur.

Un logiciel de communication doit donc offrir un service de haut niveau, avec une qualite deservice donnee, aux programmes d’application en ce qui concerne la transmission de donneesen milieu heterogene. L’ensemble de ces contraintes fournit un logiciel assez gros et complexe.Pour resoudre les problemes de fiabilite interne, assurer une conception modulaire des elements(et donc les rendre plus facilement reutilisables), l’ISO1 a defini une architecture en septcouches (l’OSI, pour “Open System Interconnection”). Les taches de controles et de reprisesen cas d’erreur sont donc reparties dans l’ensemble des couches.

Chaque couche est vue comme un fournisseur de services par les couches de niveausuperieur et le dialogue entre machines est realise par un ensemble de dialogues (suivantun protocole) entre entites de meme niveau (figure 2).

1International Standard Organisation

2

C o u c h e N( P C I + P D U ) = S D U ( N )

S A P

C o u c h e N - 1S D U ( N ) = P D U ( N - 1 )

S D U

. . .

. . .

C o u c h e N( P C I + P D U ) = S D U ( N )

S A P

C o u c h e N - 1S D U ( N ) = P D U ( N - 1 )

S D U

. . .

. . .

C a n a l

P r o t o c o l e

P r o t o c o l e

M a c h i n e A M a c h i n e B

Fig. 2 – Principe de l’organisation en couche des logiciels de communication

Pour chaque couche, il faut donc definir avec precision :

– son role (analyse fonctionnelle)– son protocole de communication avec sa couche appariee sur la machine distante,– son interface avec la couche adjacente superieure sur la machine consideree.

Aussi avant de passer a la realisation d’un logiciel de communication, il importe de passer parun certain nombre d’etapes permettant de concevoir un systeme fiable.

1.1 Breve description de la fonction de chaque couche

Les rappels donnes ici doivent vous permettre de choisir quelles couches mettre en oeuvrepour realiser votre logiciel de communication.

1.1.1 Couche physique

Cette couche est chargee de realiser l’interface avec le materiel. Elle peut utiliser les servicesde drivers particuliers ainsi que ceux du moniteur d’entree/sortie. Elle traite pour le comptede la liaison de donnees (au niveau de l’electronique) la detection des erreurs (controles deparite sur les caracteres transmis, code cyclique...). La communication est toujours realiseeen serie (pas d’echange via des coupleurs paralleles). La transmission des caracteres peut etreassuree de maniere :

3

arythmique (on re - synchronise l’horloge pour chaque caractere a l’aide de bits de departet d’arret2)

synchrone (les caracteres sont emis par paquets et on synchronise l’horloge en envoyant descaracteres de synchronisation (SYNC) en debut de paquets et eventuellement en coursde transmission d’un paquet)

isochrone (l’horloge de transmission est calee une fois pour toute et des caracteres sonttransmis en permanence).

Le choix de l’un ou l’autre de ces modes depend :

– de la quantite d’information a echanger,– des debits de transmission,– de facteurs economiques.

La couche physique devant rendre ces choix transparents pour les couches superieures, elledoit assurer :

– l’initialisation convenable des coupleurs de communication,– l’emission et / ou la reception de donnees sur la ligne.

1.1.2 Couche liaison de donnees

Cette couche doit garantir la fiabilite de transmission d’unites de donnees (trames). En effet, lacouche physique ne garantit pas un transfert sans erreur. Il faut egalement assurer un controlede flux (pour eviter de perdre ou dupliquer des informations), la correction des erreurs... Pourcela, elle met en oeuvre un protocole specifique destine a garantir la fiabilite de la liaisonentre deux machines. Elle travaille souvent en mode CONNECTE ce qui permet de faire desinitialisations.

1.1.3 Couche reseau

Lorsque deux machines desirent communiquer, elles utilisent assez souvent les services d’unreseau de communication. La couche reseau est alors chargee d’assurer le routage des donnees,de selectionner un chemin (en prenant eventuellement en compte une optimisation economique)et de transcrire l’adresse logique d’un utilisateur en une adresse physique sur le reseau.

1.1.4 Couche transport

C’est la couche charniere du modele. Elle permet de garantir, quel que soit le choix des servicesinferieurs, une qualite de transmission donnee. Elle permet aussi d’optimiser l’acheminementdes donnees, en utilisant parfois plusieurs connexions de reseau. Ceci implique donc que cettecouche assure un controle de bout en bout et parfois des controles d’erreur complementaires(notamment dans le cas de reseaux locaux). Charniere entre les couches hautes et basses, elle

2ce mode est souvent appele mode asynchrone

4

doit egalement harmoniser la longueur des SDU (Service Data Unit) et PDU (Protocol DataUnit) qu’elle transmet. On parle alors de fragmentation et de reassemblage.

1.1.5 Couche session

Elle permet d’organiser et synchroniser les dialogues dans le temps. En effet, certains echangespeuvent etre particulierement longs (gros transfert de fichiers, campagnes d’acquisition...) etil peut etre important en cas de problemes de pouvoir faire des reprises automatiques. Cettecouche permet de gerer des points de synchronisation et de repere qui permettent de progresserd’etats stables en etats stables (Cf organisation des traitements en mode transactionnel).

1.1.6 Couche presentation

C’est la couche qui permet le travail dans un environnement materiel heterogene. En effet,sur des machines differentes, il n’y a pas forcement le meme codage, la meme representationdes donnees, les memes modeles de terminaux... Il faut donc realiser une adaptation. Pourcela, on a deux solutions :

– une des machines assure une traduction des informations dans une forme directementcomprehensible par son interlocuteur,

– chaque machine utilise une representation intermediaire dans une syntaxe de transfertnormalisee. Ceci presente un gros avantage par rapport a la solution precedente car,outre l’ouverture qui lui est inherente, si on desire connecter n machines differentes, ilsuffit d’ecrire n traducteurs au lieu des n(n-1) necessaires avec la solution precedente.

Enfin, cette couche peut aussi offrir des fonctions de compression et d’encryptage desdonnees.

1.1.7 Couche application

C’est l’ensemble de services de haut niveau qui permettent d’utiliser les services de com-munication entre deux machines : transfert de fichier, messagerie... Cette couche permet degommer les differences ”logicielles” entre machines heterogenes. En particulier, le terminalvirtuel permet de gommer les differences de materiel quand on travaille en mode transaction-nel. Il convient de noter que les services de certains types d’applications sont encore en coursde normalisation.

1.2 Methodologie de conception

La premiere etape consiste a faire une analyse fonctionnelle couche par couche, compte tenudu service a fournir. Dans cette analyse il faut non seulement tenir compte du cahier descharges actuel mais aussi envisager des extensions futures. Ensuite, pour chaque couche ilfaut definir un protocole (dialogue et ses regles strictes entre les deux couches appariees).

5

L’incidence de ces elements au niveau interne suppose de definir le format des donneesechangees avec l’entite appariee et l’organisation generale du dialogue. Pour cela, on elaboredes scenarii et on realise les dialogues correspondant. Dans le meme temps, il faut prevoir lespoints d’acces au service (Service Access Point : SAP) pour la couche superieure.

Deux entites appariees vont echanger des unites de donnees de protocole (Protocol DataUnit : PDU). Ces PDU sont composees :

– de donnees venant de la couche superieure, ce sont des unites de donnees de service(Service Data Unit : SDU)

– de donnees de controle pour le protocole (Protocol Control Information : PCI). La PCIest traitee par l’entite appariee et permet de traiter les donnees echangees. La partieSDU peut ensuite etre transmise a la couche superieure.

L’interface entre couches adjacentes est realisee par les SAP. On aura differentes primitives :

– requete : ordre qu’une couche de niveau N transmet a la couche de niveau inferieure(N-1),

– indication : signal (eventuellement porteur d’une information) transmis par la couchede niveau N-1 a la couche de niveau N,

– reponse : reponse de la couche N distante vers la couche N qui a envoye une requete.La reponse fait donc suite a l’indication. Pour la couche N-1 de la machine distante, ils’agit d’un ordre a executer.

– confirmation : signal (eventuellement porteur d’information) venant de la couche N-1et indiquant a la couche N que la reponse est arrivee ou que le traitement dans l’entitelocale de niveau N-1 est terminee.

Pour certaines fonctions, il suffit d’utiliser des requetes et des indications (service non confirme)

Une fois etablis ces dialogues et communication entre couches, il ne reste plus ”qu’a”elaborer l’algorithme interne de chaque couche. Pour cela, on s’interesse aux evenements en-trant dans une couche (requete, indication,...) et on s’interesse alors aux traitements a realiserpour pouvoir produire le ou les evenements sortant qui en resultent. La representation destraitements internes d’une couche pourra etre definie selon les graphismes SDL (specificationand description language) rappeles figure 3.

6

L - R C

P - R C

0 r e p o sE t a t ( a t t e n t e é v é n e m e n t )

E v é n e m e n t e n t r a n t

E v é n e m e n t s o r t a n t

T e s t

A c t i o n s é q u e n t i e l l el e c t u r ec a r a c t è r e

Fig. 3 – Graphismes SDL

Pour plus de clarte dans la suite, on utilisera des mnemoniques correspondant uniquementau mecanisme requete / indication. Les mnemoniques (N-XY) sont construits de la manieresuivante :

N = lettre representant la couche a qui l’ordre est donne ou la couche quirenvoie le compte rendu sur l’execution de l’ordre.

X = R pour une requete ou I pour une indication.Y = type de requete ou d’indication :

C : connexion,D : deconnexion,E : Emission,R : Reception,ER : Erreur,

Par exemple on notera P-RC la requete de connexion transmise par la couche liaison dedonnees et la couche physique. On notera qu’une requete de connexion adressee a la couchephysique signifie que la couche liaison de donnees donne l’ordre a la couche physique de seconnecter. De meme une L-IE represente une indication d’emission signalee par la coucheliaison a la couche superieure. On notera que cette L-IE constitue la ”confirmation” de lacouche liaison a une L-RE.

7

2 Realisation du systeme de communication avec le khe-

pera

2.1 Architecture du systeme

Le protocole a concevoir est de type Maıtre / Esclave. Tout envoi de donnee du systemede controle vers le khepera devra donc etre precede d’une invitation a recevoir indiquantegalement vers quel peripherique (i.e. a quelle adresse) les informations recues devront etreecrites. De meme, toute demande de donnees du systeme de controle vis a vis du kheperasera precedee par l’envoi d’un invitation a emettre precisant egalement ou il faudra prendreles donnees a emettre.

Votre etude sera faite en deux temps :

– Etude d’un exemple simple, resolu (figures 4, 5, 6, 7 et 8) ;– Cas reel guide (figures 9, 10, 6, 11 et 12).

2.2 Protocole simple sans controle

Dans ce protocole, on se borne a envoyer des trames au robot SANS se preoccuper de leurbonne reception par le khepera. Le systeme de controle se borne a envoyer, lorsque le ligneest en etat, les donnees sur la liaison serie (Cf dialogues et automates).

Les invitations ont le format suivant :

Wxx = invitation a recevoir des donnees a transmettre a l’adresse xxRxx = invitation a emettre les donnees (en l’occurence l’octet) se trouvant a

l’adresse xx.

Toute trame se termine par un Retour Chariot (rc).

2.3 Protocole avec controle

Dans ce type de protocole, le khepera renvoie en echo la trame d’information qu’il a recu desqu’il l’a comprise. Il comprend un trame lorsqu’on a pu decoder convenablement l’invitationet l’adresse qui lui sont indiquees. Ensuite, tous les caracteres de la trame sont renvoyes enecho des que possible. Il faudra donc prevoir un systeme vous permettant de realiser a la foisune emission et une reception.

Compte rendu : decrire ce protocole :

– decrire le dialogue en completant les figures 9 et 10,– completer les automates fournis (figures 11 et 12).

version 3.3, 27 fevrier 2007 – redige avec LATEX

8

L i a i s o n P h y s i q u e C a n a l P h y s i q u e L i a i s o nR o b o tC a n a lM a î t r e

L - R C

i n i t i a l i s a t i o nP - R C

C P DD P E

D T RR T SD C DC T S

P - I DL - I D

P - I CP - R R ( R 0 2 r c )

R02r c

P - I RL - I R

L - R EP - R E

xr c

P - I E R

L - I DP - I R

L - I C

P - R DP - I D

D SP A E

Fig. 4 – Dialogue de la phase de connexion en mode sans controle (protocole No. 1)

9

L i a i s o n P h y s i q u e C a n a l P h y s i q u e L i a i s o nR o b o tC a n a lM a î t r e

L - R E ( 0 0 R 8 )

P - R E ( s t r )

P - I E

W00R

P - I RL - I R

L - R EP - R E

s t r = W + 0 0 R 8 + r c

8r c

L - R R ( 0 6 )

P - R R ( s t r )R06r c

P - I RL - I R

s t r = R + 0 6 +

r c

L - I EL - I E R

P - I E R

xr c

P - I RL - I RL - I E R

P - I E RP - R D

P - I D

Fig. 5 – Dialogue de la phase de transmission en mode sans controle (protocole No. 1)

10

A - I D

L - I E R

L - R D

L - R E L - I C

L - I D1 a t t - c o n n e c t

A t t e n t e c o n n e x i o nC o u c h e l i a i s o n

2 c o n n e c t - L

A - R DA - I C

L - R R

L - R E

4 é m i s s i o n5 r é c e p t i o n

A - I R

P r e p . B u f f e r

P r e p . B u f f e r

d é c o d a g e

L - I E R

L - I E

A - R R

A - R C

L - I E

A - I E

3 c o n n e c t é

L - I E R

A - R E

L - I D

6 a t t - d e c o n nA t t e n t e d é c o n n e x i o n

C o u c h e l i a i s o n

A - I D

L - R C

0 r e p o s

L - I R

A - I E R

Fig. 6 – Automate de la couche application

11

P - R E

L - I D

P - R D

P - I D1 a t t - c o n n e c t

A t t e n t e c o n n e x i o nC o u c h e p h y s i q u e

L - R D

P - I R4 é m i s s i o n

L - I E R

L - I R

L - R C

L - I EL - R E

6 a t t - d e c o n nA t t e n t e d é c o n n e x i o nC o u c h e p h y s i q u e

L - I D

P - R C

0 r e p o s

P - I D

7 a t t - d e c - e r rA t t e n t e d é c o n n e x i o nC o u c h e p h y s i q u e

P - I DP - I C

P - R R2 c o n n e c t - L

P - R D

P - R R

5 r é c e p t i o n

L - R R

P - I E

P - I E R P - I E R

P - I R L - I CP - I E R

3 c o n n e c t é

Fig. 7 – Automate de la couche liaison pour le protocole No. 1.

12

P - I R

P - I D

t i m e o u t1 a t t - c o n n e c t

A t t e n t ei n i t i a l i s a t i o n

P - R C

P - I E

P - I D0 r e p o s

P - R D

C T SD C D

P - I C

e n v o ic a r a c t è r e

P - R R

e r r e u rl i g n e

I n i t . 8 5 2 3 0

r e s e t 8 5 2 3 0

2 c o n n e c t é

f i né m i s s i o n

5 r é c e p t i o n

r é c e p t i o n

l e c t u r ec a r a c t è r e

l e c t u r e s t a t u s R x

e n v o ic a r a c t è r e

3 é m i s s i o n

P - R E

f i né m i s s i o n

P - I E R ( c )

t i m e o u t

e r r e u rl i g n e

t i m e o u t

P - I E R ( d )

4 i n v i t a t i o n

Fig. 8 – Automate de la couche physique pour le protocole No. 1.

13

14

Binome : Nom(s) :

L i a i s o n P h y s i q u e C a n a l P h y s i q u e L i a i s o nR o b o tC a n a lM a î t r e

L - R C

Fig. 9 – Dialogue de la phase de connexion en mode echo (protocole No. 2). A completer

15

L i a i s o n P h y s i q u e C a n a l P h y s i q u e L i a i s o nR o b o tC a n a lM a î t r e

L - R E ( 0 0 R 8 )

L - R R ( 0 6 )

Fig. 10 – Dialogue de la phase de transmission en mode echo (protocole No. 2). A completer

16

Binome : Nom(s) :

1

4

3

7

2

5

a t t - c o n n e c t

c o n n e c t - L

c o n n e c t é

a t t - d e c - e r r

é m i s s i o n r é c e p t i o n

6 a t t - d e c o n n

0 r e p o s

Fig. 11 – Automate de la couche liaison pour le protocole No. 2. A completer

17

1

0 r e p o s

2

5

43

6

a t t - c o n n e c t

c o n n e c t é

é m i s s i o n i n v i t a t i o n

r é c e p t i o nf i n - é c h o

Fig. 12 – Automate de la couche physique pour le protocole No. 2. A completer

18