ELECINF344/381

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

Catégories

IRL : avancées de la journée

Ajourd’hui nous avons travaillé en parallèle sur deux thèmes : le FPGA, et l’interface web.

Côté FPGA, nous avons pu simuler une RAM lisible et inscriptible depuis le processeur, ce qui est encore peu mais nous permet de penser qu’on a compris comment le lien fonctionne. Nous avons ensuite une une réflexion sur l’architecture fonctionnelle des modules du FPGA.
La mémoire du FPGA doit pouvoir servir de tampon, étant donné que Linux (peu précis au niveau du timing) enverra des paquets de données par à-coups, alors que la sortie vers le laser devra être cadencée bien régulièrement. Nous utiliserons les blocs de RAM internes du FPGA comme buffers avant et après la RAM (cf schéma), et les RAMs SPI de manière à ce que l’ensemble soit vu comme une FIFO par l’extérieur.
Le module de sécurité surveille les sorties du bloc de contrôle des DACs pour s’assurer que le laser ne reste pas allumé dans une trop petite zone durant un temps trop long. La taille de la zone (du moins sa traductions en déplacements « absolus » au niveau des coordonnées numériques) devra être fonction de la distance minimale à laquelle un observateur peut potentiellement se trouver. La durée maimale d’exposition sera à déterminer à partir de la puissance du Laser et des recommandations médicales. Cet ajustement n’est clairement pas la priorité actuelle.

 

 

 

Du côté du serveur Web, ça a été plus chaotique. Nous étions partis depuis deux jours sur l’utilisation de WebPy. Cependant son intégration avec SQLite impose l’utilisation de modules Python tierce partie, et la cross-compilation de ces modules nous pose beaucoup de problèmes. Dernièrement nous avons tenter de passer à la daily-build de la µClibC pour résoudre un problème avec l’importation de pysqlite3, ce qui a eu pour résultat de casser notre rootfs (kernel panic au démarrage à cause de dl_iterate_phdr()). Une simple recompilation en rechangeant de version de µClibC semble ne pas suffire (pour une raison inconnue), nous tenterons une recompilation depuis zéro demain.
Ces problèmes nous ont pris assez de temps et nous allons probablement chercher sur d’autres pistes, peut-être du côté de Mongrel2 comme Sam nous l’a conseillé.

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).

 

RoseWheel prend la route !

Aujourd’hui nous avons commencé à élaborer le planning du projet.

Un bug tracker a été rapidement mis en place (Redmine) et va nous permettre de :

  • Lister nos tâches et en garder des traces
  • Faire du suivi de bugs et d’ajout de fonctionnalité
  • Nous assigner des tâches les uns les autres
  • Générer des diagrammes de Gantt
  • Partager des fichiers non versionnés (pdf, images, …)

Nous avons pu éclaircir quelques points sur lesquels nous nous posions des questions :

- Il est nécessaire de charger le Rosewheel avec des objets ayant un poids inférieur à 90kg et dont le centre de gravité est approximativement le même que celui d’un être humain.

- Il faut utiliser à la fois un gyroscope et un accelerometre pour nous permettre de mesurer l’angle d’inclinaison du manche du RoseWheel car on a :

  • gyro : integrale(biais + theta_point) = derive linéaire + theta
  • accelero : theta + bruit

ces deux mesures sont en fait complémentaires,

  • gyro = theta + composantes basses fréquences
  • accelero = theta + composantes hautes fréquences

donc fusion des capteurs = filtrage passe-bas + filtrage passe haut.

- Peut-être utiliser en plus un Kalman pour rendre le signal issu de la fusion des capteurs d’angle encore plus propre.

-  Pour la gestion de la sécurité de RW (Arret si detection d’obstacle), nous avons pensé à utiliser un système de sonars et/ou détecteurs infrarouges (Sharps). L’idée serait d’en avoir plusieurs  à l’avant du robot : certains pointant horizontalement pour détecter des murs, d’autres pointant vers le sol pour détecter un changement de pente ou un objet au sol. Détecter un changement de pente  pourrait permettre d’adapter l’allure : si descente on ralentit, si montée on accelère. Par ailleurs on pourrait évetuellement détecter un trou et s’arreter pour ne pas tomber dedans. Nous n’avons pas encore poussé plus loin nos investigations en terme de chiffrage et de choix  de composants.

- Il faut utiliser comme processeur principal un processeur capable de traiter à la fois les calculs des différents filtres (Kalman,passe-haut et passe-bas) pour les calculs de l’angle theta, de traiter les calculs issus des capteurs de distance (Sonars, sharps), de traiter les données issus des encodeurs. De calculer les prochains nombre de tours à appliquer aux moteurs.

- Nous allons remplacer les moteurs CC d’origine par des moteurs Brushless, il sera donc nécessaire d’utiliser un processeur sur la carte de puissance afin de gérer la commande de ceux-ci.