TX52/LO52 P2008. LEGO Mindstorms NXT et NxOS Système de fichiers et suivi de balises

Transcription

1 TX52/LO52 P2008 LEGO Mindstorms NXT et NxOS Système de fichiers et suivi de balises Étudiants : - Sarah Amsellem - Maxime Petazzoni - Edward Nys Suiveur UTBM : Olivier Grunder

2 Remerciements Nous tenons à remercier M. Olivier Grunder pour avoir suivi cette TX tout au long du semestre, ainsi que M. Noël Martin pour ses conseils mathématiques. Nous souhaitons également remercier les autres enseignants qui ont participé aux réunions de suivi pour leur écoute et leurs conseils. Nous voulons aussi remercier David Anderson pour son soutient sur le projet, ses code reviews et ses conseils sur l implémentation des diverses fonctionnalités décrites dans ce rapport. 2

3 Table des matières 1 Pilote flash Accès aux données Écriture Dans le futur NxFS : un système de fichiers pour NxOS Cahier des charges Les besoins Le wear-leveling État de l art Spécifications Disposition, alignement et relocation Structure Permissions sur les fichiers Indexation et recherche d un fichier Implémentation Descripteurs de fichier Tampons de lecture/écriture Synchronisation des données Possibilités d évolution Défragmentation Problématique Solutions retenues Défragmentation simple Défragmentation pour un fichier Fragmentation volontaire : best overall Étude des résultats

4 4 Suivi de balises Objectif Scénario type Les balises Sur le robot : TagRoute Robot command library Fonctionnement général Sur le PC : NxFusion Modèle géométrique Détection des balises Résultats

5 Introduction Cette TX a été réalisée au cours du semestre de Printemps 2008 par Sarah Amsellem et Maxime Petazzoni, avec la collaboration de David Anderson (auteur du projet NxOS) et d Edward Nys (partie LO52). NxOS, arrivé à une certaine maturité après les diverses TX réalisées dessus à l UTBM, offre des perspectives de développement de plus en plus larges. Afin de rendre NxOS plus facilement exploitable par des application kernels de plus haut niveau, fournir des services avancés de gestion de la Flash devenait primordial. Cette TX a donc pour objectif la réalisation d un système de fichiers pour NxOS, ainsi que de la démonstration de son fonctionnement à travers un appkernel de haut niveau réalisant une découverte de balises automatisée. Après une brève description du cahier des charges et de l état de l art (il ne s agit pas du premier système de fichiers pour un OS basé sur le Lego NXT), nous aborderons la conception puis l implémentation du système de fichiers. Nous expliquerons ensuite le fonctionnement de tag-route, le noyau applicatif de suivi de balises. Enfin, nous aborderons le sujet de la défragmentation de ce système de fichiers (projet de LO52 de Maxime Petazzoni et Edward Nys). 5

6 Chapitre 1 Pilote flash Avant tout travail sur le système de fichiers, la première étape de cette TX a été de pouvoir accéder, en lecture comme en écriture, aux données de la flash. Le NXT embarque, sur la carte Atmel qui lui sert de base, une mémoire NAND Flash de 256ko en un seul banc, contrôlé par l EFC, Embedded Flash Controler. Un pilote a donc été développé pour gérer les accès à la mémoire flash, et se situe dans base/drivers/_efc.[ch]. FIG. 1.1 Internal memory mapping 1.1 Accès aux données L accès aux données présentent sur la flash est grandement simplifiée par le processeur et l EFC, qui mettent en place un mapping mémoire vers la flash. Il suffit donc d accéder à une adresse mémoire pour lire un mot de 32 bits dans la flash. 6

7 Comme le montre la figure 1.1, les adresses comprises entre 0x et 0x redirigent vers le contenu de la flash. Cet espace virtuel, de 1 Mo, est bien sûr plus grand que la flash présente dans le NXT, on n en exploite donc que le premier quart. On peut ensuite accéder à un mot de la flash de cette façon : /** A usable pointer to the base address of the flash. */ #define FLASH_BASE_PTR ((volatile U32 *)AT91C_IFLASH) volatile U32 *flashword = &(FLASH_BASE_PTR[page * EFC_PAGE_WORDS + index]); Pour faciliter la lecture d une page entière, le pilote met à disposition une fonction de lecture qui copie dans un tableau les 64 mots de chaque page : U32 pagedata[efc_page_words]; nx efc_read_page(page, pagedata); // Do something with pagedata s content. 1.2 Écriture L écriture de données sur la flash est quant à elle une opération bien plus complexe. Il faut en effet donner des commandes précises au contrôleur de la flash. Les commandes se passent via le registre AT91C_MC_FCR (Flash Control Register), le retour d informations ou d erreurs sur la commande effectuée se faisant par le registre AT91C_MC_FSR (Flash Status Register). L écriture se fait exclusivement par pages entières. Quand on souhaite écrire une page sur la flash, on appelle donc nx efc_write_page() qui va copier les données à écrire dans l espace mémoire virtuel géré par l EFC, puis déclencher l écriture de ces données en envoyant la commande appropriée dans le registre de commande. Pour une écriture, la commande se compose d une clé de commande (0x5A), du numéro de la page en question ainsi que du code de la commande d écriture, 0x01 : #define EFC_WRITE_KEY 0x5A #define EFC_WRITE ((EFC_WRITE_KEY << 24) + EFC_CMD_WP)... /* Trigger the flash write command. */ *AT91C_MC_FCR = EFC_WRITE + ((page & 0x000003FF) << 8); Il est important de noter que les accès à la flash sont bloquant jusqu à leur complétion. Trop d accès, trop rapprochés, amènent donc à une perte du contrôle des interruptions pouvant amener la brique à penser que le système a crashé (le lien coprocesseur doit être maintenu en vie en permanence, et ce travail est réalisé par une interruption). Pour éviter que 7

8 cela n arrive, le pilote d EFC intègre un petit timer avant chaque écriture ou chaque lecture, d une durée de 2ms. Ce laps de temps suffit à ce que le lien coprocesseur, cadencé à 1 khz, soit maintenu en vie par au moins une interruption. 1.3 Dans le futur Le pilote d EFC permet actuellement d accéder en lecture et écriture aux données de la flash. Cependant, l EFC propose bien plus : bloquer l écriture sur certaines régions, effacer entièrement la flash, etc. Il serait intéressant pour NxOS d étendre le pilote pour intégrer ces fonctionnalités matérielles. 8

9 Chapitre 2 NxFS : un système de fichiers pour NxOS Au fur et à mesure que le nombre de fonctionnalités de NxOS augmentent, les possibilités offertes par le système s étendent d autant. Le support quasi-complet de la plateforme matérielle en font une base de plus en plus intéressante pour d autres projets basés sur le NXT. Parmi eux, les projets visant à développer une machine virtuelle pour un langage (Java, Lua,...) sont les plus importants mais aussi ceux qui nécessitent une base stable et complète. La mise à disposition d un système de fichiers était par exemple une des plus grosses demandes, notamment des développeurs de Lejos 1, car ce manque dans NxOS constitue une des rares raisons pour Lejos de ne pas encore migrer à NxOS. Le travail réalisé dans cette TX vise à combler ce manque et à donc offrir à NxOS un système de fichiers simple mais efficace. 2.1 Cahier des charges La définition du cahier des charges du système de fichiers est en soi très simple. Les systèmes de fichiers et les opérations qu ils proposent sont bien connus. Déterminer quelles fonctions notre système de fichier devra proposer n est donc pas très compliqué. Cependant, il ne faut pas perdre de vue deux éléments importants du contexte dans lequel ce système de fichiers est développé. Le médium sous-jacent est une mémoire Flash (NAND Flash) de faible capacité (256 ko), et le système en lui-même ne dispose que de 64 ko de mémoire vive. Par conséquent, les capacités du système de fichiers sont limitées, et il faut être particulièrement précautionneux pendant l implémentation pour ne pas abuser des ressources systèmes (principalement de la mémoire). Enfin, nous souhaitions dans la mesure du possible produire un système de fichiers permettant à des projets externes tels que Lejos d utiliser NxOS, mais sans que cela n implique de changement majeur dans leurs couches hautes (machine virtuelle par exemple). Le principal besoin apporté par cette considération étant la possibilité de pouvoir exécuter du code directement depuis la flash, ce qui implique un stockage contigu des données d un fichier

10 2.1.1 Les besoins Parmi les besoins recensés pour le système de fichiers, on peut distinguer trois grands objectifs : 1. tout d abord, offrir un maximum des fonctionnalités attendues d un système de fichiers : création, ouverture, lecture/écriture, suppression, etc, dans les limites des capacités de la plateforme ; 2. tenir compte des spécificités du médium Flash pour maximiser sa durée de vie ; 3. enfin, respecter les éventuelles contraintes supplémentaires issues de besoins externes comme le cas cité plus haut avec Lejos. En plus de ces objectifs principaux, nous souhaitions dans la mesure du possible offrir un système de fichiers rapide, fiable et n utilisant pas trop de mémoire vive Le wear-leveling Une mémoire flash est un support de stockage fragile. Basé sur des mécanisme électriques pour conserver l information, chaque bloc ou page de la flash a une durée de vie limité, exprimée en nombre de programmations (ré-écriture de l information stockée). Celle du NXT par exemple est découpée en 1024 pages de 256 octets chacune ; mais chaque page a une durée de vie d environ cycles seulement. Il est donc primordial d économiser cette ressource autant que possible en optant pour des stratégies de stockage répartissant le plus possible les écritures sur la flash. On parle alors de wear-leveling. Certaines mémoires flash, comme celles présentes dans les cartes mémoire (SmartDigital, microsd,...), intègrent un mécanisme matériel et automatique de gestion des blocs et du wear-leveling. Ce système s appelle un Flash Translation Layer et réalise un mapping entre des indices logiques de blocs et leur position réelle sur la flash. Ce mapping est créé aléatoirement et éventuellement mis à jour lorsque qu un des blocs meurt. Un FTL offre une solution complètement transparente de wear-leveling. Malheureusement, le NXT n en est pas équipé. Il faudra donc palier à ce manque logiciellement, dans la mesure du possible. 2.2 État de l art Avant de commencer le développement du système de fichiers, nous avons commencé par étudier les solutions déjà existantes et implémentées. Il était en effet important que l on puisse se faire une idée des mécanismes usuels déployés par un système de fichiers, en particulier ceux conçus pour utiliser des mémoires flash. Il nous est vite apparu qu une des meilleures façon de faire du wear-leveling était de concevoir un système de fichiers LFS (Log structured filesystem), c est à dire traitant la flash comme un espace de mémoire annulaire, sans début ni fin véritablement définis. Les écritures se font alors toujours séquentiellement à la fin des données déjà présentes, les plus 10

11 vieilles déjà ré-écrites se trouvant plus avant dans la flash étant libérées au fur et à mesure. Sur le long terme, les écritures sont donc uniformément réparties sur toute la flash. Cependant, cette technique utilisée par SpriteLFS ou encore YAFFS, possède quelques désavantages. Tout d abord, elle ne permet pas l exécution directe depuis la flash, ce qui fait partie de notre cahier des charges. En effet, les blocs de données sont ajoutés les uns à la suite des autres dans la flash, et la contigüité des fichiers n est donc plus assurée. Enfin, un tel système requiert beaucoup de mémoire vive car il nécessite d importantes quantités d informations sur l état du système de fichiers et sur l organisation des fichiers. Un log structured filesystem étant trop complexe pour être implémenté sur notre plateforme, nous avons donc revu à la baisse le besoin 2 (maximiser la durée de vie de la flash) et cherché des solutions moins complexes. Pour cela, nous avons étudié le petit système de fichiers implémenté par Lejos (directement en Java, dans l implémentation de leur JVM). Bien qu il n ai pas de mécanisme de wear-leveling, la façon dont il stocke et déplace les fichiers nous a donné l idée d un mécanisme hybride permettant de retarder l usure de la flash. Ce mécanisme est décrit en détail dans les spécifications du système de fichiers (voir plus bas). Par contre, le système de fichiers implémenté dans Lejos possède une grosse lacune du point du vue du wear-leveling. En effet, il garde un index des fichiers (une table de correspondance nom de fichier numéro de page) qu il met à jour sur la flash très fréquemment. Cet index est gardé sur la dernière page de la flash, réduisant ainsi de façon artificielle la durée de vie de cette page. Nous avons heureusement trouvé une solution ne nécessitant pas de conserver un index sur la flash, augmentant ainsi la durée de vie de la flash mais aussi la résistance aux corruptions du système de fichiers dans son ensemble. 2.3 Spécifications Tout d abord, il est important de noter que les fonctionnalités offertes par NxFS sont volontairement limitées. En effet, pour limiter l empreinte mémoire du système de fichiers ainsi que la place occupée par les meta-données sur la flash, nous avons décidé de limiter les fonctionnalités au minimum requis. Ainsi, on ne trouve pas (encore) de gestion d arborescence ou de système de droits évolué dans NxFS. Un seul niveau de fichiers est disponible, accessibles par leur nom Disposition, alignement et relocation La mémoire flash utilisée pour NxFS est matériellement découpée en 1024 pages de 256 octets chacune, soit un total de 256 ko. Une page constitue pour le système de fichiers l unité indivisible de stockage de données : plusieurs fichiers ne pourront pas occuper la même page. On peut ainsi désigner un fichier par le numéro de sa première page, appelée origine. Il en découle également qu on ne peut stocker au maximum que 1024 fichiers. Chaque fichier occupe donc au minimum une page de la flash. On remarquera bien sûr que cet alignement des fichiers se traduit par des pertes d espace d autant plus grandes que la taille du fichier ne le fait pas correspondre avec la fin d une page. 11

12 FIG. 2.1 Alignement des débuts de fichier avec les pages et pertes induites Le placement des fichiers sur la flash résulte du mécanisme hybride évoqué plus haut. Ce mécanisme détermine comment vont être placés les fichiers sur la flash dans un compromis entre complexité du mécanisme, conservation de la contiguïté des données d un fichier et maximisation de la durée de vie de la flash. FIG. 2.2 Les fichiers sont stockés linéairement et de façon contigüe D une façon générale, les fichiers sont stockés linéairement, les uns à la suite des autres sur la flash (voir figure 2.2). Les fichiers s étendant vers la "droite" lorsque l on y rajoute des données, les fichiers immédiatement suivis par un autre vont se retrouver bloqués une fois le reste de leur dernière page remplie. C est là qu intervient un mécanisme de relocation dont le but est de trouver une nouvelle place suffisamment grande pour le fichier afin de permettre la poursuite de son extension. 12

13 FIG. 2.3 Relocation d un fichier en expansion à la fin de la flash La subtilité réside dans le fait que ce mécanisme ne va pas exploiter le premier espace vide rencontré dans la flash, mais plutôt tenter de placer le fichier à la fin des données présentes sur la flash (c est à dire après le "dernier" fichier). Si la place n est pas suffisante, la recherche repart depuis le début de la flash, comme montré dans la figure 2.4. Ce système, également utilisé pour déterminer l origine d un nouveau fichier, permet de répartir de façon circulaire, un peu à la manière d un log structured filesystem, le stress imposé aux blocs de la flash. FIG. 2.4 Relocation d un fichier dans le premier espace libre trouvé Une relocation peut aussi avoir lieu "vers l arrière", quand de l espace libre se situe juste devant le fichier à relocaliser, et s il n y a pas d espace à la fin de la flash. Dans la situation de la figure 2.4, le fichier 3 pourrait par exemple être relocalisé ainsi : 13

14 FIG. 2.5 Backward relocation Il arrive bien sur qu une relocation échoue : si aucun espace libre supérieur d au moins une page à la taille du fichier n est trouvé, on ne peut pas le déplacer. Il n y a plus d espace pour ce fichier sur la flash. Un mécanisme de défragmentation peut alors être lancé pour pallier à ce problème (voir partie 3) Structure À chaque fichier sont associées des méta-données qui contiennent les informations essentielles sur le fichier comme son nom ou sa taille. Ces méta-données, d une taille totale de 10 mots de 32 bits (soit 10 U32 2, ou encore 40 octets), sont structurées de la façon suivante : FIG. 2.6 Structure des méta-données 2 Un U32 est un unsigned long int, soit un entier non-signé de 32 bits 14

15 Le premier mot commence par un marqueur, 0x42, qui permet de repérer le début d un fichier. Il est suivi de 4 bits donnant les permissions de ce fichier (voir plus bas), puis par la taille du fichier en octets, stockée sur 20 bits 3. Le second mot de 32 bits est pour l instant inutilisé et réservé à des évolutions futures du système de fichiers. Reportez-vous à la section 2.5 pour plus de détails. Enfin, les 8 derniers mots contiennent le nom du fichier. Celui-ci, d une longueur maximale de 32 caractères (caractère de fin de chaîne inclus) est compacté quatre caractères par 4 dans les 8 U32s disponibles. Une simple union permet alors de faire la conversion de type sans avoir à passer pas des masques complexes Permissions sur les fichiers Une gestion basique des droits d accès aux fichiers est prévue dans NxFS. Un fichier peut ainsi être marqué comme étant en lecture seule ou exécutable afin de limiter les actions sur ce fichier. Ces permissions sont stockées sous la forme d une valeur hexadécimale (4 bits) dans le premier mot des méta-données. Par défaut, un fichier est en lecture seule. Le premier bit (en partant des bits de poids faible), dénote une autorisation d écriture dans ce fichier. Le second dénote la nature exécutable du fichier. Les deux autres bits sont encore inutilisés. Voici quelques exemples : Valeur des bits Signification 0000 Lecture seule 0010 Exécutable en lecture seule 0001 Lecture et écriture autorisées 0011 Exécutable en lecture/écriture Indexation et recherche d un fichier Le système de fichiers utilisé par Lejos contient à nos yeux un gros défaut : il maintient un index des fichiers sur une page donnée (la dernière page de la flash, numéro 1023). Bien que permettant un code dans l ensemble plus compact et plus rapide, une telle solution réduit considérablement la vie de la flash, et en particulier de cette dernière page. Une fois celle-ci inutilisable, tout le système de fichiers l est aussi! Nous avons donc souhaité nous débarrasser de ce paradigme, en faveur de meta-données décentralisées. En effet, parcourir l ensemble de la flash à la recherche d une information particulière est extrêmement rapide (et n abime pas la flash). Ainsi, le système de fichiers peut se permettre de parcourir la flash à la recherche d un fichier et de ses meta-données sans perte de performances ; le tout amenant à la perte du besoin d une table des fichiers. flash bits sont suffisant pour stocker la taille du fichier car 2 20 = 1 Mo, ce qui est supérieur à la taille de la 15

16 Recherche d un fichier À l ouverture d un fichier, une recherche est donc faite dans la flash pour le retrouver. Cependant, il n est pas nécessaire de parcourir toute la flash : quand on tombe sur un fichier, reconnaissable au marqueur 0x42 à son début, on peut directement sauter après celui-ci si ce n est pas le fichier recherché. Le parcours de la flash en est encore plus rapide, le temps d ouverture d un fichier étant alors inférieur à une milliseconde. Cette méthode est en fait obligatoire : en effet, rien n interdit un fichier de contenir dans ses données le marqueur 0x42 qui peut se retrouver au début d une page une fois stocké. 2.4 Implémentation NxFS est implémenté dans NxOS sous la forme d une librairie proposée aux noyaux applicatifs, leur fournissant ainsi une gestion facile et efficace de l espace flash disponible, s ils le souhaitent. On retrouve donc le code de NxFS dans base/lib/fs/fs.[ch]. Le code en lui-même est assez explicite. Il nous semble cependant important de revenir ici sur quelques spécificités de l implémentation. Le code génère également, via ses commentaires et comme tout le reste de NxOS, un module supplémentaire dans la documentation Doxgen de NxOS (générée dans doc/ à la compilation) Descripteurs de fichier L API du système de fichiers utilise un système de descripteurs de fichiers, permettant de rendre opaque aux utilisateurs de NxFS les détails des structures de données internes. Pour des raisons d emprunte mémoire, le nombre de fichiers ouverts (et donc de descripteurs de fichiers) est limité à 8 cette valeur pouvant cependant être augmentée si jugée non satisfaisante. Un descripteur de fichier est donc retourné par la fonction d ouverture/création de fichier, et devra être conservé par le demandeur pour toutes les opérations à effectuer sur ce fichier, jusqu à sa fermeture où son descripteur est invalidé. L ensemble des fonctions opérant sur un fichier prend donc en paramètre un descripteur de fichier, index de l entrée correspondant au fichier en question dans le tableau de structures fdset maintenu par le système de fichiers. typedef struct {...; } fs_file_t; static fs_file_t fdset[fs_max_opened_files]; Tampons de lecture/écriture NxFS utilise bien sûr des tampons de lecture/écriture. Bien que la lecture puisse se faire directement depuis la flash par adresse, cette fonctionnalité perd de son intérêt lorsque l on 16

17 traite avec plusieurs fichiers. En effet, la mémoire flash du NXT est une NAND flash, ce qui signifie que les accès peuvent être aléatoires, mais que la lecture après cet accès se fait séquentiellement 4. Ainsi, si l on souhaite lire depuis plusieurs fichiers, le système se retrouve dans une situation désavantageuse pour les accès aux données et deviendra très lent. C est pourquoi, en plus du tampon d écriture, NxFS est doté d un tampon de lecture, automatiquement mis à jour. Ces deux tampons, de la taille d une page de la flash (256 octets possèdent chacun un curseur interne de position qu il est possible de déplacer avec la fonction nx_fs_seek(), dans les limites du fichier bien sûr. Toute lecture ou écriture se fait à la position du curseur correspondant, qui est alors automatiquement déplacé en conséquence. Ces deux tampons présentent également un modèle d accès spécial. L interface à la mémoire flash réalisée par l EFC 5 permet d échanger des mots de 32 bits (U32) avec la flash. Cependant, ce n est pas le mode d échange de données que nous voulons faire présenter par l API de lecture/écriture du système de fichiers. Ces deux tampons contiennent donc une union C, regroupant dans le même espace mémoire un accès par U32 et par octet (caractère) : /** File I/O buffer. */ typedef struct { union { U32 raw[efc_page_words]; U8 bytes[efc_page_bytes]; } data; /**< The buffer data, accessible in its raw (U32) * form or byte per byte. */ U32 page; /**< The flash page this buffer is related to. */ U32 pos; /**< In-data cursor. */ } fs_buffer_t On peut ainsi accéder aux données du tampon directement par octet, ou en mode U32 brut (utilisé pour l écriture du tampon sur la flash) Synchronisation des données Un des objectifs de NxFS est d offrir une bonne résistance aux crashs. Si la brique plante ou s arrête pendant une grosse écriture dans un ficher, il faut perdre le moins de données possible. L unité d écriture indivisible étant la page, NxFS synchronise les tampons avec la flash dès que ceux-ci sont pleins, mettant à jour par la même occasion les meta-données du fichier. Ce mécanisme de synchronisation agressive des données permet à NxFS d être très résistant, mais affecte aussi ses performances. En mettant à jour les meta-données à chaque nouvelle page écrite (par nx_fs_flush(), la première page du fichier est elle aussi ré-écrite. A part pour la première page, chaque nouvelle page écrite entraine en fait deux écritures. 4 Pour plus de détails, voir la documentation du flash word prefetch dans la documentation Atmel. 5 Embedded Flash Controler 17

18 Un synchronisation des meta-données en flash plus lente est envisageable. Celles-ci ne pourraient être ré-écrites qu à l appel de nx_fs_close(). Ceci augmenterait de façon sûre les performances du système de fichier, mais le tradeoff entre gain de performances et fiabilité sur une telle plateforme en est-il intéressant pour autant? 2.5 Possibilités d évolution NxOS évolue, grandit et offre de plus en plus de possibilités, et avec elles de nouveaux besoins potentiels. Pour parer à d éventuelles nécessités d évolution de NxFS, un peu de place a été laissé dans la structure des méta-données de chaque fichier. Parmi les évolutions possibles, on compte notamment la gestion d une arborescence de fichiers pouvant se baser sur l espace réservé dans le 2ème mot de méta-données, actuellement réservé. On peut également envisager la mise en place d une gestion des droits plus approfondies, permettant une véritable gestion des permissions sur les fichiers. Enfin, il serait techniquement possible de se passer de l alignement des fichiers sur une nouvelle page. Ceci éviterait de perdre quelques dizaines voire centaines d octets par fichier, mais complexifierait beaucoup les mécanismes de lecture et d écriture, ce qui n est pas forcément un compromis intéressant à cause des faibles performances de la plateforme et de la complexité augmentée du code. 18

19 Chapitre 3 Défragmentation Ce chapitre aborde le thème de la défragmentation du système de fichiers NxFS, ou plutôt d une façon plus générale des techniques mises en place pour : soit diminuer le nombre moyen de relocations à effectuer pendant une session d utilisation du système de fichiers (c est une opération potentiellement coûteuse) ; soit récupérer de l espace libre qu une relocation ne permettrait pas de trouver par une défragmentation, ciblée ou non, des fichiers sur la flash. Note : Ces développements s inscrivent dans le cadre du projet de LO52 réalisé par Edward Nys et Maxime Petazzoni au semestre de printemps Problématique Comme vu dans le chapitre 2, lorsqu un fichier immédiatement suivi par un autre sur la flash veut s étendre au delà de la fin de sa dernière page, il doit être déplacé à un endroit sur la flash lui permettant de continuer son expansion. Ce mécanisme, appelé relocation, a pour rôle de trouver un autre "trou" ou espace libre sur la flash suffisamment grand pour accueillir ce fichier. FIG. 3.1 Relocation impossible alors que l espace libre total est assez grand Toutefois, il arrive que cette relocation soit impossible. En effet, après plusieurs relocations de divers fichiers, la flash se retrouve fragmentée et peut l être au point de ne pas 19

20 contenir de trou suffisamment grand pour accueillir le fichier à déplacer. Mais pourtant l espace libre total est bien là, comme le montre la situation présentée dans la figure 3.1. Dans cette situation, une défragmentation permettrait donc de "récupérer" l espace disponible de façon contigüe à un endroit de la flash permettant ainsi d y déplacer le fichier ayant besoin de s étendre. Cependant, il ne faut pas perdre de vue les spécificités du système de fichiers auquel cette défragmentation s applique. En effet, aucun espace n est prévu après les fichiers pour subvenir en tout ou partie à leur besoin d espace lorsqu ils grandissent. Ainsi, si l on souhaite pouvoir continuer à écrire dans un fichier F i, il faut "orienter" cette défragmentation pour placer ce fichier dans une place plus avantageuse. L endroit le plus propice étant à la fin des données en flash, après une défragmentation du reste des données (ce qui maximise l espace disponible en fin de flash). Il est également intéressant de regarder l éventuelle amélioration de performances que peut apporter une défragmentation. Les accès en écriture sur une mémoire flash sont relativement rapides, mais une relocation de fichier en cours de route peut très fortement diminuer le débit d écriture! Pour réduire le nombre moyen de relocations, on peut donc dans la mesure du possible fragmenter artificiellement la flash afin de placer après chaque fichier le plus de pages libres possibles. Cette méthode, qui n est donc pas vraiment une défragmentation, est décrite plus bas dans la section Solutions retenues Nous avons donc retenu trois solutions distinctes pour en comparer l efficacité : 1. une défragmentation simple, nx_fs_defrag_simple() ; 2. une défragmentation simple, mais "orientée" vers un fichier précis : nx_fs_defrag_for_file() ; 3. une fragmentation, dont le but est de maximiser l espace libre après chaque fichier : nx_fs_defrag_best_overall(). Note : un bloc est un ensemble contigu de un ou plusieurs fichiers, et un trou est un espace libre d au moins une page Défragmentation simple Le premier type de défragmentation, qui est aussi le plus simple, a pour objectif de maximiser l espace libre en fin de flash en ramenant les fichiers le plus possible vers le début de la flash. C est le même genre de défragmentation que l on trouve sur les PC. Il n est ici pas très adapté aux besoins de NxFS, mais il constitue néanmoins une brique de base exploitée par les autres types de défragmentation. Disposer d un espace maximum en fin de flash permet aussi de rendre une relocation quasi-immédiate, le temps de recherche étant diminué, mais apporte aussi à un nouveau fichier le plus d espace possible. 20

21 Le fonctionnement de nx_fs_defrag_simple() est relativement simple : il cherche à boucher les trous en ramenant les données vers le début de la flash, tout en essayant de minimiser les opérations de déplacement. Son algorithme est simple : pour chaque trou rencontré dans la flash, on cherche le bloc le plus approprié (c est à dire dont la taille se rapproche le plus de la taille du trou). Si on en trouve un, on l y déplace ; sinon, on ramène le bloc qui suit le trou vers la gauche pour combler le trou. FIG. 3.2 Application de la défragmentation simple Comme on peut le voir dans l exemple de la figure 3.2, l algorithme va rencontrer le premier trou après le deuxième fichier. La recherche de bloc lui fera trouver le fichier 4, qui se verra déplacé dans le trou. Le prochain trou est alors après le fichier 3, qui ne sera pas déplacé. Le seul bloc restant, contenant les fichiers 5 et 6, est alors déplacé après le fichier 3. Il est également possible de restreindre cet algorithme de défragmentation à une zone précise de la flash : cette fonctionnalité est par exemple utilisée par les autres méthodes de défragmentation Défragmentation pour un fichier Le mécanisme de défragmentation présenté dans la section précédente est efficace. Toutes les pages non utilisées se retrouvent à la fin de la flash. Cependant, il ne résout pas le problème du fichier 1 qui cherche à s étendre. On peut bien sûr le déplacer à la fin de la flash, dans les cas où l espace libre récupéré est assez grand, mais l espace qu utilisait jusqu alors ce fichier est de nouveau perdu! 21

22 Cette technique de défragmentation, plus ciblée, permet au cours de la défragmentation de s assurer qu un fichier donné sera bien le dernier sur la flash à la fin du processus, lui offrant ainsi le plus d espace possible pour s étendre. La méthode employée ici est un peu plus complexe, mais repose sur les fonctionnalités offertes par la défragmentation simple. Tout d abord, deux cas triviaux peuvent être réalisés simplement et sont représentés par la figure 3.3 : si le fichier en question est déjà à la fin de la flash ou peut l y être déplacé. Dans ce cas, on place le fichier à la fin de la flash (1) et on réalise une défragmentation simple jusqu au début de ce ficher (2). Il ne reste alors qu à le ramener au début de l espace libre ainsi créé (3). FIG. 3.3 Application de la défragmentation pour un fichier (cas simples) 22

23 Malheureusement, dans bien des cas on ne peut pas placer le fichier à la fin de la flash. On étudie alors la possibilité d échanger le fichier avec un ou plusieurs fichiers de la fin de la flash. Si c est possible, on échange ces deux régions de la flash, et on se retrouve à nouveau dans le cas précédent. Si ce n est toujours pas possible, on peut en dernier recours utiliser un processus plus complexe (et ici plus lent) : on commence par défragmenter la partie de la flash se trouvant après le fichier, et on retente tous les cas évoqués plus haut. Si cela ne marche toujours pas, la défragmentation est abandonnée Fragmentation volontaire : best overall Cette dernière technique, comme mentionné précédemment, n est pas vraiment une technique de défragmentation mais bien au contraire une fragmentation choisie dans le but d optimiser les performances du système de fichiers. Cette solution permet de minimiser les relocations en insérant des pages vides après chacun des fichiers. Nous avons ensuite réfléchi à la quantité d espace libre à placer après chaque fichier : ne voulant favoriser aucun fichier, nous avons pris la décision de placer un espace moyen après chaque fichier. L espace moyen est défini comme l ensemble des pages libres divisé par le nombre de fichiers (MSP F : Mean space per file) : MSP F = F ree pages F ile count FIG. 3.4 Application de la fragmentation volontaire Ici la mise en place de cette solution nécessite de traiter plusieurs sous cas. On commence par tirer le premier fichier vers le début de la flash, puis on itère sur tous les fichiers pour les placer à la bonne position. 23

24 Le premier cas trivial se présente lorsque l espace libre après le fichier courant correspond à l espace libre souhaité MSP F. Par contre, si l espace libre après le fichier courant est supérieur à l espace moyen par fichier, on tire le fichier suivant pour le caler à l endroit approprié (fin du fichier courant + MSP F ). Le cas le plus compliqué survient quand l espace libre après le fichier est inférieur à l espace souhaité. En effet, pour satisfaire ce cas il faut "pousser" le bloc suivant. Pour ce faire il faut étudier les sous cas qui se présentent. Dans le cas ou il y a assez d espace après le bloc à pousser pour accommoder l espace moyen par fichier, il suffit de pousser ce bloc. Si ce n est pas le cas, on essaye de résoudre ce problème d une autre façon, en tentant de déplacer le premier fichier de ce bloc à la fin des fichiers de la flash. Si nous n avons toujours pas trouvé de solution, on calcule le prochain bloc, incluant des espaces qui pourraient être déplacés en même temps que le bloc pour satisfaire ce cas. Dans le cas peu probable où aucune de ces solutions n a permis de déplacer ce bloc, nous décidons que le coût de l opération devient trop important pour résoudre ce cas et nous retournons une erreur. Le résultat d une telle fragmentation est visible dans la figure Étude des résultats Nous n avons malheureusement pas eu le temps d exploiter les résultats de ces trois méthodes de défragmentation. Cependant, les mécanismes sont là et sont fonctionnels si un noyau applicatif veut en tirer partie. Le système de fichiers sur lequel reposent ces mécanismes est encore jeune, et n a pas servi de façons suffisamment variées (en particulier près de la capacité maximale) pour en extraire des cas réels d utilisation de la défragmentation. Nos tests révèlent toutefois des temps de défragmentation assez longs de l ordre de plusieurs secondes et malheureusement incompressibles quand beaucoup de données sont à ré-arranger. Le best overall est cependant très intéressant si le nombre de fichiers utilisé est faible, ainsi que leurs tailles : on évite ainsi que les fichiers soit relocalisés les uns après les autres sans cesse, garantissant ainsi des performances uniformes. 24

25 Chapitre 4 Suivi de balises Ce chapitre présente une des applications du système de fichiers que nous avons développé dans le cadre de cette TX. Il s agit d un système de reconnaissance, suivi et mémorisation de balises. Après une phase de reconnaissance des balises présentes dans l environnement à l aide d un PC et d une webcam, le robot doit pouvoir, de façon complètement autonome, rejouer le trajet qu il a suivi mais sans aide ni balises, grâce à des instructions stockées dans un fichier. 4.1 Objectif L objectif de ce système est triple. Tout d abord, à démontrer le fonctionnement du système de fichiers créé pour NxOS pendant cette TX : toutes les opérations de bases doivent être parfaitement fonctionnelles pour permettre au système de tourner. Ensuite, de développer un mécanisme de reconnaissance et de suivi de balises pour record/replay. Enfin, de mettre en avant la polyvalence de NxOS et sa capacité à mettre à disposition simplement le matériel à travers des systèmes de contrôle rapides à prendre en main. Pour cette partie de la TX, nous avions accès aux travaux réalisées par deux TX précédentes sur des sujets similaires de suivi de balises. Cependant, les solutions mises en place dans ces TX n étaient pas assez polyvalentes pour la détection des balises. Il était également très complexe de reprendre et adapter leur code, lourd et malheureusement mal écrit. Nous avons donc décidé de s inspirer d une partie de leurs recherches pour proposer une solution plus adaptable et nous l espérons plus efficace Scénario type Le système développé ici est conçu pour évoluer dans le cadre du scénario suivant : une première phase d enregistrement est menée par le robot, en collaboration avec le PC. La caméra, équipée sur le robot mais reliée au PC, transmet ce que "voit" le robot au logiciel de reconnaissance d image. Celui-ci y recherche des balises (voir plus bas) et commande le robot pour que ce dernier suive la succession de balises, par ordre croissant. Pendant toute cette phase, le robot exécute et enregistre les commandes qui lui sont transmises. 25

26 une seconde phase de replay pendant laquelle le robot, complètement autonome (sans caméra ni PC), rejoue les commandes enregistrées et retrace ainsi le chemin parcouru Les balises Les balises recherchées par le logiciel de reconnaissance d image ont une forme bien particulière, développée pour en faciliter la reconnaissance et la lecture. Chaque balise est composée d un crochet repère à gauche et d une barrette codée à droite. Le crochet est un marqueur invariant donnant les informations de taille et de perspective. La barrette codée, quant à elle, est une suite verticale de rectangles codant une valeur sur 8 bits. Un rectangle noir correspondant à un 1, un espace blanc donnant un 0. Comme la figure suivante le montre, les dimensions sont soigneusement choisies pour faciliter la lecture de la balise. Les points rouges marquent les centres des valeurs binaires. On remarque également que les deux droites vertes obliques sont parallèles. FIG. 4.1 Analyse des dimensions d une balise 174 ( ) 4.2 Sur le robot : TagRoute Nous avons bien sûr développé dans le cadre de ce système un noyau applicatif pour NxOS, que nous avons appelé tag-route, en charge du travail d enregistrement et de relecture des commandes. La première étape a consisté à définir un langage de commandes interprétables par le robot. Ce développement a donné lieu à la création d une bibliothèque pour NxOS : RCmd 1. Puis, avec les fonctionnalités offertes par cette bibliothèque d une part, et par celle du système de fichiers d autre part, nous avons pu assembler très rapidement une application d enregistrement et de relecture. 1 Pour (Remote) Robot Command. 26

27 4.2.1 Robot command library RCmd est donc une bibliothèque additionnelle pour NxOS, placée dans base/lib/rcmd et qui met à disposition un système d exécution d instructions soit commande par commande, ou directement depuis un fichier. Le "langage" d instructions est volontairement simple et ne se veut pas un langage de commande complet du robot. Il n offre aucune fonctionnalités de variables, de tests ou d accès aux capteurs : il s agit uniquement de contrôler le robot. Ainsi, seules les commandes suivantes sont disponibles : clear, print, play, wait, exec, move, end. Chacune de ces commandes à une syntaxe lui permettant de spécifier les paramètres de l action. Par exemple : # Play a sound at 2000Hz for 500ms and wait until completion play sync # Clear screen and say hello clear print Hello, world La commande move est la plus complexe : elle permet de commander les moteurs avec des puissances et des temps spécifiés par moteur, ou globalement. En voici quelques exemples : # Move motors A and B at 100% for one second move A,B # Move motor A at 100% and motor B at 50%, both for 500ms move A,B 100, # Move motor A at 85% for 500ms and motor B at 45% for 800ms move A,B 85,45 500,800 # Move motor A at 100% and brake motor B move A,B 100,0 500 La description complète de la syntaxe des commandes est disponible sur natulte.net/nxos/trac/wiki/nxos/libraries/rcmd Fonctionnement général TagRoute, à son lancement, présente un menu à l utilisateur. Celui-ci étant géré par la bibliothèque GUI créée au début cette TX, il permet de choisir parmi les différentes fonctions proposées par le noyau. En voici un aperçu : - Tag route - 27

28 1> Replay 2. Record 3. From USB 4. Halt Celui-ci à donc le choix entre rejouer le trajet enregistré, enregistrer par USB un nouveau fichier de commandes, ou encore directement exécuter des commandes reçues par USB. Une petite console USB, nommée rcmd_console, a été développée pour l occasion et permet de tester le langage de commande ou interagir en temps réel avec le robot. Un des développements futurs serait par exemple de permettre la réception de ces commandes par Bluetooth : on disposerait alors d une véritable télécommande. En mode d enregistrement, TagRoute reçoit les commandes au format RCMD depuis la liaison USB, les exécute et les enregistre dans un fichier (ici arbitrairement nommé tag-route.data). Une fois la commande end reçue, l enregistrement prend fin. On peut alors rejouer à n importe quel moment (même après extinction de la brique puis redémarrage) le contenu du fichier ainsi créé. 4.3 Sur le PC : NxFusion NxFusion est l assemblage du système de reconnaissance de balises que nous avons développé et d un système de commande à distance du robot. Il se présente sous la forme d une interface graphique diffusant en temps réel l image perçue par le robot sur laquelle sont mises en évidence les balises détectées. En arrière plan, lorsqu activé, il envoie également les commandes appropriées au robot pour se déplacer dans son environnement. FIG. 4.2 NxFusion 28

29 Une interface graphique utilisant les bindings Python de la librairie GTK a été développée afin de permettre une liaison ergonomique entre la reconnaissance de balises via la caméra et l envoi de commandes au robot. Elle permet de commander la liaison avec le robot et la détection des balises Modèle géométrique Dans le cas simple où la balise est vue de face, c est-à-dire que l image conserve les parallèles et les orthogonales, il est trivial de récupérer la barrette contenant la valeur binaire de la balise. D un point de vue applicatif, c est un cas que nous ne rencontrerons que très peu du fait du déplacement du robot et de la position de la caméra. L image peut alors s en retrouvée transformée par de la perspective ce qui ne nous garanti plus, ni la conservation des parallèles ni des orthogonales. Pour cela, nous avons donc étudié un modèle géometrique nous permettant de retrouver la barrette des huits bits à partir du crochet, et ce, quelque soit la perspective appliquée à l image. Ainsi, si le robot voit la balise de côté, il pourra encore détecter et identifier la balise. FIG. 4.3 Balise vue sans perspective Cette méthode géometrique prend en compte quatre cas bien distincts : 1. lorsque la balise est vue de face, sans perspective, comme montré dans la figure 4.3 : il est alors très facile de lire la valeur de la balise à partir des dimensions fournies par le crochet ; 2. lorsque la balise est vue par le côté, en perspective horizontale ; 3. en perspective verticale (bien que ce cas ne devrait pas se présenter si on place la caméra à la même hauteur que les balises) ; 4. en double perspective, combinaison des deux cas précédents. 29

30 Vue de face La vue de face, la caméra sur la normale au plan de la balise, est le cas le plus simple. Une fois le marqueur crochet détecté et les positions des points de A à H déterminées, on accède très facilement aux coordonnées des milieux des valeurs binaires de la barette (pour i [0; 7]) : { xi = x A + AB + 2 EF y i = y A i BF 2 Perspective simple Dans le cas d une perspective simple nous aurons à faire à un point de fuite. Lorsque la balise sera vue de côté ou avec un peu de hauteur nous serons dans les cas de perspective horizontale et verticale. Prenons tout d abord le cas d une perspective horizontale. Cela signifie que toutes les droites initialement horizontales convergeront vers un point de fuite communément noté pf 100 (en référence à l axe i du repère). FIG. 4.4 Méthode appliquée à perspective simple horizontale 30

31 Il suffit ensuite de prolonger la droite passant par pf 100 et étant parallèle aux droites verticales qui conservent alors leur parallèlisme. On cherche le point d intersection de la droite (AD) avec la droit passant par pf 100 que l on note pf u. On sait que dans un cas ne présentant pas de perspective, la droite parallèle à (AD) et passant par B nous fournit le point bas et milieu de la barette de bits P B par l intersection de (CD). Les verticales étant conservées, on peut alors tracer la droite passant par le point bas de la barette de bits, parallèle à l axe des ordonnées. L intersection de la droite passant par (AB) et cette droite nouvellement tracée nous fournira le point haut P H milieu de la barette de bits. On trouve alors rapidement chaque point milieu de chacun des bits recherché via (pour i [0; 7]) : { xi = P B x P Hy P By y i = P B y + (2 i + 1) 16 Par le même principe, dans le cas d une perspective verticale, toutes les verticales convergeront vers le point de fuite pf 010. On trace la droite passant par ce point et horizontale afin de déterminer pf u, intersection de (AD) et de cette nouvelle droite. FIG. 4.5 Méthode appliquée à perspective simple verticale 31

32 On trouve de nouveau P B le point bas de la barette par l intersection de la droite passant par B et pf u avec (CD). On peut alors déterminer P H, intersection de la droite passant par P B et pf 010 avec (AB). Il suffira ensuite de déterminer chaque milieu de chacun des bits de la barette géométriquement par diagonalisation. Cas général : double perspective Ce cas-là est une combinaison des deux précédents puisque l on travaille avec pf 100 et pf 010. On trouve pf u intersection de la droite passant par les deux points de fuite et de la droite passant par B et parallèle à (AC). De la même manière que précédemment, il est aisé de retrouver les points que l on recherche. FIG. 4.6 Méthode appliquée à la double perspective Ce modèle géométrique a été mis en place en utilisant Matlab, qui permet d une part d effectuer des tests concernant les outils développés mais également de fournir directement les équations des coordonnées des milieux des valeurs binaires de la barrette en notation formelle. 32

33 FIG. 4.7 Les quatre cas possibles démontrés par Matlab Notre programme de détection de balises n aura donc pas à effectuer tous ces calculs intérmédiaires et aura directement connaissance du résultat selon le cas dans lequel on se situe Détection des balises La détection des balises se base donc sur les travaux géométriques préliminaires et les résultats obtenus grâce à Matlab. Le programme de détection de balises à proprement parler utilise la librairie OpenCV afin de détecter le crochet, point d entrée de notre méthode de lecture de balises. La méthode de détection consiste à déterminer les contours de l image vue par la caméra via l algorithme de Canny, puis d identifier le polygone non convexe comportant huits points et se rapprochant le plus possible de la forme du crochet. Pour plus de précision, nous testerons également la valeur des pixels à l intérieur et à l extérieur de notre polygone en fonction de leur couleur. Une fois qu OpenCV aura identifié une forme correspondant aux conditions énoncées ci-dessus, il suffit d identifier les points du crochet. Ces derniers nous permettront de nous 33

34 placer dans l un des quatre cas possibles étudiés dans la section précédente et de renvoyer les milieux des points de la barrette en fonction des équations des coordonnées des points. La dernière étape consiste à lire la valeur de la barrette, selon que la zone autour de chaque milieu des points soit noire ou blanche (1 ou 0), le bit de poids fort étant le point le plus en bas de la barrette. FIG. 4.8 Exemple de lecture de balise 4.4 Résultats Nous n avons malheureusement pas eu beaucoup de temps pour tester la détection de balises en situation réelle, ni d implémenter un comportement de découverte de l environnement pour le robot. Toutefois, les composants sont là, prêts à être utilisés. Une fois un comportement défini, il suffit de l implémenter dans NxFusion, qui propose une API très simple d accès aux balises détectées et pour l envoi de commande au robot. La détection et la lecture des balises est quant à elle fonctionnelle, et permet de lire la valeur d une balise très rapidement quelque soit son angle de vue. 34