En cours d'écriture

Processeurs

Lors des développements, on a essayé et testé plusieurs processeurs :

• SH4 d'Hitachi pour les cartes nécessitant de la puissance de calcul
• des PIC, principalement des 18F258, pour les petites cartes d'appoint

Finalement, pour limiter le nombre de cartes, nous sommes partis sur deux cartes à base de SH4, faites par nous,
combinant un processeur SH4 (SH7750R) et un gros FPGA d'Altera (EP1S25). Elles ont les caractéristiques suivantes :

• 32Mo de Flash, séparés en 3 partitions (bootloader, kernel, et root filesystem au format YAFFS)
• 32Mo de SDRAM
• un encodeur et un décodeur vidéo multi-format (PAL, NTSC) ainsi que 36Mbits de SSRAM vidéo
• USB maître (1.1) et USB esclave (2.0)
• un port d'extension 32 bits connecté au FPGA, un port IrDA, deux ports série, ...
• Linux 2.6.15

Le schéma des cartes mères est disponible ici au format pdf.
Les cartes mères sont reliées au réseau par l'intermédiaire de clefs USB-WiFi, ce qui nous permet de monter les disques des PC de développement en NFS et de nous logger dessus à distance.

Traitement vidéo

La vidéo est traitée par une carte SH4/Stratix, appelée SHiX1 dans le schéma d'architecture globale. Elle est reliée à deux caméras OV7620 par l'intermédiaire d'une interface simple. Les deux caméras permettent d'avoir deux vues différentes du terrain de jeu :

• une vue au pied du robot, pour un positionnement précis sur le trous
• une vue "lointaine" pour savoir dans quelle direction se trouvent les balles

OV7620

Les caméras OV7620 d'Omnivision sont des petites caméras numériques, utilisées dans les CMUcam, dont voici les caractéristiques qui nous intéressent :

• résolution de 640x480 pixels (en fait 326 688 pixels) : un quart sont rouges, un quart bleus et la moitié verts
• contrôle des paramètres par I2C : exposition, gains, filtres, fréquence, ...
• fréquence trame réglable
• sortie des pixels sur bus numérique 8 ou 16 bits (plusieurs formats au choix)

La sortie vidéo étant numérique (même si elles disposent aussi d'une sortie de contrôle analogique noir et blanc), ces caméras sont particulièrement bien adaptées à une interface par FPGA.
Notre carte mère dispose d'un bus d'extension relié au FPGA de 32 bits. On peut donc y brancher deux caméras pour peu qu'on sélectionne un format de sortie 8 bits (il faut garder quelques lignes pour les
horloges et le bus I2C).

Carte interface : crosstalk

Le bus d'entrée-sortie du FPAG est en 3.3V mais est compatible 5V. Il n'y a donc pas besoin d'interface entre le FPGA et les caméras. Mais c'est là que se pose le problème du crosstalk (diaphonie). Les caméras sont éloignées de la carte mère d'environ 30cm et y sont reliées par un câble en nappe. Si on ne fait pas attention à ce câble,
le couplage entre les fils peut être tel que les pixels reçus (et les synchronisation) sont impossibles à interpréter. C'est le crosstalk.

Il existe deux sortes de crosstalk, le capacitif et l'inductif. Dans les câbles et les circuits imprimés, contrairement à un croyance répandue, c'est l'inductif qui prime.

Pour le contrôler ou l'éliminer, il existe plusieurs solutions :

• mettre le plus possible de fils de masse sur le câble, en les répartissant régulièrement : la boucle formée par un fil (signal) et son fil de retour (la masse la plus proche) aura donc une surface moindre, donc une inductance plus faible. C'est la solution la plus efficace. Nous avons donc dédié un fil du câble en nappe sur deux à la masse.
• diminuer l'inductance propre des fils en diminuant la longueur du câble : impossible pour nous, on avait besoin des 30cm. Mais il n'y a pas que le câble qui crée du crosstalk. Il y a aussi le connecteur HE10, qui contribue pour près de la moitié au crosstalk total. On a donc intercalé un buffer entre le connecteur HE10 de la
  carte mère et le câble. Buffer dont l'impédance de sortie est adaptée au câble... On réduit donc la longueur totale des connexions, et surtout on évite de rajouter en plus une distorsion aux signaux à cause d'une impédance non maîtrisée. Au total, le signal est transmis correctement.

Le schéma de la carte d'interface est disponible ici au format PDF.

Carte mère principale, carte d'interface et cartes annexes

La carte mère principale, appelée SHiX2 dans le schéma global, se charge de toutes les tâches hormis la vidéo : algorithme de déplacement, acquisition des capteurs, génération du contrôle des moteurs, ... Le partage des tâches est effectué ainsi :

• en logiciel :
  • interprétation des informations des capteurs (présence de balle, blocage du barillet, position XY du robot, ...
  • algorithme de haut niveau de déplacement du robot
• en matériel
  • asservissement polaire des moteurs
  • contrôle en PWM de tous les servo-moteurs
  • calcul de la position du robot en XY à partir des roues codeuses
  • récupération et mise en forme des informations des capteurs

Au niveau électrique, la partie logique est complètement séparée des parties puissance par des optocoupleurs.

Capteurs analogiques

Ces capteurs regroupent les capteurs de couleur des balles entrées dans le robot ainsi que les ILS pour connaître la position du barillet. Ils arrivent sur un convertisseur analogique-numérique 8 voies (MCP3208) qui est interfacé en SPI avec le FPGA de la carte mère.
Les capteurs de présence/couleur des balles se composent d'une LED haut rendement cyan (Superflux) et d'une photodiode adaptée à cette longueur d'onde. Nous avons choisi une longueur d'onde bien précise pour limiter
l'influence des lumières extérieures éventuelles.