ELECINF344/381

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

Catégories

IRL : du nouveau, encore du nouveau !

Après une n ème réflexion le projet IRL évolue et se précise :

Laurent s’est penché sur les datasheets de différents modules Zigbee, notamment ceux employés à Télécom Robotics (nous remercions au passage Samuel pour son lien). Il a étudié comment brancher les modules Zigbee pour pouvoir les utiliser via un lien RS232. Pendant ce temps, Yoann s’est renseigné sur internet sur les DAC et nous avons tous ensemble regardé les cartes d’extensions disponibles pour la Beagleboard.

Yoann et Caroline ont compris grâce à Alexis que Linux ne serait pas bien adapté à l’envoi en temps réel des points au laser. Nous utiliserons donc un micro contrôleur dédié à cette tâche avec un OS temps réel qui sera vraisemblablement FreeRTOS (toutes suggestions serait la bienvenue). Ceci porte à trois ou quatre le nombre d’entités du système qui est désormais formé des éléments suivants :

  • Une carte (appelée « principale » par la suite) hébergeant l’interface web d’administration, dont les fonctions principales sont le stockage des informations et le pilotage du système.
  • Un micro contrôleur traitant le flux DMX à la volée, recevant des informations de la carte principale par Zigbee.
  • Un micro contrôleur en charge des déplacements du laser, recevant des informations par un lien filaire qu’il a avec la carte principale.
  • Un autre micro contrôleur en charge de la sécurité : il coupe le laser s’il reste sur un même point pendant trop longtemps (cette fonction pourrait éventuellement être déportée sur la carte principale).

 

Sur le même sujet :

  1. IRL : Forme générale du projet
  2. Laser, début de l’aventure
  3. IRL : une présentation riche en enseignements !

5 comments to IRL : du nouveau, encore du nouveau !

  • Yoann

    Pour la boucle de sécurité, c’est apparemment une mauvaise idée de la mettre sur la carte principale : si la boucle de sécurité crashe en même temps que le reste c’est pas cool. Sur le micro-contrôleur qui ne fait qu’envoyer les points, faut voir si ça continue de poser des problèmes.
    Après vérification dans la FAQ de ce site : https://rt.wiki.kernel.org/, il semble que comme le disait Alexis, Linux RT soit précis au mieux à 1 ms avec le bon patch, ce qui est environ 10 fois trop pour le contrôle du laser. Dans ma recherche rapide, je n’ai pas trouvé de chiffre de latence pour FreeRTOS, mais j’ai vu à plusieurs endroits qu’il était adapté au temps réel dur, donc ça devrait aller (à confirmer).
    L’idée serait donc probablement d’avoir une fifo qui permettrait d’éviter les interruptions dues à une transmission via un bus (je ne sais pas si c’est significatif) dans laquelle la carte Linux écrit par « gros paquets » et le micro-contrôleur lit par « petits morceaux ». D’après un premier calcul à la grosse louche, une FIFO de 9Kbits à 8€ chez Farnell permet de stocker ~280 points, ce qui fait que la carte sous Linux doit y écrire environ toutes les 0,02s (pour du 15 000 points par sec), on revient dans un ordre de grandeur apparemment raisonnable pour linux RT.

    Qu’en pensez-vous ?

  • Alexis

    Pour pouvoir envoyer les points de façon régulière, il faudra déclencher des interruptions à partir d’un timer. La notion d’OS temps réel ou non n’est pas vraiment importante, il faut juste avoir la possibilité de déclencher des handlers d’interruptions à intervalles réguliers, précis, et sans trop d’overhead.
    Sinon, à propos de la fifo de 9kb : de combien de RAM dispose le microcontrôleur qui sera en charge des DAC ?

  • Je pense que je me sentirais effectivement plus rassuré si la boucle de sécurité était sur un micro contrôleur indépendant du reste.

    Rq : Ton calcul implique que l’on code les coordonnées sur 16 bits (9kb/280/2coordonnées=16bits => 65536 possibilités sur une coordonnée, à comparer avec la précision du laser… peut on décemment tirer profit de cette précision ou est-ce inutile ? A voir par la suite quelle précision on adoptera en faisant des tests de résolution.

    Sinon, je valide les conclusions que tu tires de ton calcul dans lequel tu te places rappelons le dans le pire cas, i.e le cas où l’on doit transmettre le plus de points par seconde (on transmet de 8k à 15k points par secondes selon nos prédécesseurs).
    En conclusion, je pense que la combinaison de Linux RT et de FreeRTOS semble adaptée pour résoudre le problème.

    Quant au moyen de communication entre les deux entités, je pense que la fifo semble toute désignée car c’est exactement ce que l’on veut faire : une communication unilatérale en fifo entre deux systèmes (à part si l’on veut surveiller la température du laser, auquel cas il sera toujours possible de déporter cette fonctionnalité sur la carte en charge de la sécurité : ça paraitrait logique après tout !).

    Pour ce qui est des interruptions si on utilise un bus, il faudrait estimer leurs poids sur le système en fonction du micro contrôleur que l’on utilise, à voir dès demain !

  • Alexis Polti

    « la fifo semble toute désignée » : en tant que fonctionnalité oui, en tant que composant externe c’est beaucoup moins sûr :) D’où ma question sur la quantité de RAM disponible sur le contrôleur indépendant…

  • Je ne suis pas certain de l’opportunité d’avoir un micro-contrôleur séparé pour gérer la sécurité. Il y a moyen de faire un module de sécurité dans lequel on a suffisamment confiance en utilisant :
    * une routine d’interruption périodique assurant cette opération plus prioritaire que l’ensemble du système (y compris le système d’exploitation) et totalement indépendante ;
    * une version MMU du système d’exploitation pour interdire aux tâches en cours d’aller modifier les registres d’interruption qui permettraient de désactiver cette routine.