Upload
nguyenliem
View
224
Download
0
Embed Size (px)
Citation preview
ÉCOLE POLYTECHNIQUE
DE MONTRÉAL
DÉPARTEMENT DE GÉNIE INFORMATIQUE
Conception d'une architecture informatique sous QNXRTP pour le contrôle d'un robot rouleur.
Rapport de projet de fin d'études soumis comme condition partielle à l'obtention du
diplôme de baccalauréat en ingénierie.
Présenté par : Francis Mailhot Matricule: 1057217 Directeur de projet: Richard Hurteau Richard Gourdeau
Date: 17 avril 2002
I
Sommaire
Ce rapport a pour but d’offrir une structure informatique flexible et robuste pour un projet
abordé dans le cours « Projets de Génie Électrique » de l’école Polytechnique de
Montréal. Ce projet vise à implanter une équipe de cinq robots pouvant jouer au soccer,
tel que présenté lors de la compétition mondiale RoboCup. La structure des robots se
base sur le projet SpinoS, robot développé par le groupe SAE Robotique de l’École
Polytechnique de Montréal.
Chacun des robots a à son bord un ordinateur lui permettant de prendre des décisions et
de se déplacer de façon autonome. Le système d’exploitation sur lequel sera implanté ce
travail est QNXRTP, mais l’auteur dont prendre en considération que ce travail pourrait
être utilisé dans le futur sur une plate-forme différente tel que RT-Linux.
Ce rapport sera dans un premier temps orienté sur la conception de pilotes pour deux
cartes de contrôle. Ces cartes ont été achetées pour ce projet mais il n’existe actuellement
aucun pilote permettant de les utiliser sous QNXRTP. Ce type de périphérique est crucial
au projet car il permet au robot de contrôler chacun de ses moteurs. Ensuite, la
conception d’une architecture informatique en C++ et orientée objet sera présenté. Une
architecture est déjà utilisée par le groupe de SAE Robotique mais une révision complète
sera effectuée pour permettre aux futurs étudiants de PGE d’opérer les robots facilement
tout en leurs permettant d’insérer d’autres composantes sans avoir à modifier
l’architecture informatique implantée. Finalement, par le travail effectué, il sera possible
de comparer les performances des deux cartes de contrôle utilisées ainsi que du système
d’exploitation utilisé.
II
Table des matières Sommaire..................................................................................................................................I Table des matières.................................................................................................................. II Remerciements ...................................................................................................................... IV Liste des tableaux....................................................................................................................V Listes des figures................................................................................................................... VI Listes des symboles et abréviations ....................................................................................VII 1 Introduction.......................................................................................................................... 1 2 Problématique ...................................................................................................................... 2
2.1 Matériel de développement............................................................................................2
2.2 Système d’exploitation...................................................................................................2
2.3 Périphériques ..................................................................................................................3
2.4 Logiciel de contrôle........................................................................................................4
2.5 Outils de développement ...............................................................................................6
3 Pilotes des cartes de contrôles ............................................................................................ 6 3.1 Pilote ACS ......................................................................................................................8
3.1.1 Description ..............................................................................................................8 3.2 Pilote AJECO ...............................................................................................................10
3.2.1 Description ............................................................................................................10 4 Résultats 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 d’erreurs................................................................................................12 4.3.2 Activation et désactivation des pilotes ................................................................12
4.4 Désactivation des pilotes .............................................................................................13
4.5 Comparaisons sur les performances des deux cartes .................................................13
5 Logiciel de contrôle ........................................................................................................... 14 5.1 Architecture informatique de SpinoS..........................................................................15
5.2 Structure globale...........................................................................................................17
5.2.1 Intégration des cartes de contrôle.........................................................................18 5.2.2 Position du robot...................................................................................................21 5.2.3 Prise de décision....................................................................................................22 5.2.4 Mouvement du robot.............................................................................................22
5.3 Opérations devant être faites périodiquement ............................................................24
6 Résultats.............................................................................................................................. 25
III
6.1 Les cartes de contrôle ...................................................................................................25
6.2 Positionnement .............................................................................................................26
6.3 Cerveau .........................................................................................................................26
6.4 Mouvement...................................................................................................................26
7 Discussions......................................................................................................................... 27 7.1 L’ajout de périphérique................................................................................................27
7.2 L’ajout d’une autre carte de contrôle ou d’un cerveau ..............................................28
7.3 Portabilité......................................................................................................................28
7.4 Recommandations........................................................................................................29
8 Conclusion.......................................................................................................................... 30 9 Bibliographie...................................................................................................................... 31 Annexe 1 ................................................................................................................................ 32
IV
Remerciements
J’aimerais en premier lieu remercier M. Richard Hurteau sans qui cette idée de robot
joueur de soccer n’aurait jamais vu le jour à l’École Polytechnique de Montréal. Ses
indications sur l’évolution du projet et sur les besoins des autres membres du groupe
m’ont été très utiles pour orienter mon travail selon les besoins futurs de l’équipe.
J’aimerais également remercier M. Richard Gourdeau pour avoir accepter de superviser
mon travail et pour avoir mis en place un serveur CVS.
L’aide de Julien Beaudry a aussi été très importante pour ce projet puisqu’il a su répondre
à mes questions et son expérience dans le contrôle de robot rouleur fut très appréciée. Je
n’oserais point passer sous le silence l’excellent travail de Richard Grenier et Marie-Lyne
Brisson qui m’ont grandement simplifié la tâche du côté technique.
Je tiens aussi à remercier l’équipe de SAE Robotique pour toutes les heures où j’ai pu
approfondir mes connaissances qui sont maintenant appliquées dans ce projet. Plus
particulièrement Rémi Lefebvre qui a fait par le passé une plate-forme de contrôle d’un
robot rouleur et aussi, par ses réponses à mes questions. Et finalement, je tiens à
remercier ma copine, Isabelle Cyrenne, qui a su être compréhensive durant mes longues
soirées passées sur ce travail.
V
Liste des tableaux
Tableau 5.1 : Description des modules de SpinoS ...............................................................17
Tableau 5.2 : Liste des étapes pour le déplacement en position..........................................23
VI
Listes des figures
Figure 5.1 : Structure d’un 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 périphériques à la structure logicielle ................................................27
VII
Listes des symboles et abréviations
QNXRTP Système d’exploitation provenant de la compagnie QNX
Superutilisateur L’administrateur du système soit l’usager root
PGE Projet de génie électrique PWM Pulse Witdh Modulation SE Système d’exploitation CVS Concurrent Versions System
1
1 Introduction Le domaine de la robotique est en constante évolution. Les percées technologiques faites
durant les dernières années rendent accessible des applications robotisées qui étaient jadis
impossible à imaginer. Les performances des ordinateurs, les dispositifs de localisation à
haute précision, le traitement d’image numérique sont d’autant d’exemples qui repoussent
les barrières de la robotique.
Le présent travail abordera un domaine de la robotique en plein essor. Un groupe de
l’école Polytechnique de Montréal travaille présentement sur l’élaboration d’un projet
offrant la possibilité aux étudiants de génie électrique de manipuler une équipe de trois
robots joueurs de soccer. Ce projet se base en grande partie sur les spécifications
indiquées lors de la compétition RoboCup (http://www.robocup.org/).
Le travail fait dans ce rapport se veut la conception d’une architecture informatique pour
ces robots afin de répondre aux besoins actuels de l’équipe.
2
2 Problématique
Cette section énumère les principaux points selon lesquels le présent travail a pris forme.
Puisque le premier but demandé était de répondre aux besoins des différents membres de
l’équipe, il était nécessaire lors du début du projet de les définir adéquatement dans le but
d’assurer une évolution du projet. Ainsi, les différents points abordés dans cette section
permettront de mieux comprendre les besoins de l’équipe et la situation actuelle du
projet.
2.1 Matériel de développement Au moment de l’écriture de ces lignes, l’équipe de développement avait un prototype
mécanique ainsi qu’un ordinateur industriel à son bord. Ceci permettait donc de
développer une structure informatique tout en ayant la possibilité de la tester sur ce
prototype.
2.2 Système d’exploitation Par les expériences passées, les membres de l’équipe ont acquis une expérience
importante face au système d’exploitation QNX (http://www.qnx.com). La nouvelle
version de ce dernier, soit QNXRTP, jouit maintenant d’une réputation importante dans
le domaine des applications temps réel. De plus, cette plate-forme de développement
supporte maintenant le standard POSIX qui rend le développement beaucoup plus facile
pour les programmeurs comparativement aux précédentes versions de QNX.
3
Lors du début du présent travail, l’équipe voulait se consacrer uniquement à ce système
d’exploitation. Cependant, il existait des contraintes au niveau matériel qui rendait cette
alternative plus ou moins certaine. Notamment, le capteur d’image vidéo semblait créer
un problème puisque la compatibilité avec QNXRTP n’était pas assurée. Il fut cependant
décidé que le présent travail serait entièrement effectué sur QNXRTP mais qu’il était
impératif d’assurer une transition simple, s’il y a lieu, vers un système d’exploitation
comme Linux.
Pour ce qui est du langage de programmation, pour plusieurs raison, le C/C++ a été
choisit car il est très bien connu des membres de l’équipe. Aussi, ce langage est très bien
supporté par le SE QNXRTP et il a fait ses preuves dans le domaine de la robotique. Et
finalement, puisque c’est le langage principalement enseigné à l’École Polytechnique de
Montréal, il était évident que pour assurer une relève compétente au projet, ce choix
devait être fait.
2.3 Périphériques Pour rendre le robot capable de se déplacer et d’interagir avec l’environnement qui
l’entoure, il faut évidemment avoir recourt à d’autres composantes électroniques. Un
membre de l’équipe travail déjà dans ce sens et tente de trouver les cartes pouvant offrir
d’excellentes performances au robot.
4
L’achat de deux cartes de contrôle différentes a déjà été fait. Ceci dans le but d’évaluer
les performances de chacune et ensuite de procéder à l’achat des cartes manquantes selon
le résultat obtenu. Ces cartes sont le lien direct entre l’ordinateur et les moteurs et
permettent ainsi d’envoyer un signal PWM au moteur selon la commande désirée. Les
avantages de telles cartes c’est qu’elles utilisent un contrôleur PID interne qui en boucle
fermée, assure la validité des commandes désirées et qui réduit considérablement le
temps de calcul qui serait nécessaire par le CPU de l’ordinateur.
Par contre, le seul désavantage repose sur le fait qu’aucun pilote n’existe sous QNXRTP.
Donc, pour assurer la suite du projet, il est clair que cette partie a du être effectuée en
premier.
D’autres périphériques vont être appelés à être intégré dans le futur au projet mais le
présent travail ne s’attardera qu’à l’étude des deux cartes présentées.
2.4 Logiciel de contrôle Un autre point important présentement requis par l’équipe du projet est une base
logicielle pour les développements futurs. Comme il a été expliqué auparavant, la plate-
forme du robot en question provient du robot SpinoS développé par des étudiants. Donc,
une structure informatique a été implantée sous RT-Linux. Cependant, selon une
première analyse faite, il était clair que les différences entre QNXRTP et RT-Linux
imposent une modification importante de la structure informatique. Aussi, puisque les
fonctionnalités requises par un robot suiveur de ligne comme SpinoS, et un pour un robot
5
joueur de soccer étant bien différentes, plusieurs modifications sur le logiciel devaient
êtes faites.
Pour bien comprendre les requis de cette structure logicielle, il faut se pencher sur la
compétition RoboCup. Cette dernière est une compétition a laquelle une équipe de 6
robots doivent se déplacer sur le terrain de façon autonome. Il est intéressant d’observer
les réactions des joueurs de soccer réels pour essayer d’intégrer une démarche similaire
aux robots sur le terrain. Donc, un robot pourrait être appelé à ce déplacer à un point
précis du terrain pour qu’il attende que le jeu se déplace dans sa direction. Mais aussi, il
pourrait être intéressant d’avoir une commande qui indique au robot d’avancer à une
vitesse fixe comme dans le cas d’une passe vers un jouer déjà en déplacement. Même
chose pour le gardien avec qui, il pourrait être intéressant de suivre le déplacement du
ballon selon une trajectoire en vitesse. Donc, la structure informatique devra être en
mesure d’offrir ces deux types de déplacement au robot.
Un autre point important qu’il faut mentionner est que ces robots pourront être appelés à
être utilisé par des étudiants dans des cours. On sait évidemment que l’origine de ce
développement est pour le cours de « Projet de Génie Électrique », mais il a aussi été
question d’une utilisation pédagogique dans d’autres cours. Donc, la structure logicielle
doit être assez modulaire et complète pour qu’il soit facile de l’utiliser dans plusieurs
circonstances différentes et que le temps de transition entre les différentes situations soit
minime.
6
2.5 Outils de développement Pour assurer une efficacité et une sécurité dans les versions du code source développé
pendant les 4 mois de ce projet, l’auteur 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 défaut.
L’utilisation d’un outil de développement comme le logiciel Together
(http://www.togethersoft.com/) est ici approprié. D’un côté, il permet de construire
rapidement une structure orientée objet à partir d’un diagramme de classe généré selon le
modèle UML. Aussi, il permet de générer une documentation complète pour le projet
selon les commentaires indiqués dans le code source, ce qui sera évidemment très utile
pour les prochains programmeurs sur le projet.
3 Pilotes des cartes de contrôles Dans cette section, il sera question de l’implantation des pilotes pour les deux cartes de
contrôle tel que discuté auparavant. On retrouve donc, dans l’ordre le pilote pour la carte
de la compagnie ACS Tech80 ainsi que de celle de la compagnie AJECO. Et sera ensuite
pertinent de décrire les performances observées dans le but que l’équipe puisse prendre
une décision sur la carte qu’il serait préférable d’utiliser pour la suite du projet.
7
Pour permettre l’utilisation de périphérique dans des applications écrites en C/C++ sous
un système d’exploitation comme QNXRTP, il existe deux moyens différents. Le
premier étant de lier le pilote et l’application par l’éditeur de liens lors de la compilation.
Cette méthode peut s’avérer excellente dans plusieurs cas mais implique un problème de
sécurité sous QNXRTP. En effet, les pilotes développés dans ce présent travail doivent
avoir accès en écriture et en lecture à l’espace d’adresse de la carte. Par exemple, les
fonctions in(0x300) et out(0x300) suivantes du langage de programmation C permettent
d’écrire et de lire la valeur contenue à l’adresse hexadécimale 0x300. Cependant, seul le
superutilisateur du système peut utiliser ces fonctions comme il est mentionné dans la
documentation Internet de QNXRTP. Ceci implique un problème pour l’utilisation future
des robots dans le cadre du cours de PGE. Puisque les étudiants vont avoir un accès au
robot, il est préférable de leur donner des accès contrôlés dans le but d’assurer la sécurité
de l’installation ainsi que d’une protection sur leurs données.
La deuxième option est prise en charge directement par le SE. Il s’agit en fait du
gestionnaire de périphérique (device drivers) qui permet d’enregistrer une application et
la rendre accessible à partir d’un fichier contenu dans le répertoire « /dev » du SE. Donc,
une application écrite en C/C++ peut alors ouvrir ce fichier et envoyer différentes
commandes permises à la carte. Cette option a un attrait important puisque le problème
d’accès superutilisateur est alors inexistant. Cependant, cette option peut insérer des
délais minimes dans la communication entre le gestionnaire de périphérique et
l’application de l’utilisateur. Il est toutefois possible de croire que ces délais
n’influenceront pas les performances du robot.
8
Bref, pour les besoins du cours de Projet de Génie Électrique, la décision a été prise de
fournir un pilote se basant sur le gestionnaire de périphérique de QNXRTP pour les deux
cartes de contrôles décrites. Donc, tout dépendamment de la carte présente sur le robot,
une application peut ouvrir le fichier « /dev/ctrl » et envoyer les commandes désirées.
Nous verrons donc dans les prochaines sections les choix ayant été fait face à
l’implantation de ces deux pilotes.
3.1 Pilote ACS
3.1.1 Description La carte de contrôle de la compagnie ACS-Tech80 utilisée est le model 5950B en format
PC/104. Elle permet de contrôler 4 axes (moteur à courant continu) simultanément. Deux
modes permettent soit de fonctionner en boucle ouverte ou bien, avec le retour
d’encodeurs, en mode fermé. Ce dernier mode permet de plus d’envoyer 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 compréhension de cette dernière est primordiale pour réussir à
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 fonctionnalités de
9
la carte d’ACS était en fait exactement celle de la puce MC1401A sauf à quelques petites
différences dont par exemple, la possibilité d’utiliser un encodeur en mode différentiel.
La puce de contrôle était bien connue de l’auteur puisqu’elle est utilisée par les membres
de SAE Robotique depuis plusieurs années. Il a été fait par le passé un pilote de contrôle
pour la carte sous Linux permettant la communication entre la puce et l’ordinateur. Les
différences existantes entre la carte de ACS-Tech80 et celle de SAE Robotique ont été
évaluées et il a été possible de conclure que toutes les fonctions supportées par la puce
MC1401A étaient incluses dans ce pilote sous Linux. Le choix d’implantation s’est donc
tourné vers la réutilisation du code ouvert de SAE Robotique dans le but de le rendre
fonctionnel sous QNXRTP.
Autre point important est celui d’une vérification logicielle de la présence de la carte
avant d’envoyer des informations sur la plage d’adresse. La carte de ACS-Tech80
contient l’adresse (base+0x10) du bus de données un caractère équivalent à la lettre T
(0x54). Donc, lors du lancement du pilote de contrôle, il serait possible d’aller lire cette
valeur et de prouver qu’il existe bien une carte ACS-Tech80 de modèle 5950B à cette
adresse de base. Cette vérification peut s’avérer importante puisque deux modèles
différents de cartes de contrôle peut se retrouver sur l’ordinateur.
10
3.2 Pilote AJECO
3.2.1 Description Cette carte de contrôle, modèle ANDI-SERVO de la compagnie AJECO
(http://www.ajeco.fi), permet l’utilisation de deux moteurs à courant continu en boucle
fermée. Elle se base sur l’utilisation de la puce LM629 de la compagnie National
Semicondutor. Tout comme la carte de ACS-Tech80, deux modes de contrôle en boucle
fermée 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 d’éviter de refaire le travail déjà fait et puisqu’il est possible d’utiliser ce
code source ouvert, il a facilement été possible de modifier le code pour le rendre
fonctionnel sous QNXRTP et d’en vérifier les fonctionnalités et les performances de la
carte. Pour ce faire, les fichiers sdrv.h et sdrv.c ont été testés par l’exécutable demo.c
inclus sur le disque compact fourni. Il a donc été observé qu’il était possible d’utiliser
cette librairie de AJECO sous QNXRTP. Par contre, comme il a été mentionné
auparavant, il est risqué d’utiliser cette forme d’implantation puisque l’exécution des
exécutables doit nécessairement se faire avec les accès du superutilisateur. Donc, selon
les tests exécutés, il était possible et essentiel de faire une interface à cette librairie pour
en permettre l’accès à partir du gestionnaire de périphérique du SE.
11
4 Résultats pour les pilotes
Les pilotes pour les deux cartes ont été faits avec succès. Voici dont les particularités du
travail fait
4.1 Pilote pour la carte ACS-Tech80 Le fichier acs_qnx.h contient toutes les macros qui doivent être nécessairement utilisées
par QNXRTP afin d’utiliser d’enregistrer cette application sur le gestionnaire de
périphérique. Ces macros indique la liste des commandes pouvant être envoyés à la carte
par des accès selon la commande devctl() de QNXRTP.
Comme il a été mentionné, le pilote implanté dans ce présent travail provient en partir de
celui utilisé sous Linux par les membres de SAE Robotique. Les modifications apportées
à ce pilote pour le rendre fonctionnel sous QNXRTP furent mineures. Cependant,
l’intégration sous QNXRTP s’est avérée plus longue que prévu car le gestionnaire de
périphérique est une nouvelle fonctionnalité du SE et la documentation et les exemples
disponibles n’étaient pas très 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 supportées par le
pilote sont toutes celles utilisées par le microprocesseur PMD.
- Les interruptions n’ont pas été enregistrées sur le gestionnaire de périphérique
puisqu’il n’a pas été jugé essentielle de les utiliser dans la structure informatique.
12
4.2 Pilote pour la carte AJECO Le fichier dev_ajeco.h contenu sur le disque compact dans le répertoire « pilotes/ajeco »
contient les différentes commandes qu’il est possible d’utiliser avec la fonction dev_ctl()
de QNXRTP. C’est commande sont aussi décrites dans la documentation provenant avec
la carte. Comme il a été mentionné, ce pilote offre une interface aux différentes fonctions
incluses dans la librairie « sdrv.c » et « sdrc.h » d’AJECO.
4.3 Utilisation des pilotes
4.3.1 Messages d’erreurs Les messages d’information pertinents et tous les messages d’erreurs rencontrées par le
module sont envoyés dans l’application syslog. Pour les voir, il suffit faire la commande
sloginfo sur un terminal.
4.3.2 Activation et désactivation des pilotes La liste suivante énonce les différentes commandes pour activer les pilotes des cartes.
- Aller dans le répertoire contenant l’exécutable du module (cd ~pilotes/acs/ ou
bien ~pilotes/ajeco/)
- Compiler le module (make)
- Exécuter le module (./module_acs & ou bien ./dev_ajeco &) en mode
superutilisateur (commande « su »)
13
4.4 Désactivation des pilotes
- Trouver le numéro 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 d’essais effectués par un membre de l’équipe, il fut observé que la carte ACS
répondait à des requêtes à des vitesses relativement lentes, soit au minimum 1 ms par
requêtes. Dans le but de valider cette affirmation, des essais ont été faits sur la carte
AJECO et les performances obtenues ont été largement supérieures puisque qu’en temps
d’environ 350 us a été observé par requêtes.
14
5 Logiciel de contrôle
Maintenant que les deux pilotes des cartes de contrôle sont fonctionnels, il est maintenant
possible de concevoir une structure logicielle qui permettra au robot de se déplacer, de
penser et d’interagir avec son environnement.
Les besoins de l’équipe ont été discutés dans la section 2.4. Il est pertinent ici d’en faire
la liste et d’ajouter au besoin d’autres points selon le travail qui a été effectué jusqu’à
présent. Donc, il serait important d’intégrer les fonctionnalités suivantes à la structure
informatique :
• Offrir un système versatile peut importe la carte de contrôle utilisée.
• Offrir la possibilité de changer les modes de fonctionnement du robot. Donc,
passer en mode d’asservissement en vitesse ou bien en position quand on le
désire.
• Offrir un moyen de changer le module de prise de décision du robot facilement.
• Permettre aux futurs programmeurs d’ajouter des périphériques de façon
transparente à la structure logicielle.
Par cette section, une structure logicielle orientée objet sera mise en place dans le but de
répondre à la liste des besoins ci-dessus. Une évaluation de la structure informatique de
SpinoS sera en premier lieu effectué ce qui permettra d’en observer les forces et faiblesse
face aux besoins de ce travail. Par la suite, les différentes décisions prises seront
expliquées.
15
5.1 Architecture informatique de SpinoS
La structure informatique implantée sur le robot rouleur SpinoS est directement liée aux
contraintes de temps réels requis par l’équipe. RT-Linux permet d’atteindre des
performances acceptables de temps réel sur le noyau existant de Linux. Mais pour ce
faire, il faut que l’application temps réel soit intégrée sous la forme de module interne du
noyau, soit du côté que l’on surnomme « kernel space ». La figure suivante, tirée du site
Internet de QNX, explique bien cette particularité. On remarque aussi que les
applications normales qui n’ont pas de contraintes temps réel sont situées du côté « user
space ».
Figure 5.1 : Structure d’un SE comme LINUX (http://www.qnx.com)
La figure ci-dessous montre qu’il a donc du être nécessaire d’inclure un processus de
communication entre les deux niveaux. Cette particularité est présentée par la présence
de trois « tubes de communication » permettant l’échanger les informations pertinentes.
Figure 5.2 : Structure informatique de SpinoS sous RT-Linux[1]
16
Il est important de préciser la raison pour laquelle les deux parties du logiciel ont du être
séparée. En effet, pourquoi l’application spinosd n’a-t-elle pas été incorporée dans la
partie temps réel ? Ce choix de conception fait à cette époque pour le robot SpinoS
impliquait la nécessité de séparer les deux parties pour des raisons bien simples. La
principale raison étant de minimiser le temps de calcul du côté kernel space. N’ayant pas
agit de la sorte, des risques importants sur la stabilité du SE aurait pu survenir sur la
protection de la mémoire[2].
Pour ce qui est de QNXRTP, la structure du noyau est légèrement différente 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 situées dans le même espace
mémoire mais que toutes les requêtes passent par le « microkernel ». Bref, il est possible
d’obtenir d’excellentes performances temps réel avec une simple application situé dans le
« user space ». Donc, il n’est plus essentiel d’utiliser le processus de communication
entre la partie de calcul et la partie temps réel.
Les différents modules de la figure 5.2 de l’application spinosd ont aussi une importance
dans notre raisonnement. Le tableau 5.1 de la page suivante explique chacune des
parties.
17
Module Fonction
Controller Envoie les commandes du côté temps réel.
Position Détermine la position actuelle du robot selon la lecture
d’encodeur.
Trajectory Permet de déplacer le robot selon une séquence de points (x, y).
Brain Prend les décisions selon l’algorithme implanté.
Strip Module permettant de faire la lecture des données provenant d’un
capteur de ligne. Inutile pour le cas de robot joueur de soccer
Tableau 5.1 : Description des modules de SpinoS
L’ensemble 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 s’inspirant fortement de la structure informatique de SpinoS, le résultat de la figure
suivante est proposé et sera évalué.
Figure 5.4 : Structure de base du logiciel
18
Donc, une légère modification sur le diagramme de classe a été apportée dans cette
structure comparativement à la structure de SpinoS. Évidemment, les processus de
communications sont maintenant inexistants et la classe « Controller » s’occupe
d’envoyer les informations directement à la carte de contrôle. Cette dernière est
accessible, comme nous l’avons vu précédemment par le fichier « /dev/ctrl » et par les
fonctions de devctl() appropriées. La classe « Position » détermine 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 accéder à la classe
« Position » afin d’avoir les éléments essentiels pour prendre une décision.
5.2.2 Intégration des cartes de contrôle Le but recherché par cet objet est de pouvoir intégrer facilement les deux cartes de
contrôle présentement utilisées sur le projet. Donc, une solution intéressante est d’utiliser
le polymorphisme à partir d’une classe de base commune aux deux cartes de contrôle. La
figure suivante illustre ce principe.
19
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 héritant de « Controller » doivent nécessairement redéfinir les fonctions
virtuelles pures ce qui permet donc, dans la situation actuelle, d’avoir les différents
envois de commandes aux cartes ACS et AJECO redéfinis et propres à chacune des
cartes. Pour cette raison, la fonction stop() qui est virtuelle pure dans la classe
« Controller » est présente dans toutes les classes dérivées. D’un autre côté, pour éviter
la redondance de code et les inconvénients s’y rattachant, des fonctions communes aux
trois classes sont directement déclarées dans la classe de base. Par exemple, la fonction
get_pos() n’est définie que dans la classe de base ce qui évite de copier trois fois le code
correspondant dans les classes dérivées.
Autre point intéressant est la présence de la classe « Controller_virtual ». Comme son
nom l’indique, cette classe permet de simuler une carte de contrôle. Donc, il est ainsi
possible de faire exécuter le programme même si aucune carte de contrôle est présente
sur l’ordinateur.
20
Maintenant, pour offrir un système versatile, il faut maintenant être en mesure de pouvoir
créer la classe appropriée de façon simple et transparente. Pour ce faire, le patron de
conception « Factory method »[3] s’applique très bien à ce genre de problème. Ce
constructeur virtuel offre une interface qui permet de créer une classe selon l’interface de
son parent. La figure suivante illustre ce principe.
Figure 5.6 : Diagramme de classe de « Creator »
Et pour mieux comprendre l’utilité, un exemple de code pour la fonction
create_controller() est présenté.
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") {
21
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() reçoit en paramètre un identificateur. Ce dernier est
ensuite comparé dans la série de « if » et s’il y a réussite, la classe dérivée de
« Controller » est alors créée.
Aussi, dans le but d’offrir aux autres classes l’accès à ce contrôleur tout au long de
l’exécution du programme, l’ajout du patron « Singleton »8 dans la classe Creator a été
implantée. Ceci permet de conserver qu’une seule instance de la classe « Creator » tout
au long de l’exécution du programme. Et comme il est possible de le remarquer, le
constructeur est privé ce qui fait qu’il est impossible pour les objets extérieurs d’accéder
au constructeur. Pour obtenir une instance à cette classe, il faut alors faire appel à la
fonction statique Instance() qui elle peut avoir accès au constructeur privé Creator() si
aucune instance existe. Dans le cas contraire, l’instance courante est retournée.
5.2.3 Position du robot À partir de la valeur de chacun des encodeurs, il est possible de démontrer
mathématiquement que nous pouvons obtenir la position du robot et plusieurs autres
paramètres utiles comme la position x et y ainsi que l’orientation. Il ne sera pas question
22
ici de la démonstration complète de la détermination de ces paramètres car M. Beaudry a
effectué ce travail dans son projet de fin d’étude[1].
5.2.4 Prise de décision Le module de prise de décision se veut être le cerveau du robot. Aussi, comme spécifié
dans les besoins de l’équipe, la possibilité d’avoir plusieurs cerveaux différents et de
pouvoir décider dynamiquement lors l’exécution du programme serait très utile. Le
polymorphisme utilisé dans le cas de la classe « Controller » peut très bien s’appliquer ici
et vient répondre aux besoins initiaux de l’équipe. Et par l’utilisation de la classe
« Creator », il est encore possible de faire une fonction create_brain() dans laquelle un
identificateur est passé par paramètre et permet de créer l’instance désirée de façon
dynamique.
5.2.5 Mouvement du robot
Une des contraintes imposée par les membres de l’équipe est la possibilité de changer de
mode de déplacement en cours de partie. Par exemple, un défenseur pourrait préférer se
diriger à un point (x,y) alors que dans un autre cas, il pourrait préférer poursuivre un
adversaire selon une vitesse quelconque. Pour le déplacement en position, il devrait être
possible d’indiquer le point désiré mais aussi l’orientation finale du robot pour que ce
dernier ait par exemple, une prise de vue pertinente à partir de sa caméra intégrée.
23
La possibilité de changer de mode requiert un suivi des commandes précédentes
provenant du cerveau. Car dans le cas ou la dernière commande ait été selon une
commande en vitesse et que la commande actuelle soit une commande en position, alors
on doit être en mesure d’effectuer le changement de mode correctement et de façon
transparente. Pour ce faire, une simple méthode de résolution est d’ajuster en premier
lieu l’orientation du robot pour qu’il atteigne la position (x, y) demandé. Ensuite, le
déplacement en ligne droite est effectué. Et finalement, l’orientation précisée par thêta
est envoyée au robot. Le tableau suivant résume ces commandes.
Étapes Commandes
1 Orienter le robot vers le point (x,y) en le faisant tourner autour de son centre.
2 Déplacer le robot vers le point (x,y)
3 Orienter le robot selon le thêta désiré
Tableau 5.2 : Liste des étapes pour le déplacement en position
Bien qu’elle soit simple, cette méthode implique un problème de conception. Le temps
pour déplacer le robot vers une orientation selon x,y, le temps de déplacement et ensuite
l’orientation finale implique trois mouvement différents. Il existe un moyen sur les deux
cartes de contrôle de spécifier un mouvement suivant lorsque le premier est atteint (c.-à-
d. par des « breakpoints »). Le problème avec cette façon d’utiliser la carte est qu’un
déplacement en position peut prendre par exemple quelques secondes tandis que le
cerveau du robot pourrait alors changer d’idée et demander le déplacement vers une autre
24
position. Alors il doit y exister un moyen de faire en sorte qu’un changement de
commande soit interprété immédiatement par la structure informatique et non une fois
que le déplacement courant est terminé.
Pour ce qui est de l’asservissement en vitesse, ce genre de contrainte ne se pose pas
puisque la commande en vitesse est envoyée une seule fois à la carte et ce, sans causer de
délai.
5.3 Opérations devant être faites périodiquement
L’utilisation de QNXRTP permet d’atteindre d’excellentes performances temps réel.
Donc, pour la structure logicielle précédemment proposée, et selon ce qu’il avait été fait
avec le robot SpinoS, il nous est possible d’utiliser des moyens du SE afin de rendre de
façon périodique certains appels. Les quatre classes principales comportent toutes une
fonction update() qui permet de mettre à jour les différents attributs de la classe et
défectuer des vérifications de routine. Pour « Position », chaque paramètre sur le robot
est mis à jour. Pour « Movement », la vérification à savoir si une nouvelle commande a
été demandé et à savoir si la position désirée est atteinte pour un asservissement en
position est vérifiée. Et finalement, la classe « Brain » pourrait-elle aussi être appelée de
façon périodique afin que la prise de décision soit faite de façon périodique.
Les avantages de l’utilisation d’appel périodique sont importants. En effectuant des
appels périodiques sur la classe « Position » on diminue le bruit présent lors de la dérivée
calculée. Aussi, il est attrayant de simuler au préalablement le comportement du robot
25
dans un logiciel comme Matlab. Donc, en assurant une période fixe dans la prise de
décision, la simulation est alors beaucoup plus près de la réalité.
6 Résultats
La structure informatique de base a été implantée et le code source est disponible sur le
disque compact. Cependant, par manque de temps, la structure complète n’a pu être
complété entièrement. En fait, il sera possible d’observer que plusieurs fonctions ne sont
pas complètes. La présente section a donc pour but d’expliquer le travail qui a été fait
ainsi que les tests effectués.
6.1 Les cartes de contrôle Les deux classes faisant le lien avec les cartes de contrôle, soit « Controller_acs » ainsi
que « Controller_ajeco » permettent de communiquer avec ces dernières. Il a été
démontré par des essais concluants que la communication avec les cartes était
fonctionnelle. Il reste néanmoins à compléter les différents envois en position ainsi que
le changement de mode.
Aussi, il a été possible d’expérimenter que la construction dynamique effectuée à l’aide
de la classe « Creator » était entièrement fonctionnelle et répondait exactement aux
objectifs de l’équipe soit de permettre l’utilisation des deux cartes de contrôle sur la
structure informatique de façon transparente et avec un temps minimal de transition. En
fait, il n’y a qu’à changer l’identificateur présent lors de la création de l’instance vers la
classe « Controller » pour changer l’envoie aux différentes cartes.
26
6.2 Positionnement La classe « Position » est complète et les essais qui ont été effectués avec les deux cartes
de contrôle ont permis d’observer que la position, l’orientation et la vitesse retourné
étaient fonctionnels.
6.3 Cerveau L’algorithme de décision ne faisant pas parti de ce travail, le lecteur trouvera dans le
fichier Brain1.cc dans la fonction update() une prise de décision assez simple. Par contre,
il a été possible à partir de cette dernière de faire les différents 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 décision.
Aussi, la même particularité de l’instance vers la carte de contrôle a été testée.
Effectivement, il est possible de spécifier à partir d’un identificateur passé à la fonction
create_brain() du fichier pge.cc, le nom du cerveau que l’on désire utiliser. Donc, cette
structure répond encre une fois aux besoins de l’équipe d’avoir la possibilité de changer
le cerveau du robot de façon simple et rapide.
6.4 Mouvement La classe « Movement » est actuelle fonctionnelle qu’en un mode d’asservissement en
vitesse. Mais la structure de l’algorithme pour régler le problème présenté à la section
5.2.4 est suggérée dans le corps de la fonction update() et plusieurs commentaires
présents dans le code sauront rendre l’implémentation simple aux prichains
programmeurs de l’équipe.
27
7 Discussions
Cette section propose les différents points importants afin d’assurer l’évolution du projet
informatique pour les futurs programmeurs. Bien entendu, cette section n’est qu’à titre
indicatif mais elle donne un compte rendu réaliste du travail restant afin d’obtenir des
vrais joueurs de soccer!
7.1 L’ajout de périphérique
Pour l’ajout d’un périphérique quelconque, la création d’une classe pour les accès à ce
dernier est conseillée. La figure ci-desous montre un exemple où la classe
« Brain_camera » requiert l’accès à une caméra. D’un autre côté, on peut remarquer que
la classe « Brain_aveugle » ne se préoccupe pas de l’existence de la caméra.
Figure 7.1 : Ajout de périphériques à la structure logicielle
28
7.2 L’ajout d’une autre carte de contrôle ou d’un cerveau
Selon l’avancement du projet, les membres de l’équipe pourraient vouloir acheter une
autre carte dont il n’a pas été question dans ce document. Aussi, l’intégration d’un
cerveau pourrait aussi être effectuée. Les étapes indiquées si dessous permettront de
faciliter l’intégration de cette carte et du cerveau au reste de la structure.
• Il faut construire la classe dérivée de la classe de base soit « Controller » pour une
carte de contrôle 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 l’objet de façon dynamique
lors de l’exécution comme mentionné dans la section 5.2.1.
• Et finalement, il faut ajouter une référence au fichier nouvellement créé de la
nouvelle classe dans la liste des objets du « Makefile ».
7.3 Portabilité
Comme il avait été spécifié au début de ce projet, la portabilité du code vers un SE
comme Linux devait être assurée de façon simple. Le résultat obtenu permet
présentement de compiler le code sur Linux mais une partie importante de la structure
n’est pas prise en charge lors de la compilation, soit les accès aux cartes de contrôle. En
effet, les classes « Controller_acs » et « Controller_ajeco » n’ont été implanté que pour
des fonctions dédiées de QNXRTP. Donc, si un jour la décision est prise d’utiliser
Linux, les accès aux cartes de contrôles devront être modifiés ainsi que les pilotes de ces
cartes.
29
7.4 Recommandations
La liste suivante propose des points qu’il serait intéressant d’ajouter au logiciel afin de le
rendre encore plus flexible.
• Sélection des classes à utiliser à partir de la ligne de commande : il serait très
intéressant 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 l’on désire utiliser la classe « Brain_camera » ce qui
permettrait de ne pas avoir besoin de recompiler le code.
• Paramètres du robot contenus dans un fichier de configuration : Un fichier texte
pourrait contenir des paramètres succeptible de changer fréquemment. Par
exemple, les gains Kp, Kd et Ki pourraient alors être modifié sans avoir à
recompiler le code.
• Fichier de sortie : Avoir la possibilité d’enregistrer dans un fichier, lors de
l’exécution du programme, des informations pertinentes. Par exemple, les
informations sur la position des deux encodeurs et le temps associé pourrait être
sauvegardé pour qu’il puisse être possible de traiter ces informations dans un
logiciel comme Matlab.
• Implanter une interface graphique : La structure logicielle du code pourrait
facilement intégrer une interface modulaire de visualisation de différents
paramètres et états du robot. Cette particularité pourrait être très utile pour le
débogage et la mise au point de la configuration du robot. De plus, cette dernière
pourrait être utilisée dans certains cours pour des méthodes d’apprentissage.
• Utiliser un script pour démarrer les pilotes des cartes de contrôle: Puisque les
étudiants n’auront pas accès aux droits du superutilisateur, il serait nécessaire de
créer un script démarrant le pilote soit au démarrage de l’ordinateur ou bien par
l’étudiant lui même.
30
8 Conclusion Ce document est le résultat de plusieurs heures de travail. D’un côté, l’intégration des
pilotes des deux cartes de contrôle utilisées a été effectuée avec succès. Mais cette partie
du travail a nécessité plus de temps que prévu initialement car QNXRTP étant un SE
assez récent, la documentation sur le sujet est relativement rare. D’un autre côté, le
travail a porté sur une architecture logicielle orientée objet pour le contrôle d’un robot
jouer de soccer. Bien que cette partie n’ait été implantée qu’en partie, il demeure pas
moins que la structure de base est fonctionnelle et que les différents tests faits ont
démontré le respect des objectifs initiaux. Et finalement, les indications incluses dans ce
présent document et les informations laissées dans le code source sauront assurer la suite
du projet.
Ce projet de fin d’étude comporte plusieurs points dont l’auteur a fait l’apprentissage
durant ces quatre dernières années à l’école polytechnique de Montréal. Il est clair aussi
que ce projet fait aussi parti d’un domaine qui intéresse grandement l’auteur. Pour toutes
ces raisons, l’exécution de ce travail s’est avéré une excellente expérience.
31
9 Bibliographie
[1] BEAUDRY, Julien, Projet SpinoS: Conception et contrôle d’un robot mobile à vitesses différentielles -- Projet de fin d’étude, Montréal, École Polytechnique de Montréal, 2001. [2] RUBINI, Alessandro, CORBET, Jonathan, LINUX device drivers, USA, O’Reilly & 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, O’Reilly & Associates, 1995. DEITEL et DEITEL, Comment programmer en C++, Canada, Les éditions Reynald Goulet inc., 200.
32
Annexe 1 Liste des fichiers inclus sur le disque compact fournis avec ce rapport Documentation
è ACS: Contient les manuels d’utilisations et les références à la puce de PMD Corp
è AJECO: Contient les manuels d’utilisations et les références à la puce LM629 de National Semiconductor
è QNX : Contient la page Internet complète sur les indications pour le gestionnaire de périphérique de QNXRTP
Pge : Contient le code source complet de la structure informatique Pilotes
è ACS : Contient le code source pour le pilote de la carte d’ACS è AJECO : Contient le code source pour le pilote de la carte d’AJECO