ELECINF344/381

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

Catégories

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

RoseWheel : Simulateur et Testbench

Aujourd’hui nous avons travaillé sur plusieurs fronts à la fois en vue de préparer la présentation d’une part et d’autre part d’avancer sur les différentes PSSC en cours, notamment la finalisation du TestBench et du simulateur.

Nous avons complètement restructuré la mécanique du Testbench. En effet, en rapport avec le Post d’hier soir, nous observions trop de bruit lors des transitions du moteur entre les différents angles.
Afin de palier à ce problème, nous avons ajouté un potentiomètre sur l’axe du servomoteur afin de pouvoir mesurer en temps réel et de façon précise le mouvement exact du moteur. Nous sommes alors en mesure d’extraire la partie issue du moteur dans le bruit du signal mesuré.
Nous avons de plus ajouté un rapporteur centré sur l’axe du servomoteur afin d’avoir un moyen de plus pour nous permettre de valider la fiabilité de la mesure des angles issus de l’accéléromètre et du gyroscope.

Concernant le simulateur, nous observons toujours des problèmes vis-à-vis des paramètres physiques. En effet, avec les paramètres que nous utilisons pour le moment, nous obtenons toujours une valeur saugrenue de la tension de commande (aux alentours de 3000V au lieu des 24V prévus). Nous avons donc remis en question chacun des paramètres que nous avions initialement calculés et nous sommes arrivés à la conclusion que les valeurs de la constante de couple reliant le courant au couple moteur et la constante de force contre électromotrice reliant la tension contre électromotrice à la vitesse de rotation étaient peut-être faussées.
Nous nous sommes donc penchés à nouveau sur une doc (très sommaire) des moteurs utilisés dans le zzaag. De plus Alexis nous a conseillé de simuler à l’aide de Matlab/Octave les équations d’état des moteurs que nous avions injectées dans les équations d’état de RoseWheel afin d’observer directement les valeurs du couple et de la vitesse de rotation de l’axe pour différentes valeurs des 2 constantes précédemment citées. Ceci nous permettra de vérifier les valeurs que nous avons calculé.

Dans l’optique de la présentation de demain, nous nous sommes penchés à nouveau sur un certain nombre de choses :

Le schéma de l’architecture matérielle a été revu et corrigé :

 

Le schéma de l’architecture logique a  été lui aussi corrigé :

RoseWheel fait des simulations

Cet article a été rédigé hier soir…

Nous avons terminé ce week-end le PCB de notre carte capteurs. Nous avons fait le schéma de notre carte principale mais Alexis va y ajouter la partie puissance et la router pour nous.

Carte Capteurs [avant]

Carte Capteurs [arrière]

Aujourd’hui nous avons travaillé en parallèle sur l’utilisation du banc de tests et sur le simulateur qui intègre le filtre de Kalman et l’asservissement.

Le simulateur commence à fournir des résultats mais nous avons encore des problèmes de valeurs numériques. Notre simulation fait intervenir des tensions de plusieurs milliers de Volts (alors que nos moteurs n’en acceptent que 24) pour réussir à redresser le gyropode. Cela est certainement dû à une mauvaise estimation de nos constantes km (constante de couple en N.m/A) et ke (constante force contre-électromotrice en V.s/rad).

Pour les calculer nous avons récupéré les caractéristiques du moteur sur le site du distributeur :

À charge nominale on a

  • Vitesse angulaire : VA = 3751 rpm
  • Couple : T = 0.88 N.m
  • Intensité : I = 18.36 A
  • Résistance : R = 0.66 Ohm
  • Tension : U = 24.09 V

Or

  • km = T / I = 0.048 N.m / A
  • ke = (U -- R * I) / VA = 0.030 V.s / rad

Mais avec ces valeurs nous rencontrons les problèmes mentionnés plus haut. Ces problèmes viendraient-il d’ailleurs ? Alexis nous a conseillé de faire un simulateur des moteurs seuls pour déterminer vérifier nos constantes. À suivre…

Par ailleurs, comme le montre la figure suivante, le filtre de Kalman se comporte bien. Même avec un rapport signal sur bruit médiocre nous arrivons à reconstituer assez fidèlement l’angle d’inclinaison. Pour l’asservissement nous avons testé deux techniques : PID puis LQR. Le PID s’avère être délicat à régler et ne nous a pas donné de résultat satisfaisant (divergence de l’erreur au bout d’un certain temps). Le LQR se comporte beaucoup mieux et propose un réglage moins empirique. Couplé au filtre de Kalman, et problèmes de valeurs numériques exclus, notre système se comporte vraiment comme nous le souhaitons. Reste donc à vérifier si nous observons le même comportement avec les bonnes valeurs numériques pour les moteurs. Notons que pour l’instant nous incluons le déplacement et la vitesse dans nos variable d’état ce que nous ne pourrons faire que si nous arrivons à monter des encodeurs sur la mécanique du projet zzaag.

Simulateur RoseWheelCliquez sur l’image pour voir l’animation.

Concernant le banc de tests nous avons terminé sa réalisation. Nous avons monté une vidéo tournée vendredi pour le montrer en action :

Cette première version du banc de tests fonctionne ainsi :

  • on communique avec la carte de TP en RS232
  • la carte de TP commande le servo qui incline la carte capteurs du projet Wheely
  • on récupère les données des capteurs via RS232 sur l’ordinateur
  • on affiche conjointement les courbes de la commande et de la mesure

Pour les mouvements lents, nous procédons par rotations successives. La précision du servomoteur étant assez faible, cela entraîne des mouvements saccadés et introduit un bruit non négligeable lors des transitions. Par ailleurs, la calibration du banc s’avère insuffisante ce qui se traduit par un offset sur les valeurs mesurées. Nous aurions aimé présenter des courbes (superposition commande / mesure du banc de test) mais nous avons été chassés d’A405 avant d’avoir pu les exporter… No comment. Nous travaillerons demain à l’amélioration de ces résultats.

RoseWheel : PCB, banc de tests

Après deux jours de travail, nous avons fini les schémas de nos PCB et, à l’heure où cet article est écrit, nous parachevons le routage de la carte capteurs (autrefois appelée « carte logique »). Parmi les changements clé que nous avons faits, nous pouvons citer notamment l’inclusion d’une alimentation exclusive pour les références des convertisseurs analogique-numériques à l’intérieur du gyroscope et de l’accéléromètre – cela permet d’avoir des conversions plus fiables et donc de réduire le bruit des mesures.

Pour la carte principale (ancienne « carte de puissance »), les plans ont été un peu modifiés : finalement, le circuit de puissance, responsable du contrôle des moteurs en courant, sera intégré par Alexis à la carte, principalement à cause de problèmes d’intégrité du signal (utiliser le bus CAN en entrée permet d’être plus robuste face aux bruits induits par les moteurs à courant continu) et économiques (l’intégration élimine la nécessité de fabriquer une troisième carte qui ne ferait qu’accepter un PWM en entrée et le transmettre aux moteurs).

Côté banc de test, nous avons réussi à contrôler le servomoteur en angle avec la carte de TP, en utilisant les broches originalement assignées au bus SPI pour sortir du PWM. Nous avons commencé alors à le calibrer, puisque la position horizontale (à 0°) ne se trouve pas forcement au milieu de l’échelle du PWM ; pour faire cela, nous avons utilisé une application Android qui nous indiquait l’angle d’inclinaison du téléphone portable. Voici notre dispositif expérimental :

Après cela, nous avons  fini la partie mécanique en fixant une planche de balsa pour tenir la carte dans sa place pendant que nous faisons les tests. Le montage final est celui-ci :

Par rapport à la simulation physique, nous hésitons encore entre continuer à la développer en Octave ou passer à Matlab, étant donné que certaines bibliothèques utiles pour l’implémentation du filtre de Kalman ne sont pas disponibles dans le logiciel libre.

RoseWheel: banc de test (capteurs et Kalman)

Aujourd’hui nous avons démarré l’élaboration d’un banc de test pour pouvoir commencer à expérimenter et régler notre filtre de Kalman. Les capteurs que nous allons utiliser n’étant pas encore disponibles, nous allons donc commencer par effectuer nos tests en utilisant la carte capteurs du projet Wheely.
Voici des images avant et après la pose de la carte :

Nous avons rapidement fait un code pour contrôler le servomoteur à l’aide de la carte de TP. Nous réutiliserons le code de Wheely pour récupérer l’information des capteurs via RS232.

Demain, nous profiterons de notre dernier cours sur les PCB pour finir le placement-routage de nos cartes. Nous ne maîtrisons pas encore les problèmes d’intégrité du signal donc nous espérons pouvoir bénéficier de l’expertise de nos encadrants sur ce domaine sensible. En effet, avec les modules de communication bluetooth/zigbee, le bruits des moteurs, et autres imprévus, nous aurons forcément des mauvaises surprises.

Enfin, nous avons avancé sur le simulateur conçu avec octave, voici un aperçu :

 

La courbe verte représente la commande, la rouge l’erreur (l’angle par rapport à la verticale), la valeur désirée (angle nul).
La figure du dessus (en bleu aussi) représente le Gyropode.
Nous avons commencé à implémenter et régler les coefficients du PID mais ce n’est, pour l’instant, pas encore au point.
À suivre…

 

 

 

[CASPER] Architecture et liste de composants

Architecture globale

 

La beagleboard est l’élément central du système (www.beagleboard.org). Elle est chargée des algorithmes de haut niveau tel que le traitement de la vidéo et le traitement audio. C’est aussi elle qui se chargera de la connectivité internet et du pilotage des actionneurs.

Elle sera étendue par une carte embarquant un contrôleur STM32 chargé de piloter un écran LCD à partir de données stockées dans une mémoire flash.

Les informations sur les composants requis sont fournies dans les paragraphes suivants, les informations détaillées concernant les actionneurs/servomoteurs seront publiée dans un prochain post.

 

Ecran

Color LCD 128×128 Nokia Knock-Off

http://www.sparkfun.com/products/569

Avantage : bien documenté

Connexion au STM32 : un seul port SPI (pas de bus data)

Rq : sparkfun indique vendre un « loose connector » pour 2$ sur la même page, qui apparemment facilite le soudage…

Accessoires écran

1 transistor pour contrôle du rétroéclairage (http://fr.farnell.com/nxp/bc846/transistor-npn-boitier-sot-23/dp/1081227)

1 régulateur tension de 7V (pour le rétroéclairage).

Le modèle choisi sera finalement un LT1932 (http://fr.farnell.com/linear-technology/lt1932es6-pbf/ic-dc-dc-convert-led-dr-6sot2/dp/1651929). Il s’agit en réalité non pas d’un régulateur de tension mais d’une source de courant spécifiquement conçue pour alimenter une ou plusieurs leds.

Pour fonctionner, ce régulateur a besoin outre quelques résistances et condensateurs, d’une diode schottky (http://fr.farnell.com/rohm/rb050la-40tr/diode-schottky-40v-3a/dp/1680015) et d’une inductance de 6.8µH telle que celle-ci http://fr.farnell.com/panasonic/eljfa6r8jf/inductance-1210-6-8uh/dp/3838341 qui peut se commander à l’unité.

Carte STM32

1 STM32F103CBT6 (ou modèle équivalent, on a juste besoin d’un port SPI pour l’écran, un deuxieme pour une mémoire flash, un UART pour la liaison avec la beagle, et le reste des I/O serviront pour les extensions éventuelles)

1 régulateur 3.3V (L4931CD33)

1 prise jack pour l’alimentation

1 quartz 8MHz

1 prise JTag

1 switch (pour le reset…)

1 connecteur UART

1 transceiver UART (http://radiospares-fr.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6608802)

1 connecteur 6 broches (pour le SPI)

1 mémoire flash http://fr.farnell.com/spansion/s25fl032k0xmfi011/memory-flash-32m-3v-spi-8soic/dp/1861630 , qui servira à stocker les images pour le lcd

À noter : la fréquence de fonctionnement de cette flash (104MHz) laisse une marge suffisante pour récupérer des images 128*128 couleur à envoyer au LCD afin de l’animer. C’est en pratique le microcontrôleur qui limitera la vitesse de fonctionnement.

 

Son

Haut-parleur

2 Haut-parleurs MCKP2852SP1F-4752 (Ref Farnell 1801037, http://fr.farnell.com/multicomp/mckp2852sp1f-4752/dp/1801037)

Ce modèle est suffisamment petit pour pouvoir l’intégrer au visage de casper. Le deuxième pourra être placé dans le socle

 

Microphone

5 Micro pastille MCKPCM-40H15-40DB-4797 (Ref Farnell 1758416, http://fr.farnell.com/multicomp/mckpcm-40h15-40db-4797/microphone/dp/1758416)

Ce modèle a l’avantage d’être très plat (1.5mm) ce qui permettra de l’intégrer plus facilement. Plutôt que d’ajouter juste un micro à Casper, nous pourrions en ajouter 3 ou 4 autres à la base qui pourraient servir à la détection de la provenance du son. On peut alors imaginer toutes sortes de réactions du robot.

À noter : chaque microphone a besoin d’un petit circuit de polarisation, composé d’une résistance et d’une capacité de 5µF.

WiFi

Étant donné la présence de l’USB hôte sur la Beagleboard, nous pouvons pencher pour une solution de clef USB Wifi facilement trouvable dans la grande distribution (http://www.grosbill.com/4-bluestork_cle_wifi_nano_usb_wifi_n_150mbps-80561-reseaux-carte_reseau_sans_fil)

Une carte Wifi de facteur de forme SD pourrait toutefois être essayée (?).

Camera

Nous utiliserions là encore une Webcam très classique (http://www.grosbill.com/4-logitech_c120-100684-peripheriques-webcam) reconnue par linux.

Nous sortirions les différents composants de la coque de la caméra afin de pouvoir les intégrer dans un volume compact.