MoCAS – Architecture générale, problème et conception
Le module MoCAS peut être considéré comme un bus de données sans fil permettant de relier des périphériques distants, embarqués dans un modèle réduit, à un ordinateur au sol (cf. figure 1).
Trois problèmes majeurs se posent :
o Répartition de la bande passante ;
o Connectique et protocoles de transfert de données ;
o Gestion de l’énergie embarquée.

Figure 1 – Architecture de MoCAS
Répartition de la bande passante
Nous sommes en présence d’un bus de donnée sur lequel transitent les données de plusieurs périphériques. Ces données doivent être multiplexées. Toutefois, le débit de ce bus est fixe, et les besoins de ces différents périphériques peuvent être variables. Il est donc nécessaire de partager la bande passante de ce bus de données entre les différents périphériques.
Prenons un exemple.
Les données transmises par un GPS sont relativement peu gourmandes en bande passante. En effet, un GPS émet en moyenne une information de géolocalisation par seconde (1Hz). Cette information est encodée en utilisant le standard NMEA 0183 qui repose sur des trames ASCII (1 octet/caractère). La longueur des trames les plus utilisées est d’au maximum 80 caractères. Le débit nécessaire est donc de 640 bps, ce qui est négligeable.
Une centrale inertielle permet de transmettre des informations sur la dynamique telles que les accélérations vectorielles et les accélérations rotationnelles. En encodant chaque accélération avec 8bits, et en obtenant 10 mesures par seconde (toutes les 100ms), le débit nécessaire est de 480bps (2x3x8x10), ce qui, une fois encore est négligeable.
Une caméra numérique CMOS YUV avec une définition de 640x480 avec encodage 16bits des pixels pour une fréquence de rafraichissement de 25fps nécessite donc une bande passante de 122,8Mbps (640x480x16x25) si l’on récupère le flux brut. Or, le débit maximum en 5.8GHz est de 2,048Mbps. Il est donc inconcevable d’utiliser ce flux vidéo brut. Plusieurs solutions s’offrent alors à nous :
o Utiliser un encodage 8bits des pixels
o Utiliser une résolution plus faible (320x240 par exemple)
o Réduire le taux de rafraichissement de l’image (20fps par exemple)
o Utiliser l’entrelacement horizontal vidéo (1 ligne sur deux)
o Compresser le flux vidéo (OmniCE avec un taux de compression de 4 à 8 par exemple)
En appliquant toutes les solutions proposées, le débit nécessaire est de 1,5Mbps.
De plus, pour avoir une vidéo fluide, des contraintes temporelles existent sur la transmission des images vidéo. Pour un rafraichissement de 20fps, chaque image doit être transmise dans un intervalle de 50ms. Il est possible d’imaginer la perte occasionnelle d’images afin d’éviter d’introduire un décalage trop important entre l’image courant et l’image affichée.
On remarque alors que les deux premiers périphériques ont un débit nettement plus faible que la caméra embarquée, et que les contraintes temporelles associées sont très différentes (1s pour le GPS contre 50ms pour la vidéo).
Il est donc nécessaire de répartir la bande passante entre les différents périphériques et d’assurer des échéances temporelles quant au transfert des données.
Connectique et protocoles de transfert de données
Plusieurs entités vont devoir interagir entre elles :
o le PC avec le transmetteur ;
o les deux transmetteurs entre eux ;
o le transmetteur embarqué avec les différents périphériques à bord de l’avion.
Il est nécessaire de définir la manière dont ces entités vont interagir et le format des données qui seront échangées. Cela s’appelle un protocole.
Plusieurs protocoles existent dans le monde de l’informatique. Ces protocoles sont associés à des bus de communication permettant de relier un périphérique matérielle à une entité de calcul (i.e. le processeur de votre ordinateur). Par exemple pour connecter un périphérique avec un ordinateur, il est possible d’utiliser les bus USB pour les périphériques externes de tout type, PCI pour des cartes internes, IDE pour des disques durs, Ethernet pour des périphériques réseau. Chacun de ces bus définissent le protocole permettant de communiquer avec l’ordinateur au travers du bus. Protocole et bus sont alors intimement liés.
Dans notre cas, le bus USB est une solution intéressante pour relier le PC au transmetteur. Cette connectique est relativement souple d’utilisation, et la programmation y est aisée.
Les périphériques peuvent être connectés au transmetteur embarqué en utilisant un bus série de type RS232. Ce bus est simple d’utilisation et très répandue pour des périphériques embarqués tels que le GPS.
La liaison entre les deux transmetteurs est un nouveau bus en soit. Il est donc nécessaire de définir le protocole permettant aux périphériques connectés sur ce bus de communiquer avec l’ordinateur.
Gestion de l’énergie embarquée
En aéromodélisme, énergie est souvent synonyme de poids, et poids est souvent synonyme de beaucoup de problème de maniabilité de l’appareil. Il est donc nécessaire d’avoir une politique de la gestion de l’énergie intelligente.
Toutefois, on peut remarquer que la durée d’un vol en aéromodélisme est relativement courte (de l’ordre de la dizaine de minutes), et que les appareils électroniques sont souvent peut gourmands en énergie. Par exemple, un téléphone portable offre l’opportunité de faire de la visioconférence pendant une heure sans problème.
Notre attention doit donc être portée sur deux points.
o Le choix de composants électroniques peut gourmands en énergie ;
o La centralisation des sources énergétiques, une source globale étant moins encombrante et moins lourde que plusieurs sources.
Conclusion
Les travaux futurs doivent se focaliser sur les deux premiers aspects, tout en faisant attention quand aux choix technologiques liés à l’énergie à bord de l’avion.