TP Khepera Réalisation du Logiciel de communication

Transcription

1 TP Khepera Réalisation du Logiciel de communication 3IF, INSA de Lyon, 2007/2008 Guillaume Beslon, Thierry Moyaux, Christian Wolf 1 Introduction Travail demandé dans ce TP : Réalisation de la couche liaison du logiciel de communication (le reste de l architecture est fourni). Validation en assistance (sur les stations VxWorks), Un listing commenté, à envoyer par mail à l adresse suivante : [email protected]. Le format est le suivant : le sujet du mail est [KHEPIF-TP5] suivi de votre numéro de binôme. Le corps du mail doit mentionner vos deux noms et le fichier attaché doit avoir pour nom XXXX.c (plus, éventuellement XXXX.h) où XXXX est votre numéro de binôme. Tout fichier doit impérativement commencer par un commentaire mentionnant vos noms, prénoms et votre numéro de binôme... Tout mail incorrectement formaté sera refusé. Il est préférable, lors de l intégration des différents modules sous VxWorks, de réutiliser votre propre couche système (cf. TP4). Cependant, en cas de problème, une version compilée vous est fournie. Nous vous rappelons qu au delà du compte-rendu, l objectif de ce TP est de visualiser et de comprendre les enchaînements de protocoles (et donc de communications) dans un logiciel réseau organisé sur le mode OSI (bien qu ici l architecture soit très simplifiée). N hésitez donc pas à jouer avec les modules qui vous sont fournis 1... Ne vous concentrez pas uniquement sur la couche liaison : sa programmation n est qu un prétexte pour regarder plus loin. Bref, soyez curieux!!! 1 Pour cela, les modules à réaliser vous sont fournis sous forme de code objet. Vous pouvez donc directement compiler l ensemble de la chaîne de commande et de communication et l exécuter. 1

2 2 Rappel de l architecture du logiciel Le logiciel de communication est structuré en trois couches : Application (module lay application.c), Liaison (module lay data link.c, (à réaliser)), Physique (module lay physical.c). De manière à favoriser la portabilité, la couche physique est elle même découpée en deux parties principales : couche physique à proprement parler (gestion de l automate) sous-couche système gérant les entrées/sorties d une manière adaptée au coupleur de communication (sous-couche réalisée dans le TP4). Cette sous-couche encapsule et isole tous les appels systèmes (donc tous les échanges entre le et le Z85230 dans le cas de l application VxWorks). Dans le cadre de ce TP, une deuxième version de cette couche vous sera fournie afin de permettre l utilisation du logiciel de communication sur une plate-forme Linux (voir section suivante). Enfin, deux modules, dits de supervision (superv.c) et gestion mémoire (memman.c) permettent de gérer les échanges de messages entre les couches du logiciel réseau et d assurer un service rapide de réservation mémoire (sans passer par les primitives d allocation standard). Un programme principal (fichier tp main.c) permet d initialiser le khepera, de commander un mouvement et de lire les valeurs des capteurs. Il permet également, en utilisant les options de la ligne de commande, de tracer le parcourt des messages à travers les différentes couches du logiciel de communication 2 (utiliser l option -h pour connaître les commandes disponibles). Ce module doit être compilé avec l option LINUX sous linux. Le programme principal fait appel à des primitives de haut niveau pour la communication avec le robot (commande des moteurs, lecture des capteurs, etc.). Ces primitives sont disponibles dans le module (khep cde.c). 2.1 Environnement de développement et de test Le logiciel est destiné à être utilisé pour communiquer avec le khepera sur les satellites Vx- Works. Il peut cependant être testé en simulation (en C standard sous Linux), une solution qui a le mérite de garantir l indépendance vis à vis de la salle vxworks. Afin de pouvoir tester le logiciel sans khepera, ce dernier peut également être simulé avec un logiciel qui vous est fourni. Enfin, pour faciliter la mise au point du code, un mini-terminal linux vous est fourni pour que vous puissiez communiquer directement avec le robot ou avec l application 3. Ces deux dernières applications peuvent fonctionner suivant deux modes (à choisir suivant les options 2 On sera attentif aux valeurs des deux variables globales verbose et confirme qui permettent d afficher ou non les différentes étapes de la communication et d attendre ou non une validation clavier à chaque étape. Sous VxWorks, ces deux variables doivent impérativement être fixées à zéro sous peine de ralentir le programme et d en perturber le fonctionnement. Valeurs possibles : 0,1,2. 3 Il s agit de trois applications de type terminal : pipe terminal com1 se connecte sur le port virtuel COM1, pipe terminal com2 se connecte sur le port virtuel COM2 et terminal se connecte sur le vrai port de serie COM1. 2

3 de compilation) : mode réseau et mode local. Dans le premier cas, la couche système communique avec le port série de l ordinateur (on doit donc disposer de deux machines connectées par un câble croisé). Dans le second cas, le port série est simulé par un tube nommé (le simulateur ou le terminal sont alors exécutés sur la même machine que le logiciel de commande et toutes les applications sont connectés par des ports virtuels). L archive qui vous est fournie 4 contient les sources de ces deux applications (chaîne de commande et simulateur du khepera) distribuées sur plusieurs répertoires : Application Répertoires Contenu Logiciel de commande khep_com/common Sources du logiciel de commande, sauf la couche système. Le choix de la plate-forme d exécution (linux local, linux réseau, Vx- Works) est effectué à la compilation. La couche liaison vous est fournie en version compilée (lay data link.o) afin que vous puissiez étudier le fonctionnement du système. Logiciel de commande khep_com/linux Simulation de la couche système pour Linux. Le choix de la plateforme d exécution (linux local, linux réseau) est effectué à la compilation. Logiciel de commande khep_com/vxworks Couche système pour VxWorks (version compilée). Ce module est destiné aux binômes qui ne parviendraient pas à réutiliser leur propre couche système (développée au cours du TP4). Simulateur du khepera khep_sim/linux Sources du simulateur 3D du khepera ; le choix de la plateforme d exécution (linux local ou linux réseau) est effectué à la compilation. mini-terminal khep_term/linux Sources du mini-terminal ; le choix de la plate-forme d exécution (linux local ou linux réseau) est effectué à la compilation. Le mode simulé, tel que les sources sont configurées, demande l exécution des deux applications communicantes sur deux machines différentes connectées avec un câble série croisé (mode linux reseau). Par exemple, la connexion de deux machines Linux différentes, une machine exécutant le logiciel de commande (avec la version linux de la couche système), la deuxième 4 3

4 machine exécutant la simulation du khepera ; ou la connexion d un satellite vxworks avec une machine Linux exécutant la simulation du khepera ; etc. Afin de pouvoir travailler sur une seule machine, la connexion série elle même peut également être simulée (mode linux local). Cette technique permet de simuler deux ports série (COM1 et COM2) sur la même machine en utilisant un tube nommé. Pour cela, les deux applications (logiciel de commande avec couche système simulée et khepera simulée) doivent être compilées en définissant la macro SIMULATED SERIAL PORT pour les deux applications, ainsi que la macro SIMULATED SERIAL COM2 pour une des deux applications 5. La figure 1 résume quelques possibilités de connexion entre le logiciel de commande et le khepera ou le simulateur. 3 Description du logiciel de chaque couche Le logiciel de chaque couche est codé dans un fichier indépendant. Ce logiciel, qui suit les spécifications décrites dans les automates est structuré de la manière suivante : nom_couche() Début Recuperer requ^ete entrante SELON la valeur de la variable ETAT faire: CAS x: Début SELON le type de requ^ete reçue faire: CAS z: Début Traitement de la requ^ete (incluant les appels nécessaires vers le niveau inférieur) Renvoyer l indication correspondante à l appelant Definir le nouvel état Fin CAS z CAS... FIN SELON type requ^ete Fin CAS x CAS... Fin SELON valeur de la variable ETAT Renvoyer compte-rendu Fin Le logiciel comprend trois couches implémentées dans les trois fonctions suivantes : 5 On se refera aux Makefiles des deux applications 4

5 APPL. SOFTWARE 7-APPLICATION 2-DATA LINK 1-PHYSICAL systeme.c Z85230 M68331 SOFT- WARE KOS KHEPERA VXWORKS APPL. SOFTWARE 7-APPLICATION 2-DATA LINK 1-PHYSICAL sim_systvx.c 8250 ou ou 16550,... M68331 SOFT- WARE KOS KHEPERA LINUX APPL. SOFTWARE 7-APPLICATION 2-DATA LINK 1-PHYSICAL sim_systvx.c 8250 ou ou 16550, ou ou 16550,... KHEPERA SIMUATION LINUX LINUX (Define Macro SIMULATED_SERIAL_PORT) APPL. SOFTWARE 7-APPLICATION 2-DATA LINK 1-PHYSICAL sim_systvx.c named pipe LINUX KHEPERA SIMUATION (Define Macros SIMULATED_SERIAL_PORT and SIMULATED_SERIAL_COM2) (Define Macro SIMULATED_SERIAL_PORT) APPL. SOFTWARE 7-APPLICATION 2-DATA LINK 1-PHYSICAL sim_systvx.c named pipe LINUX Simulated TERMINAL SOFTWARE (pipe_terminal.c) (Define Macros SIMULATED_SERIAL_PORT and SIMULATED_SERIAL_COM2) Fig. 1 Quelques possibilités pour les connexions entre vxworks et le khepera ou leurs simulations respectives. 5

6 int call application layer() : la couche application renvoie une indication correspondant à la fin de traitement de la requête au logiciel de supervision. int call data link layer() : la couche liaison renvoie une indication correspondant à la fin de traitement de la requête au logiciel de la couche application (à réaliser). int call physical layer() : la couche physique renvoie une indication correspondant à la fin de traitement de la requête au logiciel de la couche liaison. Le logiciel de niveau système (que ce soit en simulation ou sous VxWorks) est accessible via les primitives déjà programmées : open 85230b(int parity active, int parity type) permet de lancer l initialisation du 85230, write 85230b(unsigned char *, unsigned char *) permet d émettre une chaîne de caractères tout en commençant à recevoir l écho, read 85230b(unsigned char *, unsigned char) permet de recevoir une chaîne jusqu à réception d un caractère de fin de trame, close 85230b() permet de réinitialiser le coupleur série. Les interfaces entre les différents modules sont gérées à l aide de files d attente. Il faut noter que ces files d attente sont similaires à des boites au lettres. Le superviseur scrute l état des files d attente et donne la main à un module lorsque celui-ci a quelque chose à faire. L accès aux files se fait par deux primitives : push(request *in req) pop(int layer id, request **out req) ou req est pointeur sur une requête ou une indication. Ces actions doivent être faites explicitement dans le programme. Ces primitives renvoient OK si il n y a pas eu de problème et PB sinon. Il faut noter que ces primitives ne recopient que des pointeurs sur des structures de requêtes. Il est de votre responsabilité de vous assurer que les pointeurs manipulés sont valides et en particulier que les zones sur lesquelles ils pointent contiennent en permanence des informations pertinentes. Gestion de mémoire Les structures de type request manipulé dans ce TP sont gérées de façon dynamique, ç.à.d. elles doivent obligatoirement être allouées avant d être remplies et envoyées (avec push()). Pour l allocation nous vous demandons d utiliser la fonction new request() (fourni dans les fichiers memman.c et memman.h). De même manière, toutes les structures dépilées avec pop() doivent être libérées avec delete request(). 4 Description des interfaces Il s agit ici de spécifier les caractéristiques de chaque requête et indication échangée entre les couches. Requêtes et indications sont stockées dans une structure de données nommée request : 6

7 typedef struct { int dest, type, length; char param1[max_len_message], param2[max_len_message]; } request; La structure contient le numéro de couche recevant le message (dest), le type de message, et un attribut nommé length 6 indiquant le nombre de paramètres utilisés par le message, multiplié par -1. Ces structures de données ainsi que le codage des types de requête et d indication vous sont donnés dans le fichier khep.h. 4.1 Composition des trames Les trames échangées entre le Système VxWorks et le khepera sont des chaînes de caractères dans lesquelles on peut distinguer plusieurs parties : Le premier caractère correspond au header de la couche liaison. Il indique au khepera le type d action à entreprendre (W pour écriture ou R pour lecture). l adresse (deux caractères) correspond au header de la couche application. les données proprement dites La couche liaison est chargée de rajouter en fin de chaîne un caractère de fin de trame pour clore le message. 4.2 les requêtes Chaque couche reçoit des requêtes de : connexion, déconnexion, émission, réception. en provenance du la couche supérieure (du module superviseur s il s agit de la couche application) et lui renvoie des indications de : connexion, déconnexion, émission, réception, erreur. 6 le nom a été choisi pour des raisons historiques et difficiles à décrire 7

8 4.3 Interface logiciel/couche application Destination Type Long. Remarques Application RC 0 Application RE -2 Paramètre 1 : la commande à envoyer au dispositif distant. Paramètre 2 : l adresse associée au dispositif distant. Les mnémoniques sont ceux fournis dans khep.h : AD MOTORS, AD SENSORS, AD CONFIG. Application RR -1 Paramètre 1 : l adresse associée au dispositif distant (voir RE). Application RD 0 Logiciel IC 0 Logiciel ID 0 Logiciel IER -1 Paramètre 1 : la couche où a été détectée l erreur irrécupérable (comme entier non signé de 8bit) dans le premier caractère. Logiciel IE 0 Logiciel IR -1 Paramètre 1 : la chaîne reçue. 4.4 Interface couche application/couche liaison Destination Type Long. Remarques Liaison RC 0 Liaison RE -1 Paramètre 1 : la commande à envoyer au dispositif distant. Liaison RR -1 Paramètre 1 : la commande à envoyer au dispositif distant. Liaison RD 0 Application IC 0 Application ID 0 Application IER -1 Paramètre 1 : la couche où a été détectée l erreur irrécupérable (comme entier non signé de 8bit) dans le premier caractère. Application IE 0 Application IR -1 Paramètre 1 : la chaîne reçue. 8

9 4.5 Interface couche liaison/couche physique Destination Type Long. Remarques Physique RC 0 Physique RE -1 Paramètre 1 : la commande à envoyer au dispositif distant. Physique RR -1 Paramètre 1 : la commande à envoyer au dispositif distant. Physique RD 0 Liaison IC 0 Liaison ID 0 Liaison IER -1 Paramètre 1 : le premier caractère donne le niveau de gravité : c : la couche physique est toujours connectée (cas d une erreur d écrasement ou d une erreur de parité) d : la couche physique est déconnectée (perte de ligne, réception d un BREAK ou d un TIME OUT) Liaison IE -1 Paramètre 1 : la chaîne reçue. Liaison IR -1 Paramètre 1 : la chaîne reçue. 4.6 Interface couche physique/système (coupleur) On se borne ici à décrire les quatre primitives accessibles dans le module système (déjà réalisés lors du TP khepera - coupleur E/S ) : open 85230b(int parity active, int parity type) Cette fonction renvoie un entier codant les valeurs suivantes : ID : indication de déconnexion, correspond à la réception d un signal de BREAK, ou à l expiration d un TIME OUT avant d avoir reçu les signaux CTS et DCD du dispositif extérieur, IC : indication de connexion, si l initialisation s est bien passée et si le dispositif de communication a bien renvoyé les signaux DCD et CTS en réponse à DTR et RTS write 85230b(unsigned char *outstring, unsigned char *instring) Les deux paramètres sont des pointeurs sur des chaînes de caractères. Cette fonction envoie tous les caractères de la variable outstring et attend en même temps de recevoir des caractères. Elle rend la main lorsqu elle a émis le dernier caractère de la variable instring ou lorsqu elle a diagnostiqué une erreur non récupérable. Cette fonction renvoie un entier représentant (les constantes sont définies dans systeme.h) : 9

10 le nombre de caractère reçus (supérieur 0), une indication de time out (TIME OUT=-1) une indication de perte de ligne ou de break (LINE ERROR=-2) une erreur de parité ou d écrasement concernant les caractères reçus (FRAME ERROR=-3) read 85230b(unsigned char *instring, unsigned char eof) Le premier paramètre est un pointeur sur chaîne de caractères et le deuxième est un caractère. Cette fonction se met en attente de réception jusqu à ce qu un caractère de fin de trame (conforme à celui spécifié dans la variable eof) soit reçu. Elle rend la main lorsqu elle a reçu ce dernier caractère ou lorsqu elle a diagnostique une erreur non récupérable. Les caractères reçus sont recopiés dans la variable instring passée en paramètre. Les valeurs renvoyées correspondent à celles renvoyées par la fonction write 85230b. close 85230b() Fonction sans paramètre permettant de réinitialiser le coupleur. 5 Protocole de communication Commande W00I W00R W00S W01±xxx±yyy R01 R02 fonction Initialiser le khepera Reset du khepera Arrêter les moteurs (le robot reste initialisé) Configurer les vitesses des deux moteurs (e.g. : W ) Lire les vitesses des deux moteurs (résultat : ±xxx±yyy) Lire les valeurs des capteurs (résultat : 8 valeurs à 3 chiffres) 6 Modifications du protocole depuis les TP 3 et 4 Le TP Automates enseigné cette année a été conçu pour l ancienne plateforme du département, ç.à.d. pour le tapis roulant et la carte dédiée. Le passage au robot khepera a nécessité quelque changements et nous a donné aussi l occasion d apporter quelques améliorations au protocole de communication : Le khepera communique sans bit de parité, l initialisation du coupleur doit donc être légèrement changé pour en tenir compte. Les macros ID et IC (valeurs renvoyées par open 85230b()) ont été changées : leur définition est à supprimer du fichier systeme.c (ou systeme.h). Les valeurs correctes sont définies dans khep.h. cw-gb, version 2.0, 13 avril 2007 rédigé avec L A TEX 10