Vous êtes sur la page 1sur 31

Communication avec un

Robot Lego Mindstorms

Binome :

Encadrants :

DANELON Cline
LAFFITTE Julien

Jrme ERMONT
Frdric BONIOL

Projet Long - DANELON Cline LAFFITTE Julien

Remerciements
Nous tenons remercier lensemble des personnes qui nous ont aid dans nos
recherches :
Pour le protocole IP : Adam Dunkels.
Pour le protocole LNP : Jrme Ermont et Emmanuel Chaput qui ont grandement
facilit notre comprhension du code.
Pour les questions concernant les Lego Mindstorms : le forum Freelug et plus
particulirement Khan et Philo.
Dune manire gnrale toutes les personnes qui ont rpondu nos mails : Ecole des
Mines de Nantes, Club de Robotique de lINSA.
Frdrique Coudret, pour sa disponibilit et ses conseils concernant lenvironnement
LINUX.
Nos encadrants : Jrme Ermont et Frdric Boniol pour leur disponibilit et leurs
conseils.

Projet Long - DANELON Cline LAFFITTE Julien

Sommaire
1.

INTRODUCTION............................................................................................................ 5

2.

QUE SONT LES ROBOTS LEGO MINDSTORMS ? [LEGO01-02] ........................ 5


2.1.
HISTORIQUE ................................................................................................................ 5
2.2.
ORGANISATION DE LA BRIQUE RCX............................................................................ 5
2.3.
COMMUNICATION INFRA ROUGE (IR) SUR LA BRIQUE RCX DE BASE [IR 01] ............. 6
2.3.1.
Caractristiques ................................................................................................. 6
2.3.2.
Le protocole........................................................................................................ 6
2.3.2.1.
Introduction ................................................................................................ 6
2.3.2.2.
Commande ................................................................................................. 7
2.3.2.3.
Paquet ......................................................................................................... 7
2.3.2.4.
RS232 [IR 01] ............................................................................................ 8
2.3.2.5.
Transmission .............................................................................................. 9
2.3.3.
Les limites dune communication IR .................................................................. 9
2.4.
LA PROGRAMMATION RCX ......................................................................................... 9

3.

BRICKOS [BRICK01-02] ............................................................................................. 10


3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
3.9.

4.

PRESENTATION .......................................................................................................... 10
LE NOYAU BRICKOS.................................................................................................. 10
GESTIONNAIRE DE PROCESSUS .................................................................................. 11
DESCRIPTEUR DE PROCESSUS .................................................................................... 11
ETATS ET TRANSITIONS DUN PROCESSUS .................................................................. 11
LORDONNANCEUR BRICKOS .................................................................................... 12
GESTION MEMOIRE .................................................................................................... 13
LES SEMAPHORES ...................................................................................................... 13
BRCIKOS ET LE TEMPS REEL ..................................................................................... 13

LNP : LEGOS NETWORK PROTOCOL [LNP01-03].............................................. 14


4.1.
PRESENTATION .......................................................................................................... 14
4.2.
LA PILE DE COMMUNICATION .................................................................................... 14
4.2.1.
Pr-requis......................................................................................................... 14
4.2.2.
Du point de vue de lordinateur ....................................................................... 14
4.2.3.
Du point de vue du RCX................................................................................... 15
4.2.4.
Schmas rcapitulatifs...................................................................................... 15
4.2.4.1.
Les services LNP...................................................................................... 15
4.2.4.2.
Organisation gnrale............................................................................... 16
4.3.
LES MESSAGES LNP .................................................................................................. 16
4.4.
CONSTRUCTION DES ADRESSES ................................................................................. 17
4.5.
ATTRIBUTION DES ADRESSES..................................................................................... 18
4.6.
LA DETECTION DE COLLISION .................................................................................... 18
4.7.
LE DEMON LNPD [LNP 01] ...................................................................................... 18

5.

IP [UIP01] ..................................................................................................................... 19
5.1.
5.2.
5.3.

CARACTERISTIQUES .................................................................................................. 19
GESTION MEMOIRE .................................................................................................... 20
API ........................................................................................................................... 20

Projet Long - DANELON Cline LAFFITTE Julien

5.4.
IMPLANTATION DE IP .............................................................................................. 20
5.4.1.
La boucle de contrle principale ..................................................................... 21
5.4.2.
Internet Protocol .............................................................................................. 21
5.4.2.1.
Fragmentation IP ...................................................................................... 21
5.4.2.2.
Broadcast et multicast .............................................................................. 22
5.4.3.
ICMP : Internet Control Message Protocol..................................................... 22
5.4.4.
TCP : Transmission Control Protocol ............................................................. 22
5.4.5.
UDP : User Datagram protocol...................................................................... 22
5.5.
SERVICES OFFERTS PAR LNP A IP........................................................................... 22
5.5.1.
Pr-requis......................................................................................................... 22
5.5.2.
Intgration dans le kernel de BrickOS ............................................................. 23
5.5.3.
TCP/IP et le dmon LNPd................................................................................ 23
6.

CONSEILS DINSTALLATION [HOWTO 01] ......................................................... 24


6.1.
CONSTRUCTION DU CROSS COMPILER ........................................................................ 24
6.1.1.
Binutils ............................................................................................................. 24
6.1.2.
Installation du GCC Cross Compiler............................................................... 24
6.2.
BRICKOS................................................................................................................... 25
6.3.
POUR TESTER LINSTALLATION ................................................................................. 26
6.3.1.
Tlcharger le firmware................................................................................... 26
6.3.2.
Lancer le programme de Dmo........................................................................ 26
6.4.
CHARGEMENT DE IP................................................................................................ 27

7.

RESULTATS OBTENUS .............................................................................................. 27

8.

CONCLUSION............................................................................................................... 28

Projet Long - DANELON Cline LAFFITTE Julien

1. Introduction
Ce projet prsente une tude des robots Lego Mindstorms, petits calculateurs trs
priss dans les laboratoires de recherche aussi bien pour faire du temps rel que de
lintelligence artificielle. Notre but tait danalyser la capacit de communication des ces
robots afin de modliser un systme temps rel de base.
La principale difficult consistait comprendre comment cette communication tait
mise en uvre et lintgrer sur le robot.
Dans un premier temps, nous nous sommes intresss BrickOS, systme
dexploitation ddi la gestion de la communication sur les mindstroms et lutilisation
maximale de leurs capacits calculatoires.
En complment de celui-ci a t dvelopp un protocole spcifique pour la
communication infra rouge entre un PC et un ou plusieurs robots, le protocole LNP.
Ensuite, nous nous sommes interrogs sur les possibilits de mise en place dune pile
IP rduite. Pour cela nous avons tudi le protocole IP, ses principales caractristiques et
son interfaage avec le protocole LNP.

2. Que sont les robots LEGO Mindstorms ? [LEGO01-02]


2.1. Historique
Les LEGO Mindstorms sont ns il y a une quinzaine dannes de la collaboration
entre LEGO et le Massachusetts Institutes of Technology (MIT). Fred Martin, un chercheur
du MIT, a particip grandement au dveloppement de la technologie actuellement utilise
dans les microprocesseurs. Cest ensuite la contribution du Professeur Seymour Papert qui
a permis lintgration dun langage de programmation dans la brique LEGO. En effet, ce
dernier est un pionnier dans lintelligence artificielle et est lorigine du Logo1 programming
language. En travaillant conjointement avec LEGO, il a donc particip son intgration la
brique LEGO.
Le matre mot de LEGO est, A first-time user with basic PC skills can design,
program, and build a simple robot within one hour.

2.2. Organisation de la brique RCX


Le Cur du kit Mindstorms est la brique RCX programmable. Le RCX comporte 3
entres capteurs et 3 sorties moteurs, possde 32 Ko de mmoire vive ainsi que de la
mmoire morte laquelle on ne peut avoir accs. Ce petit cerveau peut excuter 1000
commandes par secondes. Il fonctionne avec un microcontrleur 8 bits de la gamme Hitachi
H8/3297 une vitesse de 16 MHz. De plus, pour communiquer avec un ordinateur un port
infra-rouge a t mis en place.

Logo est un langage fonctionnel, interprt, qui permet une utilisation directe sans passer par une phase de compilation.

Projet Long - DANELON Cline LAFFITTE Julien

Communication Infra rouge avec un


PC

Figure 1 : Organisation du RCX

2.3. Communication Infra Rouge (IR) sur la brique RCX de base [IR 01]
Dans cette partie nest aborde que la communication implante sur le RCX de base,
on ne fera rfrence qu une communication srie classique, aucune information relative
lUSB ne sera dtaille.

2.3.1. Caractristiques
La communication entre un ordinateur et le RCX se fait au moyen dun port IR. Il
sagit dune communication half duplex, en effet le rcepteur IR est satur pendant que
lmetteur fonctionne. Le RCX utilise une porteuse 38kHz, cependant dans sa nouvelle
version 2.0 le rcepteur est accord sur une modulation 76kHz, ce qui permet la
compatibilit descendante avec des produits Lego plus rcents (Spybots, Manas...) et
ascendante avec les anciens RCX.
Le dbit est de 2400 bps, autrement dit un bit toutes les 417 s ce qui se rapproche
des performances des tlcommandes pour tlviseurs classiques.

2.3.2. Le protocole
2.3.2.1.

Introduction

La communication est faite en mode maitre-esclave o le RCX est un esclave.


Chaque donne est transporte dans un paquet.

Projet Long - DANELON Cline LAFFITTE Julien

On encode 2400bps, avec un code NRZ (Non Return To Zero). La trame sorganise
avec 1 bit de start, 8 bits de donnes, 1 bit de parit et un bit de stop ce qui est
caractristique dune communication srie de type RS232, comme nous allons le voir par la
suite.

Start

Data

Odd
parity

Stop

Figure 2 : Trame IR

Quatre niveaux de communication sont mis en uvre :


Commande
Paquet
RS232
Transmission (modulation/longueur donde)
2.3.2.2.

Commande

Ce niveau de communication permet denvoyer des commandes au RCX ou de


recevoir des requtes. Les commandes sont de quatre types :
Immediate commands (y compris les requtes dinformation)
Download commands
Remote Control Commands
2.3.2.3.

Paquet

Comme mentionn prcdemment tout type de donnes est encapsul dans un


paquet constitu :
Dune en-tte : 55 FF 00
Des bits de donnes, chaque octets est suivi de son complment ainsi pour
transmettre 55 F7 on envoie 55 AA F7 08
Un checksum qui correspond la somme de tous les octets, lui aussi suivi de
son complment
Le format gnral dun paquet est le suivant :
0x55 0xff 0x00 D1 ~D1 D2 ~D2 ... Dn ~Dn C ~C
o D1... Dn reprsente le corps du message, et C = D1 + D2 + ... Dn

Exemple
Un message est une commande immdiate de type F7 suivie par le numro du
message et encapsul dans un paquet ce qui se traduit comme suit :
55 ff 00 f7 08 12 ed 09 f6
est un paquet envoyant le message 0x12 au RCX.

Projet Long - DANELON Cline LAFFITTE Julien

Le RCX nexcute jamais deux fois le mme opcode sur une ligne, par
consquent, chaque commande a deux occurrences. Une avec le troisime
bit positionn 1 et lautre avec ce mme bit 0. Pour envoyer une
commande deux fois il faut donc alterner ce bit.

Exemple
Lenvoie de donnes peut tre une requte (ordinateur vers RCX) ou une rponse
(RCX vers ordinateur). La rponse se traduit pas le complment 1 du opcode de la requte
et rciproquement.
Op 0x10 Alive Request / Op 0xef Alive Response
Op 0x18 Alive Request / Op 0xe7 Alive Response
0x10 et 0xef sont complmentaires
0x18 et 0xe7 sont complmentaires
0x10 et 0x18 diffrent seulment par le bit 0x08
0xef and 0xe7 diffrent seulment par le bit 0x08
Remarque :
Le schma utilis pour la transmission rsulte en un nombre gal de bits 0 et 1,
ce qui permet un rcepteur de corriger une erreur qui proviendrait dun signal de lumire
constant en soustrayant la valeur moyenne du signal. Par ailleurs, on remarquera que
lentte est aussi constitue dun nombre quivalent de 0 et de 1, ce qui permet de rveiller
le rcepteur avant que les donnes utiles soient envoyes.
2.3.2.4.

RS232 [IR 01]

Voici une liste des diffrents changes relatifs une communication srie.
PC

IRtower

Name

Description

Notes

CD

Carrier Detect

not connected

RD

Receive Data

RCX==>PC

TD

Transmit Data

PC==>RCX

DTR

Data Terminal
Ready

connected, but not used

SG

Signal Ground

DSR

Data Set Ready

not connected

RTS

Ready To Send

must be high to receive or send data

CTS

Clear To Send

used to detect if tower is connected to


PC,
because it's connected in the IR-tower to
RTS

RI

Ring Indicator

not connected

Projet Long - DANELON Cline LAFFITTE Julien

2.3.2.5.

Transmission

Un 0 est cod par un pulse de 417s une frquence de 38kHz, pour un 1 la


frquence est nulle.

2.3.3. Les limites dune communication IR


Lutilisation de lIR pour communiquer des donnes au RCX nest pas sans problme,
en effet, la perte de paquets est chose courante. Tout dabord ce systme est trs directif,
autrement dit la Tour USB et le capteur du RCX doivent tre en vue directe une distance
infrieure 1m (les rayons infra rouge ne peuvent pntrer des objets opaques). De plus, il
ne doit pas tre utilis dans une pice avec une lumire trop vive qui viendrait alors perturber
les changes.
De plus, des pertes trop nombreuses peuvent devenir handicapantes lorsque lon
veut tablir un systme temps rel.

Figure 3 : Champ de vision Infra rouge dun module RCX

2.4. La programmation RCX


Au dpart, tout a t optimis pour rendre la
programmation
la
plus
simple
possible.
Lenvironnement de programmation est un
environnement graphique qui permet partir dune
bibliothque de composants de faire des glisser,
dposer. Ainsi, il ny a aucune ligne de code
crire.
Des blocks de code qui reprsentent des
commandes sont affichs sous forme dicnes. On
peut ainsi choisir la commande dsire parmi celles
disponibles dans la bibliothque. Quelques clicks
suffisent donc pour charger un programme et lexcuter.
De plus, chaque RCX peut stocker cinq programmes diffrents permettant un
mme robot dexcuter plusieurs actions diffrentes.
Bien que trs simple ce langage de programmation reste assez limit et donc sont
apparus de nouveaux langages tels que NQC (Not Quite C), PbForth (reprise de l'ancien

Projet Long - DANELON Cline LAFFITTE Julien

langage Forth) et un systme dexploitation BrickOS (anciennement LegOS). Cest ce


dernier que nous allons nous intresser.

3. BrickOS [BRICK01-02]
3.1. Prsentation
BrickOS (anciennement LegOS) est un systme dexploitation embarqu open source
crit par Markus Noga qui vient remplacer le firmware dorigine de la brique RCX.
Il offre un environnement de programmation en C/C++ permettant ainsi de surpasser
le logiciel de programmation graphique fourni avec la brique. En effet, il donne un accs total
la mmoire du RCX et fait bnficier de la puissance du C : Think 32 k not 32
variables . Autrement dit, on est plus limit lutilisation de 32 variables mais on peut dfinir
un ensemble de donnes qui se partagent les 32 Ko de mmoire. Il offre galement une bien
meilleure exploitation de la liaison Infra-Rouge entre PC et RCX.
Des utilitaires2 pour charger lOS sur le RCX et les programmes compils y sont
associs.
Cest un noyau monolithique : ses sources sont compiles dans la mme image
binaire qui est ensuite tlcharg sur le RCX. Il nintgre pas de systme de fichier puisquil
ne possde aucun priphrique de stockage de masse, mais il propose nanmoins un
certain nombre de fonctionnalits :
Gestion du multitche avec premption,
Implantation des smaphores (POSIX 1003.b compliant),
Ordonnanceur systme de priorit multiple,
Gestion dynamique de la mmoire.
Le noyau brickOS est plac dans la partie suprieure de la RAM du RCX tandis que
les programmes utilisateurs sont implants dans sa partie infrieure.

3.2. Le noyau brickOS


BrickOS utilise un systme de scrutation pour communiquer avec ses sous
ensembles : la fonction systeme_handler scrute les diffrents ensembles du RCX en
appelant tour tour leur handler respectif. Cette fonction est appele via un vecteur
dinterruption invoqu toutes les millisecondes par le timer 16 bits du RCX.
A chaque appel, plusieurs oprations sont ralises :
Incrmentation de system timer,
Appel du pilote des moteurs puis de celui du son,
Examination de LNP,
Appel du pilote des boutons,
Mise jour de lindicateur de ltat des batteries du RCX,
Mise jour de laffichage LCD.
La dernire opration effectue est la vrification du changement de contexte. Si le
compteur de temps partag du processus courant est dpass, alors la fonction tm_switcher
est appele : cest elle qui ralise le changement de contexte avec laide de lordonnanceur.

Comme lutilitaire firmdl3.

10

Projet Long - DANELON Cline LAFFITTE Julien

3.3. Gestionnaire de processus


Le gestionnaire de processus implmente un systme multitche premptif, c'est-dire que le temps de calcul processeur est allou priodiquement chaque processus et
pour une dure de temps prdfinie.
Par dfaut, cette dure est de 20 ms. Cependant le quantum de temps minimum est
de 6 ms tandis que le maximum est fix 255 ms.
Lors de sa cration, chaque processus se voit galement allou une priorit quil
conserve jusqu' sa mort. 20 niveaux de priorit ont t dfinis, le plus bas tant 0 et le plus
haut tant 20.
Le pointeur priority_head permet daccder aux diffrents niveaux de priorit en
pointant sur le niveau de priorit le plus lev. Chaque descripteur de processus est inclus
dans une liste doublement chane et comporte un pointeur priority.
Tout processus comporte un descripteur et lensemble des descripteurs est organis
en files dont notamment une par niveau de priorit.
Avant toute excution de programme, la structure contient uniquement deux
descripteurs de processus : un de priorit 0 et lautre de priorit 20. Le premier est utilis
pour mettre le RCX en veille, c'est--dire que lorsquil ny a aucun programme excuter, un
processus dattente est excut avec la priorit la plus basse.
Le second descripteur correspond au processus utilis pour la rception de donnes
via le port de communication IR.

3.4. Descripteur de processus


Chaque processus brickOS est cr en appelant la fonction execi qui prend en
paramtre le nom dune procdure systme ou utilisateur. De plus, La fonction doit retourner
une valeur entire et avoir comme paramtre le nombre darguments suivi de ceux-ci (char
*argv[]).
Lors de sa cration, execi ajoute son descripteur la structure gnrale, lopration
tant protge par un mcanisme de smaphore afin dassurer lexclusion mutuelle entre les
diffrents processus.
Il est galement dcrit par une structure de donnes pdata_t contenant les
informations suivantes :
Pointeur de pile,
Pointeur de dbut de la structure de pile,
Etat du processus,
Priorit du processus,
Pointeur sur le prochain processus de la file,
Pointeur sur le processus prcdent.

3.5. Etats et transitions dun processus


Comme pour un processus Unix, les processus brickOS se caractrisent par un
certain nombre dtats dfinissant leur statut. Ces tats sont au nombre de 5 :
Dtruit (dead) : le processus est termin et sa pile dsalloue,
Zombie : le processus sest termin mais sa pile nest pas libre,
Bloqu (waiting) : le processus est bloqu en attente dun vnement,
Prt (sleeping) : le processus est prt tre excut,
Actif (running) : le processus est en excution.

11

Projet Long - DANELON Cline LAFFITTE Julien

Ces 5 tats permettent de construire un automate du cycle de vie dun processus :

Figure 4 : Cycle de vie dun processus

Cette information concernant ltat du processus est utilise par lordonnanceur de


brickOS pour la distribution des temps de calcul RCX mais galement pour raliser la
libration des piles mmoire des processus termins.
Chaque processus brickOS peut galement stopper volontairement son excution en
appelant lune des fonctions suivantes :
Yield() : le processus restitue la ressource processeur mme si il se trouve
dans son quantum dmission,
Msleep(int time) : le processus attend lexpiration dun dlais (en ms) pass en
paramtre de la fonction,
Sleep(int time) : le processus attend lexpiration dun dlais (en s) pass en
paramtre de la fonction,
Wait_event(evt) : le processus se met en attente dun vnement pass en
paramtre de la fonction. Elle joue le rle dun rveil pour le processus qui a au
pralable t mis en attente.
Sem_wait(x) : primitive bloquante.

3.6. Lordonnanceur brickOS


Lordonnanceur de brickOS permet dallouer les ressources du RCX priodiquement
aux diffrents processus en cours dexcution et pendant une dure limite (Cf. 2.3
Gestionnaire de processus). Pour cela, il utilise un mcanisme de round robin et examine les
listes de processus dans lordre de priorit dcroissant : si le processus suivant est dans
ltat prt, alors il est lu et passe dans ltat actif.
Lorsquune liste de priorit est termine, lordonnanceur passe la suivante.
Il y a ici combinaison entre des ressources partages et protges par un mcanisme
de smaphore et lordonnancement de processus par priorit : cela peut introduire un
phnomne dinversion de priorit. Il peut en effet arriver quun processus de haute priorit
soit bloqu en attente des ressources du RCX par un processus de moindre priorit qui
consomme son temps de parole.

12

Projet Long - DANELON Cline LAFFITTE Julien

3.7. Gestion mmoire


BrickOS nutilise pas de mcanisme de gestion de la mmoire avanc tel que la
pagination ou la segmentation mmoire. Il utilise un schma dallocation linaire de la
mmoire ou chaque bloc comprend un en-tte de 4 octets et n octets de donnes :

Figure 5 : Bloc mmoire de base

Dans chaque en-tte, 2 octets sont rservs pour lidentifiant du processus tandis que
les 2 derniers sont utiliss pour spcifier la taille des donnes qui suivent.
La mmoire est rpartie entre le noyau et les programmes utilisateurs.

3.8. Les smaphores


Les smaphores implants dans brickOS rpondent au standard POSIX 1003.b et
permettent la synchronisation entre processus concurrents. Les oprations de base
possibles sont les suivantes :
Dcrmenter le compteur de manire atomique et bloquer ventuellement le
processus appelant,
Incrmenter le compteur de manire atomique.
Le dtail et lutilit des fonctions lies aux smaphores dans brickOS sont disponibles
dans le document [BRICK02].
Dans les programmes utilisateurs (clients ou pour le RCX) la gestion des smaphores
devra tre ralise soigneusement de manire viter les situations de famine pour les
processus de basse priorit. Dans le cas contraire, on ne pourra pas garantir que tout
processus pourra accder aux ressources dans un temps fini.

3.9. BrcikOS et le temps rel


Lanalyse de brickOS nous permet de voir quil met en uvre un systme de
scrutation pour communiquer avec les sous-ensembles, lallocation priodique dun temps de
calcul processeur, la mise en uvre de priorit, le round robin qui sont autant de mcanisme
indispensable la mise en uvre du temps rel.

13

Projet Long - DANELON Cline LAFFITTE Julien

4. LNP : LegOS Network Protocol [LNP01-03]


4.1. Prsentation
Dans le cadre de l'utilisation de la communication Infra Rouge (IR), BrickOS a
dvelopp le protocole LNP concurrent de celui de Lego : il est utilis pour les
communications entre un ordinateur et un ou plusieurs RCX.
LNP est inclus dans le noyau de BrickOS, mais il est cependant ncessaire de
tlcharger le package LNP pour lutiliser sur une station de travail (le plus couramment
Unix). Dans ce cas, un dmon LNPd est cr sur la machine communicante et ncessite
lutilisation dune bibliothque liblnp.

4.2. La pile de communication


Pour illustrer le fonctionnement du protocole LNP, nous allons suivre les diffrentes
oprations effectues sur un paquet jusqu lcriture des donnes dans la mmoire du RCX.

4.2.1. Pr-requis

Le RCX doit tre allum et BrickOS doit avoir t charg en mmoire.


Le dmon LNPd est lanc sur la machine UNIX.
La Tour USB est connecte.

Avant dtre transmises au RCX par lintermdiaire de la connexion IR, les donnes
doivent tre traites par le dmon LNPd. Pour ce faire, un addressing handler ou un integrity
handler doit tre appel (on rappelle que la seule diffrence entre ces deux handlers est que
ladressing handler envoie des paquets LNP auquel on a ajout une adresse source et
destination). Le choix de la routine se fait en fonction du type de connexion que lon veut
offrir : les messages dintgrit sont utiliss dans le cas dun broadcast tandis que les
messages adresss permettent dtablir du point point.
De manire gnrale on se soucie peu de ce choix, en effet, notre communication
nimplique quun seul RCX et un seul ordinateur.
Nous avons travaill avec le handler mis en place par le fichier lnptest.c qui est un
adressing handler.

4.2.2. Du point de vue de lordinateur


On doit faire appel une fonction du type :
lnp_addressing_write(unsigned char *data, unsigned char length, int dest_addr, int
port)3:
Fonction qui permet d'envoyer des donnes sur le rseau. Les paramtres data et
length permettent respectivement de prciser les donnes envoyer et leur longueur. Les
paramtres dest_addr et port permettent respectivement de spcifier l'adresse de destination
du paquet et le port sur lequel envoyer les donnes.
Elle passe ensuite le paquet la fonction lnp_logical_write(unsigned char * data,
int length) qui se charge de la communication avec le socket pour transmettre les donnes
la connexion IR.

Le nom des fonction peut changer suivant la version de LNP utilis, nous avons travaill avec la version 0.9

14

Projet Long - DANELON Cline LAFFITTE Julien

4.2.3. Du point de vue du RCX


La rception des messages sur le RCX se fait au moyen dinterruptions. Lensemble
des fonctions relatives ce traitement est contenu dans le lnp-logical.h. Une machine tat
est construite pour recevoir et envoyer les octets, elle reconnat et dcode les trames LNP et
pour chacun teste leur validit par un calcul du checksum.
Les principales fonctions mises en jeu sont set_integrity_handler(), respectivement
set_adressing_handler() : chaque arrive de messages elles associent le bon handler.
Le RCX, comme lordinateur, peuvent tre uniquement dans deux tats : tx_state ==
TX_ACTIVE qui correspond lenvoie de messages et le tx_state != TX_ACTIVE pour la
rception.
Lors de la rception, les octets sont ensuite passs la fonction lnp_integrity_bytes().
A ce niveau de la machine tats la validit de la trame est analyse. Si elle est correcte
elle est ensuite passe la fonction get_packet() qui vrifie lexactitude de lidentifiant de
lhte et du numro de port, si il y a des erreurs la trame est ignore.
Le handler analyse ensuite le paquet et copie ventuellement les informations dans la
mmoire du RCX.
Remarque
Lenvoi de donnes du RCX lordinateur est similaire, en effet les mmes fonctions
sont prsentes sur le PC et le RCX.

4.2.4. Schmas rcapitulatifs


4.2.4.1.

Les services LNP

Les services prsents prcdemment sorganisent en deux couches correspondant


aux deux couches les plus basses du modle OSI :
Le niveau liaison de donnes se divise en deux entre integrity et adressing,
la couche physique est reprsente par le niveau logical.

Intgh ()

Lnp _integrity _write ()

Lnp_addressing _write ()

Integrity

Addrh ()

Adressing
Lnp_logical_write ()

Get_packet ()

Logical

Get_packet ()

Support de
communication

Figure 6 : Les services LNP

15

Projet Long - DANELON Cline LAFFITTE Julien

Lors dune demande dcriture, suivant le handler choisi, on fait appel la fonction
lnp_xxx_write() qui elle-mme appelle lnp_logical_write(). Les donnes sont ensuite
diriges vers les sockets de lnplib.
Lors dune rception de donnes, la couche logical invoque la fonction get_packet(),
qui elle-mme fait appel intgh() ou addrh() selon le handler.

4.2.4.2.

Organisation gnrale

lnptest

Client

Services

Handler

LNPd
RCX

inet

daemon

Rcv_handler

Librairie qui offre


des services
lapplication et au
dmon

Figure 7 : Fonctionnement LNP

Sur lordinateur, le dmon LNPd doit tre lanc. Il met et reoit des
messages provenant du RCX par la tour infrarouge. Il communique via des sockets inet avec
la librairie lnplib et accde ainsi aux services fournis par LNP.
Les donnes du PC sont transmises vers le dmon travers un socket.
La librairie liblnp qui sera lie l'application envoie sur un socket.

4.3. Les messages LNP


Il existe 2 types de messages gnrs par LNP :
Les messages dintgrit : ils ne contiennent aucunes informations
dadressage et peuvent tre considrs comme lquivalent dun mcanisme
de broadcast.

Figure 8 : Message LNP dintgrit

16

Projet Long - DANELON Cline LAFFITTE Julien

Le champ longueur de donnes tant sur un octet, les donnes sont limites
une taille de 255 octets et le paquet a donc une taille maximale de 258 octets.
Les messages dadressage : ils sont quivalents un message dintgrit
contenant la fois des donnes et des informations dadressage dans le
champ IDATA.

Figure 9 : Message LNP dadressage

Ce sont des paquets similaires aux paquets UDP cest dire quil ny a
aucunes garanties sur leur arrive. En revanche, si les paquets arrivent ils ne
contiendront aucune erreur. Les paquets sont toujours envoys un hte
spcifique sur un port spcifique sur lequel un handler doit couter : dans le
cas contraire ou si une erreur se produit, alors le paquet est rejet.
Les champs DEST et SRC correspondent respectivement ladresse du
destinataire et de la source.
Dans ltat actuel, le protocole LNP nest donc pas fiabilis. Il existe cependant un
troisime type de paquets qui permet lacquittement de donnes. Lmetteur attend un
acquittement du rcepteur avant de poursuivre sa transmission.
Un systme de time-out est mis en place et qui force la retransmission dune donne.
Le nombre de retransmissions est limit 5 par dfaut avant la destruction du paquet.
Cependant ce type dchange nest pas standardis dans le protocole LNP et na
pour linstant t implant que dans le programme de tlchargement des donnes vers le
RCX.
Un protocole tel que LNP de type UDP constitue le meilleur choix lorsque lon
privilgie les performances par rapport lintgrit, par exemple dans le cas dune
communication audio o lon supporte de perdre quelques bits.

4.4. Construction des adresses


Les adresses LNP source et destination sont contenues dans le champ de donnes
du message dadressage (Cf. 3.1 Les messages LNP). Chaque champ est cod sur un octet,
qui se divise lui-mme entre une adresse hte et un numro de port associ.
La macro CONF_LNP_HOSTMASK dfinie dans le fichier /lnp/sys/lnp.h ou /dllsrc/config.h permet de spcifier le nombre de bits qui sont respectivement utiliss pour
ladresse et le port de lhte. Lutilisateur peut donc fixer le format des champs selon le
nombre de RCX quil souhaite faire communiquer et le nombre de processus destins tre
implants.

17

Projet Long - DANELON Cline LAFFITTE Julien

Par dfaut, CONF_LNP_HOSTMASK a pour valeur 0xF0 : il y a donc 4 bits rservs


pour les adresses htes et 4 bits rservs pour leurs ports, soit 16 htes comprenant chacun
16 ports.
Pour dfinir un adressage spcifique, il suffit de positionner la macro avec la valeur
hexadcimale correspondante, par exemple 0x80 pour 2 machines comprenant chacune 128
ports.

4.5. Attribution des adresses


Ladresse de lhte peut tre dfinie grce la macro CONF_LNP_HOSTADDR : elle
est donc spcifie de manire statique lorsque lon tlcharge un programme sur le RCX ou
lorsque lon excute un programme client sur le PC.
Ladresse de destination des messages est quand elle passe en paramtre de la
fonction lnp_adressing_write() : de cette manire, on dfinit ladresse de destination de
chaque paquet envoy.
Remarque :
On ne spcifie ladresse de destination que dans le cas des messages dadressage
puisque les messages dintgrit sont diffuss lensemble des lments connects.

4.6. La dtection de collision


Lalgorithme de dtection de collision implant dans le protocole LNP permet de
vrifier que les bits que lon vient de transmettre ont bien t reus par le destinataire.
Si une collision est dtecte, la fonction txend_handler() du fichier lnp-logical.c est
appele de manire stopper la transmission. Il est en effet inutile de continuer lmission
puisque LNP nintgre pas de mcanisme de correction derreur : les erreurs dues au lien IR
ne peuvent tre corriges.
Par ailleurs, afin dviter une situation de blocage lors de lmission des diffrents
htes, LNP met en uvre un mcanisme de CSMA / CD. Lorsque le RCX reoit un octet
spcifique, il ne peut plus mettre pendant une dure dfinie dans la macro
LNP_BYTE_SAFE du fichier include/lnp/sys/lnp-logical.h.
Le RCX scrute alors le support pour vrifier quaucune autre mission nest pas dj
en cours : si le support est libre, alors il peut mettre un nouvel octet. Lorsquil a termin la
transmission dune trame complte, lhte perd nouveau le droit dmettre pour une
priode spcifie dans la macro LNP_WAIT_TXOK. Cette temporisation de lmission
permet aux ventuels autres RCX du rseau denvoyer leurs donnes.
Si une collision se produit, chaque RCX stoppe sa transmission en cours pendant une
dure alatoire contenue dans la variable allow_tx. Les r-missions pourront ainsi se faire
progressivement sans nouvelle collision.
Ce mcanisme permet dviter les situations dinterblocage entre les diffrents htes,
ce qui est primordial si on veut faire du temps rel.

4.7. Le dmon LNPd [LNP 01]


Le daemon LNPd, un dmon linux, permet de communiquer plus facilement avec le
RCX, lors de lutilisation de BrickOS. Il nest pas obligatoirement ncessaire, il nest utile que

18

Projet Long - DANELON Cline LAFFITTE Julien

dans le cas o lon souhaite tablir une communication entre le code sur le RCX et celui sur
lordinateur.
Il ne fait pas partie intgrante de BrickOS et doit donc tre tlcharg sparment. La
seule chose faire pour lutiliser est de le lier lapplication.
Ce dmon comme nous le verrons par la suite est indispensable pour lintgration de
IP.

5. IP [uIP01]
5.1. Caractristiques
IP constitue limplmentation la plus minimaliste de la pile IP dfinie par la RFC1122.
Elle est destine tre embarque sur des microcontrleurs tels que le RCX ayant une
faible quantit de mmoire embarque ainsi quune faible puissance de calcul. En effet, la
taille du code est de lordre de quelques kilo-octets et lutilisation de la RAM peut-tre
configure de faon noccuper que quelques centaines doctets.
De plus, lutilisation de cette pile facilite linterfaage avec LNP puisque lintgration de
lnplib a t prvue. Dans le cas de IP classique il aurait fallu dvelopper de nouvelles
fonctions pour appeler les sockets du noyau.
Cette pile IP ne peut grer quune seule interface rseau et se concentre sur les
protocoles IP, ICMP et TCP : le protocole UDP nest implant que de manire rudimentaire
comme nous le verrons au paragraphe 5.4.5.
Le tableau suivant dresse un rcapitulatif des diffrentes caractristiques prsentes
dans la pile IP :

Figure 10 : Caractristiques de IP

Plus gnralement, lensemble des fonctionnalits requises pour une communication


point point entre 2 htes ont t conserves. En effet, un algorithme de calcul de
checksum est mis en uvre, la gestion de plusieurs ports est supporte permettant ainsi

19

Projet Long - DANELON Cline LAFFITTE Julien

lexcution de plusieurs applications simultanes. En revanche il ny a pas de mcanisme de


fentre glissante, le contrle de congestion ntant pas ncessaire puisque lon se place
dans le cadre dune communication point point.

5.2. Gestion mmoire


La pile IP nutilise pas une gestion de la mmoire dynamique : elle dispose dun
tampon global pour stocker les paquets ainsi quune table statique afin de conserver les
tats de connexions.
Le tampon pourra contenir un seul paquet de taille maximale : lorsquun paquet est
reu et quil contient des donnes, lapplication de niveau suprieur doit tre avertie. Par
ailleurs, les donnes utiles devront tre copies par lapplication afin quelles ne soient pas
perdues lors de larrive du paquet suivant. Si ce dernier arrive alors que les donnes sont
en cours de traitement, il est stock dans un second tampon soit par lquipement rseau
soit par son driver.
Le tampon global est la fois utilis pour les paquets entrants et les en-ttes des
paquets sortants : il est utilis pour stocker les en-ttes des paquets sortants avant
transmission.
En cas de retransmission, les donnes ne sont pas stockes dans le tampon, cest
lapplication qui se chargera de les reproduire la demande de IP.

5.3. API
Les API socket BSD employes dans les systmes dexploitation Unix ne conviennent
pas pour IP parce quelles ncessitent des ressources mmoire trop importantes. Le
mcanisme implant dans IP utilise un systme dvnements dans lequel une application
est invoque en rponse un certain type dvnement.
Pour ce faire une application (fonction C) est mise en place au dessus de IP. La pile
lappelle lorsque des donnes sont reues, quand des donnes ont t transmises avec
succs, quand une connexion a t tablie ou encore pour demander une retransmission.
Les temps de rponses doivent tre faibles puisque lapplication doit tre capable de
traiter les paquets entrants et les demandes de connexion, en mme temps que la pile IP
reoit les paquets.
Comme expliqu prcdemment, pour une meilleure gestion de la mmoire, IP fait
appel lapplication pour rgnrer les paquets retransmettre. Un flag est alors envoy
pour demander une retransmission : lapplication le vrifie et produit la donne adquate.
Cette technique ne complexifie pas lapplication puisque la retransmission sapparente
lenvoi dun paquet classique : la seule difficult se situe au niveau de IP qui doit savoir
quand la demander.

5.4. Implantation de IP
Contrairement la pile IP classique, limplantation des protocoles de IP est
troitement lie dans le but de rduire lutilisation mmoire.

20

Projet Long - DANELON Cline LAFFITTE Julien

5.4.1. La boucle de contrle principale


Une boucle de contrle principale a t dfinie : elle consiste en deux oprations
ralises priodiquement :
Vrification de larrive dun paquet depuis le rseau,
Vrification de la validit des timers.

Figure 11 : Boucle de contrle principale

Lorsquun paquet arrive, la routine de la pile TCP/IP est invoque. Le paquet est
trait par la pile ou lapplication concerne qui peut alors gnrer un ou plusieurs paquets de
rponse traits par les couches basses.
Lorsquun timer expire, il fait appel aux mcanismes TCP. Les couches basses se
chargent de retransmettre le paquet perdu.

5.4.2. Internet Protocol


La seule diffrence avec le protocole IP classique est que lon ne tient pas compte
des options.
5.4.2.1.

Fragmentation IP

IP reprend le principe utilis dans IP, savoir lutilisation dun buffer pour stocker
tous les fragments reus. Toutefois, un seul paquet la fois pourra tre rassembl, ce qui
ne semble pas poser de problme puisque ce mcanisme est rarement mis en place.

21

Projet Long - DANELON Cline LAFFITTE Julien

5.4.2.2.

Broadcast et multicast

Pour linstant aucune implmentation nest encore dveloppe.

5.4.3. ICMP : Internet Control Message Protocol


Par souci de simplification, seuls les messages echo request et echo reply ont t
implments. Cela est fait de manire simple : pour rpondre un echo request on change
ladresse source et destination dans len-tte du paquet de rponse et on recalcule le
checksum.

5.4.4. TCP : Transmission Control Protocol


Limplmentation de TCP est pilote par larrive des paquets et lexpiration de timer
par lintermdiaire de la boucle de contrle principale. On sadresse ensuite lapplication
pour un traitement adquat selon que lon a reu un paquet de donnes ou un acquittement.
Chaque fonctionnalit de TCP est donc mise en place par lintermdiaire dune
fonction spcifique. Par exemple pour recevoir des donnes on utilisera :
la fonction uip_newdata() pour savoir lorsque des donnes ont t envoyes
la fonction uip_datalen() pour rcuprer la longueur des donnes
Pour une liste exhaustive des fonctions se reporter au chapitre 1.4 de [uIP02]

5.4.5. UDP : User Datagram protocol


Le protocole UDP implant dans IP nest pas encore compltement achev. En
effet, la rception ou lenvoie de paquets en broadcast ou multicast nest pas supporte,
seule des applications essentielles sont dveloppes comme lenvoie de requtes DNS.
On peut aussi dfinir le nombre de connexions UDP concurrentes et si le checksum
doit tre calcul. On prcisera galement le nom de la fonction C qui doit tre appele quand
un datagramme UDP est reu.
On pourra se reporter au chapitre 5.15 de [uIP02] pour plus dinformations sur la
configuration dUDP.
Remarque :
Il est dommage que seule une implantation rudimentaire de UDP soit prsente dans
IP. En effet, pour des communications temps rel cest le protocole le plus adapt puisquil
ny a aucune retransmission et donc aucune perte de temps.

5.5. Services offerts par LNP IP


5.5.1. Pr-requis
Tout dabord, il faut charger la pile IP sur le RCX. Ce thme sera abord dans la
partie 5 Procdures dinstallation.

22

Projet Long - DANELON Cline LAFFITTE Julien

5.5.2. Intgration dans le kernel de BrickOS


Lide est dutiliser la couche dintgrit comme moyen de transport des paquets IP
ce qui permet de bnficier de la dtection de collision tout en ayant un overhead minimal de
3 octets correspondants F0, la longueur et le checksum.
De plus, le fait dutiliser une plie TCP/IP, mme rduite, sur le RCX et une passerelle
LNP-TCP/IP sur lordinateur permet galement dutiliser un langage de programmation qui
supporte les sockets.
Par ailleurs en utilisant LNP on continue faire des conomies de mmoire.

IP
Services de la couche
dintgrit

LNP
Figure 12 : Interfaage entre LNP et IP

5.5.3. TCP/IP et le dmon LNPd


Le dmon LNPd est utilis pour interagir avec lapplication cliente en tant que
passerelle TCP/IP-LNP.
Sur le RCX, la pile IP se charge de la transmission des paquets en sappuyant sur
les messages dintgrit.

Client

Figure 13 : IP et LNPd

En effet, il est plus facile dutiliser les messages dintgrit ; dans le cas contraire il
est ncessaire de dvelopper une table statique contenant une association entre le numro
de port LNP et ladresse de chaque RCX. Elle serait stocke sur le PC et remise jour
priodiquement par un mcanisme de polling. On laissera donc lapplication le soin de
dterminer si les messages la concernent.

23

Projet Long - DANELON Cline LAFFITTE Julien

De plus le plus souvent, un seul RCX est considr, donc lutilisation du broadcast
nest pas gnante.

6. Conseils dinstallation [HOWTO 01]


2.6.x4.

Cette partie vise dcrire la configuration et linstallation de BrickOS sur un noyau

6.1. Construction du cross compiler


6.1.1. Binutils
Les GNU binutils sont une collection doutils binaires. Parmi ceux-ci il y a le Gnu
Linker (ld) et le GNU assembler (as). La version installer est la 2.155, les sources sont
tlchargeables sur ftp.gnu.org/gnu/binutils.
Configuration et installation
Tlcharger la dernire version des binutils et la sauvegarder dans /usr/local/src.
Ouvrir un shell, se placer dans /usr/local/src et extraire les sources :
% tar xvf binutils-2.15.tar
Se placer dans le rpertoire binutils
% cd binutils-2.15
On peut passer maintenant la configuration pour le micro contrleur HITACHI H8300
% ./configure target=h8300-hms prefix=/usr/local
(si une erreur est leve penser vrifier que la librairie libc6-dev est correctement
installe)
On commence alors la configuration
% make
On passe en root pour installer les binutils
% make install
La phase suivante est linstallation du cross compiler.

6.1.2. Installation du GCC Cross Compiler


Il faut choisir la dernire version du GNU Compiler Collection (GCC) qui pour le
moment est la 3.4.2. Les sources sont tlchargeables sur ftp://ftp.gnu.org/gcc.

Il est impratif davoir un noyau 2.6 ou suprieur pour que le port USB de la tour soit support.
Il est conseill de bien vrifier les numros de versions afin de ne pas avoir de problme dinstallation et dimcompatibilt entre
les diffrents outils.
5

24

Projet Long - DANELON Cline LAFFITTE Julien

Configuration et installation
Tlcharger la dernire version de GCC et la sauvegarder dans /usr/local/src.
Tlcharger la dernire version de newlib et la sauvegarder dans /usr/local/src.
Modifier son path
% export PATH=/usr/local/bin :$PATH
Extraire les sources de GCC dans /usr/local/src
%tar xvf gcc-3.4.2.tar
Extraire les sources de newlib dans /usr/local/src
%tar xvf nexlib-1.12.0.tar
Copier les librairies dans le rpertoire source de GCC
% cp r newlib-1.12.0/nexlib gcc-3.4.2
% cp r newlib-1.12.0/libgloss gcc-3.4.2
Crer un rpertoire dinstallation pour le GCC
% mkdir build-gcc
Se positionner dans ce rpertoire
% cd build-gcc
On configure maintenant GCC en tant quun cross compiler pour le code C et C++
% ../gcc-3.4.2/configure target=h8300-hms prefix=/usr/local enablelanguages=c,c++ --with-gnu-as with-gnu-ld with-newlib
Compiler (cela peut prendre beaucoup de temps)
% make
Installer
% make install

6.2. BrickOS
La dernire version de BrickOS est la 0.2.6.10.6, elle se tlcharge sur
http://sourceforge.net.

Le seul problme possible est que la tour USB nest pas encore supporte pour cela
il faut donc appliquer un patch, seul le mode srie est inclus.
Configuration et installation
Tlcharger la dernire version de BrickOS et la sauvegarder dans /usr/local/src.
Tlcharger le patch pour permettre le support de GCC 3.4 et de la tour USB et la
sauvegarder dans /usr/local/src.
Extraire les sources dans /usr/local/src
% tar xvf brickos-0.2.10.6.tar
Se placer dans le rpertoire BrickOS
% cd brickos-0.2.10.6

25

Projet Long - DANELON Cline LAFFITTE Julien

Appliquer le patch
% patch p1 <../ brickos-0.2.10.6-gc-3.4.2-usb.patch
Lancer le script de configuration
% ./configure
Si le gcc nest pas trouv, il faut diter le script de configuration et ajouter le bon path
dans la variable TOOL_PATH (ici /usr/local)
Compiler (cela peut prendre beaucoup de temps)
% make
Installer
% make install

6.3. Pour tester linstallation


6.3.1. Tlcharger le firmware
La premire tape consiste tlcharger le firmware sur le RCX. Avec la tour USB le
port utilis doit ressembler /dev/usb/legousbtower0. Le simple fait de connecter la tour
provoque une mise jour automatique du noyau qui charge le module adquat. Il est
possible de vrifier le bon droulement de la procdure dans var/log/messages :
Sep 27 10:21:12 labor5 kernel: drivers/usb/misc/legousbtower.c: LEGO USB
Tower #0 now attached to major 180 minor 160
Sep 27 10:21:12 labor5 kernel: drivers/usb/misc/legousbtower.c: LEGO USB
Tower firmware version is 1.0 build 134
Sep 27 10:21:12 labor5 kernel: usbcore: registered new driver legousbtower
Sep 27 10:21:12 labor5 kernel: drivers/usb/misc/legousbtower.c: LEGO USB
Tower Driver v0.95
Sep 27 10:21:14 labor5 udev[13133]: configured rule in
'/etc/udev/rules.d/udev.rules' at line 111 applied, 'legousbtower0' becomes
'usb/%k'
Sep 27 10:21:14 labor5 udev[13133]: creating device node
'/dev/usb/legousbtower0'

Pour tlcharger le firmware sur le RCX on utilise le programme firmdl3 de brickOS.


Il se trouve dans /usr/local/bin aprs linstallation et est accessible via le PATH. Le fichier du
firmware est /usr/local/lib/brickos/brickOS.srec. Avant de commencer le tlchargement le
RCX doit tre allum et plac en vue directe de la tour.
% firm3dl --tty /dev/usb/legousbtower0 /usr/local/lib/brickos/brickOS.srec
Le tty doit contenir le nom du bon priphrique6.

6.3.2. Lancer le programme de Dmo


BrickOS
contient
plusieurs
programmes
/usr/local/share/doc/brickos/examples/demo

de

dmonstration

dans :

Afin de ne pas avoir prciser le priphrique il suffit de linclure dans un variable denvironnement : export
RCXTTY=/dev/usb/legousbtower0

26

Projet Long - DANELON Cline LAFFITTE Julien

Se placer dans /usr/local/share/doc/brickos/examples/demo


% cd /usr/local/share/doc/brickos/examples/demo
Le makefile contient toutes les donnes ncessaires
% make
Sont alors crs plusieurs fichiers compils dextension .lx
On peut alors charger sur le RCX le programme hello-world :
% dll -tty /dev/usb/legotower0 /usr/local/share/doc/brickos/examples/demo/helloworld.lx

Pour lexcution il suffit dappuyer sur le bouton start du RCX.

6.4. Chargement de IP
Le chargement de IP est semblable celui dun des programmes de dmonstration, il
suffit de gnrer un fichier binaire .lx et de le transfrer sur le RCX.
Du point de vue de lordinateur, il faut coder un client qui appelle les services de IP.
Nous nous sommes inspirs du code du ficher lnptest.c disponible avec les sources
de LNP pour le raliser. Toutefois la compilation prsente encore des problmes.
Dans le cadre dun ping lapplication sur le PC fait appel la fonction echo_request().
Les fonctions de IP sont donc vues comme une librairie pour lapplication cliente.

Application
utilisateur

IP
Interfaage
Handler

LNPd
RCX

inet

daemon

Rcv_handler

Librairie qui offre


des services
lapplication et au
dmon

Figure 14 : Intgration de IP avec LNP

7. Rsultats obtenus
Nous avons install sans difficult les diffrents lments permettant la communication
entre le PC et le RCX : BrickOS, LNP et IP. Toutefois, un problme de communication
subsiste sur lordinateur et nous navons donc pas pu visualiser concrtement un change
complet entre le RCX et notre machine client.
En effet, nous avons d modifier le code du protocole LNP afin quil puisse supporter la
tour Lego USB ; nous avons ainsi russi transmettre des donnes en half duplex depuis le
RCX vers le PC et inversement.

27

Projet Long - DANELON Cline LAFFITTE Julien

Cependant les changes ne se font pas correctement et les donnes ne remontent pas
jusquau client lorsque nous transmettons des donnes du RCX vers lordinateur. Dans le
sens inverse, des collisions ont lieu.
Au cours de nos recherches nous avons pu identifier que ces problmes provenaient
de la communication entre sockets : les critures / lectures entre les sockets du dmon
LNPd et celles de la librairie lnplib sont visiblement errones ce qui entrane un
comportement anormal. Il nous a manqu quelques jours pour les rsoudre compltement.
Le schma suivant prsente o se situe cette erreur :

lnptest

Client

Services

Handler

LNPd
RCX

inet

daemon

Rcv_handler
PB Socket

Librairie qui offre


des services
lapplication et au
dmon

Figure 15 : Problme de communication entre sockets

Une fois rsolus, IP tant charge sur le RCX, il sera alors possible dexcuter la
pile TCP / IP simplifie et donc de vrifier le bon fonctionnement dun protocole de niveau
suprieur.

8. Conclusion
Limplantation des moyens de communication, BrickOS et LNP, sur le RCX se fait
sans aucun problme. Il suffit de compiler les sources binaires sur le PC et de charger le
firmware sur le RCX laide de lutilitaire firmdl3. De plus linterfaage avec une couche de
niveau trois, comme IP, qui fait appel la librairie lnplib, se fait tout aussi simplement. Par
consquent, comme nous la montr lanalyse de brickOS, on disposerait les fonctionnalits
ncessaires une modlisation temps rel sur les robots Lego Mindstorms. Lutilisation de
ces petits calculateurs permettrait ainsi la ralisation de maquettes temps rel de base.
Les difficults rencontres concernent essentiellement les drivers du matriel, en
particulier le support de la tour USB, et la communication entre sockets inet.
Ainsi, pour les travaux venir il serait intressant de suivre lvolution du projet
brickOS dont la version 1.0 devrait tre prochainement disponible, incluant un support natif
de la tour Lego USB. De la mme manire, le dveloppement du protocole LNP reste actif et
une nouvelle version intgrant un calcul du checksum au champ de donnes sera publie
dans les mois venir.

28

Projet Long - DANELON Cline LAFFITTE Julien

Par ailleurs, comme le suggre Olaf Christ [LNP01], il pourrait tre intressant de
rflchir limplantation dun autre protocole de niveau 2, tel que SLIP7 ou PPP et de le
comparer avec LNP. Un de leurs avantages majeur serait d'tre multi plate-formes.
Enfin, pour pallier les limites de la liaison IR, on pourrait envisager lutilisation de
moyens de communication sans fils plus rcents, WIFI et Bluetooth par exemple, en tudiant
leur mise en uvre, leur cot...

Serial Link Internet Protocol RFC 1055 : Protocole de dialogue avec un rseau auquel on accde par simple liaison srie

29

Projet Long - DANELON Cline LAFFITTE Julien

Table des Figures


Figure 1 : Organisation du RCX .......................................................................................................... 6
Figure 2 : Trame IR .......................................................................................................................... 7
Figure 3 : Champ de vision Infra rouge dun module RCX ........................................................................ 9
Figure 4 : Cycle de vie dun processus ............................................................................................... 12
Figure 5 : Bloc mmoire de base....................................................................................................... 13
Figure 6 : Les services LNP ............................................................................................................. 15
Figure 7 : Fonctionnement LNP ........................................................................................................ 16
Figure 8 : Message LNP dintgrit .................................................................................................... 16
Figure 9 : Message LNP dadressage ................................................................................................ 17
Figure 10 : Caractristiques de IP

................................................................................................... 19

Figure 11 : Boucle de contrle principale ............................................................................................ 21


Figure 12 : Interfaage entre LNP et IP ............................................................................................. 23
Figure 13 : IP et LNPd

.................................................................................................................. 23

Figure 14 : Intgration de IP avec LNP ............................................................................................. 27


Figure 15 : Problme de communication entre sockets .......................................................................... 28

30

Projet Long - DANELON Cline LAFFITTE Julien

Bibliographie
[BRICK01] http://brickos.sourceforge.net/about.htm#What%20is%20brickOS
[BRICK02] E. Basilico, Excutif LegOS UNIGE / Universit de Genve, centre universitaire
dinformatique
[HOWTO 01] Matthias Ehmann, 2004
http://did.mat.uni-bayreuth.de/~matthias/veranstaltungen/ws2004/mindstorms/doc/brickoshowto.html
[IR 01] Stef Mientki, may 2001
http://oase.uci.kun.nl/~mientki/Lego_Knex/Lego_electronica/IR_tower/IR_tower.htm
[LEGO01] http://www.robotbooks.com/Lego-Mindstorms.htm
[LEGO02] http://www.automatesintelligents.com/labo/2002/archiveslegos.html
[LNP01] Olaf Christ, TCP/IP enabled legOS Student research project March 3, 2002
[LNP02] http://www.cs.brown.edu/courses/cs148/brickOS/HOWTO/lnp.html
[LNP03] Mike Ash, http://legos.sourceforge.net/HOWTO/x405.html
[uIP01] Adam Dunkels, Full TCP/IP for 8-Bit Architectures Swedish Institute of Computer
Science, 2003
[uIP02] Adam Dunkels, The uIP TCP/IP stack Swedish Institute of Computer Science,
2003

31