Livrable projet. Environnement Ada Ranvenscar pour Lego mindstorms. Livrable final projet Segway Ada Ravenscar. Titre

Transcription

1 Titre Livrable projet Environnement Ada Ranvenscar pour Lego mindstorms Type Bilan des réalisations Date 18/03/11 Auteur Destinataire Jonthan Lejeune, Madeleine Piffaretti, Elie Richa Nombre de pages Laurent Pautet,Thomas Robert, Etienne Borde 11 1

2 Table des matières 1. Introduction Résultat à l'issue du projet Rappel des tâches à réaliser Description détaillée des réalisations obtenues Tâche 1: Environnement de développement et déploiement Tâche 2: Implémentation de l'étude de cas Tâche 3:Pilotage du robot à distance via une tablette Tâche 4: Définition et mise en œuvre d'une politique de changement de modes fonctionnels Tâche 5: Expérimentation du module dans des situations diverses Problèmes rencontrés Bilan et perspectives Références

3 1. Introduction Le but de ce projet est de mettre en place, tester et valider la plateforme de développement Ada Ravenscar for NXT sur un cas concret: «contrôle de segway». 2. Résultat à l'issue du projet Le résultat obtenu à l'issue du projet est un programme Ada profile Ravenscar compilable grâce à l'utilitaire Wine sous Linux et déployable sur la brique nxt. Ce programme nous permet de faire tenir le robot à l'équilibre, cette position d'équilibre étant calibrable à l'initialisation et durant l'exécution si l'on décide de changer l'environnement du robot (inclinaison du support par exemple ou changement de lumière) grâce à des actions associées aux boutons figurant sur la brique. En parallèle nous avons développé une application que nous pensions utiliser initialement, mais dont la réalisation complète a du être abandonné suite aux problèmes (mentionnés dans la suite) que nous avons rencontrés. Il s'agit d'un programme Ada profile Ravenscar permettant au robot d'être en attente d'une demande de connexion par un appareil mobile (Android par exemple autres) et d'ensuite pouvoir recevoir des messages suivant le protocole bluetooth de Lego Mindstorms. Ces messages peuvent être de type commande (avancer, reculer) ou paramètres et remise en route de tâche. Ceci permettrait de pouvoir calibrer le robot à distance sans avoir à recompiler le programme à chaque changement ainsi que de pouvoir le contrôler à distance (type application remote control [7]). Pour ce qui est de l'application pour l'appareil mobile, nous avons commencer à développer une application pour Android mais cette dernière n'est pas finalisée. Les perspectives concernant les points inachevés du projet seront traités dans la partie bilan et perspectives de ce rapport. 3. Rappel des tâches à réaliser Voici un bref rappel des tâches énoncées dans le sujet du projet: 1) Mise en place d'un environnement de développement / déploiement fonctionnel 2) Implémentation de l'étude de cas en Ada Ravenscar du code de contrôle du segway 3) Développer une interface NXT pour piloter le robot à distance via une tablette 4) Définition et mise en œuvre d'une politique de changement de modes fonctionnels (ligne droite, rotation,...) 5) Expérimentation du module dans des situations diverses 4. Description détaillée des réalisations obtenues 4.1. Tâche 1: Environnement de développement et déploiement Cette tâche n'a pas évolué depuis le livrable de mi-parcours. En effet vu le caractère assez urgent de la réalisation de la tâche 2 (Implémentation et test de l'étude de cas en Ada Ravenscar du contrôle du segway), il nous a paru plus important, à nous ainsi qu'à l'équipe encadrante, de porter toute notre attention sur cette dernière. De ce fait nous avons stoppé l'avancement de la mise en place de cet environnement complet sous linux et utilisé l'utilitaire Wine pour compiler le code source en un binaire exécutable et chargeable sur la brique Nxt. Néanmoins des perspectives pour la mise en place de la chaine complète de compilation sous Linux se dégagent, nous les détaillerons dans la partie perspectives de ce document. 3

4 Quant au chargement de l'exécutable sur la brique après compilation, il est pris en charge par l'outil «samba_run» disponible dans la chaine de compilation pour Windows. Nous avons facilement réussi à compiler cet outil sous Linux (en passant par la bibliothèque libusb ) et nous l'avons intégré à notre chaine de déploiement. Ce qui est donc obtenu est le résultat suivant: Installation de Wine Installation de l'exécutable fourni par AdaCore grâce à Wine: gnat-gpl-2010-mindstorms-nxt-windows-bin.exe Mise en place de variables d'environnement pour faciliter la compilation et le déploiement: => variables à inclure dans l'environnement (fournies avec le livrable technique). Modification du Makefile.inc fourni dans l'environnement gnat-gpl, ce Makefile doit être utilisé par le Makefile du code à compiler. Pour que tous les exécutables Windows soit captés par Wine, il nous a fallu rajouter des.exe pour chacun d'eux. Un exemple est fourni dans le livrable technique. Réalisation d'un Makefile utilisant les variables d'environnement pour notre application de contrôle du segway. Ce makefile compile le code source et permet le déploiement du binaire grâce à une cible run qui utilise l'outil de déploiement. Le détail de la démarche à suivre est fournie dans le livrable technique Tâche 2: Implémentation de l'étude de cas Implémentation de l'étude de cas en Ada Ravenscar du code de contrôle du segway Cette tâche comprend deux parties: la compréhension de la théorie concernant le contrôleur PID puis l'implémentation en Ada du code de contrôle du segway. Théorie: Le contrôleur PID agit sur l'erreur définie comme étant la différence entre la sortie du système et la valeur cible qu'on voudrait atteindre e t = Setpoint t Output t L'action se décompose en 3 termes d'une somme : 4

5 Composante proportionnelle K p e t : ce terme a pour effet de rapprocher la sortie du système de la valeur cible. Nous remarquons évidemment que pour obtenir cet effet, il faudrait choisir K p 0. Composante intégrale K i e d : ce terme prend en compte le passé de l'erreur, 0 ainsi, si pendant un certain temps l'erreur est négative, le système est emmené à produire une erreur positive (si K i 0 ) pendant un certain temps afin de compenser l'erreur négative. L'effet est donc (entre autres) une correction rapide mais avec un dépassement important sur la valeur cible et une oscillation de la sortie. de t Composante dérivée K d : ce terme anticipe le futur de l'erreur, ainsi, si la dt dérivée de l'erreur est négative, ceci veut dire que l'erreur est en train de diminuer, et donc le contrôleur réduit la commande pour éviter un dépassement de la valeur cible. L'effet est la réduction du dépassement de la sortie et un ralentissement de la convergence. La détermination des paramètres K p, K i et K d se fait par diverses méthodes dont une expérimentale et de mise en œuvre facile qui est la méthode de Ziegler Nichols. Méthode de Ziegler Nichols: La méthode de Ziegler-Nichols consiste en la détermination des paramètres de la manière suivante: Nous annulons les actions intégrale et dérivée et nous faisons augmenter progressivement le coefficient de l'action proportionnelle, jusqu'à arriver à une valeur pour laquelle le système entre en oscillation. Cette valeur sera notée K u le gain critique, et la période d'oscillation sera notée P u. À partir de ces paramètres il suffit d'appliquer les règles décrites dans le tableau cidessous pour déterminer la valeur des paramètres du contrôleur PID. Type de contrôle K p K i K d PID 0.60 K u 2 K p P u K p P u 8 Implémentation de l'étude de cas: Dans l'exemple du segway, nous avons implémenté en Ada profil Ravenscar le contrôleur PID décris précédemment. L'objectif initial était de contrôler le segway à distance grâce à une tablette qui aurait était connectée par le bluetooth à la brique NXT. Suite à des problèmes techniques vis à vis de ces tablettes, le code fonctionnel du projet se résume uniquement à l'implémentation du contrôleur qui a abouti à des résultats très satisfaisants. 5

6 Implémentation: L'implémentation utilise les bibliothèques des pilotes NXT fournis par AdaCore. Nous avons une seule tâche qui fait office de contrôleur. Au lancement du programme, l'utilisateur a une dizaine de secondes pour positionner le robot en équilibre. La tâche enregistre la valeur lue par le capteur et applique l'algorithme du contrôleur. Notre programme du contrôleur se base sur une discrétisation du temps car la valeur lue sur le capteur se fait de manière périodique. Ainsi à l'itération k la valeur de l'erreur E est égale à E(k) = ValeurCible - ValeurLue(k) l'intégrale I est égale à I(k) = I(k-1) + E(k) * PeriodeTache la dérivée D est égale à D(k)= (E(k) E(k-1)) / PeriodeTache La valeur de sortie qui est la somme de ces valeurs est bornée par les valeurs minimales et maximales de la vitesse que l'on peut transmettre aux moteurs (-100 et 100). Période du contrôleur: Au départ, nous avions pensé que la tâche de notre contrôleur était la seule à s 'exécuter sur le processeur. De ce fait nous avons mis la période de cette tâche la plus petite possible (de l'ordre de la milliseconde). Or il existe une autre tâche périodique qui est intégrée à l'api Ada pour NXT. Cette tâche permet de lire les valeurs des capteurs et d'envoyer les commandes aux moteurs de façon périodique. Sa période est de 20 millisecondes. Il était donc inutile que la période de notre contrôleur soit inférieure à celle-ci. Borne de l'intégrale: Dans la cas où le robot tombait dans nos tests, la valeur de l'intégrale augmentait le temps que le robot soit remis dans une bonne position d'équilibre. Ceci avait pour conséquence que la valeur de sortie était très importante, et une activation continue des moteurs. Nous avons donc borné la valeur de l'intégrale pour éviter d'attendre que la valeur de sortie du contrôleur diminue lors de la remise en place du robot. Boutons: Nous avons configuré les boutons de la brique NXT. Le bouton gris du milieu permet de réinitialiser le programme pour que l'utilisateur puisse recalibrer le robot. Le bouton orange permet d'arrêter la brique. La flèche droite (respectivement la flèche gauche )permet d'augmenter (respectivement de diminuer) la valeur cible du contrôleur pour affiner l'équilibre, au cas où la valeur du capteur lue initialement ne soit pas exactement la valeur d'équilibre du robot. 6

7 Calibrage: Selon la méthode Ziegler-Nichols, il faut commencer par déterminer le coefficient de gain critique. Pour le calculer de façon expérimentale nous avons placé les coefficients Ki et Kd à zéro et fait varier le coefficient Kp de manière à ce que le robot fasse des oscillations. Pendant la phase de calibrage, nous avons également divisé l'erreur détectée par une constante C (dans notre cas c'est une valeur arbitraire égale à 10) pour diminuer les trop grandes variations d'erreur. En contre partie, nous avons multiplié la valeur du coefficient critique à chaque essai par cette constante C. Nous avons ensuite déduit une période d'oscillation qui nous a permis de calculer à partir des formules décrites par la méthode de Ziegler-Nichols les coefficients Kp, Ki et Kd définitifs. La valeur du capteur étant fortement dépendante de la qualité lumineuse de l'environnement, nous avons calibré ces valeurs dans une pièce relativement sombre pour éviter toute perturbation lumineuse sur le capteur. De plus le sol était matte et de couleur blanche unie pour éviter tout reflets. L'expérience a été étendue sur un plan incliné d'environ 30 degrés : le résultat est satisfaisant, le robot arrive à rester stable. Les valeurs obtenues après expérimentation sont K u =77.5 et P u =0.325 ce qui a donné les coefficients de contrôle K p =46.5, K i = et K d =1.89 (la valeur récupérée par le capteur est en opposition avec l'action produite par la commande, ce qui correspond à avoir un 1 dans la boucle rétroactive de contrôle, d'où le fait que nous adoptons des valeurs de coefficients positives et non négatives comme dans les cas classiques) 4.3. Tâche 3:Pilotage du robot à distance via une tablette Le but de cette tâche était de pouvoir facilement changer la valeur de nos paramètres pour le calibrage du robot segway sans avoir à recompiler et déployer le code du contrôleur à chaque changement. Il était également envisager de pouvoir envoyer des commandes au robot pour qu'il avance ou recule. Cette tâche n'a pu être aboutie par manque de temps pour les tests de l'application qui a été développée ainsi que par la défaillance du matériel dont nous disposions. En effet il s'est avéré que l'appareil Android (HTC Desire HD) que nous souhaitions utiliser connait des bugs (reconnus sur de nombreux forums) au niveau des connexions en bluetooth avec d'autres appareils. De ce fait l'application développée n'a pas pu être testée. Le code développé sera malgré tout fourni dans le livrable technique pour pouvoir potentiellement être utilisé et amélioré par la suite. Il nous a fallu dans un premier temps comprendre et se documenter sur le protocole bluetooth mis en place sur la brique nxt. Nous nous sommes référé à la documentation fournies sur le site de Lego Mindstorms [8] ainsi qu'aux explications fournies par un expert extérieur. Ce qui a été retenu et qui est important à comprendre est le format des paquets ainsi que le type de message que l'on envoie, ici message texte voué à être lu du côté de l'application contrôleur. 7

8 Cette figure explique la manière dont est faite la communication entre la brique nxt et un autre appareil. Le protocole décrit dans leur documentation doit être respecté pour que le paquet envoyé depuis l'application distante soit correctement acheminé et surtout pris en compte par le programme déployé sur la brique. Le protocole pour l'envoie de message texte est le suivant: Il faut donc respecter ce protocole pour l'envoie de message vers la brique. Nous avons ensuite mis en place un protocole interne sur la signification de nos messages envoyés, une lettre spécifique pour un type de message (Start, Stop, SendKi,...), suivi parfois d'une valeur entière si le message envoyé est un paramètre par exemple. Cette partie n'ayant pu aboutir elle reste quelque peu inachevée et surtout non testée Tâche 4: Définition et mise en œuvre d'une politique de changement de modes fonctionnels Compte tenu des résultats obtenus: un programme contenant le corps du contrôleur PID, nous n'avons pu mettre en place ces différentes politiques et par conséquent ce point ne sera pas développé. 8

9 4.5. Tâche 5: Expérimentation du module dans des situations diverses Aux vues des résultats fonctionnels obtenus nous avons seulement pu expérimenter qu'un sous ensemble de toutes les situations possibles. Nous nous sommes notamment intéressé à l'environnement lumineux pouvant altérer le bon fonctionnement du système, au type de sol ainsi qu'à l'inclinaison du support. Contraintes sur l'environnement lumineux: L'application est fonctionnelle dans un environnement plutôt sombre pour permettre au capteur de lumière d'être plus précis. Il ne faut pas avoir une source de lumière engendrant des ombres aussi bien au niveau du support (plis de carton par exemple) qu'au niveau du robot lui même. Contraintes sur le type de sol: Le sol doit être uniforme et de couleur claire. Des variations de couleurs sur le sol rendent le système non fonctionnel (aucun état stable n'est trouvé). Tests de l'application avec différentes inclinaisons du support: Pour des supports ayant une inclinaison comprise entre 0 et 30, le robot segway parvient à rester en équilibre. Lorsque le support est incliné la phase d'initialisation doit consister à tenir le robot légèrement en arrière de son centre de gravité et la plupart du temps une correction doit faite grâce aux boutons de la brique pour recalibrer la valeur étalon. 5. Problèmes rencontrés Nous avons, au cours du projet, rencontrés trois principales difficultés, l'une d'entre elle reste non résolue. Tout d'abord les résultats attendus pour la tâche 1: chaine de développement, on été modifié : nous devons développer une chaine complète sous linux au lieu de l'utilisation de Wine. Cette nouvelle demande à été un frein pour le développement du reste du projet, car une partie de notre attention été focalisée sur cette tâche. Cette dernière reste non résolue et le livrable final ne fonctionne donc qu'avec l'utilitaire Wine. Comme présenté dans le rapport de mi-parcours, nous avons rencontré des difficultés avec le capteur numérique de lumière. En effet, sur le site de AdaCore cette fonctionnalité était annoncé comme opérationnelle mais ce n'est pas le cas. Une des solutions envisagée est d'utiliser un capteur analogique (au lieu de numérique). Nous avons reçu le capteur analogique le mercredi 9 mars, ce qui nous a retardé dans les tests du programme du contrôleur et dans le calibrage des différents paramètres et ne nous a pas permis de pouvoir avancer autant que nous l'espérions dans le projet. Le dernier problème que nous avons rencontré est un défaut avec l'appareil Android que nous voulions utiliser. Comme présenté 4.3, nous désirions utiliser un appareil mobile pour commander le robot segway à distance et aussi pouvoir envoyer des valeurs différentes pour les paramètres du contrôleur PID pour pouvoir faire le calibrage sans avoir à recompiler et déployer le programme sur la brique à chaque fois. Du fait de s'en être rendu compte un peu tard nous n'avons pu palier cette défaillance et donc tester et utiliser notre application Android. 9

10 6. Bilan et perspectives En bilan du projet nous pouvons être satisfait du travail que nous avons fournit ainsi que des résultats obtenus aux vues des nombreuses difficultés et problèmes matériels que nous avons rencontré. Malgré tout peut-être qu'une meilleure anticipation sur les choses à réaliser ainsi que prise en compte plus rapide des problèmes observés nous aurait permis d'en palier certains plus rapidement et donc aller un peu plus loin d'en l'avancement du projet. Concernant les perspectives du projet, nous pouvons en retenir deux principales: En premier lieu il serait intéressant de réussir à mettre en place la chaine de compilation et de déploiement complète sous Linux. Le script de compilation dans sa forme livrée, parvient à réaliser la première étape de compilation telle que décrite par la documentation de AdaCore qui correspond au premier «make» lancé sur les sources de GCC. Cependant l'étape de génération des outils GNAT par la commande «make -C gcc cross-gnattools» rencontre une erreur de compilation durant le traitement de fichiers source en Ada, ce qui pourrait signifier que la version du compilateur installé, qui est pourtant la dernière version 2010, n'est pas apte à compiler le code en question. Une précision a été dernièrement apportée par Tristan Gingold de AdaCore, sur le fait que le compilateur pour minstorm nxt est sorti 3 mois après le compilateur natif 2010 ce qui pourrait expliquer l'incapacité du compilateur 2010 à compiler certaines sources du compilateur mindstorm. De ce fait, une piste à suivre serait de passer par l'étape classique de «bootstrap» de la compilation de GCC qui consiste à compiler à partir des sources un premier compilateur natif, et ensuite l'utiliser pour recompiler ces même sources en compilation croisée. En outre, des scripts de compilation croisée ont été récemment trouvés sur internet [9] mais le temps n'a pas permis de les tester afin de voir s'ils sont utiles à notre but. Ensuite aux vues du travail que nous avons fournit pour la mise en place d'un protocole de communication bluetooth entre la brique nxt et un appareil Android. En effet nous pensons être assez proche d'un code fonctionnel aussi bien côté Android que côté Ada. Pour la partie Ada mindstorms nous avons pu tester l'acceptation de connection demandée par un appareil mobile ainsi que la réception de message envoyé grâce une application de type envoie de message respectant le protocole Lego Mindstorms [6] [7]. 7. Références Contrôleur PID: [1] [2] [3] Drivers Nxt: [4] Application Android: [5] [6] [7] 10

11 Protocole Bluetooth Lego Mindstorms: [8] [9] 11