Rapport Préliminaire
1-) Introduction
1.1 Analyse du projet
Notre analyse du projet nous a mené à le diviser en différents sous-systèmes matériels et logiciels. La division initiale a été un peu réajustée, en particulier au niveau logiciel. Ces divisions sont détaillées plus loin dans ce rapport.
Du côté des facteurs de risque nous les avons résolu pour l'essentiel, bien
que leur implantation effective ne soit pas terminé -nous ne pouvons crier
victoire mais nous retenons notre souffle.
Au plan logiciel il s'agissait de la communication ordinateur-robot, du
calcul de position et de l'asservissement réel du robot. La communication
est réglé entièrement, les équations du calcul de position sont établies.
Quant à l'asservissement réel du robot il faudra attendre les résultats de
l'intégration pour se prononcer. Nous n'entrevoyons pas de problème majeur.
Au plan matériel les risques identifiés étaient la programmation du FPGA
ainsi que la détection des impulsions sonores. La programmation du FPGA
passe maintenant l'étape de "synthèse".
1.2 Respect de l'Échéancier
Ce rapport est produit alors que nous sommes, d'après notre échéancier, à
la fin de notre période de développement et à la veille de leur
intégration. Nous avons le 14 novembre comme date butoir du développement
et le 20 novembre pour l'intégration.
Avec nos résultats courants nous sommes confiants de respecter l'échéancier
établi.
2-) Sous-Systèmes Matériels
2.1 Présentation
L'ensemble du système matériel pour réaliser le projet UBI a été
divisé en quatre sous-systèmes ayant chacun une fonction particulière.
Ces quatre sous-systèmes sont :
* Émission des impulsions sonores
* Réception des impulsions sonores
* Communication RF
* Alimentation
La
Figure 1 donne un aperçu de la position des différents sous-systèmes
dans l'ensemble matériel du projet UBI.
Les deux sous-systèmes d'émission et de réception d'impulsions sonores
sont utilisés pour le positionnement du robot. En effet, le premier se
charge d'envoyer des signaux sonores qui seront reconnus et captés par
le sous-système de réception. Ces informations seront par la suite envoyées
au PC via le lien de communication RF, et seront utilisées pour le calcul
de la position.
Le sous-système de communication se compose de deux paires d'émetteur et
de recepteur RF de façon à pour transmettre de l'information simultanément
dans les deux directions. Le système de communication est conçu pour
remplacer l'actuel câble de communication RS232 de façon complètement
transparente.
Le sous-système concernant l'alimentation comporte deux parties distinctes.
Tout d'abord, un circuit qui permet de lire la tension sur la batterie de
piles qui sert d'alimentation principale au robot. Aussi, on a un circuit
de régulation permettant d'obtenir des tensions régulées pour alimenter les
circuits qui vont être greffés au robot, soit la communication et la
réception d'impulsions.
2.2 Émission des Impulsions Sonores
Le but de ce sous-système est d'envoyer dans les amplificateurs de
puissance des séquences d'impulsions sonores qui seront reconnues par
le sous-système de réception. La description du type de signal qui va
être reconnu par le circuit de réception est décrit dans la section
concernant celui-ci. La
figure 2 illustre les principales composantes
de ce sous-système.
Tout d'abord, un circuit numérique, nommé Émission d'impulsions/Contrôle
de haut-parleurs (EI/CHP), va générer un signal correspondant à une
sinusoïde numérique. Le fait d'utiliser un circuit numérique pour générer
la sinusoïde nous permet d'obtenir notamment une fréquence et une durée
programmables. Ceci est utile dans les cas où l'on voudrait effectuer des
ajustement en fonction de l'environnement lors de la mise au point. Par
ailleurs, ce circuit va contrôler le multiplexeur analogique qui va
permettre de déterminer quel haut-parleur émet l'impulsion. Tout ce
circuit va être implanté dans un FPGA, et est développé conjointement
avec la compagnie Robo-Kup.
Après l'étage de génération du signal, un convertisseur
numérique-analogique convertit le signal en analogique de façon à être
amplifié et émis par un haut-parleur. Puis un filtre passe-bas sert de
filtre de reconstruction. Le multiplexeur analogique, contrôleur par le
circuit EI/CHP dirige le signal vers le bon amplificateur. Finalement,
un étage de protection assure l'intégrité de notre circuit, dans le cas
de surtensions venant de l'extérieur.
Actuellement, le design du circuit EI/CHP est réalisé par Éric Turenne
de la compagnie Robo-Kup, alors que Olivier Hébert de la compagnie CUBIC
s'occupe du circuit LDI/IM du sous-système de réception. Le codage du
circuit EI/CHP en VHDL est complété et on est actuellement en phase de
simulation fonctionnelle. Le tout sera par la suite implanté dans un
FPGA de marque Xilinx.
2.3 Réception des Impulsions Sonores
Ce sous-système sert à capter les impulsions sonores qui sont émises
par le sous-système d'émission. Les impulsions sont d'abord détectées
par un micro. Puis, un filtre passe-bande est utilisé pour éliminer les
fréquences qui ne correspondent pas à celle utilisée pour la transmission
de nos impulsions. Ensuite, un amplificateur est utilisé pour augmenter
l'intensité du signal à un niveau suffisant. Une bascule Schmitt est
utilisée pour reproduire un train d'impulsions carrées. Finalement, le
circuit LDI effectue son traitement. La
figure 3 illustre ce système.
Bloc de Réception des Impulsions Sonores
Filtrage du signal reçu
Pour augmenter le rapport du signal qui nous intéresse au bruit ambiant, nous plaçons
un filtre passe bande immédiatement après le micro, nous utilisons des résistances avec
les valeurs les plus faibles possibles, nous filtrons les alimentations
(47ohms, 0.1uF et 10uF).
Le filtre est du type Butterworth du troisième ordre, voici les calculs pour le filtre
passe bas et le filtre passe haut:
Amplification du signal reçu
Afin d'obtenir un signal d'amplitude constante, peu importe la distance de la source
d'émission, nous amplifions fortement le signal pour qu'il écrête, ensuite nous le
conditionnons avec un Schmitt trigger.
Compte rendu des tests effectués sur le sous-système matériel (analogique) de réception
des tics de positionnement:
Le 27 octobre, nous avons effectué des tests dans le local où sont installés les
haut-parleurs. Nous avons vérifié la réponse en fréquence des haut-parleurs.
Leur puissance maximale est à 3kHz. Cependant, nous pouvons obtenir un signal de
bonne puissance (1/2 de la puissance à 3kHz) pour des fréquences de 6, 9 et 10kHz.
Nous avons mesuré la durée de l'écho à 140 ms dans le pire des cas, il faudra donc
prendre 200 ms comme temps d'évanouissement de l'écho.
Le 28 octobre, nous avons monté et testé le filtre du 3ieme ordre pour une fréquence
de 3kHz. Les résultats ne sont pas bons. Le filtre atténue le signal de 3kHz de 12dB
ce qui n'est plus suffisant pour la suite.
Le 29, nous avons poursuivi sans le filtre. Nous avons monté et testé le circuit de Schmitt
trigger à la sortie de l'ampli. Ce circuit très simple fonctionne relativement bien.
Le 30, nous avons discuté avec le dépanneur de la possibilité de baisser les haut-parleurs,
nous sommes montés effectuer des tests avec notre montage et une caisse descendue au sol.
Cela améliore le signal reçu. Il nous a suggéré d'utiliser une fréquence plus élevée que
3kHz pour avoir une meilleure immunité aux bruits ambiants. Il conseille aussi d'utiliser
un filtre.
Nous avons donc consulté les autres équipes et on nous a conseillé un filtre à condensateurs
commutés du quatrième ordre, le MF8. Ce filtre permet même d'amplifier légèrement le
signal (2-3dB). Nous le testerons prochainement avec le reste du circuit.
Circuit LDI/IM
Le circuit LDI sert à détecter les impulsions valides et à emmagasiner
les temps auxquels le train d'impulsions a été détecté. Ces informations
sont ensuites transmises au 6811 par le circuit d'interface au
microcontrôleur.
Comme on peut le voir sur la
figure 4, le circuit LDI est composé de
5 éléments. On a tout d'abord le compteur principal (COUNT1) qui sert
d'horloge de référence pour marquer les temps de détection d'impulsions.
Cette horloge est la même pour toutes les entrées (dans le cas où l'on
aurait plus d'un micro). Ce compteur va être de 24 bits, ce qui nous
permet de compter jusqu'à 16 777 216. Comme on veut utiliser une
horloge à 1 MHz, le compteur ne va déborder qu'à toutes les 16 secondes,
ce qui nous permet d'éviter les problèmes de multiples débordements pour
une séquence d'impulsions. Le fait d'utiliser une horloge à 1 MHz va
facilitier les problèmes de faire le lien entre les compteurs et registres
et leur valeur temporelle. En effet, un coup d'horloge va correspondre à
une période d'une microseconde.
Puis viennent la machine à états qui fait la détection d'une impulsion
valide (PVSM). Cette machine à états signale une impulsion valide à la
machine à états qui s'assure de l'acquisition (ACQSM) des 4 impulsions
nécessaires au calcul de position.
Finalement, les résultats des temps de détection des impulsion sont
stockés dans une banque de registres. Ces registres contiennent également
les valeurs de constantes qui seront utilisées dans les deux algorithmes
des machines à états. Ces registres sont accesibles à partir du 6811 via
la machine à états qui permet de faire de l'entrée sortie (IOSM).
Dans le cas où l'on voudrait avoir plus d'un capteur (micro),
l'architecture du système est suffisament modulaire pour que la
modification soit simple. En effet, on n'aurait qu'à rajouter une
instance des deux premières machines à états pour chacun des capteurs.
Puis on aurait qu'à rajouter les registres appropriés et modifier
l'interfaçage pour tenir compte de ces nouveaux registres.
Détection d'impulsions valides
Comme on peut le voir sur la
figure 5, une impulsion valide est en fait
un train d'impulsions à une fréquence bien précise. L'algorithme de
détection fonctionne comme suit :
Lorsque l'on détecte un signal positif à l'entrée du circuit, on
conserve la valeur de l'horloge principale (COUNT1) pour s'assurer
que l'on note le début du train d'impulsions. On met à zéro les compteurs
d'impulsions (UPCNT). On part également un compteur qui calcule une
demi-période (WAITTMR).
Une fois que le compteur de demi-période a atteint la valeur de la
demi-période (HALFPER), on vérifie si l'entrée du signal est l'inverse
de ce qu'on avait à l'itération précédente. Si tel est le cas, on
incrémente le compteur d'impulsions (UPCNT) et on remet le compteur de
demi-période à zéro (WAITTMR). Si jamais on n'obtient pas le bon niveau
à la demi-période, on revient dans un états d'attente puisque l'impulsion
est invalide.
Une fois que l'on a atteint le nombre d'impulsions qui correspond à la
longueur d'une impulsion sonore valide (UPLEN), on signale la validité
de l'impulsion à la machine à états qui fait l'acquisition des impulsions
valides (ACQSM).
Dans les diagrammes de machines à états, on a utilisé les conventions
suivantes :
* Les conditions de transition sont marquées près des arcs en italique.
* Les actions à effectuer sur une transition sont marquées près
des arcs en caractères gras.
* Les actions à effectuer dans un état sont marqués à droite de
l'état en caractères gras.
Comme on peut le voir sur la figure 5, une séquence d'impulsions valide
est composée d'une série de quatre impulsions valides. Il y a deux
paramètres importants qui sont illustrés. MINDELAY est le temps minimal
que l'on doit attendre entre deux impulsions avant de déclarer qu'une
nouvelle impulsion fait partie de la séquence. Ceci permet d'éliminer
les problèmes d'écho.
L'autre paramètre est MAXDELAY, qui détermine le temps maximal entre
une impulsion d'une séquence et le début de la prochaine. Ceci est utilisé
pour s'assurer que l'on obtient quatre impulsions d'une même séquence. En
effet, comme les séquences vont être distancées dans le temps par une
période plus grande que MAXDELAY, si le compteur atteint la valeur définie
par MAXDELAY, cela voudra dire que l'on a manqué une impulsion et donc
que notre séquence est invalide.
On va accumuler les temps des impulsions dans des registres temporaires.
Lorque l'on va avoir validé notre séquence (donc 4 impulsions valides),
on va copier nos registres temporaires dans des registres de transfert.
De cette façon, le microcontrôleur ne pourra faire des lectures que sur
des données valides.
Le circuit IM permet au circuit LDI de communiquer avec le
microcontrôleur 6811. Ainsi, il peut lui communiquer les résultats
de l'acquisition. Il peut également recevoir les valeurs des paramètres
qui seront utilisés dans ses algorithmes. Comme ces valeurs sont
accessibles par le microcontrôleur, on peut modifier le comportement
de l'algorithme en ne faisant que des changement au niveau logiciel sans
avoir a modifier les circuits existants.
Présentation
Le circuit IM ne sert qu'à interfacer le contenu des registres du LDI
avec le bus d'expansion du 6811. Il permet la lecture et l'écriture
de différents registres. Son fonctionnement est basé sur le fonctionnement
du bus d'expansion qui était disponible sur le 6811.
Bus d'expansion
Le bus d'expansion disponible est très simple. Il ne comporte que 16
signaux. Les 8 premiers sont un bus de 8 bits, qui correspond au port
C du microcontrôleur. En plus de ces signaux, on a 4 signaux de
sélection de périphérique en lecture (Isel[3:0]) et 4 en écriture
(Osel[3:0]). La façon d'activer ces différents signaux est très simple
: si on effectue une lecture en mémoire dans des zones bien précises,
le signal Isel approprié va être activé. Dans le cas d'un écriture en
mémoire, c'est le signal Osel qui va être activé.
Machine à états d'entrée/sortie
La machine d'état a un fonctionnement fort simple, qui illustre bien les
opérations qui sont nécessaires pour effectuer une lecture ou une écriture
d'un des registres.
Pour effectuer une écriture dans un registre du LDI, on écrit en mémoire
à l'adresse $6000 l'adresse du registe que l'on veut écrire. Ceci va
activer le signal Osel0. Puis, on écrit à l'adresse $7000 la valeur du
registre LDI que l'on veut écrire. Ceci va activer le signal Osel1.
Pour effectuer la lecture d'un registre du LDI, on écrit en mémoire à
l'adresse $8000 l'adresse du registre que l'on veut lire. Ceci va activer
le signal Osel2. Puis, on lit à l'adresse $9000 la valeur du registre LDI
que l'on veut lire. Ceci va activer le signal Isel3.
Pour ce qui est du bus, qui doit être à trois-états, on doit normalement
le mettre en haute-impédance pour les trois cas où l'on effectue des
lectures. Dans le cas où on doit écrire sur le bus (dans le cas d'une
lecture de registre), on écrit sur le bus tant que le signal Isel 3 est
actif.
Par ailleurs, on a ajouté un compteur qui se met à compter lorsque l'on
commence une opération de lecture ou d'écriture. Lorsque ce compteur
atteint une valeur limite, on revient dans l'état initial d'attente. Ceci
est pour empêcher les cas où une lecture serait interrompue et que le
circuit resterait dans un état d'attente d'une valeur pour effectuer une
lecture ou une écriture.
L'implantation du circuit LDI/IM a été architecturée de façon à être
réalisée dans un circuit de logique programmable, plus spécifiquement
un Field Programmable Gate Array. Le choix de ce type d'architecture
est basé sur les arguments suivants : tout d'abord, la réalisation physique
d'un circuit comprenant un FPGA est habituellement assez simple. En effet,
dans notre cas, il ne faut comme éléments additionnels qu'un circuit
d'horloge, un circuit d'alimentation, un circuit de mémoire pour stocker
la configuration du FPGA et des condensateurs de découplage. Par ailleurs,
cette architecture permet au circuit d'être entièrement reconfigurable en
ne reprogrammant que le circuit qui contient la configuration du FPGA,
habituellement un EPROM sériel. De plus, les circuits qui sont réalisables
avec des FPGAs correspondent exactement aux besoins que l'on a pour
réaliser le circuit LDI/IM.
Par ailleurs, une expérience en conception de circuits VLSI basés sur
cette technologie nous a poussée vers cette option.
Il est important de noter que ce circuit est développé en collaboration
avec la compagnie RoboKup. En effet, la complexité d'un tel projet est
telle qu'elle a favorisé une entente de coopération entre les deux
équipes pour cette section. Ainsi, CUBIC développe le circuit numérique
de réception des impulsions, alors que RoboKup développe le circuit
d'émission, encore une fois basée sur un design à FPGA.
Bien qu'il aurait été possible d'utiliser une capture par schémas,
il est préférable dans notre cas, vue la complexité de nos machines
à états, d'utiliser un langage de description de matériel (Hardware
Description Language ou HDL).
Pour le développement d'un tel circuit, avec un échéancier aussi serré,
il aurait été plus facile de développer avec le langage AHDL
(Altera Hardware Description Langage). En effet, ce langage permet un
prototypage très rapide dans les cas où les circuits ne sont pas trop
complexes. Toutefois, comme il est propriétaire à la compagnie Altera,
il a dû être abandonné vu le fait que nous ne disposions pas de circuits
de la compagnie à notre disposition.
Nous avons donc opté pour le VHDL (Very High Speed Digital Integrated
Circuit Hardware Description Langage) pour réaliser la description de nos
circuits. Ce langage est standard et supporté par un grand nombre de
revendeurs de produits de design électronique automatisé (Electronic
Design Automation ou EDA).
Outils VHDL/FPGA
Pour réaliser nos circuits en VHDL, nous avons utilisé un certains
nombre d'outils différents. Nous avons utilisé notamment :
* Active-VHDL de Aldec pour l'édition et la simulation
* VSS de Synopsys pour la simulation
* Synthesis de Synopsys pour la synthèse
* FPGA-Express de Synopsys pour la synthèse
* Foundation et Alliance de Xilinx pour le routage du circuit
Actuellement, tout les circuits sont codés en VHDL et les simulations
fonctionnelles ont été réalisées et validées. La synthèse des circuits
a également été réalisée. Il reste à effectuer les simulations
post-synthèses ainsi que le routage du circuit. Ceci va être réalisé
dans les jours qui vont suivre.
2.4 Communication Sans-Fil
Le système de communication sans fil est réalisé à l'aide de deux émetteurs et de deux récepteurs RF
fonctionnant à 300 MHz. Cela nous permet de réaliser un lien bidirectionnel full duplex à 9600 bauds, de
manière à rendre transparente l'utilisation du lien sans fil.
Les émetteurs utilisés ont ainsi été modifiés afin d'être contrôlés par un circuit alimenté par les lignes
de transmission du port série. Ceux-ci ont une puissance d'émission de 50 mW leur assurant une portée d'environ
300 pieds, ce qui est amplement suffisant pour les besoins du projet en cours. Les antennes utilisées sont de
petite dimension (environ 20 cm), ce qui convient à un système de transmission opérant dans une telle bande de
fréquence. Les récepteurs, pour leur part, alimentent des circuits de conversion qui fournissent les signaux
nécessaires au fonctionnement du port série.
Jusqu'à maintenant, la conception du système de communication avance rondement. Les circuits sont donc
réalisés, bien que quelques modifications y seront apportées dans les prochains jours. Des problèmes
techniques sont encore à régler, mais ceux-ci sont en voie d'être éliminés. Le circuit alimentant les
émetteurs comporte quelques lacunes, qui diminuent la puissance d'émission disponible. Par ailleurs,
certains problèmes d'interférence existent entre les paires d'émetteur/récepteur fonctionnant en direction
opposée. En effet, ceux-ci étant situés à proximité les uns des autres, certains problèmes en découlent.
Enfin, les expérimentations ont démontré qu'un bon découplage de l'alimentation est nécessaire, car le bruit
induit par l'un des deux éléments de communication pouvait avoir un effet néfaste sur l'autre. Des solutions
ont été envisagées afin de régler ces problèmes et nous pensons qu'elles seront très efficaces, c'est-à-dire
qu'elles devraient les éliminer complètement.
Nous comptons pouvoir intégrer ce sous-système à l'ensemble dès la deuxième semaine de novembre. Des tests
seront alors effectués afin de s'assurer que le lien sans fil soit véritablement transparent, c'est-à-dire
qu'il réalise exactement le même travail que l'ancien fil du Rug Warrior.
2.5 Alimentation
L'ajout de circuits électroniques supplémentaires sur le robot souleva un
problème d'alimentation du fait que ce dernier ne possède qu'une
alimentation de 5 v régulé. La circuiterie embarquée nécessitant une
alimentation de +12 v et -12 v, il fallut trouver un moyen d'obtenir les
tensions désirées avec celle disponible sur le robot et ce en respectant
autant que possible les contraintes physiques (volume et poids). L'approche
retenue est d'utiliser un convertisseur de tension continue à tension
continue.
Les critaires de sélection furent :
- la tension d'entrée (5 volts)
- double tensions de sortie (+12 v et -12 v)
- le courant de sortie (d'au moins 50 mA)
- dimensions physiques
- la disponibilité
Notre choix c'est donc porté sur le modèle HL02R05D12 de la compagnie
Power Convertibles. Nous avons présentement un exemplaire de ce
convertisseur pour utilisation dans le cadre de notre projet.
3-) Sous-Systèmes Logiciels
3.1 Présentation
L'architecture du logiciel de contrôle du robot est représentée sur la figure ci-dessous. Elle est suivie d'une explication sommaire de son fonctionnement.
La classe configuration sert à conserver tous les paramètres du logiciel. Elle lit la valeur de ces paramètres dans un fichier ASCII. Lors du démarrage de l'interface graphique, celui-ci crée d'abord une instance de la classe Configuration et ensuite une instance de la classe Théâtre. Cette dernière contient toutes les autres classes du logiciel présentées sur la figure. Ensuite, l'interface graphique exécute les commandes de l'utilisateur en appelant les fonctions membres appropriées de Théâtre ou des objets qu'elle contient.
L'interface graphique possède des indicateurs qui reflètent l'état courant du logiciel. C'est aux objets du logiciel que revient la tâche de signaler un changement de leur état par le biais de messages. Pour refléter les changements signalés, l'interface accède alors directement aux objets pour lire les nouvelles valeurs.
Pour faire l'affichage graphique du robot et des remorques, l'interface graphique doit savoir comment représenter ces objets. Pour les afficher au bon endroit et de la bonne taille, il accède directement aux objets pour récolter cette information. La représentation, la taille et la position des models étant connus, l'interface peut alors les dessiner par lui-même a l'intérieur de sa fenêtre graphique.
La communication avec le robot physique est assurée par la classe LienBH. Celle-ci possède un thread qui lit et écrit sur le port série et qui signale aux autres objets l'arrivée d'information pertinente par le mécanisme d'événements.
Le système de navigation peut être dans trois modes différents. Le premier est le mode manuel pour lequel les mouvements du robot sont dictés par l'utilisateur à l'aide, par exemple, d'une manette de jeu. Le deuxième est le mode automatique où le robot se dirige par lui-même vers une cible définie par l'utilisateur. Le dernier mode correspond à notre caractéristique distincte. C'est le mode intelligent pour lequel le robot va s'accrocher en marche arrière à une remorque. Les trois module de la classe SystemeNavigation servent à gérer chacun de ces trois modes. Cette classe possède aussi un thread. Celui-ci attend l'arrivée d'événements comme une nouvelle position. Lorsqu'un tel événement arrive, le thread demande aux autres module d'aller récolter la nouvelle information dans la classe LienBH. Ensuite, il appelle la fonction GenererNouvellesCommandes() du module de contrôle approprié. Enfin, il signale à l'interface graphique que l'état du système a changé.
Les commandes générées par les systèmes de contrôle sont destinés au système de traction qui les converties en vitesse pour chaque moteurs. Ces commandes de vitesses sont transmises au robot par l'intermédiaire le la classe LienBH.
3.2 Interface Usager
L'interface usager
de notre logiciel est relativement avancé. Les bases du code sont
réalisées, soit les différentes classes implantant les différentes fenêtres. Cet interface
comporte une fenêtre d'affichage de l'"Arêne" qui nous permet de visualiser le robot,
les remorques et la cible dans l'environnement. Une autre fenêtre affiche une
"Console" qui permet de visualiser l'état des différents paramètres du robot, soit
la vitesse, la distance parcourue, la puissance transmise aux moteurs, le temps
estimé avant la panne (batterie), la direction et le mode de navigation du logiciel
(à vue ou automatique). Une autre fenêtre permet de visualiser tous les
paramètres du logiciel numériquement. On retrouve aussi une fenêtre de style "toolbar", soit
une barre d'affichage de boutons qui permet diverses actions comme le démarrage
de la démonstration. Enfin, on retrouve une fenêtre d'état (statusbar) qui divulgue de
l'informations pertinentes en fonction de la position de la souris ... Ces fenêtres représentent
la fenêtre principal de l'interface. En plus de ces dernières, deux fenêtres supplémentaires
(de style "popup") permettent dans un premier temps de dragger les objets pertinents
(Remorques, Cible) sur l'"Arêne" et de visualiser les commandes provenant, soit du clavier,
soit du joystick ou de la souris.
Nous sommes présentement en phase de conception des images pour la console et pour
l'arêne. De plus, les fonctions de "draggage" sont en développement. Enfin, la fenêtre
d'affichage numérique ne sera réalisable qu'une fois les autres classes du projet
terminées ...
Nous croyons donc être en mesure de terminer cet interface d'ici peu et son intégration
avec le reste du projet logiciel ne devrait pas occasionner de problèmes.
3.3 Algorithmes de Navigation Intelligente
Le système de contrôle intelligent sert à contrôler le robot de façon à ce qu'il aille
s'accrocher en marche arrière sur une remorque. Ce système fonctionnera à l'aide de logique
floue. Il sera semblable à celui qui étudié dans le cadre du cours Algorithme de l'ingénieur
II donné par le professeur Marc Parizeau. Les
classes qui seront utilisées pour gérer cette
logique floue sont d'ailleurs celles qui ont été mises au point par ce professeur.
Le système de contrôle intelligent n'a pas encore été implanté mais il n'est pas essentiel
au fonctionnement de base du projet.
3.4 Algorithmes de Navigation Automatique
Le but de ce sous-système est d'atteindre une position de manière autonome.
La position en question est celle que va employer le système intelligent
pour se brancher à la remorque.
De manière générale il s'agit d'asservir la position du robot envers une
position souhaitée sur un chemin à suivre. La commande d'asservissement est
faite sur la direction donnée au robot.
De façon plus particulière la position est comparée envers une distance à
un "point de route". Ce "point de route" est établi initialement comme la
position de la cible à atteindre. Il est modifié lorsque le robot rencontre
un obstacle. La comparaison se fait envers la grandeur de la distance.
La correction apportée est sur la direction du robot, i.e. le faire
maintenir son cap, le faire tourner d'un bord ou de l'autre. Lorsqu'il faut
tourner, le virage est déterminé d'après la correction à appliquer au cap
courant du robot pour rejoindre la direction du "point de route".
Le code permet de réaliser le principe de navigation établi. De plus, le
code peut fonctionner à différentes vitesses. Il est en effet possible de
modifier la vitesse du robot en fonction de la distance au point de route,
ou à la cible. La vitesse est maximale lorsque le robot tente de rejoindre
un point de route éloigné, et elle diminue lorsque le robot dépasse un
seuil de proximité à ce point de route. Le code permet aussi de spécifier
ces valeurs en fonction de la cible.
Le code implanté fonctionne tel qu'attendu lorsqu'employé avec un
"micro-simulateur" pour le déplacement du robot. Le fonctionnement testé
est de déplacer le robot vers une cible directe (sans obstacle), et vers
une cible indirecte (avec obstacles).
Le code implanté fonctionne peu importe l'orientation initiale du robot.
Le code a les points d'entrée nécessaires pour permettre l'approche à la
cible dans une direction donnée. Les modifications nécessaires pour ajouter
cette fonctionnalité sont de raffiner la routine de détermination du point
de route.
Cette modification n'est pas projeté pour l'instant en considérant que
cette approche orienté est le rôle du sous-système intelligent, mais pourra
constituer une alternative fonctionnelle quoique moins performante.
3.5 Localisation
Pour la partie localisation, il y avait trois classes à concevoir, soient
Attitude, Senseurs et SystemePositionnement. À ce moment-ci, les trois
classes sont terminées, il ne reste que le déverminage. La difficulté de
cette partie était de trouver, mais surtout de résoudre les équations de
positionnement du robot. Après avoir trouvé les équations, nous avons
réussi, avec l'aide du logiciel Maple, à isoler le x et le y.
Avant l'intégration, il reste à vérifier la validité des équations de
positionnement. Nous avons cependant besoin que d'autres classes soient
terminées avant pour achever ce travail. Lorsque celles-ci seront
terminées, nous ferons un petit programme qui met des valeurs possibles de
temps de réception des impulsions sonores dans la fonction qui trouve la
position. Nous pourrons ainsi vérifier l'exactitude des équations.
3.6 Communication
Le lien bas-niveau et le logiciel embarqué comprennent le code pour le
68HC11 du Rug Warrior de même que le nécessaire sur le PC pour que
celui-ci puisse communiquer avec le robot. Dans un sens, l'ordinateur
peut demander au robot de changer les vitesses de ses roues, d'émettre
un bip, ou de retourner l'énergie des piles, les valeurs des encodeurs
de position sur les roues ou l'état des détecteurs de contacts. Dans
l'autre sens, le robot peut transmettre à l'ordinateur les temps de
détection des impulsions sonores, l'énergie des piles, les valeurs des
encodeurs de position sur les roues ou l'état des détecteurs de
contacts.
Pour ce faire, une classe (LienBH) du logiciel sur l'ordinateur est
entièrement consacrée au lien avec le robot, de façon à simplifier le
reste du code. Sur le 68HC11, une fonction se charge d'attendre des
données du port série et de poser les actions appropriées. D'autres
fonctions se chargent de lire les temps associés aux impulsions sonores
pour le positionnement ainsi que les divers autres senseurs. Nous
asservissons également la vitesse du robot pour s'assurer qu'elle
réponde à la consigne.
Nous avons développé du code C++ qui permet d'utiliser le port série de
l'ordinateur, code qui est maintenant fonctionnel. Somme toute, le
code de la classe LienBH est bien avancé, si ce n'est que le protocole
de communication qui pourrait subir quelques modifications. Nous avons
également écrit le code nécessaire pour utiliser le port série du 68HC11
sur le Rug Warrior.
Plusieurs tests de communication entre le robot et l'ordinateur, hors de
l'environnement Interactive C, ont été réalisés. Nous avons fait
beaucoup d'essais avec l'HyperTerminal de Windows NT, de même qu'avec
notre logiciel en C++. Dans les deux cas, les données se transmettent
parfaitement du robot vers l'ordinateur, mais ce n'est pas le cas dans
le sens contraire (de l'ordinateur vers le robot). Le robot semble
"geler" assez souvent quand il reçoit des caractères. Le problème
devrait cependant être réglé d'ici peu car nous en avons récemment
compris la cause.
Il reste donc à faire fonctionner adéquatement le code pour la
communication du robot vers l'ordinateur et à implanter sur le 68HC11 le
code nécessaire pour lire les données provenant du module de détection
des impulsions, ainsi que les fonctions, plus simples, pour lire
certains senseurs et répondre aux commandes venant de l'ordinateur.
3.7 Logiciel Embarqué (Sur le Robot)
Le logiciel embarqué constitue un point important de l'utilisation du
robot Rug Warrior. C'est par ce logiciel que passera et sera traité toute
l'information sur l'environnement du robot, la détection des impulsions
sonores et les commandes en provenance du PC via le lien série.
L'environnement du robot est constitué par la mesure de l'énergie des
piles, les valeurs des différents senseurs, des encodeurs de positions sur
les roues et des interrupteurs de détection d'obstacles.
Un aspect du logiciel embarqué est la gestion de l'information provenant
des divers sources mentionnées ci-haut. Ainsi, la priorité sera donnée à la
communication avec le PC et la réception des impulsions sonores servant au
positionnement. Les lectures des capteurs sont exécutées sur demande.
Bien que cette partie du projet soit très critique, plusieurs essais
restent à réaliser pour la communication entre le micro-contrôleur et la
carte de la logique embarquée. Toutefois, les parties de communication avec
le PC et de lectures des capteurs sont bien avancées. Suite à la
réalisation des essais mentionnés ci-haut, il sera possible de faire
l'intégration des différentes routines et de vérifier le bon fonctionnement
de la gestion de l'information.
4-) Site WEB
À ce stade du projet, l'aspect visuel (ou esthétique) du site web n'est
que très faible. Seul certains aspects de la présentation ont été
travaillés laissant plus d'importance à la fonctionnalité qu'à
l'esthétique. Une fois l'intégration des systèmes completé, un travail de
présentation des résultats sera effectué pour le rapport final.
5-) Conclusion
Nous suivons l'échéancier prévu. Les items de risque majeur ont été résolu,
bien que certaines solutions ne seront prouvée qu'à l'intégration. Nous
nous apprêtons à réaliser cette intégration.