É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