Projets Universitaires
bacc en génie informatique

Système d'assistance à la navigation en réalité augmentée (hiver 2004)
Ce projet a été réalisé dans le cadre du cours de design IV, qui est l'équivalent d'un projet de fin de bacc. Il a été réalisé en équipe de 2 personnes, c'est à dire moi et mon coéquipier Jean-François Lalonde. Ce projet a été réalisé en collaboration avec le RDDC-Valcartier, le centre de Recherche et dévellopement pour la défense Canada et s'inscrit dans le secteur du commandement et contrôle lors de guerre urbaine. Il vise à identifer les concepts d'importance relatifs à la conception d'un système d'aide à la navigation en réalitée augmentée dans un véhicule. Afin de répondre à cet objectif, un état de l'art présente deux technologies existantes, soit les affcheurs tête-haute ("head-up display") et les afficheurs faciaux ("head-mounted display"). Malgré une technologie encore non-disponible sur le marché, il est déterminé que la première option semble être celle pouvant s'appliquer le mieux aux véhicules. Les critères de durabilité, de taille de surface de projection et de luminosité sont à considérer. Par la suite, un prototype de test est développé. Cet outil est une simplification en deux aspects du problème original : les acquisitions sont effectuées en temps différé et le projecteur nécessaire est remplacé par une caméra. Tout d'abord, il est alimenté par des données provenant d'un modèle virtuel. Cette simulation suppose que les données sont non-bruitées et sont reçues en totalité et en intégrité. Elle permet d'établir certains principes importants relatifs à la présentation de l'information, notamment la quantité, la clarté, la simplicité et l'universalité. Le système est testé par le biais de différents scénarios illustrant son comportement dans diverses situations. Lorsque l'architecture du prototype est validée, un montage physique comprenant un récepteur GPS, un capteur d'orientation, une caméra ainsi qu'un véhicule commercial est réalisé afin de procéder à l'acquisition de données réelles. Ces données sont alors fournies en entrée au systéme. Deux problèmes importants se présentent, soit l'imprécision du GPS ainsi que la dérive du capteur d'orientation. Des solutions tel que l'interpolation et le ltre de Kalman sont proposées et les résultats sont analysées. Malgré les simplifications, les essais permettent de prouver la faisabilité d'un système complet, en mettant l'accent sur l'importance de posséder des capteurs de position et d'orientation sans biais ni dérive. Finalement, certaines améliorations utilisant la vision numérique sont présentées afin de pouvoir obtenir, dans le futur, un système en boucle fermée.
	Schéma bloc du prototype virtuel réalisant la réalité augmentée sur des images de synthèse.
	Schéma bloc du prototype réel réalisant la réalité augmentée sur l'image d'une caméra et utilisant les données acquises à l'extérieur
	Image obtenue avec la ville simulée. La trajectoire est superposée sur l'image de la route en 3D. Pour bien la distinguer de profil, le côté droit est vert et le côté gauche est magenta.
	Véhicule utilisé pour l'acquisition des données. On remarque les différents capteurs, soit l'antenne GPS, la caméra et le capteur de rotation.
	Image obtenue avec le prototype réel. L'image de la caméra augmentée à l'aide d'une scène 3D imitant le monde réel. Dans cette scène est affiché une trajectoire relative à la position et l'orientation du véhicule tel qu'acquise par les capteurs
	Image du prototype réel. La flèche verte indique la destination à atteindre.
	Autre image du prototype réel à un autre endroit du campus.

Babyfoot League 2K2 (automne 2001)
Réalisé dans le cadre du cours de génie logiciel orienté objet (GLOO), ce projet d'équipe (6 personnes) consistait à faire un jeu de baby-foot à quatre joueurs en réseau et fournir le design UML. Le code était en Java et nous utilisions des sockets pour faire fonctionner l'architecture client serveur. Le design a été établit en équipe, mais mes expériences passées dans la création artisanale de moteurs de jeu ont permis d'établir la structure générale. J'était responsable de l'aspect graphique, j'ai donc fait le design et l'implémentation du moteur graphique 2D et de la hiérarchie de classe qui s'y rattache afin d'avoir un beau design OO. J'ai aussi créé les graphiques, qui sont des modèles 3D pré rendus. En fin de compte, le projet a été un grand succès. Il est jouable, fluide et élégant, malgré certains petits bugs de physique ;), définitivement un des meilleurs jeu de cette année là.

Système de levage solaire (hiver 2002)
Le programme de bacc en GIF offre 4 cours de design. Le premier est un projet papier, avec aucune réalisation. Le cour de Design 2 a toujours un projet centré autour d'un panneau solaire (ouais, y'a un prof au département qui est un solar freak). Le projet de 2002 est la réalisation d'un système de levage qui lève une plaque de métal avec un électroaimant. L'électroaimant est alimenté par la pile solaire. Le hic est que l'éclairage n'est pas constant. Il faut donc un condensateur et un circuit de hachage pour réguler le courant. La photopile doit aussi tourner pour capter le maximum de lumière. Le tout est assemblé sur une structure mobile en legos et est contrôlé par le module Mindstorm. Nous avions divisés l'équipe en deux sous-groupes, un pour le hardware et l'autre pour le soft. Je me suis retrouvé dans celle du soft, responsable de la création de la simulation Simulink. Unir tous le monde pour que le travail se fasse fut difficile, mes coéquipier avaient des trucs plus urgents à faire, semble t’il, alors pour ne pas être pris à la dernière semaine pour tout faire, j'ai graduellement accomplit la tâche seul. Le résultat final, coté simulation fut très correct, mais lors de la compétition finale avec les autres équipes, notre système ne levait pas la charge très longtemps, possiblement parce qu'il y avait une fuite de courant dans le système.

Robot autonome jouant avec une balle (hiver 2003)
Dans la même veine que le projet précédant, le cours de Design 3 offre un projet nettement plus complexe. Toujours avec un système Lego Mindstorm et son contrôleur, le RCX, il faut maintenant créer un robot autonome capable de trouver une balle sur une table, de la prendre et de l'envoyer dans au but. Le robot possède une caméra (web cam Logitech) qui lui permet de voir son environnement. Cette caméra est branchée à un ordinateur qui sert de cerveau et envoie des commandes au RCX pour que celui-ci actionne les moteurs du robot. De plus, durant une période de 10 minute, le robot devait se connecter dans une pseudo station de recharge et échanger un nibble avec elle. Le tout doit être réalisé en équipe de 8 durant la session. Notre robot était une sorte de tour sur deux roues (après avoir remplacé la fly-wheel à l'arrière par des patins) actionnée par deux moteurs branché au RCX. La caméra est au sommet, ce qui donne une bonne vue pour la vision, mais laisse un angle mort à l'avant du robot. Un capteur de balle comble ce manque et permet de savoir si la balle est dans les pinces du robot. Les moteurs possèdent des capteurs de rotation, ce qui fait en sorte qu'ils sont asservis en boucle fermée par le RCX. Cela permettait d'utiliser des commandes comme "avance de 7/32 de tours" et cela se faisait assez bien. La station de recharge était assez simple et comprenait un PIC, une led IR, 4 boutons et 1 LCD pour afficher le nibble et le temps restant. La vision était basée sur la couleur. Il fallait trouver la balle, un blob rose, et se localiser sur la table. La localisation était assez complexe, seul la couleur d'un bout de bois placé dans chaque coin permettait de se localiser. Le seul hic, c'est qu'il y a 2 couleurs de coins. En trouvant les coins, on pouvait connaître la distance à ceux-ci en mesurant la distance entre les extrémités. Mais il fallait toujours en voir deux pour savoir dans quel sens le robot pointe. Le tout était implanté en C++ et utilisait la librairie OpenCV d'Intel. Ma responsabilité était le dernier système d'importance, soit l'IA. Nous avons opté pour quelque chose de simple car nous savions que le temps de test à la fin serait limité. Ce fut donc une machine d'état à deux niveaux (chaque état de base est une sous machine à état), que j'ai désigné et codé. Un sous module servait de mémoire à long terme et filtrait les infos de position et de visibilité de la vision (ma responsabilité) et un autre sous module se chargeait de traduire une commande de déplacement de haut niveau (de Avers B) en commandes de bas niveau pour le RCX et d'éviter les obstacle et le pourtour de la table. Un dernier module que j'ai codé en collaboration avec le responsable du RCX appelait les bonnes routines dans le RCX en prenant soin de limiter le temps de communication au minimum. à la fin du projet, le robot était pleinement fonctionnel et fonctionnait très bien et comptait des buts, quoique la tas de fils qui le reliait au monde extérieur était une nuisance. Lors de la compétition, toutefois, un paramètre fit défaut. Une fonction permettait de marquer la balle comme non vue si elle devait être dans le champ de vision (d'après la position mémorisée) et qu'elle n'y était pas. Quelqu'un (on ne sait pas qui) a déplacé la caméra, ce qui a altéré le point de vue et le robot s'est mis à altérer entre deux états. Il voyait la balle, avançait un peu et perdait la balle de vue (ce qui est normal), mais pensant toujours devoir la voir, il l'effaçait de sa mémoire. Zut alors! Bah, je conserve toujours un vidéo du robot en marche comptant un but, car nous filmions tout nos essais.

 

Simulateur SPTR (Automne 2003)
Un autre cours est celui de SPTR (pour systèmes parallèle, temps réels) dont le but est d'enseigner les principes théoriques des architectures parallèles. Le professeur a expérimenté avec nous de remplacer les "laboratoires" par un travail long où nous devions simuler logiciellement (C++ ou Java) l'ordonnancement du service technique du département, du moins c'est ce que nous pensions au début (j'inclus ici 99% des étudiants). Au fur et à mesure des évaluations intermédiaire du projet, l'objectif a changé pour trouver à l'aide du simulateur une SO pour le PO du département. (Note: le prof adore les acronymes inutiles, PO = problème d'ordonnancement et SO = solution d'ordonnancement). L'usage de librairie spécialisée était interdit. Le travail se faisait en équipe de 4, mais nous l'avons fait à 3, car dans chaque équipe, il y a quelqu'un qui fait rien. Le nôtre a disparu sans laisser autre chose qu'un mail de 3 ligne et a lâché son bacc à la 3e session. C'était à la mi-session, lorsque le projet devait se faire car nous avions reçu la théorie nécessaire. Après avoir mis 100+ heures dans le simulateur et qu'il était presque terminé, nous avons sus des évaluateurs du projet que ce qui était important (et qui valait 75% de la note) était la SO elle-même et que le simulateur valait 25% ou 5% du cours. Bref, notre simulateur était maintenant farfelu. 100h x 2 programmeurs pour 5% c'est ridicule. Finalement, notre simulateur permet créer graphiquement (unique parmi les autres équipes) un réseau de personnes exécutant des tâches. Le tout est sauvé en XML pour charger et sauver les données. L'interface graphique est mon principal accomplissement. Il se compose d'un éditeur graphique style Visio et d'une série de pop-up pour éditer les paramètres. Lors de la simulation, la vue se met à jour pour illustrer la progression des tâches dans le réseau de personnes. Pour les curieux, cette vue a été créée à partir de rien en surclassant un CButton et en utilisant les fonctions graphiques de bas niveau des mfc.

 

Commande par reconnaissance de la main (Automne 2003)
Dans le cadre du cours de vision numérique, nous avions à réaliser un petit projet à la fin de la session. Moi et deux coéquipiers avons opté pour un système à reconnaissance de position de la main pour lancer des commandes. La caméra était une simple webcam 320x240 pixels et le programme codé en C++ tout en utilisant la librairie OpenCV. Notre solution est la suivante: - Effectuer une soustraction de fond pour obtenir un masque du mouvement récent. - Effectuer un seuillage en hue et en saturation sur l'image sur les intervalles correspondant à la couleur de la peau, de façon à obtenir deux masques. - Faire un ET logique sur les masques pour avoir les pixels d'intérêts - Effectuer une ouverture et une fermeture - Regrouper les pixels en blobs de taille suffisante - Garder les plus gros et remplir les trous pour avoir des blobs pleins - Comparer avec les formes de références en mémoire et faire un plus proche voisin pour déterminer la forme de la main. La comparaison est effectuée en donnant la taille de l'image de référence au blob et en effectuant un simple XOR logique. C'est simple et ce fut suffisamment efficace. De plus nous n'avions que 10 jours pour réaliser ce projet, en pleine fin de session. Le résultat final fut convaincant, malgré un problème à la présentation finale: ne pas ajuster son niveau de blanc est nuisible au filtre HSV. Note: Ce n'est pas moi sur la photo ;)