En cours de rédaction

Approche

Le but de notre association est simple : apprendre. En conséquence, nous développons le maximum de choses nous mêmes, sans avoir peur de recommencer si on s'aperçoit après coup que les choix n'étaient pas très judicieux.

Deux conséquences :

• nous concevons et réalisons toutes nos cartes électroniques, notre mécanique, ainsi que, bien entendu, le logiciel (code maison, drivers Linux et port du compilateur Ada sur notre processeur);
• les solutions retenues ne sont pas forcément les plus efficaces d'un point de vue industriel (coût de revient, encombrement, ...), mais ce sont celles qui ont l'impact pédagogique le plus important. Lorsque nous trouvons des solutions originales ou particulièrement formatrices, nous essayons au maximum de les partager, généralement sous forme de tutorial (les tutoriaux disponibles sur ce site), de façon à diffuser nos connaissances et savoir-faire.

Tout ce que nous faisons est GPL, et disponible en ligne (le serveur n'est actuellement pas accessible car en train de migrer).

Architecture globale du robot

Notre robot devait être capable d'aspirer les balles sur la table ainsi que celles dans les trous, d'en stocker un certain nombre en connaissant leur couleur, de rejeter les noires à des endroits pratiques (hors du chemin, pour ne pas les ré-aspirer), et de déposer les blanches précisément dans les trous.

Mécanique

Le robot a donc un système d'aspiration de balles (3 ventilateurs inversés montés verticalement). La puissance d'aspiration permet d'attraper les balles jusqu'à 60cm du robot sur la table ou bien de les sortir des trous. De là, les balles entrent dans le robot, et sont stockées dans un barillet rotatif. Le nombre d'emplacements dans le barillet a été calculé de façon à ne jamais embarquer plus de 14 balles en même temps dans le robot.

Un système de détection de balles, situé au bord du barillet, permet de savoir si une balle a été capturée, et le cas échéant sa couleur. Un bras mobile, actionné par un servo-moteur, permet alors d'éjecter les balles noires par le côté du robot si nécessaire. Les balles blanches sont, elles, généralement gardées dans le barillet, et acheminées vers le bras de dépose dont l'entrée est contrôlée par un autre servo-moteur.

Le bras de dépose est mobile. Il permet de compenser un positionnement imprécis du robot au dessus d'un trou, et de pouvoir quand même y déposer une balle.

La détection des trous (couleur et emplacement) ainsi que la détection des balles est assurée par deux caméras : l'une orientée juste devant le robot, l'autre plus loin vers l'horizon.

Influence sur l'électronique

Pour contrôler tout ceci, nous avons donc eu besoin des blocs suivants :

• contrôleurs PWM de servo-moteurs (bras éjection, barillet, bras de dépose, porte du bras de dépose)
• détection de présence et couleur de balles (à l'entrée du barillet, dans le bras de dépose)
• contrôleurs des moteurs de propulsion (PWM) et gestion / traitement des roues codeuses
• contrôleurs des moteurs d'aspiration (PWM)
• acquisition d'information sur la position du barillet et d'un éventuel blocage
• acquisition de jack de démarrage
• acquisition et traitement des deux flux vidéos et sortie vidéo pour contrôle visuel
• alimentation des différents blocs
• gestion globale du robot

Pour choisir une solution efficace (et si possible optimale), les contraintes de chaque bloc ou tâche ont été évaluées :

Cette table tire parti du fait que nous avons réalisé des cartes intégrant un processeur et un FPGA (fortement couplés). Nous pouvons donc choisir à volonté le type d'implémentation le plus adapté (logiciel ou FPGA).

Maintenant, les deux blocs consommateurs de puissance logicielle sont le traitement de la vidéo et la gestion globale du robot. Pour être sûrs de ne pas manquer de puissance de calcul, nous avons donc réparti ces deux tâches sur deux cartes séparées :

• la première se charge de la vidéo :
  • le FPGA s'interface directement avec les caméra OV7620, stocke les trames dans des mémoires tampons, implémente un framebuffer pour la restitution (permettant un débug visuel)
  • le processeur applique les algorithmes choisi (segmentation, graph cut, ...)
• la deuxième se charge du reste :
  • le FPGA se charge des PWM, des PID, de calculer en temps réel la position en XY du robot, etc...
  • le processeur récupère toutes les informations et gère les périphériques en fonction de la stratégie choisie
• la communication entre les deux cartes s'effectue par une communication IP sur lien série (PPP)

Ce qui nous donne cette architecture globale :