ELECINF344/381

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

Catégories

RoseWheel : Choix des composants – Architecture matérielle

La réunion de vendredi avec Alexis et Samuel nous a permis d’éclaircir un certain nombre de points. Nous avons ainsi pu établir aujourd’hui un choix quasiment définitif de nos composants ainsi que l’architecture  matérielle de RoseWheel.

Le système est composé de 3 cartes :

  • Une carte mère contenant toute la logique
  • Une carte de puissance permettant de contrôler les moteurs Brushless
  • La carte de puissance permettant de contrôler les moteurs DC du projet ZZAAG

La carte mère qui se trouvera sur le guidon contient :

  • 1 processeur STM32 qui sera en charge de traiter les calculs nécessaires à l’implémentation du filtre de Kalman pour la fusion des capteurs ainsi que les calculs pour l’algorithme d’asservissement des moteurs. Concernant cet asservissement, nous avons choisi dans un premier temps d’implanter un PID. Ensuite nous nous dirigerons vers l’implémentation d’un LQR
  • Les capteurs permettant le contrôle de l’équilibre, soit le gyroscope et l’accéléromètre
  • 3 UARTs, pour une connexion RS232 pour le debug, une connexion Zigbee, une connexion Bluetooth
  • 1 LCD permettant d’afficher des informations pour l’utilisateur
  • Des jumpers ADC pour la connexion d’une partie des Sharps pour la détection des obstacles
  • 1 port CAN bidirectionnel permettant de communiquer avec la carte de puissance de contrôle des moteurs Brushless

La carte de contrôle en puissance des moteurs Brushless qui permettra aussi, dans un premier temps, de faire l’interface entre la carte de contrôle de puissance des moteurs DC du ZZAAG et la carte logique. Cette carte contient :

  • 1 processeur STM32 permettant de générer les PWM nécessaires au fonctionnement, d’une part des moteurs DC sur la carte du ZZAAG, d’autre part les PWM permettant de gérer le contrôle des moteurs Brushless
  • 1 connecteur CAN bidirectionnel fin de communiquer avec la carte mère logique différentes informations. Notamment les données permettant l’asservissement des moteurs
  • 1 jumper pour la connexion des Sharps nécessaires à la détection des obstacles à courte distance
  • 1 jumper pour la connexion des encodeurs
  • 3 ports pour la connexion des données provenant des capteurs à effet Hall du moteur Brushless et permettant de gérer le contrôle de ces moteurs

La carte de contrôle de puissance du ZZAAG qui sera contrôlée par la carte de contrôle de puissance des Brushless et qui ne nécessite en entrée que 2 PWM (1 pour chaque moteur) ainsi que 2 autres entrées permettant de contrôler la direction.

Le choix plus précis des composants est à priori :

Accéléromètre : LIS3LV02DL – 3 axes – port SPI – boitier LGA-16 – fréq échantillonnage 640 Hz – prix : 15,09 €

Gyroscope : IMU-3000 – 3 axes – port I2C – boitier QFN – fréq échantillonnage 8000 Hz – prix : 34,98 €

Encodeurs : HEDS-5500#A06 – Vmax 30000 tour/min ( un peu beaucoup mais moins cher ) – fréq échantillonnage 100 kHz – prix : 50,07 €

Bluetooth: AMB2300 – prix : 29,04 €

Xbee : XBP24-AWI-001 – prix : 30,62 €

LCD : MDLS16265LED043V – prix 39,29 €

Sharps :

  • GP2Y3A003K0F – Min distance : 20cm – Max distance : 150cm  - Angle de vision : 25°  - prix 55,35 €
  • GP2Y0A710K0F - Min distance : 40cm – Max distance : 300cm  - Angle de vision : 25°  - prix 25,57 €

Capteurs ultrason :

  • MSU05 – Angle de détection plus large que les Sharps (55°) : possibilité de fusion de capteurs – Utilisation simple : 1 GPIO – prix 21.5 €

Enfin voici un schéma de notre architecture materielle :

[CASPER] Définition de l’architecture

Nous approchons d’une architecture définitive.

Nous pensons utiliser une beagleboard car elle permet de faire du traitement audio/video (DSP) et dispose d’une puissance de calcul conséquente. Nous embarquerons certainement un linux pour ne pas avoir à réécrire les drivers type webcam etc et faciliter les traitements.

La partie mécanique sera gérée par une carte que nous allons fabriquer avec un STM32. Elle recevra les consignes issues de la beagleboard (du tracking video et du gestionnaire d’émotions) et commandera en conséquence les servomoteurs.  Il va falloir écrire des drivers linux pour que cette carte soit considérée comme un périphérique par la carte maîtresse.

 

Architecture de CASPER

Pour les différents mouvements du robot nous envisageons (principe fourni par M. Polti), d’utiliser un système de trois tiges semi-rigides reliées d’une part à des moteurs et à un plan de l’autre. (voir le système en action) Ce système permet de bien reproduire les possibilités motrices d’un cou. On aurait également un moteur pour effectuer des rotations complètes du robot.

RoseWheel : réorganisations

Nous avons tiré des enseignements de notre présentation de ce matin. Particulièrement pour l’organisation générale du projet. Ainsi nous avons choisi de nous focaliser en priorité sur l’objectif majeur du projet RoseWheel : réussir à le faire tenir en équilibre sur ses 2 roues. L’asservissement que nous allons mettre en place sur les moteurs doit nous permettre au plus vite d’atteindre cet objectif. Pour ce faire nous avons remanié notre planning.

L’utilisation de moteurs brushless est une amélioration fondamentale mais peut être faite a posteriori. Au lieu de commencer par celà nous pouvons commencer par utiliser les moteurs à courant continu. Fournis avec une carte de puissance, ils nous permettront de tester rapidement notre asservissement. Le contrôle des moteurs brushless pourra être fait par la suite.

Mais avant cela l’asservissement doit fonctionner. La fusion de capteurs et la mise en place d’un filtre de Kalman doivent être au centre de nos préocupations. Nous avons réalisé à la soutenance que l’équipe Copterix traîterait de problématiques similaires. Nous allons donc essayer de coopérer avec eux. Il est possible que, pour joindre nos efforts, nous devions passer à un gyroscope 3 axes (et non le mono-axe de la présentation).

La semaine prochaine nous allons devoir développer des modèles de nos filtres sur Octave mais aussi de fabriquer un banc de tests pour vérifier que l’information filtrée est valide. Une carte développée par nos prédécesseurs/amis et comportant des capteurs similaires nous permettra de tester nos filtres avant de concevoir les cartes. Pour cela il faudra utiliser un/des servo-moteurs pour commander l’inclinaison d’une planche et vérifier que la sortie correspond bien à la commande que nous allons envoyer.