
En cours de rédaction
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 :
Tout ce que nous faisons est GPL, et disponible en ligne (le serveur n'est actuellement pas accessible car en train de migrer).
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.
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.
Pour contrôler tout ceci, nous avons donc eu besoin des blocs suivants :
Pour choisir une solution efficace (et si possible optimale), les contraintes de chaque bloc ou tâche ont été évaluées :
| Bloc/tâche | réalisé en matériel ? | réalisé en logiciel ? | implémentation choisie |
| contrôle PWM des servo-moteurs | trivial, peu de ressources | nécessité d'avoir des interruptions précises | matérielle (FPGA) |
| détection présence / couleur de balles | trivial, peu de ressources | trivial, mais à faire en tâche de fond à intervalles réguliers | matérielle (FPGA) |
| contrôle des moteurs de propulsion | complexe (PID), mais adapté au matériel | nécessite des interruptions précises | matérielle (FPGA) |
| traitement des roues codeuses | simple, peu gourmand en ressources si bien codé | nécessite de la puissance de calcul | matérielle (FPGA) |
| contrôle PWM des moteurs d'aspiration | trivial, peu de ressources | nécessité d'avoir des interruptions précises | matérielle (FPGA) |
| acquisition sur la position du barillet et détection blocage | trivial | trivial | logiciel |
| acquisition et restitution des flux vidéo | complexe (flux asynchrones), mais adapté | impossible | matérielle (FPGA) |
| traitement vidéo | très complexe | simple, mais demande puissance de calcul | pré-traitement : matériel, traitement : logiciel |
| gestion globale du robot | irréaliste | seule solution raisonnable | logiciel |
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 :
Ce qui nous donne cette architecture globale :
| Lu | Ma | Me | Je | Ve | Sa | Di |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |