1. Introduction

Tout comme Rome ne s'est pas construite en un jour, il faut du temps avant que sa vision globale d’un projet ne se reflète sur sa table de travail. Et même si le résultat final est encore loin, ce second projet d’informatique m'a donné toutes les clés nécessaires pour que pendant les vacances d’été je puisse m’enfermer dans le noir et donner vie à ma vision ; un redoutable joueur d’échecs. Le projet de printemps présenté ci-dessous fait suite à un projet plus ancien et il est sciemment conseillé d’en prendre connaissance pour ne pas être perdu. En effet, après avoir construit une grue triaxiale, S.A.F.E, pendant cet hiver, je me suis, durant ces dernières semaines efforcé de l’automatiser. Le robot utilise donc une caméra pour repérer l’objet sélectionné. Il se dirige automatiquement vers sa cible et s’en empare. Puis, l’on passe en mode manuel et l’on dirige la grue. Une fois l’objet reposé, le robot est prêt pour une nouvelle opération. Du moins, ça c’est la théorie, la pratique est un peu différente comme on le démontrera.

2. Matériel

Le matériel comprend tous ce qui fut utilisé pour le S.A.F.E qui ne sera pas cité ci dessous. De plus les éléments de structure ne sont qu’exprimés succinctement. On se concentrera sur les pièces électroniques.

  • Raspberry Pi 3 (Model B)
  • Raspberry Pi Camera Module
  • 2x Touch Sensors (récupérés du LEGO NXT)
  • Interrupteur ON/OFF & LEDs
  • Breadboard
  • Câbles & Résistances
  • Soutiens et cadres en bois (récupérés)
  • Set de pièces légo (récupérés)
  • Matériel utilisé pour le S.A.F.E

3. Méthode

La méthode de subdivision du projet en problèmes moins complexes ayant fait ses preuves, j’ai décidé de continuer comme cela. Avec cependant une petite différence, j’ai divisé mon travail en fonction des tâches que le robot devait accomplir. L’artefact doit, trouver un objet, s’y rendre, revenir à sa position de départ et laisser les commandes à l’utilisateur puis reprendre ce cycle.

3.1Reset ()

J’ai commencé par faire revenir le S.A.F.E à sa position initiale car cela me semblait le plus facile. Pour cela, j’utilise deux Touch Sensors. Les chariots rouleront indépendamment de leur distance jusqu’à rencontrer les capteurs. Ils s’arrêteront à cet instant. Les capteurs sont connectés aux GPIO en input et renvoient un signal lorsqu’ils sont pressés. Cette partie électronique n’était pas particulièrement problématique. Cependant, les capteurs n’étant pas adaptés au GPIO il a fallu rechercher les schematics de LEGO pour repérer les câbles correspondants aux sorties des Touch Sensor. Shematics des pinout du capteur Le code est lui aussi plutôt basique. En effet, les moteurs tournent en continu jusqu’à ce que le capteur détecte une collision. Le moteur de descente tourne pour une durée déterminée. Cette fonction permettra de reset le robot après chaque déplacement et est bien utile pour la précision de l’engin.

3.2RFind ()

La deuxième partie fût la plus compliquée et problématique pour moi mais finit par se résoudre de manière très simple. Il s’agit de repérer un objet au sol et de retourner sa position dans l’image. Pour cela le robot fonctionne en plusieurs étapes. Il prend une photo, l’analyse puis retourne les informations sous forme de coordonnées (x, y). La prise d’image ne fut pas un problème. La caméra compatible avec le raspberry fut facilement branchée et une librairie par défaut existait déjà sur la machine pour les contrôles de base. L’image proccessing pour les anglophones fut cependant un vrai casse tête. En effet, il n’est pas naturel pour un ordinateur de reconnaître les objets dans une image. Pour ce faire, plusieurs idées furent envisagées, toute passant par la binarisation de l’image. Ce procédé consiste à transformer une image de couleur en image avec des pixels soit noirs soit blancs, rendant la détection d’un objet solitaire plus facile. Je me suis d’abord essayé à créer un masque bit à bit qui détecterait un pixel noir. Cependant forcé de voir que cette technique créait trop d’erreurs, je me suis rabattu sur une solution plus facile et la plus rapide. La librairie SimpleCV adaptée de OpenCV offre des algorithmes de reconnaissance plutôt performants, détectant les agrégats de pixels unis et retournant leur centre pondéré.

3.3Travel ()

Après avoir détecté l’objet sur l’image, le robot doit encore transposer ces coordonnées dans la réalité et s’y rendre. Pour se faire, on transpose la matrice de pixel en matrice métrique en utilisant une simple règle de trois puis on ajuste avec une constante. Pour que la grue se déplace, on utilise les équations du mouvement rectiligne. En connaissant la positions relative et la vitesse de croisière il est aisé de déterminer la durée du trajet. On actionnera donc les moteurs pour un temps déterminé. La grue descendra et l’électroaimant sera activé. Le robot retournera à sa position initiale et passera en mode manuel. Ces différentes fonctions sont intégrées dans un script principal simple qui import toutes les librairies et fait les réglages initiaux. De plus le mode manuel provient du code légèrement modifié du S.A.F.E déjà décrit dans le projet précédent.

4. Résultats

Les résultats son plutôt convaincant même si il est vrai, certains problèmes d’imprécision se font toujours remarquer. La séparation du code en fonctions à permis de les tester individuellement puis regroupées, simplifiant grandement la phase de débogage. Bien sur il reste des améliorations à faire mais le tout semble plutôt cohérant. Voici une vidéo de démonstration du S.A.F.E en action.

5. Discussion

Ce projet fut bien plus concentré sur la partie programmation du robot que son amélioration matérielle et en règle générale c’est du coté informatique que les problèmes se sont le plus manifestés.

5.1Problèmes

Ce projet a rencontré beaucoup de problèmes inattendus qu’il à parfois fallu résoudre en redoublant d’ingéniosité. Une grande partie de la programmation se passe à débugger le code mais sa séparation en fonctions m’a permis de les tester chacune individuellement facilitant grandement la tâche. Je ne reviendrai cependant pas sur la fois il m’a fallu 45 minutes de tests, recablage et arrachage de cheveux avant de me rendre compte que la nappe du GPIO n’était pas branchée. La reconnaissance d’image fut complexe. L’idée de l’utilisation du format .sng pour l’analyse due être abandonnée suite à des erreurs à la compilation. Il a fallu du temps avant de trouver une librairie polyvalente pas trop lourde en données. Un autre problème survenu à seulement 3 jours du rendu fut l’arrêt inexplicable du moteur de déplacement horizontal (grand chariot). Il semble que celui-ci ait grillé. Afin que la machine fonctionne tout de même, j’ai remplacé celui-ci avec le moteur « Switch » moins indispensable. L’aimant reste malheureusement toujours à la même altitude et est fixé avec un tube en plastique

5.2Améliorations

La partie matérielle fut la moins aboutie et cela se ressent. En effet, lors de ce projet, j’ai mis l’accent sur la programmation, partie qui m’intéressait plus. Malheureusement, l’un ne va pas sans l’autre. De plus les imprécisions du précédents projet ont un impact énorme maintenant plus que jamais et le tout menace à tout moment tomber. Le matériel est définitivement à améliorer

6. Conclusion

Dans l’ensemble je suis plutôt content du résultat, le robot fait, dans les grandes lignes, ce qu’on lui demande. Ce projet avait pour but de se concentrer sur la découverte des prémices de l’intelligence artificielle faible, capable de sentir son environnement et de réagir en conséquence et en cela c’est une grande réussite personnelle. Malheureusement, à l’état, je crains pour l’avenir du S.A.F.E. En effet son véritable point faible est la partie matérielle. A mon avis, avec ce projet nous avons atteint les limites de ses capacités et pour qu’un jour, il puisse vraiment jouer aux échecs son corps tout entier devrait être reconstruit à neuf de façon plus précise et plus réfléchie. Le code quant à lui me semble plutôt efficace et bien qu’il existe surement bien des méthodes pour l’optimiser je pense le garder pour la suite du S.A.F.E.