ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Architecture logicielle de Copterix

Aujourd’hui, après m’être renseigné sur 0MQ, pour le dialogue entre les différents modules de notre futur Copter, j’ai essayé de fixer l’architecture logicielle qu’on pourrait utiliser, à travers un schéma. Le voici, suivi de quelques explications :

 

Le STM32, qui fonctionnerait sous FreeRTOS, est directement relié aux capteurs et actionneurs de la carte. Ceci est nécessaire, notamment pour l’acquisition des données fournies par les capteurs : le filtre de Kalman nécessite que les données de tous les capteurs soient acquises presque en même temps. Il nous faut donc du vrai temps-réel, d’où l’intérêt du STM32 sous FreeRTOS.

 

Tournant sur la Gumstix :

Un module serait dédié aux communications avec le STM32 via l’UART. Ce module ferait des updates régulières des données des capteurs pour le filtre de Kalman, via les bibliothèques 0MQ.

Le filtre de Kalman fait l’objet d’un module à part, qui se chargerait d’envoyer régulièrement des updates au module de contrôle, pour lui indiquer l’attitude de l’objet.

D’autre part, la caméra fournit un flux vidéo (via l’API Video4Linux), qui sert comme source pour le filtre de Kanade, afin d’estimer la vitesse en translation de l’hélicoptère, fournie ensuite au module de contrôle. On aurait pu envisager d’inclure cette vitesse au filtre de Kalman, mais ce renseignement n’étant pas obtenu au même moment que les données des autres capteurs, il nous semble nécessaire de traiter séparément l’asservissement en attitude et l’asservissement en translation, quitte à utiliser un autre filtre de Kalman pour la vitesse.

Au niveau du streaming vidéo via wifi, je pense qu’on aurait pu se servir de GStreamer afin d’envoyer un flux compressé via Wifi, mais nous avons laissé cette possibilité de côté pour le moment : l’utilisation de la caméra et du filtre de Kanade semblent déjà trop gourmands en ressources pour qu’on puisse se permettre cette fantaisie. Pour le moment, Axel s’occupe de voir s’il est possible d’améliorer les performances, trop faibles pour l’utilisation du filtre de Kanade. Nous verrons donc plus tard si nous pourrons réenvisager de faire du streaming vidéo.

D’autre part, un module de communication en Wifi serait chargé de transmettre des « ordres » reçu d’un ordinateur ou smartphone au module de contrôle.

 

En revanche, il y a un problème dans cette architecture : le module (matériel) radio-fréquence est connecté directement sur le STM32. Or, les ordres reçus via RF devraient idéalement être transmis au module de contrôle. Je vois différentes solutions à ce problème :

- Transmettre les ordres RF reçus à la Gumstix, via l’UART. Mais cela semble être un chemin assez compliqué (et inutile) pour ces ordres.
- Contrôler les actionneurs selon les ordres donnés par la Gumstix, sauf quand on reçoit des ordres RF. Mais cela me semble difficile comme solution (comment faire en sorte que l’asservissement n’annule pas aussitôt les commandes transmises via RF?)
- Déporter la partie logicielle de contrôle sur le STM32, ce qui permettrait en plus de décharger la gumstix d’une partie de sa charge. (après tout, je ne sais pas ce qui m’a poussé à considérer la partie contrôle sur la Gumstix, et pas sur le STM32)

Je pense que la meilleure solution serait plutôt la troisième, mais j’attends quand même de voir ce qu’en pensent les autres.

 

De leur côté, Samuel et Bertrand ont fini les schematics du PCB, et le routage est en cours, il devrait être bientôt fini, comme prévu.

Sur le même sujet :

  1. Copterix : les aventures commencent
  2. Copterix : Architecture
  3. Copterix : début du projet
  4. RoseWheel : le retour !
  5. [CASPER] Architecture et liste de composants

6 comments to Architecture logicielle de Copterix

  • François-Xavier MOREL

    Quel protocole allez-vous utiliser sur le lien série qui relie la Gumstix au STM32 pour transmettre les informations des capteurs (et eventuellement du Transceiver RF) ?
    Est-ce que ça sera plutôt synchrone avec la Gumstix qui enverra une requête et le STM32 qui répondra par une trame contenant les informations requises ?
    Ou est-ce que le STM32 envoie périodiquement des informations de manière asynchrone et ce sera à la Gumstix de faire la part des choses ?

    Comment allez-vous encoder l’information ?

    • Loïc

      Nous n’y avons pas encore réfléchi, je vais me renseigner sur les différents protocoles existant.

    • Loïc

      Après réflexion, je pense qu’on va se tourner vers le protocole XModem (ou d’une de ses améliorations, comme ZModem), du fait de sa simplicité, de la présence d’un checksum, et d’une indication de début/fin de paquet. Par contre j’envisage de le modifier légèrement, de façon à ne pas redemander les paquets qui auraient été mal transmis, ce qui me paraît être une perte de temps dans une application temps-réel comme celle-ci.

      Le STM32 enverrait alors des informations quand il en aurait, de manière asynchrone, à la Gumstix de récupérer ces données le moment venu. Inversement pour les commandes des moteurs.

      Edit : après réflexion rapide, il me semble que la méthode décrite juste au dessus introduit un accès concurrent à l’UART, du coup on aurait peut-être intérêt à respecter un ordre, du type « je reçois des résultats de capteurs, j’envoie des commandes, je reçois des résultats, j’envoie des commandes, etc… »

  • Avez-vous regardé comment ça se passe pour 0MQ et publish/subscribe ? À mon avis, le module d’interface avec la carte STM32 doit :
    - publier ce qu’il reçoit du STM32 sous la forme d’un PUB (tous ceux que ça intéresse pourront ensuite écouter sur un SUB)
    - recevoir ce qu’il doit publier sur un PULL (ceux qui veulent publier le feront sur un PUSH)

    Il y a rarement besoin de faire des communications pair à pair en 0MQ, souvent ce n’est pas le meilleur paradigme à utiliser. On pourra en discuter en live si vous voulez.

    • Loïc

      Oui justement, j’avais vu le mécanisme de publish/suscribe, et ça me semblait parfaitement adapté pour la communication des données reçues du STM32 (c’est ce que j’ai exprimé à travers les 0MQ_update en fait, c’est juste que pour le moment il n’y a qu’un module qui écoute).

      Je n’avais pas encore vu le système de Pull/Push, mais effectivement cela m’a l’air bien pour la partie réception du module d’interface avec le STM32, si jamais on fixe le module de contrôle sur le STM32, comme sur le schéma.