Vous êtes sur la page 1sur 40

COLE POLYTECHNIQUE DE MONTRAL

DPARTEMENT DE GNIE INFORMATIQUE

Conception d'une architecture informatique sous QNXRTP pour le contrle d'un robot rouleur.

Rapport de projet de fin d'tudes soumis comme condition partielle l'obtention du diplme de baccalaurat en ingnierie.

Prsent par : Francis Mailhot Matricule: 1057217 Directeur de projet: Richard Hurteau Richard Gourdeau

Date: 17 avril 2002

Sommaire
Ce rapport a pour but doffrir une structure informatique flexible et robuste pour un projet abord dans le cours Projets de Gnie lectrique de lcole Polytechnique de Montral. Ce projet vise implanter une quipe de cinq robots pouvant jouer au soccer, tel que prsent lors de la comptition mondiale RoboCup. La structure des robots se base sur le projet SpinoS, robot dvelopp par le groupe SAE Robotique de lcole Polytechnique de Montral.

Chacun des robots a son bord un ordinateur lui permettant de prendre des dcisions et de se dplacer de faon autonome. Le systme dexploitation sur lequel sera implant ce travail est QNXRTP, mais lauteur dont prendre en considration que ce travail pourrait tre utilis dans le futur sur une plate-forme diffrente tel que RT-Linux.

Ce rapport sera dans un premier temps orient sur la conception de pilotes pour deux cartes de contrle. Ces cartes ont t achetes pour ce projet mais il nexiste actuellement aucun pilote permettant de les utiliser sous QNXRTP. Ce type de priphrique est crucial au projet car il permet au robot de contrler chacun de ses moteurs. Ensuite, la

conception dune architecture informatique en C++ et oriente objet sera prsent. Une architecture est dj utilise par le groupe de SAE Robotique mais une rvision complte sera effectue pour permettre aux futurs tudiants de PGE doprer les robots facilement tout en leurs permettant dinsrer dautres composantes sans avoir modifier larchitecture informatique implante. Finalement, par le travail effectu, il sera possible de comparer les performances des deux cartes de contrle utilises ainsi que du systme dexploitation utilis.

Table des matires


Sommaire..................................................................................................................................I Table des matires.................................................................................................................. II Remerciements ...................................................................................................................... IV Liste des tableaux....................................................................................................................V Listes des figures................................................................................................................... VI Listes des symboles et abrviations ....................................................................................VII 1 Introduction.......................................................................................................................... 1 2 Problmatique ...................................................................................................................... 2 2.1 Matriel de dveloppement............................................................................................2 2.2 Systme dexploitation...................................................................................................2 2.3 Priphriques ..................................................................................................................3 2.4 Logiciel de contrle........................................................................................................4 2.5 Outils de dveloppement ...............................................................................................6 3 Pilotes des cartes de contrles ............................................................................................ 6 3.1 Pilote ACS ......................................................................................................................8 3.1.1 Description ..............................................................................................................8 3.2 Pilote AJECO ...............................................................................................................10 3.2.1 Description ............................................................................................................10 4 Rsultats pour les pilotes................................................................................................... 11 4.1 Pilote pour la carte ACS-Tech80.................................................................................11 4.1.1 Limitations.............................................................................................................11 4.2 Pilote pour la carte AJECO..........................................................................................12 4.3 Utilisation des pilotes...................................................................................................12 4.3.1 Messages derreurs................................................................................................12 4.3.2 Activation et dsactivation des pilotes ................................................................12 4.4 Dsactivation des pilotes .............................................................................................13 4.5 Comparaisons sur les performances des deux cartes .................................................13 5 Logiciel de contrle ........................................................................................................... 14 5.1 Architecture informatique de SpinoS..........................................................................15 5.2 Structure globale...........................................................................................................17 5.2.1 Intgration des cartes de contrle.........................................................................18 5.2.2 Position du robot...................................................................................................21 5.2.3 Prise de dcision....................................................................................................22 5.2.4 Mouvement du robot.............................................................................................22 5.3 Oprations devant tre faites priodiquement ............................................................24 6 Rsultats.............................................................................................................................. 25 II

6.1 Les cartes de contrle ...................................................................................................25 6.2 Positionnement .............................................................................................................26 6.3 Cerveau .........................................................................................................................26 6.4 Mouvement...................................................................................................................26 7 Discussions......................................................................................................................... 27 7.1 Lajout de priphrique................................................................................................27 7.2 Lajout dune autre carte de contrle ou dun cerveau ..............................................28 7.3 Portabilit......................................................................................................................28 7.4 Recommandations........................................................................................................29 8 Conclusion.......................................................................................................................... 30 9 Bibliographie...................................................................................................................... 31 Annexe 1 ................................................................................................................................ 32

III

Remerciements
Jaimerais en premier lieu remercier M. Richard Hurteau sans qui cette ide de robot joueur de soccer naurait jamais vu le jour lcole Polytechnique de Montral. Ses indications sur lvolution du projet et sur les besoins des autres membres du groupe mont t trs utiles pour orienter mon travail selon les besoins futurs de lquipe. Jaimerais galement remercier M. Richard Gourdeau pour avoir accepter de superviser mon travail et pour avoir mis en place un serveur CVS.

Laide de Julien Beaudry a aussi t trs importante pour ce projet puisquil a su rpondre mes questions et son exprience dans le contrle de robot rouleur fut trs apprcie. Je noserais point passer sous le silence lexcellent travail de Richard Grenier et Marie-Lyne Brisson qui mont grandement simplifi la tche du ct technique.

Je tiens aussi remercier lquipe de SAE Robotique pour toutes les heures o jai pu approfondir mes connaissances qui sont maintenant appliques dans ce projet. Plus particulirement Rmi Lefebvre qui a fait par le pass une plate-forme de contrle dun robot rouleur et aussi, par ses rponses mes questions. Et finalement, je tiens remercier ma copine, Isabelle Cyrenne, qui a su tre comprhensive durant mes longues soires passes sur ce travail.

IV

Liste des tableaux


Tableau 5.1 : Description des modules de SpinoS ...............................................................17 Tableau 5.2 : Liste des tapes pour le dplacement en position..........................................23

Listes des figures


Figure 5.1 : Structure dun SE comme LINUX (http://www.qnx.com)..............................15 Figure 5.2 : Structure informatique de SpinoS sous RT-Linux[1] ........................................15 Figure 5.3 : Structure du noyau de QNXRTP .......................................................................16 Figure 5.4 : Structure de base du logiciel..............................................................................17 Figure 5.5 : Polymorphisme appliqu sur la classe Controller .....................................19 Figure 5.6 : Diagramme de classe de Creator .................................................................20 Figure 7.1 : Ajout de priphriques la structure logicielle ................................................27

VI

Listes des symboles et abrviations

QNXRTP Superutilisateur PGE PWM SE CVS

Systme dexploitation provenant de la compagnie QNX Ladministrateur du systme soit lusager root Projet de gnie lectrique Pulse Witdh Modulation Systme dexploitation Concurrent Versions System

VII

1 Introduction
Le domaine de la robotique est en constante volution. Les perces technologiques faites durant les dernires annes rendent accessible des applications robotises qui taient jadis impossible imaginer. Les performances des ordinateurs, les dispositifs de localisation haute prcision, le traitement dimage numrique sont dautant dexemples qui repoussent les barrires de la robotique.

Le prsent travail abordera un domaine de la robotique en plein essor. Un groupe de lcole Polytechnique de Montral travaille prsentement sur llaboration dun projet offrant la possibilit aux tudiants de gnie lectrique de manipuler une quipe de trois robots joueurs de soccer. Ce projet se base en grande partie sur les spcifications indiques lors de la comptition RoboCup (http://www.robocup.org/).

Le travail fait dans ce rapport se veut la conception dune architecture informatique pour ces robots afin de rpondre aux besoins actuels de lquipe.

2 Problmatique
Cette section numre les principaux points selon lesquels le prsent travail a pris forme. Puisque le premier but demand tait de rpondre aux besoins des diffrents membres de lquipe, il tait ncessaire lors du dbut du projet de les dfinir adquatement dans le but dassurer une volution du projet. Ainsi, les diffrents points abords dans cette section permettront de mieux comprendre les besoins de lquipe et la situation actuelle du projet.

2.1 Matriel de dveloppement


Au moment de lcriture de ces lignes, lquipe de dveloppement avait un prototype mcanique ainsi quun ordinateur industriel son bord. Ceci permettait donc de

dvelopper une structure informatique tout en ayant la possibilit de la tester sur ce prototype.

2.2 Systme dexploitation


Par les expriences passes, les membres de lquipe ont acquis une exprience importante face au systme dexploitation QNX (http://www.qnx.com). La nouvelle version de ce dernier, soit QNXRTP, jouit maintenant dune rputation importante dans le domaine des applications temps rel. De plus, cette plate-forme de dveloppement supporte maintenant le standard POSIX qui rend le dveloppement beaucoup plus facile pour les programmeurs comparativement aux prcdentes versions de QNX.

Lors du dbut du prsent travail, lquipe voulait se consacrer uniquement ce systme dexploitation. Cependant, il existait des contraintes au niveau matriel qui rendait cette alternative plus ou moins certaine. Notamment, le capteur dimage vido semblait crer un problme puisque la compatibilit avec QNXRTP ntait pas assure. Il fut cependant dcid que le prsent travail serait entirement effectu sur QNXRTP mais quil tait impratif dassurer une transition simple, sil y a lieu, vers un systme dexploitation comme Linux.

Pour ce qui est du langage de programmation, pour plusieurs raison, le C/C++ a t choisit car il est trs bien connu des membres de lquipe. Aussi, ce langage est trs bien support par le SE QNXRTP et il a fait ses preuves dans le domaine de la robotique. Et finalement, puisque cest le langage principalement enseign lcole Polytechnique de Montral, il tait vident que pour assurer une relve comptente au projet, ce choix devait tre fait.

2.3 Priphriques
Pour rendre le robot capable de se dplacer et dinteragir avec lenvironnement qui lentoure, il faut videmment avoir recourt dautres composantes lectroniques. Un membre de lquipe travail dj dans ce sens et tente de trouver les cartes pouvant offrir dexcellentes performances au robot.

Lachat de deux cartes de contrle diffrentes a dj t fait. Ceci dans le but dvaluer les performances de chacune et ensuite de procder lachat des cartes manquantes selon le rsultat obtenu. Ces cartes sont le lien direct entre lordinateur et les moteurs et permettent ainsi denvoyer un signal PWM au moteur selon la commande dsire. Les avantages de telles cartes cest quelles utilisent un contrleur PID interne qui en boucle ferme, assure la validit des commandes dsires et qui rduit considrablement le temps de calcul qui serait ncessaire par le CPU de lordinateur.

Par contre, le seul dsavantage repose sur le fait quaucun pilote nexiste sous QNXRTP. Donc, pour assurer la suite du projet, il est clair que cette partie a du tre effectue en premier.

Dautres priphriques vont tre appels tre intgr dans le futur au projet mais le prsent travail ne sattardera qu ltude des deux cartes prsentes.

2.4 Logiciel de contrle


Un autre point important prsentement requis par lquipe du projet est une base logicielle pour les dveloppements futurs. Comme il a t expliqu auparavant, la plateforme du robot en question provient du robot SpinoS dvelopp par des tudiants. Donc, une structure informatique a t implante sous RT-Linux. Cependant, selon une

premire analyse faite, il tait clair que les diffrences entre QNXRTP et RT-Linux imposent une modification importante de la structure informatique. Aussi, puisque les fonctionnalits requises par un robot suiveur de ligne comme SpinoS, et un pour un robot

joueur de soccer tant bien diffrentes, plusieurs modifications sur le logiciel devaient tes faites.

Pour bien comprendre les requis de cette structure logicielle, il faut se pencher sur la comptition RoboCup. Cette dernire est une comptition a laquelle une quipe de 6 robots doivent se dplacer sur le terrain de faon autonome. Il est intressant dobserver les ractions des joueurs de soccer rels pour essayer dintgrer une dmarche similaire aux robots sur le terrain. Donc, un robot pourrait tre appel ce dplacer un point prcis du terrain pour quil attende que le jeu se dplace dans sa direction. Mais aussi, il pourrait tre intressant davoir une commande qui indique au robot davancer une vitesse fixe comme dans le cas dune passe vers un jouer dj en dplacement. Mme chose pour le gardien avec qui, il pourrait tre intressant de suivre le dplacement du ballon selon une trajectoire en vitesse. Donc, la structure informatique devra tre en mesure doffrir ces deux types de dplacement au robot.

Un autre point important quil faut mentionner est que ces robots pourront tre appels tre utilis par des tudiants dans des cours. On sait videmment que lorigine de ce dveloppement est pour le cours de Projet de Gnie lectrique , mais il a aussi t question dune utilisation pdagogique dans dautres cours. Donc, la structure logicielle doit tre assez modulaire et complte pour quil soit facile de lutiliser dans plusieurs circonstances diffrentes et que le temps de transition entre les diffrentes situations soit minime.

2.5 Outils de dveloppement


Pour assurer une efficacit et une scurit dans les versions du code source dvelopp pendant les 4 mois de ce projet, lauteur a utilis le programme CVS

(http://www.gnu.org/software/cvs/cvs.html) qui permet de conserver une version du code source sur un ordinateur distance. Le choix de cet outil provient aussi du fait que QNXRTP contient ce programme dans son installation par dfaut.

Lutilisation

dun

outil

de

dveloppement

comme

le

logiciel

Together

(http://www.togethersoft.com/)

est ici appropri. Dun ct, il permet de construire

rapidement une structure oriente objet partir dun diagramme de classe gnr selon le modle UML. Aussi, il permet de gnrer une documentation complte pour le projet selon les commentaires indiqus dans le code source, ce qui sera videmment trs utile pour les prochains programmeurs sur le projet.

3 Pilotes des cartes de contrles


Dans cette section, il sera question de limplantation des pilotes pour les deux cartes de contrle tel que discut auparavant. On retrouve donc, dans lordre le pilote pour la carte de la compagnie ACS Tech80 ainsi que de celle de la compagnie AJECO. Et sera ensuite pertinent de dcrire les performances observes dans le but que lquipe puisse prendre une dcision sur la carte quil serait prfrable dutiliser pour la suite du projet.

Pour permettre lutilisation de priphrique dans des applications crites en C/C++ sous un systme dexploitation comme QNXRTP, il existe deux moyens diffrents. Le

premier tant de lier le pilote et lapplication par lditeur de liens lors de la compilation. Cette mthode peut savrer excellente dans plusieurs cas mais implique un problme de scurit sous QNXRTP. En effet, les pilotes dvelopps dans ce prsent travail doivent avoir accs en criture et en lecture lespace dadresse de la carte. Par exemple, les fonctions in(0x300) et out(0x300) suivantes du langage de programmation C permettent dcrire et de lire la valeur contenue ladresse hexadcimale 0x300. Cependant, seul le superutilisateur du systme peut utiliser ces fonctions comme il est mentionn dans la documentation Internet de QNXRTP. Ceci implique un problme pour lutilisation future des robots dans le cadre du cours de PGE. Puisque les tudiants vont avoir un accs au robot, il est prfrable de leur donner des accs contrls dans le but dassurer la scurit de linstallation ainsi que dune protection sur leurs donnes.

La deuxime option est prise en charge directement par le SE. Il sagit en fait du gestionnaire de priphrique (device drivers) qui permet denregistrer une application et la rendre accessible partir dun fichier contenu dans le rpertoire /dev du SE. Donc, une application crite en C/C++ peut alors ouvrir ce fichier et envoyer diffrentes commandes permises la carte. Cette option a un attrait important puisque le problme daccs superutilisateur est alors inexistant. Cependant, cette option peut insrer des dlais minimes dans la communication entre le gestionnaire de priphrique et lapplication de lutilisateur. Il est toutefois possible de croire que ces dlais

ninfluenceront pas les performances du robot.

Bref, pour les besoins du cours de Projet de Gnie lectrique, la dcision a t prise de fournir un pilote se basant sur le gestionnaire de priphrique de QNXRTP pour les deux cartes de contrles dcrites. Donc, tout dpendamment de la carte prsente sur le robot, une application peut ouvrir le fichier /dev/ctrl et envoyer les commandes dsires. Nous verrons donc dans les prochaines sections les choix ayant t fait face limplantation de ces deux pilotes.

3.1 Pilote ACS


3.1.1 Description La carte de contrle de la compagnie ACS-Tech80 utilise est le model 5950B en format PC/104. Elle permet de contrler 4 axes (moteur courant continu) simultanment. Deux modes permettent soit de fonctionner en boucle ouverte ou bien, avec le retour dencodeurs, en mode ferm. Ce dernier mode permet de plus denvoyer des commandes en position ou bien en vitesse.

Il est important de comprendre que la logique de cette carte repose sur une puce lectronique MC1401A de la compagnie PMD Corp. La documentation technique est incluse en annexe 1. La comprhension de cette dernire est primordiale pour russir implanter le pilote car il est alors possible de mieux comprendre la logique interne de la carte. En effectuant cet exercice, il a t possible de remarquer que les fonctionnalits de

la carte dACS tait en fait exactement celle de la puce MC1401A sauf quelques petites diffrences dont par exemple, la possibilit dutiliser un encodeur en mode diffrentiel.

La puce de contrle tait bien connue de lauteur puisquelle est utilise par les membres de SAE Robotique depuis plusieurs annes. Il a t fait par le pass un pilote de contrle pour la carte sous Linux permettant la communication entre la puce et lordinateur. Les diffrences existantes entre la carte de ACS-Tech80 et celle de SAE Robotique ont t values et il a t possible de conclure que toutes les fonctions supportes par la puce MC1401A taient incluses dans ce pilote sous Linux. Le choix dimplantation sest donc tourn vers la rutilisation du code ouvert de SAE Robotique dans le but de le rendre fonctionnel sous QNXRTP.

Autre point important est celui dune vrification logicielle de la prsence de la carte avant denvoyer des informations sur la plage dadresse. La carte de ACS-Tech80

contient ladresse (base+0x10) du bus de donnes un caractre quivalent la lettre T (0x54). Donc, lors du lancement du pilote de contrle, il serait possible daller lire cette valeur et de prouver quil existe bien une carte ACS-Tech80 de modle 5950B cette adresse de base. Cette vrification peut savrer importante puisque deux modles

diffrents de cartes de contrle peut se retrouver sur lordinateur.

3.2 Pilote AJECO


3.2.1 Description Cette carte de contrle, modle ANDI-SERVO de la compagnie AJECO

(http://www.ajeco.fi), permet lutilisation de deux moteurs courant continu en boucle ferme. Elle se base sur lutilisation de la puce LM629 de la compagnie National

Semicondutor. Tout comme la carte de ACS-Tech80, deux modes de contrle en boucle ferme sont possibles avec cette carte soit un asservissement en vitesse et en position.

La compagnie AJECO fourni le code source de la librairie pouvant tre utilis sous DOS. Dans le but dviter de refaire le travail dj fait et puisquil est possible dutiliser ce code source ouvert, il a facilement t possible de modifier le code pour le rendre fonctionnel sous QNXRTP et den vrifier les fonctionnalits et les performances de la carte. Pour ce faire, les fichiers sdrv.h et sdrv.c ont t tests par lexcutable demo.c inclus sur le disque compact fourni. Il a donc t observ quil tait possible dutiliser cette librairie de AJECO sous QNXRTP. Par contre, comme il a t mentionn

auparavant, il est risqu dutiliser cette forme dimplantation puisque lexcution des excutables doit ncessairement se faire avec les accs du superutilisateur. Donc, selon les tests excuts, il tait possible et essentiel de faire une interface cette librairie pour en permettre laccs partir du gestionnaire de priphrique du SE.

10

4 Rsultats pour les pilotes


Les pilotes pour les deux cartes ont t faits avec succs. Voici dont les particularits du travail fait

4.1 Pilote pour la carte ACS-Tech80


Le fichier acs_qnx.h contient toutes les macros qui doivent tre ncessairement utilises par QNXRTP afin dutiliser denregistrer cette application sur le gestionnaire de priphrique. Ces macros indique la liste des commandes pouvant tre envoys la carte par des accs selon la commande devctl() de QNXRTP.

Comme il a t mentionn, le pilote implant dans ce prsent travail provient en partir de celui utilis sous Linux par les membres de SAE Robotique. Les modifications apportes ce pilote pour le rendre fonctionnel sous QNXRTP furent mineures. Cependant,

lintgration sous QNXRTP sest avre plus longue que prvu car le gestionnaire de priphrique est une nouvelle fonctionnalit du SE et la documentation et les exemples disponibles ntaient pas trs nombreux. 4.1.1 Limitations - Il existe quelques fonctions prises en charge par le FPGA de la carte qui ne sont pas prises en charge par ce module. Les fonctions qui sont supportes par le pilote sont toutes celles utilises par le microprocesseur PMD. Les interruptions nont pas t enregistres sur le gestionnaire de priphrique puisquil na pas t jug essentielle de les utiliser dans la structure informatique.

11

4.2 Pilote pour la carte AJECO


Le fichier dev_ajeco.h contenu sur le disque compact dans le rpertoire pilotes/ajeco contient les diffrentes commandes quil est possible dutiliser avec la fonction dev_ctl() de QNXRTP. Cest commande sont aussi dcrites dans la documentation provenant avec la carte. Comme il a t mentionn, ce pilote offre une interface aux diffrentes fonctions incluses dans la librairie sdrv.c et sdrc.h dAJECO.

4.3 Utilisation des pilotes


4.3.1 Messages derreurs Les messages dinformation pertinents et tous les messages derreurs rencontres par le module sont envoys dans lapplication syslog. Pour les voir, il suffit faire la commande sloginfo sur un terminal.

4.3.2 Activation et dsactivation des pilotes La liste suivante nonce les diffrentes commandes pour activer les pilotes des cartes. Aller dans le rpertoire contenant lexcutable du module (cd ~pilotes/acs/ ou bien ~pilotes/ajeco/) Compiler le module (make) Excuter le module (./module_acs & ou bien ./dev_ajeco &) en mode superutilisateur (commande su )

12

4.4 Dsactivation des pilotes


Trouver le numro du processus du pilote par la commande ps A sur un terminal. Faire la commande kill <noProcess> en mode superuser

4.5 Comparaisons sur les performances des deux cartes


Lors dessais effectus par un membre de lquipe, il fut observ que la carte ACS rpondait des requtes des vitesses relativement lentes, soit au minimum 1 ms par requtes. Dans le but de valider cette affirmation, des essais ont t faits sur la carte AJECO et les performances obtenues ont t largement suprieures puisque quen temps denviron 350 us a t observ par requtes.

13

5 Logiciel de contrle
Maintenant que les deux pilotes des cartes de contrle sont fonctionnels, il est maintenant possible de concevoir une structure logicielle qui permettra au robot de se dplacer, de penser et dinteragir avec son environnement.

Les besoins de lquipe ont t discuts dans la section 2.4. Il est pertinent ici den faire la liste et dajouter au besoin dautres points selon le travail qui a t effectu jusqu prsent. Donc, il serait important dintgrer les fonctionnalits suivantes la structure informatique : Offrir un systme versatile peut importe la carte de contrle utilise. Offrir la possibilit de changer les modes de fonctionnement du robot. Donc, passer en mode dasservissement en vitesse ou bien en position quand on le dsire. Offrir un moyen de changer le module de prise de dcision du robot facilement. Permettre aux futurs programmeurs dajouter des priphriques de faon transparente la structure logicielle.

Par cette section, une structure logicielle oriente objet sera mise en place dans le but de rpondre la liste des besoins ci-dessus. Une valuation de la structure informatique de SpinoS sera en premier lieu effectu ce qui permettra den observer les forces et faiblesse face aux besoins de ce travail. expliques. Par la suite, les diffrentes dcisions prises seront

14

5.1 Architecture informatique de SpinoS


La structure informatique implante sur le robot rouleur SpinoS est directement lie aux contraintes de temps rels requis par lquipe. RT-Linux permet datteindre des

performances acceptables de temps rel sur le noyau existant de Linux. Mais pour ce faire, il faut que lapplication temps rel soit intgre sous la forme de module interne du noyau, soit du ct que lon surnomme kernel space . La figure suivante, tire du site Internet de QNX, explique bien cette particularit. On remarque aussi que les

applications normales qui nont pas de contraintes temps rel sont situes du ct user space .

Figure 5.1 : Structure dun SE comme LINUX (http://www.qnx.com) La figure ci-dessous montre quil a donc du tre ncessaire dinclure un processus de communication entre les deux niveaux. Cette particularit est prsente par la prsence de trois tubes de communication permettant lchanger les informations pertinentes.

Figure 5.2 : Structure informatique de SpinoS sous RT-Linux[1] 15

Il est important de prciser la raison pour laquelle les deux parties du logiciel ont du tre spare. En effet, pourquoi lapplication spinosd na-t-elle pas t incorpore dans la partie temps rel ? Ce choix de conception fait cette poque pour le robot SpinoS impliquait la ncessit de sparer les deux parties pour des raisons bien simples. La principale raison tant de minimiser le temps de calcul du ct kernel space. Nayant pas agit de la sorte, des risques importants sur la stabilit du SE aurait pu survenir sur la protection de la mmoire[2].

Pour ce qui est de QNXRTP, la structure du noyau est lgrement diffrente comme le montre cette figure.

Figure 5.3 : Structure du noyau de QNXRTP (http://www.qnx.com)

Donc, on remarque que la partie kernel space est inexistante. En effet, la particularit de QNXRTP est justement que toutes les applications sont situes dans le mme espace mmoire mais que toutes les requtes passent par le microkernel . Bref, il est possible dobtenir dexcellentes performances temps rel avec une simple application situ dans le user space . Donc, il nest plus essentiel dutiliser le processus de communication entre la partie de calcul et la partie temps rel.

Les diffrents modules de la figure 5.2 de lapplication spinosd ont aussi une importance dans notre raisonnement. Le tableau 5.1 de la page suivante explique chacune des parties.

16

Module Controller Position

Fonction Envoie les commandes du ct temps rel. Dtermine la position actuelle du robot selon la lecture dencodeur.

Trajectory Brain Strip

Permet de dplacer le robot selon une squence de points (x, y). Prend les dcisions selon lalgorithme implant. Module permettant de faire la lecture des donnes provenant dun capteur de ligne. Inutile pour le cas de robot joueur de soccer

Tableau 5.1 : Description des modules de SpinoS

Lensemble de ces modules est assez complet pour en faire une excellente basse pour la structure sous QNXRTP. Nous verrons donc dans la prochaine section les choix de conception faits.

5.2 Structure globale


En sinspirant fortement de la structure informatique de SpinoS, le rsultat de la figure suivante est propos et sera valu.

Figure 5.4 : Structure de base du logiciel

17

Donc, une lgre modification sur le diagramme de classe a t apporte dans cette structure comparativement la structure de SpinoS. videmment, les processus de communications sont maintenant inexistants et la classe Controller soccupe denvoyer les informations directement la carte de contrle. Cette dernire est

accessible, comme nous lavons vu prcdemment par le fichier /dev/ctrl et par les fonctions de devctl() appropries. La classe Position dtermine encore la position du robot mais maintenant, elle prend les valeurs des encodeurs directement de la classe Controller . Pour ce qui est de la classe Movement , elle vient remplacer la classe Trajectory de SpinoS et annule le lien existant entre Brain et Controller . Pour ce qui est de la classe Brain de cette nouvelle structure, elle envoie ses commandes de position ou bien de vitesse directement Movement et peut accder la classe Position afin davoir les lments essentiels pour prendre une dcision.

5.2.2 Intgration des cartes de contrle Le but recherch par cet objet est de pouvoir intgrer facilement les deux cartes de contrle prsentement utilises sur le projet. Donc, une solution intressante est dutiliser le polymorphisme partir dune classe de base commune aux deux cartes de contrle. La figure suivante illustre ce principe.

18

Figure 5.5 : Polymorphisme appliqu sur la classe Controller Les fonctions en italiques dans la classe Controller sont des fonctions virtuelles pures. Donc, les classes hritant de Controller doivent ncessairement redfinir les fonctions virtuelles pures ce qui permet donc, dans la situation actuelle, davoir les diffrents envois de commandes aux cartes ACS et AJECO redfinis et propres chacune des cartes. Pour cette raison, la fonction stop() qui est virtuelle pure dans la classe

Controller est prsente dans toutes les classes drives. Dun autre ct, pour viter la redondance de code et les inconvnients sy rattachant, des fonctions communes aux trois classes sont directement dclares dans la classe de base. Par exemple, la fonction get_pos() nest dfinie que dans la classe de base ce qui vite de copier trois fois le code correspondant dans les classes drives.

Autre point intressant est la prsence de la classe Controller_virtual . Comme son nom lindique, cette classe permet de simuler une carte de contrle. Donc, il est ainsi possible de faire excuter le programme mme si aucune carte de contrle est prsente sur lordinateur.

19

Maintenant, pour offrir un systme versatile, il faut maintenant tre en mesure de pouvoir crer la classe approprie de faon simple et transparente. Pour ce faire, le patron de conception Factory method [3] sapplique trs bien ce genre de problme. Ce

constructeur virtuel offre une interface qui permet de crer une classe selon linterface de son parent. La figure suivante illustre ce principe.

Figure 5.6 : Diagramme de classe de Creator

Et pour mieux comprendre lutilit, un exemple de code pour la fonction create_controller() est prsent.
Controller* Creator::create_controller(string ctrl_name) { if (ctrl != NULL) return ctrl; transform (ctrl_name.begin(), ctrl_name.end(), ctrl_name.begin(), tolower); if (ctrl_name == "virtual") { ctrl = new Controller_virtual(); } #ifdef __QNXNTO__ else if (ctrl_name == "acs") {

20

ctrl = new Controller_acs(); return ctrl; } else if (ctrl_name == "ajeco") { ctrl = new Controller_ajeco(); return ctrl; } #endif return ctrl; }

Donc, la fonction create_creator() reoit en paramtre un identificateur. Ce dernier est ensuite compar dans la srie de if et sil y a russite, la classe drive de Controller est alors cre.

Aussi, dans le but doffrir aux autres classes laccs ce contrleur tout au long de lexcution du programme, lajout du patron Singleton 8 dans la classe Creator a t implante. Ceci permet de conserver quune seule instance de la classe Creator tout au long de lexcution du programme. Et comme il est possible de le remarquer, le constructeur est priv ce qui fait quil est impossible pour les objets extrieurs daccder au constructeur. Pour obtenir une instance cette classe, il faut alors faire appel la fonction statique Instance() qui elle peut avoir accs au constructeur priv Creator() si aucune instance existe. Dans le cas contraire, linstance courante est retourne.

5.2.3 Position du robot partir de la valeur de chacun des encodeurs, il est possible de dmontrer mathmatiquement que nous pouvons obtenir la position du robot et plusieurs autres paramtres utiles comme la position x et y ainsi que lorientation. Il ne sera pas question

21

ici de la dmonstration complte de la dtermination de ces paramtres car M. Beaudry a effectu ce travail dans son projet de fin dtude[1].

5.2.4 Prise de dcision Le module de prise de dcision se veut tre le cerveau du robot. Aussi, comme spcifi dans les besoins de lquipe, la possibilit davoir plusieurs cerveaux diffrents et de pouvoir dcider dynamiquement lors lexcution du programme serait trs utile. Le polymorphisme utilis dans le cas de la classe Controller peut trs bien sappliquer ici et vient rpondre aux besoins initiaux de lquipe. Et par lutilisation de la classe

Creator , il est encore possible de faire une fonction create_brain() dans laquelle un identificateur est pass par paramtre et permet de crer linstance dsire de faon dynamique.

5.2.5 Mouvement du robot

Une des contraintes impose par les membres de lquipe est la possibilit de changer de mode de dplacement en cours de partie. Par exemple, un dfenseur pourrait prfrer se diriger un point (x,y) alors que dans un autre cas, il pourrait prfrer poursuivre un adversaire selon une vitesse quelconque. Pour le dplacement en position, il devrait tre possible dindiquer le point dsir mais aussi lorientation finale du robot pour que ce dernier ait par exemple, une prise de vue pertinente partir de sa camra intgre.

22

La possibilit de changer de mode requiert un suivi des commandes prcdentes provenant du cerveau. Car dans le cas ou la dernire commande ait t selon une commande en vitesse et que la commande actuelle soit une commande en position, alors on doit tre en mesure deffectuer le changement de mode correctement et de faon transparente. Pour ce faire, une simple mthode de rsolution est dajuster en premier lieu lorientation du robot pour quil atteigne la position (x, y) demand. Ensuite, le dplacement en ligne droite est effectu. Et finalement, lorientation prcise par thta est envoye au robot. Le tableau suivant rsume ces commandes.

tapes 1 2 3

Commandes Orienter le robot vers le point (x,y) en le faisant tourner autour de son centre. Dplacer le robot vers le point (x,y) Orienter le robot selon le thta dsir

Tableau 5.2 : Liste des tapes pour le dplacement en position

Bien quelle soit simple, cette mthode implique un problme de conception. Le temps pour dplacer le robot vers une orientation selon x,y, le temps de dplacement et ensuite lorientation finale implique trois mouvement diffrents. Il existe un moyen sur les deux cartes de contrle de spcifier un mouvement suivant lorsque le premier est atteint (c.-d. par des breakpoints ). Le problme avec cette faon dutiliser la carte est quun dplacement en position peut prendre par exemple quelques secondes tandis que le cerveau du robot pourrait alors changer dide et demander le dplacement vers une autre

23

position.

Alors il doit y exister un moyen de faire en sorte quun changement de

commande soit interprt immdiatement par la structure informatique et non une fois que le dplacement courant est termin.

Pour ce qui est de lasservissement en vitesse, ce genre de contrainte ne se pose pas puisque la commande en vitesse est envoye une seule fois la carte et ce, sans causer de dlai.

5.3 Oprations devant tre faites priodiquement


Lutilisation de QNXRTP permet datteindre dexcellentes performances temps rel. Donc, pour la structure logicielle prcdemment propose, et selon ce quil avait t fait avec le robot SpinoS, il nous est possible dutiliser des moyens du SE afin de rendre de faon priodique certains appels. Les quatre classes principales comportent toutes une fonction update() qui permet de mettre jour les diffrents attributs de la classe et dfectuer des vrifications de routine. Pour Position , chaque paramtre sur le robot est mis jour. Pour Movement , la vrification savoir si une nouvelle commande a t demand et savoir si la position dsire est atteinte pour un asservissement en position est vrifie. Et finalement, la classe Brain pourrait-elle aussi tre appele de faon priodique afin que la prise de dcision soit faite de faon priodique.

Les avantages de lutilisation dappel priodique sont importants. En effectuant des appels priodiques sur la classe Position on diminue le bruit prsent lors de la drive calcule. Aussi, il est attrayant de simuler au pralablement le comportement du robot

24

dans un logiciel comme Matlab. Donc, en assurant une priode fixe dans la prise de dcision, la simulation est alors beaucoup plus prs de la ralit.

6 Rsultats
La structure informatique de base a t implante et le code source est disponible sur le disque compact. Cependant, par manque de temps, la structure complte na pu tre complt entirement. En fait, il sera possible dobserver que plusieurs fonctions ne sont pas compltes. La prsente section a donc pour but dexpliquer le travail qui a t fait ainsi que les tests effectus.

6.1 Les cartes de contrle


Les deux classes faisant le lien avec les cartes de contrle, soit Controller_acs ainsi que Controller_ajeco permettent de communiquer avec ces dernires. Il a t

dmontr par des essais concluants que la communication avec les cartes tait fonctionnelle. Il reste nanmoins complter les diffrents envois en position ainsi que le changement de mode.

Aussi, il a t possible dexprimenter que la construction dynamique effectue laide de la classe Creator tait entirement fonctionnelle et rpondait exactement aux objectifs de lquipe soit de permettre lutilisation des deux cartes de contrle sur la structure informatique de faon transparente et avec un temps minimal de transition. En fait, il ny a qu changer lidentificateur prsent lors de la cration de linstance vers la classe Controller pour changer lenvoie aux diffrentes cartes.

25

6.2 Positionnement
La classe Position est complte et les essais qui ont t effectus avec les deux cartes de contrle ont permis dobserver que la position, lorientation et la vitesse retourn taient fonctionnels.

6.3 Cerveau
Lalgorithme de dcision ne faisant pas parti de ce travail, le lecteur trouvera dans le fichier Brain1.cc dans la fonction update() une prise de dcision assez simple. Par contre, il a t possible partir de cette dernire de faire les diffrents tests partir de certaines touches du clavier. Donc, la structure du cerveau est fonctionnelle et les prochains programmeurs pourront alors construire un algorithme plus volu de prise de dcision.

Aussi, la mme particularit de linstance vers la carte de contrle a t teste. Effectivement, il est possible de spcifier partir dun identificateur pass la fonction create_brain() du fichier pge.cc, le nom du cerveau que lon dsire utiliser. Donc, cette structure rpond encre une fois aux besoins de lquipe davoir la possibilit de changer le cerveau du robot de faon simple et rapide.

6.4 Mouvement
La classe Movement est actuelle fonctionnelle quen un mode dasservissement en vitesse. Mais la structure de lalgorithme pour rgler le problme prsent la section 5.2.4 est suggre dans le corps de la fonction update() et plusieurs commentaires prsents dans le code sauront rendre limplmentation simple aux prichains programmeurs de lquipe.

26

7 Discussions
Cette section propose les diffrents points importants afin dassurer lvolution du projet informatique pour les futurs programmeurs. Bien entendu, cette section nest qu titre indicatif mais elle donne un compte rendu raliste du travail restant afin dobtenir des vrais joueurs de soccer!

7.1 Lajout de priphrique


Pour lajout dun priphrique quelconque, la cration dune classe pour les accs ce dernier est conseille. La figure ci-desous montre un exemple o la classe

Brain_camera requiert laccs une camra. Dun autre ct, on peut remarquer que la classe Brain_aveugle ne se proccupe pas de lexistence de la camra.

Figure 7.1 : Ajout de priphriques la structure logicielle

27

7.2 Lajout dune autre carte de contrle ou dun cerveau


Selon lavancement du projet, les membres de lquipe pourraient vouloir acheter une autre carte dont il na pas t question dans ce document. Aussi, lintgration dun cerveau pourrait aussi tre effectue. Les tapes indiques si dessous permettront de faciliter lintgration de cette carte et du cerveau au reste de la structure.

Il faut construire la classe drive de la classe de base soit Controller pour une carte de contrle et de la classe Brain pour un nouveau cerveau.

Il faut ajouter un indicateur de format String soit dans la fonction create_controller() ou bien dans la fonction create_brain() de la classe Creator . Cette partie permet la construction de lobjet de faon dynamique lors de lexcution comme mentionn dans la section 5.2.1.

Et finalement, il faut ajouter une rfrence au fichier nouvellement cr de la nouvelle classe dans la liste des objets du Makefile .

7.3 Portabilit
Comme il avait t spcifi au dbut de ce projet, la portabilit du code vers un SE comme Linux devait tre assure de faon simple. Le rsultat obtenu permet

prsentement de compiler le code sur Linux mais une partie importante de la structure nest pas prise en charge lors de la compilation, soit les accs aux cartes de contrle. En effet, les classes Controller_acs et Controller_ajeco nont t implant que pour des fonctions ddies de QNXRTP. Donc, si un jour la dcision est prise dutiliser Linux, les accs aux cartes de contrles devront tre modifis ainsi que les pilotes de ces cartes.

28

7.4 Recommandations
La liste suivante propose des points quil serait intressant dajouter au logiciel afin de le rendre encore plus flexible. Slection des classes utiliser partir de la ligne de commande : il serait trs intressant de pouvoir passer sur la ligne de commande des informations comme le cerveau utiliser. Par exemple, la commande ./pge b brain_camera

pourrait indiquer que lon dsire utiliser la classe Brain_camera ce qui permettrait de ne pas avoir besoin de recompiler le code.

Paramtres du robot contenus dans un fichier de configuration : Un fichier texte pourrait contenir des paramtres succeptible de changer frquemment. Par

exemple, les gains Kp, Kd et Ki pourraient alors tre modifi sans avoir recompiler le code.

Fichier de sortie : Avoir la possibilit denregistrer dans un fichier, lors de lexcution du programme, des informations pertinentes. Par exemple, les

informations sur la position des deux encodeurs et le temps associ pourrait tre sauvegard pour quil puisse tre possible de traiter ces informations dans un logiciel comme Matlab.

Implanter une interface graphique : La structure logicielle du code pourrait facilement intgrer une interface modulaire de visualisation de diffrents paramtres et tats du robot. Cette particularit pourrait tre trs utile pour le dbogage et la mise au point de la configuration du robot. De plus, cette dernire pourrait tre utilise dans certains cours pour des mthodes dapprentissage.

Utiliser un script pour dmarrer les pilotes des cartes de contrle: Puisque les tudiants nauront pas accs aux droits du superutilisateur, il serait ncessaire de crer un script dmarrant le pilote soit au dmarrage de lordinateur ou bien par ltudiant lui mme. 29

8 Conclusion
Ce document est le rsultat de plusieurs heures de travail. Dun ct, lintgration des pilotes des deux cartes de contrle utilises a t effectue avec succs. Mais cette partie du travail a ncessit plus de temps que prvu initialement car QNXRTP tant un SE assez rcent, la documentation sur le sujet est relativement rare. Dun autre ct, le travail a port sur une architecture logicielle oriente objet pour le contrle dun robot jouer de soccer. Bien que cette partie nait t implante quen partie, il demeure pas moins que la structure de base est fonctionnelle et que les diffrents tests faits ont dmontr le respect des objectifs initiaux. Et finalement, les indications incluses dans ce prsent document et les informations laisses dans le code source sauront assurer la suite du projet.

Ce projet de fin dtude comporte plusieurs points dont lauteur a fait lapprentissage durant ces quatre dernires annes lcole polytechnique de Montral. Il est clair aussi que ce projet fait aussi parti dun domaine qui intresse grandement lauteur. Pour toutes ces raisons, lexcution de ce travail sest avr une excellente exprience.

30

9 Bibliographie
[1] BEAUDRY, Julien, Projet SpinoS: Conception et contrle dun robot mobile vitesses diffrentielles -- Projet de fin dtude, Montral, cole Polytechnique de Montral, 2001. [2] RUBINI, Alessandro, CORBET, Jonathan , LINUX device drivers, USA, OReilly & Associates, 1995. [3] GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, VLISSIDES, John, Design Patterns Elements of Reusable Object-Oriented Software, USA, Addison-Wesley, 1995.

Autres documents utiles GALLMEISTER, Bill O., POSIX.4 Programming for the real world, USA, OReilly & Associates, 1995. DEITEL et DEITEL, Comment programmer en C++, Canada, Les ditions Reynald Goulet inc., 200.

31

Annexe 1
Liste des fichiers inclus sur le disque compact fournis avec ce rapport

Documentation ACS: Contient les manuels dutilisations et les rfrences la puce de PMD Corp AJECO: Contient les manuels dutilisations et les rfrences la puce LM629 de National Semiconductor QNX : Contient la page Internet complte sur les indications pour le gestionnaire de priphrique de QNXRTP Pge : Contient le code source complet de la structure informatique Pilotes ACS : Contient le code source pour le pilote de la carte dACS AJECO : Contient le code source pour le pilote de la carte dAJECO

32